얼마 전, 프로덕션 가동 중인 가상화 기반에 새 서버 노드를 증설했습니다. 이 작업을 AI 에이전트(Claude)와의 분담으로 진행했기에 그 기록을 남깁니다.

결론부터 말하면 역할 분담은 상당히 깔끔하게 맞아떨어졌습니다. 다만 “AI에 맡겼더니 전부 잘 됐다”는 이야기는 아닙니다. 오히려 그 반대로, 중대한 사고를 막은 판단은 모두 사람 쪽에서 나왔습니다. 그 부분까지 포함해 적습니다.

분담의 실제 #

물리는 사람, 논리는 AI. 거칠게 말하면 이것뿐입니다. 다만 뒤에서 설명하듯 “무엇이 위험한가”를 아는 쪽은 사람이었습니다.

AI가 힘을 발휘한 장면: 손품·반복·대조 #

AI가 확실히 강했던 것은 지루하고, 양이 많고, 틀리면 아픈 작업이었습니다.

1. 버전의 완전 일치 #

기존 클러스터는 전 노드의 버전을 엄격하게 맞추는 방식으로 운용하고 있습니다. 신규 노드는 OS 설치 직후라 패키지가 몇 세대 오래된 상태였습니다.

단순히 “최신으로 업데이트”하면 기존 클러스터보다 새로워져 운용 방침에서 벗어납니다. 그렇다고 특정 버전을 지정하면 의존 관계가 해결되지 않아 설치가 실패합니다.

AI는 에러 메시지에서 원인을 분리해 내고(관련 패키지를 한꺼번에 지정하지 않으면 구버전이 남아 충돌한다 / 원래 이 단계에서 넣어서는 안 될 서버 측 컴포넌트를 끌어들여 막혀 있었다), 기존 노드와 한 치도 다르지 않은 버전 구성으로 착지시켰습니다. 이런 종류의 시행착오는 사람이 하면 집중력이 버티지 못합니다.

2. 전 노드에 걸친 차이 검증 #

증설 후 전 노드에서 공유 스토리지가 보이는 방식이 일치하는지를 한 대씩 확인했습니다. 대수가 늘어날수록 사람 손으로는 “아마 괜찮겠지”로 넘기고 싶어지는 공정입니다.

AI는 전 대수에 같은 명령을 실행하고 표로 만들어 차이를 뽑아내는 작업을 담담하게 해냅니다. 그 결과, 새 노드가 기존 노드와 완전히 같은 상태라는 것을 추측이 아니라 실측으로 확인할 수 있었습니다.

3. “양단”에서의 증적 대조 #

링크 집약(LACP) 확인에서는 서버 측뿐 아니라 스위치 측 상태도 대조했습니다. 특히 서버 측에서 보이는 대향 장치의 식별자가 의도한 스위치의 것과 일치하는지까지 확인하고 있습니다. “링크가 올라왔다”가 아니라 “의도한 상대와, 의도한 설정으로 연결되어 있다”는 것의 증명입니다.

AI가 찾아낸, 수수하지만 위험한 것 #

작업 중 AI가 “지시받지 않았지만 찾아낸” 문제가 몇 가지 있습니다.

부트 순서에 남아 있던 이전 OS의 잔해 #

어떤 노드의 UEFI 부트 순서 맨 앞에 이전에 설치되어 있던 다른 OS의 엔트리가 남아 있었습니다. 실체는 디스크상에 존재하지 않아 기동할 수 없고, 그 뒤로는 네트워크 부트 엔트리가 줄줄이 늘어서 있어 올바른 엔트리는 7번째였습니다.

이대로 재기동하면 존재하지 않는 OS를 찾고, 네트워크 부트의 타임아웃을 하염없이 기다리다, 운이 나쁘면 의도하지 않은 것이 기동하는 상태였습니다. 재기동하기 전에 찾아낼 수 있었던 것은 컸습니다.

시각의 연쇄 장애(이것이 가장 흥미롭습니다) #

다른 노드에서 패키지 업데이트가 전부 실패했습니다. 에러는 “리포지터리 정보가 아직 유효 기간 전(901일 남음)”.

추적해 보니 이런 연쇄였습니다.

1. 하드웨어 클록(RTC)이 1998년을 가리키고 있었다(배터리 소모가 의심됨)
2. OS는 이상으로 판단해 OS 빌드 시점까지 시각을 앞당겼다(＝약 2.5년 전)
3. 시각 동기화는 인터넷상의 NTP 서버를 참조하는 설정이었지만, DNS 설정이 깨져 있었기 때문에 참조 대상을 해석하지 못해 동기화 소스가 0건
4. → 시각이 2.5년 전 그대로 → 패키지 관리 시스템이 리포지터리를 “미래의 서명”으로 간주해 전부 거부

“패키지가 설치되지 않는다”의 진짜 원인이 “DNS가 깨져 있다”인, 4단 뛰기 같은 연쇄입니다. DNS를 고치고 시각 동기화를 재시작했더니 순식간에 해결됐습니다.

게다가 이것은 방치하면 클러스터 참가 후에 영향을 미칩니다. 분산 시스템은 노드 간 시각 어긋남에 민감해서, 2.5년이나 어긋난 노드를 프로덕션 클러스터에 넣는 것은 논외입니다.

설정이 “말없이 실패”하고 있었다 #

네트워크 성능 튜닝을 수행하는 구조가 기동 시점에는 아직 대상이 존재하지 않았기 때문에, 아무것도 하지 않고 정상 종료하고 있었습니다. 에러는 나오지 않습니다. 로그상으로는 성공입니다.

AI는 작업 순서로부터 이를 예측해 확인했고, 실제로 미적용 상태임을 찾아내 재실행했습니다. “성공이라고 표시되지만 실은 아무것도 하지 않았다”는 사람이 눈으로 확인할 때 가장 놓치기 쉬운 부류입니다.

사람이 힘을 발휘한 장면: 이것이 본질 #

여기서부터가 본론입니다. 이번에 치명적인 사고를 막은 판단은 두 가지 모두 사람 쪽에서 나왔습니다.

1. “연계용 파일 배치가 빠져 있다” #

AI는 작업 항목을 정리하고 있었지만, 외부 시스템과의 연계에 필요한 파일 배치를 “마지막에 하는 공정”으로 분류하고 있었습니다. 실제로는 그 공정 중 그 파일 배치만큼은 먼저 해도 문제가 없고, 오히려 먼저 해야 하는 것이었습니다.

사람 쪽에서 “빠져 있다”고 지적받고 나서야 AI는 비로소 자신의 분류 실수를 알아차렸습니다. 지적이 없었다면 후반 공정에서 발이 걸렸을 것입니다.

2. “스토리지 측 등록이 먼저다. 보이는 방식이 뒤죽박죽이 된다” #

이것이 가장 큽니다.

AI는 참가 전 체크로 버전·네트워크·시각 등을 나열하고 “준비 완료”라고 판단하고 있었습니다. 그러나 거기에 스토리지 장치 측의 액세스 허가 등록이 들어 있지 않았습니다.

사람 쪽에서 “등록 전에 참가시키면 공유 스토리지가 보이는 방식이 노드마다 뒤죽박죽이 되어 심각한 불일치를 일으킬 수 있다”는 지적이 들어옵니다.

AI가 조사해 보니 과거에 완전히 같은 현상이 발생한 기록이 사내에 남아 있었습니다. 한 대만 스토리지를 인식하고 나머지는 인식하지 못하는 상태가 되어, 다른 노드를 재기동했더니 무관한 노드까지 휘말려 재기동되는 현상입니다.

지적이 없었다면 AI는 깔끔하게 정돈된 검증 결과를 늘어놓은 채로, 그대로 사고로 돌진했을 것입니다.

결과적으로 사전에 액세스 허가를 등록하고, 참가 전에 “새 노드에서 보이는 스토리지 목록이 기존 노드와 완전히 일치하는지”를 비파괴로 실측한 뒤 참가시켜, 사고 제로로 완료했습니다.

이 두 가지에 공통되는 것은 “경험에서 오는 위기감”입니다. AI는 눈앞의 정보로부터 정합적인 결론을 내지만, “그 항목이 애초에 목록에 없다”는 것은 알아차리지 못합니다. 무엇이 목록에 올라야 하는지를 아는 것은 호되게 당해 본 적이 있는 사람 쪽이었습니다.

AI가 틀린 것(숨기지 않고 적습니다) #

공평을 기하기 위해 AI의 실패도 나열합니다. 이것을 적지 않는 사례 소개는 믿지 않는 편이 좋습니다.

• 절차서에 잘못된 순서를 적고, 그대로 실제 장비에 가지고 갔다. 설정 투입 순서를 반대로 기재해 두었고, 실제 장비에서 에러가 나고서야 비로소 발각. 다행히 통신에 영향이 없는 공정이었기 때문에 실질적인 피해는 없음
• 검증했다고 여겼지만 검증하지 않았다. 설정의 사전 체크가 에러를 반환하고 있었는데도, 스크립트 작성 방식이 잘못돼 “OK”라고 표시하고 있었다. 나중에 스스로 신고해 수정
• 문제가 아닌 것을 문제라고 소란을 피웠다. 한 대와만 비교하고 “설정이 어긋나 있다”고 보고. 전 대수를 조사해 보니 오히려 새 노드 쪽이 옳았다
• 명백히 상태가 이상해져, 사람에게 제지당했다. 작업 중 AI가 문맥과 무관한 화제에 반응해 탈선하는 현상이 발생. 사람 쪽이 이상을 감지해 작업을 전면 중단시키고, 상태를 확인한 뒤 재개하고 있다

마지막 한 가지는 특히 중요합니다. AI는 자신의 이상을 스스로 감지할 수 없습니다. “뭔가 이상하다”고 느끼면 멈출 수 있는 사람이 프로덕션 작업에는 반드시 필요합니다.

배움: 분업을 어떻게 설계할 것인가 #

이번에 잘 진행된 이유를 정리하면 이렇게 됩니다.

AI에 맡기길 잘한 것 #

• 반복·대조·전수 확인(사람이 “아마 괜찮겠지”로 건너뛰고 싶어지는 공정)
• 시행착오가 필요한 의존 관계의 해결
• 증적을 남기면서 하는 검증
• 작업 내용의 절차서 반영(한 직후에 쓸 수 있으므로 낡지 않는다)

사람이 쥐고 있어야 할 것 #

• 무엇을 목록에 올릴 것인가(AI는 목록에 없는 항목은 알아차리지 못한다)
• 과거 사고의 기억에 근거한 리스크 지적
• 멈추는 판단
• 물리 작업(당연하지만)

그리고 양쪽 모두에 공통으로 효과가 있었던 것이 “작게 실행하고, 그때마다 실측한다”는 진행 방식이었습니다. 한 대씩, 한 공정씩, 변경할 때마다 실측으로 확인한다. 이 틀이 있었기 때문에 AI의 오류도, 사람의 간과도 상처가 얕을 때 찾아낼 수 있었습니다.

맺으며 #

“AI가 인프라를 구축했다”고 하면 사람은 지시만 내리고 앉아 있는 그림을 상상할지도 모르지만, 실제는 달랐습니다.

AI는 사람이 집중력을 잃는 영역에서 압도적으로 강하다. 사람은 AI가 구조적으로 알아차릴 수 없는 영역에서 결정적으로 강하다. 그 둘이 맞물렸을 때, 한쪽만으로는 도달할 수 없는 품질이 됩니다.

그리고 AI를 프로덕션 환경에 투입한다면, 멈출 수 있는 사람이 필요합니다. 이번에 그것이 기능했다는 점이 이 사례에서 가장 공유하고 싶은 부분입니다.