좋은 정답 데이터를 만드는 라벨링 설계

AI Daily Special · Part 4 · 20/36

좋은 정답 데이터를 만드는 라벨링 설계

2026년 9월 23일 · 전체 36회 중 20회 · 예상 읽기 10분 · Asia/Seoul

라벨의 목적과 경계를 정의하고 판단 불가 상태와 예외 처리까지 포함한 라벨 정의서 골격을 작성할 수 있다.

좋은 정답 데이터(Ground Truth)는 현실의 유일한 정답을 그대로 옮긴 표가 아니다. 정해진 AI 사용 목적에 맞춰 관찰 단위, 라벨 의미, 필요한 증거와 판단 시점을 합의한 참조 데이터다. 따라서 라벨링의 첫 단계는 사람에게 값을 찍게 하는 일이 아니라 어떤 결정을 데이터로 표현할지 설계하는 일이다. 라벨 정의가 흔들리면 모델은 사람의 불일치뿐 아니라 조직의 모호한 정책까지 학습한다. [S1][S2][S3]

이번 회차의 흐름

1. 라벨은 이름이 아니라 운영 가능한 판단 규칙이다
2. 온톨로지는 포함과 제외의 경계를 고정한다
3. 판단 불가를 오류와 같은 통에 넣지 않는다
4. 좋은 지침은 예시보다 반례와 결정 절차가 강하다
5. 다온커머스의 반품 이미지 라벨 정의서 골격

라벨은 이름이 아니라 운영 가능한 판단 규칙이다

라벨(Label)은 모델이 예측하도록 정한 목표 값이다. Google은 원하는 결과와 같은 직접 라벨이 가장 단순하지만 실제로는 구매 이력처럼 목표를 가까이 추정하는 대리 라벨(Proxy Label)을 쓰기도 한다고 설명한다. 대리 라벨은 언제나 근사치이므로 목표와의 연결 조건과 실패 사례를 문서화해야 한다. [S2] 예를 들어 다온커머스가 반품 사유를 예측하려는데 상담 종료 코드만 쓰면, 고객의 실제 문제보다 상담사의 입력 습관을 학습할 수 있다.

정의서에는 먼저 사용 목적과 오류 비용을 적는다. 같은 반품 사진도 자동 환불을 승인할 때와 검수 우선순위를 정할 때 필요한 라벨이 다르다. 전자는 거짓 승인 비용이 커서 보수적인 증거가 필요하고, 후자는 놓치지 않는 것이 더 중요할 수 있다. 라벨은 현실 전체가 아니라 특정 시점의 특정 의사결정을 위해 선택한 관찰이므로 적용 범위와 금지 용도를 함께 써야 한다. NIST AI RMF도 과업, 지식 한계, 테스트 자료와 평가 조건을 문서화하도록 제시한다. [S4]

판단 기준

라벨 이름보다 먼저 이 값으로 어떤 결정을 내리고 어떤 오류를 감수할지 합의한다.

온톨로지는 포함과 제외의 경계를 고정한다

라벨 온톨로지(Label Ontology)는 라벨의 종류와 관계를 정의한 체계다. 관찰 단위가 주문인지 상품인지 이미지인지, 한 사례에 라벨 하나만 붙는지 여러 개가 가능한지, 상위와 하위 범주가 어떻게 연결되는지를 정한다. 각 라벨에는 정의, 포함 조건, 제외 조건, 필요한 증거, 반례, 우선순위와 다른 라벨과의 관계가 필요하다. 범주가 겹치면 우선순위 규칙이나 다중 라벨 허용 여부를 명시해야 한다.

NIST의 2026년 RUFEERS 지침은 단계별 온톨로지를 라벨링 전에 동결하고, 정의된 유형과 요건을 만족하는 사례만 태깅한다. 정의 밖 사건을 억지로 일반 유형에 넣지 않고 기록해 다음 단계의 온톨로지 후보로 넘긴다. [S1] 이는 모든 프로젝트가 같은 온톨로지를 써야 한다는 뜻이 아니라, 진행 중인 작업의 규칙을 조용히 바꾸지 말라는 실무 교훈이다. 변경이 필요하면 ontology_version을 올리고 영향받는 기존 라벨의 재검토 범위를 정한다.

판단 기준

한 회차의 라벨링 동안 온톨로지를 동결하고 예외는 숨기지 말고 다음 버전 후보로 기록한다.

판단 불가를 오류와 같은 통에 넣지 않는다

현실의 경계 사례를 반드시 기존 범주 하나로 밀어 넣으면 데이터는 깔끔해 보이지만 불확실성이 사라진다. 판단 불가(Abstain)는 증거가 부족하거나 기준상 안전하게 결정할 수 없음을 명시적으로 남기는 상태다. 이를 데이터 없음, 범위 밖, 적용 불가, 복수 가능, 추가 검토 필요와 구분하면 모델 학습과 운영 정책을 다르게 설계할 수 있다. NIST RUFEERS는 불확실한 원인 후보를 Hedged 속성으로 보존하는 예를 제시한다. [S1] Plank는 사람 간 차이를 모두 노이즈로 간주하면 주관성이나 복수의 타당한 답에서 오는 실제 변이를 잃을 수 있다고 지적한다. [S9]

판단 불가는 실패를 감추는 만능 라벨이 아니다. 라벨러가 근거를 찾지 못했는지, 이미지가 흐린지, 정의가 겹치는지, 사례가 프로젝트 범위를 벗어났는지를 reason_code로 남겨야 한다. 반복되는 코드가 많으면 개인의 실수보다 정의서나 수집 설계의 결함일 수 있다. 반대로 명백한 사례까지 보류가 늘면 교육이나 도구 UX를 점검한다. 합의율과 일치도 계산은 다음 21회차에서 다루되, 이번 회차에서는 불일치가 생겼을 때 무엇을 기록할지부터 설계한다.

판단 기준

불확실성을 강제로 지우지 말고 판단 불가의 이유를 구조화해 다음 개선의 입력으로 남긴다.

좋은 지침은 예시보다 반례와 결정 절차가 강하다

라벨 정의서에는 대표 예시뿐 아니라 비슷하지만 제외되는 반례와 경계 사례가 필요하다. 라벨러는 먼저 관찰 가능한 증거를 찾고, 포함 조건을 확인한 뒤, 제외 조건과 우선순위를 적용하고, 남은 불확실성은 보류 사유로 기록한다. Google은 사람이 합리적으로 모호한 신호를 다르게 분류할 수 있다고 설명하며 명확한 정의와 수집 조건 확인을 강조한다. [S3] 사람 라벨은 유연하지만 오류가 가능하므로 수동 점검과 다른 평가자와의 비교가 필요하다. [S2]

대규모 작업 전에 작은 파일럿으로 정의서를 시험한다. 파일럿의 목표는 높은 숫자를 만드는 것이 아니라 서로 다른 해석이 생기는 문장, 이미지, 시간 경계와 누락된 라벨을 찾는 것이다. 질문과 판정, 정의서 변경 이유를 decision_log에 남기고 라벨에는 annotator_role, guideline_version, ontology_version, evidence_ref, labeled_at, reason_code를 연결한다. Datasheets와 Data Cards 연구도 수집 및 주석 방법, 의도된 사용, 데이터와 모델 성능에 영향을 주는 결정을 문서화하도록 제안한다. [S7][S8]

판단 기준

정의서 파일 자체보다 파일럿 질문과 변경 이유와 영향을 함께 버전으로 남기는 것이 중요하다.

다온커머스의 반품 이미지 라벨 정의서 골격

가상 조직 다온커머스는 반품 이미지를 보고 검수 우선순위를 정하는 보조 모델을 준비한다. 수치와 사례는 교육용 가정이다. 관찰 단위는 반품 건당 대표 이미지 묶음이며, 목표는 환불 자동 승인이 아니라 추가 검수 순서를 정하는 것이다. 1차 라벨은 정상, 외관 파손, 구성품 누락, 오배송 의심, 판단 불가, 범위 밖으로 둔다. 한 건에 여러 문제가 보이면 다중 라벨을 허용하되 우선 검수 사유 하나를 별도 필드로 기록한다.

외관 파손은 제품 본체의 균열, 깨짐, 기능에 영향을 줄 가능성이 있는 변형이 사진에서 확인될 때 포함한다. 포장 상자의 찌그러짐만 보이면 제외하고 포장 손상 보조 라벨을 쓴다. 사진이 흐려 본체 상태를 볼 수 없으면 외관 파손이 아니라 판단 불가와 image_quality_blur를 기록한다. 주문 상품과 다른 물건처럼 보이지만 SKU 근거가 없으면 오배송으로 확정하지 않고 additional_evidence_required를 남긴다.

판단 기준

정답 데이터는 확신을 연출하는 표가 아니라 증거와 보류와 변경 이력을 함께 보존한 판단 기록이다.

라벨 정의서 최소 골격

1. 목적과 단위 업무 결정, 오류 비용, 관찰 단위, 기준 시점, 금지 용도
2. 라벨 체계 라벨 ID, 정의, 상하위 관계, 단일·다중 선택, 우선순위
3. 판정 증거 필수 증거, 포함 조건, 제외 조건, 반례, 최소 맥락
4. 예외 상태 판단 불가, 범위 밖, 적용 불가, 추가 검토, reason_code
5. 버전과 추적 ontology_version, guideline_version, evidence_ref, labeled_at
6. 변경 통제 질문 로그, 승인자, 영향 범위, 재라벨 조건, 시행일

마무리와 다음 회차

라벨링 설계는 정답을 많이 생산하는 작업이 아니라 목적에 맞는 판단 규칙을 만들고 그 한계를 기록하는 작업이다. 관찰 단위와 온톨로지, 포함 및 제외 조건, 반례, 판단 불가 이유, 증거와 버전을 먼저 정하면 사람의 판단을 재현 가능한 데이터로 바꿀 수 있다. 다음 21회차에서는 이 정의서를 실제 사람에게 적용할 때 필요한 라벨러 교육, 일치도 측정, 판정 조정과 골드 데이터셋의 역할과 한계를 살펴본다.

다음 21회차 라벨러 교육·일치도·골드 데이터셋 2026년 9월 25일

출처 및 읽을거리

확인일 2026-09-23 KST · 법률·공식 문서·표준 공개 개요·원 연구와 실무 권고를 구분했으며 다온커머스 사례는 교육용 가정이다.

• [S1] NIST - RUFEERS Annotation Guidelines NIST AI 100-8
  확인일 2026-09-23 · 특정 정보추출 평가용 지침의 실무 사례이며 모든 라벨링 과제에 동일한 온톨로지나 태깅 규칙을 요구하는 표준은 아님
• [S2] Google for Developers - Datasets Labels
  확인일 2026-09-23 · 교육용 공식 문서이며 제시된 점검 예시와 규모를 모든 프로젝트의 의무 기준으로 해석하지 않음
• [S3] Google for Developers - Data quality and interpretation
  확인일 2026-09-23 · 일반 ML 데이터 품질 가이드이며 도메인별 판정 기준과 법적 의무는 별도로 검토해야 함
• [S4] NIST AI Resource Center - AI RMF Core
  확인일 2026-09-23 · 자발적 위험관리 프레임워크이며 특정 라벨 체계나 단일 구현 방법을 강제하지 않음
• [S5] EUR-Lex - Regulation EU 2024 1689 Article 10 Data and data governance
  확인일 2026-09-23 · 고위험 AI에 관한 EU 법률 조항이며 구체적 적용 여부와 시행 의무는 관할과 사용 사례에 대한 법률 검토가 필요함
• [S6] ISO - ISO IEC 5259 2 2024 Data quality measures
  확인일 2026-09-23 · 유료 표준 전문이 아닌 공식 공개 개요만 확인했으며 세부 규범 요구는 인용하지 않음
• [S7] Communications of the ACM - Datasheets for Datasets
  확인일 2026-09-23 · 투명성 문서화 프레임워크 제안이며 자체적으로 라벨 정확성이나 규제 준수를 보장하지 않음
• [S8] Google Research - Data Cards Purposeful and Transparent Dataset Documentation for Responsible AI
  확인일 2026-09-23 · 연구와 산업 실무를 위한 문서화 접근이며 조직별 책임과 검토 절차를 별도로 설계해야 함
• [S9] Association for Computational Linguistics - The Problem of Human Label Variation On Ground Truth in Data Modeling and Evaluation
  확인일 2026-09-23 · 주로 NLP의 사람 라벨 변이를 다룬 포지션 논문이며 모든 불일치를 유용한 신호로 간주하라는 뜻은 아님
• [S10] NeurIPS Datasets and Benchmarks - Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks
  확인일 2026-09-23 · 선정된 공개 벤치마크 연구 결과이며 보고된 오류율을 다른 조직 데이터에 그대로 적용할 수 없음

2026-09-23-ai-ready-data-ep20-labeling-design.pdf

1.6 MB