Jikji Code

클라우드(Cloud Computing) 환경을 기반한 서비스의 안정적이고 효율적인 운영을 위한 데브옵스(DevOps) 사례를 소개하는 발표를 했었다. 당시에 발표자료를 준비하면서 문득 떠오른 생각이 있었다. 클라우드 환경의 시스템을 코드로 관리하는 방법에 대한 개념과 실천 방법에 대한 소개였다. 이 것을 잘 설명하는 비유를 생각하다가 우리나라 사람이라면 한 번쯤은 들어봤을 법한 '직지'가 떠올랐다. 우리가 자랑스럽게 생각하는 현존하는 세계 최고(最古, 가장 오래된)의 금속활자와 그 활자로 출판한 책이다. 직지와 인프라스트럭처 코드(Infrastructure as Code)는 닮은 점이 있다. 반복적인 작업을 피하고 대량의 결과물을 효율적으로 생산한다는 같은 목적을 갖는다. 그리고 틀을 만드는 초기 비용이 많이들고, 결과물에 이상이 있으면 처음부터 다시 틀을 만들어야 하는 번거로움도 같다. 여기서 틀이란 인프라스트럭처의 템플릿 코드(Template Code)이기도 하며 금속활자이기도 하다.

Jikji Code, The world's first movable metal type to modern printing

 
연관이 없을 것 같은 두 가지 다른 이야기를 엮게 된 이유는 인프라스트럭처 코드에 대한 부정적인 시각이 있었기 때문이었다. 그러한 의견을 가진 사람들에게 어떻게 하면 인프라스트럭처 코드의 장점에 대해 잘 설명할 수 있을 지 고민하다가 떠오르게 되었다. 이런 상상을 해 볼 수 있겠다. '직'이라는 활자를 누군가 만들어놓으면 만든 사람뿐 아니라 다른 모든 사람들도 쉽게 '직'을 몇 번이고 인쇄할 수 있다. 그리고 그 활자를 썼을 때 여러 사람의 검증을 통해 문제 없이 잘 인쇄되는 것을 확인했다면, 그 다음세대의 사용자는 검증과정을 거치지 않아도 그 활자를 믿고 인쇄작업을 할 수 있다.

인프라스트럭처를 코드로 관리하자는 의견에 대해 반대 의견을 가진 사람들의 주장은 거의 한결 같았다. 자신들이 맡은 일은 작은 일이기 때문에 별 것 없다는 것이었다. 거창하지 않기 때문에 코드로 만들 필요도 없고 오히려 새로운 언어를 배우기 위해 시간을 들일 필요가 없어서 효율적이라고 말했다. EC2 인스턴스(EC2 Instance) 두 개 정도 띄우는 서비스에 많은 노력을 기울일 필요가 없다고 했다. 시큐리티 코드(Security as Code)^[각주:1]라는 글에서 언급했듯이 그 사람들의 논리는 어느 정도의 규모가 되어야 코드로 관리하는 것이 효과를 본다는 것이었다.

물론 한 가지 특수한 사례만 보면 그렇게 볼 수 있다. 그러나 클라우드가 일반적으로 널리 활용되는 지금, 평생동안 EC2 인스턴스를 딱 2대만 만들 사람은 없다. 시간이 흐를수록 많은 과제를 수행할 것이고 비슷한 작업을 반복해야 할 것이다. 운이 좋아서 서비스가 성공한 경우라면 당연히 EC2 인스턴스 2대만으로는 부족할 것이다. 어떠한 경우라도 인프라스트럭처 코드의 장점이 필요하다. 현재는 작은 규모의 과제이기 때문에 여러 분이 직접 AWS 관리 화면(Management Console)에서 직관적으로 작업하는 것이 시간을 아끼는 것에는 동의한다고 말했다. 그러나 보안 부서에서 요구하는 것들을 매번 다 만족시킬 수 있는 지 물었고, 인프라스트럭처 코드를 사용한다면 보안 부서에서 검증완료한 코드를 이용해서 시간을 아낄 수 있다고 설득했다. 검증이 완료된 활자를 사용하는 것과 비슷하다고 말했다. 역시나 보안 부서에서 귀찮게 하는 것은 다들 질색인 모양이었다. 그 한마디에 코드로 인프라스트럭처를 관리하는 방식에 합의했다.

그러나 다른 부분에서 또 다시 부정적인 의견이 나왔다. 템플릿(Template) 또는 모듈(Module)을 사용하지 말자는 것이었다. 모듈을 사용하면 사용자가 편리해야 하는 데, 어떻게 동작하는 지 내부 구조를 잘 모르기 때문에 학습하는 시간이 필요하다는 것이었다. 만든 사람이 아니라서 의도를 잘 모르기 때문에 실수할 가능성도 많다고 말했다. 게다가 테라폼(Terraform)^[각주:2]을 그대로 쓸 때와 모듈을 사용했을 때 전달해 주어야 하는 변수가 비슷한 경우가 많아서 번거로운 작업일 뿐이라고 말했다. 그래서 모듈을 사용하는 것은 바람직하지 않다고 주장했다. 주장만 놓고 본다면 그럴듯하게 들린다. 그러나 소프트웨어 엔지니어(Software Engineer)가 이런 주장을 한다는 것은 잘 납득이 되지 않는다. 그 사람들은 C 언어를 배울 때 printf()를 잘 사용했을 것이다. 그런데 신기하게도 어떻게 동작할 지 모르는 함수를 사용해서 화면에 글자를 출력했다. 자바(Java)기반의 서버(Server) 개발자였다면 스프링 프레임워크(Spring Framework)는 무서워서 어떻게 사용했는 지 궁금했다.

모듈의 장점에 대해 이해하기 위해 이런 상상을 해볼 수 있겠다. 모듈을 활자에 대입해 보면 책의 전체 틀을 한 개의 판으로 만들던 것에서 글자단위의 활자로 전환한 과정과 같다고 볼 수 있다. 오늘 날 우리는 팔만대장경이 새겨진 목판보다 직지심체요절을 만드는 직지 활자가 더 효율적이라는 것을 당연히 알고 있다. 테라폼을 이용해서 인프라스트럭처를 관리하는 것은 금속활자를 이용해서 다수의 인쇄물을 만들어내는 것과 비슷하다. 대량 생산과 재사용에 아주 효과적이다. 그러나 치명적인 단점도 비슷하다. 인쇄에 필요한 활자를 만들려면 초기에 많은 시간이 필요하다. 일단 활자를 만들고 나면 인쇄 속도는 빠르지만 활자를 만드는 일은 결코 쉬운 것이 아니다. 자신과 타인의 미래를 위해 현재 시간을 조금 더 투자하겠다는 의지가 있어야 가능하다. 그리고 활자에 문제가 생기면 모든 인쇄물에 영향을 끼치는 단점도 있다. 문제가 생긴 활자를 고치는 일도 시간이 많이 필요하다. 다시 활자를 만들고 교체하고 전체를 인쇄해야 한다.
 
테라폼의 모듈도 비슷한 특징이 있다. 모듈을 만드는 것은 많은 공을 들여야 한다. 딱 원하는 동작만 수행하는 경우가 아니라 삭제, 변경 등의 상황까지 고려하면서 만들어야 한다.^[각주:3] 그리고 모듈을 사용하는 사람이 해당 모듈이 어떻게 동작할지 쉽게 예측하도록 만들어야 한다. 견고하면서도 직관적이고 그러면서도 유연해야 한다. 쉽지 않지만 최대한 성취한다면 그것만큼 좋은 것도 없을 것이다. 그래서 테라폼 모듈을 만들 시작할 때 모든 것을 모듈로 만들지는 않았다. 차츰 반복적으로 나타나는 자원들을 모듈로 묶어서 처리했으며, 모듈이 개선되는 동안 어플리케이션이 잘 옮겨다닐 수 있도록 설계했다. 그래서 처음에는 모듈로 만들 지 않았던 부분들이 점차 모듈로 넘어가도록 했다. 그리고 모듈에는 버전을 붙였다. 모듈을 계속 개선할 텐데, 내용이 바뀔 때마다 모든 모듈을 일괄적으로 다 바꿔버리면 곤란하기 때문이다. 모듈을 사용하는 환경에 따라 작업자가 모듈을 골라서 갈아끼울 수 있도록 버전을 명시했다.

Terraform Module

Building Infrastructure using Terraform Modules

이제 활자를 믿고 책을 인쇄하듯이 모듈을 잘 활용해서 인프라스트럭처 구축의 효율성을 높여 보는 것이 좋겠다. 한국인은 인프라스트럭처 코드를 제일 잘 이해하는 민족이라고 믿는다. 우리는 세계 최초로 모듈로된 코드를 가지고 대량의 출력물을 만들어낸 사람들의 후예이기 때문이다.

---

 

1. Security as Code [본문으로]
2. Terraform [본문으로]
3. Software Development Lifecycle [본문으로]