LLM

왜 지금 이게 문제인가 LLM을 단순한 챗봇이 아니라 ‘에이전트’로 활용하려는 시도가 늘어나면서 백엔드 엔지니어들은 새로운 형태의 통합 지옥(Integration Hell)에 빠졌다. 기존에는 서비스마다 제각각인 REST API 명세에 맞춰 툴(Tool)을 정의하고, 프롬프트에 수십 개의 함수 명세를 때려 넣는 노가다를 반복해 왔다. 툴 관리의 비대해짐: 에이전트가 처리할 도메인이 넓어질수록 tools[] 리스트는 관리 불가능한 수준으로 길어지고, 이는 곧 컨텍스트 윈도우 낭비와 모델의 추론 성능 저하로 이어진다. 표준의 부재: 서로 다른 팀이나 회사가 만든 에이전트끼리 협업하려면, 결국 또 사람이 개입해서 API 스펙을 맞추고 인증 로직을 새로 짜야 한다. 신뢰와 보안의 트레이드오프: 에이전트에게 실행 권한을 줄수록 보안 리스크는 커지며, 특히 금융권이나 대규모 커머스처럼 ‘무결성’이 중요한 한국 실무 환경에서 ‘Auto-Approve’ 같은 기능은 기술적 부채보다 무서운 운영 리스크가 된다. 구글이 제시한 MCP(Model Context Protocol)와 A2A(Agent-to-Agent) 등의 프로토콜은 이 파편화된 연결 고리를 표준화하겠다는 선언이다. 이제 에이전트는 직접 API를 호출하는 대신, 표준화된 프로토콜을 통해 데이터에 접근하고 다른 에이전트에게 업무를 위임한다. ...

왜 지금 이게 문제인가 “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을 프로덕션에 투입하는 팀이 늘어나면서 두 가지 근본적인 문제가 동시에 터지고 있다. 첫째, 지연 시간(Latency). 거대 모델에 모든 요청을 던지면 응답이 느려서 실시간 시스템에 쓸 수 없다. 둘째, 신뢰성(Reliability). 빠른 경량 모델만 쓰면 복잡한 추론에서 환각(Hallucination)이 터진다. “빠르면 부정확하고, 정확하면 느리다"는 딜레마 속에서 대부분의 팀은 하나를 포기한다. 구글이 고속 레이싱 환경에서 실험한 스플릿-브레인(Split-Brain) 아키텍처는 이 딜레마를 정면으로 공략한다. 시속 160km로 달리는 차량에서 AI가 실시간 코칭을 하는 극단적인 시나리오에서 검증된 설계다. ...

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