by Kainos·2026.6.23·7분 읽기
얼마 전까지만 해도 고민의 초점은 “어떤 AI 툴을 쓸 것인가”였습니다. Claude냐 Codex냐, 어느 모델이 더 똑똑한가를 비교하고 하나를 골랐습니다. 그런데 도구가 충분히 좋아진 지금, 질문은 바뀌었습니다 — “여러 AI 툴을 어떻게 함께 쓸 것인가, 어떻게 협업시킬 것인가”. 이 글은 그 질문을 백엔드 API 개발이라는 구체적인 현장에 대입해 본 기록입니다.
도구를 고르던 시대에서, 협업시키는 시대로
AI 코딩 에이전트를 실제 개발 업무에 붙이다 보면 단순한 질문이 생깁니다 — 개발은 Claude가 하는 게 나은가, Codex가 하는 게 나은가. 리뷰는 어느 쪽이 더 좋은가. 예전이라면 둘 중 더 나은 하나를 고르는 문제로 끝났을 것입니다. 하지만 지금은 두 도구 모두 실무에 쓸 만큼 성숙했고, 그래서 진짜 질문은 “누가 이기느냐”가 아니라 “둘을 어떻게 한 팀으로 묶느냐”가 됐습니다.
한동안은 Claude로 개발하고 Codex가 리뷰로 개선점을 짚는 방식이 충분히 효과적이었습니다. 그런데 백엔드 API 개발에 들어가면 결론이 그렇게 단순하지 않았습니다. 한 명의 천재보다, 역할이 분명한 두 명의 협업이 더 안정적인 순간이 분명히 있었기 때문입니다.
누가 더 낫냐가 아니라, 어떻게 나누냐
결론부터 말하면, 어느 한쪽이 절대적으로 우위에 있는 구조가 아닙니다. 핵심은 두 도구를 같은 역할로 경쟁시키는 것이 아니라, 서로 다른 강점을 가진 팀으로 나누는 것입니다. 실제로 Codex 리뷰는 시드 개발 과정에서 구현 누락, 테스트 부족, 기존 패턴과의 불일치, OpenAPI·DB 정합성 문제를 잡는 데 강했습니다. 반대로 Claude는 모호한 요구사항을 구조화하고 도메인 판단을 내리는 데 강합니다.
두 도구의 성격 차이
Claude Max와 Claude Code는 요구사항을 해석하고, 모호한 문제를 구조화하고, 복잡한 도메인 판단을 하는 데 강합니다. 새로운 기능의 방향을 잡거나 보안·성능·운영 리스크를 넓게 보는 데 적합합니다. 반면 ChatGPT Pro Codex는 repo 안에서 실제 파일을 읽고 수정하고, 명령을 실행하고, 테스트 결과를 반영하는 구현 루프에 강합니다.
| 항목 | Claude Max / Code | ChatGPT Pro Codex |
|---|---|---|
| 강점 | 요구사항 해석, 설계, 추론, 리스크 검토 | 구현, 테스트, 검증, 반복 작업 |
| 잘 맞는 작업 | 모호한 기능, 복잡한 도메인, 외부 연동, 정책 설계 | OpenAPI 구현, Liquibase, 단위 테스트, 패턴 적용 |
| 리뷰 관점 | 의미적 정합성, 아키텍처, 보안·성능 리스크 | repo 정합성, 구현 누락, 테스트 부족, 컴파일·스타일 |
| 위험 | 구현 검증이 약해질 수 있음 | 요구사항이 모호하면 기계적으로 구현할 수 있음 |
백엔드 API 개발에서 중요한 것
Spring Boot 기반 백엔드 API 개발은 단순히 Java 코드를 작성하는 일이 아닙니다. 다음 흐름은 창의성보다 순서·정합성·기존 패턴 준수·검증 루프가 중요합니다. 그래서 요구사항이 명확하고 기존 패턴을 따라가면 되는 구간은 Codex가 개발을 맡는 구조도 충분히 강점이 있습니다.
OpenAPI 수정 → openApiGenerate
스펙을 먼저 고치고 코드를 생성합니다. API 계약이 출발점이므로, 생성 코드와 손으로 짠 코드가 어긋나지 않게 맞추는 일이 중요합니다.
Liquibase changelog 작성
스키마 변경을 changelog로 남기고 include 순서를 맞춥니다. 누락되면 빌드가 아니라 마이그레이션 단계에서 터지므로 정합성 확인이 필수입니다.
Entity / Repository / Service / Converter / DelegateImpl 구현
기존 계층 패턴을 그대로 따라 채웁니다. 창의성보다 일관성이 중요한 구간이라, 기존 코드의 관례를 얼마나 충실히 따르는지가 품질을 가릅니다.
단위 테스트 작성
성공·실패·경계 케이스를 촘촘히 덮습니다. 구현과 테스트를 같은 루프 안에서 오가며 보강하는 작업에 강점이 큽니다.
compileJava / checkstyleMain / test 검증
컴파일·스타일·테스트를 돌려 실패를 보고 다시 고칩니다. 실제로 빌드되는 코드인지 끝까지 확인하는 검증 루프가 파이프라인의 마지막 관문입니다.
반대로 포인트 정책, 정산, 권한 모델, 외부 기관 API 연동, 상태 머신처럼 도메인 판단이 큰 기능은 Claude가 먼저 설계하거나 개발 방향을 잡는 편이 안정적입니다.
기존 방식 — Claude 개발 + Codex 리뷰
Claude가 설계와 개발을 주도하고, Codex가 리뷰와 검증을 맡고, Claude 또는 사람이 수정을 반영하는 흐름입니다. 장점이 분명합니다.
- 요구사항이 모호해도 Claude가 의도를 해석하며 방향을 잡기 좋다.
- 복잡한 비즈니스 규칙이나 예외 정책을 코드에 녹이는 데 유리하다.
- 대화형 루프를 돌며 빠르게 구현 방향을 조정할 수 있다.
- Codex가 후단에서 구현 누락·테스트 부족·정합성 문제를 잡아준다.
다만 약점도 있습니다. Claude가 제안한 코드가 실제 repo 패턴과 미묘하게 어긋날 수 있고, OpenAPI 생성 코드·Liquibase include·checkstyle·테스트 실행 같은 검증이 후행으로 밀릴 수 있습니다. 즉 설계와 개발의 유연성은 좋지만, 구현 정합성 검증은 뒤에서 보강해야 합니다.
대안 방식 — Codex 개발 + Claude 리뷰
순서를 뒤집어, Claude가 요구사항과 설계 방향을 정리하면 Codex가 실제 repo에서 구현·테스트·검증을 돌리고, Claude가 설계·도메인·리스크 관점에서 리뷰한 뒤 Codex가 수정과 재검증을 합니다. 이 방식의 장점은 백엔드 API 개발에서 특히 뚜렷합니다.
Codex는 구현 중에 실제 파일을 수정하고, Gradle 명령을 실행하고, 실패 결과를 보고 다시 고칠 수 있습니다. OpenAPI-first, Liquibase, JPA, Service, 테스트처럼 순서와 정합성이 중요한 작업에서 안정적인 구현 루프를 만들기 좋습니다. 그 뒤에서 Claude는 이런 질문을 던지는 역할을 맡습니다.
- 이 API가 진짜 요구사항을 만족하는가?
- 권한 경계가 이상하지 않은가?
- DB 모델이 나중에 확장 불가능하지 않은가?
- 서비스 책임이 과하게 섞이지 않았는가?
- 예외와 상태 정의가 비즈니스적으로 맞는가?
정리하면
두 방향 모두 정답이 될 수 있습니다. 요구사항이 명확하고 패턴을 따라가는 API는 Codex가 개발하고 Claude가 리뷰하는 편이, 도메인 판단이 큰 기능은 Claude가 설계하고 Codex가 정합성을 검증하는 편이 안정적이었습니다. 작업의 성격에 따라 누가 앞에 서고 누가 뒤에서 거를지를 바꾸는 것입니다.
결국 목표는 도구의 우열을 가리는 것이 아니라, 서로 다른 강점을 팀으로 묶어 약점을 겹쳐 메우는 것입니다. 한쪽은 의미를 보고, 한쪽은 정합성을 봅니다. 그 둘을 같은 파이프라인 위에 올려 두는 것이 지금까지의 결론입니다.
“어떤 AI를 쓸까”를 고르던 시대는 사실상 지났습니다. 이제는 여러 AI를 어떤 순서로, 어떤 역할로 협업시킬까를 설계하는 일이 더 중요해졌습니다. 개발자의 역할도 코드를 직접 짜는 사람에서, AI들의 협업을 지휘하고 그 결과를 책임지는 사람으로 옮겨가는 중입니다.