데브옵스(DevOps)를 하지 말아야 할 기업이 있다
디지털 트랜스포메이션에 대하여- 2
저번 애자일 관련 글에 이어서, 이번 글에서는 또 하나의 핫이슈인 데브옵스(DevOps)의 개념을 간단하게 알아보고, 기업에서 적용할 때 고려해야 할 부분을 논의하겠습니다. 이 글에서도 개발자 위주의 기업이 아니라 국내에서 전통적으로 비즈니스에 IT를 활용하는 기업을 대상으로 하며, 필자가 개발자 이기 때문에 Dev의 관점이 강할 수 있습니다. 작은 경험과 개인적인 생각에서 시작된 글이므로 다양한 의견은 환영합니다.
데브옵스 (DevOps) 란?
데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발 조직과 운영조직 간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.
정의를 보면 개념 자체는 쉽게 이해할 수 있지만, 막상 이를 기업환경에 적용하려고 보면 만만치 않음을 느낄 수 있습니다. 그 이유는 소통, 협업, 환경, 문화 등 주관적 해석이 필요한 개념들로 이루어져 있기 때문으로 보입니다. 그래서인지 구글 검색 등을 통해 데브옵스에 대해 설명하는 글을 보면 글쓴이의 해석에 따라 많은 차이를 보이기도 합니다.
본문에서는 이런 정의상의 모호함이 기업의 자의적 해석을 만났을 때 발생할 수 있는 몇 가지 문제점들을 다뤄보겠습니다.
Dev + Ops vs Ops + Dev
많은 기업에서 데브옵스를 해석할 때 가장 흔히 발생하는 문제는 '개발자가 운영까지' 하는 것인지, '운영자가 개발까지' 하는 것인지를 결정하려고 한다는 점입니다. 그리고 이런 결정이, 흔히 말하는 기획팀에 의해서 추진된다는 것은 더 큰 문제가 됩니다.
이런 문제가 발생하면 보통의 기업에서는 개발자가 운영 업무의 일부를 담당하는 것부터 시작하게 됩니다. 운영 업무가 더 단순하기 때문은 아닐 것이고, 대부분의 기업은 개발자가 운영자보다 많고 평상시에 개발자들이 릴리즈 등을 하면서 운영적인 요소에 접근할 기회가 반대의 경우보다는 자주 있기 때문으로 해석해볼 수 있습니다.
어떤 형태인지를 떠나서, 이런 식의 접근이 기업에 데브옵스 적용이 실패하는 제1의 요인이라고 볼 수 있습니다. 물론 데브옵스를 적용하면 상호 간의 역할이 확장되는 것이 당연합니다. 하지만 이는 동등한 협업을 위한 것이지, 어느 한쪽이 다른 쪽의 업무를 대신 담당하면서 발생하는 불균형은 없어야 합니다.
어느 한쪽이라도 협업이 아닌 업무의 가중으로 느껴지는 순간 데브옵스 장기간 적용하는 것이 실패하는 것은 당연한 수순이며, 기업에서는 그러지 않기 위해 각 팀의 역할을 어떻게 연결시킬지를 최우선으로 고민해야 합니다.
데브옵스는 비용절감이 아니다
위에서 말한 문제점은 바로 기업의 인력운용 문제와 직결됩니다. 인력운용 문제는 대부분의 기업에서 가장 민감한 문제 중 하나이며, 임원과 직원 간의 온도 차이가 극명한 부분이기도 합니다. 데브옵스가 개발자, 운영자의 추가 업무부담으로 느껴지고 거부감이 드는 것은 이러한 인식 차이에서부터 시작될 가능성이 큽니다. 대부분 기업의 임원들이 데브옵스 개념을 접하면 떠올리는 이미지는 '1인 2역' 일 것입니다. 우리는 임원들이 항상 비용의 효율적 사용을 고려하며, 그들에게 인력감축 또는 기존 인력의 최대한의 활용은 최대 관심사 중 하나라는 것을 잊어서는 안 됩니다. 물론 많은 직원들은 이미 임원진의 이런 특성을 잘 알고 있기 때문에 데브옵스 적용 시 미래에 자신들에게 일어날 재앙을 예감하고 기피하게 됩니다.
임원들은 데브옵스는 서비스별 최적화된 릴리즈 환경과 운영을 위한 '협업' 문화 또는 도구의 집합이라는 것을 받아들여야 하며, 편의에 따라 비용절감 측면으로 왜곡하지 말아야 합니다. 최근 발생한 삼성증권의 주식 오류 발행 사태는 비단 해당 기업만의 문제는 아닙니다. 사실상 국내 기업은 이미 인력운용을 비용절감에 포함시키는 바람에 IT 내부적으로 서비스들은 언제든 터질 수 있는 리스크를 가지고 있다고 해도 과언이 아닙니다.
진정한 의미의 데브옵스를 위해서는 일정기간 기존 인력의 역량 향상을 위해 상당한 비용을 투자해야 하며, 서비스별 인력 확보를 위해 추가 인력이 필요할 것입니다. 이런 부분을 감수할 준비가 되지 않은 상태에서 또다시 비용절감 측면에서 접근한다면, 데브옵스를 도입하는 순간 곪아있던 염증들이 터져 나오는 것은 시간문제 일 것입니다.
레거시 코드와 테스트 자동화
데브옵스의 정의나 발생 동기를 보면, 빠른 릴리즈를 근본적인 목표로 가지고 있습니다. 이를 위해서 빠른 개발 및 릴리즈 프로세스를 만드는 것도 중요하지만, 테스트 절차를 효율화하는 것이 무엇보다 중요합니다. 개발 프로젝트에서 많은 경우 개발에 소요되는 시간보다 각종 케이스를 테스트하는데 더 많은 시간이 소요됩니다. 이런 문제를 해결하기 위해서 실제 데브옵스를 도입하는 기업에서는 테스트 자동화를 추진하고, 이는 옵션이 아니라 필수요소라고 할 수 있습니다.
문제는, 기존 기업들이 개발하던 방식과 레거시 코드가 테스트 자동화를 적용하기에 쉽지 않은 구조라는 것입니다. 잘 갖춰진 IT기업이 아닌 이상 내부적으로 코드 리뷰 또는 리팩터링을 체계적으로 진행하는 경우가 거의 없으며, 비즈니스 로직을 구현하는 기업의 경우 일반적인 솔루션과는 다르게 규정, 업무의 변화에 따라 급하게 예외 로직을 추가하기도 하며, 그렇게 누적된 코드는 단위 테스트가 사실상 불가능한 지경에 있습니다.
이런 코드가 1, 2년이 아니라 10년 또는 30년 이상 누적된 경우가 많고, 그 기간 동안 리팩터링이 전혀 진행되지 않은 코드가 대부분입니다. 시간이 흘러 현재의 개발자들은 이런 구조에 문제가 있다는 것을 충분히 인식하지만, 대부분은 현재 업무나 이슈를 해결하기에만 적합하거나 벅찬 인력이 유지되는 상태이기 때문에 리팩터링이 쉽지 않은 게 현실입니다.
레거시 코드의 리팩터링을 위해서는 기존 업무의 경감 또는 인력 확보가 필수요소지만, 임원진 입장에서는 기존에도 문제없이 운영되는(임원진만 그렇다고 느끼는...) 서비스를 추가 비용을 투입해 개선할 필요성을 느끼지 못합니다. IT 경험이 없는 임원만 존재할 때는 말할 것도 없지만, 경험이 있는 임원이라 하더라도 본인들의 시대에 개발했던 경험을 떠올려 운영하며 현재 개발자들의 문제의식을 노력 부족으로 치부해버리기 일쑤이므로 큰 기대를 하지 않는 게 개발자들의 정신건강에 이롭습니다.
좋은 툴이 주는 효과를 알지 못하는 임원진에게...
우리 기업들의 임원진은 좋은 툴이 주는 효율성을 지나치게 무시하는 경향이 있습니다. 물론 툴이 모든 것을 해결하지 않으며 좋지 않은 툴도 익숙해지면 베테랑을 효율적으로 보이도록 사용하는 경향이 있지만, 데브옵스의 경우 그런 식의 접근으로는 해결할 수 없는 영역임을 인지할 필요가 있습니다. 기업 입장에서는 기존의 툴들로 이미 개발과 운영이 잘 이루어지고 있고, 이를 한 사람 또는 두 사람이 협업하기만 하면 데브옵스가 이해할 수 있습니다. 그리고 그러는 편이 비용절감 측면에서 유리하기 때문에 다른 해석의 여지를 주지 않을 수도 있습니다.
데브옵스는 기존의 프로세스를 잘 연결해야 하는 것은 맞지만, 일반적인 생각보다 더 유기적으로 연결되어 담당자가 빠른 개발을 통해 릴리즈를 하는 과정에서 불필요한 요소들에 신경 쓰지 않도록 하는 것이 무엇보다 중요합니다. 이를 위해서는 개발, 테스트, 형상관리 등 릴리즈 및 모니터링의 모든 과정이 잘 연계될 수 있는 고수준의 툴을 사용하는 것은 장기적으로 데브옵스 문화를 정착시키는데 큰 역할을 할 것입니다.
물론 툴의 도입은 단기적으로 불필요한 비용으로 인식될 것이고 위에서 언급한 구조적 문제가 해결되지 않은 상태에서는 큰 효과를 발휘하지 못할 수 있습니다. 하지만 구조적 개선의 의지가 충분하고, 이미 진행하고 있는 기업이라면 그 과정을 뒷받침하고 안정적으로 운영하기 위한 잘 갖춰진 툴(비용절감을 위해 그나마도 저렴한 툴을 사용하려는 관습을 버리고...)의 도입을 고민해야 합니다.
당신의 회사가 데브옵스 전담팀을 구상 중이라 면...
하루빨리 이직을 고민하시기 바랍니다. 조금 과장했지만, 이런 방식으로 접근하는 임원들이 있다면 위에서 언급한 '1인 2역' 보다 더 저수준의 통찰력을 가진 임원 밑에서 일하고 있다고 생각하시면 됩니다. '1인 2역'을 아주 좋게 해석해서 인식의 오류로 받아들일 여지가 있다면, 데브옵스 전담팀은 개념 자체를 이해하지 못했을 뿐만 아니라 개선의 여지가 없는 Top-Down 방식의 고질적 문제를 보여준다고 할 수 있습니다. 더 큰 문제는 이런 방식의 접근을 아주 정상적이며 체계적인 프로세스로 여긴다는 점에 있습니다.
국내의 많은 기업은 IT를 기업 내부의 공짜 서비스로 인식해왔고 IT인력을 체계적으로 육성해본 경험이 없습니다. 방법을 모르기 때문도 있지만, 특정 프로세스를 도입할 때 기획팀을 통하거나 TF를 만들어 Top-Down 방식으로 진행하는 것이 비용절감 측면에서 더 효과적이기 때문입니다. 대부분의 개발자는 기업 내 생존을 위해서 알아서 적응하면서 역량을 키워왔고 그런 방식으로도 충분했다고 느껴온 임원들은 데브옵스를 접할 때도 동일한 방식으로 접근할 가능성이 있습니다.
이런 기업에서 근무하고 있다면 장기적으로도 개인의 역량 향상을 위한 기업의 투자는 제한적일 것이고, 효율적이지 못 할 것입니다. 문제는 임원진 나름대로는 투자를 했다고 생각하며, 제대로 된 개선을 이뤄내지 못한 업무 담당자들을 탓할 가능성이 높습니다. 만약 독자분이 기획팀 소속이거나 IT 담당자라면 전담팀에 속하지 않기 위해 많은 노력을 하시기 바라며, 이미 이런 TF가 진행 중이라면 가시적인 성과가 날 수 없는 구조이기 때문에 부디 잘 꾸며진 보고서가 임원진에게 통하기를 기도하시기 바랍니다.
이번 글에서도 아주 주관적인 견해로 DevOps를 적용하려는 기업에 존재하는 문제점과 발생 가능한 문제들을 나열해봤습니다. 물론 더 많은 문제들이 있겠지만 작성하는 글에서는 전형적인 한국형 기업에 존재하는 구조적인 문제점과 그로 인해 발생할 수 있는 일반적인 문제를 다루려고 노력했습니다. 개인적으로 본문에서 나열한 문제가 존재하거나 개선의 의지가 없는 기업은 현상유지라도 하기 위해서 데브옵스 도입을 고려하지 않는 편이 나을 것 같습니다. 서로 다른 견해나 추가적인 의견은 댓글을 통해 자유롭게 부탁드립니다.
