MLOps

왜 지금 이게 문제인가 “GPT-4를 그냥 API로 쓰면 되지 않나?” 많은 기업이 이 질문에서 출발하지만, 넷플릭스는 다른 답을 내렸다. 범용 LLM은 넷플릭스의 콘텐츠 카탈로그, 추천 알고리즘, 사용자 행동 패턴을 모른다. “이 영화가 한국 30대 남성에게 왜 매력적인가"를 GPT-4에게 물어봐야 일반론만 돌아온다. 넷플릭스 AI 플랫폼 팀은 범용 모델을 가져다가 자사 데이터로 **Post-Training(사후 학습)**하는 내부 프레임워크를 구축했다. 이는 단순한 파인튜닝을 넘어, 프로덕션에서 추천·검색·개인화에 직접 투입되는 모델을 대규모로 생산하는 LLM 공장이다. API 의존의 한계: 외부 LLM API는 자사 데이터로 학습되지 않았고, 모델 업데이트 시점을 통제할 수 없으며, 민감한 사용자 데이터를 외부로 보내야 한다. 넷플릭스 규모에서 이 세 가지는 모두 수용 불가능하다. 파인튜닝의 인프라 복잡성: 수십~수백 대의 GPU 노드에서 분산 학습을 돌리는 것은 모델 코드를 짜는 것보다 10배 어렵다. 노드 하나가 죽으면 수일간의 학습이 날아가고, 체크포인팅은 네트워크 대역폭을 잡아먹으며, GPU 메모리 관리는 악몽이다. 한국적 맥락: 쿠팡, 토스, 카카오 같은 데이터 기반 서비스가 “우리만의 LLM을 만들어야 하나"를 고민 중이다. 넷플릭스의 사례는 Pre-training(처음부터 학습)이 아닌 Post-Training(기존 모델 위에 학습)이라는 현실적 경로를 보여준다. 어떻게 동작하는가 넷플릭스의 Post-Training Framework는 세 개의 레이어로 구성된다. ...

왜 지금 이게 문제인가 LLM을 프로덕션에 올린 팀이라면 반드시 한 번은 이 질문과 마주친다. “우리 도메인 데이터를 모델에 주입하려면, RAG를 쓸까 Fine-tuning을 할까?” 그리고 대부분은 직감으로 결정한 뒤 나중에 후회한다. 문제는 두 접근법이 해결하는 문제 자체가 다르다는 점이다. RAG는 “모델이 모르는 최신 정보를 실시간으로 보충"하는 것이고, Fine-tuning은 “모델의 행동 패턴과 출력 형식을 바꾸는 것"이다. 법률 AI에 판례 검색이 필요한 건 RAG 영역이고, 법률 문서 특유의 어투와 형식으로 답변하게 만드는 건 Fine-tuning 영역이다. 하지만 실무에서는 이 구분이 깔끔하지 않다. ...