[심스키의 입장] 백신 예약시스템, 클라우드였다면…
아마 대한민국 50대는 요며칠 컴퓨터나 스마트폰 화면을 쳐다보면서 하염없이 기다려본 이들이 많을 것입니다. 누군가는 한참 기다리다가 뻗어버린 사이트로 인해 폭발하기도 했겠죠. 코로나19 백신 예방접종 사전예약 시스템 이야기입니다.
지난 12일부터 질병청은 50대를 대상으로 코로나19 예방접종 예약을 받고 있습니다. 정부가 준비한 예약 사이트에 접속해 간단한 정보를 입력하고 클릭 몇 번만 하면 예약이 완료되는 구상이었습니다. 그러나 정부의 구상대로 진행지 않았죠. 한꺼번에 몰려든 이용자들로 인해 서버는 버티지 못했고, 정부는 연일 언론과 시민들로부터 질타를 받고 있습니다.
현재 백신 예약은 두 단계를 거칩니다. 예약 사이트에 입장을 해서 대기표를 뽑고, 자신의 순서가 되면 예약 시스템에 들어가 예약을 하는 방식입니다.
대기표를 발급하는 솔루션은 STC랩의 ‘넷퍼넬’이라는 제품이 이용됐습니다. 넷퍼넬은 네이버 클라우드 위에서 구동됩니다. 그런데 50대 백신 예약이 시작되자마자 문제가 발생했습니다. 예상보다 많은 인원이 갑자기 몰려 대기표 뽑는 것조차 어려웠습니다. 은행 지점으로 비유하자면 대기표 뽑는 줄이 길게 늘어서서 들어가지도 못하는 형국입니다.
하지만 이 문제는 금방 해결되었습니다. 네이버 클라우드는 4대로 운영하던 넷퍼넬용 클라우드 서버를 10대 더 늘렸습니다. 클라우드 상의 서버는 클릭 몇 번으로 쉽게 늘리고 줄일 수 있습니다. 그러자 대기표가 뽑히지 않는 문제는 없어졌습니다. 이처럼 갑작스러운 사용자 증가에 빠르게 대처할 수 있다는 점은 클라우드의 최대 장점입니다.
하지만 대기표만 뽑는 건 의미가 없죠. 대기표를 뽑았으면 순서대로 들어가야죠. 하지만 이번에는 아무리 기다려도 예약시스템에 들어갈 수 없는 경우가 다수 발생했습니다. 백신 사전예약은 질병청이 운영하는 ‘예방접종등록관리 정보시스템’의 기능인데, 클라우드가 아닌 IDC 물리 서버에 존재하기 때문입니다.
코로나19 백신 예방접종시스템은 기존의 예방접종등록관리 정보시스템을 기반으로 그 위에 필요한 몇가지 기능을 추가한 시스템입니다. 예방접종등록관리 정보시스템은 지난 2002년 처음 개발돼 유지보수와 업그레이드를 거듭해가며 지금까지 활용되고 있습니다.
접종 사전예약 오류는 예약 시점에 신청자가 한꺼번에 몰리면서 시스템에 과부하가 걸려 발생했습니다. 코로나19 예방접종대응추진단(이하 추진단)은 22일 참고자료를 통해 “사전예약 시스템은 기존 국가예방접종시스템을 확대 개편하는 방식으로 개발해 운영하고 있다”며 “서버의 경우 부족한 처리량을 보완하기 위해 단기 임차·증설을 통해 처리량을 증대하는 방식으로 확충하고 있다”고 설명했습니다.
이를 종합하면 이번 사태는 클라우드의 부재로 인해 발생한 사달이라고 볼 수 있습니다. 예방접종등록관리 정보시스템이 클라우드 위에 구축돼 있었다면 서버 과부하로 인한 문제는 어렵지 않게 해결할 수 있었을 것입니다. 대기표 시스템에 부하가 걸렸을 때 네이버 클라우드에서 운영되는 서버 10대를 손쉽게 추가한 것처럼 말입니다.
그러나 오래된 정보시스템에 기능만 추가하는 방식으로 만들어진 코로나19 백신접종시스템은 서버를 증설하는 것이 쉽지 않습니다. 물리 서버는 구매도 오래걸리고 구축도 오래걸립니다.
지난 해 코로나19로 인한 온라인 수업이 처음 시행됐을 때도 EBS 온라인클래스나 한국교육학술정보원의 e학습터에 과부하가 걸려 시스템 접속이 안되는 문제가 발생했었습니다. 그러나 두 서비스는 모두 마이크로소프트 애저와 네이버 클라우드라는 클라우드 위에 구현돼 있었기 때문에 빠르게 서버를 증설해 문제를 해결할 수 있었습니다.
흔히 IT에 대한 투자는 비용이라고 생각합니다. 오래됐지만 기왕에 예방접종등록관리 정보시스템이 있으니 기능 조금 더해서 코로나19 백신 예방접종시스템을 만들면 혈세를 아낄 수 있을 것이라고 생각했을 것입니다.
하지만 오래되고 유연하지 못한 IT시스템으로 인해 결국 대통령까지 나서서 사과해야 하는 사태를 만들어 내고야 말았습니다.
<심재석 기자>shimsky@byline.network
이번 기사는 조금 실망 스럽습니다.
시스템엔지니어로써 이런 폭증하는 시스템 구성은 말만큼 쉽지 않습니다.
클라우드를 이용했더라도 별반 차이는 없습니다.
단순 서버만 증설한다고 해결되는 문제가 아닙니다.
이건 디비 부하지 웹서버 부하가 아닙니다.
최초 구축시 이런 상황에 대비해서 구축된 시스템이 아니기에 갑자기 변경하는건 사실상 불가능하죠.
개발도 새로 해야 하고 시스템도 새로 구축되어야 합니다.
분산 시스템으로 개발을 다시 수정하는게 더 오래걸립니다.
구성 방법에 따라 달라질 수는 있겠지만 구축의 핵심은 디비 분산 및 큐 시스템이 얼마나 제대로 동작하느냐입니다.
클라우드는 서버 추가가 용이한거지 성능까지 올려주진 않습니다.
클라우드가 만능인양 홍보하는 이런 기사들 때문에 실무자들은 더 힘듭니다.
안녕하세요. 좋은 답글 감사드립니다.
다만 기사의 논지는 갑자기 변경해야 한다는 것이 아니라 코로나19 백신 예방접종 시스템을 개발할 때 2002년 처음 개발된 예방접종등록관리 정보시스템에 기능을 추가하는 방식으로 개발하지 않고, 새롭게 클라우드 위에서 (당연히 분산환경으로) 만들었다면 이용자 폭증에 대비할 수 있었을 것이라는 데 있습니다.
감사합니다.