코딩 에이전트와 GIIP FDE Ops는 무엇이 다른가

この文書の適用条件

そのまま実行できるコマンド

# 対象: 自組織のアプリケーションリポジトリと本番デプロイ
# 権限: リポジトリの読み取り権限
# 変更作業: なし（参照のみ）
# Production 実行: 該当なし（手元またはCIで実行）

# 1) 本番ブランチに入った変更が、レビュー（マージ）を経ているか
git log --first-parent --since="90 days ago" --date=short --pretty=format:"%h %ad %an %s" origin/main | head -n 50

# 2) レビューを経ずに直接積まれたコミットが残っていないか
git log --no-merges --since="90 days ago" --pretty=format:"%h %an %s" origin/main | head -n 50

# 3) いま本番で動いているリビジョンを即答できるか
#    デプロイ時にコミットハッシュを埋め込んでいなければ、この問いには答えられない
curl -s https://example.com/healthz | head -n 5

# 対象: 自組織の運用基盤（監視・権限・オンコール・監査）
# 権限: 各基盤の参照権限
# 変更作業: なし（確認のみ）
# Production 実行: 該当なし（確認作業）

[1] 監視と通知の受け口
    - 本番が停止したとき、最初に気づくのは人か仕組みか
    - アラートは誰の端末に届き、誰も応答しない場合に次へ渡る仕組みがあるか
    - 通知が届く先は個人のアカウントか、退職しても残る共有の受け口か

[2] 本番変更の承認
    - 本番への変更に承認者がいるか。承認は記録に残るか
    - 承認なしで本番に適用できる経路（手動デプロイ、直接SSH、DB直接接続）が残っていないか

[3] 権限とシークレット
    - 本番の認証情報はどこに保管され、誰が参照でき、いつ更新されたか
    - 退職・契約終了時に権限を剥奪する手順が文書化されているか

[4] 障害時の一次対応
    - 深夜に落ちたとき、最初の30分で誰が何をするかが決まっているか
    - 切り分けの手順（どのログを見るか、どのクエリを流すか）が書かれているか

[5] ロールバック
    - 直前のバージョンに戻す手順が、実際に試された状態で存在するか
    - データベースのマイグレーションを戻す手順があるか

[6] 監査ログ
    - 誰が・いつ・何を・どの承認で本番に適用したかを後から再構成できるか

[7] オンコールとエスカレーション
    - 一次対応者が判断できない場合の連絡先と判断権限者が決まっているか
    - 対応時間の約束（SLA）があり、その根拠となる監視間隔が定義されているか

[8] 複数システムにまたがる影響判断
    - あるサービスを停止したとき、連鎖して止まる下流を一覧できるか

結果の読み方

こういう状況で使います

• 코딩 에이전트를 도입해 개발 속도는 올랐지만, 프로덕션 장애 건수와 대응 시간은 달라지지 않았다
• "코드는 작성했지만, 프로덕션에 올리는 작업이 끝나지 않는다"는 상태가 계속된다
• 프로덕션에서 지금 어떤 버전이 동작하는지 즉답할 수 없다
• 심야 알림에 누가 응답할지가 정해져 있지 않다
• 프로덕션에 적용한 변경 기록이 개인 채팅 기록에만 남아 있다

考えられる原因（可能性の高い順）

1. 01

   작업의 단위가 다른 것을 기능의 많고 적음으로 비교하고 있다

   코딩 에이전트는 코드 변경을 완료시키는 도구이고, 운용 서비스는 상태를 계속 유지하는 역무입니다. 전자에 후자의 기능을 더해도 당번이나 승인 권한 같은 "사람과 조직에 속하는 요소"는 채워지지 않습니다.

2. 02

   프로덕션 환경에 대한 권한 설계가 없다

   프로덕션 변경을 자동화하려면 무엇을 누구의 승인으로 실행해도 되는지에 대한 권한 설계가 먼저 필요합니다. 설계가 없는 상태에서는 안전 쪽으로 기울어 결국 모든 것을 사람 손으로 되돌리게 됩니다.

3. 03

   알림 수신 체계가 개인에게 묶여 있다

   알림이 특정 개인의 계정에만 도착하는 경우, 그 사람이 부재한 시간대에는 모니터링이 실질적으로 정지됩니다. 모니터링 도구의 유무가 아니라 수신 체계 설계의 문제입니다.

4. 04

   롤백이 "되돌릴 수 있을 것"에서 멈춰 있다

   실제로 시도해보지 않은 롤백 절차는 장애 시점에 처음으로 실패가 드러납니다. 특히 데이터베이스 스키마 변경이나 데이터 삭제는 코드 되돌리기로는 복구되지 않습니다.

確認手順

1. 1

   프로덕션의 가동 리비전을 확인한다

   参照のみ

   프로덕션에서 동작 중인 커밋 해시를 배포 기록 또는 앱의 헬스 엔드포인트에서 가져옵니다. 가져올 수 없다면 변경 추적이 성립하지 않은 상태입니다.

2. 2

   리뷰를 거치지 않은 프로덕션 변경이 없는지 확인한다

   参照のみ

   위의 git 명령으로 머지를 거치지 않고 프로덕션 브랜치에 들어간 커밋을 찾아냅니다.

3. 3

   감사 로그의 존재 여부를 확인한다

   参照のみ

   프로덕션 적용에 대해 실행자·시각·내용·승인자 4가지를 사후에 재구성할 수 있는지 확인합니다. 하나라도 빠지면 감사 로그로서 부족합니다.

4. 4

   온콜 표와 알림 경로를 확인한다

   参照のみ

   최근 1개월의 알림에 대해 누가 언제 응답했는지 확인합니다. 응답 기록이 없는 알림은 "아무도 알아차리지 못했을" 가능성이 있습니다.

5. 5

   롤백을 실제로 수행할 수 있는지 확인한다

   中

   프로덕션과 동등한 구성을 가진 환경에서 직전 버전으로의 되돌림과 마이그레이션 롤백을 한 번 실행합니다.

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• 최근 장애의 1차 대응 기록을 다시 읽어본다

  탐지부터 원인 분리까지 몇 분이 걸렸고 어디서 멈췄는지 확인합니다. 멈춘 지점이 채워야 할 공백입니다.

• 프로덕션에 닿는 경로를 모두 센다

  CI/CD, 수동 배포, SSH, DB 클라이언트, 클라우드 콘솔, 관리 화면. 센 경로 중 기록이 남지 않는 것을 특정합니다.

• 부재 시 대체 담당이 정해져 있는지 확인한다

  주담당자가 휴가 중이어도 같은 절차가 돌아가는지 확인합니다. 돌아가지 않는다면 그것은 자동화가 아니라 특정인 의존입니다.

• 모니터링 대상이 "서비스 성립 조건"을 포괄하는지 확인한다

  프로세스의 생사뿐 아니라 실제로 사용자가 쓰는 경로가 성립하는지를 보고 있는지 확인합니다.

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• 코딩 에이전트로 운용까지 자동화할 수 있나요
• AI에게 코드를 작성시킨 후 프로덕션 운용은 누가 하는가
• FDE Ops와 코딩 에이전트의 담당 범위 차이를 알고 싶다

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

여기까지의 정리는 특정 제품을 전제로 하지 않는 일반적인 설계 이야기입니다. 그 위에서 GIIP가 어느 부분을 담당하는지 말하면, GIIP는 AWS와 Azure상의 복수 데이터베이스 및 약 30개의 웹 서비스를 AI 에이전트와 인간 전문가가 지속적으로 모니터링·운용하고 있습니다. AI 에이전트가 상시 모니터링과 정형적인 확인 작업을 실행하고, 불가역적인 작업이나 업무 영향을 수반하는 판단은 인간 담당자가 승인한 뒤 실행하는 역할 분담으로 운용하고 있습니다. 본 문서에서 언급한 공백 중 어느 것을 자사가 보유하고 어느 것을 외부에 맡길지는 체계 설계에 따라 달라집니다.

関連サービス

• GIIP FDE Ops の対応範囲
• コーディングエージェントとFDE Boxの違い
• AIエージェントによるIT運用