해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 41 - My journey to reimagining DevOps: Ushering in the Second Wave
1. 기술, 사람, 프로세스의 진화
해당 세션에서는 발표자가 기술리더로서 기술, 조직 (사람), 프로세스가 서로 영향을 주며 함께 진화하는 데브옵스 여정에 대하여 설명하였다.
1-1. 기술 (Technology)
처음에는 단일한 변화로 모든 것이 바뀌는 것이 아니라, 비즈니스 요구와 이해도가 발전함에 따라 점진적으로 현대적인 클라우드 아키텍처로 반복하며 나아갔다.
1-2. 사람 (People)
-
완벽하게 분리된 개발(Dev), QA, 클라우드 운영(Ops) 사일로부터 시작했다.
-
의존성을 줄이기 위해 Dev와 QA를 통합했고, 클라우드 우선 애플리케이션을 개발하며 백엔드, 프론트엔드 등 기능별 팀을 시도했으나 이는 의존성 지옥을 초래했다.
-
결국 교차 기능 팀 (Cross-functional teams)을 실험하게 되었다.
-
이후 조직 개편을 통해 데브옵스 전문 조직이 생겼고, R&D와 클라우드 운영 두 개의 전문 조직이 존재하기도 했다.
-
더 나아가 분기별로 팀원이 직접 누구와 무엇을 할지 정하는 '자기 선택(Self-selection)'을 도입했고, 이를 '적시 (Just-in-time) 계획 및 인력 배치'로 발전시켰다.
-
궁극적으로는 'You Build It, You Run It (YBIYRI)' 모델을 실험하며 팀이 기능 개발부터 테스트, 인프라 배포 및 관리, 서비스 운영까지 모든 것을 책임지게 했다.
-
YBIYRI를 수행하며 모든 팀에 알림, 모니터링, 텔레메트리 등 공통의 기본 기능이 필요함을 깨닫고 플랫폼 팀(Platform Team)을 구축했으며, 이 플랫폼을 비즈니스 가치와 ROI를 관리하는 제품으로 다루었다.
-
1-3. 프로세스 (Process)
-
연간 릴리스를 하던 전형적인 폭포수 (Waterfall) 방식에서 시작했다.
-
이후 일부 팀은 스크럼 (Scrum), 칸반 등을 사용했으며, 클라우드 애플리케이션으로 전환하며 분기별 계획 및 릴리스를 도입했다.
-
SAFe, 프로젝트 관리, 프로그램 관리 등 다양한 방식을 시도하며 Release on demand, AB 실험, '커밋 시 릴리스 (Release on commit)'까지 발전했다.
-
모든 것이 수동이었던 배포 및 운영은 점차 스크립트화되었고, 자동화된 프로비저닝과 코드형 인프라(IaC)를 거쳐 현대적인 CI/CD 파이프라인으로 발전했다.
-
특히 배포와 출시를 분리하기 위해 기능 플래그 (Feature Flags)를 도입하여, 코드는 즉시 프로덕션에 배포하되 실제 기능 출시는 제품팀이 제어할 수 있도록 했다.
-
2. 6가지 핵심 교훈
이 모든 반복과 실험의 과정에서 발표자는 기술 리더로서 다음과 같은 6가지 핵심 교훈을 얻었다고 강조한다.
-
다른 기술을 가진 1명은 교차 기능 팀이 아니다:
-
팀에 특정 기술을 가진 사람이 한 명뿐이라면, 그 사람은 코드 리뷰, 설계 리뷰 등 협업할 동료가 없어 지원을 받지 못한다.
-
이는 의도와 달리 즉시 팀 간 의존성을 증가시킨다.
-
-
기능 플래그는 만병통치약이 아니다:
- 배포와 출시를 분리하는 데는 훌륭하지만, 잘못 사용하면 위험을 줄이는 것이 아니라 오히려 증가시킬 수 있다.
-
모든 개발 단계의 의존성을 고려해야 한다:
-
코드를 병렬로 작성할 수 있다고 해서 배포나 장애 대응도 병렬로 가능한 것은 아니다.
-
특히 계획 단계 (우선순위 설정)의 의존성을 간과하기 쉽다.
-
예: 여러 제품 라인을 지원하는 데브옵스 전문 조직이 어떤 제품을 우선해야 하는지 결정할 맥락이 부족한 문제
-
-
팀의 인지 부하 (Cognitive Load)를 과소평가하지 마라:
- 'You Build It, You Run It (YBIYRI)' 모델은 팀이 알아야 할 도구, 프로세스, 정보의 양을 급격히 늘려 팀을 소진시킬 수 있다.
-
리더십 팀도 하나의 팀이다:
- 제품, UX, 엔지니어링 리더들로 구성된 핵심 그룹의 역학 관계, 소통 방식, 의사 결정 방식은 엔지니어링 팀의 성과에 막대한 영향을 미친다.
-
팀원의 '일상적인 업무 경험'에 집중하라:
-
리더는 팀원이 자신의 일을 얼마나 쉽고 즐겁게 수행하는지 세심하게 관찰해야 한다.
-
당연히 쉬워야 할 일이 어렵고 고통스럽다면 팀은 번아웃으로 직행할 것이다.
-
3. 데브옵스의 본질
발표자는 모든 변화의 궁극적인 목적은 더 나은 결과물, 더 높은 가치, 품질, 유연성, 보안, 성능, 안정성을 얻는 것이라고 말한다.
'데브옵스 핸드북'이라는 서적에서 강조하듯, 이를 위해서는 지금 우리가 하는 일이 왜 더 나은 결과로 이어지지 않는지에 대한 더 빠른 피드백이 필요하다.
중요한 것은 이 피드백이 '무엇에 대해'와 '누구로부터' 오는지 명확히 하는 것이다.
결국 데브옵스가 협업을 촉진하려던 바로 그 이해관계자 (개발, 운영, 보안 등)들로부터의 피드백이 필요하다.
하지만 오늘날 이 '협업'을 가로막는 세 가지 큰 장벽이 존재한다.
-
극심한 컨텍스트 스위칭 :
-
팀원들은 너무나 자주 다른 기술, 다른 추상화 수준, 다른 도구의 미묘한 차이를 다시 배워야 한다.
-
모든 팀이 현실을 다르게 이해하고 있어 협업이 불가능하다.
-
-
낮은 시스템 지능 :
-
시스템의 현재 상태가 리포지토리 내의 정적 구성 파일들에 흩어져 있다.
-
변경을 위해 어느 부분을 수정해야 할지 모두 기억해야 하므로 실수의 위험이 높고 자신감이 떨어진다.
-
-
핸드오프 도시 :
-
과거의 지원 티켓이 오늘날의 PR로 바뀌었을 뿐이다. 대화 대신 문서를 주고받는다.
-
정보가 도구, 코드, 리포지토리 곳곳에 숨겨져 있어 팀이 함께 모여 일할 수 있는 공유된 장소가 없다.
-
4. 미래의 데브옵스
발표자는 앞서 이야기한 이러한 문제를 해결하기 위해 우리가 상상해야 할 미래의 데브옵스 환경을 제시한다.
-
높은 시스템 지능:
- 구성 요소 간의 관계가 시스템 내에 캡처되어, 변경 시 어디를 수정해야 할지 기억할 필요가 없는 세상
-
자연스러운 컨텍스트 스위칭:
- 플로우 상태를 유지하며 생산적으로 일하고, 도구를 다시 배우느라 시간을 낭비하지 않는 세상
-
쉬운 협업:
- 시스템 구성에 대한 공유된 이해가 존재하고, 누가 무엇을 언제 작업했는지 (혹은 지금 작업 중인지) 쉽게 알 수 있는 세상
-
짧은 피드백 루프:
- 코드를 작성하거나 프로덕션에 배포하기 전, 디자인 단계에서 피드백을 받는 세상
발표자는 해당 비전이 바로 System Initiative가 해결하려는 문제라고 말한다.
System Initiative는 데브옵스 툴링을 실시간, 멀티플레이어, 멀티모달 방식으로 재창조한 데브옵스 파워 툴이다.
