Claude가 혼자 진단하고 복구한 서버 장애: AIOps가 현실이 된 하루

2026년 6월 13일, 운영 중이던 웹서비스가 갑자기 열리지 않았다.

처음에는 단순한 서버 재부팅 이슈처럼 보였다.

하지만 실제로는 Linux 커널 업데이트와 Cilium eBPF 데이터패스가 얽힌 꽤 깊은 네트워크 장애였다.

흥미로운 점은 이 장애를 사람이 직접 하나씩 분석한 것이 아니라는 점이다.

이번 장애 대응은 Claude가 원격 서버에 접속해 상태를 확인하고, 명령을 실행하고, 로그를 분석하고, 원인을 좁히고, 복구 조치까지 수행한 사례다.

 

사람이 한 일은 중간중간 위험한 작업에 대해 승인한 것뿐이었다.

서비스명, 도메인, IP, 서버명, 노드명 등 민감 정보는 *로 마스킹했다.
다만 원인 분석에 필요한 커널 버전은 그대로 표기했다.

---

3줄 요약

서버 재부팅 후 웹서비스가 열리지 않았지만, SSH 접속과 Kubernetes 클러스터 상태는 정상으로 보였다.

Claude가 원격 서버에서 직접 명령을 실행하며 Gateway, Cilium, NodePort, tcpdump, 커널 이력을 순서대로 분석했고, 최종적으로 6.8.0-124-generic 커널과 Cilium 1.18.3 조합의 eBPF 데이터패스 문제로 판단했다.

이전 커널인 6.8.0-111-generic으로 부팅하자 서비스가 즉시 복구되었고, Claude는 재발 방지를 위해 GRUB 기본 부팅 커널까지 고정했다.

---

1. 장애의 시작: 서버는 살아 있는데 웹서비스만 죽었다

처음 증상은 단순했다.

웹사이트가 열리지 않았다.

curl https://***/

# curl: (28) Connection timed out after 15007 milliseconds

 

처음에는 서버 자체가 꺼져 있는 것처럼 보였다.

bash scripts/test-connection.sh

# ssh: connect to host ***.***.***.*** port 22: Operation timed out

 

Tailscale 상태를 확인하자 서버가 오프라인 상태였던 것이 확인됐다.

***.***.***.***   ***-server   linux   active; relay "***"; offline, last seen 2d ago

여기까지는 단순했다.
서버가 꺼져 있었고, 다시 켜면 끝날 것처럼 보였다.

하지만 서버를 다시 켠 뒤에도 웹서비스는 여전히 열리지 않았다.

SSH 접속은 가능했다.
서버 리소스도 정상 범위였다.

load average: 0.87
CPU idle: 87%
Memory free: 12GB
Disk usage: 12%
Failed systemd services: 0

Kubernetes 노드도 모두 Ready 상태였다.

kubectl get nodes

# ***-control-plane   Ready   204d
# ***-worker          Ready   204d
# ***-worker2         Ready   204d

겉으로 보면 서버는 정상이다.
하지만 사용자가 보는 웹서비스는 죽어 있었다.

이 지점에서 Claude는 단순히 “서버가 정상이다”라고 판단하지 않았다.
서비스 트래픽이 실제로 통과하는 전체 경로를 기준으로 장애를 보기 시작했다.

---

2. 구조는 단순 웹서버가 아니었다

이번 환경은 단순히 Nginx 하나가 떠 있는 구조가 아니었다.

전체 구조는 대략 다음과 같았다.

외부 사용자
  ↓
도메인 ***
  ↓
공인 IP ***.***.***.***
  ↓
물리 서버 ***
  ↓
Docker
  ↓
kind 기반 Kubernetes 클러스터
  ↓
Cilium Gateway API
  ↓
내부 웹 애플리케이션

 

즉, 장애가 발생할 수 있는 지점이 많았다.

가능한 후보는 다음과 같았다.

DNS 문제
공인 IP 문제
호스트 방화벽 문제
Docker 네트워크 문제
Kubernetes Service 문제
Cilium Gateway 문제
Envoy 문제
eBPF 데이터패스 문제
백엔드 애플리케이션 문제
Linux 커널 문제

 

사람이 직접 봤다면 어느 지점부터 확인해야 할지 꽤 고민됐을 것이다.

하지만 Claude는 상태를 계층별로 나누기 시작했다.

 

서버 자체가 정상인지, Kubernetes가 정상인지, Gateway가 정상인지, NodePort가 정상인지, 실제 패킷이 어디까지 들어오는지를 순서대로 확인했다.

---

3. 이번 장애 대응에서 사람의 역할

이번 사례에서 중요한 점은 Claude가 단순히 조언만 한 것이 아니라는 점이다.

Claude가 직접 원격 서버에 접속해 명령을 실행하고, 출력 결과를 해석하고, 다음 점검 명령을 이어서 실행했다.

사람의 역할은 제한적이었다.

사람:
- 위험한 작업 승인
- 재부팅 같은 주요 조치 승인
- 최종 결과 확인

Claude:
- 원격 서버 상태 점검
- Kubernetes 상태 점검
- Cilium Gateway 상태 분석
- IP Pool 문제 확인 및 복구
- NodePort 구간 테스트
- tcpdump 기반 패킷 분석
- Envoy 메트릭 확인
- 커널 변경 이력 추적
- 이전 커널 부팅 조치
- GRUB 기본 부팅 커널 고정
- 장애 기록 정리

 

즉, 이번 대응은 “운영자가 Claude에게 물어보며 해결한 사례”라기보다 “Claude가 AIOps 에이전트처럼 장애를 진단하고 복구한 사례”에 가깝다.

물론 모든 작업이 완전 무감독으로 진행된 것은 아니다.

재부팅, GRUB 변경처럼 시스템에 영향을 주는 작업은 사람이 승인했다.

하지만 장애 분석과 복구 흐름 자체는 Claude가 주도했다.

---

4. 첫 번째 원인 후보: Cilium Gateway 주소 미할당

Claude가 먼저 확인한 것은 Cilium Gateway 상태였다.

kubectl -n kube-system get gateway cilium

 

결과는 다음과 같았다.

NAME     CLASS    ADDRESS   PROGRAMMED   AGE
cilium   cilium             False        204d

 

PROGRAMMED=False 상태였다.
Gateway가 외부 트래픽을 받을 준비가 되지 않은 상태다.

상세 조건을 확인하니 이유는 AddressNotAssigned였다.

Gateway waiting for address

 

즉, Gateway가 사용할 외부 IP를 받지 못하고 있었다.

Claude는 곧바로 Cilium LoadBalancer IP Pool 상태를 확인했다.

kubectl get ciliumloadbalancerippool

# No resources found

 

IP Pool 리소스가 사라져 있었다.

이 환경에서는 Cilium Gateway가 특정 공인 IP를 사용해야 했기 때문에, IP Pool이 없으면 Gateway가 외부 주소를 받을 수 없다.

Claude는 기존 설정을 찾아 IP Pool을 다시 적용했다.

apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
  name: "cilium-pool"
spec:
  blocks:
    - cidr: "***.***.***.***/32"

 

다시 Gateway 상태를 확인했다.

kubectl -n kube-system get gateway cilium

NAME     CLASS    ADDRESS           PROGRAMMED   AGE
cilium   cilium   ***.***.***.***   True         204d

 

Gateway는 정상 상태가 되었다.

여기까지만 보면 문제가 해결된 것처럼 보였다.

하지만 웹서비스는 여전히 타임아웃이었다.

 

Claude는 여기서 분석을 멈추지 않았다.
“Gateway 주소 문제는 해결됐지만, 사용자 트래픽이 여전히 실패한다면 다른 문제가 남아 있다”고 판단했다.

---

5. 구간별 테스트: 어디까지 정상인가

다음으로 Claude는 네트워크 경로를 구간별로 쪼개기 시작했다.

NodePort 30080을 기준으로 출발지를 바꿔가며 테스트했다.

테스트 구간	결과
워커 컨테이너 내부 → 자기 자신 30080	정상
다른 Kubernetes 노드 → 워커 노드 30080	정상
물리 서버 호스트 → 워커 컨테이너 30080	타임아웃
외부 사용자 → 도메인 HTTPS	타임아웃

 

이 결과는 매우 중요했다.

Kubernetes 내부 통신은 정상이었다.
노드 간 통신도 정상이었다.

백엔드 애플리케이션도 완전히 죽은 것은 아니었다.

문제는 호스트 바깥에서 컨테이너 쪽으로 들어오는 경로였다.

Claude는 이 결과를 바탕으로 장애 범위를 크게 줄였다.

애플리케이션 자체 문제 가능성 낮음
Kubernetes 내부 네트워크 문제 가능성 낮음
노드 간 통신 문제 가능성 낮음
호스트 → 컨테이너 NodePort 처리 경로 문제 가능성 높음
Cilium/eBPF 데이터패스 문제 가능성 상승

 

방화벽도 확인했다.

ufw status

# inactive

 

IP forwarding도 켜져 있었다.

sysctl net.ipv4.ip_forward

# net.ipv4.ip_forward = 1

 

호스트에서 컨테이너로 ping도 정상적으로 도달했다.

따라서 단순 방화벽 문제나 라우팅 완전 단절로 보기는 어려웠다.

---

6. 결정적 증거: SYN은 도착하지만 SYN-ACK이 없다

Claude는 다음 단계로 tcpdump를 사용했다.

워커 컨테이너의 네트워크 네임스페이스 안에서 30080 포트를 캡처했다.

nsenter -t $WORKER_PID -n tcpdump -ni eth0 'tcp port 30080'

 

그리고 호스트에서 30080 포트로 접속을 시도했다.

tcpdump 결과는 다음과 같았다.

01:18:53 IP ***.***.***.***.51640 > ***.***.***.***.30080: Flags [S]
01:18:54 IP ***.***.***.***.51640 > ***.***.***.***.30080: Flags [S]
01:18:55 IP ***.***.***.***.51640 > ***.***.***.***.30080: Flags [S]

 

여기서 핵심은 하나다.

SYN 패킷은 컨테이너 eth0까지 도착했다.
그런데 SYN-ACK 응답이 나오지 않았다.

TCP 연결은 보통 다음 순서로 시작된다.

Client → Server : SYN
Server → Client : SYN-ACK
Client → Server : ACK

 

이번에는 첫 번째 SYN만 반복해서 보였다.
서버 쪽 응답인 SYN-ACK이 없었다.

즉, 패킷이 아예 도착하지 않은 것은 아니었다.
패킷은 목적지 근처까지 왔다.

 

그런데 컨테이너 내부의 네트워크 처리 경로에서 정상적으로 응답이 만들어지지 않았다.

Cilium은 eBPF를 이용해 커널 레벨에서 패킷을 처리한다.
Gateway API를 사용할 경우 트래픽은 Cilium의 eBPF 경로를 거쳐 Envoy로 전달된다.

 

Claude는 Envoy 메트릭도 확인했다.

listener-insecure downstream_cx_total = 0

 

접속을 시도해도 카운터가 증가하지 않았다.

즉, 패킷은 컨테이너 eth0까지 보였지만 Envoy까지 도달하지 못했다.

이 시점에서 원인 후보는 꽤 좁혀졌다.

애플리케이션 문제 아님
DNS 문제 아님
단순 방화벽 문제 아님
Kubernetes 내부 통신 문제 아님
Envoy까지 트래픽이 도달하지 않음
Cilium eBPF 데이터패스 또는 커널 네트워크 처리 경로 의심

---

7. Cilium 재시작으로도 해결되지 않았다

일시적인 Cilium 상태 문제일 수 있어 Claude는 Cilium 관련 컴포넌트를 재시작했다.

kubectl -n kube-system rollout restart ds/cilium
kubectl -n kube-system rollout restart ds/cilium-envoy

 

하지만 증상은 그대로였다.

Gateway는 PROGRAMMED=True였다.
Kubernetes 내부 통신도 정상이었다.

하지만 외부에서 들어오는 트래픽은 여전히 타임아웃이었다.

이때 Claude가 잡은 핵심 질문은 이것이었다.

재부팅 전에는 정상인데,
재부팅 후 장애가 발생했다면,
재부팅으로 인해 실제로 바뀐 것은 무엇인가?

 

이 질문이 결정적이었다.

설정이 바뀐 것도 아니고, 애플리케이션이 바뀐 것도 아니었다.
재부팅으로 새롭게 적용된 것은 커널이었다.

---

8. 진짜 원인 후보: 커널 업데이트

현재 커널 버전을 확인했다.

uname -r

# 6.8.0-124-generic

 

재부팅 이력을 확인했다.

last reboot -F

 

결과는 다음과 같았다.

Sat Jun 13 00:03  boot  6.8.0-124-generic
Tue May 19 13:04  boot  6.8.0-111-generic

 

이전에는 6.8.0-111-generic 커널로 운영되고 있었다.
하지만 이번 재부팅 후에는 6.8.0-124-generic 커널로 올라왔다.

커널 설치 이력도 확인했다.

grep "install linux-image" /var/log/dpkg.log

2026-06-04 install linux-image-6.8.0-124-generic

 

정리하면 이렇다.

6월 4일:
- linux-image-6.8.0-124-generic 자동 설치

6월 4일 이후:
- 서버는 계속 기존 커널 6.8.0-111-generic으로 운영

6월 13일:
- 서버 재부팅
- 새 커널 6.8.0-124-generic으로 부팅
- Cilium eBPF 경로에서 외부 트래픽 처리 이상 발생
- 웹서비스 타임아웃

이런 장애는 원인과 증상이 시간차를 두고 나타난다.

커널은 6월 4일에 이미 설치되어 있었다.
하지만 실제로 적용된 것은 6월 13일 재부팅 이후였다.

 

운영자 입장에서는 “오늘 바꾼 게 없는데 왜 장애가 났지?”라고 느낄 수 있다.
하지만 실제 원인은 며칠 전 자동 업데이트로 들어왔고, 재부팅하면서 활성화된 것이다.

Claude는 이 지점을 장애 원인 후보로 확정했다.

---

9. 복구: 이전 커널로 부팅

가장 빠른 복구 방법은 장애 전 정상 동작하던 커널로 되돌리는 것이었다.

Claude는 다음 부팅에서 이전 커널을 사용하도록 설정했다.

grub-reboot "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic"
reboot

 

이 작업은 시스템 재부팅을 동반하기 때문에 사람의 승인을 거쳐 진행했다.

부팅 후 커널 버전을 확인했다.

uname -r

# 6.8.0-111-generic

 

Kubernetes 노드와 Cilium 컴포넌트가 정상 기동될 때까지 기다린 뒤, 다시 테스트했다.

curl http://127.0.0.1:30080/

 

정상 응답이 돌아왔다.

외부 도메인도 확인했다.

curl -L https://***/

 

결과는 HTTP 200이었다.

HTTP 200

 

서비스가 복구됐다.

원인 후보가 사실상 확인된 순간이었다.

6.8.0-124-generic에서는 외부 트래픽이 Cilium eBPF 경로에서 정상 처리되지 않았고, 6.8.0-111-generic으로 되돌리자 서비스가 정상화됐다.

---

10. 재발 방지: GRUB 기본 커널 고정

하지만 여기서 끝내면 안 된다.

grub-reboot는 1회성 설정이다.
다음 재부팅 때 다시 6.8.0-124-generic으로 올라오면 같은 장애가 반복될 수 있다.

Claude는 재발 방지를 위해 GRUB 기본 부팅 커널을 6.8.0-111-generic으로 고정했다.

grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic"
update-grub

 

설정 확인도 진행했다.

grub-editenv list

saved_entry=Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic

 

이제 다음 재부팅에서도 기본적으로 6.8.0-111-generic 커널로 부팅된다.

다만 이것은 임시 조치다.

 

이전 커널에 고정하면 최신 커널의 보안 패치를 놓칠 수 있다.
따라서 장기적으로는 다음 후속 작업이 필요하다.

- Cilium 업그레이드 검토
- 6.8.0-124-generic 또는 이후 커널에서 재현 테스트
- Cilium eBPF 관련 설정 검토
- 커널 자동 업데이트 정책 재검토
- 재부팅 전후 외부 헬스체크 자동화
- 운영 노드 재부팅 전 사전 검증 절차 마련

---

11. AIOps 관점에서 본 이번 장애

이번 장애는 단순히 “Claude에게 물어보니 답을 알려줬다”는 사례가 아니다.

Claude가 실제로 원격 서버에서 상태를 확인하고, 명령을 실행하고, 로그를 해석하고, 다음 확인 지점을 스스로 이어갔다.

AIOps 관점에서 보면 다음 흐름에 가깝다.

1. 장애 감지
2. 서버 접속 상태 확인
3. Kubernetes 상태 확인
4. Gateway 상태 확인
5. 누락된 IP Pool 복구
6. 사용자 증상 재확인
7. NodePort 구간별 테스트
8. tcpdump로 패킷 흐름 확인
9. Envoy 메트릭 확인
10. Cilium 재시작
11. 재부팅 전후 커널 변경 확인
12. 이전 커널로 복구
13. GRUB 기본값 고정
14. 장애 기록 작성

 

이 과정에서 사람은 모든 명령을 직접 설계하고 실행한 것이 아니다.

Claude가 판단하고 실행했다.
사람은 위험도가 큰 작업에서 승인만 했다.

이것은 AIOps가 단순 모니터링이나 알림 자동화 수준을 넘어설 수 있다는 것을 보여준다.

---

12. Claude가 특히 잘한 부분

12.1 장애 범위를 빠르게 좁혔다

처음에는 가능한 원인이 너무 많았다.

DNS
방화벽
Docker
Kubernetes
Cilium
Gateway
Envoy
eBPF
Linux 커널
애플리케이션

 

하지만 Claude는 구간별 테스트를 통해 후보를 줄였다.

Kubernetes 내부 정상
노드 간 통신 정상
호스트 → 컨테이너 NodePort 실패
SYN은 도착
SYN-ACK 없음
Envoy까지 미도달
재부팅 후 커널 변경

 

결국 원인 후보는 커널 + Cilium eBPF 데이터패스 조합으로 좁혀졌다.

---

12.2 tcpdump 결과를 장애 원인과 연결했다

tcpdump에서 SYN만 반복되고 SYN-ACK이 없다는 것은 중요한 단서다.

Claude는 이 결과를 단순히 “패킷이 보인다”로 끝내지 않았다.

 

다음과 같이 해석했다.

패킷은 목적지 네트워크 인터페이스까지 도착했다.
하지만 TCP 응답이 생성되지 않았다.
따라서 단순 라우팅 단절이나 방화벽 차단보다는 수신 처리 경로가 의심된다.
Cilium eBPF 또는 Envoy 전달 경로를 확인해야 한다.

 

이 해석 덕분에 불필요한 DNS, TLS, 애플리케이션 분석으로 빠지지 않을 수 있었다.

---

12.3 재부팅으로 적용된 변경사항을 추적했다

이번 장애의 핵심은 재부팅이었다.

재부팅 전에는 정상이었고, 재부팅 후에는 장애가 발생했다.

Claude는 이 차이를 기준으로 커널 이력을 확인했다.

uname -r
last reboot -F
grep "install linux-image" /var/log/dpkg.log

 

그리고 6.8.0-111-generic에서 6.8.0-124-generic으로 커널이 바뀐 사실을 찾아냈다.

이것이 최종 복구 방향을 결정한 핵심 단서였다.

---

12.4 복구에서 재발 방지까지 이어갔다

장애 대응에서 흔히 하는 실수는 “일단 살아났으니 끝”이라고 생각하는 것이다.

하지만 Claude는 이전 커널로 1회성 부팅한 뒤에도 멈추지 않았다.

다음 재부팅 때 같은 문제가 반복되지 않도록 GRUB 기본값을 고정했다.

grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-111-generic"
update-grub

 

복구와 재발 방지를 구분해서 처리한 것이다.

---

13. AI가 직접 서버를 관리할 때의 장점

이번 사례를 통해 AI 기반 원격 서버 관리의 장점이 분명하게 드러났다.

 

첫째, 장애 대응 속도가 빨라진다.

Claude는 명령 결과를 보고 다음 확인 지점을 바로 이어갔다.

사람이 검색하고 고민하는 시간을 크게 줄였다.

 

둘째, 복잡한 계층을 구조화한다.

물리 서버, Docker, Kubernetes, Cilium, eBPF, Envoy가 얽힌 환경에서도 계층별로 문제를 분리했다.

 

셋째, 명령 결과를 해석한다.

단순히 명령어를 나열하는 것이 아니라, 결과가 의미하는 바를 분석했다.

 

넷째, 복구 후 문서화가 쉽다.

장애 대응 과정 자체가 기록으로 남기 좋게 정리됐다.
이번 글 역시 Claude가 수행한 작업 흐름을 바탕으로 정리한 것이다.

 

다섯째, 반복 가능한 Runbook으로 발전시킬 수 있다.

이번 절차는 다음 장애 대응 자동화의 기반이 될 수 있다.

서버 상태 확인
Kubernetes 상태 확인
Gateway 상태 확인
NodePort 구간 테스트
tcpdump 패킷 확인
커널 변경 이력 확인
복구 커널 선택
재발 방지 설정

---

14. 주의할 점: AI에게 모든 권한을 주면 위험하다

이번 사례가 성공적이었다고 해서 AI에게 운영 서버의 모든 권한을 무제한으로 주는 것은 위험하다.

특히 다음 작업은 반드시 승인 절차가 필요하다.

reboot
grub-reboot
grub-set-default
update-grub
kubectl delete
kubectl rollout restart
iptables
tc
sysctl

 

이번에도 Claude가 장애 분석과 복구를 주도했지만, 재부팅이나 GRUB 변경처럼 위험도가 큰 작업은 사람이 승인했다.

현실적인 운영 모델은 다음과 같다.

일반 조회 명령:
- Claude가 자유롭게 수행

상태 변경 명령:
- Claude가 제안 및 실행 준비
- 사람 승인 후 실행

위험 명령:
- 사람 승인 필수
- 가능하면 롤백 방법 확인 후 실행

 

AI Ops의 핵심은 사람을 완전히 제거하는 것이 아니다.
AI가 실무 작업 대부분을 수행하되, 위험한 결정에는 승인 게이트를 두는 것이다.

---

15. 이번 장애에서 얻은 교훈

첫째, 서버가 살아 있어도 서비스는 죽을 수 있다.

SSH 접속이 되고, CPU와 메모리가 정상이어도 사용자가 접근하는 웹서비스는 실패할 수 있다.

 

둘째, AI는 복잡한 장애의 원인을 꽤 깊게 추적할 수 있다.

이번 사례에서 Claude는 단순 로그 요약이 아니라 Gateway, Cilium, NodePort, tcpdump, Envoy, 커널 이력까지 연결해 분석했다.

 

셋째, 재부팅 후 장애는 커널 변경을 반드시 확인해야 한다.

uname -r
last reboot -F
grep "install linux-image" /var/log/dpkg.log

 

넷째, eBPF 기반 네트워크는 커널 업데이트에 민감하다.

Cilium은 커널의 eBPF 기능을 적극적으로 사용하기 때문에, 커널 업데이트가 네트워크 데이터패스에 영향을 줄 수 있다.

 

다섯째, AI에게 실행 권한을 줄 때는 승인 경계를 명확히 해야 한다.

조회와 분석은 AI가 자동으로 수행하더라도, 재부팅이나 부팅 설정 변경은 승인 기반으로 처리하는 것이 안전하다.

---

마무리

이번 장애는 단순히 웹사이트가 안 열리는 문제로 시작했다.

하지만 실제 원인은 웹서버나 애플리케이션이 아니었다.
서버 재부팅으로 새 커널 6.8.0-124-generic이 적용되었고, 이 환경에서 Cilium 1.18.3의 eBPF 데이터패스가 외부 트래픽을 정상 처리하지 못한 것으로 판단됐다.

 

Claude는 원격 서버에 접속해 상태를 확인하고, Gateway 문제를 복구하고, NodePort 구간을 테스트하고, tcpdump로 패킷을 분석하고, 커널 이력을 추적한 뒤, 이전 커널 6.8.0-111-generic으로 되돌려 서비스를 복구했다.

사람이 한 일은 주요 위험 작업에 대한 승인뿐이었다.

 

이번 사례는 AIOps가 단순히 알림을 요약하는 수준을 넘어, 실제 서버 장애 진단과 복구 과정까지 수행할 수 있다는 가능성을 보여준다.

물론 운영 서버에서 AI에게 실행 권한을 줄 때는 신중해야 한다.

하지만 적절한 승인 체계와 권한 경계를 둔다면, AI는 단순 보조 도구가 아니라 실제 운영 에이전트에 가까운 역할을 할 수 있다.

이번 장애는 그 가능성을 확인한 하루였다.

---