[DevOps] 2024 State of DevOps Report Part 2 (플랫폼엔지니어링)
State of DevOps Report는 2014년부터 시작되어 매년 발표되고 있으며, DORA(DevOps Research and Assessment) 팀이 연구를 주도하다가 이후 Google에 인수되어 현재까지 지속적으로 발표되고 있습니다. 해당 보고서에서는 배포 빈도, 변경 실패율, 복구 시간, 리드 타임 등의 핵심 지표를 기준으로 소프트웨어 개발 및 운영 성과의 DevOps 모범 사례와 생산성 향상 전략을 분석하고 있습니다.
이전 글에서는 2024년도의 State of DevOps Report 중 AI의 내용을 중점으로 한번 알아봤는데요.
이번에는 플랫폼엔지니어링의 내용을 중점으로 한번 알아보는 시간을 가져보겠습니다.
참고자료 - 2023 State of DevOps Report 소개
[DevOps] State of DevOps Report 2023 알아보기 1탄
https://every-up.tistory.com/62
[DevOps] State of DevOps Report 2023 알아보기 1탄
[DevOps] State of DevOps Report 2023 알아보기 1탄지난 10월달에 "State of DevOps Report 2023" 이 나왔습니다!State of DevOps Report란 Google에서 DevOps를 연구하는 DORA라는 팀에서 발표하는 자료인데요.State of DevOps Repor
every-up.tistory.com
[DevOps] State of DevOps Report 2023 알아보기 2탄
https://every-up.tistory.com/63
[DevOps] 2023 State of DevOps Report 알아보기 2탄
[DevOps] 2023 State of DevOps Report 알아보기 2탄지난번에는 State of DevOps Report 2023의 주요 결과에 대한 내용을 알아보는 시간을 가졌는데요.이번에는 더 자세하게 알아보기 위해 주요 내용 중 사용자 중
every-up.tistory.com
[DevOps] State of DevOps Report 2023 알아보기 3탄
https://every-up.tistory.com/64
[DevOps] 2023 State of DevOps Report 알아보기 3탄
[DevOps] 2023 State of DevOps Report 알아보기 3탄지난번 2탄에 이어서 3탄에도 State of DevOps Report 2023의 주요 내용을 상세하게 알아보는 시간을 가져보겠습니다.이번에는 인프라스트럭처와 문화에 대한
every-up.tistory.com
플랫폼엔지니어링의 영향
2024 State of DevOps Report 내용 중 플랫폼엔지니어링의 내용을 중점으로 알아보겠습니다.
Report 내용은 한글로 번역 후 정리해봤으며, 번역 내용에 따라 원문과 의미가 조금 다를 수 있음을 사전에 알려드립니다.
개념
플랫폼 엔지니어링은 업계 전반에 걸쳐 관심과 추진력을 얻고 있는 새로운 엔지니어링 분야입니다.
엔지니어가 다양한 팀 간의 사회적 상호작용과 자동화, 셀프서비스, 프로세스 반복성의 기술적 측면의 교차점에 집중하는 사회기술 분야입니다.
플랫폼 엔지니어링에서는 골든 패스를 구축하여 개발자 경험을 개선하는 데 많은 에너지와 집중을 쏟습니다.
골든 패스는 플랫폼 사용자가 애플리케이션을 제공하고 운영하는 데 필요한 리소스와 상호 작용할 때 사용하는 고도로 자동화된 셀프 서비스 워크플로입니다. 골든 패스의 목적은 개발자가 코드에만 신경 쓰면 되도록 소프트웨어 빌드 및 제공의 복잡성을 추상화하는 것입니다. 골든 패스를 통해 자동화된 작업의 몇 가지 예로는 새로운 애플리케이션 프로비저닝, 데이터베이스 프로비저닝, 스키마 관리, 테스트 실행, 빌드 및 배포 인프라 프로비저닝, DNS 관리 등이 있습니다.
소프트웨어 개발 및 운영 성과
플랫폼 엔지니어링이 성공하려면 사용자 중심(user-centeredness)으로 접근하는 것이 성공의 핵심 요소 중 하나입니다.
여기서 사용자는 내부 개발자 플랫폼을 사용하는 개발자들을 의미합니다. 또한, 개발자의 독립성을 보장하고 제품 중심의 사고방식을 갖는 것이 필요합니다.
플랫폼이 소프트웨어 개발 및 운영 성과에 미치는 영향의 분석 결과입니다.
내부 개발자 플랫폼 사용자는 생산성이 8% 더 높았으며, 팀 성과도 10% 더 향상되었습니다. 플랫폼을 도입한 조직에서는 소프트웨어 배포 및 운영 성과가 6% 향상되었습니다. 이러한 이점과 함께 단점도 발견되었습니다. 처리량(Throughput)이 8% 감소되었으며, 변경 안정성(Change Stability)이 14% 감소되는 단점도 발견되었습니다.
플랫폼 사용 여부에 따른 생산성
플랫폼 사용 여부에 따른 생산성 분석 내용입니다.
플랫폼 미사용 시 생산성 점수가 약 6.5~8.0 범위에 분포되어 있으며, 개별 점수의 변동성이 큽니다.
플랫폼 사용 시 생산성 점수가 7.5~8.0 범위에 집중되어 있으며, 변동성이 적고, 점들이 더 조밀하게 모여 있습니다. 내부 개발자 플랫폼을 사용할 경우 평균적으로 약 8% 향상된 생산성을 보이며, 플랫폼 사용이 개발자의 생산성 일관성을 높이는 효과가 있음을 시사하고 있습니다.
플랫폼 사용 기간에 따른 조직 성과
플랫폼 사용 기간(연령)에 따른 조직 성과 분석 내용입니다.
생산성과 함께 플랫폼의 사용 기간(연령)을 고려할 때, 플랫폼 엔지니어링 이니셔티브가 시작될 때 초기 성능 향상이 나타나고, 플랫폼이 오래되고 성숙해짐에 따라 감소 및 회복이 뒤따릅니다. 이 패턴은 초기 상을 경험하지만 실현된 후에는 어려움에 직면하는 변환 이니셔티브의 전형입니다. 장기적으로 생산성 향상이 유지되면서 소프트웨어 제공 및 운영 프로세스에서 내부 개발자 플랫폼의 역할이 전반적으로 잠재력이 있음을 보여줍니다.
주요 결과
개발자 독립성의 영향
개발자 독립성은 내부 개발자 플랫폼을 사용하여 소프트웨어를 제공할 때 개인 및 팀 수준 모두에서 생산성 수준에 상당한 영향을 미쳤습니다. 개발자 독립성은 "개발자가 지원 팀에 의존하지 않고 전체 애플리케이션 라이프사이클 동안 작업을 수행할 수 있는 능력"으로 정의됩니다. 팀과 개인 수준에서 플랫폼 사용자가 지원 팀을 참여시키지 않고도 작업을 완료할 수 있을 때 생산성이 5% 향상되는 것을 확인했습니다.
전담 플랫폼 팀의 영향
흥미롭게도, 전담 플랫폼 팀을 두는 것의 생산성에 대한 영향은 개인에게는 미미했습니다.
그러나 팀 수준에서는 생산성이 6% 증가했습니다.
이 발견은 전담 플랫폼팀을 갖는 것이 개인에게는 유용하지만 전담 플랫폼팀은 전체 팀에 더 큰 영향을 미친다는 것을 시사합니다. 팀은 서로 다른 책임과 기술을 가진 여러 개발자를 두고 있기 때문에 자연스럽게 개별 엔지니어에 비해 더 다양한 개발 플랫폼을 가지게 됩니다. 전담 플랫폼 엔지니어링 팀이 있으면 플랫폼이 팀이 나타내는 작업의 다양성을 더 지원할 수 있습니다
예상치 못한 단점
플랫폼 엔지니어링은 팀과 개인의 생산성이 높아지고 조직 성과가 향상되는 측면에서 확실한 이점을 제공하지만, 예상치 못한 단점이 있었습니다. 또한 처리량과 변경 안정성이 감소하는 것으로 나타났습니다.
처리량의 경우, 플랫폼을 사용하지 않는 사람들과 비교했을 때 약 8% 감소를 보았습니다.
프로덕션에 배포되기 전에 변경 사항이 통과해야 하는 추가된 기계는 변경 사항의 전체 처리량을 감소시킵니다. 일반적으로 내부 개발자 플랫폼을 사용하여 소프트웨어를 빌드하고 제공하는 경우 시스템과 암묵적으로 팀 간의 "핸드오프" 수가 일반적으로 증가합니다. 핸드오프는 전체 프로세스에 시간을 도입하여 처리량은 감소하지만 작업을 완료할 수 있는 능력은 순전히 증가하는 기회입니다.
내부 개발자 플랫폼을 사용할 때 개발 및 운영되는 애플리케이션의 변경 안정성을 고려할 때, 놀랍게도 변경 안정성이 14% 감소했습니다. 이는 플랫폼을 사용할 때 변경 실패율과 재작업율이 상당히 증가한다는 것을 나타냅니다
플랫폼은 개발자와 팀이 변경 사항이 나쁘더라도 신속하게 수정할 수 있다는 확신을 가지고 변경 사항을 푸시할 수 있게 해줍니다. 이 경우 불안정성이 더 높아도 반드시 나쁜 것은 아닙니다. 플랫폼은 팀이 실험하고 변경 사항을 제공할 수 있는 권한을 부여하기 때문에 변경 실패와 재작업 수준이 높아지기 때문입니다.
플랫폼이 애플리케이션에 포함된 모든 테스트를 실행하는 자동화된 테스트 기능을 제공할 수도 있습니다. 그러나 애플리케이션 팀은 품질보다 처리량을 우선시하고 테스트를 개선하지 않음으로써 해당 기능을 충분히 활용하지 못하고 있습니다. 나쁜 변경 사항이 실제로 프로세스를 거쳐 적용되어 재작업이 발생하게 됩니다.
트레이드오프
플랫폼 엔지니어링이 만병통치약은 아니지만, 전반적인 소프트웨어 개발 및 운영 프로세스와 관련해서는 강력한 분야가 될 잠재력이 있습니다. 모든 분야와 마찬가지로 플랫폼 엔지니어링에는 장점과 단점이 있습니다
첫째, 개발자 독립성과 셀프 서비스 기능을 가능하게 하는 플랫폼 기능을 우선시합니다. 이를 수행할 때, 애플리케이션 라이프사이클의 모든 측면에 플랫폼을 독점적으로 사용하도록 요구하는 것과 개발자 독립성을 방해할 수 있는 것 사이의 균형에 주의가 필요합니다.
둘째, 애플리케이션 변경 사항의 불안정성을 주의 깊게 모니터링하고 경험하는 불안정성이 의도적인 것인지 아닌지 이해하려고 노력하는 것이 필요합니다. 플랫폼은 불안정성 측면에서 실험을 활성화하고, 생산성을 높이고, 규모에 따라 성능을 개선할 수 있는 잠재력을 가지고 있습니다.
2024년도의 State of DevOps Report 중 플랫폼엔지니어링의 내용을 중점으로 주요 내용을 확인해봤는데요.
State of DevOps Report 중 다른 내용으로 다뤄볼 주제가 있다면 상세하게 확인해보는 시간을 다시 가져보겠습니다....! 끝...!
유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!
'DevOps' 카테고리의 다른 글
[DevOps] 2024 State of DevOps Report Part 3 (사용자 중심 접근) (1) | 2025.03.21 |
---|---|
[DevOps] 2024 State of DevOps Report Part 1 (AI) (0) | 2025.03.07 |
[DevOps] AWS vs Azure vs GCP vs NCP 사용, 인기도, 관심도 비교 (0) | 2024.02.13 |
[DevOps] 여러가지 CI/CD 툴 사용, 인기도, 관심도 비교 (1) | 2024.02.02 |
[DevOps] AWS vs NCP 주요 서비스 기능 및 비용 비교 (1) | 2024.01.24 |