LLM 프록시를 직접 운영하지 않으면 무슨 일이 벌어지는지 어떻게 아세요?

요약

LLM을 쓸 때는 직접 운영하는 LLM 프록시를 거쳐야 사용 내역을 제대로 볼 수 있습니다.

개발자 재러드 시걸의 주장입니다. 대부분의 사람이 구독형 서비스 화면으로 LLM을 쓰지만, 업체가 주는 분석 화면만으로는 엔지니어가 판단에 쓸 사용량 자료를 얻을 수 없다고 봤습니다.

왜 중요한가

LLM 사용 기록을 업체 대시보드에 맡기지 말고 직접 쌓아 두고 들여다보자는 제안입니다.
특정 제품을 고르라는 말이 아닙니다. 인프라와 데이터가 오가는 경로를 스스로 소유하라는 원칙을 강조합니다.

핵심 내용

업체의 분석 화면은 시간대별 토큰 사용량 같은 자료를 주지 않아 판단 근거로 쓰기 어렵다고 했습니다.
자체 프록시는 여러 업체와 모델을 엔드포인트(요청을 받는 주소) 하나로 묶어 모델을 빠르게 바꾸게 해 줍니다.
어떤 키가 어느 클라이언트에서 언제 어떤 모델을 불렀고 결과가 어땠는지 로그로 남습니다.
가상 API 키를 쓰면 원래 키를 업무, 에이전트, 하네스(에이전트 실행 도구)마다 퍼뜨리지 않아도 됩니다.
코딩 중 캐시 미스(저장된 결과를 재사용하지 못한 경우)의 원인을 프록시 기록으로 20초 만에 찾았다고 합니다.

HN 반응

Codex와 Claude Code의 OpenTelemetry 기록이면 충분하고 프록시는 장애 지점이 된다는 반론에, 지출 한도는 프록시로 막아야 한다는 재반론이 맞섰습니다.
API 키로 쓰면 월 200달러 구독 한도만큼을 2~3일 만에 쓴다는 경험담을 두고, 구독료가 보조금 덕에 싸다는 의견과 토큰값은 오히려 내려간다는 반박이 오갔습니다.

30개 표시 · 전체 209개

CharlieDigital15시간 전 HN

이걸 하는 데 프록시는 필요 없습니다. 오히려 프록시를 쓰지 말아야 한다고 봅니다. 결국 생산성이 지나가는 길목에 단일 장애점이 하나 생기는 셈이니까요.

Codex[0]와 Claude Code[1]는 둘 다 OTEL 트레이스를 내보내고, 이걸 받아서 처리하면 됩니다.

OpenCode, Pi 같은 다른 하네스는 플러그인 구조에 끼어들어 플러그인으로 직접 OTEL 전송을 구현하면 됩니다(또는 이미 나와 있는 플러그인[2]을 써도 됩니다).

OpenTelemetry 컬렉터[3][4]를 직접 띄우거나, 이미 쓰고 있는 수집 인프라(예: Datadog(이해관계 없음), AppInsights 등)를 활용하세요.

OTEL 트레이스에는 필요한 정보가 다 들어 있습니다. 도구 호출, 전체 프롬프트, 토큰 사용량과 비용 같은 것들요. 덜 침습적이고 단일 장애점도 되지 않습니다. OTEL 전송과 수집은 최선형(best-effort)이라, 일부가 유실돼도 생산성에는 손해가 없습니다. 반면 프록시는 고장 나거나 과부하가 걸리면 문제가 풀릴 때까지 팀 전체가 발이 묶입니다. OTEL 트레이스 몇 개쯤 잃어도 괜찮습니다.

Codex와 CC에서 이걸 켜는 설정은 아주 간단합니다([0][1]과 [5] 참고).

--

[0] https://learn.chatgpt.com/docs/config-file/config-advanced#observability-and-telemetry

[1] https://code.claude.com/docs/en/monitoring-usage

[2] https://github.com/DEVtheOPS/opencode-plugin-otel

[3] 오픈소스 컬렉터: https://opentelemetry.io/docs/collector/

[4] 노이즈를 걸러내는 설정 예시: https://github.com/zeeq-ai/zeeq-app/blob/main/build/otel-collector-config.gcp.yaml#L67-L102

[5] .codex/config.toml과 .claude/settings.json 구체적인 예시: https://zeeq.ai/docs/key-features/session-telemetry#configuring-codex
ProjectBarks12시간 전 HN

OTEL에 대한 정당한 비판이 되지 않을까요? 하네스가 보여주기로 한 것만 볼 수 있다는 점 말이에요.

AI 회사들이 CC/Cursor 대체품을 내놓고는 절대 수집하면 안 될 데이터를 수집한 스캔들이 여러 번 있었잖아요. 구체적으로 Z.ai [0], 바이트댄스의 Trae [1], 알리바바의 Qwen [2]이 그렇습니다. 그러니 모든 하네스를 샌드박스에 넣고 네트워크 전체를 모니터링해야 한다는 쪽으로 논의가 가야 할지도 몰라요.

저라면 AI 하네스는 전부 네트워크 로깅을 켠 VM에서 돌리겠어요. 하네스를 통해 보내는 데이터를 신뢰할 수 없다는 것도 문제지만, 하네스가 어떤 데이터에 접근하는지도 감사해야 하니까요.

[0] https://www.chosun.com/english/industry-en/2026/09/22/ABYLC3M64FH5RIP2XFNL3XU5DA/

[1] https://github.com/segmentationf4u1t/trae_telemetry_research

[2] https://github.com/QwenLM/qwen-code/issues/11198
JustFinishedBSG10시간 전 HN

하네스를 직접 소유하고 있다면(그래야 하고요) 원하는 건 전부 볼 수 있어요.

그리고 eBPF로 텔레메트리를 수집해서 OTEL로 보내는 방식도 본 적이 있어요.
dinm9시간 전 HN

때로는 아주 해키한 방법까지 가기도 합니다. Laminar에서 Claude Agent SDK에 대해 했던 게 그런 경우입니다. 프로세스 안에 작은 프록시를 띄워 요청과 응답을 가로채고, 그 내용을 OTEL 트레이스로 내보냅니다. Python/JS SDK가 우리 프록시를 anthropic URL로 믿게끔 주소를 바꿔 놓으면, 프록시가 요청을 다음 단계로 전달합니다. 예전에 이 내용을 글로 썼습니다[1]. 우아한 방법은 분명 아니지만 대체로 잘 동작합니다.

[1] https://laminar.sh/blog/2025-12-03-claude-agent-sdk-instrumentation
pavelmelnichuk11시간 전 HN

Otel은 LLM 프록시가 해결해 주는 일의 4분의 1에 불과합니다. 에이전트가 엉뚱한 토끼굴로 들어가서 눈치채기도 전에 100달러를 태워 버리면 어떻게 하나요? Otel로 사후에 확인할 수 있는 건 좋지만, LLM 프록시를 직접 호스팅하면 그런 사고 자체를 막을 수 있습니다.

뻔뻔한 홍보를 하자면, 바로 이런 이유로 제가 Relay를 만들고 있습니다. 에이전트가 무엇을 하고 있고 얼마를 쓰는지 실시간으로 볼 수 있고, 하드 리밋을 걸어서 지출이 걷잡을 수 없이 불어나지 않게 할 수 있습니다. 그 밖에도 프록시가 제공하는 기능이 많습니다.

오픈소스이고 셀프 호스팅도 가능합니다.

https://github.com/anchorshell/relay https://anchorshell.com/
CharlieDigital9시간 전 HN

그건 MCP나 훅으로도 할 수 있어요.
pavelmelnichuk3시간 전 HN

아니요, 그렇지 않아요. 예를 들어 Relay에는 모델 "그룹"이 있어서, 하나가 죽으면 다른 모델로 넘어가는 폴백을 두거나, 일일 한도가 남아 있는 동안은 무료 엔드포인트를 우선 쓰게 할 수 있어요.

라우팅을 결정하는 모델이 필요할 수도 있고, 엔터프라이즈 고객용으로 응답 전후에 가드레일 성격의 모델을 두고 싶을 수도 있고요.
T-RN-R14시간 전 HN

공개합니다. 저는 Origin[1]에서 일하고 있습니다. 저희는 프록시나 LLM 게이트웨이 없이 OTEL과 그 밖의 트레이스를 수집하는 기업용 플랫폼을 만들었습니다. 로컬 추론 워크로드에서 나오는 트레이스까지 수집할 수 있습니다.

지원하는 도구에서는 프롬프트, 응답, 도구 호출을 수집하고, 이를 사용자와 조직 맥락, 그리고 실제로 그 머신에서 일어난 일과 연결합니다. 이렇게 모은 데이터로 에이전트(또는 에이전트를 운용하는 사람)가 나쁜 짓을 할 때 탐지할 수 있습니다[2].

--

[1] https://www.originhq.com/

[2] https://www.originhq.com/investigations
NeutralWanted1일 전 HN

저도 이런 걸 해 보거나 API 키를 쓰고 싶긴 한데, 사람들이 구독 대신 API 키를 쓰는 비용을 어떻게 정당화하는지 아직도 모르겠어요.

한 번 테스트해 봤는데, 저는 Claude Max 20x(월 200달러)를 쓰고 있고 매주 주간 한도를 다 쓰거나 거의 다 쓰거든요. 그런데 API 키로는 200달러를 쓰는 데 이틀에서 사흘밖에 안 걸렸어요.
bob102920시간 전 HN

많은 경우 토큰이 불어나는 건, 자율 에이전트 떼가 한 문제를 두고 "협업"하기 때문이라고 생각합니다. 사람이 개입하는 일관된 에이전트 루프 하나를 쓰는 건 덜 미래적으로 느껴질 수 있지만, (지금은) 더 효과적이고 효율적입니다.

사람들은 크게 두 부류로 나뉩니다. 이런 도구를 기술적 호기심의 대상으로 보는 사람과, 특정 목적을 이루는 수단으로 보는 사람입니다. 저는 정해진 조건 안에서 일을 끝내면 정해진 금액을 받는다는 걸 알고 있습니다. 걸린 돈이 실제로 있다면, 아주 좋은 에이전트 루프 하나에 사람이 끼어 있는 쪽(HITL)을 훨씬 선호합니다. 재미 삼아, 호기심으로, 탐색하는 용도라면(그것도 좋습니다!) 구독이 더 안심될 수 있습니다. 현실판 Factorio를 돌리면 비용이 아주 많이 들 수 있습니다.

저는 API 토큰이 성능도 더 좋다고 생각하지만, 동료들의 결과물과 제 결과물의 품질을 비교해서 본 것 말고는 증거가 전혀 없습니다. 지금은 선불 토큰에 거의 종교적인 열정을 갖고 있습니다. 저는 지금도 Visual Studio에서 무거운 작업은 대부분 copilot에 커스텀 모델 설정으로 GPT5.5를 붙여 씁니다. 충분하고도 남습니다. 월평균 토큰 비용은 100달러 미만입니다. 제 수요는 예측과 통제가 가능하기 때문에, 구독을 하면 오히려 더 비쌉니다.

이건 변동 요금제와 고정 요금제 전기의 관계와 비슷합니다. 수요 측을 통제할 방법만 안다면, 실시간 도매가를 내는 쪽이 경제적으로 엄청난 이점이 됩니다.
user4392816시간 전 HN

AI와 직접 더 손을 많이 대며 일하는 자기만의 방식이 가장 효율적이고 합리적이라는 의견을 자주 봅니다.

회사 밖에서 모바일 앱 프로젝트에 500시간을 쓴 경험으로 자신 있게 말할 수 있는데, 제 프로젝트에서는 대화를 2개에서 10개까지 열어 작업을 병렬화하는 쪽이 훨씬 효과적입니다.

API로 제공되는 모델은 구독으로 쓰는 모델과 같습니다. 특히 품질에 관해서는 꼼수가 전혀 없습니다.

그리고 GPT 5.5는 당시엔 훌륭했고 저도 프로젝트에서 많이 썼지만, 이미 오래된 모델이고 곧 퇴역합니다.

그리고 copilot에서 쓴다고 하셨는데, 그건 버그투성이에 비효율적이어서 답답한 3류 하네스입니다.

Claude Code의 Opus 5.5와는 비교가 안 됩니다.

본인에게 맞는 걸 쓰시면 되지만, 솔직히 새로운 걸 한번 써 보셨으면 합니다.
dinosaurdynasty12시간 전 HN

모델은 같아도 시스템 프롬프트는 같지 않아요.
catchnear432115시간 전 HN

저는 이 말이 맞다고 보지 않습니다. 동료들 사이의 작업 품질 차이는 스레드를 몇 개 돌리느냐가 아니라, 각각에 얼마나 주의를 기울이느냐에서 갈립니다. 그건 기술입니다.

I know that if I finish a task with a certain set of constraints that I will get paid a certain amount of money. (정해진 조건 안에서 일을 끝내면 정해진 금액을 받는다는 걸 알고 있습니다.)

그러니까 월급이 아니라는 거군요. 그렇다면 어느 정도 설명이 됩니다. 건당 보수를 받는다면 접근 방식도 영향을 받을 수 있겠죠. 그런데 작업이 많을수록 보수도 늘어난다고 생각할 수도 있으니, 좀 헷갈립니다.

I also think the API tokens perform better but I have zero evidence other than observing the quality of my work product relative to that of my peers. I have almost a religious fervor about using prepaid tokens now (저는 API 토큰이 성능도 더 좋다고 생각하지만, 동료들의 결과물과 제 결과물의 품질을 비교해서 본 것 말고는 증거가 전혀 없습니다. 지금은 선불 토큰에 거의 종교적인 열정을 갖고 있습니다.)

이게 나머지 절반인 것 같습니다. 에이전트에 푹 빠져 지내는 방식에 비해 덜 미래적으로 보이는 것도 아니고, 그저 형태가 다를 뿐입니다.
rrr_oh_man18시간 전 HN

> This is analogous to variable vs fixed rate electricity. Paying the real time wholesale price is a massive economic advantage if you can figure out how to control the demand side of the house. (이건 변동 요금제와 고정 요금제 전기의 관계와 비슷합니다. 수요 측을 통제할 방법만 안다면, 실시간 도매가를 내는 쪽이 경제적으로 엄청난 이점이 됩니다.)

도매 전기가 거의 항상 더 싸요.

죄송한데, 저도 그런 사람이 돼야겠네요... https://xkcd.com/386/
dgellow18시간 전 HN

두 분 다 같은 말씀 하시는 거 아닌가요?
sehansen16시간 전 HN

rrr_oh_man이 주장하는 건 도매 고정 요금 전기가 일반적으로 가정용 변동 요금 전기보다 싸다는 거예요. 아니면 도매라는 요소가 변동 요금이라는 요소보다 상위 개념이라는 거고요. 큰 문제는 아니에요. bob1029의 요지는 어느 한쪽이 도매냐 아니냐에 달린 게 아니니까요. 좀 좁고 (이 경우엔) 별 의미 없는 지적이지만, 그래도 맞는 지적이긴 해요.
rrr_oh_man3시간 전 HN

> It's just a somewhat narrow, (in this case) inconsequential, but also valid, nitpick. (좀 좁고 (이 경우엔) 별 의미 없는 지적이지만, 그래도 맞는 지적이긴 해요.)

맞아요! 이해해 주셔서 고마워요! 그래서 386번을 걸어 둔 거예요 :)
rrr_oh_man17시간 전 HN

제가 표현을 제대로 못 했네요.

그 비유는 틀렸습니다.

가정용 전기는 kWh당 가격이 매겨지고, 도매 전기도 kWh당 가격이 매겨지는데, 후자가 대체로 더 쌉니다. 고정 요금과 변동 요금의 문제가 아닙니다.
lesuorac16시간 전 HN

Domestic electricity is priced per kWh (가정용 전기는 kWh당 가격이 매겨집니다)

wholesale electricity is priced per kWh (도매 전기도 kWh당 가격이 매겨지는데)

the latter is, as a rule, cheaper. (후자가 대체로 더 쌉니다.)

세부 사항을 놓치신 것 같은데요. “킬로와트시당 가격이 매겨진다”는 두 가지가 왜 반드시 가격이 달라야 하죠?
rrr_oh_man16시간 전 HN
어쩌면 우리가 서로 다른 얘기를 하는 걸 수도 있겠네요. 저는 무언가를 주장하거나 전제하는 게 아닙니다. 이건 그냥 현실입니다.
```
  Average Revenues/Sales (¢/kWh)

End-use sector    July 2026
  Residential           18.31
  Commercial            14.53
  Industrial             9.77
  Transportation        14.97
  --
  Total                 14.99
```
출처: https://www.eia.gov/electricity/monthly/update/end-use.php

이유는 대체로 소비량이 많을수록 평균 가격이 낮아지기 때문입니다.
james_marks12시간 전 HN

시간대 변수도 있지 않나요? 그러면 예컨대 계속 가동하는 산업 시설의 평균은 더 낮아질 텐데요.
NortySpock11시간 전 HN

평균에 가려져서 그건 안 보이겠죠.

산업용이나 상업용 계약에 따라 다르지만, 맞아요.

그리고 저희 주는 최근에 모든 주민을 어떤 형태로든 시간대별 요금제에 넣도록 의무화했어요.
dcss_gardener1일 전 HN

요즘 나오는 플래시 모델은 Opus보다는 Sonnet에 가깝지만 가격이 아주 착합니다.

현실은 구독이 상당히 보조받고 있다는 겁니다. 돈을 태우는 프런티어 연구소가 운영하지 않는 구독은 거의 다 지난 몇 달 사이에 없애거나, 가격을 크게 올리고 한도를 낮췄습니다. 싼 토큰은 고객 확보 수단이지 진짜 상품이 아닙니다. 과격하게 들리겠지만 정말로 마약상의 판매 깔때기와 똑같습니다.

언젠가는 진짜 가격이 당신 앞에 떨어질 테고, 그만큼을 낼 방법을 찾거나 훨씬 싼 곳에 돈을 내야 할 겁니다. 지금 파악해 두는 편이 낫습니다.
Aurornis22시간 전 HN

At some point they're going to drop the real prices in your lab (언젠가는 진짜 가격이 당신 앞에 떨어질 테고)

특정 지능 수준의 토큰에 대한 실제 가격은 빠르게 떨어지고 있습니다. 모델이 좋아지고 새 하드웨어가 빨라지는 걸 감안하면, 가격은 오르지 않고 내려갈 거라고 봅니다.

Better to get a handle on it now. (지금 파악해 두는 편이 낫습니다.)

저는 여러 제공업체와 모델을 실험해 보는데, 가격이 오를지도 모른다는 이유로 지금부터 갈아타기 시작해야 한다는 주장에는 강하게 반대합니다.

말이 안 됩니다. 가격 인상은 일어나면, 일어난다면 그때 대응하면 됩니다.

모델이나 제공업체를 바꾸는 건 그리 큰 일이 아닙니다. 새 모델이나 새 하네스로 갈아타서 하루 이틀이면 감을 잡을 수 있습니다. 준비와 계획이 필요한 거창한 작업이 아닙니다.

가격이 오르면 그때 뭔가 시도해 보면 됩니다. 그전까지는 걱정하지 마세요.
qlte21시간 전 HN

Claude Code 구독이 본격적으로 인기를 끌 무렵, HN에서는 앤트로픽의 최종 목표가 개발 관련 직군 거의 모두가 월 200달러짜리 코딩 플랜을 결제하게 만드는 것이라는 의견이 유력했습니다.

그런데 앤트로픽과 오픈AI가 보조를 맞추듯 기업용 가격 체계를 만들었고, 대기업들이 상대적으로 저렴한 월 200달러 대신, 하루 200달러까지도 쓸 수 있는 API 가격을 내도록 노골적으로 압박했습니다.

지능 대비 토큰 가격이 시간이 지나며 내려가는 추세라고 해도, 가격 체계가 실제로 더 낮은 비용으로 이어진다는 뜻은 아닙니다. 특히 캐시카우인 B2B 시장에서는 더욱 그렇습니다.
Aurornis13시간 전 HN

API와 구독의 구분은 늘 있었어요. 그걸 왜 미끼 상술처럼 말씀하시는지 모르겠네요.

그리고 그건 제가 한 말을 하나도 바꾸지 않아요. 작업당 상대 가격이나 지능 단위당 가격은 API에서도 내려가고 있으니까요.

Even if token pricing relative to intelligence does trend down over time, that doesn't mean the pricing structure will actually translate to lower costs, particularly in the cash cow B2B market. (지능 대비 토큰 가격이 시간이 지나며 내려가는 추세라고 해도, 가격 체계가 실제로 더 낮은 비용으로 이어진다는 뜻은 아닙니다. 특히 캐시카우인 B2B 시장에서는 더욱 그렇습니다.)

무슨 말씀이세요? API는 구독과 같은 모델을 제공해요. API 가격이 오르고 있다고 생각하시는 게 아니라면(오르지 않았어요) 이 주장은 말이 안 돼요.
xyzsparetimexyz21시간 전 HN

말도 안 돼요. 어떻게 회사들한테 30배를 내게 설득했는지 도저히 이해가 안 가요.
Moto745115시간 전 HN

제 경험상, 윗선이 현장과 동떨어진 회사에서는 이렇게 됩니다. 영업 담당자가 현재 사용자 집단의 월 구독료 대비 토큰 사용량을 보여 주고, 같은 토큰 사용량으로 "더 많은 사용자"를 넣었을 때의 API 가격 견적서를 30% 낮춰서 내미는 거죠. 물론 핵심은, 사용자를 더 늘리고 현 상태에 할인을 해 준다고 해서 기존 사용자들이 토큰을 덜 쓰지는 않는다는 점입니다.

그러다 모든 사용자를 한 제공업체로 통합하고 나면, 청구액이 견적의 2배에서 3배가 되어 있다는 걸 알게 됩니다. 사용자는 더 많은데 평균 토큰 사용량은 같으니, 논리적으로 당연한 결과죠.

전 직장에서 저는 팀 전체를 관리하면서 여러 의무를 맞추기 위해 레거시 앱을 최신 표준으로 옮기는 작업을 많이 했습니다. 회의와 서류 작업 사이사이에 AI로 생성하는 작업이었죠. 이 일이 큰 성공으로 평가받아서, AI와 최신 기술만 다루기로 한 "엘리트 신제품 팀"에서 그 일에 집중하라며 IC 역할로 옮겨 오라는 요청을 받았습니다. 그런데 가 보니 LLM을 쓰고 있는 것처럼 보이려고 하루 12시간, 주 6일을 갈아 넣어 수작업으로 품질 낮은 코드를 찍어내고 있었습니다. 체면을 지키려는 거였죠. 토큰 예산도 없었고, API 환경에서 예산을 제대로 관리할 역량도 없었으니까요. 에이전트 군집에 매달 수천 달러를 쓰던 사람은 이미 해고한 상태였습니다. 3배짜리 예산 문제를 10배에서 30배짜리 예산 지출 문제로 키우기에 완벽한 상황이었습니다.

여러 이유로 그 직장을 떠나 새 직장을 구했는데, 그게 결정타였습니다.
bityard15시간 전 HN

기업 IT 하드웨어와 소프트웨어 구매 쪽을 잘 모르시는군요...
Foobar856818시간 전 HN

회사들은 여전히 자기들한테 지켜야 할 IP가 있다고 믿거든요. 하는 일이 기본적인 CRUD 시스템뿐이거나, 계약 몇 건 갱신 못 하면 무너지기 직전인 곳이라도요.

Hacker News에서 보기 ↗