속도가 만든 함정
14년 경력의 시니어 엔지니어가 8만 줄 규모의 Python/TypeScript 프로젝트에서 Claude Code(Opus 4.6)와 Codex(GPT-5.4)를 각각 100시간, 20시간 실전 투입한 비교 실험을 GeekNews에 공유했다. 결론부터 말하면, 두 도구 모두 '소프트웨어 엔지니어링 역량이 없으면 좋은 결과를 내기 어렵다'는 점에서 일치한다. 그런데 이 문장의 무게를 제대로 느끼고 있는 개발자가 얼마나 될까.
Claude Code vs Codex: 빠름과 신중함의 트레이드오프
Claude Code는 인터랙티브하고 빠르다. 그런데 그 빠름의 이면에는 끊임없는 감시(babysitting)가 필요하다. 지시를 무시하고, 기존 파일에 함수를 무분별하게 추가하며, 작업을 반쯤 완료한 채 멈추는 경우도 빈번하다. 마감에 쫓기는 주니어 개발자처럼 핵심 아키텍처를 재검토하기보다 핵, 패치, 헬퍼 함수로 기능 구현에만 집중하는 경향이 있다. CLAUDE.md를 노골적으로 무시하는 세션이 반복되고, 테스트가 깨지면 묻지도 않고 자의적으로 수정하려 한다.
Codex는 3~4배 느리다. 하지만 그 느림이 오히려 장점이 된다. 별도 지시 없이도 스스로 멈추고 코드를 더 깔끔하게 리워크하며, AGENTS.md를 한 번도 무시하지 않는다. 5~6년차 주니어 시니어 엔지니어 같은 느낌이다—신중하고 의도적으로 작업하며, 충분한 역량이 입증된 뒤에는 작업을 실행시켜 놓고 완료 후 리뷰하는 방식으로 전환도 가능하다. 커뮤니케이션 스타일이 다소 로봇 같다는 불만이 있지만, 엔터프라이즈급 소프트웨어 구축에는 Codex가 더 적합하다는 평가가 나온다.
실무 커뮤니티에서 가장 많이 언급된 패턴은 두 도구의 병행 사용이다. Claude로 초안과 빠른 작업을 처리한 뒤 Codex로 코드 리뷰를 돌리는 교차 검증 워크플로우가 인기를 얻고 있다. 두 모델이 동일한 방식으로 환각(hallucination)하는 경우는 극히 드물기 때문에, 서로 다른 관점의 리뷰는 실질적인 품질 향상으로 이어진다.
더 깊은 역설: 빠르게 만들수록 느리게 생각하게 된다
ReThynk AI 창업자가 dev.to에 공유한 에세이는 이 도구 비교에 불편한 맥락을 더한다. AI 덕분에 더 빠르게 만들었지만, 정신적으로는 더 느려졌다는 고백이다. AI가 코딩의 인지적 마찰을 제거하면서 생긴 부작용이다. 디버깅하고, 리서치하고, 반복하는 과정에서 발생하던 '고통스러운 씨름'이 사실은 통찰의 촉매였다. AI가 이 마찰을 없애버리자, 분석 능력을 단련시키던 인지적 저항도 함께 사라졌다.
구체적인 변화는 미묘하지만 축적된다. 복잡한 문제 해결에 대한 인내심 감소, '충분히 괜찮은' 첫 번째 솔루션을 수용하는 경향, 독자적인 멘탈 모델을 형성하는 시간 감소, 아이디어 발상과 구조화에서의 AI 의존도 심화. 생산성 지표는 올라가지만 '생각하는 근육'은 조용히 약해진다. 창작자(creator)에서 큐레이터(curator)로의 전환이 효율적이지만, 깊은 주인의식과 몰입감을 희석시킬 수 있다.
이 역설의 해법은 AI를 덜 쓰는 것이 아니라, 다르게 쓰는 것이다. 답을 얻기 위한 지름길이 아니라 사고의 파트너로 활용하는 것. 프롬프트를 입력하기 전 먼저 스스로 관점을 형성하고, 직접 해결책을 요청하는 대신 자신의 아이디어를 비판하거나 반론을 제시하도록 요청하는 방식이다. 시스템 설계와 아키텍처 결정처럼 AI가 대신할 수 있더라도 의도적으로 직접 깊이 파고드는 '전략적 마찰'을 남겨두는 것.
과잉 설계라는 또 다른 함정
2년간 프로덕션 AI 에이전트를 구축해온 개발자가 dev.to에서 지적한 세 번째 관점이 이 그림을 완성한다. 개발자들이 LLM 주변에 정교한 기계 장치를 쌓아올리는 경향—커스텀 오케스트레이션 레이어, 도구 라우팅 시스템, 프롬프트 체이닝—이 사실은 모델이 이미 해결하고 있는 문제를 다시 만드는 것일 수 있다.
커스텀 도구 선택 로직을 만드는 대신 도구 이름과 설명을 명확하게 설계하면 모델이 알아서 선택한다. 4~5단계 프롬프트 체인 대신 구조화된 단일 시스템 프롬프트가 대부분의 멀티스텝 추론을 처리한다. 복잡한 메모리 시스템 대신 잘 구조화된 컨텍스트 윈도우면 충분한 경우가 많다. 멀티 에이전트 아키텍처는 화이트보드에서 매력적으로 보이지만, 프로덕션에서는 디버깅 악몽이 된다. 단일 에이전트가 진짜로 감당 못 할 때만 분리하라는 조언이다.
과잉 설계가 발생하는 근본적인 이유도 인지적 패턴과 닮아 있다. 빠르게 복잡한 것을 만들어내는 능력이 생기면, 그 복잡성이 가치 있다는 착각이 따라온다. 도구가 빠를수록, 그 속도로 불필요한 레이어를 더 빠르게 쌓아올릴 수 있다.
시사점: 속도 이후의 질문
세 가지 관점을 종합하면 하나의 명제가 된다. AI 도구의 가치는 속도에 있지 않다. 속도는 그냥 주어진다. 진짜 가치는 그 속도를 어떤 판단력과 함께 쓰느냐에 달려 있다.
Claude Code가 빠르게 초안을 뽑더라도 아키텍처 판단은 개발자 몫이다. Codex가 신중하게 리팩토링하더라도 어떤 문제를 풀어야 하는지는 개발자 몫이다. LLM이 프롬프트 체인 없이도 추론하더라도 어떤 제약 조건을 걸어야 하는지는 개발자 몫이다. AI가 빠르게 처리하는 것들의 목록이 늘어날수록, '개발자 몫'의 밀도가 높아진다.
전망: 느린 사고가 새로운 경쟁력이 된다
AI 코딩 도구의 성능 격차는 앞으로 줄어든다. Claude와 Codex 사이의 품질 차이가 이미 문제에 따라 50:50으로 엇갈린다는 실험 결과가 이를 암시한다. 도구 자체의 차별성이 수렴할수록, 그 도구를 어떻게 구조화하고 언제 개입하며 무엇을 검증하는가가 차별점이 된다.
빠른 AI 시대의 역설적인 경쟁력은 의도적으로 느리게 생각하는 능력에 있다. 시스템 설계를 AI에게 통째로 맡기지 않는 것, 과잉 설계를 경계하며 단순함을 선택하는 것, AI가 생성한 코드의 '왜'를 이해하는 것. 이것이 도구를 쓰는 개발자와 도구로 사고하는 개발자 사이의 간극을 만든다. 그리고 그 간극은 AI가 빨라질수록 더 빠르게 벌어진다.