AI 에이전트와 함께 개발을 시작한 팀이라면 한 번쯤 이런 경험을 한다. 분명히 걷어냈다고 생각한 낡은 패턴이 어느 날 PR에 다시 등장한다. 인터페이스 하나, 팩토리 하나, 호환성 레이어 하나—삭제한 아키텍처가 에이전트 손을 빌려 조용히 되살아나는 것이다. 이건 에이전트가 멍청해서가 아니다. 맥락 부패(context decay) 때문이다.
전통적인 프로젝트는 죽은 코드를 쌓는다. AI 지원 프로젝트는 죽은 맥락을 쌓는다. dev.to에 올라온 'Project Distillation' 글이 정확하게 짚는 지점이 여기다. architecture-v1.md, architecture-final.md, new-architecture.md—살아남은 사람은 어떤 문서가 현재 기준인지 안다. 에이전트는 리포지토리 검색, 대화 히스토리, 메모리 파일을 통해 이 문서들 중 어느 것과든 마주칠 수 있다. 코드는 사라졌지만, 코드를 생성했던 가정(assumption)은 여전히 에이전트 컨텍스트 안에 살아 있다. 레거시가 복사되는 게 아니라 재생성된다는 뜻이다.
이 문제를 '리팩터링으로 해결하면 되지 않나'라고 생각한다면 한 가지 구분을 먼저 짚어야 한다. 리팩터링은 연속성을 전제한다. A → A' → A''—기존 시스템의 가정은 유지하면서 구현을 개선하는 작업이다. 반면 잘못된 게 가정 자체일 때는 리팩터링이 아니라 디스틸레이션(distillation)이 필요하다. 낡은 프로젝트에서 다음 버전으로 살아남을 자격이 있는 지식만 추출하는 것. 코드를 옮기는 게 아니라, 무엇을 의도적으로 남겨두지 않을지 결정하는 작업이다.
설계 1: 프로젝트 디스틸레이션—무엇을 잊을지 결정하라
디스틸레이션의 핵심 질문은 이것이다. "이 아티팩트가 제품과 도메인에 대한 지식인가, 아니면 과거 구현 결정의 부산물인가?" 요구사항, 도메인 규칙, 외부 계약, 재현 가능한 버그—이것들은 살아남을 자격이 있다. 아키텍처에 종속된 추상화, 히스토리컬 워크어라운드, 구현에 결합된 테스트—이것들은 훨씬 냉정하게 들여다봐야 한다.
결과물은 빈 프로젝트가 아니라 검증된 시드(Verified Seed)다. 기존 구현으로부터는 자유롭지만, 개발 과정에서 배운 것으로부터는 자유롭지 않은 출발점. 그리고 여기서 놓치기 쉬운 포인트가 있다—에이전트도 함께 리셋해야 한다. 리포지토리를 청소하는 것만으로는 부족하다. 대화 히스토리, 프로젝트 인스트럭션, 메모리 파일까지 세 가지 레이어를 분리해야 한다.
- 아티팩트 리셋: 폐기된 코드와 문서 제거
- 컨텍스트 리셋: 이전 작업 세션과의 연속성 단절
- 메모리 리셋: 낡은 퍼시스턴트 프로젝트 상태 제거 또는 격리
새 시드를 만들었다고 바로 코드를 생성시키지 마라. 먼저 새 컨텍스트의 에이전트에게 시드를 읽고 시스템을 설명하게 해라. 의도적으로 제거한 가정이 설명에 다시 등장한다면, 어딘가에 오염이 남아 있다는 신호다. 에이전트가 처음에 작성하는 것이 이후 모든 작업의 앵커가 되기 때문에, 얼마나 빨리 쓰느냐보다 무엇을 먼저 쓰느냐가 훨씬 중요하다.
테스트도 디스틸레이션 대상이다. ServiceA는 RepositoryB를 정확히 한 번 호출해야 한다는 낡은 구현을 보존할 뿐이다. 동일한 결제 요청을 반복해도 결제는 한 번만 생성되어야 한다는 행동을 보존한다. 좋은 테스트 스위트는 리디자인 이후에도 살아남아야 할 것들의 명세서다.
설계 2: 프롬프트 린팅—모델을 호출하기 전에 계약을 검사하라
맥락 부패는 에이전트가 장기간 누적한 맥락에서만 오지 않는다. CI/CD 파이프라인 안에서도 조용히 진행된다. dev.to의 또 다른 글은 이를 단적으로 보여주는 사례로 시작한다. 동일한 커밋에 파이프라인이 같은 프롬프트를 세 번 호출했다. 출력은 매번 자신 있어 보였다. 매번 틀렸다. 모델이 실패한 게 아니라 프롬프트가 실패한 것인데, 모델 쿼터를 세 번 소진한 뒤에야 알게 됐다.
핵심 인사이트는 이것이다. 프롬프트는 소스코드처럼 버전 관리하고, 모델 호출 전에 정적으로 검사해야 한다. 프롬프트는 당신과 모델 사이의 계약이다. 계약이 모호하면 출력이 모호하고, 계약이 조용히 바뀌면 CI 결과를 예측할 수 없다. 프롬프트 린터가 검사할 내용은 간단하다.
role섹션이 있는가constraints가 명시되어 있는가output_format이 정의되어 있는가- "do your best" 같은 모호한 지시가 없는가
- 프롬프트가 너무 짧거나(특정성 부족) 너무 길지(분할 필요) 않은가
이 린트 단계는 시맨틱 검토가 아니라 정적 계약 검사다. 모델을 호출하지 않고, 결정론적으로 실행되며, 실패 메시지는 모델이 아닌 프롬프트를 가리킨다. GitLab CI 기준으로 prompts/**/*에 변경이 생기면 린트 잡이 먼저 실행되고, 통과한 프롬프트만 모델 호출 단계로 넘어간다. 순서가 핵심이다—린트 실패 시 파이프라인이 멈추면, 모델에게 나쁜 질문을 다섯 번 반복하는 낭비가 사라진다.
물론 이 접근의 한계도 명확하다. 린터는 누락된 섹션을 잡지, 누락된 판단력을 잡지 못한다. 구조를 통과한 프롬프트가 도메인에서 엉뚱한 답을 내놓을 수 있다. 정적 프롬프트 린팅은 '명백한 낭비를 막는 게이트'지, '정확성을 보증하는 장치'가 아니다. 그 이상을 요구하면 다음 레이어가 필요하다.
설계 3: 에이전트 검증—발견과 증명을 다른 작업으로 취급하라
코딩 에이전트는 수상한 코드를 찾는 데 꽤 능숙하다. 리포지토리를 넘기면 한 시간쯤 콜 스택을 따라가고, 테스트를 읽고, 설정을 확인한 뒤 "이 코드 패스가 애플리케이션을 유효하지 않은 상태로 남길 수 있다"고 돌아온다. 문제는 그 다음이다. dev.to의 세 번째 글이 이 불편함을 솔직하게 짚는다. 가능한 문제를 발견하는 것과 문제가 실제로 존재한다는 걸 증명하는 것은 같은 작업이 아니다.
에이전트가 버그를 발견했을 때 다음 질문이 "얼마나 확신하냐"가 되어선 안 된다. "어떻게 증명할 수 있냐"가 되어야 한다. 다른 모델에게 검증을 맡기는 건 충분하지 않다. 클로드가 버그를 찾고 다른 모델이 동의해도, 동의는 증거가 아니다. 검증은 모델의 의견에 무관한 것을 통해서만 성립한다.
- 코드를 실행해서 행동을 재현한다
- 주장된 이유로 실패하는 테스트를 작성한다
- 실제 설정, 의존성 버전, Git 히스토리를 직접 확인한다
재현이 어려운 경우도 있다. 아키텍처 버그, 동시성 이슈는 부분적으로만 검증할 수 있거나, 재현에 확인 불가능한 전제가 필요할 수 있다. 그 경우 "검증 불가"는 유효한 결론이다. 모델이 확신에 차 보인다는 이유로 미검증 클레임을 버그 목록에 올리는 것보다 훨씬 낫다.
정적 분석과 코딩 에이전트는 경쟁 관계가 아니다. 정적 도구는 이미 알고 있는 패턴을 정확하게 잡는다. 에이전트의 강점은 아무도 규칙을 작성하지 않은 것을 눈치채는 것이다. 낯선 리포지토리를 파고들어 이상한 질문을 들고 오게 하면 된다—그 다음에 그 질문이 버그 목록에 오를 자격을 증명하도록 요구하면 된다.
세 가지를 동시에 설계해야 하는 이유
이 세 가지 설계는 각각 독립적으로도 의미가 있다. 하지만 맥락 부패라는 문제의 관점에서 보면 하나의 방어선이다. 프로젝트 디스틸레이션은 코드베이스 수준의 맥락 오염을 막는다. 프롬프트 린팅은 파이프라인 수준의 입력 품질을 통제한다. 에이전트 검증은 출력 수준의 진실성을 요구한다.
에이전트가 코드를 빠르게 뽑을수록 잘못된 가정도 빠르게 확산된다. AI가 코드 생성 비용을 낮춘다는 건 삭제의 중요성이 그만큼 높아진다는 뜻이기도 하다. 맥락을 쌓는 것보다 무엇을 맥락에서 제거할지 결정하는 일이 점점 더 핵심 엔지니어링 역량이 되고 있다. 팀 리빌딩을 설계하는 입장에서 보면, 이 능력—디스틸레이션, 린팅, 검증—은 이제 채용 기준 목록에 올라가야 할 항목이다.