r/ClaudeAI•5개월 전•57•19

Anthropic의 Generator-Evaluator 아키텍처를 활용한 12단계 웹사이트 자동 생성기 구현

I replicated Anthropic's Generator-Evaluator harness to build a website through 12 adversarial AI iterations - here's the result and what I learned

핵심 요약

Anthropic의 아키텍처를 모방해 12번의 반복적인 생성과 평가 과정을 거쳐 웹사이트를 자동으로 구축한 사례.

아키텍처 설계 — 생성자와 평가자가 파일을 통해 소통하며 12번의 반복 과정을 거쳐 코드를 개선함.
실제 브라우저 테스트 — Playwright를 활용해 코드가 아닌 실제 웹사이트 화면을 평가하여 시각적 오류를 포착함.
창의적 결과물 — 단일 생성 방식과 달리 반복적인 피드백을 통해 독창적인 디자인과 스타일을 도출함.
핵심 교훈 — AI 모델 자체보다 제약 조건과 피드백 루프를 포함한 하네스 구조가 결과물의 품질을 결정함.

Anthropic은 최근 장기 실행 앱을 위한 하네스 설계를 발표했습니다. 이는 GAN에서 영감을 받은 다중 에이전트 아키텍처로, 생성자가 코드를 만들고 평가자가 루프 내에서 이를 비판하는 방식입니다. 저는 Kiro CLI를 사용하여 저만의 버전을 만들었고, 이를 통해 제 프로젝트인 Mnemo(AI 코딩 에이전트를 위한 영구 메모리)의 마케팅 웹사이트를 생성했습니다.

아키텍처:
플래너(1회 실행) → 생성자 ↔ 평가자(12회 반복)

각 에이전트는 공유 컨텍스트가 전혀 없는 별도의 CLI 프로세스입니다. 이들은 파일(spec.md, eval-report.md)을 통해서만 통신합니다. 평가자는 단순히 코드를 읽는 것이 아니라 Playwright를 사용하여 실제 라이브 사이트를 탐색합니다.

성공 요인:
호출 시마다 초기화 — 각 에이전트는 새로 시작하며 입력 파일만 읽습니다. 컨텍스트 과부하를 방지합니다.

테스트를 위한 Playwright MCP — 평가자가 실제 사이트를 탐색하고, 클릭하고, 뷰포트 크기를 조정합니다. 코드 리뷰로는 절대 잡을 수 없는 시각적 버그를 잡아냅니다.

Anthropic의 프론트엔드 디자인 기술 — 일반적인 AI 패턴(Inter 폰트, 보라색 그라데이션, 카드 레이아웃)에 명시적인 페널티를 부여합니다. 창의적인 위험 감수를 강제합니다.

실패 시 재시도가 아닌 지속적인 반복 — 12라운드 모두 예외 없이 실행됩니다. 매 라운드마다 개선됩니다.

진행 과정은 놀라웠습니다:
1회차: AI에게 기대할 수 있는 딱 그 정도 — 기능은 하지만 기억에 남지 않음
4회차: 생성자가 "터미널 누아르" 스타일로 전환 — IBM Plex Mono, 검은색 바탕에 호박색, 거친 질감, 스캔라인. 이는 단일 생성 방식에서는 일어나지 않는 창의적인 도약입니다.
5~12회차: 다듬기, 접근성, 반응형 수정, 애니메이션 줄이기 지원

통계:

총 시간: 3시간 20분
반복 횟수: 12회 (생성자 + 평가자 각각)
수동 작성 코드: 0줄 (이후 시각적 문제 몇 개만 수정)
기술 스택: Next.js, Tailwind, Framer Motion, TypeScript

라이브 결과물: https://mnemo-mcp.github.io/Mnemo/

핵심 교훈: 모델은 엔진일 뿐입니다. 그 주변의 제약 조건, 피드백 루프, 그리고 적대적 구조인 하네스가 AI의 결과물이 쓰레기일지, 아니면 진정으로 독창적인 결과물일지를 결정합니다.

원문

커뮤니티 목록

r/ClaudeAI•5개월 전•57•19

Anthropic의 Generator-Evaluator 아키텍처를 활용한 12단계 웹사이트 자동 생성기 구현

I replicated Anthropic's Generator-Evaluator harness to build a website through 12 adversarial AI iterations - here's the result and what I learned

핵심 요약

Anthropic의 아키텍처를 모방해 12번의 반복적인 생성과 평가 과정을 거쳐 웹사이트를 자동으로 구축한 사례.

아키텍처 설계 — 생성자와 평가자가 파일을 통해 소통하며 12번의 반복 과정을 거쳐 코드를 개선함.
실제 브라우저 테스트 — Playwright를 활용해 코드가 아닌 실제 웹사이트 화면을 평가하여 시각적 오류를 포착함.
창의적 결과물 — 단일 생성 방식과 달리 반복적인 피드백을 통해 독창적인 디자인과 스타일을 도출함.
핵심 교훈 — AI 모델 자체보다 제약 조건과 피드백 루프를 포함한 하네스 구조가 결과물의 품질을 결정함.

아키텍처:
플래너(1회 실행) → 생성자 ↔ 평가자(12회 반복)

성공 요인:
호출 시마다 초기화 — 각 에이전트는 새로 시작하며 입력 파일만 읽습니다. 컨텍스트 과부하를 방지합니다.

실패 시 재시도가 아닌 지속적인 반복 — 12라운드 모두 예외 없이 실행됩니다. 매 라운드마다 개선됩니다.

통계:

총 시간: 3시간 20분
반복 횟수: 12회 (생성자 + 평가자 각각)
수동 작성 코드: 0줄 (이후 시각적 문제 몇 개만 수정)
기술 스택: Next.js, Tailwind, Framer Motion, TypeScript

라이브 결과물: https://mnemo-mcp.github.io/Mnemo/

주요 댓글

r/claudeai

AI 에이전트 간의 반복적인 피드백 루프 구조와 매번 컨텍스트를 초기화하는 방식이 AI의 잠재력을 극대화하는 핵심 전략이라는 점에 공감하는 분위기입니다.

이게 맞는 방향임. 평가자가 실제 사이트를 열어보게 강제하는 걸 사람들이 너무 과소평가함. 나는 FSB를 만드는 중인데, 에이전트가 코드 리뷰뿐만 아니라 읽기 가능한 DOM, 접근성 상태, 스크린샷, 로그가 포함된 실제 브라우저 환경을 가져야 한다는 게 내 지론임. 각 라운드마다 사이트가 크롬에서 실제로 작동한다는 걸 증명해야 하니까 피드백 루프를 속이기가 훨씬 어려워짐.

흥미롭네요, 꼭 확인해 볼게요! FSB를 사용해서 프론트엔드 개발 시 생성자 단계를 위한 더 나은 평가를 수행할 수 있을까요?

웹사이트 작업은 안 하지만, 나도 랄프 루프(ralph loop)를 만들 때 결국 같은 구조에 도달했음: 플래너, 실행자(비용 절감을 위해 Sonnet 사용), 평가자(계획의 3단계마다 혹은 실행자가 막혔을 때 호출). 인상적이지만 비용이 많이 듦.

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

프론트엔드 테스트 쪽에 빈틈이 많다고 생각해서 이런 솔루션이 더 필요하다고 봐. 나도 무조건 써볼 생각임.

나도 비슷하게 만들어 봤는데, 시간이 지나면서 스모크 테스트나 회귀 테스트, 검증 테스트가 어떻게 생겼는지, 성능 지표와 성공의 증거가 무엇인지 확실히 알도록 수정했음. 이걸 모르면 결국 건너뛰게 되거든. 기준점을 만들고 개선해야 한다는 걸 알면 스스로 집중할 수 있게 됨. 근데 토큰을 엄청 잡아먹음. 처음부터 완벽한 코드가 나올 때도 있는데, 매번 완벽할 거라고 믿을 수 있을까?

그게 문제지. 기사에서는 토큰 값만 200달러 썼다더라고. 난 회사 계정으로 돌려서 정확한 비용은 모르겠는데, 토큰은 100만 개 정도 썼어.

'매번 새로 시작한다(clean slate per invocation)'는 점이 핵심임. 다들 AI 결과물 고치겠다고 긴 세션에 컨텍스트만 때려 박는데, 그러면 오히려 더 꼬이거든. 에이전트마다 새로 시작해서 파일로만 소통하게 하는 게 정답이었음. 4번째 반복에서 '터미널 누아르'로 넘어간 것도 흥미롭네. 단발성 프롬프트는 절대 이런 창의적인 시도 안 하거든. 맨날 제일 안전하고 뻔한 결과만 내놓지.

고마워. 프롬프트 작성부터 에이전트 오케스트레이션까지 제대로 해야 LLM 성능을 100% 뽑아낼 수 있는 듯. 그냥 대화하는 것도 편하지만, 개발자라면 어떻게 해야 AI 잠재력을 최대로 끌어낼지 알아야지. 한 컨텍스트 윈도우에서 계속 돌릴 때 생기는 편향이나 컨텍스트 불안(context anxiety) 문제도, 매번 새로 시작하면 확실히 차이가 커.

나도 비슷한 거 만들어봤는데, 결국 '수정을 위한 수정'을 계속하게 되더라. 스모크 테스트나 회귀 테스트, 성능 지표 같은 걸 AI가 확실히 알게 해야 해. 안 그러면 그냥 넘어가 버리거든. 기준점(baseline)을 잡고 개선이 필요하다는 걸 인지시키면 집중력이 생기긴 하는데, 토큰을 엄청 잡아먹어. 첫 방에 완벽한 코드가 나오면 토큰 낭비인데, 매번 완벽할 거라고 믿을 수 있나?

맞아, 믿으면 안 되지! 평가자(Evaluator)한테 성공 기준을 명확히 주는 게 핵심이라는 말에 동감함. 평가자는 QA 같은 거라 제일 정교하게 다듬어야 해. 가드레일을 세우고 성공 기준을 명확히 줘서, 목표 달성하면 바로 루프를 끊게 만들어야 함. 나도 앞으로 평가자를 어떻게 더 개선할지, 그리고 사용자가 결과물에서 부족한 점을 발견했을 때 어떻게 그 부분만 다시 루프를 돌릴지 고민 중이야.

원문r/ClaudeAI