글로벌 칼럼 | '민첩한' IT 만들기, '데브옵스'만으로는 부족하다

데브옵스(Devops)가 큰 인기다. IT 관련 기사들을 보면 마치 데브옵스가 IT의 구원자처럼 들리기도 한다. 그리고 대부분의 IT 유행어들이 그렇듯 데브옵스란 용어도 컨설팅 서비스와 클라우드 서비스, 소프트웨어에 이르기까지 모든 것들을 파는데 동원된다. 그러나 개발은 판매 대상이 아니다. 사실 제품이나 서비스가 아니어서 팔 수도 없다. 개발은 본질적으로 리더십의 문제다.

데브옵스는 개발과 운영 쪽 직원들이 더 '민첩하게'(agile) 딜리버리 주기를 지원하기 위한 상향식 이니셔티브로 시작됐다. 이른바 '애자일' 개발은 더 좋은 성과를 가능케 하지만 그 민첩성이 가져오는 변화 때문에 작업이 늘어나고 필수적으로 운영 부담도 증가한다. 그래서 데브옵스 접근방식은 개발과 운영팀들이 협력하든 서로 분리되든 기본적으로 조직적 문제를 개선하도록 압박한다.

이러한 어려움은 IT 조직의 문화를 바꾸고 엔드-투-엔드 품질, 민첩성, 시장 진입 시간 등에 대한 성과 인센티브를 할당하는 것 외에 해결 방법이 없다. 즉 데브옵스에 의해 제기된 조직적 문제들은 단순히 개발과 운영 사이의 거리를 좁히는 것으로는 개선할 수 없다.

'개발 vs. 운영' 분쟁을 극복하는 방법
개발 조직과 운영 조직 사이에는 긴 분쟁의 역사가 있다. 개발 쪽은 운영 쪽을 프로젝트를 신속하게 마무리하는데 걸리적거리는 장애물로 본다. 운영 쪽은 자신이 요구하는 품질, 가용성, 운영 용이성 기준을 개발 쪽이 맞추지 못한다고 생각한다.

그래서 이런 견해차를 좁히기 위해 데브옵스는 릴리즈 관리자(release manager) 같이 양측 모두에 걸친 역할을 수행하고 동시에 둘 사이의 커뮤니케이션과 협업을 조율한다. 그러나 이런 접근방식은 비교적 작거나 복잡하지 않은 기업에서는 통할 뿐 세계적 기업을 상대해야 하는 IT 조직에서는 역부족이다. 대부분 대기업은 파편화된 레거시 기술로 IT 인프라가 구축됐는데, 민첩성과 파편화는 물과 기름처럼 서로 따로 논다.

데브옵스 리더십 문제는 사일로화된 사고방식에서 오는 문화를 IT를 구성하는 모든 기능에 걸쳐 품질과 시장 진입 시간의 관점으로 바꿔야만 해결할 수 있다. 이는 강력한 CIO 리더십을 통해서만 주도할 수 있다. CIO는 개별 부서 팀장들의 목표를 시장 진입 시간을 줄이고 품질을 높이면서 과거의 사일로화된 기능적 인센티브를 해체하는 것으로 조정할 필요가 있다.

십 년 전 이런 사일로화된 기능들은 책임소재가 분명하고 개발속도가 폭포수 개발방식으로 관리됐다. 그러나 현재는 IT의 소비자화와 급속한 변화의 시기를 맞아 이 사일로화된 시스템들은 혁신을 가로막는 걸림돌이 되고 있다.

예를 들어, 딜리버리 부서는 코드 관련된 팀이든, 시스템 관련 팀이든 상관없이 제품 품질로 평가받아야 한다. 품질 문제에 대해 자기 목소리를 분명히 낼 수 있어야 하고 운영 쪽의 기능 개발자와 협업할 필요가 있다. 품질은 운영만의 문제가 아니기 때문이다.

같은 이치로, 운영 부서는 사업 동인을 이해하면서 신속하게 사업적 가치를 제공하는 것을 지원하고 비용 효율성을 높이는데 인센티브가 주어져야 한다. 이 역시 딜리버리 만의 문제가 아니다. 만약 이런 기능적 팀들의 보수가 엔드-투-엔드 가치와 품질 딜리버리에 달려있다면, 그 조직 역시 그들의 기능적 파트너들과 협업해야 할 필요성을 깨달을 것이다.

갈등 조정을 넘어 미래를 향해
만약 데브옵스만으로 크고 복잡한 조직의 민첩성을 끌어올릴 수 없다면 어떻게 해야 할까? 민첩성을 높이기 위해서는 간단히 측정할 수 있는 것이 아니라 반드시 정량화해야 하는 기준이 있는 것처럼, 민첩성을 실현하기 쉬운 분야가 아니라 시장 진입 시간을 줄여 가장 큰 이익을 낼 수 있는 분야에 노력을 집중해야 한다.

즉 시장 진입 시간을 줄였을 때 가장 효과가 큰 사업 분야부터 시작해야 한다. 이를 위해서는 고객 요구사항의 관점에서 생각하고 거꾸로 작업해야 한다. 기술적 디자인과 프로세스 디자인, 조직적 디자인에 창의적인 모습을 보여야 한다.

마찬가지로 민첩성을 강화하려면 애자일 딜리버리 모델을 충분히 지원할 수 있는 유연한 기술 프레임워크로 바꿔야 한다. 민첩성은 프로세스에 그치는 것이 아니라 사람과 기술에 관한 문제다. 민첩성은 생각의 틀을 깨고 이해당사자들에게 최대한 빨리 가치를 전하는 방법을 찾아내는 것이다. 따라서 필요에 따라 전통적인 소프트웨어 개발 주기 모델도 고려할 필요가 있다. 물론 이 과정에서도 가장 중요한 것은 결과물에 대한 품질과 지속가능성임을 잊어서는 안 된다.

데브옵스는 운영과 개발 직원들이 전통적인 조직 모델이 통하지 않음을 인식했기 때문에 부상한 것이다. 기본 아이디어는 훌륭하다. 그러나 그 개념을 적용하기 위한 마케터의 노력에도, 데브옵스는 모든 조직 문제를 치유할 수 있는 만병통치약은 아니다.

체중을 줄이는 것처럼 결국 강한 운동과 인내만이 성과를 만든다. 민첩해지려는 시도의 발목을 잡는 사일로화된 생각의 군살로부터 조직이 자유로워지기 위해서는 근본적으로 운영방식을 바꿔야 하고 리더가 솔선수범해야 한다. 품질과 지속가능성, 시장 진입 시간이라는 전체 목표를 조직의 목표와 일치시킬 때 비로소 애자일의 장점이 실현될 수 있다. editor@idg.co.kr