사내 LLM 도입, 도메인 데이터셋 구축 단계별 오류 진단 실무

단계별로 드러나는 도메인 데이터셋 구축 실패의 주요 원인

사내 LLM 도입 프로젝트에서 가장 빈번하게 겪는 난관은 데이터셋 구축 단계별로 발생하는 품질 저하와 그로 인한 학습 성능 하락이다. 특히 도메인 특화 데이터는 외부 공개 데이터와 달리 사내에서 직접 수집·정제·검증해야 하므로, 각 단계별로 실패가 누적되면 전체 모델의 신뢰도까지 영향을 미친다.

가장 흔한 실패 원인은 데이터 수집 단계에서부터 시작된다. 예를 들어, 사내 정책 문서, 업무 매뉴얼, 내부 Q&A 등 다양한 출처에서 데이터를 모으는 과정에서 담당 부서마다 포맷, 작성 스타일, 최신화 수준이 달라 일관성 없는 데이터가 쌓이기 쉽다. 이처럼 데이터의 대표성과 품질을 놓치면, 이후 정제·검증 단계에서 근본적인 문제를 해결하기 어렵다.

이런 난관을 극복하기 위해서는 초기 수집 시점부터 데이터 출처, 최신성, 작성자, 버전 등 메타 정보를 꼼꼼히 기록하고, 수집 기준을 명확히 문서화해야 한다. 또한 데이터 품질 점검 항목을 단계별로 체크리스트화하여, 각 단계에서 반드시 검증한 후 다음 단계로 넘어가는 절차가 필요하다.

데이터 수집 단계: 대표성 오류와 사내 데이터 편향

LLM 도입을 위해 사내 도메인 데이터를 수집할 때 가장 먼저 부딪히는 문제는 '대표성 오류'다. 예를 들어, 특정 사업부의 문서만 다수 포함되고, 타 부서의 실제 프로세스·용어가 누락되면, LLM은 실제 현장과 동떨어진 응답을 생성한다. 이는 단순히 데이터 양의 문제가 아니라, 데이터의 분포와 다양성, 그리고 최신성 문제에서 비롯된다.

대표성 오류를 피하려면, 우선 사내 데이터의 전체 지형을 파악해야 한다. 이를 위해 부서별, 업무별, 연도별 데이터를 매트릭스로 나누고, 각 셀의 데이터량과 업데이트 주기를 시각화해보는 것이 효과적이다. 가령, 아래와 같이 부서-연도 행렬을 그려보면 데이터 편향을 한눈에 파악할 수 있다.

import pandas as pd
import seaborn as sns
import matplotlib.pyplot as plt

# 예시: 부서별·연도별 데이터 건수
data = pd.DataFrame({
    '2021': [120, 80, 30],
    '2022': [200, 95, 40],
    '2023': [180, 110, 35]
}, index=['영업', '개발', '기획'])

sns.heatmap(data, annot=True, cmap="YlGnBu")
plt.title('부서별 연도별 데이터 분포')
plt.show()

이런 시각화를 통해 특정 부서나 연도의 데이터가 과도하게 많거나 적다는 사실을 파악하고, 추가 수집이 필요한 영역을 명확히 정의할 수 있다. 또한, 최신성과 관련해 '최근 1년 이내 문서' 비율이 지나치게 낮다면, LLM이 구식 정보를 학습할 위험이 있으므로 이를 보완하는 것이 중요하다.

데이터 정제 단계: 중복·노이즈·포맷 이슈와 구체적 진단

데이터 정제 단계에서는 중복, 오타, 불필요한 메타데이터, 포맷 불일치 등 품질 저하 요인이 빈번하게 드러난다. 특히 사내 문서의 경우 버전 관리가 미흡해 동일 내용이 여러 파일에 중복 저장되거나, 문서 내 불필요한 이력·서명·승인 정보가 섞여 있는 경우가 많다.

실제로 LLM 학습에 투입된 데이터 중, 사내 결재 문서의 '승인 이력'이 그대로 학습되어, 챗봇이 "이 문서는 3차 승인되었습니다" 등 불필요한 내용을 답변하는 사례가 있었다. 이런 오류를 방지하기 위해서는 텍스트 정제 전 단계에서 다음과 같은 절차가 필요하다.

1. 중복 검사: 해시값 혹은 주요 키워드 조합으로 문서 중복 여부를 자동 검출한다.
2. 불필요 정보 제거: 정규표현식 등으로 결재 라인, 작성일, 첨부파일 표기 등 불필요 메타 정보를 필터링한다.
3. 포맷 일관화: 마크다운, HTML, 워드 등 다양한 포맷을 통일된 평문 혹은 JSON 등 구조화된 형태로 변환한다.

이 같은 점검 절차를 통해, 실제로 불필요 흐름이 LLM에 유입되는 것을 사전에 차단할 수 있다. 또한, 정제 기준을 미리 문서화하고, 담당자가 바뀌더라도 동일한 기준으로 정제 작업이 반복되도록 프로세스를 정립하는 것이 중요하다.

데이터 검증 단계: 라벨 오류, 샘플링, 평가 기준의 미흡

데이터 검증 단계에서는 주로 라벨 오류와 검증 샘플의 대표성 부족, 평가 기준 미흡 등이 현장에서 실제로 막히는 지점이다. 예를 들어, 사내 QA 데이터셋의 라벨링을 외주 인력이나 비전문가가 진행할 때, 용어의 해석이 부서별로 달라 일관성이 떨어지거나, 일부 라벨이 잘못 부여되는 일이 잦다.

문제는 이렇게 라벨 오류가 누적될 경우, LLM이 잘못된 도메인 지식을 내재화할 수 있다는 점이다. 실제로 "인사부서에서 승인한 문서"라는 라벨이 잘못 붙어, LLM이 인사 관련 답변에 임의로 '승인'을 강조하는 식의 오작동이 발생한 사례가 있다.

이 지점을 가르는 핵심 점검 순서는 다음과 같다.

• 샘플링 검증: 전체 데이터셋의 일정 비율을 랜덤 샘플링하여 라벨 일관성, 포맷 오류, 의미 불일치 여부를 수작업으로 확인한다.
• 다중 검증: 라벨러 2인 이상이 동일 샘플을 교차 검증해, 일치율(agreement rate)이 일정 수준(예: 95% 이상) 이하일 경우 추가 검토한다.
• 도메인 전문가 리뷰: 최종 검증 단계에서 실제 업무 담당자가 직접 일부 샘플을 리뷰해, LLM이 학습할 데이터가 현업 맥락에 부합하는지 최종 확인한다.

이 과정에서 발견된 오류는 반드시 원본 데이터셋에 피드백해 정정하고, 오류 유형별로 재발 방지 가이드라인을 수립해야 한다.

현장 적용에서 성능 저하로 이어지는 데이터 품질 이슈

실제 LLM 도입 현장에서는, 데이터셋 품질 문제가 바로 모델의 응답 품질 저하·오작동으로 이어지는 사례가 빈번하다. 예를 들어, 사내 메일 데이터셋을 학습한 LLM이 "회의록 첨부드립니다"라는 비정형 답변을 반복하거나, 특정 부서 이슈만을 편향적으로 답하는 경우가 발생한다.

이런 현상은 데이터 수집 단계의 대표성 오류, 정제 단계의 노이즈 미제거, 검증 단계의 라벨 오류 등이 누적된 결과다. 특히, 실제 사내 QA 봇에서 "알 수 없는 답변" 빈도가 갑자기 늘거나, 사용자가 반복적으로 같은 질문에 다른 답변을 받는다면, 데이터셋 전체 품질을 다시 점검해야 한다는 신호다.

실무에서는 다음과 같은 순서로 원인을 진단한다.

1. 사용자 로그 분석: LLM 응답 로그에서 오답·불일치 케이스를 추출해 어떤 유형의 질문에서 문제가 반복되는지 파악한다.
2. 문제 케이스 역추적: 문제 응답이 어떤 데이터셋, 어떤 버전, 어떤 수집 시점에 포함된 데이터에서 비롯됐는지 역추적한다.
3. 원본 데이터 재검토: 해당 데이터가 실제로 최신이고, 의미상 오류가 없는지 도메인 전문가와 재검토한다.
4. 데이터셋 개선: 오류 유형별로 데이터셋 수집·정제·검증 프로세스에 개선안을 반영한다.

이처럼 현장 대응에서 가장 중요한 것은, 데이터 품질 이슈가 드러났을 때 즉시 원인을 단계별로 좁혀 들어가고, 각 단계별 오류 유형을 문서화해 재발을 방지하는 것이다.

도메인 데이터셋 구축과 검증을 위한 실무 체크리스트

• 데이터 수집 시, 부서·연도·업무별 대표성 매트릭스를 시각화하여 편향 여부를 사전에 파악한다.
• 데이터 정제 단계에서 중복, 불필요 정보, 포맷 불일치 항목별로 자동화 필터와 체크리스트를 운영한다.
• 라벨링 작업은 반드시 다중 검증 체계를 마련하고, 도메인 전문가의 샘플 리뷰를 포함한다.
• LLM 응답 품질 저하 시, 사용자 로그 기반으로 문제 유형을 역추적하고, 데이터셋 단계별로 근본 원인을 점검한다.
• 데이터셋 구축·정제·검증 기준을 문서화하고, 담당자 교체 시에도 일관된 품질을 유지할 수 있도록 표준 프로세스를 마련한다.