가상화에 대한 짧은 단상

  지마켓 정보보안실 김용재

 

  IT세상에는 가상화에 관련된 개념이 아주 많이 존재한다고 본다. 컴퓨터의 기본 구조에서 보면, 메모리가 아주 귀했을 때 나왔을 거 같은 디스크와 메모리를 섞어 사용하는 가상 메모리부터, 반대로 하드 디스크(SSD)가 현재에 비해 아주 느렸을 때 잠시 나왔던 메모리를 디스크로 사용하는 램 디스크(이건 요즘 Redis 등 예전에 비해 많이 싸진 메모리를 기반으로 빠르게 동작하는 디비의 롤 모델라는 느낌도 든다), 예전에 CD를 이용해 게임이나 프로그램을 실행하던 때에 느린 CD 대신 디스크의 이미지로 해당 데이터를 옮겨서 CD 인 것처럼 프로그램을 속였던(아무래도 그때는 CD를 강제한 불법 복제 방지 로직을 피하는 목적들도 있었다) “Virtual CD, DAEMON Tools, cdspace” 같은 가상 CD, 자바/파이썬 등의 프로그래밍 언어가 실행되는 가상머신 환경, 메타버스, 가상 컴퓨터, 컨테이너, 클라우드 등이 모두 가상화의 개념에 속하게 될 것 같다.

 

  추가로 우리가 현재까지 컴퓨터를 이용해 자연스럽게 접하고 있는 여러 사진, 영상 등도 사실은 현실을 가상화 한 부분이라고 볼 수 있고, 해당 부분이 현재는 AI 사진, AI 영상 등으로 한 단계 더 추상화되는 느낌이 있다.

 

  가상화는 현실에 존재하는 부분을 데이터로 변화해 컴퓨터로 처리하는 세상으로 옮겨 모방, 재해석하거나, 현실은 아니지만 인간의 관념과 지각으로 현실을 대체할 수 있는 상상의 대상을 만드는 2가지의 종류가 있는 듯한다. 물론 현실에 존재하는 많은 부분도 사람의 관념적인 부분을 실제 형태로 구현했다는 측면에서는 형상화되기 전에 이미 가상화된 데이터 형태로 존재하고 있었다고 봐도 되지 않을 까는 싶다. 그렇게 생각함 요즘 뇌 과학 쪽에서 언급하듯 사람 자체가 이미 세상과 타인을 모델링하고 있지 않나 싶기도 하고 말이다.

 

 

1.1 효율성의 추구

  이전 글(IT에 대한 짧은 단상)에서 얘기했듯 IT의 가장 근간은 현실에 비해 아주 많이 빠른 처리를 하는 컴퓨터라는 존재가 있기 때문에 가능하다고 본다. 그 중에서도 현재 시점에서 CPU는 (GPU 가 조금 섭섭해할지는 모르겠지만) 태양계의 태양 같이 아직 까지는 해당 부분의 가장 기본이 되는 중심일 것이다.

 

  일반적으로 사람은 효율성을 최대화하려는 경향을 가지고 있다고 본다. 가지고 있는 시간이나 자원 등을 최대한(또는 최소한) 사용하여 최대한의 아웃풋을 내는 것을 삶의 목표로 삼고 가는 경우가 많다. 반대로 얘기되는 비움이나 미니멀리즘 같은 개념 또한 어찌 보면 완전하고, 기계처럼 확정되게 움직이지 못하고 만족하지 못하는 사람의 성향에 대한 또 다른 측면의 효율성의 추구일 수도 있다는 생각도 든다(개인적으론 이 불완전 함이 현재 완벽함을 향해서 나아가고 있는 AI에 대해 인간이 느끼는 미묘한 이질감이 아닐 까도 싶긴 하고 말이다).

 

[ 그림  2-1  용돈을 알차게 쓰기 ]

 

 

  컴퓨터 안의 효율성의 추구를 이해하기 위해 여러분이 심부름센터를 시작했다고 생각해 보자. 우선 처음엔 매출이 얼마나 될지 자신이 없을 거기 때문에, 사람을 고용하진 못하고 나 홀로 창업을 해서 상황을 보면서 조금씩 일하기 시작한다. 처음엔 실수를 방지하기 위해 한 명의 고객만을 받아 그 일을 다 처리하고, 이후 다음 고객의 일을 받아 순차적으로 일을 처리했다.

 

  근데 점점 일이 익숙해지다 보니 한 고객의 일을 처리하는 사이에 아쉽게 비어 있는 시간들이 눈에 들어오기 시작한다(예를 들어 법원에 서류를 접수하고 나면, 재판일자가 확정되기까지 멍하니 있는 것 밖에 따로 할 일이 없다. 또는 지하철을 이동하면서도 뭔가 스마트폰으로 처리할 수 있는 다른 업무들도 많을 것 같다)

[ 그림  2-2  마트 심부름 하기 ]

  이제 조금씩 멀티태스킹 모드가 되면서 한 고객으로부터 여러 개의 일을 받아서 시간시간을 나누어 채우면서 동시에 진행되는 것 같이 보이도록 일을 하기도 하고(서류를 접수하고 결과가 나오길 기다리는 중간에 다음 서류를 작성하거나, 다른 겹치지 않는 일들을 수행), 다른 업무 타입의 고객의 일을 받아서 중간중간 대기 시간에 수행하다 보니 가진 시간과 능력을 낭비 없이 쓰면서 효율적으로 개인의 리소스를 사용할 수 있게 되었다.

 

  점점 일과 매출에 자신이 붙으면서 본인과 비슷한 처리 능력을 가진 다른 직원들을 채용하기 시작한다. 이제 인적 자원을 이용하는 방법의 조합은 점점 더 다양하게 되어, 한 고객의 일을 여러 직원에게 나누어 동시에 수행하기도 하며, 여러 고객을 일을 그때그때마다 시간이 비는 직원에게 나누어서 일을 시킴으로써 회사에 있는 리소스를 최대한 사용하기 시작했다. 가끔 설문 조사 같이 완전히 병렬로 처리가 가능하지만 보유 직원 수가 안 되어 포기해야만 했던 일들은 외부의 전문적인 조사 회사한테 아웃소싱을 주고 지불하는 비용과의 차액을 벌기도 한다. 이제는 해당 프로세스가 너무 효율 적으로 돌고 있어서, 일부 놀고 있는 시간들이 빤히 보이기 때문에 좀 더 다른 일이 동시에 들어온다면 좋겠다는 생각이 든다.

 

  조금 재밌는 현상은 고객 회사에서도 비슷하게 이런 최적화를 이루려 하는 노력이 있어서, 굳이 해당 고객사의 여러 담당자들이 이 쪽에 개별로 요청을 하지 않고, 그쪽에서도 우선순위를 두어 일을 정리하여 한 사람이 맡아 이쪽에 요청하게 되었다. 전혀 기대는 안 했던 부분이지만 저 쪽도 쓸데없는 요청 채널과 처리 담당자 들 간의 커뮤니케이션 비용을 낭비하지 않고, 우리 쪽도 괜히 번거롭게 여러 담당자들을 대응하느라 시간을 보내지 않아도 되는 장점이 생기게 된 듯하다.

 

  조금 더 회사가 커지게 되자 각 직원들을 하나의 독립된 인원이기보다는 하나의 가상화된 단위로 만들면 어떨까 하는 생각이 들었다. 굳이 고객들이 우릴 특정한 개개의 사람으로 인지할 필요가 있을까? 고객들이 오라클이라는 가상의 중재 직원한테 요청하면, 우리가 각각 여유가 있을 때 오라클의 역할을 하면서 역할극을 수행하면 어떨까? 물론 이 가정은 바뀐 이 시스템이 우리가 각각 일하는 개별 상황보다 좀 더 비용이나 성능 측면에서 최대한 효율적으로 시너지와 부가가치를 일으킬 수 있다는 보장이 되어야 한다는 조건이 있긴 하다.

 

 

1.2 프로세스와 쓰레드

  앞의 심부름센터 회사(결국은 꽤 큰 컨설팅 회사가 된듯하지만) 얘기가 나름 그럴듯하게 들렸다면, 비슷한 상황이 컴퓨터의 세상에서도 마찬가지로 일어나게 된다. 처음에 만들어진 컴퓨터는 현재 있는 멀티 코어 형태의 컴퓨터가 아닌 CPU 안에 하나의 코어만 존재하는 막 창업한 1인 심부름 센터 같은 상황이었을 것이다. 해당 상황에서 처음엔 절차적으로 한 개씩의 작업을 수행하다가(아주 옛날의 긴 종이 형태의 구멍이 뚫린 테이프 입력을 사용하던 컴퓨터를 생각해 보자), 이후 점점 입력기와 처리 로직이 세련되어 감으로서(사실 이것도 유연성을 확보하기 위한 가상화라고 볼 수도 있다) 급한일을 하다 가도 시간의 여유가 생기면(컴퓨터 세상에서는 흔히 “I/O 기반 업무”라고 칭한다) 중간중간 다른 일을 끼워 넣어 할 수 있었을 것이다.

 

  프로그램은 최초에 하나의 프로세스라는 단위로 메모리 상에 만들어져 실행되게 되어 있었지만, 이후 프로세스는 내부에 작은 할 일 단위로 나눠진 쓰레드 란 서브 일꾼들을 보유하게 되었다(앞의 마지막 단계에서 나온 개인이 구분되지 않는 이상적인 오라클 일꾼의 명시적 형태라고 생각해 보자). 굳이 고객이 심부름센터에 와서 담당자와 직접 얘기하지 않아도 일만 전달해 준다면 누군가 한가한 사람이 수행할 수 있게 되듯이, CPU는 엉덩이가 무거운 프로세스라는 대상 들과 얘기하며 일을 하던 방식을 버리고, 상대적으로 가벼운 쓰레드라는 단위를 대상으로 필요한 작업을 처리하게 되었다(현재의 OS들에서 CPU는 프로세스와 직접 일을 하진 않고, 멀티 프로세싱이라 하더라도 해당 프로세스의 하나뿐인 쓰레드와 같이 일을 한다고 한다).

 

  여기에 여러 직원을 고용하게 된 심부름센터처럼 하나의 CPU 내에 여러 개의 일할 수 있는 코어가 있는 멀티 코어 CPU 가 나오게 되어 위의 프로세스-쓰레드의 관계를 조합해서 CPU 안의 코어들을 알차게 쓰기 위한 여러 전략(멀티 프로세싱, 멀티 쓰레드)들이 나타나게 된다. 또한 설문 조사 건처럼 너무 복잡하진 않지만 병렬적인 부분이 필수적으로 요구되는 부분들은 GPU에 의뢰하여 병렬로 빠르게 수행하게도 되었다.

 

  반면에 고객이 스스로 요청 건의 우선순위를 정리해 업무 효율화를 추구한 것처럼, 프로그래밍 측면에서도 CPU만 믿고 커뮤니케이션 비용을 소모하기는 싫다는 움직임에 따라 코루틴과 같이 하나의 쓰레드 만을 계속 사용하면서도 프로그램 내부적으로 중요한 업무를 “CPU 기반 업무” 인지 “IO 기반 업무” 인지를 고려해 자체 스케줄링 하여 CPU와 독립적으로 동시성 최적화를 하는 움직임도 진행되고 있다.

 

  결국 하드웨어, 운영체제, 프로그래밍 3개의 측면에서 나름 비싼 컴퓨터 하드웨어를 최대한으로 사용하여 최대의 이익을 만들어 내려는 기술적인 노력이 공동으로 일어나고 있다고 볼 수 있다. CPU는 좀 더 최적화된 명령어 배치 및 하드웨어적 연산의 효율화를 통해서, GPU는 병렬에 최적화된 다수의 프로세서 묶음을 이용한 동시 연산을 통해서, 운영체제는 프로세스와 쓰레드의 최적화된 관리를 통해서, 프로그램은 자신이 할 일들의 최적화된 의뢰를 통해서 각각 열심히 협업을 하고 있다.

 

  여기에 더 나아가서 여러 개의 CPU, 여러 개의 서버에 대해서 마치 CPU 내의 코어를 병렬 관리한 것과 비슷하게 동시성 관리를 추구하는 경우도 있게 된다(마치 여러 개의 팀으로 나누거나 여러 회사가 협력해 하나의 사람처럼 일을 하듯이 말이다). M365 나 IOS 같이 운영체제, 클라우드, 인증을 이용해 밀접하게 설계된 요즈음의 소프트웨어 환경들을 보면, 인터넷에 연결된 컴퓨터들이 누군가의 관찰 하에 마치 하나의 컴퓨터처럼 움직이는 세상이 되었다는 생각도 들기도 한다. 개인적으로는 이러한 부분들을 보면 마치 아래에 나오는 꼭두각시 인형극의 한 장면이 생각난다.

 

[ 그림  2-3  꼭두깍시 인형극 ]

 

 

 

1.3 프로세스와 쓰레드, 코루틴, GPU - 파이썬 예제

  그럼 여기서 잠시 기술적인 측면으로 넘어가서 파이썬 코드를 이용해 앞에서 얘기한 CPU, OS 측면의 프로세스/쓰레드의 동작과 프로그래밍 측면의 코루틴, GPU측면에서의 병렬 연산에 대해서 간단히 살펴보도록 하자.

 

  우선 프로세스가 무언지 살펴보자. 리눅스도 비슷하지만 윈도우 작업관리자의 세부 정보 탭을 보면 운영 체제 내부 및 우리가 사용하고 있는 프로그램에 대한 프로세스들이 다양하게 리스트업 되어 있다. 아래 작업 관리자 창의 “세부 정보” 탭을 보면 지금 이 글을 쓰고 있는 MS 워드(WINWORD.EXE) 프로그램의 프로세스도 같이 보이고 있다.

 

 

 

1) 멀티 프로세스 동작 보기

  그럼 첫 번째로 멀티 프로세스의 동작을 간단히 봐 보자. 앞서 얘기한 여러 직원들이 동시에 일을 하는 상황이다. 아래의 파이썬 코드를 보면 우리가 상황을 찬찬히 살펴보기 위한 시간을 벌기 위해서, 20회에 걸쳐 10초씩 쉬면서 자신의 프로세스 이름과 아이디를 프린트하는 “work”라는 메서드가 정의되어있다.

 

  그 아래 부분을 보면 해당 work라는 일을 하는 프로세스를 3개 생성한다(실제로는 현재의 운영 체제들은 프로세스 내에 최소 1개의 쓰레드를 만들기 때문에 해당 일이 그 쓰레드에 할당되어 CPU에게 의뢰될 것이다). 멀티 프로세스를 띄우는 파이썬 프로그램 자체도 역시 프로세스 일 것이기 때문에 가장 바깥의 메인 프로그램 코드 내에도 프로세스 이름과 아이디를 출력하게 했다.

 

from multiprocessing import Process, current_process from time import sleep   def work():     # 20회에 걸쳐 10초씩 쉬면서 루프 번호, 프로세스 이름, 프로세스 아이디를 출력한다.     for i in range(10):         print(str(i) + ": " + current_process().name + "-" + str(current_process().pid))         sleep(10)     return   if __name__ == "__main__":     # 메인 프로그램의 프로세스 이름과 아이디를 출력한다.     print("main: " + current_process().name + "-" + str(current_process().pid))       # work 프로세스를 등록 한다.     p1 = Process(target=work)     p2 = Process(target=work)     p3 = Process(target=work)         # 각각의 프로세스를 병렬로 실행한다     p1.start()     p2.start()     p3.start()     p1.join()     p2.join()     p3.join()

 

  프로그램을 실행해 보면 아래와 같이 출력이 된다.

 

c:\Python\Code\Blog>python ch2_multi_process.py main: MainProcess-3636 0: Process-1-1004 0: Process-2-8032 0: Process-3-4036 1: Process-1-1004 1: Process-2-8032 1: Process-3-4036 …

 

  이 부분을 아까 봤던 작업관리자를 통해 보게 되면 아래와 같이 4개의 파이썬 프로세스가 보이게 된다.

 

  그런데 위의 화면으로는 자세한 실행 상황을 보기가 조금 힘들기 때문에 조금 더 상황을 자세히 보여주는 MS에서 제공하는 프로세스 탐색기(Process Explorer)라는 툴을 통해서 봐 보자.

 

 

 

  해당 유틸리티로 보게 되면 메인 프로세스인 3636번을 기준으로 3개의 서브 프로세스들이 생성되어 돌아가고 있음을 트리 형태로 볼 수 있다. 첫 번째 python.exe 서브 프로세스(1004)를 더블 클릭해 Threads 탭을 보면 해당 프로세스에 속한 1개의 쓰레드(16408)가 돌아가고 있는 것을 볼 수 있다(아까 얘기했듯이 요즈음의 운영체제에서는 CPU가 프로세스와 직접 업무에 관해 대화하지 않고 쓰레드를 통해서 작업을 진행한다고 한다).

 

 

2) 멀티 쓰레드 동작 보기

  두 번째로 멀티 쓰레드 동작을 보자. 멀티 프로세스 대신 쓰레드를 사용하는 경우의 장점은 아무래도 프로세스를 왔다 갔다 바꾸면서 일하는 것보다는 쓰레드를 교체하면서 일하는 게 작업 전환 시 노력이 적게 들고, 자원도 적게 필요해 유리하다고 한다(앞의 심부를 센터에서 고객을 계속 바꿔가며 얘기하는 것보다, 고객의 일만을 추상화해서 한 사람이 교대로 처리하는 게 더 효율적인 것과 비슷하다고 볼 수 있다).

 

  다만 항상 장점만 있는 거는 아니라 쓰레드 사이의 데이터 공유가 좀 더 까다롭고, 정말로 CPU를 극한으로 쓰는 무거운 일들만 처리한다면, 절대적으로 일이 많은 한 사람이 아무리 열심히 이리저리 궁리하며 일해도 한계가 있듯이 하나의 프로세스의 처리 능력 범위를 넘어가진 못 하며, 오히려 쓰레드 전환 시의 커뮤니케이션 비용에 의해 성능이 떨어질 수 있다는 한계는 있다. 아래 코드를 보면 앞의 멀티 프로세스 코드와 거의 비슷하고, 프로세스 생성 대신에 쓰레드를 만드는 부분만 다른 것을 알 수 있다.

 

from threading import Thread, current_thread, get_ident from multiprocessing import Process, current_process from time import sleep   def work():     # 20회에 걸쳐 10초씩 쉬면서 루프 번호, 프로세스 정보, 쓰레드 정보를 출력한다.     for i in range(20):         print(str(i) + ": " + current_process().name + "-" + str(current_process().pid) + "-" + current_thread().name + "-" + str(get_ident()))         sleep(10)     return   if __name__ == "__main__":     # 메인 프로세스의 루프 번호, 프로세스 정보, 쓰레드 정보를 출력한다.     print("main: " + current_process().name + "-" + str(current_process().pid) + "-" + current_thread().name + "-" + str(get_ident()))       # work 쓰레드를 등록하고 실행한다.     th1 = Thread(target=work)     th2 = Thread(target=work)     th3 = Thread(target=work)         th1.start()     th2.start()     th3.start()     th1.join()     th2.join()     th3.join()

 

 

  역시 실행을 해보고 Process Explorer를 살펴보면 하나의 프로세스 번호(9448) 밑에 메인 쓰레드 1개(16576)와 작업 용인 서로 다른 서브 쓰레드 3개가 실행됨을 알 수 있다.

 

c:\Python\Code\Blog>python ch2_multi_thread.py main: MainProcess-9488-MainThread-16576 0: MainProcess-9488-Thread-1 (work)-16532 0: MainProcess-9488-Thread-2 (work)-4640 0: MainProcess-9488-Thread-3 (work)-1896 1: MainProcess-9488-Thread-1 (work)-16532 1: MainProcess-9488-Thread-2 (work)-4640 1: MainProcess-9488-Thread-3 (work)-1896 …

 

 

 

  ※ 참고로 파이썬(표준인 CPython)에서의 멀티쓰레드는 GIL(Global Interpreter Lock)이라는 제약이 있어서, 멀티 코어를 보유한 상태에서도 오직 한 개의 쓰레드만 동시에 동작할 수 있어서 진정한 의미의 멀티쓰레드는 아니라고 평가되고는 있다. 그래서 위의 코드는 현재로서는 타 언어에서 하나의 코어로 멀티쓰레딩을 하는 효과 정도가 있을 것 같다. 이 부분은 파이썬으로 개념을 쉽게 보여주기 위한 코드라고 생각해 주면 좋겠고, 파이썬 3.13 버전에서는 이 GIL 제약을 disable 하는 옵션이 제공(기존 라이브러리와 쓰레드 호환성 문제는 생길 수 있다)될 것이라고 하니, 수개월 후에는 이런 상황이 조금은 변할 듯도 싶다^^ 

 

 

3) 프로그램 내에서의 멀티 테스킹(코루틴) 동작 보기

  세 번째는 아까 얘기한 고객 회사 내부에서 나름대로의 우선순위를 정해 요청하는 부분을 생각해 보자. 개발 쪽에서 많이 얘기하는 보통 코루틴이나 가상 쓰레드 라는 용어가 여기에 해당될 것 같다. 코드는 앞의 형태와 비슷하게 만들게 되어있어서 count라는 메서드를 정의해서 마찬가지로 ayncio라는 쪽에 태스크를 등록한다. 역시 이것도 실행 중간에 100초의 시간을 주어 관찰할 시간을 확보했다.

import asyncio   # count 업무 정의 async def count():     print("One")     await asyncio.sleep(100)     print("Two")   # count 업무 등록해 실행 async def main():     task1 = asyncio.create_task(count())     task2 = asyncio.create_task(count())     task3 = asyncio.create_task(count())     await task1     await task2   asyncio.run(main())

 

  실행을 해보고 Process Explorer를 살펴보면 하나의 프로세스 번호 밑에 메인 쓰레드 1개만 달랑있는 상태가 보인다. 동시에 실행되고 있는 결과로 추정하기에는 아마도 프로그램 쪽에서 알아서 스케줄을 조정해 병렬 수행을 수행하고 있을 것이다. 하나 특이한 건 mswsock, dll이라는 소켓 관련 라이브러리를 이용하여 내부적으로 동시성을 관리하는 것도 같다.

 

c:\Python\Code\Blog>python ch2_ayncio.py One One One Two Two Two

 

 

4) GPU를 이용한 병렬 연산 비교하기

  마지막으로 멀티태스킹 쪽은 아니지만, 같은 병렬로 작업 속도를 높인다는 측면에서 이전 글에서 얘기한 GPU에 대한 예제를 하나 보려 한다. GPU는 얘기했듯이 CPU 보다 일반적인 연산은 느리지만, 보유한 수많은 코어를 이용해 병렬 연산에 대해서 빠르게 수행할 수 있는 컴퓨터 부품이다.

 

  아래는 CPU를 이용하는 기존 파이썬 수치 연산 라이브러리인 Numpy와 RTX 3600 그래픽 카드의 GPU를 이용하는 CUDA 라이브러리를 통해 동가의 연산을 수행할 수 있는 Cupy를 이용해 10000*10000개의 행렬에 대한 곱 연산을 수행하는 예제이다.

 

import numpy as np import cupy as cp import time   # 테스트 용 10000*10000 행렬을 만든다 N = 10000 np_matrix_1 = np.random.rand(N,N) np_matrix_2 = np.random.rand(N,N) cp_matrix_1 = cp.random.rand(N,N) cp_matrix_2 = cp.random.rand(N,N)   # 일반적인 CPU 연산을 이용하는 Numpy 라이브러리를 통해 두 개의 행렬을 곱한다. np_start = time.time() np.matmul(np_matrix_1, np_matrix_2, out=None) np_end = time.time()   # CUDA 라이브러리를 통해 GPU 연산을 이용하는 Cupy 라이브러리를 통해 두 개의 행렬을 곱한다. cp_start = time.time() cp.matmul(cp_matrix_1, cp_matrix_2, out=None) cp_end = time.time()   # 각각 소요된 시간을 측정 한다. print("NP runtime: " + str(np_end - np_start)) print("CP runtime: " + str(cp_end - cp_start))

 

  위의 코드를 실행하면 실행할 때마다 아마도 캐싱 등에 따라 시간은 좀 차이 나지만, 아래와 같이 CPU에 비해서 꽤 빠르게 실행되는 GPU의 모습을 볼 수 있다. 다른 한편으로는 이렇게 보니 코어 수는 RTX 3060 모델의 3584개와 비교할 때 물리코어가 6개인 CPU(597배 차이)가 속도는 10 배 정도밖에 차이가 나지 않아서 CPU 도 게임으로 따지면 수많은 GPU 군사들과 대적할 수 있는 소수의 일당백의 에픽 무장 들이라고도 볼 수 있을 듯도 싶다^^;

 

c:\Python\Code\Blog>python numpy_vs_cupy.py NP runtime: 7.810051202774048 CP runtime: 0.9222331047058105

 

 

1.4 가상 머신

  그다음의 가상화 단계는 개인적으로는 여러 프로그래밍 언어에서 나온 가상머신 개념이라고 생각한다. 자바나 파이썬, 요즘의 .NET CORE 같은 언어들은 윈도우, 리눅스 등 종류에 상관없이 공통의 코드 실행이 가능한 표준 가상 환경을 제공하여 동일한 코드로 동일한 동작을 하도록 지원한다. 다만 해당 부분이 100% 호환이 라기보다는 “OS의 설계에 맞춰서 최대한”이라고 하는 것이 맞을 것 같다. 예로서 앞에서 봤던 멀티 프로세싱 관련 코드는 윈도우와 리눅스 상에서 운영 체제가 서로 멀티 프로세스를 처리하는 방식이 달라서 실제 만들어 보면 조금은 상이하게 동작하기도 한다.

 

  또한 “종류에 상관없이”라는 부분도 실제로 해당 언어를 유지 보수하는 쪽에서 특정 OS 와의 호환성에 맞춰 표준 환경을 만들어 배포하겠다는 의지와 리소스가 있어야 가능한 것 같다. 그래서 이상적으로는 OS 종류와 관계없이 돌아가야 하겠지만, 실제 적으로는 지원하는 OS에 한해서 최대한 비슷하게 가 맞을 것은 같다.

 

  왜 이 부분을 가상화에 있어 의미 있는 부분이라고 생각하냐면, 이 경우 처음에는 속도 측면에서는 컴퓨터 아키텍처에 맞춘 기존의 C 보다 느려 비효율 적이라는 얘기도 있었지만, 결국은 하드웨어의 발전으로 해당 우려는 사라졌고, 프로그램이라는 것이 컴퓨터 아키텍처와 별개로 임의의 논리적인 형태로 존재하고 실행될 수 있는 가상적인 존재라는 것을 자연스럽게 받아들이게 된 계기라고 생각한다. 더 나아가 프로그램이 이렇게 가능하다면 그 프로그램을 실행시키는 OS 또한 프로그램이다 보니 마찬가지가 아닐까라고 생각하게 되지 않았을까 싶다.

 

  처음엔 각각 개별의 충전기를 사용해 사용하던 부분이 하나의 멀티 충전기로 여러 개의 다른 장비를 충전할 수 있게 됐 듯이, 컴퓨터 안의 논리적인 특정 객체로 형상화할 수만 있다면 컴퓨터 아키텍처의 종류, OS의 종류와 관계없이 유연한 소프트웨어 형태로 존재할 수 있다고 생각하게 된 부분이 현재에 추구되는 가상화와 비슷하지 않은가 싶다(마무리 작업을 하다 보니 플스, 엑스박스, 스위치, 모바일, PC, 등 여러 플랫폼에서 돌아가는 게임 타이틀이 더 적절한 비유일 듯도 싶다^^).

 

[ 그림  2-4  멀티 충전기 ]

 

 

 

1.5 가상 컴퓨터

  그다음의 가상화 단계로 Hyper-V 나 VirtualBox, VMWARE, Nutanix 같은 툴로 가상화된 컴퓨터가 있을 것이다. 앞의 심부름센터 얘기로 돌아가 보면 충분히 능력이 있는 특정한 사람이 있어서 일인 다 역을 수행하고 있다고 생각해 보자. 뭐 변장을 할 수도 있고 여러 온라인 커뮤니케이션 툴을 이용해서 이러한 역할을 할 수 있다(요즘 많이 이슈가 되는 로맨스 스캠 같은 경우도 먼 곳에서 사기꾼들은 이런 행동을 하고 있다고 볼 수 있다. 사기를 당하는 사람은 너무도 자연스럽게 서로 다른 사람처럼 바꿔가며 동시에 일을 수행하는 스파이의 행위 때문에 여러 명을 동시에 만나는 것으로 착각하고 만남을 지속하게 될 것이다).

 

[ 그림  2-5  일인 다 역의 스파이 ]

 

 

 

  점점 컴퓨터의 성능이 빨라지게 되며 많은 가동 시간 동안 앞에 얘기한 프로세스, 쓰레드, 코루틴 등이 한가하게 놀고 있을 때쯤 가상화라는 화두가 점점 실제로 상용화가 되면서, 윈도우 컴퓨터에서 리눅스와 윈도우를 동시에 돌린다거나, 맥 컴퓨터에서 윈도우를 동시에 돌리는 등의 가상화 기술과 소프트웨어들이 생겨나기 시작했다(사실 이것 이전에도 시간적으로는 현대의 가상화 환경처럼 동시적으로 동작하는 건 아니지만 멀티 부트 로더나 고스트 같은 OS 이미지의 백업, 복원 소프트웨어를 통해 여러 종류의 윈도우나 리눅스로 자유롭게 부팅을 하거나, 시스템의 특정 시점으로 복원하는 일도 유행했다. 이 부분들도 현대적 가상화의 전 단계라고 볼 수 있을 듯은 싶다).

 

  추가로 하나의 컴퓨터 안을 나누어 여러 OS를 동시에 돌리던 부분에서 확장하여, 여러 컴퓨터 하드웨어를 최적화하여 그룹 형태로 구축 후, 다양한 OS 들을 해당 환경에서 생성하고 통합하며 관리하는 솔루션 들도 만들어졌다. 소프트웨어를 이용해 여러 물리적 컴퓨터 환경을 연결하는 가상화를 만들었다고 볼 수 있다. 물론 근래의 많은 NoSQL, 클러스터링 기반의 서비스들이 해당 부분을 비슷하게 구현하여 사용하지만, 이 여러 서버들을 합쳐 구축한 운영체제의 가상화부터 많은 사람들이 서버 군을 이용한 가상화에 익숙하게 되지 않았나 싶긴 한다.

 

  다만 이런 가상화가 가능하게 된 근본적인 이유는 이전 글에서 얘기했 듯 컴퓨터 세상이 결국은 0과 1의 데이터로 이루어졌기 때문이 아닐까 싶다. 우리가 인지하는 여러 컴퓨터 부품들도 물리적 형태를 띠고 있기 하지만 하는 일은 정보의 저장 및 처리에 특화되어 있다. 그래서 여러 물리적인 컴퓨터 부품들의 데이터 저장 및 처리 과정을 실제 물리적인 구조와는 다르지만 비슷한 차원에서 흉내 낸다면 우리가 신기하게 생각하는 가상의 컴퓨터가 물리적인 컴퓨터 안에서 돌아가게 되는 일이 생기는 게 아닐까 싶다(유닛 테스트 쪽과 비교한다면 테스팅 어플의 스텁과 드라이브 같은 존재라고 할까).

 

  또한 우리가 생각하는 컴퓨터 부품이라는 것도 어찌 보면 몇 가지 분류로 비슷비슷한 감이 있다. 만약 램, SSD, 하드디스크, 레지스터 등의 속도와 가격이 비슷비슷 해지는 상황이 생긴다면 언젠간 현재의 메인 보드의 역할은 축소되고 하나의 칩 안에서 연산, 저장, 디스플레이 등의 모든 역할을 수행하는 세상이 올지도 모르겠다. 역시 이 부분도 컴퓨터 세상의 모든 것이 데이터를 처리하는 행위이기 때문에 가능한 부분이 아닐까 싶다.

 

 

  다시 가상 컴퓨터 얘기 쪽으로 가면 이러한 가상화의 단점은 아무래도 구현된 대상이 가짜라는 것이다. 앞에서 본 컴퓨터 내부의 가상화도 마찬가지지만 실제 많은 경우 너무 스위칭이 빨라서 동시에 일어나는 것처럼 보인다는 것 이외에는(멀티 프로세싱은 조금 논쟁이 있을 듯하지만), 아무리 컴퓨터가 빠르더라도 상황에 따라 서로서로 영향을 미치게 될 가능성이 있다. 그래서 보통 비슷한 성능으로 표시되는 가상 컴퓨터는 물리 컴퓨터에 비해서 성능이 어느 정도는 떨어진다는 단점이 있다. 또한 현재의 OS와 다른 타입의 OS 나 다른 CPU 아키텍처에서만 동작하는 OS를 가상화하여 돌린다면 실행하는 하드웨어와의 최적화 이슈 때문에 더욱더 단점이 두드러지게 될 것이고 말이다(컴퓨터에서 돌리는 최신 기종의 게임 에뮬레이터를 생각해 보자).

 

  추가로 개인이 아닌 상용으로 간다면 최대한 묶여 있는 컴퓨터 들을 알차게 써야 되는 입장에서 이러한 단점 부분은 아마 조금 더 두드러지게 될 것이다. 다만 멀티 프로세스나 쓰레드 등의 병렬처리 방식이 IO 기반 업무의 동시 처리에서는 큰 유용성을 가지 듯이, 개개의 가상 서버들이 평소에 많은 연산을 집중적으로 사용하지 않는 다면 여러 컴퓨터들을 묶어 그 보다 더 많은 수의 가상 컴퓨터들을 만들어 알차게 사용할 수 있는 방법이 될 수 있는 건 분명하기 때문에 많은 기업들이 사용하지 않을까 싶다.

 

 

1.6 컨테이너

  현재는 도커 또는 쿠버네티스로 대표되는 컨테이너는 어찌 봄 앞에서 얘기한 이상적인 심부름센터의 인력 활용 모델이 구현된 것이라고 볼 수 있다. 실제 컴퓨터 내부에서의 코어와 프로세스, 쓰레드, 코루틴의 어울림 과도 비슷해 보이고 말이다.

 

  기존의 컴퓨터에서 무거운 프로세스를 대신에 쓰레드가 주요 작업을 수행했던 것처럼, 앞의 가상 컴퓨터와 비슷하지만 OS 전반의 대부분의 역할들은 메인 OS와 공유해 이용하면서 컨테이너 실행을 위한 최소의 부분만을 별개로 가상화해서 돌아간다는 것이다. 집으로 따지면 하나의 공간을 나눠 여러 개의 집을 만들어 사용하다가, 공용 공간을 과감히 같이 쓰고, 민감한 개인 방만 따로 만들어 사용하는 셰어 하우스 같은 느낌이다. 개인적으로는 OS에 대부분의 역할을 맡기고 프로세스 단위로 돌아가던 기존의 멀티태스킹을 조금 더 큰 실행 범위로 모듈화 해 구성하여 돌아가고 있다는 느낌도 있다.

 

[ 그림  2-6  공통 기능을 공유하고 서로 다른 부분만 신경 쓰기 ]

 

 

  이러한 과정에서 앞에서 얘기한 가상 이미지의 장점을 십분 활용해서, 레고 블록처럼 기능을 필요한 기능 등을 모듈 별로 조합하거나, 표준 화 하거나, 손오공의 분신처럼 복제하거나 등등 작은 어플리케이션 실행 환경 조각들이 자유롭게 움직이게 할 수 있다. 앞의 가상 컴퓨터와 비교해 본다면 OS에서 각각 수행하던 연산들이 사라지기 때문에 좀 더 같은 리소스 상에서 많은 개별의 가상 컴퓨터들이 수행 가능한 효과를 가지게 될 것이다. 다만 해당 경우 중심이 되는 실제 OS의 부하가 증가될 터이지만 결과적으로 기존의 각각의 가상 OS를 돌리게 되는 행위보다는 몇몇 측면에서 더 효율 적이기 때문에 이런 기술이 각광을 받지 않게 되지 않았을까 싶다.

 

  이렇게 모듈화가 됨으로 서 사실 우리가 프로그램 영역에서 사용하던 여러 해결 방식들을 끼워 넣어 활용할 수 있게 된 것 같다. 어찌 보면 하드웨어라는 딱딱한 영역으로 생각됐던 영역이 비로소 프로그램의 일부 조각처럼 부드럽게 추상화된 일이 생긴 것도 같다. 그렇게 됨으로 서 해당 구조와 인터페이스를 통해서 마치 우리가 소프트웨어를 설계하 듯이 컨테이너를 만들고 띄우고, 조절하고 하는 일이 가능하게 되었다고 본다.

 

 

1.7 클라우드

  마지막으로 클라우드에 대한 얘기를 해보자. 클라우드는 앞에 얘기한 모든 가상화를 모아 놓은 종합선물 같은 느낌이다. 윈도우, 리눅스, 안드로이드, IOS 같이 사람들이 인지하는 정식 OS같이 취급은 안 되지만, 앞의 가상화로 이루어진 많은 기술들을 수많은 API를 통해서 컨트롤하는 여러 집합 서버 간의 가상화된 OS라고 생각한다. 이것은 일반적인 OS가 제공하는 API들을 통해서 다른 어플리케이션들과 커뮤니케이션하는 것과 비슷하다.

 

  클라우드는 굳이 나누자면 프라이빗과 퍼블릭으로 나누는데 한쪽은 솔루션 기반, 한 쪽은 서비스 기반이라고 볼 수 있을 것 같다(물론 프라이빗을 오픈 소스만으로 구축해 매끄럽게 운영하는 회사들도 있겠지만 그런 회사들은 아마 클라우드 사업을 스스로 수행할 만큼 인력, 회사의 규모나 커스터마이즈에 대한 시행착오가 충분히 쌓인 회사일 것 같다).

 

 

  프라이빗 클라우드는 서버 팜은 해당 회사에서 준비하고 클라우드 운영을 지원하는 솔루션을 구입 또는 구축해서 운영하는 형태이다. 그래서 모든 물리적인 비용은 기존과 비슷하게 지불하면서도 앞에 나온 가상화 기술들을 통해 시스템 리소스를 최대한 가용하려 하는 방식이다. 라이선스에 따라 다르겠지만 해당 가격이 어느 정도 합리적이라면(아마 퍼블릭 클라우드에 비해 경쟁력이 있어야 하니 웬만하면 그렇게 포지셔닝을 할 것은 같다) 퍼블릭에 비해서는 비용적으로 유리한 측면이 있을 것 같다.

 

  다만 평소의 운영 측면이나 장애 시의 빠른 대응 등 많은 부분에 있어서는 실제 운영하는 인력의 능력이 중요한 키 포인트가 될 것이다. 만약 스스로 구축한 환경이라면 해당 부분에 대한 의존도가 더 높아질 터이고, 관련 주요 인력의 퇴사 등은 향후의 운영 고도화 및 안정성에 크리티컬 한 영향을 미치게 될 것이다. 다만 솔루션 자체는 아마 서포트하는 회사의 태도나 기술력에 따른 편안함의 차이는 있겠지만 안정적인 운영은 보장될 것이다. 다만 항상 그렇지만 다른 솔루션으로 단기간 옮기기에는 현실의 많은 어려움이 따르기 때문에, 해당 솔루션의 가변적인 라이선스 정책 변경에 따른 비용 리스크는 생각해야 한다.

 

 

  반대로 우리가 일반적으로 클라우드라고 얘기하는 퍼블릭 클라우드는 우리가 집에서 전기나 가스를 사용하거나 OTT를 매달 구독하여 이용하는 개념과 비슷하다. 각자의 회사에서 IDC 내에 물리적으로 서버나 네트워크 장비를 구축해 내-외부 인원들이 직접 운영하던 형태에서, 물리적 구성이나 유지 운영은 클라우드 회사 쪽에서 책임지고, 해당 구축된 서비스에 대해 다른 구독 서비스와 비슷하게 이용한 양만큼만 비용을 지불하면서 사용하게 된다고 볼 수 있다.

 

[ 그림  2-7  서비스의 사용 ]

 

 

  그래서 온프레미스가 아닌 퍼블릭 클라우드를 사용할 때의 서비스 안정성에 대한 걱정 또한 기존의 다른 영역들과 비슷하다. 재난 지역에서 수도나 전기 서비스가 끊겨 사람들이 고생하는 경우 같이 만약 해당 서비스의 안정성을 보장할 수 없다면 우리는 해당 서비스에 의존한 생활을 하지 못하게 될 것이다.

 

  사실 언제든 해당 서비스가 멈춰버려 우리에게 불편을 줄 가능성은 가능하지만, 우리는 클라우드 사업을 하는 회사를 믿고 그 불편한 사건이 아주 드물거나 짧게 일어나거나, 해당 회사에서 SLA에 따른 적절한 보상을 해줄 것이라고 일반적으로 기대한다(다만 분쟁이 났을 때 고객사에서는 계속 해당 환경을 써야 되는 상황도 있고, 볼 수 있는 데이터도 제한적이기 때문에 책임 소재를 가리거나 증명하기는 애매해 보이긴 한다).

 

  또한 현실 상 회사의 규모나 전문 인력의 경험 면에서도 클라우드 운영 회사가 대체로 서비스를 받는 회사보다 클 가능성이 높은 상황이기 때문에, 메이저 통신 회사나 전력 회사의 서비스처럼 문제가 날 가능성은 아주 적긴 하지만, 그렇다고 또 아예 없다고는 할 수도 없다. 하지만 그게 또 자체 운영할 때의 리스크 보다 크다고는 할 수는 없는 상황이기 때문에 참 애매한 영역이라고 본다.

 

  앞에서 말한 것처럼 퍼블릭 클라우드 회사는 개별로 운영할 경우 시간, 작업 성격에 따라 여유 자원이 남아 있을 수 있는 서버 및 네트워크 자원들을 묶어 가상화하여, 규모의 경제를 획득하려 한다. 가상화는 하드웨어들이 소프트웨어 차원으로 추상화된 부분이기 때문에, 기존에 소프트웨어 영역에서 그랬듯이 쌓여진 지식을 이용해 자동화하고, 현재의 AI와 같은 데이터 이용 측면에서의 부가가치를 만들어 낼 수도 있게 되었다.

 

  단순한 측면에서 보면 규모의 경제로 인한 운영 비용의 감소일 수도 있고, 컨테이너의 실행에서 그랬듯이 많은 공통 기능을 고객 회사들이 같이 사용하게 되어 전체적인 클라우드 OS 레벨의 효율화 일수도 있고, SAAS와 같은 측면에서는 앱스토어나 플레이스토어와 같은 플랫폼 수익일 수도 있을 것 같다. 또한 클라우드 시스템을 돌아다니는 고객사의 많은 데이터를 법적인 테두리 안에서 중계하거나 해당 패턴을 분석하여 부가가치를 일으킬 수도 있게 될 것 같다.

 

 

  그럼 클라우드 환경에서 만날 수 있다고 생각되는 몇 가지 이슈들을 살펴보고 마무리를 해보자.

 

1) 고정적이지 않은 비용

  (퍼블릭) 클라우드에서 가장 개인적으로 화두가 되는 부분은 움직이는 비용이라고 본다. 게임센터에서 제한된 코인을 가지고 게임을 클리어해야 하는 것처럼 운영하는 입장에서는 최소의 금전적 투입을 통해서 최대의 금전적 이익을 얻어야 하는 숙제가 주어진다. 많은 경우에 API 호출 수, 데이터 양, 서비스 옵션 등 클라우드를 사용하려는 시스템의 규모 및 데이터에 비례하기 때문에 상황에 따라 가변 적이다. 실제로는 어떨지 모르겠지만 SAAS로 얘기되는 여러 서드파티 소프트웨어 또한 결국은 클라우드 시스템의 리소스를 사용하여 제공되는 서비스 이기 때문에 비슷하게 태생적으로 기존 온프라미스 같은 고정 비용으로는 제공이 힘들지 않을까 싶다(반대로 요즘은 온프라미스 요금도 이런 형태를 따라가려는 움직임이 많아진 듯하다. 약간 게임 회사들이 부분 유료화 게임의 BM을 추구하던 시기를 보는 느낌도 조금 있다).

 

[ 그림  2-8  코인 플레이 ]

  사실 이러한 비용의 예측은 클라우드 회사의 원가 구조, 성장 목표, 서비스를 이용하는 회사들의 데이터 구조, 비즈니스 형태, 범위, 인력의 숙련도 등에 따른 내-외부 변수가 많아 보이기 때문에 제공하는 컨설턴트 엔지니어 쪽에서도 정확히 추정 제시가 힘들 듯하다. 반대로 서비스를 이용하는 고객 입장에서는 자신의 회사의 가상 자원들로 일어나게 될 트래픽과 데이터를 각 클라우드의 비용 정책 및 클라우드 운영 구조와 매칭하여 정확하게 이해하지 못하면 관련된 요금 체계 때문에 예상 못하는 돌을 맞게 되는 수도 있다. 현실의 다른 분야의 예를 하나 들면 “주거용 오피스텔의 수도 요금의 경우 전입 신고 후 세대분할 신고를 거쳐 예외적으로 더 저렴한 가정용 요금으로 계산되지만, 1인 기준 정도의 사용량(월 17톤) 이상부터는 다시 상업용 요금으로 부과된다” 와 같은 수많은 미묘한 규칙들이 클라우드 서비스 안에 숨어 있을 수 있다.

 

  해당 비용은 서비스의 호출 수, 데이터 규모에 따른 비례 또는 볼륨 비용, 가상 서버의 코어, 메모리 양, 연속 운영 시간, 여러 가지 서비스 옵션, 내장 또는 서드파티 기능 사용 여부(이 경우 아쉽게도 대부분 기존부터 해당 솔루션 분야의 노하우를 축적한 전문 서드파티 쪽의 기능이 현실적이고, 선택권이 풍부한 경우가 많은 듯하다), 네트워크 영역 별 트래픽 요금의 상이성, 사용자 수, 어플리케이션 엔터티 수 등 다양한 규칙에 의해 클라우드 스스로나 사용하는 SAAS 어플리케이션과의 조합에 의해 비용이 설계되어 있다. 결국 서비스를 이용하는 고객 회사는 이러한 구조 상의 요금 체계의 민감성을 이해하면서, 자신의 회사의 자원 중 클라우드로 올라가는 자원들과 그 자원들과 데이터를 주고받게 되는 클라우드 외부 자원 및 사용자들을 같이 고려해서 비용을 예측해야 하는데, 여기까지만 얘기를 들어도 그렇게 쉬워 보이는 주제 같진 않다.

 

  또 이러한 비용들이 기존의 고정 자산+운영 비용의 영역에서 운영 비용으로 성격이 바뀌기 때문에 재무적, 기술 운영 측면에서도 미묘한 사고적 전환이 필요하지 않을까 싶다. 클라우드 내부의 비용 관련 모니터링, 비용 설계 툴, 커스터마이즈 된 SAAS 툴들을 통해 이러한 부분을 파악하고, 예측하고, 절감할 수 있다고는 하지만, 아직까지는 전체적인 파악 및 조정을 하는 것은 사람의 역량과 손을 많이 타는 분야가 아니지 싶다(누가 실시간으로 자신의 통장에서 무제한으로 돈이 빠져나가는데 그걸 로직도 확실히 파악이 힘든 자동화에만 맡겨 둘 수 있을까? 그리고 자동화는 수동화가 가능한 사람이 자동화도 가능하다고 본다). 개인적으로는 핸드폰 요금 같은 선택이 가능한 어느 정도의 명확한 범위의 고정형 요금이 있거나 가격의 영향을 주는 요소가 좀 더 줄어든다면 좀 더 서로 좋지 않을까 생각하지만, 현재로서는 해당 부분은 좀 요원해 보인다.

 

  참고로 클라우드에 따라 예약 가능한 자원 사용량을 특정 기간 설정하면 해당 예약 구간의 요금에 따라 비용을 할인해 주는 선물 또는 선결제 비슷한 제도도 있는 것 같다. 하지만 조금 아쉬운 부분은 해당 부분이 어떻게 보면 변화하는 사용량에 대해서 고객 쪽에서 스스로 예측해야 하는 부담을 안겨주는 측면이 있을 듯하고(해당 요금에 대해서 컨설턴트 쪽에서 강하게 특정 임계치를 추천하기는 꽤 부담스러울 듯하다), 또 불완전한 무제한 요금제 같이 모든 영역에 대해서 적용되는 건 아니고 아마도 클라우드 회사 내부의 여러 사정에 의해서 특정 서비스 및 특정 리소스를 대상으로 제한되는 것도 같다. 무엇보다 유연함을 표방하는 클라우드에서 고정 비용을 매력적으로 보이게 만드는 요금 설계가 조금은 아이러니한 느낌도 있다. 하지만 솔루션 계약 같은 경우에도 1년 계약보다는 다년 계약을 할 경우 요율 동결이나 추가 할인을 해주는 경우도 있으니, 마찬가지로 장기간으로 고객을 계약으로 묶는 대신 비용 할인을 제공하는 제도로 생각하면 어떨까 싶다. 뭐 아마 클라우드 회사 쪽도 안정적인 매출을 보장하는 특정한 안전장치들이 필요하지 않을까 싶으니 말이다.

 

 

  추가로 이런 비용 문제를 어렵게 만드는 부분은 클라우드 운영회사와 서비스 사용 회사가 항상 서로 반대의 입장에서 절감과 성장, 효율화 사이에서 줄다리기를 한다는 것이다. 양 쪽 다 계속 성장하는 환경이라면 규모나, 영역의 확장을 통해 이 부분이 적절한 협의를 통해서 쉽게 해결이 될 가능성이 높지만, 한쪽은 조금이라도 더 얻어야 하는 상황이고, 한쪽은 조금이라도 더 줄여야 하는 제로섬 게임의 상황이라면 갈등 요소의 상황이 생길 수도 있을 것 같다.

 

[ 그림  2-9  시소 게임 ]

 

 

  개인적인 생각으로는 적절한 상황 판단에 의해 서로 윈-윈 하는 가격 협상으로 상호 합리적인 이익을 가져오게 하는 게 낫긴 할 터이지만 세상일이 꼭 그렇진 않을 것 같긴 하다. 온프라미스 서비스 또한 물가 상승 분의 반영이나 회사 성장 목표에 따른 가격 협상 갈등은 있을 터이지만, 부가가치 및 다른 SAAS 서드파티 회사들과 연동되어 움직이는 클라우드 서비스만큼의 변수가 생기긴 힘들다고 본다.

 

 

2) Lock-in 효과와 하이브리드, 멀티 클라우드

  클라우드 쪽에서 고객에게 제공되는 가상화 위 쪽 환경은 기존의 온프라미스와 그렇게 다르지 않은 어플리케이션의 영역이겠지만, 그 밑은 수많은 API로 이루어진 하나의 가상 OS이기 때문에 현재의 다른 OS와 비슷하게 호환성 문제가 생긴다고 본다. 그래서 커피머신의 호환 캡슐 같은 lock-in 효과가 있고 마치 리눅스로 운영되는 서비스 들을 윈도우로 전환해야 할 때의 머리 아픔처럼 무언가 클라우드에 종속되는 느낌이 강하다.

 

  온프라미스도 마찬가지라고 생각될 수도 있겠지만 그쪽은 만약에 이동이 필요하다면 IDC의 위치와 내부 공간 구조 이외의 나머지는 모두 표준화에 가깝게 정리가 되 있다고 생각하기 때문에 쉽지만은 않겠지만 물리적 스위치나 서버들, 방화벽 등 관련 규칙들을 모두 하나하나 조심스럽게 옮겨서 똑같이 다른 IDC의 형태로 재구성할 수 있을 것이다(물론 이런 물리적인 행동들을 소프트웨어적으로 수행할 수 있기 때문에 클라우드의 기민성이 생기기는 한다).

 

[ 그림  2-10  커피 머신과 호환 캡슐 ]

 

 

  이러한 부분을 해결하기 위해서 보통 몇 가지 선택을 하는 듯한데, 요즘 한참 얘기되는 멀티 클라우드(퍼블릭-퍼블릭, 퍼블릭-프라이빗 조합 등)나, 온프라미스-클라우드 병행 운영을 통해서 의존성을 해결하려 한다. 이런 경우 사실 관리 대상의 다양 성에 따른 리소스 투자 문제가 생길 수 있다. 멀티 클라우드 전략의 경우 각각의 클라우드에서 제공하는 고유 기능만을 사용할 경우에는 차후 마이그레이션 시의 호환 문제나 운영 방식 간의 상이함이 생길 수 있기 때문에 테라폼 같은 IaC(Infrastructure as Code) 같은 툴로 각 클라우드의 API를 비슷하게 매칭해 이용해 해결하거나, VMWARE 나 Nutanix 같은 여러 가상 컴퓨터 솔루션이나 쿠버네티스 같은 컨테이너 환경 같이 관리 API 나 인터페이스의 표준화를 제공하는 솔루션들을 이용하여 운영 표준 및 혹시 모를 마이그레이션 문제를 해결하려 한다. 여기에 추가로 테라폼, Ansible 같은 자동화 스크립트를 통해 표준화된 API를 한번 더 감싸 자동화하려고도 하는 듯하다.

 

[ 그림  2-11  바벨탑 ]

 

 

 

  현재 상황으로는 각각의 클라우드 회사들이 윈도우, 리눅스의 상황과 비슷하게 멀티 클라우드를 쓰는 고객들을 위해 운영의 인터페이스의 표준화를 협의할 가능성은 거의 희박하다고 보기 때문에 IaC 툴의 사용은 각 클라우드에서 외부에서 원하는 API를 기능적, 보안적인 부분을 고려해 얼마나 외부에 제공할 수 있느냐에 따라 호환성의 문제가 해결된다고 본다. 또한 가상화 솔루션이나 컨테이너 환경은 보통 상업 적인 비용이 추가로 들기 때문에 해당 밴더의 가격 정책의 변경에 따른 민감성의 리스크가 생길 가능성이 있다고 본다(물론 IaC 툴 또한 마찬가지 이슈는 생길 수가 있다). 개인적으로는 약간 주제와 별개로 클라우드 위의 가상화 솔루션이나 컨테이너 환경의 경우 가상화 위에 올라간 가상화의 느낌이 있기 때문에 해당 부분이 성능적으로는 어떤 영향을 미칠지, 또는 해당 이슈를 어떻게 풀었는지가 조금 궁금하긴 하다.

 

 

3) 표준화에 따른 Ready-made 옵션들

  앞서 얘기했듯이 클라우드는 많은 선택이 있는 것처럼 보이기도 하지만, 궁극적으로 구독 서비스처럼 하나의 인터페이스를 가지고 수많은 타입의 고객들을 만족시켜야 하는 종합 SAAS 형 OS 서비스에 가깝기 때문에 다양성을 가지면서도 표준화를 추구할 수밖에 없다고 본다(결국 내부에서 볼 때 모든 외부 요소들은 클라우드 회사에서 제공하는 내부 API의 구독자 일 것 같아서 말이다). 그래서 마치 자신에게 맞는 최신 컴퓨터를 세팅하듯이 적절한 옵션과 가격, 유-무료 소프트웨어를 조합하여 사용할 운영 환경을 결정해야 한다. 이러한 옵션은 클라우드 환경과 고객 사의 환경, 여러 오픈소스 및 기술 프로세스 분야(DevSecOps 등)에 대해서 모두 잘 이해를 해야 제안 및 결정이 가능한 부분이기 때문에 수많은 클라우드 회사 내-외부의 전문 컨설턴트들이 활약하게 되는 영역인 듯싶다.

 

[ 그림  2-12  쿠키 고르기 ]

 

 

  반대로 가게를 실제 운영하는 경우와 마찬가지로 일부러 전략적으로 선택하지 않는 이상은 너무 많은 메뉴 조합의 제공은 여러 불필요한 리소스 낭비와 예외가 생길 수 있으므로, 축적된 경험 및 내부 연구를 토대로 여러 고객사의 케이스에 최대한 만족될 수 있는 조합을 표준화하고 확장하게 될 것이다. 이것은 한편으로는 특정 클라우드에 인증된 제품 군 이라든지, 안정 성과 이슈 팔로우업이 가능한 주요 파트너 사라든지 하는 개념의 형태로도 나타날 수 있다. 다만 해당 부분은 반대 측면에서 보면 기술적으로는 탄탄하지만 대응 규모가 작거나 손익 계산이 안 맞는 작은 서드파티 회사들이 클라우드 환경에 참여하는 최소한의 장벽이 됨으로써 고객들이 온프라이스에서 선택 가능했던 옵션들이 줄어드는 상황을 만들 수도 있을 것은 같다.

 

[ 그림  2-13  표준화 ]

 

 

 

4) 자동화

  앞서 얘기했듯이 가상화는 곧 소프트웨어 형태의 구현체와 데이터를 의미하기 때문에 클라우드를 선택했다는 것 자체가 이미 자동화를 적극적으로 이용하려 한다는 의미와 동일하다고 생각한다(만약 그러지 않는다면 자동차를 사서 굳이 손으로 밀어 움직이려 하는 상황과 비슷하다고 본다). 다만 그 자동화가 앞서 말한 API로 이루어진 닫혀 있는(요건 외부적으로 느껴지는 클라우드의 개방적 느낌과는 좀 모순이 되는 것도 같긴 하다^^) 클라우드 세상이라는 한계상 자동화의 기능과 범위는 내부적인 이슈로 점점 깊게 들어가게 되면 그 지원하는 API를 벗어나진 못할 것이다.

[ 그림  2-14  자동화 ]

 

 

  또한 기존의 많은 솔루션 및 OS의 API 들과 동일하게, 보안 및 전체 시스템의 안정성이라는 공익을 고려한다면 모든 API를 고객의 자동화 모듈에 제공할 수는 없다(물론 클라우드 내부 시스템에서는 아마 권한을 제어해 잘 사용하고 있을 것이다). 그래서 아마도 각 클라우드 내부에서 지원하는 자동화 툴보다는 외부에서 실행되는 자동화 툴 쪽이 내부에 접근할 수 있는 영역이 좀 더 좁을 수도 있을 것도 같다. 아무래도 클라우드 내부에서 지원하는 자동화 툴 쪽이 외부 인터페이스 영역만 공개한 채로 클라우드 좀 더 내부에 꽁꽁 숨겨놓은 API 나 데이터에 접근이 가능할 것 같기 때문이다(또한 아쉽게도 해당 내부 자동화 툴은 해당 클라우드에서만 폐쇄적인 표준일 가능성이 아주 높을 것이다). 물론 내부 자동화 툴이 외부의 서드파티 툴로 전체 인터페이스를 또 한 번의 API를 통해 제공할 수도 있을 가능성은 있다.

 

  또 자동화를 사용한다는 것은 역으로 특정 사람이 의도적으로 설계해 놓은 작업 들이 내부 API를 통해 대량으로 패턴화 해 일어난 다는 것이기 때문에 실수를 했을 때 역시 대량으로 문제가 일어나거나 모니터링 및 가역적 조치가 힘든 상황이 생길 수가 있다고 본다. 그 과정에서 과도한 자원의 실행이나 소모에 따라 추가 비용 이슈가 생길 수도 있고 말이다. 그래서 관련 자동화 프로세스를 설계할 때는 앞서 비용을 따질 때와 비슷하게 클라우드 및 본인 자신의 회사 환경을 잘 이해하는 세심한 주의가 필요할 듯도 싶다.

 

 

5) 기다림에 대한 미학

  앞서 얘기했듯이 클라우드는 많은 부분이 고객들에게는 숨겨져 있다. 운영 및 보안 적으로는 “공동 책임 모델”이라는 이름으로 정리되어 있는데, 서로 영향을 미치게 되어 신경 쓰게 하지 말고, 필요하고 잘할 수 있는 영역을 나누어 잘 관리하자는 것이다. 이는 당연히 일반 SAAS 서비스 영역에서도 비슷하게 설계되어 있다.

 

  이 모델은 클라우드 사용자들이 안전한 환경에서 선택과 집중을 하는데 도움을 주는 좋은 방식이지만, 역으로 이 때문에 가시성 및 조치 가능성 문제가 생길 수도 있는데, 이는 우리가 집에서 인터넷이 안될 때 통신사에 전화를 해서 점검을 요청하는 부분 외에는 할 수 있는 부분이 없어지는 것과 비슷하다(물론 공유기가 이상한지나, 컴퓨터가 이상한지에 대해서 이것저것 상담원이 물어볼 다른 가능성을 미리 체크해 볼 수 있겠지만 우리의 권한과 책임이 아닌 통신 망의 정상화에 대해서는 전문가들의 말을 믿고 기다릴 수밖에 없다).

 

[ 그림  2-15  주인을 기다리기 ]

 

 

  그래서 클라우드나 해당 영역의 SAAS 서비스에 대해서는 관련 클라우드 회사 및 연결되어있는 1, 2차 범위의 지원 엔지니어가 얼마나 빠르고 원활하게 잘 문제를 파악하고 본사와 커뮤니케이션 해 해결하냐에 고객의 안녕이 걸려있을 것 같다. 물론 고객 쪽 담당자도 내부 관점에서 문제에 대해 명확하게 정의하여 클라우드 환경에 맞는 방식으로 관련 커뮤니케이션을 할 수 있어야 할 것 같긴 하다(컴퓨터를 전혀 모르는 고객의 인터넷 장애를 상담하는 통신사 상담원 입장을 생각해 보자).

 

  중요한 회의를 해야 하는데 갑자기 인터넷이 안 되는 상황을 생각해 보자. 물론 이 경우  스마트폰 데이터만 충분하다면 테더링이라는 대체 가능한 옵션이 있을 수 있고, 근처 카페의 와이파이 환경으로 뛰어갈 수도 있다. 이런 선택할 수 있는 옵션이 앞서 얘기한 멀티 클라우드나, 온프라미스-클라우드 병행 체계를 마련해 놓는 이유기도 한 것 같다.

 

  SLA이나 관련 보상 계약이 있긴 하지만 현실 상으로 문제가 났을 때 그 문제로 인한 내부 피해를 산정하는 것은 클라우드 비용을 예측하는 것만큼 변수가 많은 영역일 듯싶고, 그 상황에도 해당 회사의 서비스를 그대로 이용해야 하는 미묘한 대치 상황이 될 수도 있다(게다가 그렇게 선택 가능한 클라우드 회사가 엄청 많은 것도 아니기도 하다). 만약 훗날 적절한 피해 보상을 받더라도 이미 기회는 떠나가 소 잃고 외양간 고치는 식이 될 수도 있을 것 같으니 말이다. 여하튼 클라우드 회사에서는 만에 하나라도 그런 일이 안 생기게 하려고 여러 측면에서 사이트 및 서비스 안정성을 위해 당연히 노력하겠지만, 담당자 입장에서는 그런 일은 절대 안 일어난다고 자신 있게 얘기하긴 힘든 딜레마가 생기는 부분이긴 한 것 같다.

 

 

1.8 나비의 꿈

  가상화 쪽을 얘기하다 클라우드까지 오게 됐는데(사실은 클라우드 얘기를 어떻게 잘 풀려다 보니 프로세스와 쓰레드까지 올라가게 된 거긴 하다^^) 이어졌던 이야기 흐름에 어느 정도 공감이 갔을지는 모르겠다. 현재는 현실이 가상화에 영향을 미치고 다시 가상화가 현실에 영향을 미치는 세상이 되는 것도 같아서, 마치 우리가 예전에 들었던 장자의 “나비의 꿈” 얘기처럼 뇌 과학 쪽도 그렇고 점점 현실과 가상의 경계가 조금씩 깨어지는 시기인 듯도 싶다.

 

[ 그림  2-16  나비의 꿈 ]

 

  그렇게 된 하나의 이유는 가상이나 현실이나 데이터를 기반으로 움직이는 경향이 강해져서 그렇지 않나 도 싶고, 또 우리가 평소에도 현실의 자신과 상관없이 계속 다른 세상과 자신을 상상하며 살아가기 때문이라 그런 것 같기도 하다. 우리가 현실과 마음의 가상 사이에서 계속 균형을 맞추면서 피드백을 거쳐가며 살아가는 것처럼, 우리가 가진 실제의 물리 세상과 가상화 세상은 비슷한 균형을 거치는 단계를 가지게 될 것도 같다.

 

  다른 한편으로 드는 생각으로는 요즘은 AI나 클라우드와 같은 가상 세계에 대해 모든 관심들이 집중되는 것 같기도 한데, 우리가 지금 열심히 일을 하는 이유가 평화롭거나 행복하게 잘 살려고 하는 거라는 측면을 생각하면, 우리가 왜 그렇게 해당 대상들에 열광하고 있는지를 길을 걸어가면서도 가끔은 뒤돌아보는 것도 나쁘진 않아 보인다.

 

 

- Fin -