AI 코딩 도구가 빨라질수록 팀 리드로서 나는 역설적인 불안감을 느낀다. 속도가 문제가 아니다. 속도가 높아질수록 팀이 놓치는 것들이 더 빠르게 쌓인다는 게 문제다. 최근 세 개의 사례가 이 불안감을 구체적인 언어로 정리해줬다. Vibe Coding의 구조적 맹점, AI 에이전트의 중복 생성 실패, 그리고 MCP 기반 보안 자동화의 현실—세 이야기는 결국 하나의 질문으로 수렴한다. AI가 생성한 코드의 품질은 누가 책임지는가?
핵심 이슈: '작동하는 코드'와 '안전한 코드' 사이의 간극
dev.to에 올라온 Vibe Coding 비판 글은 불편한 진실을 정면으로 건드린다. Claude로 실제 서비스를 구축한 비개발자가 자신의 앱이 어떤 데이터베이스를 쓰는지, 인증이 어떻게 작동하는지 전혀 모른다는 사례다. 앱은 돌아간다. 사용자도 있다. 그런데 IDOR 취약점이 터지거나 인덱스 누락으로 DB가 타임아웃되는 순간, 그 사람은 어디를 봐야 할지조차 모른다.
이 글의 저자가 짚은 핵심은 코드 품질이 아니다. 시스템에 대한 이해의 부재다. "AI가 자동차를 줬는데 엔진 작동 원리를 모른다—불이 붙기 전까진 괜찮다"는 비유가 정확하다. '스펙 주도 개발'로 규율을 강화해도 문제는 이동할 뿐 사라지지 않는다. AI가 생성한 구현을 검증하려면 올바른 구현이 어떻게 생겼는지를 이미 알고 있어야 하기 때문이다. 그 판단력은 프롬프트로 얻어지지 않는다.
두 번째 사례는 더 실무적이다. AI 에이전트에게 워크플로우 규칙 하나를 추가하라고 요청했더니, 에이전트는 이미 동일한 기능을 수행하는 훅 15개와 스킬 4개가 존재한다는 사실을 전혀 확인하지 않고 새 코드를 작성했다. 더 황당한 건 새로 만든 레이블 두 개—timed-followup, awaiting-reaction—를 실제로 읽는 코드가 에이전트 자신이 방금 쓴 파일 외엔 아무것도 없었다는 점이다. 레이블이 아니라 쓰레기였다.
이 저자(nomurasan)의 진단이 날카롭다. 에이전트는 시스템 지도를 로드하지 않은 채 작업을 시작하기 때문에 모든 요청이 그린필드처럼 보인다. 인간 개발자는 새 코드를 짜기 전에 기존 코드를 읽는다—중복을 만들면 바보처럼 보인다는 사회적 두려움도 작동한다. 에이전트에겐 그런 억제력이 없다.
맥락 해석: 속도는 검증 구조 없이는 부채다
세 번째 사례는 해결책의 방향을 보여준다. MCP(Model Context Protocol)를 활용해 Beagle Security를 Cursor·Claude 워크플로우에 직접 연결하면, 보안 스캔이 PR 이후 별도 대시보드 확인이 아니라 코드 저장 시점의 대화창에서 바로 피드백으로 돌아온다. SQL Injection이나 XSS가 코드가 아직 내 머릿속에 생생할 때 보인다는 것—이게 컨텍스트 스위칭 비용을 없애는 핵심이다.
그런데 이 글의 저자(Renato Marinho)가 동시에 경고하는 지점이 있다. MCP로 에이전트에게 '손'을 주면, 에이전트가 침해되거나 환각 명령을 실행할 경우 그 손이 인프라 공격 표면이 된다. 그는 V8 샌드박스 격리, SSRF 방지, DLP, HMAC 감사 체인 같은 거버넌스 레이어를 별도로 설계했다고 밝힌다. 자동화의 편의와 통제 불가 에이전트 자율성 사이의 균형—이게 MCP 도입의 핵심 설계 과제다.
세 사례를 나란히 놓으면 패턴이 보인다. AI는 생성에 최적화되어 있고, 감사·검증·억제에는 구조적으로 취약하다. 속도를 올리면 이 취약성이 증폭된다. 팀이 설계로 막지 않으면 AI가 빠르게 짤수록 기술 부채와 보안 구멍도 빠르게 쌓인다.
시사점: 팀이 빌드 전에 설계해야 할 품질 게이트 3가지
게이트 1 — 빌드 전 인벤토리 강제화
AI 에이전트가 새 훅, 스킬, 규칙, 레이블을 생성하기 전에 반드시 ls와 grep으로 동일 개념의 기존 구현을 검색하도록 워크플로우를 설계해야 한다. nomurasan의 사례에서 추출한 규칙은 단순하다: 기존 메커니즘이 있으면 확장하고, 없을 때만 새로 빌드한다. '더 깔끔한 새 코드'는 이유가 되지 않는다. 에이전트가 자율적으로 이 단계를 건너뛰지 못하도록 파이프라인에 게이트를 물리적으로 삽입해야 한다.
게이트 2 — IDE 내 보안 피드백 루프 통합
보안 검증을 PR 이후 단계에 두는 건 이미 늦다. MCP를 활용해 보안 스캔을 개발자의 실제 코딩 컨텍스트 안으로 끌어당겨야 한다. 단, 에이전트에게 보안 도구의 '손'을 줄 때는 반드시 격리 실행 환경과 감사 체인을 함께 설계해야 한다. 자동화의 편의를 얻으면서 에이전트 자율성을 통제하는 것—이 두 목표는 동시에 설계되어야 한다. 둘 중 하나만 하면 절반짜리 게이트다.
게이트 3 — 엔지니어링 판단의 체크포인트 명문화
AI가 생성한 코드가 아키텍처 리뷰, 보안 리뷰, 확장성 리뷰를 통과하지 않고 프로덕션에 올라가지 못하도록 팀 프로세스에 명시적 체크포인트를 박아야 한다. Vibe Coding 비판 글의 핵심 메시지는 이것이다: AI는 해피 패스를 풀고 엣지 케이스를 놓친다. 에이전트가 자신 있게 생성한 코드가 레이스 컨디션, 접근 제어 누락, 동시 쓰기 충돌을 내포하고 있는지 판별하는 건 경험에서 나오는 패턴 인식이다. 이 판단을 AI에게 위임할 수 없다. 사람이 최종 체크포인트를 서야 한다.
전망: AI-First 팀의 속도는 게이트 설계 수준에 비례한다
나는 AI 코딩 도구에 낙관적이다. 지금까지 본 생산성 배율 중 가장 크다. 그러나 이 낙관론은 게이트 없는 속도가 얼마나 빠르게 프로덕션 사고로 이어지는지를 냉정하게 인정하는 것과 공존해야 한다. AI-First로 팀을 리빌딩할 때, 'AI를 얼마나 많이 쓰는가'보다 '어느 지점에서 AI를 멈추고 사람이 판단하는가'를 설계하는 데 더 많은 시간을 써야 한다.
게이트는 속도를 죽이는 장치가 아니다. 게이트는 속도를 지속 가능하게 만드는 구조다. AI가 빠르게 짤수록, 팀이 먼저 설계해야 할 것은 바로 이 세 개의 멈춤점이다.