SMART Framework를 이해할 때 핵심은 “새 임베딩 모델을 하나 더 고를 것인가”가 아닙니다. 더 중요한 질문은 검색 대상 안에 들어 있는 다양한 의미 신호를 어떻게 나누고, 조합하고, 활용할 것인가입니다.
특히 RAG를 운영하는 팀이라면 이 관점이 중요합니다. RAG는 외부 지식을 검색하고, 그 결과를 사용자 요청과 결합한 뒤, LLM이 답변을 생성하도록 만드는 방식입니다.1 즉 검색, 증강, 생성 중 첫 단계인 검색 품질이 흔들리면 최종 답변의 정확성도 함께 흔들립니다.
SMART는 왜 검색 설계의 문제인가
많은 검색 시스템은 문서 하나를 하나의 벡터로 압축해 다룹니다. 이 방식은 단순하고 빠르지만, 문서가 길거나 정보 구조가 복잡할수록 한계가 드러납니다. 문서 안에 본문, 표, 이미지, 캡션, 제품 정보가 함께 들어 있다면 하나의 벡터가 모든 의미를 충분히 대표하기 어렵습니다.
멀티모달 환경에서는 이 문제가 더 커집니다. 실제 업무 데이터는 PDF, 오피스 문서, 위키, 이미지, 비디오처럼 다양한 형식으로 존재할 수 있습니다.1 RAG가 이런 데이터를 제대로 활용하려면 텍스트 검색만 잘하는 것으로는 부족합니다.
SMART는 이런 맥락에서 멀티모달 검색을 위한 프레임워크로 볼 수 있습니다. 핵심은 검색 대상을 더 풍부하게 표현하고, 사용자의 질문에 맞는 단서를 더 정확히 찾아내는 것입니다. 최근 임베딩 모델이 텍스트, 이미지, 영상, 오디오를 같은 의미 공간에서 다루는 방향으로 발전하는 것도 같은 흐름입니다.2
단일 벡터 검색이 놓치기 쉬운 것
단일 벡터 검색은 문서 전체의 평균적인 의미를 잡는 데 유리합니다. 하지만 사용자가 묻는 것은 문서 전체가 아니라 특정 문단, 특정 표, 특정 이미지 속 정보일 때가 많습니다.
예를 들어 긴 제품 매뉴얼에서 “경고등이 빨간색으로 깜박일 때 조치 방법”을 찾는 상황을 생각해볼 수 있습니다. 문서 전체를 하나의 벡터로 만들면 매뉴얼의 큰 주제는 잘 표현될 수 있지만, 특정 증상과 조치 절차가 검색 상위에 안정적으로 올라오지 않을 수 있습니다.
멀티벡터 또는 멀티모달 검색 접근은 이런 문제를 줄이기 위한 설계입니다. 문서 전체를 하나로 뭉개기보다, 의미 단위나 데이터 형식에 따라 검색 가능한 단서를 더 세밀하게 만드는 쪽에 가깝습니다.
SMART를 검토할 때 봐야 할 기준
SMART 같은 프레임워크를 도입할지는 기술 유행이 아니라 데이터와 질의의 성격으로 판단해야 합니다.
첫째, 검색 대상이 단순 텍스트인지 확인해야 합니다. 짧고 구조가 단순한 문서가 대부분이라면 기존 단일 벡터 검색으로도 충분할 수 있습니다. 반대로 PDF, 스크린샷, 차트, 제품 이미지, 긴 문서가 섞여 있다면 멀티모달·멀티벡터 접근을 검토할 만합니다.
둘째, 비용과 지연 시간을 함께 봐야 합니다. 벡터를 여러 개 사용하면 표현력은 좋아질 수 있지만 저장 공간과 검색 연산 비용도 늘어납니다. 일부 임베딩 모델은 Matryoshka Representation Learning처럼 벡터 차원을 조정해 효율을 관리할 수 있는 방법을 제공합니다.3 다만 효율화 가능성이 곧바로 도입 타당성을 의미하지는 않습니다.
셋째, 평가는 실제 사용자 질의로 해야 합니다. 벤치마크 점수보다 중요한 것은 내 서비스에서 자주 나오는 질문에 대해 필요한 근거 문서를 얼마나 안정적으로 찾는지입니다. RAG는 검색된 데이터를 프롬프트에 결합해 답변을 생성하므로,1 잘못 검색된 근거는 그 이후 단계에서 계속 영향을 미칩니다.
적용은 작게, 실패 질의부터
SMART를 “검색 시스템을 전면 교체하는 일”로 접근할 필요는 없습니다. 먼저 현재 RAG에서 실패하는 질의를 모으는 것이 좋습니다. 답변이 틀렸다면 원인이 생성 모델에 있는지, 검색 결과에 있는지, 검색 대상의 표현 방식에 있는지 나눠봐야 합니다.
그다음 실패가 자주 발생하는 데이터 유형을 확인합니다. 긴 문단에서 놓치는지, 표에서 놓치는지, 이미지나 문서 레이아웃에서 놓치는지에 따라 검색 단위를 다르게 설계할 수 있습니다.
중요한 것은 벡터를 무조건 많이 만드는 것이 아닙니다. 사용자 질문에 실제로 도움이 되는 단서를 더 잘 꺼내는 것입니다. SMART Framework의 실용적 가치는 바로 여기에 있습니다. RAG의 성능을 높이고 싶다면 모델만 바꾸기보다, 검색 대상이 어떤 의미 단위로 표현되고 있는지부터 점검해야 합니다.
1RAG (Retrieval Augmented Generation) on Databricks
2Gemini Embedding 2: Putting Text, Images, Video, and Audio in One Vector Space
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.