welclaiAI·TREND·DIGEST
활용

LLM으로 데이터 추출하기: 지저분한 텍스트를 표로 바꾸기

비정형 텍스트를 깔끔한 행과 열로 바꾸는 일에서 LLM은 조용히 빛납니다. 스키마를 정의하고, 모든 필드를 검증하고, 지저분한 입력에 대비한다면 말입니다.

use-cases2026-05-08 10:46 KST·편집장·7

상당히 많은 유용한 정보가 어떤 스프레드시트도 읽을 수 없는 텍스트 속에 삽니다. 이메일, 청구서, 이력서, 지원 티켓, 계약서, 메모 같은 것 말입니다. 이 모든 것을 깔끔한 행과 열에 쏟아붓는 것이 꿈이며, 이것은 언어 모델이 진정으로 결과를 내는 과제 중 하나입니다. 자유 형식 생성과 달리 추출에는 정답이 있습니다. 값은 텍스트 안에 있거나 없거나 둘 중 하나이며, 이는 추출을 대부분의 AI 사용 사례보다 더 유용하면서도 더 점검 가능하게 만듭니다. 이 글은 이것을 잘 해내는 법과, 어디서 잘못되는지에 대한 개념적 안내입니다.

텍스트가 아니라 스키마에서 시작하라

가장 흔한 실수는 모델에게 "중요한 정보를 뽑아내라"고 요청하는 것입니다. 그 지시에는 정답이 없으므로, 문서마다 모양이 달라져 표에 결코 적재할 수 없는 일관성 없는 필드를 얻게 됩니다. 대신 목표 스키마를 정밀하게 정의하는 데서 시작하십시오. 원하는 정확한 필드, 각각의 타입(텍스트, 숫자, 날짜, 범주, 불리언), 그리고 각각이 무엇을 의미하는지 말입니다. "청구 총액은 숫자로, 통화는 세 글자 코드로, 만기일은 YYYY-MM-DD로"는 모델이 일관되게 맞힐 수 있는 목표입니다. "돈에 관한 것들"은 그렇지 않습니다. 스키마는 명세서입니다. 하류의 모든 것이 그것을 먼저 명시적으로 만드는 데 달려 있습니다.

부재를 일급 값으로 다뤄라

실제 문서는 불완전합니다. 당신이 기대하는 필드는 흔히 누락되어 있을 것이며, 이것이 다뤄야 할 가장 중요한 단 하나입니다. 필드를 채워야 한다는 압박 아래의 모델은 빈칸으로 두는 대신 그럴듯한 값을 지어내기 때문입니다. 지어낸 청구서 번호는 진짜와 똑같아 보이며, 무엇도 그것을 틀렸다고 표시하지 않기에 빈 칸보다 훨씬 위험합니다. 그러니 "존재하지 않음"이 어떤 모습인지 — null, 빈 문자열, 특정 표식 — 를 명시적으로 정의하고, 값이 정말로 텍스트에 없을 때마다 그것을 쓰도록 모델에 지시하십시오. "필드가 존재하지 않으면 null을 반환하라. 추측하지 말라"는 어떤 추출 프롬프트에서든 가장 가치 있는 문장 중 하나입니다.

구조화된 출력을 요청하고 제약하라

이후에 파싱해야 하는 산문이 아니라, 구조화된 형식 — 보통 당신의 스키마에 맞춘 JSON — 으로 데이터를 요청하십시오. 현재 대부분의 모델과 서빙 도구는 당신이 제공하는 스키마를 따르는 제약된 혹은 구조화된 출력을 지원하며, 그 메커니즘은 Hugging Face 문서 같은 자료에 잘 정리되어 있습니다. 필드 이름을 원하는 그대로 정확히 제공하고, 각각의 타입과 허용 값을 명시하며, 범주형 필드에는 옵션의 닫힌 목록을 주어 모델이 라벨을 지어내는 대신 당신의 분류 체계에서 고르게 하십시오. 제약이 빡빡할수록 출력이 더 일관되고, 일관성이야말로 전부입니다. 당신은 줄이 맞아야 하는 행들을 만들고 있으니까요.

말하지 말고 보여줘라

지시에 잘 다듬어진 예시 두어 개 — 대표적인 입력의 일부와 그것에서 원하는 정확한 구조화된 출력 — 를 포함하면 추출 품질이 도약합니다. 예시는 산문이 전달하기 힘든 예외 상황을 전달합니다. 부분 날짜를 어떻게 형식화할지, 하나를 기대했는데 두 값을 어떻게 다룰지, 존재하지만 모호한 필드를 어떻게 할지 말입니다. 깔끔한 경우만이 아니라 어색한 경우를 다루는 예시를 고르십시오. 깔끔한 경우는 애초에 문제였던 적이 없으니까요. 잘 고른 예시 몇 개가 종종 여러 문단의 규칙보다 가치 있으며, 추가하는 데 드는 비용은 거의 없습니다.

추출 후 모든 필드를 검증하라

추출된 데이터를 결코 무턱대고 신뢰하지 마십시오. 돌아오는 즉시, 또 다른 모델이 아니라 평범한 코드로 검증하십시오. 타입이 맞는지 확인하십시오. 날짜 필드가 날짜로 파싱되는지, 숫자 필드가 수치인지, 범주가 허용된 값 중 하나인지. 범위와 형식을 확인하십시오. 수량이 음수가 아닌지, 이메일에 "@"가 들어 있는지, 코드가 기대 패턴과 맞는지. 가능한 곳에서는 내부 일관성을 교차 점검하십시오. 항목들의 합이 명시된 총액과 맞는지. 검증은 모델 오류와 진짜로 잘못된 형식의 입력을 둘 다 잡아내는 곳이며, 조용한 불량 데이터를 보이고 라우팅 가능한 예외로 바꿉니다. 검증에 실패하는 것은 무엇이든 표에 적재하는 대신 사람에게 표시되어야 합니다.

실패하는 것의 경로를 계획하라

강력한 파이프라인조차 모든 것을 올바르게 추출하지는 못하며, 그렇지 않은 척하는 것이 불량 데이터가 데이터베이스를 오염시키는 길입니다. 추출이나 검증이 실패할 때 무슨 일이 일어날지 미리 정하십시오. 신뢰도가 낮거나 잘못된 레코드를 떨어뜨리거나 맹목적으로 받아들이는 대신 사람의 검토 대기열로 라우팅하십시오. 이 인간 개입(human-in-the-loop) 폴백이, 신뢰할 수 있는 시스템과 시간이 지나며 조용히 데이터를 부패시키는 시스템의 차이를 만듭니다. 그것은 또한 NIST AI 위험 관리 프레임워크 같은 체계가 권장하는 바로 그런 결과 인식 통제입니다. 오류가 하류 비용을 가질 때, 사람이 루프 안에 머무는 것입니다. 검토 대기열은 실패의 표시가 아닙니다. 쉬운 90퍼센트를 자신 있게 자동화하게 해주는 안전밸브입니다.

라벨링된 표본에 대조해 측정하라

파이프라인을 규모 있게 신뢰하기 전에 측정하십시오. 대표적인 문서 표본을 올바른 추출로 직접 라벨링한 다음, 파이프라인을 돌려 필드별로 비교하십시오. 필드별 정확도는 어떤 필드가 신뢰할 만하고 어떤 필드가 손봐야 하는지 알려줍니다. 그리고 그 답은 거의 늘 들쭉날쭉합니다. 깔끔한 필드는 거의 완벽하고 지저분한 필드는 고전합니다. 이를 통해 정보에 입각한 결정을 내릴 수 있습니다. 신뢰할 만한 필드는 자동화하고, 신뢰할 수 없는 필드는 검토로 라우팅하는 것입니다. 스키마, 프롬프트, 예시, 혹은 모델을 바꿀 때마다 측정을 다시 돌리십시오. 그 각각이 예전에 잘되던 필드를 조용히 망가뜨릴 수 있기 때문입니다. 추출은 정답(ground truth)이 구체적인 몇 안 되는 AI 과제 중 하나이므로, 측정하지 않을 핑계가 없습니다.

모델을 탓하기 전에 입력을 살펴라

놀랄 만큼 많은 추출 문제가 모델과는 아무 상관이 없고, 텍스트가 어떻게 도착했는지와 전적으로 관련됩니다. 문서는 깔끔한 디지털 텍스트로, 스캔 이미지로, 레이아웃을 망가뜨린 내보내기 결과로, 혹은 시각적 구조가 원시 텍스트로는 잃어버리는 의미를 담고 있는 형식으로 당신에게 도착합니다. 표가 한 줄로 평평하게 뭉개지거나, 스캔본이 문자 오류와 함께 텍스트로 변환되면, 모델은 쓰레기에서 추출하는 셈이며 당신의 스키마가 아무리 좋아도 쓰레기를 만들어냅니다. 프롬프트를 튜닝하기 전에, 모델이 실제로 무엇을 받고 있는지 — 화면에 보이는 모습이 아니라 파이프라인이 보는 입력 — 를 들여다보십시오. 종종 가장 효과적인 해결책은 상류에 있습니다. 더 나은 변환, 보존된 구조, 혹은 답을 담고 있던 바로 그 레이아웃을 파괴하는 텍스트 채널로 억지로 밀어넣는 대신 이미지를 이미지로 다루는 것 말입니다.

비용과 규모도 일찍 고려하는 것이 이롭습니다. 추출은 흔히 대량 작업이기 때문입니다. 모든 문서를 가장 유능하고 가장 비싼 모델로 돌릴 필요는 드뭅니다. 많은 필드는 쉬워서 더 작고 저렴한 모델이 안정적으로 처리하고, 더 어려운 필드나 어려운 문서만 더 강력한 모델로 에스컬레이션하면 됩니다. 가능한 것은 배치 처리하고, 정확도를 측정하는 것과 같은 방식으로 문서당 비용을 측정하십시오. 정확하지만 실제 물량에서 경제성이 없는 파이프라인은 실제로 배포 가능한 것이 아닙니다. 그리고 그것을 발견할 때는 백만 건의 레코드에 겨눈 뒤가 아니라 설계 중입니다.

정리

지저분한 텍스트를 표로 바꾸는 일은 언어 모델로 할 수 있는 가장 신뢰할 만하고, 점검 가능하며, 조용히 가치 있는 일 중 하나입니다. 그것을 마법이 아니라 엔지니어링으로 다룬다면 말입니다. 스키마를 먼저 정의하고, 부재를 명시적으로 만들어 모델이 결코 값을 지어내지 않게 하며, 제약된 구조화 출력을 요청하고, 예시로 가르치며, 모든 필드를 코드로 검증하고, 실패를 사람에게 라우팅하며, 라벨링된 데이터에 대조해 측정하십시오. 검증과 검토 대기열을 건너뛰면 그럴듯하고 틀린 행을 생성하는 빠른 기계를 얻습니다. 그것들을 갖춰 넣으면, 어떤 스프레드시트도 결코 읽을 수 없던 텍스트에서 깔끔한 데이터를 얻습니다.

#data-extraction#structured-output#validation#tutorial