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

이 글은 원래 DevOps.com에 게재되었습니다. 이후 업데이트 및 수정이 이루어졌습니다.

"블록체인", "빅데이터", "디지털 혁신"과 마찬가지로 "DevOps"라는 용어는 현재 대기업 IT 부서에서 사용되는 또 다른 유행어이다.

많은 이들이 (올바르게) 소프트웨어 개발 라이프사이클 가속화의 필요성을 인식했습니다. 이는 비즈니스 목표와 긴밀히 연계된 보다 정밀한 프로세스로, 개발 및 운영 팀 간의 명확한 워크플로우와 협업을 가능하게 합니다. DevOps는 본질적으로 '애자일' 개발 방식의 진화형으로, 현대 기업의 끊임없는 혁신과 신속한 배포 요구에 대응할 수 있도록 설계되었습니다. 보안 전문가에게 이는 환상적인 이니셔티브입니다: 보안 프로세스를 훨씬 더 일찍 통합할 수 있어 버그 수정 비용을 절감하고 진행 과정에서 발생할 수 있는 잠재적 재앙을 방지할 수 있습니다.

문제는 실제로 DevOps를 성공적으로 구현하는 기업이 거의 없다는 점입니다. 기업 내부에서 적절한 지원, 장려 및 이해가 없다면, 이는 금세 무용지물이 될 수 있습니다... 아시다시피, '전쟁 이야기는 꺼내지 말라'는 그런 프로젝트 중 하나가 되어버리죠.

그렇다면 문제는 무엇일까요? 이는 흥미로운 논의이며, DevOps를 접근하는 여러 방법이 존재합니다. 제 생각에는 이러한 방법들이 탐색을 용이하게 할 것입니다. 효과적인 프로그램은 단순히 몇 가지 새로운 도구, 직함, 정교한 팀 회의로 끝나는 것이 아닙니다. 항상 쉽지만은 않을 테지만, 실패한 전략을 수정하는 데(또는 처음부터 올바른 방식으로 실행하는 데) 시간을 투자하는 것이 장기적으로 훨씬 덜 고통스러울 것입니다. 결국 이는 더 우수하고 안전한 소프트웨어로 이어질 것입니다.

분해해 보자:

애자일(Agile)이라는 앞치마의 끈을 놓아라.

조직이 애자일(Agile)과 데브옵스(DevOps) 중 하나를 선택해야 하며, 한 번 선택하면 되돌아갈 수 없다는 오해가 존재합니다.

사실은 두 가지를 하나로 통합하여 고려하고 구현할 때 개발 프로세스가 가장 효과적으로 작동한다는 점입니다. 데브옵스는 애자일 개발을 재창조하는 것이 아니라 오히려 그 확장에 가깝습니다. 프로세스가 애자일과 완전히 동일하거나 완전히 다를 것을 기대할 때 문제가 발생하기 마련입니다.

애자일은 설계자, 테스터, 개발자를 초기 단계부터 한데 모아 프로젝트 전반에 걸쳐 소통 채널을 개방하는 것을 원칙으로 삼는 크로스 기능 팀을 지지합니다. 이는 분할된 납품을 종식시키고 이중 관리를 줄이는 데 목적을 두는데, 이는 DevOps 프로세스의 두 가지 장점입니다. 그러나 DevOps는 시스템, 보안, 운영을 통합하여 더욱 포괄적인 접근을 취합니다. 이를 통해 견고한 종단간 역량을 구축하고, 궁극적으로 고객에게 완성도 높고 기능적인 소프트웨어를 제공하는 것을 목표로 합니다.

DevOps 중심 프로세스로의 전환 과정에서 불가피하게 발생하는 어려움 속에서, 개발이 분절화될 위험이 재차 나타날 수 있습니다. 기존 애자일 팀은 함께 작업하는 경우가 많지만, 보안 및 운영과 관련된 추가 요소들은 여전히 조직 내 자리를 찾지 못한 채 방치되는 경우가 많습니다. 누구도 이들을 어떻게 포함시켜야 하는지, 그들이 무엇을 해야 하는지, 그리고 그들의 전반적인 목표가 무엇인지 정확히 알지 못합니다.

DevOps는 명확히 정의된 목표, 기능 간 통합, 그리고 모든 관계자와의 직접적인 소통 없이는 작동하지 않습니다. 물론 변화 관리를 세심하게 수행해야 하는 적응 기간이 필요하겠지만, DevOps 기능이 가져다주는 개선을 통해 모든 구성원을 동일한 목표 아래 하나로 모으는 것이 성공의 절반을 차지합니다.

점점 더(다행히도) DevOps는 프로세스 내에서 보안 모범 사례에도 중점을 두어 이 단계를 단순화하고 보안 팀과 다른 팀 간의 격차를 해소하고 있습니다. 앞서 언급했듯이 개발자가 처음부터 안전하게 코딩할 수 있도록 하려면 아직 갈 길이 멀지만, DevOps 방법론의 성공적인 구현은 개발 팀 내에서 보안 역량을 강화할 수 있는 훌륭한 기반을 제공합니다.

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

DevOps 방법론의 또 다른 특징은 어느 정도 소프트웨어 개발 프로세스의 자동화입니다. 지속적 통합(CI)과 지속적 배포(CD) 원칙은 이 개념의 핵심이며, 예상하셨겠지만 도구들에 크게 의존합니다.

도구는 정말 대단합니다. 코드 저장소, 테스트, 유지보수 및 저장소 요소를 비교적 유연하게 관리함으로써 소프트웨어 전달 프로세스에 전례 없는 속도를 제공할 수 있습니다.

그러나 로봇이 언젠가 우리의 모든 일자리를 빼앗고 우리를 가둘 수 있을지라도, 아직 그 단계에는 분명히 이르지 못했습니다. 도구와 자동화에 대한 강한 의존은 오류의 가능성을 열어둡니다. 스캔과 테스트가 모든 것을 탐지하지 못할 수 있으며, 코드가 검증되지 않을 수 있어 결국 품질(보안은 말할 것도 없이)에 심각한 문제가 발생합니다. 공격자는 데이터를 훔치기 위해 단 하나의 백도어만 악용하면 되며, 품질 및 보안 관리에서 인간 요소를 포기하는 것은 재앙적인 결과를 초래할 수 있습니다.

"적정 수준"이란 사람과 도구 사이의 균형을 유지하는 것을 의미합니다. 도구는 프로젝트 목표 달성을 위해 신뢰하는 팀의 보조 수단으로 활용되어야 합니다. 다음을 수행해야 합니다:

• 사용자가 선택한 DevOps 도구 체인에 익숙해질 수 있도록 충분한 시간을 확보하십시오.
• 효과적인 협업에 집중하세요(그리고 도구가 어떻게 기여할 수 있는지)
• 프로세스의 모든 공백을 메우십시오. 기술, 지식 또는 도구와 관련된 모든 공백을 포함합니다.

요컨대, 단순히 '도구를 갖추고' 모든 것이 잘 되기를 바라는 데 그치지 마십시오.

DevOps는 유행어가 아니라 문화입니다. 여러분은 자신만의 문화를 가꾸고 계신가요?

변화 관리는 최상의 상황에서도 어렵습니다. 미지의 것에 대한 두려움은 팀의 가장 뛰어난 구성원들조차 역량을 개발하고 시야를 넓히는 것을 방해할 수 있습니다.

보시다시피, 단순히 "데브옵스를 하자"고 선언하고 운영 팀의 사무실을 옮기는 것만으로는 마법처럼 성공적인 프로세스를 구현할 수 없습니다. 많은 이들이 혼란스러워하고 기존 팀원들은 불만을 품을 것입니다. 기대치를 명확히 전달하는 것만큼이나 '행동으로 보여주는 것'이 중요합니다. DevOps는 개발 방법론인 동시에 문화적 움직임이며, 팀은 기능 간 협업과 협력의 정신을 체화하고 실천해야 합니다.

좋은 DevOps 문화는 어떤 모습인가요?

• 개인은 의사 결정 과정에 전문성을 기여할 권한이 있으며, 이는 지도층에게만 해당되는 것이 아니다.
• 팀 간의 개방적이고 정직하며 존중하는 의사소통
• 모든 구성원은 개발 과정에 품질과 안전을 통합하는 전반적인 목표에 대한 책임을 집니다.
• 모든 구성원이 기업 내 DevOps 정의, 로드맵, 그리고 각자의 역할에 대한 어떻게/무엇/왜에 대해 동일한 이해를 공유하고 있습니다.

개발 팀 내에서 긍정적인 안전 문화를 조성하는 것의 중요성을 수년간 강조해 왔으며, DevOps도 예외는 아닙니다.

적절한 도구, 지식 및 지원은 보안 모범 사례를 적용하고 발견된 취약점을 줄이며 팀이 데이터 보호의 중요성을 이해하도록 하는 데 필수적입니다. DevOps를 통해 긍정적인 변화를 위한 문화적 기반을 마련해야 합니다: 각 구성원이 자신의 역할, 가치, 기대치, 프로젝트의 전반적인 목표 및 프로세스 단계를 이해하도록 해야 합니다.

이해하셨나요? 훌륭합니다. 이제 변화를 주도하고 보안 측면을 강화하며 DevSecOps를 소프트웨어 우수성의 궁극적인 계획으로 만들어 봅시다.