클로드 코드 오푸스5 vs 페이블5, 코딩엔 뭐가 나을까

페이블로 처음부터 완벽하게 짜려다 정적 검사에서 걸린 이유

클로드 코드 사용자 사이에서 "오푸스냐 페이블이냐"라는 질문이 반복해서 올라온다. 페이블에게 처음부터 완벽한 코드를 요구했다가 정적 검사 단계에서 오류를 만난 사용자가 나오면서, 최근 페이블 폼이 떨어졌다는 의견과 오푸스로 갈아탄 후기가 잇따랐다. 두 모델의 실제 성능·가격 차이를 짚고, 모델을 바꾸는 결정이 왜 요금제 변경으로까지 이어지는지 확인했다.

방에서 나온 사례는 페이블에게 코드를 통으로 맡기고 처음부터 완성형을 기대했다가 정적 검사(static analysis) 단계에서 오류가 난 경우였다. 이 경험은 우연이 아니다. 보안 업체 소나소스가 페이블 5로 자바 모듈을 짜게 했더니 13분 만에 1222줄짜리 코드를 만들어냈지만, SonarQube Cloud로 스캔하자 HIGH 등급 보안 취약점과 부족한 테스트 커버리지가 걸려 품질 게이트를 통과하지 못했다.

모델이 그럴듯하게 동작하는 코드를 빠르게 뽑아내는 능력과, 그 코드가 정적 분석과 보안 기준을 통과하는 능력은 다른 문제라는 뜻이다. 실행하지 않고 정적 검사만 믿고 넘어가면 이런 격차가 그대로 버그로 남는다는 지적도 나온다. 보안과 직결된 코드, 이를테면 암호화나 세션, 인증 토큰을 다루는 코드에서는 안전 분류기가 경고를 띄우고 모델이 스스로 오푸스로 돌아가는 경우도 보고됐다. 클로드 고객센터도 대화 중 모델이 자동으로 전환되는 상황을 별도 문서로 안내하고 있다.

페이블 폼이 떨어졌다는 체감, 어디까지 사실인가

페이블 성능이 최근 떨어졌다는 방의 의견은 부분적으로 설명 가능하다. 프런티어급 개발 관련 요청에서 조용한 성능 저하가 있다는 지적이 나온 적이 있고, 보안 민감 코드에서 안전 분류기가 더 자주 개입해 작업 흐름이 끊기는 경우도 있다. 다만 이는 모델 자체의 코딩 실력이 낮아졌다는 뜻이라기보다, 특정 상황에서 안전장치가 더 엄격하게 작동한다는 쪽에 가깝다.

써본 사람들 사이에서는 페이블로 답을 받는 속도는 조금 빨라졌는데 그만큼 토큰을 더 많이 쓰게 됐다는 반응도 있었다. 체감 성능과 실제 벤치마크 성적이 꼭 같은 방향을 가리키지는 않는다. 페이블은 여전히 가장 어려운 추론과 긴 호흡의 에이전트 작업에서 앤트로픽이 공개한 모델 중 최고 성능이라는 평가를 유지하고 있다.

오푸스5는 벤치마크에서 앞섰지만 바깥 반응은 엇갈렸다

앤트로픽은 오푸스5를 "페이블의 프런티어 지능에 근접하면서 가격은 절반"이라는 설명과 함께 내놓았다. 가격은 입력 100만 토큰당 5달러, 출력 25달러로 오푸스4.8과 같고, 페이블은 입력 10달러·출력 50달러로 정확히 두 배다. 프런티어벤치 점수는 오푸스5가 43.3%로 페이블의 33.7%를 앞섰고, 컴퓨터 사용 능력을 보는 OS월드2.0에서도 오푸스5가 더 높은 점수를 냈다.

다만 툴콜링 벤치마크에서는 페이블이 23개 시나리오 중 21개를 통과해 오푸스5의 20개보다 나았고, 토큰과 호출 횟수도 더 적게 썼다. 벤치마크만 놓고 보면 오푸스5가 코딩과 반복적인 에이전트 작업의 기본값으로 앞서지만, 가장 어려운 장기 과제에서는 여전히 페이블에 자리가 있다는 뜻이다.

바깥 반응은 방의 분위기만큼 일방적이지 않았다. 오푸스5가 나온 직후 일주일간 여러 워크플로에 적용해본 개발자들 사이에서는 기존 스킬·플러그인과 잘 맞물리지 않는다는 불만이 나왔고, 지시에 반박하거나 작업을 끝내기 전에 멈춘다는 불만도 이어졌다. 반대로 짧은 PR을 빨리 처리할 때는 오푸스5 중간 강도를 기본으로 쓰고, 크고 오래 걸리는 프로젝트에는 여전히 페이블을 쓴다는 의견도 있었다. 모델이 자동으로 오푸스로 되돌아가는 것을 불편해하며 매번 페이블로 다시 바꾼다는 볼멘소리도 있었다.

페이블 계획 + GPT 구현보다 오푸스 단독이 낫다는 후기의 배경

방에서는 페이블로 계획을 짜고 GPT로 구현하는 조합보다, 오푸스에게 처음부터 끝까지 맡기는 쪽이 체감상 낫다는 의견이 나왔다. 클로드 코드에는 계획 단계엔 오푸스, 실행 단계엔 소네트를 자동으로 바꿔 쓰는 opusplan이라는 별칭이 있다. 하지만 페이블을 계획에, 다른 모델을 실행에 자동으로 엮어주는 별칭은 없다.

계획과 구현을 서로 다른 서비스로 쪼개면 클로드 코드가 쌓아둔 코드베이스 맥락과 도구 연동이 그 경계에서 끊긴다. 계획을 세운 모델이 실행 모델에 무엇을 왜 그렇게 짰는지 직접 전달할 방법이 마땅치 않다. 오푸스 한 모델에 처음부터 끝까지 맡기면 이 손실이 없어, 방에서 나온 "오푸스 단독이 낫다"는 체감과 맞아떨어진다.

모델을 바꾸면 요금제까지 바뀐다 — 독자에게 남는 계산

이 논의에서는 방에서 오푸스로 바꾼 뒤 맥스20 요금제에서 맥스5로 내렸다는 사례가 눈에 띈다. 클로드 코드 구독은 프로(월 20달러), 맥스5(월 100달러), 맥스20(월 200달러) 세 단계로 나뉘고, 맥스5로 내리면 월 100달러가 그대로 절감된다. 페이블이 오푸스보다 토큰당 두 배 비싸다는 가격 구조를 생각하면, 같은 작업량이라도 오푸스로 옮기는 순간 소비 토큰이 줄어들 여지가 생긴다.

오푸스5는 로우부터 맥스까지 다섯 단계의 강도(effort) 조절도 지원한다. 간단한 작업엔 로우나 미디엄을, 까다로운 리팩토링에만 엑스하이나 맥스를 골라 쓰면 같은 구독 한도 안에서 쓸 수 있는 작업량이 늘어난다. 1인 개발자나 소규모 팀처럼 매달 정해진 구독료 안에서 작업량을 최대한 뽑아내야 하는 독자라면, 모델을 오푸스로 바꾸는 결정과 강도를 낮추는 습관을 같이 검토할 만하다.

다만 이 계산은 작업 성격에 따라 달라진다. 짧은 PR과 반복적인 수정이 대부분이라면 오푸스 전환과 요금제 다운그레이드가 그대로 맞아떨어지지만, 긴 리팩토링이나 처음부터 설계가 복잡한 프로젝트가 잦다면 페이블의 자리가 남는다. 방에서는 비용 계산이 실제 결정을 갈랐지만, 오푸스가 페이블의 자리를 완전히 대신할 수 있는지는 작업이 얼마나 길고 복잡해지느냐에 따라 매번 다시 확인해야 하는 문제로 남는다.