개인 AI 에이전트의 답변 모델이 한국어를 잘하더라도, 과거 메모리를 찾는 검색 단계는 별개의 문제입니다. 2026년 4월 3일 저는 기존 임베딩 모델에서 한국어 메모리 검색이 기대만큼 맞지 않는다고 느껴 카카오의 Kanana-Nano-2.1b-Embedding을 별도 서버로 연결했습니다.
이 글은 당시 Mac에서 구성한 사례를 다시 정리한 운영 기록입니다. 정확한 Mac 모델명과 메모리 용량을 확인할 장치 정보는 남아 있지 않습니다. 모델 전체의 우수성을 입증하는 벤치마크나 모든 환경에서의 설치 가이드는 아닙니다. 특히 모델 지원 방식과 라이브러리 호환성은 이후 달라질 수 있으므로 실제 적용 전에는 배포처의 최신 문서를 확인해야 합니다.
먼저 분리한 문제는 답변과 검색이었습니다
당시 시스템은 Ollama의 nomic-embed-text를 이용해 메모리를 벡터로 만들고 검색했습니다. 문제는 LLM의 한국어 답변 품질이 아니라, 한국어 질문에 맞는 과거 기록이 상위 결과로 돌아오는지였습니다.
| 구분 | 확인할 질문 |
|---|---|
| 생성 모델 | 찾아온 문맥을 바탕으로 적절한 답을 만드는가 |
| 임베딩 모델 | 질문과 관련된 한국어 기록을 가까운 벡터로 표현하는가 |
| 검색 설정 | 문서 분할, 검색 개수, 필터가 목적에 맞는가 |
| 원문 데이터 | 찾고 싶은 사실이 메모리에 실제로 들어 있는가 |
임베딩 모델을 바꾸기 전에 마지막 두 항목도 함께 봐야 합니다. 자료가 없거나 문서 분할이 지나치게 크면 다른 모델을 붙여도 결과가 나아지지 않을 수 있습니다.
기존 호출 형식을 유지하는 어댑터를 뒀습니다
당시에는 Kanana 모델을 기존 Ollama 호출 방식으로 바로 사용할 수 없었습니다. 그래서 모델을 직접 호출하는 FastAPI 서버를 만들고, 기존 애플리케이션이 기대하는 임베딩 응답 형식에 맞추는 어댑터 역할을 맡겼습니다.
기존 에이전트
→ Ollama 호환 요청
→ FastAPI 어댑터
→ transformers로 임베딩 생성
→ Apple Silicon MPS 사용
→ 기존 형식으로 벡터 반환기록상 서버는 로컬 포트 11435에서 동작했고, 기존 Ollama 포트 대신 이 주소를 바라보도록 바꿨습니다. “기존 코드를 수정하지 않았다”는 표현은 당시 호출부의 인터페이스를 유지했다는 의미입니다. 모델 로딩 서버와 실행 설정은 새로 구성했습니다.
Apple Silicon에서는 성능보다 운영 상태를 먼저 봤습니다
당시 기록에는 Apple Silicon의 device="mps"를 사용했다고 남아 있습니다. 당시 기록에는 모델 프로세스가 약 4GB를 점유했고, 다른 백그라운드 작업과 함께 실행할 때 스왑 증가와 체감 지연이 있었다고 남아 있습니다. 이 수치는 그 환경의 관찰값이며 다른 Mac이나 라이브러리 버전에서 그대로 재현된다고 볼 수 없습니다. 별도로 로컬 모델 로딩이 실패했던 기록은 Qwen3.5 로컬 운영 실패 기록에서 볼 수 있습니다.
재부팅 뒤 서버가 사라지는 문제를 줄이기 위해 LaunchAgent와 KeepAlive도 사용했습니다. 자동 시작만으로 충분하지는 않았습니다. 프로세스가 떠 있어도 모델 로딩 실패나 응답 지연이 발생할 수 있으므로, 실제 임베딩 요청까지 확인하는 점검이 필요했습니다.
품질 비교 전에 인덱스부터 분리해야 합니다
추가 설계 기준: 임베딩 모델을 바꿀 때는 기존 문서 벡터와 새 모델의 질문 벡터를 그대로 섞지 않습니다. 차원이 같더라도 두 모델의 벡터 공간이 같다는 뜻은 아닙니다. 원문 문서와 분할 기준을 고정한 채 후보 모델용 인덱스를 별도로 만들어 문서를 다시 임베딩하고, 질문도 같은 모델로 변환한 결과끼리 비교해야 합니다.
전환 중에는 기존 인덱스와 설정을 보존해 되돌릴 경로를 남깁니다. 요청·응답 인터페이스를 유지했다는 것만으로 과거 벡터까지 호환되는 것은 아닙니다. 원문에는 재색인 절차와 전체 결과가 없어 이 작업이 당시 어떻게 완료됐는지는 확인할 수 없습니다.
당시에는 한국어 검색 결과가 더 낫다고 체감해 운영을 계속했지만, 공개 기록에는 정량 평가 세트와 전체 결과가 남아 있지 않습니다. 따라서 특정 벤치마크 점수나 “한국어 검색이 항상 향상된다”는 결론으로 확대하지 않습니다.
- 이름, 날짜, 프로젝트명처럼 정확히 찾아야 하는 질문을 준비합니다.
- 정답이 들어 있는 원문 문서와 문서 분할 결과를 고정합니다.
- 기존 모델과 후보 모델에 같은 질문과 검색 개수를 적용합니다.
- 상위 결과에 정답 근거가 포함되는지 기록합니다.
- 검색 품질과 함께 로딩 시간, 메모리, 장애 복구도 비교합니다.
모델 카드의 공개 벤치마크는 후보를 고르는 데 유용하지만, 개인 메모리의 문장 길이와 표현 방식까지 대신 평가하지는 않습니다. 실제 데이터의 소규모 검증 세트를 따로 두는 편이 안전합니다.
검색이 좋아져도 상시 운영을 유지할지는 따로 정합니다
이 사례에서 판단을 나누는 기준은 분명했습니다. 정답 원문이 저장되어 있고 같은 질문에서 기존 검색이 빗나가면 후보 모델을 비교할 이유가 있습니다. 반대로 모델을 올린 뒤 다른 작업과 함께 쓸 때 지연이 부담스럽다면 검색 체감만으로 상시 구성을 확정하지 않습니다. 당시의 약 4GB 점유 기록은 이런 운영 부담을 함께 봐야 했다는 맥락입니다.
여기의 연동 경험과 후속 평가는 구분해서 읽어야 합니다. 4월 10일의 Kanana·nomic 업무 질의 비교에는 세 묶음의 top1 기록이 있지만, 그것이 4월 3일 당시 모든 체감이나 하드웨어 조건을 소급 검증하지는 않습니다.
편집: 2026-09-13. 기존 기록의 구조를 정리한 것으로 새 실행·성능 시험이나 현재 서비스 상태 확인을 뜻하지 않습니다.
정정: 2026-09-27. 확인되지 않은 장치 사양이 확정 사실처럼 반복되지 않도록 표현을 바로잡았습니다.