Claude Code 프로젝트에 Codex를 함께 쓰는 운영 모델

며칠 동안 꽤 재밌는 실험을 했다.

Claude Code만 쓰던 프로젝트에 Codex를 넣어봤다.

시작은 단순했다.

npm i -g @openai/codex
codex

설치만 보면 별거 아니다. 그런데 진짜 흥미로웠던 건 설치가 아니라 그 다음부터였다.

나는 이 작업을 "다른 LLM도 한번 써보자" 정도로 시작한 건 아니었다. 조금 더 정확하게 말하면, Claude-only 운영 모델에서 한번 빠져나와 보고 싶었다.

최근 들어 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는 아스라다
• 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는 오가 같다

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

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

---