11/17 국가행정망 마비사태 Part. 01 원인은 무엇인가?

조사부 2023. 11. 20. 13:55

오늘은 11월 17일에 일어난 국가행정망 마비 사태에 대한 이야기를 풀어보려고 한다.

필자는 11월 17일 금요일 출근을 해서 부처 인트라넷에 접속을 시도하였다.
로그인 페이지까지는 잘 나왔지만 인증서로 로그인이 되지를 않았다.

원인이 무엇인지 내부 보안 시스템부터 이곳저곳 알아봤는데
그날 새벽에 국가정보자원관리원(이하 국자원)에서 작업이 있었다는 것이다.

언론의 발표와 동일하게 L4 스위치의 문제가 맞다.

http://www.mediaus.co.kr/news/articleView.html?idxno=307033

초유의 '행정망 먹통'에 소환된 카카오 질책 '내로남불' - 미디어스

[미디어스=송창한 기자] 정부가 행정전산망 먹통 사태가 발생한 지 3일이 지나도록 구체적인 원인을 제시하지 못하고 있다. 백업 시스템은 작동하지 않았다. 불편을 겪는 시민들에게 문자 하나

www.mediaus.co.kr

자 이제 이 이야기를 본격적으로 풀어보려고 한다.
이야기가 너무 방대해서 필자는 3개 파트로 나누어서 이야기를 하려고 한다.

Part. 01 원인은 도대체 무엇인가?
Part. 02 L4 스위치는 뭐 하는 놈인가?
Part. 03 대한민국 IT업계 현실

오늘 포스팅은 Part. 01 원인은 도대체 무엇인가? 내용을 풀어보려고 한다.

필자는 정부기관에서 네트워크와 보안 운영, 관리자로 근무 중이다.
국자원과도 필자 업무와 연관이 되어 있다.
오늘 포스팅은 필자 뇌피셜이 아닌 현장 인맥들을 들은 통해 팩트(Fact)로 작성을 하였다.

Q. 원인은 왜 발생한 것이냐?
A. 새벽에 서비스존 쪽 L4 스위치 OS 업데이트 이후 OS 자체에서 발생한 원인이다.

필자가 국자원에 직접 근무를 한 적은 없지만 들은바 작업에 대한 절차가 상당히 까다롭다.
한번 작업을 하려면 행정 절차가 90%다라고 표현을 할 정도다.

먼저 작업을 진행하기 전에 엔지니어, 작업관리자, 담당 주무관이 작업에 대해서 회의를 한다.
회의에서 결론이 나오면 작업관리자는 엔지니어에게 작업계획서 작성을 지시를 한다.

엔지니어는 작업 내용 그리고 작업의 문제가 발생할 경우 원상복구 시나리오까지 작성해서 관리자에게 제출을 한다.
심지어 작업을 할 때 어떤 명령어를 입력을 할지에 대해서 상세하게 작성을 해야 한다.
관리자가 내용을 확인을 하고 담당 주무관 제출을 하고 주무관 승인 후 주무관이 윗선에 결제를 올린다.

결제가 떨어지면 작업 날짜를 배정을 받는데 그전에 사전 작업 및 작업에 대한 예행연습을 한다.
그리고 서비스와 관련이 있는 정부기관 및 지방자치단체, 산하기관에 공문을 배포를 한다.
바로 이러한 사태가 일어나지 않도록 방지하려는 차원이다.

모든 IT 기기를 작업하는 데 있어서 변수는 존재한다.
그래서 엔지니어들은 꼼꼼하게 변수까지 대비를 하면서 매번 작업을 준비를 하는 것이다.

언론에서 그리고 정치병 환자들 댓글처럼 아무런 생각 없이 작업을 막 하는 것이 아니다.
언론에서 떠드는 것처럼 IT 하드웨어 작업 자체가 그렇게 쉬운 것은 아니다.

아무리 사전에 꼼꼼하게 준비를 하여도 버그(BUG)라는 변수가 발생을 하면 정말 답이 없다.
작업한 명령어는 누가 봐도 문제가 없는데 장비가 오동작을 하면 작업을 하는 엔지니어들 뇌정지 상태가 온다.
현장에서 해결이 안 되면 총판, 벤더사까지 요청을 하는데 버그로 인한 문제는 동일한 버그를 경험한 경험자가 있지 않는
이상 정말 잡기가 힘들다.

정말 하다가 하다가 안되면 벤더사에 Case Open 요청을 하게 되는데 이게 처리가 되는데 짧게는 일주일 길게는 몇 개월이 걸릴 수 있다.

*case open 장비에 저장된 디버그 로그를 바탕으로 제조사에서 장비의 문제를 분석하는 것을 말한다.
일종에 비행기 블랙박스와 같다고 보면 된다.

언론에서는 왜 상세 원인이 무엇인지 발표하지 않는다고 정치적 음모론을 선동을 하려고 하는데
현장에서 Case Open 의뢰가 들어갔다면 어느누구도 상세 원인을 언론에 발표할 수도 없다.
바로 원인을 알 수가 없기 때문이다.

이번 사태의 원인을 알아본 봐로는 위의 내용되로 작업자의 과실은 없었다.
준비한 작업 시나리오 되로 모든 장비를 순차적으로 업데이트를 하였고 업데이트 이후 장비가 말썽을 일으킨 것이다.
바로 OS 즉 펌웨어의 버그가 발생을 한 걸로 추측이 되고 있다.

이번 사태의 상황을 예를 들어 A서버존에 L4 스위치가 이중화 구성이 되었다고 가정을 하자.

1번 장비를 OS업데이트를 하고 제기동을 한다. 서비스에는 이상이 없다.
이유는 2번 장비가 대신 서비스를 하고 있기 때문이다.
보통은 2번 장비 절체 테스트(케이블을 탈거 후 단일화 구성으로 돌리는 테스트)를 해서 서비스를 확인하고는 한다.
절체 테스트를 했는데 서비스가 멀쩡이 잘 돌아가면 엔지니어는 안심을 하고 2번 장비를 업데이트를 진행한다.

필자는 추측을 하는데

아마도 업데이트 이후 모니터링을 몇 시간 하였을 것이다.
서비스가 멀쩡하게 잘 되다가 갑자기 버그가 발동을 해서 말썽을 일으키는 것이다.
이런 경우는 정말 답이 없다. 그냥 눈 뜨고 당한다고 보면 된다.

작업자의 과실로 명령어 오기입이나 명렁어 누락이 발생을 하면 장비에서 바로 나타나기 때문에 이렇게까지 장시간 서비스 마비 상황까지 오지는 않는다.
그리고 이런 문제가 일어날 수가 없는 게 명령어를 사전에 미리 작성을 해두고 여러 사람이 교차로 확인을 하기 때문에
정말 IT 문외한들이 근무를 하지 않는 이상 일어날 수가 없는 일이다.

더군다나 문제가 발생하고 상황을 인지한 엔지니어들은 곳 바로 업데이트를 한 OS를
이전 버전으로 롤백(Rollback)을 하였을 것이다.
이유는 버전을 유지한 체 복구를 하는 것보단 다시 원래 버전으로 돼돌려서 살리는 게 더욱 빠르기 때문이다.
하지만 이런 조치를 했음에도 동일한 증상이 일어났고, 시간은 오전 09시가 지나 전국에 있는 주민센터 및 지방자치단체 기관에서 업무가 마비가 되었고 사태가 이렇게 커진 걸로 본다.

국자원 내부에선 네트워크, 보안, 서버, 애플리케이션까지 전부 이 잡듯이 뒤져서 원인을 최대한 빨리 찾으려고 했을 것이다.
결국 L4 스위치를 다른 벤더사 제품으로 교체를 하니 서비스가 복구가 되었다는 소식을 들었다.

현재까지 알려진 이번 사태의 큰 원인은 엔지니어의 과실도 아니고 시스템을 관리하는 주무관의 과실도 아니고
서비스와 연관이 된 L4 스위치의 펌웨어 문제였던 것이다.
정말 모두가 상상하지 못 했던 원인으로 이 사단이 난 것이다.
알고보니 벤더사 L4스위치......