대부분의 개발팀은 대규모 언어 모델(LLM)을 벤더가 제공하는 프론트엔드를 통해 소비한다. 터미널 기반 도구든 웹 GUI든 음성 통화든, 형태는 달라도 구조는 같다. 내 데이터가 들어가고 그들의 응답이 돌아온다. 유료 구독이 파는 것이 바로 이 흐름이고, 당장은 그걸 사는 것 자체에 불만을 가질 이유가 없다. 문제는 그 거래의 내부에서 실제로 무슨 일이 벌어지는지, 사용자 입장에서 거의 보이지 않는다는 데 있다. 코드 자동화든, 이미지에서 3D 모델을 뽑아내는 파이프라인이든, 수십억 달러 규모의 SaaS든, 추론을 호출하는 순간부터 토큰이 어떻게 쓰이고 비용이 어디서 새는지는 블랙박스에 가깝다.
벤더 대시보드는 의사결정 도구가 아니다
원문 저자의 핵심 불만은 벤더가 제공하는 애널리틱스 패널이 엔지니어를 위한 계측이 아니라는 점이다. 그들이 '작업이 진행되고 있다'는 증거로 보여주는 화면은 대체로 보기 좋게 다듬어진 요약일 뿐, 시계열로 정리된 토큰 사용 통계가 아니다. 이런 화면으로는 어떤 결정도 내릴 수 없다는 것이 저자의 표현이다. 실무자라면 공감할 지점이 있다. 세션 단위로 입력·출력 토큰이 어떻게 분포하는지, 어떤 요청에서 비용이 급증했는지, 캐시가 언제 적중하고 언제 빗나갔는지를 추적할 수 없다면, 비용 최적화나 성능 튜닝은 감에 의존할 수밖에 없다.
물론 OpenTelemetry(OTel) 익스포트 같은 표준 관측 경로가 있다는 반론이 나온다. 저자도 이를 알고 있지만 그것만으로는 부족하다고 보며, 당장 떠오르는 이유만 다섯 가지가 더 있다고 말한다. 다만 그 목록을 구체적으로 나열하지는 않는다. 요지는 분명하다. 표준 익스포트는 하나의 선택지일 뿐, 데이터의 수집 지점과 가공 방식, 보관 위치까지 내가 통제하는 것과는 다른 문제라는 것이다.
프록시를 '직접' 운영한다는 의미
저자가 제시하는 대안은 LLM 프록시를 스스로 운영하는 것이다. 프록시는 애플리케이션과 모델 제공자의 API 사이에 놓이는 중계 계층으로, 오가는 모든 요청과 응답, 토큰 수, 캐시 상태 같은 메타데이터를 가로채 기록한다. 중요한 전제는 '내가 통제하는 곳'에서 돌려야 한다는 점이다. 저자는 특정 프록시 제품을 추천하지 않으며, 무엇을 고르든 직접 수정할 수 있다는 사실을 잊지 말라고 덧붙인다. 실제로 그는 더 나은 관측을 위해, 커스텀 MCP 서버 엔드포인트를 붙이기 위해, 그리고 추가 기능을 위해 자신의 프록시를 손봐 왔다고 밝힌다. 오픈된 중계 계층을 쓰면 벤더가 제공하지 않는 가시성을 스스로 설계해 넣을 수 있다는 것이다.
이 접근의 실효성을 보여주는 구체적 사례가 캐시 미스다. 코딩 세션 도중 캐시 미스가 발생하면, 저자는 그 원인을 손으로 20초 안에 짚어낸다고 말한다. 아직 자동화하지는 않았지만 자신이 쓰는 프록시에 API가 있어 자동화가 가능하다는 점도 언급한다. 프롬프트 캐싱이 비용과 지연에 직접적인 영향을 주는 환경에서, 미스의 원인을 즉시 특정할 수 있다는 것은 단순한 편의가 아니라 운영 비용을 좌우하는 역량이다.
소유의 문제, 그리고 한계
결국 저자가 강조하는 것은 인프라와 애플리케이션 가시성, 데이터 경로, 저장소를 모두 내가 소유하라는 것이다. 집에서는 재미와 학습을 위해, 회사에서는 '그렇게 하지 않으면 일을 제대로 하는 것이 아니기 때문에' 그렇게 한다고 그는 말한다. 한국의 실무 환경에 대입하면 이 주장은 비용 관측을 넘어 데이터 거버넌스와도 맞닿는다. 어떤 데이터가 외부 API로 흘러가는지, 그 기록이 어디에 남는지를 조직이 직접 관리할 수 있다면, 민감 정보 통제나 감사 대응에서 운신의 폭이 넓어진다.
다만 이 글은 개인 블로그의 관점이며 몇 가지 유보가 필요하다. 저자 스스로 LLM의 내부 동작을 화이트보드에 그려 설명할 만큼 이해하지 못할 수도 있다고 인정한다. 그가 말하는 것은 모델에 대한 이해가 아니라 추론을 서빙하는 과정을 계측해 통제하는 운영의 영역이다. 프록시를 자체 운영하면 중계 계층의 유지보수, 장애 지점 증가, 보안 관리라는 비용이 따라붙는다는 점도 글에서 직접 다루지는 않는다. 또한 특정 솔루션을 지목하지 않으므로, 도입하려는 조직은 자신의 트래픽 규모와 규제 요건에 맞춰 직접 검증해야 한다. 그럼에도 '내가 돌리지 않으면 무슨 일이 벌어지는지 알 수 없다'는 문제 제기 자체는, LLM을 프로덕션에 올리는 팀이라면 한 번쯤 정직하게 마주할 가치가 있다.