아무도 말하지 않는 AI 생성 코드의 보안 허점

당신의 AI 어시스턴트가 방금 400줄의 인증 미들웨어 (authentication middleware)를 작성했습니다. 코드는 깔끔해 보입니다. 린트 (lint) 검사도 통과했습니다. 당신의 PR 리뷰어는 8분 만에 이를 승인했습니다. 누가 미들웨어를 제대로 읽어보겠습니까?

여기 아무도 말해주지 않은 사실이 있습니다. 그 코드에는 토큰 갱신 주기 (token refresh cycle)에 논리적 결함 (logic flaw)이 있어, 공격자가 단 하나의 유효한 리프레시 토큰 (refresh token)이라도 얻게 된다면 세션을 무기한으로 유지할 수 있습니다. 제가 이 사실을 아는 이유는, 일본의 한 보안 연구원이 올린 Qiita 포스트를 보고 AI 생성 코드 보안에 대해 제가 알고 있던 모든 것에 의구심이 생겼고, 이후 운영 환경 (production)에서 정확히 이 버그를 찾아내느라 3주를 보냈기 때문입니다.

그 포스트는 (일본어로 작성되어 영어 커버리지가 전혀 없었으며, 제가 발견했을 당시 주식은 0이었습니다) 서구권의 어떤 보안 가이드에서도 본 적 없는 AI 생성 코드 리뷰에 대한 체계적인 접근 방식을 제시했습니다. 그것은 도구나 스캐너에 관한 것이 아니었습니다. AI가 실제로 무엇을 틀리는지 — 구문 (syntax)이나 스타일 (style)이 아닌, 논리 (logic)를 이해하는 것에 관한 것이었습니다.

AI 코드가 망가지는 세 가지 지점

일본의 보안 연구 (그리고 저는 제가 아는 몇몇 일본 보안 컨설턴트들과 이 내용을 교차 검증하는 데 시간을 보냈습니다)는 세 가지 실패 모드 (failure modes)에 집중하는 AI 코드 리뷰를 위한 특정 프레임워크를 가지고 있습니다.

1. 상태 머신 맹목성 (State Machine Blindness)
AI는 올바르게 보이지만 프롬프트 (prompt)에 포함되지 않은 상태 전이 (state transitions)를 고려하지 않는 코드를 생성합니다. 인증 미들웨어 (authentication middleware)가 가장 흔한 희생자입니다. 모델은 해피 패스 (happy path) — 사용자 인증됨, 토큰 유효함, 진행 — 를 가정하며, 토큰이 만료되거나, 취소되거나, 부분적으로 유효할 때 발생하는 상황은 무시합니다.

특정한 취약점 패턴: 새로운 토큰과 함께 기존 토큰을 원자적 (atomically)으로 무효화하지 않는 AI 생성 토큰 갱신 로직입니다. 두 토큰이 모두 작동하는 시간적 창 (window)이 발생하며, 만약 공격자가 (로그 인젝션 (log injection), 메모리 덤프 (memory dump), 또는 단순한 타이밍 공격 (timing attack)을 통해) 기존 토큰을 얻게 된다면, 그들은 영구적인 접근 권한을 갖게 됩니다.

2. 권한 경계 혼동 (Permission Boundary Confusion)
AI는 "이 사용자가 지금 이 리소스에 접근할 수 있는가"와 "이 함수가 해당 역할(role)에 의해 호출될 수 있어야 하는가" 사이의 차이를 이해하지 못합니다. AI는 개별적으로는 올바르게 보이는 RBAC (역할 기반 액세스 제어) 코드를 생성하지만, 여러 서비스에 걸쳐 권한 흐름을 실제로 추적할 때는 이를 깨뜨립니다.

작년에 저는 코드베이스에서 이를 발견했습니다. AI가 작성한 2,000줄의 권한 확인 코드였는데, 테스트 역시 AI가 생성했고 정상적인 경로(happy path)만을 다루었기 때문에 아무도 테스트하지 않은 14가지의 역할 조합이 존재했습니다.

3. 인젝션 표면 확장 (Injection Surface Expansion)
이것은 새롭고 일본에 특화된 내용입니다. AI가 생성한 코드는 인간이 작성할 때보다 더 많은 입력 처리 계층을 추가하는 경향이 있으며, 각 계층은 잠재적인 인젝션 지점 (injection point)이 됩니다. 일본 보안 연구원들은 이를 "신뢰 경계 확산 (trust boundary diffusion)"이라고 부릅니다. AI 도우미를 더 많이 추가할수록 공격자가 악성 페이로드 (malicious payload)를 주입할 수 있는 지점이 더 많아집니다.

踏み込み検査 (Fumi-komi Kensa): "침투 깊이 검사 (penetration depth inspection)"를 뜻하는 일본어 용어입니다. 이는 단순히 명백한 엔드포인트(endpoint)뿐만 아니라, 모든 AI 생성 계층을 통해 데이터가 어떻게 흐르는지 추적하는 관행을 의미합니다. 서구의 보안 문화가 진입점 (entry points)에 집중한다면, 일본의 개발 문화는 이를 중간 변환 과정까지 확장합니다.

아무도 가르쳐주지 않은 리뷰 체크리스트

Qiita 포스트는 제가 서구권 팀에 맞춰 수정한 특정 리뷰 프로토콜을 설명했습니다. 모든 AI 생성 코드 변경 사항에 대해 다음 순서대로 확인해야 합니다.

1단계: 인증 상태 머신 (authentication state machine)을 추적하십시오. 코드를 리뷰하기 전에 종이에 상태 전이 (state transitions)를 그려보세요. 그런 다음 코드가 오류 및 취소 경로 (revocation paths)를 포함한 모든 전이를 구현하는지 확인하십시오. 프롬프트에서 실패 시 발생하는 상황을 명시하는 경우가 거의 없기 때문에 AI는 이 작업에 매우 취약합니다.

2단계: 모든 권한 확인(permission check)에 상응하는 경계 테스트(boundary test)가 있는지 확인하십시오. 유닛 테스트(unit test)가 아니라, 경계 테스트(boundary test)입니다. 이 함수가 role=X 및 resource=Y인 상태로 호출될 수 있습니까? role=X 권한이 세션 중간에 취소되었을 때 호출될 수 있습니까? AI가 생성한 권한 코드는 유닛 테스트를 통과하곤 하는데, 이는 아마도 테스트 자체가 코드와 함께 생성되었기 때문일 것입니다.

3단계: 인젝션 표면(injection surfaces)의 수를 세십시오. 모든 변환(transformation), 직렬화(serialization), 또는 파싱(parsing) 계층은 잠재적인 인젝션 지점입니다. 만약 AI가 생성한 코드에 입력과 저장소 사이에 3개 이상의 계층이 있다면, 보안 검토(security review)가 필요합니다.

4단계: 신뢰 경계(trust boundary)의 일관성을 확인하십시오. 이것이 대부분의 AI 코드가 실패하는 지점입니다. AI는 누가 누구를 신뢰하는지 명시적으로 정의하지 않은 채 새로운 신뢰 경계(서비스 간 데이터 흐름, 함수 호출, 이벤트 처리)를 생성합니다. 배포하기 전에 신뢰 모델(trust model)을 문서화하십시오.

만들어진 용어: 권한 부채 (Authorization Debt)

제가 계속 목격하고 있는 상황은 이렇습니다. 팀들은 AI가 생성한 권한 로직(authorization logic)을 배포하고 개발 속도(velocity)에 만족하지만, 첫 번째 실제 보안 사고가 발생하여 그 간극이 드러날 때 몇 달 동안 기술 부채(technical debt)를 갚는 데 시간을 보냅니다.

권한 부채 (Authorization Debt) — 테스트는 통과하지만 운영 환경(production)에서는 실패하는 불완전한 권한 로직을 배포함으로써 발생하는 복리 형태의 비용입니다. 이것은 버그가 아닙니다. 아무도 명시할 생각을 하지 못했던 요구사항의 누락된 차원입니다.

AI가 권한 코드를 작성함으로써 절약한 매 1시간마다, 향후 18개월 동안 보안 강화(security hardening)를 위해 약 4시간을 되갚아야 할 것입니다. 이것은 단순한 부채가 아니라, 변동 금리가 적용되는 담보 대출(mortgage)과 같습니다.

일본 개발 문화가 올바르게 하고 있는 것

서구의 보안 문화는 도구 중심적입니다. SAST를 실행하고, DAST를 실행하며, 이 린터(linter)를 사용하고, 이 정책을 추가하라고 합니다. 제가 일본 보안 커뮤니티에서 관찰한 바에 따르면, 일본의 개발 문화는 더 인간 중심적입니다. 코드가 무엇을 해야 하는지 이해하고, 위협 모델(threat model)을 이해한 다음, 그 이해를 바탕으로 검토합니다.

이러한 차이는 그들의 리뷰 패턴에서 나타납니다:

서구적 접근 방식	일본의 영향을 받은 접근 방식
자동 스캐너를 실행하고, 발견된 것을 수정함	위협 모델(threat model)을 먼저 이해한 다음, 스캔함
...
이것은 도구의 문제가 아닙니다. 리뷰에 임하는 여러분의 멘탈 모델(mental model)에 관한 문제입니다.

회의적인 시각

여기서 제 경험은 Qiita 저자의 프레임워크를 복잡하게 만듭니다. 즉, 체계적인 리뷰 접근 방식은 그것을 수행할 수 있는 사람이 있을 때만 작동한다는 점입니다. 그리고 그런 사람을 찾는 일은 점점 더 어려워지고 있습니다.

저는 팀들이 AI 코드 리뷰 프로세스를 도입하고, 시니어들에게 체크리스트를 교육한 다음, 퇴사로 인해 그 시니어들을 잃는 과정을 지켜봐 왔습니다. 조직의 지식(institutional knowledge)은 전수되지 않습니다. 체크리스트는 전수되지만, 그 체크리스트가 왜 존재하는지에 대한 이해 없이 팀은 이를 단순히 체크박스를 채우는 요식 행위로 취급하기 시작합니다.

권한 부여 부채(Authorization Debt)는 실재하지만, 리뷰 체크리스트 부채(Review Checklist Debt) 또한 실재합니다. 관행이 기계적으로 변할 때, 그것은 보호 가치를 상실합니다. 보안 리뷰가 "실제로 무슨 일이 일어나고 있는지 이해하는 것"이 아니라 "체크리스트를 실행하는 것"이 되는 순간, 여러분은 이미 패배한 것입니다.

퇴화 방지 체크리스트 (The Anti-Atrophy Checklist)

주간 위협 모델 리뷰 — AI가 생성한 서비스 중 하나를 선택하여 데이터 흐름(data flow)을 수동으로 추적하세요. 이를 기록하세요. 코드를 보지 않고 상태 머신(state machine)을 그릴 수 없다면, 그것이 바로 여러분의 공백입니다.
월간 권한 경계 감사 (permission boundary audit) — 자동화가 아닌 수동으로 진행하세요. 공격자가 하는 것처럼 인증(auth) 코드를 읽으세요. 우회할 수 있는 방법 3가지를 찾을 수 없다면, 충분히 면밀하게 읽지 않은 것입니다.
분기별 인젝션 표면(injection surface) 수 산정 — AI 의존도가 가장 높은 서비스의 변환 계층(transformation layers) 수를 세어보세요. 지난 분기보다 늘어났다면, 그 이유를 물으세요.
원래 프롬프트(prompt)에 참여하지 않았던 사람의 인간 리뷰 없이 인증 코드를 배포하지 말 것 — 리뷰어는 AI가 심어놓은 것을 잡아내기 위해 AI로부터 거리를 두어야 합니다.

도구는 변합니다. 하지만 실패 모드(failure modes)는 변하지 않습니다.

여러분의 생각은 어떠신가요?

저는 이 리뷰 프레임워크를 6개월 동안 사용해 왔으며, 계속해서 나타나는 패턴은 AI 생성 코드(AI-generated code)가 가장 자신만만할 때, 즉 완벽하고 정확해 보일 때 가장 위험하다는 것입니다. 바로 그때 가장 철저한 검토(scrutiny)가 필요합니다. 여러분의 경험은 어떠셨나요? 아래에 댓글을 남겨주세요. 모든 댓글에 답변해 드립니다.

여러분의 팀은 AI 생성 보안 코드(security code)를 위한 특정 리뷰 관행을 개발했나요? 계속해서 놓치고 있는 패턴은 무엇인가요?

Qiita (일본 최대 개발자 커뮤니티) — "AI 생성 코드의 보안 리뷰에서 확인해야 할 포인트" miruky 작성

토론: 여러분의 리뷰 프로세스에서 계속해서 빠져나가는 AI 생성 코드 패턴은 무엇인가요? 그리고 이를 잡아내기 위해 팀에서 개발한 특정 관행이 있나요?