에이전트형 AI (Agentic AI)를 구동하는 데이터 아키텍처

시맨틱 레이어 (Semantic layers)와 지식 그래프 (Knowledge graphs)부터 벡터 검색 (Vector search), 현대적 데이터 플랫폼, 그리고 실시간 파이프라인 (Real-time pipelines)까지 — 지능의 밑바탕이 되는 인프라를 소개합니다.

2025~2026년의 헤드라인은 모델이 아닙니다. 바로 에이전트 (Agent)입니다. 거대 언어 모델 (LLM)은 기계가 추론할 수 있음을 증명했습니다. 에이전트형 AI (Agentic AI)는 기계가 행동 (Act) 할 수 있음을 증명합니다 — 즉, 인간의 개입 없이도 다단계 작업을 계획하고, 도구를 호출하며, 결과를 관찰하고, 스스로 적응합니다.

하지만 아무도 트위터(X)에 올리지 않는 아키텍처의 진실이 있습니다: 나쁜 데이터에 기반한 뛰어난 에이전트는 그저 자신감 넘치는 거짓말쟁이일 뿐입니다. 에이전트 시스템 하단의 데이터 인프라는 이 시스템이 신뢰할 수 있는 결정을 내릴지, 아니면 값비싼 환각 (Hallucination)을 일으킬지를 결정합니다. 대시보드와 배치 쿼리 (Batch queries)를 위해 구축된 전통적인 데이터 아키텍처는 자율 에이전트의 유동적이고 지연 시간에 민감하며 다중 소스를 요구하는 요구사항을 충족하기에는 근본적으로 부적합합니다.

이 글에서는 실제로 구축 가능한 참조 아키텍처와 함께, 프로덕션 등급의 에이전트형 데이터 스택 (Agentic data stack)의 모든 레이어를 분석합니다.

에이전트형 AI (Agentic AI)를 다르게 만드는 것

표준 LLM 애플리케이션은 하나의 요청을 보내고 하나의 응답을 받습니다. 반면 에이전트 시스템은 이전 단계에 의존하는 연쇄적인 요청 (Chains of requests) 을 보냅니다 — 데이터베이스를 쿼리하고, API를 읽고, 코드를 실행하며, 기록 시스템 (Systems of record)에 데이터를 쓰고

Raw 데이터베이스는 에이전트가 읽을 수 없습니다. amt_usd_cr_adj와 같은 이름의 컬럼은 LLM(Large Language Model)에게 아무런 의미가 없으며, 만약 에이전트가 잘못 추측한다면 이후의 모든 후속 작업(downstream action)이 오염됩니다.

시맨틱 레이어 (Semantic layer)는 로우 데이터를 **기계가 읽을 수 있는 비즈니스 컨텍스트 (machine-readable business context)**로 변환함으로써 이 문제를 해결합니다. 즉, 각 필드가 무엇을 의미하는지, 지표(metrics)가 어떻게 계산되는지, 어떤 데이터셋이 어떤 엔티티(entities)와 연관되어 있는지를 정의합니다. 이는 복잡한 데이터를 제품, 고객, 매출, 리스크와 같이 익숙한 비즈니스 용어로 매핑하여, 조직 전체의 데이터 자산(data estate)에 대한 통합된 뷰를 제공합니다.

에이전트를 위한 시맨틱 레이어의 핵심 구성 요소:

가상 데이터셋 (Virtual datasets): 에이전트로부터 로우 테이블의 복잡성을 숨겨주는, 정제되고 비즈니스에 정렬된 뷰 (views)
컬럼 수준 문서화 (Column-level documentation): LLM이 필드의 의미론(semantics)을 이해하는 데 사용하는 인간이 읽을 수 있는 설명
사전 정의된 지표 (Pre-defined metrics): 에이전트가 매번 다시 계산하는 대신 이름으로 호출할 수 있는 집계값 (매출, DAU, 이탈률 등)
비즈니스 규칙 (Business rules): 기계가 읽을 수 있도록 만들어진 계층 구조 정의, 관계 및 도메인 로직

이 레이어가 없다면, 에이전트는 로우 컬럼 이름과 데이터 분포로부터 테이블의 의미론을 역공학(reverse-engineer)해야 합니다. 이는 대규모 환경에서 환각 (hallucinations)을 유발하는 취약한 방식입니다.

# 예시: 시맨틱 레이어 메타데이터 (dbt / Dremio 스타일)
table: transactions
columns:
...

레이어 2 — 지식 그래프 (Knowledge Graphs, 데이터가 연결되는 방식)

시맨틱 레이어가 에이전트에게 데이터가 무엇을 의미하는지 알려준다면, 지식 그래프 (knowledge graph)는 _모든 것이 어떻게 연관되어 있는지_를 알려줍니다. 지식 그래프는 사용자, 제품, 트랜잭션, 이벤트와 같은 엔티티를 노드 (nodes)로, 그들 사이의 관계를 엣지 (edges)로 모델링하여, 에이전트가 평면적인 테이블 (flat tables)로는 표현할 수 없는 다단계 추론 경로 (multi-hop reasoning paths)를 탐색할 수 있게 합니다.

관계형 데이터베이스와의 핵심적인 차별점은 **추론 (inference)**입니다. W3C의 자원 기술 프레임워크 (Resource Description Framework, RDF) 스택을 기반으로 구축된 지식 그래프 (knowledge graphs)는 OWL 온톨로지 (ontologies)를 통한 형식적 추론 (formal reasoning)과 SHACL 검증 제약 조건 (validation constraints)을 사용하여 기존 사실로부터 새로운 사실을 도출할 수 있습니다. 이는 LLM을 위한 그라운딩 레이어 (grounding layer)로서 이상적입니다. 즉, 생성형 응답을 현실에 고정할 수 있는 구조화되고 검증 가능한 사실을 제공합니다.

GraphRAG는 두 방식의 장점을 결합합니다. 벡터 기반 검색 (vector-based retrieval)은 의미론적으로 관련 있는 청크 (chunks)를 찾아내고, 지식 그래프는 정밀한 추론을 위해 구조화되고 관계를 인식하는 컨텍스트 (context)를 제공합니다. 하이브리드 RAG-KG 프레임워크 (RAG-KG-IL)에 대한 연구에 따르면, 지식 그래프를 RAG와 통합하면 RAG 전용 베이스라인 (baselines)과 비교했을 때 환각 (hallucination) 발생률을 크게 낮추고 답변의 완전성과 추론 정확도를 향상시키는 것으로 나타났습니다. 특히 임상 질의응답 분야에서는 온톨로지 기반의 지식 그래프 프레임워크가 98%의 정확도를 달성했으며, 환각 발생률을 약 63%(ChatGPT-4)에서 단 1.7%로 줄였습니다.

지식 그래프 탐색 예시:

사용자:John → PLACED → 주문:4821
...

그래프 기반 접근 방식은 엄청난 효율성 이점도 제공합니다. 금융 문서 검색 실험 결과, 기존 RAG 방식과 비교했을 때 모순 탐지 (contradiction detection) 시 토큰 사용량이 80% 감소했으며, 토큰 소비량이 734배 절감되는 결과를 보여주었습니다. [

레이어 3 — 벡터 검색 (데이터가 검색되는 방식)

모든 지식이 관계형 스키마 (relational schema)나 지식 그래프에 깔끔하게 들어맞는 것은 아닙니다. 문서, 이메일, 지원 티켓, 제품 설명, 대화 기록과 같은 비정형 콘텐츠 (unstructured content)는 의미론적 의미를 인코딩하는 고차원 벡터인 **임베딩 (embeddings)**으로 표현하는 것이 가장 좋습니다. 벡터 검색은 쿼리 (query)와 의미론적으로 가장 유사한 콘텐츠를 찾아내어, 정확한 키워드가 일치하지 않더라도 에이전트가 관련 컨텍스트를 검색할 수 있게 합니다.

실제 운영 환경의 벡터 검색 파이프라인은 세 가지 단계로 구성됩니다:

1. 인제스션 및 전처리 (Ingestion and Preprocessing)

대규모 문서를 문장 또는 단락 단위로 청킹 (Chunking)
하이브리드 필터링 (Hybrid filtering)을 위해 메타데이터 (타임스탬프, 출처, 엔티티 ID) 부착
실시간 콘텐츠의 경우, Kafka를 통해 파이프라인으로 스트리밍

2. 임베딩 및 인덱싱 (Embedding and Indexing)

오픈 소스 모델 (BAAI/bge-small-en, all-MiniLM-L6-v2) 또는 상용 API를 사용하여 임베딩 (Embeddings) 생성
벡터 지원 데이터베이스 (Milvus, Pinecone, Qdrant, pgvector, RediSearch가 포함된 Redis)에 메타데이터와 함께 임베딩 저장
대규모 환경에서 1초 미만의 검색 속도를 보장하기 위해 근사 최근접 이웃 (Approximate Nearest Neighbor, ANN) 인덱스 구축

3. 쿼리 실행 (Query Execution)

동일한 임베딩 모델을 사용하여 사용자 쿼리를 벡터로 변환
하이브리드 검색 수행: 벡터 유사도 + 메타데이터 필터 (예: userId = X AND timestamp > T)
크로스 인코더 (Cross-encoders) 또는 LLM 기반 관련성 점수 산출을 통한 선택적 리랭킹 (Reranking)

// 하이브리드 벡터 + 메타데이터 검색 (의사 코드)
const results = await vectorDB.search({
  embedding: await embed(userQuery),
...

벡터 저장 위치: 세션 상태(Session state)와 속도 제한(Rate limiting) 기능도 필요한 에이전트의 경우 (Redis 관련 기사 참조), Redis의 RediSearch 모듈을 사용하면 하나의 시스템 내에서 세션 데이터와 함께 임베딩을 저장할 수 있어 인프라 복잡성을 줄일 수 있습니다. 대규모 검색이 필요한 경우에는 HNSW 인덱스를 갖춘 Milvus 또는 Qdrant와 같은 전용 데이터베이스가 더 나은 처리량 (Throughput)을 제공합니다.

레이어 4 — 현대적 데이터 플랫폼 (데이터가 존재하는 곳)

파편화된 데이터 사일로 (Data silos)는 프로덕션 환경에서 에이전트형 AI (Agentic AI) 구현을 가로막는 가장 큰 장애물입니다. 데이터 웨어하우스, S3 버킷, PostgreSQL 인스턴스, 제3자 API, Redis 캐시 등 다섯 개의 별도 시스템에 인증해야 하는 에이전트는 속도가 느리고, 취약하며, 거버넌스(Governance)를 구축하는 것이 불가능합니다.

**에이전트형 레이크하우스 (Agentic Lakehouse)**가 떠오르는 해결책입니다. 이는 모든 에이전트나 컴퓨팅 엔진이 쿼리할 수 있는 오픈 포맷 (Open formats) 기반의 통합 데이터 플랫폼입니다.

에이전트형 데이터 플랫폼의 네 가지 핵심 요소:

기둥 (Pillar)	기술 (Technology)	역할 (Role)
오픈 스토리지 (Open Storage)	S3/GCS 상의 Apache Iceberg	단일 진실 공급원 (Single source of truth), 버전 관리된 스냅샷 (versioned snapshots)
...	...	...

Apache Iceberg의 불변(immutable) 및 버전 관리된 스냅샷 모델은 에이전트형 워크플로 (agentic workflows)에 특히 가치가 높습니다. 에이전트는 특정 스냅샷을 고정(pin)할 수 있으며, 하위 테이블이 병렬로 진화하더라도 일관된 데이터 상태를 바탕으로 다단계 추론 (multi-step reasoning)을 실행할 수 있습니다.

**모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)**은 AI 에이전트와 데이터 플랫폼 사이의 표준 통합 계층으로 빠르게 자리 잡고 있습니다. MCP 서버는 카탈로그 작업(테이블 목록 조회, 스키마 설명, 쿼리 실행 등)을 LLM이 별도의 커스텀 커넥터 코드 없이도 네이티브하게 호출할 수 있는 도구 (tools)로 노출합니다. MCP 인터페이스를 갖춘 오픈 레이크하우스 (open lakehouse)는 에이전트에게 수천 개의 병렬 에이전트 워크로드로 확장 가능한, 거버넌스가 적용된 자기 기술적 (self-describing) 분석 기질 (analytical substrate)을 제공합니다.

에이전트형 레이크하우스 아키텍처 (Agentic Lakehouse Architecture):

[AI 에이전트 (AI Agent)]
...

레이어 5 — 실시간 스트리밍 파이프라인 (데이터 흐름 방식)

오래된 데이터(stale data)를 기반으로 작동하는 에이전트는 잘못된 결정을 내립니다. 어제의 거래 패턴을 읽는 사기 탐지 (fraud detection) 에이전트는 오늘의 공격을 놓칠 것입니다. 지난주 카탈로그를 기반으로 작동하는 개인화 (personalization) 에이전트는 품절된 재고를 놓칩니다. 실시간 파이프라인은 데이터가 생성되는 시점과 에이전트가 이에 대응할 수 있는 시점 사이의 간극을 메워줍니다.

Apache Kafka + Apache Flink는 실시간 에이전트형 데이터 파이프라인의 중추로 부상했습니다. Kafka는 분산된 파티션(partitions)을 통해 초당 수백만 개의 이벤트 스트림을 수집하며, Flink는 상태 저장(stateful) 및 정확히 한 번(exactly-once) 의미론을 통해 해당 스트림을 처리합니다. 이들은 에이전트형 워크로드가 요구하는 신뢰성 보장을 갖추고 데이터를 수집, 변환 및 라우팅할 수 있는 파이프라인을 가능하게 합니다.

Confluent는 **스트리밍 에이전트 (Streaming Agents)**를 통해 이를 더욱 발전시켰습니다. 이는 데이터 스트림 내부에서 실행되는 Flink 작업 (job)으로 네이티브하게 구축된 이벤트 기반 (event-driven) 에이전트입니다. 이 에이전트들은 데이터베이스를 폴링 (polling) 하는 대신, 이벤트가 생성되는 즉시 이벤트를 수신하고, 이벤트 윈도우 (event windows) 전반에 걸쳐 상태 (state)를 유지하며, Flink SQL의 ml_predict를 통해 인라인 (inline)으로 LLM 추론 (inference)을 호출합니다.

실시간 에이전트형 파이프라인 (Real-Time Agentic Pipeline):

[이벤트 소스 (Event Sources)]           [스트림 처리 (Stream Processing)]        [에이전트 컨텍스트 (Agent Context)]
...

Netflix는 Kafka와 Flink를 사용하여 대규모 실시간 개인화 엔진을 구동합니다. 에이전트들은 단일 이벤트를 개별적으로 처리하는 대신, 지속적인 다중 소스 이벤트 흐름을 분석하여 트렌드를 감지하고 선제적인 조치를 취합니다.

에이전트를 위한 주요 스트리밍 설계 패턴:

수집 시간 (ingestion-time) 대신 이벤트 시간 (event-time) 처리: 이벤트가 도착한 시점이 아니라 발생한 시점을 기준으로 이벤트를 처리합니다. 이는 정확한 윈도우 집계 (windowed aggregations)를 위해 매우 중요합니다.
상태 저장 조인 (Stateful joins): 스트림 내에서 트랜잭션 이벤트에 사용자 프로필 상태를 결합(enrich)하여, 에이전트가 완전히 맥락화된 페이로드 (payload)를 수신할 수 있도록 합니다.
정확히 한 번 (Exactly-once) 의미론: Kafka 트랜잭션과 Flink 체크포인트 (checkpoints)를 사용하여 중요한 파이프라인 (결제, 재고 등)에서 중복 계산을 방지합니다.
워터마킹 (Watermarking): 파이프라인을 차단하지 않고 지연 도착하는 이벤트를 유연하게 처리합니다.

종합하기: 참조 아키텍처 (Reference Architecture)

다음은 핀테크 사기 방지 에이전트, 이커머스 추천 엔진 또는 AI 지원 지원 플랫폼을 구동하는 것과 같은 프로덕션 환경의 에이전트형 AI 시스템을 위한 전체 스택입니다:

┌─────────────────────────────────────────────────────────────┐
│                        AI 에이전트 계층 (AI AGENT LAYER)                       │
│         [오케스트레이터 (Orchestrator)]  →  [도구 호출 (Tool Calls)]  →  [액션 (Actions)]        │
...

피해야 할 안티 패턴 (Anti-Patterns)

실패 사례 없이는 어떤 아키텍처 문서도 완성될 수 없습니다. 다음은 팀들이 에이전트형 데이터 인프라를 구축할 때 범하는 가장 흔한 실수들입니다:

시맨틱 레이어 (Semantic Layer) 부재 → 취약한 프롬프트 (Fragile Prompts). 원시 컬럼 이름을 해석하는 에이전트는 컬럼의 의미론적 의미를 환각 (Hallucination)할 수 있습니다. 에이전트가 쿼리할 모든 내용을 문서화하십시오.
지식 그래프 (Knowledge Graph) 없는 평면적 RAG. 벡터 검색 (Vector Search)은 '유사한' 텍스트를 찾을 뿐, '관계'를 탐색하지는 못합니다. 멀티홉 추론 (Multi-hop reasoning, 예: 공급업체 → 리스크 → 결정)에는 그래프 탐색이 필요합니다.
에이전트의 데이터베이스 폴링 (Polling). 새로운 이벤트를 확인하기 위해 PostgreSQL 테이블을 폴링하는 에이전트는 지연 시간 (Latency)과 부하를 가중시킵니다. Kafka의 푸시 (Push) 방식이 항상 더 바람직합니다.
에이전트 간 자격 증명 공유. 모든 에이전트는 카탈로그의 자격 증명 공급 (Credential vending) API를 통해 범위가 제한된 단기 자격 증명을 부여받아야 하며, 공유된 클라우드 키를 사용해서는 안 됩니다.
다단계 분석 시 스냅샷 고정 (Snapshot Pinning) 누락. 다단계 작업 과정에서 동일한 테이블을 두 번 읽는 에이전트의 경우, 실행 도중 테이블이 업데이트되면 서로 다른 결과를 얻을 수 있습니다. Iceberg 스냅샷에 고정하십시오.
관측성 (Observability) 무시. 에이전트는 수많은 데이터 호출을 수행합니다. 모든 쿼리에 트레이스 ID (Trace IDs), 지연 시간 메트릭 (Latency metrics), 캐시 히트율 (Cache hit rates)을 적용하십시오. 그렇지 않으면 잘못된 에이전트 결정의 디버깅이 거의 불가능해집니다.