AI 에이전트가 작성한 코드, 보안은 누가 지킬까

최근에 AI 코딩 에이전트를 실무에 도입한 팀 이야기를 들었다. 생산성은 확실히 올랐다고 한다. PR이 빨리 올라오고, 코드 리뷰 사이클이 짧아졌다. 그런데 보안 팀에서 "잠깐, 이거 확인해봤어?"라고 들고 온 리포트를 보고 모두가 얼어붙었다.

87%의 PR에 취약점이 있었다

DryRun Security가 2026년 3월에 발표한 보고서는 충격적이다. Claude Code, OpenAI Codex, Google Gemini 세 에이전트에게 실제 앱 개발을 시켰더니, 30개의 PR 중 26개(87%)에서 최소 한 개 이상의 고위험 취약점이 발견되었다. 인증 없는 엔드포인트, 하드코딩된 JWT 시크릿, 레이트 리미팅 누락, SQL 인젝션 등 OWASP Top 10에 나오는 것들이다.

가장 무서운 건 누적 효과다. PR 단위로 보면 작은 문제 같은데, PR이 쌓일수록 취약점이 복합적으로 연결된다. 3번째 PR에서 만든 인증 단축은 단독으로는 별거 아닐 수 있는데, 12번째 PR에서 그 코드를 기반으로 기능을 추가하면 치명적인 권한 상승으로 이어진다.

에이전트의 사고방식이 보안과 안 맞는 이유

이건 에이전트가 "바보라서"가 아니다. 에이전트는 주어진 프롬프트를 기준으로 "작동하는 코드"를 최우선으로 만든다. 보안은 프롬프트에 명시적으로 요구하지 않으면 자연스럽게 누락된다.

실제로 테스트를 보면, 명시적으로 "보안 감사를 해봐"라고 지시했을 때 Codex는 자가 수정 능력이 눈에 띄게 좋아졌다. 즉, 에이전트는 보안을 모르는 게 아니라 기본 동작 모드에 보안이 포함되어 있지 않을 뿐이다.

취약점의 종류, 놀랍게도 뻔하다

보고서에서 반복적으로 나타난 취약점 10가지를 보면 놀라울 정도로 "클래식"하다:

• Broken Access Control: 가장 흔한 문제. 인증 없는 destructive 오퍼레이션
• 비즈니스 로직 실패: 점수, 잔액, 잠금 해제 상태 등을 클라이언트에서만 검증
• WebSocket 인증 누락: REST API에는 인증 미들웨어를 만들었는데 WebSocket에는 빠짐
• JWT 시크릿 관리: 하드코딩된 fallback 시크릿 사용
• 레이트 리미팅: 미들웨어는 정의했는데 실제 적용이 안 됨

2026년에도 여전히 이런 문제들이 베스트셀러다. 에이전트가 만든 코드라고 특별히 새로운 형태의 취약점이 나오는 건 아니다. 다만, 생산성이 높아지면서 취약점이 더 빠르게, 더 많이 만들어진다는 게 핵심이다.

에이전트 환경 자체도 공격 대상

코드의 취약점만 문제가 아니다. 최근 BeyondTrust Phantom Labs가 OpenAI Codex에서 명령어 인젝션 취약점을 발견했다. 사용자가 제공한 파라미터가 셸 명령으로 그대로 전달되어 GitHub OAuth 토큰이 노출될 수 있었다. 이건 에이전트가 작성한 코드의 문제가 아니라 에이전트 실행 환경 자체의 문제다.

2025년 말에는 Claude Code에서 DNS를 통한 데이터 반출 취약점(CVE-2025-55284)도 발견되었다. 심지어 악의적인 저장소를 클론하면 API 키가 유출되는 경우까지 있었다(CVE-2026-21852).

보안 연구자 Ari Marzouk가 6개월간 AI 코딩 도구들을 테스트한 결과, 테스트한 모든 도구가 프롬프트 인젝션으로 임의 코드 실행이 가능했다. GitHub Copilot, Cursor, Windsurf, Zed, Roo Code 등 빠짐없이 전부.

실무에서 당장 해야 할 것들

그럼 어떻게 해야 할까? 당장 할 수 있는 현실적인 방법들을 정리해보자.

첫째, 에이전트 PR을 "신뢰하지 않는다"는 전제로 시작하자. DryRun 보고서의 핵심 메시지다. 에이전트가 올린 PR은 일반 PR보다 더 엄격하게 리뷰해야 한다. 특히 인증/인가 로직과 데이터 접근 패턴을 집중적으로 확인한다.

둘째, PR 단위 검사가 아니라 전체 코드베이스 검사를 정기적으로 하자. 누적 취약점은 개별 PR 리뷰에서는 보이지 않는다. 정기적인 SAST 스캔과 수동 보안 감사를 병행해야 한다.

셋째, 보안 검토를 에이전트 파이프라인에 명시적으로 넣자. "기능 구현 → 보안 감사 → 테스트" 순서를 파이프라인으로 만들면 된다. 프롬프트에 "보안 측면도 검토해서 고쳐"라고 추가하는 것만으로도 상당히 달라진다.

넷째, 에이전트에게 최소 권한만 주자. Gartner는 2026년 말까지 기업 애플리케이션의 최대 40%가 AI 에이전트와 통합될 것으로 예상한다. 에이전트가 가진 권한이 공격 노출면이 된다. 토큰 권한을 최소화하고, 민감한 오퍼레이션은 반드시 사람의 승인을 거치게 한다.

다섯째, 패턴 기반 스캐너의 한계를 인정하자. 에이전트가 만드는 취약점은 로직/인가 문제가 많은데, 정규식 기반 SAST는 이런 걸 잘 잡지 못한다. 컨텍스트를 이해하는 분석 도구가 필요하다.

생산성과 보안, 트레이드오프가 아니다

이야기를 듣고 나서 가장 인상 깊었던 건 DryRun 보고서의 결론이다. "에이전트가 안전한 코드를 만들 수 없는 게 아니다. 기본적으로 안전하게 만들지 않을 뿐이다."

생산성 향상은 진짜다. 보안 리스크도 진짜다. 둘 중 하나를 선택하는 게 아니라, 에이전트를 사용하는 방식 자체를 보안 관점에서 재설계해야 한다. 에이전트를 "빠른 주니어 개발자"라고 생각하면 자연스럽다. 주니어가 작성한 코드를 프로덕션에 바로 배포하지 않듯, 에이전트의 코드도 검증 프로세스를 거쳐야 한다.

다만 차이점이 있다면 주니어는 시간이 지날수록 배우지만, 에이전트는 매번 첫날처럼 행동한다는 것. 그래서 프로세스가 더 중요하다.

---

여러분은 AI 코딩 에이전트를 쓰시나요? 보안 검토는 어떻게 하고 계신지 궁금합니다. 에이전트 PR을 어떻게 리뷰하고 계시는지 공유해주시면 감사하겠습니다.

#ai #kr