20만 토큰이면 충분하고도 남습니다! @AmpCode 블로그는 Claude Opus 4.5 모델의 "단지"인 20만 토큰 컨텍스트 윈도우에 대한 직관에 반하는 통찰력 있는 관점을 제시합니다. 이 팀은 고품질 코딩과 작업 실행을 위해서는 20만 토큰이 충분할 뿐만 아니라, 지나치게 긴 컨텍스트보다 오히려 더 나은 경우가 많다고 주장합니다. '취함' 이론: 맥락이 많다고 항상 좋은 것은 아니다. 저자는 생생한 비유를 제시한다. "에이전트에게 너무 많은 토큰을 주면 마치 '취한' 것처럼 행동한다." • 신호 대 잡음비 문제: 지나치게 긴 대화 기록은 현재의 작은 작업과 관련 없는 많은 정보를 채워 모델의 주의력을 분산시키고 오류 및 환각을 유발할 수 있습니다. • 성능 저하: 에이전트가 최상의 성능을 발휘하도록 하려면 "현재 작업을 완료하는 데 필요한 컨텍스트만 제공하고 그 이상은 제공하지 않는 것"이 핵심입니다. "짧은 스레드" 워크플로 철학의 창시자들은 수백만 개의 토큰을 사용하는 지나치게 긴 대화에 모든 작업을 몰아넣는 것에 반대하며, 대신 짧은 스레드들을 서로 연결한 클러스터를 사용할 것을 주장합니다. • 작업 분해: 복잡한 개발 기능은 여러 개의 개별적인 작은 작업으로 분해해야 합니다. • 스레드는 작업입니다. 각 스레드는 작은 작업에 해당합니다. 예를 들어, 한 스레드는 기본 구현을 담당하고, 다른 스레드는 리팩토링을 담당하며, 또 다른 스레드는 코드 검토 또는 테스트 스크립트 작성을 담당합니다. • 컨텍스트 전달: 지속적으로 히스토리를 축적하는 대신 참조 또는 도구를 통해 스레드 간에 필요한 컨텍스트를 전달합니다. 비용 및 효율성 고려 사항: 경제적 효율성: 긴 대화는 요청마다 많은 토큰을 전송해야 할 뿐만 아니라 캐시 창을 놓치기 쉽게 만들어 비용을 더욱 증가시킵니다. • 제어 용이성: 짧은 스레드는 관리 및 추적이 더 쉽고, 각 상호 작용에는 명확한 목표가 있습니다. 이러한 작업 방식은 "큰 작업을 작은 작업으로 나누는" 고전적인 엔지니어링 원칙으로 돌아갑니다. 이 글은 본질적으로 AI 상호작용의 패러다임 전환을 주장하며, "획일적인 접근 방식"에서 "정교한 관리"로의 전환을 촉구합니다. 저자는 무한히 긴 컨텍스트 창으로 혼돈을 억제하려 하기보다는, 우수한 엔지니어링 관행을 통해 복잡한 문제를 여러 개의 간결하고 효율적인 20만 단위 컨텍스트로 나누는 것이 더 낫다고 주장합니다. 다시 말해, 20만 개 제한은 결함이 아니라 사용자가 작업을 제대로 세분화하도록 강제하는 "기능"입니다. 블로그 주소
