왜 데브옵스 도입이 종종 실패하는가 (그리고 이를 해결하는 방법)

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

"블록체인", "빅데이터", "디지털 파괴"와 마찬가지로 "데브옵스"라는 용어는 현재 대기업 IT 부서에서 유행하는 또 다른 유행어이다.

많은 이들이 (당연히) 더 빠른 소프트웨어 개발 주기의 필요성을 인식했습니다. 이는 비즈니스 목표와 긴밀히 연계된 정밀한 프로세스로, 개발팀과 운영팀 간의 명확한 워크플로우와 협업을 가능하게 합니다. DevOps는 본질적으로 '애자일' 개발 방식의 성숙한 형태로, 현대 기업의 끊임없이 변화하고 빠르게 진화하는 요구사항을 충족할 준비가 되어 있습니다. 보안 전문가에게 이는 환상적인 이니셔티브입니다: 프로세스 초기에 보안을 통합함으로써 오류 수정 비용을 절감하고 미래의 잠재적 재앙을 예방할 수 있기 때문입니다.

문제는 DevOps 구현에 진정으로 성공하는 기업이 극소수라는 점입니다. 전사적인 차원의 적절한 지원, 유지 관리 및 이해 없이는 금세 무한정 비용이 드는 구멍이 될 수 있습니다... 아시다시피, 전쟁에 대해 언급하지 않는 그런 프로젝트들 말입니다.

또한, 문제가 무엇인가요? 이는 흥미로운 논의이며, DevOps를 접근하는 몇 가지 방법이 있는데, 제가 보기에 이 방법들은 훨씬 더 원활한 운영을 보장할 것입니다. 효과적인 프로그램은 멋진 새 도구, 직함, 팀 회의 몇 번으로 끝나는 것이 아닙니다. 항상 쉽지만은 않을 것입니다. 하지만 시간을 내어 잘못된 전략을 수정하거나(또는 처음부터 제대로 실행한다면) 장기적으로 훨씬 덜 고통스러울 것입니다. 결국 이는 더 높은 품질과 더 안전한 소프트웨어로 이어질 것입니다.

자세히 살펴보겠습니다:

"애자일" 앞치마 끈을 풀어라.

기업이 애자일과 데브옵스 중 하나를 선택해야 하며, 한쪽 길을 정해놓고 절대 되돌아보지 않아야 한다는 일종의 오해가 존재합니다.

문제는 개발 프로세스가 둘을 하나의 통합된 체계로 간주하고 실행할 때 가장 효과적으로 작동한다는 점입니다. 데브옵스는 애자일 개발을 재창조한 것이 아니라 오히려 그 확장판입니다. 프로세스가 애자일과 정확히 같거나 완전히 다를 것이라는 기대가 있을 때, 바퀴는 떨어지기 마련입니다.

애자일은 기능 간 팀 원칙을 지지하며, 초기 단계부터 디자이너, 테스터, 개발자를 한데 모아 프로젝트 전반에 걸쳐 개방적인 소통 경로를 유지합니다. 목표는 고립된 배포를 종식시키고 중복 작업을 줄이는 것입니다. 이 두 가지 모두 DevOps 프로세스의 장점이기도 합니다. 그러나 DevOps는 한 걸음 더 나아가 시스템, 보안, 운영을 통합하여 견고하고 포괄적인 전문성을 제공합니다. 궁극적인 목표는 고객에게 완전하고 작동 가능한 소프트웨어 배포를 제공하는 것입니다.

DevOps 중심 프로세스로 전환하는 과정에서 불가피한 문제들이 발생할 때, 고립된 개발의 위험이 다시 나타날 수 있습니다. 종종 초기 애자일 팀은 협업을 지속하는 동안 보안 및 운영 확장 기능들이 여전히 시스템에 통합되는 과정을 겪습니다. 누구도 이들을 어떻게 포함시켜야 하는지, 그들이 무엇을 해야 하는지, 그리고 그들이 추구하는 전반적인 목표가 무엇인지에 대해 완전히 확신하지 못합니다.

DevOps는 명확히 정의된 목표, 기능 간 온보딩, 그리고 모든 관계자와의 직접적인 소통 없이는 작동하지 않습니다. 물론 신중한 변화 관리가 필요한 적응 기간이 있을 것이지만, DevOps 기능이 가져올 개선 사항에 대해 모든 구성원을 동일한 수준으로 끌어올리는 것이 성공의 절반입니다.

점점 더 많은 (다행히도) DevOps가 프로세스의 일부로서 검증된 보안 관행을 중시하며, 이 단계를 신비화하지 않고 보안 팀과 다른 모든 팀 간의 간극을 해소하고 있습니다. 앞서 말씀드렸듯이 개발자들이 처음부터 안전하게 프로그래밍할 수 있도록 하는 데는 아직 갈 길이 멀지만, DevOps 방법론의 성공적인 도입은 개발 팀 내 보안 역량을 구축할 수 있는 탁월한 기반이 됩니다.

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

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

도구는 정말 대단합니다. 소프트웨어 배포 과정을 전례 없이 가속화할 수 있으며, 코드 저장소와 테스트, 유지보수, 저장 요소들을 비교적 손쉽게 관리할 수 있게 해줍니다.

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

"황금의 중간 지점"은 사람과 도구 사이의 균형 잡힌 관계를 유지하는 데 있습니다. 도구는 프로젝트 목표 달성을 위해 신뢰하는 팀의 조력자 역할을 해야 합니다. 도구는 다음과 같아야 합니다:

• 직원들이 선택한 DevOps 도구 체인에 익숙해질 수 있도록 충분한 시간을 확보하십시오.
• 효과적인 협업에 집중하세요(그리고 도구가 이를 어떻게 지원할 수 있는지)
• 프로세스상의 모든 공백을 메우십시오. 그 공백이 기술, 지식 또는 도구에 기반한 것인지 여부와 관계없이.

간단히 말해, 무작정 업그레이드하고 좋은 결과를 기대하지 마십시오.

DevOps는 단순한 유행어가 아닙니다. 그것은 하나의 문화입니다. 당신은 자신만의 문화를 구축하고 있습니까?

변화 관리는 최상의 경우에도 어렵습니다. 미지에 대한 두려움은 가장 뛰어난 팀원들조차 자신의 역량을 확장하고 시야를 넓히는 것을 주저하게 만듭니다.

보시다시피, 단순히 "데브옵스를 하자"고 말하고 운영팀이 책상을 옮기게 하는 것만으로는 마법처럼 성공적인 프로세스가 구현되지 않습니다. 많은 이들이 혼란스러워할 것이며, 오랜 팀원들은 불쾌감을 느낄 수 있습니다. 기대치를 명확히 전달하는 것은 '자신만의 길을 가는 것'만큼 중요합니다. DevOps는 개발 방법론인 동시에 문화적 운동이며, 팀은 기능 간 협업적 사고방식을 체화해야 합니다.

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

• 개인이 자신의 전문 지식을 프로세스에 기여할 수 있도록 권한을 부여받으며, 이는 단지 경영진뿐만이 아닙니다.
• 팀 간의 개방적이고 정직하며 존중하는 의사소통
• 모든 구성원은 개발 과정에서 건물 품질 및 안전에 대한 종합적 목표 달성의 책임을 집니다.
• 모두가 기업 내 DevOps의 정의, 로드맵, 그리고 각 개인의 역할에 대한 어떻게/무엇/왜에 대해 의견을 같이하고 있습니다.

수년간 저는 개발 팀 내에서 긍정적인 안전 문화를 구축하는 것이 얼마나 중요한지 강조해 왔으며, DevOps도 예외는 아닙니다.

올바른 도구, 올바른 지식, 그리고 올바른 지원은 검증된 보안 절차를 구현하고, 발견된 취약점의 감소를 관찰하며, 팀원들에게 우리 데이터 보호의 중요성을 깨닫게 하는 데 필수적입니다. DevOps를 도입하려면 긍정적인 변화를 위한 문화적 기반을 마련해야 합니다: 모든 구성원이 자신의 역할, 가치, 기대사항은 물론 프로젝트의 전반적 목표와 프로세스별 단계를 명확히 이해하도록 해야 합니다.

이를 성공적으로 수행하셨나요? 훌륭합니다. 이제 초점을 전환하여 보안 측면을 심층적으로 조명하고, DevSecOps를 소프트웨어 우수성을 위한 궁극적인 전략으로 발전시켜 보겠습니다.