[AI] 바이브 코딩 후기(oh-my-opencode, gemini cli, antigravity)

💬 소개

잠숨고청(잠시 숨을 고르는 청년) 생활이 길어지면서, 내가 어떤 것을 해야 할지 체계적으로 정리하고 공부하기 위해 데스크톱 TODO 앱을 만들고 있다.

 

이 프로젝트를 개발하면서 바이브 코딩(Vibe Coding) 방식을 적극적으로 도입해 보았다. 구체적으로 Gemini CLI, oh-my-opencode, 그리고 Google Antigravity 환경을 활용해 보았으며, 각 도구가 가진 장단점과 특징을 리뷰해 보려고 한다.

🚨 주의 사항

무료 API 키를 사용하거나 OAuth를 사용하여 로그인한 경우, Gemini CLI나 oh-my-opencode 사용 시 입력된 프롬프트, 코드 그리고 생성된 결과물은 Google의 모델 개선에 사용될 수 있다. 따라서 무료 사용자의 경우 실무 프로젝트 개발 시 보안에 주의해야 한다.

👾 AI Agent 프롬프팅 전략

현재 Google AI Pro 플랜만 구독하여 사용 중이다. 각 AI 에이전트에게 작업을 지시할 때는 주로 아래와 같은 3단계 템플릿을 유지했다.

### [Objective]
(구현할 기능의 최종 목표와 비즈니스 로직 설명)

### [Execution Plan]
(프론트엔드/백엔드 관점에서의 단계별 실행 계획)

### [Validation Criteria]
(개발 완료 후 정상 작동 여부를 판단할 체크리스트)

이는 AI가 코드를 작성할 때 길을 잃지 않도록 돕는 명확한 내비게이션 역할을 한다. 목표를 제시하고, FE/BE 흐름을 단계적으로 세분화하여 지시하며, 스스로 결과물을 검토할 수 있는 체크리스트를 제공함으로써 AI 환각(Hallucination)을 최소화하고 정확한 산출물을 얻어낼 수 있었다.

1. Gemini CLI

프로젝트 초반 환경을 빠르게 구성할 때 주력으로 사용한 방식이다.

장점

압도적인 접근성과 토큰 여유

Gemini CLI를 OAuth로 인증한 경우, 하루 종일 사용해도 제한에 걸리지 않을 정도로 쿼터가 넉넉하다. 실제로 8시간 넘게 개발에 사용했음에도 제한에 도달하지 않았다. 구글에서 제공하는 정보에 따르면 다음과 같다.

• General Users (Personal Google Account):
  • Maximum 1,000 model requests per day
  • Maximum 60 model requests per minute
• Gemini Code Assist Paid Subscribers:
  • Google AI Pro: Maximum 1,500 requests per day
  • Google AI Ultra: Maximum 2,000 requests per day

무료 가입자나 유료 가입자 모두 매우 여유롭게 사용할 수 있다. 그럼에도 효율적인 토큰 관리를 위해 /compress를 사용하여 대화 내역을 압축하거나, /clear를 통해 새로운 세션을 만드는 등 다양한 방식을 활용했다.

빠른 속도로 초기 MVP 개발

GEMINI.md 파일과 같이 Agent에게 가이드를 내리는 Rules(System Prompt) 설정은 선택이 아닌 필수다. 개인적으로 이 파일에 다음과 같은 내용으로 단계를 구성했다.

• 기획 문서 태그를 통해 프로젝트 콘텍스트 파악
  • 프로젝트 내부에 docs/ 폴더 생성
  • 기획 문서 및 프로젝트 구조, 각 파일에 대한 간략한 설명 작성
  • 필요한 문서를 먼저 읽도록 지시
• 개발 스타일 및 컨벤션에 대한 규칙
  • 사용하는 언어에 대한 구체적인 코드 컨벤션 지시 (예: 라인 주석 대신 JavaDoc 등 문서화 주석 사용)
  • 파일 분기 시점 정의
• 테스트 및 빌드 통과 시 git 작업 진행
  • 구체적인 테스트 작성 방법 지시(실패 및 성공 테스트 작성)
  • 테스트 통과 및 빌드 성공 시 git add, commit, push 진행

이 경우 단일 요청에 소모되는 토큰량은 많아질 수 있지만, AI의 실수로 인해 처음으로 롤백해서 다시 요청하거나 잘못 개발된 내용을 수정해달라고 요청하는 것보다 훨씬 효율적이다. 또한, 프로젝트의 구조와 특정 파일의 역할 등을 간략히 정리해 두면 AI가 전체 파일을 뒤지지 않고도 빠르게 작업을 진행할 수 있다.

 

정리하자면, 명확한 룰을 작성하는 것만으로 원하는 기능을 빠르게 개발 및 검증하고, 필요한 내용을 수정할 수 있다. 이는 다른 Agent를 사용할 때도 마찬가지겠지만, 첫 번째 장점인 압도적인 접근성과 토큰 여유가 맞물려 초기 MVP의 빠른 개발을 가능하게 했다.

단점

구체적인 계획의 누락

하나의 프롬프트에 너무 많은 지시 사항을 담아 계획을 짜라고 지시할 경우, 일부 내용이 누락되는 현상이 발생한다. 특정 파일을 생성해 계획을 관리하고 그 파일을 기반으로 체크하며 개발하도록 유도하면 어느 정도 해결될 것 같다.

 

하지만 바바현사에서 매번 세세한 계획 파일까지 관리하며 지시하기에는 번거로움이 따른다. 다행히 사용량이 넉넉하므로 누락된 지시 사항은 다시 요청하면 그만이긴 하다.

2. oh-my-opencode

가장 기대했던 기술이자, 오케스트레이션(Orchestration) 도구다. 여러 AI 에이전트가 팀을 이루어 역할을 분담하는 구조를 띠고 있다.

장점

뛰어난 계획 수립

단일 모델 도구에는 없는 '에이전트 간 협업을 통한 계획 수립' 기능을 갖추고 있다. /init-deep 명령어를 통해 프로젝트에 대한 정보를 에이전트들이 참고할 수 있는 시스템 프롬프트 및 컨텍스트 문서들을 생성하게 되고, 이를 바탕으로 체계적인 개발을 진행한다.

oh-my-opencode를 사용하는 경우 크게 두 가지 개발 방식이 존재한다.

1. Sisyphus 에이전트에게 /ulw (Ultrawork) 모드로 자율 개발 시키기
2. Prometheus (Plan Builder)가 계획을 세우고 Atlas (Plan Executor)가 계획을 실행하기

각각 장단점이 있지만, 공식 문서의 설명이 아주 적절하다.

ultrawork (또는 ulw) 치세요. 끝.

/ulw 모드로 Sisyphus에게 지시를 내리면 스스로 해야 할 일들을 리스트업하고 TODO를 작성한 뒤 작업이 끝날 때까지 밀어붙인다. 다른 일을 하고 돌아오면 지시한 업무가 마무리되어 있는 것을 볼 수 있다.

 

또 다른 방식으로는 Prometheus와 Atlas를 연계하는 것이다. Prometheus에게 원하는 개발 사항을 전달하면, 역으로 필요한 정보나 테스트 방식 등을 꼬치꼬치 묻는 '인터뷰'를 시전한다.

 

모든 인터뷰가 끝나고 구체적인 기획이 완료되면, 키보드의 Tab 키를 통해 에이전트를 Atlas로 변경하여 /start-work로 실행을 지시한다. 그러면 Prometheus가 세운 정교한 계획을 바탕으로 실제 코드를 작성한다. 이 과정은 마치 뛰어난 시니어 기획자/설계자와 함께 개발하는 듯한 느낌이 들게 만든다.

역할별 모델 최적화

가장 큰 장점 중 하나다. 메인 오케스트레이터(Sisyphus)나 아키텍처 리뷰어(Oracle)에는 추론 능력이 뛰어난 최신 하이엔드 모델을, 단순 검색이나 코드 탐색(Librarian, Explore)에는 빠르고 가벼운 모델을 할당하는 등 자유로운 매핑이 가능하다.

 

설정 과정에서 OpenAI, Google 등 여러 API 인증 정보를 추가하면 역할에 맞는 모델을 자동으로 주입해 준다. 덕분에 복잡한 설정 없이 설치 직후 바로 최적화된 환경에서 개발에 돌입할 수 있다.

단점

아래 작성된 단점은 Google AI Pro 단일 플랜만 구독하고 있어 발생하는 개인적인 한계일 수 있으니 참고용으로 봐주시면 감사하겠습니다.

API 리밋(Rate Limit) 병목

여러 프로바이더(Provider)의 인증 정보를 추가하여 모델을 분산시키면 큰 문제가 없겠지만, 단일 플랜만 사용할 경우 각 에이전트 역할에 동일한 모델이 중복 할당된다. 결국 짧은 시간에 많은 요청이 몰리면서 TPM(Tokens Per Minute) 제한에 걸려 개발이 중간에 멈추는 병목 현상이 발생한다.

 

물론 oh-my-opencode 내부적으로 API 요청 실패 시 스케줄링을 통해 일정 시간 뒤 재시도하는 로직이 있다. 즉, 시간에 구애받지 않는다면 단일 플랜으로도 개발을 완료할 수는 있다.

치밀한 계획 수립에 따른 오버헤드

"나무를 베는 데 6시간이 주어진다면, 나는 처음 4시간을 도끼를 가는 데 쓸 것이다."라는 링컨의 명언처럼, 좋은 결과물을 위해서는 계획 수립에 많은 시간을 투자해야 한다.

 

하지만 Prometheus에게 계획 수립을 지시하면 체감상 꽤 오랜 시간이 소요된다. 30분씩 걸리는 것은 아니지만 답답함이 느껴질 때가 있다. AI가 계획을 세우는 동안 다른 업무를 보다가, AI의 질문(인터뷰) 알림이 울리면 다시 돌아와 응답해야 한다. 집중하고 있는 다른 업무가 있다면 약간의 Context Switching 비용이 발생한다.

 

그렇다면 속도가 빠른 Sisyphus에게 자율 작업을 시키면 되지 않을까? 이 역시 애매하다. 속도는 빠르지만 세부적인 검토 과정(인터뷰)이 생략된 채 독단적으로 코드를 수정하기 때문에 기획 의도와 다른 결과물이 나올 위험이 있다.

 

결국 목적에 따라 선택해야 한다. 시간이 걸리더라도 정교하고 높은 퀄리티의 결과물을 원한다면 Prometheus -> Atlas 파이프라인을, 빠르게 결과물을 도출하고 검증하고 싶다면 Sisyphus를 사용하는 것이 맞다.

개인적인 견해로는 Sisyphus를 사용하는게 더 사용 경험이 좋게 느껴진다.

3. Google Antigravity

Google Antigravity는 Cursor, Windsurf 등과 같은 VS Code Fork 기반의 AI 에디터이다.

장점

종합 선물 패키지

2026년 3월 3일 기준으로 Gemini 3.1 Pro, Gemini 3 Flash, Claude Sonnet 4.6, Claude Opus 4.6와 같은 다양한 모델을 자유롭게 선택하여 사용할 수 있다. 무료 계정은 주 단위로 한도가 갱신되며, Pro 및 Ultra 플랜은 5시간마다 초기화되어 플랜에 따라 더 많은 사용량을 제공한다.

 

또한 두 가지 개발 모드를 제공한다.

• Planning: 제공된 프롬프트에 대해 Task와 Implementation Plan을 수립한 후 개발을 진행한다. (oh-my-opencode의 Sisyphus와 유사하게 TODO를 계획하고 실행)
• Fast: 계획 수립 없이 제공된 프롬프트를 즉시 실행한다. (Gemini CLI와 유사)

번외 수확 (의도치 않은 버그 픽스)

oh-my-opencode로 개발한 뒤, Google Antigravity로 환경을 옮겨 다음 작업을 지시했다. 작업 완료 후 커밋 내역을 확인하다가 흥미로운 메모를 발견했다.

번외 수확: 기존 백엔드 단위 테스트 5개가 planning_memo 컬럼 누락으로 모두 실패하고 있었는데, 이번에 테스트 스키마도 함께 수정하여 전체 9개 테스트가 통과합니다.

확인해 보니 이전 도구에서 업무를 지시할 때 빌드 성공 여부만 확인하고 테스트 통과 여부를 꼼꼼히 체크하지 않은 것 같았다. 하지만 프로젝트에 세팅해 둔 GEMINI.md의 "테스트가 통과하는지 확인하고, 빌드 확인 후 git에 추가하라"는 지시 사항 덕분에 Antigravity가 스스로 이전의 실패한 테스트를 발견하고 고친 것이다.

 

물론 다른 AI Agent도 가능한 일일 수 있지만, 지시하지도 않은 레거시 버그를 스스로 찾아 수정까지 한 경험은 처음이라 매우 놀라웠다. 의도치 않은 코드 변경에 토큰이 소모되는 것을 꺼리는 사람도 있겠지만, 필자 입장에서는 바이브 코딩 중 놓칠 수 있는 에러를 AI가 스스로 잡아주어 오히려 땡큐였다.

단점

넉넉하지 않은 한도

Google AI 플랜 구독자는 무료 사용자보다 한도가 높고 5시간마다 초기화된다는 장점이 있지만, 그럼에도 한도 초과에 자주 부딪힌다. 긴 호흡으로 개발을 진행하기에는 제약이 느껴진다.

 

Google AI Pro 플랜 기준으로 최신 하이엔드 모델을 2~3회 깊게 사용하면 금세 제한이 걸리는 느낌이다. 횟수 제한이 아닌 토큰 사용량 기준이라서 작업 크기를 예측하며 애매하게 사용해야 하는 불편함이 있다.

🤔 회고

최근 AI Agent를 활용한 개발에서 가장 핵심적인 이슈는 하네스(Harness) 구축인 것 같다. 하네스는 본래 조종사나 등반가의 '안전벨트'를 뜻하지만, 소프트웨어 공학에서는 시스템이나 컴포넌트를 검증하기 위한 환경, 데이터, 스크립트, 도구들의 집합을 의미한다.

즉, 바이브 코딩의 성공 여부는 AI가 마음껏 코드를 작성하고 수정해도 시스템이 망가지지 않도록 보장해 주는 자동화된 테스트 및 실행 환경(하네스)을 얼마나 잘 구성하느냐에 달려 있다.

 

최근 김용성 님이 작성하신 토스 테크 블로그 글을 인상 깊게 읽었다. 현재 많은 개발팀의 LLM 도입은 각자도생에 가깝다고 한다. 프롬프트 컨텍스트를 잘 설계하는 엔지니어는 금방 결과를 얻지만, 그렇지 못한 엔지니어는 환각 현상을 바로잡느라 더 많은 시간을 허비한다는 것이다.

 

따라서 이러한 개인 역량의 격차를 방치하지 말고, 터미널 도구나 내부 마켓플레이스 등을 통해 팀 도메인에 최적화된 하네스를 구축하여 숙련된 팀원의 워크플로우를 조직 전체에 복제하는 시스템적 접근이 필요하다고 강조한다.

 

이 글을 읽으며 "나는 내가 사용하는 에이전트 환경에서 하네스를 완벽히 구축했는가?" 되돌아보게 되었다. 프로젝트에 도메인 지식을 주입하고, 테스트와 빌드를 강제하는 등 나름대로 안전장치를 마련하기 위해 치열하게 고민해 왔다는 사실을 새삼 깨달았다. AI를 단순한 코드 생성기가 아닌 신뢰할 수 있는 개발 파트너로 만들기 위해, 앞으로도 시스템적인 하네스 구축과 프롬프팅 전략을 꾸준히 개선해야겠다.