Data Enablement for AI: 레이크하우스를 에이전트가 믿고 쓸 데이터 기반으로 바꾸는 6가지 설계
에이전트와 RAG가 운영 단계에서 막히는 이유를 프롬프트가 아닌 데이터 기반에서 찾고, 변경분만 재임베딩하는 CDC, 표를 살리는 문서 파싱, LLM 대신 SQL을 만드는 시맨틱 레이어, 검색 전 권한 필터 등 6가지 패턴을 정리한 실무 가이드입니다. 필드 설계, 합격 시험, 6주 파일럿 순서를 덧붙였습니다.
에이전트가 틀린 숫자를 말하거나 권한 밖 문서를 꺼내는 문제는 대개 프롬프트가 아니라 데이터 기반에서 생깁니다. 저자는 이를 여섯 가지 설계로 고치자고 제안합니다. 바뀐 것만 다시 임베딩하고, 문서를 구조째 읽고, SQL은 인증된 지표 정의로 만들고, 실시간 상태는 메모리에서 읽고, 권한은 검색 전에 걸고, 넣기 전에 걸러 내는 것입니다. 시작은 비용이 낮은 권한 필터와 지표 계층이 무난합니다.
요약
Towards Data Science에 실린 Partha Sarkar의 글(2026년 10월 25일)은 기업 AI가 시범 운영을 넘지 못하는 공통 원인을 데이터 쪽에서 찾습니다. 데이터에 접근하기 어렵고, 깨끗하지 않고, AI가 바로 쓸 만큼 구조화돼 있지 않다는 것입니다. 저자는 에이전트와 RAG(검색 증강 생성)가 기존 데이터 플랫폼의 가정 네 가지를 깬다고 봅니다. 표 대신 문서·로그·그래프에서 맥락을 읽고, 밤사이 배치로는 늦으며, 테이블 권한은 벡터 검색을 막지 못하고, 날것의 스키마를 보면 LLM이 조인과 지표 정의를 지어냅니다. 대응책으로 AI-ready data fabric(AI가 쓸 수 있는 데이터 기반)의 네 기둥을 세웁니다. 이벤트 기반 동기화, 멀티모달 구조 추출, 통제된 의미 계층, 계보와 권한의 zero-trust(아무것도 기본으로 믿지 않는 보안 원칙)입니다. 그 위에 여섯 가지 설계 패턴을 올립니다.
여섯 패턴은 각각 흔한 안티패턴 하나를 겨냥합니다. 밤마다 벡터 인덱스를 다시 만드는 대신 변경분만 반영하고, 글자 수로 자르는 대신 문서를 트리로 읽습니다. LLM이 SQL을 쓰게 두지 않고 지표 요청만 내게 하며, 빠르게 바뀌는 상태는 벡터가 아니라 메모리에 둡니다. 권한은 검색 결과를 받은 뒤가 아니라 검색 전에 걸고, 인덱스에 넣기 전에 잡음과 중복을 걸러 냅니다. 저자는 재임베딩 비용을 85~95% 줄인다고 주장하지만, 이는 경험에서 나온 수치이고 벤치마크는 제시하지 않았습니다. 비용 비교에서는 시맨틱 레이어와 권한 필터가 가장 쌉니다. 아래에서는 여섯 패턴이 어떻게 작동하는지 풀고, 실제로 돌릴 때 필요한 필드와 시험, 일정을 덧붙였습니다.
핵심 메커니즘
Event-Driven Dual-Speed Pipeline: 바뀐 글만 다시 임베딩하는 동기화
CDC(change data capture, 데이터베이스의 변경 기록을 읽어 이벤트로 흘리는 방식)로 원천의 변경을 실시간으로 받아, 벡터 저장소와 지식 그래프를 함께 갱신하는 구조입니다. 변경 이벤트가 들어오면 라우터가 정규화한 본문의 SHA-256 해시를 캐시와 비교합니다. 조회수나 수정 시각만 바뀌어 해시가 같으면 재임베딩을 건너뛰고, 본문이 바뀌었으면 그 chunk만 다시 임베딩해 원자적으로 덮어씁니다. 원천에서 삭제되면 tombstone(삭제 표시) 이벤트가 나가고, 삭제 엔진이 원래 레코드 키에 딸린 chunk ID를 찾아 벡터와 그래프 간선까지 지웁니다. 저자가 든 도구는 Kafka, Debezium, Redis입니다.
CRM, 가격, 재고, 정책 문서, 티켓처럼 자주 바뀌는 원천에 맞습니다. 신선도가 하루에서 초 단위로 당겨지고, GDPR 제17조·CCPA 삭제 요청도 AI 저장소까지 내려갑니다. 스트리밍 인프라가 필요하고, 메시지가 순서를 바꿔 도착하면 시각 비교로 옛 이벤트를 걸러야 합니다. 가상 예시로, 구매팀이 단가표를 고치면 바뀐 품목 행의 chunk만 다시 임베딩됩니다. 단종 처리한 품목은 몇 초 안에 검색에서 빠집니다.
Hierarchical Semantic Parser: 표와 상위 제목을 살려 두는 문서 파싱
문서를 평문이 아닌 AST(abstract syntax tree, 구조를 계층으로 표현한 트리)로 다루는 수집 방식입니다. 흔한 방식은 PDF를 글자로 풀고 512자 같은 고정 창으로 자릅니다. 그러면 표의 행이 여러 chunk로 흩어지고, 조항은 자신이 속한 절 제목과 떨어집니다. 저자의 방식은 vision-language 레이아웃 모델로 제목, 문단, 다단, 표, 그림을 먼저 식별합니다. 그다음 요소마다 상위 경로 전체(breadcrumb)를 물려줍니다. 표는 Markdown이나 JSON 행렬로 직렬화하고, 차트는 멀티모달 모델이 요약문으로 바꿉니다.
재무 공시(10-K, 10-Q), 임상시험 보고서, 계약서, 설계 사양서처럼 표와 조항이 의미를 쥔 문서에 씁니다. 대가는 수집 속도와 GPU입니다. 저자에 따르면 쪽당 몇 초가 걸립니다. 표 관계를 100% 보존한다는 주장에도 벤치마크는 없습니다. 가상 예시로, 품질 사양서의 ‘허용 공차’ 표가 ‘3.2 외관 검사’ 절 아래 통째로 남아야 에이전트가 다른 절의 공차와 섞지 않습니다.
Governed Semantic Layer: LLM은 지표를 요청하고, SQL은 컴파일러가 만든다
AI 모델과 웨어하우스 사이에 지표 엔진을 두는 구조입니다. LLM은 인증된 지표와 허용 차원 목록을 받아 metrics, dimensions, filters로 이뤄진 typed JSON intent(타입이 정해진 요청)만 냅니다. 엔진은 승인된 산식과 검증된 조인 경로를 찾아 필수 업무 필터를 넣습니다. 데이터 단위와 실행 한도도 적용한 뒤 SQL을 컴파일합니다. 저자의 예에서는 활성 계약만 남기고 체험판과 환불 건을 빼는 조건이 지표 정의 안에 들어 있습니다. 그래서 LLM이 이 조건을 잊을 수 없습니다. 도구로는 dbt Semantic Layer와 Cube를 듭니다.
이 패턴의 핵심 동작은 답하지 않는 경우에 있습니다. 질문이 인증된 지표 두 개 사이에서 모호하면 에이전트가 되묻고, 정의되지 않은 데이터면 거절한 뒤 분석팀에 모델링 요청을 넣도록 안내합니다. 경영 보고, 셀프 BI, 고객용 분석 에이전트에 맞습니다. 지표 계층을 꾸준히 관리해야 하고, 새 질문은 정의가 생길 때까지 기다려야 합니다. 캐시된 지표는 50ms 안에 답하고(저자), 폭주하는 조인으로 웨어하우스 비용이 튀는 일도 막습니다.
Operational Context Store: 자주 바뀌는 상태는 메모리에서 읽어 넣는다
에이전트가 프롬프트를 조립할 때 인메모리 online feature store(실시간 피처 저장소)에서 현재 상태를 읽어 오는 구조입니다. 스트림 엔진(Kafka, Flink)이 슬라이딩 윈도 집계를 계속 계산해 Redis 같은 저장소에 씁니다. 모니터링 루프, 이벤트 임계값, 사용자 요청 중 하나가 에이전트를 깨우면, context assembler가 대상의 현재 상태를 가져와 구조화된 블록으로 프롬프트에 넣습니다. 그다음에야 추론이 시작됩니다. 저자는 상태 조회 5ms 미만을 기준으로 듭니다. 웨어하우스 왕복은 2~5초여서 5단계 에이전트 루프면 25초를 넘길 수 있다고 대비합니다.
사기 탐지, 실시간 상담, 동적 가격, 물류 경로, 보안 분류처럼 몇 초 사이에 판단이 바뀌는 업무에 씁니다. 장바구니, 장비 카운터, 사기 점수 같은 값을 벡터에 계속 덮어쓰면 인덱스 계산이 CPU를 다 씁니다. 저자가 이 패턴을 따로 둔 이유입니다. TTL(유효 시간)을 강제해 낡은 상태가 프롬프트에 들어가지 않게 하는 것도 장점입니다. 메모리는 기가바이트당 비싸므로 판단에 쓰는 피처만 올립니다.
Lineage-Preserving Security Fabric: 원천 권한을 chunk에 붙여 검색 전에 거른다
원천 시스템의 ACL(접근 권한 목록)과 데이터 등급을 수집 단계에서 뽑아, 모든 벡터와 그래프 노드에 바꿀 수 없는 메타데이터로 붙이는 구조입니다. 질의가 오면 서명된 JWT(사용자 신원 토큰)에서 검증된 그룹과 등급을 읽습니다. 그다음 벡터 거리를 계산하기 전에 인덱스 단계에서 후보를 그 권한 안으로 좁힙니다. 권한 밖 chunk는 후보에도 오르지 않습니다. 기존 RBAC·ABAC·행 단위 보안과 Okta, Azure AD 같은 신원 체계를 그대로 물려받습니다. 필터를 지원하는 HNSW나 IVF 인덱스가 필요합니다.
저자는 검색 후에 거르는 방식의 실패를 두 가지로 설명합니다. 하나는 empty-result cascade(빈 결과 연쇄)입니다. 가장 관련 있는 chunk가 모두 제한 문서였다면 남은 약한 조각만 모델에 가고, 모델은 그런 규정이 없다고 잘못 답합니다. 다른 하나는 응답 시간과 동작 차이로 기밀 프로젝트의 존재를 추측하게 하는 부채널 누출입니다. 인사 파일, 감사 자료, 환자 기록, 멀티테넌트 저장소를 다루는 비서라면 기본이고, 대가는 늘어나는 인덱스 저장 공간입니다.
Autonomous Curation Flywheel: 넣기 전에 거르고, 합치고, 질문을 붙인다
인덱스에 넣기 전에 단계별로 품질을 다듬는 수집 파이프라인입니다. 1단계에서 작은 전용 모델이 정보량, 문법, 사실 밀도를 밀리초 단위로 채점해 에러 로그나 일정 초대 같은 잡음을 버립니다. 저자는 기업 데이터의 최대 40%가 여기서 걸러진다고 봅니다. 2단계에서 새 chunk가 기존 권위 문서와 크게 겹치면 새 벡터를 만들지 않고 계보 정보만 고칩니다. 저자가 든 기준 예는 95% 중복입니다. 3단계에서 8B 규모로 미세조정한 작은 모델이 chunk마다 그 내용이 답하는 현실적인 사용자 질문 3~5개를 만듭니다. 이 질문을 chunk와 함께 임베딩해, 사용자 질의가 원문보다 질문과 맞물리게 합니다.
SharePoint, Confluence, 오래된 지원 티켓, 공용 메일함처럼 크고 지저분한 저장소에 맞고, 기술 문서 작성자와 묻는 경영진의 어휘 차이를 줄여 줍니다. 저자는 전체 말뭉치를 다루기에는 프런티어 모델이 너무 비싸 작은 모델을 쓴다고 설명합니다. 평가 기준표와 작은 모델을 띄울 환경을 먼저 마련해야 하고, 합성 질문이 현실적인지와 환각이 없는지를 계속 감시해야 합니다.
통념과 다른 주장
흔히 이렇게 봅니다테이블 스키마와 몇 가지 예시를 주면 LLM이 SQL을 써서 데이터 질문에 답할 수 있고, 정확도는 프롬프트를 다듬어 올린다.
저자는 이렇게 봅니다LLM이 SQL을 쓰게 두지 않습니다. 모델은 인증된 지표를 요청만 하고, 결정론적 컴파일러가 승인된 정의로 쿼리를 만듭니다. 모호하면 되묻고, 정의가 없으면 거절합니다.
근거날것의 테이블에는 적히지 않은 업무 규칙(활성 계약만, 체험판·환불 제외)이 있어 모델이 추론할 수 없습니다. 지난 분기 매출을 물으면 총예약액과 회계 기준 매출 중 무엇인지부터 정해야 합니다.
흔히 이렇게 봅니다테이블 권한이 잡혀 있으면 충분하고, 벡터 검색 결과는 애플리케이션에서 권한을 확인해 걸러 내면 된다.
저자는 이렇게 봅니다원천 ACL을 chunk에 붙여 두고 검색 전에 후보를 제한해야 합니다. 검색 후에 거르면 답이 틀어지고 정보가 샙니다.
근거벡터 검색은 뜻이 비슷하면 권한과 무관하게 제한 문서를 찾아옵니다. 그 문서를 뒤에서 빼면 약한 근거만 남아 규정이 없다는 오답이 나오고, 응답 시간 차이로 기밀의 존재가 드러납니다.
저자가 든 사례
저자는 특정 회사의 도입 사례 대신, 패턴이 없으면 무엇이 깨지는지 보여 주는 장면을 듭니다. 아래는 그 장면을 패턴 순서로 묶은 것입니다.
기밀 메모 삭제: 지운 것은 AI에서도 지워져야 한다
- 상황: 인사팀이 기밀 퇴직 위로금 메모를 지우거나, 기업 고객이 계정을 닫거나, 드라이브에서 파일이 삭제됩니다.
- 한 일: tombstone 이벤트로 딸린 chunk와 그래프 간선을 함께 지웁니다. 메모가 남아 있는 동안에는 권한 필터가 일반 직원의 질문에서 이 문서를 후보로 올리지 않습니다.
- 결과: 삭제가 AI 저장소까지 내려가고 감사 기록이 남습니다. 반영 시간의 실측치는 원문에서 밝히지 않았습니다.
- 연결: 패턴 1(CDC)과 패턴 5(권한 필터).
조항 4.2의 위약금 한도: 상위 절을 잃으면 뜻이 바뀐다
- 상황: 1만 달러 한도 조항이 무엇에 대한 한도인지는 상위 절(비밀유지 위반)에 적혀 있습니다. 대차대조표 행이 chunk 사이로 쪼개지는 것도 같은 문제입니다.
- 한 일: 조항 chunk에 상위 절 경로를 붙이고 표는 행렬로 직렬화합니다.
- 결과: 한도와 그 대상이 함께 검색됩니다. 정확도 수치는 원문에서 밝히지 않았습니다.
- 연결: 패턴 2(문서 파싱).
매출 질문 세 가지: 답하고, 되묻고, 거절한다
- 상황: 지역·분기별 순 ARR(연 반복 매출) 질문, 뜻이 모호한 지난 분기 매출 질문, 모델링되지 않은 지원 채팅 길이 질문.
- 한 일: 첫째는 지표 요청으로 컴파일하고, 둘째는 두 인증 지표 중 무엇인지 되묻고, 셋째는 거절한 뒤 모델링 요청으로 돌립니다.
- 결과: 숫자는 인증된 정의에서만 나옵니다.
- 연결: 패턴 3(시맨틱 레이어).
15분 거래 급증과 접대비 규정: 실시간 상태와 어휘 차이
- 상황: 사기 탐지 에이전트는 최근 15분 거래 수를, 운영 에이전트는 세션 오류 횟수나 물류센터 SKU 재고를 알아야 합니다. 직원은 APAC 고객 접대비 환급 여부를 묻습니다.
- 한 일: 앞은 메모리에서 상태를 읽어 카드를 막거나 트래픽을 대기 서버로 돌리고, 뒤는 미리 만든 합성 질문이 사용자 질문과 맞물립니다.
- 결과: 효과를 잰 실측 사례는 원문에서 밝히지 않았습니다.
- 연결: 패턴 4(상태 저장소)와 패턴 6(정제).
기술 디테일: 여섯 패턴을 한 번에 엮어 돌리려면
아래는 글의 패턴을 기업 데이터 플랫폼에 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드명과 숫자는 가상 예시입니다.
chunk 메타데이터 하나로 패턴 1·2·5·6을 묶으려면 모든 chunk가 같은 스키마를 갖게 합니다. 동기화에는 source_pk·source_lsn·content_hash, 구조에는 breadcrumb, 권한에는 acl_groups·classification, 정제에는 quality_score·synthetic_questions를 둡니다. 한 필드라도 비면 인덱스에 넣지 않고 격리 큐로 보냅니다. 특히 acl_groups가 빈 chunk는 공개로 간주하지 말고 막아야 합니다.
{
"chunk_id": "contract-8812#s4#s4.2#tbl1",
"source_pk": "clm.contracts:8812",
"source_lsn": 18822931,
"content_hash": "sha256:9f2c…",
"breadcrumb": ["공급계약_2026.pdf", "4. 위약", "4.2 손해배상 한도", "표 1"],
"acl_groups": ["legal", "procurement-lead"],
"classification": "confidential",
"quality_score": 0.82,
"synthetic_questions": ["납기 지연 위약금 상한은 얼마인가", "4.2조 한도는 비밀유지 위반에도 적용되나"]
}
CDC 워커의 순서를 정하려면 순서 검사를 해시 검사보다 앞에 둡니다. 들어온 source_lsn이 저장된 값보다 작거나 같으면 늦게 도착한 옛 이벤트이므로 버립니다. 그다음 해시가 같으면 끝내고, 다르면 바뀐 chunk만 재임베딩합니다. 삭제를 위해서는 source_pk → chunk_id[] 대응표를 따로 둡니다. 이 표가 없으면 tombstone이 와도 지울 대상을 찾지 못합니다. 운영 지표로 ‘삭제 요청부터 검색 불가까지 걸린 시간’을 재고, 가상 기준으로 60초를 넘으면 경보를 냅니다.
시맨틱 레이어의 intent를 받으려면 LLM 호출에 구조화 출력(JSON 스키마)을 걸고, 허용 지표와 차원을 enum으로 박아 둡니다. 목록에 없는 이름은 스키마 단계에서 거절됩니다. 출력에는 metrics, dimensions, filters(field·operator·value) 외에 clarify(되물을 선택지)와 unsupported(거절 사유) 두 칸을 더 둡니다. 그래야 되묻기와 거절이 코드 분기로 처리됩니다. temperature는 0으로 두고, 같은 질문을 3회 호출해 intent가 다르면 되묻기로 보냅니다. 지표 정의에는 name, type, sql, filter, joins와 함께 소유 부서와 인증 날짜를 적어, 숫자마다 어느 정의에서 나왔는지 답변에 붙입니다.
권한 필터를 검증하려면 권한이 낮은 테스트 계정으로 제한 문서의 내용을 겨냥한 질문 50개를 만들어 매 배포 때 돌립니다. 합격선은 노출 0건입니다. 빈 결과 연쇄를 막으려면 권한 안 후보가 기준 점수 아래일 때 ‘모른다’와 ‘접근 가능한 자료에 없다’를 구분해 답하게 합니다. 에이전트가 사용자 대신 도구를 부를 때도 같은 JWT를 넘겨 권한이 넓어지지 않게 합니다.
실시간 상태와 정제 단계의 값을 정하려면 상태 피처마다 TTL을 윈도 길이와 맞춥니다. 15분 윈도 피처라면 TTL도 15분입니다. 프롬프트에는 entity_id, as_of, 피처 값을 담은 블록으로 넣어 모델이 시각을 보고 판단하게 합니다. 정제 단계에서는 quality_score 하한과 중복 기준(저자 예시 95%)을 표본 200건을 사람이 판정한 결과로 맞춥니다. 합성 질문은 주 50개를 뽑아 실제 질문과 비슷한지, 원문에 없는 내용을 묻지 않는지 검토합니다. 효과는 실제 사용자 질문 200개의 recall@5(상위 5개 안에 정답 chunk가 드는 비율)를 정제 전후로 비교해 잽니다.
실패하는 경우와 대응. 원천 ACL이 사람마다 예외로 얽혀 있으면 chunk 메타데이터로 옮길 수 없습니다. 이때는 그 원천을 첫 파일럿에서 빼고, 권한 정리를 먼저 요청합니다. 지표 정의가 부서마다 다르면 시맨틱 레이어가 거절만 반복하므로, 가장 많이 묻는 지표 10개부터 소유 부서를 정해 인증합니다. 스캔이 흐린 문서는 표 chunk에 파싱 신뢰도를 남기고, 기준 아래면 원본 페이지 이미지를 함께 보여 줍니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 6주 동안 하는 일 |
|---|---|---|
| 스폰서 | CIO 또는 CDO | 대상 에이전트 1개와 원천 범위 승인 |
| 데이터 플랫폼 | 엔지니어 2명 | CDC 연결, chunk 스키마, 인덱스 필터 |
| 분석 엔지니어 | 1명 | 지표 10개 정의, 시맨틱 레이어 연결 |
| 지표 소유자 | 재무(FP&A)·영업기획 각 1명 | 지표 정의 인증, 확정치 30개 제공 |
| 보안·IAM | 1명 | 원천 ACL 정리, 유출 시험 질문 50개 |
| 문서 소유자 | 법무·인사 각 1명 | 계약서·규정 표본, 삭제 시나리오 |
시작 전 준비물: 에이전트가 지금 받는 실제 질문 200개(익명화), 자주 쓰는 지표의 현재 정의서와 산식, 대상 원천 목록과 원천별 권한 체계, 최근 삭제 요청 처리 절차, 현재 RAG 인덱스의 재구축 주기와 월 임베딩 비용입니다.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 현재 파일럿을 다섯 안티패턴으로 점검 | 안티패턴 점검표 |
| 2~3주 | 원천 ACL을 chunk에 적재, 유출 시험 | 유출 시험 결과(노출 건수) |
| 2~4주 | 지표 10개 정의·인증, 에이전트에 연결 | 지표 사전, 확정치 일치율 |
| 4~5주 | 원천 1개 CDC 연결, 계약서 표 파싱 | 삭제 반영 시간, 비용 비교 |
| 6주 | 판정 회의 | 확대 범위 결정서 |
담당자 확인 질문: 에이전트가 답한 숫자 중 재무 확정치와 다르게 나온 적이 있습니까, 그 지표의 공식 정의는 누가 갖고 있습니까? 원천 시스템에서 문서를 지우면 지금 AI 인덱스에서는 언제 사라집니까? 권한이 개인 단위 예외로 얽힌 저장소는 어디입니까? 표가 핵심인 문서는 어떤 종류이고 월 몇 건 들어옵니까? 몇 초 안에 판단이 바뀌어야 하는 업무가 실제로 있습니까?
진행 판정 기준(예시): 유출 시험 노출 0건, 인증 지표 확정치 일치 100%, 삭제 반영 60초 이내를 모두 넘으면 원천과 에이전트를 넓힙니다. 하나라도 못 넘으면 그 패턴만 2주 더 돌립니다. 지표 정의를 인증할 소유자를 정하지 못하면 시맨틱 레이어는 미루고 권한 필터부터 확대합니다.
AX 적용 제언. 먼저 지금 돌고 있는 RAG·에이전트 파일럿을 다섯 안티패턴으로 점검하는 것이 가장 싼 출발점입니다. 순서는 원문이 정하지 않았으므로 여기서 제안합니다. 원문 비교에서 비용이 낮은 권한 필터와 시맨틱 레이어를 먼저 놓고, 스트리밍 인프라가 드는 CDC, GPU가 드는 문서 파싱을 다음에 둡니다. 정제는 인덱스가 커진 뒤, 실시간 상태 저장소는 사기·가격·물류처럼 초 단위 판단이 있는 업무에만 붙입니다. 현업 스폰서는 숫자를 쓰는 부서(재무·영업기획)에서 세우는 편이 낫습니다. 지표 정의를 인증할 사람이 그 부서에 있기 때문입니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표처 | Towards Data Science(2026.10.25), Partha Sarkar |
| 문제 진단 | 에이전트·RAG가 깨는 네 가정: 비정형 맥락, 지연, 벡터 검색의 권한, 스키마 환각 |
| 네 기둥 | 이벤트 기반 동기화, 멀티모달 구조 추출, 통제된 의미 계층, zero-trust 계보·보안 |
| 패턴 1 | CDC + SHA-256 해시, tombstone 삭제. Kafka · Debezium · Redis. 재임베딩 비용 85~95% 절감(저자 주장) |
| 패턴 2 | AST 파싱, breadcrumb 상속, 표 Markdown/JSON 직렬화. 쪽당 몇 초, GPU 필요 |
| 패턴 3 | metrics · dimensions · filters intent, 결정론적 컴파일. dbt Semantic Layer · Cube. 캐시 지표 50ms 미만 |
| 패턴 4 | 스트림 집계 → 인메모리 저장소 → 프롬프트 주입. 조회 5ms 미만, 웨어하우스 왕복 2~5초 |
| 패턴 5 | 원천 ACL 메타데이터, JWT, 사전 필터(filtered HNSW · IVF). HIPAA · SOC 2 · ISO 27001 언급 |
| 패턴 6 | 작은 모델 품질 필터(잡음 최대 40%), 중복 기준 예 95%, 8B 모델로 질문 3~5개 |
| 비교 | 비용 낮음: 패턴 3 · 5 / 비용·복잡도 높음: 패턴 2 / 복잡도 높음: 패턴 4 |
| 안티패턴 | 날것 테이블 노출, 배치 전용 벡터 인덱스, 검색 후 권한 필터, 글자 수 분할, 벡터에 실시간 상태 |
| 수치의 성격 | 저자 경험 기반, 벤치마크 없음 |
핵심 개념
- RAG
- 질문에 맞는 자료를 먼저 검색해 그 내용을 근거로 LLM이 답하게 하는 방식.
- write-ahead log
- 데이터베이스가 변경을 실제 반영하기 전에 순서대로 적어 두는 기록. CDC가 이것을 읽는다.
- breadcrumb
- 문서 안에서 한 요소가 놓인 위치를 상위 제목부터 이어 적은 경로.
- HNSW · IVF
- 벡터 검색을 빠르게 하는 대표적인 인덱스 구조. 필터를 지원하는 변형이 있어야 사전 권한 필터가 가능하다.
- GraphRAG
- 문서 검색에 지식 그래프의 관계를 함께 써서 근거를 찾는 RAG 방식.
- SLM
- small language model. 특정 작업용으로 작게 만들거나 미세조정한 언어 모델.
내 메모
TODO: 내 생각 추가
원문: Partha Sarkar, “Data Enablement for AI: A Practitioner’s Guide to 6 Advanced Architectural Patterns”(Towards Data Science, 2026.10.25). 요약·메커니즘·통념과 다른 주장·저자가 든 장면·원문 사례 표는 글의 내용을 AX Review가 다시 정리했습니다. 원문의 수치는 저자 경험에 따른 것으로 벤치마크가 제시되지 않았습니다. 기술·현업 디테일, chunk 스키마 예시, 합격 시험, 6주 일정·판정 기준, 도입 순서 제안, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체와 코드 예시는 Towards Data Science에서 볼 수 있습니다.