🤖 AI가 6시간 동안 앱을 혼자 만든다고? 앤트로픽의 멀티 에이전트 하네스 전략 파헤치기

 

"레트로 게임 만드는 앱 만들어줘" — 이 한 줄이 바꾼 모든 것

한 줄짜리 프롬프트를 던졌더니 AI가 6시간 동안 혼자 개발을 진행하고, 레벨 에디터·스프라이트 편집기·게임 플레이 모드까지 갖춘 앱을 뚝딱 만들어냈다면 어떤 느낌일까요?

이게 공상과학 얘기가 아닙니다. 앤트로픽(Anthropic)이 2026년 3월 공개한 엔지니어링 블로그 글, '장시간 실행 앱 개발을 위한 하네스 설계'에서 실제로 일어난 일을 공유했거든요.

이 실험이 흥미로운 건 단순히 "AI가 앱을 만들었어요"가 아닙니다. AI가 혼자 오랜 시간 동안 일관성을 유지하며 작동하게 만들려면 어떤 구조가 필요한지를 생생하게 보여줬다는 점에서 주목할 만합니다. AI 도구를 쓰는 분이라면, 특히 자동화 업무나 개발·기획 쪽에서 AI를 적극 활용 중이라면 오늘 이 내용을 꼭 알아두셨으면 해요.

AI 에이전트가 혼자 일하면 왜 중간에 무너질까요?

AI에게 복잡한 작업을 맡겨본 분이라면 공감하실 거예요. 처음엔 잘하다가 어느 순간 방향을 잃거나, 느닷없이 "이제 마무리하겠습니다"라고 선언하거나, 결과물이 뭔가 이상한데 본인은 "잘 됐습니다"라고 자평하는 상황이요.

앤트로픽 엔지니어링팀은 이런 현상을 두 가지 대표적인 실패 패턴으로 정리했어요.

첫 번째는 컨텍스트 불안(Context Anxiety)이라고 부르는 현상입니다. 대화 맥락이 쌓여서 컨텍스트 창이 가득 찼다고 느끼면 AI가 스스로 작업을 조기에 마무리하려 든다는 거예요. 마치 퇴근 시간이 다가오면 슬그머니 정리하기 시작하는 직원처럼요. 실제로 Claude Sonnet 4.5 시절에 이 현상이 두드러지게 나타났다고 합니다.

두 번째는 자기 평가의 한계입니다. AI에게 "네가 만든 거 어때?" 물어보면 거의 항상 "잘 됐습니다"라고 대답해요. 그런데 실제로 보면 버그가 넘치거나 기능이 작동을 안 하는 경우가 허다합니다. 자신이 만든 결과물을 스스로 객관적으로 평가하는 능력이 기본값에서는 매우 떨어지는 거죠.

이 두 가지를 해결하지 않으면, 아무리 좋은 모델을 써도 긴 작업은 제대로 완료되기 어렵습니다.

GAN에서 힌트를 얻다: 만드는 에이전트와 평가하는 에이전트를 분리하라

앤트로픽 연구자 Prithvi Rajasekaran은 딥러닝의 고전 아이디어인 GAN(생성적 적대 신경망)에서 해결책을 찾았습니다. GAN은 이미지를 생성하는 생성자와 그게 진짜인지 가짜인지 판별하는 판별자가 서로 경쟁하면서 품질을 끌어올리는 구조입니다. 이걸 AI 에이전트 설계에 그대로 적용한 거예요.

핵심은 이겁니다. 만드는 에이전트와 평가하는 에이전트를 완전히 분리하는 것.

같은 AI가 만들고 스스로 평가하면 칭찬 일색의 자기 평가가 나오지만, 별도 에이전트가 독립적으로 평가하면 훨씬 엄격하고 객관적인 피드백이 가능해집니다. 그 피드백이 다시 생성자에게 전달되는 반복 루프가 만들어지는 거죠.

이게 바로 하네스(Harness)의 본질입니다. 하네스란 AI가 잘 작동할 수 있도록 주변 환경을 구조적으로 설계하는 틀이라고 보시면 됩니다. 프롬프트를 잘 쓰는 게 아니라, AI가 작동하는 시스템 자체를 설계하는 거예요.

"이 디자인 예쁜가요?" 주관적인 판단도 점수로 만들 수 있다

이 아이디어를 처음 적용한 분야는 프론트엔드 디자인이었어요. AI가 만드는 UI 디자인은 기능은 멀쩡한데, 비주얼이 죄다 비슷비슷하다는 문제가 있거든요. 보라색 그라디언트에 흰색 카드, AI 스타일이 뭔지 딱 티가 나는 그런 것들이요.

앤트로픽은 평가자가 주관적 판단 대신 4가지 구체적인 기준으로 채점하도록 설계했어요.

첫째는 디자인 품질, 즉 색상·타이포그래피·레이아웃이 일관된 분위기를 만드는지입니다. 둘째는 독창성으로, AI가 흔히 쓰는 패턴이 등장하면 감점이에요. 셋째는 완성도, 간격·대비·폰트 위계 같은 기술적 실행력입니다. 넷째는 기능성, 사용자가 헷갈리지 않고 목적을 달성할 수 있는지입니다.

이 중에서 독창성과 디자인 품질에 더 높은 가중치를 뒀어요. Claude는 완성도와 기능성은 이미 기본으로 잘 했거든요. 문제는 늘 "무난하고 평범하다"는 점이었으니까요.

결과는 예상보다 훨씬 드라마틱했습니다. 반복이 거듭될수록 디자인이 점점 독창적으로 변했고, 한 실험에서는 네덜란드 미술관 웹사이트를 만들다가 열 번째 반복에서 CSS 원근법 기반 3D 갤러리를 만들어냈어요. 스크롤이나 클릭이 아니라 방 사이의 문을 통과해서 이동하는 방식이었습니다. 이런 창의적 발상은 한 번에 만들라고 해서는 절대 나오지 않죠. 반복적 피드백 루프가 만들어낸 결과입니다.

3에이전트 시스템: 플래너, 생성자, 평가자의 분업

프론트엔드 실험에서 얻은 자신감을 바탕으로, 이번엔 풀스택 앱 전체를 AI가 혼자 만드는 시스템을 구축했어요. 세 역할이 명확하게 분업하는 구조입니다.

플래너 에이전트는 한두 줄짜리 프롬프트를 받아 완전한 제품 기획서를 작성합니다. "레트로 게임 만드는 앱 만들어줘"라는 한 문장이 스프라이트 애니메이션 시스템, 사운드 이펙트, AI 기반 레벨 디자이너까지 포함한 16개 기능의 기획서로 확장됐어요.

생성자 에이전트는 그 기획서를 바탕으로 React, FastAPI, SQLite 스택으로 실제 코드를 구현합니다. 스프린트 단위로 하나씩 기능을 만들고, 완료하면 평가자에게 넘깁니다.

평가자 에이전트는 Playwright MCP를 활용해 실제 앱을 브라우저로 열고 직접 클릭하면서 버그를 잡아냅니다. 코드를 눈으로 보는 게 아니라, 사용자처럼 직접 조작해서 검증하는 거예요.

그리고 가장 독특한 부분이 있어요. 스프린트 계약 방식입니다. 생성자와 평가자가 코드 작성 전에 이번 스프린트에서 뭘 만들고 어떻게 검증할지를 먼저 합의합니다. 계약이 성사된 뒤에야 개발이 시작돼요. 개발 시작 전에 인수 조건을 먼저 정하는 방식, 어디서 많이 본 것 같지 않나요? 실제 개발팀이 하는 방식과 똑같습니다.

단독 실행 vs 풀 하네스: 9달러짜리 앱과 200달러짜리 앱의 차이

같은 프롬프트로 에이전트 혼자 실행한 결과와 3에이전트 하네스 시스템을 비교했는데, 결과 차이가 충격적이었어요.

단독으로 실행했을 때는 20분에 9달러, 그러니까 약 1만 3천 원으로 앱이 완성됐습니다. 화면에선 그럴듯해 보였는데요, 실제로 플레이해보니 캐릭터가 아무 반응도 하지 않았어요. 엔티티 정의와 게임 런타임 연결 코드가 잘못 짜여 있어서 겉으로만 앱처럼 보이는 껍데기였던 거죠.

풀 하네스 시스템은 6시간에 200달러, 약 29만 원이 들었어요. 단독 실행 대비 20배 이상 비쌌지만, 실제로 작동하는 게임이 완성됐고, AI로 스프라이트를 생성하고 레벨을 자동 설계하는 부가 기능까지 탑재됐습니다.

핵심 메시지는 이겁니다. 빠르고 싸게 만든 결과물이 쓸 수 없는 것보다 못할 수도 있다는 것. 특히 실제 사용자가 쓸 제품이라면 더욱 그렇습니다. 29만 원짜리가 비싸 보이지만, 쓸 수 없는 결과물을 만들기 위해 1만 3천 원을 쓰는 건 더 낭비예요.

모델이 좋아질수록 하네스는 단순해진다 — 그래도 하네스는 필요하다

흥미로운 관찰이 하나 더 있어요. 모델이 좋아질수록 복잡한 하네스가 필요 없어진다는 겁니다.

Claude Sonnet 4.5 시절에는 컨텍스트 불안이 심해서 스프린트 단위로 작업을 쪼개고, 세션 사이에 컨텍스트를 초기화하는 복잡한 구조가 꼭 필요했어요. 그런데 Opus 4.6으로 오니 그 문제가 자연스럽게 해결됐습니다. 스프린트 없이 하나의 긴 세션으로 실행했는데도, 모델이 2시간 7분을 쉬지 않고 작업하면서 결과물을 만들어냈어요.

데이터브릭스의 최신 보고서에 따르면 글로벌 기업들의 멀티에이전트 시스템 사용량이 단 4개월 만에 327% 증가했고, 가트너는 2026년까지 기업 애플리케이션의 40%가 작업 특화 AI 에이전트를 탑재할 것으로 예측했어요. 앤트로픽이 최근 공개한 Claude Managed Agents 퍼블릭 베타도 이 흐름 위에 있습니다. 세션 당 시간당 0.08달러의 런타임 비용으로 샌드박스 환경에서 에이전트를 장시간 실행할 수 있는 인프라예요.

모델이 발전할수록 이전에 필요했던 복잡한 구조가 사라지지만, 그 자리에 더 어려운 목표를 달성하기 위한 새로운 설계 과제가 들어옵니다. 설계 자체가 필요 없어지는 게 아니에요.

이 원칙, 개발자가 아닌 분들에게도 그대로 적용됩니다

앤트로픽의 실험이 개발자에게만 의미 있는 건 아니에요. AI 자동화 업무를 설계하는 분들, 기획·마케팅·운영 업무에서 AI를 적극 활용하시는 분들 모두에게 적용 가능한 원칙이 여기서 나옵니다.

첫째, AI에게 혼자 다 맡기지 말고 감독 구조를 만드세요. 만드는 역할과 검증하는 역할을 분리하면 품질이 극적으로 달라집니다. 콘텐츠를 생성하는 프롬프트와 그 콘텐츠를 평가하는 프롬프트를 따로 두는 것만으로도 차이가 납니다.

둘째, 주관적인 기준도 점수화하세요. "좋다/나쁘다"가 아니라 구체적인 항목으로 쪼개서 명시하면 AI가 그 기준에 맞춰 개선하기 시작합니다. 평가 기준이 명확할수록 결과물이 달라져요.

셋째, 새 모델이 나오면 기존 설계를 다시 검토하세요. 예전 모델의 약점을 보완하려고 만든 복잡한 구조가 새 모델에서는 오히려 불필요한 비용이 될 수 있습니다. 설계도 유지보수가 필요해요.

마무리

"AI가 알아서 다 해주겠지"라는 기대로 프롬프트 하나 던져놓으면 실망이 기다리고 있습니다. 하지만 AI가 잘 작동할 수 있는 구조를 설계하면 이야기가 완전히 달라집니다.

앤트로픽이 이번 실험을 통해 보여준 핵심은 이거예요. AI의 능력을 극대화하는 건 더 좋은 프롬프트가 아니라 더 나은 시스템 설계라는 것. 생성자와 평가자를 분리하고, 기준을 명확히 하고, 반복 피드백 루프를 만드는 것, 이게 2026년 AI 활용의 핵심 역량이 되고 있습니다.

AI를 쓰는 것과 AI를 잘 쓰는 것은 분명히 다릅니다. 그 차이를 만드는 건 결국 구조를 어떻게 설계하느냐에 달려 있어요. 지금 AI를 활용하고 계신다면, 오늘부터 프롬프트보다 구조를 먼저 생각해보세요.