[SaaS] 자유로운설탕의 SaaS 이야기- 보안관점에서의 SAAS 이해하기 – 1부

챕터1 – On-Premise vs SAAS 

1.1 현실에서의 SAAS

어떤 주제를 이해하기 위해서 이미 우리가 익숙한 분야가 있다면 해당 분야와 비교하는 것이 좋다고 생각한다. 물론 너무 일반화하는 부분은 그에 따른 부작용이 있을 수 있기도 하지만, 이해의 출발점으로 삼기에는 괜찮은 방법이라 생각한다. 그런 측면에서 SAAS는 기존과 없던 새로운 주제로 생각할 수도 있지만, 컴퓨터의 세상 밖으로 본다면 이미 비슷한 모델이 많은 듯하다.

예를 들어 우리가 집에서 이용하는 여러 서비스를 생각해보자. 우선 수도 및 전기, 가스는 우리가 직접 만들어 내거나 유지하는 부분은 당연히 아니다. 해당 서비스는 우리가 신뢰하는 국가 또는 외부의 민간 회사에 의지해서 매달 일정한 금액을 내면서 서비스를 받는 것이라고 볼 수 있다. 수도나 전기의 종량제를 생각해 보면 SAAS를 포함한 클라우드의 여러 서비스에서 과금을 하는 방식과 무척 유사하다. 

전기나 가스 뿐만 아니라 우리가 매달 구독하는 IPTV, 인터넷 서비스, 넷플릭스 같은 서비스 또한 비슷한 성격을 가지고 있다. 특히 넷플릭스, 유튜브 같은 서비스는 망사용료 이슈에서 보듯이 인터넷 서비스라는 외부의 기간 시스템에 의존한다는 점이 클라우드에 몸을 담고 있는 SAAS와 유사한 느낌이 있다. 우리는 실제 어떤 클라우드 서비스나 솔루션을 선택하냐는 문제처럼, 인터넷이나 OTT 등을 구독할 때 서비스 품질, 접근성, 부가 컨텐츠 등등의 다양한 부분들을 저울질해 선택하고 계약을 한다.

65e6f036021edb6132ce7e6732c2c99b_1672646946_8377.jpg

[그림 1-1 – 생활속의 SAAS]

만약 해당 서비스를 믿을 수 없다면 우리는 해당 서비스에 의존한 생활을 하지 못하게 될 것이다. 재난 지역 등에서 수도나 전기 서비스가 끊겨 많은 사람들이 고생을 하는 경우와 같이 말이다. 언제든 해당 서비스가 멈춰버려 우리에게 불편을 줄 가능성은 가능하지만, 우리는 그 회사를 믿고 그 불편한 사건이 아주 드물거나 짧게 일어나거나, 해당 회사에서 장애에 대한 적절한 보상을 해줄 것이라고 일반적으로 기대한다.

  가게를 차리는 입장으로 생각해 본다면, 사실 건물주인 경우를 제외하고는 거의 필요한 모든 것을 외부 서비스와의 계약에 맡긴다고 할 수 있을 것이다. 게임 속 세상이 아닌 경우는 우리가 팔거나 서비스해야 할 많은 부분들을 우리는 구입을 하거나 적절히 가성비를 저울질해 구독을 해야 한다. 가장 기초적인 임대 계약을 맺는 상가의 경우도 입지 이외에도 서비스의 안정성 면에서 여러 부분을 체크해 봐야 한다. 현재 대출 등 권리 관계가 따라 보증금이 안전한지도 체크해야 되고, 임대료가 적절한지, 향후 갑자기 오를 위험이 없는지도 체크해 봐야한다. 어느 날 건물을 새로 지어 나가야 되거나, 타인과 소송이 걸려 계약을 유지하지 못할 가능성도 고려해 봐야 한다. 또한 건물에 문제가 생겼을 때 주인 쪽에서 빨리 해당 문제를 해결해 줄 수 있을지도 중요할 것이다.

조금 더 확장해 공유주방이나 토즈 같은 공유오피스 서비스 또한 현실의 SAAS 와 비슷한 측면들이 많다. 제공자 입장에서 보면 접근성이 좋은 장소에 오피스를 유지하고, 적절한 가격을 유지하며, 여러가지 부가 서비스를 통해서 고객의 충성도와 임대업 이상의 부가적인 수익성을 높여야 한다. 

빈 사무실 만을 제공하고 그 사무실에서 무엇을 하느냐를 자유롭게 선택하게 하는 것을 IAAS(인프라 제공)라고 한다면, 기본적인 주방기반 시설이 완비된 공유주방을 제공하면서 원하는 음식을 선택해서 요리하게 한다면 PAAS(플랫폼 제공)에 가깝고, 거기에 추가로 배달 서비스, 키오스크 서비스, 로봇을 통한 요리 자동화, 정산 서비스 및 광고 등 부가 서비스가 제공되는 부분들을 제공한다면 SAAS(서비스 제공)에 가깝지 않을까 싶다. 

65e6f036021edb6132ce7e6732c2c99b_1672646956_0877.jpg

[그림 1-2 – 공유 주방]

다만 개인적으로 PAAS와 SAAS 서비스는 어디 까지를 플랫폼이 지원하는 영역이냐고 생각하냐에 따라서 완전하게 구분되는 개념은 아니라고 본다. 소프트웨어 세상에서는 키오스크나 배달 오토바이 등의 현실의 물리적인 부분이 모두 소프트웨어로 만든 서비스 객체일 것이기 때문에 경계가 명확하지 않고 선택적이다. 예를 들어 윈도우 OS에 계산기나 브라우저가 들어 있듯이 어디까지가 사업적으로 유리하면서 법적인 부분을 지킬 수 있을지 판단함에 따라 결정되는 영역이라고 보는게 더 맞을 듯도 싶다(과거 윈도우 브라우저의 반독점 법 이슈를 생각해 보자). IOS, 안드로이드 OS 같은 경우는 PAAS와 유사한 영역이라고 생각하지만 OS 버전이 업그레이드됨에 따라 기존에 SAAS에 가깝던 앱 서비스들이 기본으로 탑재되는 상황도 일어나곤 한다.

SAAS 서비스는 보통 플랫폼을 기반으로 빌려 쓰는 소프트웨어라고 간단하게 얘기는 되지만, 실제로는 문제를 해결해 주는 하드웨어, 비즈니스 모델, 소프트웨어, 인력의 조합에 가깝다. 하드웨어 부분은 해당 SAAS가 서비스되고 있는 클라우드 회사에 위탁되어 운영되고 있는 상황이고(이 부분은 앱스토어나 구글 플레이 생태계와 앱의 관계와 비슷하다고 본다), 비즈니스 모델은 앱이 우리의 니즈를 얼마나 잘 해결하고 있는 지에 대한 부분이다. 소프트웨어는 그 앱의 기능과 품질이고, 인력은 앱을 얼마나 잘 개발하고, 업그레이드하고, 이슈 대응을 잘 해줄 수 있느냐에 대한 측면이다. 

현실에서 조금 떠나 컴퓨터 세계로 가면 예전에 CD 로 게임이나 소프트웨어를 설치하던 초기시대에는 소프트웨어 CD-KEY 라는 개념이 소프트웨어 라이선스를 보호해주는 유일한 수단 이였지만, 해당 부분도 온라인을 통한 인증이라는 방식을 채용하게 된 시점부터 의미가 크게 없게 됐다. 물론 크랙 같은 부분으로 인증을 우회하는 경우도 있긴 하지만, 현재는 소프트웨어 실행에 필요한 필수 적인 데이터들이 상당 부분 서버 쪽에 존재하며, 상호 연결성을 지향하는 경향이기 때문에, 클라이언트 측면에서의 우회는 큰 의미가 없게 되었다고 볼 수 있다. 블리자드의 배틀 넷이나 스팀, 오피스 365같은 서비스를 보면 해당 부분을 알 수 있다.

회사의 관점에서도 여러 의견이 있겠지만, 회사 내에서 운영하던 시스템이 외부에서 서비스하는 시스템으로 많이 바뀌어 가고 있다. 재택에 대한 경험이 늘어나면서 어떤 장소에서든 노트북 또는 일부 제한은 되겠지만 스마트폰을 가지고 업무를 봐야하는 니즈가 해당 부분을 가속화시켰다고 본다. 다음 글에서 얘기하겠지만 회사와 연관된 서드파티 회사들도 그 자체가 SAAS와 유사한 느낌이 있고, 해당 회사들의 시스템 자체도 클라우드 SAAS 형태로 서비스가 될 수 있어 보인다.

1.2 사용자 입장으로 본 On-Premise, SAAS

기존에 다른 수많은 사람들이 얘기했던 내용들과 겹칠 것 같긴 하지만, 그럼 온프레미스와 클라우드 기반의 SAAS는 사용자 입장에서 어떤 차이를 가지게 될까? 우선 온프레미스 시스템이 만들어지는 상황을 생각해보자. 

온프레미스 서비스를 살펴보기 위해 먼저 자신이 인터넷으로 서비스를 하는 작은 회사를 새로 차리려 한다고 해보자. 요즘은 정말 특수하게 폐쇄적인 보안이 필요한 분야 빼고는 자체로 서버 공간을 만들어서 내부에서만 서비스하는 IT 업무는 아마 거의 없다고 보는게 맞을 것이다. 아마도 시스템을 위해 제일 먼저 적당한 서버를 운영할 공간을 제공해 주는 IDC를 알아볼 것이다. 커다란 회사는 서버나 네트워크, 보안 장비에 대해서 이미 검증된 IDC, 밴더 들이 있겠지만, 처음 시작하는 작은 회사들은 그렇게 하기는 여러 면에서 힘들 것이기 초기 투자 자본을 적게 들게 하기 위해서 특정 IDC에서 제공하는 공간 및 서버 대여 서비스를 이용할 수 있을 것이다(해당 부분은 IAAS 모델과도 비슷할 것 같다). 

그럼 사실 이 시점부터 자기 주도권을 가지는 온프레미스에 대한 환상이 살짝은 깨지게 된다. 정말로 폐쇄적 운영이 필요한 큰 회사 및 클라우드 및 IDC 서비스를 제공하는 회사들은 자신만의 IDC 환경을 구축할 수 있겠지만, 일반적인 소프트웨어 기반의 회사들이 외부의 인프라에 의존하지 않고 자체적인 온프레미스 공간을 구축하는 것은 땅/건물/인력 등 사실 상 채산성 측면에서도 거의 불가능 할 것이다. 더 나아가 앞에서 얘기한 전기/수도 등의 공공재 문제까지 생각한다면, 우리가 온프레미스라고 생각하는 부분은 공전과 자전을 하는 지구 안에서 우리가 세상이 평화롭게 멈춰 있다고 느끼는 것과 같은 항산성과 불안함을 동시에 가지는 것이라고 생각한다. 물론 그 작은 확률에 대한 불안 함까지 고려하기 시작하면 아무것도 못하게 되긴 하지만 말이다.

앞의 IDC 와 그것을 이용한 IAAS 모델이 확실하고 안정적인 사업이긴 하지만, 개인적으로 생각하기에 해당 부분의 한가지 아쉬운 점은 부가가치를 높이기는 조금 어려운 분야라는 부분일 것이다. 약간 현실의 입주사에 대한 빌딩 운영과 비슷한 부분이 있기 때문이다. 데이터 측면에서 봐도 각각의 데이터는 각각의 내부 회사들의 폐쇄적인 네트워크 및 장비 안에서만 흐르게 되고, 그 데이터를 이용해서 뭔가 부가가치를 만들기도 힘들고, 사실 계약 관계에 의해서도 해당 부분에 대해 접근할 수 있는 방법은 현실적으로 없어 보인다(비즈니스, 법적인 측면 에서도 누가 자기 회사의 내부 데이터를 남에게 보여주려 할까 싶다). 물론 관제 등의 서비스 등으로 확장하여 서비스를 하긴 하지만 클라우드에 비해서는 확실히 폐쇄적인 면이 있다. 하지만 사실 이 폐쇄성이 온프레미스의 장점이기도 한 아이러니 또한 있다.

클라우드 환경에서도 IAAS를 넘어 PAAS 부터는 사용의 안정성과 편의성, 합리적인 과금을 제안하기 위하여 데이터에 일정 부분 접근할 수 있는 권리를 가지게 되겠지만, 실제 사용하는 데이터의 의미 등을 적극적으로 파악하기는 힘들 것이다. 하지만 SAAS까지 확장되게 되면 많은 부분이 달라지게 될 듯싶다. SAAS 서비스를 제공하기 위해서는 데이터의 구체적인 “의미”를 알 수 있어야 하기 때문에, 구글이나 애플이 아이폰, 안드로이드 OS을 가지고 생태계를 만들고 과금하고, 데이터를 수집하고, 수집한 데이터를 기반으로 광고 등 새로운 서비스를 확장하는 것처럼, 클라우드를 사용하는 고객들이 사용하는 정적/행동 데이터에 간접적으로 접근하여 통계적인 통찰을 얻어낼 수도 있어 보인다. 나아가 해당 부분을 클라우드 회사에서 제공하는 여러가지 분석적 도구들을 통해 적절한 계약과 권한 협의를 통해 연결할 수 있다면, 좀 더 다양한 서비스를 제공할 수 있게 될 것이다(빅데이터의 익명화를 통한 활용 같은 느낌이라고 할까).

또한 각각의 SAAS 솔루션들이 자신들에게 필요한 데이터들을 각각 수집하고, 프로파일링 하고, 분석하는 것보다는 미리 클라우드 업체가 가공한 공통 프로세스 및 API를 기반으로 접근하고 사용하는 부분이 매력적일 것이다. 클라우드 업체 입장에서도 자신들이 만들어 놓은 가상의 플랫폼을 고객과 SAAS 서비스 양쪽에 제공하는 것이 효율성이나 부가가치 측면에서 유리할 것이다. 무엇보다 이런 부분은 IDC 입장에서의 한정된 공간과 자원을 제공하는 것보다 데이터를 기반으로 부가가치를 확장시키는 효과를 가지게 되는 부분이 장점이라고 본다. 다만 단순한 공간과 서버, 인력이라는 변수에서 서비스와 데이터의 영역으로 고려 범위가 확장됨으로써, 많은 부분에서 고객사, SAAS 파트너사, 클라우드 제공자 사이의 수많은 수 읽기가 필요한 측면이 생기게 되었다고 본다. 

SAAS 제공자들의 입장에서도 기존의 단순히 문제를 해결하는 개별적인 소프트웨어를 제공하는 입장에서, 사용자의 데이터를 간접적으로 분석하여 향후 제품을 업그레이드하거나 새로운 비즈니스 기회를 만들어낼 수 있는 유용한 통찰점들을 발견할 수 있어 더욱 매력적이라고 본다. 해당 측면에서 기존 온프레미스 환경에서는 사실 상상하기 힘든 장점을 SAAS를 통해서 이룰 수 있게 되었다. 어느 쪽이 먼저 촉발시켰을 지는 모르겠지만 솔루션 또한 하드웨어 기반의 어플라이언스 장비를 통한 소프트웨어 제공 방식은 점점 사라지고, 순수한 소프트웨어 기반의 제공과 데이터를 기반으로 한 과금 모델이 점점 늘어나고 있는 것으로 보인다.

사용자 입장 에서도 클라우드 자체를 잘 활용하기 위해서라도 많은 편리한 기능들을 원하게 된다. 마치 우리가 예전 커맨드 프롬프트 외에 아무것도 없는 도스 화면에 여러 유틸리티들을 깔면서 좀 더 유용하고 편리하게 사용하고자 하던 시절이나, 윈도우의 여러 유용한 유틸리티들에 대한 니즈와 비슷하다고 볼 수 있다. 다만 하나의 잊지 말아야 될 문제는 그 모든 부가가치를 일으킬 수 있는 데이터가 대부분 고객이 맡겨 놓은 소중한 정보라는 것이다. 보안 측면에서 중요한 데이터는 고객이 맡겨 놓은 정보와 그 정보를 기반으로 일어났던 데이터, 행위, 그 것으로부터 파생되는 기업의 가치를 유지시키는 2차 데이터들이라고 본다. 이 부분에 대해서 어디까지 서비스를 위해서 클라우드 관련 회사에 제공하고, 노출시킬 수 있느냐를 고민해야 하는 것 같다.

65e6f036021edb6132ce7e6732c2c99b_1672646969_1727.jpg

[그림 1-3 소중한 것을 맡기기]

1.3 비용 측면에서의 On-Premise, SAAS

보안 솔루션 운영팀 경험을 한 후 느낀 부분 중에 하나가 보안과 비용은 떼려야 뗄 수 없는 부분이라는 것이다. 회사내에서 보안 측면에 소요되는 비용은 인력 이외에도 장비나 솔루션에 대해 많은 비용이 소모되고, 그에 따라 잘못된 선택이나 비 합리적인 선택을 했을 때의 비용 손실도 심하게 될 것이다.

온프레미스 에서의 비용 부분은 과거의 심플한 상황부터 점점 클라우드 비즈니스 모델의 영향을 받아가는 느낌이 있다. 과거에는 사용자 단위, 서버-CPU 단위, PC 단위, 어플라이언스, 정액제 기간 단위 등 도입 시점에 명확한 비용이 많았다면, 현재는 API 콜 수, 처리하는 데이터 양 등 클라우드 지향의 과금 체계가 많이 늘어난 듯하다. 보안 장비들은 기본으로 최초 구입가를 낸 후 일정 금액의 유지보수 비율을 저울질하는 게 일반적이 였지만, 아마도 해당 비즈니스 모델은 초기 판매 후 일정 금액이 계속 들어온 다는 점에서 안정적인 반면 앞서 IDC와 비슷하게 부가가치가 많이 생성되긴 힘들어 보인다. 게임으로 따지면 정액제 게임에서, 도입은 공짜지만 특정 서비스를 사용함에 따라 돈을 내는 부분 유료화 게임으로 과금 모델이 바뀌어 가고 있는 느낌이다. 

이 부분은 클라우드로 가면 더 더욱 비슷한 상황이 생기게 된다. 클라우드 SAAS 환경에서 온프레미스처럼 한번 구매 후 유지보수 비용 모델을 사용하는 경우는 꽤 드문 것 같기도 하고, 만약 그런 과금 체계가 있더라도 보통 다른 요금제보다 비용면에서 온프레미스처럼 매력적이진 않은 것 같다. 그래서 항상 비용이 상대적으로 발생하기 때문에, 과금 측면에서 보면 원하는 게임 클리어를 하기 위해(1년동안 해당 시스템을 쓰는 목적을 달성하기 위해) 한정된 코인을 아껴 써야 되는 측면이 있다(실제 클라우드 내부에는 크레딧 같은 현금과 매치되는 가상 포인트 개념이 있다. 옛날 싸이월드 도토리라고 보자). 기존에는 어쩔 수 없는 고정 비용으로 생각되던 부분도 클라우드에서는 재고는 무한이지만 비용 때문에 잘 아껴 써야 하는 자원이라는 느낌이 생기게 되어 비단 보안 뿐만 아니라 시스템 운영 부분에도 같은 압력을 받을 듯하다. 

65e6f036021edb6132ce7e6732c2c99b_1672646982_3515.jpg

[그림 1-4 한정된 코인으로 클리어 하기]

해당 크레딧 문제 관점에서도 기존에는 서버 도입/유지보수 비용, 비즈니스, 솔루션 비용이 나름 별개의 팩터였던 느낌 이였다면, SAAS 쪽에는 데이터나 호출에 기반한 과금을 디폴트로 하는 경우가 많기 때문에 클라우드 이용 요금과 SAAS 이용 요금이 데이터나 비즈니스의 흐름과 선형적으로 비례 되는 경향이 많은 것 같다. 회사 예산 측면에서도 고정비 보다는 운영 비로 잡히게 될 가능성이 높기 때문에 절감 압박이 매년 높아질 듯하다. 그리고 해당 부분은 반대 입장인 클라우드나 SAAS 업체의 수익 증대 니즈와 충돌될 수밖에 없어 보인다.

 어찌 보면 정액제 무제한 이였던 PC 인터넷의 세계에서 몇몇 메이저 회사에 의해 결정될 수 있는 종량제의 모바일 요금제의 시대로 온 것과 같은 느낌이 든다. 물론 모바일에도 무제한 요금제가 있지만, 우리가 집에서 쓰는 무제한 유선 인터넷에 비해서는 선뜻 다들 가성비를 인정하기는 어려운 금액 대이고, 해당 요금제와 비슷하려면 클라우드 SAAS 환경에서 데이터, 호출 규모와 상관없이 쓸 수 있는 사이트 라이선스가 주어져야 하기 때문에 마찬가지일 것이다. 물론 여기에는 다른 선택지가 없는 모바일과는 조금 다르게 경쟁 상태인 온프레미스 단독이나, VMWARE, Nutanix, Cytrix 같은 내부 가상화, 클라우드 서비스와의 여러 측면을 고려한 가격 효율 경쟁이 일어나긴 할 것이다.

회사 입장에서 비용을 효율적으로 쓰거나 절감하는 방법은 2가지일 것이다. 하나는 PAAS 환경에서 스스로 만들어 낸 솔루션이나 오픈소스(사실 많은 오픈 소스의 경우 기업환경에서 사용할 경우는 관리 편의성이나, 보안, 안정성, 확장성을 위해 추가 엔터프라이즈 서비스를 구독해야 하는 경우가 자주 생기는 듯하지만)를 사용하는 거지만 모든 분야에 통용될 현실적인 안으로는 보이진 않는다. 다른 하나는 과금의 포인트를 이해해서 해당 부분을 효율화 할 수 있는 전략을 세우는 것이다. 그런데 사실 그렇게 하려면 결국 데이터나 비즈니스, 관련 서버 프로그램을 비롯한 여러 IT 인프라를 종합적으로 잘 이해해 최소한의 필요한 데이터만 클라우드에 적재하고, 연산하고, 호출하고, 폐기하는 설계가 필요하다고 본다. 사실 클라우드나 SAAS 서비스에서는 이러한 것을 할 수 있는 여러가지 가시적인 부분을 API 나 CLI 및 기성 솔루션을 통해서 제공할 테지만, 구슬이 서말이라도 꿰어야 보배라고 이런 구슬들을 잘 이해하고 현재 회사의 비즈니스와 연관해 전략적으로 적절히 사용할 수 있는 사람을 구하는 것도 사실 큰 숙제이기는 할 듯하다.

그래서 많은 회사들이 단순히 온프레미스에 있는 시스템들을 클라우드에 올려서 비용 절감을 꾀하다가 종량제의 따끔함을 맛보는 경우도 있을 것 같고, 그래서 아마 요즘 클라우드나 SAAS 회사들이 무조건 적인 비용 절감 효과에 대한 마케팅적 어필을 초창기 보다는 많이 줄이고, 종합적인 최종 운영 측면에서의 비용 절감이 있다는 측면으로 어필을 하게 된 부분 일거라고 생각한다. 또한 약간 머신러닝 초창기 때와 비교해 지금 사람들의 머신러닝을 보는 시각이 많이 성숙했듯이, 클라우드와 SAAS 쪽도 사람들의 시각이 비슷한 변곡점에 와 있지 않나 싶다. 뭐 여하튼 내부이든 밖이든 누군가 구슬은 꿰 주어야 그 체인 효과가 생기지 싶다. 사실 그건 앞에서 말한 다른 대안인 오픈 소스들을 활용할 경우도 마찬가지일 것 같기도 하다.

또한 SAAS에서 선택지로 제공하는 부가 옵션 측면은 불안함과 추가 선택을 안 함에 대한 아쉬움을 타겟으로 미묘하게 설계되어, 마치 부대찌개 구성에 왠지 아쉬운 면이 있어 사리나 추가 햄들을 추가해야 먹음직해지는 것 같은 경우가 많다. 이 부분은 데이터 용량과 금액이 미묘하게 아쉽게 배치되어 있어 상위 요금제에 대한 선택을 고민하게 하는 핸드폰 요금 체계나 구독 서비스 와도 비슷해 보인다. 어찌 보면 현재의 IT 회사들이 기술을 기반으로 한 사업이긴 하지만, 구독/수수료 비즈니스 모델을 많이 채용하게 되면서, 수학 공식으로 이루어진 금융업의 흐름과 비슷한 느낌이 되지 않았나 싶은 생각도 든다.

마지막으로 앞에서 얘기했듯이 클라우드 서비스는 규모에 의한 안정성 및 부가가치를 일으키지만 그것을 위해서 많은 보이지 않는 투자들을 하고 있을 것이다. 이러한 투자들의 규모를 사실 외부에서는 명확히 알 순 없긴 때문에 이 간접적인 부분에 의한 믹스가 얼마나 SAAS나 클라우드 구독 비용에 영향을 미치는 지는 알기 힘들다. 물리적인 IDC와 같은 상황이라면 외부 추정 등으로 간접 적으로 예측할 수 있는 부분들을 전혀 알 수 없기 때문에, 외부 사용자 입장에서는 항상 비용 부분에 대한 불안함을 일정 부분 가질 수 밖에는 없는 한계가 보이기는 한다.

1.4 자동화 측면에서 본 On-Premise, SAAS

개인적으로 생각했을 때 온프레미스나 클라우드나 자동화 측면에서 본질적으로 큰 차이는 없어 보인다. 사실 온프레미스의 많은 솔루션들을 보면 생각하는 것보다 CLI 나 API를 많이 제공한다. 요즘 솔루션(특히 외산 솔루션)들을 보면 거의 제공되는 UI 화면 내부의 동작이 API 나 CLI 호출을 통해서 이루어 진다고 봐도 과한 표현은 아닌 것 같다. 사실 이건 뭐 개발에서 얘기하는 Rest API 나 마이크로 서비스를 논외로 보더라도, 클라우드 환경을 동시에 지원하는 솔루션을 만드는 현실화된 접근 방식이 아닐까 싶다. 앞에서 얘기했듯이 클라우드 환경은 가상의 환경이기 때문에 알뜰하게 사용하려면 어쩔 수 없이 데이터 흐름 분석과 연계된 자동화가 이루어져야 하며, 이 경우 외부와의 자동화 인터페이스 대표적인 표준이 API 와 CLI 환경 인 것 같다.

클라우드에서는 온프레미스에서 존재했던 물리적인 영역 부분이 많이 사라지게 된다. 서버들을 구입하거나 설치하는 과정이 생략되고 해당 물리적인 작업을 하는 인력의 행위 또한 가상화가 된다(물론 보이지 않는 뒷면에서 해당 클라우드 회사의 사람들이 열심히 실제 물리적 서버를 설치하고 효율적인 가상화 공간을 세팅하고는 있겠지만 말이다). 마치 사람이 직접 타고 움직이면서 조종해야만 했던 전차와 같은 기계가 드론과 같이 원격 조정이 가능하고, 원격 조정을 할 수밖에 없는 무기로 변화하는 것과 비슷한 느낌이다. 뭐 다른 현실 영역과 비교하자면 요즘 얘기하는 메타버스 환경과도 비슷하다는 생각이 든다. 

컴퓨터 들을 생성하고, 특정 네트워크 영역을 설계해 배치하고, 데이터들을 모니터링 할 수 있지만, 그 모든 게 어떤 원리로 일어나는 지 운영자는 (상세하게는) 몰라도 된다. 사실 내부적인 동작을 잘 알더라도 라이선스 및 시스템 안정성, 보안 측면에서 사용자 입장에서 내부에는 영향을 쉽게 미치지 못 한다고 보는게 맞다. 실제로 우리가 IDC를 운영하면서 진행해야 했던 모든 물리적인 행동들은 여러 클라우드 환경하에 CLI 나 API 메서드 들을 통해 구현되어 있다(물론 공식적으로는 쉽게 사용할 수 있다는 것을 어필하기 위해서 UI도 지원하기도 한다). 반대로 물리적인 IDC에서도 VMware, Nutanix 등을 이용하여 HCI 환경을 구성하여 클라우드처럼 사용하기도 한다. 개인적으로 클라우드나 HCI 나 독립적인 센터를 가졌냐 하는 부분만 빼고 나면, 여러 컴퓨터들을 묶은 가상화 환경을 쓰고 관리 편의성을 극대화하는 것을 추구하는 측면은 비슷하다고 생각한다. 그래서 클라우드 쪽 설명회를 가다 보면 조금은 이상하게도 느껴지지만 경쟁 상대라고도 볼 수 있는 그 VMware 환경을 클라우드에 한번 더 얹어 기존 온프레미스 관리 환경과 라이선스를 그대로 쓸 수 있다는 점을 어필하기도 한다.

 이런 측면에서 보면 클라우드 환경에서의 자동화는 심시티, 마인크레프트, 동물의 숲 과 같은 주어진 블록이나 커스텀 블록을 가지고 여러 환경과 건물을 짓는 게임과 비슷해졌다고도 볼 수 있다. 실제로 SAAS 환경에서 얘기하는 Low-Code 플랫폼의 경우도 결국 이러한 고급 블록을 해당하는 부분을 SAAS 서비스 회사와 고객 회사의 내부 고급 개발자 들이 개발하고(예를 들면 현실의 “금손”들이라고 보자) 최소한의 논리적 사고에 기반한 조립 기술을 가진 일반 도메인 전문가, 초보 수준의 개발자 들이 쉽게 만들 수 있는 플랫폼을 제공하는 환경이라고 본다. 데이터베이스 쪽을 비교하면 BI툴이나 태블로 같은 툴의 범용 버전 또는 통합된 클라우드 환경을 이용한 RPA 플랫폼에 가깝다고 본다. 물론 앞의 비용 부분에서 얘기했듯이 이런 플랫폼이 효과를 잘 나타내려면 모든 것을 잘 분석하고 전략을 세워 전체적인 흐름을 설계하고 해당 방향으로 유도할 수 있는 누군가는 꼭 필요하다고 본다. 초보 사용자들이 막혔을 때 잘 서포트해서 학습 곡선을 잘 넘길 수 있게 하는 친절한 챔피언 직군들도 필요하고 말이다.

65e6f036021edb6132ce7e6732c2c99b_1672646995_7248.jpg

[그림 1-5 가상 공간에서의 집 짓기]

1.5 보안 측면에서 본 On-Premise, SAAS, 하이브리드

앞에서 얘기한 것처럼 온프레미스 구축을 하는 것은 물리적인 상점을 차리는 것과 비슷하다. 제일 먼저 적절한 운영 공간이 필요할 것이다. 이후 해당 공간에 채울 물건(서버들이 필요하다) 및 서버를 배치할 랙과 네트워크 장비, 케이블 등을 설치하고, 서버실에 문제가 없는지 모니터링 할 수 있는 숙련된 인력도 필요하다. 이렇게 하나하나 세팅하는 데의 장점은 원하는 데로 내부 구조를 구성할 수 있는 것이지만, 반대로 처음에 설계를 잘못하거나 복잡도가 높아지면 논리와 물리의 부조화에 따른 카오스에 의해 되돌리기 힘든 구조가 된다는 단점도 발생한다. 보안 측면에서는 물리 보안 및 해당 물리적 조합들이 합쳐져 만들어진 논리 보안이 동시에 잘 설계되어야 한다.

65e6f036021edb6132ce7e6732c2c99b_1672647008_9131.jpg

[그림 1-6 가게 꾸미기]

추가로 개발 쪽은 이젠 거의 그 오해를 벗어난 것 같지만, 한 가지 오해를 일으킬 수 있는 부분은 실제 움직이고 조사하고 모니터링 하는 측면은 보안의 한 측면일 뿐이라는 것이다. 보안은 실제의 행동 전에 일어나는 데이터와 도메인의 분석에 따른 설계가 오히려 더 본질적이라고 본다. “콩 심은데 콩 나고 팥 심은데 팥 난다”고 잘못된 보안 설계로 된 어설픈 구조에서 뛰어난 인력이 투입된다고 보안 수준이 높아진다고 보진 않는다(물론 구멍 난 데는 좀 때워질 것이다). 개발에서 분석 및 설계의 중요성에 대해서 강조되듯 사실 보안 또한 행동 보다는 분석 및 고찰에 의한 설계 영역이 해당 활동의 본질에 가까운 측면이 있다고 생각한다.

회사내의 데이터 흐름을 이해하고, 그 데이터를 흐르게 하는 어플리케이션들을 이해한 상태에서 데이터의 흐름을 관리하고 모니터링 하는 여러 보안 장비 및 솔루션들을 전략적으로 배치하는 것이 중요하다고 본다. 거기에 데이터를 분석하거나 특정 패턴에 따라 분류할 수 있는 기본적인 데이터 분석을 포함한 AI 관점까지 이해할 수 있다면, 상호 보완적인 정책을 적극적으로 포진시킬 수 있을 것이다. 물리 보안을 빼고는(사실 물리 보안도 그 데이터의 분석이나, 동선에 대한 정의가 데이터에 의해서 일어난다는 부분에서는 결국 동일하다고 보지만) 보안의 모든 부분은 가상 세상에서의 논리 게임의 측면이 있다.

앞에서 클라우드 및 SAAS 환경에 대해 공유 주방으로 예를 들었지만, 사실 보안 입장에서 보면 해당 환경은 위험한 시약들을 서로 다루는 공유 실험실과 좀더 비슷하다. 잘 못 관리하게 되면 서로 다른 시약이 섞여 폭발할 수도 있고, 밖으로 나가면 안되는 물질이 유출될 수도 있으며, 내 실험실에 다른 사람이 들어와서 내 연구 결과를 훔쳐갈 수도 있다. 반면에 효율적인 공유 환경을 유지하기 위해서 특정한 실험 공간 및 장치 등은 공동으로 사용하거나. 특정 연구 결과는 회사의 이익과 법이 허용하는 한도에서 파트너사에 공유해서 시너지를 내는 게 비용적인 면에서 효율 적일 수도 있다. 그래서 개개의 활동을 서로 다른 공간에 격리함과 동시에, 시너지를 위해 (익명화 하여) 모아야 하는 이해관계가 존재한다.

65e6f036021edb6132ce7e6732c2c99b_1672647094_3485.jpg

[그림 1-7 공유 실험실]

 클라우드에서 중요시해야 되는 데이터는 앞에서 보았듯이 고객이 맡겨 놓은 정보, 고객의 거래 정보, 행동 정보(이건 여러 보안, 마케팅 적으로 다른 해석이 있을 수 있지만)에서 출발하여, 회사의 노하우를 축적해 놓은 여러 정적, 동적, 그에 기반한 분석적 정보들일 것이다. 이건 사실 변하지 않는 가치라서 온프레미스 이던 클라우드 이던 그 위의 SAAS 환경 이던 그 중요성이 달라지는 부분은 아니라고 본다.

 그럼 클라우드 보안에서 온프레미스에 비해 좀 더 신경 써야 하는 것은 무엇일까? 개인적으로 생각해 볼 때 몇 가지 측면이 있다고 본다. 

첫째, 물리 보안이 가상화로 들어 가게 되면서 가시성과 자동화가 늘어나면서 새로운 공격 영역이 생길 수도 있다는 것이다. 예를 들어 누군가가 해당 환경으로 들어와서 몰래 가상화폐를 채굴한다고 해보자. 물리적인 환경이라면 공격자가 서버를 새로 설치하는 건 불가능 하고, 기존 설치된 서버를 여러 솔루션의 내부모니터링을 피하면서 들키지 않게 사용하는 방식 이겠지만, 클라우드 환경에서는 신규 서버를 몰래 생성해서 모든 모니터링을 끄고 보유한 크레딧을 들키지 않게 소모할 수도 있을 것이다. 또는 비용이 소요되는 API 나 기능들을 반복적으로 몰래 호출해, 유용한 유료 정보를 빼내거나 비용을 전가시킬 수도 있다. 

이전에 얘기했듯이, 클라우드 및 SAAS 환경은 API 및 CLI 로 이루어진 자동화 세계이기 때문에, 아이러니 하게도 그 사이로 잘 들어갈 수만 있다면 정상적인 경로를 통해서 IDC에서 물리적인 활동을 통해서만 할 수 있었던 많은 일들이 가능할 듯하다. 결국 방어하는 입장에서는 해당 데이터와 이벤트를 기반으로 비 정상적인 행위를 잡아야 하는 상황이 된다고 본다. 여기서 하나의 문제가 생기는데 SAAS 같은 솔루션에서는 기존의 온프레미스 솔루션보다 좀 더 노출하는 모니터링 데이터의 종류와 방식을 보통 제공사 쪽에서 미리 정해진 형태로 제공하려는 경향이 강하기 때문에 자신이 원하는 수준으로 살펴보는게 불가능 할 수도 있다. 보안 기능 등도 많은 경우 미리 정해진 옵션들 중 하나를 선택하는 것으로 제공하고, 해당 부분 또한 머신러닝 이란 키워드가 붙은 순간 좀더 사용자 쪽에서는 속을 알 수 없게 되어 버리기도 한다. 추가로 자동화의 반작용으로 그 자동화에 실수가 일어나거나 악용이 되게 되면 모든 도메인에 한순간에 병렬로 악 영향을 미칠 수 있게 된다. 이러한 특성 때문에 클라우드 보안에서는 원래도 중요했던 계정의 권한 관리가 조금 더 강조되게 되는 것도 같다.

물론 클라우드 세상에도 실제의 물리 보안 영역이 있긴 하지만, 이건 현실 상 클라우드 회사에서만 보호할 수 있고 책임 질 수 있는 영역으로 봐야 할 듯하다. 이부분은 다음 얘기인 서드파티와의 비교에서 조금 더 자세히 얘기해보려 한다. 

 둘째, 가상 공간내의 중요한 데이터가 무엇인지 파악하는 부분이 매우 중요하다. 만약 온프레미스 같은 소유가 아닌 일시적으로 빌린 시스템이라는 잘못된 인식을 가지게 된다면 물리적으로 보유한 자산 보다 데이터의 보유나 파기에 대해서 무관심하게 될 수도 있다. 추가로 클라우드 기술이라는 이해가 힘든 장벽과 플랫폼에 대한 무지가 의도되지 않게 회사의 데이터를 외부로 보내게 되는 통로가 될 수도 있다고 본다. 종종 클라우드 영역과 동일 시 되는 가상화 환경인 도커나 쿠바네틱스, 자동 빌드/테스트/배포 환경인 CI/CD 등은 클라우드나 SAAS 와는 별개의 기술 영역이라고는 생각하지만, 사실 클라우드 환경에서 해당 기술들의 사이에 SAAS 서비스들이 종종 들어갈 수 있기 때문에 해당 기술에 대해 충분히 이해하지 못한다면 정확한 데이터 흐름을 파악 못하게 될 수 있고, 이는 취약한 보안 설계를 일으킬 가능성이 높다. 

다만 해당 기술에 대한 보안을 외부의 사용자 입장의 회사에서 내부적으로 이해하고 취약점들을 피해가는 것은 무척 어려울 것이므로 베스트 프랙티스를 잘 알려주는 회사나 오픈소스 기술들을 선택하여 사용하는 것이 맞지 않을까 싶다. 해당 솔루션 들을 사용하는 목적이 결국은 어떻게든 쉽고 안전하게 클라우드 환경을 이용하는 것이기 때문이다. 정리하자면 기업입장에서는 명시적으로 컨트롤이 가능한 영역에 대해서만 주요 데이터가 흐를 수 있게 클라우드나 SAAS 제공자와 충분한 커뮤니케이션을 통해서 데이터 흐름을 설계하고 모니터링 하는 것이 중요하다고 생각한다. 

셋째, 데이터 흐름의 자세한 분석이 필요한 또 한 가지 측면은, 일반적으로 보안적으로 필요한 데이터가 꼭 비즈니스적으로 필요한 데이터와 일치하지는 않는 다는 것이다. 데이터의 흐름과 종류를 정확히 파악하지 못한다면, 아무리 좋은 솔루션들을 배치했다고 해도 원하는 식별자와 패턴에 대한 충분한 데이터가 존재하지 않아서 불완전한 모니터링을 할 수도 있고, 반대로 필요 없는 과대한 보안 친화적 데이터를 클라우드에 저장하고 처리함으로써 필요 없는 솔루션 라이선스 및 클라우드 사용 비용을 전가시킬 가능성도 있다. 보안은 보통 부족함에 대한 두려움으로 과도한 데이터를 수집하려는 경향이 있고, 이것은 온프레미스 보다 클라우드에서 비용적으로 큰 약점이 될 수 있다고 본다. 앞서 얘기한 것처럼 선택가능한 보안 옵션이 제한된 부분도 있고, 불안감 때문에 일반적인 시스템처럼 유휴를 하다가 필요한 순간에 온라인화 시키기도 힘든 측면이 있기 때문에 요구 데이터에 대한 논리적 다이어트가 필요하다고 말하고 싶다. 물론 이 다이어트에는 별개의 인적, 물적 비용이 소요될 가능성이 높다.

넷째, 클라우드 시스템, SAAS 가 지원하는 여러 API 와 CLI 요소들을 파악해 자동화할 수 있는 것과 없는 것을 구분할 수 있어야 한다고 본다. 불행하게도 클라우드나 SAAS 모두 범용적 서비스를 목표로 만들기 때문에 다양한 사용자의 모든 니즈를 만족시키기는 어렵다. 그래서 그러한 니즈를 어느정도 만족하기 위해 API 나 CLI를 통해 내부 기능을 노출하고, 해당 기능을 통해 적절히 원하는 기능을 커스터마이즈 하고, 까다로운 사용자들에게 내부를 어느정도 들여다볼 수 있게 하는 경향이 있다. 뭐랄까 “너희가 원하는 걸 다 만들어 줄 수는 없지만, 내부 기능을 API 나 CLI 를 통해 공개해 줄테니 기능이 허락하는 한 조합해서 원하는 데로 써”의 느낌이라고 할까? 개발사 입장으로서는 내부의 리소스를 안 들이고, 고객사 실 사용자의 손을 빌어 파이썬이나 쉘 스크립트 같은 접근성이 쉬운 언어로 커스터마이즈를 하도록 제공할 수 있으니 밑지는 장사는 아닌 것 같다. 어찌 보면 이것이야 말로 “Low-Code”의 이상적인 표본이 아닌가 하는 생각도 들고 말이다.

  이러한 기능 및 모니터링과 관련된 API를 잘 분석하여 이용함으로써 가상화 된 세상의 변화를 캐치하고 모니터링 비용을 최적화할 수도 있다. 다만 앞에서 얘기한 것처럼 SAAS는 보통 제한적으로 선택 적인 옵션만을 제공하는 경향이 강하기 때문에 할 수 있는 것과 없는 것을 API, CLI, 로그 등을 통해 기능, 데이터 분석 면에서 잘 이해하지 못한다면 해당 활동은 의미 없게 될 뿐만 아니라 잘못된 안전에 대한 믿음이 생기게 될 위험이 있다고 본다. 앞에서 말했듯이 전체적인 이해를 통해 잘 분석된 결과를 통한 방어 설계가 중요하다. 추가로 해당 노출된 기능 들은 자동화의 측면에서 SAAS 솔루션 등에 민감한 영향이나 악영향을 줄 수도 있기 때문에 적절히 통제된 권한 하에서 적당한 부하로 잘 사용되어야 한다. 인증에 사용하는 토큰 등도 키 관리 솔루션 등을 이용해 비교적 안전하게 관리하도록 해야 하고 말이다. 이건 뒤에서 기회가 있을 테니 그 때 좀더 다루어 보려고 한다.

마지막으로 정말 처음부터 작정한 스타트 업이 아닌 이상은, 회사에 노트북 등 물리적 컴퓨터의 네트워크는 당연히 있을테고, 그렇게 되면 일시적이든 아니든 온프레미스와 클라우드가 섞인 하이브리드 형태가 필연적으로 구성되게 된다. 이 경우는 좀 더 미묘한 접근이 필요하게 된다. 온프레미스에 기존 투자된 솔루션이 클라우드와 중복될 수도 있을 테고, 또는 클라우드 환경을 지원하지 못 할 수도 있다. 새롭게 구축된 SAAS 솔루션의 기능이 폐쇄망에서 접근할 수 있는 적절한 중계 인터페이스나 온프레미스 솔루션에서 제어에 필요한 식별 수단을 제공하지 않을 수도 있다. 

SAAS 솔루션 특성 상 접근하는 대상들이 클라우드 상에 있을 때를 최적인 설계 목표로 삼고 있는 경우가 많아 보이기 때문에, 기존에 온프레미스에 있던 보안 장비/솔루션 들을 클라우드 상에서 새로 구입하거나 교체해야 되는 일도 생길 수 있다(이건 리소스 보다 비용 측면에서 크리티컬 할 수 있다). 클라우드로 가면서 라이선스 등의 형태가 달라지거나, 별도의 전용 클라우드 센터를 사용해야 하는 경우도 생길 수 있다. 추가로 HCI 같은 사실 상의 내부 클라우드 영역이 있다면 해당 부분과의 관리 효율성도 생각해 봐야 할 것 같다. 

하이브리드 환경이라면 해당 솔루션이 클라우드, 온프레미스 상의 모든 대상에 대해서 합리적인 지원 및 보안 설계가 되어있는지를 체크해 보는 것이 좋다. 필요 이상의 과도한 라이선스나 기능을 고려하라는 것은 아니지만, 당장 현재 필요 없다고 해도, 차후 예상 못하는 환경이 생기는 경우 또한 수용할 수 있는 변경 계획을 고려해야 한다고 생각한다. 무엇보다도 SAAS 솔루션이 기존 온프레미스의 특정 영역을 대체하면서 기존의 보안 설계의 가정이 깨어지는 상황을 제일 조심해야 하는 것 같다. 물론 해당 SAAS 회사 쪽에서는 클라우드로의 패러다임의 전환이라고 설득은 하겠지만 레거시는 레거시 나름대로의 가치가 있는 측면도 분명 있고, 가끔은 구관이 명관일 때도 있는 법이라는 것을 잊으면 안 된다. 세상 모든 건 언제나 장점과 단점이 반드시 같이 존재하니까 말이다.

또 Lock-Out 전략 또한 고려해야 할 텐데, 그래서는 안되는 거지만 잡은 물고기에 먹이를 안 준다고 많은 밴더들이 아무래도 기존 고객 보다는 신규 고객에 포커스를 주는 경향도 있긴 하다(물론 구독 형태에서는 그 포지션이 조금은 달라지고 있다고는 본다). 서로 믿을 수 있고 Win-Win 할 수 있는 견실한 파트너 관계는 확실히 긍정적이긴 하지만, 사용할 수 있는 전력 회사가 맘대로 가격을 올려버리는 것과 같이 매몰 비용이 커서 절대 빠져나올 수 없는 경우라면 그 것도 기업 입장에서는 큰 리스크가 될 수도 있어 보인다(요즘 외산 솔루션의 경우는 환율 이슈에 의한 비용 증가도 크게 와 닿고 있다). 멀티 클라우드, 온프레미스 하이브리드 클라우드 등으로 여러 전략을 세울 수 있지만 해당 경우 가장 큰 부분은 비용도 비용이지만 인력도 중요하다고 생각된다. 근간 기술은 비슷하다고 생각되지만 다양한 클라우드 서비스들을 종류와 관계없이 자유롭게 전환하고, 온프레미스, 클라우드 양 쪽에 능숙한 인력을 유지하고, 탈출 계획을 세울 수 있는 체계를 구축하는 것은 여러모로 회사들에겐 쉽진 않은 숙제 같다.

1.6 마무리하면서

 어찌보면 클라우드 및 SAAS 서비스 환경은 기업들의 꿈인 플랫폼과 종량제, 부가가치에 의한 부분 유료화가 가능하게 된 영역 같다. Lock-In 효과도 강하고 어찌 봄 옛 이야기에 나오는 “봉이 김선달”의 현실 버전 같은 부러운 느낌도 조금 든다. 해당 클라우드 서비스들은 계속적으로 고객 기업들의 데이터를 활용한 부가가치들을 만들고, SAAS 전문 기업 들과의 협력을 통해서 새로운 비즈니스 영역 및 서비스를 제공하고 수익을 나누려고 하는 것 같다. 

보안적 측면에서는 사실 복잡해 보이는 그 많은 선택 지중, 우리가 명확히 관리하고 싶은 영역들에 대해서 조사하고, 경험하고, 분석하고, 의논하여 이해를 못하는 영역을 줄이고, 해당 영역에 흘러가는 데이터들에 대해서 적절한 확신을 가지고 보호를 하도록 어플리케이션, 데이터의 흐름을 설계하며, 플랫폼이나 SAAS 솔루션들이 제공하는 보안 관련 기능들을 합리적인 가격에 배치하고 모니터링 하여 사업에 충분한 안전함을 보장하는 게 최선이 아닐까 싶다. 이해하는 것만큼 세상과 선택지가 보이는게 아닐까 하는 생각을 하면서 글을 마친다.

콘텐츠 검색

  • 카테고리 선택

  • 기간 선택

    ~

(Notice!!) story.jiran.com 내의 검색 결과가 보여집니다.