3.8점진적 발견과 단일 컨텍스트

단일 컨텍스트(monolithic context) 전략은 작업에 필요할 만한 것을 처음부터 전부 컨텍스트에 넣습니다. 지침, 참조 문서, 툴 정의, 예시가 모두 앞에 놓입니다.

점진적 발견(progressive discovery) 전략은 최소한만 넣고, 모델이 필요를 느끼면 그때 가져오게 합니다. 요약이나 목차만 두고 본문은 툴로 읽게 하거나, 툴 정의를 지연 로딩으로 두거나, 스킬의 설명만 상주시키고 본문은 필요할 때 읽게 하는 방식입니다.

축	단일 컨텍스트	점진적 발견
왕복 수	적음	많음
첫 응답까지의 시간	짧음	길어질 수 있음
요청당 고정 토큰	큼	작음
캐시 적합성	높음 (프리픽스가 안정적)	중간
넓은 자료 대응	컨텍스트 한계에 막힘	확장 가능
관련 없는 정보의 방해	큼	작음

마지막 줄이 자주 간과되는 지점입니다. 컨텍스트에 많이 넣으면 안전할 것 같지만, 관련 없는 내용이 많으면 모델이 흐트러집니다. 넣는 것에도 비용이 있고 그 비용은 토큰만이 아닙니다.

동시에 점진적 발견이 항상 싸지도 않습니다. 결국 다 읽게 될 자료를 한 조각씩 가져오면, 왕복마다 이전 내용이 컨텍스트에 누적된 상태로 요청이 나가므로 총 토큰이 오히려 늘어날 수 있습니다.

두 전략 중 무엇이 이기는지는 두 값으로 결정됩니다. 자료의 크기와 실제로 쓰이는 비율입니다.

        사용 비율 높음        사용 비율 낮음
크기   ┌─────────────────┬─────────────────┐
작음   │ 단일 컨텍스트    │ 단일 컨텍스트    │
       │ (그냥 다 넣는다) │ (넣어도 싸다)    │
       ├─────────────────┼─────────────────┤
크음   │ 단일 컨텍스트    │ 점진적 발견      │
       │ (어차피 다 쓴다) │ (여기가 핵심)    │
       └─────────────────┴─────────────────┘

점진적 발견이 확실히 이기는 칸은 자료가 크고 실제로는 일부만 쓰이는 경우 하나뿐입니다. 나머지 세 칸에서는 단순한 쪽이 낫습니다.

이 구도를 실제 상황에 대입하면 판단이 분명해집니다.

상황	크기	사용 비율	결론
시스템 지침	작음	항상	단일
자주 쓰는 툴 5개	작음	높음	단일
사내 시스템 툴 40개	큼	요청당 2~3개	점진적
제품 매뉴얼 전체	큼	질문마다 일부	점진적
이번 작업 대상 파일	중간	전부	단일
회사 전체 코드베이스	매우 큼	극히 일부	점진적

여기서 놓치기 쉬운 것이 캐싱이 이 계산을 바꾼다는 점입니다. 큰 자료라도 프리픽스에 안정적으로 놓여 캐시에 걸리면 반복 요청의 비용이 크게 떨어집니다. 같은 자료를 여러 요청에서 계속 쓴다면, 캐시된 단일 컨텍스트가 매번 가져오는 점진적 발견보다 저렴할 수 있습니다.

반대로 요청마다 필요한 조각이 다르면 캐시 이득이 없으므로 점진적 발견이 유리합니다.

점진적 발견은 하나의 기법이 아니라 여러 층에서 같은 원리를 적용하는 것입니다.

툴 층 — 툴 정의에 지연 로딩을 걸고 검색으로 발견하게 합니다. 3.1에서 다룬 방식입니다. 이 층의 이점 하나는 발견된 툴이 기존 목록 뒤에 덧붙어 캐시가 보존된다는 것입니다.

지식 층 — 스킬처럼 설명만 상주시키고 본문은 필요할 때 읽게 합니다. 설명은 짧으므로 상주 비용이 낮고, 모델은 작업이 그 설명과 맞을 때만 본문을 읽습니다.

데이터 층 — 문서 전체 대신 목차나 요약을 넣고 본문은 툴로 읽게 합니다. RAG도 이 층의 한 형태입니다 — 자료 전체를 넣는 대신 질의에 맞는 조각만 가져옵니다.

작업 층 — 서브에이전트에 위임해 상세한 읽기를 다른 컨텍스트에서 하게 합니다. 3.7에서 다룬 위임의 이점 중 하나가 정확히 이것입니다.

동일한 원리, 다른 층
  툴:    전체 스키마 상주  →  설명 검색 후 로드
  지식:  전체 문서 상주    →  요약 상주 + 본문 읽기
  데이터: 자료 전체 삽입    →  질의별 조각 검색
  작업:  직접 다 읽기      →  위임하고 보고만 받기

층을 섞어 쓰는 것이 보통입니다. 다만 층마다 왕복이 붙으므로, 전부 점진적으로 만들면 간단한 요청도 여러 번 왕복하게 됩니다. 가장 큰 것부터 하나씩 옮기는 것이 원칙입니다.

점진적 발견은 세션이 길어지면 성격이 바뀝니다. 가져온 것이 컨텍스트에 누적되기 때문입니다.

10번의 왕복으로 조각을 10개 가져왔다면, 마지막 요청의 컨텍스트에는 그 10개가 모두 들어 있습니다. 처음부터 다 넣은 것과 같은 상태가 되고, 왕복 비용만 추가로 치른 셈입니다.

따라서 긴 세션에서는 정리 전략이 함께 필요합니다.

전략	무엇을 하는가	언제
컨텍스트 편집	오래된 툴 결과나 사고 블록을 제거	지난 결과가 더 이상 필요 없을 때
압축	앞부분 이력을 요약으로 대체	컨텍스트 한계에 접근할 때
외부 메모	알아낸 것을 파일에 적고 컨텍스트에서 비움	나중에 다시 필요할 수 있을 때

편집과 압축은 다른 동작입니다. 편집은 지우고 압축은 요약합니다. 지운 것은 복구되지 않으므로, 다시 필요해질 가능성이 있으면 압축이나 외부 메모가 맞습니다.

외부 메모는 긴 작업에서 특히 효과가 큽니다. 모델이 알아낸 것을 파일에 적어두면 컨텍스트에서는 비워도 되고, 나중에 필요하면 다시 읽습니다. 세션을 넘어서도 남는다는 이점도 있습니다.

주의할 것은 3.4에서 다룬 관측성과의 연결입니다. 편집이나 압축이 일어났다는 사실을 기록하지 않으면 나중에 그 세션을 재구성할 수 없습니다. 모델이 실제로 본 것이 이력과 다르기 때문입니다.

마지막으로, 점진적 발견을 쓰더라도 모델이 무엇을 가져올 수 있는지는 알아야 합니다. 목차도 없이 "필요하면 찾아봐"라고만 하면 모델은 무엇이 있는지 몰라 찾지 않습니다. 발견 가능한 것들의 목록이나 요약은 상주시켜야 하고, 이것이 점진적 발견에서 상주 비용이 완전히 0이 되지 않는 이유입니다.