「Claude Code와 Codex, 어느 쪽이 더 좋은가요?」라는 기사는 이미 충분히 읽었습니다.

제가 알고 싶었던 것은 어느 한 쪽을 선택하는 이야기가 아니라, 양쪽을 동시에 수중에 두고 계속 사용하는 운용 방식이었습니다. 결론부터 말하자면, 저는 Claude Code를 개발의 주축으로 삼은 채, Codex를 「언제든 부를 수 있는 세컨드 오피니언 (Second Opinion)」으로서 슬래시 커맨드(Slash Command)화 하여 공존시키고 있습니다. 이 기사는 그 구체적인 구현과 실운용에서 발견한 구분 사용 패턴을 정리한 것입니다.

비교론이 아니라 「공존시키는 설계」에 관한 이야기입니다.

AI에게 코드를 작성하게 하다 보면 반드시 다음과 같은 상황에 직면합니다.

• Claude Code의 제안이 정말 타당한지 확신이 서지 않는다
• 버그의 원인을 쫓고 있는데, 똑같은 사고 습관으로 루프(Loop)에 빠져 있다
• 「이 문구, 이대로 괜찮은 걸까?」라며 혼자서 계속 고민하고 있다

이는 인간의 페어 프로그래밍 (Pair Programming)이나 리뷰와 마찬가지로, 또 다른 관점이 있다면 순식간에 빠져나올 수 있는 경우가 많습니다. 다만, 그러기 위해 다른 도구로 컨텍스트 (Context)를 옮기고, 프롬프트 (Prompt)를 다시 구성하고…… 하다 보면 번거로워서 결국 하지 않게 됩니다.

그래서 저는 결단했습니다. 주축은 움직이지 않는다. 개발의 중심은 Claude Code인 채로, 막혔을 때만 「세컨드 오피니언을 주세요」라고 슬래시 커맨드를 한 번 입력하면 Codex가 답해주는 구성으로 만든 것입니다.

역할은 다음과 같이 나누었습니다.

포인트는 Codex에게 편집을 시키지 않는 것입니다. read-only로 의견만 받고, 채택할지 여부는 저(와 주축인 Claude Code)가 결정합니다. 이렇게 하면 두 AI가 파일을 서로 차지하려는 사고도 발생하지 않습니다.

하고 있는 일은 놀라울 정도로 심플하며, codex exec를 read-only 샌드박스 (Sandbox)에서 호출하는 것뿐입니다. 이것을 매번 직접 입력하는 것은 번거로우므로, Claude Code 측의 **스킬 (Skill)**로 등록하여 /codex 한 번으로 호출할 수 있게 했습니다.

먼저 커맨드의 실체는 이것뿐입니다.

codex exec --full-auto --sandbox read-only --cd <project_dir> "<의뢰 내용>"

이를 스킬화하기 위해 다음과 같은 Markdown을 준비하고 있습니다 (발췌).

---
name: codex
description: >
...

이 「확인이나 질문은 필요 없습니다. 구체적인 제안까지 출력해 주세요」라는 한 문장이 은근히 효과적입니다. 이것이 없으면 Codex가 「어떤 관점에서 리뷰할까요?」라고 되물어와서, 세컨드 오피니언이어야 할 것이 왕복 랠리(Rally)가 되어버립니다. 전제를 미리 없애 놓으면 한 번에 사용할 수 있는 답변이 돌아옵니다 (이 주의사항은 후술하겠습니다).

실운용에서 /codex를 호출하는 것은 대체로 다음 5가지 패턴으로 수렴했습니다. 패턴 모음으로서 그대로 사용할 수 있도록, 던지고 있는 프롬프트의 형태와 함께 올립니다.

codex exec --full-auto --sandbox read-only --cd ./app \
"이 모듈을 리뷰하고, 지적 사항을 Critical / Warning / Info로 
분류해 주세요. 확인은 필요 없으며, 구체적인 수정 코드까지 제시해 주세요."

이전에 어떤 프로젝트에서 Claude Code에게 리뷰를 부탁했더니, 사소한 스타일 지적과 중대한 버그 지적이 같은 수준으로 나열되어 곤란했던 적이 있었습니다. 그때 주축 측의 프롬프트에 중요도 레벨 (Critical / Warning / Info) 분류 기준을 퓨샷 (Few-shot) 예시로 3개 첨부했더니, 리뷰 결과 확인 시간이 절반으로 줄었습니다. 똑같은 「중요도로 분류하게 하는」 형태를 Codex 측에도 이식하면, 두 AI의 지적을 같은 잣대로 나열할 수 있어 대조 작업이 단번에 쉬워집니다.

혼자서 설계하고 있으면 자신의 특기 있는 형태로 무의식중에 치우치게 됩니다. 이때 「다른 AI라면 어떻게 자를 것인가」를 물으면, 고정관념이 가시화됩니다.

codex exec --full-auto --sandbox read-only --cd . \
"이 프로젝트의 구성을 분석하고, 책임 분할 (Separation of Concerns) 관점에서 개선안을 제시해 주세요.\n확인 불필요, 디렉토리 구성안까지 구체적으로."

이것은 Codex가 특히 의지가 되었던 장면입니다. 개인이 운용하는 시스템에 8년 전의 PHP가 약 1만 줄 있었고, 500줄이 넘는 함수도 있는 상태였습니다. 수동으로는 건드리기 무서웠습니다. Claude Code를 통해 단계적으로 분할시켜 약 1만 줄을 3,500줄로 압축, 함수는 최대 50줄 이내까지 줄일 수 있었지만, "정말로 동작을 바꾸지 않았는가"에 대한 확신이 들지 않았습니다. 그래서 Codex에게 read-only로 차이점(diff) 관점에서만 리뷰를 시켜, 놓친 부분이 없는지 이중 체크했습니다. 작동 중인 코드에 손을 대는 공포는, 또 하나의 눈이 있는 것만으로도 상당히 완화됩니다.

같은 원인을 몇 번이고 의심하며 루프에 빠져 있을 때 탈출용으로 사용합니다.

codex exec --full-auto --sandbox read-only --cd . \
"인증 처리에서 드물게 에러가 발생하는 원인을 조사해 주세요.\n확인 불필요, 원인 특정과 수정안까지 자율적으로."

주축인 Claude Code와는 다른 모델이기에, 의심하는 지점이 다릅니다. "그 부분은 보지 못했다"라는 결과가 나오면 이기는 것입니다.

코드뿐만 아니라 에러 메시지나 README의 한 문장에도 사용합니다. "이 표현이 잘 전달될까?"를 혼자 고민하지 않고, 두 번째 시각을 얻습니다. 여기서도 판단하는 것은 자신이며, AI는 어디까지나 선택지를 늘려주는 역할입니다.

만약을 위해 보충하자면, 무엇이든 Codex에게 묻는 것은 아닙니다. 주축이 명확하게 잘하는 작업은 그대로 Claude Code에게 시킵니다.

예를 들어 테스트 일괄 생성입니다. 어떤 프로젝트에서 Laravel의 약 50개 API 엔드포인트에 테스트가 없어서, 수동이라면 2주를 예상했습니다. 이것을 Claude Code에게 기존 컨트롤러(Controller)를 읽게 하여 PHPUnit을 일괄 생성하게 했고, 3일 만에 약 200개를 생성했으며 그중 85%는 그대로 통과했습니다. 이런 종류의 "주축으로 완결되는 작업"에 굳이 세컨드 오피니언(Second Opinion)을 끼워 넣지는 않습니다. 이도류는 망설여질 때, 확신이 필요할 때 발동하는 보험이지, 상시 이중화하는 것이 아니라는 선긋기가 실운용에서는 중요했습니다.

망설여질 때의 판단은 이 표에 집약되어 있습니다.

가장 크게 부딪혔던 점은, Codex가 제안이 아니라 질문을 되돌려준다는 것이었습니다. "어떤 파일을 대상으로 할까요?", "관점을 지정해 주세요"라고 되물어오니, 세컨드 오피니언을 쓰려던 것이 오히려 왕복(interaction)만 늘어나 결국 손이 멈추게 됩니다.

대책은 앞서 언급한 대로, 프롬프트 끝에 "확인이나 질문은 불필요합니다. 구체적인 제안·수정안·코드 예시까지 자율적으로 출력해 주세요"를 기계적으로 반드시 붙이는 것입니다. 스킬(Skill) 템플릿에 아예 심어두면 붙이는 것을 잊어버릴 일도 없습니다. 문장으로 규칙을 쓰는 것보다 출력 형식을 처음부터 고정해 버리는 것이 확실하다는 점은, 주축 측의 리뷰 설계와 완전히 동일한 교훈이었습니다.

또 하나는 --sandbox read-only를 철저히 하는 것입니다. 세컨드 오피니언 역할에게 쓰기 권한을 주면, 의견을 내는 대신 멋대로 파일을 건드리게 되어 주축의 편집과 충돌합니다. 의견은 듣되, 손은 대지 못하게 한다를 구조적으로 담보해 두면 안심하고 호출할 수 있습니다.

• Claude Code를 주축으로 고정하고, Codex는 read-only 세컨드 오피니언으로서 공존시킨다 - 호출은 /codex 스킬 한 번으로. 실체는 codex exec --full-auto --sandbox read-only
• 사용하는 상황은 "리뷰·설계 상담·리팩토링 검증·버그 조사·문구 검토"의 5가지 장면
• 프롬프트에 "확인 불필요·제안까지 출력"을 반드시 붙여 질문 되돌리기를 방지
• 최종 판단은 인간. 두 AI는 선택지를 늘려주는 역할이며, 결정하는 것은 자신

"어느 쪽이 더 뛰어난가"를 비교하기보다 "어떻게 공존시킬 것인가"를 설계하는 편이 일상적인 개발을 훨씬 편하게 만들어 주었습니다. 도구의 승패가 아니라, 자신만의 전용 리뷰 체제를 구축한다는 발상입니다.

이 글이 도움이 되었다면, **좋아요·저장(Stock)**을 부탁드립니다. 큰 힘이 됩니다.

Claude Code·AI 에이전트·업무 자동화 구현 팁을 지속적으로 발신하고 있습니다. 팔로우해 두시면 새로운 소식을 받아보실 수 있습니다.

여러분은 AI의 제안에 확신이 서지 않을 때, 어떻게 세컨드 오피니언 (Second Opinion)을 구하시나요? 꼭 댓글로 알려주세요.