문서 파이프라인을 만들 때 가장 먼저 부딪히는 문제는 파싱입니다. PDF, 스캔본, 이미지, 레이아웃이 복잡한 문서를 LLM이 쓰기 좋은 구조로 바꾸려면 도구 선택이 중요합니다. 이 글은 Unstructured란 무엇인가, LlamaParse란 무엇인가, Vision API란 무엇인가를 비교해 실무 기준으로 정리합니다.
이런 분께 추천합니다 #
- 사내 문서 ingest 표준을 정하려는 팀
- PDF와 이미지가 섞인 자료를 RAG에 넣어야 하는 개발자
- OCR 이후 구조화 추출까지 한 번에 설계하려는 분
비교 기준 #
비교는 기능 이름보다 파이프라인 관점이 중요합니다.
| 기준 | Unstructured | LlamaParse | Vision API |
|---|---|---|---|
| 주력 역할 | 문서 ETL | 문서 파싱과 구조화 출력 | 이미지 이해와 추출 |
| 강점 | 커넥터와 분해 흐름 | 복잡한 PDF와 레이아웃 | 멀티모달 입력 대응 |
| 잘 맞는 입력 | PDF, HTML, 이메일 | PDF, 스캔 문서, 표 | 스크린샷, 사진, 스캔 |
| 후속 단계 | Chunking, embeddings | Parsing, indexing | Structured Outputs, search |
무엇이 다를까 #
Unstructured는 문서를 ETL 계층으로 다루는 데 강합니다. LlamaParse는 문서 파싱 품질과 구조화 출력에 초점이 있습니다. Vision API는 이미지를 읽어 다음 자동화 단계로 넘기는 데 유리합니다. 즉 하나의 도구로 다 해결하기보다, 입력 타입과 품질 목표에 따라 분리해서 보는 편이 맞습니다.
어떤 상황에 맞는가 #
Unstructured는 다양한 소스에서 문서를 모아 전처리하고 싶을 때 좋습니다. LlamaParse는 복잡한 PDF와 레이아웃을 안정적으로 읽어야 할 때 적합합니다. Vision API는 이미지 자체가 핵심 입력일 때 강합니다. 예를 들어 영수증, 스크린샷, 현장 사진은 Vision API 쪽이 자연스럽습니다.
아키텍처 도식 #
권장 아키텍처는 단순합니다. 원본 입력을 먼저 분류하고, 문서형이면 Unstructured나 LlamaParse로 보내고, 이미지형이면 Vision API를 거쳐 구조화 결과를 만듭니다. 이후에는 공통 chunking, embedding, retrieval 단계로 합치는 방식이 운영하기 쉽습니다.
체크리스트 #
- 입력이 문서인지 이미지인지 먼저 분리하기
- PDF가 복잡하면 파싱 품질을 우선 검증하기
- chunk 전략과 파싱 전략을 섞지 않기
- 표와 이미지가 많은 문서는 멀티모달 경로를 고려하기
- 후속 검색 품질까지 포함해 평가하기
결론 #
2026년 기준 문서 파싱은 도구 하나를 고르는 문제가 아니라 파이프라인을 설계하는 문제입니다. 문서 ETL에는 Unstructured, 복잡한 파싱에는 LlamaParse, 이미지 이해에는 Vision API가 각각 잘 맞습니다.
참고한 자료 #
- Unstructured docs: https://docs.unstructured.io/
- LlamaIndex docs: https://developers.llamaindex.ai/
- OpenAI Vision / Responses docs: https://platform.openai.com/docs/guides/responses-vs-chat-completions