지금 이 순간에도 수많은 팀이 AI 도구를 하나씩 추가하면서 "이번엔 진짜 효율이 올라갈 것"이라고 믿는다. 그리고 한 달 뒤 클라우드 청구서를 받아들고 멍하니 화면을 바라본다. 숫자는 분명히 올랐는데, 어디서 올랐는지 아무도 설명하지 못한다.

이것은 비용 문제가 아니다. 가시성(visibility)의 붕괴 문제다.

---

당신이 보는 것과 실제로 일어나는 것 사이의 간극

대부분의 팀은 AI 스택을 모니터링할 때 "모델 API 호출 횟수"와 "토큰 소비량"을 들여다본다. 대시보드에 숫자가 찍히고, 예산 대비 사용량이 표시된다. 직관적이고 깔끔하다.

문제는 그 대시보드가 전체 그림의 20~30%만 보여준다는 것이다.

나머지 70~80%는 어디에 숨어 있을까. 데이터 전처리 컴퓨팅, 결과 후처리 파이프라인, 서비스 간 egress 비용, 웜 버퍼 유지 비용, 재시도 로직이 만들어내는 반복 연산, 그리고 이 모든 것을 추적하기 위한 관찰 가능성(observability) 인프라 자체의 비용이다.

이 비용들의 공통점이 있다. 어떤 단일 도구의 청구서에도 명확하게 잡히지 않는다는 것이다.

---

도구가 늘어날수록 '설명 가능한 비용'의 비율이 줄어든다

여기서 역설이 시작된다.

AI 도구를 하나 추가할 때마다 팀은 새로운 모니터링 레이어를 하나씩 얹는다. 도구 A의 대시보드, 도구 B의 로그, 도구 C의 알림 시스템. 각각은 자기 영역을 잘 보여준다. 그런데 도구 A가 도구 B를 호출하면서 발생하는 egress 비용은 누구의 대시보드에도 명확하게 표시되지 않는다. 도구 B가 실패해서 도구 A가 재시도할 때 발생하는 연산은 어느 팀의 책임인가? 도구 C가 도구 A와 B의 결과를 합산하기 위해 임시로 올려둔 컴퓨팅 인스턴스는 누가 추적하는가?

이것이 내가 "가시성의 붕괴"라고 부르는 현상이다.

도구의 수가 늘어날수록, 각 도구의 내부는 더 잘 보이지만 도구들 사이의 공간은 점점 더 어두워진다. 그리고 비용은 정확히 그 어두운 공간에서 자란다.

---

실무에서 자주 목격하는 세 가지 패턴

패턴 1: "우리 모델 비용은 통제되고 있어요"

가장 흔한 착각이다. LLM API 비용은 실제로 잘 통제되고 있을 수 있다. 토큰 한도를 걸었고, 캐싱도 적용했고, 사용량 알림도 설정했다.

그런데 그 LLM을 호출하기 전에 문서를 청크로 나누고 임베딩을 생성하는 전처리 파이프라인이 있다. 그 파이프라인은 LLM 호출 여부와 관계없이 문서가 업로드될 때마다 돌아간다. 그리고 그 파이프라인의 결과물을 저장하는 벡터 DB 인스턴스는 쿼리가 없는 새벽 3시에도 웜 상태를 유지하고 있다.

모델 비용은 통제됐다. 그런데 청구서는 왜 올랐을까.

패턴 2: "우리는 서버리스로 전환해서 유휴 비용이 없어요"

서버리스는 훌륭한 선택이다. 호출이 없으면 비용이 없다. 이론적으로는.

현실에서는 서버리스 함수들이 AI 파이프라인 안에서 콜드 스타트 문제를 피하기 위해 미리 웜업된다. 특히 응답 지연에 민감한 프로덕션 환경에서는 "웜 인스턴스 최소 1개 유지" 설정이 기본값처럼 사용된다. 도구가 5개라면 웜 인스턴스가 최소 5개다. 각각은 작다. 합산하면 작지 않다.

더 중요한 것은, 이 웜 인스턴스들의 비용이 서버리스 청구서가 아닌 컴퓨팅 예약 비용으로 잡히는 경우가 많다는 점이다. 팀은 서버리스 대시보드를 보면서 "비용 없음"을 확인하고, 컴퓨팅 청구서에서 원인 불명의 고정 비용을 발견한다.

패턴 3: "관찰 가능성 도구를 추가해서 이제 다 보여요"

관찰 가능성 도구는 필수다. 그런데 아이러니하게도, 관찰 가능성 도구 자체가 비용을 만든다.

로그를 수집하고, 트레이스를 저장하고, 메트릭을 집계하는 과정에서 데이터가 이동한다. 그 데이터 이동이 egress 비용을 만든다. AI 파이프라인이 복잡할수록 로그 볼륨이 커지고, 로그 볼륨이 커질수록 관찰 가능성 비용이 커진다. 그리고 그 관찰 가능성 비용은 어느 AI 도구의 비용으로도 귀속되지 않는다.

팀은 "이제 모든 게 보인다"고 생각하면서 실제로는 보이지 않는 비용의 새로운 층을 하나 더 쌓은 것이다.

---

가시성이 붕괴되면 의사결정도 붕괴된다

비용 추적이 안 된다는 것은 단순히 청구서 관리의 문제가 아니다. 더 심각한 결과를 낳는다.

어떤 도구가 ROI를 내고 있는지 알 수 없게 된다.

도구 A가 월 50만 원짜리 구독료를 내고 있다면, 팀은 "도구 A의 비용은 50만 원"이라고 인식한다. 그런데 도구 A가 작동하기 위해 필요한 전처리 파이프라인, 데이터 이동, 웜 버퍼, 재시도 비용까지 합산하면 실제 비용은 150만 원일 수 있다. 하지만 그 150만 원은 어느 청구서에도 "도구 A 관련 비용"으로 묶여 있지 않다.

결과적으로 팀은 잘못된 숫자를 기준으로 ROI를 계산하고, 잘못된 도구를 계속 유지하고, 더 나은 대안을 검토하지 않는다. 가시성의 붕괴가 전략적 판단력의 붕괴로 이어지는 것이다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그런데 그 도구의 실제 비용을 파악하지 못한다면, 우리는 도구를 사용하는 것이 아니라 도구에게 사용당하는 것이다.

---

가시성을 회복하기 위한 실질적 접근

1. "도구 단위 비용"이 아닌 "워크플로우 단위 비용"으로 측정하라

LLM API 비용, 전처리 파이프라인 비용, 데이터 이동 비용, 관찰 가능성 비용을 하나의 워크플로우 단위로 묶어서 추적하는 체계를 만들어야 한다. 클라우드 리소스 태깅(tagging)을 도구 단위가 아닌 비즈니스 워크플로우 단위로 설계하는 것이 출발점이다.

예를 들어, "고객 문의 자동 분류 파이프라인"이라는 태그 아래 그 파이프라인에 관여하는 모든 리소스(LLM 호출, 임베딩 생성, 벡터 DB 쿼리, 결과 후처리, 로깅)를 묶으면, 그 워크플로우의 실제 총비용이 보이기 시작한다.

2. egress 비용을 별도 항목으로 추적하라

egress 비용은 AI 스택에서 가장 빠르게 증가하면서 가장 자주 무시되는 비용이다. 서비스 A에서 서비스 B로 데이터가 이동할 때마다 비용이 발생한다. 이 비용을 별도 예산 항목으로 분리하고 주간 단위로 추적하면, 불필요한 데이터 이동 패턴이 눈에 들어오기 시작한다.

특히 같은 데이터를 여러 도구가 반복적으로 가져오는 패턴은 egress 비용의 주범이다. 공유 캐시 레이어를 도입하는 것만으로도 이 비용을 30~50% 줄일 수 있다는 사례들이 보고되고 있다.

3. "웜 상태 유지" 비용을 명시적으로 예산에 포함하라

프로덕션 AI 파이프라인에서 응답 지연을 허용 범위 안에 유지하려면 웜 인스턴스가 필요하다. 이것은 선택이 아니라 현실이다. 그렇다면 이 비용을 숨기지 말고 명시적 운영 비용으로 예산에 포함해야 한다.

도구를 추가할 때마다 "이 도구가 프로덕션에서 웜 상태를 유지해야 하는가, 그 비용은 얼마인가"를 체크리스트에 포함하는 것이 좋다. 이 질문 하나가 불필요한 도구 추가를 막는 가장 효과적인 필터가 될 수 있다.

4. 관찰 가능성 비용 자체를 관찰하라

관찰 가능성 도구의 비용이 AI 파이프라인 총비용의 15~25%를 차지하는 경우가 드물지 않다. 모든 것을 로깅하고 트레이싱하는 것이 미덕처럼 여겨지지만, 실제로는 샘플링 기반 관찰 가능성이 비용 대비 효율이 훨씬 높다.

프로덕션 트래픽의 100%를 추적하는 대신 5~10%를 샘플링하되, 오류와 이상 패턴은 100% 캡처하는 방식이 현실적인 대안이다. 이 전환만으로 관찰 가능성 비용을 절반 이하로 줄이면서도 실질적인 디버깅 능력을 유지할 수 있다는 사례들이 있다.

---

도구를 추가하기 전에 던져야 할 질문

새로운 AI 도구를 도입하려는 팀에게 나는 항상 같은 질문을 던진다.

"이 도구가 기존 파이프라인에 연결될 때, 어떤 데이터가 어디로 이동하는가?"

이 질문에 명확하게 답할 수 없다면, 그 도구의 실제 비용을 예측할 수 없다는 뜻이다. 그리고 비용을 예측할 수 없는 도구는, 아무리 기능이 뛰어나도 통제 불가능한 리스크를 안고 들어오는 것이다.

우리가 직면한 문제를 해결하는 것은 더 많은 도구가 아니라, 기존 도구들이 실제로 무엇을 하고 있는지를 명확하게 보는 능력이다. 가시성은 비용 관리 도구가 아니다. 그것은 전략적 판단의 기반이다.

AI 스택이 복잡해질수록, 가장 중요한 역량은 더 많은 도구를 다루는 능력이 아니라 지금 가진 도구들이 만들어내는 전체 그림을 읽는 능력이다. 그 능력을 갖춘 팀이 청구서를 이해하고, ROI를 정확히 계산하고, 다음 도구를 추가할지 말지를 제대로 결정할 수 있다.