최강이라 평가받던 Mythos 5의 가드레일 버전으로서, Claude Fable 5가 등장했습니다. 실무에서 지금까지 최강급이었던 Opus 4.8과 비교했을 때 어디까지 우수한가. 사전 발표 단계에서 토큰 단가는 Opus의 약 2배로 알려졌으며, 현재의 사용 방식 그대로라면 비용 문제가 큽니다. 그렇다면 질문은 "빠른가·똑똑한가"가 아니라, 어떤 상황과 대응에서 사용해야 하는가를 판별하는 것입니다.

필자는 개인 자동 매매 시스템 개발에서 이 판별을 실기 평가(実機評価)를 통해 진행했습니다. 본고는 그 설계와 결정적인 계기가 된 한 사건——구현 측 모델이 창작한 존재하지 않는 API 필드를, Fable 5가 공식 사양을 스스로 취득하여 잡아낸 것——을 수치와 함께 기록합니다.

먼저 수치로 — Opus 4.8과 Fable 5

전제 (사전 발표): Fable 5의 토큰 단가는 Opus 4.8의 약 2배. "소비 토큰이 같더라도 비용은 두 배"가 출발점입니다.

중난도 A/B (동일 프롬프트를 양 모델에 투입 · 구현 1문제 + 설계 판단 1문제)

실제 태스크 (Fable을 리뷰어로 사용 · 설계 + 코드 리뷰 2 라운드)

→ 고난도·장시간 작업에서는 소비 자체가 무거움. 단가 2배와의 곱셈으로 인해 비용을 무시할 수 없습니다. 이 무게에 걸맞은 가치가 나오는지가 분기점입니다.

결론

• 중난도에서는 차이가 거의 속도뿐.
  "가치"로서 차이가 나타난 것은 고난도의 실제 태스크 - 거기서 Fable이 구현 측 모델의 할루시네이션 (Hallucination, 존재하지 않는 API 필드 창작)을 공식 사양의 자율 취득으로 검출 = 실전 사고를 미연에 방지함 - 채택 여부는 채택 = 용도 한정. 본래 목적은 독립적 적대적 리뷰어 (Adversarial Reviewer) (구현은 기존 모델 × 리뷰는 Fable). 아울러, 중난도의 단발 개발은 Fable이 빠르기 때문에, 반복의 속도를 중시한다면 비용 2배를 대가로 구현자로서 사용하는 방법도 있음.

1. 왜 "구현자로서"가 아닌 평가를 했는가

똑똑한 모델을 "빠른 구현자"로 사용하면 평가는 "같은 구현을 더 빠르고 정확하게 쓸 수 있는가"가 됩니다. 그래서 우선, 자기 완결적인 중난도 태스크(구현 1문제 · 설계 판단 1문제)를 동일한 프롬프트로 양 모델에 던지는 A/B 테스트를 진행했습니다.

결과는 호각이었습니다. 두 모델 모두 한 번에 정답을 맞혔고, 테스트도 일치했으며, 소비 토큰도 거의 동등했습니다. 차이점은 속도뿐이었으며, 구현 과제에서는 Fable 쪽이 명확하게 빨랐습니다 (앞서 언급한 표). 뒤집어 말하면, 짧은 단발성 작업에서는 단가 2배를 지불할 의미가 희박합니다. 차이가 난다면, 자신이 평소 막히는 고난도의 실제 태스크일 것이라고 가설을 세웠습니다.

그래서 관점을 바꿉니다. **구현은 기존 모델에 맡기고, 신규 모델은 "그 결과물을 독립적으로 검증하는 리뷰어"**로서 실제 태스크에 투입했습니다.

2. 결정적이었던 한 사건 — 존재하지 않는 API 필드

주제는 자동 매매 시스템의 리스크 제어 관련 수정입니다. 상세한 내용은 밝히지 않겠지만, 요점은 "주식 전략에 섞여 들어오는 ETF / ETN을 체결 전에 제외하고 싶다"는 매우 평범한 필터 구현이었습니다.

구현 측 모델이 작성한 코드는 다음과 같았습니다 (취지를 재현한 의사 코드).

# 구현 측 모델이 작성한 코드 (취지)
info = broker.get_symbol(code)
if info["SecurityType"] != "STOCK": # ← 이 행이 문제
...

언뜻 보기에는 그럴듯합니다. SecurityType (증권 종별)로 필터링한다는 것입니다.

리뷰어로 투입한 신규 모델은 여기서 멈추지 않았습니다. 증권사의 REST API (kabu STATION API) 공식 Swagger를 스스로 취득하고, /symbol의 응답 정의를 grep 하여 다음과 같이 지적해 왔습니다.

SecurityType이라는 필드는 이 API의 /symbol...

응답에 존재하지 않습니다. 이 분기는 항상 KeyError (또는 기본값)가 되어, 필터는 운영 환경에서 100% 작동하지 않게 됩니다.

종류 판정에 사용할 수 있는 것은 TradingUnit (매매 단위)이며, 도쿄 증권거래소(TSE)의 보통주는 100, ETF/ETN은 1 또는 10이 됩니다.

실제 기기에서 호출하여 확인해 보니 정확히 그대로였습니다. SecurityType은 존재하지 않았고, TradingUnit이 식별자였습니다 (보통주=100, 대상 ETN=1). 구현 측 모델은 그럴듯해 보이지만 실재하지 않는 필드명을 창작(Hallucination, 환각)하고 있었던 것입니다.

이것이 무서운 점은, 코드도 테스트도 '통과'해 버린다는 점입니다. 필터 대상이 오지 않으면 분기는 그대로 지나가고, 유닛 테스트(Unit Test)는 모의 객체(Mock)를 전제로 하기에 '그린(Pass)' 상태가 됩니다. 운영 환경의 실제 API를 마주하고 나서야 비로소 죽습니다. 리뷰어가 없었다면, 이 죽은 코드(Dead Code)는 그대로 머지(Merge)되었을 것입니다.

새로운 모델은 설계 리뷰 단계에서도 구현 측의 맹점을 여러 개 지적했으며, 코드 리뷰 단계에서는 위의 Blocker(차단 요소) 외에도 경미한 지적 사항을 몇 건 더 전달해 왔습니다. 이 모든 지적은 모두 「파일:행·근거·중요도·수정안」으로 구조화되어 있었으며, 수치 검산이나 공식 사양 대조까지 파고든 것으로, 표면적인 지적이 아니었습니다.

3. 왜 '구현자'가 아니라 '리뷰어'가 효과적인가

이 부분이 본고의 주제입니다. 똑같이 똑똑한 모델이라도, 어디에 두느냐에 따라 가치가 달라집니다.

구현자는 자신의 전제를 의심하지 않습니다. 구현에 들어가면 「SecurityType이라는 필드가 있을 것이다」라는 전제 위에 작업이 쌓이게 되며, 스스로 그 전제를 확인하러 갈 인센티브가 작동하기 어렵습니다. 이는 지능의 문제가 아니라 역할의 문제입니다. 구현자가 자신의 결과물에 대한 맹점을 찾기 어려운 것은, 인간의 코드 리뷰 문화가 해결해 온 문제와 같은 구도입니다.

리뷰어는 검증만을 업무로 부여받습니다. 「이 구현이 올바른지 1차 자료를 찾아 반증하라」는 지시는, 똑똑한 모델이 가진 「스스로 도구를 사용하여 근거를 찾아가는」 능력을 환각(Hallucination) 검출이라는 가장 효과적인 방향으로 향하게 합니다. 실제로 결정적이었던 것은 추론 능력 그 자체보다, 공식 Swagger를 스스로 가져와 대조했다는 행동이었습니다.

제공사의 공식 문서에서도 이 세대의 모델에 대해 코드 리뷰와 디버깅(버그 발견 재현율)의 향상을 언급하고 있습니다. 이번 결과는 그 특성을 '구현의 대체'가 아닌 '독립 검증'에 돌렸을 때 극대화된다는 실증적인 뒷받침이 되었습니다.

일반화하자면,

새롭고 강력한 모델은 '주역의 교체'보다 '검증 레이어의 신설'에 사용할 때 리스크 조정 후 수익률(Risk-adjusted return)이 더 높다는 것입니다. 구현 속도를 1.1배 빠르게 하는 것보다, 운영 사고를 1건 방지하는 것이 더 효과적인 국면은 많습니다.

4. 비용 — 무겁다. 하지만 무엇과 맞바꾸는가

솔직히 말하면, 리뷰어로서의 Fable은 소비가 무겁습니다 (앞서 언급했듯이 2 라운드에 약 23만 토큰, 약 23분 소요). 코드 리뷰가 16분으로 가장 무거운 이유는, 외부의 공식 Swagger를 가져오고 관련 테스트를 일일이 실행하여 검증했기 때문입니다. 이는 깊이의 반증입니다. 게다가 토큰 단가는 Opus의 약 2배입니다. 소비가 큰 영역이야말로 그 2배의 가치가 발휘됩니다.

판단 기준은 '1 토큰당 단가'가 아니라 '태스크 완료까지의 총비용과 방지한 손실'입니다. 잘못된 API 구현을 운영 환경에 투입하게 되면, 작동하지 않는 필터의 발견, 원인 파악, 재수정, 재배포, 최악의 경우 실질적인 피해까지 발생합니다. 그것과 약 23만 토큰을 저울질한다면, 무거운 리뷰라도 수지타산이 맞습니다. 반대로, 일상적인 가벼운 작업이나 결과를 저렴하게 검증할 수 있는 태스크에 매번 이 정도의 무게를 지불하는 것은 과잉입니다. 그래서 용도를 한정합니다.

5. 운영으로의 적용

실기 평가를 통해 Fable의 활용처는 두 가지로 압축되었습니다. 둘 다 '좁게' 사용하는 것이 요령입니다.

(1) 고난도 독립 리뷰어 (본령)

• 중요한 구현 (외부 API 연동·리스크 제어·비가역적 처리)에 Fable을 독립 리뷰어로 한 단계 거치게 함
• 지시는 「1차 자료를 찾아 반증하라. 확신이 들지 않는다면 미확정이라고 명시하라」 - 구현 자체는 기존 모델로 충분함. 가치는 「구현자가 놓치는 것을 잡아내는 것」에 있음

(2) 중난도 고속 구현자 (속도를 택할 때)

중난도 A/B 테스트에서는 정확성은 막상막하(샘플에서는 양쪽 모두 단번에 정답)였으나, 구현 (코드 생성)은 Fable이 몇 배 더 빨랐습니다 (37.5초 → 8.2초). 수치 그대로 읽는다면, 이는 중난도 구현 작업에서 Fable의 명확한 우위를 의미합니다. 유일한 대가는 토큰 단가가 2배라는 점입니다. 대화형으로 진행하는 개발에서는 대기 시간이 체감 성능을 좌우하므로, 비용을 허용할 수 있다면 중난도 구현은 오히려 Fable을 기본값(Default)으로 설정해도 좋습니다.

단, 속도 차이가 일률적이지는 않습니다. 동일한 중난도라도 설계 판단과 같이 '쓰는 양은 적고 생각할 것이 많은' 태스크에서는 반대로 Opus가 더 빠른 경우도 있었습니다 (샘플 규모가 작아 태스크 종류에 따라 차이가 발생합니다). Fable의 속도가 효과를 발휘하는 지점은 코드를 작성하는 양이 많은 중난도입니다.

여기서 말하는 '중난도 개발'이란, 사양이 명확하고, 스코프(Scope)가 한정되어 있으며, 정답 검증이 가능하고, 횡단 조사나 아키텍처 판단을 거의 포함하지 않는 단위 작업입니다. 구체적으로는 다음과 같습니다:

• 사양이 결정된 단일 기능 구현 (데이터 변환·정형, 입력 유효성 검사(Validation), 정규 표현식·작은 파서(Parser))
• 기존 패턴을 따른 CRUD / API 엔드포인트 1개 추가
• 재현 조건이 파악된 버그 수정
• 유닛 테스트(Unit Test) 신규 작성 및 확충
• 범위를 한정한 리팩터링(Refactoring), 보일러플레이트(Boilerplate) / 스캐폴딩(Scaffolding) 생성
• 단발성 데이터 정형 스크립트, 타입 정의 및 스키마 작성

이들은 모두 '무엇을 만들지는 정해져 있고, 나머지는 정확하고 빠르게 작성하기만 하면 되는' 태스크입니다. 본고의 A/B 테스트에서 사용한 함수 구현도 정확히 이 계층에 해당했습니다. 반대로, **저난도의 잡무나 대량의 병렬 워커(Worker)**는 대상이 아닙니다 (비용이 지배적이며, 속도 차이가 가치로 이어지기 어렵기 때문입니다).

이 '고난도는 리뷰, 중난도는 고속 구현'이라는 구분법과, (1)에서 언급한 검증용 스킬(머지(Merge) 전에 API 사양이나 할루시네이션(Hallucination)을 잡아내는 체크리스트)을 세트로 구성하면, 사람의 리뷰 규율과 마찬가지로 재현성을 확보할 수 있습니다.

요약

• 똑똑한 모델을 처음 도입할 때는 '구현의 주역 교체'로 흐르기 쉽지만, 실기 평가에서 가장 효과적이었던 것은
  **독립적인 적대적 리뷰어 (Adversarial Reviewer)**로서의 채용입니다. 중난도에서는 품질이 막상막하이지만 Fable이 훨씬 빠릅니다 (구현 시 4배 이상). '가치' 측면의 차이는 고난도 실무 태스크에서 할루시네이션 탐지라는 형태로 나타났습니다. 결정적인 요인은 추론의 영리함보다, 공식 사양을 스스로 가져와 대조하는 행동이었습니다. 구현 측에서 임의로 만들어낸 실재하지 않는 API 필드를 실서비스에 반영되기 전에 잡아낼 수 있었습니다.
• 활용법은 두 가지로 나뉩니다:
  고난도 = 독립 리뷰 (사고 방지) / 중난도 = 고속 구현 (반복 속도 향상 - 예: 사양이 명확한 단일 기능 구현, 한정적 리팩터링, 테스트 작성). 둘 다 비용이 2배인 만큼 좁은 용도로 한정합니다. 비용은 무겁지만 (리뷰 1회당 약 23만 토큰), 방지할 수 있는 사고와 맞바꾼다면 정당한 비용입니다.
• 강력한 모델은 '빠른 구현자'로도 쓸 수 있지만, 최대의 리턴은 '의심 많은 리뷰어'로 배치했을 때 발생합니다.

Discussion