8.4 플랫폼 엔지니어링과 개발자 경험

개요와 동기

플랫폼 엔지니어링은 다른 엔지니어가 소프트웨어를 만들고, 출하하고, 운영하는 데 쓰는 내부 제품, 곧 내부 개발자 플랫폼(IDP)을 만들고 운영하는 규율입니다. 각 팀이 처음부터 자기 파이프라인, 인프라, 도구를 조립하는 대신, 전담 플랫폼 팀이 잘 지원되는 “골든 패스”, 곧 합리적인 기본값이 내장된 의견 있고 지원되는 경로를 따라 큐레이션된 셀프서비스 역량을 제공합니다. 개발자 경험(DevEx)은 밀접하게 관련된 관심사로, 조직에서 엔지니어가 되는 것이 어떻게 느껴지는가입니다. 개발자가 아이디어에서 실행 중인 소프트웨어까지 얼마나 쉽고 빠르게 갈 수 있는지, 길을 막는 마찰이 얼마나 되는지입니다.

큰 팀에게 이것이 중요한 이유는 인지 부하와 마찰이 우아하게 확장되지 않기 때문입니다. 팀이 많아지면 각 엔지니어가 저글링해야 하는 도구, 시스템, 결정의 수가 계속 늘어납니다. 얼마 지나지 않아 시간의 큰 부분이 가치를 전달하는 대신 인프라 배관과 조율에 갑니다. 플랫폼이 없으면 모든 팀이 프로비저닝, 배포, 관측 가능성, 컴플라이언스 같은 같은 문제를 일관성 없이 반복적으로 해결합니다. 좋은 플랫폼은 이 공유된 복잡성을 흡수합니다. 그러면 팀은 보안, 신뢰성, 비용에 대한 조직의 표준을 물려받으면서 자기 도메인에 집중할 수 있습니다.

기업과 정부와의 관련은 높습니다. 이 조직들은 규모와 엄격한 거버넌스를 결합하기 때문입니다. 플랫폼은 컴플라이언스, 보안, 감사 요건을 팀이 기본으로 따르는 포장된 길로 한 번 코드화하기에 자연스러운 곳입니다. 모든 팀이 정책을 스스로 올바르게 해석하고 구현하기를 기대하는 것보다 낫습니다. 거버넌스를 마찰의 원천에서 표준 워크플로의 보이지 않는 속성으로 바꾸며, 대규모 규제 조직이 통제를 잃지 않고 빠르게 움직이는 데 필요한 바로 그것입니다.

핵심 원칙

플랫폼을 사용자, 로드맵, 강요가 아니라 채택을 얻어야 한다는 임무가 있는 제품으로 다루십시오.
골든 패스를 제공하십시오. 옳은 방법을 쉬운 방법으로 만드는 의견 있고 잘 지원되는 경로입니다.
팀이 티켓과 사람의 인계를 기다리지 않도록 역량을 셀프서비스로 만드십시오.
관문을 세우지 말고 길을 포장하십시오. 정당한 작업을 막지 않고 안내하는 가드레일을 내장합니다.
애플리케이션 개발자의 인지 부하를 끈질기게 줄이십시오.
균형 잡힌 다차원 신호로 개발자 경험과 생산성을 측정하십시오.
골든 패스는 선택적으로 유지하되 팀이 선택할 만큼 훌륭하게 만드십시오.

권장 사항

플랫폼을 제품으로 만든다

가장 중요한 단일 전환은 플랫폼을 위에서 부과한 의무화된 표준이 아니라 내부 고객에게 봉사하는 제품으로 다루는 것입니다. 실무적으로는 리서치와 피드백으로 개발자의 필요를 이해하고, 로드맵을 유지하고, 채택과 만족을 측정하고, 경험에 책임진다는 뜻입니다. 팀이 쓰도록 강요받지만 그들을 늦추는 플랫폼은 원망받고 우회될 것입니다. 팀을 진정으로 빠르게 해 주는 플랫폼은 평판으로 퍼질 것입니다. 품질로 얻은 채택이 플랫폼 성공의 가장 참된 척도입니다.

골든 패스와 포장된 길을 제공한다

흔한 여정에 골든 패스를 정의하십시오. 새 서비스 만들기, 배포하기, 데이터베이스 추가하기, 관측 가능성 연결하기, 컴플라이언스 요건 충족하기입니다. 골든 패스는 합리적인 기본값이 내장된 지원되고 의견 있는 끝에서 끝까지의 경로입니다. 이 경로를 따라 가드레일, 곧 보안 스캔, 정책 검사, 모범 사례를 내장해, 경로를 따르는 팀이 자동으로 컴플라이언스를 지키고 안전하게 하십시오. 목표는 단순합니다. 무언가를 하는 가장 쉬운 방법이 올바르고, 안전하고, 컴플라이언스를 지키는 방법이기도 해야 합니다. 정말 특이한 필요가 있는 팀이 벗어날 수 있도록 경로를 선택적으로 유지하십시오. 그러나 대부분의 팀이 결코 벗어나고 싶지 않을 만큼 경로를 매력적으로 만드십시오.

진정한 셀프서비스 인프라를 제공한다

포털, 명령줄 도구, API, 템플릿 저장소 같은 셀프서비스 인터페이스로 인프라와 역량을 노출해 티켓과 대기의 인계를 없애십시오. 개발자는 다른 팀에 요청을 올리고 며칠 기다리지 않고 몇 분 안에 컴플라이언스를 지키는 환경을 프로비저닝하고, 템플릿에서 새 서비스를 띄우고, 데이터베이스를 요청할 수 있어야 합니다. 셀프서비스가 플랫폼을 병목에서 가속기로 바꿉니다. 그리고 그것은 기저의 가드레일이 셀프서비스를 안전하게 만들기 때문에만 동작합니다.

개발자 포털, 서비스 카탈로그, 스코어카드를 제공한다

개발자 포털은 단일 창을 줍니다. 소유자, 문서, 의존성, 상태가 있는 모든 서비스의 카탈로그입니다. 서비스 카탈로그는 소유권과 아키텍처를 발견 가능하게 합니다. 아무도 시스템 전체를 머릿속에 담을 수 없는 규모에서 귀중합니다. 스코어카드는 테스트 커버리지, 보안 태세, 온콜 준비도, 문서화 같은 표준에 대해 각 서비스를 측정하고, 팀에게 어디에 서 있고 무엇을 개선할지에 대한 분명하고 객관적인 그림을 줍니다. 함께 이 도구들은 엔지니어가 정보를 찾는 데 쓰는 시간을 줄이고 책무를 분명히 합니다.

균형 잡힌 틀로 개발자 경험을 측정한다

단일 숫자 생산성 지표에 저항하십시오. 쉽게 조작되고 오도합니다. 개발자 경험의 실제 질감을 포착하도록 SPACE(만족과 웰빙, 성과, 활동, 소통과 협업, 효율과 흐름) 같은 다차원 틀을 쓰십시오. 설문의 인식 데이터를 도구의 시스템 데이터와 결합하십시오. 리드 타임과 배포 빈도 같은 전달 지표를 개발자 감정과 나란히 추적하십시오. 목표는 개인의 순위를 매기는 것이 아니라 마찰을 이해하고 제거하는 것입니다. 감시처럼 느껴지는 측정은 플랫폼이 의존하는 신뢰를 부식시킵니다.

인지 부하 줄이기를 일급 목표로 삼는다

인지 부하, 곧 개발자가 일을 하는 데 써야 하는 총 정신적 노력은 플랫폼이 줄이기 위해 존재하는 숨은 세금입니다. 애플리케이션 개발자가 숙달해야 하는 도구, 개념, 맥락 전환의 수를 최소화하십시오. 팀이 가치 낮은 결정을 덜 내도록 합리적인 기본값을 제공하십시오. 각 팀이 시스템의 한정되고 이해 가능한 조각을 소유하도록 소유권을 구조화하십시오. 어떤 플랫폼 기능을 평가하든 한 가지 질문을 하십시오. 그것을 쓸 팀의 부하를 줄입니까, 늘립니까?

장단점

선택	장점	단점	가장 적합한 곳
제품으로서의 플랫폼 (옵트인)	채택을 얻음. 유용하게 유지	전체 커버리지까지 더 느림	대부분의 조직
의무화된 플랫폼	빠른 표준화	원망. 우회	강한 거버넌스 필요에만
포털/플랫폼 구매	가치까지 더 빠름	덜 맞춤. 라이선스 비용	우위를 점하고 싶은 팀
자체 구축	정확한 필요에 맞음	높은 구축 및 유지 비용	크고 독특한 조직
경직된 골든 패스만	최대의 일관성	정당한 엣지 케이스를 막음	매우 균일한 워크로드
탈출구가 있는 유연한 경로	일관성과 자율의 균형	관리할 일부 이탈	다양한 팀 필요

핵심 긴장은 표준화 대 자율입니다. 표준화가 너무 적으면 모든 팀이 일관성 없이 바퀴를 다시 발명합니다. 너무 많으면 필요가 정말 다른 팀을 질식시킵니다. 제품으로서의 플랫폼 철학은 표준화를 의무가 아니라 매력적으로 만들어 이를 해결합니다. 두 번째 실제 트레이드오프는 구축 대 구매입니다. 자체 플랫폼을 구축하면 정확한 필요에 맞지만 상당한 지속적 비용을 지닙니다. 기존 도구를 채택하면 일부 맞춤을 대가로 가치가 빨라집니다.

팀과 논의할 질문

플랫폼이 배울 도구를 하나 더하는 것이 아니라 인지 부하를 줄이고 있음을 어떻게 알겠습니까? 인지 부하는 엔지니어가 일을 하는 데 쓰는 총 정신적 노력이며, 개념과 맥락 전환을 더하는 플랫폼은 인상적으로 보이면서도 이를 악화시킬 수 있습니다. 모든 기능에 하나의 시험을 채택하십시오. 그것을 쓰는 팀의 부하를 줄입니까, 늘립니까? 규모에서 이는 결정적입니다. 플랫폼은 수백 명의 엔지니어 앞에 서 있고 혼란스러운 추상화가 매일 모두에게 세금을 매기기 때문입니다. 증거를 가져오십시오. 변경을 출하하려고 개발자가 건드리는 도구와 포털의 수, 신입의 첫 배포까지의 시간, 사람들이 어디서 막히는지에 대한 정성적 피드백입니다. 플랫폼이 도구 체인을 줄이는 대신 키운다면, 포장된 길이 아니라 세금을 만든 것입니다.
스코어카드는 어떤 표준을 시행하며, 점수가 나쁜 서비스에는 실제로 무슨 일이 일어납니까? 스코어카드는 테스트 커버리지, 보안 태세, 온콜 준비도, 문서화 같은 기대에 대해 각 서비스를 측정하며, 빨간 점수에 결과가 따르지 않으면 가치가 무너집니다. 스코어카드가 순수 권고인지, 리뷰에 반영되는지, 특정 역량을 관문 통제하는지 정하고, 누가 표준을 소유하는지 정하십시오. 규제 조직에서 스코어카드는 감독 기관에 컴플라이언스 태세의 지속적 가시성을 주어 수동 보고를 대체할 수 있으므로, 정하는 기준이 중요합니다. 표준 초안과 그에 대해 점수를 매긴 실제 서비스의 표본을 가져오고, 팀이 정당하게 반발할 곳을 논의하십시오. 아무도 행동하지 않는 스코어카드는 대시보드이고, 분명한 기대에 묶인 스코어카드는 행동을 바꿉니다.
플랫폼을 로드맵, 사용자 리서치, 채택 지표가 있는 진짜 제품으로 운영합니까, 의무로 운영합니까? 이 장의 중심 내기는 표준화가 강요되는 것이 아니라 매력적이어야 한다는 것이며, 이는 내부 엔지니어를 얻어야 하는 고객으로 다룰 때만 유지됩니다. 누가 플랫폼의 제품 관리자 역할을 하는지, 개발자의 필요를 어떻게 모으는지, 어떤 채택과 만족 숫자가 성공을 정의하는지 정하십시오. 큰 조직에서 의무는 빠르게 표준화하므로 유혹적이지만, 도구가 사람들을 늦출 때 우회와 원망을 낳습니다. 현재의 자발적 채택률, 만족 신호, 팀이 오늘 보고하는 최상위 마찰 지점을 가져오십시오. 의무가 풀리는 순간 팀이 플랫폼을 버린다면, 제품을 만든 것이 아니라 정책을 만든 것입니다.
팀이 골든 패스의 가장자리에 닿으면 탈출구는 무엇이며, 경로를 넓힐지 선을 지킬지는 누가 결정합니까? 골든 패스는 합리적인 기본값이 있는 지원되고 의견 있는 경로이며, 그 가치는 대부분의 팀이 거기 머무는 데서 오지만, 출구 없는 경로는 정말 특이한 작업을 플랫폼에서 완전히 밀어내는 관문이 됩니다. 팀이 이탈을 어떻게 요청하는지, 누가 리뷰하는지, 일회성 예외와 경로 자체가 바뀌어야 한다는 신호를 어떻게 구별하는지 미리 합의하십시오. 큰 조직에서 이는 다양성을 흡수하는 플랫폼과 팀이 막혔다고 느끼는 순간 그림자 도구로 파편화되는 플랫폼의 차이입니다. 경로를 벗어난 팀의 현재 수, 그들이 댄 이유, 예외 승인에 걸리는 시간을 가져오십시오. 기업과 정부 환경에서는 각 탈출구를 그것이 우회하는 컴플라이언스 통제에 묶어, 포장된 길에서의 이탈이 보안이나 인증 기준선에서의 이탈로 조용히 번지지 않게 하십시오.
플랫폼을 자체 구축합니까, 구매합니까? 어느 쪽이든 지속적 비용의 가격을 정직하게 매겼습니까? 플랫폼 자체가 수명 주기가 있는 제품이며, 구축 대 구매 선택이 여러 해 동안 비용 구조를 정합니다. 자체 포털은 정확한 필요에 맞지만 그것을 유지할 자금이 있는 팀을 요구하고, 구매한 플랫폼은 라이선스와 결코 완벽하지 않은 적합을 대가로 가치에 더 빨리 닿습니다. 어느 역량이 만들 만큼 차별화되고 어느 것이 사야 할 범용인지 정하고, 벤더가 성숙함에 따라 그 선을 다시 검토하십시오. 큰 팀에서 판돈은 지렛대입니다. 잘못된 구축 결정은 제품이 처리했을 배관에 희소한 시니어 엔지니어를 가라앉히고, 잘못된 구매 결정은 수백 명의 개발자를 다른 이의 로드맵에 가둡니다. 유지보수, 업그레이드, 퇴출 비용을 포함해 각 옵션의 현실적인 총비용 추정을 가져오십시오. 기업과 정부 조달에서는 인증과 데이터 이식성 약관을 더하고, 위에 쌓은 서비스 카탈로그와 스코어카드를 버리지 않고 떠날 수 있는 계약을 선호하십시오.
플랫폼 팀은 봉사하는 개발자에 비해 어떻게 자금이 지원되고 규모가 정해지며, 예산이 빠듯해지면 어떻게 됩니까? 플랫폼은 지렛대로 값을 합니다. 작은 팀이 훨씬 큰 애플리케이션 개발자 집단의 생산성을 곱하기 때문입니다. 그러나 바로 그 틀 때문에 재무가 삭감을 찾을 때 이득이 한 제품 라인에 귀속되지 않고 퍼져 있어 쉬운 표적이 됩니다. 자금 모델, 플랫폼 엔지니어 대 그들이 지원하는 개발자의 비율, 믿음이 아니라 증거로 그 투자를 어떻게 방어할지 정하십시오. 큰 조직에서 자금이 부족한 플랫폼은 없는 것보다 나쁩니다. 팀이 그것에 의존하고, 그것이 쇠퇴하고, 의존이 붙은 채 마찰이 돌아오기 때문입니다. 플랫폼의 인원, 채택과 만족 추세, 조직 전체에서 되찾은 개발자 시간의 추정을 가져오십시오. 정부와 규제된 기업에서는 플랫폼을 컴플라이언스가 한 번 코드화되는 곳으로 구성하십시오. 그것을 삭감하는 것은 돈을 아끼는 것이 아니라 감사와 보안 작업을 이제 손으로 해야 하는 모든 팀에 다시 흩뿌리는 것입니다.

분야별 관점

스타트업. 엔지니어가 소수이고 여유 자금이 없다면 플랫폼 팀을 세우지 마십시오. 새 서비스가 복제해 한 시간 안에 돌릴 수 있는 골든 패스 템플릿 저장소 하나를 만드십시오. CI, 컨테이너 빌드, 린팅, 상태 검사를 미리 연결하고, 누가 의무화해서가 아니라 시간을 아끼는 것이 분명하기 때문에 퍼지게 하십시오. 살 수 있는 범용 역량은 모두 사고, 도구 체인을 작게 유지하고, 커버리지가 아니라 인지 부하를 지킬 것으로 다루십시오.

소기업. 전담 플랫폼 전문가도 빠듯한 예산도 있을 테니 내부 개발자 플랫폼을 직접 만드는 대신 관리형 플랫폼이나 의견 있는 클라우드 제품에 기대십시오. 결정을 구매 대 구축으로 구성하고 기본으로 구매하십시오. 구매한 포털과 템플릿은 유지할 팀 없이도 제너럴리스트 엔지니어에게 골든 패스를 줍니다. 벤더 변경이 운영하는 소수의 서비스를 고립시키지 않도록 셀프서비스이고 떠나기 쉬운 도구를 고르십시오.

대기업. 규모와 많은 팀이 포트폴리오 일관성을 보상으로 만듭니다. 자금이 지원되는 플랫폼 팀, 가드레일이 있는 골든 패스, 셀프서비스 프로비저닝, 서비스 카탈로그, 수백 개 서비스에 걸쳐 소유권과 품질을 보이게 하는 스코어카드입니다. 플랫폼을 우회를 낳는 의무가 아니라 자발적 채택을 얻는 제품으로 운영하고, 거버넌스가 기본으로 따라오도록 보안과 컴플라이언스를 포장된 길로 한 번 코드화하십시오. 균형 잡힌 틀로 개발자 경험을 측정하고 되찾은 개발자 시간으로 플랫폼의 자금을 방어하십시오.

정부. 조달 규칙, 투명성, 공적 책임이 플랫폼을 형성합니다. 의무화된 보안 통제와 인증 요건을 골든 패스를 따라 가드레일로 코드화해, 셀프서비스 포털로 프로비저닝하는 팀이 이미 통제 기준선을 충족하는 환경을 물려받게 하여, 몇 달의 수동 인증을 대체로 자동화된 단계로 바꾸십시오. 스코어카드로 감독 기관에 컴플라이언스 태세의 지속적이고 감사 가능한 가시성을 주고, 조달에서는 쌓은 카탈로그와 포장된 길이 한 공급자에 묶이지 않도록 데이터 이식성과 개방형 인터페이스를 요구하십시오.

사례

스타트업. 열두 명의 스타트업에는 플랫폼 팀이 없어서, 한 시니어 엔지니어가 몇 번의 금요일을 써서 CI, Dockerfile, 린팅, 상태 검사가 미리 연결된 하나의 “새 서비스” 템플릿 저장소를 만듭니다. 어떤 엔지니어든 복제해 한 시간 안에 스테이징에서 서비스를 돌릴 수 있어, 옛 프로젝트에서 구성을 복사하고 빠진 곳을 짐작하는 일이 없어집니다. 템플릿이 골든 패스이며, 모두의 시간을 아끼는 것이 분명하므로 아무도 시키지 않았는데 팀 전체가 채택합니다.

기업. 한 대형 보험사가 내부 개발자 포털을 출하하는 플랫폼 팀을 꾸립니다. 모든 서비스를 소유자, 문서, 상태 스코어카드와 함께 카탈로그화합니다. 새 서비스는 CI/CD, 보안 스캔, 관측 가능성, 컴플라이언스 검사가 미리 연결된 골든 패스 템플릿에서 만들어집니다. 데이터베이스와 환경은 포털을 통해 셀프서비스로 프로비저닝됩니다. 신입 엔지니어의 온보딩 시간이 몇 주에서 며칠로 줄고, 모든 서비스가 같은 포장된 길을 따르므로 감사 증거가 자동으로 생산됩니다. 플랫폼 채택은 자발적이며, 그것을 쓰는 팀이 눈에 띄게 더 빨리 출하하므로 퍼집니다.

정부. 수십 개의 디지털 서비스를 운영하는 한 연방 기관이 공유 플랫폼을 세웁니다. 의무화된 보안 통제와 인증 요건을 골든 패스를 따라 가드레일로 코드화합니다. 셀프서비스 포털로 인프라를 프로비저닝하는 팀은 이미 통제 기준선을 충족하는 환경을 물려받습니다. 이것이 몇 달짜리 수동 인증 작업을 대체로 자동화된 것으로 바꿉니다. 스코어카드가 각 서비스의 컴플라이언스 태세를 추적해 감독 기관에 수동 보고 없이 지속적 가시성을 주고, 희소한 전문 인력을 반복적 리뷰에서 풀어 줍니다.

비즈니스 사례: 동기, ROI, TCO

플랫폼 엔지니어링의 ROI는 되찾은 개발자 시간과 얻은 일관성에서 나옵니다. 엔지니어가 인프라와 씨름하고 정보를 찾는 데 시간을 덜 쓰면, 그들의 비싼 시간이 더 많이 제품 가치를 전달하는 데 갑니다. 더 빠른 온보딩, 더 적은 중복된 해법, 자동화된 컴플라이언스는 모두 측정 가능한 역량과 줄어든 위험으로 이어집니다. 플랫폼이 많은 팀에 봉사하므로 그에 대한 모든 개선은 조직 전체로 지렛대 효과를 냅니다.

TCO에서 도입 비용은 실제의 지속적 투자입니다. 자금이 지원되는 플랫폼 팀, (만들거나 산) 도구, 지속적 개선과 함께 플랫폼을 제품으로 운영하는 규율입니다. 도입하지 않는 비용은 퍼져 있지만 큽니다. 모든 팀이 같은 인프라 세금을 반복해서 치르고, 일관성 없는 보안과 컴플라이언스, 느린 온보딩, 고역에 소진되는 시니어 엔지니어입니다. 리더십에게 논거는 지렛대의 관점이 가장 좋습니다. 소박하고 잘 운영되는 플랫폼 팀이 훨씬 큰 애플리케이션 개발자 집단의 생산성을 곱하며, 모든 팀이 제대로 하기를 기대하는 대신 거버넌스를 한 번 코드화합니다.

안티패턴과 함정

제공되지 않고 부과된 플랫폼. 개발자가 싫어하는 플랫폼을 의무화하면 우회와 원망을 낳습니다.
상아탑 플랫폼 팀. 실제 개발자 필요를 이해하지 않고 만들면 아무도 원하지 않는 도구가 나옵니다.
포장된 길 대신 관문. 정당한 작업을 막는 가드레일은 팀이 플랫폼을 완전히 우회하게 밀어냅니다.
단일 생산성 지표. 생산성을 조작 가능한 하나의 숫자로 환원하면 행동을 왜곡하고 신뢰를 침식합니다.
감시로서의 측정. 개인의 순위를 매기는 데 쓰이는 DevEx 지표는 플랫폼이 필요로 하는 심리적 안전을 파괴합니다.
탈출구 없는 골든 패스. 진짜 엣지 케이스에 유연하지 못한 경직된 경로는 장애물이 됩니다.
자금이 부족한 플랫폼. 플랫폼을 부업 프로젝트로 다루면 굶겨 형편없는 경험이 보장됩니다.

성숙도 모델

1단계: 시작. 플랫폼이 없습니다. 각 팀이 반응적으로 자기 도구와 인프라를 조립하며, 티켓 기반 인계, 중복된 해법, 높은 인지 부하가 많습니다. 모든 팀이 프로비저닝, 배포, 컴플라이언스를 스스로, 일관성 없이 해결합니다.

2단계: 발전. 공유 도구, 템플릿, 스타터 저장소가 나타나는데, 열의 있는 엔지니어가 만든 경우가 많고 파편화되고 부분적으로 수동입니다. 몇몇 팀은 골든 패스를 채택하고 다른 팀은 무시하며, 셀프서비스는 제한적이고, 개발자 경험이 측정되지 않아 플랫폼의 가치는 일화에 의존합니다.

3단계: 표준화. 플랫폼 팀이 문서화된 골든 패스, 셀프서비스 프로비저닝, 서비스 카탈로그가 있는 개발자 포털, 스코어카드를 조직 전체에 운영합니다. 보안, 정책, 컴플라이언스 가드레일이 포장된 길에 내장되어 표준 워크플로가 컴플라이언스를 지키는 것이고, 같은 관례가 그룹마다 다르지 않고 팀 전반에 유지됩니다.

4단계: 관리. 플랫폼이 기준선에 대해 데이터로 측정되고 통제됩니다. 채택, 만족, 첫 배포까지의 시간, 리드 타임, 배포 빈도가 SPACE 같은 균형 잡힌 틀과 결합된 설문 및 시스템 신호로 추적되고, 스코어카드 결과가 리뷰에 공급되며, 인지 부하, 온보딩 시간, 되찾은 개발자 시간이 목표에 대해 모니터링됩니다. 역량에 투자하거나 퇴역시키는 결정은 옹호가 아니라 증거에 근거합니다.

5단계: 오케스트레이션. 플랫폼은 높은 자발적 채택을 가진 성숙한 제품으로, 개발자 피드백과 지표로 지속적으로 개선되고 조직 전체의 보안, 컴플라이언스, 전달 계획과 통합됩니다. 골든 패스는 필요가 이동함에 따라 적응하고, 거버넌스는 표준 워크플로의 보이지 않는 속성이며, 플랫폼 팀은 기술과 조직이 진화함에 따라 역량을 일상적으로 퇴역시키고, 교체하고, 범위를 다시 정합니다.

논의를 위한 아이디어

의무화하지 않고 플랫폼의 채택을 어떻게 얻으며, 의무가 정당화되는 때가 있다면 언제입니까?
어떤 골든 패스가 팀에 가장 먼저 가장 큰 가치를 줄까요?
감시처럼 느껴지지 않게 개발자 경험을 어떻게 측정합니까?
특이한 팀이 플랫폼에서 완전히 밀려나지 않도록 탈출구는 어디에 있어야 합니까?
플랫폼 팀이 봉사하는 개발자에 비해 적절한 규모와 자금 모델은 무엇입니까?
개발자 포털과 도구에서 무엇을 자체 구축하고 무엇을 구매할지 어떻게 결정합니까?

핵심 요점

플랫폼을 팀을 진정으로 빠르게 만들어 채택을 얻는 제품으로 운영하십시오.
올바르고, 안전하고, 컴플라이언스를 지키는 방법을 쉬운 방법으로 만드는 골든 패스와 포장된 길을 제공하십시오.
팀이 티켓과 인계를 기다리기를 멈추도록 진짜 셀프서비스를 전달하십시오.
포털, 카탈로그, 스코어카드로 소유권, 아키텍처, 품질을 보이게 하십시오.
단일한 조작 가능한 숫자가 아니라 SPACE 같은 균형 잡힌 틀로 개발자 경험을 측정하십시오.
인지 부하 줄이기를 플랫폼의 중심 목적으로 다루십시오.

참고 문헌과 더 읽을거리

Matthew Skelton and Manuel Pais, Team Topologies.
Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, et al., “The SPACE of Developer Productivity” (paper).
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
Gregor Hohpe, The Software Architect Elevator.
Camille Fournier, The Manager’s Path.
Cloud Native Computing Foundation, platform engineering white paper.