008_The Death of “Flat” RAG

1. 평면적 RAG의 종말: : ‘검색’에서 ‘탐색(Navigation)’으로

기술적 배경
- Long Context Window(거대 문맥 창)의 등장
- 에이전트의 추론 능력 향상
RAG의 한계
- 기존 RAG는 파편화된 정보를 벡터 유사도로 가져오는 수준(Top-K retrieval)
- 계층 구조를 무시하고 모든 사실을 동등하게 간주해 정보의 ‘맥락’을 놓치기 쉬움
Long Context의 등장
- Gemini 1.5/2.0처럼 수백만 토큰을 처리하는 모델
- 굳이 복잡한 인덱싱 없이 “일단 다 집어넣고 물어보는” 방식이 가능해짐
Agentic RAG로의 진화
- 이제 단순히 정보를 찾는 RAG 보다 ‘에이전틱 탐색’
- 에이전트가 필요에 따라 스스로 쿼리를 날리고 문서를 재정렬하며 데이터 간의 관계를 추론함

2. 객체를 사람이 아닌, 컴퓨터가 보기 편한 구조로 바라볼때

데이터구조는 단순히 ‘답변’을 위한 것이 아니라, ‘행동’을 위한 인프라가 되어야 합니다. 만약 데이터엔지니어가 “회사를 파일 구조로 본다”면, 데이터를 단순한 ‘기록’이 아닌, 에이전트가 조작할 수 있는 ‘실행 가능한 객체(Actionable Objects)’로 정의하는 것을 의미합니다.

객체화의 변화
- 과거: 데이터베이스의 한 행(Row)은 그저 숫자와 문자의 집합.
- 현재: 에이전트에게 데이터는 ‘상태(State)’와 ‘이력(History)’을 가진 객체
  - EX- ‘고객 A’라는 객체는 /customers/A라는 경로에 있고, 그 안에 주문 이력, 보안 등급, 마케팅 선호도 등이 ‘속성’으로 붙어 있는 구조
Semantic Layer의 통합
- 회사의 모든 데이터(DB, 문서, 코드)를 에이전트가 이해할 수 있는 시맨틱 파일 시스템(Semantic File System)으로 변환하려는 트렌드
- 에이전트는 SQL을 짜는 대신, 마치 리눅스 터미널에서 파일을 탐색하듯 cd /sales/2026, grep "churn_risk"와 같은 논리로 데이터를 처리
에이전트: 디지털트윈의 ‘뇌’이자 ‘손’이 되어주다
- 기존 디지털 트윈의 가장 큰 비극은 “그래서 뭐?”라는 질문에 답하지 못했다는 점
- 인간 관리자가 화면을 보고 직접 판단해야 했음
- 하지만 지금의 객체화된 데이터 구조, Semantic Layer의 통합은 AI 에이전트가 인간 개입없이 수행가능하게 함
  - 과거: DB 테이블 table_p01_v2 (이게 뭔지 사람이 해석해줘야 함)
  - 현재: 객체 Main_Boiler_Pressure (에이전트가 바로 이해하고 추론에 활용 가능)

“회사=파일구조”라는 관점은, 회사를 하나의 거대한 컴퓨터(World Computer)로 취급하겠다는 선언과 같습니다. 직원은 인터페이스가 되고, DB는 메모리가 되며, 에이전트는 CPU가 되어 디지털 트윈이라는 OS 위에서 비즈니스 로직을 실행하는 시대가 온 것입니다.

3. 데이터 모델링: Star Schema vs. Data Vault

Agent에게 ‘데이터 볼트’ 데이터 구조가 더 적합
- 스타스키마는 인간이 보기 편하게 데이터를 ‘압축’한 것
- 데이터볼트는 에이전트가 회사, DB 등을 ‘파일 구조’처럼 자유롭게 돌아다니기에 더 적합한 형태 *원자적(Atomic)?

구분	스타 스키마 (Star Schema)	데이터 볼트 (Data Vault)
중심 구조	Fact(수치) & Dimension(속성)	Hub(엔티티), Link(관계), Satellite(이력)
목적	인간의 BI(보고서) 시각화 최적화	시스템 간 통합 및 확장성, 추적성(Audit)
에이전트 친화도	낮음 (데이터가 이미 요약/정제됨)	높음 (원천 데이터의 관계가 보존됨)
유연성	비즈니스 로직 변경 시 스키마 수정 필요	새로운 소스 추가 시 Hub/Link만 추가하면 됨

데이터 볼트는 데이터를 “절대 변하지 않는 것”과 “계속 변하는 것”으로 나눔
- 스타스키마는 객체화(데이터 정규화)하는 대상의 구성으로 나눔
  - EX- 고객 객체 = 고객명 + 고객ID + 주소 + 가입일 등)
  - EX(데이터볼트) -고객ID: 절대 안변함/ 주소: 변할 수 있음
- Hub : 비즈니스의 핵심 키(Business Key), 엔티티(객체)의 영혼
  - 물리 세계의 특정 설비, 제품, 혹은 직원은 변하지 않는 고유 ID(Hub)를 갖습니다. (EX- 고객번호 CUST_001, 상품코드 PROD_99)
- Link: 허브 간의 관계
  - 설비 A와 제품 B의 연결, 혹은 작업자 C의 개입은 Link로 정의 (EX- 어떤 고객(CUST_001)이 어떤 상품(PROD_99)을 샀다(BUY).)
- Satellite: 그 외의 모든 상세 정보와 변화, 실시간 감각
  - 물리 세계의 ‘현재 상태’를 실시간으로 동기화하는 감각 수용체 역할 (EX- 이름, 주소, 등급, 가격 같은 것)
Satellite
= “특정 시점의 모든 유관 데이터(속성값들)가 그 시간대별로 층층이 쌓여 있는 형태”
- 데이터를 수정(Update)하지 않고 오직 입력삽입(Insert)만 발생
- 이력의 누적: 특정 고객의 주소가 바뀌면, 기존 데이터를 수정하는 게 아니라 새로운 행(Row)을 추가
- 타임스탬프 기록: 모든 새틀릿 레코드에는 Load_Date나 Applied_Date 같은 시간 정보가 필수 포함 > Point-in-time 조회가 가능한 구조
- 예시 (고객 새틀릿):
  - 2월 1일: [CUST_001 / 브론즈 등급 / 서울 거주 / 2026-02-01]
  - 2월 15일: (등급 상승 시) [CUST_001 / 실버 등급 / 서울 거주 / 2026-02-15]
  - 이렇게 쌓이기 때문에, “2월 5일 당시 이 고객의 상태는?”이라고 물으면 2월 1일 자 데이터를 찾아낼 수 있는 구조입니다.
이렇게 했을 때 장점
- 감사(Auditing)와 추적성: “데이터가 왜 이렇게 바뀌었지?”를 추적할 때 소스 데이터의 변경 이력이 100% 보존되어 있으므로 완벽한 대응 가능
- 확장성 (Agility): 새로운 컬럼이 추가되어야 한다면? 기존 테이블을 수정할 필요 없이, 새로운 새틀릿 테이블 하나를 더 만들어서 허브에 붙이기만 하면 됨. 기존 시스템에 영향 안줌
- 병렬 처리: 허브, 링크, 새틀릿이 분리되어 있어 여러 소스에서 데이터를 동시에 밀어넣어도 락(Lock) 충돌이 적어 대규모 ETL에 유리

5. 비즈니스 아키텍처 관점에서 바라본 에러(Error), 편향(Bias), 취향(Taste)의 경계

데이터 구조화에서 이 세 가지는 종종 섞여 나타나지만, 에이전트 시대에는 그 성격이 완전히 달라집니다. 에러는 ‘틀린 것’이고, 편향은 ‘치우친 것’이며, 취향은 ‘선택한 것’.

구분	과거 (Human-Centric)	현재 (Agentic-Centric)	구분의 핵심 기준
에러 (Error)	문법 오류, 정규화 실패, 논리적 모순	환각(Hallucination), 데이터 유실, 연결 단절	기능적 작동 여부 (시스템이 멈추는가?)
편향 (Bias)	설계자의 좁은 시야, 특정 도메인에 매몰	훈련 데이터의 한계, 특정 로직의 과적합	객관적 보편성 (다른 케이스에도 작동하는가?)
취향 (Taste)	네이밍 컨벤션, UI/UX 철학	추상화의 깊이, 엔티티 간의 우선순위 결정	전략적 의도 (어떤 비즈니스 가치를 우선하는가?)

휴먼 에러’는 줄지만 ‘아키텍처 편향’은 고착화된다
- AI가 데이터 구조화, 시맨틱레이어를 통제하면, 사소한 문법 에러나 정규화 실수(휴먼 에러)는 확실히 줄어듬
- 단, 평균의 함정에 빠질 수 있음
- 표준의 역습: LLM은 가장 보편적인 구조(예: 일반적인 CRM 구조)를 추천. 이는 에러는 없지만, 회사의 독특한 비즈니스 모델을 반영해야 하는 ‘취향’을 제거된 ‘평균적인 편향’에 갇히게 만듬
- 해석의 파편화: 에이전트마다 세상을 보는 ‘온톨로지(Ontology, 존재론)’가 다를 경우 시스템 전체의 논리적 에러로 번질 수 있음
  - EX- A 에이전트: 고객= ‘수익원’/ B 에이전트: =’관리 대상’으로 정의
  - 데이터 객체화 관점의 다양성이 주는 리스크
해결책: ‘취향’을 ‘프로토콜’로 승격시키기
- 에러/편향과 취향의 경계가 모호할 때 해결책은 ‘우리만의 세계관(Worldview, Ontology)’을 명시적인 가이드라인(Compliance, 정책)으로 치환하는 것
  - Semantic Guardrail: “우리 회사에서 ‘고객’ 객체는 반드시 ‘보안 등급’ 속성을 최상위에 둔다”와 같은 원칙을 세우는 것. 이는 취향을 강제하여 편향을 방지하고 에러를 차단하는 장치가 됨.
  - 객체화의 민주화: 엔지니어 뿐만 아니라 회사 내부구성원 모두에게 ‘왜 이런 구조인가?’라는 질문에 투명하게 비즈니스 언어로 번역되는 과정이 필요함.