AI 코딩 에이전트를 실무에 들이려는 팀이 늘면서, 도구 선택은 더 이상 "어느 쪽이 더 똑똑한가"라는 단순한 질문이 아니게 됐다. 오히려 각 도구가 개발자의 지시를 어떻게 해석하고 어디에서 멈추는지, 그 성향의 차이가 일상 워크플로에 더 큰 영향을 준다. 한 개발자가 일주일 동안 평소 주력으로 쓰던 클로드(Claude) 대신 코덱스(Codex)를 더 많이 사용하며 남긴 열 가지 인상은, 바로 이 성향 차이를 구체적인 상황 속에서 보여준다.
그가 정리한 핵심 대비는 명료하다. 클로드는 요청받은 것 이상을 하려 하고 사용자가 무엇을 원할지 추측해 곧바로 실행에 옮기는 반면, 코덱스는 시킨 것을 하되 과하게 나아가지 않고 "이제 끝난 것 같다"는 첫 신호에서 멈춘다. 어느 쪽이 우월하다기보다, 개발자가 통제권을 얼마나 쥐고 싶은지에 따라 체감이 갈리는 지점이다.
성향이 코드와 협업 톤에 남기는 흔적
이 차이는 실제 결과물에서 드러난다. 필자는 코덱스가 만든 루비·루비온레일즈 코드에 주석이 더 적었고 그 점이 마음에 들었다고 적었다. 아키텍처 측면에서도 코덱스는 더 단순한 해법을 내놓는 경향이 있었다. 클로드는 추상화, 개념, Sorbet 시그니처, 타입 별칭 같은 것을 많이 만들어내는 반면 코덱스는 더 절제된 결과를 냈다. 다만 같은 요구사항을 같은 문서로 양쪽에 구현시켰을 때, 클로드의 코드가 조금 더 복잡했지만 예외 상황을 더 잘 처리했다는 관찰도 함께 남겼다. 단순함과 방어적 처리는 맞바꿈 관계라는 뜻이다.
협업 톤의 차이도 흥미롭다. 클로드의 에이전트 출력은 마치 화면 공유 세션에서 옆자리 동료가 말을 건네는 느낌인 반면, 코덱스는 훨씬 기술적이어서 스타트렉의 안드로이드 캐릭터 데이터(Data)를 떠올리게 한다고 표현했다. 감정적 친근함이 없다는 것이 단점만은 아니어서, 필자는 코덱스를 쓰면서 하나의 큰 세션을 오래 끌기보다 목적이 뚜렷한 여러 세션을 병렬로 여는 방식을 선호하게 됐다고 말한다.
속도의 착시와 도구 연동의 마찰
속도에 관해서는 판단을 유보할 만한 대목이 있다. 코덱스가 핵심 변경 자체는 더 빠르게 만드는 것처럼 느껴졌지만, 그 뒤 풀 리퀘스트를 마무리하는 데 시간이 오래 걸렸다. 테스트를 여러 번 다시 돌리고 리뷰를 반복하는 등 꼼꼼함은 좋았으나, 결국 전체 소요 시간에서 이득은 없었다는 것이다. 초기 체감 속도가 곧 생산성 향상은 아니라는 현실적인 교훈이다.
실수도 있었다. 코덱스는 브랜치 A가 브랜치 B를, B가 다시 메인을 타깃으로 삼는 구조에서 리베이스를 요청받자 메인을 기준으로 리베이스해 4천 줄 이상이 추가된 풀 리퀘스트를 만들어버렸다. 필자는 "타깃 브랜치와만 리베이스하라"고 명시적으로 지시해야 했다. 반면 클로드는 다른 작업에서 갈라져 나와 동기화를 유지하려는 의도를 스스로 이해했다. 지시를 곧이곧대로 따르는 성향이 여기서는 위험으로 작동한 셈이다.
외부 도구 연동에서는 평가가 엇갈린다. MCP가 아닌 CLI로 지라·아틀라시안을 다루는 환경에서 코덱스는 지라 로그인 창을 열었다가 CLI로 넘어가고 다시 브라우저로 돌아오는 번거로운 흐름을 보였고, 이 경우 클로드가 이전 세션 맥락을 살려 원하는 방식대로 처리하려는 의지가 더 강했다. 반대로 MCP 인증에서는 코덱스 CLI 방식이 더 낫다고 봤다. 코덱스는 매번 적절한 인증·인가 절차를 열도록 안내하는 반면, 클로드는 한 턴 안에서 자동으로 실행하려다 멈춰버리는 경우가 있었기 때문이다.
실무에서 무엇을 읽어야 하나
이 사용기는 벤치마크가 아니라 한 사람의 일주일치 인상이라는 점을 감안해야 한다. 그럼에도 실무자에게 남기는 시사점은 분명하다. 급하게 디버깅해야 할 때 필자가 여전히 익숙한 클로드를 열었다는 고백처럼, 위기 상황에서는 성능 지표보다 손에 익은 도구가 중요하다. 또한 스킬·플러그인 자산이 한쪽에 몰려 있으면 그 자체가 이동을 막는 관성이 되므로, 필자는 코덱스에 클로드 스킬 폴더를 가리켜 변환을 맡기는 식으로 자산을 옮겼다. 결국 두 도구의 선택은 우열이 아니라, 알아서 앞서 나가는 파트너를 원하는지 시킨 만큼만 하는 조수를 원하는지에 대한 취향과 통제 욕구의 문제에 가깝다.