딥러닝, 임베딩, Transformer 찍먹하기

딥러닝과 임베딩, 그리고 아직 헷갈리는 것들

이번 주에 딥러닝과 임베딩도 살짝 다뤘습니다.

• 전통적 딥러닝: 고차원의 벡터 데이터를 점점 작은 차원으로 줄여서, 그 특징을 기반으로 압축해 데이터를 추출해낼 수 있게 해주는 방식. (높은 차원에서 점을 따다다닥 찍고, 모델이 거기서 정보를 뽑아내는 느낌.)
• 임베딩: 데이터를 벡터로 입력해주는 과정. LLM의 토큰과도 연관이 있음.
• Transformer: 이걸 이해하려면 임베딩을 먼저 알아야 한다고 하는데, 솔직히 아직 잘 모르겠습니다.

딥러닝과 임베딩, 그리고 헷갈렸던 것들 (찾아보고 정리함)

이번 주에 딥러닝과 임베딩도 살짝 다뤘는데, 여기서부터 "전체 흐름이 너무 어렵다, 이게 Tool이랑 무슨 연관인지 모르겠다, LLM이 모델이긴 한 건가?" 하면서 근본부터 헷갈리기 시작했습니다. 수업 시간엔 이해 못 하고 넘어갔는데, 며칠 지나서 다시 찾아보니까 생각보다 하나로 쭉 이어지는 얘기더라고요. 정리해봅니다.

임베딩, 다시 보니

일단 임베딩부터. 몰랐는데 찾아보니까 임베딩은 결국 "AI가 이해할 수 있는 숫자로 바꿔주는 번역 작업"이더라고요. AI 모델은 결국 숫자(행렬 연산) 밖에 못 다루는데, 우리가 주는 건 "미팅", "철수" 같은 텍스트잖아요. 그래서 이 텍스트를 의미를 반영한 숫자 배열(벡터)로 바꿔주는 과정이 임베딩입니다.

여기서 핵심은 "그냥 아무렇게나 숫자로 바꾸는 게" 아니라, 의미가 비슷한 단어는 벡터 공간에서도 가까운 위치에 놓이도록 바꾼다는 점이었습니다. 예를 들면 "강아지"랑 "고양이"의 벡터는 서로 가깝고, "강아지"랑 "자동차"의 벡터는 멀리 떨어지는 식이죠. 메모에 적어뒀던 "전통적 딥러닝은 고차원 벡터를 점점 작은 차원으로 줄여서 특징을 뽑아낸다"는 것도 결국 같은 맥락 — 데이터를 벡터 공간에 점으로 찍어두고, 그 점들의 위치 관계에서 의미/특징을 뽑아내는 거였습니다.

Transformer, 몰랐는데 찾아보니

Transformer는 임베딩된 벡터들을 가지고 "이 문장에서 어떤 단어가 다른 단어랑 얼마나 관련이 깊은지"를 한꺼번에 계산하는 구조더라고요. 이걸 self-attention이라고 부르는데, 예전 방식(RNN)은 문장을 앞에서부터 순서대로 한 단어씩 읽어야 했다면, Transformer는 문장 전체를 동시에 보면서 "이 단어는 저 단어랑 관련 있네"를 병렬로 계산할 수 있다는 게 특징이었습니다. 그래서 훨씬 빠르고, 문장이 길어져도 앞부분 맥락을 잘 기억하는 거고요.

그리고 지금 우리가 쓰는 GPT 같은 LLM들이 바로 이 Transformer 구조를 아주 크게(레이어를 수십~수백 겹) 쌓아 올린 것이었습니다. "임베딩을 먼저 알아야 Transformer를 이해한다"던 말이 이제 이해가 갑니다 — Transformer는 결국 "임베딩된 벡터들끼리 관계를 계산하는 기계"였던 거죠.

LLM

이것도 찾아보니 의외로 간단했습니다. LLM(Large Language Model) 자체가 "모델"이라는 단어를 이름에 그대로 달고 있는, 진짜 그 모델이었습니다. 정확히는 "Transformer 구조를 아주 크게 쌓고, 어마어마한 양의 텍스트로 '다음에 올 단어 맞히기'를 학습시킨 초거대 신경망 모델"이 LLM이었습니다. 그래서 평소에 "AI", "모델", "LLM"을 막 섞어 썼던 게, 사실 좁혀 말하면 LLM = (보통 Transformer 기반의) 초거대 언어 모델이라고 정리하면 되는 거였습니다.

그럼 Tool은 LLM이랑 무슨 상관인데?

이게 제일 헷갈렸던 부분인데, 찾아보고 나서 "아 이래서 헷갈렸구나" 싶었습니다. LLM이 실제로 할 수 있는 건 딱 하나 — "지금까지 나온 텍스트를 보고, 다음에 나올 텍스트(토큰)를 예측해서 만들어내는 것" 뿐입니다. LLM은 절대로 직접 함수를 실행하거나 진짜 코드를 돌리지 않습니다.

그럼 "Tool을 호출한다"는 건 뭐냐면, LLM이 진짜로 함수를 실행하는 게 아니라:

1. 주변 프로그램(LangChain 같은 프레임워크)이 LLM한테 "너 이런 tool들 쓸 수 있어"라고 설명을 프롬프트에 끼워 넣어줍니다.
2. LLM은 "아, 이 상황엔 이 tool을 부르는 게 좋겠다"고 판단하면, 평범한 문장 대신 정해진 형식의 텍스트(예: {"name": "personal_create_schedule", "arguments": {...}} 같은 것)를 만들어냅니다. 이것도 그냥 "다음 토큰 예측" 결과일 뿐이에요.
3. 주변 프로그램이 이 특수한 형식을 알아채고, 그때서야 실제 파이썬 함수를 대신 실행합니다.
4. 그 실행 결과를 다시 LLM한테 넘겨주면, LLM이 그걸 보고 자연스러운 문장으로 정리해서 답합니다.

즉 "Tool 호출"은 LLM 안에 내장된 기능이 아니라, LLM의 "텍스트 생성" 능력 위에 주변 프로그램이 얹어놓은 하나의 약속(프로토콜)이었습니다. LLM은 여전히 텍스트만 뱉고 있고, 그걸 "함수 호출 신호"로 해석해서 진짜로 실행하는 건 LangChain 같은 프레임워크 쪽 몫이었던 거죠.

이걸 알고 나니 예전에 정리했던 ToolStrategy도 다시 이해가 됐습니다. ToolStrategy(schema=StructuredRequestBatch)도 결국 같은 원리 — AI한테 자유 문장 대신 "이 tool을 부르는 형식으로 답해라"라고 시키고, 그 형식화된 텍스트를 우리 프로그램(LangChain)이 받아서 실제 StructuredRequestBatch 객체로 검증/변환해주는 것. Tool 호출이라는 게 결국 "LLM의 텍스트 생성 + 주변 프로그램의 해석/실행"이 합쳐진 결과라는 걸 몰랐는데 찾아보니 알게 됐습니다.

RAG는 살짝 맛보기만

RAG(Retrieval-Augmented Generation)는 아직 깊게는 못 봤지만, 몰랐는데 찾아보니 임베딩이 여기서도 그대로 쓰이더라고요. 사용자 질문을 임베딩(벡터화)해서, 미리 벡터로 저장해둔 문서들 중 의미가 가장 가까운 것들을 검색해오고, 그 검색된 내용을 LLM 프롬프트에 같이 끼워 넣어서 답을 만드는 방식이었습니다. 즉 "임베딩으로 비슷한 의미를 찾는다"는 개념이 RAG에서도 핵심 도구로 쓰이는 거고, 이건 다음에 더 깊게 파봐야 할 것 같습니다.

정리하면

이번 주는 개념이 꼬리에 꼬리를 물어서 힘들었는데, 결국 이렇게 이어지는 얘기였습니다:

텍스트를 임베딩(벡터)으로 바꾸고 → Transformer가 그 벡터들 사이 관계를 계산해서 → LLM이 다음 텍스트를 예측하고 → 그 예측 결과를 주변 프로그램이 "함수 호출"로 해석하면 그게 Tool 호출이 된다.

다음에 더 봐야 할 것

• RAG를 실제 코드로 한 번 구현해보기
• Transformer의 self-attention 계산을 좀 더 수식으로 이해해보기
• fine-tuning(진짜 파라미터를 바꾸는 학습)은 프롬프팅이랑 실제로 얼마나 다른지 비교해보기