수집한 데이터는 모아 놓는 것만으로는 쓸모가 없습니다. 정책 공고 수집 파이프라인에서 우리가 매일 받아오는 공고는 기관도 형식도 제각각인 원문 덩어리였습니다. 앱에서 시민에게 보여주려면 "누구를 위한, 어떤 종류의, 어떤 혜택인가"가 구조화되어야 했습니다. 사람이 붙어 태깅하던 이 일을 LLM 데이터 분류로 자동화하면서 내린 결정들을 정리합니다.
LLM 데이터 분류는 출력 스키마부터
LLM 분류 설계의 절반은 프롬프트가 아니라 출력 스키마 정의입니다. 우리는 다운스트림(앱 화면과 검색 필터)이 실제로 쓰는 것만 여섯 필드로 고정했습니다. 담당 기관, 공고 성격(정책·행사·구인), 관심 주제, 생애주기 대상, 문의처와 전화번호, 그리고 카드에 표시할 핵심 혜택 한 줄입니다.
필드가 애매하면 모델도 애매하게 답합니다. 각 필드에 허용값 목록이나 형식 규칙을 정의하고 응답은 스키마 검증(zod)을 통과해야만 적재됩니다. 검증에 실패한 응답은 데이터가 아니라 실패 로그로 남습니다. LLM을 파이프라인의 한 단계로 쓸 때는 이 경계 검증이 품질의 마지노선입니다.
하이브리드: 코드가 있으면 코드, 없을 때만 AI
두 번째 결정은 전부 AI에게 맡기지 않는 것이었습니다. 일부 소스에는 기관이 부여한 표준 분류코드가 이미 있습니다. 그 경우 코드 매핑을 그대로 쓰고 표준코드가 없는 소스만 LLM이 판단합니다.
이 하이브리드 구성의 이점은 세 가지입니다. 이미 정답이 있는 데이터에는 추론 비용을 쓰지 않습니다. 표준코드가 있는 데이터는 결과가 결정적이라 흔들림이 없습니다. AI 판단 대상이 줄어 검수 범위도 좁아집니다. "AI로 분류한다"는 말이 곧 "전부 AI에 맡긴다"일 필요는 없습니다.
모델은 작게, 검증은 단단하게
분류·추출처럼 출력 형식이 좁게 정의된 작업에는 경량 모델을 썼습니다. 필드 정의가 명확할수록 작은 모델과 큰 모델의 격차는 줄고 매일 수백 건 이상을 처리하는 파이프라인에서는 속도와 비용이 품질만큼 중요해집니다. 모델 등급을 정하는 일반적인 기준은 LLM 트레이드오프에서 다룬 그대로입니다. 얇은 모델이 흔들리는 지점은 스키마 검증과 재시도가 받쳐 줍니다.
대량 처리는 실시간 호출 대신 배치 API로 돌렸습니다. 100건 단위로 묶어 비동기로 제출하면 결과는 몇 시간 안에 돌아오고 호출 비용은 절반 수준으로 내려갑니다. 매일 새벽 배치라는 파이프라인 특성상 실시간성이 필요 없었기 때문에 이 선택은 사실상 공짜 할인이었습니다. 생성형 AI 기능의 비용을 구조적으로 묶는 방법은 생성형 AI 비용 게이트에서 더 자세히 다룹니다.
프롬프트도 버전을 가진다
분류 프롬프트는 코드와 함께 버전 관리합니다. 허용값 목록이 바뀌거나 필드 정의가 조정되면 프롬프트 버전을 올리고 어떤 버전으로 분류된 데이터인지 추적할 수 있게 했습니다. 분류 기준이 바뀌었을 때 과거 데이터를 재분류할지 판단하려면 이 이력이 필요합니다.
운영에서는 분류 실패의 재처리 경로도 필요합니다. 우리는 레코드 단위로 실패를 격리해 한 건의 오류가 배치 전체를 멈추지 않게 하고 실패분만 골라 다시 돌리는 재분류 스크립트를 운영 도구로 두었습니다. 프롬프트 버전을 올린 뒤 과거 데이터를 새 기준으로 재분류할 때도 같은 경로를 씁니다. 분류를 한 번의 이벤트가 아니라 반복 가능한 공정으로 만들어 두면 기준 변경이 두렵지 않게 됩니다.
전체 파이프라인에서 분류는 중간 단계입니다. 분류를 마친 데이터는 여러 출처의 중복을 통합하는 단계로 넘어가는데 그 설계는 LLM 의미 중복 제거 설계에서 이어집니다. 이 시스템의 전체 그림은 공공데이터 크롤링 자동화 사례에서 볼 수 있습니다.
자주 묻는 질문
LLM 데이터 분류는 어떤 데이터에 적합한가요?
사람이 분류 기준을 명확한 필드와 허용값으로 정의할 수 있는 데이터에 적합합니다. 원문이 자연어라 규칙 기반 파싱이 어렵지만 출력은 좁게 구조화되는 작업일수록 LLM 분류의 효과가 큽니다. 정책 공고, 문의 메일, 상품 설명 태깅이 전형적인 예입니다.
분류 결과가 틀리면 어떻게 하나요?
응답 스키마 검증으로 형식 오류를 먼저 걸러내고 허용값 밖의 답은 적재하지 않습니다. 내용 판단이 흔들리는 경우에 대비해 표준코드가 있는 소스는 코드를 우선하는 하이브리드로 AI 판단 범위 자체를 줄였습니다. 남는 오류는 운영 대시보드에서 발견해 프롬프트나 허용값 정의를 고치는 순환으로 관리합니다.
비용은 어느 정도로 봐야 하나요?
작업 단가는 모델 등급과 호출 방식이 결정합니다. 우리는 분류처럼 형식이 좁은 작업에 경량 모델을 쓰고 대량 처리는 배치 API로 묶어 실시간 상위 모델 대비 비용을 크게 낮췄습니다. 여기에 실행당 비용 상한을 걸어 이상 동작으로 인한 폭주를 차단했습니다.
분류 필드는 몇 개가 적당한가요?
다운스트림이 실제로 소비하는 것만 담는 게 기준입니다. 우리는 앱 화면과 검색 필터가 쓰는 여섯 필드로 고정했습니다. 필드가 늘수록 프롬프트와 검증, 오류 관리 비용이 함께 늘어나므로, "있으면 좋을 것 같은" 필드는 빼는 쪽이 맞습니다.
사람 검수는 완전히 없앨 수 있나요?
없애기보다 옮긴다고 보는 게 정확합니다. 건별 태깅은 사라지지만 분류 기준을 정의하고 예외를 보고 기준을 다듬는 일은 사람 몫으로 남습니다. 검수가 건 단위에서 기준 단위로 올라가는 것이 자동화의 실제 모습입니다.