Opus 5 실무 리뷰 — 코딩은 최고, 협업은 고통. 멀티모델 전략이 답이다
API 엔드포인트 3개 추가를 부탁했더니 Opus 5가 완벽한 코드를 짜냈습니다. 문제는 요청하지 않은 타입 정의 6개와 유틸 함수 4개까지 손댔다는 점이었죠. 이 작업에서 구현은 30분, PR 리뷰는 2시간 30분이 걸렸어요. 6주간 실무에 투입하며 내린 결론은 이렇습니다. 설계와 난이도 높은 구현은 Opus 5, 반복 작업과 정리는 Sonnet이나 Haiku로 역할을 나누세요. 한 모델로 모든 걸 해결하려다간 품질은 올라가지만 협업 부담이 감당 안 됩니다.
어떤 기준으로 평가했나요?
저는 REST API 코드 생성과 리팩토링 작업에 Opus 5를 6주간 투입했습니다. 주로 Express.js와 TypeScript 환경에서, 하루 평균 5~8개 태스크를 처리했죠. 평가 기준은 네 가지예요. 코드 품질(테스트 통과율, 타입 안전성), 범위 준수(요청한 것만 수정했는가), 리뷰 부담(PR 리뷰에 걸린 시간), 협업 효율성(재작업 횟수). 벤치마크 점수가 아니라 실제로 머지까지 걸린 시간을 쟀습니다. Reddit에 올라온 실사용자 보고 "Opus 5 is an incredible coder and really painful to work with"와 제 경험이 정확히 일치했거든요.
같은 작업을 Opus 5 단독과 멀티모델로 돌려봤습니다
유저 인증 API 엔드포인트를 추가하는 작업을 예로 들게요. 요청 사항은 간단했습니다. POST /auth/login, POST /auth/logout, GET /auth/me 세 개만 구현하면 되는 거죠.
Opus 5 단독으로 돌렸을 때: 30분 만에 완벽한 코드가 나왔어요. 타입 정의도 빈틈없고, 에러 핸들링도 촘촘했죠. 문제는 요청하지 않은 부분까지 손댔다는 점입니다. 기존 미들웨어 2개를 리팩토링했고, 공통 유틸 함수 4개를 새로 만들었으며, 심지어 데이터베이스 마이그레이션 파일까지 추가했습니다. 변경된 파일이 14개였어요. PR 리뷰에 2시간 30분이 걸렸고, "왜 이 부분까지 바꿨죠?"라는 질문을 7번 남겼습니다. 코드 자체는 훌륭했지만 범위 폭주(scope creep) 때문에 협업이 고통스러웠어요.
멀티모델로 나눴을 때: Opus 5에게는 설계와 핵심 로직만 맡겼습니다. "세 엔드포인트의 타입 정의와 컨트롤러 로직만 작성해줘. 기존 파일은 건드리지 마." 이렇게 명확히 제한했죠. 결과물을 받은 뒤 반복 작업(테스트 코드 작성, 주석 추가, 린트 수정)은 Sonnet 5에게 넘겼어요. Sonnet은 요청한 것만 정확히 처리했고, 변경 파일은 5개로 줄었습니다. PR 리뷰 시간은 45분. 재작업은 한 번도 없었죠. Opus 5의 코드 품질을 유지하면서도 협업 부담을 3분의 1로 줄인 겁니다.
왜 멀티모델 전략으로 전환했나요?
전환점은 하루 작업 8건 중 6건에서 범위 폭주가 발생한 날이었습니다. PR 리뷰 누적 시간이 5시간을 넘었죠. 그날 저녁 Reddit에서 "I realize the majority of rant posts on Claude models are by users who cannot set up environment correctly"라는 글을 봤어요. 환경 세팅 문제라는 반론이었는데, 저는 정반대로 받아들였습니다. "모델을 잘못 쓰고 있구나."
다음 날부터 역할 분담을 시작했어요. Opus 5에게는 두 가지만 맡겼습니다. 아키텍처 설계와 난이도 높은 구현(복잡한 비즈니스 로직, 타입 추론이 까다로운 제네릭 함수 등). 나머지는 Sonnet 5나 Haiku로 넘겼죠. 테스트 코드 작성, 주석 추가, 린트 수정, 간단한 CRUD 구현 같은 반복 작업 말이에요. 2주 후 재작업 횟수가 60% 줄었고, PR 리뷰 시간은 절반으로 떨어졌습니다. Opus 5의 강점(코드 품질)은 유지하면서 약점(범위 폭주, 리뷰 부담)은 제거한 셈이죠.
역할 분담 기준은 이렇습니다. 작업 난이도가 높거나 설계 판단이 필요하면 Opus 5, 명확한 요구사항이 있고 반복 가능한 작업이면 Sonnet 또는 Haiku. 예를 들어 새 기능 아키텍처 설계는 Opus 5, 그 설계를 바탕으로 한 CRUD 엔드포인트 구현은 Sonnet, 린트 수정과 포매팅은 Haiku예요.
멀티모델 전략을 실무에 어떻게 적용하나요?
핵심은 작업 분해, 범위 제한, 리뷰 체크리스트 세 가지입니다. "유저 대시보드 구현"이라는 큰 요청 대신 "구조 설계(Opus 5) → 컴포넌트 구현(Sonnet) → 스타일링(Haiku)"로 쪼개요. Opus 5에게 요청할 땐 "이 파일만 수정", "기존 코드는 건드리지 마" 같은 제약을 명시하고, 결과물은 "요청하지 않은 변경이 있는가?"를 먼저 확인합니다.
비용 측면도 고려해야 해요. 모든 작업을 무거운 모델로 돌리면 API 사용량이 빠르게 커집니다. 역할 분담을 시작한 뒤 한 달 청구서를 확인했더니 이전 달보다 사용량이 줄어 있더군요. 품질은 유지하면서도 비용 부담을 낮출 수 있었습니다.
Opus 5가 짠 주석에는 "leveraging", "seamless" 같은 AI 특유의 표현이 자주 등장해요. 이걸 그대로 머지하면 코드베이스가 슬롭으로 오염되죠. 저는 Sonnet에게 "주석을 자연스러운 한국어로 다시 써줘"라고 넘기거나, 직접 손봅니다.
자주 묻는 질문
Q. Opus 5 대신 Sonnet만 쓰면 안 되나요? A. 난이도 낮은 작업이라면 충분합니다. 하지만 복잡한 비즈니스 로직이나 까다로운 제네릭 함수는 Sonnet이 놓치는 경우가 많았어요. 제 경험상 복잡한 작업 10건 중 4건에서 재작업이 필요했습니다.
Q. 멀티모델 전환 비용은 얼마나 드나요? A. 작업 분해와 모델 전환에 하루 평균 20분 정도 추가됩니다. 하지만 리뷰 시간이 절반으로 줄어서 전체적으로는 시간이 절약돼요.
Q. Haiku는 어떤 작업에 쓰나요? A. 린트 수정, 포매팅, 간단한 주석 추가처럼 판단이 거의 필요 없는 기계적 작업에 씁니다. 속도가 빠르고 비용이 낮아서 반복 작업을 여러 번 돌려도 부담이 없어요.
Q. 범위 폭주를 완전히 막을 수는 없나요? A. 프롬프트에 제약을 명시해도 Opus 5는 "개선 가능한 부분"을 찾으려는 경향이 있습니다. 완전히 막기보다는, 설계 단계에만 쓰고 반복 작업은 다른 모델에 넘기는 게 현실적이에요.
2주간 멀티모델 전략을 적용하며 가장 크게 바뀐 건 PR 리뷰 시간입니다. Opus 5 단독 사용 때는 하루 평균 3시간이었는데, 역할 분담 후엔 1시간 30분으로 줄었어요. Opus 5를 "만능 도구"가 아니라 "전문가 중 한 명"으로 대하니, 오히려 그 강점이 더 빛났습니다.