플랫폼 엔지니어링이란?
플랫폼 엔지니어링은 보안, 관리되는 프레임워크 내에서 향상된 개발자 환경 및 셀프 서비스를 통해 각 개발 팀의 보안, 규정 준수, 비용 및 비즈니스 간 가치를 개선하려는 DevOps 원칙에서 구축된 사례입니다. 제품 기반 사고방식 전환과 이를 지원하는 도구 및 시스템 집합입니다.
요즘에는 플랫폼 엔지니어링이라는 용어에 대한 업계의 많은 기대가 있습니다. Gartner는 엔지니어링 조직의 약 80%가 2026년까지 플랫폼 엔지니어링 전용 팀을 가질 것으로 예상합니다. 이러한 팀은 내부 개발자 플랫폼이라는 것을 빌드하는 데 집중합니다. 도메인 – 판매(Microsoft Dynamics, Salesforce), 서비스 처리(ServiceNow), 통신(Twilio) - 플랫폼은 고유한 특성에 따라 규모를 달성하고 비즈니스 가치를 제공하는 데 걸리는 시간을 줄이도록 설계되었습니다.
개발자가 사용하거나 확장하는 플랫폼은 고도로 최적화된 개발자 환경과 간소화된 작업으로 개발 프로세스 전체에서 수고를 제거할 수 있습니다. 이러한 플랫폼에는 다음과 같은 도구가 포함됩니다.
- 개발자가 자급자족할 수 있도록 지원(예: 시작 키트, IDE 플러그 인)
- 일반적인 작업 지원
- 일반적인 패턴 및 사례를 재사용 가능한 구성 요소로 캡슐화
- 문제 또는 보안 위험에 대한 조기 조언 및 피드백 제공
- 기본 인프라 및 도구를 관리하여 작업 간소화
Microsoft의 플랫폼 엔지니어링 기능 모델은 투자, 채택, 거버넌스, 프로비저닝 및 관리, 인터페이스, 측정 및 피드백 등 플랫폼 엔지니어링을 정의하는 6가지 핵심 기능을 설명합니다. 현재 각 기능 영역에서 조직이 어디에 속하는지 파악하고 향후 성장을 위한 목표를 설정하려면 플랫폼 엔지니어링 기능 모델 정보(About the Platform Engineering Capabilities Model)를 참조하세요.
내부 개발자 플랫폼이란?
내부 개발자 플랫폼은 회사의 내부 개발 관행에 중점을 둡니다. 프로덕션에 권장되고 지원되는 개발 경로 집합을 정의하고 내부 플랫폼을 통해 증분 방식으로 "포장"합니다.
실제 비유를 사용하기 위해 새로운 경로는 종종 흙 길로 시작하지만, 더 많은 사람들이 이를 사용함에 따라 속도와 처리량을 유지하면서 안전을 개선하기 위해 포장됩니다. 내부 개발자 플랫폼 내의 포장된 경로는 비슷한 목표를 가지고 있습니다. 개발자 배달 속도를 희생하지 않고 중요한 요구 사항 및 표준을 통해 개발자를 안내하도록 설계되었습니다. 이를 위해 개발 팀은 표준화되고 안전하며 확장 가능한 셀프 서비스 기능을 제공합니다. 동시에 운영 및 IT 조직에서 기본 인프라와 도구가 효율적이고 규정을 준수하며 비용 효율적인지 쉽게 확인할 수 있습니다. 일부 경로는 부분적으로 포장될 수 있지만 완전히 포장된 골든 경로는 관련된 모든 사람의 인지 부하를 줄입니다.
개발자는 내부 개발자 플랫폼의 기본 소비자 또는 고객입니다. 자동화 및 중앙 집중화는 효율적인 작업을 가능하게 하면서 규정 준수와 같은 관련자 요구 사항을 충족하도록 보장합니다.
플랫폼 엔지니어링을 사용하면 제품 사고방식을 DevOps 및 DevSecOps의 학습과 결합하여 일련의 도구를 제공하여 이 내부 플랫폼을 만듭니다. 이러한 도구는 개발 팀을 자연스럽게 "성공의 구덩이"로 안내하는 충분한 자동화, 추적, 거버넌스 및 가시성을 제공합니다. 다국적 매스미디어 회사의 플랫폼 엔지니어링 리더로서 다음을 수행합니다.
제품 제공 속도 또는 속도를 높이기 위해 플랫폼 엔지니어링이 채택되었습니다. 중앙 집중식 팀은 각 팀이 인프라에 대해 걱정할 필요가 없으므로 효율성이 향상됩니다. 또한 모든 것이 미리 정의되어 있으므로 안전과 보안을 강화하여 오류를 줄입니다. - Daniel, Cloud Engineer, Fortune 500 Media Company
내부 개발자 플랫폼을 사용하면 인지 부하 및 수동 단계를 줄이거나 제거하여 개발 및 운영 수명 주기 전체에 걸쳐 전문 지식을 중앙 집중화하고 확장할 수 있습니다.
셀프 서비스 및 자동화에 중점을 두고 증분 방식으로 개발자 플랫폼 빌드
성공적인 플랫폼 엔지니어링 전략을 구현하는 데는 작업이 필요하지만 보수는 가치가 있습니다. 개인이 20명 미만인 팀이 수천 명의 개발자와 수백 개의 프로젝트를 지원할 수 있는 것은 드문 일이 아닙니다.
그러나 내부 개발자 플랫폼을 만드는 것은 여정입니다. 빅뱅 접근 방식이나 하향식 기반의 노력은 권장하지 않습니다. 플랫폼 엔지니어링의 중요한 측면은 개발자, 기계 학습 전문가 또는 데이터 과학자를 고객으로 취급하는 제품 사고 방식을 적용하는 것입니다. 기술 회사의 한 플랫폼 엔지니어는 다음과 같이 설명합니다.
[우리의] 플랫폼 엔지니어링 도구가 해결하도록 설계된 두 가지 주요 문제가 있습니다. 첫 번째는 셀프 서비스 모델을 사용하여 서비스 프로비저닝을 용이하게 하는 것이었습니다. … 두 번째는 성능 메트릭 및 애플리케이션 가용성과 같은 자동 지원 시스템을 제공하는 것이었습니다. 목표는 개발자가 애플리케이션 문제를 해결하고 최적화하는 데 필요한 모든 정보를 보유하면서 더 빠르고 효율적으로 작업할 수 있도록 하는 것이었습니다. - Alex, 수석 클라우드 설계자, 대규모 기술 회사
두 회사가 동일하지 않으므로 이 여정을 통해 증분 과정을 계획하기 위해 내부 고객의 특정 요구 사항을 고려하세요. 시간이 지남에 따라 어셈블할 핵심 구성 요소 집합을 설정하여 내부 개발자 플랫폼이 개발 팀이 옹호자가 되고 그 과정에서 사용할 수 있는 충분한 가치를 확보할 수 있습니다. 이 정보를 사용하여 플랫폼에 대해 실행 가능한 최소 제품인 가장 얇은 실행 가능한 플랫폼을 만들고 여기에서 확장할 수 있습니다.
중요한 점은 이러한 영역에서 어떤 투자를 하든 플랫폼 엔지니어링 과정의 핵심 구성 요소로 생각하고 싶다는 것입니다. 그런 다음 처음부터 모든 것을 구축하는 대신 사용자 지정 투자로 응집력 있는 접착제를 만들어 비즈니스에 고유한 가치를 추가하는 데 집중할 수 있습니다.