AI 에이전트가 같은 실수를 반복하는 이유
팀이 AI 코딩 에이전트를 도입하고 나서 가장 먼저 만드는 게 뭔지 아는가. 모니터링 대시보드다. 에러 로그, 슬랙 알림, Jira 티켓. 뭔가 잘못되면 알 수 있게 해두는 것. 그런데 여기에 치명적인 착각이 숨어 있다. 감지(Detection)와 예방(Prevention)은 완전히 다른 문제다.
dev.to에 공개된 실험 결과가 이 착각을 숫자로 때린다. 6개의 자율 에이전트를 145개 이상의 스펙과 960개 이상의 커밋을 대상으로 돌렸더니, 위반(violation) 감지 건수가 4,768건이었다. 그중 구조적 강제(structural enforcement)로 전환된 건 단 18건. 비율로 치면 477:1. 나머지 4,750건의 위반은 지금 이 순간에도 다시 일어날 수 있는 상태로 남아 있다. 로그에는 찍혔지만, 아무것도 바뀌지 않았기 때문이다.
'프로모션'이 없는 파이프라인은 반쪽짜리다
이 실험이 제시하는 개념이 흥미롭다. 바로 '프로모션(Promotion)'이다. 위반이 감지됐을 때 그것을 문서화하거나 Jira 티켓으로 남기는 게 아니라, 구조적으로 재발 불가능하게 만드는 것을 프로모션이라고 정의한다. 구체적으로는 세 가지 수준이 있다.
- L5 훅(Hook): pre-commit 단계에서 빌드 자체를 막는 자동화 스크립트
- L4 테스트: 위반 케이스를 테스트로 인코딩해 CI에서 자동 차단
- L3 템플릿: 재발 가능한 패턴을 아예 코드 생성 템플릿 수준에서 통제
실험에서 제시된 사례가 명확하다. 에이전트가 전체 테스트를 실행하지 않고 커밋을 날려 무관한 모듈이 깨지는 위반이 반복됐다. 문서에 규칙을 적어뒀더니 에이전트는 이틀 만에 또 어겼다. 컨텍스트 압축 과정에서 prose 규칙이 소실됐기 때문이다. L5 pre-commit 훅으로 전환하자? 이후 30일간 위반 제로.
AI 에이전트는 45분마다 규칙을 잊는다
같은 팀의 또 다른 보고서가 근본 원인을 짚는다. LLM의 컨텍스트 압축(context compression) 문제다. Claude의 컨텍스트 윈도우가 200K 토큰이라고 해도, 에이전트가 파일 40개를 읽고 커맨드 80개를 실행하면 150K 토큰이 금세 쌓인다. 이 시점에서 LLM은 초반 메시지를 요약하거나 버린다. 가장 먼저 사라지는 것이 상단에 위치한 시스템 프롬프트—즉, CLAUDE.md 규칙과 프로젝트 제약사항이다.
6에이전트 프로덕션 시스템을 운영한 경험에 따르면, 압축 이후 에이전트당 하루 평균 12건의 규칙 위반이 발생했고, 이미 처리한 파일을 다시 읽는 중복 작업이 전체 툴 호출의 23%를 차지했다. 더 심각한 건 에이전트가 아무런 에러 없이 자신 있게 규칙 위반 코드를 계속 생성했다는 것이다. 조용한 실패(silent failure)가 가장 위험한 실패다.
해결책으로 제시된 것은 PostToolUse 훅이다. 툴 호출 횟수를 카운팅하다가 150회(컨텍스트의 약 75%) 시점에 세션 요약—수정한 파일, 읽은 파일, 실행한 커맨드—을 영속 스토리지에 플러시(flush)한다. 컨텍스트 압축이 일어나도 이 메모리 파일을 읽으면 규칙과 작업 이력이 복구된다. 구현 자체는 단순하다. .claude/settings.local.json에 훅을 등록하는 것만으로 동작한다. 이 역시 L5 강제(automated, zero-awareness-required)의 전형적인 사례다.
오픈소스 130,000개 커밋이 보여주는 드리프트 패턴
Evolution Engine이라는 오픈소스 CLI가 10개 주요 오픈소스 레포를 대상으로 분석한 결과는 또 다른 각도에서 AI 생성 코드의 구조적 문제를 드러낸다. 13만 개 커밋, 25만 개 이벤트를 분석했더니 10개 레포 전부에서 유의미한 개발 드리프트 신호가 감지됐다.
가장 두드러진 패턴 세 가지:
- CI 빌드 시간 스파이크: 평균 스파이크가 기준치 대비 53배. 한 클라우드 SDK는 1,552배까지 치솟았다. 빌드가 실패하면 티가 나지만, 34배 느려진 채 통과하는 빌드는 아무도 눈치채지 못한다.
- Co-change 노벨티 제로: 같은 파일 조합이 반복적으로 함께 변경되는 패턴. 9개 레포에서 발견됐다. AI가 템플릿 기반으로 변경을 생성할 때 나타나는 전형적 시그니처다.
- 릴리스 케이던스 갭과 코드 분산의 상관관계: 릴리스가 느려질 때마다 변경이 관련 없는 파일들로 넓게 퍼지는 패턴이 8개 레포에서 확인됐다. AI 보조 배치 변경의 흔적일 가능성이 높다.
Google의 DORA 연구가 'AI는 처리량을 높이지만 안정성을 떨어뜨린다'고 지적한 이유가 여기 있다. AI는 더 크고, 더 넓고, 더 반복적인 커밋을 만들어낸다—그리고 그 변화는 어떤 단일 커밋도 이상해 보이지 않는 방식으로 조용히 누적된다.
파이프라인에 '강제 레이어'를 설계하라
세 기사를 관통하는 핵심은 하나다. AI 에이전트는 prose(문서화된 규칙)를 신뢰할 수 없다. 컨텍스트 압축이 그것을 지워버리기 때문이다. 팀이 지금 당장 할 수 있는 설계 원칙을 정리하면 이렇다.
1. 위반을 로깅하는 게 아니라 불가능하게 만들어라 pre-commit 훅, CI 게이트, 테스트 케이스—위반이 감지됐다면 그것을 빌드 파이프라인의 차단 조건으로 전환하라. Jira 티켓으로 남긴 위반은 회귀율 40% 이상이지만, L5 구조적 강제로 전환된 위반의 회귀율은 5% 미만이다.
2. 컨텍스트 압축을 예측하고 메모리를 플러시하라 장시간 세션을 운영한다면 PostToolUse 훅을 반드시 달아라. 에이전트가 '잊는다'는 사실을 모르는 채로 자신 있게 규칙을 어기는 것보다, 시스템이 먼저 메모리를 보존하는 게 낫다.
3. 프로세스 시그널을 모니터링하라 CI 빌드 시간, co-change 패턴, 릴리스 케이던스를 애플리케이션 성능만큼 주의 깊게 추적하라. AI 도입 후 이 지표들이 어떻게 바뀌는지를 보면 문제가 코드에 누적되기 전에 감지할 수 있다.
앞으로: '감지 도구'에서 '강제 파이프라인'으로
AI-First 팀에서 가장 흔히 빠지는 함정은 더 좋은 모니터링 도구를 찾는 것이다. 그러나 477:1이라는 숫자가 말해주듯, 감지 역량은 이미 충분하다. 문제는 감지된 위반을 구조적 예방으로 전환하는 프로모션 파이프라인이 없다는 것이다.
팀의 AI 에이전트가 만드는 위반 중 몇 개가 '다시는 일어날 수 없는' 상태가 됐는지 지금 당장 세어볼 수 있는가. 그 숫자가 팀의 실제 AI 거버넌스 수준이다. 도구를 도입하는 것과 도구를 통제하는 것은 다른 역량이다—그리고 지금 대부분의 팀에게 부족한 건 후자다.