16장 30일 도입 계획과 운영 회의를 설계한다

1주차: 보이게 한다

상위 세 기능만 고른다. request ID, feature, model class, token, retry, outcome을 기록한다. invoice 총액과 application 추정액 차이를 확인한다. 이때 최적화하지 않는다.

2주차: 결과 단위를 연결한다

해결, 승인, 재문의 같은 outcome을 정한다. 해결 1건당 비용과 사람 수정 시간을 계산한다. 비싼 상위 10개 trace를 비용이 아니라 원인으로 분류한다.

3주차: 안전한 절감 하나를 배포한다

불필요 context 제거, output schema, route 분리, cache 중 하나만 선택한다. 고정 평가셋과 canary를 통과시킨다. 절감과 품질 차이를 decision log에 남긴다.

4주차: 예산과 책임을 운영한다

soft·hard limit, owner, escalation, kill switch를 rehearsal한다. 팀별 showback부터 시작하고 데이터가 안정된 뒤 chargeback을 검토한다.

주간 회의는 30분이면 충분하다.

5분  결과: 해결 건수·품질 하한
10분 원가: 해결 1건당 비용과 큰 변화
10분 원인: retry·cache miss·route drift 상위 3개
5분  결정: 다음 한 가지 실험, owner, rollback 조건

비용 목표를 개발자 개인 평가에 연결하면 안전하게 필요한 호출까지 숨길 수 있다. 팀의 제품 outcome과 시스템 개선으로 평가한다. 좋은 Cost Engineering은 AI를 덜 쓰는 기술이 아니라 가치가 있는 곳에 설명 가능하게 쓰는 운영 능력이다.

부록 A 실습 정답과 확장 과제

기본 검증

npm test의 다섯 test가 통과해야 한다. 배송 FAQ는 economy, 분쟁 가능 답변은 premium으로 간다. tenant가 다른 입력은 같은 문장이어도 cache key가 달라야 한다.

과제 1: 가격표 외부화

PRICE_BOOK을 lab/data/prices.json으로 옮기고 version을 결정 영수증에 포함한다. 없는 version은 최신 값으로 조용히 대체하지 말고 요청을 실패시킨다.

과제 2: 예산 보호 개선

risk=high 요청은 hard limit을 넘더라도 바로 block하지 않고 human_approval queue로 보낸다. 단, queue 자체의 일일 상한을 둔다.

과제 3: 실제 사용량 연결

관리자 key를 browser에 넣지 않는다. server-side collector가 공식 Usage·Costs API를 호출하고 원본 response는 접근 통제된 storage에 보관한다. application dashboard에는 집계 값만 노출한다. OpenAI 공식 문서 기준으로 Usage는 상세 활동 분석, Costs는 invoice와 조정하는 재무 확인에 사용한다.

부록 B 트러블슈팅

부록 C 저작권·보안·출간 확인

원고, CostLab code, SVG 도식은 이 책을 위해 독자적으로 작성했다. 표지 비주얼은 외부 reference 없이 생성했고 prompt와 원본 경로를 figures/PROVENANCE.md에 기록했다. 실습의 회사·서비스·금액은 가상이다. 공식 문서의 화면을 복제하지 않고 사실을 요약해 URL과 검토일을 research/SOURCES.md에 남겼다.

실제 환경에서는 API key, prompt 원문, 고객 개인정보를 repository나 screenshot에 넣지 않는다. 책의 예시 key는 존재하지 않는 placeholder만 사용한다. 출간 직전 가격, API field, FOCUS version, Kubernetes 지원 상태를 공식 자료에서 다시 확인하고 FinOps 실무자 감수를 마친다.

부록 D 10일 실전 워크북

이 워크북은 읽은 내용을 자신의 서비스 산출물로 바꾼다. 하루 결과를 한 file에 남기고 다음 날 그 file을 입력으로 사용한다. service가 없다면 CostLab의 세 시나리오로 수행한다.

1일차 비용 경계 그리기

model 호출 전후의 모든 과금 가능 자원을 그린다. embedding, 검색, storage, network, observability와 사람 검토를 빼먹지 않는다. 완료 증거는 “AI 비용” 한 줄이 아니라 자원별 owner와 billing source가 있는 표다. 알 수 없는 항목은 0원으로 쓰지 말고 unknown으로 둔다.

2일차 요청 영수증 schema

필수 field 12개를 정하고 개인정보를 분류한다. raw prompt를 저장하고 싶다면 목적, 접근자, retention, 삭제 절차를 먼저 쓴다. fixture 요청 세 개로 schema validation을 통과시킨다.

3일차 가격표와 조정

공식 가격을 code에 복사하기 전에 billing unit을 확인한다. per-token, per-second, per-image, storage-day는 같은 식으로 계산할 수 없다. 가격표 version과 effective_from을 넣고 어제 사용량을 두 version으로 재계산한다.

4일차 결과 단위

현업과 함께 resolved를 정의한다. AI response 생성, 발송, 고객 해결을 구분한다. 사람 수정 시간 20건을 sampling해 평균과 p95를 기록한다.

5일차 route matrix

20개 실제 유형을 risk·complexity로 표시한다. model 이름부터 고르지 말고 품질 하한과 사람 승인 여부를 먼저 정한다.

6일차 context diet

대표 trace 다섯 개에서 실제 인용되지 않은 chunk를 표시한다. top-k를 한 단계 낮추고 정확도·근거 recall·비용을 비교한다. 한 번에 chunk 크기와 검색 model도 함께 바꾸지 않는다.

7일차 cache threat model

공유 가능한 응답과 금지 응답을 분류한다. tenant A의 답을 tenant B key로 읽는 negative test, 정책 version 변경 뒤 miss가 나는 test, TTL 뒤 만료 test를 만든다.

8일차 budget game day

soft limit과 hard limit을 fixture에서 강제로 넘긴다. 중요 요청, 일반 요청, 실험 요청이 각각 어떤 사용자 메시지와 queue 상태를 만드는지 확인한다. 담당자가 kill switch를 5분 안에 찾는지 측정한다.

9일차 회귀 평가와 canary

절감 후보 하나를 골라 30개 고정 case를 실행한다. 평균 점수 하나로 합치지 말고 high-risk false negative를 별도 gate로 둔다. canary 종료 조건과 rollback owner를 release note에 쓴다.

10일차 경영 가능한 한 장

이번 주 해결 건수와 품질 하한
해결 1건당 유효 원가와 전주 차이
증가 원인 상위 3개
검증된 절감 효과와 회귀 결과
다음 실험, owner, 예상 절감, 중단 조건

비용 review용 SQL 골격

warehouse 문법에 맞게 수정한다. estimated_cost와 invoice 비용을 섞지 않는다.

SELECT feature, route,
  COUNT(*) AS requests,
  SUM(estimated_cost_usd) AS estimated_cost,
  SUM(CASE WHEN outcome = 'resolved' THEN 1 ELSE 0 END) AS resolved,
  SUM(estimated_cost_usd) /
    NULLIF(SUM(CASE WHEN outcome = 'resolved' THEN 1 ELSE 0 END), 0)
    AS cost_per_resolved
FROM ai_request_receipts
WHERE occurred_at >= :start_at AND occurred_at < :end_at
GROUP BY feature, route
ORDER BY estimated_cost DESC;

결정 기록 template

# COST-DECISION-___
- 문제: 어떤 결과 원가가 왜 커졌는가
- baseline: 품질, 비용, latency, sample 기간
- 변경: 한 번에 바꿀 변수
- 안전 조건: 절대 낮아지면 안 되는 지표
- canary: traffic, 기간, owner
- rollback: 자동/수동 조건과 실행 명령
- 결과: 절감, 품질 차이, 예상 밖 영향
- 후속: 유지/확대/폐기와 재검토일

워크북을 마치면 숫자보다 먼저 네 가지를 설명할 수 있어야 한다. 어느 기능이 비용을 만들었는지, 그 비용으로 무엇을 해결했는지, 절감이 품질을 해치지 않았는지, 예산을 넘을 때 시스템이 어떻게 안전하게 멈추는지다.

부록 E 캡스톤 통합 시나리오: 환불 초안 비용을 20% 줄인다

상황은 분명하다. 환불 초안 기능의 월 비용이 40% 늘었지만 문의 수는 10%만 늘었다. “싼 model로 바꾼다”는 해결책을 보류하고 증거부터 모은다.

1단계 증가분을 분해한다

같은 기간과 timezone으로 요청 수, fresh input, cached input, output, retry, tool call을 비교한다. 조사 결과 정책 문서가 매 요청 전체 첨부되면서 input이 1,400에서 2,300으로 늘었고, 답변 형식 변경으로 output도 360에서 520으로 늘었다. model 가격은 바뀌지 않았다.

요청 수 효과       +10%
평균 input 효과    +18%
평균 output 효과    +8%
retry 효과          +4%
가격·환율 효과       0%
상호작용·반올림      잔여

비율은 단순 합계가 정확히 40이 되지 않을 수 있다. 설명 목적의 decomposition 방법과 잔여를 기록한다.

2단계 품질 하한을 고정한다

최근 승인된 50건을 비식별 fixture로 만든다. 정책 근거 일치 98%, 금지 표현 0건, 상담사 수정 p50 45초 이하를 하한으로 정한다. 이 값은 절감 후 협상하지 않는다.

3단계 한 변수씩 바꾼다

먼저 검색 범위를 현재 판매 채널·상품 유형·정책 유효일로 제한한다. 다음 실험에서만 output schema를 3문장과 evidence ID로 바꾼다. 두 변경을 동시에 배포하면 어느 것이 품질을 바꿨는지 모른다.

4단계 캐시 경계를 세운다

공개 정책 요약은 policyVersion:locale로 cache하지만 고객 주문과 상담 기록은 cache하지 않는다. 정책 게시 event가 cache를 무효화한다. stale answer negative test를 release gate에 넣는다.

5단계 canary와 예산을 연결한다

10% traffic에서 24시간 실행한다. 해결 1건당 비용이 20% 이상 낮고 품질 하한을 통과하면 50%로 늘린다. high-risk false negative 한 건, 수정 시간 10% 악화, stale answer 한 건이면 자동 rollback한다.

6단계 최종 영수증

변경 전: 해결당 $0.0121, 근거 일치 98.4%, 수정 p50 41초
변경 후: 해결당 $0.0093, 근거 일치 98.6%, 수정 p50 40초
절감: 23.1%
결정: 유지, 14일 뒤 재검토
남은 위험: 신규 정책 게시 event 누락 감시

이 통합 시나리오의 정답은 숫자가 아니다. 원인을 요청 수와 unit usage로 분해하고, 품질 하한을 먼저 고정하고, 한 변수씩 canary하며, rollback과 남은 위험을 기록하는 순서가 정답이다.

장별 산출물 지도