Fable 5에서 루프 설계하기

🏷️ 정보 LLM

Fable 5 같은 Mythos급 모델이 나오면서 많은 사람들이 일하는 방식이 바뀌었습니다. 특히 R Lance Martin이 공유한 내용을 보면, Fable 5의 강점은 단순히 "더 똑똑하다"는 데 있지 않습니다. 루프 구조 속에서 자기 자신을 수정하고, 기억을 쌓아가며 점진적으로 개선하는 능력이 정말 뛰어나거든요.

자가 수정 루프

보통 LLM을 쓸 때는 "프롬프트를 보낸다 → 답이 나온다"는 일방향입니다. 하지만 Fable 5는 루프 안에서 목표나 루브릭(rubric)을 통해 피드백을 받으면서 자기 자신을 고쳐나갑니다. Claude Code의 /goal 기능이나 Claude Managed Agents의 Outcomes 기능이 바로 이걸 가능하게 합니다.

핵심은 "평가가 뭔지 명확하게 정의하기"입니다. 모델이 목표를 읽고, 현재 상태를 확인한 뒤, 부족한 부분을 스스로 찾아내고, 다음 시도에서 개선하는 과정이 반복되죠. 이게 작동하려면 목표나 루브릭이 실제로 평가할 수 있는 기준이어야 합니다. 추상적인 "더 좋게" 같은 건 도움이 안 됩니다.

Outcomes 루브릭을 쓰는 실제 방법

Outcomes를 써서 루프를 설정하려면 먼저 루브릭(평가 기준)을 마크다운 문서로 정의합니다. 가장 중요한 건 "명시적이고 측정 가능한 기준"입니다.

예를 들어 재무 모델을 만드는 과제라면 이렇게 씁니다:


<!-- -->
# DCF 모델 루브릭


<!-- -->
## 수익 전망
- 최근 5년의 역사적 수익 데이터를 사용함
- 최소 5년 이상을 앞으로 예측함
- 성장률 가정을 명시하고 합리적임


<!-- -->
## 비용 구조
- 상품원가(COGS)와 운영비를 별도로 모델링함
- 마진이 과거 추이와 일치하거나 편차를 설명함


<!-- -->
## 할인율(WACC)
- WACC를 자본비용, 부채비용의 명시적 가정으로 계산함
- 베타, 무위험 금리, 주식위험프리미엄을 제시하거나 정당화함


<!-- -->
## 최종 가치
- 영구성장법 또는 상방배수법을 사용했고 명시함
- 최종성장율이 장기 GDP 성장률을 초과하지 않음


<!-- -->
## 출력 품질
- 모든 수치가 단일 .xlsx 파일에 담겨 있음
- 핵심 가정이 별도 시트에 정리됨
- WACC와 최종성장율에 대한 민감도 분석 포함

중요한 건 각 기준이 "~가 포함됨", "~을 명시함" 같은 구체적인 액션이어야 한다는 것입니다. "품질이 좋음", "제대로 함" 같은 표현은 verifier 에이전트가 평가하기 어렵습니다.

루브릭을 정의한 뒤, Claude Managed Agents에서 세션을 만들고 user.define_outcome 이벤트를 보냅니다. 그러면 자동으로:

에이전트가 작업 시작 — 당신이 추가 프롬프트를 보낼 필요 없습니다
별도 verifier가 독립 컨텍스트에서 평가 — 에이전트가 만든 결과물을 이것이 본 아티팩트만으로 루브릭 기준에 따라 검증합니다
피드백을 에이전트에게 반환 — "5개년 수익 데이터 ○, 성장률 가정 ○, 민감도 분석 ✗" 이런 식으로

이 과정이 최대 반복 횟수(기본 3회, 최대 20회)만큼 돌면서, 모든 기준을 통과할 때까지 에이전트가 자동으로 개선합니다.

왜 독립적 검증이 중요한가

여기서 핵심은 verifier가 에이전트와 다른 컨텍스트를 사용한다는 점입니다. 에이전트가 자신의 결과물을 스스로 평가하면 "어 내가 이렇게 한 이유는..." 하면서 합리화하는 편향이 생깁니다. 반면 verifier는 결과물과 루브릭만 보고 객관적으로 판단하기 때문에 훨씬 정확합니다.

Parameter Golf로 본 Fable 5의 실력

R Lance Martin은 Parameter Golf라는 벤치마크로 Fable 5를 테스트했습니다. 이 벤치마크는 16MB 크기의 모델을 10분 안에 8개의 H100 GPU에서 학습하는 과제인데, 에이전트가 직접 학습 코드를 수정하고 실행하고 로그를 확인하며 다음 실험을 결정해야 합니다. Andrej Karpathy의 autoresearch 프로젝트와 비슷한 구조죠.

결과를 보면 Fable 5가 Opus 4.7보다 약 6배 더 큰 성능 개선을 이뤄냈습니다. 더 흥미로운 건 그 방식의 차이입니다.

*Opus 4.7*: 첫 번째 실험에서 작은 성과를 낸 뒤 거의 모든 시도가 같은 패턴(스칼라 값만 조정)을 반복했습니다.
*Fable 5*: 아키텍처 변경 같은 큰 구조적 변화를 시도했고, 실패를 겪으면서도 끝까지 밀어붙여 최종적으로 가장 큰 성과를 얻었습니다.

평가하는 주체도 중요합니다. 모델이 자기 결과를 스스로 판단하는 것보다는 별도의 검증 서브에이전트(verifier)가 독립적인 컨텍스트 창에서 평가하는 게 훨씬 정확합니다. 모델이 자신의 결과물을 비판하는 데는 편향이 생기기 쉽거든요. CMA의 Outcomes 기능은 이 검증 단계를 자동으로 처리해줍니다.

메모리: 세션을 넘나드는 학습

루프는 한 세션 안에서만 도는 게 아닙니다. 메모리를 쓰면 여러 세션에 걸쳐 배운 내용을 누적할 수 있습니다. 최근에 공개된 Continual Learning Bench 1.0은 이런 상황을 벤치마킹한 첫 번째 사례인데, SQL 데이터베이스를 가진 상황에서 연속으로 질문에 답하는 태스크입니다. 각 질문은 별도의 에이전트 세션이지만, 메모리(파일시스템)는 모두에게 공유됩니다.

효과적인 메모리 사용은 다음 단계를 따릅니다:

실패 기록 — 뭔가 틀렸을 때 그걸 문서화합니다
조사 — 진행하기 전에 왜 틀렸는지 파악합니다
검증 — 진단을 확인된 사실로 바꿉니다
추상화 — 검증 결과를 일반적인 규칙으로 만듭니다
재사용 — 규칙을 읽고 다시 유도하지 않습니다

모델별 메모리 활용 차이

테스트 결과를 보면 모델마다 이 단계에서 멈추는 지점이 다릅니다.

*Sonnet 4.6*: 1단계에서 멈춤. 실패 노트를 남기지만 거의 참고하지 않습니다. "아마도 prc가 아니라 prc_usd일까?" 같은 추측만 적어두고, 다음 번엔 그 메모를 읽지 않습니다.
*Opus 4.7*: 3단계 수준. 스키마 레퍼런스를 만들고 검증 상태를 표시합니다("아마도 센트 단위? 검증 필요"). 하지만 실제로 검증할지 말지는 확실하지 않아서, 검증 커버리지가 낮습니다(중앙값 약 17%). 다시 말해, 노트는 있지만 신뢰하지 않는 수준입니다.
*Fable 5*: 전체 단계를 완주합니다. 규칙을 문서화하고, 그것이 맞는지 적극적으로 검증하고, 앞으로 그 규칙을 참고합니다. 최고 성능 실행에서는 검증 커버리지가 73%(30개 중 22개)에 달합니다.

메모리 세팅 방법

Claude Managed Agents를 쓰고 있다면, 마운트된 파일시스템에 간단한 마크다운 파일을 만들어 두세요:


<!-- -->
# 학습 기록 - 데이터베이스 스키마


<!-- -->
## 검증된 사실

**2024-01-15 검증완료**
- `prc` 컬럼은 센트 단위 (달러 아님)
  확인: SELECT prc FROM order_items WHERE ... → 값이 50~5000 범위
  (달러면 0.5~50 범위일 것이므로 센트가 맞음)

**2024-01-16 검증완료**
- `customer_id` 는 회원 ID가 아님 (같은 회원도 여러 customer_id 가질 수 있음)
  확인: WITH dups AS (SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id HAVING COUNT(*) > 1)
        SELECT * FROM dups → 10만+ 레코드 (같은 customer_id로 여러 주문함)


<!-- -->
## 아직 미확인

- 프로모션 기간 정의: START_DATE/END_DATE? 아니면 프로모션 테이블?
  (다음 세션에서 확인 필요)

에이전트는 세션을 시작할 때 이 파일을 읽고, 같은 실수를 반복하지 않습니다. 중요한 건 단순함입니다. 과도하게 상세한 노트를 쓰도록 지시하면 에이전트가 노트 쓰기에 시간을 쓰느라 본업을 못 합니다. "한 줄 요약 + 확인 방법 + 결과"만 기록하세요.

루프를 설계하는 실전 원칙

이 모든 차이를 보면, Fable 5를 쓸 때는 "더 복잡한 프롬프트를 써야 한다"는 생각을 버리고, 대신 "모델이 스스로 피드백을 받고 수정할 수 있는 루프를 만드는 게 핵심"이라는 걸 깨닫게 됩니다.

첫 번째: 성공의 정의부터 명확히 하기

루프를 시작하기 전에, "이 작업이 끝났다"는 게 뭔지 정의하세요. 루브릭을 쓸 때는:

추상적 기준 ✗ — "좋은 분석", "전문적인 결과물"
측정 가능한 기준 ○ — "5개년 데이터 사용", "각 가정마다 범위값(high/low) 제시", "10개 변수에 대한 민감도 분석"

한 글자라도 명확할수록, 에이전트와 verifier 모두 뭘 해야 할지 안다는 뜻입니다.

두 번째: 검증을 분리하기

혼자 하는 작업이면 /goal을 쓰고, 호스팅된 장기 작업이면 Claude Managed Agents의 Outcomes를 쓰세요. 둘 다 핵심은 같습니다: 검증을 에이전트가 하지 말고, 별도의 평가자에게 시키기.

/goal은 로컬 CLI에서 에이전트가 자신의 출력을 평가하도록 가이드합니다. Outcomes는 클라우드에서 독립 grader 에이전트를 자동으로 띄워 검증합니다. 둘 다 같은 원리입니다.

세 번째: 장기 작업에 메모리 더하기

한두 시간 안에 끝나는 일이 아니라면, 메모리(간단한 마크다운 파일)를 준비합니다:


<!-- -->
# 학습 기록


<!-- -->
## SQL 스키마 주의점
- prc 는 센트 단위 (달러 아님)
- customer_id 는 중복 가능 (회원 ID, 트랜잭션 ID 아님)


<!-- -->
## 검증 완료된 사실
- 2024-01-15: 프로모션 기간 동안 매출 +40% (3개 구간 검증함)
- 2024-02-01: 환불 건은 order_status = 'refunded' 아님, returns 테이블 별도 확인 필요

에이전트가 매 세션마다 이 파일을 읽고 쓰면, 실수를 반복하지 않고 이전 배움을 누적할 수 있습니다.

네 번째: 피드백 루프를 환경이 주도하게 하기

시스템 프롬프트에 "X을 할 때마다 Y를 확인하세요" 같은 지시를 길게 쓰지 마세요. 대신 평가 기준(루브릭)을 명확히 하면, 에이전트가 스스로 "아, 이 기준을 통과하려면 저 부분을 다시 확인해야겠다"고 판단합니다.

이게 Fable 5와 Opus 4.7의 가장 큰 차이입니다. Opus는 지시한 것만 따르고, Fable 5는 평가 기준을 읽고 스스로 그 기준을 충족하려고 노력합니다.

실제로 어려운 문제를 풀 때

지금까지 한 번의 프롬프트로 완벽한 답을 받으려 고민했다면, 이제 생각을 바꿀 차례입니다:

문제를 명확히 정의하되, 성공 기준은 루브릭으로 정의하기
한 번에 맞출 거라고 기대하지 않기 — 보통 2~3회 반복으로 충분합니다
장기 작업이면 메모리를 세션 간 공유 — 실수 반복 방지
검증은 에이전트가 아닌 독립 평가자에게 — 편향 없는 객관적 판단

이렇게 루프를 설계하면, 이전에는 "손으로 직접 해야 했던 일"을 Fable 5가 완전히 자동화할 수 있습니다.