Anthropic 엔지니어들이 말하는 에이전트 루프 설계 방법과 장시간 AI 앱 개발 전략

이 글은 Anthropic 엔지니어들이 실제로 장시간 자율 에이전트를 만들며 얻은 교훈을 정리한 내용입니다. 단순히 성능이 좋은 모델 하나로 앱을 완성하는 것이 아니라, 에이전트를 어떤 구조와 루프 안에 넣느냐가 결과 품질을 좌우한다는 메시지를 중심으로 다룹니다.
특히 Planner–Generator–Evaluator 구조, 장시간 실행 시 발생하는 실패 모드, 그리고 개발자가 바로 적용할 수 있는 실전 패턴까지 정리해, AI로 처음부터 끝까지 앱을 완성시키고 싶은 개발자에게 실질적인 인사이트를 제공합니다.

반응형

---

발표의 배경: “더 똑똑한 모델”보다 중요한 것

이번 내용은 Anthropic의 엔지니어 Ash Prabaker와 Andrew Wilson이 발표한 Build Agents That Run for Hours 워크숍을 기반으로 합니다.
이 발표는 Anatoli Kopadze가 공유한 영상으로 알려졌으며, 단순 데모가 아니라 실제 내부 엔지니어링 과정에서 마주친 실패와 한계를 솔직하게 공개한 점이 특징입니다.

핵심 메시지는 명확합니다.

앱을 처음부터 끝까지 만들게 하려면,
더 똑똑한 모델 하나보다 모델을 어떻게 루프에 넣는지가 더 중요하다.

---

왜 Claude Code를 그냥 오래 돌리면 안 될까?

많은 개발자가 Claude Code 같은 코딩 에이전트를 “충분히 오래 실행하면 앱이 완성되지 않을까?”라고 기대합니다. Anthropic은 이 접근이 실패하는 이유를 세 가지로 정리합니다.

1. 컨텍스트 문제

• 컨텍스트 윈도우는 유한합니다.
• 세션을 리셋하면 기억상실이 발생합니다.
• 너무 오래 유지하면 문맥이 썩는 context rot가 생깁니다.
• 컨텍스트 끝에 가까워질수록 급히 마무리하려는 context anxiety도 나타납니다.

2. 계획 문제

모델은 “처음부터 완성된 앱을 만들어줘”라는 요청을 받으면 모든 걸 한 번에 처리하려다 길을 잃습니다.
그 결과:

• 반쪽짜리 기능 구현
• 핵심 기능 누락
• 미완성 상태로 종료

3. 자기 평가의 실패

가장 과소평가되는 문제입니다.
모델은 자기 산출물에 지나치게 관대합니다.
Anthropic 표현대로, 에이전트에게 자기 결과물을 리뷰시키면 쉽게 rubber stamp가 됩니다.

이 때문에 Anthropic의 결론은 단순합니다.

생성하는 에이전트와 평가하는 에이전트는 반드시 분리해야 한다.

---

Anthropic이 제안한 핵심 구조: Planner · Generator · Evaluator

Anthropic은 장시간 에이전트를 위한 기본 구조로 세 역할 분리를 제안합니다.

Planner: 제품 관점의 설계자

Planner는 사용자의 짧은 요청을 제품 스펙 수준으로 확장합니다.
중요한 점은, 너무 이른 단계에서 세부 구현까지 고정하지 않는다는 것입니다.

• 무엇을 만들어야 하는가
• 어떤 사용자 경험이어야 하는가

까지만 정의하고, 기술적 구현 경로는 뒤 단계에서 조정되도록 둡니다.
초기 결정 오류가 전체 스프린트로 전파되는 것을 막기 위함입니다.

Generator: 실제 구현 담당

Generator는 코드 작성, UI 구현, 기능 연결, 테스트까지 수행합니다.
하지만 “완성됐다”고 선언할 권한은 없습니다.
Evaluator의 기준을 통과해야만 다음 단계로 넘어갈 수 있습니다.

Evaluator: 가혹한 비평가

Evaluator는 코드 diff만 보지 않습니다.

• 브라우저 자동화 도구로 실제 화면 실행
• 클릭, 입력, 흐름 검증
• 깨진 UX, 오류 케이스 탐지

Evaluator 역시 LLM이지만, Anthropic은 이렇게 설명합니다.

빌더를 자기비판적으로 만드는 것보다,
별도의 critic을 가혹하게 튜닝하는 편이 훨씬 쉽다.

생성과 비평 사이의 능력 차이를 하네스 설계로 활용하는 방식입니다.

---

Ralph Loop와의 차이: 반복이 아니라 계약이다

기존의 Ralph Wiggum loop는 단순 반복 실행처럼 보이지만, 실제 핵심은 다음에 있습니다.

• 작업을 작은 기능 단위로 분해
• 매 작업을 신선한 컨텍스트에서 실행
• 명확한 완료 조건과 중단 조건
• 실패가 예측 가능한 구조

Anthropic의 새 하네스는 여기에 대립적 평가(adversarial pressure)를 추가합니다.

• 고정된 plan.md를 따르지 않음
• Generator와 Evaluator가 파일 기반 계약을 협상
• 기준이 약하면 Evaluator가 수정 요구
• 합의된 계약을 기준으로 빌드와 검증 반복

즉, 핵심은 “계속 시키기”가 아니라
검증 가능한 계약을 만들고 서로 압박하는 구조입니다.

---

주관적인 품질도 평가할 수 있을까?

Anthropic은 “디자인은 평가할 수 없다”는 태도를 취하지 않습니다.
오히려 강한 기준을 글로 명시하라고 말합니다.

그들이 사용한 루브릭 예시는 다음과 같습니다.

• Design
• Originality
• Craft
• Functionality

특히 최신 모델일수록 기능 구현은 잘하므로,
디자인과 독창성의 가중치를 더 높이기도 했습니다.

중요한 교훈은 이것입니다.

• “예쁘게 만들어줘”는 기준이 아니다.
• 하지만
  • 레이아웃 밀도
  • 타이포그래피 대비
  • 상호작용 피드백
  • 오류 상태
  • 모바일 대응
    처럼 나누면 실제 평가가 가능해진다.

---

실제 결과는 얼마나 달라졌을까?

Anthropic Engineering에 따르면, 동일한 요청을 비교했습니다.

• Solo run
  • 약 20분
  • 약 9달러
• Full harness
  • 약 6시간
  • 약 200달러

비용은 크게 늘었지만 결과는 전혀 달랐습니다.
풀 하네스는 단순 데모가 아닌 제품 형태의 구조를 만들었습니다.

중요한 해석은 이것입니다.

장시간 에이전트는 더 싸게 만드는 기술이 아니라,
더 긴 작업을 끝까지 밀어붙이기 위해 비용과 구조를 투입하는 기술이다.

---

모델이 좋아지면 하네스는 사라질까?

Anthropic의 답은 분명합니다.

하네스와 모델은 함께 진화한다.

모델이 좋아질수록:

• 필요 없는 발판은 제거
• 여전히 약한 지점에는 새로운 발판 추가

“다음 모델이 나오면 하네스 엔지니어링은 끝난다”가 아니라,
어떤 하네스를 버리고 어떤 하네스를 남길지 다시 판단하는 일이 됩니다.

---

개발자가 바로 적용할 수 있는 실전 패턴

이 발표에서 바로 가져갈 수 있는 핵심 패턴은 다음과 같습니다.

1. 자기 평가 금지
   만든 에이전트에게 스스로 검사하게 하지 않는다.
2. 평가자는 실제 실행
   코드가 아니라 동작, 로그, 에러를 보게 한다.
3. 루브릭을 글로 작성
   추상적 표현을 체크리스트와 가중치로 바꾼다.
4. 계약 기반 시작
   산출물 기준을 문서화하고 상호 검토한다.
5. 트레이스 분석
   실패 로그를 읽고 규칙과 프롬프트를 개선한다.

---

728x90

이 발표를 한 문장으로 요약하면 다음과 같습니다.

에이전트 개발은 프롬프트 작성이 아니라, 작은 조직을 설계하는 일이다.

• Planner는 PM처럼 요구를 구조화하고
• Generator는 엔지니어처럼 구현하며
• Evaluator는 QA처럼 실제 동작을 검증합니다.

이 셋은 같은 기억과 성격을 공유해서는 안 됩니다.
역할, 컨텍스트, 권한, 종료 조건이 분리되어야 합니다.

앞으로 중요한 역량은 단순히 “모델에게 잘 말하는 법”이 아니라,

• 어떤 역할을 분리할 것인가
• 어떤 아티팩트로 핸드오프할 것인가
• 무엇을 자동 평가하고 무엇을 사람이 볼 것인가

를 설계하는 능력이 될 것입니다.

결국, 좋은 에이전트는 똑똑한 모델 하나가 아니라 좋은 루프를 가진 시스템입니다.

300x250