당신의 AI 에이전트는 데이터베이스 컨텍스트를 원합니다. 가장 빠른 답은 마스터 키입니다.
'읽기 전용(read-only)'으로 설정된 래퍼가 우발적인 COMMIT(트랜잭션을 종료하는 단어)을 통해 쓰기를 해제하게 만들 수 있습니다. 도구(tool)에 대한 약속은 요청입니다. 역할(role)에 대한 규칙은 벽입니다.
여기에 사다리가 있습니다.
A padlock labelled READ-ONLY, cracked open by the word COMMIT;
Context pipeline: production database to pg_dump --schema-only to schema.sql to your agent; the master-key route is blocked by the gate agent_ro: SELECT on 1 view.
에이전트는 데이터베이스의 _구조(shape)_가 필요합니다: 테이블, 컬럼, 링크. 이것이 지도입니다. 쓰기 권한이 있는 로그인은 마스터 키와 같습니다. OWASP는 이를 **과도한 에이전시(Excessive Agency)**라고 부릅니다: 직무에 필요한 것보다 더 많은 권한을 의미합니다.
The ladder: schema-only dump, masked snapshot, read-only replica - and production write access, marked never.
1 · 스키마 전용 덤프(Schema-only dump). 청사진만, 행은 없음 · 깨질 수 있는 것: 아무것도 아님
2 · 마스킹된 스냅샷 (임시 복사본, 가짜 이름). 실제 구조는 유지, 값은 가짜 · 깨질 수 있는 것: 실체가 없는 것
3 · 읽기 전용 복제본(Read-only replica) + 읽기 전용 역할(read-only role). 살아있는 구조의 데이터, SELECT만 가능 · 깨질 수 있는 것: 읽을 수는 있지만, 쓸 수는 없음
4 · 프로덕션 환경, 쓰기 접근 권한. 모든 것 · 깨질 수 있는 것: 모든 것. 절대로 이 단(rung)은 사용하지 마십시오.
첫 번째 단(Rung 1)은 한 줄입니다. 이는 청사진(테이블, 인덱스, 규칙)을 복사하고 모든 행(row)은 제외합니다. 에이전트의 코딩 지원 대부분에 대해 이것만으로 충분한 답변입니다.
pg_dump --schema-only your_db > schema.sql
Three fences on the role: read-only default, 5-second timeout, one view only. Defaults are fences; the GRANT is the wall.
CREATE ROLE agent_ro LOGIN;
ALTER ROLE agent_ro SET default_transaction_read_only = on;
ALTER ROLE agent_ro SET statement_timeout = '5s';
...
Role은 에이전트의 MCP 서버(에이전트가 통신하는 작은 도구 서버)가 사용하는 로그인 계정입니다. GRANT는 벽과 같습니다: 단 하나의 뷰(선별된 창문)에 대한 읽기 전용 접근 권한만 부여하며, 그 외에는 아무것도 없습니다. 모든 세션은 기본적으로 읽기 전용으로 시작되며, 5초가 지난 쿼리는 만료되지만, 세션 자체는 이 두 가지 기본값(경계선, fences)을 변경할 수 있습니다: 벽 자체가 아닙니다. 타임아웃 기본 설정이 꺼져 있기 때문에, 하나의 즐거운 다섯 테이블 조인(five-table join)이 오후 내내 복제본(replica)에 머무를 수 있습니다. 반드시 staging 환경(운영 환경의 테스트 사본)에서 먼저 테스트하세요.
또한 필요한 것: GRANT USAGE ON SCHEMA agent_views TO agent_ro;가 없으면 에이전트가 뷰 자체를 볼 수 없습니다.
The COMMIT story: a wrapper's read-only promise breaks with one word; a SELECT-only grant does not.
참조 MCP Postgres 서버(현재는 아카이브됨)는 에이전트의 쿼리를 읽기 전용 트랜잭션으로 감쌌습니다. [Datadog Security Labs]에 따르면, 사소한 COMMIT; 하나가 이를 끝장냈고, 그 이후 실행되는 모든 작업은 읽기-쓰기(read-write)로 작동했습니다. 래퍼(wrapper)의 약속은 요청일 뿐입니다.
에이전트가 마이그레이션(테이블 구조를 변경하는 스크립트)을 _작성_하도록 하세요. 그리고 당신이 그것을 _실행_하세요. 먼저 스냅샷에서 리허설을 진행하세요:
BEGIN;
-- 에이전트가 작성한 마이그레이션 코드가 여기에 들어갑니다
-- 실제로 무엇을 했는지 읽어봅니다
...
DROP DATABASE와 같은 몇몇 명령어는 트랜잭션 내부에서 실행될 수 없습니다. 그런 다음 사람이 실제 환경에서 실행합니다: 반드시 staging부터, 그리고 운영(production) 순서로 진행해야 합니다. 배우들도 리허설을 하듯이 말입니다.
Save this: the Map, Not Keys ladder card with the four rungs and the six-item pre-flight checklist.
연결 문자열을 붙여넣기 전에
- 스키마 전용 접근(Schema-only first):
pg_dump --schema-only가 이미 에이전트의 요구를 충족시켰습니까?
- SELECT만 가능한 역할: 에이전트 로그인에서 INSERT, UPDATE, DELETE 또는 구조 변경을 허용하지 않습니다.
- 도구뿐만 아니라 역할 자체에 대한 읽기 전용 설정(Read-only on the role, not just the tool):
ALTER ROLE을 통한 default_transaction_read_only를 사용합니다.
- 구문 시간 초과(Statement timeout): 해당 역할에 대해 짧게 설정하여 잘못된 조인(join)이 일찍 실패하게 합니다.
- 허용 목록(Allowlist) 뷰만 부여: 가공된 뷰만을 사용하고 원시 테이블은 절대 사용하지 않습니다.
- 마이그레이션 연습 및 인간의 커밋(Migrations rehearsed, human-committed): 폐기 가능한 복사본에 대해
BEGIN … ROLLBACK을 수행하며, 실제 버튼은 사람이 누릅니다.
컨텍스트는 아낌없이 제공하십시오. 접근 권한은 인색하게 제한하십시오. 이제 차이(chai)를 마저 끝내십시오.
© 2026 Honey Kiran. 모든 권리 보유.
Honey Kiran · DevOps & Platform Engineering
저는 SRE, Kubernetes, Terraform 및 플랫폼 엔지니어링에 대해 글을 씁니다. 이는 문제를 일으키는 기본값(defaults), 교훈을 주는 사고(incidents), 그리고 지탱하는 가드레일(guardrails)입니다.
오늘 당신의 에이전트는 어느 단계에 있으며, 그 "읽기 전용(read-only)"은 데이터베이스에서 오는 것입니까 아니면 단지 도구에서 오는 것입니까? 댓글로 알려주세요.
예시는 참고용입니다—운영 환경에 배포하기 전에 자체 환경에서 검증하십시오.
면책 조항(Disclaimer)
- 본 게시물은 저 자신의 시스템과 계정에서 겪은 저의 개인적인 경험을, 저의 언어로 작성한 것입니다. 이는 제가 직접 관찰하고 수행한 작업에 대한 1인칭 기록이며, 어떤 회사의 의도, 정책 또는 내부 결정을 대변하는 것이 아닙니다. 제가 모르는 부분은 그렇게 명시합니다.
- 저는 본 게시물에 언급된 어떠한 회사, 제품 또는 공급업체와도 제휴하거나, 보증하거나, 대변하지 않습니다. 모든 제품 및 회사 이름은 각 소유자의 상표권이며, 경험을 정확하게 설명하기 위해만 언급되었습니다.
- 여기에 인용된 오류 메시지, 문서 발췌문 또는 수치들은 제가 직접 기록했거나 게시물에 링크된 공개 출처에서 가져온 것이며, 작성 시점에 정확하다고 믿어진 것입니다. 제품의 동작은 시간이 지남에 따라 변경되므로, 어떤 세부 사항에 의존하기 전에 반드시 현재 공식 문서를 통해 검증해야 합니다.
- 본 게시물의 어떠한 내용도 귀하의 특정 상황에 대한 전문적, 재정적, 법률적 또는 보안 조언이 아닙니다. 예시는 설명용이며, 프로덕션 환경에서 실행하기 전에 반드시 자체 환경에서 유효성을 검증하십시오.
- 수정 제안을 환영합니다. 만약 여기에 언급된 회사 중 어느 곳이라도 공식 성명을 발표하거나, 어떤 세부 사항에 오류가 있다면, 저는 이 게시물을 업데이트하고 수정을 명시할 것입니다. 목표는 판결이 아닌 정확한 공개 기록입니다.
