루프 자체가 제품이다 — 차세대 AI 에이전트의 설계 원리

URL: https://www.youtube.com/watch?v=cv2_Lzvd1mk
날짜: 2026-09-30
채널: Tech Bridge
발표자: 롤랜드 가브릴레스쿠(Roland Gavrilescu), Introspection 공동 창업자·xAI 출신
발표 맥락: AI Engineer World's Fair

---

📌 핵심 질문 / 전체 논지

==상용 AI 에이전트의 경쟁력은 단일 모델이나 프레임워크가 아니라, 작업 루프를 운영하고 그 결과를 다음 루프의 개선 재료로 증류하는 제품 시스템에 있다.==

• 에이전트는 도구를 호출하고 관찰하고 행동하는 OODA(Observe–Orient–Decide–Act) 루프를 반복한다.
• 신호(signal)의 품질과 결과를 판정하는 검증기(verifier)의 품질이 루프의 성공률과 신뢰도를 결정한다.
• 실패 패턴·반복 행동·사용자 불만을 평가기준·스킬·프롬프트·메모리로 바꾸는 시스템 증류가 플랫폼과 모델에 종속되지 않는 해자가 된다.
• 제품이 만들어내는 가치와 그 가치를 얻기 위해 소비한 연산량의 비율인 ‘와트당 가치 있는 작업량(value of work per watt)’이 최종 경영 지표가 된다.

초기의 AI 제품은 모델을 더 잘 훈련하는 RLHF에서 출발해, 모델을 감싸는 하네스(harness) 중심으로 이동했다. 이제는 하네스가 호출하는 장기 실행 루프 자체를 설계하고, 프로덕션에서 쌓인 결과를 다시 루프와 평가에 반영하는 단계로 넘어간다. 제작자의 안목(taste)을 명시적인 평가와 실험으로 옮기면, 에이전트는 단순히 정답을 내는 도구가 아니라 제작자가 좋은 결과라고 판단하는 방식을 반복 생산하는 서비스가 된다.

1. 루프 자체가 제품이다

모델 호출 한 번의 품질보다 관찰·행동·검증·재시도를 묶은 루프의 설계가 고객에게 전달되는 실제 제품 경험을 좌우한다.

1.1. 모델에서 하네스, 하네스에서 루프로 이동한 제품 계층

1. 모델 중심 단계

   1. RLHF와 추론 능력 개선: 초기 관심사는 모델을 어떻게 훈련해 더 나은 reasoning을 하게 만들지에 있었다.
   2. 모델의 상품화: 여러 모델이 비슷한 능력을 제공하면서 모델 자체는 commodity가 되고, 어떤 작업 순서와 도구를 붙이느냐가 중요해졌다.

2. 하네스 중심 단계

   1. 하네스의 역할: 하네스는 모델에 도구, 시스템 지침, 실행 환경, 보조 에이전트를 연결해 실제 업무를 수행하게 한다.
   2. 코드 이후의 설계: 이제는 코드를 계속 손으로 추가하는 대신, 반복되는 작업과 평가를 루프로 구조화해 제품의 개선 장치를 만든다.

3. 루프 중심 단계

   1. 항상 켜진 장기 작업: xAI에서 에이전트 인프라를 만들던 롤랜드와 공동 창업자는 always-on·long-running·long-horizon 작업을 독립 제품으로 배포할 필요성을 발견했다.
   2. 독립 창업으로의 전환: 두 사람은 발표 시점 기준 몇 달 전 xAI를 떠나, 이런 장기 실행 시스템을 고객과 함께 확장 가능한 제품으로 만드는 방법을 연구하기 시작했다.

1.2. OpenClaw 자동차 협상 사례가 보여준 루프

1. 문제와 목표

   1. 목표: 자동차를 가능한 한 큰 할인으로 구매한다.
   2. 핵심 관점: 단순히 “차를 찾아 달라”고 요청하는 것이 아니라, 가격·재고·딜러 협상을 연속 작업으로 묶어야 한다.

2. 네 단계의 실행 루프

   1. 시장 탐색: Reddit에서 실제 구매자들이 공유한 가격을 찾고, 여러 판매처의 재고와 조건을 조사한다.
   2. 딜러 접촉: 딜러에게 직접 연락해 가격을 확인한다.
   3. 경쟁 유도: 여러 딜러를 서로 비교하게 만들어, 각 딜러가 더 좋은 조건을 제시하도록 한다.
   4. 검증과 잠금: 가격이 정말 좋은지 확인할 수 있는 검증 방법을 마련한 뒤 거래를 확정하고 자동차를 구매한다.

3. 사례의 제품적 의미

   1. 작업 순서가 가치의 원천: Reddit 검색, 재고 확인, 협상, 가격 검증을 각각 잘하는 모델보다 이 네 단계를 안정적으로 반복하는 루프가 실제 할인이라는 결과를 만든다.
   2. 제품으로 독립할 수 있는 구조: 이런 루프가 반복적으로 작동한다면 단순한 개인용 자동화가 아니라 자동차 구매를 위한 스타트업이 될 수 있다.
   3. 초기 OpenClaw 맥락: 발표자는 당시 Clawbot으로 불리던 초기 OpenClaw 주변에서 이 루프가 만들어졌다고 소개하며, 에이전트가 현실의 거래를 끝까지 밀어붙이는 사례로 들었다.

1.3. OODA 루프와 신호·검증기의 결합

1. OODA의 기원과 에이전트 적용

   1. 군사적 배경: OODA는 1970년대 미국 공군에서 빠르게 변하는 전투 환경에 전투기가 대응하는 방법을 설명하기 위해 쓰인 용어다.
   2. 에이전트의 대응 구조: 에이전트는 도구를 호출하고(행동), 결과를 관찰하고, 상황을 해석하고, 다음 결정을 내리는 순환을 수행한다.

2. 강한 신호와 검증 가능한 작업

   1. 신호(signal): 에이전트가 무엇을 해야 하는지 알려 주는 입력과 중간 피드백이 충분히 구체적이고 신뢰할 수 있어야 한다.
   2. 검증기(verifier): 결과가 실제 성공인지, 겉보기에 그럴듯한 실패인지 판정해야 한다.
   3. 성공률의 결정식: 신호의 품질이 루프의 성공 가능성을 높이고, 검증기의 품질이 그 성공 판정의 정확도를 조정한다.

3. 두 번째 루프의 시작

   1. 첫 루프의 산출물: 첫 번째 실행은 최종 답뿐 아니라 trace, 도구 사용 기록, 실패 지점, 하네스 설정, 평가 결과 같은 다양한 artifact를 남긴다.
   2. 개선 루프: 이 산출물을 다시 신호로 넣어 무엇을 바꿀지 판단하고, 개선된 시스템으로 다음 작업을 수행한다.
   3. 지속적 자기개선: 루프가 한 번의 실행으로 끝나지 않고, 첫 실행에서 얻은 정보를 두 번째·세 번째 루프의 입력으로 전환할 때 ‘루프 자체가 제품’이라는 명제가 성립한다.

2. 시스템 증류가 진짜 해자다

모델이나 특정 제공업체가 아니라, 실행 경험에서 배운 판단을 재현 가능한 에이전트 레시피로 축적하는 과정이 장기 경쟁우위를 만든다.

2.1. AI 시스템이 축적해야 할 재료

1. 루프가 생성하는 정보

   1. 하네스와 프로필: 어떤 시스템 지침, 도구 조합, 실행 환경, 모델별 프로필이 좋은 결과를 냈는지 기록한다.
   2. 평가와 모델: 어떤 eval과 모델이 어떤 작업에서 강했는지, 모델 선택이 비용과 품질에 어떤 영향을 줬는지 남긴다.
   3. 리소스·도구·환경: 웹 검색, LinkedIn, GitHub 같은 도구와 권한·샌드박스·실행 환경도 레시피의 일부로 취급한다.

2. 휴대성·버전 관리·진화

   1. 휴대성: 한 플랫폼이나 한 모델에 묶이지 않고 다른 제공업체와 실행 환경에서도 가져다 쓸 수 있어야 한다.
   2. 버전 관리: 무엇이 언제 왜 바뀌었는지 Git 같은 방식으로 추적해야 한다.
   3. 점진적 진화: 처음부터 완성된 설정을 가정하지 않고, 실제 에이전트 행동을 관찰하면서 레시피를 계속 바꾼다.

2.2. 연구의 데이터 레시피에서 에이전트 레시피로

1. RL 연구가 얻은 교훈

   1. 레시피의 반복 개선: 연구자들은 어떤 데이터 조합과 훈련 절차가 효과적인지 이해하고, 문제 행동이 나타날 때 레시피를 바꿔 왔다.
   2. 문제 행동의 제어: hallucination과 reward hacking이 나타나면 데이터와 보상 설계를 조정해 해당 행동을 억제했다.

2. 하네스에는 빠져 있던 것

   1. 분리된 기록의 부재: 일반적인 AI 시스템에는 하네스, 평가, 인간 판단, 변경 이력이 하나의 재사용 가능한 레시피로 묶여 있지 않다.
   2. 운영 지식의 손실: 왜 특정 도구·프롬프트·평가를 선택했는지 설명되지 않으면 담당자가 바뀌거나 모델이 바뀔 때 노하우가 사라진다.

3. 에이전트 레시피의 정의

   1. 재현 가능한 프런티어 시스템: 에이전트 레시피(agent recipe)는 평가, 조정, 인간의 판단, 도구, 모델 프로필을 한데 묶어 같은 품질의 시스템을 다시 만들게 한다.
   2. 회사 소유의 자산: 레시피는 특정 모델 제공업체가 아니라 회사가 소유하며, 회사가 선택한 모델과 제공업체에 맞춰 바꿀 수 있다.
   3. 안목의 인코딩: 레시피는 제작자가 무엇을 좋은 결과로 보는지, 그 판단에 도달한 과정이 무엇인지 기록한다.

2.3. 실패·반복·불만을 레시피로 증류하기

1. 실패 패턴의 전환

   1. 실패 패턴 → judge와 eval: 반복적으로 발견되는 잘못된 행동을 판정관과 평가 항목으로 만든다.
   2. 검증 가능한 규칙: “이 결과가 틀렸다”는 막연한 감상을 특정 trace에서 감지할 수 있는 조건으로 바꾼다.

2. 반복 행동의 전환

   1. 반복 행동 → skill과 prompt: 여러 실행에서 계속 필요한 행동을 스킬과 프롬프트로 추출한다.
   2. 효율 향상: 매번 새로 추론하게 두지 않고, 반복되는 절차를 재사용 가능한 시스템 구성요소로 만든다.

3. 사용자 경험의 전환

   1. 사용자 불만 → 하네스 개선: 사용자가 불필요한 질문, 반복 작업, 엉뚱한 결과에 불만을 보이면 하네스 수정의 신호로 기록한다.
   2. 확장과 기억 → 시스템 자산: 제품의 확장 기능과 사용자별 기억도 실행 경험에서 추출해 레시피에 포함한다.

2.4. Git 저장소와 제작자의 안목

1. Introspection의 구현 방향

   1. Git 기반 관리: 에이전트 레시피를 Git 저장소에 넣어 변경 내용과 변경 이유를 지속적으로 추적한다.
   2. 에이전트가 관리하는 자산: 소유권은 회사와 제작자에게 있지만, 실제 변경·비교·평가 실행은 에이전트가 맡을 수 있다.

2. 안목(taste)의 역할

   1. 상위 수준의 판단: 제작자는 무엇이 좋은 서비스인지 판단하는 가장 높은 수준의 기준을 제공한다.
   2. 에이전트의 자기 보정: 에이전트는 제작자의 안목에 맞도록 자기 결과를 보정하고, 그 판단을 다른 실행에도 적용한다.
   3. 레시피 간 안목의 이동: 다른 제작자의 레시피를 가져오면 단순한 하네스가 아니라 그 제작자가 좋은 결과라고 보는 기준과 도달 과정을 함께 가져온다.

3. pi.recipes의 초기 공개

   1. skills를 넘어선 레이어: 발표 시점의 초기 공개물인 pi.recipes는 2025년의 skills 개념과 비슷하지만, 평가·신호·루프·지속 개선을 함께 다루는 확장된 형태다.
   2. 포함해야 할 질문: 어떤 안목을 eval로 코드화할지, eval을 어떻게 실행할지, eval을 어떻게 계속 개선할지, 어떤 신호가 올바른지, 어떤 도구와 모델 프로필을 사용할지를 레시피가 다룬다.
   3. 초기 단계의 성격: 아직 초기 릴리스이지만, 서로 다른 제작자의 안목을 에이전트용 레시피로 사용하게 만드는 방향을 제시한다.

3. 와트당 가치 있는 작업량을 최적화하라

에이전트의 진보는 더 많은 토큰이나 더 복잡한 모델이 아니라, 가치 있는 결과를 경제적으로 생산하는 능력으로 측정해야 한다.

3.1. Cursor와 Cognition의 순서가 보여준 개발 공식

1. 세 단계의 진화

   1. 좋은 제품 만들기: 먼저 사용자가 실제로 쓸 만한 제품을 만든다.
   2. 좋은 평가 만들기: 제품의 품질을 판단할 수 있는 평가 세트를 만든다.
   3. 좋은 모델 만들기: 제품과 평가에서 얻은 artifact를 바탕으로 더 적합한 모델을 만든다.

2. 코드 밖으로 확장되는 공식

   1. 코드에서 검증된 패턴: 소프트웨어 코딩은 이 제품→eval→모델 순서를 먼저 성공적으로 보여준 영역이다.
   2. 새로운 업무 영역: 고객지원, 법률, 연구 등 코드 이외의 업무도 같은 순서를 따르게 된다.
   3. 핵심 질문: 어떤 영역에서든 “얼마나 많은 가치를 1와트의 연산으로 얻는가?”를 물어야 한다.

3.2. 프런티어 도달과 경제성의 분리

1. 프런티어를 발견하는 방법

   1. 기본 하네스와 eval에서 출발: 초기에는 기본 하네스와 기본 평가 집합으로 시스템을 시작한다.
   2. 프로덕션 실행의 필수성: 실제 사용 환경에 시스템을 배포해 보기 전에는 어디가 프런티어인지 알 수 없다.
   3. 실험의 누적: 프로덕션 결과와 사용자 반응이 다음 레시피·평가·모델 선택을 만든다.

2. 프런티어 이후의 질문

   1. 경제적 실행 가능성: 최고 품질에 도달한 뒤에는 같은 가치의 결과를 얻기 위해 필요 이상으로 돈과 연산을 쓰지 않는지가 중요하다.
   2. 인프라의 추상화: 파인튜닝 API와 인프라가 복잡한 실행을 이미 많이 추상화했기 때문에, 부족한 것은 기술 부품보다 이를 활용하는 운영 노하우다.
   3. 노하우의 핵심: 제작자의 안목을 eval로 코드화하고, 실험으로 그 기준이 실제 사용자에게도 통하는지 검증하는 방법을 확보해야 한다.

3.3. 테스트를 넘어 안목을 검증하는 평가

1. eval의 재정의

   1. 단순 테스트가 아님: eval은 함수가 통과했는지만 보는 테스트가 아니라 제작자가 좋은 결과라고 판단하는 기준을 에이전트가 재현하는 장치다.
   2. 제작자의 안목 복제: 예술가나 소프트웨어 제작자의 판단을 다른 에이전트가 일관되게 적용할 수 있도록 환경과 평가로 바꾼다.

2. 오프라인과 온라인의 합의

   1. 오프라인 평가: 제작자의 판단이 레시피 후보와 실행 궤적에 적용되는지 먼저 확인한다.
   2. 온라인 실험: 실제 사용자가 그 판단을 가치 있다고 느끼는지 프로덕션에서 확인한다.
   3. 두 집단의 일치: 제작자가 만족하는 것만으로는 충분하지 않고, 최종 사용자의 만족까지 일치해야 좋은 제품 기준으로 승격한다.

4. 인재 발굴 에이전트에 적용한 실전 루프

인재 발굴은 사람마다 좋은 채용의 기준이 다르므로, 개인의 안목을 신호·판정관·실험으로 변환하는 과정을 보여주기 좋은 사례다.

4.1. 기본 인재 발굴 에이전트 구성

1. 기본 구성요소

   1. 도구: 웹 검색과 LinkedIn을 사용해 후보자를 찾고 정보를 수집한다.
   2. 서브에이전트: Codex와 Claude Code 같은 하네스가 이미 제공하는 보조 에이전트 구성요소를 활용한다.
   3. 시스템 지침: 채용 담당자의 역할과 후보자 평가 방향을 시스템 지침으로 넣는다.

2. 개인별 기준의 문제

   1. 좋은 채용의 상대성: 모두가 “좋은 채용”을 말하지만, 실제로는 어떤 사람이 그 채용을 주도하고 무엇을 좋다고 판단하는지가 다르다.
   2. 암묵적 기준: 숙련된 채용 담당자는 숨은 인재를 찾는 안목을 가지고 있지만, 처음에는 그 기준을 명시적인 규칙으로 설명하지 못할 수 있다.

4.2. 실행 trace에서 신호와 패턴을 찾기

1. 패턴 추출 단계

   1. trace 관찰: 에이전트의 검색·접촉·선정 경로를 실행 궤적으로 모은다.
   2. 공통 행동 클러스터링: 여러 trace에서 반복되는 행동이나 사용자 불만을 패턴으로 묶는다.
   3. 다음 행동의 신호: 패턴은 시스템이 다음에 무엇을 고쳐야 하는지 알려 주는 신호가 된다.

2. 숨은 인재 사례

   1. 에이전트의 자연스러운 선택: 에이전트는 유명한 빅테크 직원에게 연락하는 것이 합리적이라고 판단할 수 있다.
   2. 제작자의 실제 안목: 숙련된 채용 담당자는 존 카맥(John Carmack)처럼 이미 유명한 사람을 찾기보다 GitHub에서 아직 알려지지 않은 ‘숨은 보석(hidden gem)’을 찾고 싶어 할 수 있다.
   3. 발견 가능한 실패: 빅테크 직원에게만 접촉하는 경향은 처음부터 명시하지 않았더라도 trace를 관찰하면 드러나는 패턴이다.

4.3. 인간은 평가를 만들기보다 평가를 보정한다

1. 판정관과 eval 생성

   1. 에이전트의 역할: 에이전트가 실행 궤적을 보고 “Google 직원에게 연락했는가, GitHub의 숨은 인재를 찾았는가”를 판별하는 judge와 eval을 생성한다.
   2. 인간의 역할: 인간은 평가 코드를 직접 작성하기보다, 그 판정 기준이 자신의 안목과 맞는지 보정한다.
   3. 최소한의 질문: “유명 빅테크 직원에게 접근하는 것보다 숨은 인재를 찾는 편이 더 좋은가?”라는 판단에 인간이 동의하면 된다.

2. 안목을 코드로 옮기는 과정

   1. 암묵지의 명시화: 인간이 동의한 판단을 에이전트가 코드와 평가 규칙으로 옮긴다.
   2. 평가의 반복 적용: 같은 judge가 여러 실행과 여러 trace에 적용돼 일관성을 만드는지 확인한다.
   3. 인간 개입의 위치: 사람은 모든 실행을 다시 검사하지 않고, 평가가 어떤 기준을 집행해야 하는지 보정하는 데 집중한다.

4.4. 레시피 후보와 프로덕션 A/B 테스트

1. 후보 생성

   1. 변경 diff: 패턴을 바탕으로 프롬프트, 도구 사용 순서, 검색 범위, 후보자 선택 기준을 바꾼 레시피 후보를 만든다.
   2. 오프라인 eval: 후보가 유명 인재 편향을 줄이고 숨은 인재를 찾는지 먼저 평가한다.

2. 온라인 검증

   1. 사용자 동의 확인: 실제 채용 담당자가 “숨은 인재를 우선하는 안목”을 가치 있다고 느끼는지 확인한다.
   2. A/B 테스트: 기존 레시피와 변경 레시피를 실제 사용자에게 나누어 보여 품질과 만족도 차이를 비교한다.
   3. 다중 암 밴딧: 여러 레시피 후보가 있다면 multi-arm bandit 방식으로 어느 안목과 실행 조합이 더 좋은 사용자 결과를 내는지 탐색한다.

3. 승격 조건

   1. 제작자 만족: 오프라인 eval에서 제작자의 기준을 충족해야 한다.
   2. 사용자 만족: 프로덕션 사용자가 그 기준이 유용하다고 평가해야 한다.
   3. 레시피 버전 승격: 두 조건이 일치하면 해당 후보를 다음 에이전트 레시피 버전으로 승격하고, 그 경험을 다시 다음 루프의 입력으로 삼는다.

4.5. ‘Miranda라면 어떻게 할까?’라는 상위 판단의 코드화

1. 비유의 의미

   1. 상황별 판단: 영화 《악마는 프라다를 입는다》의 미란다 프리스틀리처럼, 구체적인 상황에서 “미란다라면 무엇을 선택할까?”를 묻는 고수준 판단을 에이전트가 재현하게 만든다.
   2. 단순 지시를 넘어선 스타일: 규칙 목록만 복사하는 것이 아니라 어떤 상황에서 무엇을 중요하게 여기는지라는 판단의 결을 시스템에 넣는다.

2. 서비스 재현성

   1. 사람의 판단을 서비스로 변환: 한 명의 전문가가 하던 판단을 여러 사용자에게 일관된 수준으로 제공한다.
   2. 반복되는 안목: 새로운 사례가 나올 때마다 상위 판단을 적용하고, 결과를 통해 다시 그 판단을 보완한다.

5. 핵심 발언과 실행 시사점

5.1. 주요 발언 모음

“The loop is the product.” — 루프 자체가 제품이다.

“System distillation is the moat.” — 시스템 증류가 해자다.

“Value of work per watt.” — 와트당 가치 있는 작업량을 최적화하라.

“평가(evals)는 단순한 테스트가 아니라 제작자의 안목을 에이전트가 재현하고 자기개선하는 장치다.”

“인간은 평가를 직접 만들 필요가 없고, 에이전트가 만든 평가가 자신의 판단과 맞는지 보정하면 된다.”

5.2. 핵심 데이터·사실·사례

• 발표 길이: 18분 15초 동안 장기 실행 에이전트의 제품화 원리를 세 가지 문장으로 압축했다.
• 시작점: 롤랜드 가브릴레스쿠와 공동 창업자는 xAI에서 에이전트 인프라를 만들다가 독립적인 제품화 가능성을 발견했다.
• 자동차 구매 루프: Reddit 가격 탐색 → 재고 확인 → 딜러 접촉 → 딜러 간 경쟁 유도 → 가격 검증 → 구매 확정의 순서로 구성됐다.
• 레시피의 주요 요소: 하네스, 프로필, eval, 모델, 리소스, 도구, 실행 환경, 인간 판단, 변경 이력을 함께 관리한다.
• 인재 발굴 패턴: 유명 빅테크 직원에게만 접근하는 경향을 trace에서 발견하고, GitHub의 숨은 인재를 찾는 기준으로 eval을 보정한다.
• 검증 방식: 오프라인 eval로 제작자의 안목을 확인한 뒤, A/B 테스트와 multi-arm bandit으로 최종 사용자의 만족도를 검증한다.
• 경제성의 기준: 가치 있는 결과를 먼저 확인하고, 그 결과를 얻는 비용과 연산량이 고객이 지불할 만큼 합리적인지 측정한다.

5.3. 에이전트 제품을 만드는 팀을 위한 실행 순서

1. 제품 루프 정의

   1. 사용자가 맡기는 장기 작업을 관찰·행동·결정·검증의 단계로 쪼갠다.
   2. 최종 결과뿐 아니라 각 단계의 trace와 중간 artifact를 저장한다.

2. 신호와 검증기 설계

   1. 에이전트가 다음 행동을 선택할 수 있을 만큼 구체적인 성공 신호를 정의한다.
   2. 겉보기 결과와 실제 성공을 구분할 수 있는 verifier를 만든다.

3. 레시피 저장소 구축

   1. 하네스, 프롬프트, 도구, 모델 프로필, eval, 환경 설정을 Git으로 버전 관리한다.
   2. 모든 변경에 “무엇을 바꿨는가”뿐 아니라 “어떤 실행 패턴 때문에 바꿨는가”를 남긴다.

4. 안목의 운영화

   1. 전문가가 좋은 결과와 나쁜 결과를 구분하는 사례를 수집한다.
   2. 에이전트가 judge와 eval을 생성하게 하고, 전문가는 그 판단을 보정한다.
   3. 실패 패턴은 eval, 반복 행동은 skill, 사용자 불만은 하네스 개선 항목으로 변환한다.

5. 프로덕션 승격과 경제성 확인

   1. 오프라인 eval을 통과한 레시피 후보를 실제 사용자에게 A/B 테스트한다.
   2. 사용자가 그 안목을 가치 있다고 인정할 때만 다음 버전으로 승격한다.
   3. 가치 있는 산출량과 연산·비용을 함께 기록해 와트당 가치 있는 작업량을 개선한다.

5.4. 최종 결론

루프를 제품의 핵심 단위로 삼으면 모델 교체와 플랫폼 변화에도 흔들리지 않는 시스템을 만들 수 있다. 시스템 증류는 실행 경험을 회사 소유의 레시피로 전환하고, 그 레시피는 제작자의 안목을 하네스와 eval에 주입한다. 결국 수직형 AI 기업의 방어력은 어떤 모델을 호출하는지가 아니라, 얼마나 빠르게 신호를 발견하고 판단을 코드화하며 사용자 가치와 비용을 함께 검증하는지에서 나온다.