중요한 것은 '무엇'이 아닌 '어떻게'
한 때 유행 따라 로봇청소기를 산 적이 있었다. 가끔 집안청소가 필요할 때 작동을 시켜봤는데 성능이 내가 생각했던 것보다 기대이하였다. 외출했다 돌아오면 거실 구석에서 버벅거리고 있기도 하고 열린 현관문 밖으로 탈출을 시도하기도 했다. 이럴 거면 그냥 내가 손으로 청소기를 돌리는 게 낫겠다 싶었다.
그러던 어느날 친구집에 놀러 갔는데 이놈이 로봇청소기 때문에 삶의 질이 달라졌다고 하는 게 아닌가. 내가 쓰는 모델보다 성능도 더 낮은 편에 속하는 모델이었는데도 전혀 다른 반응인 게 신기해서 물어보니 친구는 나에게 로봇청소기에 대한 팁 몇 개를 알려주었다. 청소기의 이동 동선을 방해하지 않게 바닥은 적당히 정리를 해야 하고 물 보충은 어떻게 하는지 등등.. 모두 기본적인 것들이었다. 그때 느꼈다. 중요한 것은 '무엇'을 쓰냐가 아니라 '어떻게' 쓰느냐 인 것을.
여러 크고 작은 기업에 텐센트클라우드를 소개하고 도입을 도와주는 역할을 하는 필자는 클라우드에 대한 다양한 생각을 가진 고객들을 만나게 된다. 대부분 자체 엔지니어들이 깊은 클라우드 지식을 가지고 있는 경우가 많았고 일부 클라우드가 익숙하지 않은 고객들도 잘 정리된 공식문서와 몇 번의 커뮤니케이션을 통해 기존 서비스 환경을 유지하는데 큰 어려움을 겪지 않았다. 그러나 몇몇 기업들은 그들의 서비스의 규모와는 달리 클라우드에 대한 무지와 막연한 불신을 가지고 있기도 했다. 기업의 비즈니스 규모와 구성원의 기술적인 성숙도가 클라우드에도 똑같이 적용되는 것은 아닌 듯했다.
클라우드로 서비스 운영을 해본 경험이 없거나 이미 온프레미스 환경에 익숙한 기업들이 클라우드 도입을 시도할 때, 클라우드의 장점을 살리지 못하는 방향으로 사용을 진행하는 경우가 더러 있다. 이 글을 통해 필자가 만나 본 기업들의 사례를 기반으로 몇 가지를 소개하려고 한다. 이름하여 '클라우드를 클라우드답게 사용하기 위해 피해야 할 몇 가지'. 물론 대부분의 기업들에겐 해당되지 않는 IT의 기본 공리조차 간과한 이야기 같겠지만 이들 중 놀랍게도 이름만 들으면 누구나 알만한 기업에게서 얻은 사례도 있다.
이 글을 읽는 사람들에게 괜히 불안한 마음에 덧붙이자면 아래에 소개할 괴담 같은 것들이 실제로 일어나고 있는 원인은 MSP의 역량부족이나 고객사의 기술적 수준과는 전혀 관계가 없다. 이들은 몰라서 이러는 게 아니고 그냥 이렇게 쓴다.
1. VPC 설계에 관심이 없다
VPC는 클라우드에서 논리적으로 격리된 가상네트워크 환경으로 클라우드 아키텍처의 기본이 되는 개념이다. 고객들은 자체 서비스 워크로드에 맞게 VPC를 생성하고 그 안에 수많은 서브넷과 보안그룹, ACL 설정을 통해 그들만의 네트워크 환경을 구축한다.
그런데 일부 고객사들은 이러한 VPC설정을 쿨하게 생략한다. 다시 한번 말하지만 그들은 몰라서 그러는 게 아니다. 그들은 서비스 지역의 리전과 가용영역 정도만 고려할 뿐 나머지 설정은 default에 맡긴다. 기본 보안그룹에서 열려있지 않은 포트들을 열기 위해 보안그룹 설정을 건드리는 최소한의 작업만 진행할 뿐이다.
어떤 고객은 1개의 텐센트클라우드 계정에 1개의 VPC, 1개의 서브넷에 수십 개의 CVM을 몰아넣고 사용하기도 한다. 심지어 데이터베이스도 퍼블릭 서브넷에 두고 퍼블릭 IP를 이용해서 서버와 통신하는 매우 열린 마음의 고객들도 있다.
물론 이런 유형의 고객들은 대부분 자체 서비스를 운영하기보다 브랜드의 의뢰를 받아 간단한 웹 사이트나 위챗 미니프로그램 개발을 대행하는 SI 업체에 집중되어 있는 편이다.
일단 서비스 규모가 작기도 하고 1년 단위로 계약이 바뀌기도 하니 일단 빠르게 만들고 넘기기 위해 개발팀에 퍼블릭 IP만 던져주는 방식을 선호하기 때문. 의뢰하는 브랜드 입장에서도 자체 내부망을 타거나 고객 데이터베이스에 접근하지 않는 외주 서비스의 경우 크게 이런 부분에 신경을 안 쓰기도 하고 결과물을 평가할 때 겉으로 보이는 완성도나 웹 사이트 접속 속도 같은 지표들만 통과범위 안에 든다면 서로 딱히 문제 될 것은 없으니 더욱 그렇다.
이에 대해 MSP 입장에서도 고객사의 별다른 요청이 없는데 계속 계정을 모니터링해가며 VPC 아키텍처에 관해 이래라저래라 하는 것도 사실상 불가능한 일이고 그 누구도 아무런 불편을 겪지 않으니 오히려 모두에게 해피엔딩이라고 봐야 할까.
2. 종량제 요금에 대한 두려움이 있다
필자가 클라우드의 대표적 장점 중 하나라고 생각하는 것이 바로 오토 스케일링이다. 이를 통해 고객사들은 불규칙적인 트래픽에 대응하여 자원을 효율적으로 활용할 수 있다. 이에 뒤 따라오는 비용절감 효과는 덤이다. 그런데 일부 고객사는 스케일링 도입을 꺼린다. 서비스의 트래픽 패턴이 딱 스케일링에 부합하는 경우인데도 말이다.
그 이유는 역설적이게도 탄력적인 비용에 있다. 그들은 트래픽을 제외한 부분에서 고정적인 비용 지출을 하는 것에 익숙하기 때문에 비용이 싸든 적든 고정적인 비용을 내길 원한다. 같은 이유로 쓰는 만큼 비용을 지출하는 종량제 요금제(Pay-as-you-go)에 대해서도 회의적이다. 자원 활용을 실제 트래픽에 맞춰서 설정하고, 적게 쓰면 적게 내고 많이 쓰면 많이 내는 과금 모델이 그들에게는 예상치 못한 요금폭탄의 이미지로 다가오는 것 같다. (그렇다고 해서 약정모델에 대한 선호도가 높은 것도 아니다.)
그래서 이런 유형의 고객들이 필자에게 가장 많이 묻는 말이 '그래서 한 달에 얼마예요?'다. 이 질문을 하는 고객들의 머릿속에는 이미 유연함을 필두로 한 클라우드의 장점들은 사라지고 견적서에 찍힌 고정가격만 남는다. 사실상 일반 웹 호스팅과 차이가 없어지게 되는 것이다.
3. CAM 설정에 소극적이다
텐센트클라우드의 CAM(Cloud Access Management)은 사용자의 클라우드 리소스에 대한 액세스를 관리하고 제어하는 서비스로 CAM을 통해 사용자는 다양한 리소스에 대한 액세스 권한을 정밀하게 설정할 수 있고 이는 클라우드 보안에 있어서 가장 첫 번째 단계라고 할 수 있다. AWS의 동일한 서비스인 IAM을 예로 들어서 'AWS는 IAM에서 시작해서 IAM으로 끝난다'는 말이 있을 정도다.
'아무도 믿지 않는다'는 제로트러스트 보안 원칙에 따라 모든 텐센트클라우드 접근 사용자는 그들이 조작하려는 리소스에 대한 최소한의 권한만 가져야 한다. 서비스의 규모에 따라 계정 내에 다양한 리소스가 생성되고 관련 있는 여러 부서 구성원의 콘솔 접근이 필요한 경우가 있는데 이에 대한 그림을 그리고 적절한 정책을 가진 서브 어카운트를 생성하여 관리하는 것도 기업의 클라우드 운영능력을 평가하는 데 있어서 중요한 지표라고 할 수 있을 것이다.
그런데 일부 고객사는 별도의 CAM 설정 없이 루트 계정 하나만으로 모든 조직 구성원이 돌려서 사용하는 경우가 있다. 여러 사람이 삼삼오오 모여 각자 숟가락으로 찌개 하나를 공유하는 과거 '한국인의 정'을 클라우드화 하는것이 목적이라면 모르겠지만 대단히 위험한 운영방식이다. 콘솔 루트계정은 콘솔에 대한 모든 제어권한을 가지고 있기 때문이다.
그럴리는 없겠지만 누군가 악의적인 의도로 루트계정에 접근한다면 서비스를 강제로 중단시킬 수도 있고 의도하지 않은 리소스를 대량으로 구매해서 요금 폭탄을 날릴 수도 있다. 이런 경우 웃는 곳은 단 한 곳밖에 없으니 고객사 입장에서는 반드시 개선해야 한다.
4. 완전 관리형 상품을 막연히 기피한다
텐센트클라우드에는 TencentDB나 TKE와 같은 완전관리형 PaaS 상품들이 있다. OS단에 대한 관리와, 업그레이드 및 패치 작업을 텐센트클라우드에 일임하므로, 사용자는 시스템 유지 관리에 대한 걱정 없이 비즈니스 애플리케이션에 집중할 수 있는 서비스라 할 수 있겠다.
데이터베이스를 기준으로 보면, 보통 소규모 워크로드를 보유한 고객사에서는 자체서버나 CVM에 DB를 직접 설치해서 사용하는 방법을 선호한다. 익숙하기도 하고 가격 측면에서도 저렴한 것이 당연하기 때문이다. 따라서 일부 고객사들은 이러한 완전관리형 PaaS상품의 도입을 공연히 기피하는 경향이 있다. 원인은 당연히 가격에만 존재한다. 고객들이 머신 위에 직접 세팅하는 것에 비해 완전관리형 상품들은 뛰어난 장점이 있지만 그만큼 가격이 더 나가는 것도 사실이다.
기업들은 직접 데이터베이스를 설치하고 소프트웨어 버전 업데이트 및 런타임 환경을 관리하는 것에 드는 인건비를 고려하면 현재 책정된 완전관리형 PaaS 상품가격이 전혀 높다고 볼 수 없다는 것도 알고 있지만 실제 표시된 가격 앞에서 이러한 판단은 모두 흐려진다. '그래서 한 달에 얼마예요?'에 이어 '오픈소스 DB가 그렇게 비싸요?' 라는 질문공격이 연타로 들어온다.
물론 상품 특성상 소규모 애플리케이션 구축에는 어울리지 않을 수 있으나 관련 상품들은 '안 써본 사람은 있어도 한 번 써본 사람은 없다.'는 말이 딱 적합할 만큼 소중한 자체 엔지니어 인력들이 소프트웨어 관리하는데 드는 시간과 노력을 줄이고 개발에만 집중할 수 있게 해주는 좋은 방법이니 막연한 두려움은 잠시 뒤로하고 친해져 볼 필요가 있겠다. 때로는 돈을 아끼기 위해 돈을 써야 하는 법이다.
마치며
너무 기본적인 것들이라 다소 황당하게 보일 수는 있지만 많은 고객들이 이러한 기본적인 것들을 지키지 않아 클라우드를 클라우드답게 사용하지 못하고 있다. 이러한 사례가 전체 클라우드 매출에서 차지하는 비중은 작을 수 있지만, 숫자로 보면 적지 않은 기업들이 포함될 것이다. 이미 언급했지만 그들이 이런 방법으로 클라우드 서비스를 운영하는 이유가 기술적인 역량이 부족해서 이거나 좋은 MSP를 만나지 못해서가 아니다. 알면서도 당장의 편의를 위해 가장 익숙한 방법을 택하기 때문이다. 기술부채로 포장하기에는 개선방식이 너무 간단하기에 미필적고의에 의한 참사에 가깝다.
필자가 이 글을 작성한 이유도 고객사 험담을 하기 위한 게 아니다. 사례로 든 유형의 기업들은 이미 유능한 테크니션들을 보유하고 있고 그들이 가진 잠재력도 높기 때문에 구석에 방치된 필자의 로봇청소기와 같은 그들의 현재 클라우드 운영방식이 클라우드의 효율을 조금이라도 높이는 방향으로 개선이 되기를 바라는 마음에서 이다. 그것이 옳은 방향이라면 그들이 가진 잠재력과 클라우드가 만나 폭발적인 시너지를 낼 수 있을 것이다.