AI 코딩 도구 5종 직접 써본 비교 체험기 — 바이브코딩으로 실제 프로젝트를 만들어 봤습니다
Gemini CLI, Codex CLI, Kiro, Antigravity, Claude Code까지 5개 AI 코딩 도구를 실제 프로젝트에 써보고 비교한 체험기입니다. 디지털 마케터가 바이브코딩으로 프로덕트를 만든 경험과 AI FOMO에 대한 솔직한 이야기를 담았습니다.
AI 코딩 도구가 쏟아지는 시대, 직접 다 써봤습니다
2025년 들어 AI 코딩 도구가 폭발적으로 늘었습니다. Cursor, Windsurf 같은 IDE가 자리를 잡더니, 이제는 터미널에서 바로 코딩하는 CLI 도구들까지 쏟아지고 있습니다. Google의 Gemini CLI, OpenAI의 Codex CLI, AWS의 Kiro, Google의 Antigravity, 그리고 Anthropic의 Claude Code까지. 매주 새로운 도구가 발표될 때마다 "이것도 써봐야 하나" 하는 생각이 드는 건 저만은 아닐 겁니다.
저는 디지털 마케터입니다. 개발자가 아닙니다. 그런데 왜 AI 코딩 도구를 5개씩이나 써봤을까요? 이유는 단순합니다. 마케팅 실무에서 반복적으로 겪는 불편함을 직접 해결하고 싶었기 때문입니다. 광고 리포트를 자동화하고, GA4 데이터를 API로 가져오고, 나만의 대시보드를 만들고 싶었습니다. 이른바 "바이브코딩(Vibe Coding)" — AI에게 자연어로 원하는 걸 설명하면 코드를 만들어주는 방식으로 실제 프로젝트 여러 개를 완성했습니다.
이 글은 각 도구를 실제로 사용하며 느낀 솔직한 비교 리뷰입니다. 마케터의 관점에서, 비개발자가 바이브코딩으로 프로덕트를 만들면서 겪은 경험을 정리했습니다. 그리고 후반부에는 이 과정에서 빠져들게 되는 AI FOMO에 대한 이야기도 담았습니다.
5개 도구 비교 리뷰: 실제로 어떤 프로젝트를 만들었는가

Gemini CLI — 무료라는 강력한 무기
Gemini CLI는 Google이 오픈소스로 공개한 터미널 기반 AI 코딩 도구입니다. Gemini 모델을 사용하며, Google 계정만 있으면 무료로 사용할 수 있다는 점이 가장 큰 장점입니다.
이 도구로 간단한 마케팅 데이터 정리 스크립트를 만들어 봤습니다. CSV 파일을 읽어서 캠페인별 성과를 정리하는 정도의 작업에서는 무난하게 동작했습니다. 진입장벽이 거의 없어서 "AI 코딩이 뭔지 한번 경험해 보고 싶다"는 분께 추천할 만합니다.
다만 프로젝트가 복잡해지면 한계가 드러납니다. 여러 파일에 걸친 코드를 수정할 때 문맥을 잃거나, 이전 지시를 무시하는 경우가 있었습니다. 무료 티어의 토큰 제한도 긴 작업에는 부담이 됩니다. 가볍게 시작하기에는 최적이지만, 본격적인 프로젝트에는 아쉬움이 남습니다.
OpenAI Codex CLI — 가볍고 단순한 오픈소스
Codex CLI는 OpenAI가 공개한 오픈소스 터미널 코딩 도구입니다. GPT 모델을 기반으로 하며, 설치와 사용법이 간단합니다. 샌드박스 모드로 시스템 안전성을 확보한 점도 특징입니다.
이 도구로 광고 리포트 데이터를 API에서 가져와 정리하는 스크립트를 작성해 봤습니다. 단일 파일 수준의 작업에서는 깔끔하게 동작했습니다. 코드 생성 속도도 빠르고, 명확한 요청에 대해서는 정확한 코드를 만들어 줍니다.
하지만 멀티 파일 프로젝트로 넘어가면 이야기가 달라집니다. 프로젝트 전체 구조를 파악하는 능력이 약해서, 파일 간의 의존성을 놓치는 경우가 잦았습니다. 또한 코드를 실행하고 에러를 스스로 수정하는 "에이전틱" 능력이 다른 도구에 비해 제한적이었습니다. 빠르게 단일 스크립트를 만들 때는 좋지만, 지속적으로 관리해야 하는 프로젝트에는 적합하지 않았습니다.
Kiro (AWS) — 스펙 먼저, 코드는 나중에
Kiro는 AWS가 발표한 IDE 형태의 AI 코딩 도구입니다. 다른 도구들과 가장 차별화되는 점은 "스펙 기반 개발(Spec-driven Development)" 접근법입니다. 코드를 바로 생성하는 대신, 먼저 요구사항 문서와 설계 문서를 작성하고 사용자의 승인을 거친 뒤에 코드를 생성합니다.
이 도구로 GA4 Data API를 활용한 데이터 조회 프로젝트를 시작해 봤습니다. 요구사항을 입력하면 자동으로 스펙 문서가 만들어지고, 단계별로 체크리스트까지 생성해 주는 것이 인상적이었습니다. "이건 개발 프로세스를 아는 팀에서 쓰면 좋겠다"는 생각이 들었습니다.
반면 개인 프로젝트나 빠른 프로토타이핑에는 과도한 절차가 오히려 방해가 됩니다. 간단한 스크립트 하나 만드는 데 스펙 문서부터 작성해야 하는 건 배보다 배꼽이 큰 느낌이었습니다. 또한 현재 기반 모델(Claude Sonnet)의 성능이 독립적인 Claude Code에 비해 제한적으로 느껴졌습니다. 체계적인 팀 프로젝트에는 강점이 있지만, 개인의 바이브코딩 용도로는 무거운 편입니다.
Google Antigravity — 멀티 에이전트의 가능성
Antigravity는 Google이 발표한 실험적 코딩 에이전트입니다. 가장 눈에 띄는 특징은 멀티 에이전트 구조입니다. 하나의 작업을 여러 에이전트가 나눠서 병렬로 처리하는 방식으로, 복잡한 프로젝트에서 속도 이점을 가질 수 있습니다.
이 도구로 웹 애플리케이션의 여러 기능을 동시에 구현하는 테스트를 해봤습니다. 실제로 독립적인 기능 3개를 동시에 만들어 달라고 하니 각각의 에이전트가 병렬로 작업하는 모습이 인상적이었습니다. 단순 작업의 동시 처리 측면에서는 분명한 장점이 있었습니다.
하지만 현재 시점에서는 아직 실험적인 단계라는 느낌이 강합니다. 에이전트 간의 작업 결과를 병합할 때 충돌이 발생하는 경우가 있었고, 전체적인 코드 일관성을 유지하기 어려웠습니다. 개별 에이전트의 추론 품질도 단일 에이전트 도구에 비해 아쉬운 부분이 있었습니다. 미래의 방향성은 흥미롭지만, 지금 당장 메인 도구로 쓰기에는 이른 감이 있습니다.
Claude Code — 추론 품질이 결국 승부를 가른다
Claude Code는 Anthropic의 터미널 기반 에이전틱 코딩 도구입니다. Claude 모델을 사용하며, 프로젝트 전체 맥락을 이해하고 자율적으로 파일을 읽고, 수정하고, 명령어를 실행하는 능력이 가장 뛰어났습니다.
이 도구로 개인 블로그 전체를 만들었습니다. Next.js 기반의 풀스택 웹 애플리케이션으로, 프론트엔드와 백엔드 API, 데이터베이스 설계, SEO 최적화, 배포 자동화까지 모든 과정을 Claude Code와 함께 진행했습니다. 뿐만 아니라 마케팅 업무 자동화 스크립트, Notion 연동, GA4 데이터 파이프라인 등 복잡한 프로젝트들도 이 도구로 완성했습니다.
다른 도구들과 비교했을 때 가장 큰 차이는 추론의 깊이입니다. "이 파일을 수정하면 저쪽 파일에도 영향이 있으니 함께 수정해야 한다"는 판단을 스스로 해줍니다. 에러가 발생하면 로그를 읽고 원인을 분석한 뒤 수정안을 제시하는 과정이 자연스럽습니다. 복잡한 프로젝트일수록 이 추론 품질의 차이가 결정적이었습니다.
물론 단점도 있습니다. API 사용량 기반 과금이라 비용이 발생하고, 복잡한 작업에서는 토큰 소모가 상당합니다. 또한 모든 AI 코딩 도구가 그렇듯, 완벽하지 않아서 생성된 코드를 검증하는 과정은 반드시 필요합니다.
5개 도구 비교 종합표
| 항목 | Gemini CLI | Codex CLI | Kiro | Antigravity | Claude Code |
|---|---|---|---|---|---|
| 개발사 | OpenAI | AWS | Anthropic | ||
| 형태 | CLI | CLI | IDE | 웹 에이전트 | CLI |
| 기반 모델 | Gemini | GPT | Claude Sonnet | Gemini | Claude |
| 비용 | 무료 | API 과금 | 무료(프리뷰) | 무료(프리뷰) | API 과금 |
| 멀티파일 이해 | 보통 | 약함 | 보통 | 보통 | 강함 |
| 추론 품질 | 보통 | 보통 | 보통 | 보통 | 강함 |
| 에이전틱 능력 | 보통 | 약함 | 보통 | 강함(병렬) | 강함 |
| 체계성 | 약함 | 약함 | 강함 | 보통 | 보통 |
| 추천 용도 | 입문/간단 작업 | 단일 스크립트 | 팀 프로젝트 | 실험/탐색 | 복잡한 프로젝트 |
왜 Claude Code를 최종 선택했는가
5개 도구를 모두 써본 결과, 저는 Claude Code를 메인 도구로 선택했습니다. 가장 결정적인 이유는 세 가지입니다.
첫째, 복잡한 프로젝트에서의 추론 품질입니다. 파일이 20개가 넘고, 프론트엔드와 백엔드가 연결되고, 데이터베이스 스키마가 변경되는 상황에서 전체 맥락을 유지하면서 작업하는 능력은 Claude Code가 압도적이었습니다. 다른 도구들은 프로젝트가 커질수록 문맥을 잃거나 이전 작업과 충돌하는 코드를 생성하는 빈도가 높아졌습니다.
둘째, 멀티 플랫폼 지원입니다. Claude Code는 터미널 CLI로 사용할 수 있을 뿐 아니라, VS Code와 JetBrains IDE 확장으로도 동작하고, claude.ai 웹에서도 사용할 수 있습니다. 상황에 따라 터미널에서 빠르게 작업하거나, IDE에서 시각적으로 확인하거나, 모바일에서 진행 상황을 체크하는 것이 모두 가능합니다.
셋째, MCP(Model Context Protocol)를 통한 확장성입니다. MCP는 AI 모델이 외부 도구와 데이터 소스에 접근할 수 있게 해주는 프로토콜입니다. 이를 통해 Claude Code가 Notion API에 직접 접근하여 페이지를 검수하거나, 데이터베이스를 업데이트하는 것이 가능합니다. 단순히 코드를 생성하는 것을 넘어, 업무 자동화 에이전트로 활용할 수 있다는 점이 다른 도구와 차별화되는 지점입니다.
실제로 저는 Claude Code와 MCP를 조합하여 블로그 콘텐츠 생성부터 검수, SEO 최적화, 배포까지의 전 과정을 자동화하는 시스템을 구축했습니다. Notion 워크스페이스의 콘텐츠 현황을 자동으로 확인하고, 맞춤법 검수를 수행하고, 데이터베이스를 최신 상태로 유지하는 것도 같은 도구로 처리합니다. 이런 수준의 확장은 다른 AI 코딩 도구에서는 아직 구현하기 어렵습니다.
바이브코딩 시대의 AI FOMO

변화의 속도와 끝없는 불안
솔직히 고백하겠습니다. 이 5개 도구를 모두 써본 것 자체가 FOMO(Fear Of Missing Out)의 결과물입니다. 새로운 AI 코딩 도구가 발표될 때마다 "저걸 안 써보면 뒤처지는 게 아닐까"라는 불안감이 밀려옵니다. 그리고 실제로 써봐야 직성이 풀립니다.
AI 분야의 변화 속도는 다른 기술 영역과 비교할 수 없을 정도로 빠릅니다. 한 달 전에 최신이었던 도구가 이번 주에는 이미 구식이 됩니다. 이 속도를 따라가려면 끊임없이 학습하고, 시도하고, 비교해야 합니다. 그 과정에서 "내가 지금 쓰는 도구가 최선인가?"라는 의심은 끊이지 않습니다.
잘 알수록 FOMO가 심해진다
역설적이지만, AI에 대해 잘 아는 사람일수록 FOMO가 심합니다. 모르면 모르는 대로 하나의 도구에 만족할 수 있지만, 각 도구의 아키텍처 차이를 이해하고, 모델 성능의 미묘한 차이를 체감할 수 있는 사람은 "저 도구가 이 부분에서는 더 나을 수 있다"는 판단이 자동으로 떠오릅니다. 이것은 축복이자 저주입니다.
디지털 마케팅 분야에서 10년 넘게 일하면서 Google Analytics의 버전 변화(UA에서 GA4로), 광고 플랫폼의 어트리뷰션 모델 변화, 서드파티 쿠키 폐지 논의 등 숱한 기술 변화를 경험했습니다. 그때마다 "이전에 배운 것이 무용지물이 되는 게 아닌가"라는 불안이 있었습니다.
히스토리를 아는 것이 오히려 유리하다
하지만 경험으로 확인한 사실이 있습니다. 기술은 바뀌어도 맥락을 아는 사람이 새로운 기술에도 빠르게 적응합니다. GA4로 전환될 때, UA의 세션 기반 분석을 깊이 이해하고 있던 사람이 이벤트 기반 모델의 차이점을 훨씬 빠르게 파악했습니다. AI 코딩 도구도 마찬가지입니다. 이전 도구에서 "에이전틱 코딩이란 무엇이고, 컨텍스트 윈도우의 제약이 어떤 문제를 만드는지" 경험한 사람이 새로운 도구가 나왔을 때 핵심 차이를 즉시 파악할 수 있습니다.
공부한 것이 무용지물이 되는 것이 아닙니다. 쌓인 맥락 위에 새로운 지식이 더 빠르게 얹어지는 것입니다. 두려워할 것은 기술의 변화가 아니라, 변화 자체를 외면하는 것입니다.
격차는 벌어지고 있습니다
한 가지 분명한 것이 있습니다. AI 도구를 활용하는 사람과 그렇지 않은 사람 사이의 생산성 격차가 빠르게 벌어지고 있습니다. 이것은 "컴퓨터를 잘 쓰는 것"과는 다른 차원의 문제입니다.
엑셀 함수를 잘 아는 것과 AI에게 "이 데이터를 이런 기준으로 분석해 줘"라고 정확하게 지시하는 것은 완전히 다른 능력입니다. 후자는 문제를 구조화하고, 원하는 결과물의 형태를 명확히 정의하고, AI의 출력을 검증하는 능력을 요구합니다. 이 능력은 코딩을 할 줄 아는 것과도 별개입니다.
개발자의 거부감, 비개발자의 무분별함
AI 코딩 도구를 둘러싼 반응은 양극단으로 갈립니다. 한쪽에서는 경력 있는 개발자들이 AI 코딩 도구에 대해 강한 거부감을 보입니다. "AI가 생성한 코드는 신뢰할 수 없다", "기초를 모르고 AI에 의존하면 안 된다"는 입장입니다. 이 우려는 타당합니다.
반대편에서는 비개발자들이 AI 코딩 도구를 만능처럼 사용하는 모습이 보입니다. 코드 리뷰 없이 AI 출력을 그대로 프로덕션에 반영하거나, 보안 취약점이 있는 코드를 인지하지 못하고 배포하는 경우가 실제로 발생합니다.
둘 다 극단입니다. AI 코딩 도구는 강력한 보조 수단이지만, 출력물에 대한 검증 능력은 사용자에게 있어야 합니다. 개발자가 AI를 거부하면 생산성 향상의 기회를 놓치고, 비개발자가 AI를 맹신하면 품질과 보안의 문제가 생깁니다. 건강한 태도는 그 중간 어딘가에 있습니다.
보안은 바이브코딩의 사각지대
바이브코딩을 하면서 가장 조심해야 할 영역은 보안입니다. AI가 생성한 코드에 API 키가 하드코딩되어 있거나, .env 파일이 Git에 포함되거나, 입력값 검증 없이 데이터베이스 쿼리를 실행하는 경우를 실제로 여러 번 목격했습니다.
비개발자는 이런 문제를 인지하기 어렵습니다. AI에게 "잘 만들어 줘"라고 요청하면, AI는 "동작하는 코드"를 만들어 줍니다. 하지만 "안전한 코드"와 "동작하는 코드"는 같지 않습니다. .gitignore에 .env를 추가하는 것, 환경변수로 민감 정보를 관리하는 것, CORS 설정을 확인하는 것 — 이런 보안 기본기는 AI가 알아서 챙겨주지 않는 경우가 많습니다. 바이브코딩을 시작하는 분이라면 보안 체크리스트를 반드시 별도로 관리하시기를 권합니다.
도구는 바뀌어도 문제 정의 능력은 바뀌지 않습니다
5개의 AI 코딩 도구를 써보면서 가장 크게 느낀 점은 역설적이게도 도구 자체에 대한 것이 아닙니다. "AI에게 무엇을 만들어 달라고 설명하는 과정"이 가장 어렵고, 가장 가치 있는 부분이라는 것입니다.
어떤 도구를 쓰든 사용자가 문제를 명확하게 정의하지 못하면 결과물도 흐릿해집니다. "대시보드 만들어 줘"보다 "GA4 API에서 지난 30일간 페이지별 조회수를 가져와서, 상위 10개 페이지를 바 차트로 보여주는 대시보드를 만들어 줘"라고 말할 수 있는 능력이 도구 선택보다 중요합니다.
도구는 앞으로도 계속 바뀔 겁니다. 지금 최고인 도구가 1년 뒤에도 최고일 거라는 보장은 없습니다. 하지만 문제를 정의하고, 요구사항을 구조화하고, 결과물을 검증하는 능력은 어떤 도구를 쓰든 유효합니다. AI FOMO에 휘둘리기보다, 이 근본적인 능력을 키우는 것이 더 나은 투자입니다.
3줄 요약:
- AI 코딩 도구 5종을 실전에 써본 결과, 복잡한 프로젝트에서는 모델의 추론 품질(Claude Code)이 결정적인 차이를 만들었습니다.
- 바이브코딩 시대의 AI FOMO는 자연스러운 현상이지만, 기술 변화의 맥락을 이해하는 사람이 결국 새 도구에도 빠르게 적응합니다.
- 도구보다 중요한 것은 문제를 정의하는 능력입니다. AI에게 무엇을 만들어 달라고 설명하는 과정이야말로 바이브코딩의 핵심입니다.
