플랫폼 엔지니어링

서비스를 만드는 팀이 인프라를 매번 직접 조립하지 않아도 되게 공통 바닥을 깔아 두는 자리입니다. 그 바닥을 하나의 제품처럼 만들어 내놓습니다. 쓰는 쪽은 사내의 다른 개발 팀 등 내부 사용자입니다. 무엇을 하는 일이냐는 물음의 답이 한 문장이 아니라 목록으로 열립니다.

쉽고 빠른 이해

서비스를 만드는 팀이 인프라를 매번 직접 조립하지 않도록, 공통 바닥을 하나의 제품처럼 만들어 내주는 일을 다룹니다. 예를 들어 새 프로젝트를 시작할 때 필요한 서버·배포 설정을 팀마다 직접 갖추는 대신, 미리 만들어 둔 웹 포털이나 템플릿에서 바로 받아 씁니다. 쓰는 쪽은 사내의 다른 개발 팀 등 내부 사용자입니다. 만드는 쪽은 플랫폼 팀이고, 내놓은 뒤에도 쓰는 팀에게서 피드백을 모아 계속 고칩니다.

한 문장으로 안 닫히는 이유는 무엇을 내주느냐를 쓰는 팀의 필요가 정하기 때문입니다. 쓰는 팀이 다르면 담기는 것도 달라져서, 답이 목록으로 열립니다.

안에서는 무엇을 정의로 삼느냐로 갈립니다.

팀이라는 조직 형태로 보는 쪽 — 플랫폼 팀을 두어 다른 팀의 부담을 줄인다고 봅니다
내놓은 물건으로 보는 쪽 — 직접 갖다 쓸 수 있는 도구와 서비스를 묶은 것이라고 봅니다
데브옵스라는 이미 있던 이름을 다시 붙인 것으로 보는 비판적인 쪽

상세

플랫폼 엔지니어링은 무엇을 만드는지가 아니라 어느 자리인지를 가리키는 말입니다. 자리를 정하는 것은 누구에게 무엇을 내주느냐입니다. CNCF(Cloud Native Computing Foundation, 클라우드 네이티브 컴퓨팅 재단) 앱 딜리버리 워킹그룹의 플랫폼 백서는 플랫폼부터 정의합니다. 클라우드 네이티브 컴퓨팅을 위한 플랫폼은 그 플랫폼 사용자의 필요에 맞춰 정의되고 제시된 역량들의 통합된 모음입니다. 여기서 역량은 팀이 갖다 쓸 수 있는 기능이나 서비스를 뜻합니다. 프로젝트를 시작할 때 거치는 절차를 프로젝트 템플릿과 문서로 미리 묶어 제공하기도 합니다. 이런 묶음을 흔히 골든 패스라고 부릅니다. 웹 포털이나 맞춤 API(Application Programming Interface, 응용 프로그램 인터페이스)나 골든 패스 템플릿처럼, 사용자가 직접 손에 쥐는 창구가 그 역량이 실제로 드러나는 모습입니다. 백서는 플랫폼을 이 범위를 가로지르는 계층이라고도 부릅니다. 넓은 범위의 애플리케이션과 사용례에 흔히 쓰이는 역량과 서비스를 얻고 붙이는 경험이 일관되게 유지되도록 하는 계층이라는 뜻입니다.

백서는 그 다음에 팀을 정의합니다. 플랫폼 팀은 플랫폼 역량에 닿는 그 인터페이스와 경험을 책임지는 팀입니다.

이름	백서가 적은 정의
플랫폼	사용자의 필요에 맞춰 정의되고 제시된 역량들의 통합된 모음
플랫폼 팀	플랫폼 역량에 닿는 인터페이스와 그 경험을 책임지는 팀

내놓는 방식에 이름이 붙어 있습니다. 백서는 플랫폼을 제품으로 다룬다고 적습니다. 플랫폼은 사용자의 요구를 채우려고 존재하고, 다른 소프트웨어 제품과 마찬가지로 그 요구를 근거로 설계되고 진화해야 한다고 적습니다. 플랫폼은 제품 팀들에 걸쳐 가장 흔한 사용례를 받쳐 줄 역량을 제공해야 한다고 적습니다. 전달되는 가치를 최대로 하려고 한 팀만 쓰는 더 특수한 역량보다 그쪽을 앞세워야 한다고 덧붙입니다.

한 문장 정의가 안 서는 이유가 여기서 드러납니다. 정의의 주어는 역량의 모음입니다. 그 모음 안에 무엇이 들어가는지는 사용자의 필요가 정합니다. 쓰는 쪽이 다르면 골라 담는 것도 달라집니다. 그래서 이 자리에서 무엇을 마주치느냐가 목록으로 열립니다.

경계

클러스터를 세우고 굴리는 일

쿠버네티스 클러스터를 세우고 굴리는 팀은 이 자리인가. 그것만으로는 아닙니다. CNCF 백서는 플랫폼 팀이 반드시 컴퓨팅이나 네트워크나 스토리지나 그 밖의 서비스를 직접 굴리는 것은 아니라고 적습니다. 플랫폼 팀은 관리형 제공자나 내부 인프라 팀에서 그 역량을 구할 수 없을 때에만 자기 역량을 직접 만들고 유지해야 한다고 적습니다. 대신 플랫폼 팀이 가장 크게 책임지는 것은 자기 플랫폼이 내주는 서비스와 역량의 인터페이스와 사용자 경험이라고 적습니다. 인터페이스의 예로는 그래픽 사용자 인터페이스와 명령줄 인터페이스와 API 를 듭니다.

굴리는 쪽은 스스로를 다르게 정의합니다. 쿠버네티스 공식 문서는 자기를 컨테이너로 만든 워크로드와 서비스를 관리하는 이식 가능하고 확장 가능한 오픈소스 플랫폼이라고 적습니다. 선언적 설정과 자동화를 모두 쉽게 해 준다고 덧붙입니다. 클러스터를 세워 굴리는 일은 그 정의 안쪽입니다. 그 위에 다른 팀이 스스로 쓸 수 있는 창구와 기본 경로를 얹어 제품처럼 내놓는 순간이 이 자리입니다.

선이 그어지는 자리를 백서가 한 문장으로 적습니다. 플랫폼 팀은 한쪽으로는 앞서 말한 내부 인프라 팀 등 인프라와 지원 서비스를 구현하는 팀들과 함께 일관된 경험을 정의합니다. 다른 한쪽으로는 제품 팀에게서 피드백을 모아 그 경험이 요구를 채우는지 확인합니다. 두 방향이 다 있어야 이 자리입니다.

flowchart TD
    I["인프라·지원 서비스 팀"] -->|함께 정의| P["플랫폼 팀"]
    P -->|인터페이스·경험을 내줌| U["제품 팀"]
    U -->|피드백| P

이견

이 자리를 무엇으로 정의하느냐가 진영마다 갈립니다.

CNCF 백서는 서로 다른 두 정의를 나란히 인용합니다. 한쪽은 Atlassian 의 말입니다. 플랫폼 팀은 여러 스트림 정렬 팀 — 백서가 이 인용문 안에서 제품 팀이라고 풀어 쓴 이름입니다 — 이 적은 오버헤드로 쓸 수 있는 역량을 만든다고 적습니다. 플랫폼 팀이 스트림 정렬 팀의 자원과 인지 부하를 최소로 줄인다고 적습니다. 서로 다른 사용자 경험이나 제품에 걸치는, 하나로 이어진 경험을 만들 수 있다고 덧붙입니다. 정의의 주어가 팀이라는 조직 형태입니다.

다른 한쪽은 Martin Fowler 와 Evan Bottcher 의 말입니다. Bottcher 는 자기 글에서 디지털 플랫폼을 셀프서비스 API 와 도구와 서비스와 지식과 지원의 바탕이라고 정의합니다. 그것들이 매력적인 내부 제품으로 짜여 있다고 적습니다. 자율적인 딜리버리 팀들이 그 플랫폼을 써서 더 높은 속도로, 더 적은 조율로 제품 기능을 낼 수 있다고 이어 적습니다. 정의의 주어가 팀이 아니라 내놓은 물건입니다.

정의마다 쓰는 쪽을 부르는 이름이 다릅니다. 백서는 제품 팀이라 부르고, Atlassian 은 스트림 정렬 팀이라 부르고, Fowler·Bottcher 는 자율적인 딜리버리 팀이라 부릅니다. 가리키는 것은 같습니다 — 앞서 개요와 상세에서 개발 팀이라 부른, 플랫폼을 갖다 쓰는 그 내부 사용자입니다.

같은 글이 비판도 함께 싣습니다. Bottcher 는 Phil Calçado 의 말을 인용합니다. 잠깐, 이건 잘못 만든 데브옵스 팀이 아니냐고 묻습니다. 그럴 수도 있다고 스스로 답합니다. 데브옵스도 원래는 특정 역할·팀·도구를 가리키는 말이 아니었습니다. 그런데도 결국 역할이나 팀이나 도구로 굳어지는 것을 막지 못했다고 지적합니다. 이런 싸움에서 매번 지고 있다고 적습니다. 다음번에는 새 전략이 필요할지 모르겠다고 덧붙입니다.

어느 쪽이 맞는지는 여기서 판정하지 않습니다. 같은 자리를 한쪽은 팀을 어떻게 두느냐로 정의합니다. 다른 쪽은 무엇을 내놓았느냐로 정의합니다. 또 다른 쪽은 이미 있던 이름을 다시 붙인 것으로 봅니다.

플랫폼 엔지니어링

상세

경계

클러스터를 세우고 굴리는 일

이견

관련 항목

이것이 내놓는 산출물

이것이 딛고 선 기반 기술

이것을 재는 지표

이것에 관여하는 역할·참여자

이것에서 자주 나는 오류·장애

헷갈리는 이웃