
메타 디스크립션: AI 입문 강의 day8 공부 기록. LLM으로 학습용 텍스트 데이터를 직접 생성하는 방법(Zero-shot, Few-shot, CoT), 로컬 LLM(Qwen3-0.6B) 활용법, 그리고 LLM as Judge로 품질을 자동 평가하는 파이프라인까지 정리했습니다.
키워드: 합성 데이터, 데이터 증강, LLM as Judge, Qwen, 프롬프트 엔지니어링, Few-shot, Chain of Thought
예상 읽기 시간: 11분
카테고리: AI 입문 / 데이터 엔지니어링
태그: SyntheticData, DataAugmentation, LLM, LLMasJudge, Qwen, PromptEngineering
AI 강의 day8 내용을 정리한 공부 기록입니다.
AI 모델을 학습시키려면 데이터가 필요합니다. 그런데 현실에서 "좋은 데이터"를 충분히 구하기란 쉽지 않습니다. 직접 수집하면 비용과 시간이 들고, 외부 데이터셋은 우리 도메인과 맞지 않을 때가 많습니다. day8에서는 이 문제를 LLM으로 데이터 자체를 만들어버리는 방법으로 접근합니다.
이번 강의의 핵심 흐름은 이렇습니다.
샘플 데이터 (소량)
→ [LLM] → 유사 데이터 대량 생성 (합성 데이터)
→ [LLM as Judge] → 품질 평가 및 필터링
→ 깨끗한 학습 데이터셋
데이터를 만들고, 만든 데이터를 다시 LLM으로 검수하는 자동화 파이프라인입니다.
먼저 용어 구분부터 하고 넘어가겠습니다.
| 용어 | 의미 | 예시 |
|---|---|---|
| 데이터 증강 | 기존 데이터를 변형해 양을 늘리는 것 | "KFC 좋아해" → "치킨 맛있어" (같은 의미, 다른 표현) |
| 합성 데이터 | 실제 수집 없이 AI가 새로 만들어낸 데이터 | 존재하지 않는 사람의 대화 로그 생성 |
이 강의에서는 두 방법을 모두 다루지만, 핵심은 LLM에게 특정 형식·의미를 지시해서 원하는 데이터를 뽑아내는 방법입니다.
가장 직관적인 방법은 ChatGPT 웹에서 직접 요청하는 겁니다.
"안녕, 나 철수야. KFC 좋아해"와 같은 의미의 문장을 15가지 다른 표현으로 써줘.
이렇게 하면 금방 비슷한 의미의 다양한 문장을 얻을 수 있습니다. 소량이라면 충분한 방법이지만, 문제는 대량 생성이 필요할 때입니다.
OpenAI API로 대량 생성하면 어떻게 될까요? GPT-4o mini 기준으로 입력 25만 토큰에 $1.5입니다. 데이터를 수만 건 생성하다 보면 순식간에 수십만 원, 심하면 수백만 원이 나올 수 있습니다. 학습 데이터를 만들다가 API 비용 폭탄을 맞을 수 있으니 주의해야 합니다.
실수 방지: API 키는 코드에 하드코딩하지 말고
.env파일로 관리하세요. 키가 GitHub에 노출되면 큰일 납니다.
비용 문제를 해결하는 현실적인 방법은 로컬 LLM을 쓰는 것입니다. 이번 강의에서는 Qwen3-0.6B 모델을 활용합니다.
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch
model_name = "Qwen/Qwen3-0.6B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)
transformers 라이브러리로 모델을 다운로드하면 약 1.5GB 파일이 로컬에 저장됩니다. 이후에는 인터넷 없이 무제한 추론이 가능합니다.
results = []
for i in range(100):
output = generate_text(prompt_template, sample_data)
results.append(output)
for 루프 한 줄로 원하는 만큼 생성할 수 있습니다. 로컬 LLM이라 API 비용 걱정 없이 돌릴 수 있습니다.
생성 결과의 다양성을 조절하는 두 파라미터를 이해하는 게 중요합니다.
Temperature
Top_p (Nucleus Sampling)
데이터 증강 목적이라면 temperature를 0.7~1.0, top_p는 0.8~0.9 정도가 실용적인 출발점입니다.
학습 데이터는 단순한 텍스트보다 정형화된 구조가 필요한 경우가 많습니다. LLM에게 JSON 형식으로 출력하도록 프롬프트를 설계하면 됩니다.
prompt = """
아래 형식의 JSON으로 사용자 프로필 데이터를 1개 생성해줘:
{"name": "이름", "age": 나이, "messages": ["대화1", "대화2"]}
예시 외의 내용은 절대 출력하지 마.
"""
출력 결과:
{"name": "민준", "age": 27, "messages": ["치킨 먹고 싶다", "오늘 야근이야"]}
여기서 핵심은 프롬프트 엔지니어링입니다. "예시 외의 내용은 절대 출력하지 마"처럼 포맷을 강하게 지시해야 파싱이 가능한 출력이 나옵니다. 모델이 JSON 앞뒤로 설명 텍스트를 붙이는 경우가 많으니, 정규식이나 json.loads로 후처리하는 코드도 함께 준비해두는 게 좋습니다.
LLM으로 데이터를 대량 생성했다고 다 끝난 게 아닙니다. 생성 결과의 품질이 들쭉날쭉합니다. 의미가 어긋나거나, 포맷이 깨지거나, 아예 엉뚱한 내용이 섞일 수 있습니다.
이걸 사람이 일일이 검수하면 자동화의 의미가 없습니다. 그래서 등장하는 개념이 LLM as Judge입니다. LLM에게 생성 결과를 평가하게 시키는 방법입니다.
judge_prompt = f"""
다음 문장이 원문과 같은 의미를 유지하면서 자연스럽게 표현되었는지 1~5점으로 평가해줘.
원문: {original}
생성 문장: {generated}
점수만 숫자로 답해줘:
"""
주의: 생성과 평가를 같은 모델로 하면 그 모델의 편향이 그대로 반영됩니다. 가능하면 생성 모델과 평가 모델을 다르게 쓰는 게 좋습니다.
데이터 생성 품질은 프롬프트 작성 방식에 크게 달라집니다. 세 가지 전략을 비교해봤습니다.
예시 없이 지시만 줍니다. 빠르지만 포맷이 제각각이 될 수 있습니다.
"KFC 좋아해"와 같은 의미의 문장을 5개 써줘.
예시 몇 개를 먼저 보여주고 패턴을 학습시킵니다. 품질이 눈에 띄게 좋아집니다.
원문: "KFC 좋아해" → 변환: "치킨 정말 맛있지"
원문: "배고파" → 변환: "밥 먹고 싶다"
원문: "피곤해" → 변환:
추론 과정을 단계별로 유도합니다. 복잡한 데이터 생성이나 평가 작업에서 정확도가 높아집니다.
문장을 변환하기 전에 먼저 원문의 핵심 의도를 분석하고,
그 의도를 유지하면서 다른 표현을 만드는 방식으로 진행해줘.
실제로 데이터 품질을 높이려면 Zero-shot으로 시작해서 결과가 마음에 들지 않으면 Few-shot으로, 그래도 부족하면 CoT를 도입하는 순서로 접근하는 게 좋습니다.
텍스트뿐 아니라 이미지 데이터도 AI로 생성할 수 있습니다. Stable Diffusion 같은 이미지 생성 모델을 사용하면 특정 조건을 만족하는 이미지를 대량으로 만들어 학습 데이터로 활용할 수 있습니다. 이번 강의에서는 개념 수준으로 언급되었고, 실습은 텍스트 중심으로 진행되었습니다.
| 개념 | 설명 | 실무 포인트 |
|---|---|---|
| 데이터 증강 | 기존 데이터 변형해 양 늘리기 | 의미 왜곡 없는지 확인 필수 |
| 합성 데이터 | AI가 새로 만든 데이터 | 편향 주의, 다양성 확보 |
| 로컬 LLM | 비용 없이 대량 생성 | Qwen3-0.6B 등 소형 모델 활용 |
| Temperature | 생성 다양성 조절 | 증강: 0.7~1.0 / 평가: 0 |
| Top_p | 단어 선택 범위 제한 | 0.8~0.9가 무난한 출발점 |
| LLM as Judge | LLM으로 품질 자동 채점 | 생성·평가 모델 분리 권장 |
| Few-shot | 예시 포함 프롬프트 | Zero-shot보다 품질 높음 |
| CoT | 추론 과정 단계 유도 | 복잡한 평가 작업에 유효 |
day8의 핵심은 "데이터가 없으면 만들면 된다" 는 관점의 전환입니다. 단순히 생성하는 것에서 끝나지 않고, LLM as Judge로 품질까지 자동 평가하는 파이프라인을 구성하면 실제 프로젝트에서도 충분히 활용할 수 있습니다.
데이터를 만드는 것도, 만든 데이터를 검수하는 것도 모두 LLM으로 처리한다는 게 처음에는 신기하게 느껴졌지만, 결국 좋은 프롬프트 설계가 결과를 결정한다는 점에서 프롬프트 엔지니어링의 중요성을 다시 한번 실감했습니다.
다음 Day 예고: Day 10 - LangChain + RAG
LLM에게 외부 문서를 검색해서 답변하게 하는 RAG(Retrieval-Augmented Generation) 파이프라인과, 이를 구현하는 LangChain 프레임워크를 다룰 예정입니다.