합성 데이터 생성 가이드: LLM 학습·평가·테스트에 쓰는 법

제공업체 문서와 출력물 이용 약관은 2026년 10월 22일에 확인했습니다. 아래의 고객 지원 티켓과 파일럿 규모는 설명을 위해 작성한 예시이며, 실제 모델 실험 결과를 보고한 것이 아닙니다.

합성 데이터 생성이란 무엇인가요?

합성 데이터 생성은 정해진 목적에 맞춰 인공적인 레코드나 예시를 만드는 작업입니다. 대규모 언어 모델, 즉 LLM을 활용하는 개발자에게는 대개 명세와 소수의 승인된 예시를 바탕으로 고객 문의, 질의응답 쌍, 정보 추출 예시, 대화 등의 텍스트를 생성하는 일을 뜻합니다.

운전 시뮬레이터를 떠올려 보면 이해하기 쉽습니다. 도로에서 똑같은 상황이 나타나기를 기다리지 않고도 까다로운 교차로 주행을 반복해서 연습할 수 있습니다. 그렇다고 시뮬레이터를 통과했다는 사실이 실제 교통 상황에서 그 교차로를 얼마나 자주 만나게 되는지 알려 주거나, 모든 도로 상황에 대처할 수 있음을 증명하지는 않습니다. 합성 데이터셋도 마찬가지로 연습으로 다룬 범위와 현실에 관한 근거를 구분해야 유용하게 쓸 수 있습니다.

생성 방식도 중요합니다. 규칙 기반 생성기는 주문 총액이 개별 품목 금액의 합과 같아야 한다는 식의 규칙을 따릅니다. 표형 데이터 합성기는 열 사이의 패턴을 학습합니다. LLM은 프롬프트와 제공된 맥락을 조건으로 언어를 생성합니다. 이들을 함께 사용할 수도 있습니다. 코드로 유효한 주문을 만들고, LLM으로 그 주문에 관한 고객의 불만을 작성하는 방식입니다.

합성 데이터는 레코드를 마스킹하는 것과도 다릅니다. 고객 이름만 바꾸면 나머지 사연은 그대로 남습니다. 데이터 증강은 질문을 다른 표현으로 바꾸는 것처럼 기존 예시를 변형하는 작업이며, 이렇게 파생된 예시는 여전히 원본과 연결되어 있습니다. 어느 쪽도 그 자체로 개인정보 보호를 보장하거나 독립적인 근거를 만들어 주지는 않습니다.

평가용 데이터: 정답을 별도로 검증한 과제 만들기

애플리케이션 개발자에게 합성 평가 데이터가 특히 유용한 영역은 이미 알고 있는 실패 유형입니다. 정보 누락, 서로 충돌하는 지시, 지원하지 않는 요청, 낯선 표현 등이 여기에 해당합니다. 평가는 시스템의 동작을 반복해서 확인하는 테스트입니다.

계정 문제의 내용이 모호할 때 고객 지원 어시스턴트가 추가 질문을 해야 한다면, 의도적으로 모호한 요청을 생성합니다. 기대하는 조치가 정책에 맞는지는 사람이 확인해야 합니다. 생성 모델의 답변이 확신에 차 있다는 이유만으로 그것을 정답으로 삼아서는 안 됩니다.

사용이 허용된 실제 서비스 요청이 있다면, 여기서 추출한 별도의 평가 세트를 유지합니다. 실제 요청을 사용할 수 없다면 업무를 잘 아는 사람에게 독립적으로 평가 사례를 작성하도록 맡깁니다. 이렇게 하면 명세를 점검할 수 있지만, 실제 운영 환경의 전체 사용자 요청에 대한 정확도를 입증할 수는 없습니다.

파인튜닝용 데이터: 특정 동작 가르치기

모델을 조정하는 개발자는 합성 예시를 통해 기존 데이터에 부족한 출력 형식, 분류 규칙, 응답 스타일을 보여 줄 수 있습니다. 파인튜닝은 예시를 학습시켜 모델을 업데이트하는 작업입니다.

먼저 관찰 가능한 실패에서 출발합니다. 예를 들어 모델이 모호한 티켓을 계속 결제 담당으로 보내는 경우입니다. 검토를 마친 모호성 사례를 추가하고, 손대지 않은 예시로 조정한 모델과 기존 기준 모델을 비교합니다. 학습 파일의 크기가 커졌다는 사실 자체는 성공 지표가 아닙니다.

과제와 통과 여부를 판단할 평가 세트가 안정적으로 정해졌다면 파인튜닝 워크플로를 활용합니다. 사실 정보에 관한 맥락이 누락되었거나 계속 바뀌는 것이 문제라면, 생성한 답변으로 사실을 학습시키기 전에 애플리케이션에 제공하는 맥락부터 바로잡아야 합니다.

소프트웨어 테스트 데이터 생성

소프트웨어 개발자가 만드는 합성 테스트 데이터는 애플리케이션의 규칙을 실제로 시험할 수 있어야 합니다. 필드 누락, 중복 제출, 이례적인 텍스트 길이, 유효하지 않은 상태 전이, 서로 연결된 데이터베이스 레코드 등을 다뤄야 합니다.

결제 테스트에는 주문, 고객, 결제 사이의 유효한 관계가 필요합니다. 산술 연산을 언어 모델에 맡길 필요는 없습니다. 이런 제약은 코드로 구현하고, 배송 주소와 모순되는 배송 요청 사항처럼 현실적인 언어가 가치를 더하는 부분에 LLM을 사용합니다.

데이터셋을 구매하는 실무자라면 이 가운데 어떤 용도로 쓸 수 있는지 확인해야 합니다. 데모에 적합한 데이터셋이 학습에도 유용하리라는 보장은 없으며, 학습 말뭉치가 곧바로 평가 세트가 되는 것도 아닙니다.

실습: 시드 예시에서 검토를 마친 후보 데이터까지

생성 모델에 물어보지 않고도 정답을 설명할 수 있는 좁은 과제로 시작합니다. 이 실습에서는 가상의 고객 지원 티켓을 billing, access, human_review로 분류하는 후보 예시를 만듭니다.

가상의 정책은 단순합니다. 결제와 청구서 문제는 결제 담당으로, 로그인과 비밀번호 문제는 접근 담당으로, 내용이 불분명하거나 두 문제가 함께 있는 요청은 사람이 검토하도록 보냅니다. 고객이 제공하지 않은 사실은 추론하지 않습니다.

합성 데이터 예시: 라벨이 명확한 시드 여섯 개

다음과 같이 직접 작성한 시드로 분류 경계를 보여 줍니다.

• “카드가 두 번 결제됐습니다.” → billing
• “청구서에 요금제가 잘못 표시돼 있습니다.” → billing
• “비밀번호 재설정 링크가 만료됐습니다.” → access
• “비밀번호를 재설정했는데 로그인이 안 됩니다.” → access
• “결제했는데 로그인이 안 됩니다.” → human_review
• “아직도 안 됩니다.” → human_review

마지막 예시들은 명확한 사례만큼 중요합니다. 불확실하다는 판단도 유효한 결과임을 생성 모델에 알려 주기 때문입니다. 일반적인 지시만으로는 모호하게 남을 수 있는 규칙을 예시가 어떻게 전달하는지는 퓨샷 프롬프팅 가이드에서 설명합니다.

정제를 마친 후보는 다음과 같은 형태가 될 수 있습니다. 실제 API 출력을 캡처한 것이 아니라 설명용 레코드입니다.

{
  "case_id": "billing-frustrated-indirect-a",
  "text": "Another invoice with the wrong plan, seriously?",
  "proposed_label": "billing",
  "policy_reason": "The customer identifies an invoice problem."
}

중요한 결과물은 추적 가능하고 검토를 마친 사례입니다. 처음 생성 모델이 요청한 후보 수를 모두 채웠는지는 부차적입니다. 목표 개수를 맞추겠다는 이유만으로 품질이 낮은 셀을 다시 채워서는 안 됩니다.

합성 데이터 생성 툴: 문서가 보장하는 범위

툴은 전체 과정에서 어떤 부분을 담당하는지에 따라 선택합니다. 모델 API는 코드가 모델의 출력을 요청하는 인터페이스이며, 배치 서비스는 그 요청들의 실행 일정을 관리합니다. 데이터셋 라이브러리는 생성과 피드백을 조직합니다. 표형 데이터 합성기는 구조화된 데이터의 관계를 학습합니다. 어떤 기능도 직접 정한 통과 기준을 대신하지는 않습니다.

생성형 AI로 합성 데이터 만들기: 배치 API

OpenAI API는 JSONL 파일로 제출한 요청을 비동기로 처리하는 Batch를 제공합니다. JSONL은 한 줄에 JSON 객체 하나를 넣는 형식입니다. 문서에서는 고유한 custom_id를 요구하며, 출력 순서가 입력 순서와 다를 수 있다고 안내합니다. 식별자로 결과를 연결한 다음 실패와 미완료 생성을 점검하고 후보를 파싱합니다. OpenAI Batch 문서.

Anthropic의 Claude API는 서로 독립적인 Messages 요청을 처리하는 Message Batches를 제공합니다. 결과에서는 성공, 오류, 취소, 만료된 요청을 구분하며, custom_id로 각 결과를 입력에 연결합니다. 운영에서 주의할 점은 배치가 접수되었다고 해서 모든 예시가 생성 완료되었다는 뜻은 아니라는 것입니다. 전체 데이터셋을 다시 생성하는 대신 식별자를 기준으로 누락된 작업만 재시도합니다. Claude 배치 문서.

Google의 Gemini API는 요청 객체를 인라인으로 전달하거나 JSONL 파일을 업로드하는 Batch를 제공합니다. 파일 기반 요청에는 해당 결과를 식별하는 key가 포함됩니다. 규모가 큰 오프라인 데이터셋에는 파일 방식을 사용합니다. 문서에 나온 처리 시간은 목표치이므로, 대화형 워크플로가 즉각적인 완료에 의존하지 않도록 합니다. Gemini Batch 문서.

다음은 연결된 문서에서 확인한, 작업 분할에 영향을 주는 배치 한도입니다. 여러 작업에 걸쳐 만들 수 있는 전체 데이터셋의 한도는 아닙니다.

배치 요청과 후보 예시는 서로 다른 집계 단위입니다. 성공한 요청 하나가 후보 여러 개를 반환한다면 두 개수를 모두 추적합니다. 통신 오류와 함께 파싱 실패, 응답 거부, 잘린 출력도 기록합니다. HTTP 응답이 성공했다는 사실만으로 학습에 쓸 수 있는 데이터 행이 되는 것은 아닙니다.

Distilabel: 생성과 피드백 과정을 구성합니다

Distilabel은 생성, 평가, 데이터 처리 단계를 파이프라인으로 구성하는 합성 데이터 및 AI 피드백 프레임워크입니다. 문서에서는 분류, 추출, 대화, 지시문 생성 등의 사용 사례를 설명합니다. 일회성 스크립트가 여러 생성·필터링 단계로 커졌을 때 유용합니다. Distilabel 문서.

이 프로젝트는 Apache-2.0 라이선스를 사용합니다. 저장소에는 원래 개발자들이 프로젝트를 떠났으며 커뮤니티 협력자들이 유지보수를 맡고 있다고도 명시되어 있습니다. 도입할 버전을 고정하고 검증해야 합니다. 실무에서 남는 한계는 평가자입니다. 모델의 판단 과정을 체계적으로 실행한다고 해서 그 판단이 독립적이거나 옳아지는 것은 아닙니다. Distilabel 저장소.

Faker: 언어 모델 없이 테스트 데이터를 만듭니다

Faker는 프로바이더를 통해 가짜 데이터를 생성하는 Python 패키지로, 로케일과 난수 시드 설정을 지원합니다. 자연어 추론보다 통제된 필드 값이 필요할 때 애플리케이션 테스트용 픽스처를 만드는 데 유용합니다. 저장소에 명시된 라이선스는 MIT입니다. Faker 문서, Faker 저장소.

비즈니스상 관계는 여전히 직접 코드로 구현해야 합니다. 주소, 날짜, 거래를 각각 따로 생성한다고 해서 현실적인 고객 이력이 만들어지지는 않습니다. 가능하면 테스트 전용으로 예약된 식별자와 도메인을 사용하고, 생성한 픽스처가 메시지 발송이나 다른 운영 환경의 동작을 일으키지 않도록 막습니다.

Synthetic Data Vault: 테이블과 테이블 간 관계를 모델링합니다

Synthetic Data Vault, 줄여서 SDV는 표형 데이터 합성과 통계적 평가 기능을 제공합니다. 문서에는 단일 테이블, 순차 데이터, 서로 연결된 테이블을 다루는 방법이 안내되어 있습니다. 학습된 합성기는 사용자가 제공한 데이터에서 패턴을 배웁니다. 따라서 사용이 허용된 원본 데이터셋은 여전히 필요합니다. SDV 문서.

SDV의 GaussianCopulaSynthesizer는 고전적인 통계 기법으로 열의 분포와 관계를 학습합니다. CTGANSynthesizer는 생성자와 이에 맞서는 판별자를 함께 학습시키는 모델인 생성적 적대 신경망을 사용합니다. 둘 다 데이터와 그 구조를 설명하는 메타데이터를 입력받습니다. 이들은 표형 데이터 합성기이며, 범용 채팅 모델이 아닙니다. Gaussian Copula 문서, CTGAN 문서.

한계는 과제에 필요한 특성을 얼마나 충실히 보존하느냐에 있습니다. 열의 분포가 비슷해 보인다고 해서 드문 조합, 테이블 간 규칙, 후속 모델의 동작까지 보존되었다고 볼 수는 없습니다. 자식 레코드를 부모 레코드에 연결하는 외래 키를 비롯해, 애플리케이션이 의존하는 관계를 검증해야 합니다.

부족한 근거를 기준으로 합성 데이터 생성기를 고릅니다

언어 표현의 다양성이 부족하다면 모델 API를 사용합니다. 생성과 피드백을 반복 가능하게 구성하는 이점이 의존성 추가의 부담보다 크다면 Distilabel을 도입합니다. 픽스처에 통제된 값이 필요하다면 Faker를 선택합니다. 테이블 전반의 통계적 관계가 중요하고 모델링에 사용할 권한이 있는 원본 데이터가 있다면 SDV를 검토합니다.

라벨링 정책이 불명확한 문제를 더 큰 생성기로 해결하려 해서는 안 됩니다. 그것은 여기 소개한 모든 툴을 쓰기 전에 풀어야 할 문제입니다.

생성한 출력물로 학습해도 될까요? 제공업체 약관의 기준

다른 모델의 학습에 쓸 예시를 만드는 모델, 즉 교사 모델을 선택하기 전에 출력물 이용 제한부터 확인합니다. 다음 내용은 앞서 소개한 호스팅형 LLM 제공업체 세 곳의 표준 약관을 요약한 것입니다. 특정 학습 프로젝트가 허용 요건을 충족한다는 판정은 아닙니다.

• OpenAI: Services Agreement는 출력물을 경쟁 AI 모델 개발에 사용하는 것을 제한합니다. 다만 주로 데이터를 범주화·분류·정리하며 제삼자에게 배포하거나 상업적으로 제공하지 않는 모델, 그리고 OpenAI가 지정한 서비스를 통한 모델 맞춤화에 대해서는 명시된 예외가 있습니다. 서비스 계약.
• Anthropic: Commercial Terms는 Anthropic의 명시적 승인이 없는 한, 경쟁 AI 모델 학습을 포함해 경쟁 제품이나 서비스를 만들기 위해 서비스에 접근하는 것을 금지합니다. 상업용 이용 약관.
• Google: Gemini API의 Additional Terms는 서비스를 경쟁 모델 개발에 사용하는 것을 금지합니다. Google Search Grounding 조항에서는 Grounded Results 또는 Search Suggestions를 이용한 학습도 별도로 금지합니다. Gemini API 약관.

라이브러리의 소프트웨어 라이선스, 라이브러리가 호출하는 모델의 약관, 모델 가중치의 라이선스, 원본 예시에 대한 권리는 각각 따로 확인할 문제입니다. 출력물의 소유권만으로 이 모든 문제가 해결되지는 않습니다.

개인정보를 보호하는 테스트 데이터는 별도 검증이 필요합니다

합성해서 만들었다는 사실이 개인정보 보호를 보장하지는 않습니다. 기밀 레코드를 승인되지 않은 생성 서비스에 복사했다면, 나중에 가상 데이터처럼 보이는 대체물을 생성해도 이미 일어난 공개를 되돌릴 수 없습니다.

Stadler, Oprisanu, Troncoso의 합성 데이터 공개에 관한 연구에서는 평가한 모델에 따라 개인정보 보호 효과와 유용성이 달라졌습니다. 실무적으로는 “합성”이라는 말을 익명성의 보증으로 받아들이지 말고, 공개할 데이터와 생성 과정 자체를 평가해야 한다는 뜻입니다. USENIX 연구 논문.

소프트웨어 테스트에 충분하다면 승인된 스키마와 정책을 바탕으로 직접 작성한 가상의 시드를 우선 사용합니다. 실제 통계적 패턴을 보존해야 한다면 승인된 환경에서 원본을 다루고, 생성한 데이터셋을 통해 어떤 정보가 드러날 수 있는지 평가합니다.

직접 식별자, 복사된 구절, 드문 조합, 다른 사람이 이미 알고 있을 법한 정보와의 연결 가능성을 확인합니다. 이름을 바꿔도 특징적인 사건, 장소, 날짜를 그대로 유지하면 당사자를 알아볼 수 있습니다. 민감한 데이터를 공개할 때는 몇 차례의 수동 표본 점검과 중복 검사만으로 충분하지 않습니다. 위협과 예정된 수신자에 맞춰 개인정보 보호를 평가해야 합니다.

제공업체가 사용자 데이터를 학습에 쓰는지에 관한 정책과, 사용자가 출력물로 학습할 권리가 있는지는 별개의 문제입니다. 예를 들어 Gemini의 무료 서비스 약관은 민감한 정보를 제출하지 말라고 안내합니다. 반면 유료 서비스의 데이터 이용 약관은 프롬프트와 응답을 Google 제품 개선에 사용하지 않는다고 명시합니다. 약관은 EEA, 스위스, 영국에서의 무료 이용에도 유료 서비스의 데이터 이용 규칙을 적용합니다. Gemini 데이터 이용 약관.

제공업체의 학습 미사용 약속도, 로컬 실행도 결과 데이터셋을 안전하게 공유할 수 있다는 증거는 아닙니다. 공개 검토가 끝날 때까지 데이터셋의 출처 기록과 접근 통제를 유지합니다.

합성 데이터에 대한 기대는 어디서 과장될까요?

가장 큰 과장은 생성한 행을 늘리면 근거 부족도 해결된다는 주장입니다. 합성 데이터는 연습 범위를 넓히고 실패를 드러낼 수 있지만, 같은 가정을 대규모로 반복할 수도 있습니다.

표현이 달라도 같은 상황만 반복할 수 있습니다

서로 다른 문장으로 구성된 데이터셋도 실제로는 아주 적은 종류의 상황을 되풀이할 수 있습니다. 필터링을 마친 뒤 어떤 시나리오가 남았는지 추적합니다. 어떤 비즈니스 규칙, 모호성, 실패 유형이 여전히 포함되어 있는지 확인해야 합니다.

티켓 예시에서 결제와 접근 문제가 함께 있는 요청이 빠졌다면, 청구서 불만을 아무리 반복해서 넣어도 그 빈자리를 채울 수 없습니다. 유사도가 높은 이웃 사례를 검토하고, 통과한 예시뿐 아니라 탈락한 예시도 살펴봅니다. 지나치게 엄격한 품질 필터가 애써 추가하려던 어려운 사례를 눈에 띄지 않게 제거할 수 있습니다.

다시 써도 편향은 남을 수 있습니다

편향된 시드를 다른 표현으로 바꿨다고 그 가정까지 사라진다고 생각해서는 안 됩니다. 언어 스타일, 방언, 맞춤법 수준, 관련 사용자 집단별로 라벨 선택을 검토합니다. 정책상 근거가 없다면 불만 섞인 요청이나 맞춤법이 틀린 요청을 다르게 분류해서는 안 됩니다.

판정과 무관한 속성만 바꾼 대응 사례를 검토자가 비교하도록 합니다. 라벨이 달라진다면 시드, 프롬프트, 필터를 함께 조사합니다. 생성 모델과 평가 모델이 같은 오류를 서로 강화할 수 있습니다.

자기 답안을 채점하는 모델도 그럴듯한 점수를 냅니다

Zheng과 동료들은 LLM 평가자에서 위치 편향, 장황함에 대한 편향, 자기 답변을 선호하는 편향을 보고했습니다. 모델은 측정하려던 특성 대신 표현이나 제시 방식에 점수를 줄 수 있습니다. LLM-as-a-judge 연구.

정답을 기계적으로 검증할 수 있는 곳에는 결정적 검사를 사용합니다. 주관적인 판단이 필요한 경우에는 사람의 판정에 맞춰 평가자를 보정하고, 가능하면 생성 모델의 정체를 가린 뒤 의견이 갈리는 사례를 검토합니다. 평가 모델을 다른 제공업체의 것으로 바꾸면 공통 의존성 하나는 줄일 수 있지만, 오류까지 서로 독립적이 된다는 보장은 없습니다.

점수를 신뢰하기 전에 평가자를 점검하는 방법은 LLM-as-a-judge 가이드에서 설명합니다. 합성 데이터 생성에서는 어떤 예시를 학습용 정답으로 삼을지 평가자가 결정하기 전에 이 점검을 마쳐야 합니다.

모델 붕괴는 특정 위험이지, 모든 합성 데이터에 대한 결론은 아닙니다

Shumailov와 동료들은 생성한 데이터로 재귀적으로 학습하는 과정을 연구하고, 원래 분포에서 드물게 나타나는 부분이 어떻게 사라질 수 있는지 보여 주었습니다. 이는 원본 근거를 모델에서 파생된 데이터로 반복해서 대체할 때 주의해야 한다는 근거입니다. 검토를 거친 과제별 합성 데이터로 파인튜닝하면 반드시 실패한다는 뜻은 아닙니다. Nature 연구 논문.

사용이 허용된 원본 근거를 유지하고, 드문 사례를 의도적으로 보존하며, 손대지 않은 기준 모델과 후속 동작을 비교합니다. 이런 평가를 대신할 수 있는 보편적인 합성 데이터 대 실제 데이터 혼합 비율은 없습니다.

다음 업무에서는 무엇을 바꾸면 좋을까요?

지금 시작해도 되는 경우는 빠진 사례를 구체적으로 지목하고, 그 사례의 올바른 동작을 적을 수 있으며, 안정된 규칙으로 생성 후보를 검토할 수 있을 때입니다. 작은 커버리지 격자부터 시작한 뒤 유용한 사례가 추가되는 셀만 확장합니다.

파인튜닝을 미뤄야 하는 경우는 검토자들이 목표 라벨에 합의하지 못하거나 독립적인 평가 세트가 없을 때입니다. 정책과 평가 문제부터 해결합니다.

일반적인 픽스처를 쓰면 되는 경우는 데이터베이스 채우기, 경계값 확인, 트랜잭션 무결성 검증이 목적일 때입니다. 단순한 데이터로 시험할 수 없는 동작에만 생성한 언어를 추가합니다.

다음 배포 전에는 손대지 않은 동일한 사례로 기준 시스템과 변경한 시스템을 비교합니다. 고객 지원 문의 분류기라면 유형별로 잘못된 분류와 사람이 처리하도록 넘기지 못한 사례를 살펴봅니다. 의도한 동작이 개선되고 다른 영역에서 허용할 수 없는 성능 저하가 생기지 않을 때만 합성 데이터를 유지합니다.

합성 데이터에 관한 자주 묻는 질문

AI 시스템을 만들고 평가하는 실용적인 가이드를 뉴스레터로 받아보세요.