xAI API
grok-4-1-fast 기준
Grok Collections API,
싸다더니 이 비용이 따로 옵니다
xAI가 2025년 12월 22일 공식 발표한 Grok Collections API는 “RAG 인프라를 직접 짤 필요 없다”는 메시지로 주목받았습니다. 그런데 막상 요금표를 OpenAI File Search와 나란히 놓고 보니, 같은 단가 뒤에 구조가 달랐습니다. 벤치마크 수치도 도메인마다 결과가 달라서, 단순히 “최고”라고 보기 어려운 부분이 있었습니다.
Grok Collections API가 해결하려는 문제
RAG(Retrieval-Augmented Generation) 시스템을 직접 구축해본 적 있다면, 문서 파싱·청킹·임베딩·벡터 인덱싱을 따로 관리하는 것이 얼마나 번거로운지 알 것입니다. xAI는 2025년 12월 22일 이 전 과정을 API 하나로 처리하는 Grok Collections API를 공식 발표했습니다. (출처: xAI 공식 블로그, 2025.12.22)
결론부터 말씀드리면, 이 API가 주목받는 이유는 단순한 파일 저장이 아닙니다. PDF의 레이아웃, 엑셀 테이블의 계층 구조, 코드 파일의 문법 구조를 각각 다르게 파싱한다는 점이 핵심입니다. 기존 RAG 솔루션에서 “텍스트만 뽑아내면 충분하지 않냐”는 생각을 가졌다면, 이 부분에서 생각이 달라질 수 있습니다.
Collections API가 주로 노리는 영역은 금융 보고서, 법률 계약서, 대규모 코드베이스입니다. 숫자와 표가 빽빽하거나, 문장 참조 구조가 복잡하거나, 파일 수가 수천 개를 넘어가는 환경입니다. 이런 환경에서 일반적인 시맨틱 검색 단독으로는 정확도가 낮아질 수 있습니다.
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니, Collections API가 단순히 “RAG를 쉽게”가 아니라 “구조를 이해하는 파싱”에서 차별화를 시도했다는 점이 보였습니다. OCR과 레이아웃 인식을 인덱싱 단계에 포함시키는 것은 일반 벡터 DB 구성에서 별도 전처리로 처리하던 부분입니다.
문서를 이해하는 방식 — 인덱싱 구조
Collections API의 인덱싱은 세 가지 방식으로 작동합니다. OCR로 텍스트를 추출하되, PDF라면 레이아웃을 유지하고, 엑셀이라면 테이블 계층 구조를 인식하고, 코드라면 문법 구조를 파악합니다. (출처: xAI 공식 문서 docs.x.ai/developers/files/collections)
파일이 변경되면 자동으로 재인덱싱이 이뤄집니다. 이 부분이 실제 운영에서 중요합니다. 매월 업데이트되는 재무제표나 계약서 개정본을 관리할 때, 수동으로 재임베딩할 필요가 없습니다. 다만 재인덱싱 속도나 대기 시간에 대한 구체적인 SLA 수치는 공식 문서에서 확인이 필요합니다.
메타데이터 필드(Metadata Fields) 기능도 눈에 띕니다. 문서에 author, date, category 같은 필드를 붙여두면 검색 시 필터링 조건으로 쓸 수 있습니다. 예를 들어 author=”Sandra Kim”으로 특정 작성자의 문서만 검색 대상으로 좁히는 것이 가능합니다. 이 기능은 대규모 기업 환경에서 검색 정확도를 높이는 데 실질적으로 도움이 됩니다.
지원 파일 포맷이 생각보다 넓습니다
PDF, Excel, Word, PowerPoint, CSV, JSON, 마크다운, HTML, 각종 프로그래밍 언어 소스 파일, HWP(한글 파일)까지 지원합니다. 한국어 문서 환경에서도 HWP 포맷이 목록에 있다는 점은 실용적인 부분입니다. (출처: xAI 공식 문서 MIME 타입 목록, docs.x.ai/developers/files/collections)
| 파싱 대상 | 처리 방식 | 주요 보존 요소 |
|---|---|---|
| OCR + 레이아웃 파싱 | 단락 구조, 표 위치 | |
| Excel / CSV | 계층 구조 인식 | 셀 관계, 헤더 계층 |
| 코드 파일 | 문법 구조 파악 | 함수/클래스 경계 |
| HWP | UTF-8 텍스트 추출 | 한국어 지원 |
검색 비용, OpenAI랑 같은데 이게 다릅니다
Grok Collections API의 검색(retrieval) 단가는 1,000회당 $2.50입니다. 막상 OpenAI File Search 단가를 확인해보면 역시 $2.50 / 1,000 calls입니다. 같아 보이지만, 스토리지 비용 구조가 다릅니다.
💡 요금표만 보면 두 서비스가 같은 가격처럼 보이지만, 스토리지 청구 방식을 함께 놓으면 다른 그림이 나옵니다. OpenAI는 1GB 초과분부터 하루 $0.10/GB씩 스토리지 비용을 별도 청구하는 반면, xAI Collections의 스토리지 정책은 공식 문서 기준으로 별도 일일 스토리지 요금이 명시되어 있지 않습니다. 단, 크레딧 잔액이 있어야 파일 업로드가 가능하다고 명시되어 있으므로, 실제 청구 구조는 사용 전 콘솔에서 직접 확인이 필요합니다.
실제로 계산해보면 차이가 납니다. 예를 들어 10GB 문서를 한 달간 저장하면서 하루 500회 검색을 한다고 가정하겠습니다.
📊 월 비용 비교 시나리오 (10GB, 하루 500회 검색)
xAI Collections API
· 검색: 500회/일 × 30일 = 15,000회 → $37.50
· 스토리지: 공식 일일 요금 미명시 (확인 필요)
· 검색 비용만 기준: $37.50
OpenAI File Search (Responses API)
· 검색: 500회/일 × 30일 = 15,000회 → $37.50
· 스토리지: (10GB – 1GB 무료) × 30일 × $0.10/GB/일 = $27.00
· 합산: $64.50
※ xAI 스토리지 요금은 공식 문서 기준 미명시 항목이므로 실제 사용 전 콘솔 확인 필수. 위 계산은 공개된 수치만 사용한 추정치입니다.
이 계산이 의미하는 것은, 문서 저장량이 클수록 OpenAI 대비 xAI의 가격 경쟁력이 높아질 수 있다는 점입니다. 다만 xAI가 스토리지 정책을 추후 변경할 경우 이 구도는 달라질 수 있습니다.
벤치마크 수치, 도메인마다 달랐습니다
xAI 공식 발표에서는 Collections API가 “금융·법률·코드 도메인에서 최고 수준”이라고 밝혔습니다. 수치를 직접 보면 이야기가 조금 달라집니다. (출처: xAI 공식 블로그 x.ai/news/grok-collections-api, 2025.12.22)
| 도메인 | Grok 4.1 Fast | Gemini Pro 3 | GPT 5.1 | 1위 |
|---|---|---|---|---|
| 금융 (표·수치) | 93.0% | 85.9% | 84.7% | Grok |
| 법률 (LegalBench) | 73.9% | 74.5% | 71.2% | Gemini |
| 코딩 (DeepCodeBench) | 86% | 85% | 81% | Grok |
법률 도메인에서 Grok 4.1 Fast(73.9%)는 Gemini Pro 3(74.5%)에 0.6%p 뒤집니다. 이 수치가 의미하는 것은, 법률 문서 처리를 주로 하는 환경이라면 Collections API가 자동으로 최선의 선택은 아니라는 점입니다. 금융과 코딩 쪽에서는 경쟁 우위가 명확합니다.
💡 벤치마크 데이터를 공급사별로 나란히 놓고 보면, xAI가 “금융 내부 데이터셋”을 직접 만들어 테스트했다는 점이 눈에 띕니다. “Based on an internal dataset”이라는 주석이 공식 발표문에 포함되어 있습니다. 즉, 금융 93.0% 수치는 xAI 자체 데이터 기준입니다. 법률은 LegalBench(공개 데이터셋), 코딩은 DeepCodeBench(공개)를 사용했습니다. 도메인마다 테스트 기준이 달랐습니다.
Gemini 비교 수치에도 주석이 있습니다
공식 발표문에서 Gemini 수치 옆에는 “*Gemini does not expose the actual retrieved files so this metric measures the files cited by Gemini rather than the raw retrieved files.”라는 주석이 붙어있습니다. Gemini는 실제로 검색된 파일이 아니라, 응답에서 인용된 파일을 기준으로 측정했다는 뜻입니다. 이 측정 방식 차이가 점수에 영향을 줄 수 있으므로, 수치를 그대로 비교하는 것은 주의가 필요합니다. (출처: xAI 공식 블로그, 2025.12.22)
파일 상한 100GB — 실제로 언제 막히나
Collections API는 팀(team) 전체 기준으로 파일 100,000개, 총 용량 100GB 상한이 있습니다. 초과 시 xAI에 직접 문의해서 한도를 늘릴 수 있습니다. (출처: xAI 공식 문서 docs.x.ai/developers/files/collections)
100GB가 실제로 언제 문제가 되는지 계산해보면, 평균 1MB PDF 기준으로 100,000개 파일이 약 100GB입니다. 일반적인 스타트업이나 중소 기업 수준에서는 여유롭지만, 수십만 건의 법률 계약서나 SEC 신고 파일 전체를 넣으려는 엔터프라이즈 환경에서는 빠르게 천장에 닿을 수 있습니다.
⚠️ 이 구간에서 멈춥니다 — 100GB 상한은 팀 전체에 적용됩니다. 여러 프로젝트가 같은 xAI 팀 계정 아래 돌아가고 있다면, 한 프로젝트가 저장 용량을 많이 쓸수록 다른 프로젝트에도 영향이 갑니다. 운영 전에 용량 배분 계획이 필요합니다. 한도 증가 신청은 x.ai/contact 경로를 통해 문의 가능합니다.
단일 파일 상한은 100MB입니다
파일 하나당 최대 크기는 100MB입니다. 일반 PDF나 문서 파일 대부분은 이 범위 안에 들어오지만, 대형 코드베이스를 ZIP으로 묶어서 넣으려는 경우에는 100MB 제한에 걸릴 수 있습니다. 이 경우 파일을 나눠서 업로드하는 방식이 필요합니다.
직접 쓸 때 이렇게 시작합니다
Collections API를 실제로 써보려면 xAI API 키가 있어야 합니다. console.x.ai에서 계정을 만들고 크레딧을 충전하면 됩니다. Python SDK(xai_sdk)와 REST API 두 가지 방식이 모두 지원됩니다.
Python SDK로 컬렉션 만들고 검색하기
아래 코드는 xAI 공식 문서에서 제공하는 예시입니다. (출처: xAI 공식 블로그 x.ai/news/grok-collections-api, 2025.12.22)
from xai_sdk import Client client = Client() # 컬렉션 생성 collection = client.collections.create( name="Research Papers", model_name="grok-embedding-small" ) # 파일 업로드 document = client.collections.upload_document( collection.collection_id, name="ml-fundamentals.txt", data=b"...", ) # 하이브리드 검색 실행 results = client.collections.search( query="What is machine learning?", collection_ids=[collection.collection_id], retrieval_mode="hybrid", )
retrieval_mode에는 “semantic”, “keyword”, “hybrid” 세 가지가 들어갑니다. 기대했던 것과 달리 hybrid가 항상 최선은 아닐 수 있습니다. 정확한 키워드 매칭이 필요한 법령 조항 검색에서는 keyword 모드가 더 높은 정밀도를 보일 수 있고, 자연어 질문 응답에는 semantic이 빠릅니다.
채팅에 바로 붙이는 방식도 있습니다
collections_search를 tools 파라미터에 넣으면, 채팅 API 호출 시 Grok이 자동으로 지정한 컬렉션에서 검색해서 답변합니다. 이 방식에서는 도구 호출 1회당 $2.50/1,000 calls 요금이 발생합니다. 모델 토큰 비용과 별도입니다. 자주 호출되는 서비스라면 이 두 비용을 합산해서 예산을 잡아야 합니다.
자주 나오는 질문 5가지
Q. Collections API와 Files API는 다른 건가요?
A. 맞습니다. Files API는 채팅 대화에 파일을 직접 첨부하는 방식으로, 대화 맥락 내에서만 유효합니다. Collections API는 대용량 문서를 지속적으로 저장하고 여러 요청에서 반복 검색하는 구조입니다. 하나의 파일이 여러 컬렉션에 동시에 속할 수도 있습니다. (출처: xAI 공식 문서 docs.x.ai/developers/files/collections)
Q. 업로드한 문서로 모델이 학습되나요?
A. xAI 공식 문서 기준으로, Collections에 저장된 사용자 데이터는 사용자가 명시적으로 동의하지 않는 한 모델 학습에 사용되지 않습니다. 엔터프라이즈 요금제 기준으로 이 정책이 적용됩니다. (출처: xAI 공식 문서 docs.x.ai/developers/files/collections, 2025.12 기준)
Q. 한국어 문서 처리가 잘 되나요?
A. 지원 MIME 타입 목록에 HWP(한글 파일)와 UTF-8 텍스트 파일이 포함되어 있습니다. 한국어 시맨틱 검색 성능에 대한 공식 벤치마크는 현재 공개되지 않아 확인이 필요합니다. PDF나 텍스트 형식으로 변환해서 업로드하는 방식이 현재로선 가장 안정적입니다.
Q. 100GB를 초과하면 어떻게 되나요?
A. 공식 문서 기준으로 100GB 초과 시 x.ai/contact를 통해 상한 증가를 요청할 수 있습니다. 자동 처리되는 구조가 아니므로, 대용량 운영 환경이라면 미리 문의해서 한도를 늘려두는 것이 안전합니다. (출처: xAI 공식 문서)
Q. OpenAI가 아니라 굳이 xAI를 써야 할 이유가 있나요?
A. 금융 및 코드 도메인 기준 벤치마크에서 GPT 5.1보다 높은 수치를 기록했고, 스토리지 별도 일일 요금 미명시라는 구조적 차이가 있습니다. 다만 법률 도메인에서는 Gemini Pro 3가 근소하게 앞서고, xAI 생태계 자체가 상대적으로 신생이라 커뮤니티 자료와 레퍼런스가 OpenAI 대비 적은 편입니다. 금융·코딩 특화 RAG 프로젝트라면 검토할 가치가 있습니다.
마치며 — 어떤 상황에서 쓸 만한가
Grok Collections API는 “RAG 인프라를 직접 구성하기 싫다”는 니즈에 명확하게 대응하는 서비스입니다. OCR·파싱·인덱싱·재인덱싱을 API 하나로 해결한다는 콘셉트는 실제 개발 시간을 줄이는 데 효과가 있습니다.
개인적으로 이 API가 가장 빛나는 구간은 금융 데이터와 코드베이스 검색 쪽입니다. 법률 특화 시스템을 만든다면 Gemini의 법률 도메인 수치가 근소하게 높다는 점을 감안해야 합니다. 대용량 운영이라면 100GB 상한과 파일 상한이 어느 시점에서 문제가 될지 미리 계산해두는 것이 좋습니다.
검색 단가는 OpenAI와 동일한 $2.50/1,000 calls이지만, 스토리지 비용 구조가 다르게 설계되어 있습니다. 저장량이 클수록 이 차이가 커질 수 있습니다. 요금은 xAI 콘솔에서 직접 확인하고, 실제 사용 전에 소규모 테스트로 비용 구조를 검증하는 것이 실수를 줄이는 방법입니다.
본 포스팅 참고 자료
본 포스팅 작성 이후 xAI 서비스 정책·UI·기능·요금이 변경될 수 있습니다. 모든 수치 및 요금 정보는 2025.12.22 공식 발표 및 2026.03.20 기준 공식 문서를 바탕으로 작성되었으며, 실제 적용 전 xAI 콘솔 및 공식 문서에서 최신 정보를 확인하시기 바랍니다.
댓글 남기기