제 1시대 : Hardware의 시대

애플리케이션(application)-여기선 온라인 서비스(online service) 혹은 인터넷 서비스(internet service)를 뜻함-을 운영 할 수 있는 하드웨어를 개발하던 시대입니다. 스위치, 허브, 라우터 등등. 최첨단 인터넷 기술 이야기를 할 때, 망을 구성하는 하드웨어 이야기가 가장 많던 시대입니다. 그리고 지금 보기엔 신화 시대 같은 느낌입니다.

제 2시대 : Protocol의 시대

하드웨어가 발전해서 잠시 기다리는 동안 처리를 해줄 수 있을 정도가 되었습니다. 그래서 이때부터 무엇을 어떻게 요청할 것인가, 어떻게 응답할 것인가가 가장 중요한 문제가 됩니다. 그래서 많은 프로토콜(protocol)과 그 프로토콜을 사용하는 애플리케이션이 새로 나오기도 하고 과거의 것이 재탄생 하는 어지러운 시기였지만, 결국 HTTP(hypertext transfer protocol)와 FTP(file transfer protocol)가 주요 프로토콜이 되며 막을 내립니다.

프로그래밍을 모르던 어릴 때라 마치 선사시대 같은 느낌이지만, 이 시대의 유산 중에 아파치 웹 서버(Apache HTTP Server)와 웹 브라우저가 있습니다. 지금도 현역으로 맹활약 중이죠.

제 3시대 : 제 1차 Container의 시대

Servlet Container와 Virtual Host의 시대

HTTP가 애플리케이션의 기본 프로토콜이 되었습니다. 그리고 그 시간동안 하드웨어는 계속 발전했습니다. 어떤 프로토콜로, 어떤 하드웨어 위에서 서비스를 할 것인지는 정해졌습니다. 이제 남은 것은 잘 하는 것이죠. 애플리케이션을 운영하는 것이 중요한 문제가 되었습니다.

어떤 애플리케이션을 운영할지 정하는 건 사실 간단합니다. 여러 기획을 한 다음에 계획을 하고, 개발해서 가장 가능성 있는 것을 골라 집중하면 됩니다. 그러려면 우선 많은 시도를 해야 하는데, 아뿔싸. 문제가 생겼습니다. 하드웨어가 너무 발전했습니다.

애플리케이션을 개발하고 운영하면 처음에는 쓰는 사람도 적고 사용량도 적습니다. 그래서 서버 성능의 대부분은 사용하지 않습니다. 비용 효율이 문제가 되었습니다. 이전 시대라면 다른 프로토콜을 사용하는 애플리케이션을 운영해볼 텐데, 프로토콜은 이미 정리되어 더 할만한 게 없습니다. 그렇다고 성능이 낮은 서버를 쓰면 너무 오래된데다 그렇게 싸지도 않고 갑자기 고성능이 필요해질 때 곤란할 수도 있습니다. 서버가 많아지면서 네트워크가 복잡해지는 것도 어려운 문제입니다. 당장 쓰지 않더라도 어느 정도 성능이 좋은, 시대에 뒤떨어지지 않은 하드웨어를 사용해야 합니다.

그래서 고성능의 시스템(하드웨어 + OS + 시스템 서비스 + 기타 공통 부분)을 효율적으로 사용하기로 합니다. 하나의 시스템을 여러 애플리케이션이 같이 쓰는 겁니다. 하나의 시스템을 나눠 쓸 수 있는 서블릿 컨테이너(servlet container)와 가상호스트(virtual host)가 이 시대의 주역이 됩니다.

제 4시대 : Virtual Machine의 시대

시스템을 같이 쓰는 건 좋았지만 하드웨어, OS, 시스템 설정, 시스템 서비스, 시스템 라이브러리 등의 공유자원(shared resource)은 시스템을 공유하는 모든 애플리케이션이 함께 쓸 수 밖에 없었습니다. 문제는 공유자원은 이름으로 찾아야 하지만, 버전까지 일치해야 한다는 겁니다. 애플리케이션은 각자 업데이트 주기가 다르기 때문에 애플리케이션 버전마다 필요한 공유자원의 종류와 버전도 달라집니다. 시스템에 설치한 공유 자원에 따라 시스템이 운영할 수 있는 애플리케이션이 달라집니다.

개발할 때는 이름과 버전으로 정확히 필요한 것을 찾아 쓰고, 운영할 때는 같이 쓸 수 있는 서비스는 같은 시스템에 설치하도록 묶어줘야 했습니다. 결국 복잡한 의존성 관리 문제가 생겼습니다. 더욱이 애플리케이션을 운영하면 필요한 성능이 시시각각 바뀌기 때문에, 필요 성능과 비용을 같이 고려하면 문제는 더욱 복잡해집니다.

누군가는 이런 문제가 생길 것을 알았습니다. 누군가는 단순히 호기심이었을 테고, 누군가는 당장 자신이 절실하게 필요했습니다. 그들의 힘으로 쓸만한 가상머신(virtual machine)이 세상에 나왔습니다. 가상의 하드웨어를 만들고 그 위에 OS를 설치하고 거기에 시스템 설정을 하고 필요한 시스템 서비스와 시스템 라이브러리를 설치합니다. 가상머신으로 만든 각각의 시스템은 공유할 필요가 없어져 복잡한 의존성 문제에서 해방되었습니다.

가상머신의 시대가 열렸습니다. 그리고 시스템만 가상화 하고 끝나는 것이 아니라, 인프라의 가상화라는 시대를 뛰어넘는 큰 흐름을 시작합니다. 클라우드 서비스(cloud service)의 시작입니다.

제 5시대 : 제 2차 Container의 시대

OS Container의 시대

가상머신은 정말 좋았습니다. 복잡하게 얽히고 설켜 손대기 망설여지던 의존성 문제를 해결했습니다. 그러나 세상에 공짜는 없고 만병통치약도 없습니다.

가상머신을 사용한 결과 컴퓨터 자원-특히 디스크와 메모리-의 효율이 나빠졌습니다. 애플리케이션을 운영하려면 예전엔 시스템 서비스를 나눠 쓸 수 있도록 설정만 하면 됐는데, 이제는 똑같은 OS에 똑같은 시스템 설정에 똑같은 시스템 서비스와 똑같은 라이브러리를 사용하더라도 서로 다른 애플리케이션이라면 새로운 가상머신을 만들고 전부 새로 설치해야 합니다. 그렇다고 컴퓨터 자원 효율을 올려보고자 하나의 가상머신에 이런저런 애플리케이션을 같이 운영하자니 다시 의존성 문제가 생겨 이러려면 뭐 하러 가상머신을 도입했나 싶습니다.

그런 고민의 결과, LXC(LinuX Container)라는 OS 컨테이너가 나옵니다. 이 시대는 아주 짧고, 흥하지도 못한, 그런 게 있었나 싶은 시대이지만, 다음 시대의 기반이 되는 아주 중요한 시대입니다. LXC는 가상머신에서 하드웨어를 빼버리고 시스템을 부분적으로 공유 했습니다. 리눅스 한정이긴 하지만, Host OS 위에서 Guest OS를 직접 가상화 해버리면서 같은 부분은 새로 설치할 필요 없이 그냥 같이 쓰는 겁니다. 결국, 달라지는 부분인 시스템 설정, 시스템 서비스, 시스템 라이브러리만 운영하려는 애플리케이션에 맞춰 쓸 수 있게 되었습니다.

이 시대는 짧지만 그 아이디어와 기술은 다음 시대의 중요한 기반이 됩니다.

제 6시대 : 제 3차 Container의 시대

Application Container의 시대

현재입니다. 지금 이 순간이지요. LXC의 주요 기술을 가져와 시작된 시대입니다. 그리고 이전부터 있던, “스크립트로 간단하게 시스템 준비를 끝내고 싶다”는 욕망이 현실이 된 시대입니다. 도커(Docker)가 대표 주자인 애플리케이션 컨테이너(application container)의 덕분입니다.

이 시대의 특징은 시스템이 애플리케이션에 동기화 되었다는 점입니다. 이전까진 시스템이 이미 있어서 그 위에 애플리케이션을 설치해야 했습니다. 하지만 이제는 애플리케이션을 개발하는 동시에 애플리케이션을 위한 시스템도 만들 수 있게 되었습니다. 즉, 개발환경과 운영환경이 거의 일치하는 시대가 되었습니다.

새로운 시대

서버 시대의 끝

2017년 지금은 애플리케이션 컨테이너의 시대입니다. 하지만 그건 어디까지나 애플리케이션 컨테이너가 주역을 차지하고 있다는 것일 뿐, 지난 시대의 주역은 여전히 쌩쌩하게 자신의 역할을 다하고 있습니다. 어디까지나 주역이 아닐 뿐이죠.

그리고 다음 시대의 주역을 노리는 기술은 이미 등장했습니다. 바로 서버리스(serverless)입니다. AWS 람다(AWS Lambda), 구글 클라우드 펑션(Google Cloud Functions) 같은 기술입니다. 서버에서 실행하는 애플리케이션의 개념이 사라지고 서버에서 실행하는 메서드(method) 혹은 함수(function)의 개념만 남았습니다. 간단히 말하자면 온라인 서비스 개발자는 만들고자 하는 서비스의 로직에 집중하고 나머지는 신경쓰지 않도록 해주는 기술입니다.

그 외에도 많은 기술이 있지만, 목표는 하나입니다. 만드려는 서비스에 집중할 수 있게 하는 것이죠. 이 서비스를 개발할 때 사용할 수도 있고 저 서비스를 개발할 때도 사용할 수 있는 공통 기술은 보이지 않게 숨겨서 신경쓸 필요가 없도록 만드는 것입니다.

애플리케이션을 개발할 때, 서버는 점점 더 중요해지고 있습니다. 그러나 역설적이게도 서버의 존재감은 점점 더 희미해지고 있습니다. 눈치챌 수 없도록 녹아든다는 뜻이죠. 그 대신 점점 더 강조되는 건 로직입니다. 비지니스 로직(business logic)을 어떻게 만들 것인가. 비지니스 로직만 잘 만들 수 있다면, 그걸 실행하기 위한 나머지 기술은 신경쓰지 않아도 되는, 정말로 신경쓰지 않아도 되는 그런 시대가 오고 있습니다.