본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 23. 04:42

부사장 직책에서 솔로 AI 빌더로: 18개월간의 전환이 14만 7천 달러와 3개의 실패한 에이전트를 초래하다

요약

부사장직을 사임하고 솔로 AI 빌더로 전환하며 겪은 멀티 에이전트 시스템 구축의 실전 경험을 다룹니다. 예산 통제, 인프라 비용 관리, 에이전트 배포 과정에서의 시행착오와 기술적 교훈을 공유합니다.

핵심 포인트

  • 엄격한 예산 통제가 멀티 에이전트 운영의 핵심 제약 조건임
  • 에이전트 배포 시 PII 유출 및 과도한 API 호출 비용 주의 필요
  • Groq와 Claude를 활용한 효율적인 라우팅 및 지연 시간 관리
  • 경영 경험보다 정확한 오류 추적과 비용 분석이 기술적 문제 해결에 필수적

자주 묻는 질문

질문: 오라클 클라우드(Oracle Cloud)에서 실제 운영되는 다중 에이전트 시스템을 배포하는 데 가장 잘 적용된 단일 경영 역량은 무엇인가요?
답변: 엄격한 제약 조건 하에서의 예산 통제입니다. 저는 분기별 감사와 함께 4,200만 달러 규모의 러시아 디지털 인프라 프로그램을 운영했습니다. 같은 능력이 현재 오라클 테넌시(Oracle tenancy)를 월 1,800달러로 유지하며, 유휴 에이전트에 현금을 소진하지 않고 Groq와 Claude를 통해 매일 4만 건의 메시지를 라우팅하는 데 사용됩니다. 제가 만나는 대부분의 기술 창업가들은 인프라 지출을 변동 비용으로 취급하지만, 실제로는 이것이 주요 제약 조건입니다.

질문: 비전통적인 배경이 더 이상 약점이 아니게 되기 전에 실제로 몇 개의 운영 에이전트를 배포했나요?
답변: 9개입니다. 처음 세 개는 모두 폐기(write-offs)되었습니다 (하나의 경우 부주의한 Telegram 상태로 PII가 유출되었고, 다른 하나는 적절한 라우팅을 추가하기 전에 Groq 호출에 9천 달러가 소요되었습니다). 네 번째 에이전트는 LatAm 계약자를 위한 WhatsApp 기반 리드 자격 검사기였으며, 마침내 월 3,200달러의 MRR(월 반복 수익)를 창출하여 제가 경력 공백에 대해 사과하는 것을 멈추게 해주었습니다.

질문: 세 개의 에이전트 간의 레이스 컨디션(race conditions)을 디버깅할 때 어떤 경영 경험이 100% 쓸모없었나요?
답변: PowerPoint 숙련도와 교차 기능 조정 위원회입니다. 두 에이전트가 새벽 3시에 공유 메모리에서 데드락에 빠졌을 때, 이전 이해관계자 지도(stakeholder map)는 아무도 신경 쓰지 않습니다. 중요한 것은 정확한 오류 추적(error trace), 실패한 추론당 비용(cost per failed inference), 그리고 한 줄의 수정 사항뿐입니다.

질문: 솔로 AI 빌더에게 경영진에서 개발자로의 간극을 숨기는 것이 실제로 고객 확보를 늦추는 이유는 무엇인가요?
답변: 잠재 고객들은 영업 통화 시작 후 3분 이내에 회피하는 기색을 감지합니다. 제가

질문: 2025년 기준, Groq/Claude 라우팅을 사용하는 Oracle 기반의 솔로 멀티 에이전트 (multi-agent) 설정의 실제 월간 비용(burn)은 얼마인가요?
답변: 에이전트 수를 12개 미만으로 유지하고 400ms 지연 시간 SLO(Service Level Objectives)를 강제한다면 $1,800–$2,400 정도입니다. 그 이상이 된다면 블록 스토리지(block storage)를 과다 할당(over-provisioning)하고 있거나 에이전트가 오픈 루프 추론(open-loop inference)을 수행하도록 방치하고 있는 것입니다. 저는 모든 비용을 공개 스프레드시트에 기록하고 있습니다.

서류상으로는 미친 것처럼 보였던 결정

2023년 4월, 저는 러시아 정부 지원 디지털 인프라 프로그램의 부사장(Deputy CEO)직을 사임했습니다. 12개월 후, 저는 4살 아이와 함께 파나마에 살고 있었고, 통장 잔고는 14만 7천 달러가 줄었으며, 제대로 작동하는 에이전트는 단 하나도 없었습니다. 이 변화는 라이프스타일의 업그레이드가 아니었습니다. 모든 기술적 결정에 세 명의 서명이 필요하고 모든 코드 한 줄이 정치적 리스크를 수반하는 시스템에서 탈출할 수 있는 유일한 방법이었습니다.

목표는 간단했습니다. 중남미(LatAm)의 소상공인들을 위해 실제로 프로덕션(production) 환경에서 작동하는 멀티 에이전트 시스템(multi-agent systems)을 구축하고 판매하는 것이었습니다. 데크(deck)도, 피치 덱(pitch deck)도, VC(벤처 캐피털)도 없었습니다. 오직 Oracle Cloud 크레딧, 속도를 위한 Groq, 추론(reasoning)을 위한 Claude, 그리고 전달 계층(delivery layer)으로서의 Telegram/WhatsApp뿐이었습니다.

개발자와 기술 창업자들은 제 배경을 들으면 보통 똑같은 두 가지 질문을 합니다. 무엇이 전이되었는지, 그리고 무엇이 시간을 낭비했는지에 대해서 말이죠. 다음은 18개월간 제품을 출시하며 얻은 필터링 없는 목록입니다.

실제로 전이된 것: 여전히 중요한 세 가지 경영 근육

첫째, 불완전한 정보 하에서의 리스크 배분(risk allocation)입니다. 국가 디지털 인프라 프로그램을 운영한다는 것은 요구 사항의 절반도 파악되지 않은 상태에서 분기별로 800만~1,200만 달러를 투입해야 함을 의미했습니다. 동일한 패턴이 에이전트 메모리 아키텍처(agent memory architecture)에도 적용됩니다. 저는 완벽한 관측 가능성(observability)을 기다릴 수 없습니다. 저는 비용 절감을 위해 트래픽의 65%를 Groq Llama-3-70B로 라우팅하며, 신뢰도 점수(confidence scores)가 0.72 미만일 때만 Claude-3.5-Sonnet으로 폴백(fallback)합니다. 이 라우팅 로직은 제가 과거 국가 프로젝트 게이트(project gates) 관리에 사용했던 것과 동일한 스프레드시트 형식으로 작성되었습니다. 수학적 원리는 동일합니다. 단위가 루블(rubles)에서 추론 토큰(inference tokens)으로 바뀌었을 뿐입니다.

둘째, 이해관계자 압축 (stakeholder compression)입니다. 경영진은 10개의 상충하는 요구사항을 두 개의 타협 불가능한 제약 조건으로 전환하는 법을 배웁니다. 현재 저의 타협 불가능한 조건은 다음과 같습니다: 월간 총 Oracle 비용(burn) 2,000달러 미만, 그리고 WhatsApp 응답의 95백분위수(95th percentile) 종단 간 지연 시간(end-to-end latency) 900ms 미만입니다. 이 두 가지가 충족될 때까지 그 외의 모든 것들 — 화려한 벡터 저장소 (vector stores), 에이전트 계층 구조 (agent hierarchies), 자율적 계획 (autonomous planning) — 은 협상 가능합니다. 제가 대화하는 대부분의 솔로 AI 빌더들은 여전히 이 두 가지 수치 대신 참신함 (novelty)을 위해 최적화합니다. 그들은 아름답지만 파산한 시스템을 출시합니다.

셋째, 실패 비용 (failure costing)입니다. 정부 프로그램에서는 마일스톤을 놓치면 평판과 향후 예산에 타격을 입습니다. 하지만 현재 저의 환경에서 에이전트 하나가 실패하면, 낭비된 Groq 호출 비용 0.87달러와 4시간의 디버깅 (debugging) 비용이 발생할 뿐입니다. 저는 이제 과거에 국가 핵심 성과 지표 (KPIs)에 적용했던 것과 동일한 엄격함으로 이 두 가지를 추적합니다. 예전에 “연결된 지방 자치 단체의 비율 (%)”을 보여주던 스프레드시트는 이제 “성공적인 대화당 비용”과 “채널별 에이전트 가동 시간 (uptime)”을 보여줍니다. 정서적 거리감은 사람들이 생각하는 것보다 더 가깝습니다.

완전히 쓸모없었던 것들: 빠르게 버려야 했던 기술들

기업형 번역 계층 (translation layers)은 첫날에 사라졌습니다. 파나마의 그 누구도 제가 180명 규모의 매트릭스 조직 (matrix organization)을 조율할 수 있다는 사실에 관심이 없습니다. 새벽 2시에 에이전트가 “컨텍스트 윈도우 초과 (context window exceeded)” 오류를 내뱉을 때, 유일하게 유효한 기술은 정확한 트레이스백 (traceback)을 읽고, max_tokens를 4096에서 8192로 늘리면 요청당 0.0034달러의 추가 비용이 발생한다는 것을 아는 것입니다.

정치적 조율 (political navigation)은 훨씬 더 심각했습니다. 저는 어떤 차관에게 어떤 이메일을 참조(CC)해야 하는지를 배우는 데 수년을 보냈습니다. 유일한 승인권자가 월간 Oracle 청구서뿐인 상황에서 그 기술은 마이너스 가치를 가집니다. 제가 만든 처음 세 개의 에이전트에는 여전히 위원회식 사고방식이 남아 있었습니다: 과하게 설계된 핸드오프 프로토콜 (handoff protocols), “감사 (audit)”를 위한 과도한 로깅 (logging), 그리고 도구 호출 (tool call) 전의 3단계 승인 절차 같은 것들 말입니다. v4 버전에서 이 모든 것이 제거되었습니다.

가장 치명적이었던 것은 핵심적인 기술적 결정을 위임하려는 습관이었습니다. 부사장(Deputy CEO) 시절에는 이를 담당할 직원들이 있었습니다. 하지만 솔로 빌더(solo builder)로서 이제는 제가 곧 직원입니다. 과거에 40명 규모의 기술 팀을 관리하던 방식대로 제 자신의 에이전트 코드베이스(agent codebase)를 "관리"하려고 시도한 순간, 개발 속도(velocity)는 제로로 떨어졌습니다. 저는 스스로 코드를 작성하고, 디버깅(debug)하고, 프로덕션화(productionize)하는 법을 다시 배워야 했습니다. "예전에는 이 일을 감독했었다"와 "문제가 생겼을 때 새벽 3시에도 이것을 출시할 수 있다" 사이의 간극을 메우는 데 9개월의 시간과 6자릿수 달러의 비용이 들었습니다.

피벗(Pivot) 뒤에 숨겨진 정확한 수치들

사직부터 첫 월간 반복 매출(MRR) 1만 달러 달성까지 소진된 총 현금: $147,000. 세부 내역: 파나마에서의 생활비 $61k (미혼모, 사립학교, 사치 없음), 실패한 실험에 사용된 Oracle + Groq + Claude 비용 $49k, 법률 및 이주 비용 $22k, 그리고 대부분 도움이 되지 않았던 강의 및 도구 비용 $15k.

수익을 창출한 첫 번째 에이전트: 콜롬비아 건설 계약업체를 위한 WhatsApp 자격 확인(qualifier) 에이전트. 11일 만에 구축되었으며, 첫 달에 2,400건의 대화를 기록했고, 평균 티켓 가격 $1.37 기준 $3.2k의 매출을 올렸습니다. 이 에이전트는 50GB 블록 볼륨(block volume)을 가진 Oracle Autonomous Database 위에서 3-에이전트 설정(라우터(router) → 자격 확인(qualifier) → 스케줄러(scheduler))을 사용했습니다. 월간 비용은 $184였습니다. 이전의 세 에이전트는 수익 없이 실험 과정에서 각각 $9k, $14k, $6k의 비용이 들었습니다.

현재 스택 (2025년 3월 기준): Oracle Cloud Always Free 티어 및 유료 블록 스토리지(block storage), 추론(inference)의 68%를 담당하는 Groq, 복잡한 추론(complex reasoning)을 위한 Claude-3.5-Sonnet, 40ms 미만으로 결정하는 커스텀 Python 라우터(router). 모든 에이전트는 Telegram 및 WhatsApp Business API를 통해 노출됩니다. 프로덕션 환경의 총 활성 에이전트 수: 7개. 합산 월간 매출: $19,400. 완전히 혼자서 수행.

내가 간극을 숨기는 것을 멈춘 이유

처음 8개월 동안 저는 "정부 디지털 경험을 보유한 AI 빌더"라고 자신을 소개했습니다. 이 문구는 정확했지만 회피적이었습니다. 잠재 고객들은 기업의 냄새를 맡고 제가 비용을 과다 청구하거나, 상황을 지나치게 복잡하게 만들거나, 기술적인 문제가 발생했을 때 사라져 버릴 것이라고 가정했습니다.

제가 실패한 수치들 — 14만 7천 달러의 소진, 3개의 폐기된 에이전트, 첫 매출 발생까지 11개월 — 을 앞세워 대화를 시작하는 순간, 분위기가 바뀌었습니다. 기술적 구매자들은 그 흉터(scar tissue)를 존중합니다. 그들은 에이전트 #2를 죽게 만든 레이스 컨디션(race condition)이 정확히 무엇이었는지, 그리고 에이전트 #3의 메모리 누수(memory leak)를 어떻게 해결했는지 알고 싶어 합니다. 저의 이전 직함은 이제 자격 증명이 아닌, 하나의 맥락(context)이 되었습니다.

이것이 효과를 발휘하는 이유는 제가 실제로 작동하는 시스템을 보여줄 수 있기 때문입니다. 제가 잠든 사이 지난달 187개의 리드(leads)를 분류해낸 Telegram 봇을 고객들이 확인하는 순간, 그 격차는 더 이상 격차가 아니게 됩니다. 임원 출신이라는 배경은 이제 제가 왜 모델 벤치마크(model benchmarks) 대신 유닛 이코노믹스(unit economics)에 집착하는지를 설명해 주는 마케팅 문구가 되었습니다.

비전통적인 경로의 실제 일상 모습

현재의 전형적인 일주일: 에이전트 구축 또는 수정에 18시간, 고객 통화 및 인도에 12시간, Oracle 비용 최적화 및 라우팅 로직(routing logic)에 8시간, 육아에 6시간. 스탠드업 미팅(standups)도, OKR도 없으며, 새벽 4시에 라우터(router)가 고장 나도 비난할 사람이 없습니다.

살아남은 멀티 에이전트(multi-agent) 패턴들은 잔인할 정도로 단순합니다. 각 에이전트는 하나의 도구, 하나의 메모리 저장소(memory store), 그리고 하나의 성공 지표를 가집니다. 핸드오프(handoffs)는 Oracle 상의 공유 PostgreSQL 큐(queue)를 통해 200ms 폴링(polling) 방식으로 이루어집니다. 고객이 추가적인 월 400달러의 추론(inference) 비용을 지불하지 않는 한, LangGraph도, CrewAI도, 자율 루프(autonomous loops)도 사용하지 않습니다.

저는 공격적으로 라우팅합니다. 사용자 메시지가 14가지 의도 패턴(intent patterns) 중 하나와 일치하면, 이를 처리할 수 있는 가장 저렴한 모델로 보냅니다. 대화의 단 19%만이 Claude를 거칩니다. 나머지는 Groq에서 비용의 1/8 수준으로 실행됩니다. 그 라우팅 테이블(routing table)은 제가 가진 가장 가치 있는 결과물입니다. 그것은 연구 논문을 읽어서 만들어진 것이 아닙니다. 2024년 2월에 11,400달러가 사라지는 것을 지켜보며, 다시는 그 실수를 반복하지 않겠다고 결심하며 만들어진 것입니다.

AI 개발로 커리어를 전환하려는 다른 임원들을 위한 구체적인 조언

만약 여러분도 똑같은 변화를 시도하고 있다면, 첫날부터 세 가지 수치를 추적하십시오: 월간 비용 소모량 (monthly burn), 에이전트당 성공적인 대화 수, 그리고 추상화 관리 (managing abstractions) 대비 코드 작성에 소비하는 시간입니다. 만약 마지막 수치가 주간 업무의 30%를 초과한다면, 당신은 여전히 임원처럼 행동하고 있는 것입니다.

이미 비즈니스 볼륨이 확보된 전달 채널 (delivery channel)을 선택하십시오. 라틴 아메리카(LatAm)의 중소기업(SMB) 대상으로는 Telegram과 WhatsApp이 웹 인터페이스보다 전환율 면에서 4배 더 높습니다. 채널을 위해 먼저 구축한 다음, 지능 (intelligence)을 추가하십시오.

이전의 커리어를 절대 숨기지 마십시오. 당신이 잃은 정확한 달러 금액과 그 원인이 된 정확한 실수를 앞세워 말하십시오. 당신이 함께 일하고 싶은 실무자들은 그 어떤 이전 직함보다도 그러한 투명성을 더 존중할 것입니다.

그리고 처음 3~4개의 에이전트는 실패할 것이라는 점을 받아들이십시오. 이를 위해 예산을 책정하십시오. 저의 실패는 순수 추론 비용 (inference spend)으로만 2만 9천 달러를 소모했습니다. 이제 그 수치는 제가 가진 최고의 영업 이야기 (sales story)가 되었습니다.

부사장 (Deputy CEO)에서 솔로 AI 빌더 (solo AI builder)로 가는 길은 화려하지 않습니다. 그것은 값비싼 실수, 심야의 디버깅 (debugging) 세션, 그리고 대부분의 임원 기술이 프로덕션 레이스 컨디션 (production race conditions)과 접촉하는 순간 살아남지 못한다는 사실을 서서히 깨달아가는 과정입니다. 살아남는 기술들 — 제약 조건에 대한 집착 (constraint obsession), 실패 비용 산정 (failure costing), 그리고 무자비한 우선순위 설정 (ruthless prioritization) — 만으로도 실제 비즈니스를 구축하기에는 충분합니다.

그 격차를 부채로 취급하는 것을 멈추는 순간, 그것은 더 이상 부채가 아닙니다.

— Elena Revicheva · AIdeazz · Portfolio

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0