인디 게임 개발팀 Burn Rate 추적: 외주 비용을 줄이는 AI 어드바이저 설계법
인디 게임팀의 월별 Burn Rate와 현금 runway를 계산하고 외주 비용을 우선순위·리스크·일정 기준으로 최적화하는 AI 어드바이저 설계 방법을 정리합니다.
핵심 요약
인디 게임팀의 Burn Rate는 한 달 동안 실제로 소진되는 현금의 속도이며 인건비·외주비·툴 구독료·마케팅비를 같은 기준으로 기록해야 정확하게 추적할 수 있습니다. AI 어드바이저는 회계 수치를 대신 확정하는 도구가 아니라 Burn Rate와 runway를 계산하고 외주 항목의 일정 기여도·대체 가능성·재작업 위험을 비교해 의사결정을 돕는 보조 시스템으로 설계해야 합니다.
인디 게임 개발팀에서 Burn Rate가 중요한 이유
게임 프로젝트의 예산은 총액만으로 관리하기 어렵습니다. 같은 3,000만 원의 예산이라도 출시까지 12개월 동안 균등하게 사용되는 경우와 초반 3개월에 집중되는 경우의 위험은 전혀 다릅니다.
Burn Rate를 추적하면 다음 질문에 답할 수 있습니다.
- 현재 속도로 지출하면 몇 개월 뒤 현금이 부족해지는가?
- 다음 마일스톤까지 반드시 필요한 비용은 무엇인가?
- 외주 작업 중 연기하거나 내부화할 수 있는 항목은 무엇인가?
- 예산 초과의 원인이 단가 상승인지 재작업인지 범위 변경인지?
Burn Rate와 Runway의 기본 수식
월 총 Burn Rate는 해당 월의 현금 유출을 합산해 계산합니다.
투자금이나 매출처럼 같은 달에 유입되는 현금을 반영하면 순 Burn Rate가 됩니다.
현재 보유 현금을 순 Burn Rate로 나누면 단순 runway를 구할 수 있습니다.
평균값만 사용하면 최근 외주 계약이나 출시 직전 마케팅비 증가를 놓칠 수 있습니다. 따라서 최근 3개월 평균과 향후 3개월의 계획 Burn Rate를 함께 보고하는 편이 안전합니다.
어떤 비용을 Burn Rate에 포함해야 하는가?
비용 항목을 지나치게 세분화하면 기록 부담이 커지고 너무 단순화하면 의사결정에 필요한 원인을 찾기 어렵습니다. 인디 팀에서는 아래 정도의 분류가 실용적입니다.
| 비용 그룹 | 포함 항목 | 관리 기준 |
|---|---|---|
| 인건비 | 급여, 계약직 보수, 4대 보험 및 관련 비용 | 고정비로 보고 인원 계획과 연결 |
| 외주비 | 아트, 애니메이션, 사운드, QA, 번역, 포팅 | 작업 단위·납기·검수 상태 기록 |
| 툴 및 인프라 | Unity 또는 Unreal 관련 서비스, 저장소, 빌드 서버, 협업 도구 | 사용자 수와 사용량 점검 |
| 운영비 | 법무, 회계, 장비, 사무실, 결제 수수료 | 월별 반복비와 일회성 비용 분리 |
| 마케팅비 | 광고, 행사, 인플루언서, 트레일러 제작 | 출시 단계와 캠페인 목표 연결 |
환불 가능한 보증금이나 아직 지급하지 않은 견적서는 현금 Burn Rate에 바로 포함하지 않습니다. 대신 확정 예정 비용과 실제 현금 유출을 별도 필드로 관리해야 합니다.
Burn Rate 추적 데이터는 어떻게 설계할까?
AI가 유용한 조언을 하려면 먼저 데이터의 의미가 일관되어야 합니다. Google Sheets로 시작하더라도 나중에 PostgreSQL 16으로 이전할 수 있도록 다음 필드를 고정하는 것이 좋습니다.
| 필드 | 예시 | 설명 |
|---|---|---|
cost_id | C-2026-0042 | 비용 고유 식별자 |
month | 2026-08 | 현금이 실제로 나간 월 |
category | outsourcing_art | 비용 그룹 |
vendor | Studio A | 외주 업체 또는 개인 |
milestone | vertical_slice | 연결된 마일스톤 |
planned_amount | 1800000 | 승인된 계획 금액 |
actual_amount | 2200000 | 실제 지급 금액 |
progress_percent | 65 | 검수 가능한 진척도 |
rework_hours | 18 | 재작업에 투입된 시간 |
status | in_review | 계약·진행·검수 상태 |
risk_level | medium | 납기와 품질 위험도 |
핵심은 견적 금액과 실제 지급액을 구분하는 것입니다. 또한 progress_percent는 외주 업체가 보고한 진행률이 아니라 팀이 검수한 산출물 기준으로 입력해야 합니다.
외주 비용 최적화는 어떻게 판단할까?
외주를 단순히 가장 싼 업체로 바꾸는 방식은 자주 실패합니다. 단가가 낮아도 수정 횟수가 많거나 통합 작업이 복잡하면 총비용이 더 커질 수 있기 때문입니다.
외주 항목마다 다음 네 가지 점수를 기록하면 비교가 쉬워집니다.
| 평가 요소 | 질문 | 권장 점수 범위 |
|---|---|---|
| 일정 기여도 | 다음 마일스톤을 얼마나 앞당기는가? | 0~5 |
| 대체 가능성 | 내부 처리·에셋 구매·범위 축소가 가능한가? | 0~5 |
| 재작업 위험 | 요구사항 불명확성과 검수 비용이 큰가? | 0~5 |
| 현금 압박 | 지금 지급하지 않으면 runway에 영향이 큰가? | 0~5 |
우선순위 점수는 팀의 상황에 맞게 가중치를 적용할 수 있습니다.
여기서 는 일정 기여도, 은 재작업 위험, 는 현금 압박, 는 대체 가능성입니다. 재작업 위험이 높을수록 점수가 올라가도록 정의했지만 실제 계약 승인 기준에서는 위험을 줄이는 조건도 함께 제시해야 합니다.
예를 들어 다음과 같이 해석할 수 있습니다.
- 점수 3.5 이상: 외주를 유지하되 마일스톤별 검수 조건을 강화한다.
- 점수 2.0~3.4: 범위를 줄이거나 부분 외주로 전환한다.
- 점수 2.0 미만: 연기·내부화·에셋 구매를 우선 검토한다.
AI 어드바이저는 어떤 구조로 구현할까?
권장 구조는 정형 데이터 계산 → 규칙 기반 경고 → LLM 설명과 선택지 생성의 3단계입니다. Python 3.12와 FastAPI로 계산 API를 만들고 PostgreSQL 16에 비용 데이터를 저장할 수 있습니다. LLM에는 원본 영수증 전체보다 집계된 지표와 근거 행을 전달하는 편이 안전합니다.
1단계: 계산 레이어
계산 레이어는 일반 코드로 구현합니다. Burn Rate, runway, 예산 편차, 외주별 단가와 재작업률은 LLM이 추정하지 않도록 해야 합니다.
monthly_burn = actual_cash_outflow - actual_cash_inflow
runway_months = available_cash / monthly_burn if monthly_burn > 0 else None
budget_variance = actual_amount - planned_amount
rework_rate = rework_hours / max(approved_hours, 1)실제 서비스에서는 통화 단위, 부가세 포함 여부, 지급 예정일과 지급 완료일을 명시해야 합니다. 월 순현금 유출이 0 이하이면 유한한 runway 개월 수를 계산할 수 없으므로 None과 흑자·손익분기 상태를 별도로 표시합니다.
2단계: 규칙 기반 경고
규칙은 반복 가능한 운영 기준을 담당합니다.
IF runway_months < 6
THEN alert = cash_runway_warning
IF actual_amount > planned_amount * 1.15
THEN alert = outsourcing_overrun
IF progress_percent < 70 AND milestone_due_days < 14
THEN alert = delivery_risk
IF rework_rate > 0.20
THEN alert = specification_or_quality_review이처럼 임계값을 코드와 문서에 고정하면 팀원이 바뀌어도 경고 기준이 흔들리지 않습니다. 임계값은 팀 규모와 투자 일정에 맞게 조정하고 변경 이력을 남겨야 합니다.
3단계: AI 설명 레이어
LLM의 역할은 경고의 원인을 요약하고 선택지를 비교하는 것입니다. 예를 들어 다음 형식의 입력을 사용할 수 있습니다.
{
"project": "Project Aurora",
"cash_available": 42000000,
"net_burn_rate_3m": 6800000,
"runway_months": 6.2,
"outsourcing_alerts": [
{
"vendor": "Studio A",
"planned_amount": 1800000,
"actual_amount": 2200000,
"progress_percent": 65,
"rework_rate": 0.23,
"milestone_due_days": 12
}
]
}출력은 막연한 조언보다 다음과 같은 형식이 좋습니다.
- 가장 큰 비용 원인
- 다음 30일 안에 실행할 조치
- 일정에 미치는 영향
- 절감 예상액의 계산 근거
- 추가로 확인해야 할 데이터
AI가 “외주를 줄이세요”라고만 답하면 운영에 도움이 되지 않습니다. “애니메이션 12종 중 4종을 다음 마일스톤 이후로 이동하면 이번 달 지급액을 약 70만 원 줄일 수 있지만 데모 영상의 장면 2개를 교체해야 한다”처럼 범위와 영향을 함께 제시해야 합니다.
외주 비용 최적화 절차를 3단계로 정리하면?
Step 1. 계약을 산출물 단위로 쪼갠다
“캐릭터 작업 일괄”보다 “캐릭터 3종의 표정 8개와 Unity 임포트 파일”처럼 검수 가능한 단위로 계약합니다. 산출물 단위가 명확해야 진행률과 재작업 비용을 비교할 수 있습니다.
Step 2. 마일스톤 지급 조건을 연결한다
선금·중도금·잔금을 날짜가 아니라 검수 기준에 연결합니다. 예를 들어 최종 파일 전달만으로 잔금을 지급하지 않고 엔진 내 임포트·네이밍 규칙·성능 테스트까지 통과해야 지급되도록 정의합니다.
Step 3. 매주 비용 대비 일정 효과를 재평가한다
주간 회의에서 외주별로 “이번 주 지급액”, “완료된 산출물”, “다음 마일스톤 기여도”, “남은 재작업”을 함께 봅니다. 일정 효과가 사라진 외주를 관성적으로 유지하지 않는 것이 핵심입니다.
AI 어드바이저 도입 시 지켜야 할 운영 원칙
| 원칙 | 적용 방법 |
|---|---|
| 계산과 생성 분리 | 금액·비율·날짜는 코드가 계산하고 AI는 설명한다 |
| 근거 표시 | 모든 절감 제안에 원본 비용 행과 계산식을 연결한다 |
| 승인권 유지 | 계약 변경과 지급 중단은 담당자가 최종 승인한다 |
| 개인정보 최소화 | 개인 계좌·주민번호·민감한 계약 정보는 모델 입력에서 제거한다 |
| 예측 불확실성 표시 | 계획 Burn Rate에는 낙관·기준·비관 시나리오를 함께 표시한다 |
특히 외주 업체 평가를 자동화할 때는 단일 점수로 계약 해지나 지급 보류를 결정하지 않아야 합니다. 납기 지연의 원인이 업체가 아니라 팀의 요구사항 변경일 수도 있기 때문입니다.
자주 묻는 질문(FAQ)
Burn Rate는 회계상 비용과 같은가?
항상 같지는 않습니다. Burn Rate는 보통 실제 현금 유출 속도를 의미하므로 감가상각이나 아직 지급하지 않은 청구액과 다를 수 있습니다. 프로젝트 관리용 지표와 회계 보고용 지표를 분리하세요.
외주비를 줄이면 무조건 runway가 늘어나는가?
아닙니다. 작업을 내부 팀이 맡아 추가 인건비와 일정 지연이 발생하면 순절감액이 작아질 수 있습니다. 외주비 절감액에서 내부 대체 비용과 지연으로 인한 기회비용을 함께 빼야 합니다.
LLM이 비용 절감액을 직접 계산해도 되는가?
권장하지 않습니다. 비용 절감액과 runway는 PostgreSQL 쿼리나 Python 계산 코드처럼 재현 가능한 방식으로 산출하고 LLM은 계산 결과를 요약하거나 시나리오를 설명하는 역할에 한정하는 편이 안전합니다.
정리
인디 게임팀의 예산 관리는 총예산을 지키는 문제가 아니라 현금이 소진되는 속도와 다음 마일스톤의 생존 가능성을 함께 관리하는 문제입니다. 월별 Burn Rate와 runway를 일관된 데이터 구조로 기록하고 외주 작업을 산출물·검수·일정 기여도 기준으로 평가하면 비용 최적화의 근거가 생깁니다.
AI 어드바이저는 이 데이터를 바탕으로 이상 징후를 빠르게 찾고 여러 선택지의 영향을 설명할 수 있습니다. 다만 금액 계산과 계약 승인까지 AI에 맡기기보다 계산 레이어와 사람의 승인 절차를 분리해야 신뢰할 수 있는 팀 운영 도구가 됩니다.
