Claude Code × Codex 실전기 01. Claude Code 프로젝트에 Codex 넣기

이번 글의 핵심은 Claude Code만 쓰던 프로젝트에 Codex를 넣으며 운영 모델을 도구 독립적으로 다시 정리한 과정입니다.

필요했던 것은 더 좋은 프롬프트 몇 줄이 아니었습니다. Claude Code나 Codex 중 하나가 흔들려도, 프로젝트가 자기 역할과 검증 기준을 설명할 수 있는 구조였습니다.

시작은 단순했습니다.

npm i -g @openai/codex
codex

설치만 보면 별일이 아닙니다. 실제 변화는 설치 이후에 있었습니다.

ai-survival-log와 ai-survival-log-site의 역할을 분리하고, Claude Code와 Codex가 같은 계약을 읽도록 local surface를 나누는 작업으로 이어졌습니다.

최근 들어 Claude Code를 쓰는 감각이 전과 조금 달라졌기 때문입니다.

Claude-only 운영 모델은 정책 변화에 취약했습니다

2026년 3월부터 4월 초까지, Claude Code를 계속 쓰는 사람들 사이에서는 비슷한 얘기가 돌았습니다.

• 복잡한 작업에서 예전보다 답답해졌다는 얘기
• 토큰은 더 먹는데 결과물 밀도는 오히려 애매하다는 얘기
• 장시간 세션 효율이 전 같지 않다는 얘기

저도 비슷하게 느꼈습니다.

특히 체감이 컸던 건 캐시 정책 변화였습니다. 프롬프트 캐시 유지 시간이 사실상 5분 수준으로 짧아지면서, 조금만 텀이 생겨도 다시 로딩하는 느낌이 강해졌습니다. 긴 작업을 붙잡고 있을수록 이게 꽤 거슬렸습니다.

정리하면 이런 문제들이었습니다.

• 복잡한 코드 생성이나 수정 작업에서 성능이 눌리는 느낌
• 5분 캐시 정책으로 인한 장시간 세션 비효율
• 캐시 재생성 비용 증가
• 구독 쿼터 소진 가속
• 작업물 대비 토큰 소모량 증가

/effort low | medium | high로 thinking depth를 조절할 수 있게 된 것도 새로운 변화였습니다. 하지만 사용자 입장에서는 "좋아졌다"보다 "이제 사용자가 더 많이 조절해야 한다"는 감각으로 들어왔습니다.

심지어 effort 조정이 다른 세션의 캐시까지 건드리는 문제 이야기도 보이기 시작하니까, 이건 모델 하나의 품질보다 도구 운영 안정성 문제처럼 느껴졌습니다.

그래서 질문이 바뀌었습니다.

필요한 것은 더 좋은 프롬프트 몇 줄이 아니라, 특정 도구의 정책 변화에 덜 휘둘리는 프로젝트 구조가 아닐까?

핵심은 모델보다 하네스였습니다

오늘 정리한 AI Frontier EP86을 보면서 이 생각이 더 굳어졌습니다.

가장 인상적이었던 포인트는 이거였습니다.

Claude Code의 진짜 경쟁력은 모델보다 harness입니다.

이 말이 중요한 이유는, 원래 저는 Claude와 Codex를 모델 비교처럼 보고 있었기 때문입니다. 어느 쪽이 더 잘 쓰고, 더 잘 만들고, 더 잘 버티느냐.

그런데 실제로 중요한 건 그게 아니었습니다.

• 어떤 컨텍스트를 먼저 읽히는가
• 어떤 문서를 source of truth로 두는가
• 어떤 작업을 어떤 단위로 쪼개는가
• 어떤 검증 루프를 붙이는가
• 어떤 local surface 위에서 에이전트를 굴리는가

즉, 모델 자체보다 그 모델을 감싸는 운영 구조가 더 중요해지는 구간에 와 있다는 뜻입니다.

그리고 팟캐스트에서 나온 만화 비유가 이 차이를 굉장히 직관적으로 설명해줬습니다.

두 도구는 다른 조종석을 만들었습니다

팟캐스트에서는 사이버 포뮬러 비유가 나왔습니다.

아주 거칠게 옮기면 이런 느낌입니다.

• Claude Code는 아스라다
• Codex는 오가

이 비유가 좋았던 건, 단순히 "누가 더 셈?" 같은 얘기가 아니라 사람과 협업하는 방식이 다르다는 걸 정확히 짚어주기 때문입니다.

Claude Code는 아스라다 쪽에 가깝습니다.

• 질문을 더 많이 한다
• 선택지를 준다
• 사람의 애매함을 같이 정리해준다
• 사용자를 끌고 가기보다, 같이 맞춰간다

그러니까 Claude Code를 쓸 때는 "같이 운전하는 느낌"이 있습니다. 조금 더 편안하고, 사람 입장에서 덜 날카롭습니다. 잘 맞을 때는 굉장히 자연스럽습니다.

반대로 Codex는 오가 쪽에 가깝습니다.

• 덜 묻는다
• 더 직접적으로 밀어붙인다
• 스스로 처리하겠다는 감각이 강하다
• 사람의 중간 개입을 덜 전제로 둔다

그래서 Codex를 쓰면 좀 더 거칠고, 좀 더 직접적입니다. 대신 최고점만 보면 더 높게 튀는 느낌이 있습니다.

이 비유를 듣고 나니 그동안 느꼈던 차이가 더 또렷해졌습니다.

• Claude Code는 사람을 더 배려하는 조종석
• Codex는 사람보다 기계의 판단을 더 믿는 조종석

어느 쪽이 더 낫다고 단순하게 말하기는 어렵습니다. 편안함은 Claude Code 쪽에 있고, 최고점의 공격성은 Codex 쪽에 있습니다.

그리고 바로 그 차이 때문에, 둘 중 하나만 믿고 프로젝트를 설계하는 게 오히려 위험할 수도 있겠다고 느꼈습니다.

도구 교체보다 운영 모델 리팩터링이 먼저였습니다

처음엔 그냥 Codex를 실행해 보는 수준이었습니다.

npm i -g @openai/codex
codex

그런데 막상 들어가 보니, 해야 하는 일은 모델 비교가 아니라 구조 정리였습니다.

upstream과 downstream을 먼저 나눴습니다

제일 먼저 한 건 프로젝트 역할을 다시 정의하는 일이었습니다.

• ai-survival-log
  • 지식 축적
  • 위키 authoring
  • publish source of truth
• ai-survival-log-site
  • 발행 결과 소비
  • 렌더링
  • series navigation
  • presentation layer

이건 사실 머릿속엔 이미 있던 구분이었습니다. 문제는 그게 문서와 설정에 박혀 있지 않았다는 점입니다.

그래서 이번에 그걸 공식화했습니다.

.claude만 있던 프로젝트에 .codex를 추가했습니다

이게 상징적이었습니다.

원래는 Claude Code가 읽기 좋은 구조만 있었습니다. 이제는 Codex도 읽을 수 있는 local surface를 별도로 뒀습니다.

핵심은 크고 화려한 걸 추가하는 게 아니었습니다.

• .claude는 Claude용 local surface
• .codex는 Codex용 local surface
• 둘 다 같은 프로젝트 역할을 설명
• 둘 다 같은 운영 모델을 읽음
• 둘 다 같은 계약을 가리킴

즉, 입구는 나눴지만 철학은 통일했습니다.

ECC와 superpowers도 "기능"이 아니라 "원칙"만 가져왔습니다

이번에 더 분명히 느낀 건, 외부 harness를 그대로 들여오는 건 답이 아니라는 점이었습니다.

이 프로젝트에 진짜 필요했던 건 거대한 agent pack이 아니었습니다.

필요했던 건 몇 가지 운영 원칙이었습니다.

• plan before execute
• verification before completion
• systematic debugging
• selective adoption
• documentation consistency

결국 ECC나 superpowers에서 가져온 건 기능이 아니라 작업 습관이었습니다.

모델보다 프로젝트가 읽히는 구조가 중요했습니다

이번 실험을 하면서 제일 많이 든 생각은 이것이었습니다.

문제는 "Claude가 낫냐, Codex가 낫냐"가 아니었습니다. 문제는 내 프로젝트가 어떤 조종석에만 맞춰져 있느냐였습니다.

Claude Code만을 전제로 만든 프로젝트는, Claude Code가 흔들리면 같이 흔들립니다. 반대로 Codex만을 전제로 만들면, 또 다른 방식으로 구조가 거칠어집니다.

그래서 더 중요한 건 둘 중 하나를 고르는 일이 아니었습니다.

• 프로젝트 역할을 문서화하고
• source of truth를 명확히 두고
• upstream / downstream 경계를 정하고
• local surface를 분리하고
• 검증 루프를 남기는 것

즉, 도구가 프로젝트를 이해하게 만드는 게 아니라, 프로젝트가 스스로를 설명할 수 있게 만드는 것이 더 중요했습니다.

도구 추가는 구조 개선으로 이어졌습니다

이번 작업의 가장 큰 수확은 "Codex도 쓸 수 있게 됐다"는 사실 자체가 아니었습니다.

더 중요한 변화는 구조 쪽에 있었습니다.

Claude Code만으로도 돌아가던 프로젝트가, Claude와 Codex가 모두 읽을 수 있는 프로젝트로 바뀌었습니다.

그 과정에서 생긴 것들은 꽤 구체적입니다.

• upstream/downstream 역할 분리
• publishing contract 문서화
• content contract 문서화
• series 규칙 명문화
• Claude local surface 정리
• Codex local surface 추가
• 운영 시나리오와 하루 운영 루틴 정리
• 최종 consistency review 문서화

즉, LLM 하나를 더 붙였더니 프로젝트가 도구 의존성을 줄이는 방향으로 더 단단해졌습니다.

원래는 "다른 모델도 써보자"에서 시작했는데, 결국은 "모델이 바뀌어도 유지되는 운영 구조를 만들자"로 끝났습니다.

도구 독립성은 아직 진행 중입니다

물론 이걸로 LLM 독립을 달성했다고 말할 수는 없습니다.

여전히 저는 LLM을 쓰고 있고, 도구의 품질 차이는 실제 생산성에 영향을 줍니다.

하지만 바뀐 건 분명히 있습니다.

예전에는 이런 느낌이었습니다.

• Claude Code가 프로젝트를 이해한다

지금은 이쪽에 더 가깝습니다.

• 프로젝트가 자기 역할을 문서화하고 있고
• Claude도 읽을 수 있고
• Codex도 읽을 수 있고
• 다른 LLM이 와도 적응 가능한 구조가 되어 간다

저는 이 차이가 꽤 크다고 봅니다.

전자는 도구 중심이고, 후자는 프로젝트 중심입니다.

운영 구조가 도구 변화를 견디게 했습니다

npm i -g @openai/codex는 정말 별거 아니었습니다.

진짜 작업은 그 다음이었습니다.

Claude Code만 쓰던 프로젝트에 Codex를 넣는다는 건 새 LLM 하나를 더 쓰는 일이 아니라, 프로젝트 운영 모델을 다시 정의하는 일에 가까웠습니다.

최근 Claude Code에서 체감한 성능 저하, 5분 캐시 정책, 토큰 소모 증가 같은 문제는 그걸 더 분명하게 보여줬습니다. 특정 도구가 강력한 것과, 그 도구에 프로젝트 전체를 종속시키는 건 다른 문제입니다.

오늘 정리한 팟캐스트의 비유를 빌리면,

• Claude Code는 아스라다 같고
• Codex는 오가 같다

하나는 더 함께 운전하는 쪽이고, 다른 하나는 더 직접적으로 밀어붙이는 쪽입니다.

중요한 건 어느 쪽이 절대적으로 더 세냐가 아닙니다. 제 프로젝트가 어느 한 조종석이 흔들릴 때 같이 흔들리지 않도록, 스스로 구조를 설명할 수 있게 만드는 것입니다.