테스트는 통과했다. 그런데 시스템은 틀려가고 있었다
가장 무서운 버그는 에러를 던지지 않는다. CI는 녹색이고, 스테이징도 멀쩡하고, UI도 렌더링된다. 그런데 사흘 뒤 고객 클레임이 들어오고 나서야 팀은 알게 된다—에이전트가 그 사이 조용히 틀린 답을 내놓고 있었다는 것을.
이것이 드리프트(drift)의 본질이다. 하드 페일이 아니라 품질 저하다. 예외가 발생하는 게 아니라 응답이 서서히 나빠지는 것이다. AI 도구를 팀에 도입한 순간부터, 이 문제는 이미 시작된다.
드리프트는 세 얼굴로 나타난다
dev.to에 게재된 두 편의 실전 분석—Scarab Systems의 코드 드리프트 진단기와 Saurav Bhattacharya의 프로덕션 에이전트 모니터링 경험기—을 겹쳐 읽으면, 드리프트의 패턴은 크게 세 가지로 수렴한다.
첫째, 코드 드리프트. AI 코딩 에이전트는 로컬 문제를 잘 푼다. 눈앞의 에러를 패치하고, 테스트를 통과시킨다. 그런데 시스템이 복잡해질수록 에이전트는 '레이어 간 전제'를 잃기 시작한다. 한 레이어의 변경이 다른 레이어의 가정을 조용히 위반한다. 빌드는 된다. 테스트도 통과한다. 하지만 시스템은 내부적으로 스스로와 어긋나고 있다. Scarab Systems가 자체 진단 도구를 만든 이유가 여기 있다—리포지토리가 '무엇을 주장하는가', 코드가 '실제로 무엇을 하는가', 테스트가 '정말 무엇을 증명하는가', 런타임이 '무엇을 반박하는가'—이 네 가지 증거 레이어가 여전히 일치하는지를 수리 전에 먼저 확인하는 것.
둘째, 에이전트 행동 드리프트. 프로덕션에서 24시간 돌아가는 에이전트는 세 가지 방식으로 조금씩 이상해진다. 컨텍스트 신선도가 떨어지거나(지식 베이스가 7일 이상 된 청크로 가득 차거나), 응답 패턴이 기준선에서 통계적으로 멀어지거나(응답 길이, 레이턴시, 툴 호출 횟수가 2.5 시그마 이상 이탈), 환각 비율이 2%에서 8%로 서서히 올라가거나. 핵심은 개별 응답이 아니라 응답의 분포가 변하는 것을 잡아야 한다는 점이다. 단 한 번의 이상한 응답은 신호가 아니다. 100번 중 응답 패턴이 서서히 이동하는 것이 신호다.
셋째, 사일런트 툴 페일. Claude Code를 Windows PowerShell 환경에서 운영하던 개발자가 한 시간을 날렸다. 한글 키워드 라우터가 영어 규칙은 정상 동작하고 한국어 규칙만 조용히 무시했다. 에러도 없고, 로그도 없고, exit code도 0. 원인은 파일 인코딩이었다—PowerShell 5.1이 BOM 없는 UTF-8 파일을 레거시 코드 페이지로 파싱하면서 한글 바이트를 조용히 깨먹은 것이다. AI 도구의 훅(hook) 레이어에서 발생한 이 버그는 '코드 논리'가 아니라 '환경 전제'가 틀렸기 때문에 일어났다. 그리고 그래서 더 찾기 어려웠다.
공통점: 드리프트는 소리 없이 쌓인다
세 사례의 공통점은 하나다. 실패가 조용하다. 빌드가 깨지지 않는다. 테스트가 빨간불로 바뀌지 않는다. 알림이 오지 않는다. 그러다 고객 클레임이 오거나, 한 시간째 디버깅하다가 인코딩을 발견하거나, 코드리뷰에서 '이 레이어 전제가 언제 바뀐 거야?'라는 질문이 나온다.
AI가 드리프트를 만든 게 아니다. 인간 개발자도 오래된 팀의 레거시 코드에서 똑같은 일을 했다. AI가 바꾼 건 속도다. 에이전트가 하루에 수백 줄을 쏟아내는 속도로, 드리프트도 쌓인다. Scarab Systems의 표현을 빌리면, 'AI는 드리프트를 발명하지 않았다. 더 빠르고, 더 크고, 더 무시하기 어렵게 만들었을 뿐이다.'
설계로 막을 수 있는 것과 감지해야 하는 것을 분리하라
드리프트 관리의 핵심은 예방과 감지의 레이어를 명확히 나누는 것이다.
예방 가능한 드리프트는 컨텍스트 신선도다. 에이전트가 실행되기 전에 지식 베이스의 마지막 인덱싱 시점을 확인하고, 오래된 청크 비율이 30%를 넘으면 리프레시하는 것은 실행 전에 막을 수 있다. Claude Code 훅이라면 파일 저장 시 BOM 처리를 자동화하거나, 팀 온보딩 가이드 첫 페이지에 인코딩 셋업을 못 박아두는 것이 여기에 해당한다.
감지해야 하는 드리프트는 행동 변화다. 응답 길이, 레이턴시, 툴 호출 횟수를 롤링 윈도우로 추적하고, 기준선에서 2.5 시그마 이상 벗어날 때 알림이 오게 하라. 환각 탐지는 비용이 크니 5~10% 샘플링으로 시작하되, 수치 일관성과 엔티티 그라운딩 두 가지는 반드시 커버해야 한다.
코드 드리프트 감지는 리포지토리 레벨에서 설계해야 한다. 단순히 테스트를 추가하는 것이 아니라, 레이어 간 전제가 깨졌는지를 주기적으로 검증하는 루틴—코드가 주장하는 것과 실제로 하는 것이 여전히 일치하는지를 묻는 진단—이 필요하다.
팀에게 남기는 실행 체크리스트
내일 당장 쓸 수 있는 것부터 정리하면:
- 기준선은 테스트 환경이 아니라 최근 7일 프로덕션 데이터로 세운다. 테스트 분포와 프로덕션 분포는 다르다.
- 개별 이상값이 아니라 롤링 윈도우 통계로 알림을 설계한다. 하나의 긴 응답은 드리프트가 아니다.
- 컨텍스트 신선도는 실행 전에 확인한다. 실행 후 탐지보다 실행 전 예방이 훨씬 싸다.
- 의도적인 모델 업데이트나 프롬프트 변경 시 기준선을 재설정한다. 그렇지 않으면 모든 개선이 드리프트 알림으로 들어온다.
- Claude Code 훅은 로컬 환경 전제(인코딩, 쉘 버전, 경로 설정)를 팀 표준으로 문서화한다. 로직이 맞아도 환경이 틀리면 조용히 실패한다.
- 환각 탐지는 수치 일관성과 엔티티 그라운딩 두 카테고리로 시작한다. '환각했다/안 했다' 이진 판단은 쓸모없다.
드리프트 부채는 기술 부채보다 무서운 이유
기술 부채는 눈에 보인다. 복잡한 코드, 오래된 의존성, 테스트 커버리지 공백—이것들은 PR 리뷰나 린터에서 걸린다. 드리프트 부채는 다르다. 모든 수치가 정상 범위에 있는 동안 서서히 쌓이다가, 고객 클레임이 오거나 중요한 의사결정에서 에이전트의 잘못된 판단이 발견되고 나서야 수면 위로 올라온다.
AI-First 팀이 빠르게 움직일수록, 이 부채는 더 빨리 쌓인다. 에이전트 속도가 드리프트 속도도 올린다. 그래서 드리프트 감지 설계는 AI 도구 도입 이후에 생각할 일이 아니라, 도입 설계와 동시에 고려해야 할 품질 인프라다.
조용히 망가지는 시스템은 요란하게 망가지는 시스템보다 고치기 어렵다. 팀이 문제가 있다는 것 자체를 모르기 때문이다. AI 도구를 팀에 풀기 전에, '이 도구가 조용히 틀려가고 있을 때 우리는 어떻게 알 수 있는가'를 먼저 설계해야 한다.