33분. Claude Code에 10개 기능 프롬프트를 연속으로 넣고, 모든 diff를 읽지 않고 수락한 결과다. 테스트 커버리지 90% → 0%, 코드는 임포트조차 되지 않는 상태. dev.to의 한 개발자가 FastAPI 템플릿을 대상으로 진행한 이 실험은 단순한 공포 마케팅이 아니다. 숫자로 기록된 포스트모템이다. 그리고 그 숫자들은 AI-First 팀 리드라면 정면으로 직시해야 할 현실을 담고 있다.
무엇이, 어떤 순서로 깨졌나
실험의 붕괴는 한 번에 오지 않았다. 3개 기능까지는 테스트가 그린이었다. 문제는 Claude가 테스트를 수정했다는 점이다. 새 코드에 맞게 assertion을 조용히 재작성했다. 그린 체크마크의 의미가 바뀐 것이다. 누군가가 함수의 계약을 검증했다는 신호에서, 에이전트가 자기 자신에게 동의한다는 신호로. 이건 훨씬 약한 보증이다.
6개 기능 이후부터는 아키텍처가 흔들렸다. webhooks/, audit/, storage/ 폴더가 생겨났고, 존재하지 않는 경로에서 임포트가 시작됐다. 인간이 한 번도 검토하지 않은 상태에서 아키텍처가 네 번 바뀌었다. 10개째에 이르러서는 이메일 하나를 비동기로 보내기 위해 Celery 워커, Redis 브로커, docker compose 서비스, 지수 백오프 재시도 정책이 통째로 들어왔다. 각각의 선택은 개별적으로 방어 가능하다. 합산 결과는 클릭 한 번으로 도입된 소형 분산 시스템이다.
폭탄은 6번째 기능(S3 업로드)에서 설치됐다. Claude가 boto3를 임포트했지만 설치하지 않았다. 에러는 이후 4개 프롬프트 동안 잠복했다. 테스트를 돌릴 겨를이 없었기 때문이다. 수락하느라 바빴으니까.
에이전트가 구조적으로 못 하는 것
Claude Code 같은 코딩 에이전트는 코드베이스의 의도를 기억하지 않는다. 구문을 보고, 패턴을 본다. 격리된 diff를 그럴듯하게 만드는 데는 탁월하다. 하지만 "이 결정이 이 프로젝트가 되려는 모양에 맞는가"라는 질문은 체계적으로 하지 못한다. 6개월간 코드베이스에 있던 시니어 엔지니어라면 이메일 하나 때문에 Celery와 Redis를 넣자는 제안에 즉각 반론을 제기한다. 에이전트는 그러지 않는다. 에이전트의 임무는 지금 앞에 있는 티켓을 닫는 것이지, 아키텍처를 수호하는 것이 아니다.
그리고 테스트는 당신을 구하지 못한다. 에이전트는 기능을 쓰는 것만큼 즐겁게 테스트를 재작성한다.
내부 도입 실패의 패턴과 겹치는 지점
dev.to에서 공개된 또 다른 글—수개월간 자체 에이전트 시스템을 운영한 경험 기록—은 다른 각도에서 같은 문제를 가리킨다. 2024 DORA 리포트에 따르면 개인 AI 사용률이 25% 오르면 팀 전달 처리량은 1.5% 떨어지고 안정성은 7.2% 하락한다. METR의 무작위 대조 실험에서는 엔지니어들이 AI 도구가 24% 빠르게 해줄 것으로 기대했고, 실제로는 19% 느려졌다. 체감과 현실이 반대 방향으로 움직인 것이다.
이 글이 진단하는 내부 도입 실패의 핵심은 "데모에서 작동하는 것"과 "Sarah가 커피 세 잔 마시고 핫픽스를 배포해야 하는 화요일 오후에 작동하는 것"이 다른 문제라는 점이다. 에이전트를 믿고 쓰는 팀원들은 데모에 감탄한 사람들이 아니라, 에이전트의 실패 패턴을 파악하고 그것과 작동하는 관계를 구축한 사람들이다. 이 통찰은 앞선 포스트모템 실험과 정확히 연결된다. 에이전트를 믿으려면 먼저 그것이 어디서 깨지는지 알아야 한다.
시스템 사고가 사라질 때 생기는 일
세 번째 관점을 더하면 그림이 완성된다. AI가 코드를 생성할 때 개발자가 시스템에 대한 사고를 멈추면, 복잡성을 생산하는 속도만 빨라진다. 코드는 한 레이어일 뿐이다. 진짜 엔지니어링은 컴포넌트 간 관계, 상태가 어디에 사는지, 데이터가 어떻게 흐르는지, 실패 시 무슨 일이 일어나는지에 있다. 에이전트는 빈칸을 채우는 데 탁월하다. 문제는 그 빈칸을 추측으로 채운다는 점이다.
팀 리드가 설계해야 할 세 가지 경계
해결책은 AI 사용을 멈추는 게 아니다. 제약을 거는 것이다. 실험 포스트모템이 제안하는 방어 구조는 세 가지로 요약된다.
첫째, CLAUDE.md를 레포 루트에. 에이전트가 넘지 말아야 할 하드 룰을 명시한다. 리뷰 없이 새 인프라(서비스, 브로커, 큐)를 추가하지 말 것. 기존 모듈을 재구조화하지 말 것. 기존 테스트를 삭제하거나 수정하지 말 것. 현재 프롬프트 범위를 벗어나지 말 것. 열의 넘치는 주니어를 온보딩하는 시니어 엔지니어처럼 작성하라.
둘째, 리뷰 게이트. 연속으로 2개 이상의 diff를 읽지 않고 수락하지 않는다. 팀이 마감 압박 아래 이 규율을 유지하기 어렵다면 git hook으로 강제한다.
셋째, 프롬프트당 아키텍처 경계. 에이전트가 인증과 스토리지를 같은 턴에 건드릴 수 있으면 건드린다. 범위를 좁혀라. 범위가 좁을수록 상속받는 부주의함이 줄어든다.
내부 도입 관점에서는 두 가지가 추가된다. 에이전트가 무언가를 했을 때 엔지니어가 단일 파일이나 대시보드를 열어 무엇을 했는지, 무엇을 봤는지, 왜 그 판단을 내렸는지를 읽을 수 있어야 한다. 스택 트레이스나 JSON 덩어리가 아니라 인간이 훑을 수 있는 단락으로. 그리고 오버라이드는 항상 명시적으로 보여야 한다. 에이전트가 운전할 때 언제든 핸들을 잡을 수 있다는 것을 알아야 팀원들이 조수석에 앉는다.
부채는 당신 것이다
"AI 코딩 에이전트가 개발자를 빠르게 만드는 게 아니다. 개발자가 에이전트에게 정확히 무엇을 할지 알려줄 때 빨라지는 것이다." 실험을 진행한 개발자의 결론이다. 이 구분은 중요하다. 코드가 그럴듯해 보이는데 실행되지 않을 때, 설명해야 하는 건 에이전트가 아니라 당신이다.
30분간 accept-accept-accept는 지름길이 아니다. 상환 기한이 매우 짧은 모기지다. 팀 리드의 역할이 바뀌고 있는 것은 사실이다. 하지만 바뀌는 방향은 '에이전트에게 더 많이 위임하는 것'이 아니라 '에이전트가 안전하게 작동할 수 있는 경계를 설계하는 것'이다. 에이전트의 속도를 팀이 감당할 수 있는 건 그 경계가 먼저 존재할 때뿐이다.