플랫폼 엔지니어링 (Platform engineering)은 소프트웨어 엔지니어링 분야에서 가장 빠르게 성장하는 분야 중 하나가 되었습니다. 조직이 확장됨에 따라 서비스, 파이프라인, 클라우드 리소스 및 운영 도구의 수도 그만큼 빠르게 증가합니다. 공통된 플랫폼이 없다면, 모든 제품 팀은 결국 동일한 인프라 문제를 독립적으로 해결하게 됩니다.

저는 성공적인 플랫폼 엔지니어링 이니셔티브가 기술로 시작되는 것이 아니라, 개발자들이 어디에서 시간을 낭비하고 있는지를 이해하는 것에서 시작된다는 것을 발견했습니다. 내부 개발자 포털 (Internal developer portal)은 단순한 또 다른 대시보드가 아닙니다. 이는 워크플로 (workflows)를 표준화하고, 인지 부하 (cognitive load)를 줄이며, 엔지니어링 팀이 인프라를 관리하는 대신 제품을 구축하는 데 집중할 수 있게 하는 방법입니다.

이 글에서는 제가 플랫폼 엔지니어링 팀과 내부 개발자 포털을 밑바닥부터 구축하는 데 어떻게 접근할 것인지에 대해 설명합니다.

요약 (TL;DR)

• 개발자를 통제하는 것이 아니라, 개발자를 지원할 수 있는 플랫폼 팀을 구축하세요.
• 개발자의 가장 큰 페인 포인트 (pain points)를 해결하는 것부터 시작하세요.
• 플랫폼을 실제 사용자가 있는 내부 제품 (internal product)으로 취급하세요.
• 수동 요청 대신 셀프 서비스 (self-service) 워크플로를 제공하세요.
• 문서, 서비스, 배포 및 소유권에 대한 단일 지점이 되는 내부 개발자 포털 (Internal Developer Portal, IDP)을 구축하세요.
• 성공 여부를 플랫폼 기능 출시 수가 아닌, 개발자 채택률 (adoption) 및 전달 지표 (delivery metrics)를 사용하여 측정하세요.

플랫폼 엔지니어링이 존재하는 이유

조직이 성장함에 따라 엔지니어링 팀은 종종 다음과 같은 동일한 문제들을 경험합니다:

• 개발자들이 클라우드 리소스를 확보하기 위해 며칠씩 기다립니다.
• CI/CD 파이프라인이 팀마다 일관되지 않습니다.
• 문서가 여러 도구에 흩어져 있습니다.
• 특정 서비스의 소유자가 누구인지 아무도 모릅니다.
• 보안 및 컴플라이언스 (compliance) 체크가 프로젝트마다 다릅니다.

결국, 엔지니어링 팀은 소프트웨어를 구축하는 것보다 시스템을 탐색하는 데 더 많은 시간을 소비하게 됩니다.

그 지점이 바로 플랫폼 엔지니어링이 가치를 제공하는 부분입니다. 즉, 모든 팀이 사용할 수 있는 재사용 가능한 역량을 생성함으로써 가치를 전달합니다.

1단계: 개발자 페인 포인트 (Pain Points) 식별하기

단 한 줄의 코드를 작성하기 전에, 개발자들이 어디에서 시간을 허비하는지 이해하는 데 시간을 투자하십시오.

전형적인 질문은 다음과 같습니다:

새로운 서비스를 생성하는 데 얼마나 걸리는가?
온보딩 (Onboarding)에 얼마나 걸리는가?
배포 (Deployment) 단계 중 수동으로 진행되는 단계는 몇 개인가?
개발자들이 인프라 (Infrastructure) 지원을 얼마나 자주 요청하는가?
어떤 요청이 플랫폼 또는 DevOps 팀으로 반복해서 들어오는가?

이러한 답변은 플랫폼이 무엇을 가장 먼저 해결해야 하는지 우선순위를 정하는 데 도움이 됩니다.

2단계: 플랫폼 팀 정의하기

플랫폼 엔지니어링 (Platform Engineering) 팀은 단순히 DevOps 팀의 이름만 바꾼 것이 아닙니다.

이들의 미션은 내부 엔지니어링 팀을 위한 재사용 가능한 제품을 구축하는 것입니다.

전형적인 팀 구성은 다음과 같을 수 있습니다:

플랫폼 엔지니어 (Platform Engineers)
사이트 신뢰성 엔지니어 (Site Reliability Engineers, SREs)
DevOps 엔지니어 (DevOps Engineers)
클라우드 엔지니어 (Cloud Engineers)
보안 엔지니어 (Security Engineers)
개발자 경험 (Developer Experience, DevEx) 엔지니어

이들의 고객은 외부 사용자가 아닌 개발자입니다.

3단계: 내부 개발자 포털 (Internal Developer Portal) 구축하기

포털은 개발자가 플랫폼과 상호작용하는 중앙 집중식 장소가 됩니다.

개발자가 여러 시스템을 뒤지는 대신, 다음과 같은 작업을 수행할 수 있어야 합니다:

서비스 검색 (Discover services)
소유권 확인 (View ownership)
새 프로젝트 생성 (Create new projects)
애플리케이션 배포 (Deploy applications)
인프라 요청 (Request infrastructure)
문서 읽기 (Read documentation)
대시보드 확인 (View dashboards)
서비스 상태 확인 (Check service health)

하나의 포털이 수십 개의 단절된 도구들을 대체합니다.

4단계: 서비스 템플릿 표준화하기

모든 새로운 마이크로서비스 (Microservice)가 처음부터 시작할 필요는 없습니다.

다음 항목을 포함하는 재사용 가능한 템플릿을 만드십시오:

저장소 구조 (Repository structure)
CI/CD 파이프라인 (CI/CD pipeline)
테스트 프레임워크 (Testing framework)
로깅 (Logging)
모니터링 (Monitoring)
보안 스캐닝 (Security scanning)
문서화 (Documentation)

템플릿 예시:

service:
name: payments-api
language: nodejs
runtime: node20

ci:
tests: true
lint: true
security_scan: true

deployment:
environment: staging
strategy: rolling

monitoring:
metrics: enabled
logs: enabled
tracing: enabled

개발자는 몇 시간이 아닌 몇 분 만에 프로덕션 준비가 된 (Production-ready) 서비스를 부트스트랩 (Bootstrap) 할 수 있습니다.

5단계: 인프라 자동화하기

개발자가 클라우드 리소스 (Cloud resources)를 수동으로 생성해서는 안 됩니다.

인프라 (Infrastructure)는 재사용 가능한 템플릿 (templates)을 통해 프로비저닝 (provisioned)되어야 합니다.

예시:

apiVersion: platform.company.io/v1

kind: Service

metadata:
name: payments-api

spec:
runtime: node20
database: postgres
cache: redis
monitoring: enabled

배후에서는 자동화가 모든 것을 일관되게 프로비저닝합니다.

6단계: 셀프 서비스 워크플로 (Self-Service Workflows) 구축하기

모든 수동 티켓 (manual ticket)은 자동화의 기회입니다.

예시에는 다음이 포함됩니다:

리포지토리 (repository) 생성
Kubernetes 네임스페이스 (namespaces) 프로비저닝
CI/CD 파이프라인 (pipelines) 생성
데이터베이스 (databases) 요청
TLS 인증서 (certificates) 발급
DNS 설정
시크릿 (secrets) 로테이션

개발자는 다른 팀을 기다리는 대신, 포털 (portal)을 통해 이러한 작업들을 완료합니다.

7단계: 소유권 (Ownership) 가시화하기

내부 포털의 가장 가치 있는 기능 중 하나는 서비스 소유권 (service ownership)입니다.

모든 서비스는 다음과 같은 질문에 답할 수 있어야 합니다:

누가 소유하고 있는가?
어느 팀이 지원하는가?
문서 (documentation)는 어디에 있는가?
어떤 환경 (environments)이 존재하는가?
마지막으로 배포 (deployed)된 시점은 언제인가?

예시 설정:

service:
name: payments-api

owner:
team: payments

repository:
github: company/payments-api

slack:
channel: payments-alerts

runbook:
docs/runbook.md

적절한 정보를 찾는 데는 일련의 Slack 메시지가 아닌, 단 몇 초만이 소요되어야 합니다.

8단계: CI/CD 및 관측성 (Observability) 통합하기

개발자는 무슨 일이 일어나고 있는지 이해하기 위해 여러 도구를 번갈아 가며 사용할 필요가 없어야 합니다.

포털은 다음을 표면화(surface)해야 합니다:

최신 배포 (deployments)
빌드 상태 (Build status)
테스트 결과 (Test results)
보안 취약점 발견 (Security findings)
DORA 지표 (DORA metrics)
로그 (Logs)
메트릭 (Metrics)
트레이스 (Traces)
장애 이력 (Incident history)

목표는 개발자에게 단일 인터페이스 (single interface)로부터 자신의 서비스에 대한 완전한 뷰 (view)를 제공하는 것입니다.

9단계: 성공 측정하기

플랫폼 엔지니어링 (Platform engineering)은 단순히 포털을 출시했다고 해서 성공하는 것이 아닙니다.

개발자들이 실제로 그것을 사용할 때 성공하는 것입니다.

유용한 지표 (metrics)에는 다음이 포함됩니다:

개발자 온보딩 시간 (Developer onboarding time)
서비스 생성 시간 (Service creation time)
배포 빈도 (Deployment frequency)
변경 리드 타임 (Lead time for changes)
셀프 서비스 채택률 (Self-service adoption)
수동 지원 요청 수 (Number of manual support requests)
내부 플랫폼 만족도 (Internal platform satisfaction)
포털 사용량 (Portal usage)

플랫폼이 마찰(friction)을 줄인다면, 이러한 지표들은 시간이 지남에 따라 개선될 것입니다.

흔한 실수 (Common Mistakes)

일부 플랫폼 이니셔티브는 다음과 같은 이유로 어려움을 겪습니다:

• 사용자 니즈를 검증하기 전에 너무 많은 기능을 구축함
• 개발자 경험 (Developer Experience) 대신 기술에 집중함
• 팀들에게 경직된 워크플로우 (Workflows)를 강요함
• 문서화 (Documentation)를 무시함
• 플랫폼을 내부 제품 (Internal Product)이 아닌 인프라 프로젝트로 취급함

최고의 플랫폼은 엔지니어링 팀으로부터의 지속적인 피드백을 통해 진화합니다.

전형적인 플랫폼 아키텍처 (Typical Platform Architecture)
개발자 (Developer)
│
▼
내부 개발자 포털 (Internal Developer Portal)
│
├── 서비스 카탈로그 (Service Catalog)
├── 문서화 (Documentation)
├── 템플릿 (Templates)
├── 셀프 서비스 액션 (Self-Service Actions)
├── CI/CD
├── 인프라 자동화 (Infrastructure Automation)
├── 보안 (Security)
└── 관측 가능성 (Observability)
│
▼
클라우드 인프라 (Cloud Infrastructure)

포털은 진입점 (Entry point)이 되고, 자동화는 배후에서 운영 복잡성 (Operational complexity)을 처리합니다.

마치며 (Final Thoughts)

플랫폼 엔지니어링 (Platform engineering)은 통제를 중앙 집중화하는 것이 아니라, 역량을 분산화하는 것입니다.

개발자가 셀프 서비스 워크플로우 (Self-service workflows)를 통해 서비스를 생성하고, 인프라를 프로비저닝 (Provision)하며, 애플리케이션을 배포하고, 문서에 접근할 수 있을 때, 그들은 대기하는 시간을 줄이고 가치를 전달하는 데 더 많은 시간을 보낼 수 있습니다.

가장 효과적인 플랫폼 팀은 자신들이 구축한 도구의 개수로 성공을 측정하지 않습니다. 그들은 엔지니어링 마찰 (Engineering friction)을 얼마나 제거했는가로 성공을 측정합니다.

플랫폼 엔지니어링 이니셔티브를 시작하고 있다면, 모든 것을 한꺼번에 구축하려는 충동을 억제하세요. 영향력이 큰 문제 하나를 해결하고, 피드백을 수집하며, 반복 (Iterate)하세요. 시간이 흐름에 따라 여러분의 내부 개발자 포털은 단순한 도구의 집합 그 이상이 될 것입니다. 그것은 여러분의 엔지니어링 조직이 소프트웨어를 구축하고, 출시하고, 운영하는 방식의 토대가 될 것입니다.