해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 58 - The Reverse Technology Thrust
1. 기술 투자가 실패하는 이유
조직이 기술에만 집중하고 프로세스를 간과할 때, 프로젝트는 비즈니스 가치를 창출하지 못하고 소멸하는 죽음의 가치(Value of Death) 구간에 빠지게 된다.
-
플랫폼과 앱의 간극:
-
인프라와 플랫폼 구축에만 너무 많은 시간을 쏟으면, 실제 애플리케이션이 올라가기까지 긴 공백이 생긴다.
-
비즈니스 가치는 앱이 구동될 때 발생하는데, 이 시점이 늦어질수록 경영진은 프로젝트의 효용성을 의심하게 된다.
-
-
운영 팀과의 단절:
- 플랫폼 구축이 끝난 뒤에야 운영 팀 교육을 시작하면, 운영 팀은 준비 부족과 리스크를 이유로 도입을 거부하거나 방대한 수정 사항을 요구한다.
-
팀 해체의 문제:
- 프로젝트 기반 팀은 구축 후 바로 해체되는 경우가 많아, 남겨진 운영 팀이 기술적 부채를 떠안게 된다.
2. 성공적인 데브옵스 채택을 위한 방법
기술은 전체의 일부일 뿐이며, 진정한 변화를 위해서는 다음과 같은 요소가 반드시 수반되어야 한다고 한다.
-
문화(사람): 과거의 방식을 고집하지 않고 변화를 수용하는 문화적 토양이 필요하다.
-
프로세스: 비즈니스 가치를 극대화할 수 있도록 일하는 순서와 방식을 개선해야 한다.
-
기술: 앞선 두 요소가 갖춰졌을 때 비로소 도구가 시너지를 발휘한다.
실천 전략1. 비즈니스 가치 중심의 MVP 구축
완벽한 플랫폼을 먼저 만들려 하지 말고, 조직에 중요한 핵심 애플리케이션을 선정하여 이를 구동할 수 있는 최소한의 환경(MVP)부터 구축해야 한다.
이를 통해 긴박함을 조성하고 빠르게 성공 사례를 증명할 수 있다.
실천 전략2. 팀 구조의 재편 (Cross-functional Team)
네트워크, 보안, 스토리지 등 도메인별로 나뉘어 소통이 단절된 사일로(Silo) 구조를 깨야 한다.
-
교차 기능 팀:
-
다양한 분야의 지식을 가진 전문가들이 모여 하나의 Product을 책임진다.
-
"나는 내 분야가 아니니 모른다"는 식의 태도를 지양하고 공동의 목표를 향해 협업한다.
-
-
제품 중심 사고:
- 프로젝트가 끝나면 해체되는 팀이 아니라, 애플리케이션과 플랫폼의 생애주기 전체를 책임지는 지속적인 팀 구조를 유지한다.
- 프로젝트가 끝나면 해체되는 팀이 아니라, 애플리케이션과 플랫폼의 생애주기 전체를 책임지는 지속적인 팀 구조를 유지한다.
실천 전략3. 지속적 학습과 반복(Iteration)
방대한 양의 지식을 한꺼번에 배우려 하면 인지적 과부하가 온다.
정의, 구축, 배포, 유지보수를 짧은 주기로 반복하며 매 단계마다 비즈니스 가치를 측정하고 피드백을 반영하는 방식이 리스크를 최소화한다.
3. 결론
데브옵스의 진정한 목표는 최신 기술의 도입이 아니라 시장 출시 속도 단축, 비용 효율화, 운영 부담 감소라는 비즈니스 성과를 내는 것이다.
이를 위해서는 기술 적용을 우선하는 것이 아니라, 우리 조직이 일하는 방식을 어떻게 '재배치'할 것인지 고민하는 것이 우선이다.
