파이프라인은 초록색이었다. 테스트도 통과했다. 코드도 깔끔했다. 그런데 시스템은 조용히 망가지고 있었다.
Ashish Nadar가 AI 기반 백엔드 개발 연구에서 경험한 이 순간은, 단순한 버그 리포트가 아니다. AI가 코드와 테스트를 동시에 생성하는 워크플로우에서 발생하는 구조적 맹점을 정확히 짚는다.
문제의 핵심: 행동 드리프트
AI가 백엔드 로직을 수정하면서 테스트도 함께 업데이트하면 어떤 일이 생길까. 시스템의 동작이 바뀐다. 테스트는 새 동작을 기준으로 갱신된다. 파이프라인은 그린을 보고한다. 그리고 아무도 그 '새 동작'이 틀렸다는 사실을 알아채지 못한다.
이것이 Nadar가 '행동 드리프트(behavioral drift)'라고 부르는 현상이다. 코드는 오히려 더 깔끔해 보인다. 리팩터링 후 가독성이 올라갔다. 그러나 특정 실패 조건에서 트리거되어야 할 폴백 경로가 조용히 멈춰 있다. 내부 테스트는 아무것도 잡아내지 못했다.
내가 이 문제를 심각하게 보는 이유는 하나다. AI가 생성자와 검증자를 동시에 맡으면, 두 역할이 같은 편향을 공유한다. 틀린 전제 위에서 테스트를 작성하면 그 테스트는 '통과'를 보장하는 장치가 아니라 '오류를 은폐'하는 장치가 된다.
현실 사례: Amazon의 거버넌스 실패
이론이 아니다. 2025년 3월, Amazon 북미 마켓플레이스는 하루 동안 주문 건수가 99% 급감했다. 630만 건의 주문이 사라졌다. 해킹이 아니었다. 자연재해도 아니었다. AI 코딩 어시스턴트 Amazon Q가 오래된 내부 위키에서 끌어온 부정확한 정보를 바탕으로 조언했고, 그 변경이 검토 없이 프로덕션에 올라갔다.
3일 전에 이미 한 차례 사고가 있었다. 12만 건 주문 손실, 160만 건의 웹 오류. 전 세계적으로. 그리고 Amazon 내부 문서는 조용히 인정했다. 생성형 AI 도구가 "안전 인프라의 공백을 더 빠르게 노출시켰다"고.
Amazon의 대응은 90일 '코드 안전 리셋'이었다. 시니어 엔지니어가 AI 생성 코드 변경을 배포 전에 승인해야 한다. 디렉터와 VP가 조직 내 모든 프로덕션 코드 변경을 감사해야 한다. 통제된 마찰(controlled friction)을 의무화했다.
세계 최대 이커머스 기업이, 지구상에서 가장 뛰어난 엔지니어들을 보유하고도, 거버넌스가 필요하다는 사실을 사고 이후에 발견했다는 점이 중요하다. 이건 Amazon만의 문제가 아니다.
그런데 여기서 냉정하게 짚어야 할 게 있다. 시니어 엔지니어가 코드를 리뷰하는 것은 거버넌스 레이어가 아니다. 그건 병목이다. 점심 전에 47개의 AI 생성 PR을 검토하다 지친 시니어 엔지니어가 번아웃 상태에서 실수를 놓치면 시스템은 다시 무너진다. 사람을 루프에 넣는 것은 단기 처방이고, 구조가 규칙을 강제하는 것이 장기 해법이다.
테크 리드가 설계해야 할 것: 독립 검증 계층
Nadar의 처방은 명확하다. 더 좋은 내부 테스트가 아니다. 테스트를 시스템 경계 밖으로 꺼내야 한다. AI 기반 개발이 근본적으로 오염시킬 수 없는 레이어로.
외부 자동화 테스트는 실제 클라이언트처럼 백엔드에 접근한다. 내부 코드 구조에 관심이 없다. 오직 하나만 묻는다. 시스템이 여전히 올바르게 동작하는가?
dev.to에 공개된 'Beyond the Hype' 가이드는 이를 'AI 아키텍트'로의 전환이라는 프레임으로 설명한다. 개발자의 역할이 코드 작성에서 명세 설계, 시스템 통합, 검증 감독으로 이동한다는 것이다. 특히 '검증자 모델(Verifier Model)' 패턴—창의적 대형 모델의 출력을 더 작고 결정론적인 모델이나 규칙 엔진으로 검사하는 구조—은 행동 드리프트 문제에 대한 구조적 응답이다.
이 세 가지 관점을 팀 설계 언어로 번역하면 다음과 같다.
첫째, 구현과 검증을 같은 AI 세션에서 처리하지 않는다. 코드를 생성한 컨텍스트와 테스트를 작성하는 컨텍스트를 분리한다. 가능하면 다른 도구, 다른 세션, 다른 담당자가 맡도록 워크플로우를 설계한다.
둘째, 테스트 스위트를 명세 기반으로 구성한다. AI에게 준 프롬프트 스펙으로부터 테스트 케이스를 도출한다. 구현이 달라져도 명세는 바뀌지 않는다. 테스트가 구현에 종속되는 순간, 그 테스트는 드리프트를 감지하는 센서가 아니라 드리프트를 따라가는 추적자가 된다.
셋째, 감사 추적을 별도 작업이 아니라 시스템의 기본값으로 만든다. Amazon이 90일 리셋 이후 도입한 '문서화 강화'는 피로한 엔지니어에게 부담을 얹는 방식이다. 변경이 일어날 때 감사 로그가 자동으로 생성되는 구조를 설계 단계에서 심어야 한다.
전망: '품질 가드레일'은 선택이 아니다
AI가 코드와 테스트를 동시에 생성하는 속도는 계속 빨라진다. 이 속도는 거버넌스 공백을 확대하는 방향으로도 작동한다. Amazon의 내부 문서가 표현했듯, AI는 안전 인프라의 구멍을 만드는 게 아니라 이미 있던 구멍을 더 빨리 찾아낸다.
테크 리드 입장에서 이 시점에 해야 할 질문은 하나다. 우리 팀의 검증 레이어는 AI 생성 코드로부터 독립적인가?
그 답이 '아직 모르겠다'라면, 지금이 설계를 시작할 타이밍이다. 파이프라인이 초록색일 때는 이미 늦을 수 있다.