AI 서버 점검 자동화: 일주일 걸리던 Linux·Solaris 스크립트를 10분에 만든 과정

free: command not found, ps: unknown output format.

나는 DB 서버에 점검 명령을 실행했다가 오류가 계속 나오는 화면을 봤다. 처음 만든 것은 Linux용 서버 점검 스크립트였는데, 내가 접속한 서버는 Linux가 아니라 Oracle Solaris였다. 같은 서버 점검이라도 운영체제가 다르면 명령어와 출력 형식이 달랐다. 예전 같으면 명령어를 다시 찾고 결과를 비교하는 데 며칠을 썼을 상황이었다.

AI 서버 점검 자동화에서 가장 중요한 것은 스크립트를 빨리 만드는 일이 아니었다. AI가 만든 명령을 내가 실제 서버에서 실행하고, 운영체제별 차이와 결과를 직접 검증한 뒤 반영하는 과정이 핵심이었다.

AI로 서버 점검 스크립트를 만들면 얼마나 빨라질까?

AI를 사용하기 전에는 서버 점검 스크립트 하나를 만드는 데 일주일 정도 걸렸다. CPU와 메모리, 디스크 사용량, 서버 가동 시간, 실행 중인 프로세스, 좀비 프로세스처럼 매달 확인해야 할 항목을 먼저 정해야 했다. 항목마다 사용할 명령을 찾은 뒤에는 출력 결과가 보고서에 쓸 수 있는 형태인지 확인하고, 운영 서버에 적용해도 문제가 없는 명령인지 다시 검토했다.

나는 전산실 업무를 혼자 처리하고 있었기 때문에 스크립트 작성에만 시간을 쓸 수 없었다. 매달 서버 점검보고와 접속기록 점검보고를 작성했고, 장애가 발생하면 하던 일을 멈추고 대응해야 했다. 그러다 보니 간단해 보이는 점검 자동화도 실제 반영까지 일주일이 걸렸다. AI를 사용한 뒤 첫 초안은 약 10분 만에 만들 수 있었다. 다만 10분은 작성 시간이고, 실제 사용 여부를 판단하고 검증하는 책임은 여전히 나에게 있었다.

Linux 서버 점검 스크립트를 먼저 만들었다

나는 AI에게 매달 확인하는 서버 점검 항목을 설명하고 Linux 환경에서 사용할 명령을 정리하게 했다. 날짜와 운영체제, 가동 시간, 메모리, 디스크와 inode 사용량, 좀비 프로세스, CPU와 메모리를 많이 사용하는 프로세스를 한 번에 확인하는 구성이었다. 예전에는 각 명령의 옵션을 찾아보고 출력 형식을 맞추는 데 시간이 많이 들었지만, 이번에는 내가 필요한 항목과 결과 형태를 설명하자 바로 검토할 수 있는 초안이 나왔다.

나는 AI가 만든 내용을 그대로 운영 서버에 넣지 않았다. 먼저 서버 설정을 변경하거나 프로세스를 종료하는 명령이 포함되어 있지 않은지 확인했다. 그다음 로컬 환경에서 형식을 보고, 테스트할 수 있는 서버에서 실행한 뒤 운영 서버에서 결과를 확인했다. AI는 작성 시간을 줄여줬지만 실제 서버의 상태와 명령 결과를 판단한 사람은 나였다. 이 과정을 거친 뒤 Linux용 스크립트를 실제 월간 점검 업무에 반영했다.

Linux 서버의 CPU·메모리·디스크·프로세스를 확인하도록 만든 월간 점검 스크립트 일부

Linux 명령이 실행되지 않았고 서버는 Solaris였다

문제는 DB 서버에서 발생했다. Linux용 스크립트를 실행하자 free -h는 명령을 찾을 수 없다고 나왔고, GNU 방식의 ps --sort와 df -i도 정상적으로 실행되지 않았다. 처음에는 명령을 잘못 입력했다고 생각했지만 오류 내용을 다시 확인하면서 이 서버가 Linux가 아니라 Oracle Solaris라는 것을 알게 됐다. 같은 서버라는 이유로 운영체제 차이를 충분히 확인하지 않고 Linux용 명령을 실행한 것이다.

나는 AI와 함께 명령을 Solaris 환경에 맞게 다시 바꿨다. 메모리는 free 대신 prtconf, swap, vmstat로 확인하고 CPU와 프로세스는 mpstat와 prstat을 사용했다. 실제 점검에서는 CPU idle 약 98.8%, Oracle 설치 영역 사용률 79%, 백업용 NFS 영역 사용률 80%, 약 745일의 가동 시간을 확인했다. 좀비 프로세스 한 건도 발견했지만 부모 프로세스를 추적한 결과 DB가 아니라 GDM 그래픽 로그인 환경과 관련된 프로세스였다. 나는 바로 종료하거나 재부팅하지 않고 DB 서비스와 무관한 관찰 항목으로 기록했다.

Linux 명령 오류를 확인한 뒤 Solaris 환경에 맞춰 다시 만든 서버 점검 스크립트 일부

Linux와 Solaris 스크립트를 모두 직접 검증했다

나는 Linux용과 Solaris용 서버 점검 스크립트를 따로 만들었다. 운영체제마다 명령과 출력 형식이 달랐기 때문에 하나의 스크립트에 억지로 묶는 것보다 두 개로 구분하는 편이 점검 결과를 확인하기 쉬웠다. 두 스크립트 모두 내가 직접 실행하고 결과를 확인한 뒤 실제 점검 업무에 반영했다. 검증은 로컬 확인, 테스트 서버, 운영 서버 순서로 진행했고 각 단계에서 상태 조회만 수행하는지 확인했다.

검증을 마친 버전은 크론에 반영해 매시간 서버 상태를 점검하고 결과를 메일로 받을 수 있도록 구성했다. 디스크 사용률이 기준을 넘거나 좀비 프로세스가 발견되면 결과에는 표시되지만 파일 삭제나 프로세스 종료 같은 조치는 자동으로 실행하지 않았다. 운영 서버에서는 잘못된 자동 조치가 점검 누락보다 더 큰 장애를 만들 수 있다고 생각했기 때문이다. 스크립트는 이상 징후를 빠르게 보여주고, 실제 조치 여부는 내가 결정하는 구조로 남겨뒀다.

자동화로 생긴 시간은 보고서와 업무인계서에 썼다

스크립트를 반영한 뒤 가장 크게 달라진 것은 서버를 확인하는 방법보다 내가 시간을 쓰는 방식이었다. 이전에는 서버마다 접속해 같은 명령을 반복하고 결과를 복사하는 데 시간이 들었다. 이제는 수집된 결과를 먼저 확인하고 평소와 달라진 부분을 찾는 데 시간을 쓸 수 있게 됐다. Linux와 Solaris를 구분하지 않고 기억에 의존하던 점검 방식도 두 개의 스크립트와 검증 기록으로 남았다.

주변에서는 자동화를 프로그램이라고 말했지만, 내가 실제로 한 일은 머릿속에 있던 점검 순서를 밖으로 꺼내놓은 것이었다. 자동화로 확보한 시간은 매달 작성하는 서버 점검보고와 접속기록 점검보고 같은 내부 문서를 정리하는 데 사용했다. 서버 장애 대응 방법과 점검 기준이 내 머릿속에만 있다는 것도 계속 마음에 걸렸다.

그래서 나는 지금 Linux용과 Solaris용 점검 항목, 정상과 주의 기준, 결과 확인 방법을 업무인계서에 옮기고 있다. 다음 담당자가 명령어부터 다시 찾지 않아도 되도록 실제 오류와 판단 과정도 함께 기록할 생각이다. 이번에 만든 두 개의 스크립트는 자동화의 끝이 아니라 내 머릿속에 있던 20년치 업무를 문서로 옮기는 첫 번째 자료가 됐다.