생성형 AI가 세상을 뒤흔든 뒤, 많은 사람이 이렇게 묻는다. 이제 선형회귀나 랜덤 포레스트를 배우는 일은 낡은 공부가 아닌가요. 하지만 실제 답은 그 반대에 가깝다. LLM이 등장했기 때문에 오히려 머신러닝의 기본기가 더 중요해졌다. 이유는 단순하다. LLM은 머신러닝과 단절된 외계 기술이 아니라, 머신러닝이 아주 멀리까지 확장된 결과물이기 때문이다.
겉으로 보면 둘은 꽤 달라 보인다. 전통적 머신러닝은 예측, 분류, 추천처럼 비교적 또렷한 문제를 다루고, LLM은 대화하고 요약하고 글을 쓴다. 그래서 마치 서로 다른 세계의 기술처럼 느껴진다. 하지만 조금만 가까이 가서 보면, 둘 다 결국 데이터에서 패턴을 배우고, 그 패턴을 새로운 입력에 적용한다는 점에서는 같은 가족이다. 달라진 것은 기본 원리의 존재 여부보다도 학습 데이터의 규모, 사전학습 방식, 모델의 범용성, 그리고 주로 만들어 내는 출력의 형태다.
LLM은 머신러닝의 연장선 위에 있다
언어 모델의 가장 기본적인 일은 다음에 올 토큰을 예측하는 것이다. 여기서 토큰은 단어 전체일 수도 있고, 단어의 일부 조각일 수도 있다. 모델은 문장을 읽고 나서 그다음에 어떤 말이 이어질 확률이 높은지 계산한다. 이 단순해 보이는 반복이 규모를 만나면 놀라운 능력으로 커진다. 요약, 번역, 질의응답, 문장 생성 같은 기능이 모두 이 기반 위에서 나온다.1
이 지점이 중요하다. LLM은 머신러닝을 버리고 새로 태어난 기술이 아니다. 딥러닝, 표현 학습, 대규모 사전학습이 쌓여 만들어진 확장판이다. 차이는 학습을 하느냐 마느냐가 아니라, 얼마나 큰 텍스트 데이터를 어떤 방식으로 미리 학습했는지, 그리고 하나의 모델이 얼마나 많은 작업으로 옮겨 갈 수 있는지에 있다.2
전통적 머신러닝 모델이 대개 특정 문제를 위해 훈련된 전문가라면, LLM은 언어라는 공통 기반을 폭넓게 익힌 뒤 여러 일을 해 볼 수 있는 범용 인력에 가깝다. 물론 범용이라고 해서 항상 최고라는 뜻은 아니다. 다재다능한 사람과 특정 공정의 숙련공 중 누가 더 적합한지는 맡길 일에 따라 달라진다. 이 단순한 상식이 LLM 시대에도 그대로 통한다.
전통적 머신러닝과 LLM은 잘하는 일이 다르다
표 형태의 고객 데이터가 있고, 목표가 이탈 여부 예측이라면 어떻게 할까. 나이, 결제 주기, 최근 이용 횟수, 고객센터 접수 수 같은 열이 있고, 출력은 이탈할 가능성 0 또는 1에 가깝다. 이런 문제에서는 그라디언트 부스팅이나 로지스틱 회귀 같은 전통적 머신러닝이 여전히 매우 강하다. 빠르고, 비용이 낮고, 성능을 설명하기도 쉽다.
반대로 수천 개의 매뉴얼 문서, 상담 로그, 공지사항을 읽고 사용자의 질문에 자연어로 답해야 한다면 이야기가 달라진다. 입력 자체가 비정형 텍스트이고, 출력도 문장이다. 이때는 LLM이 훨씬 자연스럽다. 텍스트를 읽고, 맥락을 이어 받고, 답변을 생성하는 일이 본업에 가깝기 때문이다.
그래서 모델 선택은 유행이 아니라 문제의 모양으로 해야 한다. 먼저 출력 형식이 무엇인지 봐야 한다. 숫자 하나를 맞히는가, 클래스 하나를 고르는가, 아니면 문장을 생성해야 하는가. 그다음 입력 데이터의 형태를 봐야 한다. 구조화된 표 데이터인가, 긴 문서인가, 둘이 섞여 있는가. 여기에 지연 시간, 비용, 설명 가능성, 운영 복잡도까지 얹으면 답이 보이기 시작한다.
전통적 머신러닝은 구조화 데이터와 좁고 명확한 목표에서 강하다. LLM은 대규모 비정형 텍스트와 다양한 언어 작업에서 강하다. 하지만 LLM은 추론 비용이 크고, 응답 시간이 길어질 수 있으며, 왜 그런 답이 나왔는지 설명하기 어려운 경우가 많다. 반대로 전통적 머신러닝은 해석과 배포가 쉬운 대신, 언어적 뉘앙스와 열린 형태의 생성 작업에서는 한계가 뚜렷하다.3
이 말을 뒤집으면 이런 뜻이 된다. 모든 문제를 LLM으로 풀 필요는 없다. 그리고 모든 문제를 예전 방식으로만 풀 수도 없다. 좋은 설계자는 어느 한쪽을 숭배하지 않고, 문제에 맞는 도구를 고른다.
프롬프트는 지시이고, 파인튜닝은 습관 만들기다
LLM을 실제 서비스에 붙일 때 초심자가 가장 많이 헷갈리는 부분이 프롬프트와 파인튜닝의 차이다. 둘 다 모델의 출력을 바꾸지만, 바꾸는 방식은 완전히 다르다.
프롬프트 엔지니어링은 모델의 가중치를 바꾸지 않는다. 대신 질문하는 방식, 지시문의 구조, 예시의 배치, 출력 형식의 제약을 조정해서 원하는 답변을 끌어내는 방법이다. 같은 사람에게 일을 부탁해도 말투와 순서를 바꾸면 결과가 달라지는 것과 비슷하다. 빠르고 저렴하며, 실험 속도가 빠르다. 새로운 기능을 시험하거나, 업무 흐름을 설계하거나, 출력 형식을 맞춰 보는 첫 단계로 특히 유용하다.
파인튜닝은 다르다. 모델의 가중치를 실제로 업데이트해서 특정 작업이나 도메인에 더 잘 맞게 만드는 일이다. 법률 문체, 의료 용어, 사내 답변 형식처럼 일관성이 아주 중요하거나, 프롬프트만으로는 흔들림이 큰 경우에 검토할 수 있다. 대신 비용이 더 들고, 데이터도 더 필요하며, 잘못하면 원래의 범용 성능을 일부 잃을 수도 있다. 쉽게 말해 프롬프트가 지시라면, 파인튜닝은 반복 훈련을 통해 습관을 만드는 일이다.
현업에서는 이 둘 사이에 도메인 적응이라는 현실적인 층이 하나 더 있다. 일반 모델을 그대로 쓰지 않고, 우리 업계의 용어집, 문서 구조, 답변 톤, 업무 맥락을 반영해 점차 현장형 모델로 바꾸는 과정이다. 꼭 파인튜닝만을 뜻하지는 않는다. 프롬프트 템플릿을 정교하게 만들고, 예시를 붙이고, 외부 문서를 검색해 넣고, 필요한 경우 마지막에 파인튜닝까지 가는 식으로 단계적으로 접근할 수 있다.
실무 감각으로 정리하면 이렇다. 먼저 프롬프트로 가능성을 확인한다. 그다음 외부 지식을 붙여 정확도를 높인다. 그래도 형식, 일관성, 전문 용어 처리에서 흔들리면 파인튜닝을 검토한다. 처음부터 가장 비싼 길로 가지 않는 것이 보통 더 현명하다.
임베딩과 벡터 검색은 의미로 찾는 방법이다
LLM 시대를 이해하려면 임베딩을 다시 한 번 서비스 관점에서 봐야 한다. 임베딩은 텍스트를 숫자 벡터로 바꾸는 표현이다. 중요한 점은 이 숫자가 단순한 암호표가 아니라 의미를 어느 정도 보존한다는 데 있다. 뜻이 비슷한 문장끼리는 벡터 공간에서도 가까워진다.
예를 들어 사용자가 "주문을 취소하고 싶어요"라고 말했는데 문서에는 "결제 후 환불 요청 절차"라고 적혀 있다고 해 보자. 키워드만 보면 완전히 같은 말은 아니다. 하지만 임베딩 기반 검색은 둘이 비슷한 의미권에 있다는 것을 잡아낼 수 있다. 그래서 정확히 같은 단어가 없더라도 관련 문서를 찾아낼 가능성이 높다.
이 때문에 임베딩과 벡터 검색은 검색, 추천, 중복 문서 탐지, 유사 FAQ 찾기, RAG의 검색 단계에서 핵심 부품이 된다. 다만 여기서도 마법처럼 생각하면 곤란하다. 성능은 임베딩 모델 품질 하나로 끝나지 않는다. 문서를 어떻게 잘게 나눴는지, 어떤 메타데이터를 붙였는지, 얼마나 넓은 범위를 검색하는지, 검색 결과를 다시 정렬하는지에 따라 체감 품질이 크게 달라진다.4
또 하나 기억할 점이 있다. 의미 기반 검색이 강하다고 해서 언제나 키워드 검색보다 낫지는 않다. 제품 코드, 계약 조항 번호, 버전명, 에러 코드처럼 정확히 일치해야 하는 정보는 키워드 검색이 더 강할 수 있다. 그래서 실무에서는 임베딩 기반의 밀집 검색과 BM25 같은 희소 검색을 함께 쓰는 하이브리드 방식이 자주 쓰인다.5
즉, 임베딩은 검색을 더 똑똑하게 만들어 주지만, 검색 설계를 대신해 주지는 않는다. 좋은 검색은 좋은 표현과 좋은 인덱스, 그리고 좋은 범위 제한이 함께 만들어 낸다.
RAG는 모델에게 기억을 심는 일이 아니라, 열린 책 시험을 설계하는 일이다
RAG는 Retrieval-Augmented Generation, 즉 검색 증강 생성이다. 이름은 어려워 보여도 발상은 꽤 상식적이다. 모델이 모든 지식을 머릿속에 완벽하게 저장해 두길 기대하지 말고, 답변할 때 필요한 자료를 바깥에서 찾아 읽게 하자는 것이다.
구조를 보면 더 분명하다. 먼저 문서를 수집하고 정리한다. 그 문서를 적당한 길이의 청크로 나눈다. 각 청크를 임베딩으로 바꾸어 벡터 저장소에 넣는다. 사용자가 질문하면 그 질문도 임베딩으로 바꿔 비슷한 청크를 찾는다. 그리고 검색된 문맥을 질문과 함께 LLM에 넘겨 답변을 생성한다.4
이 설계의 장점은 명확하다. 최신 정보, 사내 문서, 자주 바뀌는 정책, 공개되지 않은 지식을 모델 재학습 없이 활용할 수 있다. 게다가 어떤 문서를 근거로 답했는지 출처를 함께 보여 주기도 쉽다. 그래서 RAG는 기업용 지식 검색, 내부 문서 도우미, 고객지원 챗봇, 개발 문서 검색 같은 기능에서 특히 강력하다.
하지만 RAG도 오해가 많다. 많은 사람이 "좋은 LLM 하나 붙이고 문서만 넣으면 끝"이라고 생각한다. 실제로는 그 반대다. RAG 품질은 모델 자체보다 문서 품질, 청크 설계, 검색 정확도, 컨텍스트 구성, 재정렬 방식, 프롬프트, 실패 시 대응 정책에 크게 좌우된다. 문서가 오래됐으면 답도 오래된다. 검색이 엉뚱하면 생성도 엉뚱해진다. 관련 문서를 너무 많이 넣으면 오히려 핵심이 묻힌다.
그래서 좋은 RAG는 문서를 많이 넣는 시스템이 아니라, 필요한 문서를 정확히 꺼내고, 필요한 만큼만 보여 주고, 불확실할 때는 모른다고 말할 수 있는 시스템이다. 예를 들어 사내 정책 챗봇이 질문과 관련된 문서를 충분히 찾지 못했다면, 그럴듯한 추측을 늘어놓는 것보다 "현재 근거 문서를 찾지 못했습니다. 담당 부서 문서를 확인해 주세요"라고 답하는 편이 훨씬 낫다. 이것이 바로 fallback 정책이다.
긴 컨텍스트 창이 커지면 RAG가 필요 없을 것처럼 들릴 때도 있다. 하지만 현실은 그렇게 단순하지 않다. 문서를 한꺼번에 많이 넣는다고 해서 모델이 중요한 부분만 정확히 골라 읽는 것은 아니다. 최근 벤치마크들도 잘 설계된 RAG가 긴 컨텍스트 접근보다 정확도 면에서 여전히 강한 경우가 많고, 청크 크기 같은 검색 설계가 성능을 크게 흔든다는 점을 보여 준다.6
결국 RAG는 모델 성능의 문제가 아니라 시스템 설계의 문제다. 검색이 약하면 생성도 약하다. 이 말은 LLM 시대가 오히려 정보검색과 전통적 머신러닝 감각을 다시 불러왔다는 뜻이기도 하다.
LLM 기능도 결국 평가와 운영으로 완성된다
LLM 데모는 쉽게 멋져 보인다. 한두 번 질문했을 때 문장이 자연스럽게 나오면 금방 감탄하게 된다. 하지만 제품은 감탄으로 운영되지 않는다. 실제 서비스에 넣는 순간, 우리는 훨씬 더 많은 질문을 해야 한다. 이 답은 사실에 맞는가. 사용자의 질문과 정말 관련이 있는가. 같은 질문에 매번 비슷한 품질을 내는가. 위험한 표현이나 유해한 내용을 내놓지 않는가. 너무 느리진 않은가. 비용은 감당 가능한가.
전통적 머신러닝에서는 정확도, 정밀도, 재현율, AUC 같은 지표가 중심이었다. LLM 기능에서는 이런 지표 감각이 사라지는 것이 아니라 더 넓어진다. 사실성, 관련성, 일관성, 안전성, 응답 시간, 토큰 비용까지 함께 관리해야 한다. 여기에 RAG가 있다면 검색 품질과 생성 품질을 따로 봐야 한다. 검색은 맞는 문서를 찾았는지, 생성은 그 문서를 근거로 답했는지를 구분해서 평가해야 하기 때문이다.
운영 단계에서는 로그가 교과서보다 중요해진다. 사용자가 어떤 질문에서 다시 물었는지, 어떤 답변에서 이탈했는지, 어떤 검색 결과가 자주 클릭되는지, 어떤 문서가 오래되어 오류를 만드는지 살펴봐야 한다. 잘 만든 LLM 시스템은 한 번 배포하고 끝나는 제품이 아니라, 피드백을 먹고 자라는 시스템이다.
이때 중요한 감각이 하나 있다. LLM 시스템의 실패는 종종 모델 자체보다 주변 설계에서 나온다. 질문 분류가 잘못되었거나, 검색 범위가 과하게 넓거나, 컨텍스트에 충돌하는 문서가 섞여 있거나, 응답 형식 제약이 부족하거나, 안전 필터가 허술할 수 있다. 그래서 개선도 모델 교체만으로 해결되지 않는다. 문제를 쪼개서 어디에서 실패하는지 보는 전통적인 오류 분석이 여전히 필요하다.
그래서 기본기가 더 중요해진다
LLM이 등장한 뒤에도 사라지지 않은 것이 있다. 문제 정의, 데이터 품질, 평가 기준, 배포 후 모니터링이다. 오히려 이 네 가지는 더 중요해졌다. 예전에는 모델 하나의 예측을 잘 맞히면 됐다면, 이제는 검색기와 생성기와 프롬프트와 정책이 함께 움직이는 시스템 전체를 설계해야 하기 때문이다.
예를 들어 고객센터 자동화 기능을 만든다고 해 보자. 어떤 질문까지 자동 응답할지, 어떤 질문은 사람에게 넘길지, 어떤 문서를 정답 근거로 삼을지, 잘못 답했을 때 비용이 얼마나 큰지 먼저 정해야 한다. 이 과정은 전형적인 머신러닝 문제 정의와 다르지 않다. 다만 출력이 문장으로 바뀌었을 뿐이다.
이 장의 핵심은 간단하다. LLM은 머신러닝의 시대를 끝낸 기술이 아니라, 머신러닝을 더 넓고 복잡한 제품 설계로 밀어 올린 기술이다. 그래서 생성형 AI 시대에도 기본기를 건너뛸 수 없다. 데이터를 읽는 눈, 평가 지표를 고르는 감각, 실패를 분석하는 습관, 운영 비용을 계산하는 현실감이 있어야 LLM도 제대로 쓸 수 있다.
멋진 답변을 하는 모델보다 더 중요한 것은, 필요한 순간에 믿을 만한 답을 내고, 틀릴 때는 안전하게 틀리며, 계속 개선될 수 있는 시스템이다. 바로 그 지점에서 전통적 머신러닝과 LLM은 다시 만난다.
다음 장에서는 이 관점을 실제 프로젝트 설계로 끌고 가 보자. 문제 정의 문서부터 데이터 수집 계획, 베이스라인 모델, 실험 로그, 개선 루프까지, 모델을 제품으로 만드는 실전의 흐름을 구체적으로 살펴본다.
참고
1Google 머신러닝 단기집중과정의 대규모 언어 모델 소개
2ML vs LLM: Key Differences, Applications & Engineering Impact
3LLM vs Traditional Machine Learning: Understanding the Key Differences
4Build an End-to-End RAG Pipeline for LLM Applications
5Vector Databases and RAG Systems — Building Intelligent LLM Applications
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.