Anthropic의 장기 실행 에이전트 하네스: 2-에이전트에서 Planner-Generator-Evaluator로

강력한 모델만으로는 부족하다는 사실이 드러났다

AI 에이전트 기술이 성숙기에 접어들면서, 단순히 강력한 모델을 선택하는 것만으로는 복잡한 소프트웨어 개발 작업을 자율적으로 완수하기 어렵다는 사실이 분명해졌다. Anthropic은 자사 엔지니어링 블로그를 통해 장기 실행 애플리케이션 개발을 위한 하네스 설계 방법론을 공개하며, 멀티 에이전트 자율 코딩 솔루션의 설계 원칙과 진화 과정을 상세히 설명하고 있다.

하네스(Harness)는 AI 모델 주변에 위치하는 소프트웨어 인프라로, 에이전트의 생명 주기, 컨텍스트, 외부 세계와의 상호작용을 관리하는 역할을 한다. 쉽게 말해 하네스는 에이전트의 "두뇌"가 아니라, 두뇌에 도구·메모리·안전 제한을 제공하는 "환경"이다. 하네스가 담당하는 핵심 기능은 초기화(에이전트가 작업을 시작할 때 필요한 환경 구성), 컨텍스트 주입(관련 정보를 적시에 제공), 도구 디스패치(에이전트가 사용할 도구와 API 관리), 상태 지속성(세션 간 작업 진행 상황 저장·복원), 정리(작업 완료 후 자원 반환)로 나뉜다.

2025년까지 업계는 더 강력한 프론티어 모델이 모든 배포 문제를 해결해줄 것이라 가정했다. 그러나 2026년에 이르러 가장 발전된 모델조차 에이전트 스캐폴딩(scaffolding) 없이는 한계를 드러낸다는 사실이 명확해졌다. 초점이 모델 중심 설계에서 인프라 중심 설계로 이동한 것이다.

하네스가 늘어난 과정

Anthropic의 하네스 설계는 실제 자율 코딩 작업에서 발견된 문제점들을 해결하며 단계적으로 발전해왔다.

2025년 11월에 공개된 초기 설계는 두 개의 에이전트로 구성된다. 이니셜라이저(Initializer)는 첫 실행 시 내구성 있는 프로젝트 환경을 구성한다. 구체적으로는 기능 목록(feature list), Git 저장소, 진행 상황 추적 파일(progress tracking file), 초기 Git 커밋이 이니셜라이저의 산출물이다. 코딩 에이전트(Coding Agent)는 세션마다 실행되며, 프로젝트 환경에서 하나의 기능을 점진적으로 구현하고, 테스트를 실행하고, 커밋하고, 진행 파일을 업데이트한 뒤 종료한다. 세션 간 컨텍스트 리셋이 핵심 설계 요소로, Claude Sonnet 4.5가 보인 컨텍스트 불안(context anxiety) 문제를 해결하기 위해 도입되었다. 이 단계에서 가장 중요한 통찰은 "프로젝트 환경 자체가 모든 세션의 공유 메모리"라는 점이다. 각 코딩 에이전트 세션은 파일 시스템과 Git 히스토리를 통해 이전 세션의 작업 맥락을 파악한다.

Opus 4.5를 활용한 3-에이전트 아키텍처로 발전하면서 더 복잡한 작업 처리가 가능해졌다. 플래너(Planner)는 한 줄짜리 프롬프트를 16개 기능, 10개 스프린트로 구성된 상세 제품 명세로 확장한다. 높은 수준의 설계에 집중하며, 오류가 연쇄될 수 있는 세부적인 기술 사항은 피한다. 각 스프린트 전 계약 협상(contract negotiation)을 수행하는 것도 특징이다. 생성기(Generator)는 명세에 따라 실제 코드를 작성하고, 평가기(Evaluator)는 생성된 코드의 품질을 독립적으로 검토한다. 생성-평가 루프(build-evaluate loop)가 핵심 동작 방식이다.

컨텍스트 불안과 컨텍스트 부패라는 함정

장기 실행 에이전트에서 발견된 중요한 현상 중 하나는 컨텍스트 불안이다. 컨텍스트 창이 채워질수록 모델이 원래 목표를 잃어버리거나 불필요한 행동을 보이는 현상이다. Anthropic의 연구에서 Claude Sonnet 4.5는 컨텍스트 불안을 강하게 나타냈으며, 이것이 하네스에 컨텍스트 리셋을 도입하게 된 직접적인 계기가 되었다.

장기 실행 에이전트는 "컨텍스트 부패(Context Rot)" 문제에도 직면한다. 수 시간에 걸친 작업에서 원래 목표를 잃어버리는 현상이다. 하네스는 에이전트의 메모리를 관리하고 상태를 데이터베이스에 지속하는 방식으로 이를 방지한다. 실용적인 해법으로는 지속적인 할 일 목록(persistent todo list)이 있다. 에이전트는 각 행동의 시작 시 이를 읽고, 종료 시 업데이트한다. Claude Code와 Manus 모두 이 방식의 변형을 사용한다. 멀티 사용자 인터랙션이나 장기 실행 작업에서는 진행 상황, 중간 결과, 대화 히스토리를 내구성 있는 저장소에 보존해 중단 후 재개가 가능하도록 설계해야 한다.

Anthropic이 문서화한 장기 코딩 작업의 핵심 패턴은 이니셜라이저-익스큐터 분리다. 이니셜라이저는 한 번 실행되어 내구성 있는 프로젝트 환경을 구성(폴더 구조, 기능 목록, init.sh, 초기 Git 커밋)하고, 익스큐터는 매 세션마다 환경을 읽고 하나의 기능을 점진적으로 처리한 뒤 종료한다. 이 분리를 통해 각 세션은 독립적으로 동작하면서도 전체 프로젝트의 맥락을 유지한다.

GAN에서 빌려온 생성기-평가기 분리

Anthropic은 자기 평가(self-evaluation) 실패 문제를 해결하기 위해 생성적 적대 신경망(GAN: Generative Adversarial Networks)에서 영감을 받은 아키텍처를 채택했다. 핵심 통찰은 "생성과 평가의 역할을 분리하는 것"이다.

전용 평가기를 회의적으로 조율하는 것이 생성기를 자기 비판적으로 만드는 것보다 훨씬 다루기 쉽다는 사실을 발견했다. 생성-평가 루프는 소프트웨어 개발 생명 주기에 자연스럽게 매핑된다. 코드 리뷰와 QA가 설계 평가기와 동일한 구조적 역할을 담당하는 것이다.

⤢✕

하네스의 핵심 역량, 컨텍스트 엔지니어링

컨텍스트 엔지니어링은 하네스 설계에서 일급(first-class) 관심사로 다루어진다. 특정 에이전트를 위한 컨텍스트 격리, 여러 단계에 걸친 정보 지속, 대용량 데이터 압축을 통한 효율성 향상이 핵심 전략이다.

Claude Agent SDK의 자동 압축 기능(적응형 컨텍스트 압축)은 컨텍스트 증가를 처리하는 핵심 메커니즘이다. 에이전트가 전체 빌드 과정에서 하나의 연속 세션으로 실행될 때, 컨텍스트 증가를 자동으로 처리하여 컨텍스트 창 초과로 인한 중단 없이 장시간 작업을 지속할 수 있다.

주의 집중 감소(attention decay)에 대응하기 위해, 하네스는 이벤트 기반으로 시스템 리마인더를 주입한다. 이를 통해 에이전트가 장시간 작업 중에도 원래 목표와 제약 조건을 유지할 수 있다.

프로젝트별 지식을 누적하는 경험 기반 메모리 파이프라인을 통해, 에이전트는 이전 세션에서 학습한 내용을 새 세션에 활용할 수 있다. 이는 마치 숙련된 개발자가 프로젝트 히스토리를 이해하고 작업하는 방식과 유사하다.

실패 패턴과 그 대응

컨텍스트 부패는 수 시간에 걸친 작업에서 에이전트가 원래 목표를 잃어버리는 현상이다. 대응 전략으로는 지속적 할 일 목록 관리, 주기적 컨텍스트 리셋, 목표를 명시하는 시스템 프롬프트 강화가 있다.

자기 평가 실패는 에이전트가 자신이 생성한 코드의 품질을 정확하게 평가하지 못하는 문제다. 생성기와 평가기를 분리하는 GAN 방식의 아키텍처로 이를 해결한다. 독립적인 평가기는 생성기보다 훨씬 효과적으로 오류를 식별한다.

상태 동기화 불일치는 멀티 에이전트 환경에서 여러 에이전트의 상태가 불일치하는 문제다. Git을 단일 진실 공급원(single source of truth)으로 활용하고, 진행 파일을 명시적으로 관리하여 해결한다. 멀티 사용자 상호작용이나 장기 실행 작업에서는 공유 상태를 외부에 지속하여 에이전트가 중단 후 재개할 수 있도록 해야 한다.

모델 중심에서 인프라 중심으로 옮겨간 업계

2025년까지 업계는 더 강력한 프론티어 모델이 모든 배포 문제를 해결해줄 것이라 믿었다. "모델을 업그레이드하면 해결된다"는 접근 방식이 지배적이었다. 그러나 2026년의 현장에서는 다른 교훈이 확인되고 있다.

"하네스가 결과를 결정한다(Harness determines the outcome)"는 원칙이 자리 잡고 있다. 동일한 모델이라도 하네스 설계에 따라 성과가 극적으로 달라진다는 사실이 반복적으로 확인되었다. 이는 소프트웨어 엔지니어링에서 좋은 도구와 프로세스가 개인의 역량만큼이나 중요하다는 오래된 진리와 맞닿아 있다.

Anthropic의 경험은 모델 단독 성능 향상보다 하네스 설계가 실무 성과에 더 큰 영향을 미칠 수 있음을 보여준다. 아키텍트와 시니어 개발자들이 AI 에이전트 시스템을 설계할 때, 모델 선정만큼이나 하네스 아키텍처에 집중해야 하는 이유가 여기에 있다.

하네스를 설계할 때 짚어야 할 것들

장기 실행 에이전트 시스템을 설계할 때 고려해야 할 핵심 체크리스트다. 이니셜라이저를 별도 에이전트로 분리해 환경 구성의 일관성을 보장하는 초기화 분리, 세션 간 상태를 Git·데이터베이스·파일 시스템에 명시적으로 기록하고 인메모리 상태에 의존하지 않는 지속적 상태 관리, 세션별 컨텍스트 리셋을 설계해 컨텍스트 불안과 컨텍스트 부패를 예방하는 컨텍스트 리셋 전략, 생성기와 평가기를 독립적인 에이전트로 구성해 자기 평가 실패 문제를 극복하는 생성-평가 분리, Git 저장소와 진행 추적 파일을 모든 에이전트의 공유 메모리로 활용하는 단일 진실 공급원, 한 세션에 하나의 기능만 처리해 각 세션이 완전하고 테스트 가능한 상태로 종료되도록 하는 점진적 진행, 에이전트별 컨텍스트 격리·압축·리마인더 주입을 설계 단계에서 고려하는 컨텍스트 엔지니어링, 에이전트 실패 시 이전 완료 지점부터 재시작할 수 있는 재개(resume) 메커니즘을 구현하는 오류 복구 설계다.

소프트웨어 공학의 오랜 원칙을 에이전트에 적용한 결과

Anthropic의 하네스 설계 방법론은 단순한 기술적 레시피가 아니다. 이는 소프트웨어 공학의 오랜 지혜, 즉 관심사의 분리(separation of concerns), 단일 책임 원칙(single responsibility), 상태 관리의 명시성을 AI 에이전트 시스템에 적용한 결과다. 2026년의 AI 에이전트 시대에도 이 원칙은 변하지 않는다. 하네스는 단지 에이전트를 감싸는 껍데기가 아니라, 에이전트가 성공할 수 있는 환경 자체다.