LLM으로 비정형 문서 자동 구조화 — 메뉴 19개 추출 정확도 실측

데이터 입력이라는 병목

매장·업체 정보를 다루는 서비스는 모두 같은 병목을 만납니다. 실제 정보는 메뉴판, 안내문, 워드 문서 같은 비정형 문서에 있는데, 시스템이 원하는 것은 스키마가 잡힌 정형 데이터(이름·가격·카테고리·영업시간)입니다. 이 간극을 사람이 메우면 매장 하나에 수십 분씩 걸리고, 오타와 누락이 따라옵니다.

LLM은 이론적으로 이 변환에 최적입니다. 문서를 읽고 JSON으로 뱉으면 되니까요. 문제는 “얼마나 정확한가”를 아무도 숫자로 말해주지 않는다는 점입니다. 데모는 늘 그럴듯하지만, 실무 투입 판단에는 필드 단위 정확도가 필요합니다. 그래서 직접 측정했습니다.

테스트 설계 — 정답지를 먼저 만든다

정확도를 측정하려면 정답지가 필요합니다. 테스트용으로 만든 가상의 카페(“달빛카페”) 데이터를 사용했습니다 — 메뉴 19개짜리 메뉴판(menu.md)과 매장 안내문(info.md)을 마크다운으로 준비하고, 같은 내용을 사람이 직접 PostgreSQL에 입력해 기준 데이터로 삼았습니다. 흐름은 이렇습니다.

비정형 문서 (menu.md, info.md)
        │
        ▼  LLM 추출 (구조화 프롬프트 + JSON 스키마)
구조화된 JSON
        │
        ▼  필드 단위 대조
수동 입력 DB (정답지) ──▶ 정확도 산출

• 모델: Qwen3-14B-AWQ (SGLang 서빙)

  로컬 GPU에서 돌아가는 중급 모델. 클라우드 최상급이 아니라 '현실적으로 운영 가능한 로컬 모델'로 어디까지 되는지가 관심사였습니다.

• temperature 0.1

  추출 작업은 창의성이 필요 없습니다. 낮은 온도가 재현성과 정확도를 높입니다.

• thinking 모드 비활성화

  Qwen3의 reasoning 모드를 끄니(enable_thinking: false) JSON 출력이 안정화됐습니다. 추론 과정이 출력에 섞여 JSON 파싱이 깨지는 문제를 원천 차단합니다.

메뉴 추출 결과 — 가격은 100%

핵심 발견은 “정형에 가까운 데이터일수록 LLM 추출이 강하다”는 것입니다. 메뉴판의 표 형식 데이터에서 가격과 카테고리는 19개 전부, 단 하나의 오류도 없이 추출됐습니다. 숫자를 잘못 옮기거나 자릿수를 흘리는 일이 없었다는 뜻인데, 사람이 19개 메뉴 가격을 옮겨 적을 때의 오타율을 생각하면 이미 사람보다 정확한 영역입니다.

추출 시간은 메뉴 19개 전체에 5.92초. 사람이 같은 작업을 하면 아무리 빨라도 10분 이상 걸립니다. 속도 면에서는 비교 자체가 성립하지 않습니다.

실패 사례 분석 — ‘벚꽃’이 ‘베트꽃’이 된 이유

유일한 이름 불일치 1건이 흥미롭습니다. 원문의 “벚꽃라떼”를 “베트꽃라떼”로 추출했습니다. 없는 메뉴를 지어낸 게 아니라, 한글 음절을 미묘하게 잘못 옮긴 OCR 유사 오탈자입니다. 가격·카테고리는 이 항목도 정확했으니 “항목은 인식했지만 표기를 틀린” 케이스입니다.

그 외 관찰 사항 두 가지. 알레르기 정보는 원문에 명시된 디저트류는 정확히 추출하고, 명시가 없는 음료류는 null로 처리했습니다 — 없는 정보를 지어내지 않은 것은 오히려 긍정적입니다. 상세 설명(description) 필드는 원문 테이블에 없었으므로 전부 빈 문자열이었습니다. LLM 추출의 상한선은 결국 원문 품질입니다.

비즈니스 정보 추출 — 정규화의 벽

매장 안내문(info.md)에서 주소·연락처·영업시간 등 7개 필드를 추출해 대조했습니다. 결과는 7개 중 5개 일치(71.4%), 추출 시간 2.38초.

주의 깊게 볼 점은, 불일치의 원인이 LLM의 “이해력”이 아니라 “정규화”라는 것입니다. 전화번호, 와이파이 정보, 영업시간 같은 팩트는 전부 정확히 뽑았습니다. 문제는 “서울특별시”와 “서울”처럼 둘 다 맞는 표기의 차이, 그리고 좌석 수 30을 문자열로 반환해 숫자 30과 타입이 어긋난 것 — 즉 추출 이후 파이프라인에서 코드로 해결해야 할 문제들입니다.

실무 적용 가이드

이 실측을 바탕으로, LLM 자동 구조화를 실무에 넣는다면 파이프라인은 이렇게 구성해야 합니다.

• 1단계 — LLM 추출은 '초안 생성기'로 규정한다

  최종 데이터 생성기가 아닙니다. 100% 정확한 필드(가격·카테고리)가 있어도, 전체 파이프라인의 신뢰 수준은 가장 약한 필드 기준으로 잡아야 합니다.

• 2단계 — 스키마 검증 + 원문 대조 후처리

  JSON 스키마 검증으로 구조를 잡고, 추출된 문자열이 원문에 실제 존재하는지 대조해 '그럴듯한 오탈자'를 잡습니다. 타입 캐스팅과 표기 정규화(시·도 명칭 등)도 이 단계입니다.

• 3단계 — 사람은 입력자가 아니라 검수자

  사람의 역할이 '19개를 입력'에서 '하이라이트된 1~2개 의심 항목을 확인'으로 바뀝니다. 작업 시간은 10분의 1로 줄고, 정확도는 오히려 올라갑니다.

모델 크기에 대한 소감도 하나. 이 결과는 클라우드 최상급 모델이 아니라 로컬에서 돌아가는 14B 양자화 모델로 얻은 수치입니다. “문서 → 구조화 데이터” 작업은 이미 로컬 중급 모델의 사정권 안에 들어와 있고, 데이터가 외부로 나가면 안 되는 환경에서도 충분히 구축할 수 있습니다.

결론

한 줄 요약: LLM 자동 구조화는 초기 데이터 입력의 보조 수단으로 이미 충분히 실용적입니다. 다만 최종 데이터는 반드시 사람이 검수하고, 오탈자 검증과 정규화 후처리를 파이프라인에 내장해야 합니다.