'도커 이전과 도커 이후' 세상이 확연히 달라진 이유

https://www.itworld.co.kr/news/215339

'도커 이전과 도커 이후' 세상이 확연히 달라진 이유

 

 

2013년 도커는 화제의 ‘바로 그’ 회사였다. 컨테이너가 주류로 부상하는 데에 결정적 역할을 하면서 신문 1면을 장식했고, 많은 분야에서 PaaS를 밀어내고 당대 최고의 인기 기술로 자리잡았다(헤로쿠(Heroku)를 기억하는 사람이 지금도 있을까?). 그리고 이제 도커는 유료 요금제 방식의 도커 데스크톱(Docker Desktop) 모델로 다시 언론의 주목을 받고 있다. 이번 발표에 대한 격렬한 반응을 보면, 도커로 인해 현재 널리 사용되는 주류 모델인 컨테이너의 인기가 얼마나 높아질 수 있었는지 다시금 상기하게 된다.
 
도커는 컨테이너를 발명한 곳이 아니라, 오픈소스 도구와 재사용 가능한 이미지로 컨테이너 기술의 접근성을 높인 회사다. 도커를 사용하면 개발자는 소프트웨어를 한 번만 만들어서 로컬 또는 프로덕션 서버에서 실행할 수 있다.
 

ⓒ Getty Images Bank 
도커 명령줄 도구가 몇 년 동안 사용된 화려한 웹 인터페이스를 밀어냈다는 사실은 개발자가 진정으로 원하는 것이 무엇인지를 잘 보여주는 사례일 것이다. 그러나 도커가 미친 영향을 제대로 이해하기 위해서는 도커 컨테이너 기술이 등장하기 직전의 상황을 되짚어보는 것이 중요하다.
 

그 다음 혁신에 대한 갈증

2009년은 가상화에서 얻는 가치가 널리 인식되고, 구현도 폭넓게 이루어진 시기다. 대다수 조직이 이미 가상화의 혜택을 얻었거나 그런 수준에 이르기 위한 로드맵을 두고 있었다. 가상화 이야기를 질리도록 들은 사람들은 IT와 소프트웨어 개발의 다음 혁신에 목말라 있었다. 그때 등장한 것이 헤로쿠다. 일반적인 PaaS와 헤로쿠는 큰 인기를 얻었다. 마치 PaaS가 세상을 정복할 듯한 분위기였다.
 
당시 헤로쿠는 대단했다. 헤로쿠 포털에서 앱을 개발하고 바로 서비스로 제공한다? 그걸 마다할 이유가 있을까? 헤로쿠에서 앱을 개발하지 않을 이유는 전혀 없는 것만 같았다.
 
그런데 시간이 지나고 보니, 헤로쿠 같은 PaaS 플랫폼을 사용하지 않을 만한 이유가 몇 가지 있었다. 예를 들어 헤로쿠에서 구축된 애플리케이션은 이식이 불가능해서 헤로쿠 안에서만 사용할 수 있었다. 개발자가 협업을 원할 경우, 원격으로 PaaS 플랫폼에서 작업해야 했다. 넷플릭스와 달리 개발자는 주로 로컬 개발을 선호하는 편이다. 개인 로컬 박스에서 작업하기를 원하는 개발자는 스스로, 수동으로 환경을 구축해야 했다.
 
또한 헤로쿠 모델은 기본적으로 제공되는 수준에서 사용할 때는 매우 강력했지만 그 기반이 복잡했기 때문에, 간단한 웹 앱 이상의 복잡한 것을 만들거나 보안 또는 성능상의 이유로 인프라를 맞춤 구성하려면 현실적으로 어려운 엔지니어링 문제로 발전했다.
 
문제가 드러나기 전까지는 모든 것이 좋았다. 그러나 IT에서 흔히 볼 수 있듯, 헤로쿠가 쓰일 만한 곳도 분명 있지만, 그렇다고 헤로쿠가 모든 작업을 위한 만능 툴을 아니라는 사실을 인지하기도 전에 많은 사람이 헤로쿠에 ‘올인’했다.
 

도커가 보여준 차이

반면, 컨테이너는 PaaS의 문제 대부분을 해결했고, 도커를 통해 개발자와 IT 관리자, 비즈니스 관리자는 그 사실을 볼 수 있었다. 실제로 도커가 처음 등장할 당시애도 그 가치는 너무나 명확했다. 헤로쿠에서 하기 어려웠던 모든 일이 도커에서는 쉬웠고, 헤로쿠에서 쉬웠던 모든 일은 도커에서도 쉬웠다. 도커를 사용하면 사전에 만들어진 서비스를 쉽고 빠르게 실행할 수 있었고, 로컬에서도 손쉽게 개발이 가능했으며 필요하면 서비스를 맞춤 구성할 수 있었다.
 
도커가 유달리 화려했던 것도 아니다. 사실 도커는 1970년대 유닉스에서 인기를 얻은 UX를 재활용했다. 도커는 리눅스 터미널에서 실행되는 명령일 뿐이었고, 대부분의 PaaS 플랫폼이 자랑했던 멋진 그래픽 인터페이스와는 완전히 달랐다. 그러나 도커 명령줄 인터페이스(CLI)는 아주 명쾌했다. 필자는 도커 CLI가 CLI 개발에 현대적 UX 감각을 더하면 세상을 바꿀 수 있다는 것을 모두에게 보여주었다고 생각한다.
 
도커, 그리고 전반적인 컨테이너는 클라우드 네이티브 애플리케이션 개발을 위한 기반 기술을 제공했다. 그때도 잘 작동했고, 지금의 새롭고 계속되는 고객의 개선 요구를 퇴행(버그, 보안 문제 등) 없이 충족할 때 필요한 데브옵스와 CI/CD(지속적 통합/지속적 배포) 모델 내의 고도로 분산된 아키텍처에서도 여전히 잘 작동한다.
 
컨테이너는 사용자에게 필요한 기능을 중단하지 않으면서 동시에 신속하게 애플리케이션을 변경할 수 있다. 또한, 영구적일 것만 같은 쿠버네티스 오케스트레이션 플랫폼을 포함하여 컨테이너를 중심으로 발전한 생태계를 통해 조직은 증가하는 컨테이너 모음을 효과적으로 확장하고 관리할 수 있게 됐다.
 
개발자는 이내 컨테이너의 가치를 알아봤다. 운영 팀도 발빠르게 이해했고, 실리콘 밸리 투자자도 알아봤다. 그러나 눈길을 잡아 끄는 시연에 익숙한 관리자, CIO, CEO에게 명령줄 도구가 온갖 화려한 장식을 매단 PaaS보다 낫다는 것을 설득하기 위해서는 얼마간의 노력이 필요했다.
 

컨테이너화된 세상에서의 일상

그렇게 해서 명령줄 도구는 2021년인 지금까지도 중대한 역할을 맡고 있다. 정말 놀라운 일이라고 할 수 있다. 게다가 컨테이너 CLI 시장도 도커 외의 다른 업체도 경쟁에 나설 수 있을 만큼 커진 것 같다.
 
컨테이너 기술이 닦은 길 덕분에 개발자는 로컬에서 또는 클라우드에서 전보다 훨씬 더 쉽게 작업할 수 있게 되었다. CIO와 CEO는 개발 주기 단축, 낮은 중단 위험, 나아가 애플리케이션 수명 전반의 관리 비용 절감을 기대할 수 있다.
 
도커는 결코 완벽하지 않고 컨테이너 역시 마찬가지다. 가상머신과 비교할 때 컨테이너로 애플리케이션을 마이그레이션할 때 더 많은 작업이 필요하다고 볼 수도 있다. 그러나 그 혜택은 앱의 수명 주기 전반에서 지속된다. 지금 개발되고 있는 새로운 애플리케이션에서도 그렇지만, 전면적인 마이그레이션, 또는 리팩터링 작업 역시 마찬가지다.
 
도커는 컨테이너 기술을 중심으로 가져오고 PaaS를 밀어내면서 현재 가장 두드러진 기술로 자리잡았다. 그 이유 하나만으로도 정말 세상을 바꿨다고 말할 수 있다. editor@itworld.co.kr