처음부터 거창한 갈아타기는 아니었습니다. 클로드를 꽤 오래 쓰면서 글쓰기, 코드 수정, 자동화 설계까지 많은 일을 맡겨 왔습니다. 그런데 어느 순간부터 제 작업은 단순 질문 답변보다 “로컬 파일을 읽고, 스크립트를 돌리고, 실패 로그를 보고, 다시 고치는 일”이 많아졌습니다. 그때부터는 말 잘하는 모델보다 작업 현장에 오래 붙어 있는 에이전트가 더 중요해졌습니다.
제가 체감한 출발점은 아주 단순했습니다. 클로드에서는 설명을 듣고 제가 다시 터미널로 옮기는 일이 자주 생겼습니다. 코덱스에서는 같은 요청을 하면 먼저 저장소를 훑고, 관련 파일을 읽고, 명령을 실행한 뒤 결과를 기준으로 다음 행동을 정했습니다. OpenAI 문서에서도 Codex를 코딩 에이전트와 장기 작업 흐름 쪽으로 설명하고, Anthropic 문서에서도 Claude Code를 터미널 안에서 쓰는 에이전트형 코딩 도구로 설명합니다. 둘 다 강한 도구지만, 제가 한 달 동안 더 많이 부딪힌 차이는 “말의 완성도”보다 “작업을 끝까지 물고 가는 방식”이었습니다. ※ 근거: OpenAI Developers Codex 문서, Anthropic Claude Code overview
실제로 블로그 자동화 파이프라인을 고칠 때 차이가 크게 났습니다. 예전에는 “이 스크립트가 왜 깨졌지?”라고 물으면 설명은 좋았지만, 제가 직접 로그를 찾고 다시 실행해야 했습니다. 코덱스로 넘어온 뒤에는 실패한 스테이지를 찾고, 관련 파일을 열고, exit code를 확인한 뒤, 어느 지점에서 막혔는지 작업 흐름 안에서 바로 좁혀 갔습니다. 제 입장에서는 상담 상대가 바뀐 게 아니라 옆자리 작업자가 바뀐 느낌에 가까웠습니다.
클로드의 장점은 여전히 대화의 결이 좋다는 점입니다. 긴 생각을 풀어낼 때, 글의 방향을 잡을 때, 사람에게 설명하듯 문장을 다듬을 때는 클로드가 편했습니다. 특히 블로그 초안이나 강의 구조를 만들 때는 제 말을 넓게 받아서 자연스럽게 정리하는 맛이 있었습니다. 그래서 “아이디어를 풀어놓는 자리”에서는 지금도 클로드식 응답이 그립습니다.
그런데 코덱스는 대화보다 작업 밀도가 높았습니다. 예를 들어 제가 “이거 한번 봐봐”라고 하면, 단순히 의견을 말하는 데서 멈추지 않고 현재 디렉토리, 테스트 명령, 관련 문서, 최근 변경 파일을 차례로 확인했습니다. 말은 조금 건조해도 실제로 손에 잡히는 결과가 더 빨리 나왔습니다. 한 달 동안 가장 크게 느낀 장점은 여기에 있었습니다. 코덱스는 제가 다시 지시하지 않아도 “읽기 → 수정 → 실행 → 검증”의 고리를 자연스럽게 이어 갔습니다.
제 블로그 파이프라인에서도 이 차이가 반복됐습니다. 이미지가 안 들어간 글, CSS가 빠진 HTML, 해시태그가 제목처럼 깨진 문제를 만났을 때 코덱스는 파일 크기, 변환 스크립트, 발행 URL 확인까지 작업 단위로 쪼개서 봤습니다. 클로드가 전체 그림을 잘 설명했다면, 코덱스는 “지금 깨진 줄”을 더 집요하게 찾았습니다. 그래서 운영 자동화처럼 실패 지점이 명확한 일에는 코덱스 쪽이 훨씬 잘 맞았습니다.
코덱스를 쓰며 가장 편했던 부분은 로컬 작업의 기본기가 좋다는 점입니다. 파일을 읽고, 검색하고, 패치를 만들고, 테스트를 돌리는 과정이 자연스럽습니다. 개발자에게는 당연해 보이지만, 실제 자동화 작업에서는 이 당연함이 큰 차이를 만듭니다. 좋은 답변을 받았는데 파일은 그대로라면 결국 제 일이 남습니다. 코덱스는 그 남은 일을 줄이는 쪽에 강했습니다.
저는 지난 한 달 동안 블로그, 영상, 러닝 데이터, 옵시디언 저장 규칙처럼 작은 자동화를 계속 만졌습니다. 여기서 코덱스가 좋았던 지점은 “성공 기준”을 먼저 잡으려 한다는 점이었습니다. 예를 들어 스크립트를 고치면 실제 실행으로 확인하고, HTML을 만들면 파일 크기와 브라우저 렌더링을 확인하고, 이미지가 들어갔는지 마크다운 안의 상대경로까지 봤습니다. 말로는 사소하지만, 이런 확인이 빠지면 운영 자동화는 며칠 뒤 같은 자리에서 또 깨집니다.
특히 제 환경처럼 개인 규칙이 많은 작업장에서는 이 장점이 더 크게 보였습니다. 새 자동화를 만들기 전에는 기존 SPoE가 있는지 찾고, 옵시디언 노트는 정해진 frontmatter를 지키고, 블로그 이미지는 Desktop 폴더에 두는 식의 규칙이 많습니다. 코덱스는 이런 규칙을 읽고 실제 명령으로 확인하는 데 강했습니다. “좋은 아이디어”보다 “다음에도 같은 방식으로 돌아가는 결과물”이 중요할 때, 코덱스의 성향이 제 작업 방식과 잘 맞았습니다.
코덱스가 모든 면에서 더 좋았다는 뜻은 아닙니다. 단점도 분명했습니다. 첫째, 문장에 따뜻한 여백이 부족할 때가 있습니다. 작업 보고나 코드 설명은 깔끔하지만, 블로그 글처럼 독자의 감정선을 타야 하는 글에서는 제가 직접 숨을 넣어줘야 했습니다. 클로드는 같은 내용을 말해도 조금 더 사람의 대화처럼 풀어내는 편이었습니다.
둘째, 코덱스는 목표를 너무 작업 단위로 쪼개다 보니 가끔 글의 큰 흐름을 놓칠 때가 있습니다. 예를 들어 “코덱스 장단점 글을 써줘”라고 했을 때 독자가 왜 이 글을 읽는지, 어떤 감정으로 들어왔다가 나가야 하는지까지 부드럽게 설계하는 힘은 클로드가 더 자연스럽습니다. 코덱스는 정확한 파일과 검증에는 강하지만, 글맛은 따로 코칭해야 할 때가 있습니다.
저도 실제로 초안을 만들 때는 이런 보완을 계속 했습니다. “형님이 겪은 장면을 넣어라”, “H2마다 개인 에피소드를 넣어라”, “단순 비교표로 끝내지 마라” 같은 규칙을 더 강하게 박아야 했습니다. 코덱스는 그 규칙을 잘 지키는 편이지만, 처음부터 감성의 온도를 알아서 맞추는 타입은 아닙니다. 그래서 글쓰기에서는 코덱스를 작가라기보다 편집 가능한 실무 파트너로 보는 쪽이 맞았습니다.
클로드가 더 좋은 순간은 분명히 남아 있습니다. 첫 번째는 생각을 넓게 펼치는 시간입니다. 아직 구조가 잡히지 않은 기획, 사람의 마음을 읽어야 하는 문장, 가족 이야기나 회고처럼 톤이 중요한 글에서는 클로드가 부드럽습니다. 제가 긴 이야기를 던지면 클로드는 말의 결을 살려서 방향을 잡는 데 능했습니다.
두 번째는 “정답보다 관점”이 중요한 대화입니다. 예를 들어 사업 방향, 콘텐츠 콘셉트, 강의의 메시지 같은 주제에서는 코덱스가 너무 빨리 작업 항목으로 바꾸려 할 때가 있습니다. 반대로 클로드는 조금 더 오래 생각을 굴리며 관점의 폭을 넓혀 줍니다. 이 차이는 장단점이라기보다 도구의 성격 차이에 가깝습니다.
제가 한 달 동안 내린 결론은 간단했습니다. 아이디어를 열 때는 클로드가 편하고, 결과물을 닫을 때는 코덱스가 편합니다. 글의 결을 잡고 싶을 때는 클로드식 대화가 좋고, 실제 파일을 고치고 검증하고 배포해야 할 때는 코덱스가 낫습니다. 그래서 둘 중 하나가 절대적으로 우월하다기보다, 제 작업에서 “마지막 책임을 누가 지느냐”를 기준으로 선택하게 됐습니다.
가장 크게 바뀐 것은 제가 AI에게 일을 맡기는 문장입니다. 예전에는 “이거 어떻게 하면 좋을까?”라고 많이 물었습니다. 지금은 “이 파일 기준으로 확인하고, 깨지는 지점 찾고, 고친 뒤 실행 결과까지 보고해줘”라고 말합니다. 질문이 의견 요청에서 완료 기준 요청으로 바뀐 셈입니다. 코덱스를 쓰면서 저도 조금 더 엔지니어처럼 지시하게 됐습니다.
블로그 자동화에서도 같은 변화가 있었습니다. 예전에는 초안이 나오면 제가 눈으로 읽고 대충 괜찮으면 다음 단계로 넘겼습니다. 지금은 검증 스크립트를 먼저 생각합니다. 합쇼체가 깨졌는지, 이미지 경로가 상대경로인지, HTML에 CSS가 들어갔는지, 발행 URL이 실제로 열리는지 확인합니다. 코덱스는 이런 방식의 작업을 잘 받아 줬고, 덕분에 제 자동화도 조금씩 “기분 좋은 데모”에서 “다시 돌릴 수 있는 운영 흐름”으로 바뀌었습니다.
재미있는 점은 제가 덜 바빠진 게 아니라, 더 정확히 바빠졌다는 점입니다. 예전에는 AI가 만든 답을 제가 다시 정리하느라 바빴습니다. 지금은 성공 기준을 세우고 예외를 줄이는 데 시간을 씁니다. 같은 시간이라도 후자가 훨씬 오래 남습니다. 한 달 지나고 보니 코덱스로 넘어온 가장 큰 효과는 속도가 아니라 작업 습관의 변화였습니다.
앞으로 저는 클로드와 코덱스를 완전히 대체 관계로 보지 않으려 합니다. 클로드는 생각을 열고 말의 온도를 잡는 데 쓰고, 코덱스는 실제 저장소와 자동화를 만지는 데 쓰는 식이 가장 현실적입니다. 특히 코드, 파이프라인, 검증, 배포처럼 실패가 로그로 남는 일은 코덱스에 맡기는 편이 좋았습니다. 반대로 회고, 철학, 브랜드 톤, 사람에게 닿는 문장은 클로드의 장점이 아직 살아 있습니다.
다만 제 메인 작업장은 코덱스 쪽으로 넘어왔습니다. 이유는 단순합니다. 제가 요즘 가장 많이 하는 일이 “말을 예쁘게 듣는 것”보다 “일이 실제로 끝났는지 확인하는 것”에 가깝기 때문입니다. 블로그 하나를 써도 글, 이미지, 옵시디언 저장, HTML 변환, 발행 확인까지 이어집니다. 이 흐름에서는 중간에 손을 놓지 않는 도구가 더 중요했습니다.
한 달 써본 결론을 한 문장으로 줄이면 이렇습니다. 클로드는 좋은 대화 상대였고, 코덱스는 더 좋은 작업 동료였습니다. 글을 같이 고민할 때는 클로드가 떠오르고, 파일을 고치고 배포까지 끝내야 할 때는 코덱스를 켜게 됩니다. 지금 제 환경에서는 그 차이가 꽤 큽니다.
작업이 코드, 파일, 자동화, 검증 중심이라면 코덱스 비중을 높여도 좋습니다. 글쓰기와 생각 정리 중심이라면 클로드를 같이 두는 편이 낫습니다.
초안은 충분히 씁니다. 다만 문장의 온도와 개인 에피소드는 직접 규칙으로 잡아줘야 합니다. 저는 코덱스를 글쓰기 도구라기보다 글까지 처리하는 작업 에이전트로 보고 있습니다.
검증입니다. 코덱스는 파일을 실제로 고치고 실행 결과를 확인하는 흐름이 강합니다. 말로 끝나는 답변보다 완료 기준을 맞추는 데 더 잘 맞았습니다.
클로드에서 코덱스로 넘어온 한 달은 모델 성능 비교라기보다 제 일하는 방식의 변화에 가까웠습니다. 예전에는 좋은 답변을 받는 것이 목표였다면, 지금은 같은 작업을 다시 돌려도 깨지지 않게 만드는 것이 목표가 됐습니다.
그래서 저는 앞으로도 두 도구를 나눠 쓸 생각입니다. 생각을 넓히고 문장을 부드럽게 만들 때는 클로드, 로컬 작업을 끝까지 밀고 갈 때는 코덱스입니다. AI 도구 선택은 누가 더 똑똑한가보다 내 작업의 마지막 단계가 어디서 끝나는가를 보면 훨씬 선명해집니다.