여러 coding agent를 써보면 각 도구의 장점이 다르다. 어떤 모델은 코드 탐색이 빠르고, 어떤 모델은 긴 작업을 잘 이어가고, 어떤 도구는 GitHub나 로컬 환경과 연결하기 편하다.
문제는 도구를 바꿀 때마다 프로젝트를 처음부터 설명해야 한다는 점이었다.
채팅 기록은 다른 도구로 옮기기 어렵다
한 agent와 오래 작업할수록 중요한 맥락이 대화 안에 쌓인다.
- 왜 이 구조를 선택했는지
- 이전 방식이 왜 실패했는지
- 어떤 파일은 건드리면 안 되는지
- 사용자에게 이미 공개된 동작은 무엇인지
- 다음 작업 전에 확인해야 하는 것이 무엇인지
새 agent는 이 대화를 모른다. 그래서 “우리 프로젝트는 이런 서비스고…”부터 다시 설명하게 된다.
이 과정에서 사람도 중요한 내용을 빼먹는다.
저장소 안에 컨텍스트를 남기기 시작했다
도구 독립적으로 유지할 수 있는 장소는 결국 프로젝트 저장소였다.
코드 외에도 다음 정보를 저장소에 두었다.
- 현재 기능 구조
- 큰 작업의 Task MD
- 작업 인덱스
- 실행·테스트 방법
- 환경별 주의사항
- 변경 금지 영역
- 완료된 결정과 아직 열린 결정
이렇게 하면 특정 agent의 메모리나 채팅 기록에 프로젝트가 종속되지 않는다.
agent에게 전체 문서를 매번 다 주지는 않았다
문서를 저장소에 둔다고 해서 모든 작업마다 전체 문서를 프롬프트에 붙이는 것도 비효율적이었다.
먼저 task를 해석하는 단계에서 관련 파일과 필요한 컨텍스트를 좁히고, 실제 worker에게는 이번 작업에 필요한 packet만 넘기는 방식이 더 안정적이었다.
중요한 건 원본을 한 곳에 두되, 실행 단계에서는 필요한 만큼만 전달하는 것이다.
현재 코드가 항상 마지막 사실이다
문서도 코드와 어긋날 수 있다.
그래서 agent를 바꿀 때는 문서만 믿지 않고 실제 저장소를 함께 읽게 한다. 문서는 의도와 경계를 설명하고, 코드는 현재 구현 상태를 보여준다.
둘이 다르면 바로 구현하지 않고 먼저 차이를 확인한다.
이 원칙 덕분에 “문서상으로는 이미 구현됐는데 실제 코드는 없다”거나 반대 상황을 빨리 찾을 수 있었다.
도구 선택보다 handoff 형식이 중요해졌다
처음에는 어떤 coding agent가 제일 좋은지에 관심이 많았다. 하지만 프로젝트가 길어지니 다른 문제가 더 크게 보였다.
좋은 모델을 써도 컨텍스트 전달이 매번 흔들리면 결과가 불안정하다. 반대로 적당한 모델이라도 작업 범위와 현재 상태가 잘 전달되면 훨씬 예측 가능한 결과가 나온다.
그래서 장기 프로젝트에서는 “어떤 AI를 쓰느냐”보다 AI가 바뀌어도 같은 프로젝트를 이어갈 수 있는 handoff 구조가 있는가가 더 중요해졌다.