[Claude 활용 24회 — AI에게 일을 위임하는 법] 18/24화: AI 비용 거버넌스 5단계 — 생산성 24% 올라도 예산은 터진다
PR은 24% 늘었는데 다음 분기에 라이선스가 끊겼다
올해 1분기, 우리 팀에 AI 코딩 에이전트 라이선스 20석이 풀렸다. 17회에서 다뤘던 것과 똑같은 상황 — 테스트 커버리지 0%인 결제 모듈에 특성화 테스트를 붙이고, 컨트롤러를 분리하고, 데드 코드를 걷어내는 데 바로 투입했다. 혼자 손으로 하면 2주는 잡아야 할 작업이 에이전트와 함께하니 사흘이면 끝났다. 팀 전체가 같은 경험을 했다.
한 분기가 지나자 숫자가 나왔다. 머지된 PR 수가 전 분기 대비 24% 증가했다. 코드 리뷰 사이클은 평균 이틀에서 반나절로 줄었다. 배포 빈도도 주 2회에서 주 4회로 올랐다. 팀장이 분기 회고에서 “역대 최고 분기”라고 발표했을 때, 나는 속으로 확신했다. ‘이 도구만 있으면 혼자서 팀 하나 분량을 해낼 수 있겠다.’
2분기 첫 주 월요일 아침, 재무팀에서 메일이 왔다. 제목은 짧았다. “개발 조직 AI 도구 비용 항목 확인 요청.” 첨부된 스프레드시트에는 우리 팀만의 비용이 아니라 전사 개발 조직의 AI 에이전트 토큰 비용이 빼곡히 적혀 있었다. 그날 나는 AI 비용 거버넌스라는 단어를 처음 들었다. 그리고 일주일 뒤, 20석 중 17석의 라이선스가 중단됐다.
우리만 그런 게 아니었다. Microsoft Research가 2026년 1월부터 4월까지 수만 명의 개발자를 대상으로 진행한 대규모 연구 결과가 공개됐다. CLI 기반 코딩 에이전트를 사용한 개발자 그룹은 미사용 그룹 대비 머지된 PR이 약 24% 더 많았다. 생산성 향상은 통계적으로도 실재했다. 그런데 같은 보고서에 함께 실린 숫자가 있었다. 에이전트 사용에 따른 토큰 비용이 연간 수백만 달러에 달했고, 극단적인 경우 한 조직에서 월 140만 달러(약 18억 원)가 청구됐다는 것이다. 결국 해당 연구에 참여한 대부분의 조직에서 엔지니어 라이선스가 중단됐다.
생산성이 분명히 올랐는데 도구를 빼앗기는 경험. 이건 기술의 문제가 아니다. 비용을 통제하는 구조를 미리 세우지 않은 거버넌스 실패다. 그리고 이 글을 쓰는 이유는, 이 실패가 예방 가능했기 때문이다.
AI 에이전트 비용이 폭발하는 구조적 이유
채팅과 에이전트는 토큰 소비 구조가 다르다
대부분의 사람은 AI 비용을 “대화”의 연장선에서 생각한다. 프롬프트를 넣고 답변을 받으니까, 대화 한 턴에 드는 비용이 고작 몇 센트 — 그 수준이 계속될 거라고 예상한다. 이건 채팅(chat)의 토큰 소비 패턴이다.
에이전트(agent)는 구조가 근본적으로 다르다. 7회에서 컨텍스트 관리를 다룰 때 잠깐 언급했지만, 에이전트가 하나의 작업을 수행하는 흐름을 뜯어보면 이렇다.
- 탐색: 관련 파일 5~10개를 읽는다. 각 파일의 내용이 입력 토큰으로 잡힌다.
- 분석: 읽은 코드의 구조를 파악하고 변경 계획을 세운다.
- 구현: 파일을 수정한다. 수정 내용이 출력 토큰으로 잡힌다.
- 검증: 테스트를 실행한다. 테스트 결과(성공이든 실패든)가 다시 입력 토큰으로 돌아온다.
- 수정: 실패한 테스트를 보고 코드를 고친다. 이전 컨텍스트 전체가 다시 입력에 실린다.
- 재검증: 테스트를 다시 돌린다.
- 반복: 3~6을 성공할 때까지 반복한다.
핵심은 반복 루프에 있다. 매번 루프를 돌 때마다 이전까지의 컨텍스트 전체가 입력 토큰에 누적된다. 첫 번째 루프에서 5만 토큰이 들었다면, 두 번째는 8만, 세 번째는 12만 — 이런 식으로 한 작업 안에서 토큰 소비가 계단식으로 증가한다.
단순 비교로 보면 이렇다.
| 활동 | 평균 토큰 소비 | 추정 비용 (API 기준) |
|---|---|---|
| 단순 질문 (채팅 1턴) | ~2,000 | $0.01~0.02 |
| 코드 설명 요청 | ~8,000 | $0.05~0.10 |
| 단일 버그 수정 (에이전트) | ~80,000 | $0.50~1.00 |
| 모듈 리팩터링 (에이전트) | ~250,000 | $2.00~4.00 |
| 대규모 기능 구현 (에이전트) | 500,000+ | $5.00+ |
채팅 한 턴에 $0.02인 비용 감각으로 에이전트를 쓰면, “이 정도 쓸 줄은 몰랐다”는 청구서를 만나게 된다. 에이전트 한 번 돌리면 채팅 수십~수백 턴에 맞먹는 토큰을 쓴다. 이걸 하루에 10번씩, 20명이 한 분기 동안 반복한 결과가 재무팀 메일이었다.
비용 분포의 극단성 — 상위 1%가 전체의 절반을 태운다
Microsoft Research 연구에서 드러난 또 하나의 사실은 비용 분포의 극단적 편향이다. 에이전트 비용은 정규분포를 따르지 않는다. 멱법칙(power law)에 가깝다. 전체 개발자 중 상위 10%가 전체 토큰 비용의 약 70%를 소비하고, 상위 1%가 절반 가까이를 차지한다는 보고가 있었다.
이 패턴은 내가 우리 팀에서 관찰한 것과 정확히 일치했다. 20명 중 에이전트를 ‘정말 잘’ 쓴 3명 — 나를 포함해서 — 이 전체 팀 비용의 60% 이상을 차지했다. 에이전트를 가장 적극적으로 활용한 사람이 가장 생산적이었지만, 동시에 가장 많은 비용을 만들어냈다.
극단 사례는 더 충격적이다. 연구에서 보고된 월 140만 달러라는 수치는 한 명이 아니라 수백 명 규모의 개발 조직 전체 비용이었지만, 그 조직 내에서도 비용의 대부분은 소수의 파워 유저가 만들었다. 이 파워 유저들은 에이전트를 밤새 돌려두거나, 11회에서 다뤘던 서브에이전트를 3단계로 중첩해서 탐색자-구현자-검증자 구조로 병렬 작업을 시키는 패턴을 자주 썼다. 에이전트 수가 곧 비용이라고 경고했었는데, 그게 팀 단위로 증폭되니 재무팀이 경악할 만한 숫자가 된 것이다.
여기서 잔인한 역설이 등장한다. 도구를 가장 잘 쓰는 사람이 가장 먼저 라이선스를 잃는다. 비용 상한 없이 “많이 쓰는 순서”로 자르면, 조직에서 가장 생산적인 사람부터 도구를 빼앗기게 된다. 이게 거버넌스 없는 도입의 결말이다.
AI 비용 거버넌스 5단계 실전 셋업
라이선스를 잃고 나서야 움직이기 시작했다. 남은 3석으로 한 분기를 버티면서 내가 한 일은, 다음에 다시 라이선스를 받았을 때 같은 이유로 잃지 않을 구조를 만드는 것이었다. 실제로 다음 분기에 10석을 다시 확보했고, 이 구조 덕분에 지금까지 유지되고 있다.
1단계 — 사용량 귀속 추적
비용을 통제하려면 먼저 누가, 언제, 무엇에, 얼마나 썼는지 알아야 한다. Claude Code는 각 세션의 토큰 사용량을 .claude/attribution.json에 기록한다. 이 파일의 구조를 이해하는 것이 1단계다.
{
"version": "1.0",
"sessions": [
{
"session_id": "sess_a7k2m9x",
"started_at": "2026-08-19T09:12:00Z",
"ended_at": "2026-08-19T09:47:00Z",
"model": "opus",
"tokens_input": 185200,
"tokens_output": 42300,
"estimated_cost_usd": 2.12,
"working_directory": "/project/payment-module",
"task_summary": "결제 모듈 특성화 테스트 추가"
},
{
"session_id": "sess_b3n5p1q",
"started_at": "2026-08-19T10:05:00Z",
"ended_at": "2026-08-19T11:32:00Z",
"model": "opus",
"tokens_input": 412000,
"tokens_output": 98700,
"estimated_cost_usd": 4.53,
"working_directory": "/project/payment-module",
"task_summary": "컨트롤러 계층 분리 리팩터링"
}
],
"daily_totals": {
"2026-08-19": {
"sessions": 5,
"tokens_input": 1240000,
"tokens_output": 287000,
"estimated_cost_usd": 13.38
}
}
}이 파일에서 봐야 할 필드는 세 가지다.
- estimated_cost_usd: 세션당 추정 비용. API 기준 단가로 환산된 값이다. MAX 구독이라 실제 청구와 다를 수 있지만, 사용량의 상대적 크기를 비교하는 데는 충분하다.
- tokens_input vs tokens_output: 입력이 출력보다 3~5배 많은 게 정상이다. 에이전트가 코드를 읽고(입력) 분석 결과를 쓰는(출력) 구조 때문이다. 만약 출력이 입력보다 많다면, 에이전트가 코드를 지나치게 많이 생성하고 있다는 신호 — 작업 지시를 더 구체적으로 좁혀야 한다(4회 참고).
- daily_totals: 일별 합산. 여기서 이상치를 빠르게 잡을 수 있다.
혼자 쓸 때는 이 파일을 직접 열어보면 되지만, 팀으로 쓸 때는 각 개발자의 attribution 데이터를 한 곳에 모아야 한다. 간단한 수집 스크립트 예시를 보자.
# collect_attribution.py — 팀 비용 데이터 수집
import json
from pathlib import Path
from datetime import date
def collect_team_usage(team_dirs: list[Path]) -> dict:
"""각 개발자의 .claude/attribution.json을 읽어 팀 합산"""
team_total = {"date": str(date.today()), "members": []}
for member_dir in team_dirs:
attr_file = member_dir / ".claude" / "attribution.json"
if not attr_file.exists():
continue
data = json.loads(attr_file.read_text(encoding="utf-8"))
today = str(date.today())
daily = data.get("daily_totals", {}).get(today, {})
team_total["members"].append({
"directory": str(member_dir.name),
"sessions": daily.get("sessions", 0),
"cost_usd": daily.get("estimated_cost_usd", 0.0),
})
team_total["total_cost_usd"] = sum(
m["cost_usd"] for m in team_total["members"]
)
return team_total수집된 데이터를 슬랙 웹훅이나 사내 대시보드로 보내면 된다. 16회에서 만든 아티팩트 대시보드에 이 데이터를 붙이면 팀 비용 현황판이 바로 완성된다. 추적이 시작되는 순간, 비용은 이미 줄어들기 시작한다. 숫자가 보이면 사람은 자연스럽게 조심하게 된다.
2단계 — 에이전트별 토큰·달러 상한
추적만으로는 폭발을 막지 못한다. 숫자를 볼 줄 아는 것과 숫자에 한도를 거는 것은 다른 문제다. CLAUDE.md나 프로젝트 설정에 비용 상한을 명시해야 한다.
# CLAUDE.md — 비용 거버넌스 섹션
## Cost Governance
### 세션별 상한
- 단일 세션 최대 토큰: 800,000 (입력+출력 합산)
- 단일 세션 최대 추정 비용: $8.00
- 상한 도달 시: 작업 중단 후 사용자에게 확인 요청
### 일별 상한
- 개인 일일 최대: $30.00
- 경고 임계값: $20.00 (66%)
- 일일 상한 도달 시: 신규 세션 차단, 기존 세션은 완료 허용
### 금지 패턴
- 밤새 무인으로 에이전트 루프 돌리기 금지
- 서브에이전트 3단계 이상 중첩 금지 (11회 참고, 비용 기하급수 증가)
- /effort max는 아키텍처 설계 검토에만 사용핵심은 두 겹의 상한을 거는 것이다. 세션별 상한은 한 번의 작업이 지나치게 비싸지지 않도록 막고, 일별 상한은 하루 전체의 총량을 통제한다. 세션별 상한만 있으면 세션을 여러 개 열어서 우회할 수 있고, 일별 상한만 있으면 한 세션에서 한꺼번에 쏟아붓는 걸 못 막는다.
숫자를 어떻게 잡을까? 내 경험에서 나온 기준선은 이렇다.
- 일반 개발 업무 (버그 수정, 기능 추가): 세션당 $2~5, 하루 $15~25
- 리팩터링/마이그레이션: 세션당 $5~10, 하루 $25~40
- 탐색적 작업 (아키텍처 검토, 코드 고고학): 세션당 $3~8, 하루 $20~30
이 숫자는 절대적인 정답이 아니다. 여러분의 코드베이스 크기, 작업 성격, 모델에 따라 달라진다. 중요한 건 숫자를 하나라도 정해놓는 것이다. 첫 2주간 추적 데이터를 보면서 현실적인 기준선을 잡고, 그 뒤에 조정하면 된다.
3단계 — fallbackModel 체인으로 비용 곡선 꺾기
모든 작업에 가장 비싼 모델을 쓸 필요는 없다. 복잡한 아키텍처 판단에는 최상위 모델이 필요하지만, 단순 코드 생성이나 테스트 작성에는 중급 모델로도 충분하다. fallbackModel 체인은 이 원리를 자동화한 것이다.
# settings.json 또는 CLAUDE.md 설정
{
"model": {
"primary": "opus",
"fallback_chain": ["sonnet", "haiku"],
"fallback_triggers": {
"daily_budget_75_percent": "sonnet",
"daily_budget_90_percent": "haiku",
"session_tokens_over_500k": "sonnet"
}
}
}이 설정의 의미는 간단하다.
- 평상시에는 Opus(최상위)로 작업한다.
- 일일 예산의 75%를 소진하면 Sonnet(중급)으로 자동 전환한다.
- 90%를 넘기면 Haiku(경량)로 내려간다.
- 세션 하나에서 토큰이 50만을 넘으면, 그 세션은 Sonnet으로 전환한다 (컨텍스트가 커질수록 비싼 모델의 효율이 떨어지기도 하므로).
실제 비용 절감 효과를 계산해보자. API 기준 100만 토큰당 비용은 대략 이렇다.
| 모델 | 입력 ($/1M 토큰) | 출력 ($/1M 토큰) | Opus 대비 비용 |
|---|---|---|---|
| Opus | $15 | $75 | 100% |
| Sonnet | $3 | $15 | ~20% |
| Haiku | $0.80 | $4 | ~5% |
하루 사용량의 30%를 Sonnet으로, 10%를 Haiku로 내리면 — 나머지 60%는 여전히 Opus — 전체 일일 비용이 약 35~40% 절감된다. 생산성의 핵심인 Opus 사용은 유지하면서, 한계 효용이 낮은 구간에서 비용을 깎는 것이다.
주의할 점이 하나 있다. Fallback이 너무 공격적이면 작업 품질이 떨어진다. 리팩터링 도중에 갑자기 모델이 바뀌면 일관성이 깨질 수 있다. 그래서 세션 중간에는 모델을 바꾸지 않는 것이 원칙이다. Fallback은 새 세션을 시작할 때만 적용되도록 설정하는 게 안전하다.
4단계 — /effort로 토큰 밀도 조절
3회에서 처음 소개한 /effort 명령은 단순한 품질 조절이 아니라 비용 조절 레버다. 에이전트가 얼마나 깊이 생각하고, 얼마나 넓게 탐색하는지를 조절한다.
# Claude Code 내에서 직접 입력
/effort min # 최소 — 즉답, 탐색 없음. 단순 질문용.
/effort low # 낮음 — 가벼운 분석. 작은 수정용.
/effort medium # 중간 — 기본값. 대부분의 작업에 적합.
/effort high # 높음 — 깊은 분석. 복잡한 버그 추적.
/effort max # 최대 — 전방위 탐색. 아키텍처 검토 전용.각 단계를 올릴 때마다 토큰 소비가 대략 1.5~2배씩 늘어난다. 즉, /effort max는 /effort min 대비 5~10배의 토큰을 쓸 수 있다. 이걸 모르고 항상 max로 놓아두면, 같은 작업이 5배 비싸게 돌아간다.
내가 실전에서 쓰는 기준은 이렇다.
- /effort min: “이 함수 이름 뭐가 좋을까?”, “이 에러 메시지 뜻이 뭐야?” — 생각 없이 물어보는 것들.
- /effort low: 단일 파일 내 간단한 수정. 타입 힌트 추가, 로깅 문구 변경.
- /effort medium: 하루의 80%는 여기. 버그 수정, 기능 추가, 테스트 작성.
- /effort high: 여러 모듈에 걸친 변경. 디버깅이 한 번에 안 끝났을 때.
- /effort max: 분기에 2~3번. 아키텍처 결정이 필요하거나, 17회에서 다룬 레거시 탐색 단계.
습관 하나를 들이면 비용이 눈에 띄게 준다. 세션을 시작할 때 딱 3초만 투자해서 “이 작업은 어느 수준이지?” 판단하고 /effort를 먼저 치는 것이다. 7회에서 다뤘던 /compact 타이밍 판단과 같은 맥락이다. 컨텍스트 절약이 곧 비용 절약이고, 비용 절약이 곧 라이선스 유지다.
5단계 — 팀 월간 예산 설계
개인 수준의 상한(2단계)과 모델 전략(3~4단계)을 세웠으면, 마지막은 팀 전체의 월간 예산을 설계하는 것이다. 이건 기술 설정이 아니라 조직 합의의 영역이다.
내가 우리 팀에서 실제로 운영하고 있는 예산 구조를 공유한다.
# 팀 월간 AI 에이전트 예산 설계 (예시: 개발자 8명)
#
# ── 1. 기본 할당 ──
# 개인별 월 기본: $250
# 8명 × $250 = $2,000/월
#
# ── 2. 버스트 풀 (공용) ──
# 기본 할당의 25%를 팀 공용 풀로 적립
# $2,000 × 0.25 = $500/월
# 용도: 긴급 장애 대응, 대규모 리팩터링, 스파이크 조사
# 사용 조건: 팀 리드 승인 (슬랙 한 줄이면 됨)
#
# ── 3. 총 월간 예산 ──
# $2,000 + $500 = $2,500/월
#
# ── 4. 알림 임계값 ──
# 개인: 50% ($125) → 정보성 알림
# 75% ($187) → 경고 알림 + fallback 모델 전환
# 90% ($225) → 강한 경고 + 팀 리드 통보
# 100% ($250) → 신규 세션 차단
#
# 팀 버스트 풀: 80% ($400) → 팀 리드 통보
#
# ── 5. 월말 정산 ──
# 미사용 개인 예산: 이월 없음 (낭비 심리 방지)
# 미사용 버스트 풀: 이월 없음
# 초과 사용: 다음 달 기본 할당에서 차감이 구조의 핵심 설계 원칙 세 가지를 설명한다.
첫째, 개인 할당과 공용 풀을 분리한다. 개인 할당만 있으면 갑자기 장애가 터졌을 때 에이전트를 못 쓰는 사람이 생긴다. 공용 풀이 있으면 필요한 사람이 일시적으로 더 쓸 수 있다. 반대로 공용 풀만 있으면 “공유지의 비극”이 발생한다 — 아무도 아끼지 않는다.
둘째, 알림 임계값을 4단계로 나눈다. 50%에서 먼저 알려주면 나머지 반을 어떻게 쓸지 계획할 수 있다. 갑자기 100%에서 차단되면 진행 중인 작업이 중단되는데, 이건 생산성에 치명적이다. 단계적 알림이 “예고된 착륙”을 가능하게 한다.
셋째, 이월을 허용하지 않는다. 이건 반직관적이지만 실험 결과다. 이월을 허용했을 때 “나중에 몰아 쓰자” 심리가 작동하면서 월말에 비용이 폭발하는 패턴이 반복됐다. 이월 없이 매달 리셋하면 사용량이 월 전체에 고르게 분산된다.
예산 숫자는 팀마다 다르겠지만, 구조는 그대로 가져다 쓸 수 있다. 중요한 건 이 숫자를 재무팀이 아니라 개발팀 스스로 정하는 것이다. 위에서 내려온 예산은 항상 부족하다고 느끼지만, 스스로 정한 예산은 지키려는 동기가 생긴다.
이 회차에서 반드시 피해야 할 함정 3가지
함정 1: 생산성 지표만으로 도입 승인을 받는다
이게 가장 위험하다. “PR이 24% 늘었습니다”라는 숫자로 AI 에이전트 도입을 승인받으면, 6개월 뒤 “그래서 비용 대비 PR당 단가가 얼마냐”는 질문이 돌아온다. 그때 대답할 준비가 안 되어 있으면 예산이 삭감된다.
도입 제안서에는 반드시 비용 상한과 거버넌스 계획을 함께 넣어야 한다. “월 $2,500 이내에서 운영하겠습니다. 추적 체계는 이렇고, 초과 시 이렇게 대응합니다”까지 포함된 제안이 승인되면, 비용이 올라도 합의된 범위 안이라 방어할 수 있다. 제안 없이 “결과가 좋으니까 계속 쓰게 해달라”는 접근은 언제든 뒤집힌다.
함정 2: “구독제니까 무제한”이라는 착각
MAX 구독 같은 정액제를 쓰면 토큰 단가를 의식하지 않게 된다. 하지만 정액제에도 실질적 한도가 있다 — 사용량이 일정 수준을 넘으면 속도 제한(rate limit)이 걸리거나, 조직 전체의 사용량이 계약 조건을 초과하면 계약 자체가 재협상 대상이 된다.
더 근본적인 문제는 기회비용이다. 에이전트를 무한정 돌리는 동안 그 세션 슬롯을 다른 팀원이 못 쓸 수 있다. 구독제의 “무제한”은 물리적 자원의 무제한이 아니다. 정액제에서도 사용량 추적과 상한 설정은 필수다.
함정 3: 추적 없이 3개월을 보내면 데이터가 없다
재무팀이 “이 비용이 정당한가?”라고 물었을 때, 여러분에게 필요한 건 데이터다. “A 프로젝트의 결제 모듈 리팩터링에 $340을 썼고, 그 결과 장애 MTTR이 4시간에서 40분으로 줄었다”고 말할 수 있어야 한다. “많이 쓰긴 했는데 정확히 뭐에 썼는지는…” 하는 순간 예산이 날아간다.
1단계(귀속 추적)를 도입 첫 날부터 켜야 하는 이유가 이것이다. 3개월 뒤에 정당성을 입증해야 할 때 소급해서 데이터를 만들 수는 없다. 처음부터 기록하고 있어야 방어할 수 있다.
AI가 코드를 짜주는 시대가 아니라, AI에게 일을 위임하는 시대다. 그런데 위임에는 비용이 따른다. 사람을 고용하면 연봉을 주듯, AI에게 일을 시키면 토큰 비용을 낸다. 위임할 줄 아는 사람이 하나의 회사가 되려면, 위임의 비용을 통제할 줄도 알아야 한다.
이번 회차의 수익화 지점
오늘 다룬 AI 비용 거버넌스는 그 자체로 컨설팅 상품이 된다. 아직 대부분의 조직이 “일단 도입하고 나중에 생각하자”는 단계에 있다. 이 글에서 다룬 5단계 — 귀속 추적, 상한 설정, 모델 체인, effort 조절, 팀 예산 설계 — 를 워크시트 한 장으로 정리하면, 도입을 검토하는 조직에 “비용 통제 프레임워크”로 제안할 수 있다. 특히 재무팀과 개발팀 사이에서 번역기 역할을 할 수 있는 사람 — “개발을 알면서 비용도 말할 수 있는 사람” — 의 가치는 AI 도구가 확산될수록 올라간다. 12회에서 다뤘던 플러그인 판매와 달리, 이건 문서 한 장과 30분 미팅으로 시작할 수 있는 저자본 컨설팅이다.
다음 회 예고: 19회에서는 AI 에이전트의 새로운 보안 위협을 다룬다. 에이전트가 읽는 GitHub 이슈, PR 코멘트, 웹페이지 — 이 모든 외부 텍스트가 잠재적 명령어가 될 수 있다. 프롬프트 인젝션이 CI/CD 파이프라인의 새로운 공격면이 되는 시대, 6회에서 세운 훅 기반 방어가 다시 주인공이 된다.
관련 회차:
- 7회: 컨텍스트 관리 — /effort와 /compact로 토큰을 절약하는 기본기
- 11회: 서브에이전트 — 에이전트 수 = 비용, 인라인 비용 상한 설정의 첫 등장
- 17회: 레거시 코드에 AI를 붙이는 법 — 오늘 비용 폭발의 실제 현장
◀ 이전 17화 (다음 차수는 아직 게시되지 않았습니다)
자주 묻는 질문
AI 코딩 에이전트는 채팅보다 비용이 얼마나 더 드나요?
채팅 한 턴은 약 2,000토큰($0.01~0.02)을 소비하지만, 에이전트는 단일 버그 수정에 약 80,000토큰($0.50~1.00), 모듈 리팩터링에 약 250,000토큰($2~4)을 소비합니다. 에이전트는 탐색-분석-구현-검증-수정의 반복 루프를 돌 때마다 이전 컨텍스트가 누적되어 토큰 소비가 계단식으로 증가하기 때문입니다.
AI 에이전트로 생산성이 올랐는데 왜 라이선스가 중단되나요?
생산성 향상은 실재하지만, 에이전트의 토큰 비용이 예상을 크게 초과하기 때문입니다. Microsoft Research 연구에서도 PR이 24% 증가했지만 일부 조직은 월 140만 달러(약 18억 원)가 청구되었고, 비용을 통제하는 거버넌스 구조를 미리 세우지 않아 대부분의 조직에서 라이선스가 중단되었습니다.
AI 비용 거버넌스란 무엇이고 왜 필요한가요?
AI 비용 거버넌스란 AI 도구 사용에 따른 비용을 사전에 통제하는 구조를 말합니다. 에이전트 도입 후 비용 폭발로 라이선스가 중단되는 것은 기술의 문제가 아니라 거버넌스 실패이며, 이 실패는 사전에 예방 가능하므로 도입 초기부터 비용 관리 체계를 갖추는 것이 중요합니다.
[…] 시리즈: Claude 활용 24회 — AI에게 일을 위임하는 법 (총 24화 중 19화)◀ 이전 18화 (다음 차수는 아직 게시되지 […]