해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 2 - The Digital Factory
1. 혼란의 벽
'혼란의 벽'이 존재하는 회사들의 워크플로우
-> 고객과 비즈니스 부서가 아이디어를 가지고, 계획들을 문서와 지라 (Jira) 티켓으로 만들어, '혼란의 벽' 너머로 개발팀에 던짐
-> 개발 팀은 지라 티켓들을 보고 구현을 하고, 또 다시 '혼란의 벽' 너머로 테스팅팀에 던짐
-> 테스팅팀은 명세서와 개발된 내용을 보고, 테스트를 한 후, 운영팀에 던짐.
-> 운영팀은 어떻게 해서든 작동하게 만들어서 고객과 비즈니스 부서로 돌려보냄.
-> 고객과 비즈니스는 원하던 구현이 아니었다고 말함.
해당 그림에서 파란색으로 보이는 것은 '가치 흐름 (Value Stream)'으로, 최초 요청부터 고객이 가치를 실현하는 순간까지 고객에게 가치를 더하기 위해 발생하는 일련의 활동이다.
하지만, 이 가치 흐름은 '혼란의 벽'에 의해 끊겨 있다.
이 벽들은 사일로(silo) 조직 (소통이 안되는 조직) 에 의해 비롯된다.
비즈니스, 개발, 테스팅, 운영 사일로 조직들이 각기 다른 목표를 가지고 서로 정렬되지 않은 채 일을 진행한다.
따라서, 해당 프로세스는 매우 느리고 비효율적이며, 보안과 품질성이 매우 떨어지는 결과를 초래한다.
2. '혼란의 벽'의 근원과 변화
과거에는 Software를 '폭포수 (Waterfall) 프로젝트'로 개발하였다.
즉, 계획, 설계, 개발, 배포, 검토, 테스트, 출시를 큰 덩어리로 진행하였고, 범위와 예산 및 시간이 고정된 전통적인 모델이었다.
그러다 2000년경 WaterFall Project 방식은 소프트웨어 개발 방식에 맞지 않다 주장하여 '시간과 예산은 고정하고, 범위는 가변적인 애자일 (Agile) 방식'으로 더 작은 increment 단위로 결과물을 전달하게 되었으며, 해당 방식이 오늘날 우리가 프로젝트를 수행하는 방식이다.
3. DevOps란
앞서 말한 소프트웨어 개발 방식인 Agile 방식보다 더 중요하게 고려해야하는 사항은 '프로덕트 (Product)'이다.
프로젝트는 항상 '산출물 (Output)'에 초점을 맞춰 정해진 시간과 돈으로 기능을 만드는 반면, 프로덕트는 '성과 (Outcome)'에 초점을 맞춰 고객의 니즈를 이해하고, 그 니즈를 해결하거나 고객의 행동을 바꾸고자 한다.
이러한 '프로덕트 사고방식'으로 나아가는 데에 도움이 되는것이 바로 '데브옵스 (DevOps)'이다.
데브옵스는 자신을 조직하고 지속적으로 가치를 전달할 수 있게 해주는 마음가짐, 문화, 기술이기 때문에 프로덕트를 개발하고자 할 때 매우 좋은 방법론이다.
해당 강의에서는 DevOps의 중요성의 예시로 테슬라를 예시로 들었다.
-
일론 머스크가 자율주행 소프트웨어 모듈 10.2가 완벽한 안전점수 (100/100)을 가진 1000명의 소유주에게 배포될것이라고 트윗을 올림. -> 테슬라는 자차들을 모니터링하고 있으며, 1000명의 소유주를 타겟팅할 수 있는 'Canary Release'를 할 수 있다는 것을 의미
-
배포후, 10.3 버전에 문제가 생겨 10.2 버전으로 롤백해야한다고 트윗을 올림. -> 도로 위에서 달리고 있는 테슬라 차량에 대해 무선 업데이트를 통해 이전 버전으로 롤백을 함.
해당 예시를 통해 테슬라가 현재 데브옵스 분야에서 얼마나 앞서나가고 있는지 확인할 수 있었다.
그렇다면 DevOps의 이점은 무엇일까?
매년 발표되는 '데브옵스 현황 보고서'가 있는데 해당 보고서는 항상 성과가 낮은 조직과 성과가 높은 조직을 비교한다.
해당 보고서에서는 성과가 높은 조직은 배포 빈도 (Deployment Frequency), 리드 타임 (Lead Time), 복구 시간 (Time to Recovery), 변경 실패율 (Change Failure Rate) 측면에서 엄청난 차이가 있음을 알 수 있다.
즉, DevOps는
- 더 빠른 시장 출시 시간 (Faster Time to Market)
- 더 높은 가성비 (More Value for Money)
- 더 높은 품질 (Higher Quality)
- 더 높은 고객 만족도 (Higher Customer Satisfaction)
- 최고의 인재들 (Top Qualified Employees)
의 이점을 가진다.
이러한 이점들만 들었을때는 모든 회사들이 당연히 적용해야되는 기술이라고 생각할 것이다.
그렇다면 왜 모두가 DevOps를 하지는 않는걸까?
DevOps에는 몇 가지 도전과제가 따르기 때문이다.
현대적인 소프트웨어 개발을 하고 훌륭한 프로덕트를 만들기 위해 적용해야 할 기술들이 꽤 많다.
해당 그림이 DevOps를 적용하기 위하여 사용해야되는 도구들인데,
- 인프라 (클라우드 or On-Premise)
- 런타임 (Docker, Kubernetes 등)
- CI/CD Pipeline (GitLab, CircleCl, GitHub 등)
- 모니터링 (Prometheus, Dynatrace, Datadog 등)
- 보안 (Synk, SonarQube 등)
- Jira, Confluence와 같은 지원 도구
- 어플리케이션 개발은 기본..
즉, 운영하기 위하여 이러한 기술들을 모두 적용하고 운영해야하며, 인지 부하 (Cognitive Load)가 매우 높다는 것을 알 수 있다.
4. DevOps의 도전 과제 해결: 디지털 팩토리
앞서 언급된 것처럼, DevOps를 도입하려는 팀은 수많은 기술과 도구를 직접 구축하고 운영해야 하는 '높은 인지 부하(Cognitive Load)' 문제에 직면한다. 모든 팀이 인프라, CI/CD, 모니터링, 보안 등을 처음부터 재발명한다면 비일관성과 중복성이 발생하여 확장하기 어렵기때문이다.
이 문제를 해결하기 위한 접근법이 바로 '디지털 팩토리(Digital Factory)' 와 그 기반이 되는 '플랫폼 엔지니어링(Platform Engineering)'이다.
1. 플랫폼 엔지니어링
플랫폼 엔지니어링의 핵심은 개발팀(프로덕트 팀)의 인지 부하를 줄여주는 것이다. 이를 위해 '플랫폼 팀'은 CI/CD 파이프라인, 모니터링, 보안 도구, 런타임 환경 등을 표준화하여 내부 개발자를 위한 '제품(Product)'처럼 제공한다.
2. 디지털 팩토리: 전체론적 접근 방식
디지털 팩토리는 플랫폼 엔지니어링을 기반으로, 조직 전체가 하나의 목표를 향해 움직이는 종합적인 시스템이다.
-
플랫폼 (Platform): DevOps를 가능하게 하는 기술적 기반
-
아키텍처 (Architecture): 팀들이 독립적으로 빠르게 개발할 수 있도록 하는 모듈식의 느슨하게 결합된(Loosely Coupled) 아키텍처.
-
데이터 (Data): 제품의 성과를 측정하고, 데이터를 기반으로 비즈니스 의사결정을 내릴 수 있는 피드백 루프.
-
고객 경험 (Customer Experience): 모든 활동의 중심에 고객을 두고, 최고의 경험을 제공하려는 노력.
-
애자일 프로그램 딜리버리 (Agile Program Delivery): 여러 팀 간의 의존성을 관리하고, 전체적인 흐름을 조율하는 역할.
-
프로덕트 관리 (Product Management): 회사의 비전과 전략을 실제 개발팀의 실행과 연결하는 역할.
이 모든 요소가 유기적으로 결합될 때, 회사는 비로소 소프트웨어 개발을 산업화하여 예측 가능하고, 빠르며, 지속적으로 고객에게 가치를 전달할 수 있게 된다.
5. 결론
'혼란의 벽'과 '사일로 조직'은 전통적인 소프트웨어 개발 방식의 문제점이다.
DevOps는 이러한 문제를 해결하고, '프로덕트' 중심의 사고방식을 통해 지속적으로 가치를 전달하는 문화이자 기술이다.
하지만 DevOps를 모든 팀이 개별적으로 도입하면 '높은 인지 부하'라는 확장성 문제가 발생한다.
이를 해결하기 위해 '플랫폼 엔지니어링'을 통해 개발팀의 부담을 줄여주고, 더 나아가 '디지털 팩토리'라는 전체론적 접근 방식을 통해 회사의 전략과 실행을 연결하여 소프트웨어 개발을 산업화해야 한다.
