내부 개발자 플랫폼 도입을 위한 3단계 프레임워크
내부 개발자 플랫폼(IDP)은 개발자가 배포 파이프라인, 구성 관리 또는 환경 프로비저닝의 부담 없이 소프트웨어 제공에 집중하는 데 도움이 될 수 있습니다. 엔지니어링 매니저라면 이것이 바로 찾고 계시던 것일 수 있습니다. 하지만 내부 개발자 플랫폼이 필요하다는 것을 아는 것과 이를 도입하는 것은 별개의 문제입니다.
플랫폼마다 설정 및 유지 관리에 필요한 리소스 수준은 다르지만, 체계적인 접근 방식으로 도입하면 조직이 성공적으로 시작할 수 있습니다. 적절한 내부 개발자 플랫폼을 선택하고 도입하면 개발자의 시간과 리소스를 크게 절약할 수 있습니다.
이 문서에서는 IDP 개념에서 구체적인 작업으로 나아갈 준비가 된 엔지니어링 매니저를 위한 3단계 프레임워크를 제공합니다.
이 문서는 다음과 같은 작업을 수행하는 방법을 다룰 것입니다.
공급업체 후보를 파악하기 위한 제안 요청서(RFP) 제출
채택을 보장하기 위해 선택된 도구 롤아웃
성공 측정 및 개발자 경험 개선 사항 추적
내부 개발자 플랫폼을 위한 RFP를 작성하는 방법
IDP 도입의 첫 번째 단계는 제안 요청서(RFP)를 작성하는 것입니다. RFP는 조직이 내부 개발자 플랫폼에서 필요로 하는 사항을 정확하게 커뮤니케이션하고 있습니다. 이에 대한 응답으로 공급업체는 안내형 데모 및 무료 소프트웨어 평가판 등을 통해 이러한 요구 사항을 충족할 수 있는 방법을 보여주는 제안서를 제출할 것입니다. 이는 또한 팀에 제안서를 평가할 명확한 기준을 제공합니다.
IDP에 필요한 모든 것을 포함하세요
RFP에서 고려해야 할 세 가지 주요 영역이 있습니다.
도전 과제: 현재 엔지니어링 팀이 직면한 도전 과제 중 내부 개발자 플랫폼이 해결에 도움이 될 수 있는 것은 무엇입니까? 해결하고자 하는 몇 가지 주요 도전 과제가 있을 것입니다.
목표: 내부 개발자 플랫폼을 도입하여 어떤 성과를 달성해야 합니까?
제품 요구 사항: 이러한 목표를 달성하려면 어떤 기능과 역량이 필요합니까?
예를 들면 다음과 같습니다.
개발자가 팀에 합류하거나 이동할 때 지식이 유실되고 있다면, 개발자 온보딩 속도를 높이는 것이 목표가 될 수 있습니다. 그렇다면 셀프서비스 워크플로 및 기술 자료 통합을 통해 셀프서비스를 지원하고 수동 구성 단계를 줄이는 기능이 우선적으로 필요할 수 있습니다.
엔지니어링 조직이 확장 중이고 더 많은 모범 사례와 표준을 따라야 한다면, 보안을 개선하고 취약성을 줄이는 것이 목표일 수 있습니다. 그렇다면 보안 플랫폼과 통합하고 성과 기록표로 규정 준수를 모니터링하는 기능이 필요할 수도 있습니다.
엔지니어가 생산성을 높이고 가장 잘하는 업무에 더 많은 시간을 쏟도록 지원하는 것이 어렵게 느껴진다면, 팀이 서비스를 빠르게 가동할 수 있도록 설정 시간을 줄이는 것이 목표일 수 있습니다. 그렇다면 인프라 자동화 및 템플릿화가 필요할 수 있습니다.
현재 상태를 명확히 파악하세요
당면한 도전 과제를 더 잘 이해하고 목표를 결정하려면 조직의 현재 개발자 경험 상태를 평가하세요. 현재 상태를 이미 알고 있다고 단정하지 말고, 개선이 필요한 부분을 조사하기 위해 개발자 설문 조사를 실시하고 기존 프로세스를 감사하며 개발자 포커스 그룹을 운영해 보세요. 다음 단계가 무엇인지 잘 설명하고 팀에 IDP 진척도를 지속적으로 알려 주세요.
Atlassian 개발자 경험 상태 보고서에 따르면 개발자의 절반 미만이 소속 조직에서 개발자 경험을 우선시한다고 생각하는 것으로 나타났습니다. 개발자 3명 중 2명이 여전히 업무 비효율성으로 인해 일주일에 8시간 이상을 허비하고 있다는 사실을 생각하면 놀라운 일이 아닙니다.
내부 개발자 플랫폼을 롤아웃하는 방법
내부 개발자 플랫폼을 선정한 후에는 공동 작업을 통해 롤아웃 프로세스를 계획하고 채택을 추적하세요. 즉시 사용할 수 있는 내부 개발자 플랫폼은 롤아웃에 필요한 팀원들의 수고를 덜어줍니다. 예를 들어, Compass는 제대로 설정하고 유지 관리하는 데 4명의 풀스택 엔지니어가 필요한 Backstage 같은 오픈 소스 플랫폼에 비해 엔지니어링 리소스가 훨씬 적게 필요합니다. Compass를 사용하면 소스 코드 관리 도구를 연결하고 리포지토리를 가져와 단 10분 만에 소프트웨어 컴포넌트 카탈로그를 채울 수 있습니다.
운영 위원회를 조직하세요
롤아웃을 훨씬 더 원활하게 진행하려면 몇 명의 주요 이해 관계자로 구성된 운영 위원회를 조직하세요. 이 전문가들은 지원을 제공하고 프로세스를 모니터링하며, 필요 시 조정 결정을 내립니다.
다음과 같은 이해 관계자를 동원할 것을 권장합니다.
임원 후원자: 개발자 플랫폼 관련 작업을 진두지휘할 최고 책임자입니다. 최고 기술 책임자, 엔지니어링 부사장 또는 플랫폼 책임자가 이 역할에 적합할 수 있습니다.
영향력 있는 개발자: 조직 전체에서 영향력 있는 개발자로 구성된 소규모 그룹을 선택하여 내부 개발자 플랫폼 롤아웃 계획을 설계하는 데 참여시키거나, 최소한 이들과 관련 정보를 지속적으로 공유하세요.
플랫폼 팀 또는 DevOps 엔지니어: 통합은 내부 개발자 플랫폼이 가치를 제공하는 방식의 열쇠이기 때문에, 이러한 도구를 담당하는 팀원들은 롤아웃 과정에서 중요한 파트너가 되어야 합니다.
정책 소유자 또는 거버넌스 팀: 내부 개발자 플랫폼은 엔지니어링 팀이 표준과 모범 사례를 더 쉽게 준수할 수 있도록 지원하므로, 계획을 수립할 때 이러한 표준 담당자와 협력하는 것이 도움이 될 수 있습니다.
롤아웃 일정 만들기
운영 위원회 구성이 완료되면 내부 개발자 플랫폼 롤아웃 일정을 수립하세요. 새로운 내부 개발자 플랫폼을 사용할 모든 팀에게 이 일정을 커뮤니케이션하고 필요에 따라 조정할 수 있도록 계획의 실현 가능성에 대한 추가 피드백을 요청하세요. 일정에 따라 진행하면서 정기적인 점검을 통해 진행률 및 도입 상황을 평가하고 지원을 제공하세요.
저희는 더욱 쉽게 시작할 수 있도록 Compass 구현 가이드를 만들었습니다.
내부 개발자 플랫폼의 성공을 측정하는 방법
진행률을 측정하려면 처음 RFP를 작성할 때 설정한 목표를 다시 확인하세요. 내부 개발자 플랫폼이 목표했던 가치를 제공하고 있는지 종합적으로 보여줄 정성적 및 정량적 주요 성과 지표(KPI)를 마련하세요. Compass를 사용하면 사용자 지정 성과 기록표를 만들어 KPI를 정의하고 엔지니어링 팀이 동일한 기준을 목표로 삼도록 할 수 있습니다.
대부분의 사람들은 KPI를 “명확한 수치” 또는 “객관적인 척도”로 생각하며, 이는 수익 또는 실패율과 같은 정량적 개념에는 잘 맞아떨어집니다. 하지만 개발자 경험은 주관적이기 때문에, KPI는 소프트웨어 제공의 체감 편의성, 체감 생산성, 직원 참여도 또는 만족도와 같이 다소 정성적인 성격을 띠게 됩니다.
조직에 맞는 올바른 측정 지표를 찾으세요
다음은 목표에 따라 추적할 수 있는 몇 가지 지표의 예시입니다.
보안 향상이 목표라면, 매 분기마다 미해결 취약성을 일정량 줄이는 것을 목표로 할 수 있습니다.
생산성 향상을 목표로 한다면, KPI는 인프라 프로비저닝 리드 타임을 5일에서 2시간으로 단축하는 것이 될 수 있습니다.
더 빠른 온보딩이 목표라면, 신규 개발자가 생산성을 발휘하기까지 걸리는 시간을 추적하고 이를 단축하는 것을 목표로 할 수 있습니다.
개발자 경험 개선이 가장 중요하다면, 개발자 설문 조사에서 더 높은 개발자 만족도 점수를 목표로 할 수 있습니다.
시간이 지남에 따라 계속 추적하세요
내부 개발자 플랫폼의 효과를 확인하는 데는 다소 시간이 걸릴 수 있습니다. 진행률을 계속 모니터링하고 팀과 함께 점검 및 회고를 활용하여 시간이 지남에 따라 내부 개발자 플랫폼이 원하는 결과를 제공하고 있는지 논의하세요.
팀 회고는 개발자와 리더에게 잘 진행되는 부분과 그렇지 않은 부분을 돌아볼 기회를 제공합니다. Atlassian 팀 플레이북의 회고 플레이에서 기본 회고 지시 사항과 템플릿은 물론, 특정 상황에 맞는 변형 버전도 확인할 수 있습니다.