기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

내부 개발자 플랫폼 구축 원칙

제품 사고방식 채택

성공의 주요 원칙은 내부 개발자 플랫폼을 기능 세트와 로드맵이 있는 일반 애플리케이션 또는 제품으로 취급하는 것입니다. 이를 통해 내부 개발자 플랫폼이 제공할 도구 및 프로세스 세트를 정의할 수 있습니다. 또한 소프트웨어 제공 주기를 개선하거나 운영 인시던트의 양을 줄이는 등 플랫폼 기능 채택의 성공을 측정하는 방법을 식별하는 데 도움이 됩니다. 제품 사고방식을 채택하면 내부 개발자 플랫폼에서 제공하는 가치를 정량화하고 원래 목표를 달성할 수 있습니다.

고객에 집중

또 다른 중요한 원칙은 내부 개발자 플랫폼의 고객이 누구인지 식별하는 것입니다. 기본적으로 고객은 개발자입니다. 플랫폼의 목표는 개발자의 요구를 충족하고 현재 위치에서 고객을 충족하는 것이므로 고객을 이해하는 것이 매우 중요합니다. 즉, 플랫폼 로드맵을 조정해야 합니다. 개발자에게 필요한 사항에 따라 기능의 우선순위를 정합니다.

온디맨드 및 자동으로 셀프 서비스 기능 제공

또 다른 성공 원칙은 셀프 서비스 메커니즘을 통해 기능을 제공하여 플랫폼이 개발자의 복잡성을 숨겨야 한다는 것입니다. 팀이 클라우드 공급자를 사용하든 Amazon Elastic Kubernetes Service(Amazon EKS)와 같은 컴퓨팅 서비스를 사용하든 개발자는 이러한 세부 정보를 신경쓰지 않아야 합니다. 내부 개발자 플랫폼은 개발자가 가치를 제공하는 데 도움이 되는 그래픽 사용자 인터페이스(GUI), API 또는 명령줄 인터페이스(CLI)와 같은 간단한 인터페이스를 제공해야 합니다. 성공적인 셀프 서비스 메커니즘을 제공하려면 올바른 템플릿 설계로 시작하는 것이 중요합니다. 템플릿에는 기능 제공을 자동화하는 데 필요한 최소 파라미터가 포함되어야 합니다. 개발자가 품질 게이트 및 보안 요구 사항을 충족하는 데 도움이 되는 테스트 프로세스를 자동화해야 하며 기능 배포 후 주요 지표에 대한 피드백도 제공해야 합니다.

셀프 서비스 메커니즘은 개발자의 인지 부하를 줄이는 데 도움이 됩니다. 개발자가 프로덕션에 배포하는 데 사용해야 하는 서비스 및 도구의 수를 줄입니다. 사용자 경험을 간소화하면 플랫폼을 더 많은 팀에 마케팅하는 데 도움이 됩니다. 개발자가 사용할 때마다 온디맨드 방식으로 내부 개발자 플랫폼을 사용할 수 있는지 확인하는 것이 중요합니다. 그런 다음 더 많은 팀을 온보딩할 때 내부 개발자 플랫폼을 확장할 준비를 해야 합니다.

선택 사항으로 사용 설정 및 특정 기능 사용 활성화

모든 팀이 첫날에 내부 개발자 플랫폼을 사용할 수 있는 것은 아닙니다. 예를 들어, 일부 팀은 컨테이너를 사용하여 워크로드를 현대화하고 다른 팀은 서버리스 솔루션을 사용합니다. 내부 개발자 플랫폼은 하나의 여정을 지원하는 것으로 시작되며 시간이 지남에 따라 더 많은 기능이 개발됩니다. 플랫폼이 확장되고 보다 성숙한 패턴이 개발자에게 제공할 준비가 될 때까지 플랫폼과 기능을 선택적으로 사용합니다.

그렇다고 해서 팀이 내부 개발자 플랫폼을 사용할 수 없다는 의미는 아닙니다. 일부 팀은 여전히 도구와 프로세스를 관리하고 내부 개발자 플랫폼의 특정 기능을 채택할 수 있습니다. 예를 들어 팀은 CI/CD 파이프라인을 채택하여 인프라를 준비할 수 있습니다. 플랫폼은 인프라 관리에 걸리는 시간을 줄여 가치를 제공하며, 이를 통해 개발자는 애플리케이션 코드에 집중할 수 있습니다.

보안 표준에 맞는 골든 경로 정의

골든 경로는 내부 개발자 플랫폼이 제공해야 하는 가장 기본적인 기능입니다. 이는 골든 경로에 개발자가 몇 분 안에 시작하는 데 도움이 되는 모범 사례와 표준이 포함되어 있기 때문입니다. 골든 경로는 개발부터 관찰성까지 소프트웨어 개발 수명 주기(SDLC) 환경을 간소화합니다. 소스 코드 리포지토리, 테스트, 배포 및 관찰성과 같이 개발자가 사용하는 대부분의 기능을 자동화합니다.

그러나 골든 경로는 자동화된 패턴을 제공하는 것뿐만 아니라 또한 개발자가 조직 규정 준수 요구 사항을 준수하는 안전한 방식으로 워크로드를 배포하는 데 도움이 되는 거버넌스를 제공합니다. 개발자의 주요 과제 중 하나는 개발 수명 주기 초기에 보안을 해결하는 것입니다. 따라서 보안 스캔 및 policy-as-code 도구를 골든 경로의 단계로 포함시켜이 문제를 제거하는 것이 중요합니다. 이를 통해 개발자에게 초기 피드백을 제공하고 배포를 위한 거버넌스 프레임워크를 제공할 수 있습니다.

골든 경로를 설계할 때 프로세스를 불필요하게 어렵게 만들지 마세요. 목표는 SDLC의 모든 단계를 처음부터 자동화하는 것이 아닙니다. 목표는 다양한 도구 또는 인프라를 사용하는 모든 복잡성을 숨길 수 있는 추상화 계층을 제공하는 것입니다. 이를 통해 개발자는 기본 서비스와 상호 작용하는 대신 빠르게 시작하고 기능 개발에 집중할 수 있습니다. 골든 경로의 예로는 개발자가 소스 코드 리포지토리를 가리키는 몇 가지 파라미터를 제공할 수 있는 템플릿이 있습니다. 내부 개발자 플랫폼은 테스트, 보안, 스캔 및 배포와 같은 다른 모든 단계를 자동화합니다.

온보딩 경험 문서화 및 간소화

내부 개발자 플랫폼의 또 다른 중요한 성공 원칙은 설명서입니다. 내부 개발자 플랫폼에는 개발자에게 easy-to-follow 온보딩 가이드를 제공하는 문서가 포함되어야 합니다. 이 가이드는 개발자가 프로젝트에 기여할 수 있는 방법에 초점을 맞추고 인터페이스 또는 플랫폼의 숨겨진 복잡성을 설명하지 않아야 합니다. 예를 들어 온보딩 가이드는 플랫폼이 Amazon EKS에서 실행되고 있음을 설명하거나 AWS 계정 가 기준 설정되는 방법을 설명해서는 안 됩니다. 이 가이드에서는 서비스 종속성과 골든 경로를 설명해야 합니다. 마이크로서비스 아키텍처의 경우 서비스가 연결되는 방법을 설명할 수도 있습니다.

설명서와 간단한 온보딩 환경은 개발자가 내부 개발자 플랫폼을 이해하고 사용해야 하는 시간을 최소화합니다. 설명서의 효과를 측정하려면 코드 변경 볼륨 지표가 유용할 수 있습니다. 이 지표는 코드 변경 횟수가 가장 많은 사람과 시간 경과에 따라 가장 활성이 높은 리포지토리에 대한 데이터를 제공할 수 있습니다. 개발자 또는 리포지토리 수준에서 데이터를 수집할 수 있습니다.