접속장애가 일으킨 소통장애… 명령 내리는 지휘자 역할 중요

‘전산 장애’는 당사자에게는 피가 마르는 일이다. 상황의 불편과 좌절을 처리하는 일은 직장생활에서 빠질 수 없는 일이지만, IT는 그 불편과 좌절의 총량을 접속자수만큼 늘려 준다. 몇십, 몇백 명이 불편해도 초조한데 수십만, 수백만 사용자가 쓰는 시스템에서의 장애란 ‘공황’의 격이 다르다.

사내 시스템의 경우야 욕 한번 먹고 말면 그만이지만 대고객 서비스의 경우 잠재고객들은 지체 없이 이탈한다. 쇼핑몰이라면 다운타임(시스템 정지시간)은 매출 손실로 분 단위로 계산된다. 장애에 대응하려 하면 손이 떨리지 않을 수 없고, 우왕좌왕하다가 더 큰 실수를 하기도 한다. 소송문화가 발달한 미국에서는 심각한 장애 뒤에는 집단소송이 뒤따르곤 한다. 점점 더 많은 사업 활동이 온라인이 되고 있는 지금, 전산시스템이 뻗어버리는 일은 영업정지 이상의 절체절명 일이다.

장애는 매출손실, 고객이탈과 같은 쓰라린 영업적 손해뿐 아니라 조직적 치부도 드러낸다. 누가 무엇을 잘못했는지를 두고 책임 소재를 따지는 데 급급한 퇴행적 문화가 피어난다. 운영팀이 보기에는 소프트웨어 개발에 문제가 있고, 개발자가 보기에는 운영 경험 부족이 눈에 들어온다. 기술 문외한이 보기에는 모두 실력이 없어 보이고, 기술자가 보기엔 예산도 인력도 확보하지 않은 채 욕심에 눈이 먼 프로젝트의 ‘말로’다. 그렇게 조직은 산으로 간다. 시스템을 둘러싼 이와 같은 부조리극은 경중의 차이는 있겠지만 매일 어딘가에서 벌어지고 있다. 지난 4월 9일과 16일, 17일의 EBS 접속 장애는 국민적 뉴스가 됐다. 사건 전 교육부는 온라인 개학을 대비, 서버 용량을 증설해 EBS 온라인 클래스와 e학습터 모두 제각각 300만 명이 동시에 접속 가능하다고 밝힌 바 있다. 언론은 이 두 서비스의 클라우드 공급업체인 마이크로소프트와 네이버가 맞대결하게 되었다며 흥분했다. EBS 사이트에 문제가 생기자 정부는 직접 마이크로소프트와 통신망 제공자인 SKB에게 사유 해명을 요구했다는 후문이다.

마치 배달 온 주방 냉장고의 용량이 주문한 것과 다르다고 따지는 풍경이다. 온라인 서비스를 둘러싼 대개의 사건은 소프트웨어적인 문제다. 달리 말하면 같은 장비와 회선을 가지고도 다른 누군가가 코드를 다르게 짜거나 설정했거나 설치했다면 벌어지지 않는다.

한 가지 희망이 있다면 그런 인간적 차이는 소프트웨어에 의해 대체될 수 있다는 점이다. 근래 유행인 데브옵스(DevOps) 또는 SRE(Site Reliability Engineering)라 불리는 IT 업무 분야다. 국내에서 전산은 SI(시스템 통합)가 외주로 만든 업무를 SM(시스템 관리)에게 던져 주고 운영하는 것이 오랜 관례였다. 쌍방의 전문성은 엄연히 다르다는 전제의 관행이었다.

하지만 만약 운영과 관리라는 인간적 업무조차 코딩해버려 플랫폼으로 만들어낼 수 있다면, 즉 데브옵스가 이뤄진다면 그 차이는 희석된다. 업무를 만들고, 이를 기계에 설치·배포하고, 관리·감독하는 일을 자동화하여, 개발 당사자가 버튼 몇 번 명령어 몇 줄로 셀프로 처리해 버린다. 그리고 그 절차를 경영을 포함한 이해당사자에게 자동으로 공개한다. 모든 과정이 투명해져 모두가 당사자가 되고 모두의 책임이 되니 일단 서로 손가락질하는 문화만큼은 사라진다.

요즈음 서버는 성능이 좋아져서 기계 한 대를 들이면 그 안에서 여러 대의 ‘가상머신(VM)’이 공존한다. 그 가상머신 속 업무 코드들은 자기가 서버 하나를 통째로 쓰고 있다고 믿는다. 클라우드란 원래 이런 착각을 임대하는 일이었다. 최근 트렌드는 그렇게 제각각 가상머신을 만들어 쓰는 것조차 낭비가 심하니, 서버 자체의 운영체제 공통부분을 읽기 전용으로 공유하고 구획을 나눠줘 업무 코드들이 자기가 별도의 서버에 있다고 착각하게 만드는 기술인 ‘컨테이너’다. 가상머신은 수십 GB의 자기만의 별도 공간이 있어야 하지만, 컨테이너는 개당 수십~수백 MB면 충분하고 가상화를 거치지 않은 경우가 많으니 속도도 더 빠르다. 일반적으로 요즈음 구매할 수 있는 PC사양(16GB 메모리)에서도 이론상 컨테이너 500개나 만들 수 있다. 이때 500개를 하나하나 설치하고 있을 수는 없다. 이를 지휘하듯 통제하는 소프트웨어 ‘오케스트레이터’는 수백, 수천의 컨테이너들을 전산실뿐만 아니라 세계 곳곳 데이터센터에 걸쳐 수시로 만들고 복제하고 지우며 자동으로 관리한다.

무한대의 자원을 쓸 수 있는 이상적인 세계에서는 원하는 만큼의 기계와 회선을 총동원할 수 있을 것이다. 하지만 이 모든 것은 비용이다. 수요에 따라 오케스트레이터가 필요한 만큼의 컨테이너를 자동으로 준비하고, 수요가 꺼지면 반납한다. 수요에 반응하여 용량을 제공하는 일은 클라우드업계에서는 자동확장(AutoScale) 기능이라 부르는데, 넷플릭스의 경우 과거 데이터로부터 수요를 선제적으로 예측해 사전에 확보하는 자동확장 엔진을 만들어 오픈소스로 공개하기도 했다. 서버 운영 노하우도 코딩될 수 있는 셈이다.

즉 주인에 따라 기계 한 대가 500대로 둔갑하기도 하고, 정말 500대를 다 사다 줘도 자동으로 ‘지휘’해내지 못한다면 499대는 놀고 있을 수도 있다. 클라우드를 고려한 프로그래밍이 안 되어 있을 수도 있고, 예상치 못한 설정 오류로 병목이 발생했을 수도 있다. 컨테이너를 언제 어떻게 얼마나 생성할지의 명령을 내리는 일은 이용 회사의 몫이다. 사업을 지속하게 하고 또 비용을 줄이는 데 사내의 클라우드 지휘자의 역할은 이처럼 크다. 클라우드 업자는 통신업자처럼 컨테이너든 가상머신이든 생성 의뢰한 만큼만 명랑하게 요금을 받아갈 뿐, 애초에 지휘를 대행할 생각은 없다. 별도의 계약이나 사정이 있다면 모를까. 그런데 어른들의 세계에서 세상일은 다르게 돌아가기도 한다. 대안이 널려 있는 시장이라면 단 한 번의 접속장애도 치명적일 수 있다. 하지만 탄탄한 브랜드가 있거나, 대체재가 별로 없는 경우라면 나쁜 뉴스조차도 유명세를 더해 전화위복이 되기도 한다. 되살아난 사이트는 “아, 난관을 뚫고 이렇게 열심히 시도한 우리!”라는 이미지마저 남길 수 있다. 완벽하기만 하면 그 소중함을 모르니, 적당히 아슬아슬한 일이 벌어져 노력하고 수습하는 모습을 보이는 편이 멋진 스토리가 될 때도 있다.

미국 밀레니엄 세대에게 사랑받던 수수료 무료 주식거래앱 로빈후드는 지난 3월, 17시간이나 거래 불능 사태에 빠졌다. 폭락 끝에 모처럼 반등하던 날 벌어진 일인 데다가 사용자 수는 천만 명. 대형 사고였다. 하지만 그 후 이 앱의 가치평가는 80억 달러로 오히려 올랐고, 2억5000만 달러의 추가 자본 조달을 진행 중이다. “얼마나 인기가 많으면 사이트가 뻗었겠느냐”며 인프라 확충용 자본을 투입하고 있는 것이다.

이번 EBS 온라인클래스도 국민적 관심을 모으고 있는 서비스. 준비 상태와는 무관하게 저지르고 보면 어떻게든 수습되리라 믿었을 것 같기도 하다. IT가 본업도 아니었고 어차피 개발도 외주. 어떻게든 하청을 동원하고 업자들을 불러대면 해결될 일이라 여겼을 수도 있다. 각종 업자들도 이 국난에서 문제 해결의 주역으로 이름을 알리기에 절호의 찬스이기에 상당히 잘 서비스해줬을 것이다.

하지만 평범한 보통 기업은 한 번의 장애로도 망할 수도 있으니, 데브옵스와 SRE를 내재화한 조직문화를 만들어 온라인 사업의 영속성을 지키도록 하자.



※ 필자는 소프트웨어 엔지니어 겸 IT평론가다. IBM, 마이크로소프트를 거쳐 IT 자문 기업 에디토이를 설립해 대표로 있다. 정치·경제·사회가 당면한 변화를 주로 해설한다. 저서로 [IT레볼루션] [오프라인의 귀환] [우리에게 IT란 무엇인가] 등이 있다.

ⓒ이코노미스트(https://economist.co.kr) '내일을 위한 경제뉴스 이코노미스트' 무단 전재 및 재배포 금지