제8부 운영·LLMOps

8.1 데이터 플라이휠 · 피드백 루프 · 지속 개선

제품이 살아 움직이기 시작하면 매일 수천, 수백만 개의 대화가 교환된다. 사용자가 묻고, 답을 받고, 이어 묻고, 문장을 고치고, 다시 생성을 누르고, 어느 순간 떠난다. 이 트래픽을 두고 두 개의 이야기가 통용된다. 하나는 투자설명회의 이야기다 — "사용이 데이터를 낳고, 데이터가 모델을 키우고, 나아진 모델이 더 많은 사용을 부른다. 우리에겐 남이 못 따라올 데이터 해자가 있다." 다른 하나는 운영팀 회고의 이야기다 — "로그는 테라바이트로 쌓이는데 제품 품질은 반년째 제자리다." 이상한 것은 이 두 이야기가 둘 다 사실이라는 점이다. 같은 트래픽, 같은 로그가 어떤 팀에서는 복리로 작동하는 플라이휠이 되고 어떤 팀에서는 열지 않는 아카이브의 무덤이 된다. 이 장은 무엇이 그 둘을 가르는지를 다룬다.

가르는 것은 데이터의 양이 아니다. 데이터를 개선으로 바꾸는 규율 있는 루프가 있느냐다. 그 루프를 우리는 데이터 플라이휠(data flywheel)이라 부르고, 그것을 실행하는 일상의 규율을 지속 개선(continuous improvement)이라 부른다. 이 장은 그 바퀴를 해부하고, 피드백 신호가 실제로 무엇을 뜻하는지(그리고 무엇을 뜻하지 않는지) 통계로 따지고, 로그를 학습 데이터로 바꾸는 큐레이션의 실무를 직접 밟은 뒤, 마지막으로 잘못 실행한 바퀴가 어떻게 제품을 거꾸로 망가뜨리는지까지 본다. 관측(7.6)이 여기서 개선으로 넘어오고, 개선안의 배포·검증은 다음 장(8.2)이 이어받는다.

8.1.1 플라이휠의 해부 — 다섯 단계와 축

플라이휠은 원래 엔진에서 회전 에너지를 저장하는 무거운 바퀴다. 처음엔 밀기 힘들지만, 관성이 붙으면 스스로 실행되고, 밀 때마다 조금씩 빨라진다. 이 비유가 제품에 붙는 지점은 정확하다. 초기엔 사용자도 데이터도 없어 개선이 더디지만, 어느 임계를 넘으면 사용이 데이터를 낳고 그 데이터가 제품을 높이는 자기강화 순환이 생긴다. 비유가 배신하는 지점도 정확히 알아야 한다. 관성은 저절로 생기지만 회전은 저절로 생기지 않는다. 엔진의 플라이휠에는 크랭크축이 붙어 계속 토크를 넣어 주고, 제품의 플라이휠에는 그 자리에 사람과 판단과 돈이 들어간다. 축이 멈추면 관성은 마찰로 조금씩 약화되고 플라이휠도 결국 선다.

LLM 제품에서 이 순환은 다섯 마디로 나뉜다.

사용에서는 사용자가 제품을 쓰며 모든 상호작용을 흘린다. 신호·데이터에서는 그 상호작용이 로그·트레이스·피드백으로 기록된다 — 이 단계는 관측성(7.6)이 이미 세워 놓은 배관이다. 큐레이션·라벨링에서는 원시 로그에서 무엇이 중요한지 골라내고 정답·선호를 붙인다. 개선에서는 큐레이션된 데이터를 프롬프트·검색·모델·평가셋의 어느 경로로 흘려보낸다. 더 나은 제품에서는 그 개선이 배포되어 사용자를 붙잡고, 다시 첫 마디로 돌아간다.

이 다섯 마디의 비대칭성이 이 장 전체의 논지다. ①·②·⑤는 인프라만 깔면 대체로 자동으로 흐른다 — 사용자는 알아서 쓰고, 로그는 알아서 쌓이고, 좋아진 제품은 알아서 사용자를 끈다. 그러나 ③은 다르다. 원시 로그에는 "이게 좋은 답인가"라는 신호가 붙어 있지 않으므로, 사람이 골라내고 판단하고 라벨해야 비로소 학습의 연료가 된다. 이 노동은 자동화로 줄일 수는 있어도 없앨 수는 없다(8.1.9에서 자동·인간 라벨의 분업을 본다). 다섯 마디 중 넷은 관성으로 흐르고 하나는 매주 수작업으로 진행해야 한다 — 그리고 그 하나가 멈추면 나머지 넷이 아무리 잘 동작해도 플라이휠 전체가 선다. 이 사실을 정면으로 다루는 것이 다음 절이다.

8.1.2 "데이터가 쌓이면 저절로 좋아진다"의 세 가지 거짓

가장 널리 퍼졌고 가장 값비싼 통념은 이것이다 — 사용자만 많으면 데이터가 쌓이고, 데이터가 쌓이면 모델이 저절로 좋아진다. 투자 언어로는 "데이터 해자"다. 이 믿음은 부분적으로만 참이고 실무에서는 대개 거짓처럼 작동한다. 세 가지 이유가 겹친다.

첫째, 원시 로그는 학습 데이터가 아니다. 로그가 담은 것은 "입력과, 지금 모델이 낸 출력"의 쌍이다. 그런데 지금 모델의 출력을 정답으로 삼아 다시 학습하면 무슨 일이 벌어지는지 보자. 모델이 어떤 유형에서 80%만 맞고 20%를 틀린다고 하면, 그 로그 전체를 지도 신호로 쓰는 순간 20%의 틀린 답이 "따라야 할 목표"로 각인된다. 자기 실수를 자기가 강화하는 것이다. 게다가 자기 출력을 반복 학습하면 분포의 꼬리 — 드물지만 중요한 케이스 — 가 라운드마다 조금씩 깎여, 다양성이 좁아지고 평균으로 수렴한다(합성데이터의 모델 붕괴와 같은 결, 3.9). 로그를 연료로 쓰려면 "지금 답보다 더 나은 답이 무엇인가"라는 신호가 반드시 별도로 붙어야 하고, 그 신호를 만드는 것이 큐레이션·라벨링이다. 그것은 무비용이 아니다.

둘째, 데이터 중력과 데이터 가치는 다르다. 로그는 중력처럼 저절로 쌓인다 — 저장 버튼만 눌러 두면 된다. 그러나 가치는 저절로 생기지 않는다. 100만 개의 "잘 처리된 평범한 대화"는 개선에 거의 기여하지 않는다. 모델이 이미 잘하는 것을 다시 보여 줘 봤자 배울 것이 없기 때문이다. 반대로 1,000개의 "제대로 라벨된 하드 케이스"는 다음 버전을 눈에 띄게 높인다. 연료는 양이 아니라 선별된 어려움이다(이것을 채굴하는 법이 8.1.8이다). 스토리지 청구서가 커지는 것과 데이터셋의 가치가 커지는 것은 상관이 거의 없다.

셋째, 개선의 병목은 데이터가 아니라 사람과 판단이다. 라벨된 데이터가 손에 있어도, 그것을 어느 경로로 보낼지 진단하고(8.1.10), 파인튜닝을 수행하고, 회귀를 검증하고, 안전하게 배포하는 파이프라인과 인력이 없으면 바퀴는 그 자리에 선다. 현장에서 가장 흔한 상태가 바로 "데이터는 넘치는데 개선이 안 되는" 교착이다. 데이터 플라이휠은 자동 기계가 아니라 계속 수작업으로 계속 밀어야 회전하는 무거운 바퀴이고, 데이터가 쌓이는 것은 관성의 일부일 뿐, 그것을 회전으로 바꾸는 힘은 큐레이션·라벨링·파인튜닝 운영에 대한 지속 투자다. "데이터가 있으니 언젠가 좋아지겠지"는 대개 실현되지 않는다.

그리고 더 무서운 진실이 있다. 잘못 실행한 플라이휠은 멈추는 것이 아니라 거꾸로 가속한다. 편향된 피드백으로 학습하면 편향이 복리로 강화되고, 잘못된 지표를 최적화하면 그 지표만 좋아지고 실질은 나빠진다(8.1.13에서 이 제품판 보상 해킹을 다룬다). 좋은 플라이휠과 나쁜 플라이휠은 같은 기계의 두 회전 방향이다 — 어느 쪽으로 도느냐는 축에 무엇을 넣느냐가 정한다.

8.1.3 피드백의 두 갈래 — 명시적·암묵적 신호

플라이휠의 연료는 피드백 신호이고, 신호는 두 갈래에서 온다. 명시적 신호는 사용자가 "평가할 의도로" 남긴 것 — 좋아요·싫어요, 별점, 응답 수정, 신고다. 암묵적 신호는 사용자가 그저 제품을 쓰면서 흘린 행동 부산물 — 재생성, 편집, 복사, 후속 질문, 체류, 이탈, 제안 수용이다. 이 둘의 성격이 정반대다. 명시적 신호는 깨끗하지만 드물고, 암묵적 신호는 풍부하지만 잡음이 많다. 어느 하나만으로 개선을 지속하려는 것이 초보 팀의 전형적 실수다.

여기서 7.6이 이 장으로 넘겨준 부담을 분명히 하자. 관측성 장은 이 신호들을 로깅·트레이싱하는 방법을 세웠지만, 로깅된 신호는 그 자체로 잡음투성이다. 재생성 이벤트 하나가 불만인지 호기심인지, 이탈 하나가 실패인지 만족인지 로그는 말해 주지 않는다. 이 장의 일은 그 잡음 위에서 결론을 내리는 것이고, 그러려면 두 갈래를 역할로 나눠 써야 한다 — 명시적 신호는 정확한 앵커로, 암묵적 신호는 대량의 스크리닝으로. 이 분업은 4.2에서 인간 평가(정확·비쌈)와 자동 평가(값쌈·대량)를 나눈 것과 정확히 같은 구조다.

문제 세그먼트는 밀도 높은 암묵적 신호로 넓게 찾고, 그 안의 소수를 사람이 라벨해 정밀 확인한다. 왜 이 순서여야 하는지, 명시적 신호만으로는 왜 세그먼트를 못 가르는지는 숫자로 따져야 분명해진다 — 다음 절이 그것이다.

8.1.4 신호는 얼마나 믿을 수 있나 — 밀도·잡음·표본크기

"이 세그먼트의 좋아요율이 60%에서 52%로 떨어졌다"는 관측 앞에서 대부분의 팀이 곧장 원인 분석에 들어간다. 그 전에 물어야 할 것이 있다 — 이 8%p 하락이 실재하는가, 표본 잡음인가. 피드백 신호는 베르누이 시행의 표본이고, 표본 비율의 불확실성은 정확한 산식으로 나온다. 비율 $\hat p$ 의 표준오차는

$$\text{SE}(\hat p) = \sqrt{\frac{p(1-p)}{n}}$$

이고, 95% 신뢰구간은 대략 $\pm 1.96\,\text{SE}$ 다. 핵심은 $n$ — 신호가 실제로 몇 개 모였는가 — 이고, 여기서 명시적·암묵적의 밀도 차이가 승부를 가른다.

명시적 신호부터 보자. 좋아요 응답률(응답 중 좋아요/싫어요 버튼이 억제된 비율)을 $\rho = 0.03$, 좋아요를 누른 사람 중 긍정 비율을 $p = 0.6$ 이라 하자. 어떤 세그먼트가 주당 $M$ 개의 응답을 낸다면, 실제로 손에 쥐는 좋아요 표본은 $n = \rho M$ 개뿐이다.

• 큰 세그먼트, $M = 10{,}000$: 좋아요 표본 $n = 300$. $\text{SE} = \sqrt{0.6\times0.4/300} = \sqrt{0.0008} \approx 0.028$, 즉 2.8%p. 두 주를 비교하면 차이의 표준오차가 $\sqrt{2}\times 2.8 \approx 4.0$%p, 95% 구간 $\pm 7.8$%p다. 8%p 하락은 겨우 이 경계에 걸친다 — 의심스럽지만 단정 불가.
• 작은 세그먼트, $M = 1{,}000$: 좋아요 표본 $n = 30$. $\text{SE} = \sqrt{0.24/30} = \sqrt{0.008} \approx 0.089$, 즉 8.9%p. 95% 구간이 $\pm 17.5$%p에 이른다. 60%에서 52%로의 8%p 하락은 잡음 속에 완전히 묻힌다. 이 세그먼트에서 좋아요율의 주간 변동은 아무것도 말해 주지 않는다.

명시적 신호로 이 작은 세그먼트를 신뢰성 있게 보려면 표본이 얼마나 필요할까. $\text{SE}$ 를 2%p로 좁히려면 $n = p(1-p)/\text{SE}^2 = 0.24/0.0004 = 600$ 개의 좋아요가 필요하고, 응답률 3%에서 이는 $600/0.03 = 20{,}000$ 개의 응답이다. 주당 1,000 응답 규모의 세그먼트에서는 20주를 모아야 한다. 문제가 발생하고 20주 뒤에 확인하는 신호는 운영에 쓸모가 없다.

이제 같은 작은 세그먼트($M = 1{,}000$)에서 암묵적 신호인 재생성률을 보자. 재생성은 응답마다 관측되므로 표본이 곧 $n = M = 1{,}000$ 이다. 기준 재생성률 $p = 0.15$ 라면 $\text{SE} = \sqrt{0.15\times0.85/1000} = \sqrt{0.0001275} \approx 0.011$, 즉 1.1%p이고 95% 구간은 $\pm 2.2$%p다. 재생성률이 14%에서 29%로 급증하면 그것은 약 13 표준오차 — 잡음일 가능성이 사실상 0인, 오해할 수 없는 신호다.

같은 세그먼트, 같은 트래픽에서 명시적 신호($\pm 17.5$%p)는 무용지물인데 암묵적 신호($\pm 2.2$%p)는 선명하다. 이유는 순전히 밀도다. 재생성은 응답의 15%에서 나오고 좋아요는 3%에서만 나오니, 같은 트래픽이 재생성 표본을 다섯 배 준다. 여기서 8.1.3의 분업이 왜 그 방향이어야 하는지가 확정된다 — 세그먼트를 가르고 문제를 찾는 일은 밀도 높은 암묵적 신호가 하고, 명시적 신호는 전체 수준의 앵커로만 쓴다. 좋아요율은 제품 전체의 만족을 대략 재는 데는 좋지만, 세그먼트를 분할할수록 표본이 말라 붙어 아무 결론도 못 준다. 세그먼트 진단을 명시적 신호로 하려 들면, 신호가 쌓일 무렵에는 이미 문제가 몇 달째 방치된 뒤다.

8.1.5 상관·인과·교란 — 신호를 오독하는 법

표본이 충분해 신호가 "실재"임을 확인했다 해도, 그 신호가 무엇을 뜻하는지는 여전히 별개의 문제다. 피드백 신호를 다룰 때 가장 흔한 죄악은 약한 대리지표를 곧이곧대로 인과로 읽는 것이다. 신호는 거의 언제나 약한 상관일 뿐이고, 정반대로 해석해도 말이 되는 경우가 많다.

재생성이 불만이라는 보장은 없다. 사용자는 다른 버전도 보고 싶어서, 혹은 맹목적으로 눌러 봐서 재생성한다. 첫 답이 완벽했는데도 습관적으로 누르는 사람도 있다. 이탈이 실패라는 보장도 없다 — 조기 이탈은 포기일 수도, 답을 얻어 만족하고 떠난 것일 수도 있다. 이 부호 모호성 때문에 이탈은 단독으로는 거의 쓸모가 없고, 반드시 다른 신호(직전에 복사했나? 세션이 짧았나?)와 결합해야 한다. 긴 체류도 마찬가지다 — 검색 UX가 20년 전에 배운 교훈이지만, 긴 체류는 흥미로워서일 수도 원하는 것을 못 찾아 헤매서일 수도 있다. 좋아요조차 품질의 신호가 아닐 수 있다. 사용자는 자기 생각에 동조하는 답, 자신감 있고 장황한 답에 좋아요를 누르는 경향이 있어서(사람 쪽의 아첨·장황 편향, 3.3·4.2과 같은 결), 좋아요를 무비판적으로 최적화하면 모델이 아첨꾼이 된다(8.1.13).

여기에 교란 변수(confounder) 가 겹치면 오독은 한층 깊어진다. "재생성률이 높은 세그먼트 = 나쁜 모델"이 아니라, 그 세그먼트에 원래 어려운 질문(코드 디버깅, 다국어)이 몰려 있을 수 있다. 난이도라는 교란을 통제하지 않으면 "모델이 나쁘다"와 "질문이 어렵다"를 가를 수 없다. 이 교란이 얼마나 지독하게 결론을 뒤집는지는 숫자로 봐야 실감이 난다. 신규 모델 B를 구버전 A와 재생성률로 비교한다고 하자. B는 파워유저 코호트에 먼저 배포돼 어려운 질문을 훨씬 많이 받았다.

합산만 보면 B의 재생성률(25.1%)이 A(12%)의 두 배가 넘는다 — B는 치명적 문제이니 롤백하자는 결론이 나온다. 그런데 난이도로 층화하면 그림이 뒤집힌다. 쉬운 질문에서 B는 8%로 A의 10%보다 낫고, 어려운 질문에서도 B는 27%로 A의 30%보다 낫다. B는 두 층 모두에서 A보다 우수한데, 합산에서는 열등해 보인다. 이유는 순전히 트래픽 구성이다 — B의 응답은 90%가 어려운 질문(재생성률이 본래 높은 영역)이라, 각 층에서 이겨도 가중평균이 위로 끌려 올라간다. 이것이 심슨의 역설이고, 교란을 통제하지 않은 채 합산 지표로 모델을 롤백하면 더 나은 모델을 버리게 된다.

교훈은 단순하다. 한 신호로, 그것도 합산 지표로 결론 내리지 마라. 신호는 삼각측량해야 한다 — 재생성률↑ 그리고 좋아요율↓ 그리고 후속 재질문↑가 같은 세그먼트, 같은 난이도 층에서 겹칠 때 비로소 "여기 문제가 있다"고 말할 수 있다. 단일 신호는 가설을 제기하는 데 쓰고, 결론은 여러 신호의 합치와 소량의 사람 확인, 그리고 교란을 통제한 층화로만 낸다.

8.1.6 삼각측량에서 개입으로 — 관측은 가설, 인과는 실험

삼각측량과 층화로 아무리 정교하게 관측 신호를 읽어도, 그것으로 얻는 것은 여전히 상관이다. "한국어 디버깅 세그먼트에서 재생성이 튀었고 좋아요가 떨어졌다"는 관측은 강한 가설이지만, "우리 모델이 한국어 오류 메시지를 잘못 다뤄서"라는 원인을 확정하지는 못한다. 그사이 라이브러리 생태계가 바뀌었을 수도, 그 코호트의 질문 난이도가 올라갔을 수도 있다. 관측 데이터만으로 인과를 확정하는 것은 원리적으로 불가능하다 — 통제하지 않은 교란은 언제나 남는다.

인과를 판정하려면 개입(intervention) 이 필요하다. 프롬프트나 검색이나 모델을 바꿔 놓고, 신호가 실제로 움직이는지 보는 것. 이것이 A/B 실험이고 다음 장(8.2)의 주제다. 이 장과 다음 장의 분업은 그래서 명확하다. 이 장의 관측 신호는 "어디를 실험할지"의 후보를 좁히고 우선순위를 매기는 일을 하고, 8.2의 실험이 그 가설을 인과로 판정한다. 관측은 값싸고 넓지만 인과를 못 주고, 실험은 인과를 주지만 비용이 크고 좁다 — 그래서 관측으로 수천 개의 가설 중 소수를 골라 실험 대상으로 삼는다. 이 순서를 뒤집어 아무 실험이나 마구 실행하면 실험 자원이 순식간에 고갈되고, 관측 없이 감으로만 고치면 잘못된 곳을 조사한다.

이 대목에서 흔한 오해 하나를 명시해 두자. 대시보드의 지표가 좋아졌다고 개선을 인과로 확정하지 마라. 지표는 계절성, 트래픽 구성 변화, 동시에 나간 다른 변경에 함께 변동한다. "지표가 올랐으니 우리 변경이 효과 있었다"는 통제 없는 전후 비교이고, 통제 없는 전후 비교는 자기기만의 가장 흔한 형태다. 큐레이션이 만든 개선안이 실제 효과가 있는지는 오직 통제된 실험만이 답한다. 이 장의 나머지는 그 실험 대상이 될 후보 — 큐레이션된 하드 케이스 — 를 어떻게 만드는지의 실무다.

8.1.7 로그를 학습 데이터로 — 무엇을 남기나

축(큐레이션)의 실무는 원시 로그를 선별·라벨된 데이터셋으로 바꾸는 일이고, 그 전제는 로그에 재구성 가능한 맥락이 남아 있는 것이다. 7.6의 트레이싱을 구축하고 있다는 가정 아래, 로그를 뒷날 학습 데이터로 쓰려면 특히 다음 필드가 온전해야 한다.

입력 쪽에서는 사용자 메시지만으로 부족하다. 그 응답을 낳은 시스템 프롬프트의 버전, RAG라면 실제로 검색되어 컨텍스트에 들어간 문서와 인용, 도구 호출이 있었다면 호출과 그 결과(6.5)까지 있어야 한다. 시스템 프롬프트 버전이 없으면 "이 답이 나쁜 게 모델 탓인지 그때의 프롬프트 탓인지"를 영영 못 가린다. 출력 쪽에서는 모델 응답과 함께 모델 ID·버전, 디코딩 파라미터(온도 등, 1.7) 를 남긴다 — 재현과 귀인에 필수다. 여기에 그 응답에 붙은 명시적·암묵적 신호(8.1.3)와 타임스탬프, 그리고 슬라이스 분석의 축이 될 세그먼트 메타데이터(언어·유스케이스·사용자군·플랫폼, 가능하면 난이도 프록시)가 붙어야 8.1.5의 층화가 가능하다. 마지막으로, 그리고 가장 자주 빠뜨리는 것 — 이 레코드를 학습에 써도 되는지의 동의·정책 플래그와 PII 마스킹 상태다(8.1.12).

이 마지막 필드를 강조하는 이유가 있다. 원시 프롬프트·응답을 그대로 무기한 저장하는 것은 프라이버시·법적 시한폭탄이다. 사용자 프롬프트에는 이름·주소·건강·금융 정보, 심지어 제3자의 개인정보가 아무렇지 않게 섞인다. 학습 후보로 로그를 남길 때는 PII를 탐지·마스킹하고, 보존기한을 건 별도 스토어로 분리하는 것이 기본이어야 한다. "일단 다 저장해 두자"는 편의가 몇 년 뒤 규제·유출로 되돌아온다. 무엇을 남기느냐의 설계는 처음부터 법무·보안과 함께 정하는 것이지, 데이터가 쌓인 뒤에 소급해 정리할 수 있는 것이 아니다.

8.1.8 하드 케이스 채굴 — 우선순위와 라벨 예산

로그를 남겼으면 이제 무엇을 라벨할지 골라야 한다. 앞서 못 박았듯 평범하게 잘 처리된 대화는 개선에 거의 기여하지 않는다 — 모델이 이미 잘하는 것을 라벨해 봤자 새 신호가 없다. 연료는 모델이 어려워한 곳, 곧 하드 케이스다. 이것을 찾아내는 채굴 신호들은 대략 다음과 같다.

채굴이 후보를 만들어도, 사람이 정밀 라벨할 수 있는 양은 예산으로 묶여 있다. 주당 200개를 라벨할 인력밖에 없다면, 어느 하드 케이스를 먼저 라벨할지 결정해야 한다. 그 우선순위는 대략 세 요인의 곱으로 산정한다.

$$\text{priority}(x) \;\propto\; \underbrace{f(x)}_{\text{빈도}} \times \underbrace{s(x)}_{\text{심각도}} \times \underbrace{\ell(x)}_{\text{학습가능성}}$$

빈도 $f$ 는 이 유형이 얼마나 자주 나오는가다 — 롱테일의 희귀 버그보다 매주 수천 번 발생하는 유형이 먼저다. 심각도 $s$ 는 틀렸을 때 피해가 큰가다 — 안전·사실 오류가 문체 취향보다 중요하다. 학습가능성 $\ell$ 이 가장 자주 무시되는데, 데이터를 넣으면 실제로 고쳐지는가를 묻는다. 원리상 라벨로 못 고치는 것(예: 최신 사실 — 이것은 RAG의 일이지 파인튜닝의 일이 아니다, 8.1.10)에는 라벨 예산을 낭비하지 말아야 하고, 이 항이 그 낭비를 걸러 낸다.

숫자로 밟아 보자. 주당 200개의 인간 SFT 라벨 예산을 다섯 개의 하드 케이스 유형에 배분한다. 각 유형의 주간 빈도·심각도(1~5)·학습가능성(0~1)을 채굴 데이터에서 추정했다고 하자.

priority 총합은 $525 + 2880 + 1080 + 720 + 81 = 5286$ 이고, 200개를 이에 비례해 나누면 위 오른쪽 열이 된다(예: 언어·문체 = $200 \times 2880/5286 \approx 109$). 이 표가 가르치는 것은 원시 빈도만으로 라벨을 배분하면 틀린다는 것이다. 빈도만 보면 사실 오류·지식 격차(1800)가 가장 큰 유형이라 예산의 최다를 가져가야 할 것 같다 — 빈도 비례 배분이면 $200 \times 1800/4650 \approx 77$ 개다. 그러나 그 유형의 학습가능성은 0.1로 낮다. SFT로 새 사실을 주입하는 것은 데이터가 노후화되는 순간 다시 틀리고 없는 사실을 흉내 내며 환각을 늘리는, 원리적으로 어긋난 처방이기 때문이다(8.1.10). 학습가능성 항이 이 유형의 배분을 77개에서 27개로 깎아, 그만큼의 라벨 예산을 SFT가 실제로 고칠 수 있는 언어·문체 결함으로 귀속시킨다. 최신성 오류는 $\ell = 0.03$ 으로 사실상 SFT 대상에서 빠져(3개), 그 900건은 RAG 인덱스 개선으로 따로 흘러간다. 안전 경계는 빈도가 낮지만(150) 심각도·학습가능성이 높아 빈도 비례라면 6개일 것이 20개로 올라온다 — 드물어도 위험한 것을 앞당기는 것이 정확히 심각도 항의 역할이다.

8.1.9 라벨링 파이프라인 — 자동 스크리닝 + 인간 라벨

채굴로 후보를 좁히고 우선순위로 예산을 배분했으면, 실제로 라벨을 붙일 차례다. 여기서 4.2의 도구가 그대로 재사용되며, 핵심은 자동과 인간을 계단식으로 쌓아 고비용인 인간의 시간을 정보량 큰 곳에만 쓰는 것이다.

1차는 자동 스크리닝이다. 결정적 검사(형식·정확·규칙)와 LLM-as-judge(개방형 품질 판정, 편향 완화 포함)로 대량 로그에 약한 라벨(weak label)을 값싸고 빠르게 붙인다. 이 단계는 명백한 통과·명백한 실패를 갈라 인간이 볼 양을 몇 분의 일로 줄인다. 다만 자동 판정은 판정자 모델의 편향을 그대로 전이하므로 최종 진실이 아니고, "애매함·고심각도"로 분류된 것은 반드시 사람에게 넘긴다. 2차는 인간 라벨이다. 형태는 목적지에 따라 다르다 — SFT용은 이상적 응답을 직접 작성하는 정답 시연(3.2), 선호 학습용은 A와 B 중 어느 쪽이 나은지 고르는 쌍대 비교(3.3), 평가용은 루브릭으로 채점하는 정답·기준 라벨(4.2)이다.

인간 라벨을 어디에 쓸지 고르는 데도 규율이 있다. 능동 학습(active learning) 은 모델이 가장 불확실하거나 자동 판정이 갈리는 케이스를 우선 사람에게 보낸다 — 이미 확신하는 케이스를 라벨하는 것은 정보 이득이 거의 없기 때문이다. 라벨 예산(8.1.8)을 정보량 큰 곳에 집중하는 이 원리가 곱해지면, 같은 인력으로 두세 배의 개선을 뽑는다. 그리고 각 데이터 배치에는 데이터 카드와 프로비넌스를 붙인다 — 출처, 수집 시점, 동의 상태, 라벨러, 라벨 가이드 버전. 뒷날 "이 배치가 회귀를 냈다"거나 "이 사용자가 삭제를 요청했다"(9.3)를 추적하려면 프로비넌스가 없이는 손을 못 쓴다. 이 이력 관리가 다음다음 장(8.3)의 모델 라이프사이클로 이어진다.

8.1.10 루프 닫기 — 신호를 어디로 흘려보내나

큐레이션된 데이터가 손에 있다고 개선이 되는 것이 아니다. 같은 증상 — 예컨대 "나쁜 답" — 이라도 원인에 따라 목적지가 완전히 다르고, 잘못 라우팅하면 비용만 쓰고 안 고쳐지거나 오히려 나빠진다. 지식 부족을 파인튜닝으로 고치려 들면 데이터가 노후화되며 다시 틀리고 환각이 는다. 톤 문제를 파인튜닝으로 고치려 들면 며칠이면 될 일에 몇 주와 파이프라인을 쓴다. 루프를 닫는다는 것은 곧 정확히 라우팅한다는 것이다.

라우팅에는 몇 가지 중요한 원칙이 있다. 저렴하고 빠른 경로부터 시도한다. 프롬프트로 고쳐지는 문제를 파인튜닝으로 고치지 마라 — 프롬프트 수정은 며칠, 파인튜닝은 몇 주에 비용도 자릿수가 다르다. 파인튜닝은 프롬프트로 안정적으로 안 되는 것에만 쓴다. 지식은 RAG, 행동은 파인튜닝이라는 구분이 그다음이다. 파인튜닝은 새 사실을 주입하는 도구가 아니다. 최신성·사실·출처가 필요한 문제는 RAG로 보내고, 파인튜닝은 스타일·형식·도메인 말투·도구 사용 패턴 같은 행동을 체화하는 데 쓴다 — 이것이 8.1.8의 학습가능성 항이 지식·최신성 유형을 SFT 예산에서 제외한 이유다. 모든 케이스는 최소한 평가셋으로 고정한다. 무엇을 어떻게 고치든, 재발을 막는 회귀 케이스로 평가셋에 넣는 것은 거의 언제나 옳다 — 가장 저렴하고 가장 확실한 루프 닫기다. 마지막으로 한 번에 하나의 변경만 민다. 여러 경로를 동시에 밀면 무엇이 개선을, 무엇이 회귀를 냈는지 못 가른다.

8.1.11 워크스루 — 재생성 급증 세그먼트에서 SFT·평가셋으로

앞의 조각들을 하나의 절차로 꿰어 보자. 출발점은 관측이다 — "코드 디버깅 유스케이스의 한국어 세그먼트에서 재생성률이 갑자기 튀었다"는 대시보드 신호(7.6). 목적지는 큐레이션된 SFT 배치와 평가셋이다. 모든 수치는 설명용 개략값이다.

단계 0 — 세그먼트 지표를 정의한다. 세그먼트 $s$ 의 재생성률을

$$r_s = \frac{\#\{\text{재생성 요청}\}}{\#\{\text{응답}\}}$$

로 정의하고, 지난 4주 기준선 평균 $\bar r_s$ 와 표준편차 $\sigma_{r,s}$ 를 세그먼트별로 유지한다.

단계 1 — 이상을 탐지한다. 이번 주 각 세그먼트의 표준화 편차(z-점수)를 본다.

$$z_s = \frac{r_s - \bar r_s}{\sigma_{r,s}}$$

한국어 디버깅만 $z = +5$ 로 급등한다. 여기서 8.1.4의 표본크기 가늠이 먼저 작동한다 — 이 세그먼트가 주당 수천 응답을 낸다면 재생성률의 표준오차는 1%p 안팎이라 15%p 급등은 잡음이 아니다. 그리고 8.1.5의 교란 통제가 작동한다 — 영어 디버깅이 정상이므로 "디버깅이 원래 어렵다"는 교란은 배제되고, 한국어 디버깅 특유의 무언가가 남는다. 마지막으로 삼각측량으로 확정한다 — 같은 세그먼트에서 좋아요율이 18%에서 9%로, 후속 재질문율도 함께 오르면 "문제 있음" 가설이 선다.

단계 2 — 하드 케이스를 추출한다. 그 세그먼트의 최근 로그에서 재생성된 대화 중 부정 신호(낮은 피드백 또는 재질문)가 겹친 것을 뽑는다. 3,200개 응답 중 재생성 928개, 그중 부정 신호가 겹친 340개가 1차 후보라 하자.

# 개략 의사코드 — 세그먼트 하드 케이스 추출
hard = [
    log for log in week_logs
    if log.segment == ("code_debug", "ko")
    and log.regenerated
    and (log.thumb_down or log.followup_reask)   # 신호 삼각측량
]
# 우선순위: 빈도(유형 클러스터 크기) × 심각도 × 학습가능성
hard.sort(key=priority, reverse=True)

단계 3 — 유형을 군집화한다. 340개를 임베딩·클러스터링(6.2)하거나 LLM으로 요약 태깅해 원인 유형을 본다. 가상의 결과다.

하나의 급증이 네 개의 다른 문제로 갈라진다 — 이것이 큐레이션의 핵심이다. 뭉뚱그려 "SFT 하자"였다면 27%(지식)는 안 고쳐지고 15%(형식)는 과잉 대응이었을 것이다. 8.1.8의 학습가능성 항이 여기서 실제로 작동한다.

단계 4 — 라벨하고 라우팅한다. 최다이자 학습가능한 48%(언어 오해)를 SFT로 보내, 사람이 각 케이스에 이상적 응답을 시연해 SFT 데이터로 만든다(3.2의 대화 포맷·손실 마스킹). 27%(최신성)는 RAG 인덱스 개선으로, 15%(형식)는 프롬프트·제약 디코딩(6.9)으로 흘린다. 동시에 각 유형의 대표 케이스를 정답·루브릭과 함께 평가셋에 고정한다(4.2).

단계 5 — 검증하고 닫는다. SFT 배치를 학습(8.3)한 뒤, 먼저 홀드아웃 평가셋으로 회귀가 없는지 확인하고, A/B로 소량 트래픽에 적용해 재생성률이 실제로 내려가는지 본다(8.2). 여기서 8.1.6을 잊지 마라 — 대시보드에서 재생성률이 내려간 것을 보는 것만으로는 부족하고, 통제된 A/B가 인과를 판정한다. 내려가면 승격, 아니면 롤백하고 원인을 재분석한다. 배포 후에도 그 세그먼트의 $r_s$ 를 계속 모니터링한다 — 플라이휠이 한 주기를 마쳤다.

이 절차를 처음부터 완벽한 자동화로 세우려 들지 마라. 대단한 이상탐지 시스템 없이도, 매주 "재생성·싫어요가 많은 세그먼트 top 3"를 사람이 30분 훑고 20개를 라벨해 SFT·평가셋으로 보내는 수동 루프만으로도 플라이휠은 작동한다. 자동화(이상탐지·능동학습·자동 라우팅)는 그 수동 루프가 병목이 됐을 때 점진적으로 붙인다. 완벽한 파이프라인을 반년 짓는 것보다 매주 한 주기를 마치는 작은 플라이휠이 낫다 — 후자는 반년 뒤에 26주기를 마쳤고, 전자는 그때 겨우 첫 주기를 시작한다.

8.1.12 프라이버시·동의 — 사용자 데이터로 학습하기

플라이휠의 연료는 사용자가 남긴 데이터다. 그런데 그 데이터로 모델을 학습·개선하는 것은 법적·윤리적으로 임의로 해도 되는 일이 아니다. 사용자의 프롬프트에는 이름·주소·건강·금융·영업비밀, 심지어 제3자의 개인정보가 섞이고, 그것을 학습에 쓰는 순간 서비스 제공과는 다른 차원의 의무가 생긴다. 관할별 법(GDPR·개인정보보호법·EU AI Act 등)의 세부는 9.3에서 다룬다. 여기서는 파이프라인 설계에 곧장 반영되는 원칙만 정리한다.

동의와 목적 제한이 첫 관문이다. "서비스를 제공받는 데" 동의한 것과 "그 데이터로 모델을 학습하는 데" 동의한 것은 다르다. 학습 사용은 보통 별도의 명시적 근거가 필요하고, 약관에 슬쩍 삽입하는 것으로는 부족한 관할이 많다(구체 요건은 관할별로 다르므로 9.3와 법무 확인이 필요하다). 특히 건강·정치·생체 같은 민감정보는 문턱이 훨씬 높다. 다음은 옵트인이냐 옵트아웃이냐다. 학습 사용을 기본 켬으로 할지 기본 끔으로 할지는 제품·관할·사용자군에 따라 갈린다. B2C 무료 제품은 고지 후 옵트아웃이 흔하지만, B2B·기업 계약은 대개 기본적으로 학습 금지가 계약·DPA로 명시된다 — 고객사 데이터를 벤더가 학습에 쓰면 계약 위반이자 영업비밀 유출이 되기 때문이다. 제품 등급별로 정책을 분리해야 한다.

옵트아웃은 선언이 아니라 파이프라인이어야 한다. 옵트아웃한 사용자·세션의 레코드가 큐레이션·라벨링·학습 데이터셋에 실제로 들어가지 않도록, 필터가 상류에 — 8.1.7에서 남긴 동의 플래그를 읽는 자리에 — 있어야 한다. 프로비넌스(8.1.9)가 갖춰져 있어야 "이미 학습에 들어간 데이터의 삭제 요청"까지 추적·대응할 수 있다. 학습 후보로 남기기 전에는 PII를 탐지·마스킹하고(이름·이메일·주민·카드번호 등), 필요한 필드만 최소로, 정해진 기간만 보관한다.

여기서 가장 흔한 착각을 정면으로 깨자 — "익명화했으니 마음대로 학습해도 된다"는 틀렸다. 마스킹은 재식별 위험을 줄일 뿐 없애지 못하고, 동의·목적 제한·계약 제약은 익명화와 별개로 걸린다. 게다가 모델은 학습 데이터를 암기하고 되뱉을 수 있어(memorization·regurgitation, 7.4), 마스킹이 조금이라도 불완전하면 한 사용자의 PII가 다른 사용자의 출력으로 유출된다. 아동 데이터나 의료·금융 같은 규제 산업 데이터에는 별도 규정이 겹친다. "학습에 쓸 수 있는 데이터"를 정의하는 정책이 파이프라인의 첫 관문이어야 하고, 그 정책은 엔지니어링이 혼자 정할 일이 아니라 법무·보안과 함께 세우는 것이다.

8.1.13 나쁜 플라이휠 — 편향과 제품판 보상 해킹

이제 8.1.2에서 예고한 어두운 회전 방향을 정면으로 본다. 피드백은 편향돼 있고, 그 편향을 무비판적으로 최적화하면 제품이 왜곡된다. 나쁜 플라이휠은 세 겹으로 온다 — 데이터가 대표성이 없고, 루프가 편향을 증폭하며, 지표를 향한 폭주가 실질을 잠식한다.

먼저 피드백은 대표성이 없다. 명시적 피드백을 남기는 사람은 극소수이고 대개 극단적 경험(아주 화났거나 아주 감동한)에 치우친다 — 이 소수 목소리(vocal minority)의 분포는 전체 사용자 분포가 아니다. 더 무서운 것은 생존 편향이다. 떠난 사용자는 피드백을 남기지 않는다. 가장 중요한 신호 — "이래서 못 쓰겠다" — 를 준 사람들이 데이터에서 전부 빠져 있고, 남은 사용자의 만족도만 보면 "다 잘되고 있다"는 착시가 생긴다. 정작 고쳐야 할 이탈 원인은 로그에 없다. 여기에 선택·노출 편향이 겹친다 — 사용자는 제품이 잘하는 것만 물어본다(못하는 것을 알면 아예 안 쓴다). 그래서 로그 분포는 제품의 강점 쪽으로 쏠리고 약점은 과소 표집된다. "우리 로그엔 그런 질문이 별로 없다"가 "그 수요가 없다"를 뜻하지 않는다.

다음으로 자기강화 루프가 편향을 증폭한다. 추천 시스템에서 잘 알려진 병이 LLM 제품에도 온다. 모델이 특정 스타일의 답을 내고, 그 스타일에 익숙한 사용자가 남고, 그들의 피드백으로 다시 그 스타일이 강화되고, 다른 스타일을 원하는 사용자는 떠난다. 피드백 루프가 초기의 작은 편향을 복리로 증폭해 다양성이 좁아지고 특정 관점·집단에 대한 편향이 굳는다(9.4의 편향·공정성으로 이어진다). 여기에 8.1.2에서 본 모델 붕괴 위험 — 자기 출력을 무비판적으로 환류시켜 꼬리가 사라지는 것 — 이 겹치면 분포는 한층 더 좁아진다.

가장 교묘한 것이 제품판 보상 해킹이다. 피드백에서 뽑은 대리지표를 최적화하면 제품은 그 지표만 좋아지고 실질은 나빠진다. RLHF의 보상 해킹(3.4), 벤치마크 게이밍(4.1)과 정확히 같은 병이고, 굿하트의 법칙 — 측정을 목표로 삼으면 그 측정은 좋은 측정이기를 멈춘다 — 의 제품판이다. 좋아요를 최적화하면 모델이 사용자에게 동조하고 자신감 있게 단정하고 듣기 좋은 말을 하도록 수렴한다. 좋아요는 올라가는데 정확성·정직성은 붕괴하는 아첨꾼이 된다(3.1의 정직성과 정면 충돌). 참여(세션 길이·왕복 수)를 최적화하면 모델이 일부러 장황하고 질질 끄는 답을 하도록 밀린다 — 사용자를 빨리 만족시켜 떠나보내는 것이 오히려 좋은 답인데도. 재생성률을 무조건 낮추도록 최적화하면 모델이 재생성 버튼을 안 누르게 만드는 방향, 즉 무난하고 반박하기 어려운 답으로 수렴한다 — 실질 개선 없이.

이 모든 것이 "피드백을 쓰지 말라"는 뜻은 아니다. 피드백은 필수 연료다. 요점은 어떤 단일 지표도 실제 목표가 아니라 대리지표임을 잊지 않는 것이다. 방어는 네 겹으로 세운다. 편향(소수 목소리·생존·선택)을 능동적으로 보정한다 — 이탈자를 따로 조사하고, 침묵하는 다수를 표집한다. 여러 신호를 삼각측량한다(8.1.5). 최적화 지표를 주기적으로 바꿔 한 지표에의 과적합을 막는다. 그리고 최종 판단을 단일 온라인 지표가 아니라 인간 앵커와 홀드아웃 평가에 건다(4.2). 대리지표 하나를 향한 폭주가 나쁜 플라이휠의 엔진이고, 이 네 겹이 그 엔진을 멈추는 제동 장치다.

이 장의 실제 결론은 경쟁우위의 정체에 관한 것이다. 데이터 플라이휠의 우위는 "데이터를 많이 가진 것"에서 오지 않는다. 같은 로그를 가진 두 팀 중, 매주 하드 케이스를 골라 라벨하고 원인별로 라우팅하고 회귀를 평가셋으로 막는 팀이 이긴다. 데이터는 흔하고 큐레이션 규율은 드물다 — 해자는 후자다. 이 규율 있는 루프가 만든 개선안을 이제 안전하게 배포하고 인과로 검증하는 일이 다음 장(8.2)의 실험·A/B·롤백이고, 이 장이 만든 SFT·선호 데이터를 버전·재현·거버넌스 있는 파이프라인으로 운용하는 일이 그다음 장(8.3)의 파인튜닝 운영이다.