[데이터넷] 민첩한 서비스 개발과 배포가 기업 경쟁력 강화에 필요한 핵심 요소가 되면서, 각기 분리돼 있던 개발과 운영을 하나로 통합한 ‘데브옵스(DevOps)’ 적용이 확산되고 있다. 데브옵스는 특별한 기술이나 제품이 아닌 하나의 업무 방법이자 문화이기에, 성공적인 적용을 위해서는 구성원들의 합의가 있어야 한다. 특히 갈수록 빨라지는 서비스 배포 주기에 맞추려면 자동화 환경을 구성해야 하는데, 이를 위한 사전 조건에 데브옵스가 필요한 만큼 앞으로는 더욱 많은 곳에서 데브옵스를 채택하게 될 것으로 전망된다. <편집자>

IT의 발전은 우리 사회를 더욱 복잡한 환경으로 바꾸고 있다. 소프트웨어 개발 측면에서도 코드 작성에 앞서 시스템 운영을 걱정해야 할 정도다. 이제 고객들은 전례 없는 민첩성에 기반해 다양한 애플리케이션 서비스를 이용하기를 기대하고 있으며, 그로 인해 예전 차세대 프로젝트와 같이 오랜 시간을 들여 완성도를 최대한 높이는 방식의 소프트웨어 개발 방식은 현재의 IT 환경에 적합하지 않게 됐다.

실제로 대부분의 국내 인터넷 서비스들은 주로 새벽에 점검시간을 가지면서 서비스 오류를 패치하거나 새로운 기능들을 배포하곤 했다. 해당 시간에는 서비스 이용이 불가능하며, 점검이 끝날 때까지 기다리는 수밖에 없다. 물론 이때 점검을 하는 이유가 이용자 접속이 드물기 때문이지만, 가령 이용자들이 활발하게 접속하는 점심시간이나 퇴근시간 이후 이러한 상황이 발생한다면 인내심이 약한 이용자들의 대거 이탈 현상을 보게 될 수도 있다.

데브옵스는 개발(Dev)과 운영(Ops)이 결합된 개념으로, 예전과 달리 개발과 운영을 분리해서 생각하는 것이 아니라 하나의 소프트웨어 개발 수명주기(SDLC)로 보고 개발과 운영이 끊임없이 이어질 수 있도록 하는 것을 의미한다. 이를 활용하면 서비스 오류 패치나 신규 기능 배포를 위해 서비스를 중단할 필요가 없으며, 개발 역량만 뒷받침된다면 하루에도 수백 번씩 새로운 소프트웨어 배포가 가능해져 현재 IT 환경에 가장 적합한 소프트웨어 개발 방식으로 평가되고 있다.

데브옵스 확산 막는 ‘SI’
개발과 운영은 언뜻 보면 별개 업무처럼 보이지만, 그렇다고 서로 남의 일이라 치부하고 신경쓰지 않는다면 제대로 된 데브옵스 구현이 어렵다. 무엇보다 개발팀과 운영팀을 하나의 팀으로 묶은 만큼 각 팀의 업무가 서로에게 영향을 준다는 사실을 인식하고 함께 참여할 수 있어야 한다. 그렇기에 데브옵스가 올바로 시행되기 위해서는 이러한 업무 문화 구축이 중요하다고 언급된다.

그러나 IT 강국을 자처하는 우리나라에서는 일부 스타트업들을 제외하면 이런 모습을 찾아보기 힘들다. 비록 조금씩 변화를 시도하고 있다 해도 오랫동안 굳어진 업무 문화를 한 순간에 바꾸는 것이 결코 쉽지 않기 때문이다.

그 원인으로 지목되는 것이 SI 사업이다. 그동안 IT는 사업을 지원하는 부수적인 도구로 여겨져 왔으며, 기업들은 비용 절감을 위해 IT를 외주업체에 위탁하는 경우가 많았다. 필요할 때마다 사업을 발주하는 것이 직접 IT 부서를 운영하는 것보다 비용적인 측면에서 유리하다고 여겼기 때문이다. 그 결과 소프트웨어 개발 역량이 없는 기업은 모바일 앱 하나를 개발할 때도 사업을 발주해 외주업체에 맡기는 형태가 지속돼 왔다.

이는 비록 비용을 절감할 수 있었다고 해도 현대 시대에 필요한 IT 역량을 갖출 수 없게 만들었다. 빠른 서비스 배포가 필요할 때도 외주업체의 개발 역량과 속도에만 의존할 수밖에 없으며, 해외 유명 서비스 등이 어느 날 갑자기 신규 기능과 서비스를 제공하는 것에 제때 대응하지 못하게 됐다.

그러나 시간이 지날수록 현업에서 IT에 요구하는 것은 점점 다양해지고 있으며, 모바일 앱 서비스는 그 자체가 비즈니스이자 자산이기 때문에 마냥 외주 개발에만 의존할 수 없는 상황에 처하게 됐다. 특히 데브옵스로 인한 소프트웨어의 빠른 개발과 배포의 이점을 알게 되면서 점점 더 많은 기업들이 데브옵스를 사내에 적용하기 위한 노력들을 하고 있다.

효과적인 협업 환경 구축 필요
사일로(Silo) 현상은 IT에서 오랫동안 문제로 지적돼 왔다. 이는 단순히 인프라 영역에서만 발생하는 문제가 아니라 조직 내에서도 발생한다.

개발자와 운영자는 한 그룹 내에 속해 있어도 소통이 원활하지 못하는 경우가 대부분이다. 각자 자기 일에만 충실하면 된다고 생각할 뿐이며, 이로 인해 원활한 협업이 이뤄지지 못하는 경우가 많다. 상황이 이렇다 보니 상호 유기적으로 연계돼야 할 양쪽의 업무가 충돌하기도 한다.

가령 개발자가 금요일 오후 5시에 작업 결과물을 운영자에게 넘겨주면, 운영자의 기분이 좋을 리가 없다. 퇴근을 앞둔 시간에 전달받았기 때문에 이를 테스트하고 배포까지 하려면 늦은 시간까지 업무를 해야 하기 때문이다. 만약 한 번에 정상적으로 기능이 동작하면 문제가 없겠지만, 오류가 발생했을 경우 업무 시간은 더욱 길어진다.

데브옵스의 목적은 이처럼 개발자와 운영자의 협업 부재로 인한 비효율성을 막고 빠르게 서비스가 배포될 수 있도록 하는 것에 있다. 개발자는 운영 업무에 대해 잘 모르고, 운영자 역시 개발 업무에 대한 이해도가 부족하다 보니 툴을 활용해 서로 간의 간극을 메꿔나갈 수 있도록 하는 방안들이 등장하고 있다.

그동안 개발자는 개발만 담당하며, 운영자는 개발 결과물의 테스트부터 배포를 진행했다. 그러나 툴을 도입하면 개발자들이 직접 테스트를 진행하고 배포까지 할 수 있게 되며, 운영자는 테스트나 배포 과정이 잘 이뤄질 수 있도록 인프라와 플랫폼 관리에만 더욱 치중할 수 있게 된다.

혹자는 개발자 업무가 늘어난다며, 운영자 업무가 줄어든다며 이의를 제기할 수도 있다. 물론 지금까지 운영자들이 소프트웨어를 배포하는 역할을 해왔지만, 그들의 본질적인 업무는 서비스가 정상적으로 동작할 수 있도록 서버, 스토리지, 네트워크 등의 인프라를 관리하고 운영하는 데 있다는 것을 알아야 한다. 실제로 운영자가 테스트를 진행하는 것은 해당 서비스가 정상적으로 동작하느냐 아니냐의 여부만 확인하는 것일 뿐, 개발자의 의도대로 서비스가 동작하는지를 확인하는 것은 어려운 일이다.

개발 문화·업무 프로세스 정립해야
데브옵스는 일의 ‘방법’이지만 그 실체를 정확히 모른 채 조직 이름만 바꿔 시행하려 하면 제대로 된 효과를 보기 어렵다. 또 데브옵스를 위한 툴만 도입하면 되는 것도 아니다. 툴은 데브옵스 효과를 높여주는 도구일 뿐, 데브옵스 구현을 위한 문화나 업무 프로세스까지 제공해주지는 못한다.

중요한 것은 특정 조직을 지정해서 프로세스를 할당하는 것만이 아니라 개발해야 하는 소프트웨어에 대해 서로 다른 역할을 가진 전문가들이 하나의 팀을 구성하는 것과 이를 지속적으로 유지해나가는 것이다. 같은 주제를 대할 때도 이해도가 높은 사람과 그렇지 않은 사람들이 있을 수 있지만, 함께 서로의 업무를 배워가면서 일을 처리해야 한다.

그러나 그 어느 누구도 가보지 못한 길을 가는 것은 결코 쉬운 일이 아니기에 처음에는 누군가의 도움을 받는 것이 권장되며, 오픈소스컨설팅은 이러한 수요를 가진 기업들을 위해 ‘데브옵스 시뮬레이션’을 제공하고 있다.

‘데브옵스 시뮬레이션’은 디지털 트랜스포메이션을 위한 시뮬레이션 프로그램 전문 기업 ‘G2G3’가 심리학자이자 교육이론학자인 데이비드 콜브(David Kolb) 박사의 경험학습이론 사이클에 기반해 개발한 것이다. 참석자들이 실제 비즈니스를 운영하고, 다양한 프로세스 변경을 계획 및 테스트하며, 그에 따른 결과로부터 경험할 수 있는 비즈니스 및 기술 가치를 제공하는데 초점이 맞춰져 있다.

이를 통해 참석자들은 ▲협업 수준 증대 ▲사일로적 사고 감소 ▲비전 및 목표, 공통적인 성공 기준에 대한 공유 ▲품질에 대한 비용 감소(결함 조기 발견 및 해소) ▲테스트 시간 감소 ▲제품 출시 기간 단촉 ▲지속적인 애플리케이션 배포 ▲더 빨리 더 많이 제품을 출시할 수 있는 능력 향상 등의 경험을 할 수 있다.

시뮬레이션 체험 과정에서 협업하는 훈련도 중요하지만, 실제로는 사업에 필요한 결과물을 만들어내는 과정을 학습하게 된다는 점에 큰 의의가 있다.

빠른 시장 검증 목표
데브옵스를 통해 소프트웨어를 개발할 때는 처음부터 최종 제품을 목표로 하지 않는다. 우선 소프트웨어를 만드는데 필요한 프로세스나 스펙, 이용층 등에 대해 먼저 정리하고, 최소한의 필요 기능이 갖춰진 제품(MVP)을 만들게 된다. 이후 해당 기업 팀원들과 지원 기업 연구원들이 함께 본격적인 제품 개발에 돌입한다. 이를 통해 대략 2~3달 안에 첫 결과물을 확인할 수 있다.

이렇게 개발된 소프트웨어는 시장 반응 확인에 이용된다. 성과가 반드시 좋아야 할 필요는 없다. 시장 반응이 좋으면 이를 더욱 발전시키면 되고, 시장 반응이 좋지 못할 경우 과감히 프로젝트를 정리하고 다른 프로젝트를 추진하면 되기 때문이다. 이처럼 해당 소프트웨어의 개발을 지속할지 아닐지의 여부를 빠르게 판단할 수 있어 비즈니스의 민첩성과 유연성을 확보할 수 있다.

그동안 기업들이 전통적으로 해오던 소프트웨어 개발 방식에 의하면 첫 배포용 제품이 나오기까지 빨라도 반년, 늦으면 1년 이상 걸리는 경우가 대부분이었다. 이는 시장에서 제품을 검증받기까지 걸리는 시간도 길 뿐더러, 제품이 출시되기까지 드는 비용도 많을 수밖에 없다.

더 큰 문제는 오랫동안 추진해온 프로젝트인 만큼 시장 반응이 좋지 않더라도 바로 정리하지 않는 대신 향후 추이를 지켜보면서 검증 비용을 추가적으로 지출하게 되는 경우다.

이 같은 과정을 거치고 나면 팀원들에게는 새로 도전해보고 싶은 아이디어와 목표가 생기게 되며, 이들이 각자의 위치로 돌아가 본인의 경험을 전파하면 데브옵스 문화가 전사 확산될 수 있다.

점진적인 기능 개선 도모
소프트웨어 개발 프로젝트는 자동차를 만드는 것에 비유된다. 이때 많이 지적되는 사항은 단계를 거치지 않고 처음부터 자동차를 만들려고 한다는 점이다. 일단 바퀴와 차체를 만들었다 해도 그것만으로는 자동차가 될 수 없다. 엔진, 제동장치, 조향장치, 안전장치 등 자동차가 제 기능을 다 할 수 있도록 하는 다양한 기능과 부품들을 필요로 한다. 그렇기에 자동차 완제품을 만들기까지 많은 시간이 걸린다.

하지만 배포되지 않은 제품은 가치가 ‘0’에 불과하다. 그 사이 연구개발(R&D)비용이나 생산비용 등은 꾸준히 발생한다. 이에 중요한 것이 MVP를 먼저 만들어내는 것이다.

자동차를 만든다고 기획은 했더라도 처음부터 자동차를 만들기보다 이동수단에 대해 정의하고 MVP에 해당하는 간단한 킥보드를 만들기는 쉽다. 이후 시장에 내놓고 반응을 보면 이를 지속적으로 판매할지 말지를 판단할 수 있게 된다.

만약 시장에서 반응이 좋다면 사업을 지속하면서도 추가적인 기능 개선을 할 수 있다. 단순히 사람의 힘만으로 달리는 것이 아니라 배터리를 이용한 동력을 추가하고, 한층 속도가 빨라지면서 속도계와 제동장치를 달고, 한 사람뿐만이 아니라 다른 사람도 이용할 수 있도록 하기 위해 크기를 키우고 하는 과정을 거치면 어느 순간 자동차가 완성된다.

중요한 것은 첫 과정이다. 처음부터 최종 목표를 만드는 것이 아니라 최종 목표를 위해 필요한 것들을 갖춰 나간다는 개념으로 진행할 필요가 있다. 한 번의 과정이 끝나면 피드백을 취합해 반영하고, 그러면서 기능을 확대해 나간다. 해당 과정을 반복하게 되면 점점 더 짧은 기간 내 새로운 기능들이 추가될 수 있고 지속적인 배포도 가능해진다.

“데브옵스, 빠르게 변화하는 고객 수요 대응에 최적” 과거에는 고객이 무엇을 원하는지 알았어도 기술 부족으로 인해 그것을 만들지 못하는 경우가 많았기에 기술을 빠르게 습득하는 것이 중요했다. 그러나 이제는 기술이 있어도 고객이 무엇을 원하는지를 모르게 됐다. 그렇기에 제품을 빠르게 만들어 시장에 출시한 후, 고객 반응을 확인하며 그에 맞춰 제품을 개선해나가는 방식이 필요하다. 결국 하루에도 수십 번의 배포를 통해 제품의 완성도를 높여나가며 고객의 바뀌는 수요에 쫓아가는 것이 현재의 추세가 됐다. 뿐만 아니라 고객이 지루해하지 않게 계속 새로운 콘텐츠도 제공해야 한다. 이제 소프트웨어 개발에 최종이라는 개념은 사라졌으며, 제품 수명이 끝나거나 고객이 더 이상 찾지 않게 될 때까지 계속 발전해 나가야 하며, 이는 데브옵스가 아닌 과거 방식으로는 사실상 불가능하다.