오픈스택 설립자가 본 클라우드와 PaaS

조슈아 맥켄티 피보탈 필드CTO

오픈소스 클라우드 플랫폼 오픈스택의 세력이 갈수록 커지고 있다. 수많은 IT벤더의 전폭적인 지원 속에 굵직한 대형 사용자도 속속 등장하는 모습이다.

당초 오픈스택은 아마존웹서비스의 대항마로 시작된 플랫폼이었다. 때문에 프로젝트 초기 퍼블릭 클라우드 사업자의 관심을 받았다. 분위기가 바뀌어서, 오픈스택은 이제 각 기업의 프라이빗 클라우드 플랫폼으로 더 인기를 끈다.

오픈스택의 가파른 성장세에 대해 오픈스택 설립자 중 한명인 조슈아 맥켄티 피보탈 클라우드파운드리 필드CTO를 만나 의견을 들어봤다.

그는 오픈스택 공동 설립자이자, 작년까지 상호운용성위원회 의장을 맡았으며, 오픈스택 기반의 프라이빗 클라우드 솔루션 업체인 피스톤 클라우드 컴퓨팅의 설립자기도 하다. NASA 근무 당시 오픈스택의 기반인 연방 정부의 첫번째 클라우드 컴퓨팅 플랫폼 ‘NASA 네뷸라(Nebula)’ 개발을 주도했다.

조슈아 맥켄티 피보탈 클라우드파운드리 필드CTO

■오픈스택 성장세의 원인을 진단한다면?

전반적인 시장 기회로 볼 때 채워지지 않았던 구멍이 있었고, 오픈스택이 빈 공간을 채웠다. 개인적으로 상호운용성이 가장 근본적 이유라고 본다. 우리가 처음에 프로젝트를 시작할 때 퍼블릭, 프라이빗 클라우드 간 상호운용성이 구성된 게 없었다. 인터넷이 이더넷 덕분애LAN과 WAN을 이어서 성공했듯, 오픈스택의 상호운용성이 이 빈자리를 채워줬다.

좀 더 세부적으로 성장원인을 꼽자면, 첫째 라이선스 정책 결정을 잘 내렸다. 소프트웨어, 상표권, 파운데이션 등이 다양한 유저, 개발자, 특히 다수 벤더에게 친화적인 방식으로 설립됐다는 게 특이한 점이다. 종전의 오픈소스 커뮤니티는 단일 벤더와만 연결되는 상황이 많았다. 리눅스는 레드햇, 드루팔은 아쿠아, 워드프레스는 오토매틱 같은 식이다. 우리는 여러 벤더와 연결될 수 있다는게 다르다.

둘째는 개발과 관련된 생태계 문화적 측면이다. 앞서 말한 라이선스가 여러 회사의 참여를 이끌어낸 배경이라면. 문화적으로 개인의 참여가 더 쉬웠다는 것이다. 재단에 고객과 기업, 벤더가 많이 참여한 만큼 오픈스택 참여가 회사의 업무는 물론 개인의 커리어 발전에 도움을 준다. 여러 오픈소스 개발자 중 오픈스택 개발자들이 훨씬 더 열심히 일한다.

셋째는 제품 사용자의 피드백이 실제 개발자에게 바르게 전달되도록 형성된 피드백 루프다. 사용자들은 새로 나온 버전의 기능이 기대에 못미치더라도, 실망하거나 비판하기보다 그동안의 빠른 발전속도를 생각해 향후 빠르게 나아질거라 기대한다.

■오픈스택 재단과 생태계를 통해 비즈니스를 하길 원하는 특정 업체에 종속될 수 있다는 비판이 있다. 오픈스택 벤더 락인에 대해 어떻게 생각하나?

고객과 벤더의 관계를 놓고볼 떄 단기적, 장기적 측면을 다 봐야 한다. 장기적으로 오픈스택 생태계가 더 커지면 사용자와 벤더 모두 이익을 본다. 단기적으로 오픈스택 이용자가 내 고객이었으면 좋겠다는고 여기는게 벤더로선 당연한 생각이다. 벤더는 다른 경쟁사 진입을 우려해 상용 피처를 내놓는다. 장기적으로 보면 상용 피처보다 공생을 추구하는 게 바람직하지만, 단기적으로 보면 이해못할 부분은 아니다.

오픈스택 재단 상호운용성 위원회에선 락인을 금지하거나 예방하는 실질적 조치를 취하지 않았다. 고객이 피처를 충분히 인지하고 선택할 수 있게 해 고객 차원에서 락인을 택하지 않게 하는 쪽으로 노력을 기울였다. 건전한 생태계라면, 밴더는 락인을 거는 옵션도 제공할 수 있어야 하고, 고객은 어떤 기능이 있는지 충분히 인지하고 선택할 수 있는 양적 조건이 마련돼 있어야 한다

사용자가 아마존의 EC2, EBS, S3를 이용하면 락인 걱정없다. MS 애저, HP 힐리온 같은 다른 클라우드 서비스로 넘어가도 예전에 아마존에서 썼던 것을 거의다 재사용 가능하다. 하지만, 아마존 레드시프트를 쓰는 순간 락인이 발생한다. 이건 아마존의 잘못이 아니다. 고객이 레드시프트를 쓰면 락인된다는 걸 이해하고 있다면 문제될 게 없다. 이해하고 선택하는 것은 고객의 몫이다.

오픈스택도 특정 기능중 상호운용성 제공하는 표준 기능이 있고, 락인될 수 있는 기능의 경우 고객이 이용여부를 결정하면 되는 부분이다. 피보탈의 오픈스택 클라우드 파운드리는 표준 IaaS를 이용한다. 락인 얘기를 많이 하지만 생각만큼 단순한 문제는 아니기에 나쁜일이라 단정짓기 어렵다. 락인은 벤더와 고객 니즈 사이에 있는 관계의 복잡성을 의미한다. 어쨌든 내가 말할 수 있는 건 우리는 락인 덜 발생하도록 노력해왔고, 그 점에 대해 만족하고 있다는 것이다.

■오픈스택은 클라우드 구축을 위한 여러 사용자의 다양한 요구를 충족시키는데 어떻게 기여하고 있나. 또한 피보탈의 클라우드 파운드리는 이에 어떻게 기여하고 있나?

먼저 오픈스택을 NASA에서 왜 만들었나 설명해야겠다. 내가 NASA에 고용된 건 PaaS를 개발하기 위해서였다. 그런데 당시 NASA에 PaaS를 올릴 IaaS가 없었다. AWS는 국가기관 외부에 있기 떄문에 쓸 수 없었다. 결국 PaaS를 만들기 전 IaaS부터 개발해야갰다고 생각해서 오픈스택을 개발하게 됐다. 물론, 몇달이면 끝날 줄 알았는데 5년 걸렸다. 오픈스택 개발이 완료됐을 때 제임스 워터스가 클라우드 파운드리 개발을 완료했다.

오픈스택은 많은 기업이 클라우드를 이용하게 했다.오픈스택은 프라이빗 클라우드 소프트웨어, 퍼블릭 클라우드 등과 다 상호호환성을 가졌다. 오픈스택이 클라우드를 필요로 하는 여러 고객이 다양한 방법으로 클라우드를 이용할 수 있는 옵션을 제공하는데 기여했다고 생각한다. 고객은 어디로 가든 유사한 방법으로 구동되는 클라우드 서비스를 이용할 수 있게 됐다. 과거엔 기업이 클라우드를 필요로 했지만, 보안이나 법적 문제, 사업적 의사결정, 벤더 락인 등등의 이유로 가질 수 없었다.

오픈스택과 피보탈 클라우드파운드리의 관계는 짧게 말할 수 있다. 오픈스택이 할 수 있다고 약속했던 많은 것을 피보탈 클라우드파운드리가 딜리버리, 즉 현실로 보여주고 있다고 생각한다.

■피보탈의 클라우드 파운드리가 제공하는 가장 큰 혜택은 무엇인가?

가장 큰 혜택이라면 경쟁자가 없다는 것이다. 피보탈 클라우드파운드리가 PaaS 중 완전한 구조를 가진 유일한 플랫폼이기 떄문이다. 미디어나 일부에서 클라우드파운드리의 경쟁자라 생각하는 부분은 우리 기능 중 일부만 이해하고 붙이는 듯하다. 예를 들어 컨테이너 오케스트레이션, 로그 애그리게이션, 마이크로서비스 등만 보고 각각의 경쟁자를 붙이는 것이다. 클라우드파운드리가 PaaS로서 전체적이고 완성된 모습을 갖췄다는 것에 대한 이해부족탓이다.

클라우드파운드리는 앱 개발부터 프로덕션까지 모든 부분에서 앱관리을 할 수 있다는 점에서 차별화된다. 그나마 가장 가까운 경쟁사는 헤로쿠 같다. 유사하다고 한 이유는 헤로쿠의 경우 퍼블릭 서비스만 있고, 재단과 생태계도 없으며, 오픈소스가 아니기 때문이다.

■피보탈의 모회사인 EMC, VM웨어와 향후 협력 방안은?

먼저 EMC 측면을 보면, EMC는 엔터프라이즈 하이브리드 클라우드를 턴키로 제공하는데 집중한다. 하드웨어, 오픈스택에 v스피어나, 다른 하이퍼바이저를 엮어 제공하겠다고 한다. 이렇게 되면 전반적 오픈스택 생태계의 성장과 EMC의 성장에 기여할 것이다. 고객은 하드웨어를 벤더별로 각각 고려할 필요없이 턴키로 모든 걸 이용할 수 있으니 유용하다.

VM웨어와 협력은 포톤, 즉 마이크로OS에서 협력가능하다고 본다. 왜냐면 클라우드파운드리가 마이크로OS를 돌리기 가장 적합하기 때문이다. 마이크로OS 개발 역량을 잘 갖춘회사가 VM웨어다.

우리는도커보다 훨씬 먼저 컨테이너를 이용한 최초의 업체 중 하나다. PaaS 측면에서 도커는 경량이란 점에서 유용하지만, 중요한 사안은 아니다. 앱을 마이크로서비스로 쪼개고, 컨테이너를 관리할 떄 중요한 건 오케스트레이션이다. 로그관리, 인증, HA, 등등 관련 부분이 훨씬 더 어려운 점이다. 피보탈 클라우드파운드리가 이점에서 강점을 갖고 있다. 클라우드파운드리 최신 버전은 도커도 지원하고, 네이티브 컨테이너도 지원하고, VM오케스트레이션도 가능하다.

데이터 서비스를 하려면 계속해서 연결된 스토리지가 중요하다. 컨테이너 관련해서 어렵고 흥미로운 부분이 오케스트레이션이다. 예를 들어 PaaS와 운영에서 어려움 발생한다고 치자. 컨테이너를 데브옵스 툴로 보면, 업무환경에서 아주 간단한 보안 패치만 보내는데도 개발자가 필요하게 되는 복잡한 상황으로 끌고 갈 수 있다.

■앞으로의 세계 오픈스택 시장 동향을 예측한다면?

IaaS의 전반적인 글로벌 트렌드가 성숙되면서, 현재 네트워킹과 컴퓨팅 업계의 트렌드가 나타나지 않을까 한다. 특정 시장을 4~5개 벤더 중 1, 2위가 시장 대부분을 점유하고, 나머지 틈새를 공략하는 벤더가 여럿 등장하는 모습이 나타날 것이다. 컴퓨팅이나 스토리지 관련해서 벤더를 생각하기 보다 프로토콜만 생각하듯 시장이 조금 더 성숙하면 피보탈이든 시스코든 어느 누구의 오픈스택이 아니라 ‘그냥 오픈스택 지원’ 식으로 상황이 달라질 거라 생각한다.

■피보탈의 마이크로서비스와 PaaS 구현에 대한 계획은 무엇인가?

가장 성숙한 마이크로서비스의 예는 넷플릭스다. 넷플릭스 오픈소스가 스프링 위에 개발됐다. 넷플릭스 오픈소스를 상용화해 스프링 클라우드로 만들었다. 클라우드 파운드리를 네이티브하게 구동한다. 피보탈 고객 중 얼리어답터는 스프링 클라우드와 클라우드 파운드리를 혼합해서 쓴다. 개선할 부분은 피보탈 클라우드 파운드리의 경우 여러 언어를 지원하지만, 스프링 클라우드는 자바만 지원한다는 것이다. 스프링 클라우드가 다양한 언어를 지원하도록 하는게 우리의 추구하는 바다.

■최근 국내 기업도 마이크로서비스에 관심을 보이기 시작했다. 기업이 마이크로서비스 구현에서 어떤 점을 고려해야 할까?

앱을 새로 개발하기보다 기존 앱을 마이크로서비스화 하는게 일반적이다. 가장 어려운 건 하나의 서비스를 마이크로서비스화하는 과정이다. 한번에 모든 걸 나눠서 마이크로서비스화하는 건 매우 어렵다. 하나의 서비스가 DB부터 실제 UX까지 전체부분을 갖게 마이크로서비스화 하는게 더 나은 방법이다. 보통 레이어별로 마이크로서비스를 만들어가는데, 이는 상당히 복잡하며, 실패확률도 높다. 전체를 하는 게 더 좋을 것이다.

다음으로 하이브리드 환경에서 퍼블릭 클라우드냐, 프라이빗 클라우드냐 결정하는 것이다. 앱이 구동과, 데이터 저장은 한곳에서 일어나야 한다. 예를 들어 실제 앱이 이용하는 데이터가 프라이빗에 있는 오라클DB라면, 내부의 프라이빗 환경에서 마이크로서비스가 진행돼야 한다. 앱은 움직이기 쉽지만 데이터는 무겁기 때문이다. 장소에 대한 측면이 중요할 것이다.

■마이크로서비스 추상화 단위는 어떻게 해야할까? 사람들에 따라 의견이 다르다.

그를 지칭하는 용어가 콘웨이 법칙에서 딴 ‘콘웨이 바운더리(Conway boundary)’다.

객체지향 프로그래밍할 때 오브젝트를 어느정도 크기로 가져갈 것인가, 오브젝트를 새로 만들지, 아니면 예전 것을 이용할 것인가 등의 질문을 할 수 있다. 그러나 제 답변은 경우에 따라 그때 그때 다르다는 것이다. 마이크로서비스에서 중요한 건 리빌딩이 아니라 기존 걸 다시 재구성하는 리팩토링이란 점이다. 실제로 그래서 애자일한 서비스 아닐까 생각한다.

마이크로서비스는 계획이 아니라 해보면서 배우는 게 많다. 실수하고 고치는 과정에서 많이 배운다. 오랜동안 소프트웨어를 만져왔고, 개발해오면서 트래픽 큰 소프트웨어도 개발했었다. 넷스케이프 브라우저도 개발했고, 오페라 브라우저에서 MTV쇼 개발도 했었는데 당시에도 DB를 만들고 확장할 떄 노멀라이즈 시켜놓고, 최대한으로 디노멀라이즈 시키는 방식을 썼다.

처음엔 완벽하지만 안 돌아가는 상태로 만들고, 지저분하지만 잘 돌아가게 발전시켜 가는 방식, 그게 마이크로서비스에 적용된다. 소분할 수 있는 부분까지 최소화하는 과정이라 보는데, 결국 상황에 따라 다르다. 샌드위치를 예로 들면 많이 배고프면 큰 거 먹고, 덜 배고프면 작은 걸 먹듯 원하는 상황에 따라 가져갈 수 있다. 규칙은 없고, 해보면서 느낌으로 얻게 되는게 더 많을 것이다.

■업계서 촉망받는 ‘40세 이하리더’에 선정된 바 있다. 업계 리더로서 앞으로 이루고 싶은 꿈이 있다면?

내가 프로그래핑을 처음 한 게 6살이었다. 당시 애플2로 했고, 굉장히 쉽게 프로그램 만들수 있었다. 지금은 상황이 달라졌다. 딸이 두 명있는데, 두 딸이 개발을 한다면, 고려해야 할 상홤이 더 많아졌다. SW 만들기 위해 이해해야 할 인프라가 너무 많아진 것이다.

내가 개발을 처음 시작할 때는 코드를 써서 작은 컴퓨터 안에서만 쓰면 되는 것이었다. 지금은 휴대폰에서 돌아갈 프로그램을 만들면 코드를 애플에 보내야 하고. 휴대폰용과 클라우드용 등등으로 몇가지 언어로 더 만들어야 한다.

6살 때 프로그램을 쉽게 만들었듯 앞으로 클라우드, 특히 PaaS를 발전시켜 모든 사람이 원하면 프로그래머 될 수 있는 쉬운 환경을 만들고 싶다.