ElevenAPI를 위한 API 인증 및 키 관리

API 인증은 서비스가 들어오는 요청이 계정에 대해 작업하도록 허용되었는지 확인하는 방식입니다. 예를 들어 ElevenAPI에서는 API 자격 증명이 사용량 기반 크레딧을 소진하거나, 대규모로 음성과 음악을 생성하거나, 일부 배포 환경에서는 민감한 오디오에 접근하는 요청을 승인합니다. 

키가 유출되면 비용이 발생하고 계정에서 콘텐츠를 생성하는 데 사용될 수 있습니다. 또한 플랫폼에 과도한 권한으로 접근할 수 있어 데이터 유출과 기타 공격 경로가 발생할 수 있습니다. 이미 2020년에도 개발자의 90% 이상이 일상 프로세스 중 하나 이상에서 API를 사용했습니다. 이제 모델 컨텍스트 프로토콜(MCP)과 AI 사용이 늘면서 API는 사실상 어디에나 존재합니다.

이 글에서는 API를 올바르게 인증하는 방법과 범위 지정, 로테이션, 조직 차원의 제어, 감사, 사고 대응까지 키의 전체 수명 주기에 걸쳐 관리하는 방법을 다룹니다. 팀에서 API 인증과 키 관리를 제대로 설정하는 데 도움이 됩니다. 읽는 동안 참고할 수 있도록 인증 레퍼런스와 일회용 토큰 레퍼런스를 열어 두세요.

요약

• ElevenAPI는 xi-api-key 헤더라는 단일 시크릿으로 모든 요청을 인증합니다. 즉, 키를 가진 사람은 누구나 크레딧을 사용하고 해당 계정에서 오디오를 생성할 수 있습니다.
• 브라우저, 모바일 앱 또는 사용자가 검사할 수 있는 다른 모든 아티팩트에 장기 API 키를 포함하지 마세요. 직접 제어하는 서버에만 보관하세요.
• 클라이언트 측 사용 사례는 장기 키가 아니라 서버 측에서 발급한 단기 일회용 토큰으로 인증해야 합니다.
• 키에 최소 권한 범위를 지정하고, 환경별로 키를 분리하며, 정기적으로 로테이션하면 유출로 인한 피해 범위를 줄일 수 있습니다.
• 감사와 이상 징후 탐지는 키 유출과 예상치 못한 상황을 방지하는 데 도움이 됩니다.

API 인증이란 무엇인가요?

API 인증은 서비스가 작업을 시작하기 전에 들어오는 요청이 특정 계정에 대해 작업하도록 허용되었는지 확인하는 방식입니다. 요청자가 자격 증명을 제시하면 서비스가 이를 검증하고, 검증이 완료되면 응답을 제공합니다. 

간단히 말해, 다음 질문에 답합니다. 이 요청은 이 계정을 대신해 작업할 권한이 있는가? 이 프로세스는 인증된 요청이 시스템 내에서 수행할 수 있는 작업을 정의하는 API 권한 부여와는 다릅니다.

키 관리란 무엇인가요?

키 관리는 API 키의 전체 수명 주기를 관리하는 폭넓은 실무를 뜻합니다. 키를 생성, 저장, 사용, 로테이션하고 접근 권한을 취소하는 방법을 결정합니다. 이러한 시스템은 API 키의 엔드투엔드 보안을 보장하기 위해 마련됩니다. 

엄격한 키 관리 시스템을 갖추면 키 유출을 방지하고 키가 공개적으로 접근 가능해질 위험을 줄일 수 있습니다. 

API 키 보안이 중요한 이유: 위협 모델

인증과 키 관리의 정의를 살펴봤으므로, 키를 잘못 처리했을 때 무엇이 잘못되는지 정확히 짚어볼 필요가 있습니다. 먼저 위협 모델을 검토하면 이후 살펴볼 모든 실무의 목적이 분명해집니다. 각각은 키 유출 가능성 또는 유출 시 피해를 줄입니다.

ElevenAPI는 xi-api-key 헤더라는 단일 시크릿 기반 메커니즘으로 인증합니다. 키를 보유한 사람은 누구나 승인되며, 요청 자체에 두 번째 인증 요소는 없습니다.

키를 가진 사람은 크레딧을 사용할 수 있습니다. 텍스트 음성 변환, 음성 텍스트 변환, 음악, 음향 효과는 모두 사용량이 측정되며, 유효한 키를 가진 공격자는 할당량이나 잔액이 소진될 때까지 계속 생성할 수 있습니다.

대규모로 생성할 수 있으며, 속도 제한 모델 때문에 이 상황은 처음 보이는 것보다 더 심각합니다. 제한은 단순한 분당 요청 수 할당량이 아니라 동시성에 기반합니다. 특정 모델군의 동시성 제한이 5인 요금제의 키는 상당한 수의 동시 생성을 유지할 수 있고, 이 제한을 이해하는 공격자는 악용을 병렬화할 수 있습니다.

계정에서 콘텐츠를 생성할 수 있습니다. 키로 생성된 모든 오디오는 워크스페이스에 귀속되며, 관련 음성과 입력에 따라 평판 문제나 경우에 따라 법적 문제가 될 수 있습니다.

키가 유출되는 방식은 평범하며, 다른 모든 종류의 자격 증명을 유출시키는 것과 같은 실패 방식입니다.

• 클라이언트 측 코드의 API 키: 브라우저 번들, 모바일 바이너리 또는 단일 페이지 앱에 포함된 키는 실질적으로 공개된 것과 같습니다. 난독화와 최소화는 다릅니다.
• 리포지토리의 API 키: 나중에 공개되거나 광범위하게 복제되는 비공개 리포지토리를 포함해 Git에 커밋된 하드코딩 키와, 추적 대상이 아니었던 .env 같은 파일에 포함된 키입니다.
• 로그와 트레이스의 API 키: 요청 로거, 오류 추적기, 관측성 파이프라인은 일상적으로 HTTP 헤더를 수집합니다. xi-api-key의 키는 로그 저장소, APM 공급업체, 그리고 이들에 대한 읽기 접근 권한이 있는 모든 사람에게 노출됩니다.
• CI 및 스크린샷의 API 키: 빌드 로그, 지원 티켓, 공유 터미널입니다.

아래 각 섹션은 이러한 위험 중 하나의 발생 가능성 또는 영향을 줄이는 방법과 연결됩니다.

가장 중요한 원칙: API 키는 서버 측에만 보관

이 글의 나머지 내용은 API 키 인증 및 관리 위험을 줄이는 방법을 설명합니다. 이 한 가지 원칙은 그 기반이므로 무엇보다 우선해 구현해야 합니다.

메커니즘이 매우 단순하므로, 가장 중요한 원칙은 장기 API 키를 직접 제어하는 서버에만 두는 것입니다. 브라우저, 모바일 앱, 데스크톱 클라이언트 또는 사용자가 다운로드하고 검사할 수 있는 어떤 아티팩트에도 포함해서는 안 됩니다. 키가 클라이언트 측 코드에 있다면 이미 손상된 것으로 간주하세요.

SDK는 ELEVENLABS_API_KEY를 자동으로 읽으므로, 가장 깔끔한 코드는 아무것도 전달하지 않고 클라이언트를 한 번만 초기화합니다.

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

// Reads process.env.ELEVENLABS_API_KEY when apiKey is omitted - never a literal.
const elevenlabs = new ElevenLabsClient();

const audio = await elevenlabs.textToSpeech.convert("JBFqnCBsd6RMkjVDRZzb", {
  text: "Generated entirely server-side.",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

프로덕션에서는 이미지에 내장하거나 리포지토리에 커밋한 .env에 넣는 대신, 프로세스 시작 시 시크릿 관리자(AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault 또는 플랫폼의 동등한 서비스)에서 값을 불러와야 합니다.

클라이언트 측 앱을 위한 일회용 토큰

가장 중요한 원칙에는 예외가 없지만, 클라이언트 자체가 ElevenAPI에 접근해야 하는 정당한 사용 사례도 많습니다. 예를 들어 브라우저에서 스트리밍 텍스트 음성 변환을 재생하거나, 모바일 앱에서 전사를 위해 오디오를 캡처하거나, 사용자의 탭에서 실시간 에이전트를 실행하는 경우입니다. 장기 키는 이러한 곳에 둘 수 없습니다. 해결책은 유출되어도 위험이 낮은 자격 증명, 즉 단기 일회용 토큰을 클라이언트에 제공하는 것입니다.

서버는 장기 키를 보관하고 자체 세션 로직으로 사용자를 인증 및 권한 부여한 뒤 단기 토큰을 발급하여 그것만 클라이언트에 전달합니다. 토큰은 빠르게 만료되고 발급된 작업에만 범위가 지정되므로, 유출되더라도 가치가 낮고 곧 무효해집니다. 지원되는 엔드포인트와 정확한 요청 형식은 일회용 토큰 레퍼런스를 참고하세요.

다음은 브로커 엔드포인트의 핵심 로직입니다. 자체 세션 로직으로 사용자를 권한 부여한 다음, 문서화된 토큰 엔드포인트에서 토큰을 발급합니다. 요청은 서버의 장기 xi-api-key로 전송되고, 생성된 단기 토큰만 클라이언트로 돌아옵니다.

// ... express app and route boilerplate
app.post("/api/voice-token", async (req, res) => {
  // 1. Authorize the user with YOUR session/auth system first.
  if (!req.session?.user) return res.status(401).json({ error: "unauthorized" });

  // 2. Mint a short-lived token server-side. The long-lived key travels only
  //    in this server-to-server request, never to the browser.
  const response = await fetch("https://api.elevenlabs.io/v1/tokens", {
    method: "POST",
    headers: {
      "xi-api-key": process.env.ELEVENLABS_API_KEY as string,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({}), // populate per the tokens reference
  });

  // 3. Return only the short-lived token. The API key never leaves the server.
  res.json({ token: await response.json() });
});

그런 다음 브라우저는 해당 토큰으로 연결하며, 장기 키는 페이지에 절대 들어가지 않습니다.

키에 최소 권한 범위 지정

최소 권한은 모든 키가 업무에 필요한 권한만 갖고 그 이상은 갖지 않아야 한다는 원칙입니다. ElevenAPI에서는 키가 할 수 있는 일과 할 수 없는 일을 제한하는 여러 권한 기반 제약을 적용할 수 있습니다.

모든 권한을 가진 단일 키는 피해 범위 측면에서 최악의 경우이며, 쉽게 선택되는 기본값이기도 합니다. 더 나은 접근 방식은 어떤 키든 결국 유출된다고 가정하고, 유출되더라도 업무에 필요한 만큼만 할 수 있게 보장하는 것입니다.

먼저 키가 호출할 수 있는 API 엔드포인트를 제한하는 범위 제한부터 적용하세요. 전사에만 사용하는 키에는 텍스트 음성 변환 접근 권한이 필요하지 않으며, 음악 기능용 키는 음성 관리에 접근할 필요가 없습니다.

다음은 크레딧 할당량입니다. 키별로 맞춤 크레딧 한도를 지정하면 유출로 인한 금전적 피해를 제한하는 동시에 자체 코드의 폭주 루프도 제어할 수 있습니다.

IP 허용 목록은 한 단계 더 나아갑니다. 키를 특정 IP 주소 또는 CIDR 범위로 제한할 수 있으며, 허용 목록에 없는 IP의 요청은 403으로 거부됩니다. 이 기능은 현재 프리뷰 중인 엔터프라이즈 기능으로, 계정 관리자에게 문의해 이용할 수 있습니다.

마지막으로 개발, 스테이징, 프로덕션 환경에서 키를 공유하지 마세요. 환경마다 고유한 범위와 할당량을 가진 별도 키를 발급하세요. 환경별 키를 사용하면 개발자 노트북에서 발생한 유출이 프로덕션 크레딧에 영향을 주지 않으며, 다른 환경을 방해하지 않고 한 환경의 키만 로테이션할 수 있고, 트래픽이 이미 출처별로 분리되어 있어 사용 로그도 해석하기 쉬워집니다.

API 키 로테이션

키 로테이션은 정기적으로 기존 키를 새 키로 교체하는 실무입니다. 침해나 노출이 의심될 때도 수행할 수 있습니다.

정기적인 로테이션은 발견되지 않은 유출이 악용될 수 있는 기간도 줄입니다. 로테이션은 코드가 이를 고려해 구축된 경우에만 부담이 없으므로, 필요해지기 전에 로테이션을 고려해 설계하세요.

핵심 기법은 키 중첩이며, 이를 통해 다운타임 없이 전환할 수 있습니다.

1. 새 API 키 생성: 기존 키와 동일한 범위, 할당량, IP 제한을 가진 새 키를 함께 프로비저닝합니다. 이제 두 키가 모두 유효합니다.
2. 키 업데이트: 시크릿 관리자의 시크릿을 업데이트하고 인스턴스가 이를 가져오도록 하여 새 키를 배포합니다. 설정에 따라 재시작, 재읽기 또는 시크릿 관리자 새로고침이 필요할 수 있습니다.
3. 트래픽 확인: 새 키로 트래픽이 흐르는지 확인하세요. 기존 키의 사용량이 사라졌는지 관찰하세요.
4. 키 접근 권한 제거: 안전한 기간 동안 트래픽이 없음을 확인한 후 기존 키를 취소하세요.

중첩 기간에는 두 키가 모두 유효하므로 자격 증명이 없어 요청이 실패하는 순간이 없습니다. 중첩 기간에는 또 다른 이점도 있습니다. 잘못 구성된 인스턴스는 기존 키를 계속 사용해 드러나므로, 해당 키를 끊기 전에 찾아낼 수 있습니다.

중첩 전환을 문제없이 수행하려면 로테이션이 코드 변경이 아닌 구성 변경이 되도록 코드를 구성하세요. 새로고침할 수 있는 한 곳에서 키를 읽고, 단일 스위치가 활성 시크릿을 결정하게 하세요.

// Rotation is driven by configuration, not code edits. The secret manager (or
// the deploy that injects env vars) is the single point of change.
// ELEVENLABS_KEY_ACTIVE selects which slot is live, enabling overlap.
let client: ElevenLabsClient | undefined;

function activeKey(): string {
  const slot = process.env.ELEVENLABS_KEY_ACTIVE ?? "primary";
  const name = slot === "primary" ? "ELEVENLABS_API_KEY_PRIMARY" : "ELEVENLABS_API_KEY_SECONDARY";
  return process.env[name] as string;
}

function getClient(): ElevenLabsClient {
  return (client ??= new ElevenLabsClient({ apiKey: activeKey() }));
}

// Call after a secret refresh to pick up the rotated key without a deploy.
function resetClient(): void {
  client = undefined;
}

중첩 기간에는 PRIMARY와 SECONDARY를 모두 설정하고 ELEVENLABS_KEY_ACTIVE를 전환합니다. 애플리케이션 코드는 전혀 변경되지 않습니다.

주기는 백엔드 키의 경우 90일마다 정기 로테이션하는 것이 합리적인 기본값이며, 고가치 키나 광범위하게 접근되는 키는 더 자주, 노출 시에는 즉시 수행해야 합니다. 프로비저닝, 배포, 검증, 취소를 수행하는 예약 작업으로 이를 자동화하면 로테이션을 이벤트가 아닌 백그라운드 프로세스로 만들 수 있습니다.

워크스페이스 접근 제어 및 권한

범위 지정과 로테이션은 개별 키를 보호하는 반면, 워크스페이스 제어는 애초에 누가 키를 발급할 수 있는지 관리합니다. 조직 정책을 정의하고 따를 수 있는 기반을 제공하며, 이는 향후 모든 키 관리 실무에 영향을 줍니다.

먼저 사람과 머신 자격 증명을 분리하세요. 사람은 각자의 계정과 권한으로 대시보드에 로그인하고, 서비스는 키 또는 더 나은 방법으로 서비스 계정으로 인증합니다. 개인의 개인 접근 권한으로 발급한 키로 서비스를 실행하지 말고, 여러 사람이 하나의 머신 키를 공유하게 하지 마세요. 그 이유는 오프보딩입니다. 사람이 퇴사하거나 서비스가 종료될 때 부수적인 피해 없이 정확히 필요한 자격 증명만 취소해야 합니다.

서비스 계정도 같은 목표를 지원합니다. 머신 워크로드에 사람과 연결되지 않은 고유한 ID와 자체 범위를 부여하므로 감사 추적의 정확성을 유지할 수 있습니다.

그다음 접근 권한을 개인별로 하나씩 매핑하지 말고 역할에 매핑하세요. 워크스페이스는 이를 위해 그룹 및 구성원 권한을 지원합니다. 각 그룹이 업무를 수행할 수 있는 최소 권한을 부여하고, 정기적으로 구성원을 검토하며, 사람이나 머신을 막론하고 단일 자격 증명이 역할에 필요한 범위를 넘지 않도록 구성하세요.

감사 및 탐지

앞선 단계에서는 유출 피해를 줄이는 방법을 살펴봤습니다. 이 단계에서는 유출이 실제로 발생했는지 탐지하는 방법을 설명합니다. 효과적인 탐지는 세 가지 습관에 기반합니다. 

첫째, 어떤 키가(시크릿 값이 아닌 식별자로) 어떤 유형의 요청을, 어디에서, 어느 정도의 규모로 처리했는지 기록하는 것입니다. 모든 로깅 및 트레이싱 계층에서 xi-api-key 헤더를 제거하세요. HTTP 미들웨어와 APM 구성의 마스킹 규칙은 키가 로그 저장소에 남는 가장 흔한 경로를 차단합니다.

둘째, 크레딧 사용량의 이상 징후를 모니터링하는 것입니다. 시간에 따른 키별 크레딧 소진량을 추적하고 기준선에서 벗어나는 상황에 알림을 설정하세요. 예를 들어 갑작스러운 급증, 비정상적인 시간대의 생성, 유휴 상태여야 하는 키가 갑자기 활성화되는 경우입니다.

셋째, 동시성 헤더를 확인하는 것입니다. 모든 응답에서 current-concurrent-requests 및 maximum-concurrent-requests 헤더로 현재 및 최대 동시 요청 수를 반환합니다. 이를 통해 남은 여유 용량을 알 수 있으며, 직접 시작하지 않았는데 최대치가 지속적으로 유지된다면 강력한 악용 신호입니다. 원시 HTTP 엔드포인트를 사용하면 응답 헤더를 직접 확인할 수 있습니다.

const resp = await fetch("https://api.elevenlabs.io/v1/text-to-speech/JBFqnCBsd6RMkjVDRZzb", {
  method: "POST",
  headers: {
    "xi-api-key": process.env.ELEVENLABS_API_KEY as string,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ text: "Monitoring headroom.", model_id: "eleven_flash_v2_5" }),
});

const current = resp.headers.get("current-concurrent-requests");
const maximum = resp.headers.get("maximum-concurrent-requests");
// Emit these to your metrics pipeline; alert on sustained saturation you did not cause.

이러한 상황에서는 알림이 발생해야 합니다. 아무도 보지 않는 대시보드는 탐지를 제공하지 못합니다. 명확한 담당자를 지정하고, 크레딧 급증 및 동시성 포화 신호를 장애에 사용하는 것과 동일한 알림 경로에 연결하세요.

사고 대응

최고 수준의 보안 및 모니터링 시스템을 갖추더라도 키는 결국 유출된다고 가정해야 합니다. 피해를 제한하는 단계 목록을 통해 이러한 상황을 계획하면 시간을 절약하고 영향을 줄이는 대응 로드맵을 마련할 수 있습니다.

다음은 API 키 노출에 대비한 사전 정의된 사고 대응 절차입니다.

1. 유출된 키 즉시 취소: 전체 범위를 파악할 때까지 기다리지 마세요. 취소된 키로는 생성할 수 없으며, 대체 키는 언제든 발급할 수 있으므로 취소는 되돌릴 수 있습니다. 이것이 가장 가치가 높은 단일 조치입니다.
2. 새 키로 로테이션: 유출된 키가 프로덕션 트래픽을 처리하고 있었다면 중첩 절차를 반대로 사용하세요. 새 키를 준비하고 트래픽을 전환한 다음 유출된 키가 비활성화되었는지 확인합니다. 코드는 구성에서 키를 읽으므로 이는 코드 변경이 아닌 구성 전환입니다.
3. 사용 로그로 피해 범위 평가: 유출을 차단한 뒤 규모를 파악하세요. 키는 얼마나 오래 유효하고 노출되어 있었나요? 그 기간에 얼마나 많은 크레딧이 사용되었고, 패턴은 정상 트래픽과 일치하나요 아니면 악용으로 보이나요? 어떤 엔드포인트에 접근했나요?
4. 종속 시크릿 로테이션: 키가 단독으로 유출되는 경우는 드뭅니다. 리포지토리, 로그 저장소 또는 CI 파이프라인에서 노출됐다면 같은 위치의 인접 시크릿도 노출된 것으로 가정하고 함께 로테이션하세요.
5. 유출 경로 차단: 키가 어떻게 유출됐는지 찾아 수정하지 않으면 다시 발생합니다. 파일을 .gitignore에 추가하고 기록을 제거하며, 로거에 헤더 마스킹을 추가하고, 빌드 아티팩트에서 시크릿을 제거하고, CI 시스템 접근 권한을 강화하세요.
6. 사후 분석 작성: 타임라인, 피해 범위, 근본 원인, 그리고 추가한 구체적인 제어 수단(범위 축소, IP 허용 목록, CI의 시크릿 스캐너, 더 짧은 로테이션 주기)을 문서화하세요.

이 단계를 따르면 API 노출 재난 상황에 활용할 수 있는 대응 프로세스를 마련하게 됩니다. 

규정 준수 현황: SOC 2, HIPAA 및 데이터 보존

인증은 더 광범위한 규정 준수 평가의 한 요소이며, 여기서 무엇을 주장할 수 있고 없는지 신중해야 합니다. 다음 내용은 사용 사례에 대한 판단이 아니라 사실에 기반한 출발점으로 보세요.

ElevenLabs는 SOC 2를 준수합니다. 적격 요금제와 사용 사례에서는 HIPAA 준수 및 무보존 모드를 이용할 수 있습니다. 무보존은 처리 후 요청 콘텐츠를 저장하지 않는다는 의미로, 입력 또는 생성된 오디오가 민감한 경우 중요합니다.

특정 모드의 적용 여부는 요금제, 구성 및 처리하는 데이터의 세부 사항에 따라 달라집니다. 이에 의존하기 전에 계정의 적격성 및 정확한 조건을 확인하고, 앞서 설명한 접근 제어와 함께 적용하세요. 규정 준수 인증은 플랫폼이 데이터를 처리하는 방식을 관리하고, 키 관리는 누가 사용자를 대신해 작업할 수 있는지를 관리합니다. 후자는 사용자의 책임입니다.

우수한 API 키 보안의 모습

서버 측 전용 키는 가장 큰 유출 표면을 제거합니다. 일회용 토큰은 실제로 API에 접근해야 하는 클라이언트까지 이 보장을 확장합니다. 범위 지정과 환경별 분리는 단일 유출의 피해를 제한합니다. 구성에 내장된 로테이션은 복구를 위험한 작업이 아닌 일상적인 작업으로 만듭니다. 워크스페이스 제어는 사람과 머신 ID를 분리합니다. 감사는 악용을 청구서의 뜻밖의 비용이 아닌 알림으로 바꿉니다. 문서화된 런북은 사고를 절차로 바꿉니다.

이는 모든 고가치 시크릿을 보호하는 것과 동일한 자격 증명 위생을, 비용을 지출하고 대규모로 오디오를 생성할 수 있다는 특수한 가치를 지닌 키에 적용한 것입니다.

실제 요청 형식에 맞춰 이를 연결할 준비가 되었다면 인증 레퍼런스와 일회용 토큰 레퍼런스에서 현재 지원되는 엔드포인트 목록을 확인할 수 있습니다. 모니터링해야 할 동시성 모델을 이해하려면 모델 레퍼런스와 API 빠른 시작을 다음으로 읽어보세요.

ElevenAPI 통합 보호

강력한 API 인증은 수많은 다른 보안 실무의 기반이 되는 핵심 제어 수단입니다. 서버 측 전용 키 사용, 클라이언트용 일회용 토큰 배포, 최소 권한 범위 지정, 키 관리에 로테이션 내장 같은 조치는 대규모 환경에서 위험을 예방하는 데 도움이 됩니다.

지원되는 엔드포인트와 사용할 정확한 헤더 형식에 관한 자세한 내용은 ElevenAPI 문서를 참고하세요. 시작할 준비가 되었다면 ElevenLabs에서 API 키를 요청하여 지금 바로 개발을 시작하세요. 

API 인증 및 키 관리 FAQ