AI 임베딩이란? 문장을 숫자로 바꿔 검색하는 이유
AI를 활용하여 생성한 이미지입니다.
“반품하고 싶어요”라고 검색했는데 문서에는 ‘반품’ 대신 ‘환불 정책’이라고 적혀 있어도 관련 안내가 나온다면 편리하겠지요. 이때 검색 시스템이 활용하는 대표적인 방법이 임베딩(embedding)입니다. 임베딩은 텍스트를 숫자 목록인 벡터로 바꾸고, 같은 방식으로 변환한 질문과 문서의 관련성을 비교합니다.[1]
임베딩은 의미를 저장하는 숫자 표현입니다
임베딩 모델에 문장이나 문서 조각을 보내면 여러 실수로 이루어진 벡터가 반환됩니다. 숫자 하나하나를 사람이 읽고 “이 값은 환불을 뜻한다”고 해석하는 것은 어렵지만, 같은 모델로 바꾼 두 텍스트를 비교하면 어느 쪽이 가까운지는 계산할 수 있습니다.[1]
예를 들어 “노트북 배터리가 빨리 닳아요”와 “배터리 수명이 짧아졌어요”는 단어가 완전히 같지 않아도 비슷한 문제를 가리킬 수 있습니다. 다만 임베딩은 문서가 사실인지, 최신인지, 사용자가 읽어도 되는지 판정하는 장치가 아닙니다. 가까운 숫자라는 결과와 신뢰할 수 있는 답변은 별도로 관리해야 합니다.
키워드 검색과 의미 검색은 경쟁 관계가 아닙니다
키워드 검색은 입력한 단어와 문서의 일치 여부를 중심으로 결과를 찾습니다. 오류 코드, 제품 번호, 법 조항 번호처럼 철자와 숫자가 정확해야 하는 검색에 잘 맞습니다. 반면 의미 검색은 질문과 문서의 표현이 달라도 주제가 비슷한 조각을 후보로 올립니다.[2]
| 목적 | 먼저 고려할 방식 | 이유와 주의점 |
|---|---|---|
| 오류 코드·상품 번호 찾기 | 키워드 또는 필터 | 한 글자의 차이도 중요하므로 의미 점수만 믿지 않습니다. |
| 표현이 다양한 FAQ 찾기 | 임베딩 의미 검색 | 동의어와 질문형 표현을 후보에 포함할 수 있습니다. |
| 정확성과 표현 다양성이 모두 중요 | 하이브리드 검색 | 키워드 조건과 의미 순위를 함께 설계합니다. |
예를 들어 “모델 X의 E-104 오류”는 먼저 제품명과 오류 코드를 필터로 좁힌 뒤 의미 검색을 적용하는 편이 안전합니다. 어떤 조합이 맞는지는 실제 질문 목록으로 비교해야 하며, 임베딩을 추가했다고 자동으로 좋아지는 것은 아닙니다.
벡터의 ‘가까움’은 모델 안에서만 비교하세요
질문을 벡터로 바꾸고 문서 벡터와의 거리나 유사도를 계산하면 검색 순위를 만들 수 있습니다. OpenAI 문서의 예시는 코사인 유사도를 사용해 관련성이 높은 문서를 먼저 가져오는 흐름을 보여 줍니다.[1] 여기서 가까움은 지도상의 거리와 다르고, 모델과 계산법에 따라 점수의 의미가 달라집니다.
따라서 A 모델로 만든 문서 벡터와 B 모델로 만든 질문 벡터를 아무 설정 없이 비교하면 안 됩니다. 모델을 바꾸거나 차원 설정을 바꾸는 경우 기존 벡터를 다시 만들 필요가 생길 수 있으므로, 저장할 때 모델명·버전·생성 시각을 함께 기록하세요. Embeddings API 요청에서도 입력 텍스트와 모델을 지정하므로, 운영 환경의 설정을 문서화해 두는 것이 좋습니다.[3]
RAG에서 임베딩이 맡는 위치
임베딩은 답변을 쓰는 챗봇이 아니라 문서 후보를 찾는 검색 단계에 가깝습니다. 문서를 조각으로 나누고 벡터로 저장한 뒤, 사용자의 질문도 같은 모델로 변환해 가까운 조각을 찾습니다. 그 결과를 생성 모델에 참고 자료로 전달하고 원문 링크를 보여 주는 전체 구성을 흔히 RAG라고 부릅니다.[2]
- 문서를 제목과 의미가 이어지는 단위로 나눕니다.
- 각 조각과 원문 위치를 저장하고 임베딩을 생성합니다.
- 질문을 같은 임베딩 모델로 변환합니다.
- 유사도와 필터로 후보 문서를 고릅니다.
- 답변에는 검색된 근거와 원문 위치를 연결합니다.
검색이 엉뚱한 조각을 가져오면 생성 모델이 유창하게 답해도 근거가 틀릴 수 있습니다. 검색 결과가 없거나 근거가 부족할 때 “모르겠다”고 답하는 경로도 함께 설계해야 합니다.
문서 분할은 검색 품질을 좌우합니다
긴 문서 전체를 한 벡터로 만들면 질문과 무관한 내용이 섞입니다. 반대로 문장을 지나치게 잘게 자르면 제목, 적용 조건, 예외가 분리되어 조각만 읽었을 때 뜻이 흐려집니다. 설명서는 기능별로, 고객센터 문서는 질문과 답변을 함께, 정책 문서는 대상·기간·예외를 함께 담는 식으로 나누세요.
각 조각에는 문서 ID, 제목, 섹션, 원문 URL, 적용일, 언어, 제품·지역, 공개 범위와 버전을 붙이는 것이 좋습니다. OpenAI Retrieval 문서는 파일 속성으로 날짜 범위 같은 조건을 먼저 적용한 뒤 검색을 좁히는 방식을 설명합니다.[2] “현재 한국 정책”을 찾는다면 최신이면서 한국에 적용되는 문서만 남긴 후 의미 검색을 수행하는 식입니다.
평가는 점수가 아니라 질문으로 하세요
유사도 점수가 높다고 정답 문서라는 뜻은 아닙니다. 실제 사용자가 할 법한 질문을 모으고, 질문마다 반드시 찾아야 하는 문서 조각을 사람이 표시하세요. 그다음 상위 결과에 필요한 조각이 들어왔는지, 문맥이 충분한지, 오래된 버전이나 다른 지역 문서가 섞이지 않았는지 기록합니다.
- 정답 조각이 상위 결과에 들어왔나요?
- 조각만 읽어도 적용 조건과 예외를 알 수 있나요?
- 권한 없는 문서가 검색 결과에 포함되지 않았나요?
- 답변에서 원문 위치를 추적할 수 있나요?
분할 방식, 필터, 키워드 결합 여부를 한 번에 하나씩 바꾸고 같은 질문 세트로 비교하세요. 검색에 실패한 질문도 숨기지 말고 별도 목록으로 남겨야 다음 개선 방향을 결정할 수 있습니다.
개인정보와 API 전송 범위를 확인하세요
외부 임베딩 API를 사용하면 입력 텍스트가 서비스로 전송됩니다. 주민등록번호, 건강 정보, 고객 상담, 사내 기밀이 들어간 문서는 마스킹이나 비식별화 가능성, 처리 근거, 보관 기간, 접근 권한을 먼저 검토하세요. OpenAI의 데이터 제어 문서는 API 데이터가 명시적 동의 없이 모델 학습·개선에 사용되지 않는다고 설명하면서도, 악용 모니터링 로그가 생성·보관될 수 있다고 안내합니다.[4]
“학습에 쓰이지 않는다”는 설명만으로 조직의 개인정보 처리 요건이 충족되는 것은 아닙니다. 민감한 원문을 보내기 어려우면 가린 테스트 데이터로 파이프라인을 검증하고, 벡터와 원문을 연결하는 저장소에도 원문과 같은 권한 통제를 적용하세요.
검색 결과가 부족할 때의 다음 단계
상위 결과가 질문을 충분히 설명하지 못한다면 점수 기준만 낮추지 마세요. 먼저 조각에 제목과 예외 조건이 함께 들어 있는지, 최신 문서 필터가 적용됐는지, 질문에 필요한 키워드가 빠지지 않았는지 확인합니다. 결과가 너무 넓으면 필터나 키워드 조건을 추가하고, 너무 좁으면 문서 분할과 질문 표현을 다시 검토하세요. 변경 전후를 같은 질문 세트로 비교해야 개선인지 우연인지 구분할 수 있습니다.
도입 전 체크리스트
- 정확한 코드 검색인지, 표현이 다른 문서 검색인지 구분했나요?
- 문서가 의미가 끊기지 않는 단위로 분할됐나요?
- 원문 URL·버전·날짜·권한이 메타데이터로 남나요?
- 실제 질문과 기대 결과를 평가 목록으로 만들었나요?
- 필요하면 키워드 검색과 의미 검색을 결합했나요?
- 모델 변경 시 재임베딩 계획이 있나요?
- 개인정보와 외부 전송 조건을 검토했나요?
자주 묻는 질문
임베딩만 넣으면 챗봇이 정확해지나요?
아닙니다. 임베딩은 후보 문서를 찾는 도구입니다. 문서 최신성, 권한 필터, 분할 품질과 답변의 근거 표시가 함께 맞아야 합니다.
키워드 검색은 없애도 되나요?
오류 코드·고유명사·정확한 숫자가 중요한 서비스라면 남겨 두는 편이 좋습니다. 의미 검색과 함께 사용하면 표현 다양성과 정확한 식별을 나눠 처리할 수 있습니다.
문서를 잘게 나눌수록 좋나요?
아닙니다. 제목, 조건, 예외가 떨어지면 검색 결과가 불완전해집니다. 질문에 답하는 데 필요한 문맥이 한 조각에 남는지 확인하세요.
