인앱 대화 검색의 구조적 한계와 쿼리 확장 레이어 제안 ver.2

인앱 대화 검색의 구조적 한계와 쿼리 확장 레이어 제안

TeamVARYVERY / Yellow Glovez
2026-07-19 개정 2판

1판 쓴지 10분만에 버전업.
───

0. 요약

대화형 AI 서비스의 인앱 대화 검색은 최첨단 모델 위에 얹혀 있음에도
검색 기능 자체는 낙후되어 있다. 본 문서는 그 실패를 네 개의 축
— 매칭·커버리지·랭킹·도달 — 으로 분해하고, 벡터 DB 구축 없이
개선 가능한 범위를 특정한다.

본 제안의 성격

기존 검색을 대체하지 않는다. 기존 어휘 검색은 그대로 두고 그
위에 확장 레이어를 얹는다. 따라서:

• 확장이 실패해도 원어 검색 결과는 그대로 나온다. 최악의 경우가
현재 상태다.
• 주장은 "검색이 좋아진다"가 아니라
"손해 없이 개선 가능성만 얹는다" 이다.

이 성격이 본 제안의 방어선이자 한계선이다. 하방은 보장하지만
상방은 보장하지 않는다.

본 문서의 관측은 특정 시점의 두 제품(제미나이 인앱 검색,
클로드 앱 검색)에 대한 블랙박스 관측이다. 제품별·경로별로
동작이 다르므로 "대화형 AI 전반"으로 일반화하지 않는다.

───

1. 문제 분해 — 검색 실패의 네 축

인앱 검색의 불만은 하나가 아니라 넷이다. 뭉뚱그리면 해법도
뭉뚱그려진다.


축
질문
실패 시 증상

매칭
표기가 달라도 찾아내는가
분명히 있는데 0건

커버리지
인덱스에 실제로 들어 있는가
아예 검색 대상이 아님

랭킹
볼 만한 것이 위로 오는가
결과는 많은데 쓸모없음

도달
그 문장 지점까지 데려다주는가
들어가서 또 찾아야 함



1-1. 관측 결과

동일 조건에서 두 제품을 비교한 결과, 서로 다른 축에서
실패했다.



제미나이 인앱
클로드 앱

흔한 어미("입니다") 검색
사실상 대부분의 대화가 반환
소수만 반환

매칭 위치 표시
없음
굵은 글씨로 표시

인덱싱 단위
메시지/턴 단위 (같은 대화가 여러 건)
대화 단위 (대화당 1건)

주 실패 축
랭킹, 도달
커버리지(의심), 도달



1-2. 해석 — 우열이 아니라 실패 방향의 차이

제미나이는 거르지 않는다. 변별력 없는 질의에도 거의 전량을
반환하므로, 결과가 많다는 것이 커버리지 우위를 뜻하지 않는다.
필터가 없는 것에 가깝다.

클로드 앱은 거른다. 다만 그 판정 근거를 외부에서 알 수 없으며,
필요한 것을 잘라냈을 가능성을 배제할 수 없다.

두 실패의 위험도는 대칭이 아니다.

• 과잉 반환은 보인다. 사용자가 결과를 보고 쓸모없음을 안다.
• 누락은 보이지 않는다. 0건은 "없다"로 읽히지 "놓쳤다"로
읽히지 않는다.

1-3. 공통 결함 — 도달

두 제품 모두 대화 ID까지만 데려다주고 멈춘다. 사용자가 원하는
것은 대화가 아니라 그 문장이 있는 지점이다.

특히 제미나이는 메시지 단위로 색인하면서도 그 위치 정보를 결과에
반영하지 않는다. 인덱스가 이미 알고 있는 것을 쓰지 않고 있다.

이는 개별 제품의 흠이 아니라 인앱 검색이라는 기능 범주 전체의
결함으로 보는 편이 정확하다.

───

2. 매칭 축 — 무엇이 실제로 문제인가

2-1. 반증된 가설 — 띄어쓰기

당초 "띄어쓰기 변형에서 매칭 실패"를 한계로 지목했으나
실측에서 반증되었다.

제미나이 인앱 검색에서 베리파이체인으로 질의했을 때, 본문에
베리파이 체인으로 띄어져 있는 대화가 정상 반환되었다. 한글은
형태소 단위로 색인되므로 공백 변형은 흡수되는 것으로 보인다.

따라서 띄어쓰기는 본 제안의 근거에서 제외한다.

2-2. 남은 가설 — 한/영 혼용과 하이픈

• 동일 개념의 이질적 표기: 베리파이체인 / Verify-Chain /
verify chain
• 하이픈이 연산자로 오인되거나 토큰 분리를 유발할 가능성

아직 검증되지 않았다. 동일 대화가 세 표기 각각으로 검색되는지
확인하는 것이 다음 실험이며, 반증되면 본 제안의 근거는 상당 부분
축소된다.

2-3. 표준 해법과의 관계 — 왜 하이브리드가 아닌가

어휘 검색과 의미 검색은 실패 방향이 반대다.

• 어휘 검색: 그 문자열이 있는 것은 다 찾지만, 표현이 다르면 못 찾음
• 의미 검색: 표현이 달라도 찾지만, 그 단어가 박힌 문서를 놓침

업계 표준 해법은 둘을 함께 돌려 결과를 융합하는 하이브리드
검색이다. 본 제안이 이를 채택하지 않는 이유는 성능이 아니라
비용이다. 하이브리드는 벡터 인덱스의 상시 유지를 전제하는데,
그것을 만들지 않는 것이 본 제안의 출발점이다.

쿼리 확장은 하이브리드의 저비용 근사다.
우수하다는 주장이 아니라, 벡터 인덱스 없이 어휘 검색의 재현율만
끌어올리는 방식이라는 뜻이다.

───

3. 기존 해법(Full Vector DB)의 부담

전체 대화를 상시 임베딩하여 벡터 DB로 유지하는 방식은 기술적으로
확립되어 있으나, 운용상 다음 부담이 있다.

1. 지속적 인프라 비용: 대규모 사용자 기반의 대화 데이터를
실시간 임베딩·저장·유지보수하는 데 상당한 서버 리소스가 든다.
2. 투자 우선순위: 메인 모델 성능 향상 대비 인앱 검색 개선의
체감 효과가 작게 평가되어 후순위로 밀리는 경향이 있다.

즉 현재의 부실한 인앱 검색은 기술적 불가능이 아니라 엔지니어링
타협의 결과로 보는 편이 타당하다.

───

4. 제안 — 온디맨드 쿼리 확장 레이어

4-1. 파이프라인

[1] 사용자 검색어 입력
        │
        ▼
[2] 미니 AI 판정 레이어 (온디맨드)
        │   ※ 1순위 자료 = 사용자 본인의 대화 코퍼스 통계
        │   ※ 외부 조회는 코퍼스에서 해결 안 될 때만 폴백
        │
        ├─[3-1] 변별력 없는 단어  → 재입력 유도 / 결과 축소
        ├─[3-2] 특이 단어         → 한글·영문·약자 확장 (OR 결합)
        └─[3-3] 문장 길이 입력    → 맞춤법·띄어쓰기 교정본 확보
        │
        ▼
[4] 확장 쿼리로 기존 텍스트 DB 재검색
        │
        ▼
[5] 결과 표시
        │   입도  = 메시지 단위 다건 (제미나이식)
        │   표시  = 매칭 위치 강조 (클로드식)
        │   정렬  = 원어 완전일치를 항상 상위 고정
        │
        ▼
[6] 클릭 시 해당 메시지 지점으로 이동   → 6장 (본 레이어 범위 밖)


4-2. 판정 근거 — 외부가 아니라 본인 코퍼스

당초 외부 웹 검색을 확장 지식원으로 상정했으나, 개인 대화 검색에
한해 부적합하다.

• 개인이 실제로 찾는 것은 고유 명명·조어·약칭이며, 이는 웹에
없거나 다른 의미로 존재한다.
• 흔한 단어일수록 외부가 잘 알고, 희귀할수록 모른다.
그런데 검색이 실제로 필요한 것은 후자다.
• 부수적으로 검색어 외부 전송(프라이버시), 질의당 외부 호출 비용,
왕복 지연이 발생한다.

대신 세 갈래를 함께 쓴다. 통계 단독으로는 한 번만 등장한
희귀 조어를 커버할 수 없기 때문이다.


갈래
내용
커버 범위

룰
병기 패턴 추출 — 한글 뒤 괄호 안 영문 표기 등
1회 등장 조어도 포착

통계
등장 빈도, 동시 출현, 치환 관계
반복 사용되는 용어

실패 피드백
사용자가 못 찾았다는 신호를 반영
나머지



실패 피드백은 단서가 필요하다. 0건일 때 시스템은 무엇을
놓쳤는지 알 수 없으므로, 사용자가 이후 해당 대화를 찾아 연결해
줄 때 비로소 학습된다. 이 단계를 생략하면 성립하지 않는다.

이 모든 것은 학습이 아니라 집계다. 모델을 사용자별로 재학습할
필요가 없고, 모델은 공용 하나를 두고 개인화는 표가 담당한다.

4-3. 색인 시점 — 지연 색인

기존 대화 전체를 소급 색인(백필)하지 않는다.

• 신규 대화는 종료 시 집계.
• 기존 대화는 사용자가 다시 열었을 때 그 시점에 색인한다.
• 여유가 있으면 유휴 시간에 점진 처리.

이는 UA-RAG의 액티브 앵커와 같은 원리다 — 필요할 때 필요한
만큼만 로드한다.

부작용과 그 처리

• 한 번도 열지 않은 대화는 확장 혜택을 받지 못한다. 그러나 기본
검색은 그대로 작동하므로 현상 유지일 뿐 악화가 아니다. 자주
보는 것부터 좋아진다는 점에서 우선순위도 타당하다.
• 표본이 일부에 편중되어 빈도 통계가 편향될 수 있다. 다만 판정에
필요한 것은 절대 빈도가 아니라 상대 순위이며, 흔한 어미와
희귀 조어의 순서는 편향에도 뒤집히지 않는다.

4-4. 정리 시점 — 감쇠와 복구

감쇠. 오래 쓰이지 않은 항목은 가중치를 점차 낮추고, 일정
이하가 되면 표에서 제거한다. 감산 장부가 필요 없고 표 크기가
저절로 억제된다.

단, 축은 빈도가 아니라 최근성이어야 한다. 이 시스템의 목적이
희귀 조어를 잡는 것인데 빈도 임계값으로 청소하면 가장 필요한
단어가 가장 먼저 지워진다. 목적을 스스로 잡아먹는 구조가 된다.
사용자가 그 단어로 검색하면 타이머를 초기화한다.

복구. 감쇠로 빠진 항목도 소실이 아니라 휴면이다. 기본 검색은
그 대화를 여전히 찾아내므로, 사용자가 결과를 눌러 열면 그 시점에
다시 색인되고 가중치가 부여된다. 별도 복구 기능이 필요 없다.

삭제. 대화가 삭제되면 인덱스에서 빠지고 결과에도 나오지
않는다. 기존 동작 그대로이며 새 규칙이 필요 없다. 파생 통계에 남는
기여분은 감쇠가 처리한다.

세 정책이 서로의 뒤처리를 한다. 지연 색인은 실제로 열리는 것만
통계에 넣고, 감쇠는 안 쓰이는 것을 빼고, 삭제는 기존 동작에
맡긴다. 추가 장부가 하나도 없다.

4-5. 설계 원칙 — 대체가 아니라 추가

일반 웹 검색의 의도 추정이 비판받는 지점은 원래 검색어를 버리고
다른 것을 찾아준다는 데 있다. 명시적 제어(따옴표 등)를
무력화하면 사용자는 통제권을 잃는다.

본 제안은 다르다.

• 원어는 그대로 두고 확장어를 OR로 덧붙인다.
• 원어 완전일치 결과는 항상 상위에 고정한다.

사용자가 잃는 것이 없으므로 자동 개입이라는 사실 자체는 문제되지
않으며, 별도 토글도 필요하지 않다.

대체는 박탈이고, 추가는 보완이다.

4-6. 비용과 지연

• 연산: 단어 빈도 집계는 모델 추론이 아니라 카운터 갱신이다.
GPU가 필요 없고, 임베딩 대비 자릿수가 다르다. 대화 하나 처리
비용은 모델이 답변 한 번 생성하는 비용에 비해 무시할 수준으로
보인다.
• 백필: 지연 색인으로 회피한다(4-3).
• 실질 부담: 연산이 아니라 운영이다. 시스템이 하나 늘면
모니터링·장애 대응·스키마 변경이 따라온다. 연산이 싸도 사람
시간은 싸지 않다.
• 지연: 단일 키워드 파싱 수준이므로 기존 인앱 검색이 이미
소요하는 응답 시간 안에 대체로 묻히는 수준으로 예상된다. 절대
속도가 아니라 기존 지연 대비 추가분이 작다는 점이 핵심이며,
실제 값은 실측이 필요하다.

요약하면 "인프라를 안 만든다"가 아니라
"자릿수 싼 것을, 실제 쓰이는 만큼만 만든다" 이다.
그럼에도 도입되지 않는다면 그것은 비용이 아니라 우선순위의
문제이며, 이는 3장의 진단과 일치한다.

───

5. 본 제안이 커버하는 범위


축
해결 여부
비고

매칭
가능
표기 확장이 정확히 이 문제

랭킹
범위 밖
아래 5-1

커버리지
부분 회피
아래 5-2

도달
부적절
6장



5-1. 랭킹은 이 레이어의 몫이 아니다

초판에서 랭킹을 "이미 좁혀진 결과 위의 재정렬이므로 부담이 작다"고
서술했으나 과대 주장이었다.

실제 랭킹 신호 — 매칭 위치(제목/본문), 매칭 밀도, 최신성, 대화
길이 — 는 전부 검색 엔진 코어 로직에 속한다. 확장 레이어에서
이를 구현하려는 것은 검색 엔진을 다시 만드는 일이다.

본 제안이 랭킹에 대해 요구하는 것은 하나뿐이다:
원어 완전일치를 상위에 고정할 것. 이는 새 랭킹을 만드는 것이
아니라 기존 랭킹에 제약 하나를 거는 것이다.

5-2. 커버리지 — 포기가 아니라 부분 회피

인덱스에 없는 것을 확장으로 찾을 수는 없다. 그러나 커버리지 문제의
상당 부분은 "어디까지 색인하느냐"가 아니라 **"무엇을 색인 대상으로
삼느냐"**다.

• 현재 다수의 인앱 검색은 메시지 본문만 색인한다.
• 사용자는 파일명, 코드 블록, 첨부 메타데이터까지 찾기를 원한다.

색인 항목 자체를 넓히는 것만으로 체감 커버리지가 크게 달라질
수 있으며, 검색 결과에 "파일 첨부됨" 같은 메타데이터를 노출하는
것도 부분적 회피가 된다. 이는 앞단에서 제안 가능한 영역이다.

───

6. 도달 — 모델이 아니라 배관으로

도달은 결정론적으로 완전히 해결되는 문제다.

어느 메시지에서 매칭되었는지는 인덱스가 이미 알고 있다. 검색
결과에 대화 ID 대신 메시지 ID를 실어 보내고, 클라이언트가 그
지점으로 이동시키면 끝난다.

6-1. 모델을 넣으면 안 되는 이유

• 정확도 100%가 보장되는 작업을 확률적 장치로 바꾸게 된다.
• 존재하지 않는 위치를 지시할 위험이 생긴다. 한 번의 오지시로
기능 전체의 신뢰가 무너진다.
• 불필요한 지연이 추가된다.

6-2. 현실적 장벽과 대응

아무도 하지 않았다면 이유가 있다.


장벽
대응

책임 소재가 검색팀과 클라이언트팀 사이에 걸침
조직 문제이며 기술 문제가 아님. 명시해 두는 것으로 충분

대화 수정·삭제 시 이동 지점이 사라짐
삭제된 대화는 결과에 뜨지 않으므로 클릭 자체가 발생하지 않음. 대화는 남고 특정 메시지만 사라진 경우, 이동 실패 시 대화 상단으로 폴백

긴 대화에서 중간 지점 이동 시 로딩·스크롤 성능
대상 메시지 주변 일부를 함께 로드하여 문맥 확보



타임스탬프를 메시지 ID의 대안으로 쓰자는 제안이 있으나 채택하지
않는다. 같은 시각에 여러 메시지가 존재할 수 있고, 삭제 시에는
타임스탬프 역시 가리킬 대상이 없어지므로 안정성 이점이 없다.

본 문서의 개선안 중 가장 저렴하면서 체감 효과가 가장 큰 것이
도달이다. 모델도, 벡터 DB도, 학습도 필요 없이 반환 필드 하나를
바꾸는 작업이다. 그럼에도 아직 구현되어 있지 않다.

───

7. 검증 상태와 실험 설계

7-1. 확인된 것

• 제미나이 인앱 검색은 띄어쓰기 변형을 흡수한다 (당초 가설 반증)
• 제미나이는 메시지/턴 단위로 색인하며 같은 대화를 여러 건 반환한다
• 제미나이는 매칭 위치를 표시하지 않는다
• 클로드 앱은 매칭 위치를 표시하며 반환 건수가 현저히 적다
• 클로드 앱 검색과 모델이 사용하는 검색 도구는 서로 다른
시스템이다 (동일 질의에 다른 결과)

7-2. 미확인

• 한/영 표기 및 하이픈에서의 매칭 실패 여부 → 2-2
• 클로드 앱의 적은 반환 건수가 부분 색인 때문인지, 관련도 임계값
때문인지
• 인앱 검색의 실제 응답 지연
• 각 서비스의 내부 색인 정책 (외부에서 관측 불가)

7-3. 비교 방법론의 한계

두 제품은 내부 아키텍처가 다를 가능성이 높고, 그 내부는 외부에서
관측할 수 없다. 따라서 1-1의 비교는 거동 관측이지 아키텍처
비교가 아니다. 본 문서는 이를 아키텍처 우열의 근거로 쓰지 않으며,
"두 제품이 서로 다른 축에서 실패한다"는 현상 기술에만 사용한다.

다만 상대 아키텍처를 추정하여 그 추정 위에서 비교를 기각하는
것 역시 같은 문제를 안는다. 내부 구조는 양쪽 모두 관측 불가다.

7-4. 제안하는 실험

1. 표기 변형 테스트: 동일 대화를 베리파이체인 /
Verify-Chain / verify chain 세 표기로 검색. 2-2를
확정하거나 반증.
2. 위치 편향 테스트: 긴 대화 하나에서 초반에만 등장한 희귀어와
후반에만 등장한 희귀어로 각각 검색. 부분 색인과 관련도 임계값을
구분.
3. 동일 조건 A/B: 같은 엔진에서 확장 레이어 ON/OFF의 재현율·
정밀도 비교. 제품 간 비교보다 이쪽이 본 제안의 직접 근거다.

7-5. 설계상 미해결

• 확장어와 원어의 구체적 가중치 배분
• 변별력 판정 임계값
• 감쇠 속도와 통계표 크기 상한

───

8. 결론

인앱 검색의 부실은 기술적 불가능이 아니라 우선순위의 결과다.
그리고 그 부실은 하나의 문제가 아니라 매칭·커버리지·랭킹·도달
네 개의 서로 다른 문제다.

• 매칭은 벡터 DB 없이, 룰과 본인 코퍼스 통계를 읽는 경량 판정
레이어로 개선할 수 있다. 기존 검색을 대체하지 않으므로 실패해도
손해가 없다.
• 랭킹은 검색 엔진 코어의 몫이다. 본 제안은 원어 완전일치
상위 고정이라는 제약 하나만 요구한다.
• 커버리지는 색인 정책의 문제이나, 색인 항목을 넓히는 방식으로
부분 회피가 가능하다.
• 도달은 모델이 필요 없다. 가장 싸고, 가장 효과가 크며,
아직 아무도 하지 않고 있다.

───

부록. 관련 기존 개념

• UA-RAG — 앵커의 세 속성(참조 식별, 탐색 공간 제약, 진리
독립성). 6장의 메시지 앵커가 참조 식별에 해당한다.
• 액티브 앵커 — 지연 로딩 기반 세션 연속 포인터. 4-3의 지연
색인이 같은 원리다.
• 계층형 메모리 구조 제안 — 참조 범위의 통제권을 사용자에게
두는 설계 축. 본 문서의 4-5(대체가 아니라 추가)와 감쇠 타이머
초기화가 같은 원칙을 따른다.