컴퓨터는 '사과'와 '배'가 비슷한 과일이라는 것을 어떻게 알까요? 원-핫 인코딩의 한계부터 Word2Vec, 그리고 현대 AI의 핵심인 트랜스포머(Transformer) 기반 임베딩까지. 텍스트를 숫자로 변환하여 의미를 계산하는 임베딩의 세계와 이를 활용한 RAG(검색 증강 생성) 아키텍처를 다뤄봤습니다.
둘 다 같은 Transformer 자식인데 왜 다를까? '빈칸 채우기'와 '이어 쓰기' 비유로 알아보는 BERT와 GPT의 결정적 차이. 프로젝트에서 겪은 시행착오와 선택 가이드.
ChatGPT는 질문에 답하지만, AI Agent는 스스로 계획하고 도구를 사용해 작업을 완료한다. 이 차이가 왜 중요한지 정리했다.
세 가지 AI 코딩 도구를 실제로 써보고 비교했다. 자동완성, 코드 생성, 리팩토링 각각 어디가 강한지 솔직한 후기.
고객 상담 챗봇이 엉뚱한 대답을 해서 식은땀 흘린 경험, 그리고 RAG(검색 증강 생성)를 도입해 '오픈북 테스트'를 치르게 한 과정을 공유합니다. 벡터 DB, 임베딩, 그리고 하이브리드 검색까지 파헤쳐봅니다.
우리는 "사과"라고 하면 빨갛고 맛있는 과일을 떠올립니다. 하지만 컴퓨터에게 "사과"는 그저 01010011... 같은 이진수 덩어리일 뿐입니다.
컴퓨터가 언어를 이해하게 하려면, 먼저 인간의 언어를 숫자(벡터)로 바꿔줘야 합니다.
초기에는 아주 단순한 방법을 썼습니다. 원-핫 인코딩(One-Hot Encoding)입니다. 세상에 단어가 3개만 있다고 칩시다: [사과, 배, 자동차]
[1, 0, 0][0, 1, 0][0, 0, 1]이 방법 치명적인 문제가 있습니다.
루트 2) 컴퓨터는 "사과가 배랑 비슷한지, 자동차랑 비슷한지" 알 방법이 없습니다.이 문제를 해결하기 위해 등장한 것이 바로 밀집 벡터(Dense Vector), 즉 임베딩(Embedding)입니다.
임베딩 기술은 하루아침에 만들어진 것이 아닙니다. NLP(자연어 처리)의 발전사와 궤를 같이합니다.
딥러닝 이전에는 단순히 단어의 빈도수를 셌습니다. TF-IDF (Term Frequency - Inverse Document Frequency)가 대표적입니다. "어떤 문서에서 특정 단어가 얼마나 자주 나오나?"를 따집니다. 하지만 여전히 단어의 '순서'나 '문맥'은 무시했습니다.
구글이 Word2Vec을 발표하면서 세상이 뒤집혔습니다. "비슷한 문맥에 등장하는 단어는 의미도 비슷하다"는 분포 가설(Distributional Hypothesis)을 증명했습니다. '사과' 주변에는 '맛있다', '먹다', '과일' 같은 단어가 자주 나옵니다. '배' 주변에도 '맛있다', '먹다', '과일'이 자주 나오죠. 신경망은 이를 학습하여 "아, '사과'와 '배'는 비슷한 벡터 좌표를 가져야겠구나!"라고 판단합니다.
Word2Vec의 한계는 동음이의어를 구별 못 한다는 겁니다.
"배를 먹었다"의 배(Fruit)와 "배를 탔다"의 배(Ship)를 똑같은 벡터 [0.7, 0.3, -0.4]로 처리합니다.
2018년, BERT의 등장으로 판이 바뀝니다.
이제는 단어 하나가 고정된 벡터를 갖는 게 아니라, 문맥(Context)에 따라 임베딩이 달라집니다. 이를 Contextual Embedding이라고 합니다.
임베딩의 가장 유명한 예시가 바로 연산 가능성입니다.
왕(King) - 남자(Man) + 여자(Woman) = ?
이 벡터 연산을 수행하면 놀랍게도 여왕(Queen)에 가장 가까운 벡터가 나옵니다.
단어의 의미가 벡터 공간(Vector Space) 상의 위치와 방향으로 매핑된 것입니다.
이제 단어는 수만 차원의 0과 1이 아니라, 실수로 가득 찬 좁은 차원의 벡터가 됩니다.
[0.8, 0.2, -0.5][0.7, 0.3, -0.4] (사과랑 비슷함)[-0.1, 0.9, 0.8] (사과랑 전혀 다름)임베딩이 중요해지면서, 이 벡터들을 전문적으로 저장하고 검색하는 벡터 데이터베이스(Vector Database)가 떴습니다. Pinecone, Milvus, Weaviate, 그리고 Elasticsearch의 벡터 검색 기능 등이 대표적입니다.
기존 DB(MySQL)는 "name = '홍길동'" 같은 정확한 일치 검색만 잘했습니다. 하지만 벡터 DB는 유사도 검색(Similarity Search)을 합니다. "빨간색 과일"이라는 질의를 벡터로 바꿔서 던지면, DB는 그 벡터와 거리가 가까운 데이터를 찾아줍니다. '사과', '체리', '딸기' 같은 것들이 나오겠죠.
이것이 바로 요즘 AI 업계의 핫한 키워드인 RAG (Retrieval-Augmented Generation, 검색 증강 생성)의 핵심입니다. LLM은 2023년까지의 데이터만 학습해서 최신 뉴스를 모릅니다. 우리가 최신 뉴스 기사를 임베딩해서 벡터 DB에 넣어둡니다. 사용자가 "어제 삼성전자 주가 어때?"라고 물으면,
임베딩의 차원은 높을수록 표현력이 좋아집니다. OpenAI의 text-embedding-3-large 모델은 3072차원이나 됩니다.
하지만 차원이 너무 높으면 차원의 저주(Curse of Dimensionality)에 빠집니다. 데이터 간의 거리가 멀어지고, 계산량이 폭증하며, 과적합(Overfitting) 위험이 커집니다.
그래서 학습은 고차원에서 하되, 시각화나 분석을 할 때는 t-SNE나 UMAP 같은 알고리즘을 써서 2차원이나 3차원으로 차원 축소(Dimensionality Reduction)를 합니다. 우리가 눈으로 보고 이해할 수 있게 만드는 거죠.
임베딩은 AI가 세상을 이해하는 눈입니다. 텍스트뿐만 아니라 이미지, 오디오, 비디오까지 모든 것을 벡터로 바꿀 수 있습니다(Multimodal Embedding). 모든 데이터가 같은 벡터 공간에 존재하게 되면, "개가 공을 잡는 사진"을 검색할 때 텍스트로 "Dog catching ball"이라고 쳐도 찾아낼 수 있습니다. 텍스트 벡터와 이미지 벡터가 서로 가까운 곳에 위치하기 때문입니다.
Q: Word2Vec과 BERT의 결정적인 차이는 무엇인가요? A: 문맥(Context)의 반영 여부입니다. Word2Vec은 '배'라는 단어를 언제나 같은 벡터로 봅니다. 반면 BERT는 "배를 먹다"와 "배를 타다"를 문맥을 보고 구분하여 서로 다른 벡터를 생성합니다. 그래서 BERT가 훨씬 정확도가 높습니다.
Q: RAG를 구축하려면 꼭 유료 벡터 DB를 써야 하나요?
A: 아닙니다. 초기에는 Facebook이 만든 오픈소스 라이브러리인 Faiss를 사용해서 로컬 메모리 상에서 검색을 구현할 수 있습니다. 또는 PostgreSQL의 pgvector 확장을 사용하면 기존 RDBMS에서도 벡터 검색이 가능합니다. 규모가 커질 때 Pinecone 같은 관리형 서비스를 고려하세요.
Q: 임베딩 모델은 반드시 파인 튜닝(Fine-tuning)해야 하나요? A: 대부분의 경우 아닙니다. OpenAI나 Hugging Face의 최신 사전 학습(Pre-trained) 모델들은 이미 범용적인 성능이 뛰어납니다. 특수 분야(예: 법률, 의료) 용어가 너무 많을 때만 파인 튜닝을 고려하세요. 보통은 RAG를 통해 지식을 주입하는 것만으로 충분합니다.