Claude Code Harness와 더 긴 에이전트 작업의 비용

Karpathy가 Claude Code Harness에 관한 긴 글을 공유한 것은 작지만 큰 함의를 지닌 신호처럼 느껴졌습니다. AI 코딩의 무게 중심이 영리한 프롬프트 (Prompts)에서 실행 시스템 (Execution systems)으로 이동하고 있습니다. 프롬프트는 모델에게 도움을 요청하는 것이지만, 하네스 (Harness)는 모델에게 작업 공간, 메모리 흔적 (Memory trail), 도구 (Tools), 체크포인트 (Checkpoints), 그리고 작업이 단일 대화보다 커졌을 때 지속할 수 있는 리듬을 제공합니다.

이러한 변화는 왜 하네스 방식이 매우 매력적으로 변하고 있는지, 그리고 왜 그것이 또 다른 토큰 집약적인 기계처럼 보일 수 있는지를 설명해 줍니다. 우리가 에이전트 (Agents)에게 더 많은 책임을 맡길수록, 에이전트가 읽고, 보존하고, 비교하고, 검증하고, 정리해야 할 컨텍스트 (Context)가 더 많이 필요하기 때문입니다. 꿈은 자율적인 진보입니다. 하지만 그 비용은 계획 토큰 (Planning tokens), 도구 출력 토큰 (Tool output tokens), 핸드오프 토큰 (Handoff tokens), 검증 토큰 (Verification tokens), 그리고 정리 토큰 (Cleanup tokens)을 통해 청구됩니다.

이 리포스트가 중요했던 이유

Karpathy는 빌더 (Builders)들의 행동 방식을 바꾸는 아이디어들을 걸러주는 유용한 필터가 되었습니다. 그가 Claude Code Harness 논의에 주목한 것은 실질적인 진실을 가리켰기 때문에 중요했습니다. 에이전트 성능의 다음 도약은 모델 자체뿐만 아니라 모델을 둘러싼 프레임워크 (Frame)로부터도 올 수 있습니다.

Claude Code는 이미 이 프레임워크가 왜 중요한지를 보여줍니다. Anthropic은 이를 코드베이스 (Codebase)를 읽고, 파일을 편집하며, 테스트를 실행하고, 커밋된 코드 (Committed code)를 전달할 수 있는 시스템이라고 설명합니다. 이는 채팅 답변과는 매우 다른 경험입니다. 모델은 여전히 중심에 있지만, 주변의 워크플로우 (Workflow)가 모델이 무엇을 보는지, 어떤 도구에 접근할 수 있는지, 언제 멈춰야 하는지, 어떻게 진행 상황을 기록하는지, 그리고 작업이 완료되었음을 어떻게 증명하는지를 결정합니다.

긴 하네스 에세이들은 동일한 점을 날카롭게 지적합니다. 장시간 실행되는 에이전트들은 익숙한 방식으로 실패합니다. 충분한 컨텍스트를 수집하기 전에 시작합니다. 계획에서 벗어납니다. 컨텍스트 윈도우 (Context window)가 채워짐에 따라 불안정해집니다. 작업을 축소함으로써 복잡한 작업을 피합니다. 약한 체크 (Checks)를 작성하고 너무 일찍 성공을 선언합니다. 오래된 문서와 모순된 상태를 남깁니다. 하네스는 이러한 실패들을 무시하기 어렵게 만들기 위해 존재합니다.

작업 생성 실행 프레임 (The task generated execution frame)

가장 흥미로운 아이디어는 하네스 (Harness)가 작업 (Task)을 중심으로 생성되어야 한다는 점입니다. 작은 버그 수정, 연구 종합, 풀스택 앱, 그리고 과학적 워크플로우 (Scientific workflow)는 동일한 운영 패턴을 공유해서는 안 됩니다. 각 작업은 자신만의 실행 프레임 (Execution frame)을 가질 자격이 있습니다.

코딩 작업의 경우, 해당 프레임은 기능 목록, 진행 파일, 초기화 스크립트 (Init script), 그리고 각 세션이 한 번에 하나의 기능에만 집중하도록 하는 규칙을 생성할 수 있습니다. 디자인 작업의 경우, 플래너 (Planner), 생성기 (Generator), 그리고 평가기 (Evaluator)를 생성할 수 있습니다. 연구 작업의 경우, 소스 맵 (Source map), 주장 테이블 (Claims table), 그리고 최종 모순 검사 (Contradiction check)를 생성할 수 있습니다. 사용자는 목표를 설명합니다. 에이전트 (Agent)는 먼저 작업의 정직함을 유지할 수 있는 스캐폴딩 (Scaffolding)을 구축합니다.

이것이 바로 이 방식이 강력하게 느껴지는 이유입니다. 모호한 요청을 구체적인 운영 환경으로 전환하기 때문입니다. 작업은 분해됩니다. 미지의 요소들은 명명됩니다. 중단 조건 (Stop conditions)은 기록됩니다. 검증 (Verification)은 생성 (Generation)과 분리됩니다. 새로운 컨텍스트 (Context)는 이전 경로에 대한 집착 없이 결과를 검토할 수 있습니다. 에이전트의 작업은 인간이 검사할 수 있는 아티팩트 (Artifacts)를 남기기 때문에 감독하기가 더 쉬워집니다.

비용 또한 명확합니다. 모든 아티팩트는 토큰 (Tokens)을 소비합니다. 모든 검토 단계는 토큰을 소비합니다. 모든 인수인계 요약은 토큰을 소비합니다. 취약한 하네스는 형식적인 절차를 추가함으로써 토큰을 낭비합니다. 좋은 하네스는 값비싼 실패를 방지하기 위해 토큰을 사용합니다.

토큰 경제학 (The token economics)

진정한 질문은 하네스가 많은 토큰을 소비하느냐가 아닙니다. 소비합니다. 진짜 질문은 추가적인 토큰이 신뢰성, 속도, 그리고 더 적은 인간의 개입을 보장하느냐 하는 것입니다.

가공되지 않은 모델 (Bare model)은 특히 작업이 작을 때 빠르고 저렴하게 답변할 수 있습니다. 하지만 작업이 많은 파일, 많은 세션, 그리고 많은 결정에 걸쳐 확장됨에 따라, 저렴한 상호작용은 종종 값비싼 재작업 (Rework)으로 이어집니다. 하네스는 프로젝트가 나중에 숨겨진 실수로 인해 대가를 치르지 않도록 초기에 더 많은 비용을 지불합니다.

이러한 현상은 에이전트 워크플로 (agent workflows)에서 이미 나타나고 있습니다. 저장소를 읽는 것은 토큰 (tokens)을 소모하지만, 컨텍스트 (context)를 건너뛰면 잘못된 계획을 세우게 됩니다. 진행 상황 파일 (progress file)을 작성하는 것은 토큰을 소모하지만, 상태 (state)를 놓치면 다음 세션에서 프로젝트를 다시 파악해야 하는 상황이 발생합니다. 별도의 검증기 (verifier)를 실행하는 것은 토큰을 소모하지만, 동일한 에이전트가 자신의 작업에 점수를 매기게 두면 느슨한 테스트 (soft tests)를 유도하게 됩니다. 정리 (Cleanup) 작업은 토큰을 소모하지만, 엔트로피 (entropy)는 다음 작업을 더 어렵게 만듭니다.

하네스 (harness)가 규율 없이 확장될 때 '토큰 먹는 하마 (token guzzler)'라는 표현은 타당합니다. 하지만 하네스가 인간의 조정 (coordination), 프로젝트 관리 (project management), 테스트 설계 (test design), 그리고 코드 리뷰 (code review)를 대체하고 있는 상황이라면 그 표현은 덜 타당해집니다. 실질적인 측정 기준은 '토큰당 결과물 (outcome per token)'입니다. 만약 하네스가 10배 더 많은 컨텍스트를 소모하여 심각한 오답 (false completion) 하나를 방지할 수 있다면, 그것은 저렴한 비용일 수 있습니다. 반면, 최종 결과물은 여전히 취약한데 아름다운 프로세스 기록만 만들어낸다면, 그것은 계량기가 달린 소음 (noise)에 불과합니다.

빌더들을 위한 유용한 패턴

가장 좋은 하네스 패턴은 압축적이고 작업 인지적 (task aware)인 것입니다. 첫째, 컨텍스트 입력 (context intake)을 강제하십시오. 에이전트는 계획을 세우기 전에 중요한 파일, 소스, 제약 조건 (constraints), 그리고 미지의 요소 (unknowns)를 식별해야 합니다. 둘째, 가시적인 작업 원장 (task ledger)을 만드십시오. 원장에는 무엇을 시도했는지, 무엇이 통과되었는지, 무엇이 실패했는지, 그리고 무엇이 남아 있는지를 보여주어야 합니다. 셋째, 검증 (verification)을 독립적으로 유지하십시오. 검사기 (checker)는 테스트하기 가장 쉬운 동작이 아니라, 요청된 동작을 평가해야 합니다. 넷째, 진행 후에는 작업 공간 (workspace)을 정리하십시오. 문서화 (documentation), 데드 코드 (dead code), 그리고 오래된 가정 (stale assumptions)은 작업 표면 (task surface)의 일부입니다. 다섯째, 중단 규칙 (stop rules)과 함께 토큰 예산 (token budget)을 설정하십시오. 자율성 (Autonomy)은 언제 계속하고 언제 물어봐야 할지를 알 때 더 잘 작동합니다.

이러한 패턴은 코드 이외의 영역에서도 중요합니다. 연구자는 Miss Formula를 사용하여 수식 이미지를 사용 가능한 수학적 표기법으로 변환하고, ChatGPT나 Gemini에게 해석을 비교하도록 요청한 다음, Editable Figure를 사용하여 AI가 생성한 논문 그림을 편집 가능한 벡터 형식으로 바꿀 수 있습니다. 동일한 하네스 (harness) 로직이 적용됩니다. 입력을 캡처하고, 주장 경로 (claim trail)를 보존하며, 출력을 검증하고, 최종 결과물 (artifact)을 편집 가능한 상태로 유지하십시오.

더 큰 의미

하네스에 관한 논의는 사실 신뢰 (trust)에 관한 것입니다. 사람들은 단순히 자신감 있게 들리기만 하는 에이전트를 원하지 않습니다. 그들은 방향성을 유지하고, 제약 조건 (constraints)을 준수하며, 자신의 상태 (state)를 드러내고, 실수로부터 회복할 수 있는 에이전트를 원합니다. 작업 생성 실행 프레임 (task generated execution frame)은 그러한 요구에 대한 하나의 해답입니다.

이는 토큰을 소비할 것입니다. 또한 토큰을 소비해야만 합니다. 긴 작업에는 메모리 (memory), 점검 (checks), 그리고 조정 (coordination)이 필요합니다. 중요한 것은 그 토큰들을 레버리지 (leverage)를 창출하는 곳에 사용하는 것입니다. Karpathy가 Claude Code Harness 논의를 공유한 것은 하나의 간단한 교훈에 주목하게 했습니다. AI 작업의 미래는 모델, 도구, 그리고 이들을 연결하는 규율 있는 운영 체제 (operating system)에 의해 형성될 것입니다.