공학으로서의 보안, LLM, 그리고 연구의 의미에 관한 단상
목차
-
서론: 컴퓨터 과학에서 컴퓨터 보안 연구의 의미
-
본론
-
결론: 철학, AI, 사이버 보안을 아우르는 멋지고 명쾌한 해답
서론: 컴퓨터 과학에서 컴퓨터 보안 연구의 의미
나는 국내 모 대학에서 컴퓨터 보안으로 박사를 받고 싶은 대학원생이다. 정확히 말하면 그 악명 높은 석박사통합과정의 석사 연차다. 아직 박사과정이라고 부르기에는 양심이 찔리고, 석사과정이라고 부르기에는 남은 시간이 지나치게 길다.
우리 연구실에서는 한 번, 세계적으로 손꼽히는 보안 연구실에서 박사학위를 받으신 분의 세미나가 열린 적이 있다. 그분은 발표를 마친 뒤 교수님의 인도에 따라 우리 연구실에 물리적으로 처넣어지셨고, 이후 약 다섯 시간 동안 영어 토킹을 빙자한 토론과 서울 맛집 소개가 수행되었다.
그때 등장한 화두 중 하나는 보안 학계에 대한 그분의 환멸이었다. 그분의 주장을 최대한 순화하면 다음과 같다.
컴퓨터 보안 학계는 근본적으로 유사과학과 크게 다르지 않다.
실제 발언은 이보다 조금 더 급진적이었다. 다만 이 글이 그 거대한 주장을 전부 다루려는 것은 아니다. 내가 가져오려는 것은 그중 보안 논문의 평가 방식에 관한 불편한 질문 하나뿐이다.
그분이 특히 문제 삼은 것은 신규 취약점이었다.
첫째, 논문의 기여를 증명하기 위해 반드시 신규 취약점을 찾아야 한다고 여기는 관행은 이상하다. 둘째, 발견한 신규 취약점의 개수를 제안 기법의 우수성을 보여주는 핵심 증거로 사용하는 것도 이상하다. 셋째, 수많은 프로그램과 설정을 시험한 뒤 성공한 사례만을 골라 제시한다면, 이 모든 과정은 거대한 데이터 체리 피킹이 될 수 있다.
당시의 나는 이 주장에 강하게 반대했다. 새로운 기법이 실제 프로그램에서 새로운 취약점을 발견했다면, 그것은 해당 기법이 현실에서 유용하다는 꽤 설득력 있는 증거라고 생각했기 때문이다.
우리는 서로의 주장에 끝내 동의하지 못했지만, 서울 맛집 정보를 공유하기 위해 적당한 지점에서 논쟁을 묻었다. (사실 짬 차이로 내가 숙였다.)
지금 돌이켜보면 당시의 쟁점을 좀 더 정확히 표현하면 다음이 될 것이다.
보안 연구에서 실제로 작동했다는 사실은 연구의 기여를 어디까지 증명하는가?
컴퓨터 보안 연구를 평가할 때는 과학적 설명과 공학적 검증을 함께 살펴보는 것이 도움이 된다고 생각한다. 적어도 내가 관심을 두는 시스템 보안 연구는 자연에 이미 존재하는 법칙을 발견하는 일보다, 인간이 만든 복잡한 시스템에서 작동하는 해법을 설계하는 일에 가까운 편이다.
이런 연구에서는 방법의 우아함에 더해 실제 환경에서의 효과, 실패 조건, 비용과 재현 가능성을 함께 보면 기법의 가치를 판단하기가 수월해진다.
신규 취약점 발견은 현실 적합성을 보여주는 한 가지 증거다. (나는 그렇게 생각한다) 제안한 기법이 합성된 예제뿐 아니라 실제 규모의 코드에서도 유의미한 문제를 찾을 수 있음을 보여주기 때문이다.
그러나 신규 취약점을 찾았다는 사실과, 그 발견 개수가 기법의 일반적인 우수성을 나타낸다는 주장은 구분할 필요가 있다.
발견 개수만으로 다른 프로그램과 취약점에서도 그 기법이 우수할 것이라고 판단하기는 어렵다. 어떤 프로그램을 골랐는지, 얼마나 많은 대상을 시험했는지, 실패한 대상에는 어떤 특징이 있었는지를 함께 보지 않으면, 성공에 기법과 실험 대상의 선택이 각각 얼마나 기여했는지 불분명하게 남을 수 있다.
다시 말해 “새 취약점을 찾았다”와 “따라서 이 방법은 일반적으로 우수하다” 사이에는 꽤 긴 거리가 있다.
이 긴 인트로는 바로 그 거리에 관한 이야기다.
최근 연구를 하다가 문득 다음과 같은 의문이 들었다.
실제로 작동하는 것이 중요한 공학적 연구라면, LLM으로 좋은 결과를 냈다는 사실은 그 선택을 어디까지 정당화해주는가?
LLM에 관한 재미없는 농담
내가 즐겨 사용하는 LLM 연구 농담이 하나 있다.
내가 왼발로 의자를 차면 덜컹한다.
오른발로 의자를 차면 덜커덩한다.
양발로 의자를 찼더니 덜커덩 덜컹한다.
몹시 놀라운 발견이다.
이 주장에 관해 수백 번의 의자 차기 실험을 수행하고, 왼발·오른발·양발 조건에서 발생한 소리의 차이를 정량적으로 분석한 뒤 논문으로 제출한다면, 나는 아마 데스크 리젝, 즉 입구컷부터 걱정해야 할 것이다.
그런데 여기서 의자를 LLM으로 바꾸면 상황이 조금 달라지는 것 같다.
왼쪽 프롬프트를 입력했더니 LLM이 덜컹한다.
오른쪽 프롬프트를 입력했더니 LLM이 덜커덩한다.
두 프롬프트를 함께 입력했더니 덜커덩 덜컹한다.
그리고 갑자기 다음과 같은 제목이 가능해진다. “대규모 언어 모델의 프롬프트 구성에 따른 복합적 응답 행동에 관한 실증 연구”. 운이 좋다면 탑 티어 학회에 붙을지도 모른다.
물론 실제 학회가 이 정도로 단순하다는 뜻은 아니다. 이 농담은 내 불만을 설명하기 위해 공들여 제작한 허수아비에 가깝다.
(새롭고 복잡한 대상을 관찰하는 일에는 충분히 가치가 있을 수 있다. 내가 이 농담으로 표현하고 싶었던 것은, 다른 대상이었다면 사소하게 여겼을 관찰에 LLM이라는 이유로 조금 더 관대해지는 것은 아닌가 하는 의심이다.)
주변 사람들은 너그럽게도 이 농담에 공감해주었다. 그래서 나는 한 걸음 더 나아가 다음과 같이 생각했다.
보안 연구에서 LLM을 마법 망치로 사용하는 몇몇 논문을 읽을 때면, 그 사용 이유와 성과 사이의 설명이 조금 더 있었으면 좋겠다.
이 생각은 LLM의 사용을 제대로 정당화하지 못한 논문은 리젝한다는 지도교수님의 의견과, 랩 미팅에서 같은 문제로 수없이 깨진 나의 경험을 통해 강화되었다.
하지만 지도교수님과 랩 미팅은 과학적 증거가 아니다. 적어도 내가 랩 미팅에서 깨진 횟수는 통계적으로 유의미할 수 있지만, 그것만으로 일반적인 결론을 내리기는 어렵다.
처음에는 문제 정의가 있었다.
적어도 순서상으로는 그래야 했다.
그래서 나름대로 기준을 세워보기로 했다.
지극히 개인적인 ‘LLM을 잘 쓴 논문’과 ‘그렇지 않은 논문’의 구분
나도 연구를 해야 한다. 게다가 LLM을 사용해야 한다. 왜냐고 묻지 마시길. 제 월급은 거기서 나온다.
생계는 충분히 강한 연구 동기지만, 방법론적 정당화로는 대체로 받아들여지지 않는다. 따라서 내가 생각하는 ‘LLM을 잘 쓴 연구’와 ‘그렇지 않은 연구’의 차이를 파악할 필요가 있었다.
이를 위해 엄밀하고 공정하며 재현 가능한 논문 선정 절차를 수행했다.
(이 괄호 안에는 여러분이 원하는 멋진 서베이 논문에 등장하는 데이터셋 선정 과정과, 그 과정이 공평하고 공정하다는 증명이 들어 있다. 납득하기 어렵다면 상자 안의 양을 떠올리시면 된다.
이제 납득하셨으리라 믿는다.)
국제적 분쟁 방지를 위해 자세한 논문 이름은 공개하지 않겠다.
내가 좋다고 느낀 연구들은 대체로 세 가지 질문에 비교적 좋은 답을 제시하고 있었다.
첫째, LLM은 무엇을 담당하며, 어떤 이점이 있는가?
설득력 있게 읽었던 연구에서는 LLM에 맡기려는 문제가 비교적 구체적으로 정의되어 있었다.
예를 들어 자연어로 작성된 보안 요구사항과 코드 사이의 관계를 연결하거나, 구문적으로 다른 코드에서 비슷한 보안 불변식의 위반을 찾거나, 불완전한 문맥에서 분석에 필요한 후보를 생성하는 경우다.
“의미 이해가 필요하므로 LLM을 사용했다”는 설명만으로는 이런 설계의 적절성을 판단하기 어려웠다.
다루려는 의미 관계와 LLM의 입력·출력, 출력의 정오를 판단할 기준과 전체 시스템에서의 역할이 드러나면 그 선택을 이해하기가 쉬워진다. 더 단순한 규칙이나 검색, 기존 프로그램 분석, 소형 모델과의 비교도 LLM이 제공하는 이점을 가늠하는 데 도움이 된다.
LLM이 유일하게 가능한 해법일 필요는 없다. 더 높은 성능이나 더 넓은 적용 범위, 낮은 개발 비용도 충분히 선택 이유가 될 수 있다. 추론 비용, 재현성과 불투명성에 관한 부담을 함께 비교하면 그 이점이 어느 정도인지 더 잘 판단할 수 있을 것이다.
다만 LLM을 먼저 쓰기로 했다면, 그 선택을 다른 대안과 비교해보는 과정이 특히 궁금해진다. 새로운 도구를 써보다가 적절한 문제를 발견할 수도 있으니, 출발한 순서만으로 연구를 평가하기는 어려울 것이다.
아쉬웠던 경우는 규칙이나 검색으로도 처리할 법한 문제에서, 최종 성능이 조금 높아졌다는 설명 외에 LLM을 선택할 이유를 충분히 찾기 어려웠을 때다. 문제와 성과를 연결하는 설명이 부족하면, LLM이 설계상 필요한 구성요소인지 논문을 그럴듯하게 만드는 장식인지 독자로서는 판단하기 어렵다.
둘째, 성능 향상은 어디에서 왔는가?
나는 작동한다. 고로 기여한다.
데카르트는 이런 말을 한 적이 없다. 몇몇 실험 절을 읽다 보면 비슷한 인상을 받을 때가 있다.
LLM을 추가한 뒤 결과가 좋아졌다면, 그 개선이 어디에서 왔는지도 궁금해진다.
프롬프트가 좋아서인지, 검색된 문맥이 좋아서인지, 모델의 규모가 커서인지, 외부 도구가 실제 판단을 수행했기 때문인지 살펴볼 수 있다.
각 구성요소의 기여를 알아보는 데에는 ablation study와 baseline 비교가 도움이 된다. 모든 구성요소를 한꺼번에 넣고 최종 숫자만 제시하면, 왼발, 오른발, 의자, 바닥, 녹음기와 방의 습도를 모두 바꾼 뒤 소리가 달라졌다고 주장하는 셈이다. 결과의 차이는 확인할 수 있어도 무엇 때문에 달라졌는지는 불분명하게 남을 수 있다.
셋째, 언제 틀리며 틀렸을 때 무엇이 깨지는가?
모든 성공한 데모는 서로 비슷하지만, 실패한 시스템은 저마다의 방식으로 실패한다.
입력이나 문맥이 달라질 때 판단이 흔들리는지, 모델이나 프롬프트의 변화에 결과가 얼마나 민감한지 살펴볼 필요가 있다. 정확도가 조금 오른 대신 분석 비용이 수십 배 증가했다면, 그 교환 관계도 함께 보면 성과의 의미를 판단하는 데 도움이 된다.
오류의 영향은 LLM이 맡은 역할에 따라 달라진다. 추천된 취약점 후보를 사람이 검토한다면 오탐을 걸러낼 수 있다. 반대로 LLM의 “이 경로는 안전하다”는 판정으로 분석 대상을 제거한다면, 한 번의 오답이 취약점 누락으로 이어질 수 있다.
모든 LLM 출력을 형식 검증으로 확인할 필요는 없다. 오류가 연구 결론과 실제 보안성에 미치는 영향에 맞춰 검증 수준을 정하는 것이 중요하다고 생각한다.
정리하면, 내가 생각하는 좋은 LLM 연구는 대체로 다음과 같다.
LLM이 담당하는 역할과 선택 이유가 드러나고, 성능 향상에서 각 구성요소의 기여를 살펴볼 수 있으며, 오류가 발생하는 조건과 그 영향을 함께 설명해주는 연구.
이 기준은 주관적이다.
그런데 왜 LLM을 잘 써야 하는가?
그리하여 나는 두 가지 의견을 갖게 되었다.
첫째, 보안 연구에서는 실제 시스템에서 작동하는 것이 중요하다.
둘째, LLM을 선택한 이유와 신뢰할 수 있는 범위를 함께 살펴보면 그 성과를 해석하기가 수월해진다.
그러다 내가 LLM을 평가할 때 다른 도구보다 더 까다로운 기준을 적용하고 있는 것은 아닌지 의심하게 되었다.
이것은 이중잣대 아닌가?
보안 논문에서 도구의 선택을 평가할 때, 우리는 보통 그 도구가 문제에 얼마나 잘 맞는지를 살핀다. 탐색 전략이나 분석 기법, 솔버를 선택한 이유를 묻더라도, 그것이 유일하게 가능한 해법임을 철학적으로 증명하라는 요구와는 거리가 있다.
그런데 LLM을 사용한 논문에는 유독 “LLM이 반드시 필요한가?”라는 질문을 던지고 있는 것은 아닐까?
작동하는 시스템을 만들었다는 사실로 충분하지 않은가?
새로운 취약점을 더 많이 찾았고, 기존 방법보다 성능이 좋으며, 실제 문제를 해결했다면 그것으로 기여가 성립하는 것 아닌가?
쉽게 넘기기 어려운 반론이다.
내가 현재 내린 잠정적인 답은 이렇다.
LLM에도 다른 도구와 같은 평가 원칙을 적용하는 편이 타당해 보인다. 다만 실험에서 고정하고 통제하기 어려운 요소가 있다면, 그 선택의 이유와 결과의 의미에 관해 추가적인 설명이 필요할 수 있다.
LLM이 특별히 신비하거나 사악하다고 생각해서는 아니다.
LLM을 포함한 시스템의 결과에는 학습 데이터의 영향, 입력된 문맥, 생성된 코드와 외부 도구의 동작 등 여러 요인이 관여할 수 있다. 따라서 관찰된 성공을 하나의 기제로 설명하기가 쉽지 않을 때가 있다.
특히 모델 버전을 고정하거나 변경 이력을 확인하기 어려운 상용 API를 사용한다면, 실험에서 ‘모델’이라는 변수를 어느 정도 통제했는지 살펴볼 필요가 있다.
모델에 관한 정보가 충분히 공개되지 않은 경우에는 같은 이름 아래 내부 버전이나 정책이 바뀌었는지, 평가 대상이 학습 데이터에 포함되었는지 확인하기 어려울 수 있다. 같은 입력에서 결과가 얼마나 안정적으로 나오는지도 별도로 살펴볼 문제다.
이런 재현성의 불확실성은 결과를 다시 얻는 수고뿐 아니라, 우리가 무엇을 실험했는지 설명하는 데에도 영향을 줄 수 있다.
이러한 조건에서는 성능 숫자의 해석에도 여지가 남는다. 개선이 모델의 의미 추론에서 왔는지, 검색 모듈과 외부 도구에서 왔는지, 평가 데이터의 표면적 특징을 잘 포착한 덕분인지 최종 수치만으로 구분하기는 어렵다.
내가 추가적인 설명을 기대하는 이유는 이런 불확실성이 연구의 결론에 얼마나 영향을 주는지 알고 싶기 때문이다.
물론 다른 도구에도 비슷한 질문을 던질 수 있다. 휴리스틱의 실패 조건, 정적 분석의 건전성과 정밀도의 경계, 퍼징 연구에서 벤치마크와 시드의 영향 등을 함께 설명해주면 결과를 평가하는 데 도움이 된다.
LLM에서도 도구의 이름 자체보다 실험에서 통제할 수 있었던 범위와 결과에 남아 있는 불확실성에 따라 설명의 수준을 정하는 편이 합리적일 것이다.
이렇게 보면 처음 만났던 그 박사님의 주장과 나의 주장은 완전히 반대되는 것이 아니었을지도 모른다.
신규 취약점 발견과 LLM을 통한 성능 향상은 모두 가치 있는 성과다. 다만 발견 개수로 기법의 일반적인 우수성을 판단하거나, 숫자가 올랐다는 이유로 LLM이 문제의 본질을 해결했다고 단정하기에는 추가적인 근거가 필요할 수 있다. 관찰한 성과와 그 성과에 대한 해석의 범위를 나누어 말하면, 독자도 어디까지 받아들일지 판단하기가 쉬워진다.
도구의 성공은 결과를 만든다. 그 결과가 나온 조건과 일반화할 수 있는 범위, 실패 조건을 함께 설명하면 연구의 기여를 더 분명하게 평가할 수 있다.
결론: 철학, AI, 사이버 보안을 아우르는 멋지고 명쾌한 해답
철학에서는 오래전부터 관찰 결과가 어떤 설명을 얼마나 정당화할 수 있는지를 두고 싸워왔다.
하나의 관찰 결과가 서로 다른 여러 설명과 양립한다면, 관찰에 성공했다는 사실만으로 특정 설명을 확정하기는 어렵다.
동굴 벽에 비친 그림자가 정확도 93.7%를 기록했다고 해서, 동굴 밖의 사물을 완전히 이해했다고 말할 수는 없다.
보안 연구에는 이런 판단을 어렵게 만드는 사정들도 있다. 공격자와 방어자가 서로의 방법을 보고 대응을 바꿀 수 있고, 시스템과 모델도 계속 변한다. 성공하지 못한 공격과 발견하지 못한 취약점은 관찰하기 어려운 경우도 있다.
LLM은 이런 환경에서 꽤 강력하고 편리한 도구가 될 수 있다.
LLM을 망치로 사용하는 방식도 충분히 유용할 수 있다. 다만 무언가가 부서졌다는 결과에서 못을 정확히 박았다는 결론으로 넘어가려면, 그 사이의 설명을 조금 더 듣고 싶다.
요컨대 다음과 같다.
공학적 연구에서 도구가 작동했다는 사실은 그 자체로 가치가 있다.
그 도구를 언제, 왜, 어디까지 믿을 수 있는지 설명하면 그 성과를 더 잘 평가하고 활용할 수 있다.
물론 나는 철학, AI, 사이버 보안을 아우르는 이보다 훨씬 더 멋지고 명쾌한 해답을 발견했다. 그러나 이 블로그의 여백은 그것을 적기에 너무 좁다.