플랫폼 구현의 핵심 측면
플랫폼 엔지니어링은 소프트웨어 엔지니어링과 시스템 디자인, 그리고 운영 우수성을 결합하여 애플리케이션을 빌드하고 배포하는 안정적이고 확장성 있는 인프라를 만드는 통합적인 접근 방식입니다. 플랫폼 엔지니어링의 핵심은 강력한 플랫폼을 구축하는 것뿐만 아니라 비즈니스 목표에 부합하면서도 개발 팀의 역량을 강화하는 셀프 서비스 환경을 만드는 것입니다. 성공적인 플랫폼 엔지니어링 이니셔티브는 올바른 팀과 문제 영역에 대한 명확한 이해에서 시작합니다. 이러한 이해를 바탕으로 운영을 간소화하고, 마찰을 줄이고, 개발자가 인프라 관리보다는 애플리케이션 빌드에 집중하게 하는 시스템을 개발할 수 있습니다.
팀이 준비된 후에는 노동 집약적 영역을 자동화하는 데 초점이 옮겨지고, 자동화를 통해 시간을 절약하고 오류를 줄일 수 있는 반복적인 수동 작업을 식별합니다. 그런 다음에는 기존 자원의 인벤토리가 필요하며, 이로써 팀은 도구와 서비스를 중앙에서 더 쉽게 관리하고 확장할 수 있게 됩니다. 다음 단계는 포장 도로 내기라고도 부르며, 여기에는 프로젝트 전반의 일관성을 보장하는 표준 워크플로와 환경을 만드는 작업이 포함됩니다. 이후, 환경을 서비스로 배포하면 프로세스를 더욱 간소화하고 팀은 요구에 따른 환경을 신속하게 시작할 수 있습니다. 이 시점에서 기본 목표는 셀프 서비스 개발자 환경을 최적화하고, 개발자가 워크플로를 독립적으로 관리할 수 있게 하는 동시에 성공에 필요한 도구와 지원을 얻도록 하는 것입니다. 이러한 접근 방식은 개발 팀이 인프라와 상호 작용하는 방식을 변화시켜 애플리케이션을 빌드하고 제공하기 위한 민첩하고 성능이 뛰어난 환경을 만듭니다.
구현 계획을 명확하게 정의하여 세우는 것 외에도, 플랫폼 엔지니어링을 광범위한 하나의 개념으로 접근하기보다는 4가지 주요 영역으로 분류하는 것이 구현 과정을 쉽게 하는 데 도움이 될 수 있습니다.
- 엔지니어링 시스템에는 CI/CD, 패키지 관리, 클라우드 기반 코딩 환경, 코드 스캐너 및 린터와 같은, 개발을 가능하게 하는 도구 및 서비스뿐만 아니라 GitHub Copilot과 같은 AI(인공 지능) 도우미도 포함됩니다.
- Application Platform은 일반적으로 사용되는 앱 스택(예: Azure Policy, Azure Key Vault, Azure Container Apps 또는 Cosmos DB)의 빌딩 블록으로 사용되는 큐레이팅된 서비스로 구성됩니다.
- 애플리케이션 템플릿은 워크로드 프로비전을 용이하게 하고 모범 사례에 맞게 조정할 수 있는 잘 정의된 조직별 템플릿을 제공합니다.
- 개발자 셀프 서비스 기능은 개발자가 조직 표준을 준수하고 거버넌스를 보장하면서 워크플로를 자율적으로 관리할 수 있도록 지원합니다.
이러한 영역을 구현 전략에 통합하면 개발자의 수고를 줄이고, 혁신을 촉진하고, 원활한 개발 환경을 만들 수 있습니다.
팀 구축
플랫폼 엔지니어링 조직에서 올바른 문화를 조성하는 것은 장기적인 성공을 위한 필수 조건입니다. 수동적 문화를 능동적 문화로 전환하는 것이 핵심으로, 이를 통해 플랫폼 팀이 조직을 지원하는 도구를 구축하고 유지 관리하는 책임을 맡아야 합니다. 이러한 변화는 지식 사일로와 운영 중단을 줄이는 데 매우 중요합니다. 플랫폼 엔지니어링 노력의 성공은 플랫폼 엔지니어링 역량 모델에서 설명하는 투자 역량과 일치하며, 이 모델에서는 임시 단계부터 최적화 단계까지 이르는 조직 완성 단계를 거치는 것을 강조합니다. 임시 단계에서는 기업이 플랫폼 엔지니어링의 필요성을 인식하지만, 리더십과 개발 팀 간의 완전한 일치가 부족할 수 있습니다. 조직이 성숙해짐에 따라 경영진의 지지와 문화적 변화는 플랫폼 팀이 의미 있는 변화를 주도할 수 있는 협력적이고 혁신적인 환경을 장려하여 조직이 효과적으로 확장할 수 있게 합니다.
플랫폼 엔지니어링 팀에는 안정적이고 효율적이며 안전한 내부 개발자 플랫폼을 구축하고 확장하기 위한 다양한 기술과 제품 중심 사고방식이 필요합니다. 플랫폼 엔지니어는 컨테이너 오케스트레이션(예: Kubernetes), CI/CD 파이프라인(예: GitHub Actions, Azure Pipelines), 모니터링 도구(예: Azure Monitor, Prometheus, Grafana)를 비롯한 여러 주요 영역에 능숙해야 합니다. Terraform 및 Bicep과 같은 IaC(코드형 인프라) 도구에 대한 전문 지식은 인프라 프로비전 자동화에 매우 중요합니다. 또한 플랫폼 엔지니어는 시스템 전반에서의 자동화 및 통합을 위해 Python, PowerShell 또는 Bash와 같은 스크립팅 언어로 코드를 능숙하게 작성할 수 있어야 합니다. 플랫폼 엔지니어를 위한 인재 풀을 확보하기는 쉽지 않을 수 있지만, 좋은 팀을 구성하려면 소프트웨어 개발, SRE(사이트 안정성 엔지니어링), IT 운영과 같은 다양한 배경의 전문 지식을 결합해야 합니다.
노동 집약적 영역 자동화
노동 집약적 영역을 자동화하는 것은 일반적으로 개발자의 셀프 서비스 역량을 지원하는 첫 번째 포장 도로를 나타냅니다. 이를 구현하기 위해서는 먼저 자주 수행하거나 오류가 발생하기 쉽거나 노동 집약적인 프로세스, 특히 수동 작업이나 서비스 데스크 작업과 관련된 프로세스를 식별합니다. 다음으로 프로세스 빈도, 복잡성, 감사 가능성과 같은 요소를 평가하여 자동화 대상의 순위를 지정합니다. CD(지속적인 업데이트) 파이프라인에서 IaC(코드형 인프라)를 구현하면 애플리케이션 배포를 간소화할 뿐만 아니라 공유 인프라와 도구의 동적 프로비전도 가능해집니다. GitHub Actions, Azure DevOps와 같은 유연한 CI/CD 플랫폼 또는 Flux, Argo CD와 같은 GitOps 솔루션을 사용하여 병목 상태를 줄이고 팀 역량을 강화합니다.
시간이 지남에 따라 "EaC(모든 것을 코드로)" 패턴을 채택하면 IaC 템플릿 및 구성(예를 들면 Bicep 및 Azure Resource Manager 템플릿, Terraform 매니페스트 파일, Helm 차트 포함)에 중앙 집중식 Git 리포지토리를 사용하여 안전하고 반복 가능한 자동화 프레임워크가 만들어집니다. 이러한 리포지토리는 운영 팀에서 관리하며, 개발자는 병합하기 전에 안전하게 검토되고 감사되는 풀 요청을 제출할 수 있습니다. 그러면 동일한 CI/CD 도구가 애플리케이션별이든 공유이든 모든 인프라, 도구 또는 서비스를 프로비전하고 구성할 수 있습니다. 이러한 접근 방식은 확장성, 개발자 셀프 서비스, 거버넌스 프로세스와의 원활한 통합을 지원하여 플랫폼 엔지니어링이 조직의 목표에 부합하고 운영 민첩성을 높이도록 합니다.
"모든 것을 코드로" 접근 방식은 거의 모든 리소스나 프로세스를 보안 Git 리포지토리의 파일로 나타내는 데 중점을 둡니다. 커밋 기록, 액세스 제어, 풀 요청, 분기 보호와 같은 Git의 강력한 보안 기능은 투명성을 보장하고, 협업 검토를 가능하게 하며, 변경 내용을 통합하기 전에 자동화된 검사를 강제할 수 있습니다. 이러한 기능은 CI/CD 시스템과 결합하여 인프라, 도구, 프로세스를 관리하기 위한, 다재다능하고 감사 가능하고 안전한 프레임워크를 만듭니다.
인벤토리 및 중앙 집중화
조직이 성장함에 따라 기술 자산이 증가하고 더 복잡해지면서 작업이 중복되고, 프로젝트가 버려지고, 자원이 낭비되는 결과가 종종 발생하게 됩니다. 인벤토리 및 자산 추적을 중앙 집중화하는 작업은 이러한 문제를 해결하기 위한 플랫폼 엔지니어링의 중요한 단계입니다. 인벤토리 시스템은 팀이 코드, API, 컨테이너, VM(가상 머신), 사용 권한 등과 같은 자산을 추적하고 관리할 수 있도록 합니다. 이 프로세스는 거버넌스를 향상할 뿐만 아니라 재사용을 촉진하고 검색 가능성을 높여 팀이 더 효율적이고 효과적으로 운영할 수 있게 합니다.
중앙 집중식 인벤토리는 자산에 태그를 지정, 정리하여 거버넌스를 개선하는 데 중요한 역할을 합니다. 적절하게 태그를 지정하면 리소스가 해당 소유자나 팀과 연결되므로 수명 주기를 관리하고 변경이 미칠 잠재적 영향을 이해하기가 더 쉬워집니다. 검색 가능성 향상은 또 다른 주요 이점으로, 팀이 기존 자원을 찾고 재사용하는 데 도움을 줘서 불필요한 중복 작업을 방지하고 기술의 비효율적 분산을 줄여줍니다. 또한 인벤토리를 중앙 집중화하면 조직이 오래되거나 불필요한 자산을 식별하고 정리하여 자원을 최적화함으로써 낭비를 줄이고 비용을 절감할 수 있습니다.
다양한 도구는 인벤토리 및 자산 추적을 지원하며, 각 도구는 기술 에코시스템의 다양한 측면을 충족합니다. 예를 들어 ADE(Azure Deployment Environments)는 IaC(코드형 인프라)를 통해 생성된 복잡한 인프라를 추적하는 방법을 제공합니다. 마찬가지로, Azure API 센터를 사용하면 개발자가 API를 효율적으로 검색하고 관리할 수 있습니다. GitHub 패키지 또는 Azure Artifacts와 같은 패키지 레지스트리는 공급망 보안을 개선하고 승인된 패키지 및 SDK를 관리하여 추가적인 가치를 제공합니다.
인벤토리 시스템의 이점을 더욱 향상하기 위해 조직은 자산 간에 관계형 연결을 설정하여 에코시스템에 대한 더 포괄적인 관점을 제공할 수 있습니다. 예를 들어 API 정의, 해당 코드 리포지토리, 연결된 환경 및 거버넌스 정책 간의 관계를 매핑하면 팀이 더 높은 정확도로 자원을 관리할 수 있습니다.
포장 도로 내기
플랫폼 엔지니어링에서 사용하는 "포장 도로"라는 비유는 혁신 촉진과 표준화된 지침 제공 사이의 균형이라는 의미를 전달합니다. 처음에는 팀이 목표를 달성하기 위해 여러 비공식적인 경로를 통해 다양한 도구와 워크플로를 실험할 수 있습니다. 시간이 지남에 따라 플랫폼 팀은 가장 효과적이고 널리 채택되는 접근 방식을 관찰하여 이를 "포장 도로", 즉 팀이 채택할 수 있는 효율적이고 사용자 친화적이고 매력적인 최적화된 워크플로로 변환합니다.
종종 "포장 도로 내기"라고 말하는 이 과정에는 팀 워크플로의 일반적인 패턴을 식별하고 이를 확장성 있는 표준화된 솔루션으로 변환하는 작업이 포함됩니다. 이러한 도로는 보안, 아키텍처 모범 사례, 규정 준수 요구 사항을 완벽하게 통합하여 원활하고 안정적인 환경을 제공합니다. 개발자는 인지 부하 감소, 통합을 위한 일관된 API, 필요에 따라 결합할 수 있는 모듈식 기능, 운영 목표에 부합하는 예측 가능한 성능을 활용할 수 있습니다.
플랫폼 엔지니어링 역량 모델은 이 과정에서 중요한 역할을 하며 조직에서 비공식적인 경로에서 포장된 도로로 전환할 시기를 결정할 수 있도록 돕습니다. 이 모델은 표준화가 필요한 영역을 식별하고 이러한 작업을 효과적으로 확장하는 방법에 대한 통찰력을 제공합니다. 이러한 구조화된 접근 방식은 품질, 규정 준수, 성능에 중점을 두면서도 혁신이 제한되지 않도록 보장합니다.
포장 도로 내기 접근 방식은 모범 사례를 장려하되 과도하게 지시하지 않습니다. 이 방식은 커뮤니티 기여를 지원하여 팀이 협력을 통해 플랫폼을 개발하면서도 고유한 사용 사례에 대한 유연성을 유지할 수 있도록 합니다. 이 방법론은 혁신과 표준화의 균형을 맞추어 팀이 조직의 요구 사항을 일관되게 충족하는 동시에 탁월함을 발휘할 수 있는 환경을 조성합니다.
환경을 서비스로 배포
환경을 서비스로 배포하는 방식은 인프라에 안전하고 표준화되고 자동화된 프로비전을 구현하기 위한 것입니다. 이 접근 방식의 핵심 원칙은 프로비전 ID와 비밀을 개발자가 직접 액세스하지 못하게 하는 방식으로 유지하는 것입니다. 이렇게 하면 인프라 업데이트가 안전하게 유지되면서 거버넌스가 적용됩니다. 예를 들어 ADE(Azure Deployment Environments)는 역할 분리를 지원하고 IaC 템플릿 관리를 중앙 집중화하여 이 모델의 좋은 예가 됩니다.
플랫폼 엔지니어 및 운영 팀은 ADE를 통해 협업하여 특정 환경 유형에 대한 템플릿 카탈로그를 만들고 유지 관리합니다. 사전 구성된 설정으로 보강된 이러한 템플릿은 관리 ID를 통합하고 역할에 따라 액세스를 제어합니다. 그런 다음 개발자는 중요한 자격 증명 또는 기본 구독에 직접 액세스할 필요 없이 이 CI/CD 파이프라인을 사용하여 Azure CLI 또는 Azure 개발자 CLI와 같은 도구를 통해 인프라를 프로비전할 수 있습니다. 이러한 분리는 개발자 생산성을 유지는 동시에 규정 준수와 보안을 보장합니다.
ADE를 사용하지 않더라도, IaC(코드형 인프라) 콘텐츠가 안전하고 변경 불가능한 위치에서 제공되고 비밀 관리가 자동화하고 격리된다면 동일한 원칙을 더 넓은 범위에 적용할 수 있습니다. 이러한 방식을 가능하게 함으로써 플랫폼 엔지니어링은 팀이 일관된 환경을 배포하는 동시에 조직의 거버넌스와 운영 효율성을 유지할 수 있도록 지원합니다.
셀프 서비스 개발자 환경 최적화
완벽한 셀프 서비스 개발자 환경은 플랫폼 엔지니어링 성공에 매우 중요하지만, 이를 성취하기 위해 때로는 사용자가 활동하는 장소로 가서 그들을 만나야 합니다. 개발자, 운영 등의 모든 역할은 자신들의 워크플로를 정의하는 특정 도구와 환경을 선호합니다. 새로운 경험이 채택되기 위해서는 이러한 기존의 “선호도”를 맞추는 것이 중요합니다. 실용적인 접근 방식은 이미 사용 중인 도구에 맞게 조정된 여러 사용자 인터페이스를 계획함으로써 팀이 간단한 개선부터 시작하고, 그 가치를 증명하고, 필요에 따라 더 정교한 솔루션으로 발전시킬 수 있도록 하는 것입니다.
완전히 새로운 환경을 만들기보다는 기존 도구를 개선하고 통합하는 것이 좋습니다. 편집기, IDE(통합 개발 환경), DevOps 제품군, CLI 도구 및 하위 코드 환경과 같은 플랫폼에는 오버헤드를 최소화하면서 사용자 지정 및 확장을 허용하는 확장성 모델이 있는 경우가 종종 있습니다. 이러한 접근 방식은 유지 관리를 줄이고, 친숙한 사용자 환경을 적용하고, 채택을 가속화합니다. 예를 들어 웹 기반 IDE 확장은 VS Code 또는 vscode.dev를 위해 구축된 확장처럼 로컬 개발 환경으로 확장할 수 있는 유연한 웹 호환 시작 지점을 제공합니다. 마찬가지로 Microsoft Teams 또는 Slack과 같은 도구에서 ChatOps 인터페이스는 자동화 워크플로를 트리거하고 CI/CD 플랫폼과 통합하는 직관적인 방법을 제공합니다.
중앙 집중식 인터페이스가 필요한 조직의 경우 사용자 지정 개발자 포털에 투자하는 것이 장기적인 이점을 제공할 수 있지만 신중한 계획과 자원이 필요합니다. Spotify에서 처음 개발한 도구 키트인 Backstage.io와 같은 솔루션은 플러그 인과 타사 도구를 통합하여 동적인 개발자 중심 허브를 만들 수 있는 고도로 사용자 지정이 가능한 포털을 제공합니다. Power Pages와 같은 간단한 솔루션으로 시작하든 포괄적인 포털을 구축하든 관계없이, 목표는 조직의 요구에 부합하면서 사용자의 역량을 강화하는 확장성 있고 사용자에게 친숙한 환경을 제공하는 것입니다.