청크(chunks) 크기를 512에서 1024 토큰으로 변경하면서 Vectorize 비용을 월 $1.20 절감했습니다. 하지만 Claude Sonnet 비용은 $92가 더 발생했습니다. 계산을 해보기 전까지는 이런 결과가 나올 줄 몰랐습니다.

저는 매 사이클마다 RAG 단계를 거치는 일일 에이전트 워크플로우를 가진 광고 분석 SaaS를 운영하고 있으며, 하루에 약 400회 실행됩니다. 실제로 측정해보고 싶다는 호기심이 생기기 전까지 3개월 동안 청크 크기를 기본값인 512 토큰으로 설정해 두었습니다. 그래서 동일한 100개의 광고 보고서를 세 가지 방식(256, 512, 1024 토큰)으로 인덱싱하고, 20개의 고정된 쿼리를 각각 5번씩 실행한 뒤 지연 시간(latency), 인용 정확도(citation accuracy), 그리고 예상 월간 비용을 추적했습니다.

요약 테이블은 512 토큰이 깔끔하게 승리하는 것처럼 보였습니다:

청크 크기 (Chunk size)	평균 지연 시간 (Avg latency)	인용 정확도 (Citation accuracy)	월간 벡터 비용 (Monthly vector cost)
256 tokens	43ms	16.2 / 20	~$4.80
...

하지만 벡터 저장소 수치는 함정입니다. 1024 토큰 청크를 사용하면, top_k: 5 검색 시 Claude의 컨텍스트(context)로 약 2,560 토큰이 아닌 약 5,120 토큰이 들어옵니다. 입력 토큰 100만 개당 $3를 기준으로 계산하면, 약 2,560개의 추가 토큰 × 월간 12,000회 호출 = 3,070만 토큰 = 월 $92가 됩니다. Vectorize에서 아낀 $1.20는 이에 비하면 미미한 수준입니다.

또한 1024 토큰 청크는 환각(hallucination)이라기보다는 제가 _희석(dilution)_이라고 부를 만한 현상을 만들어냈습니다. Claude가 내용을 지어내는 것은 아니었지만, 주변 텍스트를 너무 많이 포함하여 실제 핵심을 놓치는 문제가 발생했습니다. 예를 들어 한 캠페인의 60일간 성과 데이터가 하나의 밀집된 청크로 들어오면, 모델은 제가 질문한 이상치(anomaly) 대신 평균값만을 제시하곤 했습니다. 반대로 청크가 너무 작으면 정반대의 문제가 발생합니다. 캠페인 요약이 세 개의 256 토큰 조각으로 나뉘어 있으면, top_k: 3 결과가 불완전한 정보를 가져오는 경우가 많았습니다.

현재 제가 운영하는 방식은 동일한 데이터에 대해 두 개의 인덱스를 사용하는 것입니다. 정확도가 우선인 요약 쿼리를 위한 report-512 네임스페이스(namespace)와 지연 시간에 민감한 즉석 질문을 위한 live-256 네임스페이스를 구분하여 사용합니다:

const summaryChunks = await vectorize.query(embedding, {
  topK: 5,
  namespace: 'report-512',
...

저장 비용은 두 배로 늘어났지만, 제 호출량(call volume) 기준으로는 라이브 경로(live path)에서의 Claude 비용 절감액이 이를 충분히 상쇄하고도 남습니다. 호출량이 더 적은 환경에서도 이 계산이 성립할지는 — 아마도 그렇지 않을 것입니다.

또한 이번 실험 도중 청크 크기(chunk size)와는 전혀 무관한 운영 장애(production incident)를 겪기도 했습니다. 인덱스(index) 중간에 임베딩 모델(embedding model)을 교체하면서 차원 불일치(dimension mismatch)가 발생했고, 이로 인해 오전 9시에 RAG 단계 전체가 중단되었습니다. 해당 장애 사례와 아직 실행하지 않은 청크 중첩(chunk overlap) 실험 결과는 전체 보고서에 담겨 있습니다.

차원 불일치 사고와 문서 유형별 동적 청킹(dynamic chunking)으로 다음에 무엇을 테스트할지에 대한 내용을 포함하여 전체 분석 내용을 riversealab.com에 작성했습니다.

전체 포스트 보기 →