삽질 테크 블로그

Appearance

LLM의 작동 원리부터 RAG까지, 처음 만나는 AI 기초 ​

솔직히 나도 처음에 LLM이라는 단어를 들었을 때 "그냥 엄청 큰 AI 모델인가 보다" 정도로 넘겼다. ChatGPT가 등장하고 나서야 "이게 대체 어떻게 이렇게 말을 잘 하지?"라는 궁금증이 생겼고, 그 궁금증을 따라가다 보니 Transformer니 어텐션이니 하는 개념들을 만나게 됐다. 이 글은 그 과정에서 정리한 것들이다. LLM이 뭔지, 어떻게 돌아가는지, 그리고 왜 RAG라는 게 필요한지까지 한 흐름으로 다뤄보려 한다.

모든 걸 깊이 있게 파고들 수는 없다. 그보다는 "아, 이게 이런 구조였구나" 하는 큰 그림을 잡는 데 초점을 뒀다.

LLM, 대체 뭔가 ​

LLM은 Large Language Model의 약자다. 말 그대로 "거대 언어 모델"인데, 여기서 중요한 건 "거대"라는 부분이 아니라 **"언어 모델"**이라는 부분이다. 언어 모델이란 결국 "다음에 올 단어가 뭘까?"를 예측하는 확률 모델이다. "오늘 날씨가" 다음에 "좋다"가 올 확률이 높고, "코끼리"가 올 확률은 낮다 — 이 정도의 직관으로 시작하면 된다.

그런데 이 단순한 원리를 수천억 개의 파라미터와 인터넷 전체에 가까운 텍스트 데이터로 스케일업하면 신기한 일이 벌어진다. 번역을 하고, 코드를 짜고, 논리적인 추론도 한다. GPT-4, Claude, Gemini, LLaMA 같은 모델들이 전부 이 "다음 토큰 예측"이라는 같은 원리 위에 서 있다는 게 아직도 좀 놀랍다.

Transformer와 어텐션 메커니즘 ​

LLM의 핵심 아키텍처는 Transformer다. 2017년 구글 연구팀이 "Attention Is All You Need"라는 논문에서 발표한 건데, 이름이 참 자신감 넘친다. 근데 실제로 그 자신감이 맞았다.

Transformer 이전에는 RNN(순환 신경망)이나 LSTM 같은 구조가 주류였다. 이 모델들은 텍스트를 앞에서부터 한 단어씩 순서대로 처리한다. 문제가 뭐냐면, 문장이 길어지면 앞쪽 정보가 점점 희미해진다. "서울에서 태어난 민수는 어렸을 때 부산으로 이사했고, 대학은 대전에서 다녔는데, 지금 사는 곳은..."에서 "서울"이라는 정보가 끝까지 유지되기 어려운 거다.

Transformer는 이 문제를 셀프 어텐션(Self-Attention)이라는 메커니즘으로 해결한다. 핵심 아이디어는 간단하다. 문장의 모든 단어가 다른 모든 단어를 동시에 참고할 수 있게 하는 것이다. "민수가 지금 사는 곳"이라는 부분을 처리할 때, 모델이 "서울"이나 "부산" 같은 앞쪽 단어에 직접 주의(attention)를 기울일 수 있다. 순서대로 읽어 나가는 게 아니라, 필요한 정보가 있는 곳을 직접 바라보는 셈이다.

멀티헤드 어텐션(Multi-Head Attention)은 이 과정을 여러 "관점"에서 동시에 수행한다. 어떤 헤드는 문법적 관계를 보고, 다른 헤드는 의미적 관계를 보고, 또 다른 헤드는 문장의 먼 곳에 있는 맥락을 추적한다. 마치 한 문장을 여러 명이 각자 다른 시각으로 동시에 읽는 느낌이라고 생각하면 된다.

또 한 가지 큰 장점은 병렬 처리다. RNN은 한 단어씩 순서대로 처리해야 하지만, Transformer는 모든 단어를 동시에 처리할 수 있다. 이 덕분에 GPU를 최대한 활용할 수 있고, 학습 속도가 비약적으로 빨라졌다. 결과적으로 더 큰 데이터셋, 더 큰 모델이 가능해졌고, 지금의 LLM 시대를 열게 된 거다.

LLM이 보여주는 신기한 특징들 ​

LLM에는 전통적인 머신러닝과 꽤 다른 특성들이 있다. 내가 특히 흥미롭게 느낀 것 몇 가지를 꼽아본다.

인컨텍스트 학습과 퓨샷 러닝 ​

보통 머신러닝 모델을 새로운 작업에 쓰려면 데이터를 모으고, 학습시키고, 평가하는 과정을 거쳐야 한다. LLM은 그냥 프롬프트에 예시 몇 개를 넣어주면 된다. 이걸 퓨샷 러닝(few-shot learning)이라고 하는데, 정확히는 모델의 파라미터를 건드리지 않고 프롬프트 안의 맥락만으로 새로운 패턴을 학습하는 인컨텍스트 학습(in-context learning)의 한 형태다.

예를 들어 "좋아요 → 긍정 / 별로예요 → 부정 / 이건 어때요 → ?"처럼 예시 두 개만 보여주면 모델이 감성 분류를 해낸다. 모델을 재학습시킨 게 아니라, 프롬프트 안에서 패턴을 파악한 것이다. 이게 가능한 이유가 아직 완전히 설명되지 않았다는 게 좀 묘한 부분이다.

창발적 능력 ​

모델의 크기가 일정 규모를 넘어서면 갑자기 새로운 능력이 나타나는 현상이 있다. 이걸 창발적 능력(emergent abilities)이라고 부른다. 소규모 모델에서는 전혀 못 하던 수학 문제 풀기나 복잡한 추론을 대규모 모델에서는 갑자기 해내는 식이다.

정확히는 모르겠지만, 이 현상이 정말 "갑자기" 일어나는지에 대해서는 학계에서도 논쟁이 있다. 측정 지표에 따라 점진적으로 개선되는 것처럼 보일 수도 있다는 연구도 있고. 어쨌든 규모가 커질수록 예상 못 한 능력이 발현된다는 사실 자체는 꽤 인상적이다.

범용성 ​

하나의 모델로 번역, 요약, 코드 생성, 질의응답, 창작 글쓰기까지 처리할 수 있다. 예전에는 각 작업마다 별도의 모델을 만들었는데, LLM은 프롬프트만 바꾸면 같은 모델이 완전히 다른 일을 한다. 이건 솔직히 처음 경험했을 때 충격이었다.

실제로 어디서 쓰고 있나 ​

이론은 그렇고, 실무에서는 어떻게 쓰이고 있을까.

고객 응대 자동화가 가장 빠르게 퍼지고 있는 영역 중 하나다. KB국민카드 같은 곳에서는 LLM 기반 챗봇이 이벤트 정보를 실시간으로 조회해서 답변을 생성하고, VOC(고객 의견) 데이터를 자동 분류하는 데도 쓴다. gpt-4o-mini 같은 경량 모델을 쓰면 gpt-4o 대비 16배 이상 비용을 절감하면서도 실용적인 수준의 분류 정확도를 얻을 수 있다고 한다.

코드 생성과 개발 보조도 빠르게 확산되고 있다. GitHub Copilot, Cursor, Claude Code 같은 도구들이 대표적인데, 코드 작성 자동화, 리뷰 효율화, 테스트 생성 같은 영역에서 개발 생산성을 끌어올리고 있다. 개인적으로도 이 글을 쓰는 데 AI 도구의 도움을 받고 있으니, 이건 뭐 직접 체험하고 있는 셈이다.

그 밖에도 제조업의 품질관리 데이터 조회, 금융업의 규제 준수 지원, 건설업의 시공 매뉴얼 검색 등 산업 전반으로 퍼지고 있다. 다만 기업 입장에서 데이터 유출이나 보안 문제가 커서, 온프레미스로 자체 LLM을 구축하려는 움직임도 커지고 있다. 이건 좀 의견이 갈릴 수 있는데, 클라우드 API가 편하긴 하지만 민감한 데이터를 외부로 보내는 게 꺼려지는 조직은 분명 있다.

그런데 왜 RAG가 필요할까 ​

LLM이 이렇게 똑똑한데 왜 추가적인 장치가 필요한 걸까. 핵심은 두 가지 문제다.

첫째, 지식 컷오프. LLM은 학습 시점까지의 데이터만 알고 있다. "2026년 1월에 발표된 정책이 뭐야?"라고 물어도, 모델의 학습 데이터에 포함되어 있지 않으면 대답할 수 없다. 아니, 더 정확히 말하면 대답할 수 없는 게 아니라 — 그럴듯하게 지어내서 대답한다. 이게 두 번째 문제인 할루시네이션(hallucination)이다.

할루시네이션은 모델이 사실이 아닌 내용을 마치 사실인 것처럼 자신있게 생성하는 현상이다. "존재하지 않는 논문을 인용"하거나 "없는 법률 조항을 언급"하는 식의 사례가 꽤 보고되어 있다. 언어 모델의 본질이 "그럴듯한 다음 토큰 예측"이니까 어찌 보면 당연한 건데, 실무에서는 치명적일 수 있다.

RAG(Retrieval-Augmented Generation)는 이 문제를 "외부 지식을 검색해서 가져다 주자"는 접근으로 해결한다.

RAG는 어떻게 동작하나 ​

RAG의 전체 흐름을 단순화하면 이렇다.

  1. 사용자가 질문을 한다
  2. 질문을 기반으로 외부 지식 저장소(보통 벡터 DB)에서 관련 문서를 **검색(Retrieval)**한다
  3. 검색된 문서를 LLM의 프롬프트에 함께 넣어서 답변을 **생성(Generation)**한다

이름 그대로 "검색으로 보강된 생성"이다. LLM 혼자 기억에 의존하는 대신, 필요한 정보를 먼저 찾아서 참고 자료와 함께 답변하게 만드는 구조다.

좀 더 구체적으로 보면 이런 과정이 있다. 먼저 문서를 적절한 크기로 나누고(청킹), 각 조각을 임베딩 모델로 벡터화해서 벡터 DB에 저장해둔다. 사용자 질문이 들어오면 같은 임베딩 모델로 질문도 벡터화하고, 벡터 DB에서 유사한 문서 조각을 찾아온다. 그리고 이 문서 조각들을 "이 내용을 참고해서 답변해줘"라는 프롬프트와 함께 LLM에 넘긴다.

2025년 기준으로 고급 RAG 기법들도 많이 나왔다. 지식 그래프와 결합한 KG-RAG가 바이오메디컬 QA에서 할루시네이션을 18% 줄였다는 연구도 있고, Self-reflective RAG 같은 기법은 할루시네이션 비율을 5.8%까지 낮추었다는 보고도 있다. 하지만 RAG가 할루시네이션을 완전히 없애주는 건 아니다. 검색된 문서가 부정확하거나 불충분하면 여전히 문제가 생길 수 있다.

RAG의 핵심은 "검색 품질"

RAG를 도입한다고 자동으로 답변이 좋아지는 게 아니다. 검색 단계에서 관련 문서를 얼마나 잘 찾아오느냐가 전체 파이프라인의 성능을 좌우한다. 임베딩 모델 선택, 청킹 전략, 하이브리드 검색 구성 같은 디테일이 결국 결과를 결정한다.

LangChain으로 RAG를 구축하면 뭐가 좋은가 ​

RAG 파이프라인을 처음부터 직접 만들 수도 있다. 임베딩 API 호출하고, 벡터 DB 연결하고, 프롬프트 조립하고, LLM 호출하고... 한번 해보면 알겠지만 생각보다 코드가 지저분해지고, 컴포넌트를 바꿀 때마다 이곳저곳을 수정해야 한다.

LangChain은 이 과정을 훨씬 깔끔하게 만들어주는 프레임워크다.

가장 큰 장점은 컴포넌트 추상화다. 임베딩 모델을 OpenAI에서 Cohere로 바꾸고 싶다면 코드 한 줄만 바꾸면 된다. 벡터 DB를 Chroma에서 Pinecone으로 바꿔도 마찬가지다. 나머지 파이프라인 코드는 건드릴 필요가 없다. 프로토타이핑 속도가 확 빨라지는 지점이 여기다.

문서 로더와 텍스트 스플리터가 기본 내장되어 있다는 것도 편하다. PDF, 웹페이지, CSV, 노션 등 다양한 소스에서 문서를 읽어오는 로더가 이미 만들어져 있고, 청킹 전략도 RecursiveCharacterTextSplitter 같은 것들이 준비되어 있다. 이런 것들을 직접 구현하면 시간이 꽤 든다.

그리고 LangSmith라는 디버깅/모니터링 도구와 통합되어 있다. RAG 파이프라인에서 문제가 생겼을 때 "검색은 잘 됐는데 생성이 이상한 건지, 아니면 검색 자체가 잘못된 건지"를 추적하기가 수월하다. 프로덕션에서 운영할 때 이게 없으면 디버깅이 상당히 고통스럽다.

물론 단점도 있다. LangChain은 프레임워크 오버헤드가 있어서 직접 구현 대비 약간의 레이턴시가 추가된다. 토큰 사용량도 약간 더 많을 수 있다. 그리고 추상화 레이어가 두꺼워서 내부에서 무슨 일이 벌어지는지 파악하기 어려울 때가 있다. 내 경험상, 학습 목적이라면 한 번쯤은 LangChain 없이 직접 만들어보는 것도 도움이 된다. 그래야 LangChain이 어떤 부분을 편하게 해주는지 체감할 수 있다.

LangGraph는 LangChain 위에 얹어서 복잡한 에이전트 워크플로우를 관리할 수 있게 해주는 도구인데, 이건 다음 글에서 다루는 게 나을 것 같다.

정리하면서 ​

LLM은 Transformer 아키텍처 위에서 "다음 토큰 예측"이라는 단순한 원리로 작동하지만, 규모의 힘으로 놀라운 능력을 보여준다. 하지만 학습 데이터 이후의 정보는 모르고, 모르는 것도 아는 척 대답하는 할루시네이션 문제가 있다. RAG는 외부 지식을 검색해서 LLM에 먹여주는 방식으로 이 한계를 보완한다. LangChain은 이 과정을 구조화하고, 컴포넌트를 쉽게 교체하고, 빠르게 프로토타이핑할 수 있게 도와주는 프레임워크다.

솔직히 이 글에서 다루지 못한 것들이 많다. 토크나이저가 어떻게 동작하는지, 파인튜닝과 RLHF는 뭔지, 벡터 검색의 구체적인 메커니즘은 어떤 건지 — 이런 것들은 각각이 하나의 글감이다. 이 시리즈의 다음 글들에서 하나씩 풀어볼 생각이다.

아직 이 분야는 몇 달 단위로 판이 바뀌고 있어서, 지금 쓰는 내용도 금방 업데이트가 필요해질 수 있다. 그래도 큰 틀은 변하지 않을 거라고 본다. Transformer, 어텐션, 검색 보강 생성 — 이 세 가지 개념은 당분간 AI를 이해하는 데 있어 기본 어휘로 남아 있을 것이다.

참고 자료

삽질 테크 블로그

© 2026 Shoney. All rights reserved.