Fable 5 할당량 부족 문제: 5개의 AI 모델로 30개의 프로젝트를 (익사하지 않고) 운영하는 방법
요약
다양한 AI 모델 구독과 로컬 모델을 활용하여 다수의 프로젝트를 효율적으로 관리하는 '라우팅 규율(routing discipline)' 전략을 소개합니다. 특정 모델의 할당량 제한 문제를 해결하기 위해 작업의 복잡도에 따라 모델을 배정하는 운영 노하우를 다룹니다.
핵심 포인트
- 작업의 성격(아키텍처, 분석, 일상 작업 등)에 따른 모델 라우팅 전략 수립
- Fable 5와 같은 고성능 모델의 할당량을 극대화하기 위한 우선순위 관리
- Claude, Gemini, Grok 및 로컬 모델(Ollama)을 혼합한 하이브리드 워크플로우 구축
- 모델 리셋 시간에 맞춘 번다운 일정 수립을 통한 운영 효율화
원문은 aei-digitalsolutions.com/sprintfleet에서 처음 게시되었습니다.
화요일 15:00. 제 프리미엄 AI 할당량이 리셋되는 시간이며, 동시에 제가 이미 할당량을 다 써버렸다는 사실을 깨닫게 되는 시간이기도 합니다. 세 개의 클라이언트 마감 기한이 임박해 있고, App Store 출시를 기다리는 앱이 있으며, 절반만 설정된 연구 실행(research run)이 진행 중인데—가장 무거운 작업을 위해 필요했던 모델은 다음 주까지 사용할 수 없게 된 상황입니다. 사람마다 한계에 부딪히는 날은 다르지만, 저에게는 정확한 타임스탬프가 있습니다. AI 구독을 통해 전문적인 업무를 병행하는 사람이라면 누구나 겪는 패턴은 동일합니다. AI가 부족한 것이 아니라, 최악의 순간에 '적절한' AI가 부족해지며, 그다음에 무엇을 해야 할지에 대한 계획이 없는 것입니다.
저는 공공 행정 분야의 컨설턴트입니다. 서류상으로는 컨설팅 업무를 수행하지만, 실제로는 신뢰할 수 있고 진보된 AI 모델들의 등장으로 인해 31개의 프로젝트를 동시에 운영하고 있습니다. 몇몇 국가의 클라이언트 업무, 개발 중인 세 개의 앱(하나의 앱은 이미 App Store와 Google Play에 출시됨), 트레이딩 모델(trading model), 펀딩 파이프라인, 창의적인 프로젝트, 그리고 건물 리노베이션까지 포함됩니다. 5개의 AI 구독과 로컬 모델(local models)을 실행하는 소규모 Mac 클러스터가 이 모든 것을 관리 가능하게 해줄 것이라 생각했습니다. 하지만 오랫동안 그것들은 단지 상황을 더 복잡하게 만들 뿐이었습니다.
강제적인 사건 (The Forcing Event)
모든 것을 바꾼 것은 묘하게도 이 프로모션 보너스였습니다.
Fable 5가 출시되었을 때, 그것은 저의 통상적인 문제를 뒤집어 놓았습니다. 질문은 더 이상 "어떻게 사용량을 아낄 것인가?"가 아니라, "주간 한도가 0에 도달하기 전에 이 엘리트 티어(elite tier)에서 어떻게 최대의 가치를 추출할 것인가?"가 되었습니다.
Fable 5를 사용할 수 있는 독특하고 제한된 시간의 기회는 거대한 운영 가속기(operational accelerator) 역할을 했습니다. Fable 5가 제공하는—그리고 제가 실시간으로 활발히 경험하고 있는—심층적인 분석 및 과학적 추론 능력(scientific reasoning capabilities)을 제 전체 포트폴리오가 누릴 수 있도록 하기 위해, 저는 대기 중인 프로젝트를 가능한 한 한꺼번에 앞당겨 실행했습니다. 만약 어떤 프로젝트가 올해의 로드맵에 있었다면, 그 주에 바로 시작되었습니다.
그다음 주은 품위 있게 지나가지 않았습니다. 실행(run)을 계속 이어가기 위한 밤샘 작업이 이어졌고, Claude Cowork 앱의 사용량(Usage) 메뉴를 마치 연료 게이지를 살피듯 눈을 떼지 못한 채 퍼센트 바를 지켜보았습니다. 하지만 그 압박 속에서, 그 이후로 제가 매주 사용해 온 무언가가 형태를 갖추게 되었습니다. 바로 라우팅 규율(routing discipline)입니다.
Fable은 오직 Fable만이 처리할 수 있는 작업들—아키텍처 결정, 복잡한 분석, 단 한 번에 완벽해야 하는 산문—을 위해 아껴두었습니다. 그 외의 모든 것은 플릿(fleet)의 다른 모델들로 배정되었습니다. 무거운 빌드에는 Opus를, 일상적인 작업에는 워크호스(workhorse)인 Sonnet을, 긴 문서 연구에는 Gemini를, 실시간 시장 신호에는 Grok을, 앱 보안 감사에는 Grok Build를 사용했습니다. 그리고 기밀 사항이나 밤새 처리할 수 있는 배치(batch) 작업은 저의 로컬 Mac 클러스터(Ollama를 통해 Gemma 및 Llama 실행)에 맡겼습니다. 저는 희소한 모델을 위한 우선순위 목록을 만들었고, 초기화 시간(reset times)에 맞춘 번다운 일정(burn-down schedule)을 수립했으며, 사용량이 0에 도달하는 순간을 대비한 서면 백업 계획을 마련했습니다.
이 중 어느 것도 화이트보드 위에서 설계된 것이 아니었습니다. 그것은 트리아지(triage, 응급 처치/우선순위 분류)였습니다. 하지만 트리아지는 결과적으로 훌륭한 디자이너라는 사실이 밝혀졌습니다.
같은 주에 두 번째 발견이 있었습니다. 바로 Claude Code입니다. 저는 그동안 AI 코딩을 채팅 활동—붙여넣기, 복사, 다시 붙여넣기—으로 취급해 왔습니다. Claude Code는 차원이 다른 존재였습니다. 모델이 코드베이스 내에서 직접 빠르고 정확하게 작업하며, 제가 완전히 다른 일을 하는 동안 긴 자율 빌드(autonomous builds)를 수행하는 에이전트형 하네스(agentic harness)였습니다. 이는 플릿의 정밀 도구가 되었고, 저에게 어떤 모델을 실행하느냐만큼이나 모델이 '어디서' 실행되느냐가 거의 그만큼 중요하다는 것을 가르쳐 주었습니다.
살아남은 두 가지 교훈
프로모션 기간은 계속 연장되고 있지만, 두 가지 구조적 현실은 영구적인 것으로 증명되었습니다.
사용 예산(Usage budgets)은 탱크가 아니라 사이클입니다. 리셋 시점이 다가올 때 프리미엄 할당량(premium allocation) 중 남아 있는 것은 증발해 버립니다. 이월되지 않습니다. 이를 깨닫고 나면 전략은 저절로 세워집니다. 각 리셋부터 다음 리셋까지의 기간을 별도의 예산 사이클로 취급하십시오. 가장 중요한 프리미엄 작업을 초기 사이클에 집중 배치(front-load)하고, 경계선이 오기 전에 남은 예산을 의도적으로 소진하십시오. 이때 아무 작업이나 하는 것이 아니라, 우선순위 목록(shortlist)의 앞부분에 있는 작업부터 처리해야 합니다. 이제 저의 스프린트 계획은 다음과 같이 시작됩니다: "이번 스프린트에는 두 번의 프리미엄 사이클이 있습니다. 사이클 1: 화요일 15:00까지 47%가 남아 있으며 이월되지 않음 — 오늘 이 두 가지 작업을 다음 순서대로 처리할 것."
인간의 승인이 필요한 작업만이 지연되며, 밤샘 작업은 확장 가능하지 않습니다. 계획된 스프린트를 몇 주간 진행한 후, 저는 증거를 확보했습니다. AI 전용 경로(AI lanes)는 안정적으로 완료되었습니다. 쌓이는 것은 저에게 달려 있는 작업들이었습니다: 결정, 검토, 로그인, 전송 버튼 클릭, 서명 등입니다. 그리고 보너스 주간에 제가 내놓았던 영웅적인 해결책—그저 깨어 있는 것—은 일회성 묘기였을 뿐, 시스템이 아니었습니다. 해결책은 구조적이어야 했습니다: 인간을 먼저 일정에 배치하십시오. 매일 정확히 하나의 '별표 표시된 필수 과업(starred must-do)'을 지정하십시오. 이는 전주에 미리 선택된, 반드시 일어나야 하는 단 하나의 일입니다. 읽는 날(Reading days)과 결정하는 날(Decision days)을 분리하십시오. 축적된 자료를 바탕으로 신선한 상태에서 내리는 결정이, 밤 23:40에 흐름 중간에 강제로 내리는 결정보다 훨씬 낫기 때문입니다. 모델은 인간을 중심으로 일정이 잡혀야 하며, 그 반대가 되어서는 안 됩니다.
한 화면으로 보는 방법론
그 결과, 제가 '스프린트플릿 방법론(SprintFleet Method)'이라고 부르는 이중 레이어 시스템이 탄생했습니다.
**포트폴리오 레이어(portfolio layer)**는 마스터 트래커입니다. 프로젝트당 하나의 행을 가진 스프레드시트로 구성되며, 번호, 카테고리, 우선순위, 상태, 그리고 제가 이 시스템에서 가장 중요하다고 생각하는 셀인 '구체적인 다음 단계(concrete Next Step)'를 포함합니다. '다음 단계'가 비어 있는 프로젝트는 정의상 정체된 상태입니다. 복잡한 프로젝트에는 로드맵 시트를 할당하며, 해당 시트의 작업 행에는 'AI 프롬프트(AI Prompt)' 열이 포함됩니다. 이는 컨텍스트(context)가 생생한 계획 단계에서 미리 작성하여 바로 붙여넣을 수 있는 프롬프트로, 몇 달 후에도 인간이든 기계든 향후 어떤 세션에서도 아무런 사전 정보 없이 즉시 작업을 실행할 수 있도록 합니다.
**스프린트 계층 (sprint layer)**은 해당 트래커에서 1주일 단위의 계획을 추출합니다. 라우팅 테이블 (routing table)은 모든 작업을 각각의 레인(lane)에 할당합니다: 프리미엄 쇼트리스트 (premium shortlist), 워크호스 모델 (workhorse model), 연구용 모델 (research model), 야간 배치 (overnight batch), 또는 나 자신. 일일 일정은 인간의 컬럼을 최우선으로 둡니다—하루에 하나의 스타(star)를 배정합니다. 스코어보드 (scoreboard)는 각 프로젝트를 스프린트 목표와 대조하여 추적합니다. 번호가 매겨진 규칙 목록은 위기 상황 중간에 내리고 싶지 않은 결정들을 미리 기록해 둡니다: 상황이 잘못되었을 때의 슬리피지 순서 (slippage order), 건너뛸 수 없는 품질 게이트 (quality gates), 그리고 예산이 조기에 소진될 경우의 성능 저하 경로 (degradation path) 등이 그것입니다. 한 주는 매일 아침 2분간의 체크인과, 현실이 계획대로 흘러가지 않을 때를 대비한 구제 플레이북 (remediation playbook)으로 운영됩니다. 스프린트 종료 보고서는 구독료와 시간이 실제로 어디에 사용되었는지를 보여주며, 주차 사이에 데이터가 유실되지 않도록 트래커와 다시 동기화됩니다.
실제 일주일의 기록
최근의 한 스프린트를 약간의 극적 요소와 익명화를 더해 재구성했습니다: 월요일 15:00, 사용량 화면 확인: 프리미엄 사이클이 두 번 앞서 있고, 첫 번째 사이클의 잔여량이 47% 남음. 그날 오후에는 의도적으로 47%를 소진했습니다—먼저 엔지니어링 문서 (engineering dossier)의 아키텍처 검토를 진행하고, 그다음 연구용 모델을 통한 디자인 검토를 진행했습니다. 화요일의 '스타'는 5분짜리 인간 작업인 '전송 버튼 누르기'였는데, 이는 지난 스프린트에서 두 번이나 밀렸던 작업이었습니다. 주 중반에는 고객사의 긴급 상황으로 인해 이틀간의 오전 시간이 통째로 사라졌습니다. 플레이북은 플레이북 본연의 역할을 수행했습니다: 놓친 '스타'들을 불가능한 목요일 일정으로 쌓아 올리는 대신, 내가 평온했던 월요일에 작성해 둔 슬리피지 순서에 따라 우선순위가 가장 낮은 작업을 즉시 드랍(drop)했습니다. 마감 기한 레인은 보호되었습니다. 토요일은 독서의 날로 정하여 어떤 결정도 내리지 않았습니다. 일요일, 맑은 정신으로 결정을 내리는 데는 20분이 걸렸습니다. 금요일 보고서에 따르면 한 레인이 수요일에 바닥났음을 보여주었습니다. 이는 죄책감이 아닌 증거로서의 데이터이며, 다음 스프린트의 속도 조절에 반영되었습니다.
보고할 가치가 있는 솔직한 실패 사례: 나의 인덱스 파일 (index file)이 마스터 트래커 (master tracker)와 동기화되지 않고 어긋났으며, 이미 점유된 슬롯에 새로운 프로젝트 번호를 매길 뻔했습니다. 내가 규칙을 어겼기 때문에, 이제 이 방법론에는 선언된 단일 진실 공급원 (sources of truth)에 관한 규칙이 포함되어 있습니다.
나는 이것을 Claude의 무료 기술로 만들었다
이 방법은 Claude 스킬 (Claude skill)로 패키징되어 있습니다. 이를 통해 "내 프로젝트를 통제할 수 있게 도와줘" 또는 "내 주간 계획을 세워줘"라고 요청하면 Claude가 지침을 따라 트래커 (tracker), 라우팅 (routing), 예산 주기 (budget cycles), 별표 표시된 날 (starred days), 체크인 (check-ins), 보고서 (reports)를 포함한 전체 시스템을 생성합니다. 이를 구축하면서, 저는 동일한 계획 작업에 대해 도움 없이 수행하는 Claude와 벤치마크 (benchmark)를 실시했습니다. 스킬을 사용했을 때는 21개의 품질 단언 (quality assertions) 중 21개를 모두 충족했지만, 사용하지 않았을 때는 21개 중 16개만 충족했습니다. 누락된 부분은 비용이 많이 드는 치명적인 오류들이었습니다: 번다운 (burn-down) 일정이 역순으로 계획되거나, 성능 저하 경로 (degradation path)가 없거나, 지연 순서 (slippage order)가 없는 등의 문제였습니다.
이것은 무료이며 MIT 라이선스 (MIT-licensed)를 따릅니다. Claude Code 또는 Claude 데스크톱 앱에서 다음과 같이 입력하세요:
/plugin marketplace add aei-soli/claude-skills
소스 및 상세 정보: github.com/aei-soli/claude-skills. 트래커 구축 스크립트, 라이브 대시보드 (live dashboard), 유지 관리되는 모델 계층 맵 (model-tier maps) 등이 포함된 유료 버전이 준비 중이지만, 방법론 자체는 완전히 무료입니다.
단 하나만 기억해야 한다면
한계에 부딪힌 후가 아니라, 계획을 세우기 전에 사용량 화면을 확인하십시오. 그리고 매일 정확히 하나의 별표 표시된 인간의 과업 (starred human task)을 부여하십시오. AI 함대 (fleet)는 진정으로 놀랍습니다. 여러분이 생각하는 것보다 더 많은 일을 해낼 것입니다. 하지만 제독 (admiral)이 충분한 휴식을 취한 상태로 나타나야만 이 시스템은 여러분을 위해 작동합니다.
Adrian Ionescu는 루마니아와 동남유럽에서 활동하는 공공 행정 컨설턴트이며, AEI Digital Solutions에서 AI 지원 도구를 구축합니다. SprintFleet Method는 무료이며 MIT 라이선스를 따르는 Claude 스킬입니다: aei-soli/claude-skills.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기