팀에서 LLM API 를 쓸 때 키를 나눠 주지 말고 게이트웨이를 두자

팀에서 LLM API 를 쓰기 시작하면 가장 먼저 생기는 문제는 모델 선택이 아니라 키 관리다. 벤더 키를 메신저로 돌리고, 각자 PC 의 설정 파일에 넣고, 누가 얼마를 썼는지 아무도 모른다. 작은 중계 서버(게이트웨이) 하나로 이 문제를 정리한 경험을 적는다.

하는 일

각자의 도구 ──(게이트웨이 토큰)──▶ 게이트웨이 ──(벤더 키)──▶ LLM API
                                      │
                             사용량·비용 기록, 상한 검사

• 벤더 키는 게이트웨이 서버에만 둔다. 사용자에게는 게이트웨이가 발급한 토큰을 준다. 토큰은 언제든 개별로 끊을 수 있고, 벤더 키는 한 번도 서버 밖으로 나가지 않는다.
• 요청은 손대지 않고 그대로 넘긴다. 경로 앞부분으로 벤더를 고르고 나머지는 그대로 전달한다. 스트리밍 응답도 그대로 흘려보낸다. 게이트웨이가 요청 형식을 해석하지 않으니 벤더가 새 기능을 내도 고칠 것이 없다.
• 토큰마다 라벨과 일일 상한을 둔다. "이 토큰은 하루 얼마까지". 실수로 반복 호출을 걸어도 피해가 상한에서 멈춘다.
• 응답의 사용량 정보를 읽어 비용을 기록한다. 누가, 어떤 모델로, 얼마를 썼는지가 남는다.

클라이언트는 한 줄만 바꾼다

공식 SDK 는 대부분 접속 주소를 바꿀 수 있다. 주소를 게이트웨이로, 키 자리에 게이트웨이 토큰을 넣으면 나머지 코드는 그대로다.

const client = new Anthropic({
  baseURL: 'https://llm.example.com/anthropic',
  apiKey: process.env.GATEWAY_TOKEN,
});

만들면서 겪은 것

• 비용 집계는 사고 토큰을 따로 더해야 맞는다. 벤더에 따라 사용량 정보에서 답변 토큰과 사고 토큰이 다른 필드로 온다. 하나만 보면 비용이 실제의 몇 분의 일로 찍힌다.
• 단가표에 없는 모델은 최고 단가로. 단가표는 수동 관리라 새 모델에 뒤처진다. 0원으로 계산하면 일일 상한이 조용히 무력해진다.
• 상태 파일이 조용히 안 써졌다. 컨테이너를 루트가 아닌 사용자로 돌리는데, 이름 있는 볼륨은 루트 소유로 만들어진다. 사용량 기록이 권한 오류로 실패하고 있었는데 오류가 겉으로 드러나지 않았다. 이미지를 만들 때 그 디렉터리를 미리 만들고 소유자를 바꿔 두면 새 볼륨이 그 소유권을 물려받는다. 이미 만들어진 볼륨은 지우고 다시 만들어야 했다.

  RUN mkdir -p /state && chown node:node /state
  USER node

• 오류 응답에 내부 정보를 싣지 않는다. 상태 확인 주소와 오류 메시지에는 어떤 벤더와 연결돼 있는지, 키가 어떤 상태인지를 넣지 않았다.

게이트웨이가 풀어 주지 않는 문제

프롬프트에 담긴 내용은 결국 외부 서비스로 나간다. 게이트웨이는 누가 얼마나 보냈는지는 알려 주지만, 보내도 되는 내용인지는 판단해 주지 않는다. 사내 코드나 고객 데이터를 다루는 도구를 붙일 때는 그 저장소와 데이터가 외부 전송이 허용된 것인지를 먼저 확인해야 한다. 우리는 코드 원문 대신 구조 요약(함수와 선언의 이름)만 보내는 모드를 따로 만들었는데, 비용 절감 효과는 거의 없었고 오직 이 목적으로만 쓸모가 있었다. 그리고 이런 도구의 도입 자체는 조직의 보안 정책 안에서 합의하고 진행할 일이다.

정리

게이트웨이는 백 줄 남짓한 프록시로 시작할 수 있다. 키가 한 곳에만 있고, 사람마다 상한이 있고, 사용량이 보인다. 이 세 가지만으로도 "누가 키를 깃에 올렸다"와 "이번 달 청구서가 왜 이래"라는 두 가지 사고를 예방한다.