API를 붙였다.
처음엔 그게 전부인 줄 알았다. 클로드 API 키 발급받고, 호출 코드 몇 줄 넣고, 실행. 데이터가 나왔다. 꽤 그럴듯했다. 바이브코딩이라는 게 원래 이런 거구나 싶었다.
비용은 얼마나 나오나, 클로드 코드 API 대시보드를 봤다. 짜짠. 으음? 월100달러가 나오네?
월 100달러. 생각보다 빠르게 도달할 지표가
KOSPI 브리핑 서비스를 만들고 있었다. 매일 아침 미국 지수, EWY, VIX, 환율 데이터를 끌어모아서 오늘 장이 오를지 내릴지 예측하는 리포트를 자동으로 생성하는 것. 구조는 단순했다.
문제는 내가 데이터 수집부터 리포트 생성까지 전부 클로드 Sonnet에게 맡겼다는 거다. 뉴스 요약도 클로드, 지표 해석도 클로드, 최종 문장 작성도 클로드. 하루에 두 번이니까 괜찮겠지 싶었는데, 매 호출마다 수천 토큰이 오갔다. 월로 환산하니 대략 100달러.
개인 프로젝트에 매달 13만 원을 낼 생각은 없었다.
제미나이에게 물어봤다 — 이걸 어떻게 줄이냐고
솔직히 말하면, 이 질문을 클로드에게 하기가 약간 멋쩍었다. 그래서 제미나이에게 던졌다. 넌 다를 거야.
돌아온 답이 명쾌했다. “하이브리드 구조로 가세요. 정보 수집과 전처리는 제미나이 Flash, 최종 글쓰기만 클로드에게.”
오호 이런 방법이.
개념은 간단하다. LLM을 하나 쓰는 대신 두 개를 역할에 맞게 나눈다. Gemini 1.5 Flash는 입출력 비용이 클로드 Sonnet의 10분의 1 수준이다. 뉴스 크롤링, 요약, 수치 계산처럼 반복적이고 정형화된 작업은 Flash에게 넘긴다. 클로드는 Flash가 정리해 준 핵심 데이터만 받아서 최종 문장을 쓴다.
결과적으로 클로드에 넘어가는 토큰이 80% 이상 줄었다.
구조를 다시 짰다 — 두 모델이 분업하는 방식
실제로 적용한 흐름은 이렇다.
1단계는 제미나이 Flash가 맡는다. 미국 3대 지수 등락, EWY 흐름, VIX 수치, 공포탐욕지수, 환율 데이터를 수집하고 각각 한두 줄로 요약한다. 뉴스도 제목과 핵심 문장만 추린다. 여기서 나오는 결과물은 300토큰 안팎의 구조화된 텍스트다.
2단계는 클로드가 받는다. 이 요약본만 프롬프트에 넣고 “오늘 KOSPI 브리핑 써줘”라고 시킨다. 클로드는 데이터를 해석하는 대신, 이미 정리된 재료로 문장을 짓는다. 역할이 명확하니 결과도 깔끔하다.
월 비용은 100달러에서 15달러 수준으로 내려왔다.
바이브코딩의 현실 — 만들 수 있다. 그런데 운영 비용이 있다
API를 처음 붙이는 순간은 쉽다. 클로드든 GPT든, 키 발급받고 호출 코드 붙이면 뭔가 돌아가는 것처럼 보인다. 그게 바이브코딩의 매력이기도 하고, 함정이기도 하다.
막상 서비스가 돌아가기 시작하면 운영 비용이 생긴다. 개인 프로젝트라면 월 몇 달러 수준이어야 지속 가능하다. 그러려면 어떤 모델이 어떤 일을 해야 하는지, 토큰을 어디서 아껴야 하는지를 설계 단계에서 생각해야 한다.
기획자로 18년을 지내오면서 배운 게 있다면, 만드는 것보다 유지하는 게 더 어렵다는 것. API도 마찬가지다.
마무리
제미나이가 요약하고, 클로드가 쓴다.
이 구조가 최선인지는 모르겠다. 더 나은 방식이 나올 수도 있고, 몇 달 뒤엔 또 비용 구조가 바뀔 수도 있다. 어차피 이 바닥은 빠르게 움직이니까.
지금 당장 API 비용이 부담스러운 바이브코더라면, 일단 하이브리드 구조부터 고려해보길. 완벽한 설계보다 돌아가는 설계가 먼저다.
아직 돌아가고 있으니, 됐다.