IDP, 반복 요청을 제품화하는 플랫폼
IDP는 반복되는 인프라·배포·운영 요청을 Golden Path로 제품화해 개발자의 인지 부하와 대기 시간을 줄이는 내부 플랫폼이다. 핵심은 포탈 UI가 아니라 선언적 인터페이스, 자동화 백엔드, 관찰 가능한 검증, 그리고 개발자 중심의 제품 운영이다.
Script Companion
오디오와 함께 스크립트 보기
- 01
Internal Developer Platform, 줄여서 IDP는 개발자가 코드를 쓰는 일 밖의 복잡성을 덜 느끼게 만드는 내부 플랫폼이다. 인프라 설정, 배포 파이프라인, 모니터링 설정을 매번 개발자나 운영팀이 수동으로 처리하면 생산성이 떨어지고 설정 편차도 커진다. 그래서 IDP의 핵심 가치는 모든 인프라를 숨기는 것이 아니라, 반복되는 운영 지식을 셀프서비스 형태로 제품화하는 데 있다. 플랫폼 엔지니어의 중요한 결과물이 IDP라고 볼 수 있는 이유도 여기에 있다.
- 02
IDP가 등장한 배경은 인프라를 누가 만들 것인가보다 반복 요청을 언제까지 사람 손으로 라우팅할 것인가에 가깝다. 전통적인 방식에서는 운영팀이 개발 환경을 정의하고 세팅하며, 이 과정은 시간이 많이 들고 오류가 나기 쉽다. AWS Prescriptive Guidance는 IDP를 개발자가 환경, 배포, 리소스, 설정을 독립적으로 관리하게 하는 내부 제품으로 설명한다. Gartner 전망에서는 2026년까지 대형 소프트웨어 엔지니어링 조직의 80%가 재사용 가능한 서비스, 컴포넌트, 도구를 제공하는 플랫폼 엔지니어링 팀을 만들 것이라고 본다.
- 03
IDP 후보를 판단할 때는 포탈을 만들 수 있는지가 아니라 반복성과 대기 시간, 오류 패턴을 본다. 예를 들어 새 NestJS 서비스와 PostgreSQL, prod 배포 요청이 매달 20건 이상 반복되고, 요청마다 1일 이상 대기하거나 보안 그룹, 알림, 백업 설정 누락이 반복된다면 좋은 후보가 된다. 반대로 한 팀 5명 이하가 분기 1~2회만 쓰는 작업이라면 Backstage부터 세우기보다 GitHub Actions 수동 실행 버튼, Terraform module, 짧은 runbook이 더 적절할 수 있다. 도구보다 먼저 볼 것은 병목이다.
- 04
IDP 성숙도는 한 번에 완성되지 않는다. Port.io와 CNCF 2025 기준 모델에서는 Level 1 임시방편부터 Level 5 최적화까지 단계가 나뉘며, 각 단계에 6~12개월을 투자하는 것이 현실적이라고 본다. Level 1은 스크립트와 수동 설정, 특정인에게 집중된 지식이 특징이고, Level 2는 CI/CD 파이프라인과 일부 자동화가 있지만 문서가 부족한 상태다. Level 3은 표준 템플릿, 서비스 카탈로그, 기본 셀프서비스가 있고, Level 4는 플랫폼 팀이 제품 팀처럼 피드백 루프를 운영한다. Level 5는 셀프서비스가 기본값이고 AI 통합과 DORA 지표 엘리트 수준을 지향한다.
- 05
IDP의 핵심 구성요소는 서비스 카탈로그, 셀프서비스 인프라, CI/CD 파이프라인, 문서 포탈, 비밀 관리다. 서비스 카탈로그는 서비스의 목록, 상태, 소유자를 보여주고, 셀프서비스 인프라는 개발자가 환경과 리소스를 직접 만들게 한다. CI/CD는 코드에서 빌드, 테스트, 배포까지 이어지는 자동화를 담당하고, 문서 포탈은 API 문서와 운영 가이드, 온보딩 문서를 모은다. 비밀 관리는 API Key와 DB 비밀번호 같은 민감 정보를 안전하게 다룬다. 여기서 중요한 점은 구성요소의 이름보다 이들이 반복 요청을 하나의 흐름으로 묶는다는 사실이다.
- 06
IDP가 동작하는 방식은 오케스트레이션 레이어로 이해하면 쉽다. 개발자가 포탈 UI나 CLI에서 새 NestJS 서비스를 만들고 싶다고 요청하면, IDP 오케스트레이터가 필요한 작업 목록을 만들고 순서대로 실행한다. Terraform은 AWS 리소스를 프로비저닝하고, GitHub API는 레포를 만들고, CI/CD 파이프라인은 연결되며, CloudWatch 알림도 설정된다. 마지막에는 새 서비스가 서비스 카탈로그에 등록된다. 따라서 해결 메커니즘의 중심은 포탈 UI 자체가 아니라 반복 티켓을 최소 파라미터 템플릿과 정책이 내장된 자동 실행으로 바꾸는 것이다.
- 07
IDP의 인터페이스가 효과적인 이유는 개발자에게 무엇을 원하는지 묻고, 어떻게 구현할지는 플랫폼이 결정하기 때문이다. 이것이 선언적 인터페이스의 원리다. 개발자는 NestJS 서비스, prod 환경, PostgreSQL 필요처럼 업무 의도를 선언하고, 플랫폼은 인스턴스 타입, 서브넷, 백업 정책 같은 운영 결정을 수행한다. Score 공식 문서도 이 경계를 분명히 둔다. score.yaml은 개발자 소유의 workload 설정을 선언하고, 플랫폼 소유의 인프라 설정은 대상 환경의 구현체가 해석한다. 좋은 IDP는 업무 의도를 받되, 플랫폼이 결정한 운영 결과를 감사 가능한 형태로 남겨야 한다.
- 08
이 선언적 추상화는 IDP에만 있는 패턴이 아니다. IDP에서 Score의 score.yaml workload가 type: postgres를 선언하면 플랫폼이 RDS 인스턴스 타입, VPC 서브넷, 보안 그룹을 결정한다. Kubernetes에서는 Deployment manifest의 replicas: 3 선언을 보고 어느 노드에 스케줄링할지와 재시작 정책을 시스템이 결정한다. Terraform은 .tf resource block을 바탕으로 API 호출 순서, 의존성 그래프, 변경 계획을 만든다. SQL의 Schema DDL도 CREATE TABLE users 같은 선언을 받고 인덱스 물리 구조, 스토리지 레이아웃, 실행 계획을 시스템이 결정한다.
- 09
선언적 추상화에는 분명한 트레이드오프가 있다. 추상화 수준이 높아질수록 인지 부하는 낮아지지만, 시스템이 결정한 How가 의도와 다르면 디버깅 비용이 올라간다. 그래서 새 선언적 시스템을 평가할 때는 네 가지를 물어야 한다. What과 How의 경계가 어디인지, 시스템이 결정한 How를 어떻게 관찰하는지, 선언과 실제 상태가 어긋났을 때 어느 쪽을 신뢰하는지, 추상화를 깨고 내려갈 비상 경로가 있는지다. IDP에서는 catalog가 실제 인프라보다 늦을 수 있으므로 catalog만 보면 안 된다.
- 10
좋은 IDP는 기본 경로를 제공하지만 수정 불가능한 감옥이 되어서는 안 된다. CNCF의 설명처럼 셀프서비스를 제공하되 underlying tech를 접근 불가능하게 만들면 안 된다. Score에서 직접 Terraform 수정으로 내려가거나, Backstage 템플릿에서 직접 GitHub repo 편집으로 내려가는 비상 경로가 필요하다. Backstage 실습에서도 UI가 뜬 것만 확인하면 부족하다. 선언인 catalog-info.yaml, 시스템이 본 결과인 catalog API 응답, 그리고 drift 가능성을 함께 확인해야 한다. 포탈에는 성공이라고 보이는데 실제 인프라가 의도와 다를 수 있기 때문이다.
- 11
Backstage Software Template은 IDP의 Golden Path를 구체화하는 대표 예시다. 개발자가 새 서비스 만들기를 누르면 YAML로 정의된 템플릿이 실행된다. 하지만 성공 로그만으로는 충분하지 않다. Backstage 공식 문서는 템플릿 실행 실패 시 실패한 각 섹션의 로그를 열어 디버깅할 수 있고, 실패한 실행을 이전 파라미터가 채워진 상태로 다시 시작할 수 있다고 설명한다. 그래서 운영에 넣기 전에는 GitHub repo 이름 중복처럼 일부러 실패 케이스를 만들어야 한다. 실패 단계가 보이지 않거나 실패 후 일부 리소스가 남으면, 그것은 아직 Golden Path가 아니라 부분 자동화된 수동 작업이다.
- 12
실제 사례는 IDP가 기술 통합만으로 끝나지 않는다는 점을 보여준다. Zepto는 500명 이상의 개발자가 새 마이크로서비스 온보딩에 며칠씩 쓰고, 700개 이상의 ArgoCD 애플리케이션과 400개 이상의 AWS 리소스 가시성이 부족한 문제를 Backstage, ArgoCD, Kubernetes 기반 IDP로 줄였다. DoorDash의 DashStack은 피처 플래그 기반 카나리아 배포 자동 분석, 원클릭 데이터베이스 프로비저닝, HashiCorp Vault 연동 자동 시크릿 로테이션을 제공했다. Slack 내부 플랫폼은 서비스, 데이터베이스, 크론잡을 단일 CLI로 배포하고 Backstage 커스텀 플러그인으로 실시간 배포 피드백을 제공했다. Zalando Sunrise는 Backstage 기반으로 CI/CD, Kubernetes, 관찰 가능성 도구를 단일 대시보드로 통합했다.
- 13
실패 패턴은 반복된다. 껍데기 포탈은 버튼이 있지만 실제 자동화가 없어서 개발자 신뢰를 잃는다. 도구 과부하는 통합 없이 도구만 추가해 개발팀이 평균 7.4개 도구를 쓰고 주 6~15시간을 낭비하는 상황으로 이어진다. 측정 부재도 크다. 30%의 팀이 성공 지표가 없으면 플랫폼을 만들었다는 사실과 개발자 흐름이 빨라졌다는 결과를 구분할 수 없다. 강제 표준화는 왜를 설명하지 않은 규칙 때문에 우회 경로를 만들게 하고, 과도한 추상화는 뭔가 깨졌을 때 원인을 알 수 없는 블랙박스를 만든다.
- 14
특히 조심할 것은 플랫폼 silent failure다. Backstage 템플릿이 완료를 반환해도 보안 그룹이 0.0.0.0/0으로 열리거나 포트가 맞지 않을 수 있고, IAM 정책이 적용되지 않아 ECS Task는 뜨지만 S3나 Secrets Manager 접근에서 런타임 에러가 날 수 있다. RDS가 생성됐어도 storage_encrypted = false 상태일 수 있고, 태그가 빠져 비용 할당과 소유자 추적이 어려울 수 있다. 이런 문제는 Conftest로 Terraform plan을 사전 차단하고, AWS Config와 SSM Automation으로 사후 복구하며, 템플릿 자체 결함이면 카탈로그, 인프라, repo 순서로 수동 rollback해야 한다. 카탈로그를 마지막에 지우면 좀비 상태가 생길 수 있다.
- 15
도입 전략은 MVP-First가 현실적이다. 2026년 기준 성공하는 플랫폼 팀은 8주 안에 컨셉에서 동작하는 플랫폼까지 도달하는 접근을 택한다. MVP에는 표준 데이터베이스 타입 프로비저닝, 기본 CI/CD 파이프라인, 표준 애플리케이션 구조 템플릿 같은 최소 요소가 들어간다. 가장 흔한 실수는 포탈 UI부터 만들고 백엔드 자동화를 나중으로 미루는 것, 모든 서비스 타입과 모든 환경을 한꺼번에 지원하려는 것, 개발자를 인터뷰하지 않는 것이다. 먼저 자주 반복되는 요청 1개를 자동화하고, 실제 개발자 2~3명을 얼리 어답터로 만들어 빠르게 피드백을 받아야 한다.
- 16
성공 측정은 기술 지표보다 흐름 지표에서 시작한다. 플랫폼 채택률은 Golden Path를 사용하는 서비스 비율을 보고, 첫 배포까지 시간은 신규 서비스 생성에서 첫 프로덕션 배포까지 걸리는 시간을 본다. 수동 개입 빈도는 플랫폼 팀에 들어오는 수동 요청 건수의 감소 추세를 확인하고, 개발자 만족도는 eNPS로 추적한다. DORA 지표로는 배포 빈도, Change Lead Time, Failed Deployment Recovery, Change Fail Rate, Deployment Rework Rate를 연결해 볼 수 있다. 다만 이 지표들은 팀 순위표가 아니라 서비스별 흐름 진단 도구다. 리드 타임이 줄었는데 변경 실패율이 올랐다면, 플랫폼은 성공한 것이 아니라 검증 단계를 너무 많이 숨긴 것이다.
같은 레이어