클라우드 비용 검토 회의에서 가장 자주 나오는 말이 있다. "AI 쪽에서 뭔가 많이 나오는 것 같은데, 정확히 어디서 나오는지 모르겠어요." 이 문장 하나가 현재 수많은 기업의 AI-클라우드 스택이 처한 현실을 압축한다.

AI 도구는 분명히 도입했다. 클라우드도 쓰고 있다. 그런데 청구서는 예측이 안 되고, ROI는 보고서에만 존재하며, 엔지니어링팀은 "왜 이렇게 비용이 나오는지" 설명하는 데 스프린트의 상당 시간을 쓴다. 문제는 AI 도구 자체가 아니다. 문제는 AI 도구와 클라우드 인프라가 서로를 이해하지 못하는 구조에 있다.

---

"보이는 비용"과 "보이지 않는 비용" 사이의 간극

많은 팀이 AI 비용을 추정할 때 모델 API 호출 비용만 계산한다. OpenAI, Anthropic, 혹은 자체 호스팅 모델의 토큰 단가를 뽑고, 예상 사용량을 곱하면 끝이라고 생각한다. 이 계산이 틀린 건 아니다. 다만, 전체 그림의 30~40%만 보고 있을 가능성이 높다.

실제 AI 스택에서 비용이 발생하는 지점은 훨씬 분산되어 있다.

• 데이터 이동 비용(Egress): AI 모델이 추론을 수행하려면 데이터가 있어야 한다. 데이터가 모델이 실행되는 위치와 다른 리전, 다른 클라우드, 혹은 온프레미스에 있다면 그 이동 자체가 비용이다. 클라우드 제공사들은 데이터를 가져오는 건 거의 무료로 제공하지만, 내보내는 건 다르다. GB당 과금이 쌓이면 월말에 꽤 놀라운 숫자가 된다.

• 전처리·후처리 컴퓨팅: 원시 데이터를 모델에 넣기 전에 정제하고, 모델 출력을 다시 비즈니스 로직에 맞게 가공하는 과정은 별도의 컴퓨팅 자원을 소비한다. 이 파이프라인이 비효율적으로 설계되어 있으면 추론 비용보다 전처리 비용이 더 나오는 경우도 있다.

• 로깅·모니터링·컴플라이언스: AI 출력의 품질을 추적하고, 규정 준수를 위해 로그를 보존하고, 이상 탐지를 돌리는 것 모두 비용이다. 특히 금융, 의료, 공공 분야처럼 감사 요건이 있는 곳에서는 이 비용이 예상보다 훨씬 크게 나온다.

• SLA 버퍼: 응답 지연에 민감한 서비스라면 실제 피크 트래픽보다 더 많은 컴퓨팅을 항상 예약해두어야 한다. 이 "빈 용량(empty capacity)"은 아무것도 안 하면서 비용을 낸다.

이 항목들을 합산하면 "보이는 비용"인 모델 API 라인 아이템은 전체의 절반이 안 되는 경우가 많다. 나머지는 인프라 곳곳에 분산되어 있어서, 누가 봐도 "AI 비용"이라고 찍혀 있지 않다.

---

왜 이 구조가 고쳐지지 않는가

비용 구조가 이렇게 분산되어 있다는 걸 많은 팀이 어느 정도는 안다. 그런데 왜 고쳐지지 않을까?

첫 번째 이유는 예산과 로드맵이 분리되어 있기 때문이다. AI 도구는 데이터팀이나 ML팀이 관리하고, 클라우드 인프라는 인프라팀이 관리한다. 두 팀은 서로 다른 예산 코드, 서로 다른 분기 목표, 서로 다른 KPI를 가지고 움직인다. AI 도구의 비효율이 클라우드 비용으로 나타나도, 어느 팀의 문제인지 귀속이 안 된다. 귀속이 안 되면 아무도 고치지 않는다.

두 번째 이유는 통합 비계(integration scaffolding)의 존재다. AI 도구는 기본적으로 클라우드 네이티브 환경, 즉 탄력적인 분산 컴퓨팅을 전제로 설계되어 있다. 그런데 많은 기업의 실제 환경은 온프레미스와 클라우드가 섞여 있거나, 레거시 데이터 레이크가 현대적 AI 파이프라인과 연결되어 있지 않다. 이 간극을 메우기 위해 팀들은 미들웨어, 수동 동기화 작업, 맞춤형 로깅 레이어를 만든다. 이 비계를 유지하는 데 스프린트 용량의 30~50%가 소모될 수 있다는 분석은 과장이 아니다. 이 비용은 클라우드 청구서에 직접 찍히지 않지만, 엔지니어링 시간이라는 형태로 조직이 지불하고 있다.

세 번째 이유는 가시성 도구 자체가 파편화되어 있기 때문이다. AWS Cost Explorer, Azure Cost Management, GCP Billing 각각의 대시보드는 자기 플랫폼 안에서의 비용은 잘 보여준다. 그런데 AI 추론이 멀티클라우드 환경에서 돌아가거나, SaaS AI 도구와 자체 인프라가 섞여 있으면 통합된 비용 뷰를 얻기가 어렵다. 비용이 어디서 나오는지 모르면 줄일 수도 없다.

---

비용 구조를 바꾸는 세 가지 접근

이 문제를 해결하는 데 "더 좋은 개발자를 뽑으면 된다"거나 "더 나은 계약을 협상하면 된다"는 접근은 통하지 않는다. 근본적으로 아키텍처 문제이기 때문이다. 실무에서 효과가 있는 접근은 다음 세 가지다.

1. 비용 귀속(Cost Attribution)을 아키텍처 설계 단계에서 결정한다

많은 팀이 시스템을 먼저 만들고, 나중에 비용 태깅을 붙이려 한다. 이 순서가 문제다. AI 워크로드가 생성하는 모든 리소스—컴퓨팅, 스토리지, 네트워크 트래픽, 로깅—에 처음부터 태그 체계를 설계해야 한다. 어떤 AI 기능이, 어떤 팀의, 어떤 프로덕트에 귀속되는지를 인프라 코드(IaC) 레벨에서 명시하면, 월말 청구서 분석이 아니라 실시간 비용 모니터링이 가능해진다.

2. 데이터 위치와 모델 실행 위치를 의도적으로 정렬한다

AI 비용에서 egress가 차지하는 비중을 줄이는 가장 직접적인 방법은 데이터가 있는 곳 가까이에서 추론을 실행하는 것이다. 이게 단순하게 들리지만, 실제로는 데이터 거버넌스, 컴플라이언스 요건, 기존 인프라 위치가 얽혀 있어서 쉽지 않다. 그럼에도 불구하고 데이터 이동 경로를 명시적으로 매핑하고, 불필요한 데이터 복사를 제거하는 것만으로도 egress 비용을 의미 있게 줄일 수 있다. 일부 팀은 이 작업만으로 월 클라우드 비용의 15~20%를 절감했다는 사례를 공유한다.

3. 통합 비계를 줄이는 방향으로 스택을 진화시킨다

미들웨어와 수동 동기화 작업이 스프린트를 잡아먹고 있다면, 그 비계를 유지하는 데 드는 비용을 명시적으로 계산해볼 필요가 있다. 엔지니어 한 명의 스프린트 시간 중 40%가 통합 유지보수에 쓰인다면, 그 비용은 해당 엔지니어 연봉의 40%다. 이 숫자를 경영진에게 보여주면 "통합 아키텍처 개선"이 단순한 기술 부채 해소가 아니라 재무적 의사결정이 된다.

---

지금 당장 할 수 있는 진단

이론보다 실천이 먼저다. 지금 당신의 스택에 다음 질문을 던져보자.

Q1. 지난달 AI 관련 클라우드 비용을 항목별로 분해할 수 있는가? 모델 API 비용, egress 비용, 전처리 컴퓨팅 비용, 로깅 비용을 각각 구분해서 말할 수 있다면 가시성은 확보된 것이다. 그게 안 된다면 비용 태깅부터 시작해야 한다.

Q2. AI 파이프라인에서 데이터가 몇 번 이동하는가? 원시 데이터에서 최종 AI 출력까지의 경로를 그려보면, 불필요한 데이터 복사나 리전 간 이동이 보인다. 이 경로를 단축하는 것이 egress 비용 절감의 시작이다.

Q3. 통합 유지보수에 스프린트의 몇 퍼센트가 쓰이는가? 이 숫자를 팀 리더에게 물어보라. 대부분은 정확한 숫자를 모른다. 2주간 엔지니어링 시간을 추적해보면 놀라운 숫자가 나올 가능성이 있다.

---

청구서는 아키텍처의 거울이다

매달 예측 불가능하게 늘어나는 AI 클라우드 청구서는 단순히 "AI를 많이 써서"가 아니다. 그것은 AI 도구와 클라우드 인프라가 서로를 이해하지 못하는 채로 나란히 달리고 있다는 신호다.

더 나은 모델을 도입하거나, 더 저렴한 클라우드 제공사로 갈아타는 것으로는 이 구조가 바뀌지 않는다. 비용이 어디서 발생하는지 정확히 보고, 데이터와 컴퓨팅의 위치를 의도적으로 정렬하고, 통합 비계를 줄이는 방향으로 스택을 진화시키는 것—이것이 AI 청구서를 통제 가능한 범위로 되돌리는 유일한 경로다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그 도구가 예산을 잠식하고 있다면, 문제는 도구가 아니라 도구를 쥔 방식에 있다.