카카오, 한국어 검색용 Kanana-2 임베딩 상업 활용 허용

카카오는 2026년 10월 29일 공식 발표에서 한국어 검색에 활용할 Kanana-2-embedding 모델 두 종을 허깅페이스에 공개했다. 공개된 것은 30억 매개변수의 3B와 13억 매개변수의 1.3B 모델 가중치이며, 두 모델에는 조건에 따라 상업적 활용이 가능한 카나나 오픈 라이선스가 적용됐다. 카카오 노병석 유니파이드 파운데이션 모델 성과리더는 이 발표에서 “흩어진 정보 속에서 필요한 정보를 정확히 찾아내는 기술이 중요하다”고 말했다.

전자신문의 공개 당일 보도는 과거 대화와 정보를 의미 단위로 찾아 연결하는 개인화 에이전트 용도를 짚었다. 임베딩 모델은 질문과 문서를 숫자 벡터로 바꿔 의미가 가까운 내용을 찾는다. 따라서 개발자가 당장 검토할 대상은 답변을 쓰는 생성 모델의 대체품이 아니라, 한국어 검색과 검색 증강 생성(RAG)에서 관련 자료를 골라내는 단계다.

3B와 1.3B는 무엇이 다른가

Kanana-2-embedding의 3B·1.3B 모델과 각각의 기본 벡터 차원을 비교한 구성

두 모델의 기본 선택 기준은 검색 품질과 실행 부담이다. 카카오는 Kanana-2 소형 언어모델을 검색에 맞게 학습해 3B를 만들고, 큰 모델의 학습 결과를 작은 모델에 전달하는 지식 증류로 1.3B를 구축했다. 같은 계열이지만 작은 모델을 쓰면 가중치를 적재하는 부담이 줄어드는 대신, 공개 평가에서 나타난 검색 점수 차이를 받아들여야 한다.

3B: 기본 출력 벡터는 2560차원이다. 한국어 문서에서 관련 항목을 놓치는 비용이 큰 RAG나 내부 자료 검색의 첫 비교 기준으로 삼을 만하다.
1.3B: 기본 출력 벡터는 1280차원이다. 추론 자원이 제한되거나 요청량이 많은 콘텐츠 검색에서 먼저 검토할 수 있으나, 실제 검색 품질은 서비스의 문서와 질문에 따라 달라진다.
공통: 최대 4096토큰을 입력받고, MRL 방식으로 출력 벡터를 1024·512·256·128차원으로 줄일 수 있다. 입력 한도와 출력 차원은 서로 다른 설정이다.

카카오가 공개한 3B 모델 카드의 평가표에서 전체 차원의 Ko-Retrieval 평균 점수는 3B가 0.8211, 1.3B가 0.7958이며, 128차원에서는 각각 0.7488과 0.7211이다. nano-BEIR 한국어 평가의 전체 차원 점수도 3B 0.6088, 1.3B 0.5866으로 제시돼 있다. 이 수치는 제작사가 같은 조건에서 공개한 MTEB 평가 결과로, 국내 서비스의 검색 기록을 이용한 독립 검증 결과는 아니다.

평가에서는 별도의 작업 지시 문구 없이 원문 입력을 사용했다. 실제 서비스가 질의와 문서에 다른 전처리 방식이나 검색 단위를 쓰면 순위와 체감 품질도 달라질 수 있다. 공개 점수는 두 모델을 비교할 출발점이며, 어느 쪽이 모든 한국어 자료에서 더 유용한지를 단정하는 값은 아니다.

벡터를 줄이면 저장량과 검색 점수가 함께 바뀐다

MRL은 학습된 벡터의 앞부분만 사용해 더 짧은 벡터를 만드는 방법이다. 3B의 기본 2560차원을 128차원으로 줄이면 벡터 값의 개수는 20분의 1이 된다. 모델 자체가 작아지는 것은 아니므로, 이 설정은 가중치 적재 메모리보다 문서 벡터를 보관하고 검색하는 쪽에 직접 영향을 준다.

저장량을 가늠하려고 문서 100만 건을 각각 하나의 벡터로 만들고, 벡터 값마다 4바이트를 쓰는 경우를 가정해 보자. 공개된 차원 수로 계산하면 3B의 전체 차원 벡터 값은 약 10.24GB, 512차원은 약 2.05GB, 128차원은 약 0.51GB다. 같은 가정에서 1.3B의 전체 차원은 약 5.12GB가 된다. 이는 벡터 값만의 십진 단위 계산이며 검색 색인의 부가 정보, 문서 원문, 복제본과 실행 메모리는 포함하지 않는다.

저장량 감소에는 검색 품질의 대가가 따른다. 제작사 평가에서 3B의 Ko-Retrieval 점수는 전체 차원보다 128차원에서 낮았고, 1.3B에서도 같은 방향의 차이가 나타났다. 따라서 문서가 많다는 이유만으로 가장 짧은 벡터를 고르기보다, 저장 가능한 규모와 상위 검색 결과에 남아야 할 문서의 비율을 함께 보는 편이 타당하다.

입력 길이도 색인 설계에 영향을 준다. 4096토큰을 넘는 문서는 나눠 입력해야 하고, 한도 안에 드는 긴 문서라도 주제가 여러 개라면 한 벡터가 어느 질문에 응답해야 하는지 불분명해질 수 있다. 질문과 비교할 검색 단위를 문단이나 내용 묶음으로 정하는 일은 모델의 최대 입력 길이와 별개의 결정이다.

상업적 사용이 가능한 범위

카나나 오픈 라이선스는 연구·개발뿐 아니라 조건에 따른 상업적 활용을 허용한다. 라이선스 조항은 모델을 이용해 자체 서비스를 개발하고 운영하는 경우와, 제삼자에게 모델이나 파생 모델 자체의 접근을 제공하는 경우를 구분한다. 이 구분 때문에 ‘상업적 사용 가능’이라는 표현만으로 모든 판매 방식에 같은 조건이 적용된다고 볼 수는 없다.

모델이나 파생 모델에 대한 접근을 API·클라우드 등 원격 서비스로 제삼자에게 제공하거나 재판매하려면 별도의 카카오 상업 라이선스가 필요하다. 시스템 통합 또는 고객사 내부 설치 방식으로 모델을 제공·판매하는 경우와, 기기에 탑재한 모델을 제삼자에게 제공·판매하는 경우도 별도 계약 대상이다. 반면 이 열거된 방식에 해당하지 않는 자체 서비스의 개발·운영에는 별도 상업 라이선스를 요구하지 않는다고 명시돼 있다.

재배포할 때는 이용 제한을 다음 이용자에게 전달하고, 라이선스 사본과 고지문을 제공하며, 수정한 파일에는 변경 사실을 표시해야 한다. 관련 웹사이트나 서비스 설명 자료 등에 ‘Powered by Kanana’를 눈에 띄게 표시하도록 한 조항도 있다. 검색 기능을 자체 서비스에 넣는 일과 가중치를 포함한 솔루션을 고객사에 판매하는 일은 출시 전에 서로 다른 사용 형태로 구분해야 한다.

직접 운영을 선택하면 외부 임베딩 API에 문서를 보내지 않는 구성을 설계할 수 있다. 그 대신 추론에 필요한 장비, 문서 변경 때의 재색인, 검색 결과의 품질 관리는 운영자가 맡는다. 공개 가중치와 조건부 상업 사용 허용은 이런 선택지를 넓히지만, 운영 비용까지 없애 주지는 않는다.

한국어 RAG·콘텐츠 검색·개인화 에이전트의 출발점

Kanana-2-embedding이 표현이 다른 과거 정보를 의미에 따라 찾는 개인화 검색 사례

한국어 RAG에서는 3B의 전체 차원을 품질 기준선으로 놓고 작은 모델이나 짧은 벡터가 얼마나 뒤처지는지 살펴보는 선택이 자연스럽다. 관련 문서를 검색 단계에서 놓치면 뒤의 생성 모델은 그 문서를 근거로 답할 수 없다. 이 때문에 RAG의 검색 단계는 답변 문장만큼 중요하며, 문서의 주제와 길이에 맞춘 분할 방식도 결과에 영향을 준다.

콘텐츠 검색은 1.3B와 축소 차원을 먼저 비교할 만한 영역이다. 게시물 수가 많을수록 문서마다 저장할 벡터의 길이가 전체 색인 규모에 누적되기 때문이다. 제목에 없는 표현으로도 관련 본문을 찾는 것이 의미 검색의 장점이지만, 짧은 벡터를 택했을 때 필요한 콘텐츠가 뒤로 밀리면 저장 공간 절감만으로 좋은 선택이라고 할 수 없다.

개인화 에이전트에서는 이용자가 예전에 말한 내용을 다른 표현으로 다시 찾는 장면이 직접적인 적용처다. 카카오가 든 ‘전에 이야기했던 조용한 식당’이라는 예처럼, 식당 이름 대신 의미가 가까운 과거 표현을 검색 대상으로 올릴 수 있다. 검색된 기록을 어떤 이용자의 어느 시점 정보와 연결할지는 임베딩 밖의 서비스 설계가 결정한다.

이제 국내 개발자는 공개된 가중치로 한국어 문서와 실제 질문에 맞는 조합을 비교할 수 있다. 3B와 1.3B의 차이는 제작사 평가에서 확인되지만, 최종 선택은 서비스가 허용하는 누락률, 응답 지연과 색인 규모에 따라 갈린다. 카카오가 예고한 다음 연구는 더 큰 언어모델을 바탕으로 임베딩 학습과 지식 증류를 이어가는 방향이다.

함께 읽기: