Split View: AI 모델 개발, 처음부터 끝까지 — 데이터에서 배포까지의 현실적인 생애주기

AI Model Development, Start to Finish — a Realistic Lifecycle from Data to Deployment

• Introduction — The Biggest Misconception About "Model Development"
• Stage 0 — Build the Eval First
• Data — Quality Beats Quantity
• Pretraining — The World of Scaling Laws
• The Fine-Tuning Spectrum — from SFT to DPO
• Evaluation — Don't Trust Benchmarks (Halfway)
• Serving — The Fight That Outlives Training
• After Deployment — The Data Flywheel
• How an Individual Starts
• Closing
• References

Introduction — The Biggest Misconception About "Model Development"

Say "developing an AI model" and most people picture pretraining: thousands of GPUs grinding for months. But in 2026, the overwhelming majority of real-world model development is not that. The true first step happens before a single line of code — climbing the decision ladder:

Rung 1. Does prompt engineering solve it?     → most projects end here
Rung 2. Does RAG (retrieval) solve it?        → if knowledge is the problem
Rung 3. Do you need fine-tuning?              → if format/tone/domain behavior is the problem
Rung 4. Do you need pretraining?              → if you are a frontier lab

Each rung up costs roughly ten times more and takes away that much flexibility. The first skill of a good model developer is not writing training code — it is the judgment not to climb higher than necessary. This article walks what actually happens at each stage, in order, once that judgment is made.

Stage 0 — Build the Eval First

The most-repeated mistake in model development: "train first, check by vibes later." Reverse the order. The eval set comes before the model.

• Success criteria as numbers: not "summarizes well" but "key-fact omission under 5%, hallucination under 1%."
• A golden dataset of ~100 items: representative cases pulled from real inputs, plus trap cases you want to fail loudly. It need not be perfect — it needs to be version-controlled and repeatable.
• The regression habit: change one prompt line, run the evals. Without this habit you live inside "it worked yesterday" mysteries.

I applied the same principle building the JLPT mock exam tool — the test verifying that answer positions were evenly distributed came before the question bank. Once the eval exists, everything else becomes an experiment.

Data — Quality Beats Quantity

Whichever rung you climb, data is eighty percent of the outcome, and every data lesson converges to one maxim: one good gigabyte beats a terabyte of garbage.

• Deduplication: a large share of web-crawled data is duplicated. Duplicates drive overfitting and memorization, and they are the main culprit behind benchmark contamination (below).
• Filtering and curation: language ID, quality classifiers, harmful-content removal. It is an open secret that frontier labs differ more in these pipelines than in architecture.
• Licensing and provenance: in 2026, legal review is not a luxury but a standard stage of the pipeline.
• Synthetic data's rise — and its trap: generating training data with a stronger model (distillation data, self-instruct) is now standard technique. But training generation after generation on model outputs alone clips the tails of the distribution — the reported risk of model collapse. Synthetic data is seasoning, not the staple.

At the fine-tuning stage, hundreds to thousands of high-quality demonstrations beat hundreds of thousands of noisy ones. Hand-craft just 100 examples yourself and you will never see your problem the same way again.

Pretraining — The World of Scaling Laws

Most teams never come here, but knowing this floor's physics improves judgment on every floor above it.

Scaling laws are that physics. DeepMind's Chinchilla work showed that for a given compute budget there is an optimal ratio of model size to data — roughly 20 tokens per parameter. Earlier-generation models were undertrained relative to their size; after this finding the industry recalibrated toward "smaller models, more data." Half the reason today's good small models beat yesterday's large ones lives here.

The distributed-training stack is the engineering that executes the physics:

• Data parallelism: replicate the model across GPUs, split the batch, synchronize gradients (all-reduce).
• Tensor/pipeline parallelism: when the model itself no longer fits on one GPU, split the layers (pipeline) or the matrices (tensor).
• Mixed precision (bf16) and gradient checkpointing: the standard memory-versus-speed trades.
• Failure is the default: across thousands of GPUs and weeks of training, hardware failure is a "when," not an "if." Your checkpoint strategy is your survival strategy.

If the infrastructure layer interests you, the NVIDIA GPU Operator and MIG guide covers GPU operations on Kubernetes, and the neural network lab lets you touch backpropagation at the bottom of it all.

The Fine-Tuning Spectrum — from SFT to DPO

Fine-tuning is not one technique but a spectrum. In working order:

SFT (supervised fine-tuning) — training on demonstrations of "for this input, answer like this." The most direct way to teach format compliance, tone, and domain vocabulary.

LoRA / QLoRA — instead of updating all weights, attach small low-rank adapter matrices beside each layer and train only those. Trainable parameters drop by orders of magnitude, which is what made fine-tuning a 7B-class model on a single consumer GPU possible — the single most important invention for individual developers. QLoRA adds 4-bit quantization to cut memory once more.

Alignment — teaching "preferred answers," beyond merely correct ones. RLHF as established by InstructGPT required a reward model plus PPO — a complex pipeline — but DPO (Direct Preference Optimization) replaced much of it with a simple loss that optimizes directly on preference pairs, dramatically lowering the barrier. The practical default in 2026 is "SFT → DPO (or a variant)."

When to use which: for knowledge injection, RAG comes before fine-tuning (fine-tuned knowledge is slow and costly to update). Where fine-tuning wins is format, style, and domain-specific behavior — always emitting JSON, following in-house code conventions, holding a persona.

Evaluation — Don't Trust Benchmarks (Halfway)

Benchmark contamination is this stage's biggest trap. When public benchmark items leak into training data, scores rise while ability stays flat. Looking at a shiny new model's numbers, "how do we know these items weren't in training?" is always a legitimate question.

The three-layer structure of practical evaluation:

1. Automatic metrics — accuracy/F1 for tasks with exact answers (classification, extraction). Cheap and fast; push as much as possible here.
2. LLM-as-judge — a strong model grades free-form outputs. It scales, but carries biases (favoring its own style, favoring longer answers), so its agreement with human grading must be validated periodically.
3. Human evaluation — the most expensive and most accurate final court. Even a small batch before important releases.

And the most important point: your own eval set for your own task tells you more about your product than any public benchmark. The golden set from Stage 0 keeps working here.

Serving — The Fight That Outlives Training

A model trains once; inference runs forever. Most of the total cost lives in serving.

• Quantization: shrinking weights from bf16 to INT8 or 4-bit halves-to-quarters memory — quality loss must be measured per task, but it is often smaller than you fear.
• Distillation: teach a small model with a large model's outputs, getting comparable task quality at a fraction of the cost. "Prototype on frontier, distill for production" has become the standard pattern.
• KV cache and continuous batching: transformer inference is bottlenecked by memory bandwidth more than compute. Understanding why vLLM-style engines (PagedAttention, continuous batching) multiply throughput is worth one focused afternoon.
• Latency budgets: design for p99, not p50, and use streaming to shrink perceived latency.

If your problem is packing multiple models densely onto one GPU, the MIG partitioning guide is exactly the infrastructure answer at this point.

After Deployment — The Data Flywheel

Deployment is not the end; it is the moment your best data collector comes online.

• Production evaluation: run the offline golden set alongside online sampled grading. The live distribution will drift from the development distribution.
• Failure mining: conversations where users re-ask, correct, or abandon are the finest raw material for the next fine-tune.
• The flywheel: deploy → collect failures → turn them into data → retrain → deploy. The rotation speed of this loop is the team's true skill level. Model development is not a project — it is an operating loop.

How an Individual Starts

A realistic path to experience the whole cycle personally:

1. Once from scratch: train a tiny transformer with a nanoGPT-style mini implementation. Scaling intuition comes from a few hundred lines of code.
2. One fine-tune: an open 7B-class model, LoRA, 500 examples you made yourself. The goal is to feel data quality driving the result.
3. One eval harness: a 100-item golden set for your own task plus an auto-grading script. This alone is a top-decile habit.
4. One serving run: quantize a model, host it locally, measure throughput and latency.

If the study method itself is the question, the 8 techniques in how to study with AI apply directly; if the career is the goal, the AI/LLM engineer section of the roles knowledge map is your next stop.

Closing

The lifecycle of AI model development compresses into one sentence: build the eval first, distrust your data, climb the ladder only as high as needed, and design the loop that runs after deployment. The training curve is the glamorous part — but the game is always decided before and after it: in data, evaluation, and operations.

References

• 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 docs · vLLM