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

> xAI의 realtime voice를 개발자 관점에서 쓰려면 `wss://api.x.ai/v1/realtime`를 보면 됩니다. 2026년 4월 6일 기준 공개 self-serve 조건은 `$0.05 / 분`, 팀당 `100` 동시 세션, 세션당 `30`분이며, 서버는 API key, 브라우저와 모바일은 ephemeral token을 써야 합니다. 단발성 음성 출력만 필요하면 TTS API가 더 자연스럽습니다.

- URL: https://blog.laozhang.ai/ko/posts/grok-voice-agent-api
- Published: 2026-04-06
- Updated: 2026-04-20
- Author: AI Free API Team (https://blog.laozhang.ai/ko/about)
- Category: API 가이드
- Tags: Grok Voice Agent API, xAI, 음성 에이전트, WebSocket, Realtime API

---
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를 다시 확인해 정리했습니다. **2026년 4월 20일**에는 STT 경계를 업데이트했습니다. xAI는 이제 별도 Grok STT docs and endpoints를 공개하고 있습니다.

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

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

| 지금 해결하려는 문제 | 먼저 고를 경로 |
| --- | --- |
| 저지연 양방향 voice conversation 자체를 만들고 싶다 | **Grok Voice Agent API** |
| 마지막에 한 번만 음성을 생성하면 된다 | **Text to Speech API** |
| 진짜 병목이 전화 연결, WebRTC, media routing으로 옮겨갔다 | **음성 프레임워크 / telephony route** |
| 일반 audio to text 전사가 필요하다 | **Grok STT API** |

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

xAI의 product page는 **Speech to Text**도 언급합니다. 이 경계는 첫 발행 이후 바뀌었습니다. **2026년 4월 20일** 기준 xAI는 별도 Grok STT route를 공개하고 있습니다. 파일이나 audio URL은 `POST https://api.x.ai/v1/stt`, realtime transcription은 `wss://api.x.ai/v1/stt`를 사용합니다. STT는 text를 반환하고, Voice Agent API는 live spoken session을 실행합니다.

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

- **Voice Agent API**: live voice session 자체가 제품일 때
- **TTS API**: 음성이 마지막 output layer일 뿐일 때
- **Grok STT**: audio to text가 목적일 때 사용. 자세한 내용은 [Grok STT API: endpoint, 가격, 실시간 전사와 Voice Agent API 차이](https://blog.laozhang.ai/ko/posts/grok-speech-to-text-api)

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

| 먼저 알아둘 것 | 현재 공개 답변 |
| --- | --- |
| 공식 realtime endpoint | `wss://api.x.ai/v1/realtime` |
| 제품 이름 | Grok Voice Agent API |
| 공개 self-serve 가격 | `$0.05 / 분` (`$3.00 / 시간`) |
| 공개 runtime limits | 팀당 `100` 동시 세션, 세션당 `30`분 |
| browser용 안전한 인증 경로 | backend가 ephemeral token을 발급하고 client가 그 token으로 연결 |
| 첫 구현의 안전한 출발점 | 먼저 backend에서 realtime session을 잡는다 |
| 가장 자주 놓치는 비용 | tools 호출은 minute rate와 별도 과금 |
| 음성 출력만 필요할 때 | `POST https://api.x.ai/v1/tts` |
| self-serve 공개 region 표기 | pricing/model page는 `us-east-1` |
| OpenAI Realtime에서 넘어올 때의 결론 | 큰 흐름은 재사용 가능하지만 event names와 세부 동작은 완전히 같지 않다 |

![Grok Voice Agent API의 핵심. 엔드포인트, 가격, 인증 경계, 도입 경로를 보여준다](https://blog.laozhang.ai/posts/ko/grok-voice-agent-api/img/cover.webp)

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

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용 계약으로 설계되어 있다는 신호입니다.

![backend API key, client-side ephemeral token, 그리고 장기 key를 브라우저에 두지 말아야 한다는 인증 경계 그림](https://blog.laozhang.ai/posts/ko/grok-voice-agent-api/img/auth-split.webp)

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

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

| 항목 | 현재 공개 정보 |
| --- | --- |
| Voice session 요금 | `$0.05 / 분` |
| 시간 환산 | `$3.00 / 시간` |
| 동시 세션 수 | 팀당 `100` |
| 세션 최대 길이 | `30`분 |
| 공개 region | `us-east-1` |

하지만 실무적인 비용 판단은 여기서 끝나지 않습니다. 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마다 꼭 필요한가”까지 함께 봐야 합니다.

![minute rate, tool 비용 층, runtime limits, public region caveat를 함께 보여주는 비용 보드](https://blog.laozhang.ai/posts/ko/grok-voice-agent-api/img/cost-stack.webp)

## 지금 공개된 기능만으로도 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이 더 큰 문제일 때

![live dialogue용 Voice Agent API, one-shot speech용 TTS, 그리고 media/orchestration이 더 무거울 때의 음성 프레임워크를 비교하는 그림](https://blog.laozhang.ai/posts/ko/grok-voice-agent-api/img/route-map.webp)

## 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가 있나요?**  
네. 2026년 4월 20일 기준 xAI는 Grok STT REST route `POST https://api.x.ai/v1/stt`와 realtime route `wss://api.x.ai/v1/stt`를 공개하고 있습니다. 이 문서는 live spoken agent session용 Voice Agent API만 다룹니다.

**현재 공개 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를 검토하면 됩니다.