[AI × DBA 1편] DBA가 AI를 쓰면 뭐가 달라지나 — 15년차가 직접 검증해봤다 (AI DBA, DB 자동화)
이 글 요약
AI는 SQL 초안·실행계획 해설·로그 요약에서 시간을 확실히 줄여줍니다. 하지만 **결과물은 언제나 '초안'**입니다.
- AI는 내 DB의 통계·데이터 분포·업무 규칙을 모릅니다. 그래서 없는 파라미터를 지어내거나, 버전에 맞지 않는 문법을 자신 있게 내놓습니다.
- 이 시리즈는 "AI 좋아요"가 아니라 어디까지 맡기고, 어디서 멈추고, 무엇을 검증해야 하는지를 10편에 걸쳐 정리합니다.
들어가며
Oracle DBA와 서버 관리를 15년 해오면서 "이번엔 진짜 DBA가 필요 없어진다"는 말을 몇 번 들었습니다. 자동 튜닝 어드바이저가 나왔을 때도, Autonomous Database가 나왔을 때도 그랬습니다. 그리고 지금은 AI입니다.
이번에는 조금 다르긴 합니다. 자연어로 물으면 SQL이 나오고, 실행계획을 붙여 넣으면 해설이 나옵니다. Oracle은 Autonomous Database에 자연어로 SQL을 생성하는 Select AI를 넣었고, 2025년에는 SQLcl을 통해 AI 도구가 Oracle Database에 연결되는 MCP 서버를 발표했습니다. PostgreSQL 쪽에도 커뮤니티 MCP 서버가 여럿 나와 있습니다.
그래서 직접 써봤습니다. 이 시리즈는 그 검증 기록입니다. 1편에서는 시리즈 전체 지도를 보여드리고, AI로 되는 것과 안 되는 것, 그리고 어떤 순서로 써야 사고가 안 나는지를 먼저 정리합니다.
[내부 링크: Claude 시리즈 1편] — AI 도구 자체가 처음이시라면 기본 사용법부터 보고 오시면 이해가 빠릅니다.
1. 시리즈 편성 — 10편으로 무엇을 다루나
| 구분 | 편 | 제목 | 핵심 키워드 |
| 1부 기초 | 1 | DBA가 AI를 쓰면 뭐가 달라지나 (이번 편) | AI DBA, DB 자동화 |
| 2 | DB 접속 정보를 AI에게 줘도 될까 | AI 보안, 민감정보 | |
| 3 | AI에게 내 DB 구조를 이해시키는 법 | 프롬프트, 스키마 | |
| 2부 실무 | 4 | 느린 SQL, AI에게 실행계획을 읽혀봤다 | SQL 튜닝, 실행계획 |
| 5 | AI가 짜준 SQL, 운영 DB에 그냥 써도 될까 | 쿼리 검증 | |
| 6 | 장애 로그 1만 줄을 AI에게 던졌더니 | 로그 분석 | |
| 7 | AI로 DB 문서화 자동화하기 | 테이블 명세서 | |
| 3부 심화·전망 | 8 | AI로 Oracle → PostgreSQL 마이그레이션 보조하기 | 문법 변환 |
| 9 | AI가 절대 대체 못 하는 DBA 업무 5가지 | DBA 역할 | |
| 10 | AI 시대에 DBA는 살아남을까 | 커리어 전망 |
기준 버전은 Oracle 19c와 PostgreSQL 17입니다. 19c는 Oracle이 지원 기간을 2032년까지 연장한 장기 릴리스라 현장에서 가장 많이 돌고 있고, PostgreSQL은 18이 2025년 9월에 나왔지만 운영 현장에서는 아직 17이 주력인 곳이 많아 17로 잡았습니다. 예시 테이블은 모두 가상입니다.
2. AI로 되는 것 vs 안 되는 것
| 업무 | AI 효용 | 이유 |
| SQL 초안 작성 | 높음 | 문법·조인 골격은 빠르고 정확한 편 |
| 실행계획 해설 | 높음 | 오퍼레이션 의미 설명은 잘함 |
| 인덱스·튜닝 제안 | 중간 | 통계·데이터 분포를 모르고 제안함 |
| 에러 원인 추정 | 중간 | 후보는 잘 뽑지만 우선순위는 틀리기 쉬움 |
| 운영 DB 직접 실행 | 금지 | 책임 소재·롤백 판단이 불가능 |
| 장애 시 최종 결정 | 금지 | 업무 영향도·SLA를 모름 |
정리하면 AI는 **"빠르고 성실하지만 우리 시스템을 처음 본 주니어"**입니다. 일을 시킬 수는 있지만 결재를 맡길 수는 없습니다.
3. 직접 해본 예시 — AI가 틀리는 순간
3-1. 잘 된 경우: 쿼리 초안
가상의 주문 테이블로 요청했습니다.
[프롬프트]
Oracle 19c 기준입니다.
테이블 ORDERS(ORDER_ID NUMBER PK, CUST_ID NUMBER, ORDER_DT DATE, AMOUNT NUMBER(12,2), STATUS VARCHAR2(10))
최근 30일 동안 STATUS='DONE' 인 주문을 고객별로 합산하고, 합계 상위 10명만 보여주세요.
인덱스 사용을 고려해서 ORDER_DT 컬럼에 함수를 씌우지 마세요.
-- AI 답변 (검증 후 그대로 사용 가능했던 예)
SELECT cust_id,
SUM(amount) AS total_amt
FROM orders
WHERE order_dt >= TRUNC(SYSDATE) - 30
AND status = 'DONE'
GROUP BY cust_id
ORDER BY total_amt DESC
FETCH FIRST 10 ROWS ONLY;
조건을 구체적으로 주면 이 정도는 바로 나옵니다. FETCH FIRST는 12c부터 지원되므로 19c에서 문제없습니다.
3-2. 틀린 경우: 버전·환경을 안 알려줬을 때
같은 요청에서 "Oracle 19c"를 빼고 "최근 30일 상위 10명"만 물으면 PostgreSQL식 LIMIT 10이나 INTERVAL '30 days'가 섞여 나오는 경우가 있었습니다. 더 위험한 건 존재하지 않는 초기화 파라미터나 뷰 이름을 그럴듯하게 만들어내는 경우입니다. 그래서 AI가 알려준 파라미터는 반드시 딕셔너리에서 먼저 확인합니다.
-- Oracle 19c: AI가 말한 파라미터가 실제로 있는지 확인
SELECT name, value, isdefault, issys_modifiable
FROM v$parameter
WHERE name = LOWER('¶m_name');
-- PostgreSQL 17: 같은 확인
SELECT name, setting, unit, context, source
FROM pg_settings
WHERE name = :'param_name';
결과가 0건이면, 그 답변은 거기서 끝입니다.
3-3. 위험한 경우: 인덱스 추천
"이 쿼리 느린데 인덱스 추천해줘"라고만 하면 AI는 거의 항상 WHERE 절 컬럼으로 복합 인덱스를 제안합니다. 하지만 STATUS 값의 99%가 'DONE'이라면 그 인덱스는 쓸모가 없습니다. AI는 이 분포를 모릅니다. 분포는 DBA가 확인해서 알려줘야 합니다.
-- 분포 확인 (Oracle 19c)
SELECT status, COUNT(*) cnt,
ROUND(RATIO_TO_REPORT(COUNT(*)) OVER () * 100, 2) pct
FROM orders
GROUP BY status
ORDER BY cnt DESC;
이 부분은 [4편: 느린 SQL, AI에게 실행계획을 읽혀봤다]에서 실제 실행계획으로 자세히 다룹니다.
4. 사고 안 나는 사용 순서
- 문제 정의 — DB 버전, OS, 증상, 재현 조건을 먼저 적습니다.
- 민감정보 마스킹 — IP, 계정, 비밀번호, 실데이터는 지웁니다. (2편에서 기준을 상세히 다룹니다)
- AI에 질의 — DDL, 실행계획 텍스트처럼 구조 정보 위주로 줍니다.
- 교차 검증 — 공식 문서와 딕셔너리 뷰로 답변을 확인합니다.
- 개발 DB 테스트 — 통과하면 변경관리·롤백안과 함께 운영 반영, 실패하면 3단계로 돌아갑니다.
[내부 링크: ORA-12541 해결 글] / [내부 링크: ORA-01017 해결 글] — 에러 메시지를 AI에 그대로 붙여 넣기 전에, 접속 오류는 이 두 글의 점검 순서로 먼저 확인해 보세요. 리스너·인증 문제는 AI보다 체크리스트가 빠릅니다.
5. 업무별 위험도 신호등
| 신호 | 업무 | 운용 원칙 |
| 초록 | 개념 학습, 에러 코드 해설, 문서 초안, 스크립트 골격 | 바로 활용 |
| 노랑 | SQL 튜닝 제안, 인덱스 추천, 쿼리 변환, 로그 원인 추정 | 검증 후 활용 |
| 빨강 | 운영 DB 실행 권한, 장애 최종 판단, 실데이터·접속정보 전달 | 맡기지 않음 |
6. DBA가 만나는 AI 도구 4가지 유형
| 유형 | 예 | 장점 | 주의할 점 |
| ① 채팅형 | 웹·앱 AI 어시스턴트 | 가장 쉽고 범용 | 붙여넣는 내용 관리 |
| ② IDE 통합 | VS Code 확장, 코딩 에이전트 | 스크립트·파일 직접 다룸 | 터미널 실행 권한 범위 |
| ③ DB 내장 | Oracle Select AI (Autonomous DB) | 스키마 메타데이터 활용 | 클라우드·버전 제약 |
| ④ MCP 연결 | Oracle SQLcl MCP 서버, PostgreSQL MCP 서버 | AI가 DB를 직접 조회 | 읽기 전용 전용 계정 필수 |
④로 갈수록 편해지지만, AI가 DB에 직접 붙는 순간 권한 설계가 먼저입니다. MCP를 쓸 계획이라면 최소한 아래처럼 조회 전용 계정부터 만드세요.
-- Oracle 19c: AI 연결용 읽기 전용 계정 (가상 예시)
CREATE USER ai_ro IDENTIFIED BY "<강력한_비밀번호>"
DEFAULT TABLESPACE users QUOTA 0 ON users;
GRANT CREATE SESSION TO ai_ro;
GRANT SELECT ON app.orders TO ai_ro; -- 필요한 테이블만 개별 부여
-- SELECT ANY TABLE, DBA 롤은 절대 부여하지 않음
-- PostgreSQL 17: 읽기 전용 롤
CREATE ROLE ai_ro LOGIN PASSWORD '<강력한_비밀번호>';
GRANT CONNECT ON DATABASE appdb TO ai_ro;
GRANT USAGE ON SCHEMA app TO ai_ro;
GRANT SELECT ON app.orders TO ai_ro;
ALTER ROLE ai_ro SET default_transaction_read_only = on;
ALTER ROLE ai_ro SET statement_timeout = '30s';
[내부 링크: Cline/VS Code 시리즈 — 에이전트 권한 설정 편] — IDE 에이전트에 터미널 실행을 허용할 때의 승인 설정은 이 글을 참고하세요.
7. 운영 적용 전 5단계 체크리스트
| 단계 | 확인 항목 | 확인 방법 |
| 1. 버전 확인 | 19c/PG17 기준 문법·기능인가 | v$version, SELECT version(); |
| 2. 공식 문서 대조 | 문법·동작이 문서와 일치하는가 | Oracle Docs, PostgreSQL Docs |
| 3. 개발 DB 실행 | 실행계획·결과가 기대와 같은가 | 운영과 비슷한 통계·데이터량에서 |
| 4. 영향도 검토 | 락, REDO/WAL, 소요 시간, 롤백 방법 | 작업 계획서 |
| 5. 변경관리 기록 | AI 사용 여부·검증자·원복 스크립트 | 변경 티켓 |
특히 5번이 중요합니다. 나중에 문제가 생겼을 때 "AI가 그렇게 하라고 했다"는 근거가 되지 않습니다. 검증한 사람의 이름이 남아야 합니다.
[내부 링크: PostgreSQL 시리즈 — 실행계획(EXPLAIN) 편] — 3단계의 실행계획 비교가 익숙하지 않으시면 먼저 읽어보세요.
마치며
핵심 3줄
- AI는 SQL 초안·실행계획 해설·로그 요약에서 시간을 줄여주지만, 결과는 항상 초안입니다.
- AI는 내 DB의 통계·분포·업무 규칙을 모르고, 없는 파라미터도 지어냅니다. 딕셔너리 뷰와 공식 문서로 확인하세요.
- 운영 반영은 "마스킹 → 질의 → 교차 검증 → 개발 DB 테스트 → 변경관리" 순서를 지킵니다.
다음 편 예고 — 2편 **「DB 접속 정보를 AI에게 줘도 될까 — 보안 기준 정리」**에서는 어떤 정보까지 AI에 넣어도 되는지, 마스킹은 어떻게 하는지, 사내 반입 범위를 어떻게 정할지 구체적인 기준표로 정리하겠습니다.
이 글이 도움이 되셨다면 공감과 구독 부탁드립니다.