서론

이 기사에서 얻을 수 있는 것 (3가지 핵심 요약)

업무 데이터에 답변하는 RAG를 TiDB로 구현하는 과정에서, 문서에는 나와 있지 않은 1차 정보(공식 문서에는 없으며, 실제로 구동해 보고 나서야 알게 된 사실)와 RAG의 신선도를 정량적으로 평가하는 방법론이 쌓였습니다.

본 기사의 내용은 다음 세 가지입니다.

• RAG의 신선도를 "측정"하는 방법론 ("신선도 오답률"을 질문 분포 × 동기화 간격의 함수로 측정)
• 일본어 전문 검색(Full-text Search)의 함정과 설계 레시피 (MULTILINGUAL 파서는 형태소 분석이 아님)
• TiDB의 "신선도 경계" 실측 (점 참조(Point Lookup)는 즉시 / TiFlash 열 저장소(Column Store)는 ≈142ms의 동기화 지연)

결론의 일부("데이터와 임베딩(Embedding)을 단일 엔진에 두면 신선도를 유지할 수 있다")는 단일 엔진 일반의 성질이며, TiDB에만 국한된 것은 아닙니다 (§5에서 구분하여 설명합니다). 본 기사의 목적은 "TiDB의 우월함을 보여주는 것"이 아니라, 구현 과정에서 얻은 1차 정보와 신선도를 측정하는 방법을 공유하는 것입니다.

이 기사의 전제

본문에서 사용할 용어를 최소한으로 미리 정의합니다.

• RAG: LLM이 답변하기 전에 DB에서 관련 정보를 검색하여 전달하는 메커니즘 (Retrieval-Augmented Generation).
• 벡터 검색 / 임베딩 (Embedding): 텍스트를 수치 배열(=임베딩)로 변환하여 "의미적 유사성"으로 검색하는 기법.
• 전문 검색 (Full-text Search): 단어의 키워드 일치로 찾는 검색 (§3에서 일본어의 함정을 다룸).
• CDC: Change Data Capture. DB의 업데이트 이벤트를 감지하여 다른 시스템으로 흘려보내는 메커니즘. §2의 "동기화@1"은 이에 해당하는 이상적인 케이스.
• TiDB / TiDB Cloud Zero: MySQL 호환 서버리스 분산 DB. **하나의 DB에서 SQL + 벡터 검색 + 전문 검색 + 트랜잭션(여러 처리를 묶어서 확실하게 반영하는 성질, ACID)**을 작성할 수 있음. TiDB Cloud Zero는 curl 한 번으로, 가입 없이 바로 생성할 수 있는 무료 일회용 클러스터(본 기사의 모든 검증은 이것으로 실시).
• HTAP (행 저장소 TiKV / 열 저장소 TiFlash): 쓰기 및 점 참조(Point Lookup)에 강한 행 저장소(TiKV)와 집계 및 분석에 강한 열 저장소(TiFlash)를 하나의 DB에 공존시키는 메커니즘.
• p50 / p95: 레이턴시(Latency, 응답 시간)의 분포 지표. p50 = 중앙값(절반이 이보다 빠름), p95 = 95 퍼센타일(95%가 이보다 빠름 = "느린 쪽의 대표값"). §5에서 검색 레이턴시 평가에 사용.
• 점 참조 (Point Lookup): 기본 키(Primary Key) 등으로 레코드 1건을 직접 조회하는 읽기(예: 상품 ID로 재고를 가져옴). TiDB에서는 행 저장소(TiKV)가 담당하며, 업데이트가 즉시 반영됨.
• RTT (Round Trip Time, 네트워크 왕복 시간): 클라이언트에서 DB까지 왕복하는 통신 시간. 클라우드 DB 쿼리 지연의 상당 부분은 이것이 차지함(본 기사의 측정값에도 포함됨).
• 본 기사에서 비교하는 2가지 구성:
  • 동기형 RAG: 벡터 DB와 RDB를 각각 별도로 운영하며, 주기적/CDC로 동기화하는 일반적인 구성 → 동기화 지연으로 인해 데이터가 오래됨.
  • 라이브 참조 RAG: 데이터와 임베딩을 동일한 DB에 두고, 항상 최신 데이터를 참조하는 구성.

이 기사의 검증 맵 (전체상 먼저 확인)

TiDB Cloud Zero 상에서 수행한 검증은 5가지입니다. 결론을 지도로 나타내면 다음과 같습니다:

①②③는 구현을 통해 얻은 1차 정보, ④는 HTAP 집계에서 우위가 나타나지 않은 null 결과, ⑤는 병행 업데이트 하에서의 간섭 내성 확인입니다. 이후 이 순서대로 설명하겠습니다.

1. 왜 「신선도」가 문제인가

어떤 상품이 품절된 직후에, 동일한 질문을 「정기 동기화형 RAG」와 「라이브 참조 RAG」에 던졌을 때의 본 검증 데모 실행 로그입니다.

👤 상품 5번 재고 있나요?
❌ 동기화형 (VectorDB+RDB를 정기 동기화): 「네, 12개 재고가 있습니다」 ← 오래됨. 이미 품절됨
✅ 라이브 참조: 「품절 (0개)입니다」 ← 올바름

그림 1: 재고가 0이 된 후 다음 동기화까지의 「오답 창(Error Window)」. 이 창의 기간 동안만 동기화형은 오래된 재고를 반환한다.

LLM도 프롬프트도 나쁘지 않습니다. 검색 기반(Search Infrastructure)이 오래된 데이터를 반환하고 있을 뿐 (stale RAG). 그리고 실질적인 피해는 무시할 수 없습니다. 「업데이트 직후의 상품을 반드시 질문한다」 = 신선도가 가장 중요하게 요구되는 **상한 케이스(Upper Case)**에서 계측한 결과:

그림 2: 신선도 민감도의 상한 케이스에서 100문항 중 43문항이 오답. 그중 30문항은 「품절을 “재고 있음”으로 오답」.

• 100문항 중 43문항이 오답, 그중 30문항은 「실제 재고가 0인데 “재고 있음”이라고 답하는」 위험한 방향 (판정 기준: 스냅샷의 재고 > 0 이고 실제 재고 = 0).
• ※ 이 43%는 「변화한 항목을 겨냥하여 질문하는」 상한 케이스. 일률적으로 카탈로그를 물으면 0~3% (후술). 실제 운영의 쿼리 분포는 이 사이에 위치합니다.

「신선도는 기반의 문제」라는 것을 알게 되었다면, 다음에 필요한 것은

그것을 어떻게 측정할 것인가입니다.

2. RAG의 신선도를 “측정하기”: 신선도 오답률이라는 방법론

막연하게 「동기화 지연은 나쁘다」라고 말하는 대신, 측정 가능한 지표로 구체화합니다.

정의 (원인을 LLM으로부터 분리)

신선도 오답률 = 동일 질문을 동일 시점에 「동기화형」과 「라이브」로 던졌을 때, 라이브는 정답이고 동시에 동기화형은 오답인 비율. 검색 로직, 임베딩(Embedding), 난수 시드(Random Seed)를 양측 모두에서 완전히 고정하여, 차이점을 동기화 지연에 귀속시킴.

※ 여기서 「동일 시점」이란 실제 시간의 병행 처리가 아니라, **업데이트 이벤트와 질문을 하나의 시간축에 나열하여 순차적으로 재생하는 결정적 리플레이(Deterministic Replay)**에서의 동일 지점(=동일한 업데이트 적용 수)을 의미합니다. 동기화형과 라이브에 동일한 시퀀스를 별도로 흘려보내며 비교하기 때문에, 차이는 동기화 지연에만 귀속됩니다. 실제 시간으로 업데이트를 흘리면서 측정하는 병행 검증은 §5 (간섭 내성)에서 다룹니다.

중요한 점은, 본 실험의 오답 판정은 「스냅샷 재고 > 0 이고 실제 재고 = 0」인 데이터 대조로 결정되며, LLM은 개입하지 않는다는 것입니다. = 신선도 오류는 검색층에서만 결정됨을 나타냅니다 (생성 품질의 문제가 아님). 판정의 핵심은 이것뿐입니다:

got = read_stock(table, pid) # table = products_live / products_snapshot
true_stock = truth[applied][pid] # 그 시점의 “진정한” 재고
wrong = (got > 0) != (true_stock > 0)

실험 설정 (무엇을, 어떻게 측정했는가)

• 데이터: 상품 80건의 카탈로그 (재고, 설명, 카테고리). 결정적으로 생성 (시드 고정으로 재현 가능).

• 업데이트: 재고 수를 랜덤하게 바꾸는 조작을 100건, 결정적인 순서로 적용 (품절=0을 많이 포함).

• 질문: 100건. 「이 상품의 재고가 있나요?」를 다음 두 가지 방식으로 자동 생성하여, 각 시점의 진정한 재고와 대조.

  • uniform (하한): 모든 상품에서 일률적으로 랜덤하게 질문 (재고 변화와 무상관).
  • active (상한 케이스): 업데이트 직후의 상품을 반드시 질문하는 구성. 「재고가 움직인 직후에 확인한다」는 행동이 100% 집중된 이론적인 상한으로, 실제 이용 그 자체라기보다는 "신선도가 가장 크게 요구되는 최악에 가까운" 케이스.

• 동기화 간격 (Sync Interval): 동기화형이 「@N (N건의 업데이트마다 1회씩 모아서 동기화한다)」는 의미의 @N으로 표기하며, @1 (매 업데이트 = CDC 상당의 이상적 상태) / @5 / @20 / @60으로 변경하며 비교합니다. N이 클수록 동기화가 드물어지며, 데이터는 오래되기 쉬워집니다 (업데이트가 매 분 수 건이라면 @20...

はおおむね数分間隔に相当）。 -
재고 조회 방식: 재고 확인은 **점 참조(TiKV Row Store)**로 읽습니다 (업데이트 직후에도 최신 값이 반환됨 = read-your-writes. 자세한 내용은 §4). '실시간 참조'가 0%가 되는 것은 이 때문입니다. 참고로 TiFlash를 통한 분석 및 대규모 벡터 조회에는 별도의 신선도 경계(≈0.1s급, §4)가 있습니다.

실시간 테이블 / 스냅샷 테이블이란 (＋@5의 구체적 예시)

두 개의 테이블은 각각 2가지 RAG 아키텍처가 보는 데이터 소스입니다.

실시간 테이블(Live Table): 실시간 참조 RAG의 데이터. 업데이트가 즉시 반영되어 항상 최신 상태입니다. products_live

） -
스냅샷 테이블(Snapshot Table): 동기형 RAG의 데이터. products_snapshot

）@N

업데이트마다 실시간 테이블에서 복사되며, 동기화와 동기화 사이의 간격은 오래된 상태로 유지됩니다.

실제 시스템에서는, 동기형 RAG의 LLM은 스냅샷 테이블을, 실시간 참조 RAG의 LLM은 실시간 테이블을 참조하여 답변합니다. 다만 '재고가 있는지'는 테이블 값으로 결정되며, LLM의 능숙도와는 관계가 없습니다. 그래서 §2에서는 LLM을 제외하고, 두 테이블의 재고를 '진짜 재고'와 직접 대조하여 오답을 계산합니다 (신선도의 오류가 검색 계층에서만 결정됨을 보여주기 위해).

구체적 예시(@5의 경우):

• 업데이트 ③에서 상품 A가 12 → 0(품절)으로 변경됩니다.
• 동기화는 5 업데이트마다 이루어지므로 (@5), 다음 동기화는 업데이트 ⑤입니다. 업데이트 ③부터 ⑤까지의 간격, 스냅샷 테이블은 여전히 '12개'입니다. - 이 간격 동안

이유(관찰을 통한 추측): 일본어는 단어를 공백으로 구분하지 않기(분절이 없기) 때문에, MULTILINGUAL 파서가 어휘 경계(Word Boundary)를 제대로 파악하지 못하고 있는 것으로 보입니다. 영숫자(SKU·모델 번호)는 공백이나 하이픈으로 자연스럽게 구분되므로 안정적으로 히트합니다.

※ 내부 사양은 공식 문서에서 최신 정보를 확인하십시오 (여기서는 실측 동작과 설계 판단을 보여줍니다).

-- 영숫자(SKU/모델 번호)라면 정확하게 히트. 관측상, fts_match_word는 소문자·WHERE 절 내에서 사용.
SELECT product_id, name FROM products
WHERE fts_match_word('SKU-1234', description);

설계 레시피

• **일본어 자연어 → 벡터 검색 (Vector Search)**에 가깝게 구성 (의미로 검색).
• 전문 검색(Full-Text Search)은 영숫자(SKU·모델 번호·카테고리 기호·에러 코드)로 한정한다.
• fts_match_word('어휘', 컬럼)는 소문자로 작성. **측정 시점에는 WHERE 절 내에서 다른 조건(술어)과 조합/다중 사용 시 에러(1221)**가 발생했습니다 (공식 문서는 WHERE + ORDER BY를 통한 관련도 순 정렬 예시를 보여주므로, 이용 형태는 위 문서를 재확인 필요).
• 벡터 열·전문 인덱스는 TiFlash 레플리카(Replica)가 전제 조건이다. AUTO_RANDOM(주키에 랜덤 값을 자동 채번하여 쓰기 집중을 피하는 TiDB 기능) 주키와의 병용은 가능하다.

4. 1차 정보 ②: TiDB의 「신선도 경계」를 실측하다

「단일 엔진이라면 언제나 최신」이라고 해도, 어디까지 즉시적이고 어디서부터 지연되는가가 실제 구현에서는 중요합니다. 전제로, TiDB는 동일한 테이블을 행 스토어(TiKV) = 쓰기·점 참조용과 열 스토어(TiFlash) = 분석·대규모 벡터용 양쪽 모두에 유지합니다 (HTAP). 신선도의 동작은 이 두 가지에서 다릅니다.

그림 5: HTAP의 이중 유지. 동일한 데이터 1건(예: 상품 A의 재고)이 행 스토어(TiKV)와 열 스토어(TiFlash) 양쪽에 유지된다. 업데이트는 먼저 행 스토어에 즉시 반영되고, 열 스토어에는 조금 늦게 동기화된다. 이 「읽는 위치에 따른 반영 타이밍의 차이」가 다음에 측정할 신선도 경계의 정체이다.

스키마는 다음과 같이 작성합니다:

(리포지토리의 sql/schema_rt.sql은 동기 비교용으로 products_live / products_snapshot 두 테이블로 구성되어 있습니다. 아래는 요점을 한 테이블로 간략화한 것입니다. 명시적 ID로 투입하기 위해 주키는 AUTO_RANDOM이 아닌 순수 BIGINT PRIMARY KEY입니다.)

CREATE TABLE products (
product_id BIGINT PRIMARY KEY,
name VARCHAR(128),
...

그림 6: 업데이트 후, 점 참조(TiKV 행 스토어)는 즉시. 분석/대규모 벡터(TiFlash 열 스토어)는 ≈142ms의 동기화.

• 점 참조(TiKV 행 스토어) = 즉시. 재고를 0으로 업데이트한 순간 검색에 반영 (read-your-writes = 쓰기 직후에 읽어도 반드시 최신값이 반환됨을 보장. 5/5 케이스에서 확인). update+read 왕복은 중앙값 ≈331ms이지만, 이는 us-west-2로의 네트워크 RTT(Round-Trip Time)가 대부분이며 엔진 지연이 아니다.
• TiFlash 열 스토어의 동기화 지연 ≈ 142ms.

측정 방법(재현용): 행을 업데이트 → /*+ read_from_storage(tiflash[...]) */로 열 스토어를 강제하고, 새로운 값이 반환될 때까지 100ms 간격으로 폴링(Polling) → 반영 시간을 기록. n=3에서 142ms (입도(Granularity)가 100ms이므로 실제 지연은 수십ms). 1개 환경에서의 소수 회 측정값이므로 절대값은 환경에 의존한다. 설계 시에는 「점 참조=즉시 / 분석계=~0.1s급」이라는 자릿수 감각을 사용하십시오.

⚠️ §2의 「라이브=0%」와의 정합성 (중요)

엄밀히 말하면 「라이브 참조」도 지연 시간이 0은 아닙니다. TiFlash를 통한 벡터/전문(Full-text) 읽기에는 위에서 측정한 ~0.1s 급의 신선도 경계가 존재합니다. §2에서 0%가 된 이유는 재고 질문을 **점 참조(TiKV)**로 측정했기 때문이며, 질문 간격이 동기화 창(Synchronization window)보다 충분히 길었기 때문입니다. 따라서 올바른 비교는 다음과 같습니다:

라이브 ＝ 0.1s 급의 신선도 경계 vs 동기형 ＝ 분시간 단위의 동기화 간격 (본 검증의 동기화 간격은 「업데이트 N건마다」로 정의. 업데이트가 매 분 수 건 발생한다면 @20은 수 분 간격에 해당) ── 즉, 자릿수 차이(업데이트 속도에 따라 대략 3자리 규모)가 발생하는 차이

이것이 본 기사의 정량적인 주장입니다.

「신선도 지연 시간 0」은 점 참조의 즉시성을 의미하며, 분석계에는 위의 경계가 있다고 이해해 주십시오.

설계 지침

• 「재고 있어?」와 같이 신선도가 민감한 점 참조는 행 스토어(TiKV)에 가깝게 ＝ 즉시성.
• 대규모 벡터 검색·분석 집계는 열 스토어(TiFlash)를 경유하여 ~0.1s 급의 동기화를 허용한다는 전제로 설계한다.
• 최신 상태 × 의미 검색을 하나의 쿼리로 (직전에 재고가 0이 된 상품은 즉시 제외):

SELECT product_id, name, stock,
VEC_COSINE_DISTANCE(emb, ?) AS dist -- ?=질문문의 임베딩. dist가 작을수록 의미가 가까움
FROM products
...

주의:

WHERE 절로 필터링하면서 ORDER BY VEC_COSINE_DISTANCE를 수행할 경우, HNSW(근사 최근접 이웃 탐색 알고리즘) 인덱스가 작동할지는 필터링의 선택도(Selectivity)나 버전에 따라 달라집니다. 본 검증 규모에서는 풀 스캔(Full Scan)이라도 문제가 없으나, 대규모 시에는 EXPLAIN을 통해 실행 계획(인덱스 사용 여부)을 확인하십시오.

5. 설계 판단: 단일 엔진으로 구성할 것인가 (왜 TiDB인가)

• 그림 4에서 본 신선도의 승리는 「단일 엔진화」의 승리이며, 이는 TiDB에 국한된 것이 아닙니다. 원본 데이터와 동일한 DB에 벡터를 두면, Postgres+pgvector로도 동일한 그림을 그릴 수 있습니다.
• 그렇다면 TiDB를 선택하는 이유 (측정으로 뒷받침되는 범위):
  • 분산·서버리스 환경에서의 read-your-writes 보장: curl 한 번으로 생성하는 일회성 클러스터(TiDB Cloud Zero)에서 벡터 + 전문 + SQL + ACID + 점 참조의 즉시성을 단일 연결로 갖출 수 있습니다 (동기화 작업이나 별도의 OLAP도 불필요).
  • 단일 스테이트먼트(Statement)로 「최신 상태 필터 × 벡터 × 전문」 작성이 가능합니다 (조합 불필요, §4의 SQL).
  • 향후 스케일 업 시 동일한 SQL 그대로 HTAP/수평 확장(Horizontal Scale)으로 확장 가능합니다 (아키텍처 재설계 불필요).

HTAP의 우위를 측정했으나, 본 검증 규모에서는 나타나지 않음

「열 스토어라면 대규모 집계가 빠를 것」이라 기대하며, 50k~500k 행 규모로 집계 레이턴시(Latency)를 측정했습니다.

그림 7: GROUP BY 집계. 이 규모/환경에서는 열 스토어의 명확한 우위가 나타나지 않음 (속도비는 노이즈 영역).

• 본 검증의 규모와 환경에서는 HTAP의 명확한 우위가 나타나지 않았습니다.

원인: 집계가 가볍고(GROUP BY 5개 카테고리), 레이턴시는 네트워크 RTT(Round Trip Time) 지배적(200-400ms)이며, 무료 클러스터의 소규모 TiFlash를 사용했기 때문입니다. 따라서 본 기사는 「TiDB는 HTAP에서 빠르다」라고 주장하지 않습니다.

HTAP의 우위는 수백만 행 및 무거운 분석의 영역이며, 본 검증의 범위를 벗어납니다(향후 검토 사항). 우위가 나타나지 않은 결과도 그대로 기재하였습니다.

간섭 내성: 병행 업데이트 중에도 검색 레이턴시는 저하되지 않았다

집계의 절대 속도에서는 차이가 나지 않았지만, HTAP의 본질은 **「쓰기(OLTP)와 분석·벡터 읽기(OLAP)가 서로 간섭하지 않는 것」**입니다. 이에 주제와 직결되는 방식으로, 재고 업데이트를 병행하여 흘려보내면서 라이브 RAG 검색의 레이턴시(각 조건 n=40회)를 측정했습니다. 단일 연결의 writer(쓰기를 보내는 쪽)는 네트워크 RTT 제약으로 인해 초당 수 건밖에 쓸 수 없으므로, writer를 병렬 연결(4/12 스레드)로 구성하여 실효 쓰기 속도를 실측치 기준 0 → 28 → 85 updates/sec까지 끌어올려 비교하였습니다.

그림 8: 실효 쓰기 부하를 0→28→85 updates/sec로 높여도, 라이브 RAG 검색의 p50은 평탄(157→158→151ms)하며, p95도 저하되지 않는다.

주석: 무부하(0/sec)에서 p95가 349ms로 가장 높은 것은, 측정 순서상 첫 번째 조건이었기 때문에 연결이나 캐시가 예열되기 전(Cold Start)의 영향을 포함했기 때문입니다. 부하를 가한 조건에서는 p95가 오히려 188~209ms 범위 내로 유지되었습니다. 핵심은 「실효 ~85 업데이트/sec까지 올려도 읽기 레이턴시(Latency)가 악화되지 않는다」는 점입니다. 수백 업데이트/sec급의 고부하 검증은 향후 과제입니다.

*그림 9: 「조합형」 구성(왼쪽, 동기 지연 있음)과 단일 엔진(오른쪽). 「신선도 제로 지연」은 점 참조의 즉시성을 의미한다(분석계는 §4의 신선도 경계).

(임의) mem9로 사용자 문맥을 기억하여 개인화하기

TiDB 위에 구축된 에이전트용 장기 기억 mem9를 병용하면, 라이브 재고 답변에 「사용자의 관심사·과거 문의 내용」을 반영할 수 있습니다(본 기사의 주제인 신선도와는 별개의 축이지만, TiDB 생태계의 한 사례입니다).

from expagent.mem9 import Mem9
mem = Mem9() # MEM9_API_KEY로 활성화 (api.mem9.ai or self-host)
mem.store("시부야구 거주·방재와 육아에 관심. 이전에 무선 이어폰을 문의함", labels=["user-profile"])
...

실제로 MEM9_API_KEY를 설정하여 구동한 실제 로그(발췌):

mem9 store -> {'status': 'accepted'}
mem9 search -> {'memories': [{'content': 'The user is interested in disaster prevention
and child-rearing information.', 'memory_type': 'insight', ...}]}
...

여기서도 1차 정보가 2가지 있습니다:

• mem9는 입력을 사실 추출하여 정규화하여 저장합니다 (일본어 문맥 → memory_type: insight 형태의 영어 지식으로 변환. 검색은 일본어 쿼리로도 교차 히트 가능).
• store 직후의 검색은 비어 있으며, 수 초 후에 검색이 가능해집니다 ── mem9에도 「쓰기→색인화(Indexing)」의 지연 경계가 존재하며, 이는 본 기사의 신선도 테마와 일치합니다 (store는 {'status':'accepted'} = 비동기 수락).

신선도의 주요 결과(§2~4)는 mem9와 무관합니다. mem9는 개인화를 위한 부가가치로서 병용하고 있습니다.