AI 툴 세 번 갈아탄 이야기 — Cursor에서 Claude, 그리고 Codex
혼자 남은 리뉴얼에서 시작해 Cursor, Claude, Codex까지. 툴은 세 번 바뀌었는데, 끝까지 남은 건 따로 있었어요.
작년 6월, 회사 프론트엔드 개발자가 전부 퇴사했어요. 리뉴얼 프로젝트를 앞에 둔 채로요. 남은 사람은 저 하나였습니다.
이 얘기로 시작하는 이유가 있어요. 제가 AI 툴을 쓰는 방식이 이 사건 전후로 완전히 갈렸거든요. 그 전까지 AI는 '좀 똑똑한 자동완성'이었는데, 이후로는 일을 통째로 맡기는 동료가 됐어요.
오늘은 그 과정에서 주력 툴을 세 번 갈아탄 이야기예요. Cursor에서 Claude로, 그리고 Codex로. 스포일러를 하나 흘리자면 — 끝까지 남은 건 툴이 아니었습니다.
| 기간 | 주력 구성 |
|---|---|
| 2024.03 – 2024.12 | IntelliJ + Tabnine (자동완성 + 챗) |
| 2025.01 – 2025.02 | IntelliJ AI Assistant |
| 2025.02 – 2025.06 | Cursor |
| 2025.06 – 2025.09 | Claude + Cursor (Claude 주력) |
| 2025.09 – 현재 | Codex + Claude + Cursor (Codex 주력) |
자동완성만 믿고 살던 시절
시간을 좀 되감아 볼게요. 2024년 3월부터 연말까지는 IntelliJ에 Tabnine을 붙여 썼어요. 자동완성이랑 챗, 딱 거기까지. 2025년 초 두 달은 IntelliJ AI Assistant로 갈아탔는데, 큰 차이는 없었어요.
이 시기의 AI는 코드를 '제안'하고, 저는 한 줄씩 받아주는 관계였어요. 일을 통째로 맡긴다는 발상 자체가 없었죠. 도구라기보다는 꽤 똑똑한 자동완성 사전. 딱 그 정도였습니다.
돌아보면 자동완성의 한계는 실력이 아니라 단위였어요. 한 줄씩 받다 보면 설계는 여전히 제 몫이고, AI는 제가 이미 정한 길을 빨리 걷게 해줄 뿐이거든요. 길 자체를 다시 그려주지는 못했어요.
(그때는 이게 한계인 줄도 몰랐습니다. 다들 그렇게 쓰고 있었으니까요.)
에이전트 시대 — 세 번의 갈아타기
Cursor — 감 익히기
2025년 상반기 주력은 Cursor였어요. IDE 안에서 채팅으로 코드를 만들다 보니 어느 순간 감이 오더라고요. 아, 이제 AI한테 '일'을 시킬 수 있구나.
여기서 말하는 '감각'은 거창한 게 아니에요. 어디까지 맡기고 어디부터 내가 잡을지, 그 경계를 정하는 눈이에요. 지시가 애매하면 결과도 애매하게 돌아온다는 것. 작업을 잘게 쪼개는 것보다 목적을 분명히 하는 게 먼저라는 것. 전부 이때 몸으로 배웠어요.
이때 익힌 감각이 없었다면, 뒤에 나오는 이야기도 전부 없었을 거예요.
Claude — 혼자 남은 리뉴얼
그리고 6월, 앞에서 말한 그 사건이 터집니다. 리뉴얼은 해야 하는데 프론트엔드 개발자는 저 혼자.
자동완성 수준의 도움으로는 답이 안 나오는 규모였어요. 더 빠르고 깊게 갈 방법을 찾다가 도착한 곳이 Claude였습니다.
(개인 계정 Pro를 제 돈 주고 결제했어요. 그만큼 절박했습니다.)
달라진 건 도구가 아니라 제 역할이었어요. 코드를 '치는' 시간이 줄고, 무엇을 왜 만드는지 정의하고 결과를 검증하는 시간이 늘었죠. 혼자서 리뉴얼을 감당할 수 있었던 건 손이 빨라져서가 아니라, 제 손이 필요한 곳이 줄었기 때문이에요.
Codex — 결정타는 토큰
2025년 9월, GPT-5가 나오자마자 Codex로 갈아탔어요. 이유는 전혀 고상하지 않습니다. 토큰이요, 토큰.
에이전트 방식은 구조적으로 토큰을 많이 씁니다. 계획을 세우고, 코드를 읽고, 고치고, 검증하는 모든 단계가 대화거든요. 한도가 빡빡하면 아끼게 되고, 아끼는 순간 일하는 방식 자체가 쪼그라들어요. '한도 걱정 없이 돌린다'는 건 편의가 아니라 방식의 전제 조건이었습니다.
물론 Claude랑 Cursor를 버린 건 아니에요. 지금도 셋을 상황 따라 같이 씁니다.
돌아보니 남은 것
CLI에서 앱으로
인터페이스는 줄곧 CLI였어요. 터미널에서 에이전트 돌리는 흐름이 손에 익어서요. 2026년 1월부터는 Codex 앱으로 옮겼습니다.
(이건 진작 옮길 걸 그랬어요. 괜히 버텼습니다.)
손에 익었다는 이유로 버티는 것도 관성이더라고요. 도구를 세 번이나 갈아탄 사람이, 인터페이스 하나는 2년을 붙잡고 있었으니까요.
솔직한 고백 하나
하네스(harness)가 정확히 뭔지 아직 잘 몰라요. 도구가 에이전트를 감싸서 실행해 주는 층... 정도로만 알고 있어요.
안 찾아봤냐고요? 네. 제 방법론대로 돌렸을 때 아무 문제가 없었거든요. 자랑은 아니고, 우선순위의 문제예요. 도구 내부를 아는 것과 도구로 결과를 내는 것 중 하나를 골라야 했고, 저는 후자를 골랐어요. 내부가 궁금해지는 날이 오면 그때 파도 늦지 않다고 생각했고요.
(덧붙임: 그날이 왔습니다. 하네스가 뭔지 모른다던 사람이 회사에서 하네스를 직접 만들었어요. 검색해서 배운 게 아니라 필요해서 만들었고, 만들고 나서야 왜 필요한지 몸으로 알았습니다. 그 이야기는 백엔드 개발자가 프론트 화면을 고치기 시작했다에 있어요.)
도구는 세 번 바뀌었어요. 그런데 끝까지 남은 건 도구가 아니라 일하는 방식이었습니다.
그 방식이라는 건 결국 이 다섯 가지예요.
- 목적과 제약은 사람이 정한다
- 대안을 받는다
- 반문한다
- 작게 구현한다
- 검증한다
이 흐름은 Cursor에서든 Codex에서든 똑같았어요. 자세한 방법론은 AI와 일하는 프로세스 시리즈에서 제대로 풀어볼게요. 이 시리즈의 다음 편은 — 셋을 같이 쓰는 이유입니다.
