AI가 코드를 생성하고, 스펙을 작성하고, 테스트까지 짜주는 시대다. 그런데 팀에서 'AI가 만들었으니 빠르다'는 말은 들어봤어도, 'AI가 만든 게 맞는지 어떻게 확인했냐'는 질문이 먼저 나오는 경우는 드물다. 문제는 그 검증의 빈자리에서 조용히 쌓인다. 25만 줄 레거시 감사 사례, Claude 스펙 기반 개발 안티패턴, AI 생성 테스트의 구조적 한계—이 세 가지를 하나의 품질 파이프라인으로 연결해서 보면, 우리가 놓치고 있는 지점이 선명하게 드러난다.
핵심 이슈: AI는 그럴듯하게 틀린다
dev.to에 공개된 레거시 코드 감사 사례는 읽는 것만으로도 불편하다. 20년 된 Python 모놀리스, 25만 줄, 테스트 제로, 평문 비밀번호 저장—그 자체로도 충분히 끔찍한데, 진짜 문제는 AI 에이전트가 이 코드를 분석하면서 만들어낸 오류들이다. 1차 단일 에이전트 분석 결과는 18개 섹션, 1,100개 항목의 방대한 보고서를 뽑아냈다. 그러나 3일 후 검증해 보니 절반이 틀렸다. 실제로 11개 파일에 존재하는 프론트엔드 라이브러리를 '코드베이스에 없다'고 단언했고, DB 트리거 수를 '200+'로 추정했지만 실제는 401개였다. 심지어 존재하지 않는 DB 클래스 4개를 그럴듯한 필드 수와 관계까지 붙여서 발명했다.
가장 인상적인 오류는 FK(Foreign Key) 889개 건이다. ref_로 시작하는 컬럼 명명 관례를 외래 키로 오해한 이 숫자는 이터레이션 2→3→4를 거치며 아무도 의심하지 않고 인용됐다. 검증 에이전트 15개가 재확인해도 grep -c "ref_"는 여전히 889를 반환했다. 쿼리는 맞았지만 해석이 틀렸다. 실제 DB의 information_schema를 직접 조회하자 답이 나왔다: 15개. 그것도 전부 시스템 테이블에만. 20년 운영된 비즈니스 테이블에는 참조 무결성이 단 하나도 없었다.
맥락 해석: 세 개의 증상, 하나의 구조적 문제
이 감사 사례가 보여주는 교훈은 단순하다. AI는 검증 수단 없이 주장하면 반드시 환각한다. 저자가 7번의 이터레이션 끝에 확립한 규칙 1번이 '모든 발견에는 file:line 증거가 필요하다'인 이유다. 검증 불가능한 발견은 픽션이다. 더 날카로운 통찰은 마지막 이터레이션에 있다. 검증(validation) 팀의 신뢰도 점수는 89.4%였지만, 적대적(adversarial) 팀 구성 후 점수는 81.8%로 떨어졌다. 저자는 이 낮은 점수가 더 신뢰할 만하다고 말한다. 프로세스가 작동한다는 증거이기 때문이다.
Claude 스펙 기반 개발 안티패턴(dev.to)은 파이프라인의 상류(upstream)에서 같은 문제를 보여준다. 스펙이 모호하면 AI는 '합리적인 가정'을 채워 넣는다. 그 가정은 범용 베스트 프랙티스에 기반하고, 당신의 도메인 컨텍스트와는 무관하다. 특히 두 가지 안티패턴이 팀에서 반복적으로 나타난다. 첫째, Claude에게 스펙까지 생성하게 하는 워크플로우—이건 순환 논리다. AI가 자신이 이해한 것을 스펙으로 쓰고, 그 스펙으로 구현하면 현실 도메인에 한 번도 닿지 않는 코드가 나온다. 둘째, 수용 기준(acceptance criteria) 없는 스펙—"오류를 우아하게 처리한다"는 기준이 아니다. "필수 필드 누락 시 422와 구조화된 에러 바디를 반환한다"가 기준이다. 수용 기준이 없으면 AI는 기술적으로 완벽하지만 기대와 전혀 다른 구현을 낼 수 있다.
AI 생성 테스트 문제(dev.to)는 파이프라인 하류(downstream)에서 같은 구조적 결함을 드러낸다. 저자의 첫 문장이 모든 걸 요약한다: "AI가 생성한 유닛 테스트는 기술적으로 유효하고, 지속적으로 녹색이며, 거의 완전히 쓸모없었다." AI는 커버리지를 채우는 테스트를 생성하는 데 최적화되어 있다. 그러나 커버리지는 안전의 대리 지표일 뿐이다. AI가 생성한 테스트의 문제는 무엇을 검증하는지 불명확한 이름, 한 테스트에 여러 실패 원인, @BeforeEach에 숨겨진 암묵적 의존성이다. 테스트가 실패해도 '무엇이 깨졌는지' 알 수 없는 테스트는 알리바이일 뿐 자산이 아니다.
시사점: AI 품질 파이프라인을 설계하라
세 사례를 하나의 파이프라인으로 연결하면 구조가 보인다.
1단계 — 스펙 품질 게이트: 도메인 지식은 사람이 제공하고, 구조화는 AI가 담당한다. 스펙에는 반드시 수용 기준과 명시적 비목표(non-goals) 섹션이 있어야 한다. Claude의 명확화 질문은 스펙 결함 신호로 처리하고, 그 자리에서 스펙을 업데이트한다.
2단계 — 구현 시 증거 기반 원칙: AI가 생성한 코드나 분석에는 반드시 검증 가능한 근거가 따라야 한다. file:line 참조, 실제 쿼리 결과, 프로덕션 데이터 확인—추정은 분석이 아니다. 비용이나 공수 추정은 AI에게 맡기지 않는다.
3단계 — 테스트 품질 기준: AI가 생성한 테스트를 그대로 병합하기 전에 이름이 명세가 되는지, 하나의 테스트가 하나의 실패 원인만 갖는지, Given/When/Then 구조가 자명한지 검토한다. 커버리지 숫자가 아니라 진단 가치로 테스트를 평가한다.
4단계 — 적대적 검증: 감사 사례의 핵심 교훈이다. 같은 에이전트(또는 같은 팀원)에게 검증을 맡기면 확증 편향이 생긴다. 독립적인 검증 레이어, 가능하면 '틀렸음을 증명하라'는 미션을 가진 팀을 별도로 운영한다.
전망: '빠른 AI'보다 '검증된 AI'가 팀 자산이다
솔직히 말하면, AI 품질 파이프라인을 제대로 설계하는 건 처음에는 느리게 느껴진다. 스펙을 RFC처럼 쓰고, 테스트 이름을 명세처럼 다듬고, 에이전트 결과를 적대적으로 재검증하는 과정은 '그냥 AI한테 시키면 5분인데'라는 유혹과 계속 싸운다. 그러나 레거시 감사 사례의 889→15 FK 전환이 보여주듯, 검증 없는 빠름은 잘못된 전략 결정으로 이어진다. 마이그레이션 전략 전체가 바뀌는 수준의 오류를.
AI-First 팀에서 테크 리드의 역할 변화도 여기서 시작된다. AI가 생성한 코드를 머지하는 속도를 올리는 것보다, AI 산출물이 팀 파이프라인을 통과하기 위한 품질 게이트를 설계하는 것이 더 중요한 역할이 됐다. 스펙 설계 규율, 에이전트 결과 검증 프로토콜, 테스트 품질 기준—이 세 가지를 팀 워크플로우에 명시적으로 심지 않으면, AI는 속도를 높이는 동시에 기술 부채도 같은 속도로 쌓는다. 빠른 AI가 아니라 검증된 AI가 팀의 실제 자산이다.