AI 지원 프로젝트에서는 레포지토리(repo)가 너무 커서 붙여넣을 수 없는 순간이 찾아옵니다. 대부분의 사람들은 더 많이 붙여넣음으로써 이 문제를 해결합니다. '컨텍스트 윈도우(context window)는 이제 엄청나게 크니까'라고 추론하며, README 파일, 라우터(router), 마이그레이션(migrations), 그리고 가장 최근 PR 두 개를 던져 넣습니다.
그러면 어시스턴트가 이미 확정된 아키텍처와 모순되는 코드를 자신감 있게 작성하고, 지난 스프린트에서 제거했던 엔드포인트(endpoint)를 다시 도입하며, 어느 마이그레이션에도 존재하지 않는 필드 이름을 지정합니다. 컨텍스트 크기가 커진 것이 도움이 되지 않았습니다. 단지 모델에게 잘못된 참조를 고를 수 있는 더 많은 공간을 제공했을 뿐입니다.
모델은 무엇을 무시해야 하는지 모른다
큰 컨텍스트 윈도우가 만능 해결책(harness)이 아닙니다. 그것은 모델이 놓치는 검색 문제입니다. 왜냐하면 한 번에 서른 개의 문서를 가중치로 계산해야 하고, 여러분의 README는 이미 3년이나 오래되었기 때문입니다. 실제 계약 내용이 생성된 OpenAPI 파일에 존재하지만, README에는 v1 수동 JSON 형태가 설명되어 있다면, 모델은 때때로 README를 읽게 됩니다.
모든 것을 덤프하는 것은 컨텍스트 엔지니어링의 게으른 버전일 뿐입니다. 이는 여러분의 작업을 토큰 예산(token budget)에 위임하는 것입니다.
답변을 실제로 결정하는 세 가지 슬라이스
충분한 세션이 지나고 나면, 결과물을 바꾸는 문서 집합은 작다는 것을 알게 됩니다:
1. 방금 작업하던 것. 열려 있는 파일들, 마지막으로 실패한 테스트(test), 오류 추적(error trace)입니다. 모델은 세션 간에 기억이 없으며, 이것이 사람들이 빠뜨리는 부분입니다. 이것이 없다면, 어시스턴트는 레포지토리를 다시 요약하고 여러분이 한 시간 전에 내린 결정을 조용히 되돌립니다.
2. 기계가 읽을 수 있는 형태의 강력한 제약 조건(hard constraint). 어시스턴트가 계속 잘못하는 것은 보통 텍스트로 어디에도 존재하지 않는 규칙입니다. 필드 이름, 필수 여부 대 선택적 여부, 상태 코드(status code), 속도 제한(rate limit) 등은 산문 설명이 아니라 계약서에 존재합니다. 어시스턴트를 그 계약서가 있는 곳으로 안내하는 것이 그것에 대해 작성하는 어떤 단락보다 효과적입니다. 우리는 결국 마지막으로 실제 엔드포인트와 재실행했던 로컬 OpenAPI 파일을 유지했고, 어시스턴트가 임의로 생성하던 엔드포인트 비율이 급격히 떨어졌습니다. 인간이 작성한 단락으로는 결코 그 무게를 지탱할 수 없었을 것입니다.
3. 넘지 말아야 할 경계. 어떤 파일을 건드리지 말아야 하는지, 어떤 서비스가 공유되는지, 어떤 마이그레이션(migration)이 이미 적용되었는지 한 문장으로 명시하는 것이다. "조심하세요"와 같은 모호한 글은 아무 효과가 없다. 구체적인 금지는 그 대상을 명명한다.
나머지는 모두 노이즈(noise)이다
README, 아키텍처 문서(architecture doc), 설계 결정 목록 등은 인간을 위한 것이다. 하지만 이들은 또한 부패하기 쉬운 결과물이기도 하다. 모델이 구식의 마크다운 파일과 실시간으로 읽을 수 있는 기계가 판독 가능한 결과물 사이에서 선택해야 할 때, 실제로 이를 제시한다면 살아있는(live) 쪽이 승리한다.
실제 관점에서 볼 때, 컨텍스트 엔지니어링(Context engineering)은 완전성의 반대 개념이다. 그것은 현실과의 접촉을 견디는 몇 안 되는 참조 자료를 선택하고 나머지는 의도적으로 제외하는 것이다. 오래된 요약으로 가득 찬 20만 토큰 창은 세션이 실제로 의존하는 파일들로 구축된 2만 토큰 창보다 더 나쁜 비서가 된다.
모델이 결코 알아차리지 못하는 세 가지는 무엇인가? 그 간극이야말로 아마도 만들어낸 엔드포인트(endpoints)가 나오는 곳일 것이다.