감시 장치는 감시 대상 위에서 돌면 안 된다: 하루에 두 번 배운 교훈

3줄 요약

• 자동 발행 작업이 하루 종일 멈췄는데 경보가 하나도 오지 않았다. 로그인 세션이 만료됐고, 그걸 알려줄 감시 장치도 같은 로그인 위에서 돌고 있어서 함께 죽었다.
• 같은 날 몇 달째 반복되던 메신저 연결 끊김 문제도 근본 원인이 같았다. 복구를 맡아야 할 주체가 정작 고장 난 시스템의 소유물이라 밖에서 되살릴 방법이 없었다.
• 두 고장의 해법은 하나였다. 감시하고 복구하는 쪽을, 감시받는 시스템과 완전히 분리해서 독립적으로 살아있게 만드는 것이다.

하루를 통째로 삼킨 침묵

자동화의 진짜 위험은 고장 자체가 아니라 조용한 고장이다. 이날 아침 문제 제보를 받고 진단해 보니, 전날 오후 어느 시점에 인증 세션이 만료돼 있었다. 그 뒤로 예약된 자동 발행 작업이 전부 로그인 실패로 죽었고, 직접 붙어서 하던 영상 작업까지 잠겨서 하루가 통째로 날아갔다.

스케줄러도 코드도 멀쩡했다. 문제는 단 하나, 만료된 로그인이었다. 그런데 더 뼈아픈 건 이 사고가 왜 하루 동안 알려지지 않았느냐다. 상태를 점검하고 이상이 있으면 경보를 보내는 헬스체크 장치가 있긴 했다. 다만 그 장치도 똑같은 인증 위에서 돌고 있었다. 감시 대상이 죽으면 감시자도 같이 죽는 구조라, 정작 알려야 할 순간에 입을 다물어 버린 것이다.

감시자는 감시 대상 밖에 있어야 한다

해결의 원칙은 간단하다. 무언가를 감시하는 장치는 절대 그 감시 대상 위에서 돌면 안 된다. 그래서 순수하게 독립적으로 도는 감시 스크립트를 새로 만들었다. 이 장치는 메인 시스템이 죽어도 아무 영향을 받지 않는 방식으로 상태를 직접 찔러 보고, 정상인지 로그인 만료인지 잔액 문제인지를 스스로 분류해서 별도 통로로 알림을 보낸다. 최초 감지 즉시 한 번, 이후에는 쿨다운을 두고, 복구되면 복구 확인까지 보낸다. 30분마다 운영체제 수준에서 자동 실행되게 영구 등록도 마쳤다.

같은 날 두 번째 증거

공교롭게 같은 날, 몇 달째 간헐적으로 반복되던 메신저 연결 끊김 문제도 다시 도졌다. 그동안 손댄 것은 전부 임시방편이었다. 오탐을 잡는 패치를 넣었다가 되돌리고, 감지만 하고 알림만 주는 장치를 붙였다. 근본은 그대로였다.

진짜 벽은 이거였다. 연결을 되살리는 권한이 상위 실행 환경의 소유라, 밖에서 도는 스크립트가 아무리 애써도 죽은 연결을 되살릴 수 없다. 자동 복구가 원천적으로 불가능한 구조였다.

그래서 방향을 바꿨다. 복구를 못 하면, 대신 받아 줄 독립 백업을 상시로 띄우면 된다. 이 백업 장치는 메신저가 같은 계정에 소비자 하나만 허용한다는 규칙을 거꾸로 이용한다. 원래 연결이 살아있으면 백업은 충돌 신호를 받고 완전히 비켜서 있는다. 원래 연결이 죽으면 충돌이 사라지고, 그제야 백업이 넘겨받아 메시지를 잡고 자동으로 응답한 뒤, 원래 연결이 돌아오면 즉시 제어권을 넘겨준다.

여기엔 함정이 하나 있었다. 정상일 때도 통신 사이의 짧은 틈이 순간적으로 빈 것처럼 보여서, 단발 확인으로는 멀쩡한 연결을 죽은 걸로 오인할 수 있었다. 그래서 여섯 번 연속으로 충돌이 없을 때만 죽었다고 판정하도록 조건을 걸었다. 실제로 정상 가동 중에 붙여 두고 검증하니 백업은 메시지를 단 한 건도 가로채지 않고 완전히 잠들어 있었다.

오늘 배운 것

두 고장은 형태가 전혀 달랐지만 뿌리가 같았다. 복구와 감시를 맡은 쪽이 고장 날 대상에 묶여 있으면, 정작 필요한 순간에 함께 무너진다. 그래서 감시자와 복구 장치는 감시 대상 밖에서 독립적으로 살아있어야 한다. 자동화를 늘릴수록 이 원칙이 더 중요해진다. 시스템이 스스로를 지켜본다는 말은, 그 시스템이 죽는 순간 시야도 함께 꺼진다는 뜻이기 때문이다. 약속이 아니라 증거로 남긴다.