Claude Code Harness와 긴 AI 작업의 비용

Karpathy가 Claude Code Harness에 관한 긴 글을 공유한 것은 작은 신호처럼 보이지만 큰 의미를 담고 있다. AI 코딩의 무게 중심이 기발한 프롬프트(Prompt)에서 실행 시스템(Execution System)으로 이동하고 있다. 프롬프트는 모델에게 도움을 요청한다. Harness는 모델에게 작업 공간, 기억의 흔적, 도구(Tool), 확인 지점, 그리고 하나의 대화를 넘어 작업을 지속하기 위한 리듬을 부여한다.

이러한 변화는 harness 방식이 왜 매력적인지를 설명한다. 동시에 그것이 왜 또 하나의 토큰(Token) 소비 장치로 보이는지도 설명한다. 우리가 AI 에이전트(AI Agent)에게 더 많은 책임을 맡길수록, AI 에이전트는 더 많은 문맥(Context)을 읽고, 저장하고, 비교하고, 검증하고, 정리해야 한다. 꿈은 자율적인 전진이다. 청구서는 계획의 토큰, 도구 출력의 토큰, 인수인계의 토큰, 검증의 토큰, 정리의 토큰으로서 날아온다.

Karpathy는 제작자의 행동을 변화시키는 아이디어를 식별하는 유용한 신호가 된다. 그가 Claude Code Harness의 논의에 주목한 것이 중요한 이유는 그것이 실용적인 진실을 가리키고 있기 때문이다. AI 에이전트의 다음 성능 향상은 모델 자체뿐만 아니라, 모델을 둘러싼 프레임워크(Framework)로부터도 생겨날 수 있다.

Claude Code는 이 프레임워크가 왜 중요한지를 이미 보여주고 있다. Anthropic은 Claude Code를 코드베이스를 읽고, 파일을 변경하며, 테스트를 실행하고, 커밋된 코드를 전달하는 시스템으로 설명한다. 이는 채팅 답변과는 완전히 다른 경험이다. 모델이 중심에 있지만, 주변의 작업 절차가 모델이 무엇을 볼지, 어떤 도구를 사용할지, 언제 멈출지, 어떻게 진행 상황을 남길지, 어떻게 완료를 증명할지를 결정한다.

Harness에 관한 긴 글은 같은 점을 더욱 날카롭게 지적한다. 길게 이어지는 AI 에이전트의 작업은 흔히 발생하는 형태로 실패한다. 충분한 문맥을 수집하기 전에 시작한다. 계획에서 벗어난다. 문맥 창(Context Window)이 가득 차면 불안해한다. 복잡한 일을 작게 보이게 만들어 회피한다. 약한 검사를 작성하고 너무 빨리 성공을 선언한다. 오래된 문서와 모순된 상태를 남긴다. Harness는 이러한 실패를 간과하기 어렵게 만들기 위해 존재한다.

가장 흥미로운 생각은 harness가 태스크(Task)에 맞춰 제작되어야 한다는 점이다. 작은 버그 수정, 연구 요약, 풀스택 앱, 과학적 작업의 흐름을 동일한 운영 형식으로 다루기는 어렵다. 각각의 태스크에는 저마다의 실행 프레임이 필요하다.

코딩 태스크라면, 그 프레임은 기능 목록, 진행 파일, init 스크립트, 그리고 각 세션이 하나의 기능에만 집중하도록 하는 규칙을 만들 수 있다. 디자인 태스크라면 계획자, 생성자, 평가자를 둘 수 있다. 연구 태스크라면 출처 맵, 주장 표, 마지막 모순 확인 절차를 만들 수 있다. 사용자는 목표를 설명한다. AI 에이전트는 먼저 작업을 정직하게 유지하기 위한 발판을 만든다.

여기에 방식의 힘이 있다. 모호한 의뢰가 구체적인 작업 환경으로 변한다. 태스크는 분할된다. 미지의 지점에는 이름이 붙는다. 정지 조건은 기록으로 남는다. 검증은 생성으로부터 분리된다. 새로운 문맥을 가진 평가자는 이전의 진행 방식에 얽매이지 않는 상태에서 결과를 볼 수 있다. AI 에이전트의 작업이 인간이 점검할 수 있는 성과물을 남기기 때문에 감독도 쉬워진다.

비용 또한 명확하다. 모든 성과물은 토큰을 사용한다. 모든 평가 공정은 토큰을 사용한다. 모든 인수인계 요약은 토큰을 사용한다. 약한 harness는 절차를 위해 토큰을 낭비한다. 좋은 harness는 값비싼 실패를 방지하기 위해 토큰을 사용한다.

중요한 질문은 harness가 많은 토큰을 사용하는가 여부가 아니다. 사용한다. 중요한 질문은 추가적인 토큰이 신뢰성, 속도, 그리고 인간의 개입 감소를 사고 있는가 하는 점이다.

작은 작업에서는 모델만으로도 빠르고 저렴하게 답할 수 있다. 하지만 작업이 많은 파일, 많은 세션, 많은 판단으로 확장되면, 저렴한 대화는 종종 높은 재작업(Rework) 비용으로 변한다. Harness는 처음에 많이 사용함으로써, 나중에 숨겨진 오류의 대가를 치르지 않도록 한다.

이는 AI 에이전트의 작업 절차에서 이미 보이고 있다. 리포지토리(Repository)를 읽는 것은 토큰을 사용하지만, 문맥을 건너뛰면 잘못된 계획이 생긴다. 진행 파일은 토큰을 사용하지만, 상태를 잃으면 다음 세션이 프로젝트를 다시 발견해야 한다. 별도의 검증자는 토큰을 사용하지만, 동일한 AI 에이전트에게 자기 평가를 시키면 약한 테스트가 만들어지기 쉽다. 정리는 토큰을 사용하지만, 무질서는 다음 태스크를 어렵게 만든다.

토큰 소비 장치 (token consumption device)라는 표현은 harness가 규율 없이 팽창할 때는 타당하다. 하지만 harness가 인간의 조정, 프로젝트 관리, 테스트 설계, 코드 리뷰를 대신 수행한다면 평가는 달라진다. 실용적인 척도는 토큰당 성과이다. Harness가 10배의 문맥 (context)을 사용하더라도, 중대한 가짜 완료 (false completion)를 하나 방지할 수 있다면 그 비용은 낮을 수 있다. 아름다운 절차 메모만 만들고 최종 결과가 취약한 상태로 남는다면, 그것은 측정되는 잡음 (noise)일 뿐이다.

좋은 harness는 작고 태스크에 민감하다. 첫째, 문맥 수집을 강제한다. AI 에이전트 (AI agent)는 계획을 세우기 전에 중요한 파일, 출처, 제약 사항, 미지의 지점을 특정해야 한다. 둘째, 가시적인 태스크 장부를 만든다. 장부에는 시도한 것, 통과한 것, 실패한 것, 남아 있는 것이 보여야 한다. 셋째, 검증을 독립시킨다. 확인 역할은 테스트하기 쉬운 행동이 아니라, 요청된 행동을 평가한다. 넷째, 전진한 후에 작업 공간을 정리한다. 문서, 사용되지 않는 코드, 오래된 전제 조건도 태스크의 표면에 포함된다. 다섯째, 토큰 예산과 중단 규칙을 설정한다. 자율성은 언제 계속할지, 언제 물어볼지를 알 때 더 잘 작동한다.

이러한 유형은 코드 외부에서도 중요하다. 연구자들은 Miss Formula를 사용하여 수식 이미지를 수학적 표기법으로 변환하고, ChatGPT나 Gemini에게 해석을 비교하게 한 뒤, Editable Figure를 통해 AI가 생성한 논문 도표를 편집 가능한 벡터 형식으로 변환할 수 있다. 동일한 harness의 논리가 적용된다. 입력을 유지하고, 주장(claim)의 흐름을 보존하며, 출력을 검증하고, 최종 결과물을 편집 가능한 상태로 남기는 것이다.

harness에 대한 논의는 신뢰에 대한 논의이다. 사람들이 원하는 것은 자신만만하게 말하기만 하는 AI 에이전트가 아니다. 방향을 유지하고, 제약 사항을 존중하며, 자신의 상태를 보여주고, 실패로부터 회복할 수 있는 AI 에이전트이다. 태스크로부터 만들어지는 실행 프레임워크 (execution framework)는 그 요구에 대한 하나의 해답이다.

그 프레임워크는 토큰을 사용한다. 사용해야만 한다. 긴 작업에는 기억, 확인, 조정이 필요하기 때문이다. 중요한 것은 지렛대 역할을 하는 곳에 토큰을 사용하는 것이다. Karpathy가 Claude Code Harness에 관한 논의를 공유함으로써 단순한 교훈에 이목이 집중되었다. AI 작업의 미래는 모델, 도구, 그리고 이들을 연결하는 규율 있는 운영 시스템에 의해 형성될 것이다.