AI 에이전트고성능 AI 모델(Fable 5)의 투입 시점 판단 기준
· 알고수
- #multi-model
- #model-selection
- #refactoring
- #cost
먼저 전제 하나. 12개의 에이전트는 모두 Anthropic의 Claude 모델로 돌아갑니다. 평소에는 Claude Opus(그때까지 Anthropic의 최상위 모델)와 Claude Sonnet(그보다 가벼운 모델)을 썼어요.
세션 한도 알림을 본 건 다섯 스프린트(짧은 작업 주기)짜리 정리 작업의 마지막 스프린트에서였습니다.
인증·보안 담당 에이전트(Gatekeeper)가 외부 GitHub Action 8종, 16군데를 특정 커밋(SHA)에 고정하는 작업을 돌리던 중이었어요. 실행 로그(.out 파일)에 남은 건 두 줄이었습니다. "session limit · resets 7:10pm." Claude 사용량이 정해진 시간 동안 쓸 수 있는 상한에 닿았다는 알림입니다. 에이전트는 작업 도중에 멈춰 있었고, 고치던 변경은 커밋되지 않은 채 그대로 남아 있었죠. 제 반응은 놀람보다는 "아, 맞다. 이번엔 더 비싼 모델이었지"에 가까웠어요.
Opus보다 위에 있는 Anthropic의 고성능 모델 Fable 5는 2026년 6월 10일에 나왔고, 저는 그날 바로 전환했어요. 그날 첫 스프린트 지시는 "모든 코드 보안점 및 개선점을 분석해서 리스트업한 뒤 스프린트 계획을 수립하라"였습니다.
문제
성능이 더 좋은 모델이 생겼다. 그런데 그게 항상 옳은 선택인지는 다른 질문이었다.
결정
평소엔 Claude Opus·Sonnet을 쓰고, 대형 정리 때만 그 위에 새로 나온 Fable 5(이하 프리미엄 모델)를 골라서 투입한다.
결과
6 스프린트(감사 1번 + 정리 5번)가 가르쳐 준 것은 성능의 한계가 아니라 투입 시점의 중요성이었다.
전환 당일의 전체 감사
Fable 5에게 처음 시킨 일이 전 코드베이스 감사였던 건, 지금 생각해도 적절한 시험이었습니다. "더 잘하는지 보자"보다는 "가장 어려운 걸 시켜 보자"에 가까운 결정이었어요.
결과는 결정 기록(ADR) 한 건, ADR-030이었습니다. 이 글에서는 이 감사와 그 뒤의 정리 계획을 통틀어 ADR-030이라고 부릅니다.
보안 취약 지점, 코드 품질, CI·인프라의 세 방향으로 동시에 훑었고, 의심스러운 결론은 모두 코드를 직접 열어 확인했습니다. 그 과정에서 잘못된 판단 5건을 걸러 냈어요. 예를 들어 실패 시 되돌리는 처리(Saga 보상 트랜잭션: 여러 서비스에 걸친 작업이 중간에 실패하면 앞 단계를 되돌리는 로직)가 "없다"고 분석했지만 실제로는 있었습니다(compensateGitHubFailed/compensateAiFailed). 코드 편집기(Monaco)를 필요할 때만 불러오는 처리도 "안 돼 있다"고 했지만 next/dynamic으로 이미 돼 있었어요. 넓게 훑는 단계와 정확히 확인하는 단계를 나눈 덕에 이런 오판이 걸러졌습니다.
최종 결론은 높은 위험 0건이었습니다. 기본기가 탄탄하다는 확인이기도 했어요. 중간 위험 3건, 낮은 위험 5건, 개선 7건. 그리고 이를 처리할 다섯 스프린트짜리 계획이 세워졌습니다. 감사 스프린트 1번에 정리 스프린트 5번, 이 글에서 말하는 6 스프린트는 이것입니다.
다섯 스프린트의 결과
스프린트 1 · 보안 빠른 개선
공개 API 지정 일원화 · 이벤트 API 입력 검증 · 프롬프트에 섞이는 외부 입력 격리 · 요청 헤더 정리
스프린트 2 · 운영 매뉴얼
암호화 키 교체 절차 · 처리에 실패한 메시지 재처리 절차 (문서만)
스프린트 3 · 백엔드 분해
study.service 823줄 → 서비스 5개 · saga-orchestrator 516줄 → 모듈 3개
스프린트 4 · 프론트엔드 분해
AddProblemModal 805줄 → 파일 4개 · settings 844줄 → 252줄 · Redis 로깅 정리
스프린트 5 · 공급망·CSP·CI
외부 GitHub Action 8종 버전 고정 · CI에 박혀 있던 스크립트를 파일로 분리 · CSP(콘텐츠 보안 정책) 실험(보류)
계획은 예상대로 소화됐습니다. 그런데 성능보다 눈에 들어온 건 비용이었어요.
토큰 소모가 확연히 달랐습니다. 추론이 깊다는 건, 모델이 한 번에 넓은 맥락을 안고 생각한다는 뜻이고, 그만큼 토큰을 많이 쓴다는 뜻이기도 했어요. 다섯 번째 스프린트에서 보안 담당 에이전트가 버전 고정 작업을 이어 가다 세션 한도에 닿은 게 처음이었습니다. Fable 5로 바꾼 뒤 처음 겪은 세션 중단이었어요.
경계에 모이는 회귀
백엔드·프론트엔드 분해 스프린트를 돌리면서 같은 패턴이 반복됐어요.
큰 파일을 쪼개는 리팩토링에서 생기는 회귀(전에 되던 게 깨지는 것)는 쪼갠 경계에 모인다는 것.
study.service.ts를 파일 5개로 쪼갰을 때, 잘못된 건 각 파일 안의 로직이 아니었어요. 파일 사이의 경계였습니다. Redis 키를 전부 훑는 redis.keys O(N) 문제는 쪼개기 전부터 있었는데, 쪼개고 나서야 머지 직전에 코드를 검토하는 리뷰 에이전트 Critic의 눈에 들어왔어요.
프론트엔드 분해도 비슷했습니다. 그 전에 리뷰 종류부터 정리하면, 리뷰 에이전트 Critic은 두 단계로 봅니다. ① 자동 리뷰(Auto-Critic)는 작업이 커밋될 때마다 그 변경만 봅니다. ② 머지 직전 최종 리뷰는 커밋 하나가 아니라 기준 브랜치 대비 전체 변경을 보고, 문제가 없을 때까지 1차, 2차… 여러 번 돕니다. 프론트엔드 분해에서 나온 문제는 이렇게 잡혔어요.
- 번역 키로 감싸지 않은 문구 → ① 자동 리뷰
setError(null)초기화 누락 → ② 최종 리뷰 1차- 다른 상태에서 계산되는 값을 놓친 것 → ② 최종 리뷰 2차
최종 리뷰는 3차에서야 문제 없음이 나왔어요.
이 분해 스프린트들도 Fable 5로 돌렸습니다. 그런데도 이 문제들은 리뷰 라운드를 거쳐서야 잡혔어요. ADR-030의 다섯 스프린트 계획에서 리뷰가 얼마나 돌았는지 보면:
15라운드
Critic 누적 리뷰 라운드 (분해 스프린트 2개)
백엔드 7 + 프론트엔드 8 (최종 리뷰 포함)
6건
경계에서 생긴 회귀
자동 리뷰·최종 리뷰 1·2차에서 발견
경계에서 생긴 회귀는 전부 리뷰 단계에서야 나왔습니다. 자동 리뷰, 그리고 전체 변경을 보는 최종 리뷰에서요. 프리미엄 모델로 작업했어도, 이 회귀들을 잡은 건 다른 모델로 한 번 더 보는 검토였어요.
프리미엄 모델이 리뷰 횟수를 줄여 줄지는 아직 실측하지 못했습니다. 같은 분해를 일반 모델로 해 본 적이 없어서 비교할 기준이 없어요.
프리미엄 모델이 값을 할 때
전략의 핵심은 골라서 투입하기입니다.
평소 스프린트(기능 추가, 버그 수정, 문서 갱신)는 Opus·Sonnet으로 충분합니다. 이미 정해진 패턴 위에 코드를 더하는 작업에서는 추론 깊이의 차이가 크게 드러나지 않아요. 비용 효율이 훨씬 중요합니다.
프리미엄 모델이 투자 대비 효과(ROI)를 내는 건 다른 경우입니다.
01
일반 모델로 하면 최종 리뷰를 여러 번 도는 작업
쪼갤 경계가 많은 대규모 분해, 보안 감사, 여러 모듈을 가로지르는 리팩토링. 리뷰 라운드가 줄면 비용이 바로 줄어요.
02
기술부채 원금을 갚는 작업
ADR-030처럼 쌓여 온 문제를 한꺼번에 정리하는 스프린트. 여기에 한 번 비용을 쓰면, 이후 일반 모델로 일하는 스프린트들의 품질도 같이 올라가요.
03
처음 보는 영역
전 코드베이스를 처음부터 다시 보는 감사, 새로운 영역 설계. 맥락 없이 시작하는 일일수록 추론 깊이의 차이가 납니다.
프리미엄 모델을 언제 꺼내나
이번 6 스프린트에서 얻은 핵심이 이거예요. 프리미엄 모델에 쓰는 비용은 그 스프린트 하나를 위한 게 아니라, 이후 여러 스프린트의 기본 수준을 올리기 위한 것입니다. 빚을 갚을 때처럼, 원금을 갚아서 이자(리뷰 라운드 비용)를 줄이는 거죠.
이 전략이 통하지 않는 경우
이 전략을 "늘 프리미엄 모델을 쓰자"로 읽으면 틀립니다.
몇 가지 전제가 있어요.
첫째, 전면 리팩토링은 효과가 빨리 줄어듭니다. ADR-030 분해가 효과 있었던 건 823줄, 516줄 같은 분명한 "원금"이 있었기 때문이에요. 이미 잘 나뉜 코드를 더 쪼개면 회귀 위험에 비해 얻는 게 작습니다. 아픈 곳이 분명한 데에 투입하는 것이지, 모든 곳에 투입하는 게 아니에요.
둘째, 큰 모델이 무조건 더 정확하지는 않습니다. 분해 스프린트도 Fable 5로 돌렸지만, 쪼갠 경계에서 생긴 회귀는 여전히 리뷰 단계에서야 나왔어요. 강한 모델을 써도, 다른 모델로 한 번 더 보는 검토는 필요했습니다.
셋째, 비용은 진짜입니다. 다섯 번째 스프린트에서 세션 한도에 닿은 건 경고였어요. 모든 스프린트를 프리미엄 모델로 돌리면 토큰 소모, 세션 중단 위험, 비용이 함께 올라갑니다. 골라서 투입해야 하는 이유예요.
앞선 글과 이 글
「다른 회사 모델(Codex)로 검토하는 리뷰 에이전트 Critic 도입」 글에서 저는 특정 모델에 묶이지 않는 시스템에 대해 썼어요. 리뷰 에이전트 Critic을 교체가 아닌 추가로 들이고, 어떤 모델이든 자리를 바꿔 앉힐 수 있는 하네스(에이전트들이 일하는 규칙·도구·실행 환경 묶음)를 향해 간다는 기록이었습니다.
이 글은 그 후속입니다. 모델 종속에서 벗어나려는 방향 위에서 생긴 다음 질문, "그래서 어떤 모델을, 언제, 어디에 쓸 것인가" 에 대한 답이에요.
묶여 있으면 고를 게 없으니, 이 질문 자체가 성립하지 않아요. 모델을 바꿔 앉힐 수 있는 쪽으로 가야 비로소 전략이 생기고 시점을 고를 수 있게 됩니다.
Fable 5로 바꾼 날, 저는 막 나온 모델을 전 코드베이스 감사에 투입했습니다. 결과가 좋았어요. 하지만 더 중요한 건 그 뒤였습니다. 언제 다시 꺼낼지를 알게 된 것. 그리고 그 판단이 단순한 성능 비교가 아니라 기술부채를 갚을 시점이라는 틀로 자리 잡은 것이에요.
다음에 대형 리팩토링이 필요해지면, 그때 다시 프리미엄 모델을 꺼낼 겁니다. 지금은 아니에요. 이미 깨끗해진 경계 위에서 평소 스프린트가 잘 돌아가고 있으니까요.