1M context 숫자보다 중요한 것, agent가 멍해지는 구간

큰 context window는 agent 시대의 가장 그럴듯한 숫자다. 200K, 1M, 2M 토큰은 긴 코드베이스와 긴 대화를 한 번에 품을 수 있을 것처럼 보인다. 하지만 Garrit Franke의 글이 HN에서 주목받은 이유는 그 숫자가 실제 작업 가능 영역과 다르다는 경험을 정확히 짚었기 때문이다.

글은 context window 안에도 “smart zone”과 “dumb zone”이 있다고 설명한다. 앞부분에서는 모델이 비교적 선명하게 지시와 세부사항을 붙잡지만, 일정 지점을 넘으면 attention이 흐려지고 방금 받은 조건도 놓치기 시작한다는 관찰이다. 작성자는 그 경계가 광고된 최대치가 아니라 대략 100K 토큰 안팎에서 체감된다고 말한다.

코딩 agent에서는 이 문제가 빨리 온다. 몇 번의 파일 읽기, 긴 디버깅 로그, 테스트 출력, 반복된 수정 지시가 쌓이면 세션은 금세 무거워진다. 자동 요약이나 compaction은 도움이 되지만, 이미 품질이 떨어진 상태에서 만든 요약이라면 중요한 판단을 놓칠 수 있다.

대안은 context를 무작정 키우는 것이 아니라 작업 단위를 더 작고 명확한 artifact로 나누는 쪽이다. 직접 쓴 spec, plan, handoff note는 모델이 만든 긴 대화 요약보다 신호가 높다. 다음 세션이나 다음 사람이 바로 이어받을 수 있는 작은 문서가 context budget을 아껴 준다.

HN 댓글의 논점도 비슷했다. 긴 창은 유용하지만, 실제 성능은 창의 크기보다 정보의 배치와 압축 품질에 좌우된다. agent workflow를 설계할 때 context window는 무한한 저장소가 아니라 비용이 있는 작업 메모리로 다루는 편이 낫다.

원문: Don’t trust large context windows. HN 토론: item 48524620.