AI 코드, '돌아간다'와 '안전하다'는 다르다

AI 코드, '돌아간다'와 '안전하다'는 다르다

MCP 프로덕션 이슈 3종, LLM 보안 스캔 실측, vibe-coded 사이트 데이터 유출—세 사례가 동시에 가리키는 것은 AI 생성물에 대한 검증 게이트 설계의 부재다.

AI 코드 품질 MCP 프로덕션 이슈 claude-security 보안 게이트 AI 코드 검증 vibe-coding 위험 LLM 보안 스캔
광고

'작동한다'는 말이 요즘처럼 위험하게 들린 적이 없다. AI 코딩 도구는 확실히 빠르다. 세무 신고 자동화를 직접 실험한 한 개발자는 32건의 거래를 freee에 입력하는 데 Claude Code + MCP로 3분이 걸렸다고 보고한다. 수작업이라면 1시간이 넘는 일이다. 그런데 같은 실험이 프로덕션에서 세 번 깨졌다. 영수증 첨부 불가, 270개 툴 스키마가 컨텍스트를 집어삼킨 토큰 낭비, 그리고 API 레이트 리밋을 조용히 무시하는 실패 모드. 세 가지 모두 '작동하는 것처럼 보이다가 실제로는 틀린' 케이스다.

이 이야기의 핵심은 MCP 자체의 결함이 아니다. MCP는 바이너리 업로드를 지원하지 않는다—이건 프로토콜 설계 결정이다. 270개 툴이 컨텍스트를 채우는 건 SaaS 벤더가 '제품 전체를 하나의 MCP 서버로 노출'하는 현재 관행의 문제다. 레이트 리밋 응답을 조용히 넘기는 건 MCP 프로토콜에 retry_after 프리미티브 자체가 없기 때문이다. dev.to에 공개된 이 freee + Claude Code 실험이 의미 있는 건, 이 세 가지 한계를 '90% 작동, 10%는 CLI 접착제'라는 정직한 프레임으로 정리했기 때문이다. 해피 패스보다 이음새를 먼저 설계하라는 결론은, AI-First 워크플로우를 팀에 도입하려는 테크 리드라면 그냥 지나쳐선 안 된다.

보안 쪽은 더 직접적인 실측값이 나왔다. Anthropic 공식 플러그인 claude-security v0.10.0을 189개 서브에이전트, 2시간 분량으로 실행한 결과가 dev.to에 공개됐다. 결과는 20건(HIGH 5 / MEDIUM 15). 111개 원시 후보 → 83개 중복 제거 → 45개 패널 심사 → 20개 최종 확정. 패널 거절률이 절반을 넘는다. 이걸 어떻게 읽을 것인가—'패널이 잘 작동한다'는 증거인지, '리서치 단계가 후보를 과잉 생성하고 패널이 뒷수습한다'는 증거인지—보고서 자체는 이 두 해석을 가르는 데이터를 제공하지 않는다. 하지만 결정적인 숫자가 하나 있다. 최종 20건 중 거짓 양성으로 기각한 것이 0건이었다는 것. 코드만 읽고 추론하는 LLM이 기존 정적 분석이 놓친 설정 파일과 자연어 지시 파일의 보안 문제를 실제로 잡아냈다.

이 두 사례를 이어주는 세 번째 이야기가 있다. AI 툴로 클라이언트 사이트를 납품한 신입 개발자 사례—프론트엔드는 깔끔했고, 백엔드는 다른 사용자의 개인정보를 아무에게나 노출했다. 개발자는 문제가 생기자 같은 AI 툴에 다시 패치를 요청했고, 결과는 '쓰레기 위에 쓰레기'였다. 인증, 권한, 데이터 격리—이 중 어느 것도 스크린샷에 나타나지 않고, AI 툴이 UI를 그럴듯하게 만들었다고 해서 자동으로 해결되지 않는다. dev.to의 이 글이 직접적으로 짚은 것처럼, '완성처럼 보였다. 완성이 아니었다.'

세 사례의 공통 구조를 정리하면 이렇다. AI가 생성하거나 실행한 결과물은 '작동 확인'과 '보안·정합성 확인'이 분리된 두 개의 게이트를 통과해야 한다. 그런데 대부분의 팀은 첫 번째 게이트조차 명시적으로 설계하지 않는다. freee + MCP 실험의 결론이 '해피 패스보다 이음새를 먼저 설계하라'인 것처럼, claude-security가 2시간짜리 스캔 파이프라인으로 존재하는 이유가 있다. AI가 코드를 빠르게 만들수록, 검증 게이트의 부재가 더 빠르게 프로덕션에 도달한다.

테크 리드 관점에서 지금 당장 팀에 적용할 수 있는 설계 원칙은 세 가지다. 첫째, MCP나 AI 에이전트를 프로세스에 붙일 때 프로토콜이 구조적으로 처리하지 못하는 영역(바이너리, 레이트 리밋, 오케스트레이션)을 먼저 목록화하고 그 이음새를 명시적으로 설계한다. 둘째, AI 생성 코드에 대한 보안 스캔을 CI/CD 파이프라인의 선택 항목이 아닌 의무 게이트로 배치한다—claude-security처럼 LLM 기반 스캔이 설정 파일과 자연어 지시 파일까지 읽는다는 점은 기존 정적 분석 도구와 병행할 이유가 된다. 셋째, AI가 만든 결과물을 팀원이 '이해한 뒤 배포'하는 문화를 온보딩 단계에서 명문화한다. 초보 개발자의 vibe-coded 사이트 문제는 숙련도의 문제가 아니라 '검증 없이 배포하는 것이 허용된 문화'의 문제다.

전망은 솔직히 낙관적이다. claude-security의 파이프라인 설계—인벤토리 → 위협 모델 → 리서치 → 스윕 → 패널—는 AI 보안 검증이 체계화되는 방향을 보여준다. MCP 레이트 리밋 문제는 이미 per-tool 토큰 버킷을 강제하는 MCP 게이트웨이들이 등장하면서 프로토콜 외부에서 해결되고 있다. 도구는 빠르게 성숙하고 있다. 문제는 도구가 아니라, 팀이 검증 게이트를 설계하기 전에 도구를 먼저 배포하는 순서에 있다. AI 코드가 '돌아간다'는 것과 '안전하다'는 것은 여전히, 그리고 앞으로도 한동안은, 다른 질문에 대한 다른 답이다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요