장기 실행 에이전트를 위한 효과적인 하네스 \ Anthropic
요약: AI 에이전트가 수 시간 혹은 며칠 동안 복잡한 작업을 수행할 수 있게 되면서, 여러 컨텍스트 윈도우에 걸쳐 일관된 진행을 이루는 것이 중요한 과제가 되었습니다. Anthropic은 이 문제를 해결하기 위해 초기화 에이전트와 코딩 에이전트의 두 가지 솔루션을 개발했습니다. 초기화 에이전트는 환경을 설정하고, 코딩 에이전트는 각 세션마다 점진적인 진전을 이루며 다음 세션을 위해 명확한 아티팩트를 남깁니다. 이 접근법은 기능 목록 작성, 점진적 진행, 철저한 테스팅, 그리고 정리된 상태 유지를 통해 에이전트가 효과적으로 장기간 작업할 수 있게 합니다.
AI 에이전트가 더욱 강력해짐에 따라, 개발자들은 시간 혹은 며칠에 걸친 복잡한 작업을 에이전트에게 맡기고 있습니다. 그러나 여러 컨텍스트 윈도우에 걸쳐 에이전트가 일관된 진전을 이루게 하는 것은 여전히 미해결 문제입니다. 장기 실행 에이전트의 핵심 과제는 에이전트가 불연속적인 세션에서 작업해야 하며, 각 새로운 세션은 이전에 무슨 일이 있었는지에 대한 기억 없이 시작한다는 점입니다. 엔지니어들이 교대 근무하며 일하는 소프트웨어 프로젝트를 상상해보세요. 각 새로운 엔지니어는 이전 교대에서 무슨 일이 있었는지에 대한 기억 없이 도착합니다. 컨텍스트 윈도우는 제한되어 있고, 대부분의 복잡한 프로젝트는 단일 윈도우 내에서 완료할 수 없기 때문에, 에이전트는 코딩 세션 사이의 격차를 연결할 방법이 필요합니다.
우리는 Claude Agent SDK가 많은 컨텍스트 윈도우에 걸쳐 효과적으로 작동할 수 있도록 하는 두 가지 솔루션을 개발했습니다. 첫 번째 실행 시 환경을 설정하는 초기화 에이전트와, 모든 세션에서 점진적인 진전을 이루면서 다음 세션을 위해 명확한 아티팩트를 남기는 코딩 에이전트입니다. 동봉된 빠른 시작에서 코드 예제를 찾을 수 있습니다.
장기 실행 에이전트 문제
Claude Agent SDK는 코딩뿐만 아니라 모델이 도구를 사용하여 컨텍스트를 수집, 계획, 실행해야 하는 다른 작업에도 능숙한 강력하고 범용적인 에이전트 하네스입니다. 압축과 같은 컨텍스트 관리 기능을 갖추고 있어, 에이전트가 컨텍스트 윈도우를 소진하지 않고 작업에 참여할 수 있습니다. 이론적으로는 이러한 설정이 주어지면 에이전트가 무기한 동안 유용한 작업을 계속 수행하는 것이 가능해야 합니다.
하지만 압축만으로는 충분하지 않습니다. 기본 설정 상에서도 Opus 4.5와 같은 프런티어 코딩 모델이 Claude Agent SDK에서 여러 컨텍스트 윈도우에 걸쳐 루프로 실행되더라도, “claude.ai의 클론을 만드세요”와 같은 상위 수준의 프롬프트만 주어진다면 프로덕션 품질의 웹 앱을 구축하는 데에는 부족합니다. Claude의 실패는 두 가지 패턴으로 나타났습니다.
첫째, 에이전트는 한 번에 너무 많은 일을 하려는 경향이 있었습니다. 본질적으로 앱을 한 번에 완성하려는 시도였습니다. 종종 이로 인해 모델이 구현 도중에 컨텍스트를 소진하게 되어, 다음 세션은 절반만 구현되고 문서화되지 않은 기능으로 시작해야 했습니다. 에이전트는 무슨 일이 있었는지 추측해야 했고, 기본 앱을 다시 작동시키는 데 상당한 시간을 소비해야 했습니다. 이것은 항상 완벽하게 명확한 지시사항을 다음 에이전트에게 전달하지 않는 압축으로도 발생합니다.
두 번째 실패 모드는 프로젝트 후반부에 종종 발생했습니다. 일부 기능이 이미 구축된 후, 나중에 에이전트 인스턴스가 주변을 둘러보고 진전이 있었음을 확인한 다음 작업이 완료되었다고 선언하는 경우였습니다.
이 문제는 두 부분으로 분해됩니다. 첫째, 주어진 프롬프트가 필요로 하는 모든 기능에 대한 기초를 마련하는 초기 환경을 설정해야 하며, 이는 에이전트가 단계별로, 기능별로 작업할 수 있도록 합니다. 둘째, 각 에이전트에게 목표를 향한 점진적인 진전을 이루도록 프롬프트를 해야 하며, 동시에 세션 종료 시 환경을 정리된 상태로 남겨야 합니다. “정리된 상태”는 메인 브랜치에 병합하기에 적합한 종류의 코드를 의미합니다. 주요 버그가 없고, 코드가 정돈되어 있으며 잘 문서화되어 있으며, 일반적으로 개발자가 관련 없는 엉망을 정리할 필요 없이 새로운 기능 작업을 쉽게 시작할 수 있습니다.
내부적으로 실험할 때 우리는 이러한 문제를 두 부분으로 된 솔루션으로 해결했습니다.
초기화 에이전트: 첫 번째 에이전트 세션은 모델에게 초기 환경을 설정하도록 요청하는 특수화된 프롬프트를 사용합니다. init.sh 스크립트, 에이전트가 수행한 작업을 기록하는 claude-progress.txt 파일, 그리고 추가된 파일을 보여주는 초기 git 커밋입니다.
코딩 에이전트: 모든 후속 세션은 모델에게 점진적인 진전을 이루도록 요청한 다음, 구조화된 업데이트를 남기도록 요청합니다.
여기서 핵심 통찰은 에이전트가 새로운 컨텍스트 윈도우로 시작할 때 작업 상태를 빠르게 이해할 수 있는 방법을 찾는 것이었으며, 이는 git 기록과 함께 claude-progress.txt 파일로 달성됩니다. 이러한 관행에 대한 영감은 효과적인 소프트웨어 엔지니어들이 매일 하는 일을 이해하는 것에서 왔습니다.
환경 관리
업데이트된 Claude 4 프롬프트 가이드에서 우리는 “첫 번째 컨텍스트 윈도우에 다른 프롬프트를 사용”하는 하네스 구조를 포함하여 다중 컨텍스트 윈도우 워크플로우에 대한 몇 가지 모범 사례를 공유했습니다. 이 “다른 프롬프트”는 초기화 에이전트가 미래의 코딩 에이전트가 효과적으로 작업하는 데 필요한 모든 필요한 컨텍스트로 환경을 설정하도록 요청합니다. 여기서 우리는 그러한 환경의 몇 가지 주요 구성 요소에 대해 더 자세히 설명합니다.
기능 목록
에이전트가 앱을 한 번에 완성하거나 프로젝트를 조기에 완료한 것으로 간주하는 문제를 해결하기 위해, 초기화 에이전트에게 사용자의 초기 프롬프트를 확장하는 포괄적인 기능 요구사항 파일을 작성하도록 프롬프트했습니다. claude.ai 클론 예제에서 이것은 “사용자가 새로운 채팅을 열고, 쿼리를 입력하고, 엔터를 누르고, AI 응답을 볼 수 있습니다”와 같은 200개 이상의 기능을 의미했습니다. 이러한 기능은 모두 처음에는 “실패(failing)”로 표시되어 나중에 코딩 에이전트들이 전체 기능이 어떻게 보이는지 명확한 개요를 갖게 되었습니다.
“json
{
"category": "functional",
"description": "New chat button creates a fresh conversation",
"steps": [
"Navigate to main interface",
"Click the 'New Chat' button",
"Verify a new conversation is created",
"Check that chat area shows welcome state",
"Verify conversation appears in sidebar"
],
"passes": false
}
`
우리는 코딩 에이전트에게 이 파일을 편집할 때 passes 필드의 상태만 변경하도록 프롬프트했으며, "테스트를 제거하거나 편집하는 것은 용납할 수 없습니다. 이는 누락되거나 버그가 있는 기능으로 이어질 수 있기 때문입니다"와 같은 강력한 지시사항을 사용했습니다. 일부 실험 후에 우리는 이것에 JSON을 사용하기로 결정했습니다. 모델은 마크다운 파일에 비해 JSON 파일을 부적절하게 변경하거나 덮어쓸 가능성이 더 낮기 때문입니다.
점진적 진전
이 초기 환경 스캐폴딩이 주어지면, 코딩 에이전트의 다음 반복은 한 번에 하나의 기능에 대해서만 작업하도록 요청받았습니다. 이 점진적인 접근법은 에이전트가 한 번에 너무 많은 일을 하려는 경향을 해결하는 데 결정적으로 중요한 것으로 밝혀졌습니다.
점진적으로 작업하더라도, 모델이 코드 변경 후 환경을 정리된 상태로 남기는 것이 여전히 필수적입니다. 우리의 실험에서 우리는 이러한 동작을 유도하는 가장 좋은 방법은 모델이 자신의 진전을 설명적인 커밋 메시지와 함께 git에 커밋하고, 진전 파일에 요약을 작성하도록 요청하는 것임을 발견했습니다. 이것은 모델이 git을 사용하여 나쁜 코드 변경을 되돌리고 코드베이스의 작동 상태를 복구할 수 있게 했습니다. 이러한 접근법은 또한 효율성을 높였습니다. 에이전트가 무슨 일이 있었는지 추측하고 기본 앱을 다시 작동시키는 데 시간을 소비할 필요가 없어졌기 때문입니다.
테스팅
우리가 관찰한 마지막 주요 실패 모드는 Claude가 적절한 테스팅 없이 기능을 완료한 것으로 표시하는 경향이었습니다. 명시적인 프롬프트가 없으면 Claude는 코드 변경을 하고, 개발 서버에 대해 단위 테스트나 curl 명령으로 테스팅을 했지만, 기능이 종단 간으로 작동하지 않는다는 것을 인식하지 못했습니다.
웹 앱을 구축하는 경우, Claude가 브라우저 자동화 도구를 사용하고 인간 사용자처럼 모든 테스팅을 하도록 명시적으로 프롬프트되면 종단 간으로 기능을 검증하는 데 대체로 잘했습니다.
Claude가 Puppeteer MCP 서버를 통해 claude.ai 클론을 테스트하면서 찍은 스크린샷입니다. Claude에게 이러한 종류의 테스팅 도구를 제공하면 성능이 극적으로 향상되었습니다. 에이전트가 코드만으로는 명확하지 않은 버그를 식별하고 수정할 수 있었기 때문입니다.
일부 문제는 여전히 남아 있습니다. 예를 들어, Claude의 비전과 브라우저 자동화 도구의 제한으로 인해 모든 종류의 버그를 식별하는 것이 어렵습니다. 예를 들어, Claude는 Puppeteer MCP를 통해 브라우저 네이티브 알림 모달을 볼 수 없으며, 이러한 모달에 의존하는 기능은 결과적으로 더 버그가 많은 경향이 있습니다.
상황 파악
위의 모든 것이 준비되면 모든 코딩 에이전트는 상황을 파악하기 위해 일련의 단계를 거치도록 프롬프트됩니다. 어떤 것들은 매우 기본적이지만 여전히 유용합니다.
- pwd를 실행하여 작업 중인 디렉터리를 확인합니다. 이 디렉터리에서만 파일을 편집할 수 있습니다.
- git 로그와 진전 파일을 읽어 최근에 어떤 작업이 수행되었는지 파악합니다.
- 기능 목록 파일을 읽고 작업하지 않은 가장 높은 우선순위의 기능을 선택하여 작업을 시작합니다.
이 접근법은 Claude가 코드를 테스트하는 방법을 알아낼 필요가 없으므로 모든 세션에서 일부 토큰을 절약합니다. 또한 초기화 에이전트에게 개발 서버를 실행할 수 있는 init.sh 스크립트를 작성하도록 요청한 다음, 새로운 기능을 구현하기 전에 기본적인 종단 간 테스트를 거치도록 하는 데도 도움이 됩니다. claude.ai 클론의 경우 이것은 에이전트가 항상 로컬 개발 서버를 시작하고 Puppeteer MCP를 사용하여 새 채팅을 시작하고, 메시지를 보내고, 응답을 받는다는 것을 의미했습니다.
이것은 Claude가 앱이 손상된 상태로 남겨졌는지 빠르게 식별할 수 있고 즉시 기존 버그를 수정할 수 있도록 했습니다. 에이전트가 대신 새로운 기능 구현을 시작했다면 문제를 악화시켰을 것입니다.
이 모든 것을 고려할 때, 일반적인 세션은 다음과 같은 어시스턴트 메시지로 시작합니다.
`
[Assistant] I'll start by getting my bearings and understanding the current state of the project.
[Tool Use]
[Tool Use]
[Tool Use]
[Assistant] Let me check the git log to see recent work.
[Tool Use]
[Assistant] Now let me check if there's an init.sh script to restart the servers.
[Starts the development server]
[Assistant] Excellent! Now let me navigate to the application and verify that some fundamental features are still working.
[Assistant] Based on my verification testing, I can see that the fundamental functionality is working well. The core chat features, theme switching, conversation loading, and error handling are all functioning correctly. Now let me review the tests.json file more comprehensively to understand what needs to be implemented next.
“
에이전트 실패 모드 및 솔루션
| 문제 | 초기화 에이전트 동작 | 코딩 에이전트 동작 |
|——|———————|——————-|
| Claude가 전체 프로젝트에 대해 너무 일찍 승리를 선언함 | 기능 목록 파일 설정: 입력 사양을 기반으로 종단 간 기능 설명 목록이 있는 구조화된 JSON 파일을 설정합니다. | 세션 시작 시 기능 목록 파일을 읽습니다. 작업을 시작할 단일 기능을 선택합니다. |
| Claude가 버그나 문서화되지 않은 진전이 있는 상태로 환경을 남김 | 초기 git 리포지토리와 진전 노트 파일이 작성됩니다. | 세션 시작 시 진전 노트 파일과 git 커밋 로그를 읽고, 문서화되지 않은 버그를 포착하기 위해 개발 서버에서 기본 테스트를 실행합니다. 세션 종료 시 git 커밋과 진전 업데이트를 작성합니다. |
| Claude가 기능을 조기에 완료된 것으로 표시함 | 기능 목록 파일 설정 | 모든 기능을 직접 검증합니다. 철저한 테스팅 후에만 기능을 “통과(passing)”로 표시합니다. |
| Claude가 앱을 실행하는 방법을 알아내는 데 시간을 소비함 | 개발 서버를 실행할 수 있는 init.sh 스크립트 작성 | 세션 시작 시 init.sh를 읽습니다. |
장기 실행 AI 에이전트의 네 가지 일반적인 실패 모드와 솔루션을 요약합니다.
향후 작업
이 연구는 모델이 많은 컨텍스트 윈도우에 걸쳐 점진적인 진전을 이룰 수 있게 하는 장기 실행 에이전트 하네스에서 가능한 한 솔루션 세트를 보여줍니다. 그러나 여전히 미해결 질문들이 남아 있습니다. 가장 주목할 만한 것은, 단일의 범용 코딩 에이전트가 모든 컨텍스트에서 최고의 성능을 발휘하는지, 아니면 다중 에이전트 아키텍처를 통해 더 나은 성능을 달성할 수 있는지 여부가 여전히 불분명하다는 것입니다.
테스팅 에이전트, 품질 보증 에이전트, 코드 정리 에이전트와 같은 특수화된 에이전트가 소프트웨어 개발 수명 주기에 걸쳐 하위 작업을 훨씬 더 잘 수행할 수 있다는 것은 합리적입니다. 또한 이 데모는 풀스택 웹 앱 개발에 최적화되어 있습니다. 향후 방향은 이러한 발견을 다른 분야로 일반화하는 것입니다. 일부 또는 모든 이러한 교훈들이 예를 들어 과학 연구나 금융 모델링에서 필요한 종류의 장기 실행 에이전트 작업에 적용될 가능성이 있습니다.
감사의 말
Justin Young이 작성했습니다. David Hershey, Prithvi Rajasakeran, Jeremy Hadfield, Naia Bouscal, Michael Tingley, Jesse Mu, Jake Eaton, Marius Buleandara, Maggie Vo, Pedram Navid, Nadine Yasser, Alex Notov의 기여에 특별히 감사드립니다. 이 작업은 Claude가 안전하게 장기 호라이즌 자율 소프트웨어 엔지니어링을 할 수 있게 만든 Anthropic 전반의 여러 팀의 집단적인 노력을 반영하며, 특히 코드 RL 및 Claude Code 팀의 노력을 반영합니다. 기여에 관심이 있는 지원자는 anthropic.com/careers에서 지원하실 수 있습니다.
각주
- 우리는 이 문맥에서 이들을 별도의 에이전트라고 부르는 것은 그들이 다른 초기 사용자 프롬프트를 가지고 있기 때문입니다. 시스템 프롬프트, 도구 세트, 전반적인 에이전트 하네스는 그렇지 않고 동일했습니다.
핵심 포인트
- 장기 실행 에이전트는 여러 컨텍스트 윈도우에 걸쳐 일관된 진전을 이루는 것이 핵심 과제입니다
- 초기화 에이전트와 코딩 에이전트의 두 부분 솔루션으로 이 문제를 해결합니다
- 기능 목록(JSON 파일), 점진적 진전, 철저한 테스팅, 정리된 상태 유지가 중요합니다
- Puppeteer MCP 같은 브라우저 자동화 도구로 종단 간 테스팅을 수행해야 합니다
- 향후 연구는 다중 에이전트 아키텍처와 다른 분야로의 일반화를 탐구할 수 있습니다