DevOps 도입이 자주 실패하는 이유 (그리고 해결 방법)

이 글은 원래 DevOps.com에 게재되었으며, 이후 업데이트 및 수정되었습니다.

"블록체인", "빅데이터", "디지털 파괴"와 마찬가지로 "DevOps" 역시 현재 대기업 IT 부서에서 흔히 남발되는 유행어 중 하나입니다.

많은 기업이 더 빠른 소프트웨어 개발 수명 주기의 필요성을 (정확하게) 파악했습니다. 이는 비즈니스 목표와 긴밀하게 연계된 보다 정밀한 프로세스로, 개발 팀과 운영 팀 간의 명확한 워크플로우와 협업을 가능하게 합니다. DevOps는 본질적으로 끊임없이 혁신하고 빠르게 배포해야 하는 현대 비즈니스의 요구를 수용할 준비가 된, 성숙한 "애자일(Agile)" 개발 방식입니다. 보안 전문가에게 DevOps는 환상적인 이니셔티브입니다. 프로세스 초기 단계부터 보안을 통합함으로써 버그 수정 비용을 절감하고 향후 발생할 수 있는 잠재적 재앙을 방지할 수 있기 때문입니다.

문제는 DevOps 도입에 진정으로 성공하는 기업이 드물다는 점입니다. 조직 전반에 걸친 적절한 지원과 육성, 이해가 없다면 DevOps는 금세 애물단지로 전락할 수 있습니다. 마치 언급조차 꺼려지는 골칫덩이 프로젝트처럼 말이죠.

그렇다면 무엇이 문제일까요? 이는 흥미로운 논의 주제이며, 제가 생각하기에 DevOps를 훨씬 원활하게 추진할 수 있는 몇 가지 접근 방식이 있습니다. 효과적인 프로그램은 단순히 새로운 도구, 직함, 팀 회의를 도입하는 것 이상을 의미합니다. 항상 쉬운 길은 아니겠지만, 시간을 들여 잘못된 전략을 수정하거나(혹은 처음부터 올바르게 구현하거나) 하는 것은 장기적으로 볼 때 훨씬 덜 고통스러운 일입니다. 궁극적으로는 더 높은 품질과 더 안전한 소프트웨어를 얻는 결과로 이어질 것입니다.

하나씩 살펴보겠습니다.

"애자일"이라는 굴레에서 벗어나십시오.

조직이 애자일과 DevOps 중 하나를 선택해야 하며, 일단 한 길을 정하면 뒤돌아보지 말아야 한다는 오해가 다소 존재합니다.

중요한 점은 두 가지를 하나로 고려하고 구현할 때 개발 프로세스가 가장 잘 작동한다는 것입니다. DevOps는 애자일 개발을 재창조하는 것이 아니라, 오히려 이를 확장하는 개념입니다. 프로세스가 정확히 애자일과 같거나, 혹은 애자일과 완전히 다르기를 기대할 때 탈이 나기 시작합니다.

애자일은 기획자, 테스터, 개발자를 처음부터 한 팀으로 묶고 프로젝트 전반에 걸쳐 열린 소통을 약속하는 교차 기능 팀의 원칙을 지지합니다. 애자일의 목표는 부서 간 장벽을 허물고 중복 작업을 줄이는 것인데, 이는 DevOps 프로세스의 장점이기도 합니다. 하지만 DevOps는 여기서 한 걸음 더 나아가 시스템, 보안, 운영을 통합함으로써 고객에게 완전하고 기능적인 소프트웨어를 제공하는 것을 궁극적인 목표로 하는 탄탄한 엔드투엔드 역량을 갖추게 합니다.

DevOps 중심의 프로세스로 전환하는 과정에서 필연적으로 겪게 되는 고충 속에서, 부서 간 장벽이 다시 생겨날 위험이 있습니다. 기존 애자일 팀은 협업을 유지하더라도, 새로 합류한 보안 및 운영 인력은 조직 내에서 자신의 역할을 찾지 못해 방황할 수 있습니다. 아무도 그들을 어떻게 포함해야 할지, 그들이 무엇을 해야 할지, 전체적인 목표가 무엇인지 명확히 알지 못하기 때문입니다.

DevOps는 명확하게 정의된 목표, 교차 기능 온보딩, 그리고 모든 당사자와의 직접적인 소통 없이는 작동하지 않습니다. 물론 신중한 변화 관리가 필요한 적응 기간이 있겠지만, DevOps 기능이 가져올 개선 사항에 대해 모두가 같은 방향을 바라보게 하는 것만으로도 절반은 성공한 셈입니다.

다행스럽게도 DevOps는 프로세스의 일부로서 보안 모범 사례를 강조하고 있으며, 이를 통해 보안 단계를 이해하기 쉽게 만들고 보안 팀과 다른 모든 부서 간의 간극을 좁히고 있습니다. 앞서 언급했듯이 개발자가 처음부터 안전하게 코딩할 수 있도록 역량을 강화하기까지는 아직 갈 길이 멀지만, DevOps 방법론의 성공적인 도입은 개발 팀 내에 보안 역량을 구축할 수 있는 훌륭한 토대가 됩니다.

자동화가 전부는 아닙니다(그리고 가장 안전한 것도 아닙니다).

DevOps 방법론의 또 다른 특징은 어느 정도 소프트웨어 개발 프로세스를 자동화한다는 점입니다. 지속적 통합 및 지속적 배포(CI/CD) 원칙은 이 개념의 초석이며, 짐작하시겠지만 도구에 매우 의존적입니다.

도구는 정말 훌륭합니다. 코드 저장소 관리, 테스트, 유지보수, 저장 요소 등을 비교적 매끄럽게 처리하여 소프트웨어 배포 프로세스에 전례 없는 속도를 가져다줍니다.

하지만 로봇이 언젠가 우리의 일자리를 모두 빼앗고 우리를 가둘지 몰라도, 아직 그 단계에 도달한 것은 아닙니다. 도구와 자동화에 과도하게 의존하면 오류가 발생할 여지가 크게 열립니다. 스캔과 테스트가 모든 것을 잡아내지는 못하며, 코드가 검토되지 않은 채 넘어갈 수 있고, 이는 향후 엄청난 품질(보안은 말할 것도 없고) 문제를 야기합니다. 공격자는 데이터를 훔치기 위해 단 하나의 뒷문만 이용하면 되므로, 품질 및 보안 관리에서 인간의 요소를 배제하는 것은 재앙적인 결과를 초래할 수 있습니다.

가장 좋은 방법은 사람 과 도구의 균형을 맞추는 것입니다. 도구는 프로젝트 목표를 달성하기 위해 신뢰할 수 있는 팀의 보조 수단으로 활용되어야 합니다. 다음 사항을 실천하십시오:

• 팀원들이 선택한 DevOps 툴체인에 익숙해질 수 있도록 충분한 시간을 할애하십시오.
• 효과적인 협업(그리고 도구가 이를 어떻게 지원할 수 있는지)에 집중하십시오.
• 기술/지식 부족이나 도구 기반의 문제 등 프로세스상의 모든 격차를 해결하십시오.

요컨대, 단순히 도구만 갖추고 잘되기를 바라는 식은 곤란합니다.

DevOps는 유행어가 아니라 하나의 문화입니다. 여러분의 조직은 이 문화를 잘 키워가고 있나요?

변화 관리는 언제나 어려운 법입니다. 미지의 것에 대한 두려움은 가장 뛰어난 팀원조차 자신의 역량을 키우고 시야를 넓히는 것을 가로막을 수 있습니다.

단순히 "DevOps를 도입하자"라고 말하며 운영 팀의 자리만 옮긴다고 해서 성공적인 프로세스가 마법처럼 구현되지는 않습니다. 많은 이들이 혼란을 겪을 것이고, 오랫동안 함께해 온 팀원들은 불만을 느끼게 될 것입니다. 기대치를 명확히 소통하는 것만큼이나 직접 행동으로 보여주는 것이 중요합니다. DevOps는 개발 방법론인 동시에 하나의 문화적 움직임이므로, 팀 전체가 부서 간 경계를 허물고 협력하는 사고방식을 내재화해야 합니다.

훌륭한 DevOps 문화란 어떤 모습일까요?

• 리더뿐만 아니라 구성원 개개인이 자신의 전문성을 프로세스에 발휘할 수 있는 권한을 가집니다
• 팀 간의 개방적이고 솔직하며 존중하는 소통
• 모든 구성원이 개발 프로세스에 품질과 보안을 내재화한다는 공동의 목표에 책임을 집니다
• 비즈니스 내 DevOps의 정의, 로드맵, 그리고 각자의 역할에 대한 이유와 방식에 대해 모두가 같은 이해를 공유합니다.

저는 수년간 개발 팀 내에서 긍정적인 보안 문화를 구축하는 것의 중요성을 강조해 왔으며, DevOps도 이와 다르지 않습니다.

보안 모범 사례를 달성하고, 발견되는 취약점을 줄이며, 데이터 보호의 중요성을 팀 전체가 인식하게 하려면 올바른 도구와 지식, 그리고 지원이 필수적입니다. DevOps를 도입할 때는 긍정적인 변화를 위한 문화적 토대를 마련해야 합니다. 모든 구성원이 자신의 역할과 가치, 기대치, 그리고 전체 프로젝트 목표와 프로세스 단계를 명확히 이해하도록 하십시오.

준비가 되셨나요? 좋습니다. 이제 한 단계 더 나아가 보안 측면을 강화하고, DevSecOps를 소프트웨어 우수성을 위한 궁극적인 전략으로 삼아보세요.