AI 외주개발, 최상급 모델을 쓰면 결과도 최상급일까? Fable 5 vs Opus 5 실측 (2026)

"AI 외주개발"이라는 검색어는 올해 들어 뜻이 둘로 갈렸습니다. 하나는 챗봇이나 문서 인식처럼 AI 기능이 들어간 서비스를 개발사에 맡기는 외주개발이고, 다른 하나는 개발사가 AI 코딩 도구로 프로젝트를 만드는 외주개발이에요. 어느 쪽을 검색하셨든 발주자의 속마음은 비슷합니다. "AI로 만든다는데, 결과물을 믿어도 되나?"라는 질문이죠.

이 질문에 개발사들이 내놓는 흔한 답이 "저희는 최신 최상급 모델을 씁니다"입니다. 그런데 정말 좋은 모델을 쓰면 좋은 결과물이 나올까요? 벤치마크 점수는 등급 순서대로 나오지만, 실제 외주 프로젝트를 통째로 맡겼을 때도 등급 순서대로 결과가 나오는지는 아무도 검증해주지 않습니다. 외주개발사인 저희에게 이건 곧 견적과 마감의 문제라서 직접 확인해보기로 했어요.

그래서 지난 7월, 실제 고객 프로젝트를 익명화한 문서 6종을 실험 당시 클로드 최상급 등급이던 Fable 5와 한 단계 아래인 Claude Opus 5에 똑같이 맡겼습니다. 도구는 둘 다 Claude Code로 통일했기 때문에 하네스 변수 없이 모델 성향의 차이만 남는 조건이었고, 결과물은 실무 시나리오 10개를 실제 화면에서 끝까지 눌러보는 방식으로 판정했습니다. 같은 실험에 Kimi K3와 GPT-5.6 Sol도 함께 투입했는데, 4개 모델 전체 비교는 영상에서, 회사도 도구도 다른 두 제품의 비교는 GPT-5.6 Codex vs Claude Opus 5 실사용 비교에서 따로 다뤘습니다.

결과부터 말씀드리면, 최상급 Fable 5는 10개 장면 중 6개를 닫았고 아래 등급인 Opus 5는 9개를 닫았습니다. 등급표의 순서와 실무 판정의 순서가 뒤집힌 겁니다.

이 글을 읽으면 아래와 같은 차별화 인사이트를 얻어갈 수 있습니다.

• 같은 도구에서 모델 등급 차이가 실제 외주 결과물에 어떻게 나타나는지 증거 화면으로 확인할 수 있습니다.
• 가장 빨리 끝낸 모델이 어디서 미끄러졌는지, 그리고 그 장면이 발주자에게 왜 중요한지 알 수 있습니다.
• AI 외주개발 결과물을 검수할 때 무엇을 봐야 하는지, 이 실험에서 나온 기준 3가지를 가져갈 수 있습니다.
• 리트머스가 AI 외주개발 프로젝트를 실제로 어떻게 검증하는지, 내부 방식과 사례를 볼 수 있습니다.

그래서 이 글은 두 모델의 서열을 정하는 글이 아닙니다. AI 외주개발을 맡기는 쪽이 "어떤 모델을 쓰나요?" 대신 무엇을 물어야 하는지를 실측으로 보여주는 글이죠.

AI 외주개발이란: 두 가지 뜻, 그리고 공통의 질문

용어부터 짧게 정리하고 가겠습니다. AI 외주개발은 현장에서 두 가지 의미로 쓰입니다. 첫째는 AI 기능이 핵심인 서비스를 외부 개발사에 맡기는 것으로, 특허 아이디어를 분석하는 SaaS나 영수증을 읽어 원가를 계산하는 앱 같은 프로젝트가 여기에 속해요. 둘째는 개발사가 Claude Code나 Codex 같은 AI 코딩 도구로 일반 서비스를 만드는 방식, 흔히 바이브코딩 외주라고 부르는 쪽입니다.

리트머스는 두 가지를 모두 합니다. AI 기능이 들어간 서비스를 만들고, 그 서비스를 만드는 과정에도 AI를 씁니다. 그래서 두 의미 모두에서 같은 질문을 매일 받아요. "AI가 만든 결과물을 누가, 어떻게 검증하나요?" 이 실험은 그 질문에 답하기 위해 설계됐습니다. 어떤 개발사를 골라야 하는지 일반론이 궁금하시다면 바이브코딩 외주개발사, 어떻게 선택해야 할까에 기준을 정리해 두었고, 이 글은 그 기준 가운데 "검증" 하나를 실제 증거로 파고듭니다.

실험 조건: 하네스를 통일하고 프롬프트 한 줄만 줬습니다

실험 대상은 농산물 수거센터의 거래 관리 시스템입니다. 센터, 본사, 공공기관, 공급자, 바이어까지 이해관계자가 다섯 축인 실제 케이스를 익명화했고, 두 모델 모두 Claude Code에서 최대 성능 설정으로 동시에 출발시켰습니다. 프롬프트는 한 줄이었어요.

네 모델에 똑같이 입력된 프롬프트 전문. 평가표도, 구현 순서도, 기술 스택 지정도 없었습니다. 이미지 출처 : YouTube 'Kimi K3 vs 클로드, AI 4개에 같은 외주 프로젝트를 통째로 맡겨봤습니다' by 리트머스

"프로젝트 자료 보고 실제 개발 좀 끝까지 해줘. 지금 있는 기본 환경에서 1차 출시본으로 최대한 완성하고, 네가 직접 실행해서 문제 없는지도 확인해줘." 평가 기준을 일부러 주지 않았습니다. 실제 발주는 친절한 채점표와 함께 오지 않기 때문이죠. 참고로 영상과 이 글의 데모 데이터는 모두 익명화된 가상 정보입니다.

한 가지 덧붙이면, 이 실험 이후 두 모델 모두 후속 버전이 나왔습니다. 그래도 이 기록을 그대로 내보내는 이유는 결론이 특정 버전의 점수가 아니라 "검증 루프가 있느냐"에 관한 것이기 때문이에요. 모델은 계속 바뀌지만, 발주자가 결과물을 검수하는 기준은 바뀌지 않습니다.

속도는 Fable의 압승이었습니다

먼저 인정할 것부터 인정하고 가겠습니다. Fable 5는 48분 14초 만에 프로젝트를 완주했습니다. Opus 5의 1시간 15분 24초보다 27분이나 빨랐고, 실험에 참여한 네 모델 중에서도 압도적인 1위였어요. 작업 관리 기록도 깔끔했고, 자체 테스트 시나리오를 만들어 전부 통과시킨 뒤 완료를 선언했습니다.

실험에 참여한 네 모델의 소요 시간과 세션 비용. 비용은 공개 단가 기준 추정치이며, 집계 방식이 모델마다 달라 직접 비교는 어렵습니다. 이미지 출처 : YouTube 'Kimi K3 vs 클로드, AI 4개에 같은 외주 프로젝트를 통째로 맡겨봤습니다' by 리트머스

세션 비용은 Fable이 약 $111.70, Opus가 약 $71.35로 추정됐습니다. 요약하면 이번 기록에서 Fable은 더 빨랐고 더 비쌌습니다. 외주개발 견적의 언어로 옮기면 "더 비싼 인력이 더 빨리 끝냈다"는 상황인데요. 문제는 그 속도로 만든 결과물이 검수를 통과했는가입니다. 여기서부터 두 모델의 길이 갈립니다.

Fable이 미끄러진 곳: 시험지를 자기가 냈습니다

Fable의 자체 테스트는 전부 초록불이었습니다. 그런데 실측에서 정정전표 화면에 0.1kg을 입력하자 서버가 거절했어요. 원인을 따라가 보니 설계 단계에서 무게 필드를 정수로만 받도록 정해놓고, 자체 테스트도 정수로만 돌렸던 겁니다. 자기가 낸 시험지로는 만점인데, 소수점 무게가 필수인 농산물 거래의 현실 앞에서는 첫 입력부터 막힌 거죠.

수량 조정에 -0.1을 입력하자 서버가 정수만 받겠다며 거절합니다. 이미지 출처 : YouTube 'Kimi K3 vs 클로드, AI 4개에 같은 외주 프로젝트를 통째로 맡겨봤습니다' by 리트머스

빠른 완주의 비결이 알고 보니 검증 범위를 스스로 좁힌 데 있었다는 것, 이번 실험에서 가장 곱씹게 되는 장면입니다. 거래 후 화면이 바로 갱신되지 않는 문제도 함께 발견됐습니다. 촬영 중에는 "똑똑한 애가 머리를 굴려서 빨리 끝내고 쉬다가 털린 것"이라는 평이 나왔는데, 저희 생각에도 이만한 요약이 없어요.

외주개발 발주자 입장에서 이 장면이 중요한 이유는 따로 있습니다. "테스트 다 통과했습니다"라는 보고는 개발사가 발주자에게 가장 자주 하는 말인데, 이 실험은 그 말이 무엇을 보장하고 무엇을 보장하지 않는지 정확히 보여주거든요. 테스트 통과는 "만든 사람의 기준에 맞다"는 뜻이지 "현장 규칙에 맞다"는 뜻이 아닙니다. 그 둘의 간격을 메우는 게 검수이고, AI가 짠 코드일수록 그 간격은 넓어질 수 있습니다.

Opus가 이긴 곳: 완성 선언 전에 자기를 의심했습니다

Opus 5의 세션 로그에서 갈림길이 보였습니다. 자체 테스트 53개를 만들어 전부 통과시킨 것까지는 Fable과 비슷한데, 그 뒤 행동이 달랐습니다. 멈추지 않고 실제 브라우저를 띄워 결과물을 다시 검증했고, 그 과정에서 로그인, 라우팅 가드, 모바일 환경변수 버그 세 개를 스스로 찾아 고친 기록이 남아 있었어요. 테스트 통과를 완료로 치지 않고 실제 화면으로 재검증하는 루프, 이것이 두 모델의 판정을 가른 결정적 차이였다고 저희는 보고 있습니다.

마감 후 정정 시나리오의 Opus 결과물. 원본은 그대로 두고 변경량과 사유가 이력으로 남습니다. 이미지 출처 : YouTube 'Kimi K3 vs 클로드, AI 4개에 같은 외주 프로젝트를 통째로 맡겨봤습니다' by 리트머스

Fable이 미끄러졌던 바로 그 정정전표 시나리오에서 Opus는 소수점 수량(-0.2kg)과 금액(-240원)까지 처리하고, 원본을 보존한 채 변경 사유를 이력으로 남겼습니다. 이 장면을 끝까지 닫은 건 실험에 참여한 네 제품 중 Opus 하나뿐이었습니다. 화려한 신규 기능이 아니라 "마감된 거래를 규칙대로 되돌릴 수 있는가" 같은 역방향 흐름에서 실력이 갈렸다는 점을 기억해 두시면 좋겠어요.

판정: 6 vs 9, 그리고 이 숫자를 읽는 법

실무 시나리오 10개 기준 최종 판정은 Fable 6개, Opus 9개였습니다.

네 모델의 판독 결과표. 이 글에서 다룬 Fable 5는 6개, Claude Opus 5는 9개를 닫았습니다. 이미지 출처 : YouTube 'Kimi K3 vs 클로드, AI 4개에 같은 외주 프로젝트를 통째로 맡겨봤습니다' by 리트머스

이 숫자를 "Opus가 Fable보다 좋은 모델"로 읽으면 곤란합니다. 이건 한 번의 실행에서 나온 기록이고, 두 모델은 우열이라기보다 성향이 달랐거든요. 정리하면 이렇습니다.

• Fable 5: 방향을 빠르게 맞추는 힘. 요구를 빠르게 형태로 만들어 보여주는 내부 프로토타입, 별도 QA를 붙일 수 있는 상황에서 48분이라는 속도는 분명한 가치입니다.
• Opus 5: 끝까지 닫는 힘. 취소, 정정, 권한 같은 역방향 흐름까지 검증돼야 하는 출시용 개발이라면 이번 기록에서는 이쪽이 앞섰습니다.
• 공통: 네 모델 모두 오프라인 복구 시나리오는 '부분'에 그쳤습니다. 여러 기기가 같은 거래를 올렸을 때의 충돌 정책을 고객도 정해주지 않았기 때문이에요.

결국 "어느 등급을 쓸까"보다 먼저 물어야 할 것은 "이 프로젝트에 필요한 게 속도인가 마감인가"라는 질문이었습니다. 등급표는 그 질문에 답해주지 않더라고요.

이 실험이 AI 외주개발 발주자에게 남긴 검수 기준 3가지

여기까지가 실험 기록이라면, 지금부터는 그 기록을 외주개발 발주자의 언어로 옮겨보겠습니다. 저희가 이 실험 뒤에 고객 미팅에서 실제로 꺼내 쓰게 된 기준이에요.

1. "어떤 모델을 쓰나요?" 대신 "완료 선언 전에 무엇을 다시 확인하나요?"

모델 이름은 결과물을 보장하지 않았습니다. 같은 도구, 같은 문서, 같은 프롬프트에서 더 높은 등급이 더 적게 닫았으니까요. 판정을 가른 건 테스트 통과 뒤에 실제 화면을 다시 눌러보는 루프의 유무였습니다. 개발사에 물어야 할 것은 도구 목록이 아니라, 완료라고 말하기 전에 무엇을 어떤 순서로 다시 확인하는지입니다. 이 질문에 절차로 답하지 못하는 곳이라면 모델이 무엇이든 같은 위험을 안게 됩니다.

2. 자체 테스트 통과는 증거가 아니라 출발점입니다

Fable의 테스트는 전부 통과했지만 첫 입력에서 막혔습니다. 테스트를 만든 주체가 결과물을 만든 주체와 같으면, 시험지와 답안지가 같은 손에서 나오죠. 그래서 검수는 만든 쪽의 테스트가 아니라 발주자의 현장 시나리오로 해야 합니다. 이 실험에서 저희가 쓴 시나리오 10개도 "역할별 진입", "45분 내 취소", "마감 후 정정", "기준가 변경이 현장 단가에 반영되는가"처럼 전부 현장에서 실제로 벌어지는 일이었어요. 외주개발 검수의 시험지는 발주자가 내야 합니다.

3. 정답이 없는 요구는 구현이 아니라 질문으로 돌아와야 합니다

오프라인 복구 시나리오는 네 모델 모두 닫지 못했습니다. 모델의 잘못이 아니라, 충돌 정책이라는 정답을 고객이 정하지 않았기 때문이죠. 검증 루프가 있는 모델도 정답 없는 요구는 끝까지 닫지 못했고, 그런 요구는 코드가 아니라 질문으로 발주자에게 돌아와야 했습니다. 좋은 개발사의 신호 하나는 착수 전에 이런 질문이 많이 오는 것입니다. 기능명세가 왜 그렇게 중요한지는 외주개발 사기, 90%는 '기능명세 부재'에서 시작합니다에서 따로 다뤘습니다.

리트머스는 AI 외주개발을 이렇게 검증합니다

이 기준은 저희가 실험 뒤에 새로 만든 게 아니라, 실험으로 다시 확인한 것에 가깝습니다. 리트머스는 상담과 견적, 기획, 개발 전 과정에 AI를 쓰는 개발사고, 그래서 "AI가 실행하고 사람이 검증한다"를 운영 원칙으로 두고 있어요. 구체적으로는 이렇게 일합니다.

• 명세가 단일 진실원천입니다. 요구사항을 마크다운 명세로 저장소 안에 두고, AI 코딩 에이전트는 그 명세를 읽고 구현합니다. 요구 ID가 명세, 작업, 코드, 테스트까지 이어지도록 추적 사슬을 남깁니다.
• 사람이 승인하는 게이트가 세 번 있습니다. 명세 리뷰, 작업 리뷰, 그다음이 구현 자율인데, AI의 비결정성과 환각을 전제로 설계한 구조입니다.
• 테스트 통과를 완료로 치지 않습니다. 내부 가이드의 표현을 그대로 옮기면 "통과는 명세와 일치일 뿐 옳다가 아니다"이고, QA는 Given/When/Then 시나리오로 실제 화면에서 확인합니다.
• 6주 MVP는 기획, 디자인, 개발, QA를 6주 안에 끝내는 방식입니다. QA가 일정 안에 들어 있어서 속도를 이유로 검수를 빼지 않습니다.

이 방식으로 실제 AI 기능이 들어간 서비스도 만들어 왔습니다. 특허 아이디어를 GPT-4o로 분석해 명세서 초안과 선행기술 보고서를 만드는 SaaS 넥스팁, ChatGPT와 Gemini를 병행 테스트해 최적 조합을 찾은 헬스케어 AI 피드백 앱 백프로핏이 대표적이에요. 영수증 인식에 Gemini와 Vertex AI 폴백 구조를 쓴 요식업 원가분석 SaaS는 요즘 AI 외주개발, 4000만 원이면 이런 것까지 만듭니다 영상에서 실제 화면과 함께 공개했습니다. AI 기능을 만드는 프로젝트든 AI로 만드는 프로젝트든, 마지막에 검수하는 쪽은 사람이어야 한다는 원칙은 같습니다.

이렇게 일한 결과가 숫자로도 남아 있습니다. 5년차에 누적 계약 500건을 넘겼고 매출의 절반이 재계약에서 나옵니다. 2025년 국민브랜드대상 외주 개발 플랫폼 부문에 이어 2026년에는 포브스코리아 최고의 브랜드 대상(AI 에이전시 부문)과 대한민국 AI 산업 대상(AI 기반 외주 개발 에이전시 부문)을 받았고요. 재계약이 절반이라는 건, 첫 프로젝트의 검수를 통과한 고객이 다음 프로젝트를 다시 맡겼다는 뜻입니다.

모델 선택보다 중요한 것

리트머스는 AI와 바이브코딩을 실전 외주개발에 가장 깊게 붙여 쓰는 개발사입니다. 새 모델이 나올 때마다 이렇게 실제 프로젝트 환경에서 직접 검증하고, 프로젝트 성격에 따라 속도형 모델과 마감형 모델을 다르게 배치하되 마지막 검수는 사람이 현장 시나리오로 합니다. AI 외주개발을 검토 중이시라면, 우리 프로젝트가 바이브코딩 외주에 적합한지부터 검토해드립니다.

그런데 여기서 자연스럽게 다음 질문이 남습니다. 같은 회사 안에서 등급 차이가 이랬다면, 회사도 다르고 도구도 다른 GPT-5.6 Codex와 Claude Opus 5가 붙으면 어떻게 될까요?

그 비교는 아래 글에 정리해 두었습니다. 화면이 가장 예뻤던 결과물이 검수에서 0개로 끝난 장면과 두 제품의 세션 로그까지 다루고 있어서, 이 글에서 본 "등급보다 검증 루프" 관점을 다른 조합으로 확장하는 데 도움이 될 겁니다.

GPT-5.6 Codex vs Claude Opus 5 실사용 비교: 같은 외주 프로젝트를 통째로 맡겨봤습니다 (2026)

6주 MVP 방식이 우리 프로젝트에 맞는지부터 알고 싶으시다면, 무료 견적 상담으로 먼저 진단해 드립니다.