속도는 얻었다. 그런데 뭘 잃었나?
Claude로 하루 만에 피처를 뽑아내고, Copilot이 PR을 자동 리뷰하는 팀. 스프린트당 피처 3개 이상. 외부에서 보면 이상적인 AI-First 팀이다. 그런데 dev.to에 올라온 한 글은 이 풍경에 정직한 균열을 드러낸다. 저자는 Claude로 React 앱을 빠르게 개발하다가 어느 순간 깨달았다. "내가 직접 짜지 않은 피처는 깊이를 이해하지 못하고 있다." PR마다 수십 개 파일이 바뀌고, 리뷰는 형식이 됐고, 엣지 케이스는 머릿속 '나중에 볼 메모'로 쌓였다. 고객 질문에 "확인 후 답변드리겠습니다"가 늘어나는 건 그 결과였다.
이 문제는 단순한 '코드 이해 부족'이 아니다. 두 겹짜리 구조를 갖는다. 첫째는 전문성 격차다. 이미 아는 개념에서는 에이전트의 실수를 잡아낼 수 있다. 하지만 처음 다루는 영역에서는 에이전트가 틀린 가정을 해도 알아차릴 수 없다. 둘째는 학습 루프 붕괴다. 코드를 직접 타이핑하는 과정은 단순 노동이 아니었다. 시스템에 대한 직관을 쌓는 피드백 루프였다. 에이전트에게 작성을 위임하는 순간, 그 루프가 끊긴다. dev.to의 또 다른 글—'hand coding 백래시는 노스탤지어가 아니다'—은 이를 더 날카롭게 짚는다. AI 도구의 진짜 위협은 출력물의 품질이 아니라 구별 불가능성이다. 틀린 코드가 맞아 보이는 상태, 그게 더 위험하다.
Meta가 보여준 반면교사
'hand coding 백래시' 글이 인용한 Meta 사례는 시스템 차원의 경고다. Meta는 AI 도입을 위에서 아래로 강제했다. 엔지니어는 AI 사용량 지표로 평가받았다. 결과는 생산성 향상이 아니라 번아웃과 이탈이었다. '우리 팀 AI 도입 지표가 좋아졌나?'를 묻는 순간, '이 AI가 시스템을 더 좋게 만들었나?'는 더 이상 묻지 않게 된다. AI-First 팀 리드로서 내가 가장 경계하는 시나리오가 바로 이것이다. 속도 지표는 올라가고, 품질 감각은 조용히 무너지는 것.
Anthropic Mythos의 교훈: 오탐이 말해주는 것
curl 프로젝트 리드 Daniel Stenberg의 보고서는 AI 보안 도구에 대한 냉정한 데이터를 제공한다. Anthropic의 Mythos는 curl에서 보안 취약점 5개를 보고했다. curl 보안팀이 검토한 결과? 실제 취약점은 1개뿐이었다. 나머지 3개는 문서화된 API 한계를 취약점으로 오판한 오탐, 1개는 일반 버그였다. 확인된 취약점조차 심각도 '낮음'이었다.
이 결과를 Mythos 실패로 읽으면 절반만 맞다. curl은 OSS-Fuzz, Coverity, CodeQL, 수십 차례의 전문 감사를 거친 17만 8천 줄짜리 코드베이스다. 200억 개 이상의 인스턴스에 설치되고, 573명의 기여자가 평균 4.14회 재작성한 코드다. 쉬운 버그는 이미 수년 전에 잡혔다. Stenberg가 직접 밝혔듯, AI 도구들이 이전 8~10개월간 이미 200~300개 버그를 수정했다. Mythos가 들어올 자리가 좁았던 것이다. 진짜 교훈은 다른 데 있다: AI 보안 도구의 결과를 그대로 신뢰하면 안 된다. 80% 오탐율은 도구가 나쁜 게 아니라, 검토 없이 결과를 받아들이는 프로세스가 나쁜 것이다.
의심을 시스템으로 만드는 법: 멀티 에이전트 리뷰
그렇다면 어떻게 할 것인가. 가장 실용적인 해법은 dev.to 글이 제시하는 멀티 에이전트 리뷰 프레임워크다. 코드를 한 줄도 쓰기 전에, 먼저 설계 문서를 비기술 언어로 작성하게 한다. 문제, 가정, 선택한 접근법, 검토하고 기각한 대안을 모두 포함한다. 구현 후에는 세 역할의 에이전트가 순서대로 리뷰한다.
- 솔루션 아키텍트 에이전트: 확장성·유지보수성 문제와 검증되지 않은 가정을 찾는다
- 비기술 사용자 에이전트: 기능이 실제 사용자가 기대하는 것과 다른 부분을 평이한 언어로 짚는다
- 컨텍스트 없는 시니어 엔지니어 에이전트: diff만 보고 불명확하거나 문서화되지 않은 부분을 찾는다
저자의 경험에 따르면 이 멀티 패스 리뷰는 매번 무언가를 잡아냈다. 놓친 엣지 케이스, 검증되지 않은 가정, 생성 에이전트에게는 자명했지만 리뷰 에이전트 눈에는 완전히 불투명한 설계 결정. 이건 단순한 코드 리뷰 체크리스트가 아니다. 에이전트가 에이전트를 의심하는 구조다. 내가 직접 이해할 수 없는 코드를 다른 에이전트에게 설명하게 만드는 것이다.
에이전트에게 던지는 질문 두 가지를 그대로 가져올 만하다:
"오늘 이 프로젝트에 합류한 신입 엔지니어에게 설명하듯 이 코드 변경을 설명하라. 어떤 문제를 해결하는가, 어떤 가정을 했는가, 검토하고 기각한 대안은 무엇인가."
"진행하기 전에, 이 버그의 근본 원인을 어떻게 찾았는지 설명하라. 시스템 상태에 대해 어떤 가정을 하고 있는가, 이 수정이 코드베이스의 어떤 다른 부분에 영향을 줄 수 있는가."
이 프롬프트들은 에이전트의 추론을 표면으로 끌어올린다. 설명할 수 없으면 믿지 않는다.
팀 리드가 지금 당장 챙겨야 할 것
세 소스를 엮으면 실행 가능한 원칙이 나온다.
첫째, AI 도구 결과에 오탐 비율을 예산으로 편성하라. Mythos의 curl 사례처럼 80% 오탐은 예외가 아닐 수 있다. 보안 스캔 결과를 그대로 티켓으로 만드는 워크플로우는 팀 에너지를 낭비시킨다. 1차 필터링 프로세스를 먼저 설계해야 한다.
둘째, 에이전시를 지표로 측정하라. 'hand coding 백래시' 글이 제안하는 rework ratio가 가장 직접적이다. 에이전트가 생성한 코드의 재작업 비율이 직접 작성 코드보다 높다면, 생성 속도가 품질 비용을 갉아먹고 있는 것이다.
셋째, 이해하지 못하는 모듈에는 에이전트를 쓰지 않는다. 팀 누구도 깊이 모르는 모듈에 에이전트를 붙이면, 그럴듯하게 보이지만 복잡도만 증가하는 코드가 쌓인다. 인증, 상태 관리, 인프라 설정은 직접 작성하고 여러 사람이 리뷰하는 규칙을 지킨다.
코드베이스가 블랙박스가 되는 순간
Stenberg의 표현을 빌리면, 우리는 과거에 AI 출력물의 블랙박스 문제를 해결하기 위해 설명 가능성 패키지를 요구했다. 이제 같은 원칙을 코드베이스에 적용해야 한다. 코드 변경의 이유가 PR과 함께 인코딩되지 않으면, 결국 코딩 에이전트만 디버깅할 수 있는 코드베이스가 된다. 그건 속도를 얻고 오너십을 잃는 거래다.
AI-First로 팀을 리빌딩하면서 내가 가장 자주 하는 말이 있다. AI는 도구가 아니라 동료다. 동료를 맹목적으로 믿지 않듯, 에이전트도 맹목적으로 믿지 않는다. 설명을 요구하고, 가정을 검증하고, 이해하지 못하면 진행하지 않는다. 의심은 비효율이 아니라 품질 관리 그 자체다.