AI 에이전트들은 도구를 사용하는 능력이 점점 좋아지고 있지만, 여전히 많은 에이전트들이 지루한 이유로 실패하곤 합니다. 바로 어떤 데이터를 신뢰해도 되는지 알지 못하기 때문입니다.

어떤 워크플로우는 오래된 임베딩 (embeddings)을 읽습니다. 또 다른 워크플로우는 테넌트 범위 (tenant scope) 없이 원시 테이블 (raw tables)을 쿼리합니다. 세 번째는 차트 숫자를 답변에 복사하지만, 어떤 필터가 그 숫자를 생성했는지 아무도 알 수 없습니다. 모델은 똑똑해 보이지만, 데이터 경로는 엉망입니다.

만약 여러분이 AI 제품을 구축하고 있다면, 해결책은 "더 많은 컨텍스트를 추가하는 것"이 아닙니다. 해결책은 **AI 데이터 액세스 레이어 (AI data access layer)**입니다. 이는 에이전트가 실시간 비즈니스 컨텍스트를 요청할 수 있게 하면서, 동시에 여러분의 앱이 권한 (permissions), 스키마 (schemas), 최신성 (freshness), 그리고 근거 (evidence)를 강제할 수 있도록 하는 얇고 테스트 가능한 경계입니다.

이 가이드는 여러분의 스택을 연구 프로젝트로 만들지 않으면서도 이러한 레이어를 설계하는 방법을 보여줍니다.

에이전트에게 데이터 액세스 레이어가 필요한 이유

대부분의 AI 기능은 다음과 같은 단순한 패턴으로 시작합니다:

1. 사용자 데이터를 가져옵니다.
2. 이를 프롬프트 (prompt)에 넣습니다.
3. 모델에게 답변을 요청합니다.
4. 답변이 정확하기를 바랍니다.

데모용으로는 작동합니다. 하지만 제품에 고객, 팀, 역할 (roles), 결제 플랜 (billing plans), 감사 요구사항 (audit requirements), 그리고 복잡한 실제 데이터가 포함되면 무너집니다.

프로덕션 에이전트는 다음과 같은 질문에 대한 답변이 필요합니다:

• 이 레코드를 소유한 테넌트 (tenant)는 누구인가?
• 이 사용자가 매출 데이터를 볼 권한이 있는가?
• 이 숫자는 오늘 것인가, 지난주 것인가, 아니면 오래된 벡터 청크 (vector chunk)인가?
• CRM과 데이터 웨어하우스 (warehouse)의 내용이 다를 때 어떤 소스가 우선되어야 하는가?
• 인용 (citations)이나 쿼리 근거 (query evidence)를 보여줄 수 있는가?
• 데이터 소스가 다운되면 어떻게 되는가?

RAG는 비정형 문서 (unstructured documents)에는 도움이 되지만, RAG가 완전한 데이터 전략은 아닙니다. 임베딩 (embeddings)은 "환불을 언급하는 정책을 찾아줘"와 같은 작업에는 훌륭합니다. 하지만 "트라이얼 (trials)을 제외하고, ARR이 1만 달러 이상인 계정의 이탈 위험을 소유자별로 그룹화하여 보여줘"와 같은 작업에는 취약합니다.

이를 위해 에이전트에게는 구조화된 데이터 (structured data), 의미론적 정의 (semantic definitions), 그리고 승인된 도구 (approved tools)로 들어가는 관리된 경로가 필요합니다.

핵심 아이디어

AI 데이터 액세스 레이어는 에이전트와 여러분의 데이터 시스템 사이에 위치합니다.

에이전트는 Postgres, Stripe, HubSpot 또는 데이터 웨어하우스(warehouse)와 직접 통신하지 않습니다. 대신 승인된 소수의 데이터 도구(data tools)를 호출합니다. 이러한 도구들은 컨텍스트(context)를 반환하기 전에 규칙을 강제합니다.

사용자 요청 (User request)
   ↓
에이전트 플래너 (Agent planner)
...

이 레이어는 다음과 같은 데이터를 반환해야 합니다:

• 범위 지정됨 (Scoped): 테넌트(tenant), 사용자(user), 역할(role) 및 플랜(plan)에 따라 필터링됨.
• 최신성 (Fresh): 데이터가 언제 검색되었는지 명확함.
• 타입 지정됨 (Typed): 모호한 덩어리(blobs)가 아닌 스키마(schemas)에 의해 구조화됨.
• 설명 가능함 (Explainable): 소스 ID, 쿼리 요약 및 인용(citations)을 포함함.
• 제한됨 (Limited): 작업에 필요한 만큼의 컨텍스트만 제공함.
• 로그 기록됨 (Logged): 모든 액세스는 감사(auditable) 가능함.

목표는 모델을 전지전능하게 만드는 것이 아닙니다. 모델이 추측할 가능성을 낮추는 것이 목표입니다.

현재 AI 플랫폼 트렌드가 보여주는 것

최근 AI 플랫폼 뉴스들은 동일한 방향을 가리키고 있습니다. 에이전트 시스템(agentic systems)이 채팅(chat)에서 실행(action)으로 이동하고 있습니다. 엔지니어들은 도구 사용(tool use), MCP 스타일의 통합(integrations), 거버넌스가 적용된 컨텍스트(governed context), AI 분석 API(AI analytics APIs), 그리고 에이전트 모니터링(agent monitoring)에 대해 논의하고 있습니다. 새로운 제품들 또한 "신뢰할 수 있는 컨텍스트(trusted context)", 고객 범위별 분석(customer-scoped analytics), 권한 우선 감지(permission-first sensing), 그리고 검증 가능한 지식 그래프(verifiable knowledge graphs)를 밀어붙이고 있습니다.

빌더(builders)들에게 주는 신호는 명확합니다. 다음 단계의 유용한 AI 기능은 단순히 더 나은 프롬프트(prompt)가 아닙니다. 그것은 더 안전한 데이터 경로(data path)입니다.

실질적인 고충(pain points)은 다음과 같습니다:

• 에이전트는 오래된 프롬프트 덤프(prompt dumps)가 아닌 실시간 데이터(live data)가 필요합니다.
• 팀은 다른 테넌트의 기록을 노출하지 않으면서 고객 대상 분석(customer-facing analytics)을 수행하기를 원합니다.
• RAG 답변에는 인용(citations)과 소스의 최신성(freshness)이 필요합니다.
• 디버깅과 컴플라이언스(compliance)를 위해 도구 호출(tool calls)은 반드시 로그가 기록되어야 합니다.
• 모든 프롬프트가 너무 많은 데이터를 포함하면 AI 비용이 상승합니다.
• 개발자는 에이전트가 백엔드 전체를 돌아다니게 허용하지 않으면서도 빠른 통합(integrations)을 구현해야 합니다.

이는 콘텐츠의 공백도 만들어냅니다. 많은 기사들이 RAG, 벡터 데이터베이스(vector databases) 또는 에이전트 프레임워크(agent frameworks)를 개별적으로 설명합니다. 권한, 의미론적 정의(semantic definitions), 도구 스키마(tool schemas), 실시간 쿼리(live queries), 그리고 증거(evidence)를 하나의 반복 가능한 패턴으로 결합하는 중간 레이어(middle layer)를 설명하는 경우는 드뭅니다.

일반적인 RAG만으로는 충분하지 않을 때

RAG는 답변이 문서(docs), 지원 티켓(support tickets), 회의록(meeting notes), 정책(policies), 전사본(transcripts), 지식 베이스(knowledge bases)와 같은 텍스트에 존재할 때 유용합니다.

하지만 많은 제품 관련 질문들은 텍스트 검색(text retrieval) 문제가 아닙니다.

훌륭한 AI 데이터 액세스 레이어(data access layer)는 적합한 곳에는 RAG를, 적합한 곳에는 SQL을, 적합한 곳에는 API를 사용하며, 모든 곳에 규칙(rules)을 적용할 수 있습니다.

최소 아키텍처 (The minimum architecture)

거대한 플랫폼이 필요하지는 않습니다. 다섯 가지 부분으로 시작하세요.

1. 도구 계약 (A tool contract)

에이전트가 무엇을 요청할 수 있는지 정확하게 정의하세요.

나쁜 도구 예시:

{
  "name": "query_database",
  "input": "SQL string from model"
...

더 나은 도구 예시:

{
  "name": "get_customer_health_summary",
  "input_schema": {
...

모델은 의도(intent)와 파라미터(parameters)를 선택해야 합니다. 쿼리(queries)에 대한 제어권은 백엔드(backend)가 가져야 합니다.

2. 정책 게이트 (A policy gate)

어떤 도구가 실행되기 전에, 사용자와 에이전트 세션이 요청된 데이터에 접근할 수 있는지 확인하세요.

최소한 다음 사항들을 평가해야 합니다:

• 테넌트 ID (tenant ID)
• 사용자 ID (user ID)
• 역할 (role)
• 워크스페이스 멤버십 (workspace membership)
• 결제 플랜 (billing plan)
• 데이터 민감도 (data sensitivity)
• 요청된 작업 (requested action)
• 접근 목적 (purpose of access)

다음은 간단한 TypeScript 스타일의 정책 확인 예시입니다:

type DataRequest = {
  tenantId: string;
  userId: string;
...

프롬프트(prompt)가 “허용된 데이터에만 접근하라”고 말하는 것에 의존하지 마세요. 정책 코드(policy code)가 이를 강제하도록 만드세요.

3. 시맨틱 레이어 (A semantic layer)

시맨틱 레이어(semantic layer)는 비즈니스 용어를 한 번만 정의하므로, 에이전트가 지표 로직(metric logic)을 임의로 만들어내지 않도록 합니다.

예시:

metrics:
  active_users:
    description: 선택된 기간 동안 최소 하나 이상의 성공적인 세션을 가진 사용자.
...

이것이 중요한 이유는 AI의 답변이 문법이 아닌 정의(definitions)에서 실패하는 경우가 많기 때문입니다. 만약 “활성 사용자(active user)”가 앱 전체에서 세 가지 다른 의미로 쓰인다면, 에이전트는 그 혼란을 증폭시킬 것입니다.

4. 소스 커넥터 (Source connectors)

커넥터(connectors)는 지루하고 좁은 범위여야 합니다.

예시:

• get_invoices(customer_id)
• get_recent_product_events(account_id, lookback_days)
• search_docs(query, tenant_id, filters)
• get_metric(metric_name, segment, date_range)
• get_crm_account(account_id)

각 커넥터(connector)는 구조화된 데이터(structured data)와 근거(evidence)를 함께 반환해야 합니다:

{
  "data": {
    "mrr": 1240,
...

근거(evidence)는 에이전트(agent)에게 인용할 수 있는 대상을 제공하며, 사용자에게는 디버깅(debug)할 수 있는 수단을 제공합니다.

5. 액세스 로그 (An access log)

모든 데이터 도구 호출(data tool call)은 흔적을 남겨야 합니다.

로그 항목:

• 누가 데이터를 요청했는가
• 어떤 에이전트/세션이 요청했는가
• 도구 이름
• 입력 파라미터 (input parameters)
• 정책 결과 (policy result)
• 접근한 소스 시스템 (source systems)
• 행/문서 수 (row/document counts)
• 지연 시간 (latency)
• 예상 비용 (cost estimate)
• 해당 데이터를 사용한 답변 ID (answer ID)

이는 단순히 컴플라이언스 (compliance)만을 위한 것이 아닙니다. 이는 운영 환경에서 가장 흔히 발생하는 질문인 "에이전트가 왜 그렇게 말했나요?"에 답하는 데 도움을 줍니다.

실질적인 요청 흐름 (A practical request flow)

사용자가 다음과 같이 질문한다고 가정해 봅시다:

"오늘 어떤 계정(accounts)에 전화를 해야 하며, 그 이유는 무엇인가요?"

취약한 에이전트는 CRM 메모, 최근 티켓, 사용량 요약, 결제 이벤트를 하나의 긴 프롬프트 (prompt)에 쏟아부을 수 있습니다.

더 강력한 흐름은 다음과 같습니다:

1. 의도 분류 (Classify intent): 계정 우선순위 지정.
2. 사용자의 계정 액세스 권한 확인.
3. 시맨틱 레이어 (semantic layer)에 어떤 지표가 우선순위를 정의하는지 질문.
4. 범위가 지정된 계정 후보군 가져오기.
5. 상위 계정에 대해 필요한 근거(evidence)만 추출.
6. 인용(citations)이 포함된 순위가 매겨진 답변 생성.
7. 데이터 소스 및 최종 답변 로그 기록.

데이터 레이어 (data layer)의 예시 출력 형태:

{
  "accounts": [
    {
...

이제 에이전트는 시스템의 모든 개인적인 세부 정보를 보지 않고도 유용한 답변을 작성할 수 있습니다.

구현 체크리스트 (Implementation checklist)

에이전트에게 운영 데이터에 대한 액세스 권한을 부여하기 전에 이 체크리스트를 사용하세요.

액세스 제어 (Access control)

• 모든 데이터 요청에 테넌트 ID (Tenant ID)가 필수적임.
• 코드 내에서 사용자 역할 (user role)을 확인함.
• 민감한 필드 (sensitive fields)는 기본적으로 비식별화 (redacted) 처리됨.
• 명시적으로 승인되지 않는 한 테넌트 간 조인 (cross-tenant joins)은 차단됨.
• 디버그 모드 (debug mode)는 일반 답변보다 더 엄격한 액세스 권한을 가짐.

데이터 품질 (Data quality)

• 모든 지표(metric)는 하나의 정의를 가짐.
• 모든 결과에는 신선도(freshness)가 포함됨.
• 오래된 데이터(stale data)는 숨기지 않고 라벨을 붙임.
• 누락된 데이터는 명확한 이유를 반환함.
• 에이전트에게 증거가 불충분할 경우 이를 말하도록 지시함.

도구 설계 (Tool design)

• 도구는 가공되지 않은 데이터베이스 셸(shell)이 아니라 특정 작업에 특화되어야 함.
• 입력값은 스키마(schema)에 따라 검증됨.
• 출력값은 모델이 사용하기에 충분히 작아야 함.
• 대규모 결과 세트는 프롬프트에 들어가기 전에 요약됨.
• 도구 오류는 유형화(typed)되어 있으며 복구 가능해야 함.

관찰 가능성 (Observability)

• 도구 호출(tool calls)은 답변 ID와 연결됨.
• 정책 거부(policy denies) 사례가 추적됨.
• 커넥터(connector)별로 지연 시간(latency)을 측정함.
• 컨텍스트 조립(context assembly) 후 토큰 사용량을 측정함.
• 고위험 데이터 액세스는 검토(review)를 트리거함.

RAG, SQL, API, 그리고 지식 그래프(knowledge graphs) 사이에서 선택하는 방법

유행한다고 해서 데이터 패턴을 선택하지 마세요. 질문에 적합하기 때문에 선택해야 합니다.

사용자가 문서, 정책, 티켓, 전사 데이터(transcripts), 이메일, 릴리스 노트, 위키 페이지와 같이 언어 중심의 콘텐츠에 대해 질문할 때는 RAG를 사용하세요.

사용자가 수치, 트렌드, 코호트(cohorts), 매출, 사용량, 퍼널 단계(funnel steps) 또는 비교에 대해 질문할 때는 **SQL 또는 웨어하우스 쿼리(warehouse queries)**를 사용하세요.

결제 상태, 구독 변경, 권한 또는 워크플로 상태와 같이 소스 시스템이 비즈니스 로직을 보유하고 있는 경우에는 **제품 API(product APIs)**를 사용하세요.

엔티티(entities), 의존성(dependencies), 출처(provenance), 정책, 계보(lineage), 신원(identity) 및 멀티 홉(multi-hop) 컨텍스트와 같이 관계가 중요한 경우에는 **지식 그래프(knowledge graphs)**를 사용하세요.

대부분의 진지한 AI 제품은 이들의 혼합이 필요합니다. 데이터 액세스 레이어는 이러한 복잡성을 에이전트로부터 숨겨줍니다.

흔한 실수

실수 1: 모델이 SQL을 직접 작성하게 두는 것

강력하게 느껴지기 때문에 유혹적입니다. 하지만 위험하기도 합니다. 모델은 느린 쿼리를 생성하거나, 테넌트 필터(tenant filters)를 누락하거나, 필드를 노출하거나, 존재하지 않는 테이블 이름을 만들어낼 수 있습니다.

자연어 분석(natural-language analytics)이 필요한 경우, 제어된 쿼리 플래너(query planner), 허용 목록에 있는 지표(allowlisted metrics), 쿼리 제한(query limits)을 사용하고 실행 전에 검토 가능한 SQL을 사용하세요.

실수 2: 벡터 검색(Vector search)을 진실로 취급하기

벡터 검색(Vector search)은 유사한 텍스트를 찾아낼 뿐입니다. 해당 텍스트가 최신인지, 권한이 있는지, 혹은 정확한지를 증명하지는 않습니다. 메타데이터 필터(metadata filters), 소스 신선도(source freshness), 그리고 인용(citations)을 추가하세요.

실수 3: 너무 많은 컨텍스트(Context)를 보내는 것

컨텍스트가 많아지면 오히려 답변의 질이 떨어질 수 있습니다. 비용, 지연 시간(latency), 그리고 주의 분산(distraction)을 증가시킵니다. 가장 작으면서도 유용한 결과만을 반환하세요.

실수 4: 불확실성을 숨기는 것

데이터가 누락되었거나, 오래되었거나, 부분적이라면 답변에 그 사실을 명시해야 합니다. 사용자는 확신에 찬 추측보다 신중한 답변을 더 신뢰합니다.

실수 5: 내부 도구(Internal tools)를 건너뛰는 것

데이터 액세스 레이어(Data access layer)는 사용자 대상 채팅만을 위한 것이 아닙니다. 지원 에이전트(support agents), 관리자 대시보드(admin dashboards), 온보딩 보고서(onboarding reports), QA 워크플로(QA workflows), 그리고 내부 코파일럿(internal copilots)을 지원하는 데에도 도움이 됩니다.

간단한 구축 계획

1인 개발자나 소규모 팀이라면 단계별로 구축하세요.

1주 차: 질문 목록 작성 (Inventory the questions)

AI 기능이 답변해야 할 상위 20개의 사용자 질문을 나열하세요. 각 질문을 텍스트 검색(text retrieval), 구조화된 쿼리(structured query), 워크플로 상태(workflow state), 또는 혼합형(mixed)으로 분류하세요.

2주 차: 5개의 안전한 도구 정의 (Define five safe tools)

데이터베이스 전체를 노출하지 마세요. 가치가 높은 질문들을 위해 5개의 좁은 범위의 도구를 만드세요. 입력 스키마(input schemas)와 출력 스키마(output schemas)를 추가하세요.

3주 차: 정책 검사 추가 (Add policy checks)

모든 호출에 테넌트(tenant), 사용자(user), 역할(role), 목적(purpose)을 요구하세요. 기본적으로 거부(Deny by default)하고, 거부된 내역을 로그로 남기세요.

4주 차: 근거 추가 (Add evidence)

소스 ID(source IDs), 타임스탬프(timestamps), 쿼리 요약(query summaries)을 반환하세요. 모델이 사용자 대상 답변에서 근거를 인용하도록 만드세요.

5주 차: 품질 측정 (Measure quality)

예상되는 근거가 포함된 테스트 프롬프트(test prompts)를 만드세요. 오답, 인용 누락, 과도한 데이터 가져오기(over-fetching), 정책 거부, 그리고 지연 시간(latency)을 추적하세요.

작은 버전에서도 실제 가치를 얻을 수 있습니다. 핵심은 신뢰할 수 있는 경로를 먼저 만든 다음, 이를 확장해 나가는 것입니다.

아키텍처를 강화하기 위한 내부 링크

이 패턴은 다음과 같은 인접한 프로덕션 작업과 잘 결합됩니다:

• 모델 라우팅 (routing), 캐싱 (caching), 폴백 (fallbacks) 및 비용 제어를 위해 **LLM 게이트웨이 (LLM gateway)**를 사용하세요.
• 도구 결과와 최종 답변이 스키마 (schema)와 일치하도록 **구조화된 출력 검증 (structured output validation)**을 사용하세요.
• 중대한 진술에 대해 **주장 검증 파이프라인 (claim verification pipeline)**을 사용하세요.
• 프롬프트 (prompt)에 개인적인 컨텍스트가 포함되지 않도록 **데이터 최소화 (data minimization)**를 사용하세요.
• 요청부터 최종 답변까지의 도구 호출을 추적하기 위해 **에이전트 관측성 (agent observability)**을 사용하세요.

이러한 요소들이 결합되어 프롬프트 튜닝 (prompt tuning)만 하는 것보다 더 강력한 프로덕션 기반을 구축합니다.

최종 요약 (Final takeaway)

데이터에 접근할 수 있는 에이전트라고 해서 자동으로 유용해지는 것은 아닙니다. 데이터 경로가 범위가 지정되고 (scoped), 최신이며 (fresh), 설명 가능하고 (explainable), 테스트 가능할 (testable) 때 비로소 유용해집니다.

에이전트가 대중화되기 전에 AI 데이터 액세스 레이어 (AI data access layer)를 구축하세요. 사용자가 잘못된 답변을 발견한 후에 신뢰성을 사후에 보완하는 것보다, 초기에 권한, 메트릭 정의 (metric definitions), 근거를 강제하는 것이 훨씬 쉽습니다.

최고의 AI 제품은 가장 큰 프롬프트를 보내기 때문에 승리하는 것이 아닙니다. 적절한 시점에, 적절한 가드레일 (guardrails)과 함께, 적절한 소스로부터 모델에게 올바른 컨텍스트 (context)를 제공하기 때문에 승리할 것입니다.

자주 묻는 질문 (FAQ)