AI 임베딩 모델 고르기 — 클로드는 아예 안 만듭니다

내 문서로 답하는 챗봇을 만들려면 "의미가 비슷한 문단 찾기"가 먼저입니다. 그러려면 문장을 숫자 뭉치로 바꿔야 하고, 그걸 해 주는 게 임베딩 모델입니다. 그래서 공식 문서에서 임베딩 항목을 열면 — 좀 당황스러운 문장이 첫 줄에 있습니다. "우리는 자체 임베딩 모델을 제공하지 않습니다." 그러고는 다른 회사를 소개하고, 문서 나머지 전체가 그 회사 사용법입니다. 심지어 "여러 업체를 두루 살펴보고 고르라"고까지 씁니다.

📌 30초 요약

• 클로드를 만드는 회사는 임베딩 모델을 안 만듭니다. 문서가 직접 그렇게 밝힙니다.
• 그래서 검색 기능을 붙이면 열쇠가 둘, 청구서도 둘이 됩니다.
• 질문과 문서를 다르게 임베딩해야 합니다. 구분을 비워 두면 검색 품질이 떨어집니다.
• 숫자 개수를 줄여도 됩니다. 기본은 1024개인데 앞에서부터 잘라 256개로 써도 됩니다.
• 정밀도를 낮추면 저장 용량이 4배·32배 줄어듭니다. 검색 품질과 맞바꾸는 선택지입니다.

1. 임베딩이 뭐고 어디에 쓰나

임베딩은 문장을 숫자 목록으로 바꾼 것입니다. 뜻이 비슷한 문장끼리는 숫자도 비슷해지도록 훈련돼 있어서, 두 숫자 뭉치가 얼마나 닮았는지 계산하면 의미가 얼마나 가까운지가 나옵니다. 단어가 하나도 안 겹쳐도 뜻이 통하면 찾아냅니다. 검색창에 정확한 단어를 넣어야 걸리던 시절과 갈리는 지점이죠.

쓰임은 셋입니다. 의미로 찾기(내 문서 더미에서 질문에 맞는 문단 고르기), 추천(비슷한 글·상품 묶기), 이상 감지(평소와 동떨어진 것 찾기). 첫 번째가 압도적으로 많습니다. 내 문서로 답하는 챗봇을 만들어 본 적 있다면 이미 안 보이는 곳에서 쓰고 계셨을 겁니다.

고를 때 볼 것도 문서가 정리해 뒀습니다. 훈련 데이터의 규모와 분야 적합도(내가 다룰 분야와 가까울수록 좋음), 속도(대량으로 돌릴수록 중요), 내 데이터로 더 훈련시킬 수 있는지 셋입니다. 특히 사내 용어가 많은 분야라면 두 번째·세 번째가 성능을 가릅니다.

2. 만드는 회사가 "우린 안 만든다"고 씁니다

대화 모델을 만드는 회사가 임베딩 모델도 같이 낼 거라고 짐작하기 쉽습니다. 실제로 다른 곳들은 그렇게 합니다. 그런데 여기는 자체 임베딩 모델이 없다고 문서에 명시하고, 대신 이 분야에 집중해 온 다른 회사를 안내합니다. 그 회사는 금융·의료처럼 분야를 좁힌 모델과 고객별 맞춤 훈련까지 제공한다고 소개돼 있습니다.

문서 태도가 흥미롭습니다. 한 곳을 자세히 안내하면서도 "여러 업체를 평가해 내 용도에 맞는 곳을 찾으라"고 덧붙입니다. 자기 생태계로 묶어 두려 하지 않는 셈인데, 뒤집어 보면 "이건 우리 영역이 아니다"라는 선 긋기이기도 합니다.

현실적으로 이게 뜻하는 건 하나입니다. 검색 기능을 붙이는 순간 열쇠가 둘, 청구서도 둘, 장애 지점도 둘이 됩니다. 답변 쪽이 멀쩡해도 임베딩 쪽이 막히면 검색이 통째로 죽습니다. 웹에서 자료를 긁어와 AI에 먹이는 구조를 짜 봤다면 감이 오실 텐데, 수집·임베딩·답변이 각각 다른 회사면 어디서 끊겼는지부터 확인하는 습관이 필요합니다.

3. 종류가 생각보다 많습니다

"임베딩 모델 하나 고르면 끝"이 아닙니다. 성격이 다른 갈래가 여럿이고, 잘못 고르면 성능이 아니라 구조가 안 맞아서 고생합니다.

갈래	한 번에 넣는 분량	언제 고르나
범용 (센 것·균형·가벼운 것)	32,000토큰	대부분의 경우. 여러 언어에 두루 강함
분야 전용 (코드·금융·법률)	32,000 / 법률용은 16,000	그 분야 용어가 성능을 가를 때
여러 매체 섞기	32,000토큰	글·이미지·영상을 함께 검색할 때
조각에 문맥 심기	120,000토큰	긴 문서를 잘라 넣는데 앞뒤 맥락이 중요할 때
재순위 매기기	32,000토큰	일단 넓게 찾은 뒤 정확도를 끌어올릴 때

특히 조각에 문맥을 심는 갈래가 실무에서 값어치가 큽니다. 긴 문서를 조각내면 각 조각만 봐서는 무슨 얘기인지 모르는 문제가 늘 생기는데 — 손으로 제목·출처를 붙여 넣는 대신 문서 전체 맥락을 반영한 조각 벡터를 만들어 줍니다. 한 번에 넣는 분량도 12만 토큰으로 훨씬 크고, 부르는 방식도 일반 임베딩과 다릅니다.

하나 더. 가장 가벼운 등급에는 가중치가 공개된 판이 있습니다. 자유롭게 쓸 수 있는 조건이라 내 서버에 직접 올려 돌릴 수 있습니다. 자료를 밖으로 못 내보내는 환경이라면 이 선택지부터 보세요 — 이 경우 열쇠도 청구서도 하나로 돌아옵니다.

4. 돈과 용량을 줄이는 세 가지

임베딩은 저장 비용이 은근히 큽니다. 문단 하나가 소수 1024개니, 문서가 수십만 개면 벡터 창고가 본문보다 무거워집니다. 줄이는 방법이 셋 있습니다.

첫째, 숫자 개수 줄이기. 기본은 1024개인데 256·512·2048 중에서 고를 수 있습니다. 재미있는 건 이미 만들어 둔 1024개짜리를 앞에서부터 잘라 256개로 써도 된다는 점입니다. 러시아 인형처럼 앞쪽에 굵직한 정보가, 뒤쪽에 세밀한 정보가 담기도록 훈련돼 있어서죠. 자른 뒤에는 길이를 다시 1로 맞춰 주기만 하면 됩니다.

둘째, 정밀도 낮추기. 소수를 그대로 두는 대신 정수로 바꾸면 용량이 4분의 1, 아예 0이냐 1이냐만 남기면 32분의 1까지 줄어듭니다. 여덟 개 값을 부호만 보고 0과 1로 바꿔 한 덩어리로 눌러 담는 방식입니다. 물론 정밀도를 버리는 만큼 검색 정확도와 맞바꾸는 선택입니다.

셋째, 닮은 정도 계산을 싼 걸로. 이 벡터들은 길이가 1로 맞춰져 나오기 때문에 코사인 유사도와 내적이 같은 값이 됩니다. 내적이 계산이 더 빠르니 그냥 내적을 쓰면 됩니다. 유클리드 거리로 재도 순위는 동일하게 나옵니다.

⚠️ 질문과 문서를 같은 방식으로 넣으면 안 됩니다

검색에 쓸 때는 이게 질문인지 문서인지를 반드시 지정해야 합니다. 문서가 "비워 두거나 없음으로 두지 말라"고 못 박아 뒀습니다. 지정하면 내부적으로 서로 다른 안내 문구가 앞에 붙어서 임베딩됩니다 — 질문에는 "이 질문에 맞는 문서를 찾기 위한 표현으로", 문서에는 "검색되기 위한 표현으로" 같은 식이죠. 이 한 줄 차이가 검색 품질을 눈에 띄게 바꿉니다. 검색이 영 시원찮으면 여기부터 확인하세요.

5. 자주 묻는 질문 (FAQ)

Q. 답변 모델과 임베딩 모델을 같은 회사로 맞춰야 하나요?

전혀요. 임베딩은 내 창고에서 문단을 골라내는 단계일 뿐이고, 고른 문단을 어느 모델에게 읽힐지는 완전히 별개입니다. 실제로 여기서는 같은 회사로 맞추는 게 불가능합니다. 자체 임베딩 모델이 없으니까요.

Q. 나중에 임베딩 모델을 바꾸면 어떻게 되나요?

모델마다 숫자를 배치하는 방식이 달라서 기존 벡터와 새 벡터는 서로 비교가 안 됩니다. 즉 문서 전체를 다시 임베딩해야 합니다. 문서가 많다면 이게 곧 비용이자 작업 시간이니, 갈아탈 생각이라면 규모가 작을 때 결정하는 편이 낫습니다.

Q. 재순위 모델은 꼭 필요한가요?

필수는 아니지만 효과가 큽니다. 임베딩으로 후보를 넉넉히 스무 개쯤 뽑고, 그중에서 질문과 정말 잘 맞는 것을 다시 줄 세우는 용도입니다. 임베딩만으로 상위 세 개를 곧장 쓰는 것보다 정확도가 올라갑니다. 대신 한 단계가 더 붙으니 응답이 조금 느려집니다.

Q. 한국어 문서도 잘 되나요?

범용 등급이 여러 언어 검색 품질에 맞춰 만들어졌다고 소개돼 있습니다. 다만 내 문서에서 실제로 잘 되는지는 직접 재 보는 수밖에 없습니다. 자주 들어올 질문 스무 개쯤을 정해 두고, 정답 문단이 상위에 올라오는 비율을 모델별로 비교해 보세요.

✨ 정리하면

검색을 붙이려면 임베딩은 밖에서 구해 와야 합니다. 셋만 기억하세요 — 질문과 문서를 구분해서 넣고, 숫자 개수는 잘라 써도 되고, 정밀도를 낮추면 용량이 최대 32분의 1까지 줄어듭니다. 그리고 모델을 바꾸면 전부 다시 만들어야 하니 규모가 작을 때 정하세요. 이미지까지 다룰 생각이라면 이미지가 서버에서 줄어드는 규칙도 같이 보시고, 새는 돈은 AI 지출 관리 허브에 단계별로 모아 뒀습니다.

※ 2026년 9월 기준 공식 문서(임베딩 안내)를 바탕으로 정리했습니다. 소개된 업체와 모델 구성·요금은 수시로 바뀌니 도입 전 해당 업체 문서를 확인하세요. FAQ의 "모델을 바꾸면 전부 다시 임베딩해야 한다"는 부분은 동작 원리에 근거한 권고입니다.