이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
LLM에 운영 데이터베이스를 연결할 때 읽기 전용 역할만 부여하면 쓰기는 막을 수 있지만 사용자가 읽어서는 안 되는 급여나 재무 데이터까지 조회하는 문제는 남습니다. DeepSQL은 영어 정책을 스키마 허용 목록과 테이블·컬럼 차단 목록으로 바꾼 뒤 스키마 인트로스펙션, 실행 전 가드, 스키마 API에서 적용해 금지된 객체가 모델 컨텍스트에 들어가지 않게 합니다. 가드는 최상위 FROM 절이 아니라 CTE, 서브쿼리, UNION 분기까지 포함한 전체 문장을 검사하고 COMMENT와 CALL의 오탐을 줄여 보안 경계가 꺼지지 않도록 합니다. View as는 대상 사용자의 제약을 에이전트에도 적용한 상태에서 정책을 약 30초 안에 검증하게 하며, DeepSQL은 자체 VPC와 모델 엔드포인트를 사용하는 self-hosted 형태로 공개되어 있습니다.
섹션별 상세
LLM 데이터베이스 도구에서 읽기 전용 연결만 사용하는 방식은 쓰기 변경만 막을 뿐 조회 권한을 구분하지 못합니다. 여러 사용자를 하나의 서비스 계정으로 묶으면 지원 엔지니어도 재무나 인사 테이블을 자연어로 조회할 수 있고, 감사 로그에는 실제 사용자가 아니라 deepsql_agent만 남습니다. 따라서 자연어가 SQL 숙련도라는 우연한 접근 장벽을 없애는 만큼, 사용자별 읽기 권한과 추적성을 별도로 설계해야 합니다.
DeepSQL v1.2.0은 관리자가 영어로 작성한 규칙을 허용 스키마 목록과 테이블·컬럼 deny list로 변환합니다. 변환된 정책은 모델이 통제하지 못하는 세 지점인 스키마 인트로스펙션, 실행 전 쿼리 가드, 웹 UI와 MCP 클라이언트가 호출하는 스키마 API에서 적용됩니다. 금지된 객체를 컨텍스트에 넣지 않는 구조는 실행 시 거부하는 것만으로는 막기 어려운 테이블명과 컬럼명 노출을 줄이는 데 의미가 있습니다.
SQL 접근 제어는 최상위 쿼리의 FROM 절만 검사해서는 CTE나 서브쿼리 내부의 민감한 테이블 참조를 놓칠 수 있습니다. 예시에서는 crm.customers가 허용된 대상처럼 보이지만 CTE가 hr.compensation에서 employee_id와 base_salary를 읽어 최종 결과에 급여를 섞습니다. 따라서 CTE, 모든 서브쿼리, UNION 분기, lateral join을 문장 전체에서 허용 목록과 대조해야 하며, 그렇지 않으면 allowlist가 장식에 그칩니다.
sql
WITH leak AS (
SELECT employee_id, base_salary FROM hr.compensation
)
SELECT c.name, l.base_salary
FROM crm.customers c
JOIN leak l ON l.employee_id = c.owner_id;최상위 FROM 절에는 허용된 crm.customers만 나타나지만 CTE가 hr.compensation의 급여 컬럼을 읽어 결과에 포함하는 우회 사례입니다.
보안 가드는 차단율만 높이는 것이 아니라 정상 작업을 막지 않을 정도의 분류 정확도도 확보해야 계속 켜둘 수 있습니다. DeepSQL은 COMMENT ON TABLE처럼 실제 변경이 아닌 구문을 mutation으로 잘못 판정했던 사례를 수정하고, CALL도 동일한 구분 대상에 넣었습니다. SQL 에디터가 에이전트와 다른 코드 경로를 사용하면 사용자가 직접 입력한 문장으로 제약을 우회할 수 있으므로 두 입력 표면을 같은 정책 경계 안에 둬야 합니다.
정책이 실제 사용자에게 어떻게 보이는지 확인하지 않으면 관리자 작성 규칙은 검증되지 않은 가정으로 남습니다. DeepSQL의 View as 기능은 자격 증명 없이 대상 프로필의 스키마 트리, 에이전트, 대시보드를 그 사용자처럼 확인하게 하며, 새 규칙 검사를 약 30초 안에 수행할 수 있게 합니다. 가장 세션의 에이전트가 관리자 정책을 계속 사용하던 후속 문제도 수정되어야 하므로, 화면뿐 아니라 에이전트의 제약 계산까지 대상 사용자 기준으로 바뀌어야 합니다.
데이터베이스 노출은 잘못된 배포처럼 되돌리기 어렵고, 한 번 읽힌 행을 회수할 수 없다는 점에서 설계 단계의 예방이 중요합니다. DeepSQL은 self-hosted 방식으로 자체 VPC와 모델 엔드포인트 안에서 실행되며, 정책을 인트로스펙션·가드·스키마 API에 걸쳐 적용하고 전체 SQL 문장을 해석합니다. 저장소는 GitHub의 github.com/DeepSQLAI/deepsql에 공개되어 있고 v1.2.0은 git checkout과 docker compose up --build -d로 실행할 수 있습니다.
용어 해설
- 스키마 범위 접근 정책(Schema-scoped Access Policies)
- — 사용자나 역할이 접근할 수 있는 데이터베이스 스키마를 제한하고, 추가로 테이블과 컬럼의 deny list를 적용하는 권한 관리 방식입니다. DeepSQL은 관리자가 작성한 영어 규칙을 허용 스키마 목록과 테이블·컬럼 차단 목록으로 변환해 실행 전 검사와 스키마 노출 제어에 사용합니다.
- 스키마 인트로스펙션(Schema Introspection)
- — 데이터베이스의 스키마, 테이블, 컬럼 같은 구조 정보를 읽어 에이전트나 애플리케이션의 컨텍스트로 가져오는 과정입니다. 접근이 금지된 객체를 이 단계에서 제외하면 모델이 실행 전에 민감한 테이블 이름과 컬럼명을 접하지 않으므로, 사후 쿼리 차단만 사용하는 방식보다 정보 노출 범위를 줄일 수 있습니다.
- SQL 문장 가드(Statement Guard)
- — SQL을 실행하기 전에 문장 전체가 정책에 부합하는지 검사하는 보안 계층입니다. 최상위 FROM 절만 확인하지 않고 CTE, 서브쿼리, UNION, lateral join 같은 내부 구성요소까지 해석해야 우회 경로를 막을 수 있으며, COMMENT와 CALL처럼 변경으로 오인하기 쉬운 구문도 정확히 분류해야 보호 기능이 꺼지는 일을 피할 수 있습니다.
- 사용자 가장(Impersonation)
- — 관리자가 다른 사용자의 권한과 화면 경험을 대신 확인하는 기능입니다. 실제 사용자의 자격 증명을 사용하지 않고 대상 프로필의 스키마 트리, 에이전트, 대시보드를 확인할 수 있어 정책 검증을 반복 가능한 절차로 만들며, 가장 세션 안의 에이전트에도 대상 사용자의 제약을 적용해야 의미가 있습니다.
- 읽기 전용 역할(Read-only Role)
- — 데이터베이스의 INSERT, UPDATE, DELETE 같은 변경 작업을 막고 조회만 허용하는 권한 역할입니다. 그러나 읽기 자체를 차단하지는 않으므로 지원 엔지니어가 접근할 수 없어야 할 급여나 재무 테이블도 조회할 수 있습니다. 따라서 쓰기 방지와 행·테이블·컬럼 단위 접근 통제는 별도의 문제로 다뤄야 합니다.
기술
- DeepSQL
- Postgres
- MySQL
- MCP
- SQL
- Docker Compose
활용 사례
- 지원 엔지니어의 고객·티켓 데이터 조회
- 재무·인사 데이터가 포함된 기업용 분석 시스템
- 사용자별 접근 정책을 적용한 자연어 데이터베이스 질의
- 관리자가 실제 사용자 권한을 검증하는 데이터베이스 운영
언급된 리소스
GitHubDeepSQLAI/deepsql
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 22.수집 2026. 08. 22.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
