데브옵스로 클라우드 ALM을 가속화하는 법

우리는 소프트웨어 엔지니어링에 있어서 큰 발전을 이룩했다. 민첩한 업무 실행, 빈번한 점검, 자동화를 통한 구축/시험 덕분에 지난 10년 동안 개발 활동이 매우 신속해졌다. "지속적인 통합"이라 불리는 이런 혁신으로 개발이 빨라지고 프로젝트 문제가 감소하며 프로젝트 프로세스를 더욱 잘 예상할 수 있게 됐다.

하지만 많은 IT 조직들은 애플리케이션 라이프사이클이 빨라지면서 새로운 코드를 생산할 때까지 작업을 멈추는 일이 발생하게 되었다. 운영의 영역에서 각 다운스트림(Downstream) 그룹이 선택한 툴을 이용해 그 작업을 완수하면서 다양하면서 중복적인 노력으로 실행된 수동 프로세스로 회귀하는 일이 비일비재하게 발생하고 있다.

코드 변경사항이 완전히 자동화된 애플리케이션 라이프사이클을 통해 지속적인 배치를 IT 조직들이 달성하기 전에는 현업의 요구사항이 계속해서 미해결 상태로 남게 될 것이다. 게다가 현업 부문들은 애플리케이션 스폰서의 필요와 크게 상관이 없는 IT 자체 개입의 또 다른 예로써 지속적인 통합에서의 모든 긍지를 갖게 될 것이다.

필자는 지속적인 배치에 반하는 여러 가지 주장을 들어 알고 있다. 이런 주장은 잘못된 코드를 생산 환경에 도입했을 때의 결과와 E2E(End to End) 자동화가 이행될 경우에 잘못된 코드가 공개될 가능성 증가에 초점을 맞추고 있다. 결과적으로 이 주장의 요지는 인간의 개입 없이는 잘못될 소지가 있다는 것이다.

경험상 인간의 개입 때문에 문제가 발생하는 경우가 더 많기 때문에 이 주장은 잘못되었다고 생각한다. 지루한 수동 프로세스의 근거야 어떻든 사용자 수요가 우선시 될 수 밖에 없다. 이미 수립된 접근방식을 고수한다면 아무 것도 얻을 수 없을 것이다. 자체 자원을 위해 필요한 수 주에 걸친 요청 사이클에 지쳐 아마존 웹 서비스서 VM을 구매한 개발자들에게 물어보기 마란다.

지속적인 배치를 위해서는 자동화, 통합, 인센티브 조정이 필요하다
지속적인 배치를 위해서는 4가지가 필요하다.

최적화된 자동화 프로세스. 프로세스에 위원회의 검토가 포함된다면 누군가 추가 진행을 승인하는 동안 프로세스가 정지하거나 주기적인 공개를 간과하여 시스템이 전혀 빨라지지 않는 상황이 발생할 수 있다. 복잡성 또는 다른 이유로 비정기적인 변경사항이 자동이어서는 안 된다는 주장은 변화를 위해 인간의 개입이 필요하다는 주장과 완전히 다른 이야기이다. 이것은 단지 정기적인 변경사항을 위한 자동화 통과를 활성화하면서 필요에 따라 개입을 지원하는 프로세스를 이행해야 한다는 뜻이다.

통합된 E2E 툴체인(Toolchain). 프로세스를 뒷받침하는 툴이 존재하지 않는 한 자동화된 작업 흐름은 무의미하다는 것은 확실하다. 기본적으로 한 단계에 있어서 툴의 결과물은 다음 단계의 툴로 이전되어야 하며, 이는 툴들이 서로 연계되어야 한다는 뜻이다.

오늘날, 여러분이 선택하는 데브옵스 툴체인은 대형 벤더들이 제공하는 값 비싼 브랜드 서비스이거나 자체적으로 오픈소스 구성요소들을 한데 묶어 사용하는 경우가 대부분이다. 각 접근방식마다 장단점이 있다. 이 영역의 중요성이 점차 증가하는 가운데 이에 대한 관심을 갖는다면 더욱 유연하면서 감당할 수 있는 솔루션이 머지 않아 시장에 등장하게 될 것이다.

공유된 애플리케이션 아티팩트(Artifact). 이런 연합 툴들은 이를 이용하는 모든 집단에 공통적인 아티팩트를 거쳐야만 한다. 실행과 설정을 재생성하게 되면 아무리 자동화된 런북(Runbook)이라 하더라도 추가적인 작업이 필요하며 실수의 가능성이 높아지고 신속한 기능 제공을 저해하게 된다. 단일한 일련의 아티팩트를 사용하고 이것들을 그룹들에 전달하여 필요에 따라 기관을 분리할 수 있는 권한을 추가하거나 제거하는 것이 훨씬 낫다.

기관 내 메트릭스와 인센티브 조정. 인센티브의 경우, 문화에 관한 이야기를 하지 않을 수 없다. 앞서 언급했듯이 여러 집단을 한데 모아 개인적인 관계를 발전시킨다고 해서 마찰과 실수가 사라질 것이라고는 생각하지 않는다. 생산적으로 협동하는 집단들은 반드시 일련의 메트릭스와 인센티브를 공유하게 마련이다. 한 집단을 업데이트된 기능의 공개 빈도에 따라 측정하고 다른 그룹을 운영 안정성으로 측정하면 목표 달성에 대한 충돌이 발생할 수 있다.

단일한 일련의 조치를 이행하여 모두가 협력하도록 해야 한다. 운영 안정성에 대한 필요와 빈번한 업데이트 요건을 조합하면 여러 집단이 아니라 한 집단 내에서 문제가 발생하기 때문에 이전의 모든 메트릭스를 연합하여 이를 달성할 수 있을 것이라고 생각하지 말기를 바란다.

분명한 것은 이런 일이 쉽지 않으며 이로 인해 엄청난 분열이 발생할 수 있다는 점이다. 이것은 분명한 사실이며 우리가 10년 전의 IT 세상에 살았다면 이런 파괴적인 조치를 취할 필요가 전혀 없었을 것이다.

하지만 우리가 사는 세상은 다르다. 우리가 살고 있는 세상은 비즈니스 변화의 속도 가속화를 위해 IT가 예전과는 달라져야 하는 세상이다. 제조업은 지난 30년 동안 효율성과 비용 절감을 추구하면서 과거의 방식을 버리고 새롭게 탈바꿈해왔다. 이제는 모든 것들이 빠르게 변화하고 있으며 IT에게는 이렇게 긴 시간이 허락되지 않을뿐더러 이를 피해갈 수도 없다.

* Bernard Golden은 클라우드 관리 소프트웨어 회사인 엔터프라이즈 솔루션 포 엔스트라투스 네트웍스(Enterprise Solutions for enStratus Networks)의 부사장이다. 또 '초보자를 위한 가상화(Virtualizations for Dummies)' 등 3권의 가상화 및 클라우드 컴퓨팅 저서를 출판한 작가다. ciokr@idg.co.kr