OpenClaw 개발 핵심은 Codex
OpenClaw를 둘러싼 대중적 인상에는 흥미로운 반전이 있다.
많은 사람에게 이 프로젝트는 Claude Code와 함께 기억된다.
실제로 Peter Steinberger가 2025년 중반과 하반기에 보여준 작업 방식은 AI 코딩 에이전트로 이렇게까지 만들 수 있다는 감각을 널리 퍼뜨리는 데 큰 역할을 했다.
하지만 공개 발언을 시간순으로 따라가 보면, 후반부의 실제 실행 축은 점점 Codex 쪽으로 기울어 갔다.
Claude Code가 전환의 계기를 만들었고 OpenClaw는 그 존재감을 키우는 데 기여했지만, 프로젝트가 커지고 작업 시간이 길어질수록 Peter Steinberger의 실제 작업 방식은 Codex와 더 잘 맞았다.
이 글은 바로 그 지점을 정리하려는 글이다.
Peter Steinberger는 누구인가
Peter Steinberger는 개발 도구와 제품을 오래 만들어온 개발자이자 창업가다.
문서 처리 소프트웨어 회사 PSPDFKit의 공동창업자로 널리 알려졌고, 이후에도 여러 개발 도구와 자동화 프로젝트를 직접 만들어 공개해 왔다.
또한 OpenClaw를 만든 인물로, 2026년 2월 14일에는 OpenAI에 합류한다고 직접 밝혔다.
이 글에서 그의 발언이 주목할 만한 이유는 단순히 유명 개발자여서가 아니다.
직접 에이전트 코딩 도구를 강하게 밀어붙여 써본 사용자이면서, 그 과정과 선호 변화를 공개 글로 비교적 자세히 남긴 인물이기 때문이다.
사실 관계 정리
- 사실: Peter Steinberger는 2025년 8월 25일
My Current AI Dev Workflow에서Claude Code를 자신의main driver라고 적었다. - 사실: 같은 시기 그는
Ghostty + Claude Code중심 워크플로우, plan mode, 파일 기반 계획, 보조 리뷰 절차를 적극적으로 사용한다고 설명했다. - 사실: 해당 글의 현재 공개 주소는 제목 그대로의 경로가 아니라
optimal-ai-development-workflow경로를 사용한다. - 사실: 2025년 10월 14일
Just Talk To It - the no-bs Way of Agentic Engineering에서는 에이전트와 대화하며 계획을 세우고 실행시키는 방식을 더 강하게 밀기 시작했다. - 사실: 2025년 12월 28일
Shipping at Inference-Speed에서는GPT 5와Codex가 자신의 작업 방식을 크게 바꿨다고 적었고, 긴 리팩터링과 큰 작업을Codex에 오래 맡기는 패턴을 상세히 설명했다. - 사실: 같은 글에서 그는
Codex가 더 많은 코드를 먼저 읽고, 큰 작업이나 리팩터링에서 더 잘 맞았으며, 한 세션에서Claude보다 훨씬 더 많은 일을 처리한다고 평가했다. - 사실: 같은 글에서 그는
Opus와Claude Code계열 도구를 더 빠르고 성급한 편으로 묘사하면서, 작은 수정에는 강점이 있지만 큰 기능이나 리팩터링에서는 전체 맥락을 덜 읽는 경우가 있다고 적었다. - 추정: 즉
Claude Code를 안 써서가 아니라, 공개 발언 기준으로는Claude Code 중심에서Codex 중심으로 선호가 이동한 것으로 보는 편이 자연스럽다. - 의견: 이 사례의 핵심은 특정 모델의 절대 우열보다
프로젝트 단계가 바뀌면서 어떤 에이전트 성격이 더 잘 맞았는가에 있다.
OpenClaw 가 Claude Code 를 띄우게 된 이유
이 질문이 자주 나오는 이유 자체는 이해할 만하다.
OpenClaw와 Peter Steinberger의 작업 방식은 많은 개발자에게 Claude Code 류 도구의 가능성을 체감하게 만든 사례였기 때문이다.
2025년 여름과 초가을에 공개된 글과 데모, 워크플로우 공유는 AI 코딩 에이전트가 단순 자동완성 단계를 넘어설 수 있다는 인상을 강하게 남겼다.
특히 이 시기에는 Claude Code가 실제 개발자들 사이에서 인지도를 빠르게 넓히던 구간과도 겹친다.
Peter Steinberger 본인이 2025년 8월 25일 기준 Claude Code를 메인 도구로 적어두었기 때문에, OpenClaw를 만든 사람도 결국 Claude Code 쪽 아니었나라는 인상이 형성된 것은 자연스럽다.
즉 대중적 기억과 초기 인상만 보면 OpenClaw = Claude Code 서사의 대표 사례처럼 보일 여지가 충분했다.
이 지점은 과장이 아니라, 적어도 전환의 계기와 인지도 확대라는 측면에서는 꽤 타당한 해석이다.
후반 작업 대부분 Codex 중심으로 굳어진 이유
공개 발언을 더 뒤까지 보면 이야기가 달라진다.
2025년 12월 28일 글에서 Peter Steinberger는 이미 Codex를 긴 시간 돌려도 되는 실행형 도구로 다루고 있다.
단순한 선호 표현을 넘어, 몇 시간짜리 리팩터링, 여러 프로젝트 병행, 큰 맥락을 오래 유지하는 세션, 짧아진 프롬프트, 적은 재설명 같은 작업 습관 전체가 Codex 중심으로 재구성되어 있다.
여기서 중요한 포인트는 질문을 덜 하는 에이전트가 아니라 계획을 세운 뒤 오래 달릴 수 있는 에이전트를 원했다는 점이다.
프로젝트 초반 탐색 구간에서는 대화형 왕복이 큰 장점이 될 수 있다.
하지만 OpenClaw처럼 연결 범위가 넓고, 기능이 빠르게 늘고, 장시간 리팩터링과 병렬 작업이 많은 프로젝트에서는 중간중간 흐름을 끊지 않는 것이 더 중요해질 수 있다.
Peter Steinberger의 공개 글을 기준으로 보면, 후반 작업에서 중요했던 것은 대략 다음과 같았다.
- 많은 파일을 먼저 읽고 시작하는가
- 긴 세션에서 맥락을 유지하는가
- 큰 작업을 맡겼을 때 수정의 수정이 덜 필요한가
- 짧은 프롬프트와 적은 재설명으로도 움직이는가
- 동시에 여러 프로젝트를 굴려도 흐름이 덜 깨지는가
그 기준에서는 Codex가 더 잘 맞았다는 것이 그의 후반 평가에 가깝다.
따라서 왜 Claude Code가 아니라 Codex로 다 했나라는 질문은 완전히 틀린 질문이라기보다, 시간축을 압축해서 본 질문에 가깝다.
더 정확한 표현은 초기 전환과 인상 형성에는 Claude Code가 중요했지만, 후반의 실제 실행 작업 다수는 Codex 중심으로 이동했다에 가깝다.
Claude Code vs Codex
이 지점을 이분법으로 정리하면 오히려 실제 맥락이 흐려진다.
공개 발언 기준으로 보면 두 도구는 강점이 꽤 다르다.
Claude Code 강점
- 탐색적 문제를 대화로 풀어갈 때 상대적으로 잘 맞는다.
- 빠른 왕복과 작은 수정, 정리, 리팩터링에서 강점이 있다.
- 초기 시점에는 plan mode 같은 보조 흐름과 함께 사용하기 좋았다.
- 개발자가 계속 붙어서 방향을 조율하는 작업에는 장점이 있었다.
Claude Code 한계
- 큰 작업에서 전체 맥락을 충분히 읽지 못한 채 성급하게 움직인다는 불만이 후반 공개 발언에 나타난다.
- 장시간 실행 중 중간 확인이나 재설명 비용이 상대적으로 더 크게 느껴졌던 것으로 보인다.
- 프로젝트가 커질수록 보조 절차와 작업 의식이 늘어나는 점을 Peter Steinberger가 번거롭게 느낀 것으로 읽힌다.
Codex 강점
- 큰 작업 전 많은 코드를 읽고 시작하는 성향이 장점으로 평가됐다.
- 긴 세션에서 컨텍스트 유지가 좋고, 한 세션 생산성이 높다고 평가됐다.
- 큰 기능 추가와 장시간 리팩터링에서
수정의 수정비용이 덜 든다는 점이 강조됐다. - 프롬프트를 짧게 주고도 오래 실행시키기 쉬운 쪽으로 워크플로우가 단순화됐다.
Codex 한계
- 시작이 느리게 느껴질 수 있다.
- 개발자가 먼저 구조와 방향을 어느 정도 잡아놓았을 때 더 잘 맞는다.
- 팀 협업보다 개인 중심, 빠른 실험과 장시간 실행에 더 잘 들어맞는 면이 있다.
- 모든 상황에서 무조건 낫다기보다
계획 후 실행성격이 강한 프로젝트에서 장점이 두드러진다.
이 사례의 핵심은 모델 우열보다 작업 방식 궁합이다
이 사례를 단순히 Codex 승, Claude Code 패로 읽으면 중요한 것을 놓치게 된다.
Peter Steinberger의 글을 보면 그는 Claude 계열 모델 자체를 부정하지 않는다.
오히려 일반 목적 모델로서의 매력, 컴퓨터 자동화 쪽에서의 재미, 작은 수정과 정리 작업의 강점을 계속 인정한다.
달라진 것은 모델 선호보다 개발자 역할에 더 가깝다.
직접 한 줄씩 쓰는 사람보다, 구조를 정하고 작업을 쪼개고 오래 실행시키는 사람이 되는 쪽으로 이동한 것이다.
그 역할에서는 질문을 잘하는 조수보다 큰 문맥을 유지하며 오래 달리는 실행기의 가치가 커진다.
OpenClaw 후반 작업이 Codex 중심으로 굳어졌다는 인상은 바로 여기서 나온다.
프로젝트가 커질수록 핵심 병목이 코드를 대신 써줄 수 있는가보다 얼마나 덜 끊기고 오래 밀어붙일 수 있는가로 바뀌었기 때문이다.
어떻게 정리하는 편이 가장 정확할까
가장 무리 없는 정리는 이렇다.
- 사실: 2025년 8월 시점 공개 글에서는
Claude Code가 메인 드라이버였다. - 사실: 2025년 12월 시점 공개 글에서는
Codex가 후반 주력 실행 도구처럼 묘사된다. - 추정: 따라서
OpenClaw개발 흐름은 한 도구만 고집한 사례라기보다, 초기에는Claude Code의 전환 효과를 크게 누리고 후반에는Codex의 장시간 실행성을 더 높게 산 사례로 보는 편이 자연스럽다. - 의견: 이 사례는 AI 코딩 도구 비교이면서 동시에
개발자가 설계자이자 오케스트레이터로 이동하는 과정을 보여주는 상징적 사례다.
결론
OpenClaw는 분명 Claude Code의 가능성을 더 널리 보이게 한 사례이다.
하지만 개발 워크플로우 내 지속적 사용 측면에서 Codex 가 훨씬 유리한 지점이 있다.
Codex가 더 빠르고 효율적이며 가성비 측면에서 몇 배 이상 유리하다는 측면에서 이러한 의견을 강화한다.
즉, Codex 가 오래 읽고, 덜 끊기고, 긴 맥락을 유지하는 작업 방식과의 궁합에 있었다.
특히 GPT-5.4 는 장점을 강화하고 단점을 보완하였으며 실제로 올해 상당한 사용량 증가가 확인되었다는 이야기가 있다.
2025년 12월 28일 공개 글을 보면 Peter Steinberger는 이미 큰 작업, 긴 세션, 컨텍스트 유지, 짧은 프롬프트, 병렬 프로젝트 흐름에서 Codex 쪽에 더 큰 만족을 보이고 있다.
AI 별로 각 영역에서 유리한 도구는 다를 수 있으며 그 것은 자신이 겪어보며 선택해야 한다는 점을 말해준다.
일반 대중 Gemini 선호, 일반 개발자 커뮤니티 Claude 선호와 달리 실용적 가치는 다를 수 있다.