- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 들어가며 — "모델 개발"의 가장 큰 오해
- 0단계 — 평가를 먼저 만들어라 (eval-first)
- 데이터 — 품질이 양을 이긴다
- 사전학습 — 스케일링 법칙의 세계
- 파인튜닝 스펙트럼 — SFT에서 DPO까지
- 평가 — 벤치마크를 믿지 마라 (반쯤은)
- 서빙 — 학습보다 오래가는 싸움
- 배포 후 — 데이터 플라이휠
- 개인이 시작하는 법
- 마치며
- 참고 자료
들어가며 — "모델 개발"의 가장 큰 오해
"AI 모델을 개발한다"고 하면 많은 사람이 GPU 수천 장 위에서 몇 달간 돌아가는 사전학습(pretraining)을 떠올립니다. 그러나 2026년 현재, 실무에서 일어나는 모델 개발의 절대다수는 그것이 아닙니다. 진짜 첫 단계는 코드를 한 줄도 쓰기 전에 오르는 결정 사다리입니다.
1단. 프롬프트 엔지니어링으로 되는가? → 대부분 여기서 끝난다
2단. RAG(검색 증강)로 되는가? → 지식이 문제라면 여기
3단. 파인튜닝이 필요한가? → 형식·톤·도메인 행동이 문제라면 여기
4단. 사전학습이 필요한가? → 당신이 프런티어 랩이라면
사다리를 한 단 오를 때마다 비용은 열 배씩 뛰고, 유연성은 그만큼 떨어집니다. 좋은 모델 개발자의 첫 번째 실력은 학습 코드를 잘 짜는 것이 아니라 불필요하게 사다리를 오르지 않는 판단력입니다. 이 글은 그 판단 이후, 각 단계에서 실제로 무슨 일이 벌어지는지를 순서대로 걷습니다.
0단계 — 평가를 먼저 만들어라 (eval-first)
모델 개발에서 가장 많이 반복되는 실수는 "일단 학습부터 돌리고 좋아졌는지 나중에 느낌으로 확인"하는 것입니다. 순서를 뒤집으세요. 모델보다 평가 셋이 먼저입니다.
- 성공 기준을 숫자로: "요약을 잘한다"가 아니라 "핵심 사실 누락률 5% 이하, 환각률 1% 이하"처럼.
- 골든 데이터셋 100문항: 실제 사용자 입력에서 뽑은 대표 사례 + 실패했으면 하는 함정 사례. 완벽할 필요 없이, 버전 관리되고 반복 실행 가능하면 됩니다.
- 회귀 평가 습관: 프롬프트 한 줄을 바꿔도 평가를 돌립니다. 이 습관이 없으면 "어제는 됐는데 오늘 안 되는" 미스터리에 갇힙니다.
이 원칙은 제가 JLPT 모의시험 도구를 만들 때도 그대로 적용됐습니다 — 문제 은행보다 "정답 위치가 고르게 분포하는가"를 검증하는 테스트가 먼저였습니다. 평가가 먼저 있으면 나머지 전부가 실험이 됩니다.
데이터 — 품질이 양을 이긴다
어떤 단계로 가든 데이터가 성패의 8할입니다. 그리고 데이터 작업의 격언은 하나로 수렴합니다: 쓰레기 1TB보다 좋은 데이터 1GB.
- 중복 제거(dedup): 웹 크롤 데이터의 상당량은 중복입니다. 중복은 과적합과 암기를 부르고, 벤치마크 오염(뒤에서 다룹니다)의 주범입니다.
- 필터링과 큐레이션: 언어 감지, 품질 분류기, 유해 콘텐츠 제거. 프런티어 랩들의 차별점은 아키텍처보다 이 파이프라인에 있다는 것이 업계의 공공연한 비밀입니다.
- 라이선스와 출처: 2026년의 모델 개발에서 법무 검토는 사치가 아니라 필수 공정입니다.
- 합성 데이터의 부상과 함정: 강한 모델로 학습 데이터를 생성하는 방식(distillation 데이터, self-instruct)은 이제 표준 기법입니다. 단, 모델 출력만으로 세대를 거듭 학습하면 분포의 꼬리가 잘려나가는 모델 붕괴(model collapse) 위험이 보고되어 있습니다 — 합성 데이터는 실데이터의 양념이지 주식이 아닙니다.
파인튜닝 단계라면 수백~수천 개의 고품질 시연 데이터가 수십만 개의 잡음 데이터보다 낫습니다. 데이터를 직접 100개만 손으로 만들어 보면, 자신의 문제를 보는 눈이 달라집니다.
사전학습 — 스케일링 법칙의 세계
대부분의 팀은 여기 올 일이 없지만, 이 층의 원리를 아는 것은 모든 층의 판단에 도움이 됩니다.
스케일링 법칙이 이 세계의 물리학입니다. DeepMind의 Chinchilla 연구가 보여준 핵심은 "주어진 컴퓨트에서 모델 크기와 데이터량의 최적 비율이 존재한다"는 것입니다 — 대략 파라미터 1개당 토큰 20개. 이전 세대 모델들은 데이터 대비 파라미터가 과했고("undertrained"), 이 발견 이후 업계는 "더 작은 모델을 더 많은 데이터로" 방향으로 재조정됐습니다. 오늘날 좋은 소형 모델이 몇 년 전 대형 모델을 이기는 이유의 절반이 여기 있습니다.
분산 학습 스택은 이 물리학을 실행하는 공학입니다.
- 데이터 병렬: 같은 모델을 여러 GPU에 복제, 배치를 나눠 처리하고 그래디언트를 동기화(all-reduce).
- 텐서/파이프라인 병렬: 모델 자체가 한 GPU에 안 들어갈 때 층을 쪼개거나(파이프라인) 행렬을 쪼갭니다(텐서).
- 혼합 정밀도(bf16)와 그래디언트 체크포인팅: 메모리와 속도의 표준 트레이드오프.
- 장애는 기본값: 수천 GPU × 수주의 학습에서 하드웨어 장애는 "만약"이 아니라 "언제"입니다. 체크포인트 전략이 곧 생존 전략입니다.
이 인프라 계층이 궁금하다면 NVIDIA GPU Operator와 MIG 가이드에서 쿠버네티스 위의 GPU 운영을, 신경망 실습소에서 역전파의 바닥 원리를 직접 만져볼 수 있습니다.
파인튜닝 스펙트럼 — SFT에서 DPO까지
파인튜닝은 하나의 기법이 아니라 스펙트럼입니다. 실무 순서대로:
SFT(지도 파인튜닝) — "이런 입력엔 이렇게 답해라"의 시연 데이터로 학습합니다. 형식 준수, 톤, 도메인 어휘를 가르치는 가장 직접적인 방법입니다.
LoRA / QLoRA — 전체 가중치를 갱신하는 대신, 각 층 옆에 작은 저랭크 행렬(어댑터)만 붙여 학습합니다. 학습 파라미터가 수백분의 일로 줄어 소비자용 GPU 한 장으로도 7B급 모델을 파인튜닝할 수 있게 만든, 개인 개발자에게 가장 중요한 발명입니다. QLoRA는 여기에 4비트 양자화를 더해 메모리를 한 번 더 줄입니다.
정렬(alignment) — "정확한 답"을 넘어 "선호되는 답"을 가르치는 단계입니다. InstructGPT가 확립한 RLHF(인간 피드백 강화학습)는 보상 모델 + PPO라는 복잡한 파이프라인이 필요했지만, **DPO(Direct Preference Optimization)**가 "선호 쌍 데이터로 직접 최적화"라는 단순한 손실 함수로 상당 부분을 대체하면서 정렬의 진입 장벽이 크게 낮아졌습니다. 2026년의 실무 기본값은 "SFT → DPO(또는 그 변형)"입니다.
언제 무엇을 쓰나: 지식 주입은 파인튜닝보다 RAG가 먼저입니다(파인튜닝은 지식 갱신이 느리고 비쌉니다). 파인튜닝이 이기는 곳은 형식·스타일·도메인 특화 행동입니다 — JSON만 뱉게 하기, 사내 코드 컨벤션 따르게 하기, 특정 말투 유지하기.
평가 — 벤치마크를 믿지 마라 (반쯤은)
벤치마크 오염이 이 단계의 최대 함정입니다. 공개 벤치마크 문제가 학습 데이터에 섞여 들어가면 점수는 오르지만 능력은 그대로입니다. 새 모델의 화려한 벤치마크 점수를 볼 때 "이 문제들이 학습에 없었다고 어떻게 보장하지?"는 언제나 정당한 질문입니다.
실무 평가의 3층 구조:
- 자동 지표 — 정확한 정답이 있는 과제(분류, 추출)의 정확도/F1. 싸고 빠르니 최대한 여기로.
- LLM-as-judge — 자유 서술 출력을 강한 모델이 채점. 스케일이 되지만 편향(자기 출력 선호, 장문 선호)이 있어, 사람 채점과의 일치율을 주기적으로 검증해야 합니다.
- 인간 평가 — 가장 비싸고 가장 정확한 최종심. 중요 릴리스 전 소량이라도.
그리고 가장 중요한 것: 자신의 과제로 만든 자신의 평가 셋이 어떤 공개 벤치마크보다 당신의 제품에 대해 많은 것을 말해줍니다. 0단계에서 만든 골든셋이 여기서 계속 일합니다.
서빙 — 학습보다 오래가는 싸움
모델은 한 번 학습되지만 추론은 영원히 돌아갑니다. 총비용의 대부분은 서빙에서 나옵니다.
- 양자화: 가중치를 bf16에서 INT8, 4비트로 줄이면 메모리가 절반~4분의 1로 — 품질 저하는 과제별로 측정해야 하지만 생각보다 작은 경우가 많습니다.
- 증류(distillation): 큰 모델의 출력으로 작은 모델을 가르쳐, 특정 과제에서 몇 분의 일 비용으로 비슷한 품질을 냅니다. "프런티어로 프로토타입 → 증류로 양산"이 표준 패턴이 됐습니다.
- KV 캐시와 연속 배칭: 트랜스포머 추론의 병목은 연산보다 메모리 대역폭입니다. vLLM류 서빙 엔진의 PagedAttention·continuous batching이 처리량을 몇 배로 끌어올린 이유를 한 번은 이해해 둘 가치가 있습니다.
- 지연 예산 설계: p50이 아니라 p99로 설계하고, 스트리밍으로 체감 지연을 줄입니다.
여러 모델을 GPU 하나에 밀도 있게 태우는 문제라면, 앞서 쓴 MIG 분할 가이드가 정확히 이 지점의 인프라 해법입니다.
배포 후 — 데이터 플라이휠
배포는 끝이 아니라 가장 좋은 데이터 수집기의 가동입니다.
- 프로덕션 평가: 오프라인 골든셋 + 온라인 샘플링 채점을 병행합니다. 실사용 분포는 반드시 개발 분포에서 드리프트합니다.
- 실패 사례 채굴: 사용자가 다시 묻거나, 수정하거나, 이탈한 대화가 다음 파인튜닝의 최고 원료입니다.
- 플라이휠: 배포 → 실패 수집 → 데이터화 → 재학습 → 배포. 이 루프의 회전 속도가 곧 팀의 실력입니다. 모델 개발은 프로젝트가 아니라 운영 루프입니다.
개인이 시작하는 법
이 전체를 개인이 체험하는 현실적인 경로:
- 바닥부터 한 번: Karpathy의 nanoGPT류 미니 구현으로 작은 트랜스포머를 직접 학습시켜 보세요. 스케일링의 직관은 코드 몇백 줄에서 옵니다.
- 파인튜닝 한 번: 공개 7B급 모델을 LoRA로, 자기가 만든 데이터 500개로. 데이터 품질이 결과를 좌우하는 것을 몸으로 느끼는 것이 목적입니다.
- 평가 하네스 한 번: 자기 과제 골든셋 100개 + 자동 채점 스크립트. 이것만으로 상위 10%의 습관입니다.
- 서빙 한 번: 양자화한 모델을 로컬에서 띄워 처리량과 지연을 측정해 보세요.
학습 방법론 자체가 고민이라면 AI로 공부하는 법의 8가지 기법이, 이 분야 커리어가 목표라면 직무별 지식 지도의 AI/LLM 엔지니어 절이 다음 단계입니다.
마치며
AI 모델 개발의 생애주기를 한 문장으로 압축하면 이렇습니다. 평가를 먼저 만들고, 데이터를 의심하고, 사다리는 필요한 만큼만 오르고, 배포 후의 루프를 설계하라. 화려한 것은 학습 곡선이지만, 승부가 나는 곳은 언제나 그 앞뒤 — 데이터와 평가와 운영입니다.
참고 자료
- Andrej Karpathy, "A Recipe for Training Neural Networks" · nanoGPT
- Hoffmann et al. (2022), "Training Compute-Optimal Large Language Models" (Chinchilla)
- Hu et al. (2021), "LoRA: Low-Rank Adaptation of Large Language Models"
- Ouyang et al. (2022), "Training language models to follow instructions" (InstructGPT/RLHF)
- Rafailov et al. (2023), "Direct Preference Optimization"
- Shumailov et al. (2023), "The Curse of Recursion" (model collapse)
- Hugging Face PEFT 문서 · vLLM