왜 DevOps 구현은 종종 실패하는가(그리고 이를 해결하는 방법)

본문은 처음에 Devops.com에 게재되었습니다. 이후 업데이트 및 수정이 이루어졌습니다.

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

많은 사람들이 이미 (올바르게) 더 빠른 소프트웨어 개발 라이프사이클의 필요성을 인식하고 있습니다. 이는 비즈니스 목표와 긴밀히 연계된 더 정밀한 프로세스로, 개발 팀과 운영 팀 간의 명확한 워크플로와 협업을 가능하게 합니다. DevOps는 본질적으로 "애자일" 개발로, 모든 개발자가 현대 비즈니스의 지속적인 혁신과 신속한 배포 요구에 대응할 준비가 되어 성장합니다. 보안 전문가에게 이는 놀라운 진전입니다: 프로세스 초기에 보안을 주입함으로써 오류 수정 비용을 절감하고 잠재적 재앙을 방지할 수 있기 때문입니다.

문제는, 진정한 의미에서 DevOps를 성공적으로 구현하는 기업이 거의 없다는 점입니다. 기업 전체의 적절한 지원, 육성 및 이해가 없다면, 그것은 금방 백상아리가 되어버립니다... 아시다시피, "전쟁 이야기는 꺼내지도 말라"는 그 유명한 프로젝트들 중 하나가 되어버리는 거죠.

그렇다면 문제는 무엇일까요? 이는 흥미로운 논의입니다. 저는 DevOps를 구현하는 여러 방법이 있으며, 이를 통해 항해가 훨씬 수월해질 것이라고 믿습니다. 효과적인 계획은 단순히 화려한 새 도구, 직함, 팀 회의가 아닙니다. 항상 쉬운 일은 아니지만, 장기적으로 보면 실패한 전략을 수정하는 데(또는 처음부터 올바른 방식으로 구현하는 데) 드는 고통은 훨씬 적습니다. 결국 이는 더 높은 품질과 더 안전한 소프트웨어로 이어질 것입니다.

자세히 살펴보자:

"민첩성"의 앞치마 끈을 풀어라.

조직이 애자일과 DevOps 중 하나를 선택해야 하며, 한 길을 정해놓고 절대 되돌아보지 말아야 한다는 오해가 있습니다.

문제는 개발 프로세스가 가장 효과적으로 작동할 때는 이 두 가지를 하나의 통합된 체계로 고려하고 구현할 때라는 점입니다. DevOps는 애자일 개발을 재구성한 것이 아닙니다. 오히려 애자일 개발의 확장입니다. 사람들이 이 프로세스가 완전히 애자일처럼 변하거나 애자일과 완전히 다른 방향으로 변할 것이라고 기대할 때, 종종 문제가 발생합니다.

민첩성은 크로스 기능 팀의 원칙을 지지하며, 초기 단계부터 디자이너, 테스터, 개발자를 한데 모아 프로젝트 전반에 걸쳐 열린 소통 채널을 유지할 것을 약속합니다. 그 목표는 고립된 전달을 중단하고 이중 작업을 줄이는 것이며, 이는 DevOps 프로세스의 이점이기도 합니다. 그러나 DevOps는 한 걸음 더 나아가 시스템, 보안, 운영을 통합하여 강력한 종단 간 기술 조합을 제공하며, 궁극적인 목표는 고객에게 완벽한 기능을 갖춘 소프트웨어를 전달하는 것입니다.

더욱 DevOps 중심의 프로세스로 전환하는 과정에서 피할 수 없는 어려움 중 하나로, 고립된 개발의 위험이 재차 발생할 수 있습니다. 초기 애자일 팀은 함께 작업하도록 할 수 있지만, 새로 추가된 보안 및 운영 담당자들은 여전히 컴퓨터 속에서 해결책을 찾고 있습니다. 그들을 어떻게 포함시켜야 하는지, 그들이 무엇을 해야 하는지, 그리고 그들의 전반적인 목표가 무엇인지 아무도 확신하지 못합니다.

명확한 목표, 크로스-기능적 온보딩, 그리고 모든 관계자와의 직접적인 소통 없이는 DevOps는 작동할 수 없습니다. 물론, 신중한 변경 관리가 필요한 조정 기간이 있을 것입니다. 그러나 DevOps 기능이 가져다주는 향상된 역량에 대해 모든 구성원이 공감대를 형성하는 것이 성공의 절반입니다.

(다행히도), DevOps도 점차 보안 모범 사례를 프로세스의 일부로 삼아 그 신비로운 장막을 걷어내고, 보안 팀과 다른 모든 사람들 사이의 간극을 메우는 데 중점을 두고 있습니다. 앞서 말씀드렸듯이, 개발자에게 처음부터 보안 코딩 능력을 부여하는 데는 아직 갈 길이 멀지만, DevOps 방법론의 성공적인 도입은 개발 팀 내부에서 보안 역량을 함양하는 탁월한 기반이 됩니다.

자동화가 모든 것은 아니다(또한 가장 안전한 것도 아니다).

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

도구는 훌륭합니다. 실제로 그렇습니다. 이들은 소프트웨어 배포 프로세스에 전례 없는 속도를 가져다주며, 코드 저장소, 테스트, 유지보수 및 저장 요소를 비교적 원활하게 관리합니다.

그러나 언젠가는 로봇이 우리의 모든 일자리를 빼앗고 우리를 감금할지도 모르지만, 아직까지는 그렇지 않습니다. 도구와 자동화에 대한 과도한 의존은 오류의 문을 열어둡니다. 스캔과 테스트가 모든 것을 탐지하지 못할 수 있으며, 코드가 제대로 검토되지 않을 수 있어 엄청난 품질(안전성은 말할 것도 없이) 문제를 야기할 수 있습니다. 공격자는 데이터를 훔치기 위해 단 하나의 백도어만 이용하면 되며, 품질 및 보안 관리에서 인적 요소를 포기하는 것은 재앙적인 결과를 초래할 수 있습니다.

"균형점" 은 사람과 사람 사이의 균형을 보장하는 도구입니다. 도구는 신뢰하는 팀의 조력자 역할을 하여 프로젝트 목표를 달성해야 합니다. 여러분은 다음과 같이 해야 합니다:

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

간단히 말해, 단순히 "기운 내라"고만 하지 말고 최선의 결과를 바라야 한다.

DevOps는 유행어가 아니라 하나의 문화입니다. 당신은 성장하고 있습니까?

변화 관리는 가장 좋은 상황에서도 어렵습니다. 미지의 것에 대한 두려움은 가장 뛰어난 팀원들조차 기술 향상과 시야 확장을 가로막을 수 있습니다.

보시다시피, 단순히 "데브옵스를 하자"고 말하고 운영팀이 책상만 옮긴다고 해서 마법처럼 성공적인 프로세스가 구현되지는 않습니다. 많은 이들이 혼란스러워할 것이며, 오래 근무한 팀원들은 불만을 느낄 것입니다. 기대되는 소통은 물론이고, '실천에 나서기' 역시 중요합니다. 데브옵스는 개발 방법론이자 문화적 운동으로, 팀은 기능 간 협업이라는 사고방식으로 살아 숨 쉬어야 합니다.

우수한 DevOps 문화는 어떤 모습인가?

• 개인은 리더뿐만 아니라 프로세스에 전문 지식을 제공할 권리가 있다.
• 팀 간의 개방적이고 정직하며 상호 존중하는 의사소통
• 모든 구성원은 개발 과정에 품질과 안전을 통합하는 전반적인 목표에 대해 책임을 진다.
• 기업 내 DevOps의 정의, 로드맵 및 각 구성원의 역할 수행 방식/내용/이유에 대해 모두가 의견을 같이합니다.

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

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

이해하셨나요? 훌륭합니다. 이제 초점을 전환하여 보안을 강화하고 DevSecOps를 탁월한 소프트웨어를 구현하는 궁극적인 계획으로 만들어 봅시다.