[Scaling Laws] 심화 개념 정리

난이도: 중급

태그: LLM,Transformer,언어모델

이 문서는 AI 전문가가 뉴비에게 설명하듯 작성된 심화판입니다. 개념을 암기하는 것이 아니라, 실무 의사결정에 연결하는 것을 목표로 합니다.

당시 상황과 역사적 맥락

모델 크기 경쟁이 심화되던 시기였지만, 투자 대비 성능 상승을 체계적으로 예측하는 공식이 부족했습니다.

모델 구조/구성요소 역할 (초심자용)

• power-law 회귀: 규모 변수와 손실 관계 정량화
• frontier 해석: 같은 compute 예산에서 최적 조합 탐색
• 실험 설계 가이드: 감으로 하던 확대 전략을 수치화

역사적 의미와 후속 영향

• 대규모 학습 예산 계획의 표준 도구로 자리잡음
• Chinchilla식 compute-optimal 논의의 기반 제공
• 연구에서 "얼마나 키울지" 의사결정 품질 향상

아주 쉽게 한 줄 요약

모델/데이터/연산을 얼마나 늘려야 효율적인지 공식처럼 정리한 연구입니다.

진짜 핵심 3문장

• 이 방법은 기존 방식의 병목을 줄이기 위해 나왔습니다.
• 핵심 아이디어는 "더 잘 이해"하거나 "더 효율적으로 계산"하는 구조/학습법 변경입니다.
• 실무에서는 성능만 보지 말고 비용/지연/안전까지 같이 봐야 합니다.

처음 보는 사람용 핵심 용어 5개

• 학습(Training): 모델이 데이터를 보고 규칙을 익히는 과정
• 추론(Inference): 학습된 모델이 실제 질문에 답하는 과정
• 파라미터: 모델이 학습으로 얻게 되는 숫자(지식 저장소)
• 지표(Metric): 모델이 잘하는지 수치로 보는 기준
• 트레이드오프: 성능을 올리면 비용/속도가 나빠질 수 있는 관계

그림/자료로 다시 보기

그림 파일은 순차 추가 예정입니다. 우선 아래 도식 설명을 기준으로 읽으세요.

• 그림에서 먼저 볼 것: 모델/데이터/컴퓨트 증가에 따른 손실 곡선(power-law) 그래프를 중심으로 보세요.
• 자료 읽는 순서: (1) 한 줄 요약 -> (2) 구조/흐름 도식 -> (3) 핵심 수식 -> (4) 리스크/실무 적용
• 체크 질문: "이 블록이 없으면 성능/비용에 어떤 문제가 생길까?"를 스스로 답해보세요.

1단. 문제 정의

모델·데이터·컴퓨트를 어디에 얼마나 투자해야 최적인지 경험적 기준이 부족했다.

핵심 질문은 "왜 기존 방법으로는 충분하지 않았는가"입니다.

2단. 기존 한계

무작정 파라미터만 키우면 수익 체감과 비용 낭비가 발생한다.

면접에서는 한계를 구조/학습/운영 관점으로 나눠 말하면 설득력이 올라갑니다.

3단. 핵심 아이디어

loss와 규모 변수 간 power-law 관계를 경험적으로 모델링해 투자 방향을 정량화했다.

핵심은 변경점 자체보다, 그 변경점이 병목을 어떻게 줄였는지 설명하는 것입니다.

핵심 수식/알고리즘

• L(N,D,C)≈A N^-a + B D^-b + ...: 규모-손실 power-law 근사
• compute-optimal frontier: 같은 compute에서 최적 N,D 조합 추정

Scaling Law 한 줄 정의 (직관)

모델/데이터/연산을 키우면 성능이 좋아지는데, 그 개선이 랜덤이 아니라 power-law 형태로 예측 가능하다는 법칙입니다.

대표 형태: L(N)=A N^-alpha + B

즉 파라미터가 커질수록 loss가 줄고, log-log 그래프에서 거의 직선 패턴이 나타납니다.

세 가지 scaling 축

• Model size scaling: L(N) ∝ N^-alpha
• Dataset scaling: L(D) ∝ D^-beta
• Compute scaling: L(C) ∝ C^-gamma

핵심 메시지: N, D, C를 함께 봐야 하며, 어느 하나만 극단적으로 키우면 비효율이 생깁니다.

왜 Scaling Law는 power-law 형태로 나타나나?

핵심 결론: 현실 데이터의 long-tail 분포 + 모델의 점진적 근사 과정이 결합되면 오차 감소가 power-law로 나타나기 쉽습니다.

1) 데이터 자체가 long-tail (Zipf)

자연어/이미지/코드 데이터는 상위 빈도 패턴이 대부분 질량을 차지하고, 희귀 패턴이 긴 꼬리를 이루는 분포를 가집니다.

텍스트에선 Zipf 법칙으로 자주 표현합니다.

즉 고빈도 패턴은 빨리 학습되지만, tail 패턴은 매우 천천히 커버됩니다.

2) 모델은 분포를 단계적으로 근사한다

모델은 학습을 통해 p_theta(x)가 실제 분포 p_data(x)를 점점 잘 근사하도록 파라미터를 조정합니다.

초기에는 쉬운(고빈도) 구조를 먼저 맞추고, 이후 예산이 늘어날수록 희귀/복잡 패턴까지 근사합니다.

이때 남은 오차가 "한 번에 급락"하기보다 점진적으로 줄어들어 power-law 꼴이 나타납니다.

학습 관점으로 쓰면

생성모델 학습은 결국 p_theta(x) ≈ p_data(x)를 만들려는 과정입니다. 모델이 커질수록 더 많은 패턴/긴 문맥/복잡 구조를 표현할 수 있어 error가 점차 감소합니다.

왜 error 감소가 power-law가 되기 쉬운가

long-tail 데이터에서는 학습 순서가 대체로 head -> mid -> tail로 진행됩니다.

• 쉬운 패턴: 적은 용량으로 빠르게 학습
• 중간 패턴: 추가 용량 필요
• 희귀 패턴: 매우 많고 커버 비용이 큼

그래서 모델 확장에 따라 tail을 "조금씩 계속" 커버하게 되고, 결과적으로 error ~ N^-alpha 형태가 관측됩니다.

정보이론 관점

LLM 학습 loss는 보통 cross-entropy입니다.

모델 규모가 커지면 근사 품질은 좋아지지만, 자연 데이터의 본질적 불확실성 때문에 loss가 0으로 가지는 않습니다. 그래서 다음처럼 쓰는 경우가 많습니다.

여기서 L_inf는 irreducible entropy(데이터 자체의 예측 불가능성)입니다.

함수 근사 관점

신경망은 함수 근사기이며, 용량(capacity: 파라미터/폭/깊이)이 커질수록 근사 오차가 완만하게 감소합니다.

이 패턴은 종종 error ~ capacity^-k 형태로 근사되고, 스케일링 법칙의 경험식과 맞물립니다.

실무에서 보는 exponent 의미

LLM 스케일링 지수는 작은 값(문헌/설정에 따라 다르지만 대체로 0.0x대)인 경우가 많아, 성능을 조금 더 올리려면 자원 증분이 매우 크게 필요합니다.

즉 "개선은 꾸준하지만 비싸다"가 실무 해석입니다. 이것이 대규모 GPU/데이터 투자와 직결됩니다.

Scaling law는 언제 깨질 수 있나

• 데이터 고갈/품질 한계
• 연산 예산/시스템 한계
• 아키텍처 병목
• 최적화 안정성 한계

그럼에도 현재까지 언어/비전/생성 모델에서 스케일링 경향은 다양한 범위에서 반복 관측되고 있어, "scale + algorithm" 병행 전략이 유지되고 있습니다.

한 줄 결론

Scaling law는 단순 경험칙을 넘어, 데이터 분포 구조 + 정보량 한계 + 함수 근사 동역학이 합쳐져 나타나는 통계적 현상으로 보는 게 가장 정확합니다.

3) 그래서 log-log에서 직선이 보인다

L(N)=A N^-alpha + B 같은 형태는 log-log 축에서 거의 직선으로 보입니다. 실험자 입장에선 "규모를 키울 때 성능 개선률이 일정한 규칙을 따른다"는 의미입니다.

직관 정리

• 데이터: head는 쉽고 tail은 어렵다
• 모델 확장: head -> mid -> tail 순서로 점진 커버
• 결과: 오차 감소가 완만한 power-law 패턴

즉 power-law는 우연한 curve fitting이 아니라, 데이터 분포 구조와 함수근사 동역학이 함께 만든 현상으로 해석할 수 있습니다.

OpenAI Scaling Laws 핵심 해석

• 성능 개선은 power-law 경향을 보임
• 당시 관측 구간에서 뚜렷한 saturation 신호가 약했음
• 그래서 "크게 키우면 예측 가능하게 좋아진다"는 전략이 강화됨

이 관찰이 거대모델 시대의 투자 논리를 강하게 뒷받침했습니다.

Compute-optimal scaling: 균형이 핵심

GPU/예산이 제한된 상황에서는 모델만 키우거나 데이터만 늘리는 전략이 비효율적일 수 있습니다.

• 큰 모델 + 적은 데이터: 과소학습/비효율
• 작은 모델 + 과도한 데이터: 용량 한계
• 균형 잡힌 N:D:steps: 같은 compute에서 더 높은 성능

Chinchilla 수정점 (2022)

핵심 메시지: GPT-3 계열 설정은 상대적으로 "모델이 크고 데이터가 부족"했을 수 있으며, compute-optimal 관점에선 더 많은 토큰 학습이 유리하다는 결과였습니다.

실무 요약으로 자주 인용되는 비율은 대략 모델 1 파라미터당 약 20 토큰 수준입니다.

대표 비교(논문 맥락): GPT-3(175B/300B tokens) 대비 Chinchilla(70B/1.4T tokens)가 여러 벤치에서 우세.

왜 이 법칙이 연구 방향을 바꿨나

과거에는 새 아키텍처 아이디어 탐색 비중이 컸지만, 이후에는 "스케일이 가장 재현성 높은 성능 향상 수단"이라는 인식이 강해졌습니다.

그래서 주요 계열(GPT, Gemini, Claude, LLaMA 등)도 스케일링 전략을 중심축으로 가져갔습니다.

Scaling의 현실적 한계

• 비용 폭증: 대규모 학습 비용/인프라 요구 급증 (수치 추정치는 출처마다 편차 큼)
• 데이터 제약: 고품질 공개 텍스트의 한계 -> synthetic data, self-play, RL 활용 증가
• diminishing returns: 규모가 커질수록 단위 투자 대비 개선폭 감소

Post-scaling 흐름: inference scaling

최근에는 training scaling만이 아니라, 추론 시 계산량을 늘려 성능을 끌어올리는 접근이 강화되고 있습니다.

• Chain-of-Thought, tree search, reasoning-oriented decoding
• 핵심 아이디어: training scaling + test-time compute의 결합

직관 비유

AI 모델을 학생으로 보면:

• 모델 크기 = 뇌 크기
• 데이터 = 공부량
• compute = 공부 시간

결론은 "더 큰 뇌 + 더 많은 공부 + 더 긴 공부시간"이 성적을 올리지만, 결국 효율적인 공부 전략(알고리즘/추론법)도 함께 필요하다는 것입니다.

용어/기호 빠른 사전 (뉴비용)

• baseline: 비교 기준이 되는 가장 단순한 방법
• objective / loss: 모델이 최소화하려는 학습 목표 함수
• inference: 학습된 모델로 실제 입력에 대해 예측을 수행하는 단계
• latency: 요청 1건 처리 시간(지연), throughput: 단위 시간 처리량
• Q/K/V: Attention에서 Query/Key/Value 벡터
• d_k: Key 벡터 차원(스케일링에 사용)
• N, D, C: 보통 파라미터 수(N), 데이터 토큰량(D), 연산 예산(Compute, C)
• top-k: 점수가 높은 상위 k개 후보
• KL: 두 확률분포 차이를 나타내는 발산 지표(정렬/RL 문맥에서 자주 사용)
• trade-off: 한 지표를 올릴 때 다른 지표(비용/지연 등)를 일부 포기해야 하는 관계

읽는 방법: 수식에서 기호가 나오면 먼저 위 사전으로 의미를 확인하고, 그다음 "이 기호가 성능/비용 중 무엇을 바꾸는지"를 연결해서 이해하면 됩니다.

논문 간 비교 포인트

Chinchilla는 이 결과를 실전 학습 비율 권고로 구체화했다.

4단. 비용/리스크

데이터 품질/도메인 변화 시 법칙 외삽 실패 가능.

• 품질 리스크: 분포 이동 시 성능 저하 가능
• 운영 리스크: 지연/메모리/비용 급증 가능
• 거버넌스 리스크: 안전/편향/출처 검증 요구 증가

실패 사례 체크리스트

• 긴 입력/드문 도메인에서 급격한 품질 저하가 있는가
• 단일 지표는 좋아도 사용자 체감 오류가 늘어나는가
• 평균 성능 뒤에 tail failure가 숨겨져 있지 않은가

5단. 실무 적용

학습 예산 계획, 모델 크기 결정, 데이터 수집 우선순위 설정에 직접 사용한다.

• 도입 전: baseline 2개(품질/비용)로 사전 비교
• 도입 중: canary 배포 + rollback 조건 명시
• 도입 후: 품질/지연/비용/안전성 대시보드 동시 모니터링

예상 질문과 답변 (면접/실무 심화)

Q1. 이 논문의 핵심 기여를 한 문장으로 말해보세요.
A1. 핵심은 기존 병목을 특정하고, 그 병목을 직접 줄이는 학습/구조/시스템 변경을 제시했다는 점입니다. 면접에서는 숫자보다 병목-해결 매핑을 먼저 말하면 전달력이 높습니다.

Q2. 성능이 좋아도 실무에서 실패하는 대표 이유는?
A2. 비용과 안정성을 같이 보지 않기 때문입니다. 오프라인 정확도가 높아도 지연/메모리/운영 복잡도가 임계치를 넘으면 서비스 품질이 떨어집니다.

Q3. 이 논문을 도입할 때 baseline은 어떻게 잡나요?
A3. 가장 단순하고 강한 baseline 두 개를 동시에 잡아야 합니다. 하나는 품질 기준, 다른 하나는 비용 기준으로 두 축을 같이 비교해야 도입 판단이 가능합니다.

Q4. 이 접근의 실패 사례를 어떻게 감지하나요?
A4. 분포 이동, 길이 증가, 노이즈 입력, adversarial 질의에서 지표를 분리해 봐야 합니다. 특히 평균 성능이 아닌 tail failure를 별도로 추적해야 합니다.

Q5. 다음 단계 실험을 1개만 한다면?
A5. 단일 run이 아니라 multi-seed/다중 조건으로 변동성을 먼저 측정하겠습니다. 재현성 없는 개선은 실무에서 신뢰하기 어렵기 때문입니다.