[디지털데일리 백지영기자] 방역패스 첫날이었던 13일 질병관리청이 운영하는 코로나19 전자예방접종증명서 앱 ‘쿠브(COOV)’에 시스템 과부하가 발생하면서 사용자들이 큰 불편을 겪었다. 결국 질병관리청은 이날 하루 방역패스 적용을 하지 않기로 결정하고, 방역패스 위반 사례에 대해서도 과태료도 부과하지 않기로 했다.
하지만 이날 시스템 장애와 관련, 난데없이 ‘KT 클라우드’에 불똥이 튀었다. 질병관리청이 이날 시스템 장애 원인에 대해 해명하는 과정에서 “쿠브 서버가 위치한 KT DS 클라우드센터에서 접속부하로 인해 원활하게 처리되지 않은 것으로 파악했다”고 말했기 때문이다.
실제 쿠브 앱이 현재 KT 클라우드 인프라에서 운영되는 것은 사실이다. KT는 지난해 9월부터 자사의 공공기관 전용 클라우드 서비스인 ‘G-클라우드’에서 질병관리청의 코로나19 정보관리시스템과 쿠브 앱을 운영 중이다. 다만 클라우드 인프라 구축과 서비스 관리는 그룹사인 KT DS가 담당하고 있다.
때문에 질병관리청이 ‘KT DS 클라우드센터’를 거론한 것도 무리는 아니다. 하지만 이번 장애가 마치 클라우드 서비스에 장애가 발생한 것처럼 표현되면서 KT로써는 때 아닌 곤혹을 겪었다.
클라우드 업계는 이번 시스템 장애를 애플리케이션 자체의 문제로 보고 있다. 쿠브 애플리케이션 설계 자체가 클라우드 환경에 최적화돼 있지 않기 때문에 생겨난 문제라는 것이다.
클라우드 서비스는 일반적으로 사용량이 증가할 경우, 자동 확장(오토스케일링) 등의 기능을 통해 필요한 IT 자원을 신속하게 늘릴 수 있는 것으로 알려져 긴급 상황에도 빠른 대처가 가능한 것으로 알려져 있다.
하지만 이같은 기능을 사용하기 위해선 앱을 클라우드 환경에 맞게 재설계하는 것이 필요하다. 또, 웹/WAS(웹애플리케이션서버) 문제라기보다 데이터베이스(DB)에 문제가 있었을 것으로 추측하고 있다.
질병관리청도 이날 KT DS의 서버 운영과 관련해 문제가 있었던 것처럼 보도되자 정정에 나서기도 했다. 질병관리청 관계자는 “KT DS 클라우드센터에서 서버 운영 상 문제가 발생했다는 뜻은 아니었다”며 “KT는 질병청 요청에 의해 서버 증설 규모 등을 제안받아 수행하는 역할을 한다”고 선을 그었다.
질병관리청은 이어 보도참고자료를 내고 “방역패스 시행에 대비해 쿠브 앱 관련 서버 증설 등 사전 조치를 했음에도 전자예방접종증명서의 실시간 대량 인증처리 장애 등 과부하 대응에 미흡한 점이 있었다”며 “시스템 오류로 불편을 드려 죄송하고, 대량인증 절차 효율화 등 긴급 개선작업을 진행 중”이라고 밝혔다.
또 다른 클라우드 업계 관계자는 “질병관리청의 수요 예측 실패에 무게를 두는 것이 맞을 것 같다”면서도 “다만 개인정보 등 민감한 의료정보가 담긴 DB 서버를 클라우드 환경에서 운영했을까 하는 의문도 든다”고 말했다.
그는 “보통 클라우드 환경에서 웹, WAS 등 프론트엔드 서버들은 스케일아웃을 통해 원활하게 확장이 되지만, 만약 로드밸런싱 없이 단일 서버에서 DB를 운영했다면 트래픽 부하 발생 시 성능 제약이 발생할 수도 있다”며 “DB에 접종증명을 요청하는 메시지Q가 쌓이면서 부하가 발생할 수도 있었을 것”이라고 추정했다.
<업데이트>
내부 사정에 정통한 한 업체 관계자는 이번 장애 원인과 관련해 "NGINX(프록시 서버) 설계 오류에 따른 것"이라며 "앱 재설계를 통해 용량을 증설해 일단 해결된 것으로 안다"고 설명했다.