[2025.12.05 주간 개발 트렌드] React2Shell 정리 (RSC 취약점, 영향 범위, 패치)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# Redis 안에서 키워드와 벡터 검색을 함께 다룬다

RAG를 만들때는 어떤 모델을 사용할지 먼저 고민하기 쉽다. 그런데 검색 단계에서 관련없는 문서를 가져오면 모델이 좋은 답변을 만들기 어려워진다.

이번주 11월 25일에 [Redis 8.4](https://redis.io/blog/redis-8-4-open-source-ga/)가 GA로 공개됐다. FT.HYBRID를 통해 전문 검색과 벡터 유사도 검색을 한 쿼리에서 결합할 수 있게 됐다. 성능과 메모리, Streams 관련 개선도 포함됐다.

이번주에는 Hybrid Search가 왜 필요한지와 검색을 하나의 엔진으로 묶을때 확인할 부분을 정리해보려고 한다.

# 1. 키워드와 의미 검색은 잘하는 일이 다르다

사용자가 에러 코드처럼 정확한 문자열을 입력했다면 같은 문자열이 있는 문서를 찾는게 중요하다. 반대로 표현은 달라도 비슷한 문제를 설명하는 문서를 찾고싶을 수도 있다.

```text
정확한 문자열이 중요한 질문
→ ERR_PAYMENT_TIMEOUT 해결 방법

의미가 비슷한 문서가 필요한 질문
→ 결제 요청을 보냈는데 응답이 오래 걸린다
```

키워드 검색과 벡터 검색은 이 두 상황에서 서로 다른 도움을 줄 수 있다. 벡터만 사용하면 중요한 제품명이나 버전, 에러 코드의 정확한 일치를 놓칠 수 있고 키워드만 사용하면 다른 표현의 관련 문서를 놓칠 수 있다.

그래서 어느 방식이 무조건 더 좋다고 고르기보다 실제 질문의 성격을 보는게 좋겠다. 검색 결과를 섞는 Hybrid Search는 이런 서로 다른 신호를 함께 사용하는 접근이다.

# 2. FT.HYBRID는 어느 부분을 맡나

기존에 두 검색 결과를 따로 받아 애플리케이션에서 합치고있었다면 결과 수와 점수를 맞추는 코드가 필요했을것이다.

[FT.HYBRID](https://redis.io/docs/latest/commands/ft.hybrid/)는 텍스트 검색과 벡터 검색 결과를 엔진 안에서 결합한다. RRF와 선형 결합 방식으로 하나의 순위 목록을 만드는 기능을 제공한다.

```text
질문
├── 텍스트 검색 결과
└── 벡터 검색 결과
          ↓
       순위 결합
          ↓
    하나의 결과 목록
```

이렇게 묶으면 외부에서 결과를 합치는 코드를 줄일 여지가 있다. 다만 문서를 수집하고 임베딩을 생성하고 인덱스를 준비하는 과정까지 없어지는것은 아니다.

명령어 하나가 RAG 전체를 대신하는것으로 생각하면 헷갈린다. 모델에 어떤 문서를 전달하고 답변을 어떻게 검증할지는 여전히 애플리케이션의 설계에 포함된다.

# 3. 점수 두개를 그냥 더하면 될까

텍스트 검색의 점수와 벡터 유사도의 값은 같은 기준이라고 가정하기 어렵다. 한쪽 숫자가 더 크다는 이유만으로 더 관련있다고 판단할 수는 없다.

RRF는 각 검색 결과에서의 순위를 이용해 결과를 결합하는 방식이다. 서로 다른 점수의 크기를 그대로 비교하는 부담을 줄일 수 있다.

아래 숫자는 동작을 생각해보기 위한 가상의 순위다.

| 문서 | 키워드 순위 | 벡터 순위 |
| --- | --- | --- |
| A: 정확한 에러 코드 안내 | 1위 | 8위 |
| B: 관련 장애 해결 가이드 | 3위 | 2위 |
| C: 표현이 비슷한 일반 문서 | 20위 | 1위 |

두 방식에서 모두 상위에 있는 B가 좋은 후보일 수 있다. 하지만 정확한 에러 코드가 꼭 필요한 질문이라면 A를 놓치지 않는지도 확인해야한다.

선형 결합에서는 각 점수의 정규화와 가중치도 중요해진다. 설정을 조절할 수 있다는것과 올바른 비율을 알고있다는것은 다른 문제다.

그래서 실제 질문과 정답 후보를 모아 비교하는 과정이 필요하다. 데모 질문 몇개에서 좋아보이는 결과만으로 검색 방식을 결정하기는 어렵겠다.

# 4. 검색 품질을 어떻게 확인하면 좋을까

우선 기존 검색과 Hybrid Search에 같은 질문을 넣고 결과를 나란히 보자. 기대하는 문서가 상위에 나오는지와 관련없는 문서가 얼마나 섞이는지 확인할 수 있다.

```text
평가용 질문
├── 정확한 이름과 코드가 있는 질문
├── 표현이 다른 유사한 질문
├── 여러 조건을 함께 가진 질문
└── 답이 없는 질문
```

정답이 없는 질문도 중요하다. 어떤 결과든 반드시 보여주면 모델이 관련없는 문서를 근거로 답변을 만들 수 있기 때문이다.

문서 검색의 성공과 최종 답변의 성공도 나눠서 보면 좋겠다. 검색은 제대로 했는데 답변을 잘못 구성한것인지, 필요한 문서를 처음부터 못찾은것인지 구분해야 개선할 위치가 보인다.

문서를 나누는 크기와 제목, 본문에 넣는 정보도 결과에 영향을 준다. 엔진을 바꾸기 전에 수집한 문서가 질문에 답할 내용을 포함하는지도 살펴보자.

검색 시간을 줄이는것과 충분한 후보를 가져오는것 사이에서도 선택이 생긴다. 상위 결과 수를 바꿨다면 지연 시간과 답변 품질을 같이 비교해야겠다.

# 5. Redis 하나로 합치기 전에 확인할것

이미 캐시로 Redis를 사용하고있다면 검색까지 같은 기술로 다룰 수 있다는 점이 편하게 느껴질 수 있다. 그렇다고 기존 캐시 인스턴스에 검색 부하를 그대로 추가하는게 항상 좋은 선택은 아니다.

벡터와 검색 인덱스는 메모리를 사용하고 질의에는 연산이 필요하다. 캐시의 응답 시간과 검색 요청이 서로 영향을 주는지도 확인해야한다.

```text
운영에서 함께 볼것
데이터 크기 / 인덱스 메모리 / 검색 지연 / 캐시 지연
문서 갱신 / 백업과 복구 / 접근 범위
```

여러 고객의 문서를 저장한다면 검색 단계에서도 접근 가능한 문서만 후보가 되도록 설계해야한다. 결과를 모델에 넘긴 다음에 숨기는 방식으로는 이미 전달된 내용을 되돌리기 어렵다.

또한 임베딩 모델을 바꿀때 기존 벡터와 새 벡터를 어떻게 관리할지도 정해야한다. 검색 엔진을 하나로 묶어도 데이터 갱신과 재색인의 계획은 필요하다.

운영 구성을 단순하게 만들 수 있는지와 필요한 검색 품질과 규모를 만족하는지를 같이 비교하면 좋겠다. 도구가 하나라는 사실만으로 전체 시스템이 단순해지는것은 아니다.

# 마무리

이번 Redis 8.4는 캐시나 자료구조 저장소로만 보던 Redis에서 검색과 AI 문맥 조회의 역할이 더 커지는 변화로 보인다.

개인적으로는 애플리케이션에서 직접 합치던 검색 결과를 엔진 안에서 다룰 수 있다는 점이 눈에 들어왔다. 그만큼 어떤 기준으로 합친 결과가 좋은지 확인하는 작업도 중요하겠다.

우선 실제 질문과 기대하는 문서를 모아서 기존 검색과 비교해보면 좋겠다. 검색 명령을 줄이는것 다음에 모델이 필요한 문맥을 제대로 받는지 확인해야겠다..


[2025.11.28 주간 개발 트렌드] Redis 8.4 정리 (Hybrid Search, 벡터 검색, RAG)

독자의 메모