Azure에서 내부 개발자 플랫폼 설계하기: 기반 구축

By Mirko Peters · 2026-08-13

팟캐스트 동반 블로그에 다시 오신 것을 환영합니다! 오늘의 심층 분석에서는 업계 전반의 아키텍처 논의를 뜨겁게 달구고 있는 주제, 즉 내부 개발자 플랫폼(IDP)을 더 깊이 다룹니다. 최근 에피소드를 들으셨다면, 인지 부하가 개발자의 생산성을 조용히 떨어뜨리고 있다는 이야기를 나눴던 것을 기억하실 겁니다. 오늘은 한 걸음 더 나아가, 최신 클라우드 패러다임, 컨테이너화 전략, 인프라 as 코드 원칙을 활용해 Microsoft Azure에서 견고하고 확장 가능하며 안전한 IDP를 구축하는 방법을 살펴보겠습니다.

Automatically translated with AI from the original post. Read the English original

Titelbild: Architecting Internal Developer Platforms on Azure: Building the Foundation

현대 기업의 엔지니어링 조직은 역설에 직면해 있습니다. 클라우드를 통해 개발자에게 전례 없는 힘을 주었지만, 동시에 운영 복잡성에 파묻히게 만들었습니다. 개발자들은 비즈니스 로직을 작성하는 시간보다 네트워크 토폴로지, ID 및 액세스 관리 구성, 배포 파이프라인과 씨름하는 데 더 많은 시간을 쓰고 있습니다. 내부 개발자 플랫폼(IDP)은 큐레이션된 추상화 계층 역할을 하여 이 문제를 해결합니다. 개발자를 제약하는 것이 아니라, 프로덕션까지 빠르고 안전하게 이어지는 골든 패스(golden path)를 제공해 힘을 실어 줍니다. 그럼 Azure에서 이 기반을 어떻게 설계할지 살펴보겠습니다.

Azure에서의 내부 개발자 플랫폼 소개

Azure 서비스의 기술적 세부 사항에 들어가기 전에, IDP가 정확히 무엇인지, 그리고 Azure가 이를 호스팅하기에 왜 독보적인 위치에 있는지 짚고 넘어가겠습니다. IDP는 기성품으로 구매하는 단일 소프트웨어가 아닙니다. 내부 도구, 서비스, 인프라 워크플로를 하나의 일관된 개발자 포털로 조합하여 제품화한 집합체입니다. 개발자와 기반 클라우드 인프라 사이에 위치하며, 상위 수준의 개발자 의도를 보안이 적용되고 규정을 준수하며 프로덕션에 바로 사용할 수 있는 클라우드 리소스로 변환합니다.

Azure는 엔터프라이즈급 기본 요소(primitives)의 방대한 생태계를 제공합니다. 그러나 이러한 원시 기본 요소를 개발자에게 그대로 노출하면 구성 드리프트, 보안 취약점, 고아 리소스가 생기기 쉽습니다. Azure에 IDP를 설계하면 플랫폼 엔지니어는 이러한 네이티브 서비스를 의견이 반영된 표준화된 템플릿으로 감쌀 수 있습니다. 즉, 개발자는 Azure 네트워킹이나 역할 기반 액세스 제어(RBAC)에 대한 전문 지식 없이도, 데이터베이스와 캐싱 계층이 연결된 완전히 구성된 마이크로서비스 환경을 요청할 수 있습니다.

현대적 IDP의 핵심 기둥

플랫폼을 설계할 때는 셀프 서비스, 골든 패스, 추상화, 가드레일이라는 네 가지 핵심 기둥을 기준으로 결정을 내려야 합니다. 이것이 없으면 IDP는 또 하나의 티켓 시스템이나 문서화되지 않은 위키 페이지로 전락할 위험이 있습니다.

운영 부담 없는 셀프 서비스

셀프 서비스는 모든 IDP의 핵심입니다. 전통적인 환경에서는 개발자가 새 스테이징 환경이나 Cosmos DB 인스턴스가 필요하면 Jira 티켓을 발행하고, 플랫폼 팀의 검토를 기다리고, 운영 팀의 프로비저닝을 기다린 뒤, 구성이 프로덕션과 일치하기를 바라야 합니다. Azure의 IDP는 이 전체 수명 주기를 자동화합니다. 중앙 포털을 통해 개발자는 셀프 서비스 워크플로를 실행하여 몇 분 안에 리소스를 프로비저닝할 수 있으며, 변경 사항의 리드 타임을 크게 줄일 수 있습니다.

골든 패스와 추상화 계층

골든 패스는 조직 내에서 일을 처리하는 방식으로, 의견이 반영되고 공식적으로 지원되는 경로입니다. 유연성을 없애는 것이 아니라 마찰을 없앱니다. 애플리케이션 매니페스트 하나 같은 간단한 구성 파일 뒤에 Azure의 복잡성을 추상화하면, 개발자는 무엇을 배포할지 선언하기만 하면 되고, Azure에 어떻게 배포될지는 IDP가 처리합니다.

네이티브 인프라를 위한 Azure 서비스 활용

Azure에서 IDP를 구축하려면 컴퓨팅, 스토리지, 네트워킹, ID를 처리할 적절한 기반 서비스를 선택해야 합니다. 플랫폼 요구 사항을 Azure 네이티브 서비스에 어떻게 매핑할 수 있는지 살펴보겠습니다.

Microsoft Entra ID를 활용한 ID 및 액세스 관리

보안은 ID에서 시작됩니다. Microsoft Entra ID(이전 명칭: Azure Active Directory)는 IDP의 보안 기반 역할을 합니다. 플랫폼 포털을 Entra ID와 통합하면 SSO(Single Sign-On)를 적용하고, 개발자 그룹을 특定 플랫폼 기능에 매핑할 수 있습니다. Azure Managed Identities를 사용하면 배포된 애플리케이션이 구성 파일이나 리포지토리에 자격 증명을 하드코딩하지 않고도 Azure Key Vault나 Azure SQL 같은 다른 Azure 리소스에 안전하게 액세스할 수 있습니다.

데이터 및 스토리지 추상화

애플리케이션에는 데이터가 필요하지만, 플랫폼 팀이 팀이 새 프로젝트를 시작할 때마다 데이터베이스를 수동으로 생성할 필요는 없어야 합니다. Azure Service Operator for Kubernetes 또는 셀프 서비스 워크플로로 감싼 Azure Resource Manager(ARM) 템플릿을 사용하면 Azure Database for PostgreSQL, Azure Cosmos DB, Azure Cache for Redis 같은 관리형 서비스를 필요할 때 프로비저닝할 수 있습니다. IDP는 이러한 데이터베이스가 저장 데이터 암호화, 적절한 방화벽 규칙, 기본적으로 활성화된 자동 백업을 갖춘 상태로 프로비저닝되도록 보장합니다.

컨테이너화 및 오케스트레이션 전략

컨테이너는 최신 클라우드 네이티브 애플리케이션의 공용어와 같습니다. 애플리케이션을 패키징하고 실행하는 방식을 표준화하는 것은 성공적인 IDP를 구축하는 데 필수적입니다.

컴퓨팅 엔진으로서의 Azure Kubernetes Service

대부분의 최신 엔터프라이즈에서 Azure Kubernetes Service(AKS)는 IDP의 기본 컴퓨팅 엔진 역할을 합니다. AKS는 대규모로 마이크로서비스를 실행하는 데 필요한 확장성, 이식성, 오케스트레이션 기능을 제공합니다. 그렇더라도 개발자가 원시 Kubernetes YAML 매니페스트를 직접 작성해야 해서는 안 됩니다. IDP는 Ingress 컨트롤러, 네트워크 정책, 영구 볼륨 클레임의 복잡성을 높은 수준의 워크로드 추상화 뒤에 숨겨야 합니다.

컨테이너 레지스트리 및 공급망 보안

Azure Container Registry(ACR)는 AKS와 매끄럽게 통합되며 컨테이너 전략의 핵심 요소를 이룹니다. IDP는 코드 커밋부터 컨테이너 이미지 빌드까지의 파이프라인을 자동화해야 하며, Microsoft Defender for Containers 같은 도구를 활용해 클러스터에 배포되기 전에 이미지의 취약점을 검사해야 합니다. ACR을 플랫폼 워크플로에 포함하면 신뢰할 수 있고 검사를 마친 이미지만 프로덕션 환경에 배포되도록 보장할 수 있습니다.

플랫폼 엔지니어링을 위한 Infrastructure-as-Code 원칙

IDP를 구축할 때 Infrastructure-as-Code(IaC)는 선택 사항이 아닙니다. 플랫폼이 관리하는 모든 인프라는 정의되고, 버전 관리되며, 자동화된 파이프라인을 통해 배포되어야 합니다.

Azure 생태계에서 IaC 도구 선택하기

Azure는 매우 다양한 IaC 도구를 지원합니다. Bicep은 Azure 리소스를 선언적으로 배포하기 위한 Microsoft의 도메인 전용 언어로, 기존 ARM 템플릿보다 간결한 구문과 Azure 기능에 대한 기본 지원을 제공합니다. 또는 Terraform(또는 OpenTofu)은 멀티 클라우드 및 엔터프라이즈 환경에서 널리 채택되고 있습니다. 어떤 도구를 선택하든, IDP는 프로비저닝 요청이 승인되면 이러한 스크립트를 개발자에게서 숨기고 백그라운드에서 실행해야 합니다.

상태 관리 및 모듈형 설계

플랫폼을 유지보수하기 쉽게 하려면 재사용 가능한 인프라 모듈 라이브러리를 구축하십시오. 예를 들어 App Service 또는 AKS 배포에 연결된 데이터베이스와 모니터링 인스턴스를 묶은 표준 "web-api-module"을 만들 수 있습니다. IaC 상태는 blob 버전 관리가 활성화된 Azure Storage 계정에 안전하게 저장하여, 플랫폼 엔지니어링 팀이 모든 구독에 걸친 인프라 변경 사항에 대한 신뢰할 수 있는 감사 추적을 유지하도록 하십시오.

보안 가드레일 및 규정 준수 적용

셀프 서비스 플랫폼을 도입할 때 경영진이 흔히 우려하는 것은 보안과 규정 준수에 대한 통제력 상실입니다. 효과적인 IDP는 보안을 왼쪽으로 이동(shift left)시키고 가드레일을 플랫폼 워크플로에 직접 내장함으로써 이러한 우려를 뒤집습니다.

자동 적용 도구로서의 Azure Policy

플랫폼 가드레일을 설계할 때 Azure Policy는 가장 든든한 도구입니다. 리소스를 수동으로 감사하는 대신, Azure Policy를 사용해 특정 Azure 리전으로 리소스 생성을 제한하거나, 모든 스토리지 계정에 암호화를 요구하거나, 특정 네트워크 태그를 의무화하는 등 조직 표준을 자동으로 적용할 수 있습니다. 개발자가 이러한 정책을 위반하는 리소스를 프로비저닝하려 하면, IDP는 검증 단계에서 이를 포착하고 즉각적인 피드백을 제공합니다.

Secret 관리 및 Key Vault 통합

하드코딩된 시크릿은 오랫동안 반복되어 온 보안 취약점입니다. IDP는 기본값으로 안전한 시크릿 관리를 강제해야 합니다. Azure Key Vault를 배포 워크플로에 통합하여 애플리케이션 시크릿, API 키, 연결 문자열이 런타임에 안전하게 주입되도록 하십시오. 이렇게 하면 개발자에게 노출되지 않고 소스 코드 管理 저장소에도 남지 않습니다.

셀프 서비스 개발자 포털 구축

앞서 살펴본 ID, 컴퓨팅, IaC, 보안이라는 기반 요소를 모두 하나의 단일 창, 즉 개발자 포털로 모아야 합니다. 이것이 IDP의 사용자 인터페이스입니다.

Azure 중심 포털을 위한 Backstage 도입

Spotify의 Backstage와 같은 오픈 소스 프레임워크는 개발자 포털을 구축하는 사실상의 표준이 되었습니다. Backstage를 사용하면 소프트웨어 카탈로그를 만들고, 템플릿(소프트웨어 템플릿이라고 함)을 관리하며, 플러그인을 통합할 수 있습니다. Azure API와 직접 통신하는 사용자 지정 Backstage 플러그인을 구축하면, 개발자가 단일 대시보드에서 Azure 리소스를 생성하고, 서비스 상태를 확인하며, 배포 파이프라인을 추적할 수 있습니다.

직관적인 개발자 경험 설계

포털을 설계할 때는 개발자를 고객으로 대해야 합니다. 사용자 경험은 막힘이 없어야 합니다. 개발자는 포털에 접속해 "SQL 백엔드가 포함된 마이크로서비스" 템플릿을 선택하고, 서비스 이름과 소유 팀을 간단한 양식에 입력한 뒤 제출 버튼을 클릭하기만 하면 됩니다. 몇 분 안에 IDP가 Azure 인프라를 프로비저닝하고, 기본 코드가 포함된 GitHub 저장소를 생성하며, CI/CD 파이프라인을 구성하고, 서비스를 내부 카탈로그에 등록해야 합니다.

성공 측정 및 다음 단계

IDP 구축은 종료일이 정해진 프로젝트가 아니라 지속적인 제품 여정입니다. 플랫폼이 가동되면 투자를 정당화하고 개발자 경험을 지속적으로 개선하기 위해 플랫폼의 효과를 측정해야 합니다.

추적해야 할 핵심 지표

개발자 속도와 플랫폼 안정성을 반영하는 지표에 집중하십시오. 회사에 새로 합류한 개발자의 첫 "Hello, World"까지 걸리는 시간, 배포 빈도, 변경 실패율, 평균 복구 시간(MTTR)을 추적하십시오. 또한 정기적인 개발자 만족도 설문조사를 실시하여 플랫폼 워크플로에서 여전히 마찰이 발생하는 지점을 파악하십시오.

다음 단계

작게 시작하십시오. 첫날부터 거대한 엔터프라이즈 플랫폼을 구축하려고 하지 마십시오. 컨테이너 배포 표준화나 데이터베이스 프로비저닝 자동화처럼 하나의 사용 사례를 선택하고, 그것을 중심으로 최소 기능 플랫폼(MVP)을 구축하십시오. 초기 도입 팀의 피드백을 수집하고, 골든 패스를 반복적으로 개선하며, 플랫폼 기능을 조직 전체로 점진적으로 확장하십시오.

Azure에 기본적으로 Internal Developer Platform을 설계함으로써, 여러분은 단순히 배포를 자동화하는 것이 아니라 지속 가능한 엔지니어링 성장을 위한 엔진을 구축하고 있는 것입니다. 읽어 주셔서 감사합니다. 이 주제에 대해 더 깊이 있는 오디오 토론을 원하시면 팟캐스트 에피소드도 꼭 확인해 보십시오. 즐거운 아키텍처 설계 되십시오!