AI 도입 전략2026.08.28읽는 시간 11분
벡터 저장, 의미 기반 검색 데이터는 어디에 둘까?
비슷한 뜻을 찾으려면 저장 방식부터 달라집니다
—VIEWS
—LIKES
—SAVES
비슷한 뜻을 찾으려면 저장 방식부터 달라집니다
회사에 문서는 이미 충분히 쌓여 있습니다. 업무 매뉴얼은 드라이브에, 제품 정보는 데이터베이스에, 지난 보고서와 회의록은 폴더별로 정리돼 있습니다. 그런데 이 자료를 AI가 참고하게 만들려고 하면 "문서는 다 있는데 왜 질문과 관련된 내용을 못 찾지?", "검색어를 조금만 바꿔도 결과가 달라지는데 이게 정상인가?", "데이터베이스가 이미 있는데 뭘 또 만들어야 하나?" 같은 질문이 먼저 나옵니다.
이 질문들의 공통 원인은 하나입니다. 지금까지의 저장 방식은 문서를 정확히 꺼내는 일에 맞춰져 있습니다. AI에 필요한 것은 뜻이 가까운 문서를 찾는 일입니다. 이 글은 벡터 저장이 무엇인지, 기존 저장과 무엇이 다른지, 우리 회사에 필요한지 판단하는 기준까지 정리합니다.
벡터 저장은 문장이나 문서의 의미를 여러 개의 숫자로 표현해 원문·출처와 함께 보관하는 방식입니다. 이 숫자 묶음을 벡터라고 부릅니다. 뜻이 비슷한 문장일수록 서로 가까운 값을 갖습니다. 그래서 단어가 정확히 일치하지 않아도 의미가 가까운 자료를 먼저 꺼낼 수 있습니다.
기존 저장과 벡터 저장은 대체 관계가 아닙니다. 사내 시스템의 데이터베이스와 파일 서버는 그대로 두고 그 옆에 "의미로 찾는 계층"을 하나 더 얹는 구조에 가깝습니다.
문서를 보관하는 능력과 문서의 의미를 찾아내는 능력은 다른 기능이기 때문입니다. 두 기능은 같은 시스템 안에 있다고 해서 자동으로 함께 생기지 않습니다.
기존 저장 방식은 대상이 명확할 때 강합니다. 고객번호 1024번 고객을 조회하거나 2026_휴가규정.pdf 파일을 여는 일처럼 찾을 대상이 이미 정해져 있으면 빠르고 정확합니다.
반면 AI에게 들어오는 질문은 대상이 정해져 있지 않습니다. "재택근무 규정"이라는 정확한 이름 대신 "집에서 일할 수 있는 조건이 어떻게 되나요?"처럼 들어옵니다. 도서관에 비유하면 앞의 방식은 청구기호로 책을 꺼내는 일이고 뒤의 방식은 "신임 팀장이 읽을 만한 리더십 책"을 골라 오는 일입니다.
사람마다 같은 대상을 다른 단어로 부르기 때문입니다. 사내 규정에는 '경조 휴가'라고 적혀 있는데 직원은 "가족 행사 때문에 쉴 수 있는 날이 며칠인가요?"라고 묻습니다. 사람은 두 표현이 같은 것을 가리킨다는 사실을 압니다. 단어를 맞춰 찾는 검색은 그렇지 않습니다.
이 격차는 오래전에 측정된 적이 있습니다. Furnas 외 3인은 Communications of the ACM 1987년 논문 「The Vocabulary Problem in Human-System Communication」에서 이를 다뤘습니다. 두 사람이 같은 대상에 같은 단어를 자발적으로 선택할 확률은 0.20 미만이었습니다. 같은 연구는 설계자가 고른 단어 하나로만 접근하게 만든 시스템을 지적했습니다. 그런 시스템이 흔한 상황에서 실패율은 80~90%였습니다.
찾지 못한 정보는 결국 사람에게 되돌아옵니다. 아틀라시안은 2025년 State of Teams 보고서에서 지식 노동자 1만 2천 명과 임원 200명을 조사했습니다. 응답자들은 업무 시간의 25% 이상을 답을 찾는 데 쓰고 있었고 56%는 필요한 정보를 얻는 유일한 방법이 누군가에게 묻거나 회의를 잡는 것이라고 답했습니다.
두 방식은 판정 기준 자체가 다릅니다. 일반 저장은 조건이 맞는지를 따지고 벡터 저장은 얼마나 가까운지를 따집니다.
구분 | 일반적인 저장 | 의미 검색을 위한 벡터 저장 |
|---|---|---|
판정 기준 | 조건이 일치하는가 | 뜻이 얼마나 가까운가 |
강한 질의 | 고객번호 1024번 조회, 파일명으로 열기 | "집에서 일할 수 있는 조건은?" 같은 서술형 질문 |
약한 질의 | "휴가 관련 문서 찾아줘" | "주문번호 A-2211 상태"처럼 정확히 일치해야 하는 조회 |
저장 형태 | 값과 행, 파일 그대로 | 원문 조각 + 의미 좌표 + 출처·권한 정보 |
준비 작업 | 스키마 설계와 색인 | 문서 분할, 의미 좌표 생성, 권한 표시 |
실패 방식 | 결과가 없다고 명확히 알려줌 | 엉뚱하지만 그럴듯한 문서를 상위에 올림 |
표의 결론은 하나입니다. 벡터 저장은 기존 저장보다 나은 기술이 아니라, 질문의 형태가 달라졌을 때 필요한 다른 종류의 저장입니다.
컴퓨터가 문장의 뜻을 사람처럼 이해해 보관하지는 않습니다. 대신 문장의 특징을 수백에서 수천 개의 숫자로 바꿔 좌표처럼 다룹니다.
"연차 사용 방법"과 "휴가 신청 절차"는 글자가 다릅니다. 두 문장을 숫자 좌표로 바꾸면 서로 가까운 위치에 놓이고 "서버 장애 대응"은 멀리 떨어집니다. 사용자가 "휴가 어떻게 신청해?"라고 물으면 질문도 같은 방식으로 좌표가 됩니다. 시스템은 그 좌표에서 가장 가까운 문서부터 꺼냅니다.
문서를 벡터로 바꾼다고 해서 원문을 버리는 것이 아닙니다. 실무에서는 원문 조각, 문서 이름, 작성 부서, 갱신 날짜, 열람 권한을 숫자와 한 세트로 묶어 저장합니다. 답변에 근거 문서를 함께 붙이려면 원문과 출처가 남아 있어야 합니다. 권한이 없는 사람에게 문서가 노출되지 않게 하려면 권한 정보도 같이 있어야 합니다.
벡터 저장 도입은 도구 선택이 아니라 검색 대상 선정에서 시작합니다.
전사 문서를 한 번에 넣지 않고 질문이 반복되는 영역 하나를 고릅니다. 인사 규정, 제품 사양, 고객 응대 스크립트처럼 문의가 몰리는 문서 묶음이 첫 후보입니다.
직원이 실제로 던진 문장을 그대로 모읍니다. 이 질문 목록이 나중에 검색이 잘되는지 판단하는 기준이 됩니다. 문서 목록만으로는 검색 품질을 측정할 수 없습니다.
80쪽짜리 문서를 통째로 저장하면 어느 부분이 답인지 지목하기 어렵습니다. 항목 단위로 나눈 뒤 조각마다 문서명·갱신일·부서·권한을 붙입니다.
모아둔 질문을 넣고 상위 5건 안에 정답 문서가 들어오는 비율을 셉니다. 이 숫자가 개선되는지로 판단하면 "느낌상 나아진 것 같다"는 평가를 피할 수 있습니다.
검색어가 문서에 그대로 없으면 자료를 못 찾습니다
직원이 쓰는 말과 문서에 적힌 말이 다릅니다.
같은 개념을 부서마다 다른 이름으로 부릅니다
경조 휴가·가족 행사 휴가·특별 휴가가 한 회사 안에 섞여 있습니다.
문서를 찾으려면 결국 담당자에게 묻습니다
검색으로 끝나야 할 일이 회의나 메신저 질문으로 넘어갑니다.
사내 문서를 근거로 AI가 답하게 만들고 싶습니다
공개 지식이 아니라 우리 규정과 사양을 인용해야 합니다.
답변에 출처를 함께 보여줘야 합니다
어느 문서 몇 쪽에서 나온 답인지 확인할 수 있어야 승인이 납니다.
문서마다 열람 권한이 다릅니다
검색 결과도 부서·직급 권한을 따라야 합니다.
3개 이상 해당하면 의미 검색용 저장 구조를 검토할 시점이고 5개 이상이면 이미 사람의 시간으로 손실을 메우고 있을 가능성이 큽니다.
찾는 대상이 정확한 값으로 정해져 있으면 벡터 저장이 오히려 불리합니다. 고객번호, 주문번호, 계약 ID처럼 문자열이 정확히 일치해야 하는 조회는 기존 데이터베이스가 더 빠르고 정확합니다.
전문 용어와 고유명사가 많은 문서도 마찬가지입니다. arXiv에 공개된 2026년 금융 문서·표 검색 벤치마크에서 키워드 기반 BM25는 Recall@20을 제외한 모든 지표에서 임베딩 기반 검색보다 좋은 성적을 냈습니다. 종목명·지표명처럼 표현이 이미 표준화된 문서에서는 단어를 그대로 맞추는 편이 유리하기 때문입니다. 같은 연구는 두 방식을 결합한 하이브리드 검색이 모든 구간에서 우위를 유지했다고 보고했습니다.
그래서 실무 결론은 교체가 아니라 병용입니다. 정형 데이터는 기존 데이터베이스에 두고 서술형 문서에만 의미 검색 계층을 얹는 구성이 일반적입니다.
AI를 쓰면 무조건 새 저장소가 필요하다
필요 여부는 AI 사용이 아니라 질문의 형태가 정합니다. 정확한 값으로 찾는 질문만 있다면 지금 구조로 충분합니다.
벡터로 바꾸면 원문은 지워도 된다
근거 표시와 권한 검사에 원문과 출처가 필요합니다. 숫자만 남기면 답변에 출처를 붙일 수 없습니다.
기존 데이터베이스를 갈아엎어야 한다
정형 데이터는 그대로 두고 서술형 문서에만 검색 계층을 얹는 구성이 일반적입니다.
문서를 다 넣으면 알아서 잘 찾는다
분할·출처·권한 설계가 빠지면 그럴듯한 오답이 상위에 올라옵니다.
여기까지 오면 다음 질문이 자연스럽게 생깁니다. 이 숫자 좌표를 수십만, 수백만 건 저장하고 질문과 가장 가까운 것을 빠르게 찾으려면 어디에 보관해야 할까요?
그 역할을 맡는 기술이 벡터 데이터베이스입니다. 의미를 나타내는 숫자 데이터를 저장하고 그중 가까운 것을 골라내는 작업에 맞춰 설계된 저장·검색 시스템입니다. 다음 글에서는 일반 데이터베이스와 무엇이 다른지, 어느 규모부터 필요한지를 다룹니다.
그 전에 검색과 생성이 어떻게 이어지는지 보고 싶다면 RAG란 무엇인가를, 기존 데이터베이스로 될지부터 판단하고 싶다면 AI 검색 DB, 일반 데이터베이스로 안 되나를 먼저 보면 순서가 맞습니다. 문서를 연결하기 전에 정해야 할 기준은 사내 문서 연결 전 3가지에 정리돼 있습니다.
저장 방식을 바꾸기 전에 확인할 것은 우리 문서가 어떤 질문을 받고 있는가입니다. NextGenAI는 문서 위치·형식·질문 유형·권한 구조를 함께 점검해 의미 검색 계층이 필요한 구간을 먼저 찾아냅니다. 기업 AI 도입 전반의 순서는 AX 컨설팅 가이드에서 확인할 수 있습니다.
무료 AX 진단을 신청하면 실제 질문 목록을 기준으로 지금 구조에서 몇 건이 답변 가능한지부터 확인해 드립니다.
벡터 저장은 문장이나 문서의 의미를 여러 개의 숫자로 표현해 원문·출처와 함께 보관하는 방식입니다. 단어가 정확히 일치하지 않아도 의미가 가까운 자료를 먼저 꺼낼 수 있어, 서술형 질문에 답하는 용도로 쓰입니다.
RELATED · 함께 읽으면 좋은 글
