요즘 거의 모든 보안 팀의 Slack 채널에서 일어나는 순간이 있습니다.

누군가 스크린샷을 붙여넣습니다. LLM(대규모 언어 모델)이 팀이 온보딩하는 데 한 스프린트 전체를 소요했던 코드베이스에서 단 30초 만에 SQL 인젝션 (SQL injection)을 찾아냈습니다. 누군가는 🔥 이모지로 반응합니다. 다른 누군가는 반쯤 농담조로 말합니다. "우리 모두 일자리를 잃겠네요."

그러고 나서 며칠 후, 같은 팀은 세 개의 마이크로서비스 (microservices)에 걸쳐 레이스 컨디션 (race condition)을 수동으로 추적하는 데 6시간을 보냅니다. 이는 스캐너에 절대 나타나지 않고, 어떤 모델도 지적하지 못하며, 위협 모델링 (threat-modeling) 세션 중에 누군가가 "이 두 요청이 동일한 밀리초에 도착하면 어떻게 되나요?"라는 이상한 질문을 던졌기 때문에 겨우 발견된 그런 종류의 버그입니다.

이 두 순간은 모두 사실입니다. 두 가지 모두 현재 보안 팀에서 일어나고 있는 일입니다. 그리고 "AI vs 인간"에 관한 대부분의 논쟁은 두 번째 상황을 완전히 무시하고 있습니다.

모두가 잘못하고 있는 논쟁

어떤 보안 포럼을 훑어보더라도 서로를 향해 소리치는 두 진영을 발견할 수 있을 것입니다.

제1진영: AI는 몇 년 안에 취약점 연구원 (vulnerability researchers)을 대체할 것이다. 코드를 읽는 속도를 봐라. 이미 얼마나 많은 것을 알고 있는지 봐라.

제2진영: AI는 눈속임일 뿐이다. 발견한 내용의 절반은 환각 (hallucinate)이며, 종이봉투에서 빠져나올 정도의 추론 능력도 없다.

두 진영 모두 실제로 일어나고 있는 일을 제대로 보고 있지 않습니다. 정직한 답변은 어느 헤드라인보다도 지루합니다: AI는 놀라운 패턴 매칭 (pattern-matcher) 도구가 되었지만, 취약점 연구는 외부에서 보기에는 그렇게 보였을지언정 결코 단순한 패턴 매칭만은 아니었습니다.

그 차이가 이야기의 핵심입니다.

기계가 진정으로 승리하는 지점

인정할 것은 인정합시다. 왜냐하면 많은 보안 전문가들이 현실과 맞지 않는 방식으로 반사적으로 무시하는 경향이 있기 때문입니다.

규모에 따른 속도는 결코 작은 문제가 아닙니다. 한 번도 본 적 없는 40만 줄 규모의 코드베이스를 검토하라고 사람에게 요청한다면, 그들이 방향을 잡는 데만 며칠, 어쩌면 몇 주가 걸릴 수도 있습니다. 하지만 동일한 코드베이스를 요약하고, 인증 흐름 (auth flow)을 매핑하며, 가장 위험한 파일 5개를 지목하라고 LLM (대규모 언어 모델)에게 요청하면, 커피가 식기도 전에 답을 얻을 수 있습니다. 이것은 눈속임이 아닙니다. 수 시간의 오리엔테이션 작업이 단 몇 분으로 압축된 것입니다.

반복은 인간이 조용히 실패하는 지점이며, 아무도 이를 인정하고 싶어 하지 않습니다. 만약 보안에 취약한 동일한 JWT 검증 (JWT-verification) 코드 조각이 3년에 걸쳐 80명의 서로 다른 엔지니어에 의해 80개의 마이크로서비스 (microservices)로 복사되어 붙여넣기 되었다면, 지친 인간 검토자는 그중 몇 개만 찾아내고 나머지는 놓치게 될 것입니다. 이는 그들이 일을 못 해서가 아니라, 인간은 12번째 반복쯤 되면 집중력을 잃기 때문입니다. 모델은 지루해하지 않습니다. 모델은 실행할 때마다 일관되게 80개 모두를 찾아낼 것입니다.

AI는 낯선 영역을 위한 번역기 역할을 합니다. 모든 연구자는 결국 Elixir, Rust, 혹은 제대로 문서화되지 않은 사내 프레임워크와 같이 자신이 모르는 스택 (stack)을 마주하게 됩니다. 문서를 읽느라 반나절을 허비하는 대신, 라우팅 레이어 (routing layer)가 인증에 대해 무엇을 가정하고 있는지 질문하여 즉시 사용 가능한 답변을 얻을 수 있습니다. 이 기능 하나만으로도 사람들이 새로운 타겟에 빠르게 적응하는 방식이 조용히 재편되었습니다.

만약 취약점이 이미 수천 번이나 다뤄진 내용처럼 보인다면 — 그리고 실제 발생하는 버그의 엄청난 비중이 그러하다면 — 오늘날의 모델들은 이를 포착하는 데 진정으로 뛰어난 능력을 보여줍니다.

한계점 (Where It Falls Apart)

여기서부터는 멋진 스크린샷으로 남기기 어려운 부분입니다. 왜냐하면 이것은 단 한 번의 극적인 실패가 아니라, 조용하고 구조적인 격차이기 때문입니다.

은행 앱을 예로 들어봅시다. 모든 엔드포인트 (endpoint)는 적절하게 인증을 수행합니다. 권한 부여 (Authorization) 체크는 빈틈이 없습니다. 입력값 검증 (Input validation)도 깔끔합니다. 정적 분석기 (static analyzer)를 전체 코드에 실행해도 아무런 결과가 나오지 않습니다.

그럼에도 불구하고 — 사용자가 거의 동시에 별도의 엔드포인트를 통해 이체를 실행하고 취소하면, 레이스 컨디션 (race condition)이 발생하여 계좌에 금액이 두 번 입금될 수 있습니다.

그 중 어느 것도 코딩 실수(coding mistake)가 아닙니다. 코드는 작성된 대로 정확하게 작동하고 있습니다. 잘못된 것은 '프로세스(process)'입니다. 이를 인식하려면 함수가 어떻게 실행되어야 하는지가 아니라, 시스템을 통해 돈이 어떻게 움직여야 하는지에 대한 이해가 필요합니다. 그것은 학습 데이터셋(training set)에 있는 패턴이 아닙니다. 그것은 의도(intent)에 대한 판단입니다.

실제 세상의 보안 침해(compromise)는 단 하나의 깔끔한 취약점(vulnerability)에서 발생하는 경우가 드뭅니다. 그것은 체인(chains)을 통해 발생합니다. 즉, 낮은 심각도의 저장형 XSS(stored XSS)가 세션 탈취(session theft)로 이어지고, 이것이 아무도 제대로 잠그지 않았던 대시보드로 이어지며, 결국 아무도 계획하지 않았던 권한 상승(privilege escalation)으로 이어지는 식입니다. 개별적으로 보면 각 단계는 '낮음(low)' 또는 '정보성(informational)'으로 평가될 수 있습니다. 하지만 이들이 하나로 엮이면 전체 계정 탈취(account takeover)가 됩니다. 이러한 체인을 파악하려면 전체 공격 경로(attack path)를 한 번에 머릿속에 담아두고, 매 단계마다 "그다음엔 어떻게 되지?"라고 물어야 합니다. 그리고 이는 인간이 명시적으로 가이드하지 않는 한, 모델들이 여전히 일관성 없게 수행하는 영역입니다.

그리고 설명하기조차 가장 어려운 범주가 있습니다. 바로 '알려지지 않은 미지의 영역(unknown unknowns)'입니다. HTTP 요청 스머글링(HTTP request smuggling), 프로토타입 오염(Prototype pollution), 의존성 혼란(Dependency confusion), 그리고 프롬프트 인젝션(Prompt injection) 그 자체 같은 것들 말입니다. 이러한 공격 클래스들은 호기심 많은 인간이 아직 아무도 문서화하지 않은 이상한 상호작용을 발견하고 그것을 파고들기로 결정하기 전까지는, 그 어떤 학습 데이터셋에도 단 0초 동안조차 존재하지 않았습니다. 어제의 지식으로 학습된 모델은 구조적으로 내일의 카테고리를 발명할 수 없습니다. 모델은 누군가 먼저 이름을 붙인 '이후'에 그것을 인식하는 속도만 빨라질 뿐입니다.

호기심에 관한 불편한 진실

훌륭한 연구자들과 충분한 시간을 보내다 보면, 그들이 모두 약간 짜증스러울 수도 있는 성격적 특성을 공유한다는 것을 알게 됩니다. 바로 "아마 괜찮을 거야"라는 말을 그냥 지나치지 못한다는 점입니다.

이 두 요청이 순서가 바뀌어 도착하면 어떻게 될까? 사용자가 세션 도중에 계정을 삭제하면 어떻게 될까? 하위 시스템이 여전히 이전 세션 토큰을 신뢰할까? 만약 지원팀 직원이 모두가 보편적이라고 가정하는 검사 과정을 조용히 우회하는 디버그 패널(debug panel)을 가지고 있다면 어떻게 될까?

이러한 질문들은 코드를 읽는 것에서 나오는 것이 아닙니다. 그것은 실제 압박 속에서 실제 편법을 쓰는 실제 사람들이 시스템을 실제로 어떻게 사용하고, 오용하고, 남용할지를 상상하는 데서 나옵니다. 그것은 프롬프트 템플릿 (prompt template)으로 추출할 수 있는 기술적 기술이 아닙니다. 그것은 차라리 직업적 편집증 (professional paranoia)에 가까우며, 조직이 어떻게 운영되어야 하는지에 대해 읽는 것이 아니라, 실제로 무언가를 망가뜨려 보고 조직이 실제로 어떻게 운영되는지를 지켜봄으로써 얻어지는 것입니다.

그렇다면 현재 '좋은 상태'란 실제로 어떤 모습일까?

이 시점에서 가장 많은 것을 얻어내고 있는 연구자들은 AI를 대체재나 장난감 중 하나로 취급하는 사람들이 아닙니다. 그들은 양측의 강점을 모두 활용하는 분업 (division of labor) 방식을 찾아낸 사람들입니다.

예를 들면 다음과 같습니다: 모델이 코드베이스 (codebase)를 훑으며 당신에게 오리엔테이션 지도 (orientation map)를 건네게 하세요. 모델이 명백한 패턴 매칭 (pattern-matches)을 표시하게 하여 당신이 지루한 작업에 시간을 낭비하지 않게 하세요. 그다음, 공격자처럼 생각하는 과정이 실제로 필요한 부분—체인을 구축하고, 가정을 의심하며, 모델이 묻도록 프롬프트 되지 않았던 짜증 나는 "만약 ~라면?" 같은 질문을 던지는 단계—에는 직접 개입하세요.

이것은 인간을 위한 위로용 보상이 아닙니다. 이것은 진정으로 더 효율적인 워크플로 (workflow)입니다. 대안, 즉 모델의 출력을 비판 없이 신뢰하는 것은 충분히 논의되지 않는 그 나름의 실패 모드 (failure mode)를 가지고 있습니다: 바로 거짓된 확신 (false confidence)입니다. "발견된 문제 없음"이라고 보고하는 스캐너나 모델이 문제가 존재하지 않는다는 것을 의미하지는 않습니다. 그것은 모델이 인식한 패턴에 일치하는 것이 없다는 것을 의미할 뿐입니다. 침묵을 건강 상태가 양호하다는 증거로 취급하는 것이 바로 비즈니스 로직 (business-logic) 버그가 프로덕션 (production) 환경으로 곧장 미끄러져 들어가는 방식입니다.

아무도 좋아하지 않지만, 옳은 비교

사람들은 계속해서 계산기 비유를 들고 나오는데, 이는 다소 식상할 수 있지만 식상한 이유는 그 비유가 정확하기 때문입니다. 계산기가 수학자들의 일자리를 뺏지는 않았습니다. 계산기는 수동 산술 (manual arithmetic)을 없앴고, 사람들이 더 어려운 문제들을 생각할 수 있도록 자유를 주었습니다. 자동 완성 (Autocomplete) 기능이 개발자를 대체하지도 않았습니다. 그것은 지루한 키 입력 과정을 없앴을 뿐이며, 아키텍처 결정 (architecture decisions)은 언제나 그랬듯 사람의 영역으로 남겨두었습니다.

취약점 연구 (Vulnerability research) 또한 동일한 변화를 겪고 있습니다. 다만 보안 버그는 자동 완성 가능한 코드와 달리 지름길을 거부하는 고집스러운 특성이 있어, 다른 분야들보다 그 변화가 조금 늦게 나타나고 있을 뿐입니다. 업무의 반복적인 80% — 즉, 상황 파악, 패턴 매칭 (pattern-matching), "이와 똑같은 실수를 전에 본 적이 있는가"와 같은 작업들 — 은 빠르게 자동화되고 있습니다. 침해 사고의 발생 여부를 실제로 결정짓는 나머지 20% — 비즈니스 로직 (business logic), 연쇄적 추론 (chained reasoning), 아직 아무도 명명하지 않은 새로운 공격 클래스 (attack class) — 는 완고하게도, 현재까지도 여전히 인간의 영역입니다.

공격자들은 코드를 직접 깨뜨린 적이 없습니다. 그들은 가정을 깨뜨립니다. 현재로서는 어떤 가정이 의문을 제기할 가치가 있는지를 이해하는 것은 여전히 오직 사람만이 할 수 있는 일입니다.

이 상황이 영원히 지속되지는 않을 것입니다. 하지만 오늘날에는 그것이 사실이며, 어느 쪽으로든 그렇지 않은 척하는 것은 아무 이유 없이 공황에 빠지거나, 혹은 매우 나쁜 이유로 안주하게 만드는 결과를 초래할 뿐입니다.