Claude Opus 5가 2026년 7월 24일 출시됐다. SWE-bench Pro 기준 69.2에서 79.2로, 두 달 만에 10점 점프다. 가격은 입력 100만 토큰당 5달러, 출력 25달러로 전작 Opus 4.8과 동일하다. CursorBench 3.2 최대 노력 설정에서 Fable 5 최고 점수와 0.5% 이내 차이를 내면서 비용은 절반이다. 벤치마크만 보면 지금 당장 팀 워크플로우에 투입하지 않을 이유가 없어 보인다.
그런데 잠깐 멈춰야 한다. 더 좋은 모델을 기존 파이프라인에 꽂는다고 결과가 자동으로 좋아지지 않는다. dev.to에 올라온 'AI Coding Isn't the Problem. AI Engineering Is.'라는 글이 이 지점을 정확히 짚는다. 글의 핵심 주장은 간단하다. AI 코딩 어시스턴트가 일관성 없는 결과를 내는 이유는 모델 지능의 문제가 아니라 컨텍스트 부재의 문제라는 것이다. 아키텍처 결정 이력, 기술 부채 관리 방식, 보안 규칙, 코딩 컨벤션—이것들을 주지 않으면 AI는 프로젝트 지식 대신 통계적 확률로 빈칸을 채운다. 같은 프롬프트가 전혀 다른 시스템을 만들어내는 이유가 여기에 있다.
이 두 사실을 겹쳐보면 Opus 5 도입의 실제 과제가 보인다. 문제는 모델 교체가 아니다. 모델에 무엇을 먹일 것인가다. Opus 5의 100만 토큰 컨텍스트 윈도우는 기본값이자 최댓값으로 제공된다. 이론적으로는 대규모 코드베이스 전체를 한 번에 넣을 수 있다. 하지만 코드베이스를 통째로 붙여넣는다고 엔지니어링 컨텍스트가 전달되지 않는다. 왜 이 아키텍처를 선택했는지, 어떤 트레이드오프를 수용했는지, 어떤 규칙은 절대 위반하면 안 되는지—이것들은 코드 바깥에 있다.
그렇다면 AI-First 팀이 Opus 5를 워크플로우에 제대로 심으려면 무엇을 먼저 해야 하는가. 세 가지 레이어로 나눠서 생각하는 것이 현실적이다.
첫째, 아키텍처 컨텍스트를 문서로 만들어서 시스템 프롬프트에 주입하라. '왜 이 아키텍처인가', '어떤 결정이 이미 내려졌는가', '어떤 패턴은 금지인가'를 ADR(Architecture Decision Record) 형태로 관리하고, 이걸 Opus 5를 호출하는 모든 에이전트의 시스템 프롬프트에 포함해야 한다. 컨텍스트 윈도우가 넓어졌다는 것은 이 문서를 더 풍부하게 넣을 수 있다는 뜻이지, 문서 없이도 된다는 뜻이 아니다.
둘째, 노력(effort) 설정에 따른 행동 차이를 파이프라인 설계에 반영하라. Opus 5는 xhigh나 max 설정에서 사고 모드를 끌 수 없다. Opus 4.8에는 없던 제약이다. 기존 워크플로우를 그대로 모델명만 바꿔 이식하면 예기치 않은 오류를 만난다. API 호출 시 effort 파라미터를 명시하고, 속도가 중요한 단계와 품질이 중요한 단계를 분리해 각각 적절한 설정을 적용해야 한다.
셋째, 자동 폴백(fallback) 기능을 에이전트 파이프라인 설계에 활용하라. 이번 출시와 함께 안전 분류기에 의해 차단된 요청을 다른 모델로 자동 전환하는 기능이 API에 추가됐다. 에이전트가 보안 관련 요청을 처리하다 막히는 상황에서 파이프라인 전체가 멈추는 대신, 적절한 모델로 라우팅되도록 미리 설계해 두면 안정성이 크게 높아진다.
비용 ROI 관점에서도 냉정하게 따져야 할 부분이 있다. CursorBench에서 Fable 5와 0.5% 이내 차이라는 숫자는 매력적이지만, 그건 최대 노력 설정 기준이다. 벤치마크 출처인 dev.to 분석 기사가 지적하듯, 어느 effort 레벨에서 측정했는지가 명시되지 않은 수치는 비용 비교에 거의 쓸모가 없다. 에이전트 루프에서 실제 총비용은 모델 단가가 아니라 '동일한 결과를 얻는 데 몇 번의 시도가 필요한가'로 결정된다. 컨텍스트가 부족한 상태로 Opus 5를 돌리면 더 강한 모델이 더 그럴듯한 틀린 답을 더 빠르게 만들어낸다. 재시도 비용이 누적된다.
팀 구조 관점에서도 함의가 있다. Opus 5가 Fable 5 수준에 근접하는 코딩 능력을 절반 가격에 제공한다는 것은, 자동화할 가치가 없다고 여겼던 작업들의 경계를 다시 그릴 여지가 생겼다는 의미다. 하지만 'AI Coding Isn't the Problem. AI Engineering Is.' 기사가 제기한 질문—"AI가 참여하는 엔지니어링 시스템을 누가 설계하는가"—은 여전히 사람의 몫이다. 더 강한 모델이 나올수록 아키텍처 원칙을 정의하고, 엔지니어링 표준을 코드화하고, AI 출력을 검증하는 역할의 무게가 오히려 커진다. 모델이 강해질수록 그 모델에게 맥락을 주지 않았을 때의 위험도 커지기 때문이다.
전망을 정리하면 이렇다. Opus 5의 가격·성능 비율은 일상적인 코딩·업무 자동화에 투입하는 '기본 모델'로서 설득력이 높다. Anthropic의 모델 라인업이 '누가 더 똑똑한가'에서 '누가 더 저렴하게 똑똑한가'로 경쟁 축을 옮기는 시점에 나온 이 모델은, 팀의 에이전트 파이프라인에서 Fable 5를 쓰던 자리를 상당 부분 대체할 수 있다. 단, 초장문 컨텍스트나 복잡한 다단계 추론이 핵심인 작업은 여전히 Fable 5가 유리하다. 결국 모델을 교체하는 것보다, 어떤 작업에 어떤 모델을 어떤 컨텍스트와 함께 쓸 것인지를 설계하는 것이 AI-First 팀의 실제 과제다. 더 좋은 도구가 생겼다. 이제 그 도구를 제대로 쓰는 시스템을 만들 차례다.