알림: 이 글은 martinfowler.com 의 What I Talk About When I Talk About Platforms 을 번역(의역)한 것입니다.
효과적인 디지털 플랫폼이 제공 규모를 확장하는 데 도움이 되는 이유, 플랫폼에 포함되어야 하는 내용, 플랫폼 구축을 시작하는 방법에 대해 알아봅니다.
요즘엔 모두가 디지털 프로덕트(Digital Product) 를 대규모로 빠르게 제공하기 위해 '플랫폼'을 구축하고 있죠.
반면에, 일부 조직은 조직 구조와 운영 모델을 먼저 다루지 않고, 기존의 공유 서비스를 기반으로 구축하려고 시도하면서 어려움을 겪고 있어요.
그렇다면 무엇이 효과적인 디지털 플랫폼을 만들까요? 같이 알아봅시다.
어쨌든 '플랫폼'은 무엇일까요?
'플랫폼'이란 단어를 처음 들었을 때 모호하게 느껴질 수 있어요. 굳이 설명하자면 규모에 따른 전달 속도와 효율성을 높이는 데 매우 중요한 접근 방식에 대한 추상적 개념이죠. 그래서 이 모호함을 해결하기 위해 글을 쓰게 되었습니다. 제가 업계에서 지금껏 일하며 이야기해 온 내용들을 정리해보았습니다.
비유하자면 우리가 대부분 잘 아는 '소프트웨어 및 하드웨어 플랫폼'에 대한 이해는 대체로 다음과 같을 거에요. 일반적으로 응용 프로그램이 실행될 수 있고, 파일 시스템 및 보안과 같은 재사용 가능한 기능을 제공하는 운영 환경을 말하죠.
'디지털 플랫폼' 은 이보다는 생소한 개념이겠지만, 조직 수준에서 확대하면 위와 유사한 특성을 가져요. 운영 환경이 제공하는 재사용 가능한 기능들을 통해 개발팀이 프로덕트(Product)를 보다 신속하게 제공할 수 있게 해주죠.
디지털 플랫폼(Digital Platform)은 셀프 서비스(Self-Service) API, 도구, 서비스, 지식 및 지원(Support) 등을 제공하는 기반이에요. 강력한 내부 프로덕트죠. 내부 팀은 플랫폼을 활용하여 공동 작업을 줄일 수 있어요. 즉, 다른 역할의 팀과 협업하며 나타나는 의존성과 소통에 소비되는 시간 지연을 피할 수 있죠. 따라서 더 빠른 속도로 제품을 지속적으로, 자율적으로 배포할 수 있습니다.
Thoughtworks에서는 플랫폼 기능의 5가지 핵심 요소(링크 1, 링크 2)를 정의하는 모델을 개발했습니다. Delivery Infrastructure, Architecture and API Remediation, Self-Service Data, Experiment Infrastructure and Telemetry, 및 Customer Touchpoint Technology 가 포함됩니다. 우리는 글로벌한 경험을 통해 이 요소들이 디지털 기업이 되기 위한 가장 중요한 공유 역량이라는 것을 배웠어요.
이 글은 플랫폼의 기능들 중, 저희가 딜리버리 인프라(Delivery Infrastructure) 로 정의한 것에 초점을 맞추고 있어요. 클라우드 호스팅 및 데브옵스(DevOps) 도구를 포함하는 영역이죠. (다만 위에서 언급한 5요소 중, 딜리버리 인프라 이외의 플랫폼 기능들에도, 이 글에서 소개된 것과 동일한 특성들이 적용될 수 있습니다.)
첫째, 비(非)플랫폼
몇년 전, 저는 호주의 대규모 금융 서비스 기관(이하 BigCo)에 대해 컨설팅 업무를 맡았습니다.
현장에 도착하고 바로 첫 번째 목표를 세웠어요. 애플리케이션 인프라, 호스팅 및 운영 영역에서 무슨 일이 일어나고 있는지 알아보는 일이었죠. 해결해야 할 과제가 어디에 있는지 제대로 이해하는 것이 중요했어요. 우리는 작업 시스템을 통해 실제 변화를 추적하고 작업이 어떻게 수행되는지 살펴보기로 결정했습니다.
BigCo 는 클라우드 및 자동화에 대해 대규모로 투자하고 있었습니다. 하지만 그럼에도 불구하고 인프라 및 운영 영역에서 전통적인 팀을 유지하고 있었어요. 이 '전통적인 팀'은 주된 기술 역량에 따라 구성되어 있었죠. 우리는 몇 가지 일반적인 변경 사항이 회사에서 어떻게 수행되는지 그 전 과정을 따라가 보았습니다. 각 변경 사항에는 여러 팀이 참여했습니다. 애플리케이션 서버 구성에 변경해야 할 사항이 있던 이슈는 우선 '미들웨어(Middleware) 팀'이 담당했습니다. 그런데 미들웨어 팀은 곧 기본 운영체제의 시스템 설정을 변경해야 할 상황을 맞닥뜨렸죠. 하지만 이는 미들웨어 팀이 아니라 '미드레인지(Midrange) 팀'의 고유 권한이었습니다. 미들웨어 팀은 도중에 미드레인지 팀에게 작업의 일부를 부탁해야 했죠. 운영체제 설정 뿐 아니라 다른 분야도 마찬가지였습니다. 데이터베이스에 대한 것은 '데이터베이스 관리자(DBA) 팀'에게, 네트워크에 대한 것은 '네트워크 팀'에게 부탁해야 했습니다. 오케스트레이션(Orchestration)을 주로 처리하는 운영 자동화 팀은 물론이고, 엔터프라이즈 모니터링, 보안, 변경 및 릴리스 관리를 처리하는 팀도 따로 있었습니다. 더해서 로드 밸런서나 방화벽에 대한 변경은 회사가 직접 할 수 없었는데, 각기 다른 관리형 서비스 공급자(Managed Service Provider)를 통해서 해결해야 했습니다.
(그림 1: 고도로 전문화된 인프라 및 운영팀 분리)
사내의 각 팀은 독립적이었습니다. 각자의 기술 영역에서는 높은 효율성을 지녔고, 전문화되었죠. 차별화되지 않는 기능은 아웃소싱했고, 거버넌스를 적용했어요. 비용도 절감했죠. 그러나 이 모든 것은 각자의 영역에서였을 뿐, 고객에게 기능을 엔드 투 엔드로 제공하는 효율성을 측정하지는 않았습니다.
이런 이유로 인프라와 관련된 작은 변경일지라도 수행되기까지 느릴 수밖에 없었습니다. 몇 주에서 몇 달이 걸리며 고객 대응에 큰 영향을 미쳤죠. 간단하지 않은 변경이라면 더더욱 느려짐은 말할 필요도 없었습니다. 이로 인해 엔지니어와 관리자는 꼭 필요한 것이 아니면 가능한 한 변경 횟수를 최소화하려는 경향을 띄게 되고 말았죠.
(그림 2: 애플리케이션 제공 팀에서 요구하는 변경 작업에는 몇 주 또는 몇 달이 소요됩니다.)
BigCo 에서는 이로 인해 애플리케이션과 인프라의 내부 품질이 점진적으로 저하되었습니다. 환경 및 구성 설정에 약간의 불일치가 여기저기 발생하기도 했죠. 꼭 필요한 변경이 아니면 꺼려하다보니 작고 사소한 개선들이 이루어지지 않고 있었어요. 품질과 일관성을 위한 리팩토링이 잘 진행되고 있지 않았다는 이야기죠.
그런데 이러한 성향은 실제로 스스로 강화되는 경향이 있습니다. 이렇게 각 팀이 서로 영향을 주고 받는 환경에서 누군가 실수하지 않기 위해서는 예측 가능성이 중요하다고 느꼈을 겁니다. 사내 인원들 스스로 예측 가능성을 중시하게 되면서, 무언가 개선하고 바꾸는 일은 갈수록 보수적으로 검토되게 되었죠. 어떤 부분을 변경하면 지금까지와는 다른 행동양식을 띄게 되어 예측 가능성이 줄어들 수 있으니까요.
요약하면 BigCo 에서 인프라와 호스팅을 다루는 것은 느리고 어려웠습니다.
"백로그 결합(Backlog Coupling)" 의 영향
민첩한 소프트웨어 제공을 위해 손쉽게 얻을 수 있는 성과는 항상 디지털 채널에 있었습니다. 비즈니스 리더는 고객의 요구 사항을 식별하고 있고, 소규모 자율 팀은 그들과 긴밀히 협력하여 이를 충족하는 기능을 구축하죠. 그러나 디지털 프로덕트 팀이 더 기민하게 대응할 수록, 외적인 제약사항은 더욱 커집니다
일반적으로 디지털 팀을 괴롭히는 세 가지 주요 영역이 있죠. 굼뜨게 움직이는 핵심 트랜잭션 기록 시스템, 고품질 데이터 및 분석에 대한 액세스, 공유 인프라 및 운영입니다.
저는 '백로그 결합(Backlog Coupling)'이라는 용어를 사용합니다. 여기서 백로그는 애자일(Agile) 딜리버리(Delivery) 팀에서 자주 사용하는 계획 도구입니다.
(그림 3: 변경 사항이 여러 팀의 백로그(작업 대기열)에 걸쳐 종속성을 가질 때 백로그 결합이 발생합니다.)
이는 간단한 개념이에요. 어떤 팀이 백로그를 만들었다고 해보죠. 만약 그중 많은 항목이 다른 팀에서 또 다른 백로그를 만들게 유도한다면 어떨까요? 또 그렇게 했을때 비슷한 연쇄 효과가 연달아 일어난다면요? 이러면 생산성과 대응력이 엄청나게 저하됩니다. 이 백로그들은 조직 전체에 걸쳐 서로 연결되긴 하지만, 각자 서로 다른 작업 체계에 따라 우선순위가 지정됩니다. 최종적으로 일을 해결하기까지의 과정이 복잡해진다는 소리죠. 아마 이런 상황에서 칸반(Kanban)을 보면 해당 작업에는 'blocked' 라는 큰 빨간색 스티커가 붙여있지 않을까요? 이해관계자는 한숨을 쉬고 있겠죠. 여러 팀이 공유하는 서비스를 담당하고 있는 쪽에선 각 팀의 서로 다른 요구사항에 대응하려고 이리저리 분주할 겁니다. 뭐, 그래봤자 가장 큰 목소리를 가진 팀에 우선 반응해주는 게 최선일 테지만요.
백로그 결합이 구체적으로 대략 얼마나 나쁠까요? 호주의 한 통신 회사에서 제 동료들이 수치적으로 연구한 이야기를 들려드릴게요. 그들은 Delivery 단계를 통과하는 수백 가지 작업에 대해 살펴보았습니다. 일부 작업은 종속성 없이, 다른 팀 구성원과의 협업 없이 단일 팀에서 완료할 수 있었어요. 반면 다른 팀을 기다려야 하는 작업의 경과는 대개 10 ~ 12배 정도 더 느렸죠. 종속성은 실제로 지대한 영향을 미친다는 것을 정량적으로 알 수 있었습니다.
이건 여러 면에서 우리에게 해를 끼쳐요. 우선 순수한 업무 처리량과 고객 요구에 대한 대응력에 부정적인 영향을 미치는 게 자명하죠. 그리고 우리는 종속성을 보다 효율적으로 관리하기 위한 보다 장기적인 계획을 세우도록 유도"당합니다". 이런 문화는, 어떤 결과던 '하나의 단일 팀이 주된 책임을 지도록 하는 지향성'(accountability)을 저하시키고, 많은 팀의 동기 부여를 죽이는 것을 목격했어요. 팀들은 쉽게 서로 책임을 전가하고 지속적인 개선 추구를 중단하게 될 수도 있습니다.
그리고 사내의 여러 팀에게 공유되는 서비스를 맡는 팀에도 과부하가 걸리죠. 그런 팀에 일하면서 여기 저기 휘둘리는 건 그리 재미있는 일이 아닙니다.
최근 '애자일 확장'(Scaling Agile)의 전통은 이 문제를 한 가지 방식으로 해결하려고 합니다. 여러 팀에 걸쳐 우선순위를 조정하는 세레머니(Ceremony)를 도입하는 방법입니다. 백로그 결합을 생성되는대로 두지 않고, 연쇄적인 우선순위를 세부 조정하는 겁니다. 이 방법은 문제 해결에 도움이 되기는 하지만 치러야 할 대가가 있죠. 전반적으로 각 팀의 자율성과, 변화에 자체 대응하는 능력이 줄어듭니다. 저는 이것이 우리가 택해야 할 유일한 방법이라 말하고 싶지 않군요.
따라서 좋은 '플랫폼'의 우선적인 특징은 가능한 최대로 백로그 결합의 양을 줄이는 것이어야 해요. 플랫폼은 티켓을 제기하고 작업을 할당할 필요가 없는 서비스를 제공해야 합니다. 셀프 서비스(Self-Service) 는 좋은 플랫폼의 주요 특징을 정의합니다.
플랫폼은 팀에게 셀프 서비스 접근(Self-Service Access), 셀프 서비스 프로비저닝(Self-Service Provisioning), 셀프 서비스 구성(Self-Service Configuration), 셀프 서비스 관리(Self-Service Management), 셀프 서비스 운영(Self-Service Operation) 을 허용해야 합니다.
허술한 피상적인 프라이빗 클라우드
자, BigCo 는 셀프 서비스(Self-Service)의 필요성을 인식했습니다. 그러나 지금껏 일해 오며 익숙해진 사고 방식과 이미 확립된 레거시(Legacy) 인프라로 인해서 어떻게 해야 좋을지 판단하는 데 어려움을 겪었죠. 중앙 집중식 자동화 도구에 대한 투자는 이미 있었기 때문에, 첫 번째 노력은 애플리케이션 딜리버리(Delivery) 팀이 인프라를 셀프 프로비저닝(Self-Provisioning) 할 수 있는 셀프 서비스 기능을 만드는 것이었습니다.
우선 셀프 서비스 도구(Self-Service tool)는 딜리버리(Delivery) 팀이 매우 고정된 템플릿을 사용해 온디맨드로 컴퓨팅 인스턴스를 요청할 수 있도록 구축되었어요. 프로비저닝된 가상 머신 인스턴스는 구성이 고정되었으며 보안적으로 안전하게 잠겨 중앙 미드레인지(midrange) 팀이 전체 인스턴스들을 한번에 제어할 수 있도록 했습니다. 다만 이는 딜리버리(Delivery) 팀이 스스로 인스턴스에 추가적인 작업을 할 수는 없다는 것을 의미해요. 예를 들면 패키지 설치, 네트워크 연결, 스토리지 연결, 로드 밸런서 프로비저닝, 모니터링 도구 구성 등 딜리버리(Delivery) 팀 입장에서 인스턴스에 유용할 것으로 기대되는 어떤 작업을 수행하려면 미드레인지(midrange) 팀에게 티켓을 생성해야 합니다. 딜리버리(Delivery) 팀 입장에선 전과 같이 여전히 답답하게 느껴질 만한 제약 사항이죠.
(그림 4: BigCo 는 애플리케이션과 인프라 실행 방식의 기본 사항을 변경하지 않고 기본적인 셀프 서비스 API 를 구축했습니다. 결과적으로 제공(Delivery) 속도에는 큰 변화가 없었습니다.)
음 혹자는 일단 이 제약을 비판하기에는 이르다고 생각할 수도 있습니다. 이건 단지 첫번째 이터레이션(Iteration)이었을 뿐이니까요. 첫술에 배부르랴? 맞는 말입니다. 하지만 여기에는 BigCo 의 인프라 및 운영 팀의 의도가 담겨있었습니다. 우선 인프라 및 운영 팀은 당시 자체 조직 사일로를 무너뜨리고 중요한 책임(결과적으로 접근 권한)을 딜리버리(Delivery) 팀에 넘길 준비가 되어있지 않았어요. 또한, 제약을 없애고 셀프 서비스를 온전히 가능하게 할 API를 충분히 구축하는 데 필요한 노력이 적어도 당장은 실행 가능하지 않다고 판단하고 있었습니다.
우리는 이러한 유형의 접근 방식을 '피상적 프라이빗 클라우드'(Superficial Private Cloud)라고 부릅니다. 즉, 중앙에서 제어하는 양은 줄이지 않고 매우 제한된 방식으로 딜리버리(Delivery) 팀이 사용할 수 있도록 하려는 접근방식입니다. 기존에 사용하던 가상화 플랫폼을 크게 바꾸지 않고 포장만 그럴듯하게 하는 것이라 할 수 있죠.
한편 BigCo 에서는 병행된 노력으로 딜리버리(Delivery) 팀이 AWS 를 직접 사용할 수 있도록 기능을 잠금 해제했습니다. 선례가 확립되자 많은 다른 프로덕트의 딜리버리(Delivery) 팀들이 AWS를 사용하기 위해 몰려들었습니다.
AWS 는 딜리버리(Delivery) 팀이 직접 사용할 수 있는 강력한 플랫폼입니다. 완전한 셀프 서비스라고 할 수 있고, 책임의 경계가 명확하죠. 말 그대로 "You build it, you run it" 입니다. AWS 은 플랫폼의 가용성(Availability)을 보장하고, 충분한 수준의 API 를 제공합니다. 애플리케이션 딜리버리(Delivery) 팀은 그 위에서 애플리케이션을 구축(build), 구성(configure) 및 실행(run)할 수 있죠.
(역주: "You build it, you run it" 은 데브옵스 세계에서 아주 유명한 어구입니다. 2006년 Amazon 의 CTO 였던 Werner Vogels가 처음 언급했고, 데브옵스 시대의 서막을 알리는 말이 되었습니다. 말 그대로 소프트웨어를 개발하는 사람(팀)이 실행 및 운영까지 수행한다는 의미입니다.)
근데 설마 이게 이야기의 끝일까요?
자율성은 시장 출시 시간을 단축하고 혁신을 강화합니다.
제가 만난 대부분의 조직에는 '재사용을 위한 구축'(build for re-use)이라는 기본 철학이 있었습니다. 즉, 미래를 염두에 두고 기능들을 중앙에 집중화하여 만들어 두면, 나중에 재사용하여 비용을 절감하면서도 이미 검증된 기능으로 위험을 회피할 수 있다는 것입니다.
(그림 5: 대부분의 조직은 기본적으로 비용 효율성을 얻기 위해 중앙에서 기술을 선택 및 강제합니다.)
지난 몇 년 동안 저는 운이 좋게도 호주의 주요 테크 회사에서 기술 리더십 팀의 일원이 되었습니다. 수백 명의 엔지니어를 보유하고 있는 글로벌 회사이기도 했고 온라인으로도 큰 영향력을 발휘하는 곳이었죠.
이번엔 이 곳을 편의상 WebBiz 라고 명칭해볼게요. 아주 큰 조직은 아니었지만 딱 BigCo 와 동일한 종류의 과제에 직면할 만큼의 규모는 있던 곳이었습니다. 인프라, 애플리케이션 및 데이터 측면에서도 적지 않은 레거시(Legacy)를 보유하고 있었죠. 그러나 이미 말했듯 거대한 회사는 아니었기에 비교적 빠르게 개선해 볼 수 있을 만큼은 작았습니다.
처음 WebBiz 는 임대 데이터 센터의 가상화 플랫폼(Virtualized Platform)을 사용하고 있었습니다. 이후 AWS로 다년간의 마이그레이션을 시작했죠. 그러면서 동시에 애플리케이션과 인프라의 빌드와 실행에 대한 책임도 조정했습니다. 중앙화된 운영 팀만이 가지던 권한을 개별 프로덕트 팀들이 자율적으로 수행하도록 한 것이죠. 제가 목격한 전통적인 중앙 운영에서 데브옵스(DevOps)으로의 가장 완전한 전환이었습니다. 저는 "You build it, you run it" 이라는 사고방식으로 소규모 조직을 시작하는 것이 실제로 그리 어렵지 않다고 생각해요. 그러나 반대로 기존의 전통적인 방식으로 해오던 규모 있는 조직을 새로 전환하기 위해서는 용기와 비전의 연속성이 필요합니다. WebBiz 는 그 점에서 매우 좋은 성과를 거두었습니다.
마이그레이션의 일환으로, WebBiz 의 프로덕트 팀에는 스택의 모든 부분을 구성하고 실행하는 방법에 대한 완전한 자율권이 부여되었어요. 이 접근 방식은 '팀 관리 인프라'(Team-Managed Infrastructure)로 명명되었습니다. 초기에 몇 가지 (중앙화 된) 고정값이 설정되어 있었지만, 각 팀은 중앙의 개입을 거의 받지 않고 스택의 모든 부분에 대해 자체적으로 결정을 내렸습니다.
WebBiz 는 기존 조직의 일반적인 편견을 성공적으로 뒤집었죠. 결과적으로 각 팀마다 다른 기술은 조직의 다양화를 불러왔어요. 또한 필요만 있다면 새로운 기술을 만드는 것(invention)을 선호하는 분위기도 정착되었죠. 새로운 기술들이 창조되었고, 각 엔지니어는 기술 스택에 대해 더 깊은 경험을 쌓을 수 있었습니다. 배포된 항목에 대한 책임 수준도 전과 달리 신속하게 설정되었죠. 팀 의존성은 크게 제거되었습니다. 말인즉슨, 전반적으로 모든 직원이 스스로 정해 직접적으로 참여하는 일의 비중이 높아졌다고 봐야죠. 이건 채용에도 유리했습니다. 자신이 원하는 기술을 선택하고, 자율적으로 어려운 비즈니스 및 기술 문제에 도전해 일을 처리하며, 스스로 책임을 지는 문화는 많은 인재들에게 매력적으로 어필되었거든요.
기술 다양화로 항력(drag) 증가
그러나 모든 이점에도 불구하고 완전한 자율성으로 전환하려면 확실한 비용이 필요합니다. AWS 를 플랫폼으로 채택함으로써 중앙 집중식 인프라 팀에 대한 백로그 결합(Backlog Coupling)을 제거하는데 유의미한 도움을 받았습니다. 그러나 AWS 만으로 인프라에 대한 모든 해결책이 될까요? 아닙니다. 그 외에도 선택할 것은 많죠. 여전히 모든 팀은 인프라 구축 및 운영의 모든 측면에 대해 또 다른 영역에서 일련의 결정을 내려야 합니다.
(그림 6: 클라우드 네이티브 랜드스케이프(Cloud Native Landscape) [출처: www.cncf.io])
위는 CNCF(Cloud Native Computing Foundation) 가 제공하는 클라우드 네이티브 랜드스케이프(Cloud Native Landscape) 의 최신 버전입니다. 클라우드 네이티브 아키텍처 구축 시 관심 영역별로 그룹화된 몇 가지 일반적인 오픈 소스 및 제품 제공을 포착하려는 시도라고 할 수 있죠. 생태계에서 가장 잘 확립된 지도라고 할 수 있는데, 이런 저런 기술로 꽤나 붐비는군요. 이 많은 기술들 중에서, 각 팀은 요구 사항에 가장 적합한 제품을 선택할 수 있어야 합니다. 그리고 해당 제품을 통합하고 운영하는 방법을 배워야 하겠죠.
역주: 저자가 클라우드 네이티브 랜드스케이프(Cloud Native Landscape) 를 최신 버전이라고 했지만, 이는 2018년 초까지의 기준입니다. 해당 이미지는 v1.0 이고, v2.0이 2018년 3월 릴리즈되었습니다. 번역을 하는 2024년의 지금은 위의 이미지보다 "훨씬" 많은 기술이 클라우드 네이티브 랜드스케이프에 포함되어 있습니다. 하지만 특정 기술의 분포와 관계없이, 2018년이던 2024년이던 저자가 말하고자 하는 바는 달라지지 않습니다. 회사가 중앙에서 스택을 통제하지 않기로 했으니, 각 팀이 자율적으로 선택 가능한 수많은 기술들이 있습니다. 클라우드 네이티브 랜드스케이프는 그것을 직관적으로 보여주는 대표적인 예시일 뿐입니다. 저자는 그저 AWS 와 같은 클라우드 서비스 제공자(Cloud Service Provider; CSP)에 대한 권한을 각 팀에게 부여하는 것만으로는 부족하다고 말하고 있습니다. 사내에서 만든 '플랫폼'이 클라우드 서비스 제공자는 물론, 클라우드 네이티브 랜드스케이프와 같은 별개의 기술 및 서비스도 같이 유기적으로 품을 수 있어야 한다는 것입니다. 즉, 쉽게 비유해서 애플리케이션 팀이 클라우드 네이티브 랜드스케이프를 들여다보면서 수많은 기술들에 대해서 시류를 살피고 공부하며 인프라에 관한 세부 설치 및 구성을 직접 하도록 두기 보단, 플랫폼 팀이 이를 대신해 플랫폼으로서 기능을 제공하자는 의미입니다. 물론 플랫폼 팀이 클라우드 네이티브 랜드스케이프의 수많은 기술에 대한 사전 설정을 모두 제공해줄 수는 없습니다. 대신, 사내에서 대다수의 수요를 커버할 수 있을 정도 만큼의 다양성만 사전 제공하면 된다는 것입니다. '파레토 법칙'을 생각하면 됩니다. 풀어 말하자면 생태계에 10개의 기술이 있을때, 회사에서 집중적으로 쓰일 2개만 플랫폼으로 제공해도, 80% 의 사내 수요를 감당할 수 있습니다. 나머지 20% 는 아마 나머지 8개 기술에 대한 수요로 흩어져 있어서 플랫폼으로 제공하기에는 노력 대비 효과가 적을 겁니다. 이 이율배반은 다음 섹션인 "내부 제품(Internal Product)으로서의 플랫폼" 에서 자연스레 이어지는 흐름으로 다루어집니다. 파레토 법칙에서 20% 에 속하는 소수 케이스의 경우, 즉 플랫폼이 제공해주기 어려운 수요의 경우, '포장된 도로'(Paved Road) 가 아니라 자체적인 대안(스스로 개척한 도로)을 허용한다는 Netflix 의 사례도 그러한 맥락으로 언급되는 것입니다. 대신 그런 팀은 지원되지 않는 기술과 방법을 택한 이유에 대해 스스로 좋은 결과로서 책임 져야 합니다.
기술은 빠르게 발전합니다. 보다시피 선택할 옵션도 많죠. 그런데 이 모든 기술에 전문가인 사람은 아마 거의 없을 겁니다. 따라서 각 팀이 인프라에 대한 선택 사항을 지속적으로 조사하고 평가해야 하는 오버헤드는 분명 있다고 할 수 있습니다. 또 서로 다른 팀 사이에 기술 또는 팀원을 이전하는 경우, 마찰(friction)도 발생할 수 있죠.
이 문제는 어떻게 해결할까요?
그 답으로 WebBiz 는 이제 보다 명확하게 정의된 딜리버리 인프라 플랫폼(Delivery Infrastructure Platform)을 구축하기 시작했습니다. 여러 기본값(default)들이 사전에 정의된 세트로 주어진다고도 볼 수 있는데요. 덕분에 프로덕트 팀 입장에서는 부담이 줄어들고 (인프라가 아닌 애플리케이션 자체에 집중함으로서) 생산성을 높이는 도움을 받을 수 있었습니다.
하지만 이렇게 함으로서 혹시 역으로 자율성이 가져온 이점을 잃을 위험이 있지는 않을까요?
내부 제품(Internal Product)으로서의 플랫폼
우리는 항상 트레이드 오프에 마주칩니다. 자율적인 다양화(Autonomous Diversification)와 의무적 통합(Mandated Consolidation)도 그렇죠. 그 사이에서 올바른 균형을 찾아가는 것은 금방 되는 일이 아니에요. 사전에 스위트 스팟(Sweet Spot)을 예측하기는 훨씬 더 어렵습니다. 이러한 균형을 찾아가는 데 성공하기 위한 핵심 요소는 플랫폼이 사용자 입장에서 매력적이어야 한다는 것입니다.
플랫폼을 설득력있게 만드는 것은 무엇일까요?
다음은 몇 가지 아이디어입니다.
- 플랫폼은 사내에서 요구되는 (전부는 아니지만) 대다수의 사용 사례(Use Case)를 커버할 수 있는 셀프 서비스(Self-Service)입니다.
- 플랫폼은 구성(조합) 가능하며, 독립적으로 사용할 수 있는 개별 서비스를 포함합니다.
- 플랫폼은 딜리버리(Delivery) 팀에게 융통성 없이 딱딱한 작업 방식을 강요하지 않습니다.
- 플랫폼은 쉬운 진입로(예: 빠른 시작 가이드, 문서, 코드 샘플)를 통해 빠르고 저렴하게 사용을 시작할 수 있습니다.
- 플랫폼에는 공유를 위한 풍부한 내부 사용자 커뮤니티가 있습니다.
- 플랫폼은 기본적으로 안전하고 규정을 준수합니다.
- 플랫폼은 최신의 상태입니다.
예를 들자면 위의 항목에 많이 해당할수록 사용자 입장에서 합리적인 플랫폼이라 느낄 겁니다. 궁극적으로 정리하면 딜리버리 인프라 플랫폼(Delivery Infrastructure Platform)은 각 팀이 편리하게 플랫폼 기능을 사용할 수 있도록 해야 합니다. 그냥 손쉽게 플랫폼을 이용하는 것이 별도로 자신만의(각 팀만의) 것을 구축하고 유지하는 것보다 유익하다고 생각될 때 비로소 플랫폼의 역할이 의미있어집니다.
이것과 관련해서, Netflix 는 중앙 집중식 도구(Centralised Tooling)를 "포장된 도로"(Paved Road)라고 설명합니다. 우선 각 팀이 꼭 이러한 중앙화된 도구나 플랫폼을 사용하도록 강제되지는 않아요. 만약 어떤 팀이 회사에서 이미 잘 닦아놓은 "포장된 도로"가 아니라 비탈길을 스스로 개척하면서 도로를 만들어간다면 그것도 충분히 용인됩니다. 단, 해당 팀은 스스로 자체적인 대안(스스로 개척한 도로)을 유지하는 데 드는 모든 비용과 결과를 책임져야 합니다.
(역주: 플랫폼 엔지니어링의 영역에서는 "골든 패스"(Golden Path)라는 용어도 종종 사용됩니다. "포장된 도로"(Paved Road) 와 둘다 "길"로 비유한다는 점은 공통점이지만, 서로 다른 개념입니다. 전자는 공통적인 관심사에 대한 템플릿에 가깝고, 후자는 중앙화되면서 검증된 도구를 의미합니다.)
문단을 종합적으로 짧게 정리하자면, 플랫폼은 단순한 소프트웨어나 API 그 이상이어야 합니다. 즉, 문서화, 컨설팅, 지원 및 에반젤리즘(Evangelism), 템플릿 및 지침을 포괄하는 개념이 되어야 합니다.
잠깐만요, 이거 "데브옵스(DevOps) 팀" 아닌가...요?
나쁘게 끝났나요?
어쩜, 그럴 수도요.
(저는 아직 데브옵스(DevOps) 논쟁에서 패배를 인정할 준비가 되지 않았습니다. 만약 독자님의 회사에 'DevOps' 라는 팀이 있다면, 제가 의미하는 DevOps 와 다른 의미일 겁니다.)
(역주: 데브옵스 개념이 등장했을 때에는 특정한 협의(狹義)가 아니라, 문화 그 자체이자 철학으로 정의하는 입장이 많았습니다. 그러나 시간이 지나며 반대로 특수성을 띈 역할이나 팀, 도구와 같이 특정한 개념을 지칭하는 사례도 생겼습니다. 또는 기존의 운영팀을 거의 그대로 이름만 데브옵스 팀으로 바꾸는 경우도 있었습니다. 이를 보고 데브옵스라는 개념을 잘못 언급하지 말자며 지적하는 분위기도 생겼습니다. 그러나 오히려 반대로 데브옵스의 정의가 현실적으로 문제가 있다는 등 이를 비판하는 목소리도 존재했습니다. 반면 데브옵스의 구체성이 모호하여 서로 다른 개념과 사례를 같은 단어인 데브옵스로 지칭하게 되어 대화할수록 오해가 쌓인다던가 하는 의견도 있었습니다. 저자는 데브옵스 개념이 처음 등장했을 때부터 지금까지 동일하게 순수한 입장을 고수하고 있다는 의미입니다.)
딜리버리 인프라 플랫폼(Delivery Infrastructure Platform)을 구축(build)하고 운영(operate)하기 위해 팀을 구성할 수도 있습니다. 대부분 이것이 처음 시작하는 가장 좋은 방법이 될 것이라고 생각하고요. 그렇다면 '플랫폼 팀'과 '고객'의 책임 범위를 매우 명확하게 해야 합니다. 아 여기서 '고객' 이라 함은, 플랫폼의 내부 사용자입니다. 명확성을 위해 이를 구체적으로 '애플리케이션 팀'이라고 지칭해볼게요.
애플리케이션 팀은 애플리케이션을 구축(bulid), 배포(deploy)하고 모니터링(monitoring)을 수행합니다. 그리고 플랫폼에서 프로비저닝하고 배포하는 애플리케이션 구성 요소(component)와 애플리케이션 인프라에 대해 직접 작업하고 실시간 운영해야 합니다.
플랫폼 팀은 마찬가지로 플랫폼을 구축(build), 배포(deploy)하고 모니터링(monitoring)을 수행해야 하죠. 역시 플랫폼 구성 요소와 플랫폼 인프라에 대해 직접 작업하고 실시간 운영해야 합니다.
플랫폼 팀은 이상적으로는 플랫폼에서 어떤 애플리케이션이 실행되고 있는지조차 몰라도 괜찮아야 합니다. 오직 플랫폼 자체의 가용성(Availability)만 책임지면 됩니다.
이러한 방식으로 애플리케이션 팀과 플랫폼 팀 모두 자체 제품의 빌드 및 실행에 대한 책임을 집니다. 애플리케이션 팀의 프로덕트는 애플리케이션이고, 플랫폼 팀의 프로덕트는 플랫폼입니다. "You build it, you run it" 이라는 말은 여전히 적용됩니다.
어디서부터 시작해야 해요?
딜리버리 플랫폼(Delivery Platform) 구축에 성공하기 위해서는 몇 가지 사전조건이 있어요.
첫째, 당신이 이미 '프로젝트'에서 벗어나는 여정을 이미 시작했어야 해요. 플랫폼은 프로덕트(Product)입니다. 플랫폼을 제품으로 취급하기 위해서 구축(build)와 실행(run)을 모두 담당하는 장기적이고 안정적인 제품 팀이 필요해요.
둘째, 애플리케이션 실행 책임의 일부 또는 전부를 중앙 집중식 운영(Centralised Operation)에서 벗어나 애플리케이션 팀으로 기꺼이 전환해야 합니다. 대신 플랫폼은 애플리케이션 팀이 자신이 구축한 것에 대해 책임을 질 수 있도록 도구와 서비스를 제공하죠. 중앙에서 일방향적으로 세부 지원(support)을 하는 경우에는 이런 일이 일어나지 않으니, 그러지 말고 애플리케이션 팀이 플랫폼을 통해 '스스로를 지원하도록' 하세요.
셋째, 사내의 엄격한 일관성과 애플리케이션 팀에 부여하는 자율성(자유+책임) 사이의 이율배반 관계에서 적절한 균형점을 찾아나갈 준비가 되어 있어야 합니다. 플랫폼 자체가 그 최적점으로 수렴하도록 맞추어가세요!
자, 마지막으로, 몇 가지 유의사항을 꼭 기억해주세요.
- 당신의 플랫폼은 당신이 설치할 수 있는 인프라, 도구 및 API 뿐만이 아닙니다. 우선 딜리버리(Delivery) 팀이 독립적으로 어느 정도 범위까지 선택하는 것이 좋을지 vs 또는 플랫폼 팀은 어느 정도 범위까지 합리적인 기본값(Sensible Defaults)(또는 제약)을 제공해야 할지에 대해 차차 정해 가야 해요. 또한, 딜리버리(Delivery) 팀이 (원하는) 새로운(다양한) 기능들을 가능한 빠르게 도입하는 것과 vs 플랫폼 팀이 지속적으로 유지 보수를 해낼 수 있는 정도의 상태를 지속하는 방법에 대해서도 답해 나가야 하죠. 이를 위해서는 내부 컨설팅 스킬과 트레이닝 및 에반젤리즘(Evangelism)이 필요할 거에요.
- 처음엔 최종적으로 어떤 플랫폼 기능이 필요하게 될지 모를 수 있어요. 그러니 실제로 명료하게 확실한 요구 사항을 중심으로 소규모로 시작해보세요. 우선 애플리케이션 팀 내부에서 이미 효과가 검증된 솔루션을 검토하는 것이 좋아요. 그리고 플랫폼 팀과 그 고객이 될 팀(애플리케이션 팀)이 서로 합작해서 초기 기능을 만들고 테스트 해 보는 것 역시 추천합니다.
- '플랫폼' 이란 단어를 사용하는데 신중하세요! 이미 사내에서 전통적으로 보유하고 있는 제한된 가상화 호스팅(Limited Virtualized Hosting) 이나 제약된 중앙 관리 도구(Locked-Down Centrally-Managed Tooling)과 크게 다르지 않은 개념에 '플랫폼' 이란 이름을 붙이지 않도록 주의하세요.
Top comments (0)