도입 사례 — 중견기업 레거시 팀

이 사례는 실제 컨설팅 경험을 익명화해 재구성한 것이다. 조직명·인물·구체 수치는 실제와 다르며, 흐름과 판단 지점만 사실에 기반한다.

상황

대상 조직은 업력이 긴 중견기업의 IT 조직으로, 사내 시스템 다수가 오래된 자바 기반 모놀리스 위에서 돌아가고 있었다. 개발 조직 규모는 수십 명 단위였고, 코드 리뷰 절차는 문서상 존재했지만 실제로는 형식적인 승인 클릭에 가까웠다. 도입 전 상태는 성숙도 모델의 L1 탐색(Exploring) 단계였다. 일부 개발자가 개인적으로 코딩 에이전트를 써봤지만 팀 차원의 규칙도, 공유되는 산출물도 없었다. 프롬프트는 각자의 채팅창 안에서 시작하고 끝났다.

도입 과정

파일럿 선정

전사 확산 대신 실패 비용이 낮은 내부 관리자 도구 하나를 파일럿으로 골랐다. 사용자가 제한적이고, 문제가 생겨도 매출에 직접 영향을 주지 않는 영역이었다. 도입 로드맵이 권하는 첫 걸음 그대로였다.

첫 회전과 저항

문제는 파일럿의 첫 사이클이었다. 팀은 의도 문서 없이 곧바로 코딩 에이전트에게 기능을 맡겼다. 결과물은 빠르게 나왔고 데모에서는 그럴듯해 보였다. 그러나 아무도 왜 그렇게 구현됐는지 설명하지 못하는 코드가 쌓이기 시작했다. 매니페스토가 짚은 "검증 없는 바이브" 안티패턴이 그대로 재현된 셈이다. 이후 사소한 수정 하나가 이해하지 못한 다른 코드를 건드리면서 회귀 버그를 냈고, 팀 내에서 "이럴 거면 예전 방식이 낫다"는 회의론이 나왔다. 시니어 개발자 일부는 "에이전트가 우리 도메인의 예외 케이스를 모른다"며 참여 자체를 주저했다.

동시에 다른 문제도 겹쳤다. 에이전트가 만들어낸 변경이 사람 리뷰 대기열에 그대로 쌓이면서, 생성은 빨라졌는데 병합은 예전과 똑같이 느린 상황이 벌어졌다. "병목이 된 인간" 안티패턴이었다.

교정

파일럿 중간에 방향을 틀었다. 1단계 — 의도 정의를 건너뛰지 않기로 하고, 이후 작업마다 의도 문서 템플릿으로 목표와 성공 기준을 먼저 합의했다. 3단계 — 공동 구현에서는 에이전트가 계획을 먼저 제안하고 사람이 승인한 뒤에만 구현에 들어가는 관문을 세웠다. 검증 대기열 문제는 리스크 매트릭스를 도입해 풀었다. 결제·인증 연동처럼 실패 비용이 큰 변경만 인간 리뷰를 필수로 남기고, 내부 도구성 변경은 자동 테스트와 교차 리뷰만으로 통과시키도록 등급을 나눴다. 반복되던 도메인 설명은 CLAUDE.md와 용어집으로 옮겨 다음 세션부터는 다시 설명할 필요가 없게 만들었다.

결과와 교훈

파일럿이 끝날 무렵 팀은 성숙도 모델의 L2 실천(Practicing) 단계에 도달했고, 검증 체계와 공용 컨텍스트 자산이 자리 잡은 일부 영역은 L3 자산화(Compounding)로 넘어가기 시작했다. 사이클 리드타임은 눈에 띄게 줄었고, 재작업률도 낮아졌다. 다만 이 결과는 첫 사이클의 실패를 정직하게 인정하고 6단계 — 환류를 통해 규칙으로 옮겼기 때문에 가능했다. 의도 문서와 계획 승인 관문을 건너뛴 채 속도만 좇았다면, 파일럿은 데모 단계에서 멈췄을 것이다. 교훈은 하나로 요약된다. 저항의 신호(회의론, 리뷰 지연)는 도입을 멈출 이유가 아니라 어느 단계가 빠졌는지 알려주는 진단이었다.