Claude API를 호출하면 결과가 나와요. 종목 분석을 시키면 분석이 나오고, 목업을 넘기면 코드가 나오고. "되네?"의 순간이 연속되다 보면, 비용은 나중에 생각하게 돼요.
주주톡 초기가 그랬어요. 에이전트를 4개로 나눴다가 6개로 늘리고, 병렬로 바꾸고, 토론 시스템을 붙이고. 기능이 하나씩 붙을 때마다 LLM 호출 횟수도 조용히 늘어났어요.
어느 날 종목 하나 분석에 총 몇 번의 호출이 들어가는지 세어봤어요.
에이전트 6개 + 토론 라운드 3회 + Supervisor 종합 = 한 분석당 최소 15번의 LLM 호출
숫자를 보고 나서야 "이거, 기획서에 없는 숫자다"라는 생각이 들었어요.
처음에 6개 에이전트를 순서대로 돌리면 각각 10~15초, 합치면 약 90초가 걸렸어요. 사용자한테 90초 기다리라고 할 수는 없으니 병렬화했고, 그건 15~20초로 줄었어요.
근데 시간만의 문제가 아니었어요. Claude API를 직접 쓴다면, 한 번의 종목 분석에 들어가는 토큰이 얼마인지 계산해봐야 했어요. 에이전트 하나당 입력 3,000~5,000 토큰, 출력 500~1,000 토큰. 6개면 입력만 약 25,000 토큰, 여기에 토론과 Supervisor를 더하면 분석 한 번에 40,000 토큰 이상이에요.
사이드 프로젝트 기준으로 계산하면, 하루 사용자가 50명이고 각자 5번 분석을 돌린다고 가정하면 하루 250회, 총 약 1,000만 토큰. Claude Opus 기준으로 환산하면 하루 수십 달러 규모가 나왔어요.
이때 처음으로 "AI 호출을 설계한다"는 게 뭔지 감이 잡혔어요.
6개 에이전트가 항상 다 필요한 건 아니에요. AAPL 같은 기술주를 분석하는데 원자재 에이전트가 왜 필요해요? 에너지 종목이 아니면 유가 분석은 거의 무의미해요.
그래서 섹터별 가중치 매트릭스를 만들었어요. 12개 섹터 × 6개 에이전트의 가중치를 정의하고, 0.5 미만이면 아예 호출 안 하는 구조로요.
| 섹터 | 차트 | 재무 | 금리 | 뉴스 | 원자재 | 경쟁사 |
|---|---|---|---|---|---|---|
| 기술 | 0.85 | 0.90 | 0.55 | 0.70 | 0.40 | 0.65 |
| 에너지 | 0.80 | 0.75 | 0.85 | 0.65 | 0.95 | 0.60 |
| 금융 | 0.75 | 0.85 | 0.90 | 0.70 | 0.30 | 0.70 |
AAPL을 넣으면 원자재(0.40)와 경쟁사(0.65 → 섹터 기준 따라 다름) 에이전트는 빠져요. 결과적으로 종목에 따라 6개 중 4~5개만 실행돼요.
이 결정의 핵심은 "비용을 줄이려고 품질을 희생한 게 아니다"는 거예요. 오히려 관련 없는 에이전트가 "데이터 부족, 중립" 판정을 내려서 전체 점수를 오히려 왜곡하는 문제를 막았어요.
비용 절감이 분석 품질과 함께 갔을 때, 이 결정이 기획서에 들어갈 수 있는 것이에요.
AED에서 Claude Code 스킬을 두 개 만들었어요. mockup-apply(목업을 기존 코드에 적용)랑 frontend-checkpoint(구현 상태를 스펙과 비교). 둘 다 기존에 없는 거라 직접 만들어야 했어요.
여기서 "직접 만들기 vs 사서 쓰기 vs AI에 맡기기"의 ROI를 따지게 됐어요.
직접 만들기: 스킬 하나 만드는 데 약 1~2일. 유지보수는 내가 다 해야 해요.
사서 쓰기: 해당 기능을 정확히 커버하는 도구가 없었어요. 비슷한 건 있었지만, 우리 워크플로우에 맞으려면 어차피 커스텀이 필요했어요.
AI에 맡기기: 스킬 명세서를 작성하고, Claude Code에 "이 워크플로우대로 돌아가는 slash command를 만들어달라"고 넘겼어요. 약 3~4시간.
결론적으로 AI에 맡겼어요. 근데 중요한 건 그 이후예요. AI가 만든 스킬이 처음부터 제대로 돌아간 건 아니었어요. mockup-apply는 초기 버전에서 기존 기능을 날리는 문제가 있었어요. 이걸 잡는 데 하루가 더 들었고요.
결국 "AI에 맡기기"의 진짜 비용은 프롬프트 작성 시간 + 검증 시간이에요. 프롬프트만 넘기고 끝난다고 생각하면 실제 비용을 과소평가하게 돼요.
지금은 두 스킬 모두 안정적으로 쓰고 있어요. 하지만 "AI에 맡기면 저절로 된다"는 착각이 얼마나 비싼지 이 경험으로 알게 됐어요.
이 경험들이 쌓이면서, 저는 기획서에 AI 관련 항목을 따로 넣기 시작했어요. 세 가지예요.
기능 하나가 추가될 때마다 "이 기능은 호출당 몇 토큰인가?"를 명시해요. 정확한 숫자가 아니어도 돼요. 오더 오브 매그니튜드만 잡아도 충분해요.
이걸 기록해두면 "기능 추가 = 비용 증가"가 눈에 보이는 숫자가 돼요.
모든 작업에 가장 비싼 모델이 필요한 건 아니에요. 주주톡에서는 이렇게 나눴어요.
"언제 비싼 모델을 쓸 것인가"를 기획 단계에서 명시하면, 구현할 때 모델 선택이 임의적이지 않게 돼요.
API 장애, 타임아웃, 예산 초과 시 어떻게 할지를 기획서에 써요. "LLM 호출 실패 시 캐시된 결과 반환", "예산 임계치 도달 시 소형 모델로 자동 전환" 같은 것들이요.
주주톡에서는 Supervisor 에이전트의 셀프리뷰를 데이터 품질 0.4 미만인 경우에만 실행하게 했어요. 항상 실행하는 것 대비 약 60~70%의 Supervisor 추가 호출을 줄였어요. 폴백이 아니라 조건부 실행이지만, 발상은 같아요 — 항상 최선이 아니어도 되는 경우를 명확히 정의하는 것.
"기능 하나 추가"를 이제 "토큰 X원짜리 기능 하나 추가"로 생각하게 됐어요.
이게 단순히 비용 절감 마인드가 아니에요. AI 기능의 규모를 가늠할 수 있는 단위가 생긴 것이에요. 이전에는 "에이전트 하나 더 붙이면 어때요?"라는 질문에 "좋은데요, 해볼게요"라고 답했어요. 지금은 "에이전트 하나 더 붙이면 분석당 8,000토큰 추가예요. 그 품질 향상이 그 비용을 정당화하나요?"라고 물어볼 수 있어요.
기획자가 AI 시스템을 설계할 때, 토큰 단가를 모른다는 건 인건비를 모르고 채용 계획을 세우는 것과 비슷해요.
숫자를 알면 협상할 수 있어요. 아끼거나 쓰거나 바꾸거나. 모르면 그냥 쓰는 거예요.
솔직히, 이 프레임워크도 완벽하지 않아요.
섹터 가중치 매트릭스는 제가 도메인 직관으로 채웠어요. 0.4와 0.5 사이의 컷오프가 최적인지는 충분히 검증하지 못했어요. 다른 섹터 분류 기준을 쓰면 전체가 달라질 수도 있어요.
그리고 "토큰 예산"을 기획서에 넣으면 이걸 실제로 추적하는 인프라가 필요해요. 로깅, 모니터링, 알림. 사이드 프로젝트에서 이걸 다 갖추기는 아직 무거워요.
기획서에 숫자를 넣는 건 시작이에요. 그 숫자가 실제와 얼마나 맞는지 검증하는 루프가 있어야 진짜 관리가 돼요. 그 루프는 아직 만들고 있는 중이에요.