같은 클로드인데 9달러 결과물은 멈추고 200달러 결과물은 움직인 이유 | DAKER 커뮤니티

같은 모델을 써도 결과가 전혀 다르게 나오는 순간이 있습니다. 겉으로는 그럴듯한 화면이 완성됐는데, 막상 눌러보면 핵심 기능이 비어 있는 경우입니다. 반대로 시간과 비용이 더 들더라도 실제로 동작하는 결과물이 나오는 경우도 있습니다.

이 차이는 모델 자체보다 구조에서 갈리는 경우가 많습니다. 퀀텀점프클럽이 Anthropic 엔지니어링 노트 Harness design for long-running application development(2026년 3월 24일, Prithvi Rajasekaran)를 30분에 압축한 영상을 바탕으로, 오늘 세션에 바로 적용할 수 있는 관점만 추려 봅니다.

차이는 모델이 아니다. 구조다.

같은 클로드인데 결과가 10배. $9 솔로와 $200 하네스
같은 클로드다. 왼쪽은 부탁만 한 솔로, 오른쪽은 목표·도구·평가가 잠긴 하네스.

솔로 에이전트는 20분, 9달러로 레트로 게임 메이커를 만들었습니다. 화면은 그럴듯했지만 플레이를 누르면 캐릭터가 움직이지 않았습니다. 같은 모델을 하네스에 넣자 6시간, 200달러가 들었고, 이번에는 실제로 움직였습니다. 더 센 모델을 기다리기보다, 이미 있는 모델이 스스로 못 하는 판단을 바깥 구조로 빼는 쪽이 먼저일 수 있습니다.

9달러짜리 결과물은 왜 멈췄나

프롬프트는 한 줄이었습니다. 레벨 에디터, 스프라이트 에디터, 엔티티 행동, 플레이 테스트가 있는 2D 레트로 게임 메이커를 만들라는 요청이었습니다. 솔로 런은 기대를 먼저 화면으로 보여줍니다. 패널이 있고, 캔버스가 있고, 플레이 버튼도 있습니다. 처음 몇 초는 완성된 것처럼 보입니다.

하지만 클릭하는 순간 빈칸이 드러납니다. 고정 높이 패널이 뷰포트를 낭비하고, 스프라이트와 엔티티를 먼저 만들라는 작업 순서가 UI에 드러나지 않습니다. 엔티티는 화면에 나타나지만 입력에 반응하지 않습니다. 코드 안에서는 엔티티 정의와 게임 런타임의 배선이 끊겨 있습니다. 겉은 앱처럼 보이지만 속은 더미에 가깝습니다.

이 실패는 모델이 멍청해서라기보다, 자기 작업을 후하게 채점하고 컨텍스트 창이 차면 일을 일찍 접는 성향에서 나옵니다.

반면 하네스 런은 같은 한 줄에서 시작했지만, 플래너가 이를 10개 스프린트와 16개 기능 스펙으로 키웠습니다. 스프라이트 애니메이션, 행동 템플릿, 효과음과 음악, AI 스프라이트·레벨 생성, 공유 링크 내보내기까지 범위를 넓혔고, 플래너에게 프론트 디자인 스킬을 읽게 하자 시각 언어도 스펙에 먼저 붙었습니다. 그 결과 캔버스가 화면을 채우고, 패널 비율이 맞아졌으며, 플레이 모드에서 캐릭터가 실제로 움직였습니다.

물론 완벽하지는 않았습니다. 점프가 플랫폼에 겹치는 거친 물리, 넘지 못하는 벽, 여전히 드러나지 않는 작업 순서 같은 UX 문제는 남았습니다. 그래도 핵심은 분명합니다. 안 되는 것과 되는 것의 차이가 생겼습니다.

겉은 앱이고 속은 더미인 상태를 넘기려면, 생성과 판정을 분리해야 한다.

모델이 혼자서 자주 실패하는 두 가지

Context Anxiety

컨텍스트 창이 차면 모델은 남은 기능을 대충 닫고 완료를 선언하는 경향이 있습니다. 컴팩션은 앞부분을 요약해 같은 세션을 이어 가지만, 불안의 원인이 창 안에 그대로 남습니다. 리셋은 다릅니다. 창을 비우고, 인수인계 문서만 남긴 채 다음 에이전트가 이어받습니다. 연속성은 파일에 두고, 세션의 머리는 비우는 방식입니다.

Sonnet 4.5에서는 이 리셋이 필수였다고 합니다. 다만 비용은 있습니다. 오케스트레이션, 토큰, 지연이 늘어납니다. 인수인계 파일에 다음 할 일과 현재 상태가 충분히 남아 있지 않으면, 리셋은 단순한 기억상실이 됩니다.

Self-Evaluation Bias

모델은 자기가 만든 결과물을 후하게 평가합니다. 디자인처럼 정답이 없는 영역에서는 특히 심하고, 테스트가 있는 코드에서도 큰 문제가 아니라며 통과시키는 일이 생깁니다. 그래서 만드는 자와 채점하는 자를 분리하는 구조가 필요해집니다.

평가자도 LLM이므로 관대한 성향이 완전히 사라지지는 않습니다. 그래도 관대한 생성기를 고치는 것보다, 회의적인 평가기를 키우는 편이 훨씬 쉽습니다. 바깥 피드백이 생기면 생성기는 비로소 맞설 기준을 갖게 됩니다.

자기 채점은 기록으로 남길 수 있어도, 통과 권한은 바깥 평가자에게 두는 편이 낫다.

플래너, 생성기, 평가기로 나누는 이유

이 구조는 생성과 판정을 한 모델에 맡기지 않는다는 점에서 GAN의 발상과 닿아 있습니다. Anthropic은 이를 프론트 실험에서 먼저 검증한 뒤, 풀스택 장시간 코딩으로 옮겼습니다.

플래너

플래너는 1~4문장짜리 요청을 제품 스펙으로 키웁니다. 여기서 중요한 점은 구현 디테일을 과하게 적지 않는다는 것입니다. 무엇을 납품할지만 잠그고, 경로는 만들면서 찾게 둡니다. 잘못된 스펙이 아래로 흘러가면 전체가 무너지기 때문에, 범위와 맥락을 잡는 역할이 중요합니다.

생성기

생성기는 한 기능씩 만듭니다. 예전 하네스는 스프린트 단위로 잘랐고, 매 스프린트 전에 평가기와 계약을 맺었습니다. 무엇이 완료인지, 무엇으로 시험할지를 코드보다 먼저 적는 방식입니다. 스펙이 일부러 높게 잡혀 있기 때문에, 이 계약이 유저 스토리와 시험 가능한 구현 사이를 이어 줍니다.

평가기

평가기의 핵심은 Playwright로 화면을 직접 클릭한다는 점입니다. 스크린샷만 보는 것이 아니라 UI, API, DB 상태를 사용자처럼 두드립니다. 스프린트 계약의 기준을 하나씩 검증하고, 하나라도 임계값 아래면 실패로 처리합니다.

예를 들어 3번 스프린트의 레벨 에디터는 기준이 27개였습니다. 사각형 채우기가 시작점과 끝점만 찍는 버그, 삭제 키 조건이 어긋난 버그, FastAPI가 reorder를 frame_id로 받아 422를 내는 문제처럼 로그가 구체적이어야 수정 비용이 줄어듭니다.

처음부터 평가기가 강했던 것은 아닙니다. 문제를 찾고도 괜찮다고 승인했고, 표면만 훑다가 가장자리 버그를 놓치기도 했습니다. 사람 판단과 어긋난 로그를 프롬프트에 여러 번 되먹인 뒤에야 QA 역할을 제대로 하기 시작했습니다. 그래도 더 깊은 기능이나 직관에 어긋나는 인터랙션, 작은 레이아웃 문제는 남았습니다. 다만 솔로 런처럼 핵심 기능이 아예 안 되는 상태와는 분명한 차이가 있었습니다.

디자인도 평가 기준이 있어야 달라진다

프론트 실험에서는 미를 점수로 바꿨습니다. 디자인 품질, 독창성, 크래프트, 기능을 기준으로 삼았고, 클로드는 크래프트와 기능은 기본적으로 해내는 편이어서 독창성과 품질의 가중치를 높였습니다. 보라색 그라데이션과 흰 카드 같은 슬롭을 감점하자 결과 방향도 달라졌습니다.

네덜란드 미술관 사이트 예시에서는 아홉 번째까지 평범한 다크 랜딩 페이지가 나왔고, 열 번째에 CSS 원근의 3D 전시실로 뒤집혔다고 합니다. 한 번에 나오지 않고 다섯에서 열다섯 번 정도 반복합니다. 점수는 대체로 오르지만, 중간 회차를 더 선호하는 경우도 있었습니다. 결국 기준 문장 하나가 결과의 성격을 강하게 밀어붙입니다. 박물관 급이라는 한 줄이 시각적 방향을 한쪽으로 모은 셈입니다.

부탁과 강제를 한 파일에 두지 않는 편이 좋다

CLAUDE.md는 요청입니다. 읽고 따르라는 메모는 어디까지나 부탁입니다. 반면 위험한 동작은 훅으로 잘라야 합니다. 부탁은 무시될 수 있지만, 훅은 우회가 어렵습니다.

영상에서 언급된 51개 에이전트, 85개가 넘는 스킬, 21개 보안 훅, 90개 규칙은 과시가 아니라 모델의 반복 실패를 메운 흔적에 가깝습니다. 중요한 것은 그 숫자를 복제하는 일이 아니라, 지금 반복해서 실패하는 구멍 하나를 골라 파일, 훅, 평가자 중 하나로 바깥에 빼는 일입니다.

규칙은 부탁이고, 훅은 강제다.

실제로는 다음 정도만 먼저 갖춰도 방향이 달라집니다.

그다음에는 실제로 배포까지 가는 것이 중요합니다. 화면이 예쁜 상태에서 멈추지 않고, 다른 사람이 링크를 열어 한 번 성공하는 지점까지 가야 합니다.

모델이 강해질수록 하네스는 다시 줄여야 한다

하네스의 모든 부품은 모델이 이 일을 혼자 못 한다는 가정 위에 있습니다. 그 가정이 틀렸거나 모델이 더 강해지면, 비계는 곧 비용이 됩니다. 그래서 한 번에 크게 줄이기보다 부품을 하나씩 떼어 보며 무엇이 실제 하중을 받는지 확인하는 편이 낫습니다.

예를 들어 Opus 4.5는 컨텍스트 리셋과 스프린트가 필요했습니다. 하지만 Opus 4.6이 더 오래, 더 큰 코드베이스에서 버티자 스프린트를 걷고 평가를 마지막 한 번으로 옮겼습니다. 플래너와 평가기는 남겼습니다. 플래너가 없으면 생성기는 범위를 작게 잡고 시작하고, 평가기는 모델이 혼자 잘하는 구간에서는 오버헤드가 되지만 가장자리 작업에서는 여전히 리프트를 줍니다.

검증 사례로는 브라우저 DAW가 제시됐습니다. 한 줄로 웹 오디오 기반의 풀 기능을 만들라는 요청이었고, 약 4시간, 125달러가 들었습니다. 빌더는 두 시간 넘게 한 세션으로 버텼고, 평가기는 1라운드에서 클립 드래그, 신스 패널, EQ 커브가 디스플레이만 있다고 지적했습니다. 2라운드에서는 마이크 녹음 스텁, 클립 분할, 그래픽 이펙터 문제를 다시 집어냈습니다.

생성기를 혼자 두면 핵심 기능이 껍데기로 남기 쉽고, 마지막 마일을 잡는 쪽은 평가기라는 점이 여기서도 드러납니다. 결과물은 프로툴스가 아니었고, 클로드는 소리를 듣지 못하므로 음악적 취향의 피드백 루프도 약합니다. 그래도 편곡 뷰, 믹서, 트랜스포트가 브라우저에서 움직였고, 에이전트가 템포와 키를 정하고 멜로디와 드럼을 깔고 리버브를 넣을 수 있었습니다.

더 센 모델을 기다리기보다, 모델이 스스로 못 하는 판정을 구조로 빼는 쪽이 먼저다.

오늘 세션에 바로 심을 최소 구조

처음부터 새 에이전트 51개를 깔 필요는 없습니다. 지금 쓰는 클로드코드 창 하나에 아래 네 칸만 넣어도 출발점이 달라집니다.

  1. 한 줄 목표. 오늘 배포 링크에서 다른 사람이 성공해야 하는 동작 하나.
  2. 금지 경로. 예전에 실패했거나 더 이상 쓰지 않는 파일, API, 폴더.
  3. 완료 증거. 평가자가 브라우저에서 클릭해 확인할 문장 하나.
  4. 실패 승격. 같은 구멍이 두 번 나오면 그 구멍을 훅으로 옮기는 규칙.

이 네 칸이 갖춰진 뒤에 플래너와 평가기를 붙이면 됩니다. 칸이 비어 있으면 에이전트를 늘려도 같은 더미가 반복될 가능성이 큽니다.

참고 자료

원문 영상: https://www.youtube.com/watch?v=UJckFZ_nsrw

원문 노트: https://www.anthropic.com/engineering/harness-design-long-running-apps

지금 쓰는 에이전트 워크플로에서 가장 자주 무너지는 구멍은 어디인지, 비슷한 경험이 있다면 어떤 구조로 바깥에 빼고 있는지 궁금합니다.