141: tweet overflow

클라우드 혁명의 끝자락에서: 테라폼 모듈로 스쳐보는 인프라스트럭처 추상화의 미래

컴퓨터는 크게 하드웨어와 소프트웨어로 구성된다. 범용 컴퓨터는 고정된 물리적 하드웨어에서 변경 가능한 소프트웨어를 실행 가능하도록 하면서 등장했다. 흥미로운 건 원래 소프트웨어도 물리적 실체가 있었다는 점이다. 그 이전에는 더욱 그랬지만, 천공 카드만 보더라도 눈에 보이고, 만질 수 있고, 촉감이 있고, 온도가 있으며 심지어 사람이 내용을 읽고 이해할 수 있는 물체였다. 하지만 저장장치와 입출력 장치의 발전에 따라서 이러한 물리적인 성질은 사라져버린다. 이제 소프트웨어는 가상적인 실체가 되었다. 눈에 보이지도 않고, 만질 수도 없으며, 촉감도 없고, 온도도 없고 오직 컴퓨터 하드웨어 연결된 출력 장치(모니터)를 통해서만 내용을 확인하거나 실행해볼 수 있는 가상의 존재이다.

하드웨어의 물리적인 지위는 공고해보인다. 특히 입력장치(키보드, 마우스 등)와 출력장치(모니터) 세트로 구성된 인간과 계산 유닛의 인터페이스로서 컴퓨터의 물리적인 실체가 위협 받은 일은 아직까지는 없는 것 같다. 하지만 모든 계산 장치(컴퓨터)가 인간과 직접 상호작용하는 인터페이스와 직접 연결되어있는 것은 아니다. 일반적으로 서버 컴퓨터는 사용자가 이 컴퓨터에 접근하기 위한 물리적인 인터페이스를 가지지 않는다. 이러한 인터페이스는 초기 셋업이나 컴퓨터가 정상적으로 작동하지 않는 비상시에만 사용되며, 평시에는 네트워크를 사용해 외부의 인터페이스를 사용해서 접근한다. 인터페이스로 사용하는 컴퓨터에서는 직접 계산을 하지 않고, 서버 컴퓨터의 자원을 사용해 계산을 할 수 있다.

명령을 내리는 클라이언트 컴퓨터와 계산만을 수행하는 서버 컴퓨터의 구성은 지금은 너무나도 당연한 것이 되었다. (인터페이스 역할을 하는) 컴퓨터에서 가능한 많은 일들이 실제로 클라이언트 컴퓨터에서 일어난다고 생각하면 오산이다. 연산은 네트워크 상에 있는 사람 컴퓨터를 통해서 이루어진다. 단순히 웹브라우저로 어떤 웹사이트에 접속하는 것조차도 사실은 다른 사람 소유의 컴퓨팅 자원을 사용하는 일이다. 네트워크의 본질은 다른 컴퓨팅 자원을 활용하는 일이다.

그렇다고 원격에 존재하는 물리적인 실체가 사라지는 것은 아니다. 서버 컴퓨터는 누군가 조립해서 만든 특정한 CPU와 메모리, 저장용량을 가진 한 단위의 컴퓨터이기 때문이다. 네트워크 너머의 물리적 실체. 인터넷 데이터 센터(IDC)에 가면 이러한 독립적인 단위의 서버 컴퓨터들이 무수히 많이 설치되어있다. 서버 컴퓨터를 관리하는 사람들에게 이런 물리적인 실체와 물리적으로 셀 수 있는 단위를 가진 컴퓨터란 굉장히 중요하다.

하지만 클라우드가 등장하면서 컴퓨터의 단위가 도전받기 시작한다. 예를 들어서 특정한 사양을 가진 컴퓨터 10대가 필요하다고 해보자. 기존에는 IDC 상에 물리적 실체를 가진 서버 컴퓨터 열 대를 설치해서 네트워크 설정을 해야했다. 하지만 클라우드에서는 사양과 필요한 대수를 지정하면 곧바로 서버 컴퓨터들을 사용할 수 있다. 여기서 중요한 점은 클라우드 서비스가 서버 설치 업무를 대행해주는 일을 하는 서비스가 아니라는 점이다. 실제로는 클라우드 데이터 센터에 이미 무수히 많은 서버 컴퓨터가 존재하고 있다. 이러한 서버 컴퓨터들은 여전히 셀 수 있는 물리적 실체를 가지고 있지만, 이제 더 이상 이 물리적인 단위를 기준으로 사용자에게 제공되지는 않는다. 클라우드 서비스는 이러한 인프라스트럭처(서버 컴퓨터들의 집합) 위에서 가상화된 컴퓨팅 자원(=새로운 단위의 서버 컴퓨터)을 제공한다. 따라서 데이터 센터에서 허용하는 한 어떠한 사양(크기)의 컴퓨터라도 요청받는 즉시 생성해서 제공할 수 있게 된 것이다.

가상화라는 기술을 클라우드 서비스에서 처음 사용한 것은 당연히 아니다. 하지만 클라우드가 혁명적이었던 이유는 서버 컴퓨터가 필요한 사람들이 더 이상 서버 컴퓨터의 물리적 실체를 고려할 필요가 없도록 만들어주었다는 점이다. 클라우드 서비스를 제공하는 쪽에게 여전히 서버 컴퓨터는 물리적 실체를 가지고 있지만, 적어도 이를 이용하는 사람들은 서버 컴퓨터의 물리적인 제약에 대해서 고려를 할 필요가 없어졌다. 이제 컴퓨팅 자원은 사양이 고정되어있지 않으며, 아무리 많이 사용하더라도 공간을 차지하지도 않는다. 클라우드가 등장하면서 이제 컴퓨터를 세는 단위는 물리적 하드웨어가 아니며, 클라우드 위에서 진정으로 가상화된 실체가 되었다.

클라우드 데이터 센터는 물리적인 실체를 가지고 있지만 클라우드 서비스의 컴퓨팅 자원을 비롯한 모든 하드웨어 장비는 가상화되어있다. (제대로 된) 클라우드 서비스들은 기존의 물리적인 하드웨어가 하는 역할을 하는 가상화된 장치를 생성하고 수정하고 삭제하는 일련의 작업을 코드로 실행할 수 있도록 API를 제공한다. 소프트웨어가 동적인 성격을 가진 것처럼, 소프트웨어를 실행하는 하드웨어 자체가 동적으로 구성될 수 있는 가능성이 열린 것이다. 물리적인 실체는 이제 가상화된 자원을 조작하는 인터페이스 뒤로 숨어버린다. 하드웨어가 소프트웨어로 추상화되었다.

컴퓨터 네트워크 구성을 위한 물리적인 장비들을 구성하고 설계한 것을 아키텍처라고 한다. 설계란 제약 위에서 어떤 문제를 해결하기 위해 상상력을 펼치는 공간이다. 그러나 현실에서 아키텍처를 구성하는 요소는 모두 물리적인 실체를 가지고 있으며, 이러한 설계로부터 구현된 아키텍처가 얼마나 경직되어있는지는 쉽게 상상할 수 있다. 물리적으로 구현되어야하는 아키텍처는 자연스럽게 물리적인 제약들에 대해서 고려해야만 한다. 가장 간단한 경우를 생각해보자. 서버 컴퓨터를 한 두 대 설치할 때 공간은 문제가 아니지만, 이런 서버를 1000대씩 설치하기 시작한다면 공간에 대한 비용이나, 건물이 서버 무게를 견딜만큼 튼튼한지가 현실적인 문제가 된다. 처음 구상하던 아키텍처를 서버실의 형태나 크기를 확인하고 다시 처음부터 설계해야할 수도 있다. 이외에도 다양한 구성요소들이 있으며 처음 아키텍처를 구현할 때 드는 비용도 높지만, 이를 다시 수정하는 비용은 처음에 설치하는 비용보다 더 클 수도 있다. 이런 면에서는 컴퓨팅은 물리적 공간을 설계하는 건축의 영역에 걸쳐있다.

클라우드를 감히 혁명이라고 말하는 것은 이러한 아키텍처의 물리적인 속성을 증발시켜버렸기 때문이다. 클라우드 위의 모든 자원은 가상화되어있으며 아키텍처를 상상하기만 한다면 그대로 만들어질 수 있다. 물론 기존 하드웨어 리소스를 가상화된 리소스가 완벽히 대체하는 것은 아니다. 클라우드 위에서는 아키텍처를 설계하기 위해서는 클라우드 리소스들이 어떤 역할을 하는지에 대한 충분한 이해가 필요하며, 게임의 논리 자체가 달라졌으므로 완전히 새로운 설계 원칙들을 익혀야만 한다. 기능이 아니라, 리소스의 실체 때문에 설계 전략도 달라진다.

클라우드 위에도 여전히 설계와 구현 사이의 갭은 존재한다. 설계를 클라우드 자원들로 구현하는 작업은 의외로 쉽지 않다. 이런 작업을 처음하는 사람이라면 상당한 시행착오를 거쳐야만 한다. 클라우드가 다음으로 발전할 방향은 사실 여기서부터 이미 확정되어있던 걸지도 모른다.

설계와 구현의 갭을 메우기 위해 자연스럽게 코드로서의 인프라스트럭처(Infrastructure as Code, IaC) 패러다임이 등장한다. 여기서 코드는 절차적인 명령이라기보다는 아키텍처 설계를 위한 문법이라고 이해되어야한다. 이러한 대표적인 도구로는 아마존 웹 서비스의 클라우드 포메이션(CloudFormation)이나 하시코프의 테라폼(Terraform)이 있다. 테라폼은 HCL이라는 전용 언어를 사용하며, 이를 사용해 컴퓨팅 자원을 정의하는 코드는 다음과 같다.

resource "aws_instance" "web" {
  instance_type = "t2.micro"
}

이 코드가 곧 컴퓨팅 자원 한 단위를 정의하는 명령어이다. 실제로 이 코드가 곧 컴퓨팅 자원이라는 것을 이해한다면 클라우드의 강력함을 실감할 수 있을 것이다. 이 코드 어디에도 물리적인 실체에 대한 고려는 없다.

훨씬 더 좋은 성능을 가진 컴퓨터 10 단위를 정의하는 코드도 크게 다르지 않다. instance_typecount 속성을 지정하면 그만이다.

resource "aws_instance" "web" {
  instance_type = "m4.4xlarge"
  count = 10
}

IaC는 아키텍처 설계와 구현의 갭을 메워준다. 테라폼의 HCL 코드는 그 자체가 클라우드 아키텍처의 설계도이며 동시에 구현이다. 테라폼에는 planapply 명령어가 있는데, plan은 HCL로 설계한 아키텍처가 실제로 구현 가능한 아키텍처인지를 임시로 검증해주며, apply는 설계도 대로 클라우드 위에 아키텍처를 구현한다. 설계도가 곧 실체가 되었다. 이 실체는 기존의 물리적인 하드웨어들로 구성된 아키텍처와 같은 역할을 하는 실체이다.

이러한 변화는 놀라운 것이지만 아직 끝이 아니다. 테라폼에는 모듈 기능이 있다. 모듈은 아키텍처 재사용을 위한 추상화된 형태로 아키텍처를 작성하는 방식을 지원한다. 모듈은 재사용될 수 있으며 몇 가지 매개변수에 따라 다양한 양태로 실체화된다. 물리적인 아키텍처든 클라우드 아키텍처든 기존에 아키텍처를 조금이라도 설계해보고 구현해본 적이 있다면 이러한 접근이 마냥 반갑지만은 않을 것이다. 앞서 살펴보았지만 하드웨어가 물리적인 실체였던 시절에 아키텍처란 매우 경직되어있는 것이었다. 아키텍처는 다양한 제약들을 바탕으로 최적화된 형태로 만들어져야 했으며, 아키텍처 설계를 위해 공유할만한 패턴들이 존재하더라도 아키텍처 자체를 재사용한다는 발상은 상식적으로 받아들이기 쉽지 않은 것이었다. 클라우드에 온다고 이런 사정이 완전히 달라지는 것은 아니다. 일반적인 아키텍처 설계를 받아들인다고 하더라도 항상 자신의 상황에 맞춰 최적화를 해야하기 때문이다. 따라서 여전히 아키텍처는 재활용하는 것이 아니라 상황에 따라 최적화된 형태로 매번 재설계하는 것이었다. 나는 모듈 기능에 대해 회의적인 입장이었지만, 하시코프(Hashicorp)는 이런 생각에 게의치 않고 하시콘프(Hashiconf) 2017에서 테라폼 모듈 레지스트리(Terraform Module Registry)를 발표한다.

테라폼 모듈의 본질은 아키텍처를 추상화하는 것이다. 이에 대한 불신은 아키텍처가 추상화할 수 있는 성질의 것인지에 대한 의문이다. 테라폼 모듈 레지스트리를 보면서 아키텍처 추상화가 비록 어려운 것이더라도 결국 이 방향으로 발전해나갈 것이라는 확신이 들었다. 아키텍처가 추상화 되면 복잡한 설계는 모듈 뒤로 숨어버린다. 모듈을 사용하면 복잡한 아키텍처 구현에 대한 충분한이해 없이도 아키텍처의 가치를 충분히 향유할 수 있게 된다. 예를 들어보자. 클라우드에서 병렬적으로 딥 러닝 학습을 수행하고 싶은 데이터 과학자가 있다. 하지만 클라우드 위에서 이러한 학습 환경을 구축하기 위해서는 클라우드를 비롯해 아키텍처에 대해서도 상당한 지식을 필요로 한다. 하지만 이러한 학습 환경을 지원하는 잘 구현된 아키텍처 모듈이 있다면 이 데이터 과학자는 이 아키텍처를 사용하고 자신은 학습 프로그램을 개발하는 데만 집중할 수 있다.

이런 일이 정말로 가능하냐고 묻는다면 현재 내 답은 당연히 아니오이다. 아키텍처에 대한 이해없이 아키텍처를 향유한다는 것 자체가 어려운 일이기 때문이다. 모듈은 여전히 가상화된 자원 자체를 완벽하게 숨겨주지는 않는다. 사용자는 아키텍처 모듈을 사용하더라도 클라우드 콘솔과 API를 직접 사용해서 많은 문제에 대응해야 하며, 이를 위해서 극단적인 경우 아키텍처 모듈을 설계한 사람만큼의 지식이 필요할 수도 있다. 또 다른 문제도 있다. 원칙적으로 모듈을 같은 클라우드 계정 안에서 매개변수만 바꿔서 여러번 정의할 수 있어야한다. 그러나 클라우드는 모듈을 구현하기 위해 충분히 격리된 공간을 제공하지 않는다. 이 때문에 아키텍처를 모듈로 추상화하는 작업이나 사용하는 방식은 상당히 교묘해질 수 있다. 예를 들어 이름 충돌을 방지하기 위해서 리소스의 자원이 어느 정도 범위에서 공유되는지 이해하고 있어야한다. AWS의 경우 S3의 이름은 모든 사용자 수준에서 공유되며, IAM은 계정 수준에서 공유된다. ELB는 리소스 이름이 곧 id로 사용되며(즉, 이름이 같으면 충돌이 난다), EC2와 같은 어떤 자원은 리소스 이름을 태그로 지정되기 때문에 전혀 충돌이 일어날 일이 없기도 하다. 모듈을 정의하려면 추상적으로 아키텍처를 설계해야하며 이러한 예상가능한 충돌에 대해서 충분히 대비해야한다. 바로 이러한 이유들 때문에 아키텍처 모듈(추상화)에 대한 의심은 합리적으로 보인다.

마법은 없다. 현실적으로 아직은 쉽지 않고, 많은 시행 착오들이 필요해보인다. 현실적인 한계는 있지만, 그럼에도 불구하고 아키텍처 추상화는 충분히 이상적인 발전 방향이다. 결국에 테라폼의 모듈도 진화해나갈 것이고, 클라우드 역시 이러한 추상화를 충분히 지원하는 방향으로 진화해나갈 것이다. 컴퓨터의 진화라는 관점에서 이러한 변화는 하루 아침에 시작된 것이 아니다. 이 아래에는 분명히 물리적인 제약으로부터의 해방과 더 높은 추상화라는 일관적인 저류가 흐르고 있다.

, nacyot.

블로그nacyot이 운영합니다.