Grok Voice Agent API 가이드: 엔드포인트, 가격, 인증, 도입 경로 (2026년 4월)

xAI의 realtime voice를 개발자로서 붙이려면, 먼저 “voice API가 있나?” 같은 넓은 질문에서 벗어나는 편이 좋습니다. 지금 공개 developer route로 가장 분명한 것은 Grok Voice Agent API이고, endpoint는 **wss://api.x.ai/v1/realtime**입니다. 2026년 4월 6일 기준 공개 self-serve 정보는 $0.05 / 분, 팀당 100 동시 세션, 세션당 최대 30분을 보여 줍니다. 구현에서 가장 먼저 고정해야 할 것도 세 가지입니다. long-lived API key는 backend에만 둔다. browser와 mobile은 ephemeral token으로 붙는다. 그리고 필요한 것이 live conversation이 아니라 마지막 단계의 음성 출력이라면, realtime loop보다 Text to Speech API가 더 맞다.

“

이 글은 2026년 4월 6일 기준으로 xAI의 Voice Agent docs, pricing / model page, voice overview, Text to Speech docs, product page, release notes를 다시 확인해 정리했습니다. 공개 문서가 아직 모호한 부분은 억지로 메우지 않고 경계로 남겼습니다.

먼저, 지금 고르려는 음성 경로가 무엇인지 나누기

이 주제에서 가장 흔한 실수는 Voice Agent API, TTS, STT, 음성 프레임워크를 전부 하나의 “voice API”로 읽는 것입니다. 실제 구현에서는 이걸 먼저 나누는 편이 훨씬 낫습니다.

이건 표현 차이가 아니라 그대로 설계 차이입니다. turn-taking 대화, 낮은 지연의 audio 왕복, 세션 중 tools, phone-agent 형태가 필요하면 Voice Agent API가 맞습니다. 반대로 앱이 이미 상태를 쥐고 있고 마지막에 speech output만 필요하다면 TTS가 더 단순하고 비용 구조도 읽기 쉽습니다.

xAI의 product page는 Speech to Text도 언급합니다. 다만 2026년 4월 6일 기준으로 개발자가 바로 따라갈 수 있는 public docs route가 분명한 쪽은 Voice Agent API와 TTS였습니다. STT capability 자체를 부정할 필요는 없지만, 현재 공개 self-serve developer route로 확정해 쓰기에는 아직 문서 경로가 더 모호합니다.

그래서 지금은 이렇게 나눠 보는 편이 안전합니다.

• Voice Agent API: live voice session 자체가 제품일 때
• TTS API: 음성이 마지막 output layer일 뿐일 때
• STT: public docs route가 더 분명해질 때까지 보류

지금 공개된 접속 조건을 한 화면에 잡기

가장 빨리 붙이면서도 안전한 접속 순서

xAI가 문서에서 보여 주는 최소 흐름은 단순합니다.

1. wss://api.x.ai/v1/realtime에 연결
2. session.update 전송
3. conversation.item.create로 사용자 메시지 생성
4. response.create로 응답 요청

trusted backend에서 시작한다면 최소 JavaScript는 이렇게 볼 수 있습니다.

js
import WebSocket from "ws";

const ws = new WebSocket("wss://api.x.ai/v1/realtime", {
  headers: {
    Authorization: `Bearer ${process.env.XAI_API_KEY}`,
  },
});

ws.on("open", () => {
  ws.send(
    JSON.stringify({
      type: "session.update",
      session: {
        voice: "eve",
        instructions: "You are a helpful assistant.",
        turn_detection: { type: "server_vad" },
      },
    }),
  );

  ws.send(
    JSON.stringify({
      type: "conversation.item.create",
      item: {
        type: "message",
        role: "user",
        content: [{ type: "input_text", text: "Hello!" }],
      },
    }),
  );

  ws.send(JSON.stringify({ type: "response.create" }));
});

이 경로가 첫날에 좋은 이유는 인증 경계가 명확하기 때문입니다. 실제 key는 backend에만 있고 socket session도 backend가 통제합니다. browser audio capture, WebRTC, 전화 라우팅, 더 무거운 orchestration은 그 다음에 붙이면 됩니다.

팀이 가장 쉽게 무너지는 지점은 “서버에서 되니까 이 key를 그대로 브라우저에 넣자”는 판단입니다. xAI 문서는 client-side apps가 ephemeral token을 써야 한다고 명확히 적고 있습니다. 그 public route가 POST https://api.x.ai/v1/realtime/client_secrets입니다. backend가 short-lived credential을 발급하고, client는 그 token으로 realtime socket을 엽니다. browser path에서는 sec-websocket-protocol에 xai-client-secret. prefix를 쓰는 흐름도 문서화되어 있습니다.

여기서 나오는 기본 규칙은 간단합니다.

• 먼저 backend에서 시작한다: 가장 안전하고 원인 파악이 쉽다
• browser / mobile에서 직접 연결한다: backend가 ephemeral token을 발급할 수 있을 때만

초기에 알아두면 도움이 되는 defaults도 있습니다.

• turn detection 기본값은 server_vad
• default PCM audio는 24 kHz
• 지원 audio formats는 audio/pcm, audio/pcmu, audio/pcma
• 공개 voices는 eve, ara, rex, sal, leo

이건 사소한 파라미터 목록이 아니라, 이 API가 실제 voice product용 계약으로 설계되어 있다는 신호입니다.

비용을 읽는 법: minute rate는 바닥값일 뿐이다

공개 self-serve 조건만 짧게 쓰면 다음과 같습니다.

하지만 실무적인 비용 판단은 여기서 끝나지 않습니다. xAI voice pages에서 가장 중요한 문장은 minute rate 자체보다 tools 호출이 별도 과금이라는 점입니다. voice agent가 function calling, web search, X search, collections, MCP-backed tools를 쓰면 그 호출은 $0.05 / 분에 포함되지 않습니다. minute rate는 session floor일 뿐 전체 bill이 아닙니다.

간단한 예를 들어 보겠습니다. 10분 voice session의 base rate는 약 $0.50입니다. 여기에 web_search를 20번 호출하고 현재 공개 가격이 $5 / 1,000 calls라면 검색 비용만 약 $0.10이 추가됩니다. 액수는 작아 보여도 제품 경제성은 달라집니다. 지금 만들고 있는 것이 “voice app”인지, 아니면 audio I/O가 붙은 retrieval agent인지에 따라 cost structure가 달라지기 때문입니다.

현재 공개된 tool prices는 적어도 다음을 포함합니다.

• web_search: $5 / 1,000 calls
• x_search: $5 / 1,000 calls
• code_execution: $5 / 1,000 calls
• collections_search / file_search: $2.50 / 1,000 calls

region 관련 문구도 한 줄로 납작하게 만들면 안 됩니다. public pricing/model page는 self-serve region을 **us-east-1**로 보여 줍니다. 반면 product page는 multi-region infrastructure와 custom rate limits를 이야기합니다. 이 둘은 같은 약속이 아닙니다. 공개 developer contract는 pricing/model page를 기준으로 읽고, 더 넓은 infrastructure language는 enterprise framing으로 보는 편이 안전합니다.

그래서 budgeting question은 “몇 분 말하느냐”만으로는 부족합니다. “평균 session이 몇 번의 tools를 부르고, 그 호출이 매 turn마다 꼭 필요한가”까지 함께 봐야 합니다.

지금 공개된 기능만으로도 real workloads에는 충분하다

Voice Agent API는 문서에 따라 너무 넓어 보이거나 너무 좁아 보일 수 있습니다. 구현자에게 유용한 읽기는 이렇습니다. 현재 공개된 기능만으로도 이미 여러 real agent workloads를 충분히 커버할 수 있습니다.

현재 docs가 분명히 보여 주는 것은 다음과 같습니다.

• WebSocket 기반 live two-way voice conversation
• built-in voices
• server_vad turn handling
• telephony-friendly μ-law, A-law를 포함한 여러 audio formats
• web_search, x_search, file_search, remote MCP tools, custom functions
• OpenAI Realtime style clients를 위한 compatibility entrypoint

이 조합이면 browser assistant, phone agent, support flow, retrieval-backed voice interface, operator copilot 정도는 현실적인 대상이 됩니다. 여기서 남겨야 할 판단은 두 가지입니다.

첫째, tools는 부가 기능이 아니라 핵심 route의 일부입니다.
이 API는 “음성으로 읽어 주는 기능”이 아닙니다. 대화 중 lookup, internal retrieval, custom function이 필요한 제품도 바로 같은 main route에서 다룰 수 있게 설계되어 있습니다.

둘째, compatibility는 유용하지만 zero-change migration은 아닙니다.
xAI는 base URL을 wss://api.x.ai/v1/realtime로 바꾸면 많은 OpenAI Realtime client와 SDK를 재사용할 수 있다고 말합니다. 이건 실제로 도움이 됩니다. 하지만 동시에 event name 차이와 unsupported events도 문서화합니다. 대표 예가 response.text.delta와 response.output_text.delta의 차이입니다.

따라서 이동할 때는 이렇게 보는 편이 좋습니다.

• session 전체 흐름은 많이 재사용할 수 있다
• event handling은 그대로 두면 안 된다
• compatibility note는 출발을 빠르게 해 주지만 xAI-specific differences 검토를 대신해 주지는 않는다

raw API보다 음성 프레임워크가 더 나아지는 시점

raw API와 framework를 “무엇이 더 고급인가”의 문제로 보면 판단이 흐려집니다. 실제로는 병목이 어디로 이동했는지가 더 중요합니다.

지금의 핵심 문제가 아직:

• realtime session을 최소 구성으로 붙일 수 있는가
• auth boundary를 안전하게 유지할 수 있는가
• minute rate와 tool cost를 분리해서 예산화할 수 있는가

라면 raw Voice Agent API에서 시작하는 편이 보통 맞습니다. 가치 검증에 필요한 것은 이미 충분히 할 수 있습니다.

반대로 ready-made voice framework가 더 값어치를 가지는 시점은 다음과 같습니다.

• browser audio capture나 playback pipeline 자체가 너무 복잡하다
• phone routing, telephony, media forwarding이 주된 어려움이 되었다
• WebRTC나 deployment topology가 xAI socket보다 더 무거운 문제다

xAI의 voice overview는 LiveKit, Twilio, WebRTC, telephony examples로 이어집니다. 이건 병목이 “xAI를 붙이는 일”에서 “media와 orchestration을 굴리는 일”로 바뀌었을 때 framework가 더 큰 효과를 낸다는 꽤 명확한 신호입니다.

실무적 분리는 이렇게 정리할 수 있습니다.

• Voice Agent API: live conversation 자체가 제품
• TTS API: one-shot speech output만 필요
• 음성 프레임워크: media plumbing, telephony, orchestration이 더 큰 문제일 때

OpenAI Realtime에서 왔다면 이것부터 확인하기

xAI의 compatibility note는 이 API에 들어가기 쉽게 만들어 줍니다. 다만 이를 “drop-in compatible” 한 문장으로 줄이면 위험합니다. 더 정확한 요약은 네 가지입니다.

1. 큰 구조는 이어진다. stateful realtime session, streaming events, live audio, tool use라는 큰 틀은 익숙하다.
2. endpoint는 바뀐다. 중심 contract는 wss://api.x.ai/v1/realtime로 이동한다.
3. event names가 완전히 같지는 않다. response.output_text.delta와 response.text.delta 차이가 대표적이다.
4. 없는 이벤트도 있다. xAI docs는 conversation.item.retrieve, conversation.item.truncate 같은 unsupported events를 직접 적어 둔다.

이 섹션의 가치는 브랜드 비교가 아니라, 이동하면서 사고를 줄이는 데 있습니다. 이미 Realtime-oriented client architecture가 있다면 xAI는 확실히 접근하기 쉬운 편입니다. 하지만 첫 production 검증에서는 socket 연결 성공만 보지 말고 event-level behavior까지 확인해야 합니다.

FAQ

Grok Voice Agent API의 정확한 endpoint는 무엇인가요?
**wss://api.x.ai/v1/realtime**입니다.

공개 self-serve 가격은 얼마인가요?
현재 공개 정보는 $0.05 / 분, 시간 기준으로 **$3.00 / 시간**입니다. tools 호출은 별도 과금입니다.

브라우저에서 직접 연결할 수 있나요?
가능하지만, 안전한 경로는 backend가 ephemeral token을 발급하고 client가 그 short-lived credential로 접속하는 방식입니다. long-lived API key를 browser code에 두면 안 됩니다.

Voice Agent API와 TTS API는 같은 것인가요?
아닙니다. Voice Agent API는 live conversation용 realtime WebSocket API이고, TTS API는 one-shot speech generation용 REST API입니다.

tools를 지원하나요?
지원합니다. xAI docs는 web_search, x_search, file_search, remote MCP tools, custom functions를 명시합니다.

공개 self-serve STT API가 있나요?
product page는 Speech to Text를 언급하지만, 이번 확인에서는 Voice Agent API와 TTS 쪽 문서 경로가 훨씬 더 명확했습니다. 그래서 STT는 public docs route가 더 뚜렷해질 때까지 보류하는 편이 안전합니다.

현재 공개 limits는 무엇인가요?
public pricing/model page는 팀당 100 동시 세션, 세션당 최대 30분을 보여 줍니다.

결론

“Grok Voice Agent API”에 대한 가장 유용한 답은 API가 존재한다는 사실 자체가 아닙니다. 더 중요한 것은 xAI의 realtime route가 개발자에게 이미 꽤 분명하게 열려 있고, 동시에 처음부터 분리해서 봐야 할 것도 뚜렷하다는 점입니다. 정확한 WebSocket endpoint, server key와 client token 사이의 인증 경계, minute rate 위에 쌓이는 tools 추가 비용. 이 세 가지를 처음부터 분명히 잡을 수 있다면 live voice product의 출발점으로 Voice Agent API는 충분히 쓸 수 있습니다. 단발성 speech output만 필요하다면 TTS가 더 빠르고 자연스럽습니다. 병목이 이미 media plumbing, telephony, orchestration으로 옮겨갔다면 그때 ready-made voice frameworks를 검토하면 됩니다.