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

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

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

많은 이들이 (올바르게) 더 빠른 소프트웨어 개발 라이프사이클의 필요성을 인식해 왔습니다. 이는 비즈니스 목표와 긴밀히 연계된 보다 정밀한 프로세스로, 개발 팀과 운영 기반 팀 간의 더 명확한 워크플로우와 협업을 가능하게 합니다. 데브옵스는 본질적으로 현대 기업의 요구를 충족하도록 발전하고 준비된 '애자일' 개발 방식입니다. 현대 기업은 끊임없이 혁신하고 신속하게 배포합니다. 보안 전문가에게 이는 탁월한 이니셔티브입니다: 프로세스 초기에 보안을 주입할 수 있어 오류 수정 비용을 절감하고 향후 발생할 수 있는 재앙을 방지할 수 있습니다.

문제는 실제로 DevOps 도입에 성공하는 기업이 거의 없다는 점입니다. 전사적인 지원과 관심, 이해가 제대로 뒷받침되지 않으면 기업은 금세 무한정 자금이 소모되는 구멍이 될 수 있습니다... 아시다시피, '전쟁 이야기는 꺼내지 말아야 할' 그런 프로젝트 중 하나가 되죠.

그렇다면 문제는 무엇일까요? 흥미로운 논쟁이며, DevOps를 접근하는 몇 가지 방법이 있다고 생각합니다. 이를 통해 훨씬 더 원활하게 진행할 수 있을 것입니다. 효과적인 프로그램은 몇 가지 새로운 정교한 도구, 직함, 팀 회의 이상의 의미를 지닙니다. 항상 쉽지만은 않을 것입니다. 하지만 제대로 작동하지 않는 전략을 수정하는 데 시간을 투자하거나(또는 처음부터 올바른 방식으로 구현하는 것) 장기적으로 훨씬 덜 고통스러울 것입니다. 그리고 궁극적으로 더 안전하고 품질이 높은 소프트웨어로 이어질 것입니다.

자세히 살펴보자:

에이프릴의 앞치마 끈을 풀어주세요.

조직이 애자일(Agile)과 데브옵스(DevOps) 중 하나를 선택해야 하며, 한 길을 정해 뒤돌아보지 않아야 한다는 다소 잘못된 생각이 존재합니다.

문제는 개발 프로세스가 둘을 하나로 간주하고 구현할 때 가장 잘 작동한다는 점입니다. DevOps는 애자일 개발을 재창조한 것이 아니라 오히려 그 연장선상에 있습니다. 프로세스가 애자일과 정확히 동일하게 진행되거나 완전히 다르게 진행되기를 기대할 때 문제가 발생하기 마련입니다.

애자일은 다기능 팀 원칙을 지지합니다. 이는 초기 단계부터 디자이너, 테스터, 개발자를 한데 모아 프로젝트 전반에 걸쳐 소통 채널을 개방하도록 약속하기 때문입니다. 이는 사일로화된 전달을 중단하고 이중 관리를 줄이는 것을 목표로 하며, 이는 DevOps 프로세스의 이점이기도 합니다. 그러나 DevOps는 한 걸음 더 나아가 시스템, 보안 및 운영을 통합하여 견고하고 포괄적인 기술 역량을 제공함으로써 궁극적으로 고객에게 완전하고 기능적인 소프트웨어를 제공하는 것을 목표로 합니다.

DevOps 중심 프로세스로 전환하는 과정에서 불가피하게 발생하는 문제점들 속에서, 고립된 개발의 위험이 다시 고개를 들 수 있습니다. 애자일 팀은 주로 협업하지만, 보안 및 운영 인력은 여전히 조직 내에서 자리를 잡아가고 있습니다. 이들을 어떻게 통합해야 하는지, 그들이 수행해야 할 역할과 전반적인 목표가 무엇인지에 대해 명확히 인지하는 사람은 거의 없습니다.

DevOps는 명확히 정의된 목표, 부서 간 협업, 그리고 모든 관계자와의 직접적인 소통 없이는 작동하지 않습니다. 변화 관리를 신중하게 수행해야 하는 적응 기간이 있을 것이 분명하지만, DevOps 기능이 가져올 개선점에 모두가 동의하도록 하는 것이 성공의 절반입니다.

점점 더 (다행히도) DevOps는 프로세스의 일환으로 보안 모범 사례에 더 중점을 두어, 그 단계를 신비화하지 않고 보안 팀과 다른 모든 팀 간의 격차를 줄이고 있습니다. 앞서 말했듯이, 개발자들이 처음부터 안전하게 코딩할 수 있도록 하려면 아직 갈 길이 멀지만, DevOps 방법론의 성공적인 구현은 개발 팀의 보안 역량을 발전시킬 수 있는 훌륭한 기반이 됩니다.

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

DevOps 방법론의 또 다른 특징은 어느 정도 소프트웨어 개발 프로세스의 자동화입니다. 지속적 통합 및 지속적 배포(CI/CD) 원칙은 이 개념의 초석이며, 상상할 수 있듯이 도구들에 크게 의존합니다.

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

그러나 로봇이 언젠가 우리의 모든 일자리를 빼앗고 우리를 감옥에 가둘 수도 있지만, 아직까지는 확실히 그렇지 않습니다. 도구와 자동화에 대한 과도한 의존은 오류 발생 가능성을 열어둡니다. 스캔과 테스트가 모든 것을 포착하지 못할 수 있고, 코드가 검증되지 않아 향후 품질(보안 문제는 말할 것도 없이)에 심각한 문제가 발생할 수 있습니다. 공격자는 데이터 탈취를 위해 단 하나의 백도어만 악용하면 됩니다. 품질 관리와 보안에서 인간 요소를 배제하는 것은 재앙적인 결과를 초래할 수 있습니다.

중요한 것은 사람과 도구 사이의 균형을 유지하는 것입니다. 도구는 프로젝트 목표를 달성하기 위해 신뢰하는 팀을 보조하는 역할을 해야 합니다. 다음을 수행해야 합니다:

• 선택한 DevOps 도구 체인에 사람들이 익숙해질 수 있도록 충분한 시간을 할당하십시오.
• 효과적인 협업에 집중하세요(그리고 도구가 이를 어떻게 지원할 수 있는지)
• 프로세스상의 모든 격차를 해결하십시오. 이는 기술/지식 기반이든 도구 기반이든 상관없습니다.

요컨대, 단순히 '준비'만 하고 좋은 결과를 기대하는 데 그치지 마라.

DevOps는 유행어가 아니라 문화입니다. 당신만의 DevOps 문화를 가꾸고 계신가요?

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

보시다시피, 단순히 "데브옵스를 하자"고 말하고 운영 팀이 책상만 옮기게 하는 것이 마법처럼 성공적인 프로세스를 구현해주지는 않습니다. 많은 이들이 혼란스러워할 것이며, 오랜 기간 근무해 온 팀원들은 불만을 느낄 것입니다. 기대치를 명확히 전달하는 것이 중요하며, '본보기를 보이는 것' 역시 필수적입니다. DevOps는 개발 방법론일 뿐만 아니라 문화적 움직임을 의미하며, 팀은 기능 간 협업과 협력적 사고방식을 체화해야 합니다.

훌륭한 DevOps 문화는 어떤 모습인가요?

• 사람들은 자신의 경험을 과정에 기여할 수 있는 힘을 지니고 있으며, 단지 지도자들에게만 국한되지 않는다.
• 팀 간의 개방적이고 정직하며 존중하는 의사소통
• 각 개인은 개발 과정에 품질과 안전을 통합하는 전반적인 목표에 대한 책임을 진다.
• 모든 구성원이 회사 내 DevOps 정의, 로드맵, 그리고 각 개인의 역할에 대한 방법, 내용, 이유에 대해 동의하고 있습니다.

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

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

숙달하셨나요? 훌륭합니다. 이제 초점을 전환하여 보안 측면을 구현하고, DevSecOps를 소프트웨어 우수성을 위한 궁극적인 계획으로 만들어 봅시다.