사상 리더
에이전틱 AI와 데이터베이스 개발의 만남: AI가 실제로 쿼리를 실행할 수 있게 되면 무엇이 달라질까
Unite.AI를 Google의 선호 소스에 추가
지난 몇 년간 AI를 활용한 데이터베이스 개발은 비교적 익숙한 방식으로 진행돼 왔다. 개발자가 요구 사항을 설명하면 AI가 SQL을 생성한다. 개발자는 이를 읽고 잘못된 부분을 수정한 뒤 실행 여부를 결정한다.
이런 작업 방식에서는 중요한 경계 하나가 유지됐다. AI는 실행할 작업을 제안할 수 있지만, 그 작업을 데이터베이스에 적용할지는 여전히 사람이 결정한다.
하지만 에이전틱 AI가 등장하면서 그 경계가 사라지기 시작했다. 오늘날 AI 시스템은 스키마를 살펴보고, 쿼리를 실행하고, 결과를 해석한 뒤, 다음에 어떤 작업을 할지 결정할 수 있다. 최근 설문조사에 따르면 조직의 62%가 이미 AI 에이전트를 시험하고 있으며, 23%는 기업 내 어딘가에서 에이전틱 시스템을 확대하고 있다고 답했다.
따라서 데이터베이스 팀은 당장 답해야 할 아키텍처 관련 질문을 마주하고 있다. AI가 SQL을 실행할 수 있느냐는 질문이 아니다. 실행할 수 있다. 진짜 질문은 어시스턴트가 코드 제안을 멈추고 데이터베이스에 직접 작업을 수행하기 시작하면 무엇이 달라지는지, 그리고 그 자율성을 얼마나 엄격하게 통제해야 하는지다.
제안에서 실행으로
간단한 인덱스 결정 사례만 봐도 이런 변화가 왜 중요한지 알 수 있다.
에이전트는 느린 쿼리를 발견하면 스키마를 살펴보고, 인덱스가 도움이 될 수 있다고 판단해 인덱스를 생성한 다음, 워크로드를 다시 실행하고 결과를 확인한다.
다음과 같이 평범한 작업을 실행할 수도 있다.
CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);이 문장 자체는 특별할 것이 없다. AI 어시스턴트도 똑같은 내용을 제안할 수 있다. 차이는 최종 결정을 누가 내리느냐에 있다.
어시스턴트를 사용할 때는 개발자가 제안을 검토하고 테스트한 뒤 실행 여부를 결정한다. AI가 조언하고 사람은 직접 실행한다. 실행 권한이 있는 에이전트라면 시스템이 스스로 결정을 내리고 승인 대기 없이 다음 단계로 넘어갈 수 있다.
그 결정이 옳다면 작업 속도는 빨라진다. 하지만 에이전트가 항상 전체 상황을 파악하는 것은 아니다. 시스템을 운영하는 사람에게는 분명한 애플리케이션 종속성, 비즈니스 규칙, 워크로드 패턴, 유지보수 시간대 또는 그 밖의 맥락을 놓칠 수 있다.
따라서 에이전트는 기술적으로는 합리적으로 보이는 결정을 내리고도, 자신이 작업하는 환경의 구체적인 제약과 요구 사항을 고려하면 잘못된 판단을 할 수 있다.
작업이 연쇄적으로 이어지기 시작하면 위험은 커진다. 잘못된 쿼리는 SELECT 느리게 실행되는 데 그칠 수 있다. 잘못된 명령은 UPDATE 대형 테이블 전체를 잠그거나 의도한 것보다 훨씬 많은 행에 영향을 줄 수 있다. 한 쿼리에 사용되는 인덱스가 불필요할 수도 있지만, 다른 쿼리에는 오버헤드를 더한다. 에이전트가 전체 운영 맥락을 파악하지 못하고 가능한 모든 사용 사례를 테스트할 수도 없기 때문에, 스키마 변경으로 에이전트가 알지 못했던 종속 항목이 깨질 수 있다.
문제는 에이전트가 데이터베이스와 관련해 좋은 결정을 내리지 못한다는 데 있지 않다. 에이전트는 좋은 결정을 내리는 경우가 많다. 문제는 그런 결정을 직접 실행하도록 허용하면 팀이 에이전트의 권한 범위와 접근 가능한 맥락, 사람이 개입해야 하는 지점, 결과에 대한 책임 주체를 훨씬 명확히 해야 한다는 것이다.
Gartner는 위험 통제가 미흡한 점 등을 이유로 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 전망한다. 데이터베이스 팀이 얻을 교훈은 간단하다. 실행 권한은 통제 장치보다 먼저가 아니라, 통제 장치를 마련한 뒤에 부여해야 한다.
안전하게 위임할 수 있는 작업은 무엇일까?
데이터베이스 작업 중에는 다른 작업보다 훨씬 안전하게 맡길 수 있는 것이 있다.
쿼리 분석이 좋은 예다. 에이전트는 쿼리 통계를 살펴보고, 실행 계획을 가져오고, 인덱스와 테이블 구조를 확인한 뒤, 프로덕션 데이터를 변경하지 않고도 가능성 높은 해결책을 제안할 수 있다.
다음과 같은 쿼리가 대형 Orders 테이블을 반복해서 스캔하는 것을 발견할 수 있다.
SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;그런 다음 스캔이 발생하는 이유를 설명하고 인덱스를 제안해 DDL을 생성할 수 있다. 유용하게 쓰이기 위해 반드시 실행할 권한이 CREATE INDEX 필요한 것은 아니다.
다음과 같은 작업도 마찬가지다.
- 실행 계획 설명하기;
- 누락되거나 불필요한 인덱스 식별하기;
- 다음 항목 표시:
SELECT *쿼리 또는 비 SARGable 조건자; - 조인 및 필터 푸시다운 검토하기;
- 종속성 및 스키마 검토하기;
- SQL 오류 해결하기;
- SQL 스크립트 최적화하기.
실무적인 구분은 간단하다. 에이전트가 문제를 파악할 수 있을 만큼 접근 권한을 부여하되, 데이터베이스를 변경할 권한까지 자동으로 부여하지는 않는다. 폭넓은 조회 권한은 유용할 수 있지만, 폭넓은 실행 권한을 부여하는 것은 별개의 결정이다.
사람의 통제가 여전히 중요한 지점
일부 데이터베이스 관련 결정에는 여전히 사람이 개입해야 한다. 가령 에이전트가 어떤 AuditLog 수억 개의 행이 있는 테이블을 발견하고 오래된 레코드를 삭제해야 한다고 판단한다고 해 보자.
DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());SQL이 완벽하게 유효하더라도 그 결정은 매우 잘못된 것일 수 있다.
규제 정책상 7년간 보관해야 할 수도 있다. 어떤 애플리케이션은 해당 기록에 의존할 수도 있다. 트랜잭션 로그가 증가하지 않도록 일괄 삭제해야 할 수도 있다. 삭제 전에 기록을 보관해야 할 수도 있다.
이러한 요구 사항이 반드시 스키마에 반영되어 있는 것은 아니다.
데이터베이스 작업을 코드 생성 문제로만 보는 데에는 이런 한계가 있다. 데이터베이스에는 기술적 구조가 있지만, 그와 관련된 결정은 기술적 작업을 통해 표현되는 비즈니스 판단인 경우가 많다. 다음과 같은 작업에도 같은 주의를 기울여야 한다.
DROP및 파괴적ALTER문장;- 프로덕션
UPDATE및DELETE운영; - 대규모 데이터 마이그레이션;
- 역할 및 권한 변경;
- 제약 조건 수정;
- 복제 또는 가용성에 영향을 미치는 변경;
- 비즈니스 로직이 포함된 저장 프로시저 배포.
기술적으로 올바른 작업이라고 해서 반드시 적절한 작업인 것은 아니다. 따라서 사람의 승인을 에이전트형 AI에 불편한 제약으로 여겨서는 안 된다. 영향이 큰 데이터베이스 작업에서는 승인이 아키텍처의 일부다.
AI 에이전트에도 최소 권한 원칙이 필요하다
데이터베이스 팀이 피해야 할 편법 중 하나는 에이전트가 개발자의 기존 자격 증명을 사용하게 하는 것이다. 간편하긴 하지만, 그렇게 하면 에이전트가 해당 개발자가 이미 가진 모든 접근 권한을 얻게 된다.
더 안전한 방법은 사용자와 서비스에 적용하는 것과 같다. 최소 권한 원칙을 따르는 것이다. Microsoft는 작업에 필요한 권한만 부여하고 권한이 높은 활동을 모니터링할 것을 권고한다.
예를 들어 성능 분석 에이전트에는 다음과 같은 권한이 필요할 수 있다.
CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION아마 다음과 같은 권한은 필요하지 않을 것이다.
ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin에이전트마다 서로 다른 ID를 부여할 수도 있다. 보고 에이전트의 경우 SELECT 몇 개의 스키마에 대한 접근 권한을 부여받을 수 있다. 마이그레이션 에이전트는 개발 환경이나 스테이징 환경에서만 작업할 수 있다. 프로덕션 에이전트에는 범위를 엄격히 제한한 권한을 부여하되, 실행 전에 승인을 받도록 할 수도 있다.
OWASP도 AI 에이전트에 같은 기본 원칙을 권고한다. 읽기 권한과 쓰기 권한을 분리하고, 도구와 리소스를 제한하며, 민감한 작업에는 명시적인 승인을 요구하는 것이다.
원칙은 간단하다. 에이전트가 맡은 작업에 필요한 권한만 부여하고, 에이전트를 실행한 사람이 가진 권한까지 부여하지는 않는다.
워크플로에 사람을 포함하라
에이전트형 데이터베이스 작업을 위한 더 나은 모델은 통제된 워크플로다.
관찰 → 분석 → 제안 → 검토 → 실행 → 검증 → 기록
에이전트가 느린 API 엔드포인트를 조사한다고 가정해 보자. 에이전트는 해당 엔드포인트를 뒷받침하는 SQL을 찾아 실행 계획과 테이블 통계를 확인하고, 인덱스가 누락되었을 가능성을 발견한 뒤 마이그레이션 스크립트를 준비한다.
먼저 스테이징 환경에서 해당 스크립트를 실행할 수 있다. 에이전트는 워크로드를 다시 실행해 결과를 확인하고 프로덕션 변경 사항을 준비한다.
그런 다음 에이전트는 멈춘다.
개발자나 DBA가 마이그레이션을 검토하고 종속성과 비즈니스 영향을 확인한 뒤, 프로덕션 환경에 적용되기 전에 승인한다.
에이전트는 반복적인 작업을 상당 부분 처리할 수 있다. 하지만 영향이 큰 변경에 대한 최종 책임은 사람에게 남는다.
트랜잭션 제어를 통해 안전성을 한층 더 높일 수 있다. 예를 들어 PostgreSQL의 세이브포인트를 사용하면 앞서 수행한 작업을 모두 버리지 않고 트랜잭션의 일부만 롤백할 수 있다. 이는 긴밀히 연결된 자동화 변경에 도움이 될 수 있지만, 롤백이 적절한 권한 설정과 승인 절차를 대신하지는 못한다.
dbForge AI Assistant 같은 도구도 이런 작업에 자연스럽게 활용할 수 있다. 스키마 정보를 활용해 SQL을 생성하고 설명하며, 오류를 해결하고, DDL을 비교하고, 비효율적인 인덱스를 찾아내고, 최적화 스크립트를 준비할 수 있다. 이때 생성된 SQL은 개발자가 검토할 수 있도록 계속 표시된다.
목표는 중요한 결정은 사람이 내리도록 하면서 반복적인 작업을 자동화하는 것이다.
진정한 목표는 통제된 자율성이다
에이전트형 AI가 반드시 “AI는 제안만 한다”와 “AI가 데이터베이스를 직접 운영한다” 중 하나를 선택해야 한다는 뜻은 아니다. 그 중간에는 다양한 선택지가 있다.
팀은 SQL 설명, 스키마 검토, 읽기 전용 점검처럼 위험도가 낮은 작업부터 시작할 수 있다. 그런 다음 에이전트가 개발 및 스테이징 환경에서 점차 더 많은 작업을 맡도록 할 수 있다.
쓰기 권한은 훨씬 나중에 부여해야 하며, 영향을 받는 행의 수, 트랜잭션, 롤백, 모니터링, 승인에 대한 명확한 제한을 두어야 한다. 프로덕션 환경에서 완전히 자율적으로 변경을 수행하는 경우는 드물어야 한다.
이는 위험도가 낮은 워크플로와 중요도가 낮은 데이터부터 시작하고, 담당자가 진행 상황을 파악할 수 있도록 하며, 에이전트의 활용 범위가 넓어질수록 거버넌스를 강화하라는 Deloitte의 지침과도 비슷하다.
목표는 완전한 자율성이 아니다. 에이전트가 도움을 줄 만큼의 자유는 주되, 필요한 것보다 더 많은 접근 권한은 주지 않는 것이다.
핵심 요점: 데이터베이스 개발에는 여전히 판단력이 필요하다
AI 에이전트는 데이터베이스 엔지니어링의 반복 작업을 상당 부분 줄일 수 있습니다. 작업 부하를 파악하고, 쿼리를 살펴보고, 스키마와 실행 계획, 오류 및 성능 데이터를 연관 지어 분석한 뒤, 확인한 내용을 바탕으로 조치를 취할 수 있습니다.
하지만 AI 시스템이 데이터베이스 상태를 변경할 수 있게 되면 문제의 성격이 달라집니다. 팀에는 신원, 권한, 트랜잭션 경계, 승인, 관측 가능성, 롤백 및 감사 추적에 관한 명확한 규칙이 필요합니다.
2025년에 AI를 사용하는 조직은 88%에 달했지만, 그중 단 7%만이 AI를 조직 전반에 완전히 확장 적용했다고 답했습니다. AI가 대규모 환경에서도 안정적으로 작동하도록 하는 일이 더 어려운 과제입니다.
데이터베이스 개발도 같은 방향으로 나아가고 있습니다. 가장 유용한 에이전트는 가장 많은 일을 하도록 허용된 에이전트가 아니라, 권한의 범위가 명확히 이해되고 통제되는 에이전트입니다.
이제 질문은 AI가 데이터베이스 작업을 실행할 수 있는지가 아니라, 어떤 작업을 AI가 실행하도록 맡길 수 있는지, 그리고 어떤 제약 조건을 적용해야 하는지입니다.
