AI 자동 실행에 승인과 롤백이 필요한 이유와 설계 방법
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
승인과 롤백이 필요한 이유는 AI가 실수하기 때문이 아니라, 아무도 모르는 사이에 프로덕션 상태가 바뀌는 것이 가장 큰 실패 모드이기 때문입니다. 설계에서는 변경 전 스냅샷 확보, 승인 게이트, dry-run과 본실행의 분리, 대상 allowlist, 멱등성, 실행 전 롤백 절차의 존재, 감사 로그, 단계적 전개, 중지 스위치의 9가지를 갖춥니다. 롤백할 수 없는 작업은 자동화하지 않는다는 것이 경계를 정하는 기준입니다.
この文書の適用条件
| 対象製品 | AI 운용 워크플로 전반(오케스트레이터 제품에 의존하지 않음) |
|---|---|
| 確認バージョン | 제품 버전에 의존하지 않는 설계상의 설명(스냅샷 예시는 SQL Server 2012 이상을 가정) |
| 適用環境 | AWS, Azure, 온프레미스 |
| 必要権限 | 스냅샷 획득에는 대상 인스턴스 접속 권한. 워크플로 정의 편집 권한 |
| 実行影響 | 참조만 함(본문 중 명령은 상태를 변경하지 않음) |
| 再起動 | 불필요 |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- 자사 운용 자동화 워크플로 정의
- 権限
- 워크플로 정의 편집 권한
- 変更作業
- 없음(정의 작성 예시)
- Production実行
- 해당 없음(설계 샘플)
# 対象: 自組織の運用自動化ワークフロー定義
# 権限: ワークフロー定義の編集権限
# 変更作業: なし(定義の記述例)
# Production 実行: 該当なし(設計サンプル)
workflow: sample-log-maintenance
# 実行対象を明示的に限定する。ここに書かれていないホスト・DBには一切触れない
scope:
allowlist_hosts: [LEGACY-SQL01]
allowlist_databases: [SampleDB]
deny_if_role: [primary-replica-source]
# 実行前に必ず状態を保存する。保存に失敗したら以降のステップへ進まない
pre_snapshot:
- id: capture-config
command: dump-configuration
required: true # 失敗時は abort(スキップ不可)
retention: 30d
steps:
- id: check-log-usage
kind: read
dry_run: false # 参照のみなので dry-run の概念が無い
requires_approval: false
idempotent: true
rollback: not-required # 状態を変えないため
- id: apply-parameter-change
kind: write
dry_run: true # まず差分だけを出力して人が読む
requires_approval: true # dry-run の出力を見た人が承認して初めて本実行
approvers: [ops-oncall, dba-lead]
approval_expires_in: 2h # 古い承認で実行されないように失効させる
idempotent: true # 同じ入力で2回流しても結果が変わらない
rollback:
exists: true # 存在しない場合、この step は定義エラーとして拒否する
command: restore-configuration --from capture-config
verified_at: 2026-08-13
- id: never-auto
kind: write
requires_approval: true
auto_execute: forbidden # 承認があっても自動実行経路からは呼ばない
# 段階的展開: 1台 → 一部 → 全体。各段で停止条件を評価する
rollout:
stages: [canary(1), partial(25%), full]
halt_on: [error_rate_increase, unexpected_diff, snapshot_missing]
# 停止スイッチ: これを立てると進行中の実行も次のステップに進まない
kill_switch:
flag: /etc/ai-ops/HALT
honored_between_steps: true
# 状態記録: 各ステップの結果を永続化し、再開時に完了済みを再適用しない
state_store:
key: run_id + step_id
values: [pending, running, succeeded, failed, rolled_back, skipped]
resume_policy: skip-succeeded이 정의의 핵심은 세 가지입니다. 첫째, rollback.exists가 false인 단계는 정의 단계에서 거부하는 것. 둘째, 승인에 유효기간을 두어 상황이 바뀐 뒤의 오래된 승인으로 실행되지 않도록 하는 것. 셋째, state_store를 통해 재개나 재시도 시 동일한 변경이 이중으로 적용되지 않도록 하는 것입니다.
- 対象
- SQL Server 2012 이상 / Amazon RDS for SQL Server
- 権限
- 대상 인스턴스 접속 권한(sys.configurations는 기본적으로 조회 가능)
- 変更作業
- 없음(참조만 함)
- Production実行
- 가능
-- 対象: SQL Server 2012 以降 / Amazon RDS for SQL Server
-- 権限: 対象インスタンスへの接続権限(sys.configurations は既定で参照可能)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
SERVERPROPERTY('MachineName') AS machine_name,
SYSDATETIMEOFFSET() AS captured_at,
c.configuration_id,
c.name,
c.value, -- 設定された値
c.value_in_use, -- 実際に効いている値
c.is_dynamic, -- 再起動なしで反映されるか
c.is_advanced
FROM sys.configurations AS c
ORDER BY c.name;value와 value_in_use가 다르면, 설정은 변경되었지만 재시작을 기다리는 상태입니다. 스냅샷에는 두 값을 모두 저장하십시오. 하나만 저장하면 어느 값으로 되돌려야 하는지 판단할 수 없습니다.
- 対象
- 자사 운용 호스트(대상 DB에 접속 가능한 위치)
- 権限
- 대상 DB 접속 권한과 저장 디렉터리 쓰기 권한
- 変更作業
- 없음(DB 상태는 변경하지 않음. 파일만 출력)
- Production実行
- 가능
# 対象: 自組織の運用ホスト(対象DBへ接続できる場所)
# 権限: 対象DBへの接続権限と、保存先ディレクトリへの書き込み権限
# 変更作業: なし(DBの状態は変更しない。ファイルのみ出力)
# Production 実行: 可能
SNAP_DIR=/var/lib/ai-ops/snapshots
RUN_ID=sample-run-0001
mkdir -p "$SNAP_DIR/$RUN_ID"
# 1) 変更前の構成を保存する(保存に失敗したら以降へ進まない)
sqlcmd -S LEGACY-SQL01 -U sample_user -d SampleDB -i capture_configuration.sql -o "$SNAP_DIR/$RUN_ID/before.txt" || exit 1
# 2) 変更を適用する(承認済みの場合のみ。ここでは実行しない)
echo "apply step は承認後に別経路で実行する"
# 3) 変更後に同じクエリを流し、差分を人が読める形で残す
sqlcmd -S LEGACY-SQL01 -U sample_user -d SampleDB -i capture_configuration.sql -o "$SNAP_DIR/$RUN_ID/after.txt"
diff -u "$SNAP_DIR/$RUN_ID/before.txt" "$SNAP_DIR/$RUN_ID/after.txt" > "$SNAP_DIR/$RUN_ID/diff.txt"
# 4) 差分が空でないこと(=意図した変更が入ったこと)と、想定外の行が無いことを確認する
cat "$SNAP_DIR/$RUN_ID/diff.txt"비밀번호를 커맨드라인에 직접 적지 마십시오. 인증 정보는 환경 변수나 시크릿 스토어에서 전달합니다. 스냅샷 저장 위치는 대상 시스템이 중지되어도 읽을 수 있는 곳에 두십시오.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| 변경 전 스냅샷 | 변경을 적용하기 전 상태를 저장하는 것 | 저장에 실패하면 실행을 중단하는가. 저장 위치는 대상이 중지되어도 읽을 수 있는가 |
| 승인 게이트 | 누가·무엇을·어떤 조건으로 승인할지에 대한 정의 | 승인자가 실행자와 다른 사람인가. 승인에 유효기간이 있는가 |
| dry-run과 본실행의 분리 | 차이만 출력하는 실행과 실제로 적용하는 실행을 분리하는 것 | dry-run 출력이 사람이 읽을 수 있는 diff 형태인가 |
| 대상 스코프 제한 | 대상 호스트·대상 DB에 대한 명시적 allowlist | allowlist에 없는 대상에는 지시가 있어도 실행되지 않는가 |
| 멱등성 | 동일한 입력으로 여러 번 실행해도 결과가 변하지 않는 것 | 재시도나 재개 시 이중 적용이 발생하지 않는가 |
| 롤백 절차의 사전 존재 | 되돌리는 방법이 실행 전에 결정되어 있는 것 | rollback이 정의되지 않은 단계를 정의 단계에서 거부하는가 |
| 감사 로그 | 실행자·실행 시각·입력·출력·승인자의 기록 | 5개 항목이 모두 갖춰져 있는가. 나중에 변경할 수 없는 위치에 있는가 |
| 단계적 전개 | 1대 → 일부 → 전체로 확대하는 것 | 각 단계에서 중지 조건을 평가하는가. 이상 시 자동으로 멈추는가 |
| 중지 스위치 | 진행 중인 자동 실행을 멈추는 수단 | 누가 누를 수 있는가. 누른 뒤 다음 단계로 진행하지 않음을 확인했는가 |
| 상태 기록(순차 실행) | 각 단계의 상태를 영속화하는 것 | 재개 시 이미 성공한 단계를 다시 실행하지 않는 설계인가 |
こういう状況で使います
- 자동화한 처리가 동작하고 있었을 텐데, 언제부터 멈춰 있었는지 알 수 없다
- 프로덕션 설정이 어느 순간 바뀌어 있는데, 누가 바꿨는지 특정할 수 없다
- 같은 자동 실행을 재시도했더니 변경이 이중으로 적용되었다
- 자동 실행을 멈추고 싶은데, 멈출 방법이 "프로세스를 kill하는" 것뿐이다
- 자동 실행 로그는 있지만, 승인자와 입력값이 기록되어 있지 않다
- dry-run 결과를 보지 않고 본실행이 진행되는 경로가 남아 있다
考えられる原因(可能性の高い順)
01
감지와 실행을 같은 경로로 묶어두었다
이상을 감지한 에이전트가 그대로 대응을 실행하는 구성에서는, 감지 오류가 그대로 상태 변경으로 이어집니다. 감지와 실행 사이에 승인을 두면, 오탐이 상태를 바꾸지 않게 됩니다.
02
실행 대상이 지시문에서 동적으로 결정된다
대상 호스트나 데이터베이스 이름을 자연어 지시에서 해석하면, 의도하지 않은 대상과 일치할 수 있습니다. allowlist로 대상을 정적으로 고정하면 이 경로를 막을 수 있습니다.
03
재시도가 멱등하지 않다
타임아웃 후 재시도나, 중간 실패로부터의 재개에서 이미 적용된 변경이 다시 적용될 수 있습니다. 단계 단위의 상태 기록이 없으면 어디까지 진행했는지 판단할 수 없습니다.
04
롤백을 "나중에 생각하자"로 미뤄두었다
실행 시점에 되돌리는 방법이 없는 작업은, 실패한 순간 선택지가 사라집니다. 롤백 절차의 존재를 실행의 전제 조건으로 두면 이 상황을 구조적으로 막을 수 있습니다.
05
감사 로그를 실행 로그로 대체하고 있다
애플리케이션 로그에는 실행 내용은 남지만, 승인자와 승인 시각은 남지 않습니다. 사후에 "누구의 판단이었는가"를 재구성할 수 없으면, 원인 규명이 추측에 의존하게 됩니다.
確認手順
- 1
자동 실행 목록을 만든다
参照のみ현재 동작 중인 자동화 처리를 나열하고, 각각이 상태를 변경하는지 참조만 하는지를 분류합니다. 분류할 수 없는 것은 일단 참조 전용으로 내립니다.
- 2
각 자동 실행의 롤백 절차 존재 여부를 확인한다
参照のみ상태를 변경하는 항목에 대해, 되돌리는 절차가 문서화되어 있는지, 실제로 시도해본 적이 있는지를 확인합니다.
- 3
감사 로그의 5개 항목이 갖춰져 있는지 확인한다
参照のみ최근 자동 실행 1건을 골라, 실행자·실행 시각·입력·출력·승인자를 재구성할 수 있는지 시험합니다.
- 4
중지 스위치 동작을 검증 환경에서 확인한다
中중지 플래그를 세우고, 진행 중인 실행이 다음 단계로 넘어가지 않는지 확인합니다. 프로덕션에서는 실시하지 마십시오.
- 5
재시도 시 이중 적용을 검증 환경에서 확인한다
中중간에 의도적으로 실패시키고, 재개했을 때 이미 완료된 단계가 다시 실행되지 않는지 확인합니다.
対応方法
すぐに実施できる低リスクの対応
상태를 변경하는 자동 실행을 일시적으로 참조 전용으로 내린다
低설계가 갖춰질 때까지 감지와 제안까지만 자동화하고, 실행은 사람이 합니다. 동작을 멈추지 않고 위험도만 낮출 수 있습니다.
대상 allowlist를 정의한다
低대상 호스트와 데이터베이스를 나열하고, 거기 없는 대상에는 실행하지 않도록 합니다. 가장 먼저 효과가 나는 대책입니다.
중지 스위치를 마련한다
低플래그 파일이나 설정값으로 자동 실행을 멈출 수 있게 하고, 누를 수 있는 사람을 명시합니다.
事前検討が必要な変更
dry-run과 본실행을 별도 단계로 나눈다
中dry-run은 차이만 출력하고, 본실행은 승인된 차이에 대해서만 동작하는 구성으로 합니다.
승인 게이트를 구현하고, 승인에 유효기간을 둔다
中승인자, 승인 대상, 유효기간을 정의합니다. 유효기간이 없으면 상황이 바뀐 뒤의 오래된 승인으로 실행될 수 있습니다.
단계 단위 상태 기록을 넣는다
中각 단계의 상태를 영속화하고, 재개 시에는 이미 성공한 단계를 건너뜁니다. 순차 실행 중 실패를 견딜 수 있는 최소 구성입니다.
감사 로그를 변경할 수 없는 위치에 남긴다
中실행자·시각·입력·출력·승인자를, 실행 주체가 고쳐쓸 수 없는 저장소에 기록합니다.
단계적 전개를 도입한다
中1대에서 시도하고, 중지 조건에 걸리지 않으면 범위를 넓힙니다. 전체 동시 적용을 기본값으로 하지 않는 것이 목적입니다.
専門家のレビューが必要な作業
롤백할 수 없는 작업을 자동 실행 경로에서 제외한다
専門家レビュー必須후술하는 작업 범주를 자동 실행 대상에서 제외하도록 정의합니다. 제외 기준을 잘못 그으면 되돌릴 수 없는 작업이 무승인으로 실행되므로, 구현 전 설계 검토가 필요합니다.
승인 권한 설계를 조직의 책임 분계에 맞춘다
専門家レビュー必須누가 승인할 수 있는지는 기술이 아니라 책임의 문제입니다. 서비스 중지를 수반하는 판단의 승인자를, 업무 측과 합의한 뒤 정의합니다.
!注意事項
- 사람의 승인 없이 자동 실행해서는 안 되는 작업: 데이터 삭제, KILL, SHRINK, 강제 페일오버, 복제 초기화, CDC 재설정, 인덱스 전체 재구축, 대규모 통계 갱신, 파라미터 변경, 스키마 변경, DB 재시작, 방화벽 및 권한 변경, binlog 초기화, 백업 삭제.
- 이들의 공통점은 취소가 어렵거나, 실행 중 다른 처리를 끌어들여 정지시킨다는 점입니다. 승인을 거친 뒤, 변경 전 스냅샷과 롤백 절차를 확인하고 나서 실행하십시오.
- 롤백 절차가 존재하지 않는 작업은 자동화 대상으로 삼지 마십시오. "실패하면 수동으로 고친다"는 절차가 아닙니다.
- 승인을 요청하는 알림을 보내는 것만으로는 승인 게이트가 되지 않습니다. 승인을 얻기까지 실행이 진행되지 않음을 구현으로 보장하십시오.
- 단계적 전개는 중지 조건과 함께여야 비로소 기능합니다. 중지 조건이 없는 단계적 전개는 단지 장애 발견이 늦어질 뿐입니다.
- dry-run 출력을 사람이 읽지 않은 채 승인하는 운용이 되어 있지 않은지 정기적으로 확인하십시오. 형식만 남은 승인은 승인이 없는 상태와 다르지 않습니다.
バージョン・環境による違い
これで解決しない場合に確認すること
최근 자동 실행 1건을 골라 5W1H를 재구성해 본다
누가·언제·무엇을·어떤 입력으로·어떤 승인으로 실행했는지를 로그만으로 재구성할 수 있는지 시험합니다.
승인자가 실행자와 동일하지 않은지 확인한다
동일 인물만 승인할 수 있는 상태는 승인 게이트로서 형식뿐인 것이 됩니다.
중지 스위치를 누를 수 있는 사람을 확인한다
야간에 이상이 발생했을 때, 당직자가 단독으로 멈출 수 있는지 확인합니다.
스냅샷 저장 위치가 대상과 운명을 같이하지 않는지 확인한다
같은 서버에 저장하고 있으면, 그 서버가 사라졌을 때 스냅샷도 함께 사라집니다.
allowlist 점검 시기를 정한다
대상이 늘거나 줄었을 때 allowlist가 갱신되지 않으면 실제 상태와 어긋납니다.
この文書の根拠と限界
一般的な技術説明
설계 요소와 작업 범주의 경계는 가역성과 영향 범위에 기반한 일반적인 운용 설계입니다. SQL 예시는 SQL Server의 sys.configurations 공개 사양에 기반합니다. "GIIP 대응 범위" 단락만 GIIP 자체의 운용 형태에 대한 기술이며, 고객 사례가 아닙니다. 사고율이나 방지 효과의 수치는 검증할 수 없어 기재하지 않았습니다.
よくある質問
어디까지 자동화해도 됩니까?
영향이 가역적이고, 대상이 allowlist로 제한되어 있으며, 롤백 절차가 실행 전에 존재하고, 감사 로그가 남는 작업까지입니다. 이 네 조건 중 하나라도 빠지는 것은 승인 게이트 뒤쪽에 두십시오.
승인은 누가 합니까?
실행자와는 다른 사람이 합니다. 추가로, 서비스 중지를 수반할 수 있는 작업은 기술 담당자뿐 아니라 업무 측 의사결정권자를 승인자에 포함하십시오. 중지할지 여부는 기술적 판단이 아니기 때문입니다.
롤백할 수 없는 작업은 어떻게 다룹니까?
자동 실행 대상에서 제외합니다. 실행해야 한다면, 변경 전 스냅샷 확보와 복구 수단(백업 복원 등)의 소요 시간 추정을 사전에 준비한 뒤 사람이 실행합니다.
dry-run이 있으면 승인은 필요 없습니까?
필요 없어지지 않습니다. dry-run은 차이를 보여주는 장치일 뿐이고, 그 차이를 적용해도 되는지의 판단은 별개입니다. dry-run 출력을 사람이 읽고, 그 결과에 대해 승인하는 형태로 하십시오.
중간에 실패한 자동 실행을 재개하면 이중 적용되지 않습니까?
단계 단위로 상태를 영속화하고, 재개 시 이미 성공한 단계를 건너뛰는 설계라면 막을 수 있습니다. 각 단계를 멱등하게 만들면 상태 기록이 손실된 경우의 피해도 줄일 수 있습니다.
감사 로그에는 무엇을 남겨야 합니까?
실행자, 실행 시각, 실행 내용, 입력과 출력, 승인자의 5가지입니다. 저장 위치는 실행하는 에이전트 자신이 고쳐쓸 수 없는 곳으로 하십시오.
この文書がカバーする質問
- AI 워크플로의 순차 실행과 상태 기록은 어떻게 설계하는가
- AI에 프로덕션 작업을 맡길 때 승인 플로우는 어떻게 만드는가
- 자동화해서는 안 되는 데이터베이스 작업 목록을 알고 싶다
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
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エージェントと人間の専門家が継続的に監視・運用しています。
AI 에이전트가 데이터베이스 장애에 대응할 수 있는 범위와, 사람이 판단해야 하는 범위
장애 대응을 단계별로 나누어 AI가 담당할 수 있는 범위(감지·원인 분리·제한적인 1차 대응)와 사람이 판단해야 하는 범위(불가역적 작업·중단 판단)를 정리하고, 조회 전용 트리아지 쿼리를 제공합니다.
giip코딩 에이전트와 GIIP FDE Ops는 무엇이 다른가
코딩 에이전트와 운용 서비스는 "작업의 단위"가 다릅니다. 두 영역의 스코프 경계를 9가지 관점에서 비교하고, 자사에서 확인할 수 있는 명령을 함께 제공합니다.
ai-operationsAI가 만든 애플리케이션을 프로덕션에 올리기까지 필요한 작업
"동작하는 코드가 완성됐다"에서 "프로덕션에서 운영 가능하다"까지 남는 작업을 14개 항목으로 정리하고, 하드코딩된 키 탐지와 의존 패키지 취약점 확인 명령을 함께 제공합니다.
sql-serverSQL Server의 MAXDOP과 Cost Threshold for Parallelism을 확인·변경하는 방법
서버·데이터베이스·쿼리의 3단계에서 병렬 처리 수준을 확인하고 변경하는 절차와, 각각의 적용 범위·영향 범위의 차이를 정리합니다.
関連サービス
자동 실행의 승인 라인을 설계한다
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
자동 실행의 승인 라인을 설계한다