Immutable Infrastructure

몇 년 전, IoT 과제에 참여했을때 Immutable Artifact (변경불가능한 결과물) 또는 Immutable Infrastructure에 대해 겪은 것을 이야기를 하려고 한다. IoT과제는 지속적 전달(Continuous Delivery)^[각주:1]과 불변의 인프라스트럭처(Immutable Infrastructure)^{[각주:2] [각주:3]}를 도입하였다. 그러나 안타깝게도 대부분의 사람들은 그 개념이 무엇인지 잘 몰랐다.^[각주:4] 기존 엔지니어들이 하던 방식을 그대로 따르려고만 했고 일정 압박을 핑계로 운영 환경에서의 긴급 변경을 수 없이 요청했다. 테스트(Test)를 충분히 할 생각은 하지않고 버그는 항상 있을 수 있다는 핑계로 운영 환경에서 발견된 결함을 그 자리에서 바로 고치길 원했다.

어느 날, 주말에 문제가 발생했다. 역시나 개발자는 문제를 해결하기 위해 운영 중인 서버에 접속해야 한다며 계정 접속을 허용해 달라고 이야기 했다. 운영 환경에 직접 접속해서 뭔가를 조작하는 것은 원칙에 어긋난다고 답변 했더니 그 개발자는 운영팀이 실력이 없어서 스크립트를 잘 못다루기 때문에 걱정이 많은 것 같다고 생각한 모양이었다. 그 개발자는 대략 이런 느낌으로 말했다. "그 것은 너무 쉬워요. 그냥 접속해서 스크립트 하나만 실행하면 되요. 잘 모르시겠으면 제가 할게요".

긴 이야기를 돌아왔는데, 이런 경험을 꺼낸 이유는 지속적 전달에서 중요하게 생각하는 개념 중 하나인 불변(Immutable)에 대해서 이야기 해 보기 위해서다. 간단한 비유를 들어 설명해 보려고 한다. 방금, 새로운 스마트폰(Smart Phone)을 구매했다는 상상을 해보자. 너무 즐겁고 기뻐서 어쩔 줄 모를 것이다. 그런데 새 전화기가 갑자기 오동작을 일으키며 툭하고 꺼진다면 매우 상심이 클 것 같다. 그런데 판매자가 원인을 알고 싶다면서 내 전화기를 뜯어보자고 한다면 어떤 생각이 들까? 기분이 나쁜 것은 말할 것도 없고 제조사에 대한 신뢰가 급격하게 떨어질 것이다. 품질 관리를 어떻게 한 것인지 의심이 들수 밖에 없다. 만약 별 문제가 없어 보여서 다시 조립을 했다고 해도 찝찝해서 그 전화기를 계속 쓰고 싶지 않을 것이다.

만약 위와 같은 비유가 잘 와닿지 않는다면, 다른 상황을 생각해 볼 수 있다. 음식점에 가서 라멘을 시켰다고 상상해 보자. 주문한 음식이 나왔는데, 뭔가 간이 안맞거나 달걀이 덜 익었다고 생각해 보자. 그래서 종업원을 불렀는데, 내가 주문한 음식을 뒤적거리면서 내용물을 확인하거나 그 자리에서 맛을 확인해 보겠다고 한 숟가락을 떠서 먹어본다면, 손님의 입장에서는 어떤 생각을 하는 것이 일반적일까? 아마도 대부분의 사람들이라면 이러한 상황에서는 더 이상 그 음식을 먹고 싶지 않을 것이다.
 

 
 
서비스(Software Service Application)도 고객에게 무형의 가치를 제공하는 상품이기 때문에 같은 방식으로 품질 관리를 할 수 있다고 생각한다. 많은 사람들이 서비스를 공산품과 같은 방식으로 품질관리하겠다는 의견에 동의하지 않을 수 있다. 그 이유는 소프트웨어(Software)는 무형의 자산이고 품질관리가 어렵다고 오랫동안 생각해 왔기 때문일 것이다. 서비스도 소프트웨어이므로 같은 속성을 가지기 때문에 품질 관리가 어렵다고 생각할 것이다.

그러나 웹(Web)과 인터넷(Internet)이 보편화된 지금 우리는 커피(Coffee) 한 잔을 사서 마시듯이 앱(Smart Application)을 구매하고 사용하고 있다. 비용을 지불하고 원하는 것을 얻는다는 과정이 단지 재래시장이나 마트에서만 일어나는 것이 아니라 서비스 상품에서도 발생하고 있다.

그래서 우리는 서비스를 제조업처럼 품질 관리할 수 있고 그렇게 해야한다. 서비스를 제공하는 소프트웨어는 상품이고 서버는 그 내용물을  제공하는 매체(제품)이므로 개발자나 운영자가 함부로 고객의 제품에 들락날락 거리지 않아야 한다. 왜? 고객이 기분 나쁘기 때문이다. 첫째, 기능이 제대로 동작하지 않아서 비용을 지불한 만큼 원하는 것을 얻지 못했기 때문이고 둘째, 고객이 비용을 지불한 '내' 제품을 판매자가 건드렸기 때문이다.

---

 

1. Continuous Delivery [본문으로]
2. Bakery System [본문으로]
3. PhoenixServer [본문으로]
4. 그 들은 늘 파이프라인(Pipeline)과 머신 이미지(Machine Image)가 소프트웨어 서비스(Service)의 품질을 높여 준다고 말했지만, 실제로는 제대로 이해한 것 같지 않았다. 문제가 생길 때마다 운영 중인 서버(Service Server)에 들어가서 뚝딱뚝딱 처리하면 되는 것 아니냐고 말했기 때문이었다 [본문으로]