Fable 5를 쓰기 전에 겨냥할 곳을 먼저 정합니다

Fable 5처럼 비싼 코딩 모델은 아무 곳에나 쓰면 금방 낭비됩니다. 먼저 싼 모델로 코드베이스를 훑고, 어디에 써야 가장 큰 효과가 나는지 정해야 합니다.

비싼 모델을 항상 켜 두는 것이 가장 큰 낭비입니다

Ray Amjad는 Anthropic이 Claude Code 안에서 Fable 5 관련 문구를 바꾼 점을 보고, Fable 5가 다시 돌아올 가능성을 이야기합니다. 새 문구에는 주간 사용량과 /usage credits가 언급됩니다. 그래서 Fable 5가 Claude Design처럼 따로 사용량 막대를 가질 수 있다고 봅니다.

하지만 영상의 중심은 제품 소식이 아닙니다. 핵심은 Fable 5가 돌아왔을 때 어떻게 써야 하는가입니다. Ray는 지난번 Fable 5를 쓸 수 있었을 때 많은 사람이 같은 실수를 했다고 말합니다. 모델에게 뚜렷한 목표를 주지 않고 코드베이스 전체를 맡겼습니다. “버그를 고쳐줘”처럼 넓게 던지고, 모델이 알아서 마법처럼 고치기를 바랐습니다.

그렇게 쓰면 컨텍스트를 빨리 다 씁니다. 돈도 빨리 씁니다. 결과도 흐려집니다. 비싼 모델은 오래 켜 두는 모델이 아니라, 가장 어려운 곳에 겨냥해서 쓰는 모델입니다.

먼저 싼 모델로 모든 파일을 점수화합니다

Ray가 소개하는 기준은 Anthropic의 보안 연구자 Nicholas Carlini가 말한 방식입니다. Carlini는 큰 코드베이스에서 버그나 보안 문제를 찾을 때, 언어 모델이 모든 파일을 훑게 합니다. 그리고 각 파일이 흥미로운 문제를 담고 있을 가능성을 1점에서 5점으로 매기게 합니다.

그다음 1점과 2점은 버립니다. 3점, 4점, 5점만 남깁니다. 이 방식은 모델이 처음부터 모든 곳을 깊게 파고들지 않게 합니다. 먼저 싼 모델이 넓게 훑고, 더 강한 모델은 남은 중요한 곳에만 들어갑니다.

Deep Dive: 이 점수화의 원전과, 노트가 생략한 전제: 이 1–5점 방식은 SCW 팟캐스트 AI Bug Finding(2026-03, 게스트 Nicholas Carlini)에서 Carlini가 Ghost 같은 코드베이스를 감사할 때 쓴 실제 절차입니다. 보안과 무관한 파일을 먼저 거르고, 남은 파일을 "흥미로운 게 있을 가능성"으로 1–5점 매겨 1·2를 버리고 3·4·5만 깊게 봅니다. Ray는 이 보안 기법을 일반 우선순위 판단으로 확장한 것입니다. 다만 Carlini의 원래 맥락에는 노트가 생략한 두 전제가 있습니다. (1) 완벽한 오라클: 메모리 손상 버그는 ASan 크래시라는 깔끔한 합/불 판정이 있어 발견이 신뢰할 만합니다. 일반 코드베이스 점수화에는 그런 오라클이 없습니다. (2) 그래서 그는 별도 critique/triage 에이전트로 모든 발견을 clean 이미지에서 재검증합니다(모델이 세션 초반 스스로 심은 우회 코드를 나중에 "버그"라 보고하는 자기기만까지 걸러냅니다). 즉 점수도 발견도 그 자체로 진실이 아닙니다. 이 방식을 내 작업에 옮길 때는 점수를 "사람이 먼저 볼 후보"로만 쓰고, 나만의 검증 단계를 따로 두어야 합니다.

Ray는 Project Glasswing에서 Claude Mythos Preview를 쓸 때도 비슷한 흐름이 있었다고 설명합니다. 코드베이스를 훑고, 파일에 점수를 매기고, 기회를 찾은 뒤, Mythos를 그 위치에 보냈다는 것입니다.

이 방식은 보안 문제에만 쓰는 방법이 아닙니다. 질문을 이렇게 바꾸면 됩니다. “우리는 Fable을 우리 코드베이스의 어디에 써야 하는가?” 이 질문에 답하기 위해 먼저 점수를 만듭니다.

점수는 영향도와 기회를 곱해서 만듭니다

Ray가 제안하는 가장 단순한 식은 impact x opportunity입니다.

영향도는 이 부분을 고쳤을 때 얼마나 많은 문제가 줄어드는지를 뜻합니다. 예를 들면 많은 파일이 import하는 코드, 트래픽이 큰 화면, 자주 실행되는 경로가 영향도가 큽니다.

기회는 지금 그 부분에 고칠 만한 여지가 얼마나 많은지를 뜻합니다. 버그가 많거나, 복잡하거나, 낡았거나, 흐름이 자주 막히는 곳입니다.

영향도가 낮고 기회도 낮으면 그냥 둬도 됩니다. 영향도는 높은데 기회가 낮으면 지금은 잘 돌아가고 있을 수 있습니다. 기회가 높아도 영향도가 낮으면 당장 크게 중요하지 않을 수 있습니다. Ray가 겨냥하자는 곳은 영향도와 기회가 둘 다 높은 곳입니다.

이 식은 여러 작업에 바꿔 쓸 수 있습니다.

• 기술 부채를 줄이고 싶다면 git churn x complexity를 씁니다. 자주 바뀌는 곳은 영향도에 가깝고, 복잡한 곳은 기회에 가깝습니다.
• 죽은 코드를 찾고 싶다면 unused confidence x size를 씁니다. 안 쓰일 가능성과 크기를 곱합니다.
• 전환율을 올리고 싶다면 traffic x drop-off를 씁니다. 사람이 많이 지나가고 많이 떨어져 나가는 곳부터 봅니다.

여기서 중요한 점은 점수 자체가 완벽해야 한다는 말이 아닙니다. Fable 5 같은 비싼 모델을 쓰기 전에, 먼저 어디에 보낼지 고르는 장치를 만들어야 한다는 말입니다.

Deep Dive: impact와 opportunity는 "다른 축"이지 "무상관"이 아닙니다. impact는 그 자리의 중요도·도달 범위(역할), opportunity는 그 자리의 개선 여지·망가진 정도(현재 상태)입니다. 서로 다른 것을 재므로 어느 하나로 다른 하나를 추론할 수 없고, 그래서 둘 다 매겨 곱합니다(논리적 AND). 한쪽이 0이면 곱이 0으로 떨어집니다(완벽한 핵심 코드 = impact 5·opportunity 0, 아무도 안 쓰는 누더기 = opportunity 5·impact 0 → 둘 다 후순위). 단, "다른 축"이 "통계적으로 무상관"을 뜻하지는 않습니다. 키와 몸무게처럼 별개 차원이어도 상관될 수 있습니다. 실제로 고impact 코드는 이미 단단해 opportunity가 낮은 음의 상관을 보이기도 하고, 빠르게 자라는 핫스팟은 둘 다 높은 양의 상관을 보이기도 합니다. 부호가 맥락마다 다르므로 한쪽에서 다른 쪽을 넘겨짚으면 안 됩니다. 노트 프롬프트가 "두 점수를 독립적으로 판단한 뒤 곱하라"고 한 것은 무상관이라는 주장이 아니라, 측정이 서로 오염되지 않게 하라는 절차 규칙입니다(채점 모델이 "중요하면 버그도 많겠지"라고 가짜 상관을 지어내면 측정 자체가 망가집니다).

Claude Code에는 점수화 작업을 먼저 맡깁니다

Ray는 자신의 AgentStack 프로젝트를 예로 듭니다. 목표는 코드베이스 안의 기술 부채를 줄이는 것입니다. 그는 Claude Code에 이렇게 요청합니다.

기술 부채를 줄이고 싶습니다. 점수는 git churn x complexity입니다. Sonnet subagent를 써서 코드베이스를 살펴보고, git churn이 높고 복잡도도 높은 곳을 찾아 주세요. git churn 점수와 complexity 점수는 각각 1점에서 5점으로 매기세요. 둘은 서로 독립적으로 판단한 뒤 마지막에 곱하세요. 상황에 맞게 작업 흐름을 바꾸세요.

이 프롬프트의 핵심은 비싼 모델을 바로 투입하지 않는 데 있습니다. 먼저 Sonnet 같은 싼 모델에게 넓은 탐색과 점수화를 맡깁니다. 그리고 Fable 5는 점수가 높은 곳에 보냅니다.

Ray는 더 나은 점수를 만들려면 Claude Code를 실제 데이터와 연결하라고 말합니다. 예를 들어 전환율을 다룬다면 트래픽과 이탈률이 필요합니다. 운영 문제라면 실행 빈도, 성능 지표, Sentry 같은 오류 데이터가 도움이 됩니다. 이미 가진 데이터가 많을수록 점수는 더 쓸모 있어집니다.

영상의 예시에서는 chat route가 가장 높은 점수를 받은 항목으로 나옵니다. 애플리케이션에서 가장 중요한 부분이기 때문입니다. Slack 메시지를 처리하는 부분과 voice agent를 다루는 서비스도 높은 순위에 오릅니다. 이렇게 순위가 나오면, 먼저 어디를 봐야 할지 알 수 있습니다.

고친 뒤에는 더 깊은 원인을 묻습니다

Ray가 지적하는 또 다른 낭비는 부분 수정입니다. 모델에게 특정 위치를 주고 “이걸 고쳐”라고 하면, 모델은 그 자리의 증상만 고칠 수 있습니다. 하지만 같은 종류의 문제가 코드베이스 여러 곳에서 반복된다면, 더 깊은 원인이 있을 수 있습니다.

그래서 Ray는 Fable 5에게 후속 질문을 던지라고 말합니다.

여기에 더 큰 패턴이 있습니까? 우리가 고쳐야 할 더 깊은 원인이 있습니까?

이 질문은 모델이 단순한 패치에 머무르지 않게 합니다. 사용자가 명시적으로 요구하지 않으면 모델은 큰 구조 변경을 조심스러워할 수 있습니다. 하지만 사용자가 더 깊은 원인을 묻고, 구조를 고칠 여지를 열어 주면, 증상이 아니라 문제를 만든 구조를 고칠 가능성이 커집니다.

결국 순서는 이렇습니다. 먼저 싼 모델이 넓게 훑습니다. 점수를 만들고 우선순위를 정합니다. 비싼 모델은 높은 점수의 문제에 씁니다. 그리고 그 자리에서 바로 끝내지 말고, 같은 문제가 반복되는 더 큰 원인이 있는지 묻습니다.

작은 저장소와 나쁜 데이터에는 예외가 있습니다

Ray는 이 방식이 언제나 필요한 것은 아니라고 말합니다. 저장소가 아주 작다면 굳이 점수화할 필요가 없습니다. 바로 Fable 5를 써도 됩니다.

데이터가 나쁘면 점수도 나빠집니다. 쓰레기 데이터를 넣으면 쓰레기 결과가 나옵니다. 이때는 사람이 중간에 들어가 판단해야 합니다.

또 하나의 비용은 사람의 주의입니다. Fable 5에게 더 깊은 구조 문제를 물었다고 해서 일이 공짜가 되지는 않습니다. 큰 구조 변경을 검토하고, 다시 대화하고, 실제로 받아들일지 판단하는 데 사람의 시간이 듭니다.

그래도 이 방식은 기다리는 동안 할 수 있는 일이 분명합니다. 지금부터 우리 코드베이스에서 영향도와 기회를 어떻게 매길지 정합니다. 어떤 데이터를 쓸지 정합니다. 순위 목록을 만들어 둡니다. 그러면 Fable 5가 돌아왔을 때 가장 중요한 일부터 맡길 수 있습니다.

강한 모델의 가치는 모든 일을 대신하는 데 있지 않습니다. 강한 모델을 가장 중요한 문제에만 쓰게 만드는 준비가 가치를 만듭니다.

Deep Dive

2026-06-29

impact x opportunity는 silver bullet이 아니라 강제 장치입니다

이 식을 풀면 결국 개입의 기대값(EV) 입니다. (고쳤을 때의 가치) × (고칠 게 있을 가능성). 곱셈을 쓰는 건 "둘 다 높아야 한다"는 논리적 AND를 담기 위해서입니다. 다만 이건 EV 추론이 물려받는 약점을 그대로 안고 있고, 공식에는 빠진 항도 있습니다. 실제로 최대화하고 싶은 것은 (가치 × 가능성) ÷ 실제 수정에 드는 사람·시간 비용이고, 거기에 시간축도 빠져 있습니다. 노트가 말한 "사람의 주의 비용"이 바로 그 분모입니다. 비싼 모델을 넓게 쓰면 안 되는 이유는 Fable 5 첫날 리뷰의 "워프 드라이브" 비유가 잘 보여줍니다. 긴 자율 실행에는 탁월하지만 빠른 주고받기에는 약하므로, 깊이로 보낼 곳을 먼저 좁혀야 합니다.

이 식이 잘 듣는 조건: (1) 비싸고 희소한 자원을 배분할 때, (2) 일이 독립적으로 스캔 가능한 단위로 쪼개질 때, (3) 단위 간 편차가 실제로 클 때, (4) 목표가 총합 개선일 때, (5) impact·opportunity의 정직한 프록시를 댈 수 있을 때. 노트의 예외("저장소가 작으면 그냥 Fable 5 써라")도 결국 "편차가 없으면 무의미"의 한 사례입니다.

깨지는 지점:

• Goodhart의 법칙: complexity·churn은 "버그 가능성"의 프록시일 뿐입니다. 측정값이 목표가 되는 순간 좋은 측정값이 아니게 됩니다. 그걸 목표로 삼으면 버그가 아니라 "복잡해 보이는 것"을 최적화하게 되어, 복잡하지만 정확한 코드에 자원을 쏟고 단순해 보이지만 진짜 버그가 있는 코드는 버려질 수 있습니다. 이것은 코드 커버리지 같은 지표를 agent에 그대로 들이댈 때의 함정과 같은 현상입니다.
• min과 max의 범주 오류: 이 식은 고가치 타깃을 찾는 max 휴리스틱입니다. 그런데 보안·정합성은 가장 약한 한 곳(min)이 지배합니다. 트래픽 없는 admin 엔드포인트 하나의 인증 우회가 전체를 무너뜨리는데, 그 파일은 impact가 낮아 버려졌을 것입니다. 원전의 Carlini조차 "이 루프를 돌리면 안전하냐"는 질문에 "No"라고 답합니다. 점수화는 버그를 효율적으로 찾는 도구이지 안전을 보증하는 도구가 아닙니다.
• 부재와 구조에 눈멈: 파일 단위 점수는 "없는 것"(빠진 보안 통제, 빠진 테스트, 두 파일 사이의 레이스)과 아키텍처 문제(올바른 수정이 여러 파일에 걸쳐 있고 개별 파일은 어느 것도 고점이 아닌 경우)를 구조적으로 보지 못합니다. 겨냥 단계는 이미 고른 지점만 깊게 팔 수 있을 뿐입니다.
• 정적·탐욕적(greedy): 점수는 한 시점의 스냅숏입니다. 1등을 고치면 지형이 바뀌고, 늘 현재 최고점만 치면 탐색(exploration)을 굶습니다. Carlini가 "안 골랐을 법한 파일"에서 의외의 버그를 건진 그 효과를 놓칩니다.

bitter lesson과의 연결: 그렇다고 더 정교한 점수 장치에 과투자해서도 안 됩니다. SCW 팟캐스트의 교훈처럼, 모델이 좋아지면 특정 모델에 맞춰 만든 화려한 scaffolding은 도움이 아니라 족쇄가 됩니다(Carlini는 Princeton 벤치마크에서 하니스를 통째로 버리자 점수가 40%에서 92%로 뛴 사례를 듭니다). 점수 장치는 "충분히 좋은" 수준이면 됩니다. 플랫폼에 흡수될 래퍼·보조 도구에는 얕게 투자하라는 원칙과 통합니다.

Key Insight

만능 열쇠는 impact x opportunity라는 공식이 아니라, "비싼 자원을 쓰기 전에 싼 넓은 패스로 어디에 쓸지 먼저 배분한다"는 메타 수(手) 입니다. 노력보다 포지셔닝이 가치를 만든다는 Naval의 AI 시대 레버리지 원칙과 같은 이야기로, 싼 모델은 속도가 아니라 비싼 모델의 위치 선정을 위한 것입니다. 공식은 그 메타 수의 값싸고 깨지기 쉬운 한 구현일 뿐입니다. 목표에 따라 분모(÷ 노력), 시간축, min/max 성격에 맞게 매번 갈아 끼워야 하고, 그 점수는 "정답"이 아니라 "사람이 먼저 볼 후보를 추리는 신호"로만 써야 합니다.