토큰은 싸졌는데 업무는 왜 비쌀까: AI의 건당 원가를 설계하는 법

AI 업무의 경제성을 보려면 같은 품질 기준으로 승인된 결과 한 건당 운영 원가를 측정해야 합니다. 모델 사용료에 검색·도구·실패 실행·사람의 검수·운영 유지 비용을 더하고, 그 기간 실제로 승인된 결과 수로 나누는 방식입니다. 초기 구축 투자와 확보된 업무 시간, 현금 절감은 별도로 기록해야 판단을 흐리지 않습니다.

월말에 AI 사용료가 적게 나왔습니다. 팀은 저렴하게 자동화를 운영했다고 생각합니다. 그런데 담당자는 생성된 초안을 고치고, 재실행하고, 누락된 데이터를 확인하느라 많은 시간을 썼습니다. 비용 대시보드에는 모델 청구액이 보이고 사람의 작업은 기존 급여 안에 섞입니다. 이 상태에서는 API가 저렴해진 것과 업무가 효율적으로 끝난 것을 구분하기 어렵습니다.

AI 프로젝트의 다음 질문은 “어떤 모델이 더 싸지?”에서 한 걸음 더 나아가야 합니다. “같은 품질의 결과를 승인하는 데 무엇이 얼마나 들었지?” 이 글은 그 질문에 답할 작은 원가표와 측정 구조를 제안합니다. 가격 전망이나 특정 상품 투자 조언이 아닌 업무 운영 설계입니다. 등장하는 비용과 사례는 실제 고객사의 성과가 아닌 가상 예시입니다.

1. 측정 단위를 먼저 정한다

FinOps Foundation의 Unit Economics 설명은 기술 지출을 조직이 얻는 가치와 연결해 보는 접근을 다룹니다. 기술 요청당 비용과 고객·거래·해결 사례 같은 사업 단위 비용을 구분합니다. 이 관점을 업무 자동화에 적용하면 토큰 수와 실제 완료 결과를 서로 다른 측정 단위로 둘 수 있습니다.

참고한 FinOps Framework는 FinOps Foundation의 CC BY 4.0 자료입니다. 이 글에서는 원칙을 한국어로 요약하고 사내 업무용 계산과 절차를 새로 제안했습니다. 재단의 검증이나 보증을 받은 사례는 아닙니다.

운영팀에게 도움이 되는 단위는 업무에 따라 다릅니다. 견적 업무라면 승인된 견적 한 건, 고객 문의라면 팀이 정한 조건을 충족해 해결된 문의 한 건, 내부 조사라면 근거 검토를 통과한 보고서 한 건이 될 수 있습니다. 생성 횟수나 호출 횟수는 시스템 효율을 설명하지만 그 자체로 업무의 완료를 증명하지 않습니다.

완료의 정의는 측정 시작 전에 합의합니다. 어떤 필수 항목이 있어야 하는지, 누가 승인하는지, 재작업 상태는 무엇인지, 나중에 오류가 발견되면 어떻게 반영할지 기록합니다. 생성 시점을 완료 시점으로 잡으면 초안을 많이 만드는 시스템이 실제 처리 성과보다 좋아 보일 수 있습니다.

비교할 업무 묶음도 고정해야 합니다. 단순 문의와 복잡한 계약 검토를 섞고 이전보다 건당 비용이 줄었다고 주장하면 업무 난도 변화가 결과에 섞입니다. 같은 품질 기준과 유사한 난도 묶음에서 비교한 뒤 범위를 넓힙니다. 처리량만 늘어난 경우에는 수요 자체가 늘었는지, 중복 결과가 포함됐는지도 함께 확인합니다.

2. 운영 원가의 경계를 공개한다

LeanX가 제안하는 첫 원가표에는 다섯 묶음이 들어갑니다. 이 구성과 뒤의 계산은 FinOps 문서의 공식 예제를 복제한 것이 아니라 사내 업무 측정을 위한 독자적인 적용 제안입니다.

1. 모델 실행: 입력·출력·캐시 등 실제 청구 기준에 따른 사용료를 기록합니다.
2. 검색과 도구: 검색 인프라, 외부 데이터, 연결 도구, 저장과 전송 비용을 기록합니다.
3. 실패와 재시도: 승인 결과로 이어지지 못한 실행도 같은 업무 묶음에 귀속합니다.
4. 사람의 작업: 자료 준비, 검수, 수정, 예외 해결에 든 시간을 기록합니다.
5. 반복 운영: 모니터링, 문서 갱신, 평가, 장애 대응과 정기 유지에 든 비용을 배분합니다.

각 비용이 겹치지 않게 정의해야 합니다. 모델 청구액에 재시도 사용료가 이미 포함돼 있다면 이를 별도 항목으로 한 번 더 더하지 않습니다. 실패와 재시도는 실행 분류 태그로 관리할 수 있습니다. 시스템 전체 운영 비용에 도구 사용료가 포함돼 있다면 도구 묶음에도 중복 기록하지 않습니다.

사람의 시간은 계산에 쓰는 시간당 내부 원가 기준을 명시합니다. 급여를 단순히 근무 시간으로 나눌지, 조직이 정한 부대 비용을 포함할지 재무 담당자와 일관되게 정합니다. 이 값은 업무 자원 사용을 비교하기 위한 배분 기준입니다. 검수 시간이 줄었다고 이미 지급하는 급여가 그만큼 사라진다는 뜻은 아닙니다.

공유 인프라도 경계가 필요합니다. 여러 업무가 쓰는 검색 시스템의 월 비용을 한 업무에 모두 붙이면 비교가 흔들립니다. 사용량, 사용자 수 또는 합의한 배분 기준으로 나누고 기준을 원가표에 적습니다. 직접 관측한 비용과 추정 배분한 비용을 구분하면 결과의 확실성을 설명할 수 있습니다.

초기 구축·교육·이관 비용은 별도로 기록합니다. 반복 운영 원가를 보기 위한 표와 전체 사업성 표를 나란히 둘 수 있습니다. 초기 투자를 기간별로 배분한다면 그 기간과 가정을 명시해야 합니다. 초기 비용을 제외한 수치를 전체 비용처럼 부르면 안 됩니다.

3. 가상 계산: 낮은 API 청구액이 낮은 원가를 뜻하지 않을 때

한 달 동안 접수한 요청 100건을 대상으로 실행했다고 가정해 보겠습니다. 중복 요청은 없으며, 같은 품질 기준으로 승인된 결과가 A안에서는 80건, B안에서는 90건입니다. 나머지는 해당 월말까지 완료되지 않은 작업입니다. 두 안의 사람이 수행한 작업 비용은 같은 내부 시간당 기준으로 환산했고, 모든 실행 비용에는 실패와 재시도를 포함했습니다.

A안의 월 운영 원가를 모델·도구 10만 원, 사람 검수·수정 80만 원, 정기 유지 10만 원으로 가정합니다. 합계는 100만 원이고 승인된 결과는 80건입니다. 승인 결과당 운영 원가는 100만 원 ÷ 80건 = 12,500원입니다. 모델·도구 청구액만 보면 요청당 1,000원이지만, 그것은 승인된 업무의 원가와 다른 지표입니다.

B안은 모델·도구 20만 원, 사람 검수·수정 50만 원, 정기 유지 20만 원을 가정합니다. 합계는 90만 원이고 승인 결과는 90건입니다. 승인 결과당 운영 원가는 90만 원 ÷ 90건 = 10,000원입니다. 이 조건에서는 시스템 청구액이 늘었어도 전체 운영 자원의 사용과 승인 결과를 함께 보면 B안의 건당 원가가 낮습니다.

이 계산은 B안의 우월성을 실제로 입증한 결과가 아닙니다. 동일 품질과 유사 난도라는 가정이 성립하는지, 측정한 시간에 누락이 없는지, 미완료 작업이 다음 달에 어떤 비용을 만들지 실제 평가가 필요합니다. 초기 구축과 교육, 이관 비용도 이 운영 비교에는 포함하지 않았습니다. 전체 도입 판단에서는 별도로 더해야 합니다.

또한 2,500원의 차이를 승인 건수에 곱해 바로 현금 절감이라고 보고하면 안 됩니다. 줄어든 검수 시간을 다른 업무에 사용했는지, 외주 지급이나 초과근무 등 실제 지출이 변했는지 확인해야 합니다. 원가 개선, 확보된 처리 여력, 추가 매출, 현금 지출 감소를 각각 기록하면 성과를 과장하지 않고 설명할 수 있습니다.

4. 요청부터 승인까지 같은 식별자를 이어 붙인다

청구 대시보드와 업무 시스템이 서로 다른 단위로 기록하면 연결 작업이 필요합니다. LeanX는 최초 요청에 업무 식별자를 부여하고 모델 실행, 검색, 도구 호출, 재시도, 사람 검토, 최종 승인에 연결할 것을 제안합니다. 여러 번 실행해도 동일 업무를 중복으로 완료 처리하지 않아야 합니다.

최소 기록에는 업무 종류와 난도 묶음, 실행 식별자, 연결한 업무 식별자, 모델·도구 버전, 직접 관측 비용, 사람 투입 시간, 승인 상태와 승인 시각을 포함할 수 있습니다. 입력 문서 전체나 민감한 고객 내용을 비용 분석용 로그에 복제할 필요는 없습니다. 비용 분석 목적에 필요한 정보와 보관 기간을 정하고 담당자 접근을 제한합니다.

하나의 실행이 여러 결과를 만드는 경우에는 비용 배분 규칙을 미리 정합니다. 반대로 여러 에이전트가 같은 결과를 만드는 경우에는 모든 실행을 그 결과에 묶어 봅니다. 작업 단계별 비용을 살펴야 반복 호출이 필요한지, 검색 범위가 과도한지, 사람의 재검토가 어디서 생기는지 찾을 수 있습니다.

FinOps for AI 문서는 AI 지출의 복잡성, 예측의 어려움, 여러 팀과 공급자에 걸친 비용 배분을 다룹니다. 이 원칙을 우리 운영에 적용하면 월 총액과 함께 업무 종류별 비용, 미완료 비용, 실행 변동을 볼 필요가 있습니다. 단가표를 읽는 것만으로는 사용 패턴을 설명하기 어렵습니다.

실제 청구액은 공급자 청구서와 맞춰 봅니다. 내부 로그와의 차이는 환율, 할인, 공유 비용, 집계 시차 등 원인을 확인하고 기록합니다. 작은 파일럿에서는 자동화된 데이터 창고보다 표 한 장으로 시작할 수 있습니다. 다만 관측값과 추정값, 누락된 비용은 숨기지 않는 편이 좋습니다.

5. 평균 비용과 비싼 예외를 같이 본다

대부분의 요청이 저렴하게 끝나도 소수의 예외에서 호출과 재시도가 길게 이어질 수 있습니다. 평균만 보면 이 부담이 드러나지 않을 수 있습니다. 완료 건수와 건당 비용에 더해 비용 분포, 재시도 횟수, 보류된 작업, 사람에게 넘어간 작업을 확인합니다. 표본이 작다면 복잡한 백분위 수치보다 개별 비싼 사례를 먼저 검토할 수 있습니다.

실행 상한도 업무 기준으로 정합니다. 최대 호출 횟수, 도구 사용량, 경과 시간 또는 누적 비용에 도달하면 작업을 멈추거나 사람에게 넘기는 경로를 둡니다. 구체적인 상한은 정상 업무가 필요한 자원과 예외 영향을 측정한 뒤 정합니다. 이 글은 모든 업무에 통하는 호출 수나 비용 한도를 제시하지 않습니다.

상한이 너무 낮으면 정상 작업이 불필요하게 중단되고 사람 비용이 늘 수 있습니다. 반대로 상한이 높으면 실패를 늦게 감지할 수 있습니다. 멈춘 작업의 이유와 사람이 해결한 시간을 함께 보며 조정합니다. 시스템 비용을 줄이려고 사람의 예외 처리를 무제한 늘리면 전체 건당 원가는 개선되지 않을 수 있습니다.

최적화 후보는 단계별로 비교합니다. 더 작은 모델, 검색 자료 정리, 중복 호출 제거, 검수 화면 개선 등을 한 번에 모두 바꾸기보다 변경과 평가 결과를 연결해 기록합니다. 모델 사용료가 감소해도 승인 품질이 떨어지거나 사람 시간이 늘면 다음 결정을 다시 봐야 합니다. 품질을 유지한다는 조건은 비용 목표 옆에 항상 남아 있어야 합니다.

6. 운영 회의에서 결정을 남긴다

월 보고서는 총 청구액 하나로 끝내지 않습니다. 업무별 승인 결과 수, 완료되지 않은 요청 수, 승인 결과당 운영 원가, 품질 결과, 사람 투입 시간과 비용 변동의 원인을 같이 봅니다. 측정 기간 밖으로 넘어간 작업과 나중에 발견한 오류도 후속 기록으로 연결합니다. 승인 건수를 늘리려고 기준을 낮추지 않았는지 별도 점검합니다.

사업 책임자는 어떤 결과에 비용을 쓸지 정합니다. 현업 담당자는 실제 완료와 품질을 판정합니다. 개발·운영 담당자는 실행 경로와 직접 비용을 설명합니다. 재무 담당자는 배분 기준과 지출 변화를 확인합니다. 이 역할이 같이 보는 표를 만들면 한 팀의 비용 감소가 다른 팀의 숨은 작업 증가로 옮겨갔는지 살펴볼 수 있습니다.

첫 달의 목표는 정교한 대시보드를 만드는 것이 아닐 수 있습니다. 반복 업무 하나에서 요청부터 승인까지 비용을 추적하고, 비용이 많이 든 사례의 원인을 찾는 것만으로도 다음 변경을 정할 수 있습니다. 측정 결과를 보고 유지, 개선, 범위 축소 중 무엇을 선택했는지 이유와 함께 남깁니다. 자료가 부족하면 결론을 미루고 다음에 무엇을 더 측정할지도 적습니다.

LeanX는 AI 교육 이후 실제 업무 파일럿과 구축까지 연결합니다. 비용 때문에 도입을 망설이거나 도입 뒤 효과를 설명하기 어렵다면, 반복 업무 하나의 승인 결과와 검수 시간을 기준으로 적용 범위를 정할 수 있습니다. AI 업무 원가·파일럿 상담