AIdeazz에 처음 게시되었습니다 — 정식 링크와 함께 이곳에 교차 게시되었습니다.

파나마 부동산 고객을 위한 Telegram 봇인 저의 첫 번째 프로덕션 AI 에이전트는 단순한 쿼리를 Claude 3 Haiku로 라우팅하는 데 18%의 확률로 실패했습니다. 오류 로그에는 LLM 제공업체로부터 429 Too Many Requests가 표시되었지만, 저의 속도 제한(rate limits)은 한계치에 전혀 도달하지 않은 상태였습니다. 저는 3일 동안 커스텀 재시도 로직(retry logic)을 디버깅하며 시간을 보냈고, 결국 문제는 에이전트 오케스트레이션 레이어(agent orchestration layer)에서 max_concurrent_requests 파라미터가 5가 아닌 1로 잘못 설정되었다는 것을 발견했습니다. 이것은 코딩 실수가 아니라 시스템 설계(systems design)상의 간과였습니다. 부CEO(Deputy CEO) 시절이었다면 누군가를 해고했을 법한 실수였습니다. 하지만 이제는 저뿐이었습니다.

저는 러시아에서 15년 동안 기업의 사다리를 올라갔고, 국가 디지털 인프라 프로그램의 부CEO로서 정점에 도달했습니다. 우리는 1억 달러가 넘는 예산을 관리하고, 수백 명의 팀을 감독하며, 복잡한 정치적 상황을 헤쳐 나갔습니다. 그러다 저는 AIdeazz를 구축하기 위해 벤처 캐피털(VC) 투자 하나 없이, 미혼모로서 파나마로 이주했습니다. 경영진에서 1인 AI 개발자로의 전환은 새로운 기술적 기술을 배우는 것보다 오래된 습관을 버리는 것에 더 가까웠습니다. 어떤 경영적 "지혜"는 쓸모없는 짐이었고, 다른 부분들은 놀라울 정도로 강력했습니다.

쓸모없는 경영적 잔재: 절차를 위한 절차

부CEO로서 저는 간트 차트(Gantt charts), 분기별 검토, 상세한 프로젝트 계획에 따라 움직였습니다. 모든 이니셔티브에는 운영 위원회(steering committee), 리스크 레지스터(risk register), 그리고 50페이지 분량의 비즈니스 케이스가 있었습니다. 이는 수백 명의 사람과 수백만 달러의 공적 자금을 관리하는 데 필수적이었습니다.

AIdeazz를 시작했을 때, 저는 이를 복제하려고 시도했습니다. 저는 첫 번째 멀티 에이전트 시스템(multi-agent system)을 위해 단계, 의존성, 가설적 KPI를 개략적으로 설명하는 "전략적 로드맵(strategic roadmap)"을 작성하는 데 일주일을 보냈습니다. 심지어 단 하나의 Telegram 봇을 위해 "리스크 매트릭스(risk matrix)"까지 만들었습니다. 결과는 어땠을까요? 배포된 코드 한 줄도 없었습니다. 로드맵은 이론적인 계획이라는 스스로 만든 감옥이 되어버렸습니다.

혼자서 AI 에이전트 (AI agents)를 구축하는 현실은 피드백 루프 (feedback loop)가 분기(quarter) 단위가 아닌 시간 단위로 측정된다는 점입니다. 새로운 Groq 모델이 출시되거나, Claude 3 Opus 업데이트로 API 동작이 바뀌거나, 혹은 고객이 Telegram 대신 WhatsApp 연동을 요청하기도 합니다. 저의 "전략적 로드맵"은 잉크가 마르기도 전에 쓸모없게 되었습니다. 저는 이틀 정도의 계획 수립 범위 (planning horizon)를 받아들이는 법을 배웠습니다. 이제 저의 "프로젝트 계획"은 "오늘 할 일 (To Do Today)", "진행 중 (Doing)", "완료 (Done)"라는 세 개의 컬럼을 가진 Trello 보드입니다. 만약 어떤 작업이 4시간 이상 걸린다면, 그것은 더 작게 분해됩니다. 필요에 의해 탄생한 이러한 민첩성 (agility)은 그 어떤 기업 구조도 복제할 수 없는 것입니다. 1인 운영 체제에서 "프로세스 (process)"라는 오버헤드 (overhead)는 제품 출시 (shipping)에 대한 직접적인 세금과 같습니다.

예상치 못하게 유용했던 경영 기술: 예산 편성 및 벤더 관리 (Vendor Management)

규모는 극적으로 다르지만 직접적으로 전이된 기술 중 하나는 예산 편성 (budgeting)이었습니다. 부CEO로서 저는 수백만 달러 규모의 예산을 관리했습니다. 지금은 한 달에 몇 백 달러를 관리합니다. 하지만 원칙은 동일합니다. 무자비한 최적화 (optimization)와 단위 경제성 (unit economics)에 대한 이해입니다.

AIdeazz를 위한 저의 Oracle Cloud Infrastructure (OCI) 청구서는 저의 주요 인프라 비용입니다. 저는 상태 비저장 에이전트 (stateless agents)를 위한 OCI Container Instances, 이벤트 기반 작업 (event-driven tasks)을 위한 OCI Functions, 그리고 지속성 저장소 (persistent storage)를 위한 소규모 OCI Autonomous Database를 혼합하여 사용합니다. 저의 목표는 이를 월 100달러 미만으로 유지하는 것입니다. 이를 위해서는 끊임없는 경계가 필요합니다. 예를 들어, 처음에는 장시간 실행되는 에이전트를 위해 범용 VM (general-purpose VM)을 사용했는데, 이로 인해 월 35달러가 소요되었습니다. 이를 유휴 상태일 때 0으로 스케일링 (scale to zero)되는 Container Instance로 리팩터링 (refactoring)함으로써 비용을 월 8달러로 줄였습니다. 이것은 단순한 "비용 절감"이 아니라 "생존"의 문제입니다. 인프라에서 절약된 모든 1달러는 고객으로부터 벌어들여야 할 1달러를 줄여줍니다.

벤더 관리 (Vendor management) 역량 또한 그대로 적용되었습니다. 임원으로서 저는 글로벌 기술 거대 기업들과 다년 계약을 협상했습니다. 이제 저는 API 제공업체들과 협상합니다. 저의 LLM 라우팅 (routing) 전략은 바로 이 경험의 직접적인 결과물입니다. 저는 단일 제공업체에 종속되지 않습니다. Groq, Claude, OpenAI의 지연 시간 (latency)과 비용을 확인하는 커스텀 라우터를 사용합니다. 만약 특정 작업(예: 간단한 요약)에서 Groq의 Llama 3 8B가 Claude 3 Haiku보다 3배 저렴하고 5배 빠르다면, 저의 라우터는 해당 작업을 그곳으로 보냅니다. 복잡한 추론 (reasoning)을 위해 Claude 3 Opus가 필요하다면, Claude로 보냅니다. 이것은 단순히 기술적인 우아함에 관한 문제가 아닙니다. 변동 비용 (variable costs)을 최소화하는 것에 관한 문제입니다. LLM 토큰 비용의 10% 절감은 소규모 고객 프로젝트에서 이익과 손실을 가르는 차이가 될 수 있습니다. 이러한 동적 라우팅 (dynamic routing)을 구현함으로써, 현재 모든 LLM 호출에 걸친 평균 토큰 비용은 초기 $0.0000015에서 토큰당 $0.0000008로 낮아졌습니다.

가장 힘든 피벗: 위임에서 딥 워크 (Deep Work)로

가장 큰 정신적 변화는 위임 (delegation)에서 딥 워크 (deep work)로 전환하는 것이었습니다. 임원으로서 저의 역할은 '무엇(what)'을 정의하고 팀이 '어떻게(how)' 할지를 결정하게 하는 것이었습니다. 저는 코드를 만지거나, 서버를 설정하거나, 운영 환경의 문제를 직접 디버깅하는 일이 거의 없었습니다. 저의 가치는 전략적 방향 설정, 자원 배분, 그리고 거시적 수준에서의 문제 해결에 있었습니다.

이제 저는 '어떻게(how)' 그 자체입니다. 저는 멀티 에이전트 시스템 (multi-agent systems)을 위한 Python 코드를 직접 작성합니다. OCI 네트워킹 규칙을 설정합니다. 에이전트의 상태 관리 (state management)에서 발생하는 KeyError를 디버깅합니다. 이는 제 뇌의 회로를 완전히 재구성해야 하는 작업이었습니다. 초기 좌절감은 엄청났습니다. 예전 팀의 주니어 개발자라면 몇 분 만에 해결했을 버그에 몇 시간을 허비하곤 했습니다. 제 자존심은 큰 타격을 입었습니다.

하지만 이러한 딥 워크 (Deep Work)는 예상치 못한 이점을 제공합니다. 바로 시스템에 대한 독보적인 이해도입니다. 고객이 새로운 기능을 요청할 때, 저는 API 호출부터 데이터베이스 스키마 (Database Schema) 변경 사항에 이르기까지 이를 구현하는 데 정확히 무엇이 필요한지 알고 있습니다. "팀에 확인해 보겠습니다"라는 말은 필요 없습니다. 기술적 현실과의 이러한 직접적인 연결은 더 빠른 반복 (Iteration)과 더 현실적인 약속을 가능하게 합니다. 또한 이는 제가 최신 상태를 유지하도록 강제합니다. 저는 매일 아침 2~3시간을 문서 (Documentation)를 읽고, 새로운 모델을 실험하며, 오픈 소스 (Open-source) 프로젝트를 검토하는 데 보냅니다. 이러한 지속적인 학습은 타협할 수 없는 부분입니다.

내가 격차를 숨기기를 그만둔 이유: "비전통적"인 강점

오랫동안 저는 경영진으로서의 과거를 과소평가했습니다. 개발자 직무에 지원하거나 AIdeazz를 피칭할 때, 저는 독학한 코딩 기술, AI 자격증, 그리고 현재 진행 중인 프로젝트에만 집중했습니다. 부CEO (Deputy CEO)라는 직함이 "너무 시니어다", "현실 감각이 없다", 또는 "진정한 개발자가 아니다"라는 신호를 주는 부채라고 느꼈기 때문입니다.

그러다 저는 정직해지기 시작했습니다. LinkedIn과 피칭 자료에 제 전체 경력 이력을 기재했습니다. 대규모 디지털 인프라 프로그램을 관리하던 역할에서 작고 집중된 AI 에이전트 (AI Agents)를 구축하는 역할로의 전환 (Pivot)을 설명했습니다. 반응은 놀라웠습니다. 회의적인 시선 대신, 저는 호기심을 발견했습니다.

저의 "비전통적인" 배경은 자산이 되었습니다. 고객들은 제가 단순히 기술적 실현 가능성을 넘어 비즈니스 제약 사항을 이해한다는 점을 높게 평가했습니다. 고객 지원 자동화를 위한 멀티 에이전트 시스템 (multi-agent system)을 논의할 때, 저는 단순히 정확도 지표 (accuracy metrics)뿐만 아니라 운영 비용에 미칠 잠재적 영향에 대해서도 이야기할 수 있었습니다. 고객의 AI 인프라를 위해 OCI를 사용할 것을 제안했을 때, 저는 개발자의 관점이 아닌 기업적 관점에서 보안 및 확장성 (scalability)의 이점을 명확히 설명할 수 있었습니다. 경영진 역할로 수년간 다듬어온 비즈니스 전략과 기술적 구현 사이의 간극을 메우는 능력은 이제 저만의 고유한 판매 제안 (unique selling proposition)입니다. 이것이 제가 벤처 캐피털 (VC) 투자 없이도 Oracle Cloud 상에서 프로덕션용 AI 에이전트를 출시할 수 있는 이유입니다. 저는 예산 항목부터 API 엔드포인트 (API endpoint)에 이르기까지 전체 라이프사이클을 이해하고 있습니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: 경영진에서 AI 개발자로 전환하며 겪은 가장 큰 기술적 도전은 무엇이었나요?
A: 가장 가파른 학습 곡선은 비동기 프로그래밍 패러다임 (asynchronous programming paradigms)과 분산 시스템 설계 (distributed systems design), 특히 멀티 에이전트 오케스트레이션 (multi-agent orchestration)을 마스터하는 것이었습니다. 초기에는 여러 LLM 호출과 외부 API 사이의 레이스 컨디션 (race conditions)을 디버깅하는 것이 끊임없는 싸움이었습니다.

Q: 전담 DevOps 팀 없이 Oracle Cloud Infrastructure 비용을 어떻게 그렇게 효과적으로 관리하나요?
A: 사용하지 않을 때 0으로 스케일링되는 OCI Container Instances 및 OCI Functions와 같은 서버리스 (serverless) 구성 요소를 광범위하게 활용합니다. 또한 OCI Monitoring 및 Alarms를 사용하여 리소스 소비를 추적하고, 컴퓨팅 인스턴스의 적정 규모 산정 (rightsizing)과 같은 비용 절감 기회를 식별합니다.

Q: 비용과 성능 최적화를 위한 주요 LLM 라우팅 (routing) 전략은 무엇인가요?
A: 프롬프트의 복잡성, 요구되는 지연 시간 (latency), 현재 토큰 비용에 따라 요청을 동적으로 라우팅하는 맞춤형 Python 애플리케이션을 사용합니다. 단순한 요약 작업은 주로 Groq의 Llama 3 8B로 보내고, 복잡한 추론 작업은 Claude 3 Opus로 전달하며, 폴백 (fallback) 및 재시도 (retry) 로직이 내장되어 있습니다.

Q: 경영진으로서의 리더십 기술 중 1인 개발에 직접적으로 적용할 수 있었던 구체적인 기술이 있었나요?

A: 프로젝트 우선순위 설정 (Project prioritization) 및 리스크 관리 (Risk management)가, 비록 마이크로 규모이긴 했지만 매우 귀중했습니다. 어떤 기능을 먼저 구축할지 결정하고, 시스템의 잠재적인 실패 지점 (failure points)을 이해하는 능력은 작동하는 소프트웨어를 빠르게 출시 (ship)하는 능력에 직접적인 영향을 미쳤습니다.

— Elena Revicheva · AIdeazz · Portfolio