클라우드라는 용어가 처음 등장했을 때, 그것은 실로 뜬구름이었다. 통신사의 컨설팅 프로젝트를 진행하면서 클라우드 개념에 대해 금융투자사 메릴 린치의 자료를 기반으로 조사했었다. 당시에는 클라우드 개념을 이렇게 잡았다. 1) 가상화 사업자, 2) VDI(Virtual Desktop Interface) 사업자, 3) Map-Reduce 기반 Big Data 시스템 제공자, 4) 공유 스토리지 사업자, 5) SalesForce.com과 같은 임대형 비즈니스 지원 서비스 사업자, 6) CDN 서비스 사업자가 모두 클라우드 서비스라고 주장했고 IaaS 기반의 클라우드 사업을 시도했던 시대였다. 국내에서도 통신사와 대형 제조사 들이 앞다퉈 IaaS 기반의 클라우드 플랫폼 구축을 시도했다. 허나 명확한 사업 모델과 기술 청사진 없이 진행하다 참담한 실패를 했던 것으로 기억한다. 한 통신 사업자는 '클라우드'란 용어 자체가 회사 내에서 금지어가 될 정도였다.
이런 웃지 못할 일들이 있던 시절이 불과 5, 6년 전이다. 그러나 요즘은 그야말로 클라우드 시대라 해도 손색이 없을 정도다. 대부분 회사가 클라우드 기반 서비스를 제공하는 시대가 됐기 때문이다. 10년이면 강산이 변한다는 옛말이 무색할 정도로 불과 5년 만에 IT의 전통 패러다임이 모두 바뀐 셈이다.
넥슨 코리아에 입사한 후, 본격적으로 AWS 기반의 퍼블릭 클라우드를 사용했다. 물론 2012년에도 AWS 프로비저닝과 모니터링에 관련된 프로젝트를 진행했지만, 그때의 AWS와 요즘 경험하는 AWS는 하늘과 땅 차이로 다르다. 2012년 당시에는 AWS 서비스라고 해봤자, 5가지 밖에 없었고 '자동화'는 존재하지도 않았다. 당시 프로젝트는 AWS SDK를 기반으로 자동화를 구현하는 프로젝트였다. 허나 넥슨에서 경험한 AWS는 그야말로 신세계였다. 복잡한 아키텍처를 그림으로 그리고 그대로 구축하는 데 반나절이면 될 정도였다. 전에는 같은 작업을 하는 데 장비 구매부터 평균 두세 달이 걸렸으니, 이는 혁명에 가깝다. 그뿐만 아니다. 구축한 아키텍처를 모두 코드화시키고 다른 지역에 코드를 구동시키면 한 시간 내에 모든 아키텍처가 구축되어 동작한다. 참으로 기적이 아닐 수 없다.
나는 이런 신세계를 경험하면서 인프라 엔지니어들이 기존 방식을 탈피하는 방법을 설명해주고 싶었다. 다행히도 내가 생각하는 비전을 설명해주는 책을 만나게 됐다. 그래서 시간을 쪼개 가며 이 책을 번역하게 됐다. 이 책을 통해 AWS 운영에 대한 생각과 관점이 바뀌길 기대해본다. 인프라가 코드로 구현된다는 것은 정말 놀라운 일이 아닐 수 없다. 부디 여러분이 이 책을 통해 많은 것을 배우고 인프라 관리에 대한 영감을 얻길 바란다.
나는 2015년 모 통신사 컨설팅 프로젝트를 진행하면서 '데브옵스(DevOps)'라는 용어를 처음으로 접했다. CI(Continuous Integration)라는 용어는 그보다 훨씬 오래 전인 2008년부터 사용하기 시작했다. 그해, 모 통신사의 대형 서비스 플랫폼의 운영 지원 및 고도화 기획을 담당했는데 해당 플랫폼의 원활한 유지 보수가 가장 큰 이슈였다. 전 국민을 대상으로 하는 플랫폼으로 장애 없는 유지 보수가 절대적으로 필요했으나 소스 코드의 관리 부재, 체계적인 빌드와 배포 시스템의 미비로 변경 개발 반영은 그야말로 손에 땀을 쥐는 매우 어려운 작업이었다. 가끔은 너무 시급해서 소스 코드를 상용 서버에 복사한 후 상용 서버에서 소스를 고쳐서 컴파일해 올리는 일도 있을 정도로 모든 절차가 임기응변으로 이뤄지고 있었다.
당시 소프트웨어 공학 방법론은 주로 개발된 코드를 재사용하는 방법에 대해서만 다루고 있었다. 이는 In-house 개발 및 COTS소프트웨어에 대해 적합한 방법론이다. 대형 SI에서는 주로 Waterfall 모델을 이용해 요구 사항 정의로 일이 시작되고 요구 사항의 구현으로 일이 끝나는 방법론 중심이었다. 다시 말해 실시간으로 운영 중인 시스템에 주기적으로 배포를 끊임없이 하기 위한 적절한 방법론 자체가 없었음이 맞을 것 같다. 당시 나는 Test NG(Next Generation)라는 이론을 접했고 여기에서 CI라는 용어를 처음으로 접했다. 개발 후 소스를 커밋하면 빌드 및 테스트를 자동으로 처리해주고 결과물을 바이너리로 남기는 일련의 과정을 CI라는 용어로 설명하고 있었다. 필자는 이 CI 절차를 도입해 유지 보수하는 데 반영시켰다. 이를 통해 자동화된 테스트를 통한 어처구니없는 실수를 차단시킬 수 있었다. 빌드 및 테스트가 성공한 바이너리만 상용 배포하도록 했고 배포된 바이너리에 오류가 있다면 직전 바이너리로 대체 배포할 수 있었다. 이를 통해 유지 보수가 훨씬 용이해졌을 뿐 아니라 작업 소요 시간, 평균 배포 주기, 배포 실패율 등을 산출하여 차기 운영프로젝트의 규모 산정 자료로 활용하기까지 할 수 있었다.
아쉬웠던 것은 테스트 환경 및 스테이징 환경 구성이 쉽지 않고 자동 배포가 불가능한 점이었다. 당시는 클라우드라는 용어가 막 등장하던 시절이다. 즉, 테스트 및 스테이징 환경을 구축하려면 별도의 하드웨어 투자가 필요하고 어떤 프로젝트에서도 이런 환경을 갖추기가 드물었다. 그러다 보니 로컬 PC 환경에서 개발 및 테스트 후 상용에 올릴 수밖에 없었고, 코드에 문제가 없어도 실행이 되지 않는 상황이 많이 발생했다.
바야흐로 클라우드 시대로 들어오면서 이런 환경의 구축이 가능한 시대가 됐다. CI 개념은 코드 빌드 및 바이너리 생성에서 멈추지 않고 인프라 생성과 바이너리 배포에까지 확장됐다. 이런 작업은 일반적으로 개발자보다는 운영자에게 이관돼왔다. 그러나 이러한 확장은 개발자와 운영자의 벽을 허물어뜨리는 결과를 가져오고 있다. 굳이 데브옵스라는 용어를 안 써도 이런 상황은 이미 발생하고 있다.
데브옵스는 소스 빌드, 바이너리 생성을 넘어 환경의 생성과 배포까지 모든 절차를 하나의 파이프라인으로 엮는 광범위한 작업을 의미한다. 그러나 국내에는 이런 거대한 작업을 해온 경험을 가진 인력이나 조직이 많지는 않은 것 같다. 너무 빨리 변하는 환경에 적응도 힘든 상황에서 데브옵스는 조직 자체를 흔드는 일이다. 이미 갖춰진 조직에서는 R&R 문제로 실현이 쉽지 않고 운영 안정성 측면 때문에 누구에게도 이런 일을 전체적으로 할 수 있는 권한을 부여하지 않기 때문이다.
이 책은 현행 프로젝트나 현행 서비스 환경을 데브옵스로 전환하는 데 필요한 대부분을 설명하고 있다. 1장부터 순서대로 따라 하다 보면 어느 순간 데브옵스 환경의 실체를 볼 수 있을 것이다. 또한 이 책에 나와 있는 예시를 여러 번 반복적으로 구축하다 보면 누구든지 자신이 수행할 프로젝트를 데브옵스로 쉽게 이끌 수 있는 경지에 오르게 될 것이다. 현실적으로 데브옵스로의 전환이 용이하지 않더라도 이 책을 통해 어떻게 하면 데브옵스로의 연착륙이 가능할지에 대한 아이디어를 얻을 수 있을 것이다. 또한 스타트업이나 신규 프로젝트를 기획하고 있다면 이 책에서 제시한 대로 따르면 200%의 실적을 달성할 수 있을 것이다.
