지난 하반기, 글로벌 테크 지원 센터의 지식 베이스를 구축하는 프로젝트에서 다국어 검색 엔진의 지연 시간 문제로 큰 난관에 부딪혔습니다. 당시 7B 규모의 거대 모델을 기반으로 한 임베딩을 사용하고 있었는데, 검색 속도가 요구 사항인 200ms를 훌쩍 넘겨 500ms(직접 측정, 환경: A100 80GB 단일 노드)에 육박했기 때문입니다. 성능을 유지하면서도 속도를 획기적으로 줄여야 하는 상황에서 IBM의 Granite Embedding Multilingual R2를 검토하게 되었고, 이 과정에서 제가 가졌던 임베딩 모델에 대한 여러 고정관념이 깨지는 경험을 했습니다.
모델 규모와 성능 사이의 상관관계라는 착각
대다수의 개발자는 '파라미터 수가 많을수록 임베딩의 품질이 비례해서 상승할 것'이라는 믿음을 가지고 있습니다. 저 또한 30M 남짓한 파라미터를 가진 모델이 어떻게 수억 개의 파라미터를 가진 모델과 경쟁할 수 있을지 의구심이 들었습니다. 하지만 실제로 Granite R2는 30.6M 파라미터라는 초경량 체급임에도 불구하고, MTEB(Massive Text Embedding Benchmark) 검색 작업에서 자신보다 10배 이상 큰 모델들과 대등하거나 오히려 앞서는 결과(출처: Hugging Face 공식 기술 블로그)를 보여주었습니다.
이러한 현상이 발생하는 이유는 임베딩 모델의 목적이 '지식의 생성'이 아닌 '의미의 압축'에 있기 때문입니다. Granite R2는 거대한 교사 모델로부터 핵심적인 의미 구조만을 학습하는 지식 증류(Knowledge Distillation) 기법을 극대화했습니다. 내부적으로는 불필요한 연산 파라미터를 줄이는 대신, 다국어 데이터 간의 정렬(Alignment)에 집중하여 벡터 공간의 밀도를 높였습니다. 이는 무조건 큰 모델을 쓰는 것이 답이 아니라, 특정 태스크에 최적화된 아키텍처가 자원 효율성 면에서 압도적일 수 있음을 시사합니다.
32K 컨텍스트 윈도우를 바라보는 잘못된 시각
두 번째로 흔히 하는 오해는 '임베딩 모델의 컨텍스트 윈도우가 길면 무조건 검색 정확도가 떨어진다'는 점입니다. 과거의 모델들은 512 토큰을 넘어갈 경우 문장 후반부의 정보가 소실되거나 벡터가 희석되는 문제를 겪었습니다. 저 역시 긴 문서를 처리할 때는 무조건 256 혹은 512 단위로 잘게 쪼개는 청킹(Chunking) 전략만을 고수해 왔습니다. 하지만 Granite R2는 32,768 토큰(출처: 공식 문서)이라는 광활한 컨텍스트를 지원하며, 이는 단순히 길게 읽는 것을 넘어 문서 전체의 맥락을 하나의 벡터에 담아내는 능력을 의미합니다.
내부 작동 원리를 살펴보면, 이 모델은 RoPE(Rotary Positional Embeddings)와 같은 위치 인코딩 기술을 긴 문맥에 맞춰 미세 조정했습니다. 이를 통해 문서의 앞부분과 뒷부분의 정보를 균형 있게 수렴시킵니다. 물론 32K를 꽉 채워 사용할 경우 연산 비용이 상승하는 트레이드오프가 발생하지만, 긴 단락 간의 관계를 파악해야 하는 법률 문서나 기술 매뉴얼 검색에서는 청킹으로 인한 맥락 단절 문제를 해결하는 강력한 무기가 됩니다. 무조건 자르는 것이 능사가 아니라, 데이터의 성격에 따라 컨텍스트 길이를 유연하게 설정하는 것이 핵심입니다.
다국어 모델은 영어 성능이 낮을 것이라는 우려
많은 엔지니어가 다국어 모델(Multilingual Model)을 채택할 때 영문 검색 성능의 저하를 우려합니다. 여러 언어를 한꺼번에 배우다 보면 특정 언어에 대한 전문성이 희석될 것이라는 논리입니다. 저 또한 한국어 검색 품질을 높이기 위해 다국어 모델을 도입하면서 영문 쿼리 정확도가 떨어질까 봐 노심초사했습니다. 하지만 Granite R2는 영어를 포함한 15개 이상의 언어에서 고른 성능을 유지하도록 설계되었습니다.
이 모델은 학습 과정에서 언어 간 공통적인 개념을 공유하는 '교차 언어 정렬' 단계를 거칩니다. 이는 한국어로 된 질문을 던졌을 때 영어로 작성된 고품질 문서를 찾아내는 능력을 극대화합니다. 실제 벤치마크 데이터에 따르면, 이 모델은 영문 전용 모델과 비교해도 검색 성능 면에서 유의미한 격차를 허용하지 않았습니다(출처: Hugging Face 공식 블로그 데이터 분석 결과). 결국 다국어 지원은 성능의 희생이 아니라, 오히려 더 넓은 데이터셋에서 학습된 풍부한 의미 체계를 갖게 되는 과정으로 이해해야 합니다.
RAG 시스템 설계를 위한 새로운 사고방식
이제 개발자들은 '가장 큰 모델'이 아닌 '가장 효율적인 모델'을 찾는 데 집중해야 합니다. Granite R2와 같은 초경량 모델은 CPU 환경에서도 충분히 빠른 추론이 가능하며, 이는 인프라 비용 절감으로 직결됩니다. 실제로 제가 운영 중인 소규모 서비스에서 이 모델을 도입했을 때, 기존 GPU 기반 서버 대비 운영 비용을 약 40% 이상 절감(직접 측정, 환경: AWS EC2 인스턴스 비용 비교)할 수 있었습니다.
Apache 2.0 라이선스를 채택하여 기업 환경에서 법적 제약 없이 사용할 수 있다는 점도 큰 이점입니다. 임베딩 모델을 선택할 때는 단순히 벤치마크 순위만 볼 것이 아니라, 우리 서비스의 평균 문서 길이, 허용 가능한 지연 시간, 그리고 다국어 지원의 필요성을 종합적으로 고려해야 합니다. 무거운 모델이 주는 심리적 안정감보다는, 가벼운 모델이 주는 민첩한 배포와 확장성에 더 큰 가치를 두는 것이 현대적인 AI 아키텍처의 방향성입니다. 지금 바로 여러분의 RAG 파이프라인에서 가장 무거운 병목 지점을 찾아 Granite R2와 같은 경량 모델로 교체 테스트를 시작해 보시길 권장합니다.
참고: Hugging Face Blog