표를 Markdown으로 잘라 벡터DB에 넣으면 되는 거 아닌가
← 전체 목차 · 이전: PDF 문서는 어떻게 처리하는가 · 다음: 문서 QA는 왜 파일명만 봐서는 안 되나
"표를 Markdown으로 바꿔 청킹하고, 프롬프트에 정확히 계산하라고 당부하고, 안 되면 표 전체를 컨텍스트에 통째로 넣는다." 이 세 문장은 전부 **"텍스트 + 모델의 자각"**에 기대고 있다. 그러나 통계·집계·조건 필터링을 묻는 질문 앞에서 이 접근은 구조적으로 무너진다 — 표는 문서가 아니라 데이터이기 때문이다.
왜 "표를 텍스트로 자른다"가 실패하는가
| 실패 지점 | 구체적 증상 |
|---|
| 분할 오정합 | 청킹이 행·열 대응 관계를 잘라 버림 — 조각에 표 헤더가 빠지고 열 이름을 잃는다 |
| 대형 표 오버플로우 | 수십~수백 행이 컨텍스트 윈도우에 들어가지 않는다 |
| 실시간성 부재 | 통계 대상은 DB 안의 살아 있는 데이터이지 정적 문서가 아니다 |
| 실행 안전 리스크 | 모델에 직접 SQL 실행 권한을 주면 슬로 쿼리·오조작·전체 스캔 위험 |
| 스키마 드리프트 | 업무 테이블 필드가 자주 바뀌면 생성된 SQL이 계속 실패 |
절단 입도의 딜레마는 파라미터 조정 문제가 아니라 노선 자체의 오류다. 작게 자르면 행·열 관계가 끊기고, 크게 자르면 컨텍스트에 안 들어간다 — 이 축 위에서는 균형점이 존재하지 않는다. 해법은 "표를 텍스트로 자르는" 전제를 버리는 것이다.
핵심 전환: 색인 대상을 "데이터"에서 "데이터에 대한 설명"으로 옮긴다
잘못된 노선 올바른 노선
──────────── ────────────
표 원본 데이터를 통째로 청킹 표 구조 + 필드 주석 + 업무 의미만 색인
↓ ↓
행·열 관계가 절단당함 벡터 검색은 "어느 표·어느 열을 봐야 하는가"만 담당
↓ ↓
모델이 텍스트에서 수치를 눈짐작 질의 시 해당 범위 데이터를 그때그때 조회
↓ ↓
계산 오류 / 답변 실패 집계는 전부 DB 엔진이 실제 계산
기준 아키텍처: 의미 라우팅 분류 + 이중 경로 검색 + 안전 실행 엔진
| 구성요소 | 역할 |
|---|
| 질문 분류 라우팅층 | 사실형 문서 질문 → 순수 텍스트 벡터 경로 / 통계·조건 질문 → 구조화 데이터 경로로 자동 분기 |
| 구조화 데이터 계층 모델링 | 표 원본은 전량 청킹하지 않고, 표 구조·필드 주석·업무 의미만 의미 색인. 조회 시 해당 범위만 필요시 로딩 |
| 독립 안전 실행 엔진 | 읽기 전용 권한·쿼리 타임아웃·반환 행수 상한을 강제. 고위험 쿼리문·전체 스캔 자동 차단. 모든 쿼리는 이 엔진을 통해서만 실행되고 모델은 직접 계산하지 않는다 |
| 소급 표기(소급) | 실행 결과에 데이터 출처와 소급 태그를 자동 첨부해, 모든 수치가 원본 표 필드로 역추적 가능 |
생산 이상 처리 — 상용화의 마지막 한 겹
| 상황 | 대응 |
|---|
| 쿼리문 생성 실패 | 자동 재작성 재시도 |
| 쿼리 실행 실패 | 정적 표 조각 답변으로 강등, "참고용" 라벨 부기 — 서비스는 끊지 않되 강등 상태를 숨기지 않는다 |
| 업무 DB 링크 장애 | 정적 스냅샷 검색 모드로 강등, "실시간 아님" 명시. 복구 후 이력 질의를 소급 보정 |
| 스키마 드리프트 | 메타데이터 자동 동기화 — 표 구조·필드 주석·열거값을 정기적으로 재수집해 의미 색인 갱신, 수작업 매핑 유지 불필요 |
모니터링 4지표: 쿼리문 생성 정확률 / 실행 실패율 / 슬로 쿼리 비중 / 수치 검증 통과율 — 이상 시 자동 경보.
핵심 통찰
- 정확도는 프롬프트 문제가 아니라 실행 권한 귀속 문제다 — "모델이 더 정확히 계산하게" 만드는 모든 접근은 결국 확률적 생성기에게 결정론적 계산을 맡기는 것이다. 집계를 데이터베이스에 맡기는 순간 정확도는 확률 문제에서 확정성 문제로 바뀐다.
- 절단 입도의 딜레마는 조정 공간이 아니라 노선 오류의 증상이다 — "표를 텍스트로 자른다"는 전제 자체가 틀렸다는 신호가 바로 이 양자택일이다. 정답은 그 축 위에서 균형점을 찾는 것이 아니라 축을 바꾸는 것 — 스키마만 색인하고 데이터는 필요시 조회한다.
- 색인 대상은 "데이터의 설명"이어야지 "데이터 자체"여서는 안 된다 — 표 구조·필드 주석·업무 의미에 의미 색인을 걸면 벡터 검색은 "어느 표·어느 열을 봐야 하는가"라는 자신이 잘하는 일만 맡고, 정확한 수치는 결정론적 쿼리가 가져온다. 의미 능력과 정확 능력을 각자 제자리에 두는 설계다.
- 안전 경계는 반드시 독립 컴포넌트여야 하며 프롬프트의 한 줄일 수 없다 — 읽기 전용·타임아웃·반환 행수 상한·고위험 문 차단·전체 스캔 차단은 모델이 닿을 수 없는 곳에서 강제되어야 한다. 프롬프트에 쓴 제약은 모델에게 협조를 요청하는 것이지 방어가 아니다.
- 소급 가능성은 구조화 문답의 최소 납품 기준이다 — 모든 수치가 원본 표 필드로 역추적되지 않으면, 업무 담당자는 그 숫자를 근거로 의사결정을 내릴 수 없다. 소급 태그 없는 통계 결과는 맞고 틀리고를 떠나 사용 불가와 같다.
- 스키마 드리프트는 예외가 아니라 상수이며 자동 동기화로 다뤄야 한다 — 업무 필드가 매일 바뀌는 것이 정상이다. 매핑 관계를 사람이 유지보수하는 방안은 두 번째 달에 무너진다. 표 구조·필드 주석·열거값을 정기적으로 재수집해 의미 색인을 자동 갱신하는 것이 지속 가능한 시스템으로 만드는 관건이다.
- 강등 경로의 설계 수준이 "돌아간다"와 "상용화할 수 있다"를 가른다 — 생성 실패 시 재작성 재시도, 실행 실패 시 정적 조각 답변 + "참고용" 표기, 링크 장애 시 스냅샷 검색 + "비실시간" 표기 — 핵심 원칙은 서비스를 끊지 않되 강등 상태를 절대 숨기지 않는 것이다.
- 면접(설계) 질문의 동사에 답이 있다 — "정확도를 어떻게 높이는가"가 아니라 "어떻게 보장하는가"를 물었다면, 답은 조정 기법이 아니라 실행 엔진·검증·모니터링 같은 메커니즘이어야 한다.
엔지니어링 실전 Tips
- "이 숫자는 누가 계산했는가"로 설계를 자가 점검할 것: 답이 LLM이면 아직 설계가 끝나지 않은 것이다. 모든 통계·집계는 실행 엔진의 결과여야 한다.
- prompt의 계산 제약은 "보조"로만 명시할 것: 실제 정확도는 실행 엔진이 실제로 계산하고 조회하는 데 달려 있다는 공감대를 팀 안에 만들어 두지 않으면, 누군가 프롬프트 튜닝을 정확도 방안으로 보고하게 된다.
- 강등에는 반드시 라벨을 붙일 것: "참고용", "비실시간" 표기 없는 강등은 사고다. 사용자가 강등된 데이터를 실시간 데이터로 오인하는 편이 즉각적인 오류 표시보다 훨씬 위험하다.
- 4개 모니터링 지표를 함께 볼 것: 생성 정확률 하락·실행 실패율 상승·슬로 쿼리 비중 증가·수치 검증 통과율 하락은 각각 스키마 드리프트·권한/문법 문제·쿼리 품질 저하·결과 신뢰도 하락이라는 서로 다른 장애 방향을 가리킨다.
- 스키마 동기화는 필드명뿐 아니라 필드 주석과 열거값까지 함께 끌어올 것: 의미 색인은 필드 주석에, 조건 필터링은 열거값에 의존한다. 필드명만 동기화하면 반쪽짜리다.
- 답변 구성은 "경계부터, 방안은 나중에"로: 구조화 RAG가 어디서 실패하는지부터 말하고 기준 아키텍처, 마지막으로 이상 처리를 보태는 순서가 조기 실격을 피한다.
- 더 파고들 방향: 라우팅층 자체의 정확도 확보(오분류 시 이중 경로를 모두 태워 융합할 것인가), 문서 사실과 표 통계가 동시에 걸리는 질문의 결과 융합 전략, 안전 실행 엔진의 구체 형태(읽기 전용 계정 vs 쿼리 화이트리스트 vs AST 수준 문법 검증 vs 행 단위 권한), 수치 검증 통과율을 라벨 없는 프로덕션 환경에서 지속 측정하는 방법.