Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 05. 09:41

API 키를 삭제했는데 아무것도 고장 나지 않았다

요약

Tailscale의 새로운 LLM 게이트웨이인 Aperture를 사용하여 API 키 관리의 복잡성을 해결하는 방법을 소개합니다. Aperture는 프록시 역할을 통해 더미 키를 실제 키로 교체하고, 모델 라우팅 및 비용 로그를 통합 관리합니다.

핵심 포인트

  • Aperture는 API 키를 직접 노출하지 않는 프록시 게이트웨이임
  • Tailscale의 신원 기반 인증을 통해 환경 변수 관리 부담을 제거
  • OpenAI 형식의 요청을 통해 다양한 LLM 제공업체로 라우팅 가능
  • 기존 Tailscale 인프라를 활용하여 추가 인프라 구축 없이 도입 가능

최근 내 서버들을 살펴보며 조용한 불안함을 느꼈다. LLM (Large Language Model)과 통신하는 모든 머신은 각자 자신만의 API 키 세트를 가지고 있었다. DeepSeek, Gemini, OpenRouter 등이 VPS 인스턴스와 웹 앱 전반에 흩어져 있었다. 새로운 프로젝트가 추가될 때마다 복사본은 더 늘어났다. 키를 교체(rotate)하고 싶다면, 그 키가 어디에 있는지 모든 장소를 기억해야만 했다.

그러다 Aperture를 발견했다.

Aperture의 실체

Aperture는 현재 베타 버전인 Tailscale의 LLM 게이트웨이(gateway)이다. 이름은 플랫폼처럼 들리지만, 실제로는 더 단순한 것, 즉 **프록시 (proxy)**이다.

사용자의 앱은 더미(dummy) API 키(-)를 사용하여 게이트웨이에 OpenAI 형식의 요청을 보낸다. Aperture는 이를 수신하여 세 가지 작업을 수행한다:

  1. 인증 교체 (Auth swap) — 더미 키를 자신의 볼트(vault)에 있는 실제 키로 교체한다.
  2. 라우팅 (Route) — 모델 이름을 읽고 적절한 제공업체(provider)로 전달한다.
  3. 로그 (Log) — 통합 대시보드를 위해 토큰과 비용을 기록한다.
사용자 앱                 Aperture 게이트웨이          DeepSeek API
   │                          │                        │
   │  POST /v1/chat/          │                        │
...

Aperture는 사용자의 Tailscale tailnet에서 실행되기 때문에, 인증은 신원(identity) 기반으로 이루어진다. 서버가 네트워크에 있다는 사실 자체가 곧 권한 부여(authorization)가 된다. 환경 변수(environment variables)를 통해 API 키가 돌아다닐 필요가 없다.

Tailscale에 대한 의문

중요한 무언가를 위해 Tailscale에 의존한다고 말할 때마다, 나는 항상 똑같은 시선을 받는다. "한 회사에 너무 많은 신뢰를 두고 있군요."

타당한 직관이다. 하지만 Tailscale의 데이터 평면(data plane)은 Linux 커널에 있는 것과 동일한 프로토콜인 WireGuard이다. 만약 Tailscale이라는 회사가 내일 사라지더라도, 다음 키 교체 시점까지 연결은 계속 작동할 것이다. 완전한 독립성을 원한다면 오픈 소스 제어 서버인 Headscale을 실행할 수도 있다.

키 배포, ACL, MagicDNS와 같은 제어 평면(control plane)이 바로 Tailscale이 가치를 더하는 부분이다. 그리고 이 제어 평면은 강력한 실적을 보유하고 있다: 수백만 대의 장치, 그리고 가동 시간(uptime)을 중요하게 생각하는 기업들의 운영 환경에서 사용되고 있다.

더 실무적인 관점에서 보자면: 만약 여러분이 이미 Tailscale을 사용 중이라면 (저 역시 서버, Jetson, 홈 디바이스 모두에서 사용 중이었습니다), Aperture는 새로운 인프라를 전혀 추가하지 않습니다. 이미 보유하고 있는 인프라 위에서 동작합니다.

마이그레이션: 단 6줄

저는 세 가지 LLM 제공업체를 사용하는 웹 앱을 운영하고 있었습니다. 텍스트 보강(text enrichment)을 위한 DeepSeek, 이미지 분석을 위한 Gemini, 그리고 비전(vision)을 위한 OpenRouter였습니다. 각 제공업체는 자신만의 클라이언트 팩토리(client factory)를 가지고 있었습니다:

# 이전: 세 개의 제공업체, 세 개의 기본 URL(base URL), 세 개의 API 키
def _get_gemini_client():
    return OpenAI(
...

이후:

# 이후: 모두 하나의 게이트웨이를 통해, 하나의 주소로, 키 없이
def _get_gemini_client():
    return OpenAI(base_url="http://aperture/v1", api_key="-")
...

단 6줄이 변경되었습니다. 세 개의 base_url 값과 세 개의 api_key 값입니다. 이것이 마이그레이션의 전부입니다.

그다음에는 거의 무모하게 느껴지는 단계가 왔습니다. 서버에서 키를 삭제한 것입니다. .env 파일의 항목이 6개에서 2개로 줄었습니다:

이전:  GEMINI_API_KEY, DEEPSEEK_API_KEY, OPENROUTER_API_KEY,
       XAI_API_KEY, JWT_SECRET, TAVILY_API_KEY
이후:   JWT_SECRET, TAVILY_API_KEY

남겨둔 두 개는 LLM 키가 아닙니다. JWT는 로컬 서명 비밀값(signing secret)이며, Tavily는 자체 형식을 가진 웹 검색 API입니다. Aperture는 OpenAI 호환 채팅 완성(chat completions)만을 프록시(proxy)합니다.

서비스를 재시작하고 API를 호출했습니다. 작동했습니다. 첫 번째 시도에 성공했습니다.

단 하나의 예외

한 대의 머신은 직접 연결 상태를 유지합니다: 제 AI 에이전트(AI agent)가 실행되는 서버입니다.

이것은 순환 의존성(circular dependency) 문제입니다. 만약 Aperture가 다운되면, 이를 디버깅하기 위해 에이전트가 온라인 상태여야 합니다. 만약 에이전트가 Aperture를 통해 라우팅되는데 Aperture가 고장 난다면, 저는 아무것도 할 수 없는 상태(dead in the water)가 됩니다. 진단도 불가능하고, 수정도 불가능하며, 오직 SSH를 통한 복구만 가능해집니다.

규칙은 다음과 같습니다: 제어 평면(control plane)은 직접 연결을 유지하고, 그 외 모든 것은 게이트웨이를 통해 라우팅한다. 한 대의 머신에 DeepSeek 키 하나를 두는 것은 저렴한 보험입니다.

새 서버에 Tailscale 자동화하기

마지막 단계: 이를 새로운 머신에서도 마찰 없이(zero-friction) 사용할 수 있도록 만드는 것입니다. Aperture를 통한 라우팅에 Tailscale이 필요하다면, 새 서버에 Tailscale을 추가하는 과정 또한 고통이 없어야 합니다.

Tailscale에는 이를 위한 기능인 **인증 키 (auth keys)**가 있습니다. 대화형 브라우저 로그인과 달리, 사전 승인된 인증 키를 사용하면 다음과 같이 tailnet에 참여할 수 있습니다:

tailscale up --authkey=tskey-auth-...

브라우저도 필요 없고, 사람이 개입할 필요도 없습니다. 일회용 키를 생성하거나 재사용 가능한 키를 생성할 수 있는데, 재사용 가능한 키는 자동화에 이상적이며 매번 새로운 키를 생성하지 않고도 서버를 프로비저닝(provisioning)할 수 있게 해줍니다. 또한 tag:server와 같은 태그를 미리 할당하여 ACL 규칙을 자동으로 적용할 수도 있습니다.

제 설정의 경우, 에이전트의 자격 증명 저장소(credential store)에 재사용 가능한 인증 키를 저장합니다. tailnet에 서버를 추가하는 것은 단 한 줄의 명령어로 끝납니다. 서버가 온라인 상태가 되면 MagicDNS가 게이트웨이를 자동으로 해석하며, 즉시 LLM 트래픽을 라우팅할 수 있습니다. 키를 배포할 필요도, 수동 설정을 할 필요도 없습니다.

내가 배운 것들

  1. Aperture는 생각보다 작습니다. 이것은 플랫폼이 아닙니다. 기존 Tailscale 네트워크 상의 프록시(proxy)입니다. 가치 대비 복잡성 비율(value-to-complexity ratio)이 이례적으로 높습니다.

  2. "하나의 URL을 통해 모든 제공자(provider)를 사용한다"는 것은 해방감을 줍니다. 세 개의 클라이언트 팩토리(client factories)가 세 줄의 동일한 코드로 압축되었습니다. 게이트웨이에 제공자를 한 번만 추가하면 모든 앱이 이를 사용할 수 있습니다.

  3. 프록시 모델은 신뢰의 구조를 역전시킵니다. 모든 서버에 모든 키를 신뢰하도록 맡기는 대신, 하나의 게이트웨이를 신뢰합니다. 게이트웨이는 실제 자격 증명(credentials)을 보유하는 유일한 장소입니다.

  4. 제어 평면 (control plane)을 이를 통해 라우팅하지 마세요. 만약 디버깅 도구가 자신이 디버깅해야 할 대상에 의존하게 된다면, 문제를 해결하기 위해 물리적 접근이 필요한 상황을 만들게 됩니다.

  5. 인증 키는 Tailscale를 제로 터치 (zero-touch)로 만듭니다. 재사용 가능한 키를 사전 승인해 두면, 서버 추가는 단 한 줄의 명령어로 가능합니다. 브라우저도, 로그인 흐름도, 사람이라는 병목 현상도 없습니다.

  6. 모든 것이 게이트웨이에 속할 필요는 없습니다. LLM이 아닌 서비스(검색 API, 암호화 비밀값 등)는 여전히 자체적인 키가 필요합니다. Aperture는 엄격하게 채팅 완료 (chat-completion) 프록시입니다.

  7. 진정한 승리는 방지된 확산 (sprawl)에 있습니다. 제가 삭제한 키들은 제가 알고 있던 키들이었습니다. 진짜 가치는 이제 기본 설정이 "게이트웨이를 통해 라우팅"이 되었기 때문에, 앞으로 제가 배포할 일이 결코 없을 키들에 있습니다.

Hermes Agent로 제작되었습니다. X에서 @MariaTanBoBo를 팔로우해 주세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0