하네스 설계: 장기 실행 애플리케이션 개발의 새로운 패러다임

Executive Summary

핵심 요약

GAN 영감의 멀티 에이전트 구조: 생성적 적대 신경망(GAN)에서 차용한 생성기(Generator)-평가기(Evaluator) 패턴을 소프트웨어 개발에 적용하여, AI가 자체 결과물을 객관적으로 평가하지 못하는 근본적 문제를 해결했다.

프론트엔드 디자인 품질의 정량적 평가: "이 디자인이 아름다운가?"라는 주관적 질문을 디자인 품질·독창성·기술력·기능성이라는 네 가지 채점 기준으로 구조화하고, 평가기 에이전트에게 실제 브라우저를 탐색하며 채점하도록 했다.

3-에이전트 풀스택 아키텍처: 기획자(Planner), 생성기(Generator), 평가기(Evaluator) 세 에이전트가 각각 스펙 작성, 스프린트 기반 구현, QA 테스트를 담당하는 협업 구조로, 수시간에 걸친 자율 코딩 세션에서 완전한 풀스택 앱을 만들어냈다.

모델 진화에 따른 하네스 경량화: Opus 4.5에서 Opus 4.6으로 업그레이드하면서 스프린트 분해 구조를 완전히 제거해도 2시간 이상 일관된 코딩이 가능해졌다. 하네스는 모델 발전에 따라 단순해지는 것이 아니라 이동한다.

비용 대비 품질의 극적 차이: 레트로 게임 메이커 구현에서 단일 에이전트($9, 20분)는 핵심 기능이 작동하지 않았으나, 풀 하네스($200, 6시간)는 실제로 플레이 가능한 게임을 제작했다. DAW 프로젝트는 하네스 v2로 $125, 약 4시간 만에 브라우저 기반 음악 제작 프로그램을 구현했다.

Key Person

핵심 인물

Full Translation

본문 번역

단순한 구현은 왜 한계에 부딪히는가

Anthropic은 이전 연구에서 하네스 설계가 장기 실행 에이전틱 코딩의 효과에 상당한 영향을 미친다는 것을 보여준 바 있다. 초기 실험에서는 초기화 에이전트(initializer agent)가 제품 스펙을 작업 목록으로 분해하고, 코딩 에이전트가 한 번에 하나의 기능씩 구현한 뒤 세션 간 아티팩트를 넘기는 방식을 사용했다. 개발자 커뮤니티에서도 "랄프 위검(Ralph Wiggum)" 방법론처럼 훅이나 스크립트로 에이전트를 지속적 반복 사이클에 묶어두는 유사한 접근법이 등장했다.

그러나 몇 가지 문제는 끈질기게 남았다. 복잡한 작업에서 에이전트는 시간이 지날수록 방향을 잃는 경향이 있었다. 이 문제를 분해해 보면 두 가지 공통된 실패 모드가 관찰된다.

첫째, 모델은 컨텍스트 윈도우가 채워지면서 장시간 작업의 일관성을 잃는다. 일부 모델은 컨텍스트 불안(context anxiety)이라는 현상을 보이는데, 자신이 컨텍스트 한계에 다가가고 있다고 판단하면 작업을 조기에 마무리하려 한다. 컨텍스트 리셋(context reset) — 컨텍스트 윈도우를 완전히 비우고 이전 에이전트의 상태와 다음 단계를 담은 구조화된 핸드오프와 함께 새 에이전트를 시작하는 것 — 이 이 두 문제를 모두 해결한다. 이전 테스트에서 Claude Sonnet 4.5는 컨텍스트 불안이 강해서 컴팩션(compaction)만으로는 충분하지 않았고, 컨텍스트 리셋이 하네스 설계의 필수 요소가 되었다.

둘째, 이전에 다루지 않았던 문제로 자기 평가(self-evaluation)가 있다. 자신이 만든 결과물을 평가하라고 하면, 에이전트는 인간 관찰자에게 품질이 명백히 평범해 보이는 경우에도 자신감 넘치는 칭찬으로 응답하는 경향이 있다. 이 문제는 디자인처럼 검증 가능한 소프트웨어 테스트에 해당하는 이진 검사가 없는 주관적 작업에서 특히 두드러진다. 그러나 검증 가능한 결과가 있는 작업에서도 에이전트는 여전히 좋지 않은 판단을 보일 때가 있다. 작업을 수행하는 에이전트와 판단하는 에이전트를 분리하는 것이 이 문제를 해결하는 강력한 레버가 된다.

프론트엔드 디자인: 주관적 품질을 채점 가능하게 만들기

저자는 자기 평가 문제가 가장 두드러지는 프론트엔드 디자인에서 실험을 시작했다. 아무런 개입 없이 두면 Claude는 기술적으로 기능하지만 시각적으로 눈에 띄지 않는 안전하고 예측 가능한 레이아웃으로 수렴한다.

두 가지 통찰이 하네스를 형성했다. 첫째, 미학을 완전히 점수로 환원할 수는 없지만, 디자인 원칙과 선호를 인코딩하는 채점 기준으로 개선할 수 있다. "이 디자인이 아름다운가?"는 일관되게 답하기 어렵지만, "이것이 우리의 좋은 디자인 원칙을 따르는가?"는 Claude에게 구체적으로 채점할 거리를 준다. 둘째, 프론트엔드 생성과 채점을 분리함으로써 생성기를 더 강한 결과물로 몰아가는 피드백 루프를 만들 수 있다.

이를 바탕으로 생성기와 평가기 에이전트 모두에게 주어지는 네 가지 채점 기준을 작성했다:

디자인 품질(Design Quality): 색상, 타이포그래피, 레이아웃, 이미지 등이 결합되어 뚜렷한 분위기와 정체성을 만들어내는가. 독창성(Originality): 의도적인 창의적 결정이 보이는가, 아니면 템플릿 레이아웃과 라이브러리 기본값, AI 생성 패턴인가. 보라색 그라데이션 위 흰색 카드 같은 "AI 슬럽" 패턴은 여기서 감점이다. 기술력(Craft): 타이포그래피 위계, 간격 일관성, 색상 조화, 대비비 같은 기술적 실행. 기능성(Functionality): 미학과 독립적인 사용성.

디자인 품질과 독창성에 더 높은 가중치를 부여했다. Claude는 기본적으로 기술력과 기능성에서 이미 좋은 점수를 받고 있었기 때문이다.

Claude Agent SDK 위에 루프를 구축했다. 생성기 에이전트가 사용자 프롬프트에 기반해 HTML/CSS/JS 프론트엔드를 만든다. 평가기에는 Playwright MCP를 부여하여, 점수를 매기기 전에 실제 페이지와 직접 상호작용하고 스크린샷을 캡처할 수 있게 했다. 그 피드백이 다시 생성기의 다음 반복 입력으로 흘러간다. 생성당 5~15회 반복을 실행했으며, 전체 실행은 최대 4시간까지 소요되었다.

인상적인 사례가 하나 있다. 네덜란드 미술관 웹사이트를 만들라는 프롬프트에서, 9번째 반복까지는 깔끔한 다크 테마 랜딩 페이지를 세련되게 다듬었다. 그런데 10번째 사이클에서 기존 접근을 완전히 폐기하고 사이트를 공간적 경험으로 재구상했다. CSS 원근법으로 렌더링된 체크무늬 바닥의 3D 방, 벽면에 자유로운 위치로 걸린 작품, 스크롤이나 클릭 대신 출입구 기반 갤러리 탐색. 단일 패스 생성에서는 본 적 없는 종류의 창의적 도약이었다.

풀스택 코딩으로의 확장

3-에이전트 아키텍처

이전 하네스에서는 초기화 에이전트, 한 번에 한 기능씩 작업하는 코딩 에이전트, 세션 간 컨텍스트 리셋으로 일관성 있는 멀티 세션 코딩을 해결했다. Opus 4.5는 컨텍스트 불안을 대부분 자체적으로 제거했기 때문에 이 하네스에서는 컨텍스트 리셋을 완전히 삭제할 수 있었다. 에이전트들은 전체 빌드에 걸쳐 하나의 연속 세션으로 실행되었고, Claude Agent SDK의 자동 컴팩션이 컨텍스트 성장을 처리했다.

기획자(Planner): 이전 하네스는 사용자가 상세한 스펙을 직접 제공해야 했다. 이 단계를 자동화하기 위해 1~4문장의 간단한 프롬프트를 전체 제품 스펙으로 확장하는 기획자 에이전트를 만들었다. 세부적인 기술 구현이 아닌 제품 컨텍스트와 고수준 기술 설계에 집중하도록 프롬프팅했다. 기획자가 세분화된 기술 세부사항을 미리 지정하다 잘못되면, 스펙의 오류가 하위 구현으로 연쇄 전파될 수 있기 때문이다. AI 기능을 제품 스펙에 엮어 넣을 기회를 찾도록 지시하기도 했다.

생성기(Generator): 이전 하네스의 한 번에 한 기능 접근법이 범위 관리에 효과적이었기에 유사한 모델을 적용했다. 생성기에게 스프린트(Sprint) 단위로 작업하며 스펙에서 한 번에 하나의 기능을 가져오도록 지시했다. 각 스프린트는 React + Vite + FastAPI + SQLite(후에 PostgreSQL) 스택으로 앱을 구현했다.

평가기(Evaluator): 이전 하네스의 애플리케이션은 인상적으로 보였지만 실제로 사용해 보면 진짜 버그가 있었다. 이를 잡기 위해 평가기가 Playwright MCP로 실행 중인 애플리케이션을 사용자처럼 클릭하며 탐색하고, UI 기능·API 엔드포인트·데이터베이스 상태를 테스트했다. 각 스프린트를 프론트엔드 실험에서 적용한 기준(제품 깊이, 기능성, 시각 디자인, 코드 품질)으로 채점했고, 어떤 기준이라도 경계값 아래로 떨어지면 해당 스프린트는 실패 처리되어 생성기에 상세 피드백이 전달되었다.

각 스프린트 전에 생성기와 평가기는 스프린트 계약(Sprint Contract)을 협상했다. 코드를 한 줄도 작성하기 전에 해당 작업 단위의 "완료"가 무엇인지 합의하는 것이다. 에이전트 간 커뮤니케이션은 파일을 통해 처리됐다. 한 에이전트가 파일을 쓰면 다른 에이전트가 읽고 응답하는 방식이었다.

하네스 실행 결과: 레트로 게임 메이커

프롬프트: "레벨 에디터, 스프라이트 에디터, 엔티티 행동, 플레이 가능한 테스트 모드를 포함한 2D 레트로 게임 메이커를 만들어라."

단일 에이전트(Solo)는 20분에 $9로 완성했지만, 풀 하네스는 6시간에 $200가 소요됐다. 비용은 20배 이상 차이 났지만, 결과물의 품질 차이는 즉각적으로 드러났다.

단일 에이전트 결과: 초기 화면은 기대에 부합하는 것처럼 보였으나, 실제로 클릭해 보니 레이아웃이 공간을 낭비하고 워크플로우가 경직되어 있었다. 가장 중요한 문제는 게임 자체가 작동하지 않았다는 것이다. 엔티티는 화면에 나타났지만 입력에 반응하지 않았다. 코드를 살펴보니 엔티티 정의와 게임 런타임 간의 배선이 끊어져 있었다.

풀 하네스 결과: 기획자가 원래의 한 문장 프롬프트를 10개 스프린트에 걸친 16개 기능 스펙으로 확장했다. 코어 에디터와 플레이 모드 외에도 스프라이트 애니메이션 시스템, 행동 템플릿, 사운드 효과, AI 지원 스프라이트 생성기와 레벨 디자이너, 공유 가능 링크를 통한 게임 내보내기까지 포함되었다. 실제로 캐릭터를 움직이고 게임을 플레이할 수 있었다. 물리 엔진에 거친 부분이 있었지만 핵심은 작동했다.

평가기가 실제로 잡아낸 버그들

평가기의 발견은 구체적이고 실행 가능했다. 스프린트 3에서만 레벨 에디터에 대한 27개 기준이 있었다. 예를 들어: 사각형 채우기 도구가 드래그 시작/끝 지점에만 타일을 배치하고 영역을 채우지 않는 버그, 엔티티 삭제 핸들러의 조건문 오류, FastAPI의 라우트 순서 문제로 'reorder'를 정수로 파싱하려다 422 오류가 발생하는 문제 등이었다.

평가기가 이 수준으로 작동하게 하려면 상당한 튜닝이 필요했다. 기본 상태의 Claude는 형편없는 QA 에이전트다. 초기 실행에서 정당한 문제를 식별해 놓고도 별 문제가 아니라고 스스로를 설득한 뒤 작업을 승인하는 것을 목격했다. 평가기의 로그를 읽고, 저자의 판단과 차이가 나는 예시를 찾아 QA 프롬프트를 업데이트하는 과정을 여러 차례 반복한 뒤에야 합리적인 채점이 가능해졌다.

하네스의 반복 개선

첫 번째 하네스 결과는 고무적이었지만, 부피가 크고 느리고 비쌌다. 논리적 다음 단계는 성능을 저하시키지 않으면서 단순화하는 방법을 찾는 것이었다. 하네스의 모든 컴포넌트는 "모델이 스스로 할 수 없는 것"에 대한 가정을 인코딩하며, 그 가정은 스트레스 테스트할 가치가 있다 — 틀렸을 수도 있고, 모델이 개선되면서 금방 낡아질 수도 있기 때문이다.

스프린트 구조 제거

Opus 4.6의 출시와 함께 하네스 복잡도를 줄일 동기가 더 강해졌다. 출시 블로그에서 언급된 것처럼 "Opus 4.6은 더 신중하게 계획하고, 에이전틱 작업을 더 오래 지속하며, 더 큰 코드베이스에서 안정적으로 작동하고, 자체 실수를 잡아내는 코드 리뷰 및 디버깅 능력이 향상되었다." 이 모든 것이 하네스가 보충해 왔던 역량이었다.

스프린트 구조를 완전히 제거했다. 기획자와 평가기는 유지했다. 기획자 없이는 생성기가 범위를 축소했고, 평가기 없이는 여전히 빈틈이 남았다. 평가기를 스프린트별이 아닌 빌드 마지막에 한 번만 실행하는 것으로 변경했다.

모델 역량이 높아지면서 평가기의 부하 지지(load-bearing) 정도가 작업에 따라 달라졌다. 4.5에서는 빌드가 생성기의 한계 근처에 있었기에 평가기가 의미 있는 문제를 잡았다. 4.6에서는 모델의 기본 역량이 높아져 그 경계가 바깥으로 이동했다. 이전에 평가기의 검증이 필요했던 작업이 이제 생성기 혼자서도 충분히 잘 처리하게 되었지만, 여전히 생성기 역량의 경계에 있는 부분에서는 평가기가 실질적 개선을 제공했다.

결과: 브라우저 기반 DAW

프롬프트: "Web Audio API를 사용하여 브라우저에서 완전한 기능을 갖춘 DAW(디지털 오디오 워크스테이션)를 만들어라."

실행 시간은 약 4시간, 토큰 비용은 $124.70이었다. 대부분의 시간은 빌더가 차지했으며, 스프린트 분해 없이도 2시간 넘게 일관되게 작동했다. 기획자는 4.7분에 $0.46, 1차 빌드는 2시간 7분에 $71.08, 1차 QA는 8.8분에 $3.24 식으로 진행되었다.

QA 에이전트는 여전히 실질적 빈틈을 발견했다. 1차 피드백에서 "앱이 인상적으로 보이고 AI 통합도 잘 작동하지만, 핵심 DAW 기능 여럿이 인터랙티브 깊이 없이 표시만 되고 있다"고 지적했다. 클립 드래그/이동, 악기 UI 패널(신스 노브, 드럼 패드), 시각적 이펙트 에디터(EQ 커브, 컴프레서 미터) 등이 빠져 있었다. 2차 피드백에서도 오디오 녹음 스텁, 클립 리사이즈, 이펙트 시각화 등의 누락을 잡아냈다.

최종 앱은 전문 음악 프로그램과는 거리가 있고, 에이전트의 작곡 능력도 미흡했다. 또한 Claude는 실제로 소리를 들을 수 없어서 QA 피드백 루프가 음악적 취향에 관해서는 덜 효과적이었다. 하지만 작동하는 어레인지먼트 뷰, 믹서, 트랜스포트가 모두 브라우저에서 구동되었고, 프롬프팅만으로 짧은 곡 스니펫을 만들 수 있었다. 에이전트가 템포와 키를 설정하고, 멜로디를 깔고, 드럼 트랙을 구성하고, 믹서 레벨을 조정하고, 리버브를 추가했다.

앞으로의 방향

모델이 계속 개선되면 더 오래, 더 복잡한 작업을 수행할 수 있게 된다. 어떤 경우에는 모델 주변의 스캐폴딩이 시간이 지나면서 덜 중요해지고, 다음 모델을 기다리면 특정 문제가 저절로 해결될 것이다. 반면, 모델이 나아질수록 기본 성능으로는 불가능했던 복잡한 작업을 하네스로 달성할 수 있는 공간도 넓어진다.

이 작업에서 얻은 교훈들: 작업 대상 모델을 실제 문제에 대해 실험하고, 트레이스를 읽고, 원하는 결과를 달성하도록 성능을 튜닝하는 것이 항상 좋은 관행이다. 복잡한 작업에서는 과제를 분해하고 각 측면에 특화된 에이전트를 적용함으로써 추가적인 성능 향상 여지가 있다. 새 모델이 나오면 하네스를 재검토하여, 더 이상 성능에 필수적이지 않은 부분을 걷어내고 이전에는 불가능했던 새로운 역량을 추가하는 것이 일반적으로 좋은 관행이다.

흥미로운 하네스 조합의 공간은 모델이 개선됨에 따라 줄어드는 것이 아니다. 이동할 뿐이다. AI 엔지니어에게 흥미로운 일은 다음의 새로운 조합을 계속 찾는 것이다.

Glossary

주요 키워드 정리

하네스 (Harness)

AI 에이전트의 행동을 제어·조율하는 외부 프레임워크. 프롬프트, 도구, 컨텍스트 관리, 에이전트 간 핸드오프 등을 포함하는 오케스트레이션 시스템이다.

컨텍스트 불안
(Context Anxiety)

모델이 컨텍스트 윈도우 한계에 가까워졌다고 판단할 때 작업을 조기에 마무리하려는 경향. Sonnet 4.5에서 강하게 관찰되었으나 Opus 4.5 이후 크게 완화되었다.

컨텍스트 리셋
(Context Reset)

컨텍스트 윈도우를 완전히 비우고 구조화된 핸드오프 아티팩트와 함께 새 에이전트를 시작하는 기법. 컴팩션과 달리 완전한 백지 상태를 제공한다.

컴팩션 (Compaction)

대화 이력의 초반부를 요약하여 같은 에이전트가 단축된 기록으로 계속 작업하는 방식. 연속성은 유지하지만 완전한 백지 상태를 주지 않는다.

스프린트 계약
(Sprint Contract)

각 스프린트 시작 전에 생성기와 평가기가 "완료"의 정의를 합의하는 프로세스. 코드 작성 전에 테스트 기준을 명확히 한다.

Playwright MCP

브라우저 자동화 도구 Playwright를 MCP(Model Context Protocol) 서버로 제공하여, 에이전트가 실행 중인 앱과 직접 상호작용할 수 있게 하는 도구.

AI 슬럽 (AI Slop)

AI 생성 콘텐츠의 전형적이고 무개성한 패턴. 보라색 그라데이션 위 흰색 카드, 수정 없는 기본 컴포넌트, Inter 폰트 사용 등이 대표적 예시다.

Claude Agent SDK

Anthropic의 범용 에이전트 하네스. 코딩을 비롯한 다양한 도구 사용 작업에 적합하며, 자동 컴팩션 등 컨텍스트 관리 기능을 내장하고 있다.

Fact Check

팩트체크

✓ 사실 확인됨

GAN(생성적 적대 신경망)에서 두 모델이 경쟁하는 구조를 소프트웨어 개발에 적용했다는 설명

GAN은 실제로 생성자(Generator)와 판별자(Discriminator) 두 네트워크의 적대적 학습 구조다. 이 글에서 설명하는 생성기-평가기 패턴은 GAN의 수학적 학습 과정을 직접 복제한 것은 아니지만, "한 에이전트가 만들고 다른 에이전트가 판단한다"는 구조적 영감으로서의 비유는 정확하다.

✓ 사실 확인됨

Opus 4.6 출시 블로그에서 언급된 개선 사항(더 신중한 계획, 에이전틱 작업 지속력, 코드 리뷰 능력 등)

해당 인용은 Anthropic의 공식 출시 블로그 포스트의 내용과 일치한다. Opus 4.6은 2026년 초에 출시되었으며, 장기 컨텍스트 처리와 에이전틱 코딩 성능의 상당한 개선이 공식적으로 발표되었다.

⚡ 맥락 보충 필요

풀 하네스($200, 6시간) vs 단일 에이전트($9, 20분)의 비교에서 결과물 품질 차이가 "즉각적으로 드러났다"는 주장

정성적 비교에서 풀 하네스의 우위는 분명하다(핵심 게임 기능의 작동 여부). 그러나 이 글에는 정량적 성공 지표(완성된 기능 수, 버그 밀도, 사용자 테스트 점수 등)가 제시되지 않았다. 또한 비용 효율성 관점에서 $200은 현재 일반 개발자 워크플로우의 경제성과 비교할 때 상당한 금액이며, 6시간의 실행 시간도 실무 적용 시 고려해야 할 제약이다. 결과물의 질적 우위는 인정되지만, 이를 범용적으로 적용할 때의 비용-편익 분석은 아직 미완이다.

△ 부분적 맥락

"Ralph Wiggum" 방법론을 개발자 커뮤니티의 유사한 접근법으로 소개

이 방법론은 Geoffrey Huntley가 소개한 것으로, 에이전트를 지속적 반복 사이클에 묶어두는 훅/스크립트 기반 접근법을 지칭한다. 다만 이것이 개발자 커뮤니티에서 광범위하게 수렴한 접근법이라기보다는 여러 실험적 방법론 중 하나로 보는 것이 더 정확하다.

Claude Insights

Claude 인사이트

분석 관점

"하네스는 사라지지 않는다, 이동한다" — 이 글의 가장 중요한 통찰

이 블로그 포스트에서 가장 주목할 만한 메타 교훈은 마지막에 등장한다. 모델이 좋아지면 하네스가 불필요해질 것이라는 직관적 예측 대신, 저자는 하네스가 필요한 영역이 이동할 뿐이라는 관점을 제시한다. Sonnet 4.5에서 필수적이었던 컨텍스트 리셋이 Opus 4.5에서 불필요해졌고, Opus 4.5에서 필수적이었던 스프린트 분해가 Opus 4.6에서 불필요해졌다. 그러나 매번 새로운 하네스 컴포넌트(기획자, 보다 정교한 평가기, AI 기능 통합 프롬프팅)가 추가되었다.

이것은 AI 엔지니어링의 장기적 가치에 대한 중요한 시사점이다. "프롬프트 엔지니어"의 역할이 일시적이라는 비관론과 달리, 에이전트 하네스 설계는 모델 발전과 함께 진화하는 엔지니어링 분야라는 논거를 제공한다.

놓친 관점

자기 평가 실패의 더 깊은 함의

이 글은 에이전트의 자기 평가 실패를 실용적 문제로 다루지만, 이것은 현재 LLM의 더 근본적인 특성을 반영한다. 모델이 자신의 출력을 일관되게 비판하지 못하는 것은 단순한 "관대함"이 아니라, 생성 과정과 평가 과정이 동일한 가중치 공간에서 작동하기 때문에 발생하는 구조적 편향일 가능성이 높다. 같은 분포에서 샘플링된 출력을 같은 분포로 평가하면 본질적으로 긍정 편향이 발생한다.

이 관점에서 보면 생성기-평가기 분리는 단순한 실용적 해결책이 아니라, 현재 아키텍처 하에서 자기 비판의 근본적 어려움에 대한 우회 전략이다. 향후 모델이 메타인지(metacognition) 능력을 갖추게 된다면 이 구조도 또 한 번 이동할 것이다.

더 넓은 맥락

비용 구조의 현실적 함의

이 글이 다루지 않는 중요한 측면은 경제적 접근성이다. 레트로 게임 메이커 하나에 $200, DAW에 $125라는 비용은 실험적 연구로서는 합리적이지만, 일반 개발자의 일상 워크플로우에 통합하기에는 상당한 장벽이다. 현재 프리랜서 개발자의 시급을 고려하면 6시간 자율 코딩의 비용이 인간 개발자의 동일 시간 비용과 비교되기 시작하는 지점에 있다.

그러나 비용의 추세를 보면 이야기가 달라진다. API 가격은 지속적으로 하락하고 있고, 모델 효율성은 향상되고 있다. Opus 4.6에서 스프린트 분해를 제거한 것만으로도 상당한 토큰 절약이 가능해졌다. 현재 $200짜리 작업이 6개월 후에는 $30~50 수준으로 내려올 가능성이 높다. 이 시점이 되면 "AI 에이전트가 처음부터 끝까지 앱을 만든다"는 것이 실험실의 데모가 아니라 실무 옵션이 된다.