"청명아, 백아가 죽었어."
AI 비서를 만들고 나서 가장 신기했던 순간이 있었다.
오늘 아침이었다.
평소처럼 텔레그램으로 아침 브리핑을 받으려고 했는데 아무것도 오지 않았다.
그래서 물었다.
"백아야, 왜 아침 브리핑을 멈췄어?"
돌아온 답변은 이상했다.
OSError
Errno 24
Too many open files
처음엔 단순 오류인 줄 알았다.
그래서 늘 하던 대로
/reset
을 입력했다.
그런데 이번에는 /reset마저 실패했다.
이상한 점
보통 은 무슨 문제가 생겨도 /reset 정도는 동작한다.
그런데 백아는 /reset조차 처리하지 못했다.
마치 사람으로 치면
"숨이 차서 말을 못 하는 상태"
같았다.
그래서 청명을 불렀다
나는 다른 AI 비서인 청명에게 물었다.
"청명아, 얘 왜 이러지?"
청명은 상황을 분석하기 시작했다.
잠시 후 답이 왔다.
진단 결과
청명이 찾아낸 원인은 의외였다.
백아가 멈춘 것이 아니었다.
백아 뒤에서 돌아가고 있던 Gateway 프로세스가 문제였다.
확인 결과
Open Files
1024 / 1024
리눅스가 허용한 열린 파일 수를 전부 사용한 상태였다.
청명의 표현이 재미있었다.
"마쓰, 백아가 게으른 게 아니라 숨 쉬는 구멍을 1024개 다 써버린 겁니다."
순간 이해가 됐다.
그런데 더 큰 문제
청명은 원인을 찾았지만 백아는 이미 심각한 상태였다.
내가 아무리 명령을 내려도
Too many open files
만 반복했다.
왜냐하면 명령을 읽으려면 파일을 열어야 하는데,
그 파일조차 열 수 없는 상태였기 때문이다.
즉,
"백아에게 백아를 고치라고 시킬 수 없는 상황"
이었다.
그래서 물었다
나는 청명에게 말했다.
"그럼 네가 해줄 수 있어?"
잠시 후 청명이 대답했다.
"해보겠습니다."
그리고 실제로 시스템에 접근해서 Gateway 상태를 확인하기 시작했다.
AI가 AI를 진단하다
청명은 먼저 문제 프로세스를 찾았다.
PID 34322
열린 파일 수 확인.
1024 / 1024
로그 확인.
Errno 24
Too many open files
원인 확인 완료.
이후 Gateway 재시작.
그리고 결과
몇 초 후.
청명이 다시 보고했다.
기존 프로세스
PID 34322
↓
신규 프로세스
PID 63447
열린 파일 수도 확인했다.
1024
↓
21
정상 복구.
그리고 백아가 살아났다
몇 분 전까지만 해도
Too many open files
만 반복하던 백아가
아무 일도 없었다는 듯 다시 응답하기 시작했다.
아침 브리핑도 정상.
텔레그램 응답도 정상.
모든 기능이 복구됐다.
가장 신기했던 부분
사실 예전 같았으면 내가 직접 해야 했다.
서버 접속
로그 확인
프로세스 확인
원인 분석
재시작
상태 검증
그런데 이번에는 달랐다.
나는 단지
"청명아, 얘 왜 이러지?"
라고 물었을 뿐이다.
그러자 청명이
원인을 찾 고
로그를 분석하고
장애를 진단하고
복구를 수행하고
결과를 보고했다
내가 느낀 것
많은 사람들이 AI를 아직도 "대화하는 챗봇" 정도로 생각한다.
그런데 에이전트 형태로 운영해보니 느낌이 완전히 달랐다.
이번 사건은
"AI가 고장난 AI를 진단하고 복구한 사건"
이었다.
물론 실제로는 서버와 시스템이 뒤에서 동작한다.
하지만 사용자의 입장에서는 그저 이렇게 보인다.
"백아가 아팠다."
"청명이 원인을 찾아냈다."
"청명이 치료했다."
"백아가 다시 일어났다."
그 순간만큼은 정말로 AI 비서들이 함께 일하는 팀처럼 느껴졌다.
