AI 에이전트가 데이터베이스 장애에 대응할 수 있는 범위와, 사람이 판단해야 하는 범위
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
AI 에이전트가 강점을 보이는 영역은 감지와 원인 분리입니다. 상시 모니터링과 상관 분석, 정형화된 확인 쿼리를 한꺼번에 실행해 사실을 수집하는 작업은 자동화할 수 있습니다. 1차 대응은 조건부로, 영향이 가역적이고 대상이 한정된 작업에 한정됩니다. 근본 대응과 구성 변경은 사람의 판단이 필요합니다. 이유는 세 가지로, 작업의 불가역성, 영향 범위 추정의 어려움, 그리고 "서비스를 중단할지, 느린 상태로 계속할지"가 기술적 판단이 아니라 업무적 판단이라는 점입니다.
この文書の適用条件
| 対象製品 | SQL Server / MySQL / Aurora MySQL(트리아지 쿼리 대상) |
|---|---|
| 確認バージョン | SQL Server 2012 이상, MySQL 5.7 / 8.0 계열 및 Aurora MySQL 2 / 3 |
| 適用環境 | 온프레미스, EC2, Amazon RDS, Aurora, Azure |
| 必要権限 | SQL Server는 `VIEW SERVER STATE`. MySQL은 `PROCESS` 권한. `KILL`에는 별도로 `ALTER ANY CONNECTION`에 준하는 권한이 필요 |
| 実行影響 | 트리아지 쿼리는 조회 전용. `KILL` 예시는 변경을 수반하며 사람의 승인이 필요 |
| 再起動 | 불필요 |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- SQL Server 2012 이상 / Amazon RDS for SQL Server / Azure SQL Managed Instance
- 権限
- VIEW SERVER STATE
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: SQL Server 2012 以降 / Amazon RDS for SQL Server
-- 権限: VIEW SERVER STATE
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
r.session_id,
r.blocking_session_id, -- 0 以外なら、この値のセッションに待たされている
r.status,
r.command,
r.wait_type,
r.wait_time AS wait_time_ms,
r.wait_resource,
DB_NAME(r.database_id) AS database_name,
s.login_name,
s.host_name,
s.program_name,
r.total_elapsed_time AS elapsed_ms,
SUBSTRING(t.text, 1, 500) AS sql_text
FROM sys.dm_exec_requests AS r
INNER JOIN sys.dm_exec_sessions AS s
ON r.session_id = s.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.blocking_session_id <> 0
OR r.session_id IN (
SELECT blocking_session_id
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0
)
ORDER BY r.wait_time DESC;블로킹의 시작점은 `blocking_session_id`를 따라갔을 때 자신은 아무에게도 대기당하지 않는 세션입니다. 체인의 중간을 중단해도 해소되지 않습니다. 참고로 대기를 유발하는 쪽이 실행 중이 아니면 `sys.dm_exec_requests`에 행이 나타나지 않으므로, `sys.dm_exec_sessions` 쪽에서 해당 session_id의 상태도 확인하세요.
- 対象
- MySQL 5.7 / 8.0 계열, Aurora MySQL 2 / 3
- 権限
- PROCESS 권한(다른 사용자의 세션을 보기 위해 필요)
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: MySQL 5.7 / 8.0 系、Aurora MySQL 2 / 3
-- 権限: PROCESS 権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
trx.trx_id,
trx.trx_state,
trx.trx_started,
TIMESTAMPDIFF(SECOND, trx.trx_started, NOW()) AS trx_age_sec,
trx.trx_mysql_thread_id AS thread_id,
trx.trx_rows_locked,
trx.trx_rows_modified, -- 大きいほどロールバックに時間がかかる
p.user,
p.host,
p.db,
p.command,
p.time AS thread_time_sec,
p.state,
LEFT(COALESCE(trx.trx_query, p.info), 500) AS current_sql
FROM information_schema.INNODB_TRX AS trx
LEFT JOIN information_schema.PROCESSLIST AS p
ON p.ID = trx.trx_mysql_thread_id
ORDER BY trx.trx_started ASC;
-- 補助: トランザクションを持たない接続も含めて全体を見る
SHOW FULL PROCESSLIST;`trx_state`가 `RUNNING`이어도 `current_sql`이 비어 있다면 "트랜잭션은 열려 있지만 현재 쿼리가 흐르지 않는" 상태입니다. 애플리케이션 측의 커밋 누락이나, 커넥션 풀이 유지 중인 연결을 의심해 보세요. `trx_rows_modified`는 롤백 시간을 추정하는 데 사용할 수 있습니다.
- 対象
- SQL Server 2012 이상 / MySQL 5.7 이상·Aurora MySQL
- 権限
- SQL Server는 ALTER ANY CONNECTION(또는 `sysadmin` / `processadmin`), MySQL은 CONNECTION_ADMIN에 준하는 권한
- 変更作業
- 있음(실행 중인 세션 강제 종료와 해당 트랜잭션의 롤백)
- Production実行
- 사람의 승인을 받은 경우에만 실행 가능
-- 対象: SQL Server 2012 以降 / MySQL 5.7 以降・Aurora MySQL
-- 権限: SQL Server は ALTER ANY CONNECTION、MySQL は CONNECTION_ADMIN 相当
-- 変更作業: あり(セッションの強制終了とトランザクションのロールバック)
-- Production 実行: 人間の承認を得た場合のみ
-- 実行前に、以下の6項目すべてを確認する。1つでも未確認なら実行しない。
-- 1. 対象がブロッキング連鎖の起点か(他に待たされていないセッションか)
-- 2. そのセッションが何をしているか(定常のアプリ処理・バッチ・DDL のいずれか)
-- 3. ロールバックの想定時間(更新行数が多いほど長く、その間ロックは解放されない)
-- 4. 呼び出し元が再試行するか。しない場合、業務データが欠落しないか
-- 5. 止める代わりに待つ選択肢が取れないか(業務側の許容時間の確認)
-- 6. 承認者は誰か。実行の記録をどこに残すか
-- SQL Server: セッションIDを指定(値はサンプル)
KILL 57;
-- ロールバックの進捗を確認する(KILL 後に実行する参照専用クエリ)
-- KILL 57 WITH STATUSONLY;
-- MySQL / Aurora MySQL: PROCESSLIST の ID を指定(値はサンプル)
-- KILL 12345;`KILL`은 롤백을 발생시킵니다. 변경된 행 수가 많은 트랜잭션에서는 롤백이 원래 처리보다 더 오래 걸릴 수 있으며, 그동안 잠금은 해제되지 않습니다. "중단하면 빨리 끝난다"고 단정할 수 없다는 점이 이 작업을 자동 실행 대상으로 둘 수 없는 주된 이유입니다. SQL Server에서는 `KILL <spid> WITH STATUSONLY`로 롤백 진행 상황을 확인할 수 있습니다.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| 감지 | 이상이 발생했음을 알아차리는 단계 | AI가 강점. 상시 모니터링, 임계값 초과 감지, 복수 메트릭 상관 분석, 과거 패턴과의 대조 |
| 원인 분리 | 사실을 수집해 원인 범위를 좁히는 단계 | AI가 강점. 정형화된 조회 쿼리를 한꺼번에 실행하고 결과를 맞춰보며 사실관계를 정리 |
| 1차 대응 | 영향을 중단하거나 경감하는 단계 | 조건부. 영향이 가역적이고 대상이 allowlist로 한정된 작업만. 그 외에는 사람의 승인 |
| 근본 대응·구성 변경 | 재발하지 않도록 구조를 바꾸는 단계 | 사람의 판단 필요. 스키마 변경, 파라미터 변경, 구성 변경은 영향 범위 추정을 수반 |
| 사후 분석 | 무슨 일이 있었는지 기록하고 대책을 정하는 단계 | AI가 초안 작성, 사람이 확정. 시계열과 로그 정리는 자동화할 수 있고, 원인 확정과 대책 결정은 사람이 수행 |
| blocking_session_id | 이 세션을 대기시키는 상대 세션 ID | 0이 아닌 값을 따라가 아무에게도 대기당하지 않는 세션(체인의 시작점)을 특정 |
| wait_type / state | 무엇을 대기하고 있는가 | 잠금 대기인지 I/O 대기인지 CPU 대기인지에 따라 다음에 볼 곳이 달라짐 |
| trx_rows_modified | 해당 트랜잭션이 변경한 행 수 | 클수록 롤백에 시간이 걸림. `KILL` 판단 근거가 됨 |
| trx_age_sec / elapsed_ms | 트랜잭션 경과 시간 | 장시간 열려 있는 경우 커밋 누락이나 커넥션 풀 유지를 의심 |
| program_name / host | 연결 출처 | 특정 애플리케이션이나 배치에 편중되어 있지 않은지. 편중은 원인 파악에 직결 |
こういう状況で使います
- 애플리케이션 타임아웃이 급증했지만 데이터베이스가 원인인지 아직 분리하지 못했다
- 특정 테이블에 대한 업데이트만 대기 상태다
- 야간에 발생한 이상을 아무도 알아차리지 못하고 아침에 발견됐다
- 모니터링은 되어 있지만 알림이 너무 많아 어느 것이 진짜인지 판단할 수 없다
- 장애가 발생할 때마다 확인할 쿼리를 매번 기억해 가며 실행하고 있다
- 1차 대응을 AI에게 맡기고 싶지만 어디까지 맡겨야 할지 경계를 정하지 못했다
考えられる原因(可能性の高い順)
01
감지 체계는 있지만 원인 분리 절차가 사람의 기억에 의존한다
확인해야 할 쿼리가 절차로 정리되어 있지 않으면, 대응자에 따라 수집하는 사실이 달라집니다. 단계 중에서 가장 자동화하기 쉬운 부분입니다.
02
1차 대응의 가능 여부가 사전에 정해져 있지 않다
어떤 작업을 자동으로 실행해도 되는지 정해져 있지 않으면, 안전을 위해 전부 수동으로 돌아가거나 반대로 위험한 작업까지 자동화되는 두 가지 중 하나가 됩니다.
03
불가역적 작업이 가역적 작업과 동일하게 취급된다
세션 종료, 데이터 삭제, 복제 초기화는 모두 "대응"이라 불리지만 되돌리기 쉬운 정도가 다릅니다. 구분 없이 다루면 사고로 이어집니다.
04
중단 판단의 권한자가 정해져 있지 않다
서비스를 중단하고 복구를 우선할지, 느린 상태로 계속할지는 업무적 판단입니다. 판단 권한자가 정해져 있지 않으면 기술 담당자가 판단을 떠안게 되어 대응이 늦어집니다.
確認手順
- 1
블로킹 체인을 확인한다
参照のみ위의 조회 전용 쿼리로 대기 중인 세션과 대기시키는 세션을 목록화하고 체인의 시작점을 특정합니다.
- 2
활성 세션과 연결 출처를 확인한다
参照のみ연결 출처 애플리케이션이나 호스트에 편중이 없는지 봅니다. 편중이 있다면 해당 애플리케이션의 최근 변경 사항을 확인합니다.
- 3
대기 이벤트를 집계한다
参照のみ잠금 대기, I/O 대기, CPU 대기 중 무엇이 지배적인지 확인합니다. 다음에 볼 곳이 여기서 정해집니다.
- 4
트랜잭션 로그 사용 현황을 확인한다
参照のみ로그의 여유 공간이 고갈되면 업데이트 처리 전체가 멈춥니다. 장시간 트랜잭션이 로그 재사용을 막고 있지 않은지 확인합니다.
- 5
복제 지연을 확인한다
参照のみ조회용 트래픽을 레플리카로 보내는 경우 지연으로 업무에 영향이 생깁니다. 지연 크기와 증가 추세를 확인합니다.
- 6
최근 변경 사항을 확인한다
参照のみ배포, 배치 추가, 파라미터 변경이 직전에 없었는지 확인합니다. 시계열 일치는 유력한 단서입니다.
対応方法
すぐに実施できる低リスクの対応
트리아지 쿼리 모음을 절차로 고정한다
参照のみ장애 시 실행할 쿼리를 목록화하여 에이전트가 자동으로 일괄 실행할 수 있게 합니다. 조회 전용이므로 자동화해도 영향이 없습니다.
사실 요약을 자동 생성한다
参照のみ수집한 결과를 시계열로 정리해 대응자가 읽을 수 있는 형태로 만듭니다. 단정하지 않고 사실과 관측값만 나열합니다.
중단 판단 권한자를 명시한다
低서비스 중단을 수반하는 판단을 누가 할지 대응 절차 맨 앞에 적어둡니다. 장애 시 찾아다니지 않도록 합니다.
事前検討が必要な変更
자동 실행해도 되는 1차 대응을 정의한다
中영향이 가역적이고 대상이 한정된 작업(읽기 전용 확인, 캐시 재적재, 조회계 분리 등)을 나열하고, 그 외에는 승인을 필수로 합니다.
사후 분석 초안을 자동화한다
低시계열, 수집한 관측값, 실행한 작업을 자동으로 정리하고, 원인 확정과 대책 결정은 사람이 합니다.
모니터링 대상을 서비스 성립 조건에 맞춘다
中프로세스의 생존 여부뿐 아니라 실제 처리 경로가 정상 동작하는지를 보는 모니터링을 추가합니다.
専門家のレビューが必要な作業
블로킹 시작점 세션을 종료한다
専門家レビュー必須롤백이 발생하며, 변경된 행 수에 따라 원래 처리보다 오래 걸릴 수 있습니다. 위의 6개 항목을 확인하고 승인을 받은 후 실행하세요.
레플리카로 전환(페일오버)한다
専門家レビュー必須지연 중인 레플리카로 전환하면 데이터 누락이 발생할 수 있습니다. 지연량과 업무 요건을 확인한 후 사람이 판단하세요.
구성이나 파라미터를 변경하여 근본 대응한다
専門家レビュー必須영향 범위 추정과 롤백 절차가 필요합니다. 장애 대응 중의 변경은 그 변경 자체가 새로운 장애 요인이 될 수 있습니다.
!注意事項
- 사람의 승인 없이 AI 에이전트가 실행해서는 안 되는 작업: 데이터 삭제, `KILL`, `SHRINK`, 강제 페일오버, 복제 초기화, CDC 재설정, 인덱스 전체 재구축, 대규모 통계 업데이트, 파라미터 변경, 스키마 변경, DB 재시작, 방화벽 및 권한 변경, binlog 초기화, 백업 삭제.
- 경계를 나누는 이유는 세 가지입니다. 첫째는 불가역성으로, 실행 후 원래 상태로 되돌릴 수 없거나 되돌리려면 별도의 복구 작업이 필요합니다. 둘째는 영향 범위 추정이 어려워 대상 데이터베이스 이외의 연계 시스템까지 파급됩니다. 셋째로 "서비스를 중단할지, 느린 상태로 계속할지"는 기술적 판단이 아니라 업무적 판단이며 기술적 정확성만으로는 결정할 수 없습니다.
- `KILL`이 반드시 상황을 개선하는 것은 아닙니다. 롤백이 발생하며, 변경된 행 수가 많으면 원래 처리보다 시간이 더 걸릴 수 있습니다. 그동안 잠금은 해제되지 않습니다.
- 장애 대응 중의 구성 변경은 그 변경 자체가 새로운 장애 요인이 됩니다. 근본 대응은 복구 후에, 영향 조사와 롤백 절차를 준비한 뒤 실시하세요.
- 조회 전용 쿼리라도 극단적으로 고부하 상태인 인스턴스에서는 응답이 오지 않을 수 있습니다. 가져오는 데이터량을 제한하고 타임아웃을 설정하세요.
- AI가 제시한 원인은 가설입니다. 사후 분석의 확정과 대책 결정은 사람이 수행하세요.
バージョン・環境による違い
これで解決しない場合に確認すること
최근 장애에서 감지부터 원인 분리 완료까지 걸린 시간을 확인한다
시간의 대부분이 "무엇을 봐야 할지 기억해내는" 데 쓰였다면 트리아지 자동화가 효과적입니다.
1차 대응에서 실행한 작업을 가역·불가역으로 분류한다
불가역적 작업을 승인 없이 실행했다면 그것이 다음 사고 요인입니다.
중단 판단이 누구의 권한인지 확인한다
권한자가 부재인 시간대에는 어떻게 할지까지 정해져 있는지 확인합니다.
알림의 정확도를 확인한다
최근 알림 중 실제로 대응이 필요했던 비율을 셉니다. 낮다면 진짜 이상이 묻힐 수 있습니다.
사후 분석 기록이 다음 장애에서 참조되는지 확인한다
기록이 읽히지 않는다면 형식이나 보관 장소를 재검토하세요.
この文書の根拠と限界
一般的な技術説明
트리아지 쿼리는 SQL Server의 동적 관리 뷰 및 MySQL의 `information_schema` 공개 사양에 기반합니다. 단계별 경계는 작업의 가역성과 영향 범위에 기반한 일반적인 운영 설계입니다. "GIIP 대응 범위" 단락만 GIIP 자체의 운영 형태에 대한 설명이며 고객 사례가 아닙니다. 복구 시간·장애 건수·자동화율 등의 수치는 검증할 수 없어 기재하지 않았습니다.
よくある質問
AI 에이전트에게 장애 대응을 어디까지 맡길 수 있나요?
감지와 원인 분리는 맡길 수 있습니다. 1차 대응은 영향이 가역적이고 대상이 명시적으로 한정된 작업에 한정됩니다. 근본 대응과 구성 변경, 그리고 서비스를 중단할지 여부의 판단은 사람이 해야 합니다.
왜 `KILL`을 자동 실행하면 안 되나요?
롤백이 발생하며, 변경된 행 수에 따라 원래 처리보다 오래 걸릴 수 있기 때문입니다. 그동안 잠금은 해제되지 않고 상황이 악화될 수 있습니다. 또한 중단된 처리를 호출한 쪽이 재시도하지 않으면 업무 데이터가 누락될 수 있습니다.
사람 전문가가 담당해야 하는 작업은 구체적으로 무엇인가요?
불가역적 작업의 실행 판단, 서비스 중단 여부, 영향 범위가 여러 시스템에 걸치는 경우의 판단, 근본 대응 설계, 그리고 사후 분석 확정입니다. 모두 기술적 정확성만으로는 결정되지 않으며 업무 영향과 책임 소재가 관련됩니다.
트리아지 쿼리는 프로덕션 환경에서 실행할 수 있나요?
본 문서의 첫 번째와 두 번째 쿼리는 조회 전용이므로 실행할 수 있습니다. 다만 극단적으로 고부하 상태에서는 응답이 오지 않을 수 있으므로 가져오는 건수를 제한하고 타임아웃을 설정하세요. 세 번째 `KILL`은 변경을 수반하므로 승인이 필요합니다.
1차 대응을 자동화하려면 무엇을 준비해야 하나요?
대상의 allowlist, 변경 전 스냅샷, 롤백 절차, 감사 로그, 정지 스위치입니다. 이것들이 갖춰지지 않은 작업은 자동 실행 대상으로 두지 마세요.
AI가 제시한 원인을 그대로 받아들여도 되나요?
가설로 다루세요. 수집한 사실의 정리는 자동화할 수 있지만, 원인 확정은 관측되지 않은 요소의 영향을 받습니다. 사후 분석은 AI가 초안을 작성하고 사람이 확정하는 형태가 적합합니다.
この文書がカバーする質問
- AI 운영에서 사람 전문가가 담당해야 하는 작업은 무엇인가
- AI 에이전트에게 데이터베이스 1차 대응을 맡겨도 되는가
- DB 장애 시 먼저 실행해야 할 확인 쿼리를 알고 싶다
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
위의 단계 구분과 경계는 특정 서비스를 사용하지 않고도 자체적으로 구현할 수 있습니다. GIIP에서는 AWS와 Azure 상의 여러 데이터베이스 및 약 30개의 웹 서비스를 AI 에이전트와 사람 전문가가 지속적으로 모니터링·운영하고 있으며, 감지와 원인 분리는 AI 에이전트가 수행하고, 위에 나열한 불가역적 작업과 중단 판단은 사람 담당자가 승인한 후 실행하는 방식을 취하고 있습니다. 자체적으로 경계를 정할 때 어떤 작업을 가역적으로 볼 수 있는지 판단하기 어렵다면, 현재 구성과 과거 장애 기록을 바탕으로 정리할 수도 있습니다.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
SQL Server에서 장시간 열려 있는 트랜잭션을 확인하는 SQL
sys.dm_tran_active_transactions 계열 DMV로 시작 시각·세션·마지막 실행 SQL까지 포함하여 방치된 트랜잭션을 특정하는 절차입니다.
aurora-mysqlAurora MySQL에서 특정 쿼리가 느려졌을 때 확인하는 절차
슬로우 쿼리 로그, PROCESSLIST, EXPLAIN, 다이제스트 집계 순으로 위험도가 낮은 확인부터 시작해 느린 쿼리를 찾아내는 절차입니다. performance_schema가 비활성화된 환경의 대안도 제시합니다.
monitoring서버와 데이터베이스를 24시간 모니터링할 때 설정할 항목
24시간 모니터링을 설계할 때의 모니터링 대상·임계값 사고방식·에스컬레이션 체계·외부 모니터링의 필요성을 계층별로 정리한 체크리스트입니다.
ai-operationsAI 자동 실행에 승인과 롤백이 필요한 이유와 설계 방법
자동 실행의 설계 요소(스냅샷·승인 게이트·dry-run 분리·allowlist·멱등성·감사 로그·단계적 전개·중지 스위치)와, 승인 없이 실행해서는 안 되는 작업의 경계를 정리합니다.
関連サービス
장애 시 1차 대응의 경계를 정리한다
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
장애 시 1차 대응의 경계를 정리한다