AI Agent를 위한 안전한 DB 접근 계층 API로 제한하는 실무 보안 설계

AI Agent의 DB 직접 접근을 막고 API로만 통제하는 설계

AI 에이전트에게 DB 접속 권한을 직접 주면 편해 보이지만, 실제 운영에서는 다음 문제가 생깁니다.

1) 과도한 행위 발생 위험

AI는 의도와 다르게 쿼리를 넓게 만들 수 있습니다.

너무 많은 row 조회
불필요한 JOIN 확장
민감 컬럼 포함 조회
잘못된 UPDATE / DELETE 실행
대량 export 성격의 쿼리 생성

즉, 사람이 “이 정도만 조회하겠지”라고 생각해도, 모델은 맥락상 과하게 동작할 수 있습니다.

2) 통제와 감사가 어려움

SQL 직접 실행은 유연하지만, 그만큼 통제가 어렵습니다.

어떤 사용 목적이었는지 추적이 어려움
결과적으로 어떤 데이터를 노출했는지 추적이 어려움
쿼리 한 번에 여러 테이블을 엮어 민감정보를 재구성할 수 있음
악의적 프롬프트 인젝션에 취약해짐

3) DB는 업무 규칙의 중심이 아님

DB는 저장 계층이지, 업무 정책의 중심이 아닙니다.
AI 통제는 “테이블 단위”가 아니라 “업무 행위 단위”로 관리해야 합니다.

예를 들어, “주문 조회”, “고객 상태 변경”, “장애 이력 조회” 같은 업무 의미가 있는 기능으로 분리해야 합니다.

DB가 아니라 API를 AI의 유일한 통로로 만들기

가장 안전한 구조는 다음입니다.

AI Agent
  -> Function / Tool 호출
  -> Agent Gateway 또는 API Gateway
  -> Policy Engine
  -> Business API / Query Service
  -> DB

즉, AI는 DB를 모르게 하고, 허용된 API만 호출하게 만드는 방식입니다.

이 구조의 장점은 분명합니다.

허용된 행위만 제공 가능
데이터 범위를 제한하기 쉬움
민감정보 마스킹 가능
감사로그를 남기기 쉬움
쓰기 작업은 승인형으로 분리 가능
도메인 규칙을 API에서 강제 가능

“DB 프록시”, “DB 릴레이”, “DB API”는 어떻게 다른가

용어가 비슷해서 헷갈리기 쉬운데, 목적이 다릅니다.

1) DB 프록시

DB 연결을 중간에서 대신 받아주는 계층입니다.

역할

연결 풀링
TLS 종료
인증서 관리
접속 제어
일부 쿼리 로깅

한계

SQL 자체는 여전히 자유도가 높음
AI가 넓은 쿼리를 만들 수 있음
업무 의미 기반 통제가 어려움

300x250

즉, 전송 중계에는 좋지만 AI 행동 통제에는 약합니다.

2) DB 릴레이

“중계 서버”라는 의미로 많이 쓰입니다.
실질적으로는 프록시와 유사하거나, 내부 규칙 없이 단순 전달만 하는 경우가 많습니다.

한계

통제 포인트가 약함
의미 기반 검증이 어려움
AI가 악의적 또는 비정상적 요청을 보낼 때 막기 어려움

즉, 릴레이만 두는 것은 보안적으로 충분하지 않은 경우가 많습니다.

3) DB API

업무 기능을 API로 노출하는 방식입니다.

예시

GET /orders/{id}
GET /customers?email=...
POST /reports/sales-summary
PATCH /users/{id}/status

장점

허용된 기능만 노출
파라미터 검증 가능
레코드 수 제한 가능
마스킹, 승인, 감사 적용 가능
쿼리 복잡도를 서버에서 통제 가능

실무적으로는 가장 추천되는 방식입니다.

설계 방식의 큰 분류

AI 에이전트용 DB 접근 통제 방식은 크게 4가지로 나눌 수 있습니다.

1. 단순 프록시형

AI가 내부 DB 프록시 서버에 요청하면, 프록시가 전달하는 방식입니다.

적합한 경우

접속 통제만 필요할 때
초기에 빠르게 구성할 때
레거시 시스템에 최소 변경으로 붙일 때

문제점

정책 검증이 약함
행위 단위 제어가 어렵다
복잡한 검색 조건이 들어오면 제어 난이도 상승

결론

보안 통제의 중심으로 쓰기에는 부족합니다.

2. SQL Allowlist형

AI가 SQL을 직접 쓰지는 못하지만, 정해진 SQL 템플릿만 호출하는 방식입니다.

예시

get_order_detail(order_id)
list_failed_logins(hostname, from, to)
get_sales_summary(from, to, group_by)

서버 내부에는 고정된 SQL이 있고, 외부 입력은 파라미터로만 받습니다.

장점

SQL 인젝션 방어에 유리
허용된 쿼리만 실행
빠르게 안전성 확보 가능

단점

템플릿이 많아지면 관리가 어려움
유연한 탐색성은 낮음

적합한 경우

보안이 중요하고 조회 패턴이 비교적 정형화된 환경

3. 구조화 요청(JSON DSL)형

AI가 SQL 대신 구조화된 요청만 보내는 방식입니다.

예시

{
  "dataset": "orders",
  "select": ["order_id", "customer_id", "amount"],
  "filters": {
    "status": "paid",
    "created_at": {
      "from": "2026-05-01",
      "to": "2026-05-27"
    }
  },
  "sort": [
    {"field": "created_at", "direction": "desc"}
  ],
  "limit": 100
}

서버는 이 요청을 검증한 뒤 내부 정책에 맞는 SQL로 변환합니다.

장점

컬럼 allowlist 적용 가능
필터 검증이 쉬움
limit 강제 가능
조회 대상 범위를 통제하기 좋음

단점

DSL 설계가 필요함
복잡한 분석 조회는 별도 설계가 필요함

적합한 경우

AI가 다루는 데이터 조회를 점진적으로 표준화하고 싶을 때

4. 도메인 API형

업무 기능별로 API를 명확히 정의하는 방식입니다.

예시

주문 조회 API
고객 상태 조회 API
장애 이력 조회 API
보안 이벤트 조회 API
통계 요약 API

장점

가장 안전하고 관리 쉬움
업무 정책과 자연스럽게 연결
승인 흐름과 감사 체계 넣기 좋음
AI에게 “무엇을 할 수 있는지”를 분명히 제공

단점

API 설계와 개발 비용이 듦
초기에는 기능 쪼개기가 필요함

적합한 경우

장기적으로 운영할 AI 에이전트 시스템
민감한 데이터와 운영 데이터가 섞인 환경

결론

실무에서는 도메인 API형이 최종 목표가 되는 경우가 많습니다.

가장 권장되는 아키텍처

실무적으로 가장 균형 잡힌 구조는 다음입니다.

AI Agent
  -> Tool Calling / Function Calling
  -> Agent Gateway
  -> Policy Engine
  -> Business API
  -> DB

여기에 다음 요소를 붙입니다.

인증: 서비스 계정 / 사용자 토큰 / 에이전트 토큰
인가: role, scope, tenant, resource 단위 통제
감사: 호출자, 목적, 파라미터, 결과 건수 기록
제한: timeout, row limit, rate limit, concurrency limit
마스킹: 주민번호, 이메일, 전화번호, 계정 정보 등
승인: 삭제, 대량수정, 민감정보 조회는 human approval

API 설계의 핵심 원칙

1. SQL이 아니라 “업무 행위”를 API로 설계

좋지 않은 예

POST /query
POST /sql

좋은 예

GET /orders/{id}
GET /orders
POST /reports/sales-summary
PATCH /customers/{id}/status

AI에게는 “SQL 실행기”가 아니라 “업무 기능 호출기”를 주는 것이 안전합니다.

2. 읽기와 쓰기를 분리

읽기와 쓰기를 같은 API/권한으로 섞지 않는 것이 중요합니다.

읽기 전용

조회
검색
집계
통계
상태 확인

쓰기 작업

등록
수정
삭제
권한 변경
상태 변경

AI는 기본적으로 읽기만 허용하고, 쓰기 작업은 별도의 workflow 또는 승인 단계가 필요합니다.

3. 결과 크기와 범위를 강제

무제한 조회는 위험합니다.

강제할 항목

limit 상한
기본 페이지네이션
날짜 범위 제한
검색 조건 필수화
대량 export 금지
민감 컬럼 제외

예시

기본 limit=50
최대 limit=500
기간 조건 없으면 조회 불가
개인정보 포함 조회는 승인 필요

4. 컬럼 allowlist 사용

테이블 전체를 노출하지 말고, 허용된 컬럼만 노출해야 합니다.

예시

허용: 주문번호, 상태, 금액, 생성일
비허용: 카드 식별 정보, 내부 메모, 계정 토큰, 감사상 민감 필드

이 방식은 AI가 의도치 않게 내부 비밀정보를 조합하는 것을 막는 데 매우 중요합니다.

기술적으로 반드시 넣어야 할 통제 포인트

1. 인증(Authentication)

AI 에이전트가 누구인지 식별해야 합니다.

OAuth2 client credentials
JWT
mTLS
내부 서비스 토큰
워크플로우별 별도 API Key

중요한 것은 “누가 호출했는지”를 명확히 남기는 것입니다.

2. 인가(Authorization)

누가 무엇을 할 수 있는지 제한해야 합니다.

읽기 가능
특정 데이터셋만 접근 가능
특정 테넌트만 접근 가능
특정 시간대만 접근 가능
특정 작업은 승인 후만 가능

권한은 사용자 기준뿐 아니라 에이전트 tool 기준으로도 관리하는 것이 좋습니다.

3. 요청 검증

입력값 검증은 매우 중요합니다.

허용된 필드만 받기
숫자 범위 체크
문자열 길이 제한
정규식 검증
날짜 형식 검증
허용되지 않은 조합 차단

예시

status는 paid, pending, canceled만 허용
from <= to
최대 조회 기간 31일
search는 특수문자 폭주 제한

4. 쿼리 안전장치

내부적으로 SQL을 생성할 때는 다음을 반드시 적용하는 것이 좋습니다.

Prepared Statement
ORM 또는 Query Builder
SQL 템플릿 고정
SELECT * 금지
조인 수 제한
정렬 가능 필드 제한
서브쿼리 제한
timeout
max rows
explain cost 제한 가능하면 적용

5. 감사 로그

AI 운영에서 가장 중요합니다.

기록해야 할 것:

호출자
에이전트 이름
tool 이름
요청 시각
파라미터 요약
반환 row 수
성공/실패 여부
쓰기 작업이면 변경 대상과 변경 전후 요약
승인 여부

예시

2026-05-28T10:15:21Z agent=sec-bot tool=get_sales_summary
user=jjchoi scope=finance.read
params={from:2026-05-01,to:2026-05-27,group_by:day}
result_rows=27 status=success

민감 정보 통제 방식

AI 시스템에서 가장 조심해야 할 것은 조회 데이터가 “너무 잘 보이는 것”입니다.
따라서 다음 기능이 중요합니다.

1. 마스킹

이메일 일부 마스킹
전화번호 일부 마스킹
주민번호/계좌번호 마스킹
토큰/비밀번호/세션값 완전 비노출

예시

hong***@company.com
010-****-1234

2. 최소 공개 원칙

AI에게는 업무 수행에 필요한 최소 정보만 보여줘야 합니다.

예시

주문 처리 에이전트에게는 주문 상태와 금액만
보안 에이전트에게는 이벤트 요약과 호스트명만
고객센터 에이전트에게는 고객 식별자와 티켓 상태만

3. 민감 조회는 별도 도구

PII, 결제, 내부 감사, 인사 데이터는 일반 조회 API와 분리하는 것이 좋습니다.

쓰기 작업은 특히 더 엄격해야 함

조회보다 수정이 훨씬 위험합니다.

권장 패턴

읽기 API: 자동 허용
쓰기 API: 조건부 허용
고위험 쓰기: 사람 승인 필수

예시

고객 상태 비활성화
권한 부여
대량 데이터 수정
삭제
아카이브
외부 시스템 연동 전송

승인 흐름 예시

AI 요청
  -> 변경안 생성
  -> 정책 엔진 검토
  -> 사람 승인
  -> API 실행
  -> 결과 감사로그 기록

이 패턴이 있으면 AI가 실수해도 피해를 줄일 수 있습니다.

API 구현 방식 예시

1. REST API

가장 보편적입니다.

예시

GET /api/v1/orders?status=paid&from=2026-05-01&to=2026-05-27&limit=50

장점

단순
감사와 프록시 연동 쉬움
AI tool로 연결하기 편함

2. GraphQL

유연한 조회에는 좋지만, 보안 통제가 어렵게 느껴질 수 있습니다.

장점

원하는 필드만 선택 가능
복합 조회에 강함

단점

쿼리 복잡도 통제가 필요
깊은 중첩 조회 방어 필요
비용 제한 없으면 위험

결론

정교한 통제가 필요하면 REST 또는 제한된 DSL이 더 안정적인 경우가 많습니다.

3. gRPC

내부 마이크로서비스 환경에서는 좋습니다.

장점

성능 우수
명세 기반
강한 타입 보장

단점

AI tool로 노출할 때는 변환 계층이 필요할 수 있음

4. Function Calling / Tool Server

AI 에이전트와 가장 잘 맞는 방식입니다.

예시

search_orders
get_customer
get_incident_summary
update_account_status

AI는 함수 이름과 파라미터만 알고, 내부 구현은 모르게 됩니다.
이 방식이 가장 “AI 통제”에 어울립니다.

실제로 많이 쓰는 운영 패턴

패턴 1. 조회 전용 대시보드형

AI는 조회와 요약만 수행합니다.

운영 현황 요약
장애 통계
보안 이벤트 요약
고객 문의 추세
주문 현황 분석

장점

매우 안전
빠르게 도입 가능

패턴 2. 조회 + 승인형 수정

AI는 수정 요청안까지만 만들고, 실제 실행은 사람 승인 후 진행합니다.

예시

계정 비활성화 요청
권한 제거 요청
이상 행위 계정 차단 요청

장점

자동화와 통제의 균형이 좋음

패턴 3. 제한적 자동 수정형

사전 정의된 안전한 조건에서만 자동 실행합니다.

예시

동일 패턴 반복 장애 대응
단순 상태 전환
정해진 임계치 초과 시 알림 등록

조건

정책이 명확해야 함
롤백 가능해야 함
감사로그 필수

패턴 4. 데이터셋별 분리형

업무별로 API와 권한을 분리합니다.

예시

finance API
security API
customer API
inventory API

이 방식은 운영과 보안 모두에 유리합니다.

보안 관점 점검 포인트

내부 사용자나 운영팀에 제시할 때는 아래를 점검 기준으로 삼으면 좋습니다.

1) AI가 DB 계정을 직접 갖지 않는가

운영 DB 직접 연결 금지
read-only 계정도 최소화
필요 시 반드시 API 경유

2) API가 업무 기능 단위로 쪼개져 있는가

SQL 실행 API 금지
범용 query endpoint 금지
의미 있는 기능만 허용

3) 민감정보가 최소화되어 있는가

마스킹 적용
민감 필드 분리
대량 export 차단

4) 쓰기 작업에 승인 절차가 있는가

자동 수정 범위 제한
고위험 작업 승인 필수
되돌리기 절차 존재

5) 모든 호출이 로그로 남는가

누가
언제
무엇을
얼마나
왜 했는지

6) 타임아웃, 레이트리밋, row limit이 있는가

무한 조회 방지
폭주 방지
대량 추출 방지

7) 프롬프트 인젝션 방어가 있는가

tool 허용 범위 고정
tool 설명에 민감정보 금지
결과를 다음 tool의 지시문으로 해석하지 않음
사용자 입력과 시스템 정책 분리

구현 시 흔한 실패 사례

실패 1. AI에게 SQL 문자열을 그대로 허용

가장 위험합니다.
모델이 예기치 않은 쿼리를 만들 수 있고, 인젝션 방어도 어려워집니다.

실패 2. 범용 query API 하나로 모든 DB를 열어둠

겉보기엔 편하지만 사실상 DB 직접 개방과 비슷합니다.

실패 3. 조회 API에 limit 없음

대량 덤프 사고로 이어질 수 있습니다.

실패 4. 민감정보를 그대로 반환

마스킹 없이 보여주면 사고가 커집니다.

실패 5. 감사로그 미흡

사고 후 원인 추적이 거의 불가능해집니다.

예시 API 설계안

조회

GET /api/v1/customers/{customer_id}
GET /api/v1/orders?status=paid&from=2026-05-01&to=2026-05-27&page=1&limit=50
GET /api/v1/security/events?severity=high&from=2026-05-27T00:00:00Z&to=2026-05-28T00:00:00Z

집계

POST /api/v1/reports/sales-summary

{
  "from": "2026-05-01",
  "to": "2026-05-27",
  "group_by": "day"
}

수정

PATCH /api/v1/users/{id}/status

{
  "status": "disabled",
  "reason": "policy_violation"
}

승인 요청

POST /api/v1/approvals

{
  "action": "disable_user",
  "target_id": "u12345",
  "reason": "suspicious_login_pattern"
}

기술 스택 예시

환경에 따라 아래처럼 조합할 수 있습니다.

API 서버: FastAPI, Spring Boot, Node.js, Go
정책 엔진: OPA(Open Policy Agent), 자체 규칙 엔진
인증: OAuth2, JWT, mTLS
감사로그: ELK, OpenSearch, SIEM, DB audit table
승인 흐름: 워크플로우 엔진, Slack 승인, 티켓 시스템
AI 연동: MCP, function calling, tool server
DB 접근 계층: ORM, query builder, stored procedure

현실적인 추천 결론

실무적으로 가장 좋은 순서는 다음입니다.

최종 추천 구조

AI는 DB에 직접 연결하지 않는다
업무 기능 기반 API만 허용한다
SQL은 서버 내부에서만 생성한다
조회/수정/집계를 분리한다
민감 작업은 승인형으로 둔다
감사로그와 마스킹은 필수다
레이트리밋, limit, timeout을 강제한다

즉, DB 프록시는 보조 수단, AI 통제의 본체는 API 계층입니다.

한 문장으로 정리

AI 에이전트에게 DB를 직접 열어주는 대신, 허용된 업무 API만 통해서 데이터 조회·집계·변경을 수행하게 하고, 그 사이에 정책 엔진·감사로그·승인 절차를 두는 구조가 가장 안전하고 운영하기 좋습니다.

“AI Agent용 DB API 표준 설계서” 형태로, 조회 API / 수정 API / 집계 API / 승인 API / 감사로그 / 정책 엔진까지 포함한 문서화를 통해 관리가 필요합니다.

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)