🎯 CSV는 이제 그만! LLM이 가장 잘 이해하는 테이블 포맷은?

 

안녕하세요! 요즘 AI 시스템 개발하시느라 정말 고생 많으시죠?

특히 RAG 파이프라인 구축하실 때 테이블 데이터를 어떤 형식으로 LLM에 전달해야 할지 고민해보신 적 있으실 거예요.

그냥 익숙한 CSV 쓰시나요? 아니면 JSON이 표준이라고 생각하시나요?

사실 이 선택 하나가 시스템의 정확도와 비용에 엄청난 영향을 미친다는 사실, 알고 계셨나요?

왜 데이터 포맷이 이렇게 중요할까요?

많은 RAG 파이프라인에서 문서 안의 테이블 정보를 추출해서 LLM에 전달하는 과정이 필수적이에요.

그런데 데이터 포맷을 잘못 선택하면 두 가지 큰 문제가 발생해요.

첫째는 시스템 정확도 문제예요. LLM이 소화하기 어려운 형식으로 데이터를 주면 답변의 정확도가 불필요하게 낮아질 수 있어요.

둘째는 토큰 비용 증가예요. 어떤 포맷은 같은 데이터를 표현하는 데 다른 포맷보다 몇 배나 많은 토큰을 사용하거든요.

OpenAI의 GPT-4 API는 입력 토큰 100만 개당 약 13만 원, 출력 토큰은 약 52만 원이 청구돼요. 토큰 사용량에 따라 과금되는 LLM API를 쓰신다면 이건 곧 비용 증가로 직결되는 거죠.

실험은 어떻게 진행됐을까요?

한 연구팀이 통제된 실험 환경에서 데이터 포맷이 LLM의 정확도에 미치는 영향을 철저하게 테스트했어요.

실험 설계는 이랬어요. 1,000개의 합성 직원 레코드를 LLM에 전달하고 그 데이터를 바탕으로 질문에 답하게 했어요.

각 레코드는 8개의 속성을 가지고 있었죠. ID, 이름, 나이, 도시, 부서, 급여, 경력, 프로젝트 수 같은 것들이요.

그리고 1,000개의 무작위 질문을 던졌어요. 이 과정을 11가지 서로 다른 데이터 포맷으로 반복했고요.

사용한 모델은 GPT-4.1 나노였어요. 이 모델은 OpenAI가 2025년 4월에 공개한 GPT-4.1 패밀리 중 가장 작고 빠른 버전이에요.

100만 토큰의 컨텍스트 윈도우를 지원하면서도 MMLU 벤치마크에서 80.1%를 기록했죠. 특히 분류나 자동완성 같은 작업에 최적화되어 있고 입력 토큰당 약 130원의 저렴한 비용으로 사용할 수 있어요.

질문 예시를 한번 볼까요?

"Grace X413의 경력은 몇 년이에요?" 답: "15"

"Alice W204의 급여는 얼마예요?" 답: "131370"

이런 식으로 특정 레코드의 필드 값을 찾는 질문들이었어요.

충격적인 실험 결과가 나왔어요

자 이제 가장 궁금하신 결과를 공개할게요. 11가지 포맷 중 어떤 게 가장 좋았을까요?

Markdown-KV 포맷이 60.7%의 정확도로 1등을 차지했어요.

그런데 많은 개발자들이 기본으로 사용하는 CSV는 44.3%로 하위권에 머물렀어요. 무려 16.4%포인트 차이가 나요.

JSON도 52.3%로 기대보다 낮았고 JSONL은 더 낮은 45.0%를 기록했어요.

반면 XML은 56.0%, YAML은 54.7%로 상위권에 올랐네요.

여기서 재미있는 트레이드오프가 있어요.

정확도가 높은 Markdown-KV는 52,104개의 토큰을 사용한 반면 가장 토큰 효율적인 CSV는 19,524개만 사용했어요. 약 2.7배 차이가 나죠.

GPT-4.1 나노의 가격이 입력 토큰 100만 개당 약 130원이니까 CSV로 처리하면 약 2,538원, Markdown-KV로 처리하면 약 6,773원이 드는 거예요.

정확도를 위해 약 2.7배의 비용을 지불해야 하는 거죠.

각 포맷은 실제로 어떻게 생겼을까요?

1등을 차지한 Markdown-KV는 이렇게 생겼어요.

각 레코드를 마크다운 헤더로 구분하고 키-밸류 쌍으로 정보를 표현하는 방식이에요. 구조가 명확하고 읽기 쉽죠.

반면 CSV는 우리가 익숙한 형태예요. 헤더 한 줄, 데이터 한 줄씩 간결하게 표현되지만 LLM이 이해하는 데는 어려움이 있었나 봐요.

JSON은 구조화되어 있고 프로그래밍적으로 다루기 쉽지만 LLM 정확도 면에서는 중간 정도였어요.

흥미로운 건 XML이에요. 56.0%의 정확도로 2위를 차지했는데 76,114개의 토큰을 사용해서 비용 면에서는 가장 비쌌어요.

하지만 복잡한 계층 구조를 가진 데이터에서는 XML의 명확한 태그 기반 구조가 LLM의 이해를 도울 수 있어요.

실무에 어떻게 적용할 수 있을까요?

이 실험 결과를 바탕으로 실무에 적용할 수 있는 인사이트를 정리해볼게요.

첫째, 정확도가 최우선이라면 Markdown-KV를 고려해보세요.

특히 RAG 시스템에서 사용자 경험이 중요하고 약간의 추가 비용을 감수할 수 있다면 좋은 선택지예요. Databricks의 경우 RAG 파이프라인에서 데이터 품질이 1% 향상되면 최종 답변 정확도가 3-5% 개선된다는 연구 결과를 발표했어요.

둘째, 가독성과 비용의 균형이 필요하다면 마크다운 테이블을 고려해보세요.

51.9%의 정확도로 중간 정도이지만 25,140개의 토큰만 사용해서 비용 효율적이에요. 월간 100만 건의 쿼리를 처리하는 시스템이라면 Markdown-KV 대비 약 55만 원의 비용을 절감할 수 있어요.

셋째, CSV나 JSONL을 기본값으로 쓰는 건 조심하세요.

이 흔한 포맷들이 실제로는 시스템 정확도를 해칠 수 있어요. NVIDIA의 NeMo 프레임워크 문서에서도 RAG 시스템 구축 시 데이터 포맷 최적화를 핵심 단계로 강조하고 있어요.

넷째, 테이블이 포함된 복잡한 PDF를 처리할 때는 전처리가 필수예요.

UnstructuredIO 같은 도구를 사용해서 테이블을 추출한 후 적절한 포맷으로 변환하는 과정이 중요해요. UnstructuredIO는 2024년 기준 월간 500만 건 이상의 문서 처리를 지원하는 오픈소스 라이브러리예요.

다른 LLM 모델에서는 어떨까요?

GPT-4.1 나노만 테스트했다는 게 이 실험의 한계인데요.

다른 모델들은 어떨지 궁금하시죠?

Anthropic의 Claude 3.5 Sonnet은 200K 토큰의 컨텍스트 윈도우를 지원하고 입력 토큰 100만 개당 약 390원, 출력 토큰은 약 1,950원의 비용이 들어요.

Claude는 특히 구조화된 데이터 처리에 강점을 보이는데 학습 데이터의 특성상 XML이나 JSON 같은 구조화된 포맷에서 더 좋은 성능을 낼 가능성이 있어요.

Google의 Gemini 1.5 Pro는 무려 200만 토큰의 컨텍스트 윈도우를 지원하고 입력 토큰 100만 개당 약 325원의 비용이에요.

대용량 문서 처리에 특화되어 있어서 큰 테이블을 다룰 때 유리할 수 있어요.

Meta의 Llama 3.1 70B는 오픈소스 모델이라 직접 호스팅하면 비용을 크게 줄일 수 있어요.

AWS SageMaker에서 호스팅 시 시간당 약 1만 원 정도의 비용으로 운영할 수 있고 월간 수백만 건의 쿼리를 처리한다면 API 기반 모델보다 경제적일 수 있어요.

실제 프로덕션 환경에서는 어떻게 활용할까요?

실제 프로덕션 RAG 시스템을 구축할 때는 이런 점들을 고려해야 해요.

먼저 벡터 데이터베이스 선택이에요.

Pinecone은 월간 100만 건의 쿼리를 무료로 제공하고 그 이상은 1,000건당 약 130원의 비용이 들어요. Weaviate는 오픈소스로 직접 호스팅이 가능하고 Qdrant는 메모리 효율성이 뛰어나 대용량 데이터 처리에 강점이 있어요.

청크 크기 설정도 중요해요.

일반적으로 512-1024 토큰 단위로 문서를 분할하는데 테이블 데이터는 하나의 완전한 단위로 유지하는 게 좋아요. 테이블을 중간에 나누면 컨텍스트가 손실되어 정확도가 크게 떨어질 수 있거든요.

하이브리드 검색 전략도 고려해보세요.

벡터 검색과 키워드 검색을 결합하면 정확도가 15-20% 향상될 수 있어요. Elasticsearch와 벡터 데이터베이스를 함께 사용하는 방식이 대표적이에요.

비용 최적화는 어떻게 할까요?

RAG 시스템을 운영하다 보면 비용이 만만치 않아요.

캐싱 전략을 활용하면 비용을 30-50% 절감할 수 있어요.

Redis나 Memcached를 사용해서 자주 조회되는 쿼리 결과를 캐싱하면 LLM API 호출 횟수를 크게 줄일 수 있어요.

배치 처리도 효과적이에요.

여러 쿼리를 모아서 한 번에 처리하면 API 호출 오버헤드를 줄이고 처리 속도도 개선할 수 있어요. OpenAI의 Batch API는 일반 API 대비 50% 할인된 가격으로 제공돼요.

모델 라우팅 전략도 고려해보세요.

간단한 쿼리는 GPT-4.1 나노 같은 작은 모델로 처리하고 복잡한 쿼리만 큰 모델로 보내면 비용을 최적화할 수 있어요.

LangChain이나 LlamaIndex 같은 프레임워크는 이런 라우팅 로직을 쉽게 구현할 수 있게 도와줘요.

이 실험의 한계점도 알아야 해요

물론 이 실험에도 한계가 있어요.

첫째, 한 가지 패턴의 데이터만 테스트했어요. 실제 업무 데이터는 훨씬 다양하고 복잡하죠.

둘째, 단순한 테이블 형태만 테스트했어요. 병합된 셀이 있는 복잡한 테이블이나 중첩된 JSON 구조에서는 결과가 달라질 수 있어요.

셋째, 비교적 큰 테이블을 사용했고 헤더를 반복하지 않았어요. 더 작은 테이블이나 헤더를 주기적으로 반복하면 특히 CSV나 HTML 같은 헤더 기반 포맷의 정확도가 높아질 거예요.

넷째, 특정 레코드의 필드 값을 찾는 질문만 테스트했어요. 집계 계산이나 비교 같은 다른 유형의 질문에서는 다른 결과가 나올 수 있어요.

마무리하며

솔직히 데이터 포맷이 이렇게 큰 차이를 만들 줄은 몰랐어요.

그냥 CSV나 JSON 쓰면 되는 거 아닌가 싶었거든요.

하지만 이 연구 결과를 보면 간단한 데이터 변환만으로도 LLM 기반 시스템의 정확도를 크게 향상시킬 수 있다는 걸 알 수 있어요.

여러분이 RAG 시스템을 개발하고 계시다면 한번 다양한 포맷을 테스트해보시는 걸 추천드려요.

특히 CSV를 기본으로 쓰고 계셨다면 Markdown-KV나 XML 같은 포맷으로 바꿔보시고 정확도 변화를 측정해보세요.

작은 변화가 큰 차이를 만들 수 있답니다!

여러분의 RAG 시스템이 더 정확하고 효율적으로 작동하길 바랄게요.