14명 중 0명, AI 코딩 첫 프롬프트의 보안 공백

AI 요약

• 무슨 일: SOUPS 2026 채택 논문이 AI 코딩 어시스턴트 사용 중 보안 요구사항이 첫 프롬프트에서 빠지는 현상을 관찰했습니다.
  • 연구진은 전문 소프트웨어 엔지니어 15명을 인터뷰하고, 14개 코딩 세션을 Gemini CLI와 Gemini 2.5 Pro로 관찰했습니다.
• 숫자: 첫 프롬프트에 보안 요구사항을 넣은 참가자는 0명이었고, 숨은 보안 문제를 스스로 잡은 참가자는 2명이었습니다.
• 개발자 영향: AI 코딩 보안은 모델 성능보다 프롬프트 템플릿, 리뷰 체크리스트, 보안 경고 UI 문제로 이동합니다.
  • 논문은 자동 보안 리뷰 pass, 민감 코드 생성 전 요구사항 확인, OWASP class inline warning을 설계 제안으로 냈습니다.

2026년 5월 22일 arXiv에 올라온 논문은 From Preventive to Reactive입니다. 이 논문은 AI 코딩 어시스턴트 보안을 취약점 비율만으로 보지 않습니다. 연구진은 전문 소프트웨어 엔지니어 15명을 인터뷰하고, 그중 14명이 Gemini CLI와 Gemini 2.5 Pro로 보안 관련 코딩 과제를 수행하는 장면을 관찰했습니다. 결론은 날카롭습니다. 개발자가 보안 지식을 잃은 것이 아니라, 그 지식이 첫 요구사항이 아니라 생성 후 리뷰 단계로 밀립니다.

논문은 SOUPS 2026 채택 논문입니다. SOUPS는 usable privacy and security 분야에서 사람의 행동, 도구 인터페이스, 조직 관행을 함께 다루는 학회입니다. 이번 연구의 뉴스 가치는 새 모델 점수나 새 IDE 기능이 아니라, AI 코딩 도구가 개발자의 보안 행동을 어디로 밀어내는지 실제 세션으로 봤다는 데 있습니다. 최근 코딩 에이전트 시장은 Claude Code, Codex, Copilot, Cursor, Gemini CLI처럼 파일 수정과 명령 실행까지 맡기는 방향으로 가고 있습니다. 이 환경에서 "개발자가 나중에 리뷰하면 된다"는 가정은 점점 비싸집니다.

연구 설계는 단순한 설문이 아닙니다. 연구진은 2025년 11월부터 2026년 1월까지 전문 소프트웨어 개발자 15명을 모집했습니다. 참가자는 full-stack, machine learning, frontend, R&D, general software engineering 역할을 포함했고, 학생이나 대학 직원은 제외했습니다. 각 세션은 45-60분으로 진행됐습니다. 먼저 보안 실무와 AI 코딩 도구 사용 경험을 묻는 반구조화 인터뷰를 하고, 이어 self-hosted VS Code server에서 Think-Aloud 코딩 과제를 수행했습니다.

코딩 과제는 세 가지였습니다. 첫째는 JSON payload를 받는 /update-profile HTTP endpoint 구현입니다. 이 과제는 input validation, authorization, sanitization이 자연스럽게 나오는지 보려는 장치입니다. 둘째는 새 backend project 초기화입니다. 이 과제는 secret management, secure defaults, 환경 분리를 보는 쪽입니다. 셋째는 file upload 함수의 race condition을 고치는 debugging 과제입니다. 연구진은 과제 설명에 보안 요구사항을 노골적으로 넣지 않았습니다. 참가자가 AI를 쓸 때 보안을 스스로 요구사항으로 가져오는지 보기 위해서입니다.

가장 큰 숫자는 0입니다. 논문은 코딩 세션 참가자 14명 중 첫 프롬프트에 보안 요구사항을 포함한 사람이 없었다고 적습니다. 일부 참가자는 직전 인터뷰에서 authorization, 민감정보, 취약점 유형을 말할 수 있었습니다. 그러나 실제 Gemini CLI 세션에서 첫 요청은 기능 구현, 프로젝트 구성, 디버깅 같은 기능 목표에 집중했습니다. 논문이 말하는 prompting gap은 이 지점입니다. 보안 지식과 보안 프롬프팅 행동이 분리됩니다.

두 번째 숫자는 2입니다. 14개 코딩 세션에서 숨은 보안 문제를 별도 프롬프트 없이 잡은 참가자는 2명이었습니다. P10은 AI가 생성한 profile update endpoint에서 현재 사용자 ID를 secure session store가 아니라 POST body에서 읽는 문제를 발견했습니다. 공격자는 요청 body를 바꿔 다른 계정의 profile을 수정할 수 있습니다. P12는 다른 방식으로 성공했습니다. 초기 수정을 끝낸 뒤 AI에게 추가 보안 우려가 남아 있는지 물었고, 그 과정에서 본인이 떠올리지 못한 DDoS 관련 위험을 표면화했습니다.

이 결과는 "초보 개발자가 AI를 믿어서 위험하다"는 단순한 설명과 다릅니다. 연구진은 참가자를 Pre-AI, AI-era, AI-native 세 cohort로 나눴지만, 경험 cohort가 보안 성과를 안정적으로 예측하지 못했다고 봤습니다. P10은 비교적 경험이 적은 AI-era 참가자였고, P12는 Pre-AI 참가자였습니다. 반대로 더 오래 개발한 참가자도 중요한 문제를 놓쳤습니다. 논문은 연차보다 보안 지식이 필요한 순간에 실제 질문으로 전환되는 습관이 더 중요했다고 해석합니다.

이 대목은 최근 기업용 AI 코딩 도구 도입 논의와 바로 연결됩니다. 팀은 보통 어떤 모델이 더 좋은지, 어떤 IDE가 편한지, 어떤 가격표가 낮은지부터 비교합니다. 그러나 이 논문이 보여주는 실패 지점은 모델 선택 이전입니다. 개발자가 "profile update endpoint를 만들어줘"라고 요청했을 때 도구는 authorization boundary를 먼저 물어야 합니다. 민감 입력을 감지해 보안 요구사항 확인을 요구하거나, 생성 후 "이 코드는 session-bound user identity를 가정합니다" 같은 경고를 붙이는지도 직접적인 차이를 만듭니다.

논문은 기존 연구도 함께 짚습니다. Pearce 등은 과거 GitHub Copilot이 high-risk vulnerability scenario에서 생성한 코드 중 약 40%가 exploitable했다고 보고했습니다. Perry 등은 AI assistant를 쓴 개발자가 더 덜 안전한 코드를 만들면서도 자신의 코드가 안전하다고 더 믿는 경향을 보였다고 밝혔습니다. 이번 논문은 그 결과가 왜 생기는지 행동 단위로 설명합니다. AI가 기능적으로 그럴듯한 코드를 빠르게 내놓으면, 개발자는 보안 요구를 처음부터 넣기보다 나중에 잡을 수 있다고 가정합니다.

참가자 발언도 같은 방향을 보입니다. 한 참가자는 AI output이 기능성과 가독성에는 집중하지만 보안은 기본값으로 다루지 않는다고 설명했습니다. 다른 참가자는 AI와 함께하면 보안 고려가 머릿속에서 뒤로 밀리고, 한 줄씩 읽지 않게 된다고 말했습니다. 연구진은 이를 개인의 게으름으로만 보지 않습니다. 현재 AI 코딩 어시스턴트의 기본 interaction model이 "기능 명세를 주면 코드가 나온다"는 형태이기 때문에, non-functional requirement인 보안, 접근성, 성능이 사용자가 적극적으로 끌어오지 않으면 빠진다는 분석입니다.

P10 사례는 실무자가 바로 이해할 수 있는 종류의 결함입니다. /update-profile endpoint에서 user ID를 request body에서 읽으면, 인증된 사용자가 자기 ID가 아닌 다른 ID를 넣는 순간 권한 우회가 됩니다. 전통적인 secure coding 교육에서는 "identity는 client input이 아니라 session, token, server-side context에서 가져온다"는 규칙으로 설명할 수 있습니다. AI가 그 규칙을 자동으로 적용하지 않았고, 도구 UI도 이 부분을 security-sensitive code로 표시하지 않았습니다. P10이 잡은 것은 모델 덕분이 아니라 개발자의 별도 보안 판단입니다.

P12 사례는 반대로 도구 설계의 가능성을 보여줍니다. P12는 "추가 보안 우려가 남았는가"를 AI에게 물었습니다. 그 질문 하나가 DDoS 관련 위험을 끌어냈습니다. 이 행동은 매우 간단하지만, 14개 세션 중 거의 유일하게 관찰된 효과적 coping strategy였습니다. 여기서 실무 지침 하나가 나옵니다. AI 코딩 작업을 끝낼 때 "보안 리뷰해줘"를 뒤늦게 붙이는 것보다, 팀 차원의 템플릿으로 "생성 전 요구사항"과 "생성 후 보안 질의"를 모두 강제해야 합니다.

논문이 제안한 도구 개선도 구체적입니다. 첫째, AI 코딩 어시스턴트는 코드 생성 뒤 자동 보안 리뷰 pass를 실행할 수 있습니다. 둘째, 인증, 파일 업로드, 결제, PII, 외부 URL fetch, database write처럼 민감한 문맥에서는 생성 전에 보안 요구사항 확인을 요구할 수 있습니다. 셋째, OWASP vulnerability class와 관련된 패턴을 inline warning으로 표시할 수 있습니다. 넷째, 하나의 "최선의 답"만 보여주지 말고 보안 민감 코드에서는 대안 구현, 가정, 불확실성을 같이 보여줘야 합니다.

이 제안은 Salt Code 같은 policy engine이나 GitHub Copilot code review, Snyk Agent Scan, Semgrep/SonarQube MCP 같은 도구와도 맞물립니다. 차이는 삽입 위치입니다. SAST와 DAST는 대체로 code written after를 봅니다. PR review bot도 이미 만들어진 diff를 봅니다. 이 논문이 지적하는 빈틈은 그 전입니다. 첫 프롬프트와 첫 생성 결과에서 보안 요구가 빠지면, 뒤의 도구들은 더 많은 수정 비용을 떠안습니다. AI 코딩 속도가 빨라질수록 이 비용은 line count가 아니라 review queue와 예외 승인으로 나타납니다.

조직 차원의 질문은 더 불편합니다. "우리 개발자는 보안을 잘 안다"는 말은 충분하지 않습니다. 이 논문에서는 보안 우려를 말할 수 있는 개발자도 첫 프롬프트에는 그것을 넣지 않았습니다. 따라서 팀은 AI coding policy를 문서 하나로 끝내기 어렵습니다. repository template, AGENTS.md, Copilot/Codex/Claude Code instruction file, PR checklist, pre-commit hook, CI security scanner, IDE warning이 같은 요구사항을 반복해야 합니다. 보안 지식은 기억에 남아 있는 것만으로는 부족하고, AI와 상호작용하는 순간의 기본값으로 들어가야 합니다.

개발팀이 바로 실험할 수 있는 최소 변화는 세 가지입니다. 첫째, 보안 민감 작업용 프롬프트 템플릿을 만듭니다. 예를 들어 endpoint 생성 요청에는 authentication source, authorization rule, input validation, rate limit, audit log, PII handling을 필수 항목으로 넣습니다. 둘째, AI가 만든 diff를 리뷰할 때 "기능이 맞는가"와 "보안 요구를 처음부터 만족했는가"를 분리합니다. 셋째, 에이전트가 파일을 수정한 뒤 반드시 보안 질의를 한 번 더 수행하게 합니다. 이 세 가지는 새 제품 도입 없이도 가능한 통제입니다.

다만 연구의 한계도 분명합니다. 표본은 15명이고, 코딩 관찰은 14개 세션입니다. 과제는 연구 환경에서 진행됐고, Gemini CLI와 Gemini 2.5 Pro가 pre-installed된 self-hosted VS Code server를 사용했습니다. 실제 회사 repository, 장기 작업, 팀 리뷰, CI 실패, 고객 데이터, 배포 압박이 붙으면 행동이 달라질 수 있습니다. 참가자 P6도 연구 환경에서는 만족한다고 했지만 실제 직장이라면 같은 결과에 만족하지 않았을 것이라고 말했습니다. 따라서 이 논문은 보편 법칙보다 경고 신호로 읽어야 합니다.

그럼에도 0/14라는 숫자는 무시하기 어렵습니다. AI 코딩 도구가 보안 지식을 없앤 것이 아니라, 보안 지식이 실행되는 위치를 바꾼다는 해석은 최근 제품 흐름과 잘 맞습니다. Copilot과 Codex는 code review, sandbox, automation, billing control을 붙이고 있고, 보안 벤더는 AI-generated code governance를 PR 전후로 밀어 넣고 있습니다. 이 논문은 그 제품 경쟁의 사람 쪽 원인을 보여줍니다. 첫 프롬프트가 기능만 말하면, 이후의 agent loop는 기능을 중심으로 굴러갑니다.

앞으로 좋은 AI 코딩 도구의 기준은 "보안 리뷰 기능이 있다"보다 더 엄격해질 수 있습니다. 좋은 도구는 사용자가 endpoint를 요청하는 순간 "누가 이 리소스를 바꿀 수 있는가"를 묻고, file upload를 요청하는 순간 race condition과 path traversal을 떠올리게 하며, OAuth callback을 요청하는 순간 redirect URI와 state 검증을 요구해야 합니다. 보안은 마지막 /security-review 명령 하나가 아니라, 생성 인터페이스의 기본 문법이 되어야 합니다. 이 논문이 남긴 실무 메시지는 간단합니다. AI에게 코드를 맡기는 팀은 보안을 리뷰 단계에만 두면 이미 한 박자 늦습니다.