플랫폼 엔지니어링 성공을 위한 제품 사고방식의 핵심

작성자: Aeris Stewart, 2023년 8월 31일

플랫폼 엔지니어링이 전 세계를 휩쓸고 있는 데에는 그럴 만한 이유가 있습니다. 좋은 플랫폼은 TicketOps를 줄이고 구성 설정을 표준화하며 리드 타임과 출시 시간을 단축합니다. 이 분야의 새로운 인기에도 불구하고 플랫폼 엔지니어링이 DevOps와 차별화되는 요소에 대한 몇 가지 질문이 남아 있습니다. 이러한 질문에 대한 답은 모든 성공적인 플랫폼 엔지니어링 노력의 핵심인 제품 접근 방식으로서의 플랫폼에 있습니다.

Luca Galante에 따르면 플랫폼 엔지니어링은 "클라우드 네이티브 시대의 소프트웨어 엔지니어링 조직을 위한 셀프 서비스 기능을 지원하는 도구 체인 및 워크플로를 설계하고 구축하는 분야"입니다. 플랫폼 엔지니어는 "컨텍스트와 기본 기술을 추상화하지 않고 개발자의 인지 부하를 낮추는 방식으로 서로 결합된 다양한 기술과 도구로 구성되는" 내부 개발자 플랫폼을 구축합니다.

제품 접근 방식에는 사용자 조사, 정의된 임무, 등대 팀 활용, 정기적인 피드백 받기, 내부 동의를 위한 플랫폼 반복 및 마케팅이 필요합니다. 이러한 제품 관리 모범 사례를 함께 사용하면 플랫폼이 진정한 개발자 셀프 서비스를 지원하고 적절한 수준의 추상화를 찾을 수 있습니다.

"만들면 그들이 올 것이다"는 개발자가 플랫폼을 채택하도록 보장하기 위한 실행 가능한 전략이 아닙니다. 마찬가지로 개발자에게 플랫폼을 사용하도록 강요하는 것도 실패할 가능성이 높습니다. 의무적인 사용은 분노를 불러일으키고 신뢰를 감소시키며 섀도우 작전을 초래합니다. 플랫폼이 조기에 종료되는 것을 방지하려면 플랫폼을 제품처럼 취급하고 고객, 즉 개발자에게 판매해야 합니다.

이 문서에서는 실제로 제품 사고방식이 어떤 모습인지, 그리고 각 구성 요소가 플랫폼의 성공에 기여하는 이유에 대한 높은 수준의 개요를 제공합니다.

개발자의 문제점과 이러한 문제를 완화하기 위해 개발자가 이미 수행하고 있는 작업을 포괄적으로 이해하지 못하면 사람들이 실제로 사용하고 싶어하는 플랫폼을 구축할 수 없습니다. Hashicorp의 Michael Galloway는 Doma에 있는 동안 자신의 팀과 함께 실시한 사용자 설문 조사의 예를 공유했습니다. 인터뷰 대상자의 작업 계획 단계부터 디버깅 및 테스트에 이르기까지 전체 소프트웨어 제공 프로세스에 대해 질문하는 것이 아이디어입니다. 이러한 방식으로 플랫폼 팀은 개발자가 가장 좌절감을 느끼는 문제를 해결하기 위한 기능 생성에 우선순위를 둘 수 있습니다.

종종 플랫폼 팀은 플랫폼이 어떠해야 하는지에 대해 서로 상충되는 요구 사항과 관점을 갖고 있음을 발견하게 됩니다. 플랫폼 제품 관리자는 서로 다른 응답을 실행 가능하고 성공적인 계획으로 전환하는 데 도움을 줄 것입니다. 성공적인 플랫폼 팀은 또한 오픈 소스 및 상용 도구를 연구하고 유익한 경우 사전 구축된 솔루션을 플랫폼에 통합합니다. 그들은 McKinsey가 개발한 내부 개발자 플랫폼 참조 아키텍처와 같은 청사진을 출발점으로 연구합니다.

귀하의 사명 선언문은 플랫폼 팀에 명확한 정체성과 우선 순위를 제공합니다. 이는 또한 관련 이해관계자에게 비즈니스에 미치는 영향을 이해하고 전달하기 위한 출발점이기도 합니다. 좋은 사명 선언문은 감정적이고 고무적이며 단순하지만 의미가 있고 조직의 수명과 일치하며 사용자 연구를 통해 정보를 얻습니다.

플랫폼 엔지니어링 여정을 시작할 때 많은 조직에서는 무엇을 먼저 구축해야 할지 모릅니다. 혼란은 두 가지 중요하면서도 상충되는 우선순위 때문에 발생합니다. 한편으로, 플랫폼 팀은 한 번에 너무 많은 기능을 구축하여 감당할 수 있는 것보다 더 많은 것을 물어뜯는 것을 원하지 않습니다. 반면, 기업 전체를 포괄할 만큼 얇은 플랫폼은 개별 팀에 충분한 가치를 제공하지 못하는 경우가 많습니다.

올바른 균형을 유지하는 방법은 등대 팀을 활용하는 것입니다. Lighthouse 팀은 조직의 플랫폼을 구축하기 위해 선택한 첫 번째 사람들 그룹이므로 올바른 플랫폼을 구축하기 위해 그들과 많은 시간을 보내십시오. 대사와 전도자를 양성하고 그들에게 나머지 팀(및 조직!)이 귀하의 플랫폼에 참여하도록 할 시간을 주십시오. 등대팀에 실질적인 가치를 제공하는 플랫폼을 구축한 후에는 조직 전체의 더 많은 팀과 함께 이 프로세스를 반복하세요.