\"LLM한테 추천 맡기면 되지 않아?\" — 이 질문이 위험한 이유

"LLM한테 추천 맡기면 되지 않아?" — 이 질문이 위험한 이유

"우리 서비스에 추천 기능을 넣자. LLM한테 맡기면 되지 않아?"

요즘 CTO들과 미팅을 하거나 밋업에 참가하면 이런 이야기에 고민하는 CTO들을 정말 자주 본다고 해요. CEO, PM, PO, 사업 리더 할 것 없이 LLM이 마치 우리 서비스의 모든 데이터를 꿰고 있는 만능 추천 엔진인 것처럼 이야기하는 거예요.

겉으로 보면 둘이 똑같기 때문에 이런 오해가 생기거든요. 데이터베이스에 SQL을 던지면 답이 나오고, LLM에 프롬프트를 던져도 답이 나오고. "질문하면 답해준다"는 경험이 동일하니 안쪽이 근본적으로 다르다는 걸 신경 쓰지 않게 되는 거죠.

근데 안쪽은 완전히 달라요. 데이터베이스는 이미 저장해둔 데이터 안에서 찾아서 답하고, LLM은 사전에 학습한 일반 지식과 우리가 프롬프트에 함께 넣어준 정보를 토대로 추론해서 답해요. 저장소에서 꺼내오는 것과 건네받은 정보로 추론하는 것. 완전히 다른 일이에요.

f(x) = y — LLM은 거대한 함수다

결론부터 말하면, LLM은 데이터베이스가 아니에요. LLM은 거대한 함수예요.

데이터베이스는 데이터를 저장하죠. 사용자 정보, 구매 이력, 상품 목록, 클릭 로그 같은 걸 체계적으로 보관하고, 질의를 통해 정확하게 꺼내와요. "지난 30일간 A 사용자가 구매한 상품 목록"이라고 질의하면 정확히 그 목록이 반환돼요. 저장된 범위 안에서 조건에 맞는 결과를 반환하는 거예요.

LLM은 우리 서비스의 데이터를 데이터베이스처럼 정확하게 조회 가능한 형태로 갖고 있지 않아요. 물론 아무것도 모르는 건 아니에요. 학습 과정에서 인터넷에 공개된 텍스트들의 패턴을 익혔으니까 "배달의민족이 뭐야?" 같은 일반 상식엔 답할 수 있어요. 근데 이건 백과사전을 읽고 감을 잡은 것에 가까울 뿐이에요. 사용자 행동 로그, 실시간 재고, 거래 내역 같은 비즈니스 데이터는 알지 못하거든요.

대규모 파라미터로 이루어진 거대한 수학 함수가 입력(프롬프트)을 받으면 가장 그럴듯한 출력(응답)을 생성하는 거예요. `f(x) = y`. x가 프롬프트이고 y가 응답.

그래서 LLM에게 "A 사용자에게 맞는 상품을 추천해줘"라고 물으면 LLM은 이렇게 반응해요. "A 사용자가 누군데요? 어떤 상품이 있는데요? 그 사용자가 뭘 샀는데요?" 우리 데이터베이스에 접속해서 데이터를 조회하는 게 아니니까요.

LLM의 기본 동작은 매번 기억을 잃는 구조(비상태, Stateless)예요. 함수라는 건 입력을 넣으면 출력이 나오는 기계라는 뜻이거든요. 매 호출이 독립적이에요. 어제 A 사용자에 대해 물어봤어도, 오늘 다시 물어보면 어제 대화를 기억 못 해요. (채팅 기록이 이어지는 것처럼 보이는 건, 이전 대화 내용을 매번 입력에 통째로 다시 넣어주기 때문이에요.)

반면 데이터베이스는 한 번 저장하면 계속 남아있는 저장소(상태 유지, Stateful). 어제 저장한 A 사용자의 구매 이력은 1년 뒤에도 정확히 그대로 남아있어요.

"우리 데이터로 학습시키면 되잖아" — 학습은 기억이 아니다

예상되는 반론이 있죠. "그러면 우리 데이터로 학습시키면 되잖아." 모델이 데이터를 학습해서 똑똑해진 거니까, 우리 데이터도 학습시키면 우리 서비스를 아는 LLM이 되는 것 아니냐는 논리.

결론부터. 학습은 기억이 아니에요.

설령 파인튜닝을 통해 일부 도메인 패턴을 학습시킬 수 있더라도, 최신 사내 데이터를 저장하고 조회하는 수단으로 쓰는 건 적절하지 않아요. "A 사용자가 3월 15일에 구매한 상품 목록"을 정확히 기억하는 LLM이 만들어지는 게 아니에요. 패턴을 익힌 거지, 데이터를 저장한 게 아니거든요. 일부 학습 데이터가 재현되는 현상은 실제로 관찰되지만, 데이터베이스처럼 정확히 조회 가능한 저장과는 다른 거예요.

게다가 우리 서비스의 데이터는 매일 바뀌잖아요. 오늘 품절된 상품이 내일 다시 입고되고, 매 시간 새로운 행동 로그가 쌓이고. 일주일 전에 학습시킨 내용은 이미 낡은 정보. 파인튜닝은 상당한 시간과 비용이 들고, 모델 규모와 방식에 따라 편차도 큰데 매일 바뀌는 재고와 행동 로그를 매번 학습시킬 수는 없어요. 파인튜닝은 보통 특정 베이스 모델에 종속되니까 모델 업그레이드되면 재학습이나 재평가 비용까지 추가로 생기고요.

결국 답은 간단해요. 매번 LLM에게 우리 데이터를 외우게 시키는 건 비현실적이니, 필요할 때 데이터를 꺼내서 LLM에게 건네주면 되는 거예요. 그 데이터를 꺼내주는 게 바로 데이터베이스의 역할이에요.

Function Calling이 마법처럼 보여도 결국 데이터 인프라가 먼저다

"요즘은 AI가 알아서 DB 데이터를 가져와서 사용하잖아." 맞아요, LLM에게 추천받는 건 당연히 가능해요. 근데 그 구조는 "LLM한테 추천하게 하면 돼" 같은 단순한 구조가 아니에요.

요즘 LLM은 Function Calling이나 외부 연동 프로토콜을 통해 데이터베이스를 직접 조회하는 것처럼 동작할 수 있어요. 근데 구조를 뜯어보면, LLM이 도구를 호출 → 도구가 데이터베이스에서 데이터를 가져옴 → LLM에게 넘겨주는 거예요. LLM이 직접 DB를 조회하는 게 아니라, 중간 도구가 데이터를 가져와서 프롬프트에 넣어주는 거예요.

그 도구가 일하려면? 데이터베이스가 있어야 하고, 데이터가 정리되어 있어야 해요. 결국 데이터 인프라가 먼저라는 결론은 똑같아요.

올바른 구조는 두 가지 방식이 있어요.

첫째, 기존 추천 시스템의 결과를 LLM에게 넘기는 방식. 구글, AWS 등 클라우드사가 제공하는 추천 서비스나 이미 구축된 협업 필터링 시스템을 통해 개인화된 추천 후보를 넓은 범위로 뽑아와요. 그 후보군을 LLM에게 넘기면, LLM이 사용자 맥락에 맞게 순서를 조정하거나 추천 이유를 자연어로 설명해주는 역할을 하는 거죠.

둘째, VectorDB로 먼저 추리는 방식. 서비스 데이터를 벡터로 변환해서 저장해두고, 사용자의 질문이나 관심사와 의미적으로 연관도 높은 데이터를 먼저 추려내요. 수만 개 상품 중 연관도 높은 수십 개를 먼저 골라내는 거예요. 그걸 LLM에게 넘겨서 최종 추천을 만드는 구조.

어느 쪽이든 핵심은 같아요. LLM에게 전체 데이터를 쏟아붓는 게 아니라, LLM이 소화할 수 있는 크기로 추려서 넘겨주고 그 위에서 추론하게 하는 거예요. 너무 많은 정보를 한꺼번에 넣으면 오히려 정확도가 떨어지거든요.

기존 추천 시스템이 잘 돌아가면 그걸 LLM으로 교체할 이유가 없다

솔직히 이게 제일 중요한 포인트예요.

기존 추천 시스템은 사용자의 모든 행동 데이터를 먹고 자랐어요. 어느 페이지에서 얼마나 머물렀는지, 어떤 상품을 몇 번 클릭했는지, 장바구니에 넣었다가 뺀 상품, 미리보기만 재생하고 떠난 강의. 수천만 건의 행동 로그가 수치화되어 모델에 반영돼 있어요. "이 사용자는 Python 강의를 자주 수강하지만 프론트엔드는 건너뛰고, 저 사용자는 할인 쿠폰이 있어야만 결제한다" — 이런 것까지 빼곡히 기록되어 있는 거예요.

LLM 단독으로 A 사용자에게 강의를 추천하려면 뭐가 필요할까요. A 사용자의 모든 행동 데이터, 전체 사용자의 구매 데이터, 모든 강의 목록, 리뷰 데이터, 주문 정보 등을 프롬프트에 다 넣어줘야 해요. 근데 이건 한 번만 하면 되는 게 아니에요. 다시 추천해달라고 하면 방금 넣었던 데이터를 또 넘겨야 해요. LLM은 이전 요청을 기억 못 하니까. 매 요청마다 방대한 데이터를 항상 같이 넘겨야 하는 거예요.

사실상 불가능해요. 토큰 수 제한도 있고, 비용도 있고, 수천만 건의 행동 로그를 텍스트로 변환해서 프롬프트에 넣는다는 것 자체가 비현실적이에요. LLM은 텍스트 맥락 이해에 뛰어나지, 수천만 건의 수치화된 행동 로그를 실시간 분석하는 데 적합한 건 아니니까요.

비용과 속도 이야기도 빠질 수 없어요. 전통적인 추천 시스템은 한 번의 추천에 수 밀리초가 걸리고 비용도 거의 안 들어요. LLM 기반은 지연과 비용 모두 자릿수가 달라요. 하루에 수백만 명이 접속하는 서비스에서 매번 LLM을 호출한다면? 응답은 느려지고 비용은 천문학적.

LLM은 거대한 함수이지, 거대한 저장소가 아니에요. 추론과 저장은 분리되어야 해요. 그 위에 LLM을 얹는 거지, LLM이 모든 걸 대체하는 게 아니에요.

"AI를 도입하겠다"는 좋은 방향이에요. 다만 그 전에 물어볼 것들이 있어요. 사용자 행동 로그가 제대로 쌓이고 있는지, 추천에 필요한 데이터가 정의되어 있는지, 그 데이터를 꺼내서 LLM이 소화할 수 있는 형태로 정제해서 넘겨줄 수 있는 구조가 갖춰져 있는지. 이 질문에 답할 수 없다면, LLM 도입 전에 할 일이 먼저 있는 거예요.