에이전트 AI는 데이터베이스 설계의 암묵적 가정을 깬다

Who Should Read

LLM 에이전트에 Postgres 접근 권한을 주려는데 안전장치 설계가 막막한 백엔드 개발자

Core Mechanics

• DB는 사람이 짠 코드가 호출한다고 가정했다
  • 사람이 SQL을 쓰고 리뷰하고 배포하는 전제로 인덱스와 커넥션 풀을 잡아 왔다.
  • 에이전트는 추론으로 쿼리를 만들어서 처음 보는 5개 테이블 조인도 날릴 수 있다.
• 에이전트의 쓰기는 의도적이지 않을 수 있다
  • 에이전트는 잘못 이해한 채로 쓰거나 재시도하며 반복해서 쓴다.
  • 원문 사례는 API가 HTTP 200과 빈 결과를 줬고 에이전트가 500건을 불완전한 데이터로 승인한 경우다.
• soft delete, append-only 로그, 멱등성 키를 깐다
  • agent가 쓰는 테이블은 hard delete 대신 deleted_at, deleted_by, delete_reason 컬럼을 둔다.
  • 중요한 데이터는 UPDATE 없이 INSERT만 하는 로그 테이블로 만들고 idempotency_key에 UNIQUE를 건다.
• 에이전트는 커넥션을 오래 잡고 늘어난다
  • LLM 추론 시간 동안 커넥션을 잡고 있고 서브 에이전트로 세션이 팬아웃된다.
  • 에이전트 전용 풀을 따로 두고 PgBouncer를 transaction 모드로 쓰라고 한다(원문 예시는 실제 연결 20개로 클라이언트 500개).
• 나쁜 쿼리가 조용히 지나간다
  • 에이전트는 느린 결과도 그냥 쓰고 빈 결과가 진짜 없음인지 쿼리 오류인지 모른다.
  • 쿼리에 agent_id, task_id, step 주석을 붙여 pg_stat_statements에서 집계하라고 한다.
• 스키마는 이제 LLM과의 계약이다
  • stat_cd, flg_1 같은 이름은 Text-to-SQL에서 틀린 쿼리를 부른다.
  • 못 바꾸는 레거시는 이름을 풀어 쓴 agent용 VIEW와 COMMENT로 감싼다.
• 권한은 에이전트 타입별 role로 최소화한다
  • 에이전트마다 role을 나눠 필요한 테이블·컬럼에만 GRANT 한다.
  • 앱 코드가 아니라 DB 레벨에서 폭발 반경(blast radius)을 줄이라는 얘기다.

Community Reactions

• 에이전트에 프로덕션 DB 직접 접근을 주는 것 자체가 문제라는 의견
  • 쓰기는 저장 프로시저나 API 레이어로 허용 범위를 미리 정의해야 한다는 댓글이 여러 개였다.
  • 탐색용 쿼리는 분석용 별도 DB에서 하면 된다는 주장이다.
• 읽기와 쓰기를 나눠 쓰는 실사용 패턴 경험
  • 한 댓글은 OLTP를 near real-time으로 OLAP에 복제해 읽기를 맡기고 쓰기는 API로만 한다고 했다.
  • ban_user 대신 request_to_ban_user를 두고 사람이 승인해야 실행되게 한다고 한다.
• 읽기 전용 접근은 생산성이 컸다는 경험
  • 읽기 전용으로 DB를 열어줬더니 보고서를 직접 안 만들던 임원들이 AI에게 물어봐서 만족한다는 댓글이 있었다.
• 원문 코드에 대한 기술적 반론
  • UNIQUE 제약 위반은 조용히 무시되지 않고 에러를 반환하므로 INSERT OR IGNORE 같은 처리가 필요하다는 지적이 있었다.
  • Postgres 커넥션은 무거워서 빠르게 돌리면 비싸다는 점에서 brief는 session을 말하는 듯하다는 의견도 있었다.
• 사람도 이미 같은 문제를 일으킨다는 의견
  • 사용자가 많아지면 사람이 만든 쿼리도 비효율적이고 예측 불가능하다는 댓글이 있었다.
  • 제약조건과 row level 권한을 DB에 박아두라는 의견이다.

How to Apply

• 에이전트용 role에 타임아웃부터 걸기
  • 오늘 agent_worker role을 만들고 statement_timeout을 5s, idle_in_transaction_session_timeout을 10s로 설정하라.
  • 에이전트 접속 계정을 이 role로 바꿔서 폭주 쿼리를 막아라.
• 에이전트 쓰기 경로에 멱등성 키 붙이기
  • task_id, operation, target_id를 해시한 키를 만들어 로그 테이블 UNIQUE 컬럼에 넣어라.
  • 재시도해도 한 번만 쓰이는지 같은 키로 두 번 INSERT해 확인하라.
• 에이전트가 볼 스키마는 VIEW로 감싸기
  • 레거시 컬럼은 agent_ 접두 VIEW로 의미 있는 이름으로 바꿔라.
  • 컬럼마다 COMMENT를 docstring처럼 쓰고 에이전트에는 VIEW 권한만 줘라.
• 쿼리에 agent 컨텍스트 주석 달기
  • 쿼리 앞에 agent_id, task_id, step 주석을 붙이는 SQLAlchemy 이벤트 훅을 넣어라.
  • pg_stat_statements에서 agent_id별로 집계해 시간을 많이 쓰는 에이전트를 찾아라.

Try It

-- Postgres에서 psql로 실행 (agent role 최소 설정 예시)
CREATE ROLE agent_worker;
ALTER ROLE agent_worker SET statement_timeout = '5s';
ALTER ROLE agent_worker SET idle_in_transaction_session_timeout = '10s';

CREATE TABLE order_state_log (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  order_id UUID NOT NULL,
  previous_status TEXT,
  new_status TEXT NOT NULL,
  changed_by TEXT NOT NULL,
  changed_at TIMESTAMPTZ DEFAULT now(),
  reason TEXT,
  idempotency_key TEXT UNIQUE
);

GRANT INSERT ON order_state_log TO agent_worker;

Terminology

관련 논문

• 모델이 그렇게 좋다면 OpenAI는 왜 회사 100개를 직접 안 차릴까

  HN 댓글 답: 코드는 쉬워도 뭘 만들지 아는 건 별개라 토큰을 판다

• OpenShell: 자율 AI 에이전트를 가두는 NVIDIA의 안전한 샌드박스 런타임

  정책 파일로 에이전트의 파일·네트워크·자격증명 접근을 커널 수준에서 통제한다

• Omnara: Claude Managed Agents의 오픈소스 대안 (셀프호스팅 가능)

  어떤 모델·머신에서도 에이전트를 돌리는 오픈소스 managed agent 플랫폼

• Rust off Rails: 코드 없이 Markdown 60개로 만든 AI 에이전트용 웹 스택

  Markdown 규칙 60개로 에이전트가 Rust 웹앱을 짜게 한다는 프레임워크

• LayerFS: AI 코딩 에이전트를 위한 파일시스템

  에이전트마다 임시 Workspace를 마운트하고 결과만 커밋하는 파일시스템

• Launch HN: Alter (YC S25) – 멀티유저 에이전트용 접근 제어

  에이전트마다 별도 신원·정책·감사로 API 키 공유 문제를 푼다

• Claude로 코드의 공격 표면(attack surface) 줄이기

  Claude로 25개 오픈소스를 분석해 불필요하게 열린 코드 493건을 찾았다

• WhatsApp 도움말 페이지에 숨겨진 LLM 지시문: 규제기관을 추천하지 말라

  WhatsApp 도움말에 화면엔 안 보이는 AI 지시문 102개가 숨어 있었다

Related Resources

• https://arpitbhayani.me/blogs/defensive-databases/