[작성자:] aiknowsai

“커피를 마실 만한 곳”을 찾는데, 자료에는 “동네 카페”라고 적혀 있다면 어떨까요? 표현이 달라도 관련된 내용을 찾도록 돕는 기술이 있습니다. 임베딩은 글 같은 정보를 비교하기 쉬운 숫자 묶음으로 표현하는 방법입니다.

지난 글에서 RAG는 필요한 자료를 찾아 답변에 참고하는 방식이라고 배웠습니다. 이번에는 그 자료를 찾는 데 활용할 수 있는 임베딩을 살펴봅니다.

---

숫자로 만든 위치라고 생각해 보세요

임베딩은 정보를 여러 숫자로 나타냅니다. 이렇게 순서대로 놓인 숫자 묶음을 벡터라고 부릅니다. 숫자들을 좌표처럼 생각하면, 글 하나를 지도 위의 한 점으로 비유할 수 있습니다.

이 지도에서는 모델이 비슷하다고 표현한 내용이 서로 가까이 놓일 수 있습니다. 다만 실제 임베딩은 종이 지도보다 훨씬 많은 숫자를 쓰며, 숫자 하나하나에 사람이 이해하기 쉬운 이름을 붙이기는 어렵습니다. Google의 임베딩 설명도 이 점을 구분합니다.

---

같은 단어가 없어도 후보를 찾을 수 있어요

설명을 위한 가상의 지도에 다음 표현을 놓아 봅시다.

• 카페
• 커피 마실 곳
• 우산

의미의 관련성을 나타내는 지도라면 앞의 두 표현을 가까운 쪽에, 우산을 다른 쪽에 놓는 모습을 떠올릴 수 있습니다. 이 배치는 이해를 돕는 비유이며, 실제 모델로 계산한 결과는 아닙니다.

이처럼 텍스트 임베딩을 활용한 검색은 똑같은 단어를 찾는 데만 의존하지 않고, 질문의 뜻과 관련된 자료를 후보로 찾을 수 있습니다. RAG에서 참고할 문단을 고를 때도 이런 방법을 활용할 수 있습니다. 구체적인 검색 방식은 시스템마다 다릅니다. Google Cloud의 텍스트 임베딩 문서는 이 검색 원리를 설명합니다.

---

가까운 자료도 다시 읽어야 해요

어떤 임베딩을 만들지는 모델과 작업에 따라 달라집니다. 음식의 종류를 구분하는 지도와 아침 메뉴를 추천하는 지도는 서로 다른 관련성을 담을 수 있습니다.

따라서 검색에서 가까운 후보가 나왔다고 해서 그 내용이 사실이거나 지금 내 상황에 맞는다는 결론까지 얻은 것은 아닙니다. 임베딩은 관련 자료를 찾는 단서로 쓰고, 자료의 내용·날짜·조건은 원문에서 확인하세요.

오늘은 이렇게 기억하면 충분합니다. 임베딩은 정보를 숫자로 표현해 관련성을 비교하도록 돕고, 그 숫자만으로 정답을 보증하지는 않습니다.

---

출처와 확인일

• Google Machine Learning Crash Course — Embedding space and static embeddings · 문서 수정일 2025년 8월 25일
• Google Cloud — Get text embeddings · 온라인 문서

자료 확인: 2026년 10월 30일. 특정 서비스의 이용 가능 여부나 성능을 시험한 글은 아닙니다.

---

1. 설명서를 펼쳐 보고 대답한다면

새로 산 가전제품의 예약 기능이 헷갈릴 때를 떠올려 보세요. 비슷한 제품을 써 본 사람의 기억보다, 내 제품의 설명서를 찾아 읽은 답이 더 도움이 될 때가 있습니다. AI도 질문과 관련된 자료를 먼저 찾아서 답을 만들도록 구성할 수 있습니다.

이 방식을 RAG라고 부릅니다. 영어로는 Retrieval-Augmented Generation, 우리말로는 보통 ‘검색 증강 생성’이라고 합니다. 이름은 어렵지만, 핵심은 필요한 자료를 찾아 AI가 답할 때 참고하도록 건네는 것입니다. NIST도 질문과 관련된 정보를 지식 저장소에서 찾아 모델에 제공하는 방식으로 설명합니다. NIST 공식 용어 설명

---

2. 자료 찾기부터 답변까지 세 단계

설명서에 답하는 AI를 예로 들어 보겠습니다. 사용자가 “이 제품의 예약 설정은 어떻게 해?”라고 물으면, RAG 시스템은 대체로 다음 순서로 움직입니다.

1. 찾기: 준비된 설명서 중 질문과 관련된 부분을 찾습니다.
2. 함께 전달하기: 질문과 찾아낸 내용을 묶어 AI에 건넵니다.
3. 답 만들기: AI가 그 내용을 참고해 읽기 쉬운 설명을 작성합니다.

여기서 찾는 대상은 인터넷 전체가 아닐 수 있습니다. 회사 내부 문서나 미리 모아 둔 설명서처럼, 정해진 자료 모음일 수도 있습니다. 따라서 ‘RAG를 쓴다’는 말만으로 실시간 웹 검색이나 최신 정보 확인까지 이루어졌다고 생각하면 곤란합니다.

우리가 눈여겨볼 점은 검색 결과가 답변을 만드는 재료로 들어간다는 것입니다. 검색 목록을 보여 주고 끝내는 것과도 차이가 있습니다. Microsoft의 RAG 작동 과정

---

3. 어제 배운 파인튜닝과는 어떻게 다를까요

지난 글의 파인튜닝은 추가 학습으로 모델을 특정 작업이나 응답 방식에 맞추는 방법이었습니다. RAG는 답할 때 사용할 참고 자료를 찾아 입력에 더하는 방식입니다. 자료를 참고하게 하려고 모델 자체를 매번 다시 학습시킬 필요는 없습니다.

설명서 내용이 바뀌었다면 RAG에서는 연결된 자료를 최신 내용으로 관리하는 일이 중요합니다. 오래된 설명서만 연결해 놓고 AI가 알아서 새 규칙을 알 것이라고 기대할 수는 없습니다.

파인튜닝과 RAG는 함께 쓸 수도 있습니다. 오늘은 어느 쪽이 무조건 더 좋다고 외우기보다, ‘추가로 학습시키는가, 답할 때 자료를 제공하는가’를 구분해 보세요. AWS의 RAG 설명

---

4. 자료를 찾아도 틀릴 수 있습니다

설명서를 찾았어도 다른 모델의 설명서라면 답이 맞지 않을 수 있습니다. 필요한 주의사항이 빠진 부분만 찾아왔다면 중요한 조건을 놓칠 수도 있습니다. 올바른 자료를 받아도 AI가 내용을 잘못 해석하거나 근거 없는 설명을 보탤 가능성은 남습니다.

그래서 답변을 읽을 때는 다음을 확인해 보세요.

• 맞는 자료인가: 제품명이나 적용 대상이 내 질문과 같은가요?
• 유효한 자료인가: 작성일과 개정일을 확인했나요?
• 답을 뒷받침하는가: 표시된 출처를 열었을 때 실제로 그 내용이 있나요?

출처가 붙어 있다는 사실과 답변이 정확하다는 판단은 별개입니다. Microsoft도 검색된 내용이 관련 없거나 불완전하면 부정확한 답이 나올 수 있고, RAG가 환각을 완전히 없애지는 못한다고 안내합니다. Microsoft의 한계 설명

---

5. 이렇게 요청해 보세요

자료를 참고할 수 있는 AI 기능을 이용한다면, 답만 요청하지 말고 확인할 근거도 함께 요청해 보세요.

“이 설명서에서 예약 설정과 관련된 부분을 찾아 순서대로 설명해 줘. 근거가 되는 절 제목이나 페이지도 표시해 줘. 자료에서 확인되지 않는 내용은 추측하지 말고, 확인되지 않는다고 말해 줘.”

이 요청 자체가 RAG 기능을 켜 주는 것은 아닙니다. 파일을 올렸다는 사실만으로 그 서비스의 내부 방식이 RAG라고 단정할 수도 없습니다. 실제로 어떤 자료를 참고할 수 있는지는 이용하는 기능을 확인해야 합니다.

답을 받았다면 표시된 원문을 한 번 열어 보세요. 페이지 번호가 맞는지, 빠진 조건은 없는지 비교하는 습관이 도움이 됩니다. 오늘 기억할 한 가지는 이것입니다. RAG는 참고 자료를 활용해 답하도록 돕는 방식이며, 자료의 품질과 답변 확인은 여전히 중요합니다.

공식 자료 확인일: 2026년 10월 29일. NIST와 AWS 페이지는 게시일 표시 없음, Microsoft 문서는 2026년 8월 21일 갱신.

---

1. 이미 배운 모델을 더 학습시켜요

파인튜닝은 이미 학습한 AI 모델을 특정한 일에 맞게 추가로 학습시키는 방법이에요. 여기서는 입력과 바람직한 답변 예시를 짝지어 학습하는 방식을 살펴볼게요. OpenAI 공식 설명

---

2. 질문창에 예시를 넣는 것과는 달라요

프롬프트는 답변할 때 참고할 지시나 자료를 주는 것이에요. 예시를 함께 넣을 수도 있죠. 파인튜닝은 별도의 학습으로 답변 생성에 영향을 주는 내부 수치인 가중치를 조정해요. 질문창에 예시를 붙여 넣는 것만으로 파인튜닝이 되는 것은 아니에요. 두 방법의 차이

---

3. 일정한 답변 형식에 활용할 수 있어요

가상의 독서 모임 AI를 떠올려 보세요. 책 소개를 입력받아 ‘한 줄 요약 → 토론 질문 2개’로 답한 예시들을 학습시키는 거예요. 원하는 답변 형식을 더 일관되게 만드는 데 파인튜닝을 활용할 수 있어요. 다만 매번 그 형식을 지킨다고 보장되지는 않아요.

---

4. 학습 뒤에도 확인은 필요해요

파인튜닝만으로 최신 정보나 정확성이 보장되지는 않아요. 학습에 쓰지 않은 질문으로 답변을 시험하고, 중요한 내용은 원문과 공식 자료로 확인해야 해요. 학습과 평가에 관한 공식 안내

---

1. 편향은 한쪽으로 치우치는 경향이에요

네. AI의 답도 특정 관점이나 조건 쪽으로 반복해서 치우칠 수 있어요. 이런 경향을 ‘편향’이라고 해요. 말투가 차분하고 설명이 자연스럽다고 해서, 여러 사람의 상황을 고르게 고려한 답은 아닐 수 있어요.

다만 마음에 들지 않는 답이나 부족한 답 하나만으로 편향이 있다고 단정할 수는 없어요.

---

2. 학습 자료만의 문제는 아니에요

AI가 배운 자료에 어떤 정보가 많고 적은지는 답에 영향을 줄 수 있어요. 하지만 자료만 살펴봐서는 충분하지 않아요. AI를 설계하고 개발할 때의 선택, 사람들이 AI를 사용하는 환경도 함께 살펴야 해요. 미국 국립표준기술연구소(NIST)도 편향을 데이터와 알고리즘뿐 아니라 사람과 사회적 맥락까지 포함해 다룹니다. NIST 공식 설명

---

3. 주말 추천으로 생각해 볼까요?

이해를 돕기 위해 만든 가상 예시예요. 실제 AI를 시험한 결과가 아닙니다.

“주말에 할 일을 추천해 줘”라고 물었는데, 답이 늘 자동차로 멀리 가거나 돈이 많이 드는 활동에 몰린다고 해 볼게요. 차가 없거나 비용을 아끼고 싶은 사람에게는 선택지가 좁게 느껴질 수 있어요.

이때는 “차를 이용할 수 있다고 가정한 건가요?”라고 짚어 볼 수 있어요. 한 번의 추천만으로 편향을 판정하기보다, 어떤 조건이 빠졌고 비슷한 치우침이 반복되는지 살펴보는 거예요.

---

4. 빠진 조건과 다른 선택지를 물어보세요

다음처럼 질문을 이어 가 보세요.

• “이 추천은 어떤 조건을 가정했나요?”
• “차 없이 갈 수 있고, 무료로 즐길 수 있는 활동도 알려 주세요.”
• “처음 추천과 다른 방식으로 주말을 보내는 선택지도 있나요?”

이런 질문은 답의 가정을 살펴보고 선택지를 넓히기 위한 방법이에요. 질문을 바꾼다고 편향이 사라지거나 중립적인 답이 보장되는 것은 아니에요. 실제로 이용할 장소의 운영 시간과 비용 등은 공식 안내에서 확인해 주세요.

---

1. 점수 옆의 ‘시험 이름’도 보세요

AI 소개에서 높은 점수를 보면 무엇이든 잘할 것 같죠. 하지만 수학 시험 성적만으로 글쓰기 실력까지 알 수는 없어요.

AI의 ‘벤치마크’는 정해진 과제와 기준으로 성능을 비교하는 시험이라고 생각하면 쉬워요. 점수를 볼 때는 어떤 일을 평가했는지부터 살펴보세요. 평가의 구성 살펴보기

---

2. 시험 내용과 조건이 중요해요

계산 문제를 푸는 시험과 글의 핵심을 찾는 시험은 평가하는 능력이 달라요. 같은 이름의 시험이라도 어떤 자료와 도구를 썼고, 어떻게 채점했는지 확인해야 해요.

점수 하나만으로 모든 능력이나 내 작업의 성공을 보장할 수는 없어요. NIST도 실제 사용 환경과 비슷한 조건에서 평가하고, 다른 조건에 적용할 때의 한계를 살피도록 안내해요. NIST 평가 지침

---

3. 내게 필요한 일은 다를 수 있어요

이해를 돕기 위한 가상 예시예요. 실제 AI를 시험한 결과가 아닙니다.

계산 문제에서 높은 점수를 받은 AI가 있다고 해볼게요. 내가 필요한 일은 ‘어려운 안내문을 쉽게 고치기’예요. 계산 점수만 보고 고르기보다, 안내문의 중요한 내용은 남기면서 읽기 쉽게 바꾸는지 확인하는 편이 낫겠죠.

---

4. 작은 비교부터 해보세요

직접 고를 때는 개인정보가 없는 내 작업 예시 몇 개를 준비해 보세요. 비교할 AI에 같은 자료와 요청을 주고, ‘중요한 내용이 빠지지 않았나’, ‘내가 읽기 쉬운가’를 살펴보는 거예요.

이건 내 작업에 맞는지 가늠하는 작은 비교예요. 몇 번 써본 결과로 AI의 전체 실력을 과학적으로 검증할 수는 없어요.

높은 점수를 보면 먼저 이렇게 물어보세요. ‘어떤 시험에서, 어떤 조건으로 받은 점수일까?’

---