AI 코딩 툴을 갈아타며 정리한 선택 기준

예전에는 AI 코딩 툴을 볼 때 누가 제일 똑똑한가를 먼저 봤다. 몇 달 동안 이것저것 갈아타고 나니, 지금은 보는 기준이 꽤 달라졌다. 이제 먼저 보는 건 얼마나 오래 맡길 수 있나, 환각을 어디까지 감당할 수 있나, 내 작업 방식과 자율성 수준이 맞나, 다른 모델과 조합이 되나 같은 것들이다. 결국 성능 그 자체보다 작업 리듬의 문제에 더 가깝다는 걸 알게 됐다.

이 글에서 말하는 경험 범위는 아래 정도다.

Antigravity: Gemini 3.0 Pro
Claude Code: Claude Opus 4.5, 4.6
Codex: GPT 5.1, 5.2, 5.3, 5.4

왜 계속 갈아탔는가

한 툴에 오래 정착하지 못해서 계속 옮겨 다닌 건 아니다. 작업이 바뀔수록 내가 중요하게 보는 기준이 더 선명해졌고, 그 기준에 맞춰 메인 툴이 바뀌었다.

처음에는 바이브 코딩 자체를 어디까지 믿을 수 있는지가 궁금했다. 그다음에는 단일 모델 하나보다 여러 모델을 역할별로 묶어 쓰는 편이 더 나은지 시험해 보고 싶었다. 지금은 일을 던져 놓고 한참 뒤에 결과를 받는 흐름이 실제로 돌아가는지, 그리고 그 결과를 내가 다시 통제하기 쉬운지가 제일 중요하다.

Antigravity와 Gemini 3.0 Pro: 바이브 코딩 입문과 한계

Antigravity는 내가 바이브 코딩을 제대로 해 본 첫 툴이었다. 블로그를 갈아엎을 때도 써 봤고, Unity 미니게임인 FlyingCat을 일주일 정도 만드는 동안에도 꽤 오래 붙잡고 있었다. 그 시기를 지나면서 처음으로 AI에게 구현을 제법 맡길 수 있겠다는 감각을 얻었다.

도움이 없었던 건 아니다. 초반 속도는 분명히 빨랐고, 내가 직접 코드를 다 치지 않아도 결과를 앞으로 밀 수 있다는 감각을 줬다. 다만 메인 코딩 툴로 쓰기에는 한계가 생각보다 빨리 보였다.

제일 괴로웠던 건 반복되는 컴파일 에러였다. 내가 초반이라 미숙했던 부분도 있었겠지만, Unity에서 작업을 굴리다 보면 비슷한 오류를 계속 되풀이해서 만나는 경우가 잦았다. Gemini 3.0 Pro의 환각도 코딩에서는 자주 발목을 잡았다. 그래서 Antigravity는 바이브 코딩의 가능성을 처음 체감하게 해 준 툴로는 의미가 있었지만, 메인 환경으로 오래 들고 가기는 어려웠다.

OpenCode/OMO: 모델 조합의 가능성

그다음 단계에서 기억에 남은 건 OpenCode 자체보다 Oh-My-OpenCode가 보여준 작업 방식이었다. 당시에는 Claude와 Gemini를 이미 쓰고 있었고, 여기에 GPT까지 더해 여러 모델을 역할별로 나눠 쓰는 흐름을 처음 제대로 굴려 봤다.

여기서 얻은 가장 큰 수확은 단일 모델의 성능보다 모델끼리 어떻게 역할을 나누는가가 더 중요하다는 점이었다. 하나는 전체 흐름을 잡고, 하나는 구조나 리팩토링 같은 깊은 일을 맡고, 하나는 빠르게 코드와 문서를 훑게 두는 식으로 배치하면 서로의 약점이 꽤 많이 상쇄됐다.

OMO를 쓰면서 harness도 많이 들여다보게 됐다. 오픈소스 프로젝트 코드를 읽으면서 구조를 익혔고, 내가 필요했던 기능을 직접 붙여 보기도 했다. PR을 올릴 때는 이미 같은 기능이 먼저 들어가 있어서 반영되지는 않았지만, 그 과정 덕분에 harness를 보는 기준은 이때 많이 잡혔다. 실제로 OMO의 서브에이전트 구성은 따로 추출해 두었고, 회사에서 Claude Code 에이전트 오케스트레이션을 만들 때 참고했다.

OpenCode를 지금도 계속 쓰는 건 아니지만, 툴을 고르는 기준은 이때 거의 정리됐다. 좋은 툴은 혼자 모든 걸 해결하는 툴이 아니라, 내가 원하는 방식으로 여러 모델을 엮을 수 있게 해 주는 툴이었다.

Codex와 GPT 5.4: 맡겨도 된다는 신뢰

2026년 2월 초부터는 개인 작업에서 Codex를 계속 보고 있었다. 다만 5.3 codex까지는 꽤 쓰기 힘들었다. 너무 로봇 같았고, 사람이 한 말을 자연스럽게 받아들이지 못하는 경우가 많았다. 이제는 일을 맡겨도 되겠다는 신뢰가 생긴 건 5.4부터였다.

내 작업 스타일은 원래 일을 잘게 쪼개고, 범위를 정해 던지고, 돌아온 결과를 다시 통제하는 쪽에 가깝다. 5.4부터는 Codex가 이 흐름과 잘 맞았다. 작업을 던져 놓으면 30분, 40분 정도 혼자 처리하다가 결과를 들고 돌아오는 식의 리듬이 자주 나왔다. 다른 사람들은 Codex가 일을 끝까지 안 간다고 느끼기도 하는데, 내 기준에서는 오히려 적당한 선에서 끊고 돌아오는 편이었다.

Claude Code가 같이 방향을 찾아간다는 느낌이라면, Codex는 방향을 알아서 잡아 간다는 느낌에 가깝다. 긴 문제를 붙잡고 구조를 정리하거나, 리팩토링처럼 한동안 손을 떼고 맡겨도 되는 작업에서는 특히 만족도가 높았다.

단점도 분명하다. 너무 방어적으로 코드를 짜는 경향이 있어서, 필요 이상으로 가드 로직을 두껍게 깔거나 결과물이 지나치게 무거워질 때가 있다. 처리 자체는 잘하는데, 그 완벽주의가 오히려 코드를 지저분하게 만드는 순간이 있다.

왜 다시 Claude Code를 같이 쓰려 하는가

그렇다고 Codex 하나로 끝날 것 같지는 않다. 회사에서는 계속 Claude Code를 쓰고 있고, 집에서도 당분간은 Claude Code와 Codex를 같이 쓰는 구성이 제일 잘 맞을 것 같다.

이유는 Claude Code가 맡는 역할이 분명하기 때문이다. Claude는 Codex보다 harness가 강한 편이고, 문제의 전체 그림을 더 잘 본다. 결과물도 조금 더 사람 손을 탄 느낌이 있다. 문제를 어떻게 자를지, 어느 방향으로 갈지, 어디서 멈출지를 정하는 단계에서는 Claude가 중재자로 들어올 때 결과가 더 좋아지는 경우가 있다.

반대로 실제 일을 길게 맡겨 두고 처리시키는 쪽은 Codex가 더 잘 맞는다. 그래서 지금 기준으로는 Claude가 방향을 잡고 Codex가 밀어붙이는 조합이 가장 안정적이다.

지금의 선택 기준

지금은 툴을 볼 때 아래 네 가지를 먼저 본다.

환각 허용치: 반복 컴파일 에러나 명백한 사실 오류가 잦으면 메인 툴로는 오래 쓰기 어렵다.
사용량 여유: 긴 작업을 맡겨 둘 수 있는 여유가 있어야 실제 생산성이 나온다.
자율성 수준: 내가 핑퐁을 많이 하며 같이 끌고 갈 것인지, 범위를 정해 맡길 것인지와 툴의 성격이 맞아야 한다.
조합 가능성: 비슷해 보이는 모델도 실제로는 역할이 다르기 때문에, 여러 모델을 함께 써 보며 감을 잡는 과정이 중요하다.

결국 내 결론은 최고의 단일 모델을 찾는 것보다 모델마다 어디까지 맡길 수 있는지 직접 겪어 보고 역할을 나누는 것에 더 가깝다. Claude Code와 Codex도 겉으로 보면 비슷해 보이지만, 조금만 오래 써 보면 방향이 꽤 다르다. 그 차이는 리뷰 몇 개 읽는 것보다 직접 굴려 보는 편이 훨씬 빨리 보인다.