대부분의 사람들은 LLM에 프롬프트를 입력할 수 있습니다. 하지만 실제 트래픽을 견뎌내는 제품에 이를 통합하는 것은 완전히 다른 차원의 문제입니다. 채팅창에 글을 쓰는 수준을 넘어 실제 프로덕션 단계의 AI를 출시하고 싶다면, 기술 스택이 실제로 어떻게 맞물려 돌아가는지 이해해야 합니다. 이것은 마법이 아닙니다. 개별적인 엔지니어링 문제들이 연결된 파이프라인이며, 각 레이어마다 고유한 실패 모드가 존재합니다.
사용자가 단어를 입력하는 순간부터 에이전트가 작업을 완료하는 순간까지, 현대적인 AI 시스템이 어떻게 작동하는지 살펴보겠습니다.
기초: 모델이 생각하는 방식
핵심적으로, 거대 언어 모델(LLM)은 정확히 한 가지 일만 수행합니다. 바로 다음 토큰을 예측하는 것입니다. 그 토큰은 다음 단어일 수도, 단어의 일부일 수도, 혹은 기호일 수도 있습니다. 시, 코드, 추론 등 그 외의 모든 것은 이 단일 작업을 대규모로 수행하면서 나타나는 창발적 행동입니다.
프롬프트에서 모델의 응답에 이르는 과정은 다음과 같습니다.
**토큰화(Tokenization)**가 첫 번째 단계입니다. 신경망에게 가공되지 않은 텍스트는 아무런 의미가 없으므로, 모델은 단어를 조각으로 나누고 각 조각을 숫자로 매핑합니다. "tokenization"이라는 단어는 세 개의 별도 토큰이 될 수 있습니다. "New York"이라는 문구는 어휘 사전에 따라 하나 또는 두 개의 토큰이 될 수 있습니다. 이 숫자들은 임의적인 것이 아니라, 모델이 학습 과정에서 익힌 고정된 사전을 바탕으로 합니다.
단어가 숫자로 변환되면, 이제 의미를 부여해야 합니다. **임베딩(Embeddings)**은 이러한 숫자를 벡터로 변환합니다. 벡터는 수학적 공간에서 유사한 개념을 가깝게 배치하는 긴 부동 소수점 값의 목록입니다. "King"과 "Queen"은 서로 가까이 위치합니다. "Paris"와 "Berlin"은 서로 클러스터를 형성하지만, "Python"이나 "JavaScript"와는 다른 영역에 위치합니다.
하지만 벡터만으로는 순서를 알 수 없습니다. **위치 인코딩(Positional encoding)**은 문장에서 각 토큰이 어디에 위치하는지 모델에게 알려줍니다. 이것이 없다면 "The dog bit the man"과 "The man bit the dog"은 동일하게 보일 것입니다.
그다음은 **어텐션 메커니즘(Attention mechanism)**입니다. 여기서 모델은 입력된 모든 토큰을 훑어보며 다음 토큰을 예측하는 데 어떤 토큰이 중요한지 결정합니다. 예를 들어 "회사가 언제 설립되었으며, 현재 누가 이끌고 있습니까?"라고 물으면, 모델은 "founded"를 날짜와 연결하고 "leads"를 CEO 이름과 연결해야 합니다. 어텐션이 바로 이러한 연결을 만들어냅니다.
이러한 연산들은 수십 개의 **레이어(Layers)**로 쌓이며, 초기 레이어는 구문을 처리하고 후기 레이어는 추상적인 추론을 구축합니다. 중간 어딘가에 있는 **피드포워드 네트워크(Feed-forward networks)**는 사실적 연관성을 저장합니다. 모델이 파리가 프랑스의 수도라는 사실이나, 특정 API가 JSON 페이로드를 기대한다는 지식을 유지하는 곳이 바로 여기입니다. 정확히 데이터베이스라고 할 수는 없지만, 패턴을 활성화하는 압축된 가중치의 망이라고 할 수 있습니다.
마지막으로, **디코딩(Decoding)**은 내부의 벡터 표현을 다시 사람이 읽을 수 있는 토큰으로 변환합니다. 모델은 자신이 영어를 쓰고 있다는 것을 "아는" 것이 아닙니다. 그저 수천 개의 가능한 다음 토큰들의 순위를 매기고, 중단 조건에 도달할 때까지 가장 확률이 높은 토큰을 반복해서 선택할 뿐입니다.
RAG 레이어: 모델에게 메모리 부여하기
베이스 모델은 특정 시점에 지식이 고정되어 있습니다. 모델의 가중치는 특정 차단 날짜까지의 인터넷 정보를 담고 있으며, 사용자가 직접 제공하지 않는 한 개인 문서를 참조할 수 없습니다. 이 때문에 대부분의 비즈니스 작업에서 베이스 모델만으로는 한계가 있습니다. 검색 증강 생성(Retrieval-Augmented Generation), 즉 RAG는 모델이 답변하기 전에 참고할 수 있는 외부 라이브러리를 제공함으로써 이 문제를 해결합니다.
개념은 간단하지만 실제 구현은 까다롭습니다. 먼저, 문서를 가져와 **청킹(Chunking)**을 적용합니다. 100페이지짜리 PDF를 프롬프트 창에 통째로 집어넣지는 않습니다. 대신 의미를 유지하면서도 모델의 컨텍스트 제한 안에 들어갈 수 있도록 문단, 섹션 또는 의미론적 블록 단위로 나눕니다.
각 청크는 LLM 내부의 토큰과 마찬가지로 임베딩 모델을 거쳐 벡터가 됩니다. 이 벡터들은 정확한 조회가 아닌 유사도 검색에 최적화된 특수 저장소인 **벡터 데이터베이스(Vector database)**에 저장됩니다. 사용자가 질문을 하면, 질문을 임베딩한 후 데이터베이스에 다음과 같이 묻습니다. "이 벡터와 의미상 가장 가까운 청크는 무엇인가?"
단순한 벡터 검색만으로는 정확한 일치를 놓치는 경우가 많습니다. 제대로 된 프로덕션 시스템은 키워드 매칭과 의미론적 유사성을 결합한 **하이브리드 검색(Hybrid search)**을 사용합니다. 누군가 "SLA-99 준수"를 묻는다면, 단순히 느낌이 비슷한 문서가 아니라 해당 문자열이 실제로 포함된 문서를 찾아내야 합니다.
검색 후에는 **리랭킹(Re-ranking)**을 통해 노이즈를 걸러냅니다. 초기 검색 결과로 20개의 청크가 반환될 수 있지만, 실제로 도움이 되는 것은 상위 3~4개뿐일 수 있습니다. 리랭커는 관련성을 점수화하여 LLM에 전달하기 전에 나머지 항목을 버림으로써, 토큰을 절약하고 환각(Hallucination) 현상을 줄입니다.
에이전트 레이어: 행동하기
RAG는 모델이 읽게 하고, 에이전트는 모델이 행동하게 합니다.
에이전트는 근본적으로 루프 안에 있는 LLM입니다. 관찰하고, 추론하고, 행동한 뒤, 다시 관찰합니다. 에이전트에게 항공권 예약을 요청하면, 단순히 예약 과정이 어떻게 되는지 설명하는 데 그치지 않습니다. 작업을 단계별로 나누고, 적절한 함수를 호출하며, 응답을 읽고, 상황을 조정합니다.
루프는 다음과 같습니다. Observe(관찰): 에이전트가 현재 상태(사용자의 요청, 이전 도구 호출 결과, 발생한 오류 등)를 읽습니다. Reason(추론): LLM이 구조화된 계획을 생성하거나 미리 정의된 옵션 중에서 선택하여 다음에 무엇을 할지 결정합니다. Act(행동): 도구를 호출합니다.
도구는 에이전트가 현실 세계와 접촉하는 방식입니다. 도구는 모델에게 API에 필요한 매개변수가 무엇인지 정확히 알려주는 JSON schema로 정의됩니다. LLM은 임의로 HTTP 요청을 생성하지 않습니다. 대신 스키마를 채웁니다. "city: London, units: metric 매개변수로 날씨 API를 호출해줘." 도구가 온도를 반환하면, 에이전트는 이를...