맥락 다듬기
출처: Hacker News
2026년 6월 5일
몇 달 전, 저는 Viv (@Vtrivedy10)의 “The Anatomy of an Agent Harness”(링크)를 읽고 있었습니다. 이 글은 하네스가 무엇이며 왜 중요한지, 그리고 하네스를 구성하는 요소들이 무엇인지에 대해 깊이 있게 파고듭니다.
어느 정도는, 소프트웨어 개발자가 되면 언제나 최신 동향을 따라가야 한다는 점과, 지난 1년 정도에 등장한 이 “하네스” 개념에 대한 아주 좋은 개요를 제공한다는 점이 맞물렸습니다.
글을 읽던 중, 한 가지 비전이 떠올랐습니다: 컨텍스트 윈도우를 불변의, 추가만 가능한 대화 로그로 취급하는 대신, 모델이 직접 컨텍스트 윈도우를 검사하고 수정하도록 하면 어떨까?
ChatGPT가 출시된 이후, 컨텍스트 윈도우를 “추가 전용 대화 기록”으로 보는 사고방식이 얼마나 깊게 자리 잡았는지 깨달았습니다. 이제 거의 모든 개발자는 시스템 프롬프트, 사용자 메시지, 그리고 점점 늘어나는 사용자 메시지, 어시스턴트 메시지, 도구 호출 및 도구 호출 결과의 리스트라는 정신 모델을 가지고 있습니다.
하지만 그 가정을 버린다면 어떨까요? 모델 자체가 컨텍스트 윈도우를 가변적으로 만들 수 있다면?
생각이 더해질수록 머리가 빙빙 돌았습니다. 모델이 잘못된 길로 가고 있거나, 바퀴가 빙빙 도는 상황을 스스로 인식할 수 있다면? 컨텍스트 윈도우를 스스로 관리해서, 이른 시점의 히스토리를 “자동 압축”해 컨텍스트 윈도우가 고갈되는 것을 방지하거나 최소한 지연시킬 수 있다면? 또 무엇을 할 수 있을지, 혹은 실제로 모델이 할 수 있을지 궁금했습니다.
하지만 생각할수록 불확실해졌습니다. 모델이 방금 전 몇 초 전에 만든 응답에 문제가 있는지를 스스로 파악할 수 있을까요?
처음엔 모델에게 컨텍스트 윈도우에 대한 전체 편집 권한을 주면, 잘못된 경로를 피하거나 루프에 빠지는 것을 방지하고, 더 이상 관련 없는 이전 섹션을 삭제함으로써 효율이 높아질 것이라고 생각했습니다. 하지만 곧 불안감이 들었습니다. 실제로 작동하게 하려면 기존 컨텍스트 윈도우를 감싸는 추가적인 설명을 모델에게 계속 제공해야 할지도 모른다는 생각이 듭니다. 이런 아이디어를 실현하려면 모델이 사전에 이런 방식으로 훈련돼야 할지도 궁금했습니다.
Claude와 함께 아이디어를 탐색하면서, 큰 모델이 작은 모델의 컨텍스트 윈도우를 관찰하고 편집하는 접근법에 합의했습니다. Claude는 이 아이디어를 부를 몇 가지 이름을 제시했는데, 저는 “context sculpting”이라는 이름에 끌렸습니다. 아이디어의 핵심적인 느낌을 잘 담고 있었습니다.
잠깐 이야기: 이 아이디어를 가지고 놀던 지 일주일 정도 뒤, Anthropic이 “advisor strategy”에 대해 포스팅한 것을 보았습니다. “Opus를 어드바이저로, Sonnet이나 Haiku를 실행기로 짝지어, 비용은 적게 들면서도 Opus 수준의 지능을 에이전트에 제공한다”는 내용이었습니다. 그래서 제 “context sculpting” 아이디어가 완전히 미친 것이 아니라는 확신이 들었습니다.
출처: https://x.com/claudeai/status/2042308622181339453
또 다른 잠깐 이야기: Viv의 글을 읽던 시점에 저는 재귀 언어 모델(RLMs)(링크)에 대해 많이 생각하고 있었습니다. 그래서 이 점이 “context sculpting” 아이디어에 영향을 주었을 가능성이 있습니다.
이 아이디어가 실제로 가능한지 확인하고 싶었습니다. 처음엔 대단한 실험을 설계하고, 논문으로 정리해서 AI 연구자들로부터 찬사를 받겠다는 큰 꿈을 꾸었습니다. 하지만 곧 야망을 낮추고, 작은 “엔지니어링 사례 연구”—제가 “vibe research”(분위기 연구)라고 부르는—에 집중했습니다.
Claude와 함께 계획을 세우면서, 제 “vibe research”가 다루고자 했던 핵심 질문은 다음과 같습니다.
하나의 모델에게 다른 모델의 작업 중인 컨텍스트를 턴 사이에 다시 쓰는 권한을 주면 어떤 일이 일어날까?
저는 Pi agent harness 프레임워크(GitHub)를 사용해 맞춤형 하네스를 만들자고 제안했습니다. Pi는 최소주의적이며 확장성이 뛰어나 이 아이디어를 구현하기 위한 모든 훅을 제공하므로 Claude도 동의했습니다.
우리는 더 능력 있는 모델을 “outer agent”(외부 에이전트), 더 작은 모델을 “inner agent”(내부 에이전트) 라고 부르기로 했습니다. Claude와 함께 견고한 계획을 잡은 뒤, 실제 구현과 실험 실행은 Codex로 옮겼습니다.
Codex는 블로그 포스트 초안을 작성하기도 했습니다. 여기서는 제 글이 아니라 Codex가 쓴 부분을 섞어 보이겠습니다. 예를 들어 프로젝트 아키텍처에 대한 섹션은 다음과 같습니다.
하네스는 간단한 2계층 루프이다
- inner agent가 실제 작업을 수행한다.
- inner turn이 완료될 때마다 outer agent가 전체 inner context를 검사한다.
outer agent는 네 가지 행동 중 하나를 선택한다.
pass_throughrewrite_contextrollbackterminate
고수준 흐름은 다음과 같다.
while run_is_active:
inner_agent.take_one_turn()
outer_agent.observe(full_inner_context)
decision = outer_agent.decide()
if decision == pass_through:
continue
if decision == rewrite_context:
replace inner context with rewritten version
if decision == rollback:
restore an earlier checkpoint
if decision == terminate:
stop이 프로토타입의 중요한 설계 선택은 다음과 같다.
- outer agent는 전체 inner context를 볼 수 있다.
- outer agent는 매 턴마다 개입할 기회를 가진다.
- inner agent는 스컬프팅이 일어나고 있다는 사실을 명시적으로 알지 못한다.
- 주요 개입 수단은 전체 컨텍스트 재작성이며, 세밀한 패치가 아니다.
우리는 이를 **“데모”**라 부르기로 했고, 정식 실험이라기보다는 **“데모 설정”**이라고 설명했다.
데모 목표는 논문 스타일의 실험을 수행하는 것이 아니라, 하네스가 엔지니어링 패턴으로서 컨텍스트 스컬프팅을 신뢰할 수 있고 검증 가능한 시연을 제공할 수 있는지를 테스트하는 것이었다.
데모는 두 가지 작은 작업을 사용했다.
-
코딩 수리 작업
- 에이전트는
node verify.mjs가 통과하도록 아주 작은 파일 기반 작업 관리자 CLI를 고쳐야 한다. - 워크스페이스에는 의도적으로 오래된 레거시 노트가 방해 요소로 포함되어 있다.
- 검증은 객관적이다: 다섯 개 테스트 모두 통과해야 한다.
- 에이전트는
-
로컬 코퍼스 합성 작업
- 에이전트는 작은
docs/코퍼스만을 사용해 질문에 답하고, 고정된 구조의answer/final_answer.md파일을 작성한다. - 코퍼스에는 방해 문서가 포함되어 있다.
- 검증은 정확한 출력 파일 형태와 기대되는 증거 체인을 확인한다.
- 에이전트는 작은
각 작업마다 inner_only 실행 두 번, outer_harness 실행 두 번을 진행했다.
결과
솔직히 말하면, 결과는 흥미로웠다. Codex는 gpt-5.4-mini를 inner agent 모델로, gpt-5.4를 outer agent 모델로 사용해 데모를 실행했다. 먼저 베이스라인으로 inner agent만 사용한 코딩 수리 작업 두 번, 합성 작업 두 번을 실행했다. 그 다음 outer agent + inner agent 하네스를 사용해 코딩 수리 작업 두 번, 합성 작업 두 번을 실행했다. 총 8번 실행. 가드레일은 inner agent 턴 수 상한과 예상 API 비용 상한을 설정했다.
요약
- 8/8 실행이 성공적으로 완료
- 8/8 검증 단계 통과
- 가드레일 트리거 0회
- 총 예상 API 비용