이 기사는 지금까지 Claude Code 하나로만 작업해 온 엔지니어가, Opus 4.7의 경험이 좋지 않아 Codex로 눈을 돌려보며 깨달은 점을 정리한 것이다.

실제로 사용해 본 소감은 많은 사람이 정리하고 있지만, 그러한 동작이 발생하는 이유에 대해 고찰하는 사람은 별로 보이지 않았다.

따라서 본 기사에서는,

• Claude Code와 Codex의 공식 정보
• 실제로 이용하며 관측한 동작
• 그로부터 도출한 가설

을 정리해 본다.

Anthropic / OpenAI에 공통되는 발전 과정

LLM은 문맥적 정합성을 우선시하기 쉽다

Claude / Codex를 포함한 현재의 LLM (Large Language Model)은 대량의 텍스트로부터:

「다음에 올 단어를 예측한다」

학습을 기반으로 하고 있다.

Anthropic / OpenAI 양측 모두, 이러한 next-token prediction (다음 토큰 예측) 방식의 학습을 전제로 설명하고 있다.

Anthropic:

Claude 2 interview -
OpenAI:

Better language models

현재의 주요 LLM은 Transformer 아키텍처를 기반으로 하고 있다.

Transformer는 Attention (어텐션) 메커니즘을 통해 문맥 내 단어들 사이의 관계를 다루는 구조를 가지고 있으며, 현재 LLM의 기초가 되고 있다.

그 위에서 대량의 자연어와 코드를 학습함으로써:

• 대화
• 설계 논의
• 프로그래밍
• 문서화

등의 패턴도 내부 표현으로서 획득하고 있다.

이러한 LLM의 발전 경위를 알고 나면, LLM이 출력하는 것이 「문맥으로서 자연스러운 출력」 쪽으로 기울기 쉬운 경향을 보이는 것은 자연스러운 현상으로 받아들이는 것이 좋아 보인다.

OpenAI는 hallucination (환각, 그럴듯한 오출력)에 대한 설명 중에서:

they may guess rather than say 'I don't know'

(「모르겠다」고 답하는 대신 추측해 버리는 경우가 있다)

라고 설명하고 있다.

coding agent는 grounding을 중시하고 있다

grounding (그라운딩)이란, 본 기사에서는 리포지토리, 실행 환경, 테스트 결과와 같은 실제 정보원을 근거로 추론하는 것을 가리킨다.

Anthropic / OpenAI 양측 모두, coding agent (코딩 에이전트)에 있어서:

• 코드 탐색
• 도구 실행
• 테스트 실행
• 실행 결과 확인

을 상당히 중시하고 있으며, LLM 단독의 추론뿐만 아니라 실제 코드베이스나 실행 결과에 접지(grounding)하는 방향으로 나아가고 있다.

Anthropic의 Claude Code docs에서도:

• code exploration (코드 탐색)
• root cause analysis (원인 분석)
• testing (테스트 실행)

등의 workflow (워크플로)가 명시되어 있다.

OpenAI의 Codex docs에서도:

• code reading (코드 읽기)
• repo integration (리포지토리 연동)
• verification (검증)

이 상당히 전면에 내세워져 있다.

Anthropic / OpenAI 양측 모두, 코드나 실행 결과를 실제로 확인하면서 추론을 진행하는 것을 중시하고 있음을 알 수 있다.

이는 실제 정보원에 대한 grounding을 중시하고 있다고 말할 수 있을 것이다.

이 섹션을 정리하면, Claude Code / Codex 모두 LLM이 범용성을 얻기까지의 진화 과정은 공통적이라는 것을 알 수 있다.

적어도 이번에 관측한 차이점은, LLM 자체의 기본적인 발전 과정만으로는 설명하기 어려워 보인다.

Claude Code와 Codex의 설계 사상 차이

Claude Code는 형성된 작업 가설과의 정합성을 유지하려는 경향이 강하다

Anthropic은 Claude Code를:

agentic coding system

(자율적으로 태스크를 진행하는 코딩 시스템)

으로 설명하며:

• 코드베이스 읽기
• 여러 파일에 걸친 변경
• 테스트 실행 및 커밋

과 같은 일련의 작업을 자율적으로 진행하는 것을 중시하고 있다.

또한, Claude Code의 베스트 프랙티스(Best Practice)에서는:

Explore first, then plan, then code

(먼저 탐색하고, 그다음 계획하고, 그 후에 구현한다)

즉, 먼저 탐색을 수행하고, 그 후에 계획을 세우며, 구현으로 나아가는 워크플로우가 권장되고 있다.

입력 컨텍스트 (Input Context)를 바탕으로 조사하여 작성한 계획 (plan)이 후속 추론에 강력한 영향을 미칠 가능성이 있다.

내가 실제로 관측한 범위 내에서도 그러한 경향을 관찰할 수 있었다.

기존 애플리케이션의 사양을 조사할 때, 기억하고 있는 정보를 그대로 계획에 반영했으나 실제 코드와 괴리가 있었을 때의 동작에서 관찰한 사례이다.

기존 사양인 xxx에 대해 상세 내용을 파악하고 싶다.
yyy 파일에 로직이 있고,
아마 이런 느낌이었을 것이다.

라는 상태에서 계획을 작성해 나가면,

• yyy 파일이 존재할 것
• 알고 싶은 로직이 포함되어 있을 것
• 주변 파일도 탐색할 것

을 명시한 계획이 작성되었다.

계획을 리뷰했을 때도 위화감이 없었기에 그대로 조사를 진행하도록 했다.

조사 결과는 언뜻 보기에는 기대한 대로의 결과처럼 보였지만, 직관적으로 논리가 맞지 않는 설명이 되어 있는 듯한 위화감을 느꼈다.

이 zzz에 대해,
어떤 코드를 보고 확정했는지 알려달라

라는 지적을 하자, Claude Code는 다음과 같이 충격적인 응답을 돌려주었다.

코드를 읽지 않았습니다.
코드로부터 파악하겠습니다.

코드상으로는 실제와 달랐습니다.
정확하게는 이렇습니다.

이것이 서두에서 언급한 Opus 4.7 경험이 나쁜 인상으로 남은 사례이다.

엔지니어에게 있어서는, 코드 확인을 동반하지 않은 채 그럴듯한 설명이 생성되어 버린 사례이다.

공식 정보와 실제 경험을 통해 느낀 점을 정리하자면, 나에게 Claude Code는 조사 태스크에 대해 입력 컨텍스트로부터 형성한 작업 가설 (plan)을 중심으로 추론을 진행하며, 그 가설과의 정합성을 유지하려는 경향이 있는 에이전트 (agent)로 보였다.

Codex는 코드나 실행 결과와의 정합성을 유지하려는 경향이 강하다

반면, OpenAI는 Codex를 다음과 같이 설명한다.

read, edit, and run code

(코드를 읽는다 → 편집한다 → 실행한다)

코딩 에이전트 (coding agent)로서 말이다.

또한 OpenAI는 다음 사항들도 상당히 전면에 내세우고 있다.

• repo integration (리포지토리 연동)
• code reading (코드 읽기)
• test/review loop (테스트와 검증을 반복하는 루프)

또한, Codex의 베스트 프랙티스 (best practice)에서는 프롬프트에 다음과 같은 요소를 포함할 것을 권장하며, 테스트와 리뷰 워크플로우를 강조하고 있다.

goal, context, constraints, and completion criteria

(목표 · 문맥 · 제약 조건 · 완료 조건)

태스크의 완료 조건의 명확성을 중시하며, 사전 지식 그 자체보다는 목표 (goal)나 완료 조건 (completion criteria)에 의해 태스크를 정의하는 방향성이 보인다.

내가 실제로 관측한 범위 내에서도 그러한 경향을 관찰할 수 있었다.

기존 사양인 xxx에 대해 상세 내용을 파악하고 싶다.
yyy 파일에 로직이 있고,
아마 이런 느낌이었을 것이다.

라는 요청을 하자, Codex는 다음과 같은 응답을 보냈다.

조사한 결과 사용자께서 알고 계신 것과 다른 부분이 있음을 확인했습니다.
두 가지 사항을 확인해 주십시오.

조사 결과에는 구체적인 코드를 제시한 후, 이를 통해 어떻게 읽어낼 수 있는지에 대한 정보가 첨부되어 있었다.

공식 정보와 실제 경험을 통해 느낀 점을 정리하자면, 나에게 Codex는 조사 태스크에 대해 입력 컨텍스트를 조사 대상이나 완료 조건의 정의에 활용하면서도, 실제 코드나 실행 결과를 우선하여 추론을 업데이트하는 경향이 있는 에이전트 (agent)로 보였다.

이 섹션을 요약하면, Claude Code는 형성된 작업 가설 (plan)과의 정합성을 유지하려는 경향이 있고, Codex는 코드나 실행 결과와의 정합성을 유지하려는 경향이 있는 것으로 보였다.

그 결과, 사용자가 부정확한 전제를 제공했을 경우에도 Claude Code는 그 전제의 영향을 받은 채 추론을 진행하기 쉬운 반면, Codex는 코드나 실행 결과를 근거로 전제를 재검토하기 쉬운 것으로 보였다.

현재의 활용 구분

지금까지 소개한 내용은 어디까지나 공식 정보를 바탕으로 한 나의 개인적인 가설과 실제 경험에서 얻은 고찰이다.

하지만 실제로 양쪽을 모두 사용해 나가면서, 양자 사이에는 무시할 수 없는 경향의 차이가 있다고 느끼게 되었고, 현재는 명확하게 역할을 나누어 이용하고 있다.

현재 나의 기본 방침은 다음과 같다.

조사・기술 검토・PR 작성 → Claude Code
구현・리팩터링(Refactoring)・코드 수정 → Codex

구현은 Codex に 맡긴다

구현 작업에 대해서는 현재 거의 Codex에 맡기고 있다.

앞 절에서 언급했듯이, 나의 관찰에 따르면 Codex는 코드나 실행 결과와의 정합성(Consistency)을 유지하려는 경향이 강하다.

실제 이용 시에도,

사용자의 인식
↓
코드 확인
...

이라는 흐름이 되는 경우가 많으며, 기존 코드베이스(Codebase)를 이해하면서 수정을 진행하는 태스크와 궁합이 좋다고 느끼고 있다.

따라서 기존 코드의 이해나 수정, 리팩터링(Refactoring)과 같은 작업에서는 현재 Codex를 제1선택지로 삼고 있다.

PR 본문은 Claude Code に 맡긴다

반면, PR(Pull Request) 본문 작성은 Claude Code에 맡기고 있다.

이는 변경 의도를 설명하는 능력에 관한 이야기가 아니다.

나의 관찰에 따르면, 양쪽 모두 변경 의도에 대해 사용자로부터 충분한 정보가 주어지지 않으면 잘못된 추측을 할 가능성이 있다.

차이를 느끼는 부분은 변경 내용을 정리하거나 요약하는 방식이다.

예를 들어 동일한 차이점(Diff)으로부터 PR 본문을 생성했을 때, Codex는 변경 내용을 망라하여 나열하는 경향이 있다.

- FooRepository를 추가
- UserUseCase를 수정
- APIClient의 책임을 변경
...

정보로서는 정확하지만, 인간이 변경의 전체상을 파악하기에는 다소 부하가 높다.

반면 Claude Code는 여러 변경 사항을 묶어서 정리하며,

인증 처리의 책임을 정리하기 위해,
관련된 Repository와 UseCase의 의존 관계를 재검토했다.

와 같이, 인간이 이해하기 쉬운 입도(Granularity)로 압축하여 설명하는 경우가 많다.

그렇기 때문에 현재는 구현을 Codex에 맡기고, 완성된 차이점을 Claude에게 읽혀서 PR 본문을 생성하는 운용 방식으로 정착되었다.

기술 조사에서는 양쪽 모두를 사용한다

또한, 기술 조사나 설계 검토에 대해서는 Claude Code와 Codex를 조합하여 이용하는 경우가 많다.

새로운 라이브러리나 아키텍처(Architecture), 개발 프랙티스(Practice)를 검토할 때는 먼저 Claude Code를 이용한다.

실제로는,

• OSS의 구현 조사
• 프레임워크(Framework)의 베스트 프랙티스(Best Practice) 조사
• 설계 패턴(Design Pattern) 비교
• 타사 사례 수집

과 같은 용도로 이용하는 경우가 많다.

따라서,

세상에는 어떤 해결 방법이 있는지
어떤 프랙티스가 존재하는지

를 파악하는 단계에서는 Claude Code를 이용하는 경우가 많다.

하지만 그 결과를 그대로 채택하는 경우는 드물다.

실제로 중요해지는 것은,

그 프랙티스를 우리 제품에 적용할 수 있는가
기존 코드와의 정합성을 맞출 수 있는가
도입 비용이나 영향 범위는 어느 정도인가

라는 검증이다.

여기서는 Codex를 이용하는 경우가 많다.

실제 코드베이스를 바탕으로 하면서,

이 설계를 도입하면 어디에 영향을 주는가
기존 구현과의 차이점은 무엇인가
도입 시 문제가 될 만한 곳은 어디인가

를 구체적으로 검토하는 용도와 궁합이 좋다고 느끼고 있다.

그 결과, 기술 조사에 대해서는,

정보 수집・일반론 정리 → Claude Code
기존 코드베이스로의 적용 검토 → Codex

라는 흐름으로 진행하는 경우가 많다.

나에게 Claude Code는 선택지를 넓히기 위한 도구이며, Codex는 그 선택지를 실제 코드베이스에 적용 가능한지 검증하기 위한 도구가 되고 있다.

구분 사용의 기준

현재 나의 구분 사용을 한마디로 표현하면,

코드를 변경하고 싶다면 Codex
정보를 정리하고 싶다면 Claude

이다.

물론 양쪽 모두 고성능의 코딩 에이전트(Coding Agent)이며, 많은 태스크는 어느 쪽으로든 실행할 수 있다.

하지만 실제 개발 현장에서는,

• 코드와의 정합성을 중시하고 싶은가
• 문맥이나 정보 정리를 중시하고 싶은가

에 따라 요구되는 동작이 달라진다.

지금까지 소개한 구분 사용을 되돌아보면, 내 안에서는 점차 역할 분담이 명확해졌다.

Claude Code는 인간이 안고 있는 모호한 과제를 정리하고 선택지를 넓히는 역할을 담당하고 있다.

반면 Codex는 그 선택지를 실제 코드베이스에 적용하고 검증하며 구현하는 역할을 담당하고 있다.

그렇기 때문에 현재의 나는,

Claude Code
= 문제 공간의 탐색
Codex
...

로 파악하고 있다.

Anthropic은 Claude Code에서

Explore first, then plan, then code

(먼저 탐색하고, 그다음 계획하고, 그 후에 구현한다)

라는 워크플로우(Workflow)를 권장하고 있다.

반면 OpenAI는 Codex를

read, edit, and run code

(코드를 읽고 → 편집하고 → 실행하는)

코딩 에이전트 (coding agent)로 설명하고 있다.

나는 양자를 경쟁 제품이 아니라, 서로 다른 특성을 가진 개발 파트너로서 구분하여 사용하고 있다.

마치며

2026/6 현재, Claude Code / Codex 모두 풍부하게 사용할 수 있는 환경에서의 구분 사용 메모이다.

현시점에서는,

• 정보 수집 및 정리는 Claude Code
• 구현 및 검증은 Codex

라는 형태로 정착되어 있다.

다만, 이러한 구분 사용이 앞으로도 계속된다는 보장은 없다.

최근의 동향으로서 모델의 진화는 매우 빠르며, 이번에 관측한 특성 차이 그 자체가 몇 달 후에는 작아져 있을 가능성도 충분히 있다.

또한, 토큰 (token)에 드는 비용은 증가하는 추세이며, 이대로 여러 개의 코딩 에이전트 (coding agent)를 계속 병용하는 비용은 머지않아 무시할 수 없게 될 것이다.

그때 다시 한번 최적의 선택을 할 수 있도록 하기 위해서라도,

• Claude Code는 어떤 상황에서 가치를 발휘했는가
• Codex는 어떤 상황에서 가치를 발휘했는가
• 왜 현재의 구분 사용으로 정착되었는가

를 기록으로 남겨두고 싶었다.

장래에 비용 최적화를 고려할 때도, 각각의 특성을 이해해 둠으로써 더 나은 선택지를 고를 수 있게 될 것이다.

Discussion