# 플랫폼 엔지니어링이란? 개발자 셀프서비스 가이드

URL: https://codebasechat.com/ko/journal/what-is-platform-engineering-ko
Type: blog
Locale: ko
Published: 2026-10-13
Updated: 2026-10-13

---

> 내부 개발자 플랫폼, 골든 패스, 플랫폼 팀이 필요한 시점과 작게 시작하는 순서를 실무 관점에서 정리합니다.

플랫폼 엔지니어링이란, 개발자가 소프트웨어를 출시하는 데 필요한 것들(개발 환경, 배포 파이프라인, 서비스 생성, 문서, 보안 가드레일)을 셀프서비스로 바로 쓸 수 있도록 내부 플랫폼을 만들고 운영하는 실천법입니다. 소수의 팀이 "아이디어에서 운영 환경까지 가는 길"을 하나의 제품처럼 다루고, 개발자가 그 제품의 고객이 됩니다. 목표는 기다리는 시간, 티켓 수, 배워야 하는 도구 수를 줄이는 것입니다.

아마 이미 겪어 보셨을 겁니다. 새 서비스 하나를 만들려면 저장소, 파이프라인, 데이터베이스, 시크릿, 대시보드, 온콜 순번이 필요한데, 각각 다른 위키 페이지에 있거나 Slack에서 다른 사람에게 물어봐야 합니다.

## 플랫폼 엔지니어링은 왜 생겨났을까요?

"만든 사람이 운영도 한다(You build it, you run it)" 방식은 팀이 서비스 하나와 도구 몇 개만 맡을 때는 잘 작동했습니다. 도구 체인이 쿠버네티스, 테라폼, CI 시스템 세 개, 시크릿 매니저, 서비스 메시, 관측성 스택까지 커지자 더 이상 확장되지 않았습니다. 모든 제품 개발자가 사실상 파트타임 인프라 엔지니어가 되어야 했습니다.

그 비용은 예산표의 한 줄이 아니라 인지 부하로 나타납니다. 어떤 Helm 차트가 "올바른" 것인지 찾는 데 90분이 걸리는 개발자는 실력이 부족해서 느린 것이 아닙니다. 기본값(defaults)이 없어서 느린 것입니다.

![포장도로가 언덕 위로 이어지는 모습, 골든 패스를 비유한 이미지](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/4d5d1f-inline1.webp)

플랫폼 엔지니어링은 이 문제에 대한 교정입니다. 모든 팀이 같은 스택을 처음부터 조립하는 대신, 전담 팀이 한 번 조립해서 가장 쉬운 선택지로 만들고 계속 건강하게 유지합니다. 애널리스트들도 같은 흐름을 보고 있습니다. [Gartner는 2026년까지 대형 소프트웨어 엔지니어링 조직의 80%가 플랫폼 엔지니어링 팀을 갖게 될 것으로 전망했습니다](https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering). 2022년에는 45%였습니다.

## 플랫폼 팀은 실제로 무엇을 만들까요?

벤더 다이어그램은 잠시 잊으세요. 대부분의 회사에서 플랫폼 팀은 네 가지를 제공합니다.

- 
**내부 개발자 플랫폼(IDP).** 클라우드와 CI 위에서 동작하는 셀프서비스 도구와 워크플로 전체입니다. Backstage 포털일 수도 있고, 상용 제품일 수도 있고, 템플릿과 CLI를 잘 관리한 저장소일 수도 있습니다.

- 
**골든 패스.** "새 API 서비스 만들기"나 "큐 추가하기"처럼 자주 하는 작업을 위한, 의견이 담기고 지원되는 경로입니다.

- 
**가드레일.** 정책, 보안 스캔, 비용 한도를 기본값으로 적용해서 안전한 선택이 가장 게으른 선택도 되게 만듭니다.

- 
**문서와 탐색.** "이 서비스의 담당자는 누구인지, 런북은 어디 있는지, 무엇에 의존하는지"에 답해 주는 카탈로그입니다.

이 중 어떤 것도 새로운 제품 카테고리가 필요하지 않습니다. 좋은 플랫폼 상당수가 쿠키커터 템플릿 하나와, 누군가 계속 최신으로 유지하는 README에서 시작했습니다.

## 골든 패스란 무엇이고, 팀은 왜 무시할까요?

CNCF는 골든 패스를 "빠른 프로젝트 개발을 위해 잘 통합된 코드와 기능을 템플릿으로 조합한 것"이라고 설명합니다. 이 정의는 [Google Cloud가 Spring Boot 예제로 풀어 쓴 글](https://cloud.google.com/blog/products/application-development/golden-paths-for-engineering-execution-consistency)에서 확인할 수 있습니다. 쉽게 말하면, 새 서비스가 첫날부터 저장소, 파이프라인, 로깅, 배포 설정을 갖도록 해 주는 템플릿입니다.

실패하는 패턴도 그만큼 단순합니다. 아무도 요청하지 않았고, 그 길을 걸을 팀과 이야기하지 않고 만든 경로는 채택률이 한 자릿수에 머뭅니다. 그러면 플랫폼 팀은 개발자들이 왜 계속 티켓을 여는지 의아해합니다. 경로는 우회로보다 짧아야 합니다. 그렇지 않으면 사람들은 우회로를 택합니다.

골든 패스를 살아 있게 만드는 규칙은 두 가지입니다.

- 
**울타리가 아니라 포장도로입니다.** 개발자는 경로를 벗어날 수 있지만, 경로 밖에서 만든 것의 지원 부담은 스스로 집니다.

- 
**제품처럼 운영합니다.** 누군가 피드백을 읽고, 채택률을 추적하고, 아무도 쓰지 않는 경로는 삭제합니다.

## 플랫폼 엔지니어링은 이름만 바꾼 DevOps인가요?

일부는 맞습니다. 그리고 정직한 답이 마케팅용 답보다 쓸모가 있습니다. DevOps는 문화입니다. 개발과 운영이 책임을 함께 나누고 피드백 루프를 짧게 유지하는 것이죠. 플랫폼 엔지니어링은 반복되는 운영 업무를 제품으로 바꿔서, 그 문화를 규모 있게 지속하는 한 가지 방법입니다.

SRE는 또 다른 분야입니다. SRE는 신뢰성 목표를 정의하고 측정하며, 그 목표를 지키기 위해 언제 배포를 멈출지 결정합니다. 플랫폼 팀은 포장도로를 깔고, SRE 팀은 그 위에서 어느 정도의 위험을 감당할 수 있는지 알려 줍니다.

- 
**DevOps**는 문화이자 실천 방식입니다. 결과물은 공유된 책임과 자동화이며, 보통 직함과 티켓 대기열로 변질되면서 실패합니다.

- 
**SRE**는 신뢰성 규율입니다. 결과물은 SLO, 에러 버짓, 장애 대응 프로세스이며, 권한 없는 당직 순번이 되면서 실패합니다.

- 
**플랫폼 엔지니어링**은 내부 제품 팀입니다. 결과물은 셀프서비스 플랫폼과 골든 패스이며, 아무도 쓰지 않는 플랫폼이 되면서 실패합니다.

실패 양상은 두 번 읽을 가치가 있습니다. 티켓을 받아서 요청받은 것을 무엇이든 만드는 플랫폼 팀은 이름만 바뀐 운영 팀이고, 옛 대기열 문제를 그대로 물려받습니다.

![한쪽은 엉킨 케이블, 다른 쪽은 정리된 케이블인 서버 랙](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/483c49-inline2.webp)

## 플랫폼 팀을 꾸릴 만한 가치는 언제 생길까요?

엔지니어가 30명 미만이고 서비스가 한두 개뿐이라면 건너뛰세요. 이 규모에서는 좋은 템플릿 저장소와 공용 테라폼 모듈로 충분하고, 전담 플랫폼 팀은 오버헤드입니다. 열 명 규모의 팀에서는 몇 사람이 조용히 플랫폼 역할을 맡게 되는데, 그것도 괜찮습니다.

같은 신호가 반복해서 나타나기 시작하면 투자할 가치가 생깁니다.

- 
새 서비스가 운영 환경에 올라가기까지 몇 주가 걸리고, 대부분은 다른 사람을 기다리는 시간입니다.

- 
세 팀이 같은 배포 문제를 세 가지 방식으로 해결했습니다.

- 
신입 엔지니어의 온보딩이 암묵지 더미와 "Priya한테 물어보세요, 그 사람이 알아요"로 이루어집니다.

- 
보안과 컴플라이언스 검토가 마지막에, 팀별로, 손으로 이루어집니다.

Team Topologies가 말하는 최소 실용 플랫폼(thinnest viable platform)이 가장 작은 유용한 형태입니다. 가장 큰 반복 고통을 없앨 만큼만 만들고, 잘 문서화하고, 그 이상은 만들지 않습니다. 팀 전체에서 시간을 가장 많이 잡아먹는 워크플로 하나부터 시작하세요. 보통은 "새 서비스 만들기"나 "프리뷰 환경 받기"입니다.

기능 플래그는 여러 개의 개별 시스템보다 공용 서비스로 두는 편이 저렴한 기능의 좋은 예입니다.

모든 팀이 호출할 수 있는 플래그 서비스는 같은 감사 로그와 같은 정리 규칙을 갖고, 각 팀이 반쯤 동작하는 토글 시스템을 따로 만드는 수고를 덜어 줍니다. 구매하든 직접 만들든, 각 저장소가 아니라 플랫폼 위에 있어야 합니다.

## 플랫폼과 코드 읽기는 어떤 관계일까요?

다이어그램이 인정하는 것보다 훨씬 깊은 관계입니다. 플랫폼은 주변 지식만큼만 쓸모가 있습니다. 개발자가 "서비스 A는 서비스 B에 어떻게 인증하나요?"라고 물으면, 답은 코드, 설정, 그리고 여섯 달 전에 쓰인 런북 어딘가에 있습니다.

여기서 플랫폼 팀은 조용히 시간을 씁니다. "X는 어디에 설정되어 있나요?"로 시작하는 Slack 질문을 받고, 이번 주만 다섯 번째로 기억을 더듬어 답합니다. 저장소가 8만 줄을 넘어가면 플랫폼 팀이 사람 검색 인덱스가 되는 효과가 뚜렷하게 드러납니다.

![코드 편집기가 켜진 노트북 옆에 시스템 다이어그램 스케치가 놓인 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/428ff2-inline3.webp)

도구가 몇 가지 도움이 되는데, 문제의 서로 다른 절반을 풉니다. 문서를 코드 가까이에 두는 docs-as-code 도구는 글로 된 부분을 담당합니다.

코드를 이해하는 어시스턴트는 코드 자체에 대한 질문에 답합니다. Sourcegraph의 어시스턴트는 대규모 멀티 리포지토리 조직을 겨냥하고, 기업을 대상으로 견적 기반으로 판매됩니다. 그래서 엔지니어 열다섯 명짜리 팀보다는 큰 환경의 플랫폼 팀에 더 잘 맞습니다.

에디터 안에서 하는 일상적인 작업에는 범용 어시스턴트가 많은 부분을 커버합니다. 다만 주어진 맥락만 안다는 한계가 있습니다.

우리가 따라 할 만한 패턴은 이렇습니다. 골든 패스 템플릿, 소유권 카탈로그, 코드의 검색 가능한 인덱스를 같은 곳에 두고, 신입 엔지니어가 사람에게 묻기 전에 그곳에서 먼저 질문하게 합니다. 효과는 시간 단위로 측정할 수 있습니다. 이 작업을 한 뒤 플랫폼 팀이 일주일에 "이 설정은 어디 있나요" 질문에 열 번 미만으로 답하게 된다면, 잘 된 것입니다.

## 대성당을 짓지 않고 시작하려면 어떻게 할까요?

실패하는 플랫폼 노력의 대부분은 도구부터 시작합니다. 더 나은 순서는 사람, 경로, 도구 순입니다.

- 
**개발자 열 명을 인터뷰합니다.** 병합된 PR과 실행 중인 기능 사이에서 어디서 시간을 잃는지 물어보세요. 같은 세 가지 답을 듣게 될 겁니다.

- 
**경로 하나를 골라 한 달 안에 출시합니다.** 끝에서 끝까지 동작하는 "새 서비스" 템플릿 하나가, 빈 타일 40개가 있는 포털보다 낫습니다.

- 
**전후를 측정합니다.** 새 서비스의 첫 배포까지 걸리는 시간과 신입의 첫 병합 PR까지 걸리는 시간을 추적하세요. 이 두 숫자가 어떤 만족도 설문보다 많은 것을 알려 줍니다.

- 
**로드맵과 변경 로그를 공개합니다.** 플랫폼 작업은 드러내지 않으면 보이지 않습니다.

- 
**삭제합니다.** 아무도 쓰지 않는 경로와 도구를 은퇴시키세요. 사람들이 신뢰하는 작은 플랫폼이, 사람들이 우회하는 큰 플랫폼보다 낫습니다.

먼저 포털을 사려는 충동은 참으세요. 엉킨 워크플로 위에 포털을 얹으면 더 보기 좋은 엉망이 생길 뿐입니다. 항목 247개 중 절반이 오래된 카탈로그는 카탈로그가 없는 것보다 나쁩니다.

## 무엇이 잘못되는지, 그리고 언제 알아챌까요?

반복해서 나타나는 실패 패턴이 세 가지 있습니다.

**헬프데스크 플랫폼.** 요청이 티켓으로 들어오고, 팀이 수작업으로 처리하면서 셀프서비스라고 부릅니다. 테스트: 개발자가 누구와도 말하지 않고 흔한 작업을 끝낼 수 있나요?

**강제 플랫폼.** 리더십이 플랫폼이 좋아지기 전에 모든 팀을 플랫폼으로 옮깁니다. 채택률 숫자는 좋아 보이지만 만족도는 무너집니다. 처음 여섯 달은 사용이 자연스럽게 생기도록 두세요.

**만능 플랫폼.** 모든 요청이 기능이 되면서 표면적이 부풀고 품질이 떨어집니다. 이유와 함께 글로 "아니요"라고 말하세요.

유용한 조기 경보는 Slack 질문 수와 문서화된 답의 비율입니다. 같은 질문이 한 달에 세 번 나오는데 문서도, 템플릿도, 자동화도 없다면, 그게 다음 백로그 항목입니다.

## 다음 주 월요일에는 실제로 무엇을 할까요?

팀 전체에서 가장 많은 시간을 낭비하는 일 하나를 골라 지루하게 만드세요. 대부분의 회사에서는 새 서비스 만들기나 테스트 환경 받기입니다. 경로를 쓰고, 사람들이 찾을 수 있는 곳에 두고, 절약되는 시간을 세어 본 뒤에야 더 큰 팀이 필요한지 결정하세요.

플랫폼 엔지니어링은 설치하는 도구 체인이 아닙니다. 내부 개발자를 고객으로 대하겠다는 결정이고, 그 결정을 실제로 했다는 증거는 신입의 첫 출근일과 첫 병합 변경 사이가 짧아지는 것입니다.

## FAQ

### 플랫폼 엔지니어링과 DevOps는 어떻게 다른가요?

DevOps는 개발과 운영이 책임을 나누는 문화와 실천 방식이고, 플랫폼 엔지니어링은 그 문화를 확장하기 위해 반복 운영 업무를 셀프서비스 제품으로 만드는 내부 제품 팀입니다.

### 플랫폼 팀은 몇 명부터 필요한가요?

엔지니어가 30명 미만이고 서비스가 한두 개뿐이라면 보통 필요하지 않습니다. 같은 배포 문제를 여러 팀이 따로 풀고 신규 서비스 출시에 몇 주씩 걸리기 시작하면 검토할 시점입니다.

### 골든 패스란 무엇인가요?

새 서비스 생성처럼 자주 하는 작업을 위해 지원되는 기본 경로입니다. 저장소, 파이프라인, 로깅, 배포 설정을 처음부터 제공하는 템플릿 형태가 일반적입니다.

### 내부 개발자 플랫폼(IDP)은 꼭 Backstage로 만들어야 하나요?

아닙니다. Backstage 포털, 상용 제품, 또는 템플릿과 CLI를 잘 관리한 저장소 모두 IDP가 될 수 있습니다. 중요한 것은 도구 종류가 아니라 개발자가 셀프서비스로 작업을 끝낼 수 있는지입니다.

### 플랫폼 엔지니어링을 어떻게 시작하면 좋을까요?

개발자 열 명을 인터뷰해 가장 큰 시간 낭비를 찾고, 그 작업 하나를 한 달 안에 끝까지 동작하는 경로로 만드세요. 그다음 전후 시간을 측정하고, 도구 구매는 그 뒤에 결정하세요.