국내에는 개발 7년차, 매니저 1일차의 저자로도 알려진 Camille Fournier가 Ian Nowland와 함께 쓴 Platform Engineering에 관한 책이다.

최근 몇 년 동안 Platform Engineering이 주 업무 중 한 분야이기도 해서 꽤 많이 고민하고 공부했었기에 이 책이 나온다고 해서 기다리고 있었다.(하지만 이제야 읽었다.ㅎㅎ)

플랫폼 엔지니어링이라는 건 꽤 어려운 분야라고 생각한다. 어느 분야이든 어렵지 않은 영역은 없지만 Platform이라는 용어 자체가 너무 광범위하기 사람마다 이해하는 영역이 꽤 다르다고 생각한다. 나는 현재 SRE로 일하고 있어서 인프라 관점에서 플랫폼 엔지니어링을 보는 편이고 그렇게 만든 사내 개발자 플랫폼(IDP)에 관해서 여러 번 발표도 하고 다른 회사에 소개도 종종 하기는 했는데 이 책은 정말 좋은 책이라고 생각한다. 플랫폼 엔지니어링에 관한 건 아니지만 플랫폼/인프라 조직 관점에서 가장 도움 된 책은 팀 토폴로였다.

우리 둘 다, 뛰어난 엔지니어들의 그룹이지만 조직 내에서 '고객의 요구나 안정성에 대한 고려 없이 재미있어 보이는 것만 만드는 팀'이라는 평판을 받고 있는 팀을 성숙하고 잘 운영되는 고객 중심 플랫폼 팀으로 바꾸도록 돕는 난제를 맡고 있었다.

이 용어가 최근의 기술 유행어(buzzword)일 수 있지만, 우리는 이것이 최신의 과대선전(hype)으로 퍼지기 훨씬 오래전부터 이를 잘 수행하는 방법을 찾으려 노력해 왔다.
사실 우리가 접한 대부분의 플랫폼 엔지니어링 팀은 내가 앞에서 언급한 조직이 처음에 가졌던 것과 같은 평판을 가지고 있다. 이들은 아무도 요구하지 않은 기능을 그저 재미있어 보인다는 이유로 만들어냈다. 종종 그러한 중요한 작업이 마땅히 가져야 할 운영상의 성숙도도 없다. 이런 일이 생기는 것이 애초에 플랫폼 엔지니어링이 어렵기 때문이다! 과대선전을 걷어내면 조직적 성숙도의 진화가 보일 것이다.

저자가 둘 다 플랫폼 엔지니어링에 대해 고민도 많이 하고 경험도 많으므로 그 고민이 잘 정리되어 있어서 누군가 플랫폼 엔지니어링에 관심이 있다면 이 책을 먼저 보라고 권하고 싶다. 플랫폼 엔지니어링이라는 말 자체는 최근 몇 년 사이에 떠오른 용어이지만 내가 보는 관점에서는 빅테크 회사 위주로 이미 십여 년간 내부에서 플랫폼 엔지니어링을 시도하고 자리 잡았고 그 관례가 정리되어서 업계로 나오면서 플랫폼 엔지니어링이라는 분야가 생기기 시작했다고 생각한다. 그래서 업계에서 플랫폼 엔지니어링이라는 말을 쓰기 시작한 지는 몇년 되지 않았지만, 플랫폼 엔지니어링의 노하우는 꽤 많이 쌓여있다고 생각하는데 그 노하우가 이 책에 고스란히 담겨있다. 공감되는 부분이 너무 많아서 줄을 너무 많이 치면서 읽은 책이다.

1부 플랫폼 엔지니어링의 정의와 필요성

1장 플랫폼 엔지니어링이 점점 더 중요해지는 이유

지난 25년간 소프트웨어 조직들은 한 가지 문제에 직면해 왔다. 여러 팀이 공유하는 코드, 도구, 인프라를 어떻게 관리할 것인가? 이 문제를 해결하기 위해 대부분의 조직은 이러한 공유 요구사항을 담당할 중앙 팀을 만들었다. 하지만 대부분의 경우 이는 그다지 효과적이지 않았다.

그런 중앙 팀을 개선하는 대신 완전히 없애버리는 방법을 선택한 조직들도 있었다. 그런 조직은 각 애플리케이션 팀에 클라우드 접근 권한과 원하는 오픈소스 소프트웨어(OSS)를 선택할 권한을 주었다. 하지만 선택한 서비스나 소프트웨어의 복잡한 운영 및 유지보수 부담은 애플리케이션 팀의 몫이 되었다. 결국 효율성과 규모의 경제를 창출하는 대신, 소규모 팀조차도 사이트 신뢰성 엔지니어링과 데브옵스 전문가를 두어야 했다.

한편, 클라우드와 OSS의 장점을 수용하면서도 중앙 팀 모델을 포기하지 않은 조직들도 있었다. 장점이 단점보다 크다고 확신했기 때문이다. 가장 좋은 성과를 얻은 조직은 플랫폼, 그러니까 다른 엔지니어들이 편하게 그 위에서 개발할 수 있는 공유 서비스를 구축한 조직이다. 플랫폼 담당자들은 클라우드와 OSS의 복잡성을 관리하면서도 사용자들에게는 안정성을 제공하는 전문가로 성장했다. 또한, 애플리케이션 팀의 의견을 경청하고 협력하면서 회사의 요구사항을 계속 충족하고 발전시켰다.

다양한 조직에서 문제를 해결하기 위해 여러 시도를 하면서 플랫폼 엔지니어링이 떠오르게 된 과정을 잘 설명한다.

복잡성 관리라는 근본적인 과제는 모든 종류의 내부 플랫폼 개발에 공통이라는 점을 기억하기 바란다.

플랫폼 엔지니어링은 플랫폼을 개발하고 운영하는 하나의 분야이다. 이 분야의 목표는 비즈니스에 레버리지를 전달하기 위해 전체 시스템의 복잡성을 관리하는 것이다. 플랫폼 엔지니어링은 폭넓은 애플리케이션 개발자층을 위한 소프트웨어 기반 추상화로서의 플랫폼을 개발하고, 이를 비즈니스의 토대로 운영하는 큐레이션 제품 접근 방식을 통해서 그러한 목표를 달성한다.

플랫폼 엔지니어링의 핵심 가치는 레버리지 개념에 있다. 플랫폼 엔지니어링의 맥락에서 레버리지는 소수의 플랫폼 팀 엔지니어들의 작업이 조직 전체의 업무를 줄여주는 것을 의미한다.

플랫폼을 하나의 제품으로 보는 것이 매우 중요하다. 플랫폼을 매력적인 제품으로 개발한다는 것은 플랫폼의 기능을 결정할 때 고객 중심적 접근 방식을 취한다는 뜻이다. 그러려면 사용자가 주된 초점이 되어야 한다.

플랫폼 엔지니어링의 기본적인 개념에 대한 설명이다.

플랫폼 엔지니어링은 OSS와 벤더(제품이나 서비스를 제공하는 업체 또는 조직)의 선택을 조직의 필요에 맞게 제한된 집합으로 추상화하고 강력한 의견을 제공함으로써 관심사의 분리를 가능하게 한다.

오케스트레이션 시스템인 쿠버네티스의 부상은 여러 면에서 PaaS와 IaaS 모두가 기업의 요구를 충족시키는 데 실패했다는 것을 인정하는 것이다. 쿠버네티스는 애플리케이션을 소위 '클라우드 네이티브'로 만들어서 인프라 관련 접착제를 줄이려는 시도라고 할 수 있다. 하지만, 비록 쿠버네티스가 많은 것을 표준화했음에도 복잡성 측면에서는 득이 되지 않았다.

애플리케이션이 테라폼 접착제 대신 YAML 접착제를 더 많이 사용하게 되었을 뿐이다. 앞에서 논의했듯이 플랫폼 엔지니어링의 목표는 전체 접착제의 양을 줄이는 것이다.

클라우드와 OSS가 제대로 연동되도록 다양한 자동화와 도구들이 생기게 되는데 이를 이 책에서는 접착제라고 부르고 이 접착제로 인해서 점점 변경이 어렵게 되고 운영이 복잡해지게 된다고 설명하는데 결국 이 접착제를 줄이는 것이 중요하다. Terraform, 정확히는 HCL 대신 YAML로 바뀌었을 뿐이라는 말에 동의한다.

애플리케이션 개발자들은 자신이 좋아하는 시스템을 사용할 때 더 큰 자율성과 주인의식을 느낀다. 하지만 기업이 다양한 선택으로 인한 지원 부담과 장기 비용 절감에 초점을 맞추기 시작하면 이러한 이점은 종종 잊힌다. 이런 상황에서 지도층의 본능적인 첫 반응은 권위에 호소하여 표준을 규정하는 것이다.

플랫폼 엔지니어링은 현대적인 엔지니어링 팀에게 그들이 즐겨 사용할 수 있는 시스템이 필요하다는 점을 인정한다. 이러한 시스템은 단순히 비용 절감이나 자체 지원 부담에만 초점을 맞추지 않고, '고객으로서의 팀'을 배려하는 팀들이 제공해야 한다. 권위에 호소하는 표준 규정 대신, 플랫폼 엔지니어링은 광범위한 요구사항을 충족할 수 있는 소수의 기본요소를 큐레이션하는 고객 중심의 제품 접근 방식을 취한다. 이를 위해서는 비즈니스 현실을 고려한 타협과 좋은 플랫폼 아키텍처의 증분 전달(incremental delivery), 그리고 애플리케이션 팀과 직접 협력하여 그들의 요구를 경청하려는 자세가 필요하다. 이것이 잘 이루어지면, 아키텍트나 데이터베이스 관리자, CTO, 플랫폼 부사장(VP)의 권위에 호소하는 대신 플랫폼이 제공하는 서비스를 활용하는 파트너십의 효과를 입증할 수 있다. 이러한 방식을 잘 적용한다면, 하향식 명령으로 인한 최악의 결과를 피하면서도 사용되는 OSS와 클라우드 기본요소의 수를 줄이는 것이 가능하다.

인프라나 플랫폼을 관리하다 보면 어떤 정책이나 시스템을 적용해야 할 때가 있기 때문에 권위에 호소해서 조직 전체가 적극적으로 움직이면 얼마나 좋겠냐는 생각이 들 수 있고 실제로 나도 이런 생각을 하거나 시도 비슷한 것도 해본 적이 있다. 하지만 결과적으로는 좋은 방법이 아니라고 생각해서 지금을 잘 접근하지 않는데 이 책에서도 그 부분을 강조해 주어서 좋았다.

플랫폼 엔지니어링은 사용 중인 기본요소의 수를 줄이는 것에서 한 걸음 더 나아가 남은 요소들과의 '접착제'를 줄이는 것을 목표로 한다. 기본요소들을 더 광범위한 요구를 충족할 수 있는 체계적인 플랫폼 역량들로 추상화함으로써 애플리케이션 수준의 접착제를 대부분 제거할 수 있다.

테라폼은 플랫폼 엔지니어링이 접착제의 단점을 어떻게 해결하는지 보여주는 데 아주 적합한 예이다.

전문가 그룹을 단순한 '접착제' 유지보수 센터에서 실제로 무언가를 구축하는 엔지니어링 센터로 발전시켜야 한다. 그런 엔지니어링 센터가 곧 플랫폼이다.

이 책은 테라폼 적용으로 인한 상황을 예시로 드는데 테라폼을 적용하고 관리가 어려워서 테라폼이 중앙 집중화되고 해당 팀은 이 테라폼 유지보수 센터가 되어 버린다. 테라폼을 정말 십 년간 좋아했던 나도 이 문제를 겪으면서 고민도 많이 했고, 결국 테라폼을 상당 부분 걷어버리고 플랫폼을 대체하고 방향을 찾았다고 느낀다. 플랫폼으로 대체하진 못했더라도 테라폼을 쓰는 대부분의 조직이 테라폼에 관해서 어느 정도 애증의 감정을 느끼고 있을 거라고 생각한다.

성숙한 데브옵스의 목표는 "만든 사람이 소유한다(you built it, you own it)"라는 접근 방식을 통해 책임 소재를 단순화하는 것이다. 이 개념이 10년 넘게 인기를 끌었지만, 실제로 모델을 실현한 기업은 많지 않다. 실현에 성공한 기업들의 경우, 우리는 플랫폼이 바탕 의존성의 운영 복잡성을 추상화해서 제공한 '레버리지'가 주된 성공 요인이라고 믿는다.

지금까지 이야기한 문제점들을 처리하고 감당하는 운영 플랫폼을 구축하는 것이 쉬운 일은 아니다. 특히, 애플리케이션 팀이 선택의 제한을 수용하게 만들기가 어렵다. 하지만 이런 플랫폼이 없으면 조직 전체가 이러한 문제에 직접 노출되거나, 기존의 운영팀(구체적인 이름이 무엇이든)을 계속 돌릴 수밖에 없다.

플랫폼 엔지니어링은 이러한 엔지니어 그룹들이 각자의 사일로에서 벗어나 균형 잡힌 플랫폼을 만드는 더 광범위한 임무를 가진 팀에서 일할 것을 요구한다.

모든 결과를 달성하는 데 상당한 시간이 걸릴 수 있음을 인정하지만, 우리는 이것이 추구할 가치가 있는 이상이라고 믿는다.

아주 동의한다. 시간이 지나고 조직이 커지면 또 다른 문제를 만나겠지만(처음 테라폼을 적용했을 때도 너무 좋았었다.) 조직이 어느 정도 커진다면 현재는 플랫폼 엔지니어링 접근이 맞는 방향이라고 생각한다.(물론 그 플랫폼이 어떤 형태이냐가 중요하겠지만...)

모든 새로운 아이디어를 플랫폼에 끼워 맞춰야 한다고 주장하는 것은 아니다. 오히려, 이러한 아이디어가 독립적으로 발전하도록 두고, 성공적이고 광범위한 수요가 있는 것만 통합하는 것이 최선의 방법일 때가 많다.
플랫폼 팀은 사람들을 플랫폼에서 멀어지게 할 혁신과 실험을 억제하고 싶은 유혹을 받는다.

나도 수년간 플랫폼이라는 망치를 들고 있던 터라 모든 것이 못으로 보여서 계속 객관적으로 보려고 하지만, 이 유혹은 정말 심하긴 하다.(보통 동료들이 정신 차리게 해주는 거 같다.)

2장 플랫폼 엔지니어링의 기둥들

플랫폼 엔지니어링 실무의 4대 '기둥(pillar)'을 도출할 수 있다.
제품 - 큐레이션 제품 접근 방식을 따른다.
개발 - 소프트웨어 기반 추상화를 개발한다.
범위 - 폭넓은 애플리케이션 개발자층을 지원한다.
운영 - 플랫폼을 비즈니스의 토대로 삼는다.

플랫폼을 만들면서 이렇게 핵심 기둥을 고민하거나 정하지는 않았지만 이렇게 핵심 요소는 고민할 때 도움이 꽤 될 것 같다.

플랫폼 엔지니어링의 첫 기둥인 큐레이션 제품 접근 방식(curated product approach)은 다른 세 기둥의 균형을 잡는 역할을 한다. 여기서 제품 접근 방식이란 개발자들이 순수하게 기술적인 사고방식에서 벗어나 고객이 시스템에 대해 원하는 바와 시스템을 사용하는 경험에 초점을 맞추는 것을 의미한다. 그리고 큐레이션이란 특정한 상호작용 패턴과 사용 규칙이 존재할 뿐만 아니라 이 플랫폼의 범위에 무엇이 포함되고 제외되는지에 대한 나름의 관점(opinion)을 가지고 그에 따라 제공 사항들을 엄선한다는 뜻이다.

큐레이션 제품 접근 방식이 성공하면 두 가지 유형의 플랫폼 제품이 만들어진다.

포장도로
큐레이션 플랫폼의 가장 일반적인 유형으로, 여러 서비스를 층층이 쌓아서 사용하기 쉬운 작업흐름(workflow)을 만든다. 종종 이 플랫폼을 '포장도로(paved path)'라고 부른다.

이것은 포장도로이지 강제된 서비스가 아니므로, 특수한 요구사항이 있는 팀은 언제든 도로에서 벗어나 자신의 길을 갈 수 있다.

철도
둘째 유형의 큐레이션 플랫폼은 포장도로형과는 아주 다른 모습이다. 이 유형은 기존 제품으로는 해결되지 않지만 여러 애플리케이션 팀에게 필요한, 유의미한 틈(gap)을 발견한 경우에 적합하다.

이 유형은 흔히 애플리케이션 팀이 특정 요구사항을 충족하기 위해 만든 프로토타입에 기반한다. 그러한 프로토타입을 일반화하여 더 폭넓게 사용할 수 있는 서비스를 만든 것이 이 유형의 플랫폼이라고 할 수 있다.

제품 접근 방식을 따른다는 말은 뻔한 말인 듯하면서도 실제로는 꽤 모호하게 느껴질 수도 있는 부분이라고 생각한다. 그동안 플랫폼을 만들어주면서 요구사항을 다 만드는 게 아니라 opinionated여야 한다는 생각을 많이 했는데 그 부분에 대해서 짚어주고 있고 포장도로에 대해서는 나도 많은 생각을 했지만, 철도에 대해서는 생각해 본 적이 없어서 재미있었다.

소프트웨어를 구축하지 않은 플랫폼 엔지니어링은 플랫폼 엔지니어링이 아니다.

내부 결제 플랫폼이든 인프라 수준의 컴퓨트 플랫폼이든, 플랫폼 엔지니어링은 사내에서 개발한 소프트웨어 로직을 사용하여 바탕 시스템을 추상화함으로써 레버리지를 만든다. 다른 말로 하면, 그러한 추상화 없이는 복잡성을 관리하는 플랫폼을 만들 수 없다. 추상화 없이는, 단지 인프라를 공급하고 모든 복잡성을 사용자에게 떠넘기는 것에 불과하다.

완전한 캡슐화가 적절한 수준의 추상화인지 판단하는 핵심 기준은 애플리케이션 엔지니어의 관점에서 바라보는 것이다. 즉, 표면적을 줄이고 바탕 OSS 및 벤더 시스템과 관련된 자원(공개 문서 등 포함)들과 그들을 분리했을 때 과연 생산성이 높아졌는지, 아니면 단지 플랫폼 팀이 관리하기 쉽게 만든 것일 뿐인지는 아닌지 점검해야 한다. 실제로 생산성이 높아졌음을 확신할 수 있을 때까지는 바탕 시스템에 대한 직접 접근을 허용하고, 그로부터 배우는 것이 낫다.

추상화 역시 중요한 부분이지만 어디까지 어떻게 추상화할 것인지는 어려운 영역이다. 그럼에도 이 부분의 고민은 무척 중요한데 추상화하면 어떤 부분은 감춘다는 의미이므로 누구는 편하다고 느끼겠지만 누구는 헷갈리고 추상화된 부분을 알고 싶어하면서 적절한 추상화인지 고민하게 되는데, 추상화에 대한 기준을 제시해 준 게 좋았다.

우리는 레지스트리를 만든 팀이 사용자가 수동으로 정보를 채울 것이라고 생각하거나, 기계적인 스크레이핑(scraping) 후 '그냥' 정리만 하면 될 거라고 생각했을 때 레지스트리가 잘 자리 잡지 못하는 사례를 목격했다. 광범위한 성공은 플랫폼이 이러한 레지스트리와 얼마나 잘 통합되어 메타데이터를 지속적으로 자동 캡처하고 레이블링할 수 있느냐에 달려 있다고 믿는다. 엔지니어들이 큐레이터 역할을 하는 것만큼 싫어하는 것은 없기 때문이다.

이 부분 또한 중요한데 어떤 정보를 현재 상태에서 채워 넣는 건 가능하지만(이마저도 쉽진 않다.) 이를 앞으로도 계속 녹슬지 않은 정보로 만들려면 훨씬 어려운 일이 되고 추상화 외에도 넛지 요소가 많이 필요해진다.

시스템을 더 저렴하고, 안전하며, 사용하기 쉽게 만드는 역량(capability)을 개발해야 한다. 이러한 역량에는 다음이 포함된다.

셀프서비스 인터페이스
셀프서비스는 플랫폼이 제공하는 핵심 요소의 하나이다. 대규모 고객층을 효율적으로 지원하려면 셀프서비스가 필요하다.

사용자 관측성
플랫폼에서 덜 이야기되지만 중요한 또 다른 셀프서비스 유형이 사용자 관측성(user observability)이다. 개발자가 플랫폼을 이용해서 애플리케이션을 개발하고 운영하는 전체 수명 주기 동안 개발자 스스로 문제를 디버깅할 수 있도록 원격 측정 기능을 구축해야 한다.

가드레일
가드레일 구현이 플랫폼 구축의 중요한 일부가 된다. 여기서 가드레일은 값비싼 설정 오류가 발생할 가능성을 크게 낮추는 보호 장치와 기본 한곗값들을 말한다.

다중 테넌트
널리 사용되는 플랫폼의 핵심적인 측면 하나는 플랫폼이 다중 테넌트(multitenant)를 지원해야만, 즉 동일한 런타임 구성요소 내에서 서로 다른 애플리케이션을 돌릴 수 있어야만 효율적이라는 점이다.

전부 중요하지만 난 여기서 셀프서비스 인터페이스와 가드레일이 제일 중요하다고 생각한다.

플랫폼 엔지니어링 실천의 마지막 기둥은 플랫폼을 하나의 토대(foundation; 기반)로서 운영하는 것이다. 플랫폼은 애플리케이션 엔지니어가 자신의 비즈니스를 믿고 맡길 수 있는 튼튼한 토대가 되어야 한다.

플랫폼 팀은 끊임없이 고객 문의를 받게 된다. 이런 문의들은 주로 온보딩 과정의 예외적인 상황이나 애플리케이션별 프로덕션 문제점에 관한 것으로, 애플리케이션, 플랫폼, 또는 기반 시스템의 변경이나 장애로 인해 발생한다.

플랫폼이 더 적합한 기업에서조차도 인프라 엔지니어링 스타일의 문화가 지속되는 주된 이유는 그러한 플랫폼을 구축할 소프트웨어 개발자들이 타인의 시스템을 제대로 운영하는 데 필요한 실무에 관여하기를 꺼리기 때문이다. 플랫폼 엔지니어링 팀은 운영 실무를 적극적으로 활용해야 한다. 플랫폼이 기업이 신뢰할 수 있는 토대로 자리 잡게 하는 핵심 요소가 그것이기 때문이다.

이 책을 읽으면서 나에게는 잘 와닿지 않은 부분이 조직에 관한 것인데 내 현 상황에서는 같은 팀에서 플랫폼 구축과 인프라 운영을 함께하는 데 반해 책에서는 플랫폼 구축과 운영을 하는 별도의 조직을 더 일반적으로 얘기하고 있었다. 인프라 운영을 같이하므로 토대가 되어야 한다는 부분은 약간 더 쉬웠을 수 있다고 생각하지만 그럼에도 플랫폼이 기반 인프라로써 안정감을 줘야 한다는 것은 당연하고 플랫폼으로 추상화함으로써 그전까지는 운영 주체가 모호했던 부분을 명확하게 나누어서 일부는 플랫폼을 운영하는 쪽에서 책임져야 한다는 부분은 중요하다.

2부 플랫폼 엔지니어링 실무

3장 착수 시기와 방법

플랫폼이 새로운 기능을 제공하는 이유는 단순한 효율성이 아니라 레버리지여야 함을 의미한다.

이 의미는 중앙 팀에서 뭔가를(꼭 플랫폼이 아니더라도) 회사 관점에서는 여러 팀이 똑같은 일을 하니까 중앙 팀에서 한다는 효율성이 아니라 소수가 회사 전체에 이득을 주는 레버리지여야 한다는 의미다.

이들의 의도는 순수할 수 있지만, 우리의 경험상 일부는 변화에 대해 불평을 멈추지 않을 것이다.

이 시점에서 플랫폼 팀은 신뢰를 전혀 쌓지 못했다. 단지 호의를 얻었을 뿐이다. 팀이 만든 것은 그저 조직의 새로운 사일로이다. 이제 팀의 당면 목표는 엔지니어링 팀과의 협업을 최대한 유지하는 방법을 찾는 것이다. 신속한 가치 전달로 신뢰를 쌓아야 한다.

플랫폼 구축에 대한 반대 여론은 실제로 많이 경험해 봤다.

대기업에서 온 신규 엔지니어들을 주의하라

실제로 이들이 아는 것은 과거에 유사한 문제를 겪었던 다른 회사의 완성된 솔루션일 뿐일 수 있다.

이마저도 경험해 봤다. 꼭 대기업이 안다고 하더라도 대부분의 사람은 자신이 이전에 잘 사용했던 솔루션을 그대로 여기서 사용하려는 경향이 있다. 이게 잘못되었다는 것은 아니고 익숙한 도구로 하려는 일을 빠르게 잘하려는 것이지만 플랫폼을 만드는 처지에서는 이 지점이 꽤 많은 충돌 지점이 된다.

플랫폼 팀이 약 50명 정도로 성장하면 비로소 첫 번째 프로젝트 관리자를 두어야 할 것이다. 가능한 한 이 비율을 넘기지 말아야 한다.

이건 아직 잘 모르겠다. 훨씬 소수일 때도 PM이 필요하다고 생각했었지만, 지금은 전혀 그런 생각을 하지 않는다. 제일 큰 이유는 그런 사람을 찾을 수 있을지 모르겠기에 이기도 하고 서비스와 달리 내부 플랫폼에 관해서 PM과 협업한 경험이 그리 많지 않아서이기도 하다.

통합 플랫폼을 구축할 때 간과되는 중요한 요소 중 하나는 발견성(discoverability; 또는 발견 가능성)이다. 기업의 규모가 클수록, 플랫폼 팀이 제공하는 기능이 자신에게 필요할 수 있다는 사실을 사람들이 인지하기가 더 어려워진다.

결제 플랫폼을 '결제 플랫폼' 대신 '글렌게리Glengarry'라고 부르는 것은 발견성 문제 해결에 전혀 도움이 되지 않는다. 플랫폼 팀은 자신이 제공하는 기능과 서비스를 조직 전체에 알릴 계획을 반드시 세워야 한다.

이는 시간이 지날수록 공감되는 부분인데 기능이 늘어나고 고도화되고 조직이 커질수록 해당 기능의 존재 자체를 모르는 사람이 많아지게 된다. 가장 의존하는 건 다양한 채널을 통해서 여러 번 공지해서 알리는 방법이기는 한데 보통 그 필요성은 느끼는 때가 아니면 해당 공지를 보더라도 무심코 넘어가기 마련이다. 기본적으로는 공지로는 한계가 있고 플랫폼의 흐름과 기능에서 해당 기능이 필요할 때 알려줄 수 있어야 한다고 생각하고 있지만 현실에선 쉽지 않기도 하다. 좋은 기능이 잘 알려지지 않아서 못 쓰였던 상황을 볼 때마다 아쉬움이 생긴다.

통합 플랫폼 팀은 본질적으로 중간자 위치에 갇혀 있다는 점을 짚고 넘어갈 필요가 있다. 일반적으로 통합 플랫폼 팀은 바탕 컴퓨트, 저장, 네트워킹을(그리고 종종 보안과 신원 인증 서비스도) 관리하는 핵심/인프라 플랫폼 조직의 일부가 아니다.

통합 플랫폼 팀이 애플리케이션과 핵심 플랫폼 팀들 사이에 위치한다는 것은 스택의 양쪽에서 발생하는 오류의 영향을 받는다는 뜻이기도 하다. 이로 인해 디버깅과 운영이 한층 더 까다로워진다.

이게 아까 말한 조직 얘기인데 내용이 좋음에도 불구하고 여기서 말하는 플랫폼 팀의 영역이 좀 모호하게 느껴지긴 한다. 그럼에도 플랫폼이라는 것 자체가 중간자의 위치에 있다는 것은 동의하고 여기서 말하는 문제를 잘 해결해야 한다.

'플랫폼 엔지니어링'과 이미 가까이 있는 영역부터 시작해서, 거기서 효과적인 방법을 배우고 그것을 더욱 확대 적용하는 것이 더 낫다.

엔지니어들은 자신의 제품을 지원하는 데 시간을 써야 한다. 엔지니어의 질문에 정기적으로 답하지 않는다면, 고객이 시스템을 사용하려 할 때 겪는 어려움을 이해할 기회를 놓치게 된다.

이 부분 역시 너무 중요하다. 플랫폼이 잘 만들어서 수동 지원을 줄이려는 목적도 포함되어 있지만 이러한 수동 지원은 영원히 없어지진 않을 거라고 생각한다. 이 지원을 통해서 사용자가 어떻게 플랫폼을 사용하고 뭘 착각하는지 잘 이해할 수 있고 그런 지원이 없다면 프로바이더만 만족하는 프로바이더의 함정에 빠질 수 있다고 생각한다. 이 함정에 빠지기 쉬우므로 빠지지 않기 위한 노력과 장치가 많이 필요하다.

큰 기술적 문제를 해결하는 사람만 승진시킨다면, 사용성을 개선하고 고객 팀의 의견을 경청하며 가장 시급한 문제 해결을 위해 업무 우선순위를 조정하는 인재들은 조직을 붙잡아두기 어렵다.

플랫폼의 가치에는 고객의 마이그레이션 부담 경감이 반드시 포함되어야 한다.

엔지니어링 팀을 제품 중심 사고방식으로 전환하는 데 있어 지름길 같은 것은 없다.

팀은 고객과 더 많은 시간을 보내야 하며, 단순히 최근 고객 불만을 해결하는 것이 아니라 전체적인 문제를 해결하기 위한 전략적 계획에 더 많은 시간을 투자해야 한다.

조직 관점에서 이 부분은 중요하다. 여기 있는 말에는 동의하면서 이런 타입의 사람이 있는 것인지 분위기가 만들어지면 이런 접근방법을 배우게 되는지는 여전히 어렵다.(휴먼 관리는 너무나도 어렵다.) 그럼에도 팀 자체가 제품 중심 사고방식을 취해야 함은 필수적이고 이게 되지 않으면 제대로 된 플랫폼은 아마도 만들 수 없을 것이다.

4장 훌륭한 플랫폼 팀 만들기

플랫폼 팀은 복잡한 시스템 위에 추상화 계층을 개발해 사용자의 생산성을 높이지만, 해당 시스템을 이해하는 전문가들로 구성하지 않는다면 나중에 운영상 문제를 야기할 수 있다.

훌륭한 플랫폼 팀을 만드는 방법은 다양한 강점을 가진 인재를 채용하고, 각자가 성공할 수 있는 문화를 조성하는 것이다.

좋은 팀을 만드는 법에 관해서 난 아직 너무 초보 단계다. 글로 읽으면 이해되는 말이지만 현실에선 너무 어렵다. 현재 생각은 "좋은 사람을 뽑으면 된다"라는 무책임한(?) 생각 정도이다.

소프트웨어와 시스템 중 한쪽에만 지나치게 치우친 팀을 개선하려면 두 종류의 작업을 동등하게 평가해야 한다. 보통의 경우 그러려면 팀에 새로운 역할을 추가할 필요가 있다.

첫 단계는 소프트웨어 대 시스템이라는 기존 구분 방식의 한계를 깨닫는 것이다.

우리 저자들은 플랫폼 팀에 다음과 같은 세 가지 주요 시스템 중심 역할이 필요하다고 믿는다.
시스템 엔지니어 - 진정한 시스템 제너럴리스트이다. 데브옵스 엔지니어라고 부르는 게 적당하겠지만, 업계에는 그 밖에도 여러 이름이 있다.
신뢰성 엔지니어 - 시스템의 신뢰성에 깊이 집중한다. 시스템 엔지니어링의 다른 측면은 무시한다.
시스템 전문가 - 시스템 전문가(system specialist)는 특정 분야의 깊은 전문성에 기반한 여러 구체적인 역할을 아우르는 이름이다. 이를테면 리눅스 엔지니어, 성능 엔지니어, 네트워크 개발 엔지니어 등이 시스템 전문가에 속한다.

앞에서도 몇 번 얘기했지만, 이 책에서 얘기하는 플랫폼 팀이 위치한 회사 내의 조직도를 잘 모르겠다. 어쨌든 지금 내가 있는 조직은 아주 큰 조직은 아니기에 인프라 운영과 플랫폼 구축을 한 팀에서 다 하고 있어서 명확하지는 않더라도 위의 역할을 다 섞어서 하고 있다. 팀이 커지면서 조직에 대한 고민도 많았는데 지금 확신(?)하고 있는 대로 한 팀으로 있는 것이 한쪽으로 치우치지 않고 사일로를 만들지 않는다고 생각한다.

성공적인 플랫폼 팀에서는 특히 시니어급 소프트웨어 엔지니어들이 일반적인 애플리케이션 팀의 '백엔드' 엔지니어들과는 다소 다른 특징을 보인다. 다음은 대표적인 세 가지 특징이다.

시스템을 이해하려는 의지가 강하다.
이들은 자신이 작성한 코드와 그 코드가 실행되는 시스템의 상호작용을 깊게 이해하고자 한다

필수 비즈니스 시스템의 온콜 당직을 불편해하지 않는다.

신중한 속도로 배포하는 것을 받아들인다.
시스템 세부사항을 좋아하고 사용자 문제를 즉시 해결하기 위해 자유롭게 코드를 작성하고 싶어 하는 뛰어난 인재는 많다. 하지만 플랫폼의 소프트웨어 엔지니어는 코드 작성 외에도 운영, 통합, 실험에 시간을 할애해야 한다.

꼭 플랫폼 팀에 한정된 얘기도 아니다.

우리의 경험상 성공적인 플랫폼 팀에서는 폭 넓은 시스템 엔지니어가 더 일반적인 역할이므로, 이를 먼저 살펴보겠다.
소프트웨어 작성보다 시스템 이해에 중점을 두면서도 그 초점을 폭넓게 가져가 여러 전문 분야를 이해하는 인재는 거의 모든 플랫폼 팀에 도움이 된다. 이들이 성능이나 리눅스, 네트워킹 등 특정 개별 분야의 세계적 전문가는 아닐지라도, 서로 다른 유형의 시스템이 어떻게 작동하고 통합되는지에 대한 복잡성을 이해하려는 동기가 있기 때문에 대부분의 소프트웨어 엔지니어보다 더 많은 지식을 보유하고 있다.

플랫폼 엔지니어링 문화를 도입했다면, 팀의 모든 구성원은 단순히 자동화나 신뢰성이 아닌 플랫폼 제품의 기능이라는 관점에서 자신의 작업을 생각해야 한다.

왜 특정 시스템 요소의 전문가를 구하는 대신 폭넓은 시스템 엔지니어 역할을 인식하고 채용해야 할까? 이유는 세 가지이다.
• 전문화에는 시간이 걸린다. 쓸 만한 시스템 엔지니어는 이미 '시니어' 수준의 경력을 갖춘 경우가 많아서, 그만한 경력이 아니면서도 능력 있는 시스템 엔지니어를 구하기가 어렵다.
• 유능한 시스템 엔지니어는 승진하려면 전문화가 필요하다고 느끼게 된다. 이들이 시스템 전문가로 변신하면, 팀으로서는 이들이 기여하는 폭넓은 지식(매우 중요함)을 잃게 된다.
• 전문가가 너무 많을 필요는 없지만, 폭넓은 시스템 엔지니어는 반드시 필요하다.

영역 구분 없이 필요하다면 뛰어드는 엔지니어는 너무 소중하다. 여기서 당연히 폭이 넓은 것만으로는 안 되고 깊이도 있어야 하는데 플랫폼 팀이 아니더라도 좋은 동료의 자질이지만 이런 사람들이 만들어주는 분위기와 문화가 없다면 플랫폼도 제대로 만들 수 없다고 생각한다.

우리는 일반적인 업무를 거부하는 시스템 전문가들도 보았다. 그런 사람들은 우리가 '내부 전도사(internal evangelist)로서의 전문가'라고 부르는 역할을 원한다. 이들은 회사에 당장 가치가 없는 오픈소스 프로젝트에 기여하거나, 컨퍼런스에서 발표하거나, 생소한 새로운 기술을 연구하는 데 열심이며, 자신의 전문 분야와 관련된 '있으면 좋을 법한' 내부 프로그램을 운영하는 데 시간을 보내고 싶어한다. 우리도 모든 엔지니어가 그런 활동을 하라고 장려한다. 단, 적절한 수준에서만이다.

그래, 적절한 수준에서 말이다.

우리 저자들은 이러한 난제를 성공적으로 풀기도 했고 실패하기도 했다. 회사 문화, 조직 내 우리의 위치, 프로세스 변경에 대한 CTO의 의지 등이 성공과 실패에 영향을 미치는 요인이었다. 거기서 배운 점은, 긍정적인 한계적 변화(positive marginal change)가 바로 성공의 관건이라는 것이다. 이는 개별 사례를 바탕으로 점진적 변화를 추진하되, 장기적으로는 더 큰 변화를 위한 근거를 쌓아가는 것을 말한다.

플랫폼 엔지니어링의 성과에 관해서 문제를 겪어본 경험은 없어서 이 부분은 일단 기록만 해둔다.

많은 사람이 의존하는 플랫폼은 조직의 운영에 핵심적인 요소이다. 따라서 플랫폼을 천천히 변경하고 신중하게 운영하는 것은 당연한 일이다.

팀이 약간 독특한 문화를 갖는 것은 괜찮지만, 고도로 신뢰할 수 있는 시스템을 운영하는 데 대한 자부심이 결함 있는 코드를 계속 배포하는 제품 엔지니어링 팀에 대한 경멸로 변질될 정도가 되면 안 된다. 그러면 훌륭한 플랫폼을 구축하는 데 매우 중요한 고객 공감 능력을 잃을 위험이 있다.

사용자에 대한 공감이 중요하다는 것은 동의하면서도 현실에선 쉽지 않은 부분도 있긴 하다.

5장 제품으로서의 플랫폼

플랫폼의 경우 최고의 제품 아이디어가 여러분의 엔지니어들과 회사 내 다른 부서 엔지니어들로부터 나오는 경우가 흔하다. 따라서 작은 프로토타입(원형)을 발굴하고 그것을 더 많은 개발자가 유용하게 사용하도록 확장할 수 있는지 살펴보는 것이 새로운 제품을 발굴하는 유효한 방법일 때가 많다.

대기업이든 스타트업이든, 플랫폼 엔지니어링의 일환으로 제품 관리를 도입하려 한다면 첫 단계는 고객을 이해하고 존중하는 것이다. 좋은 제품을 만들려면 제품의 대상이 명확해야 한다. 하지만 내부 고객을 이해하기란 쉽지 않다. 매일 대화할 수 있는 사람들이지만, 그렇다고 그들이 자신이 원하는 것을 정확히 설명할 수 있다는 뜻은 아니다. 내부 고객은 문제가 생길 때만 불만을 표시하는 수동적인 소비자일 수도 있고, 자체 플랫폼을 구축하려는 능동적인 경쟁자일 수도 있다. 여러분은 동료이자 고객인 내부 사용자들을 만족시켜야 하지만, 그들이 요구하는 모든 것을 들어줘야 하는 것은 아니다.
플랫폼의 대상이 누구든, 그들을 이해관계자가 아닌 고객으로 보고 그들의 요구를 충족하는 제품을 만드는 것이 중요하다. 어떤 기업도 고객에게 제품 사용을 강요하지 않는다. 내부 시스템도 마찬가지이다.

플랫폼을 제품으로 보고 아이디어를 발굴하고 사용자의 요구사항을 알아내는 것은 어찌 됐든 핵심이다. 일반 B2C보다 사용자 수는 적지만 그렇다고 요구사항의 수가 적다거나 명확하다는 뜻이 아니기도 하다.

내부 고객을 상대하다 보면 제품의 성공 여부를 판단하는 데 사각지대가 생기기 마련이다. 더욱이 여러분의 일을 과소평가하거나 당연하게 여기는 고객을 상대하다 보면 추가적인 마찰이 발생한다.

플랫폼의 경우에는 고객층이 작을 뿐만 아니라 대개는 고정되어 있다. 내부 고객은 플랫폼 팀이 제공하는 제품을 사용할 수밖에 없다(고객이 자체적으로 플랫폼을 만들지 못한다). 팀이 내부 고객에게 원하는 것이나 플랫폼 제품에 대한 평가를 물어볼 수는 있지만, 동료에게 솔직하게 의견이나 불평을 제공하기란 쉽지 않다.

플랫폼 팀에 제공하는 제품을 사용할 수밖에 없다는 점이 중요하다. 이 부분을 잘못 해석하면 사용성이 좋다고, 필요성이 있다고 착각하기 쉽다. 물론 착각하지 않는 것인지 판단할 수 있는 기준이 없는 것도 사실이다. 결국 회사 내 동료이기 때문에 정말 솔직한 얘기를 다 하기는 쉽지 않다.

여러분이 아무리 노력해도 만족하지 않는 고객층이 존재한다.

실제로 그러므로 모든 걸 만족시키려고 해서는 안 된다.

고정된 고객층을 대할 때는 플랫폼 엔지니어링 팀이 실패하는 유형은 크게 두 가지이다. 첫째는 제품 도입률(adoption metric)을 완전히 무시하다가 나중에야 플랫폼 제품이 일부 고객에게만 유용하다는 사실을 깨닫는 것이다. 이는 '당연한' 기능으로 간주되지만 사실은 미완성인, 대다수 고객의 요구에 맞지 않는 제품들이 누적되는 결과로 이어질 수 있다. 둘째는 도입률만을 중요한 지표로 보고 이를 빌미로 고객에게 맞지 않는 시스템을 강요하는 것이다. 고정 고객층이 있다고 해서 그들이 필요로 하고 원하는 것을 만드는 노력을 게을리해서는 안 된다.

플랫폼 팀이 만드는 제품은 대부분 어려운 일을 쉽게 만들거나 아예 불필요하게 만드는 것이다. 그러다 보니 내부 고객은 개선 사항을 곧 잊어버리기 쉽다. 이는 고객이 영원히 만족하지 못하는 무한 루프로 이어질 수 있다. 플랫폼 팀이 병목 지점 하나를 해결하면 고객은 곧바로 다음 문제에 눈길을 돌린다.

또한 대부분의 사람은 이 모든 것을 잘 작동시키는 것이 얼마나 복잡한 일인지 이해하지 못하며, 뭔가 고장이 나기 전까지는 플랫폼을 당연하게 여긴다는 점도 잊지 말아야 한다. 무관심이 곧 고객 만족인(즉, 불만이 없으면 만족하는 것인) 경우가 많다.

마지막으로, 내부 고객이 때로는 경쟁자처럼 행동한다. 오타가 아니다. 플랫폼 팀의 고객이 엔지니어이면, 그리고 팀이 그들의 요구를 따라잡지 못하면, 고객은 팀과 조율하며 기다리기보다 필요한 것을 직접 만들어버릴 수 있다.

이 모든 것을 다 경험해 본 것 같다. 플랫폼의 유용성을 계속 객관적으로 고민해 보는 것, 정말 좋은 플랫폼을 만드는 것은 전체 라이프사이클에서 가장 중요한 일이다.

팀이 순전히 관계 모델에만 근거해서 다른 엔지니어링 팀을 위한 제품을 만드는 것, 즉 그냥 다른 팀이 원하는 것을 그대로 만들어 주는 것은 양측 모두를 실패로 이끈다. 대다수의 엔지니어링 팀은 자신들이 정확히 무엇을 원하는지 모른다. 요청한 것을 그대로 구현해 주어도 실제로 도입하지는 않을 수 있다.

나도 수없이 하던 말이다. 고객은 자신이 원하는 것을 정확히 알지 못하고 대부분은 문제의 원인보다는 해결책을 가져오기 때문에 원인을 정확히 알아야 한다. 그리고 OO가 안되어서 아직 쓸 수 없다고 말하는 대부분의 사용자는 OO가 생긴다고 해서 사용하지 않는다. 이건 B2C 제품에서도 똑같다고 생각하는데 그 말이 가짜로 말했다거나 그런 게 아니라 제품을 사용한다는 건 불편함보다는 필요성이나 유용성 때문이 훨씬 크다.

널리 쓰일 플랫폼을 만들려면 특정 고객의 요구사항을 넘어 일반화할 수 있는 문제를 파악하는 방법을 익혀야 한다.

앞에서 플랫폼이 opinionated여야 한다는 의미도 이 일반화할 수 있는 문제를 파악해서 그걸 해결하면서 생기는 마찰을 이겨내어야 하는데 또 그게 고집이나 오만이 아니라 실제로 잘 판단해야 한다.

핵심은 기술 자체가 아니라 기술을 사용할 사람들에 초점을 두고 고객 공감 문화(culture of customer empathy)를 조성하는 것이다.

과연 사람들이 원하는 것을 만들고 있는가? 그것을 어떻게 아는가?

내부 고객 대응의 모든 난제는 우리가 '기능 공장의 함정(Feature Shop Trap)'이라 부르는 상황에서 정점을 이룬다. 기능 공장의 함정이란, 플랫폼 팀이 좀 더 전략적인 제품 로드맵을 전달하는 데 필요한 타협안들을 밀어붙이는 대신, 고객들의 기능 요청을 처리하는 일에만 매몰되는 현상을 말한다.

어떤 면에서는 기능 공장이 되었다가 다시 빠져나오기를 반복하게 되는 것 같다.

전사적 클라우드 이전 계획과 같이 수요가 급증하는 상황에서는 어떨까? 이 경우 플랫폼 팀은 '선별 적용 모드(triage mode)'로 전환해서, 가장 많은 고객 그룹을 만족시키기 위해 자주 요청되는 클라우드 제품부터 처리하게 된다.

이런 문제에 골몰하다 보면 여러분은 갑자기 제품 관리 시간의 대부분을 그저 각각의 작업을 선택하고 정당화하는 데에만 사용하게 되며, 이 상황에서 벗어날 방법을 찾을 시간은 없어진다.

대체로 플랫폼 팀들이 이런 함정에 빠지는 이유는 두 가지 실수 때문이다. 첫째는 플랫폼 아키텍처가 추가 수요를 감당할 준비가 되기 전에 제품 도입을 확장하려는 압박에 굴복하는 것이고, 둘째는 고객의 요청이 구체적이라는 이유로 그 요청을 충실히 이행하는 것이 최선의 대응이라고 가정하는 것이다.

이건 정말 빠지기 쉬운 함정이다. 둘 다 실제로 의미 있기 때문이다. 플랫폼을 만들고 나서 지금 돌아보면 도입률을 늘리려는 유혹을 어느 정도 내려놓았던 게(내가 생각한 건 아니었지만...) 정말 좋은 수였다고 생각한다.

고객들이 요구사항을 제시하고 플랫폼 팀이 그것을 처리해서 해금해 줄 때까지 기다리는 데 익숙해지면, 그리고 도입률이 충분히 높아진 상황이라면, 플랫폼을 더욱더 셀프서비스화하기 위해 고객의 구체적인 요청을 뒤로 미루는 것을 정당화하기가 어려워진다.

이를 달성하려면 기능 요청들을 살펴보고 그 요청들이 대표하는 패턴을 생각해 봐야 한다. 플랫폼을 어떻게 발전시켜야 고객이 플랫폼 팀을 기다릴 필요 없이 특정 범주의 기능들을 스스로 구현할 수 있을까? 모든 고객의 기능 요청에 직접 대응하는 대신 이러한 더 광범위한 전략적 작업에 우선순위를 두는 것을 두려워하지 말아야 한다.

새로운 기능 요청은 가급적 해당 고객은 물론이고 미래의 고객 모두를 돕는 솔루션으로 이어질 만한 것일 때만 받아들이고, 협상이 필요한 일회성 맞춤 요구는 최대한 거부하는 것을 목표로 삼아야 할 것이다.

동의하고 계속 노력하지만, 구체적인 요구사항이고 이유가 있기 때문에 쉽지 않은 일이기도 하다.

플랫폼 엔지니어링 팀은 혁신의 최전선에 있는 '개척자(pioneer)' 역할을 담당하는 것이 아니라, '정착자(settler)'와 '도시계획가(town planner)' 역할을 수행한다. 즉 작은 그룹이 성공적으로 개척한 아이디어를 가져오면 그것을 좀 더 광범위한 팀들이 유용하게 사용할 수 있도록 확장하는 것이다
이를 위해 여러분이 장려해야 할 문화는, 아이디어의 출처에는 너무 집착하지 않고, 고객의 요구를 충족하는 최고의 제품 아이디어를 찾는 데 집중하는 것이다.

파트너 팀이 찾아와 그들의 다양한 문제를 해결할 무언가를 구축할 계획이 플랫폼 팀에 있는지 물어볼 가능성이 높다는 이점이 생긴다.

종종 아이디어의 출처에 집착하게 되는 모습이 생각나서 반성하게 되었다.

고정된 사용자층이 있음에도 플랫폼 팀은 고객들이 도입하지 않는 미완성 제품을 만드는 것으로 악명 높다.

나도 이런 경험을 많이 해봤다. 그래서 플랫폼을 잘 만들고 싶다고 생각했던 거 같다.

단순히 거친 가장자리를 다듬는 데만 집중하다 보면, 문제를 완전히 재고찰(rethinking)할 기회를 놓칠 수 있다.
프레임워크와 도구에서 플랫폼으로의 진화는 그 자체로 재고찰이다. 하지만 이 점을 완전히 받아들이지 못하는 플랫폼 팀도 있다. 고객의 삶을 편하게 만들어줄 코드 조각을 제공하는 데만 치중한다면, 소위 '가장자리 다듬기의 함정(edge-smoothing trap)'에 빠질 위험이 생긴다

우리는 여러분이 문제를 재고찰하는 것부터 제품 접근 방식을 시작하길 권장한다. 무언가를 더 쉽게 만드는 대신, 사용자가 이것에 대해 알 필요가 있는지 자문해 보라.

플랫폼의 레버리지는 운영을 통해 프로세스를 소유할 때만 제대로 발휘된다. 플랫폼 팀이 해결책의 일부만 지원한다면, 플랫폼 팀이 소비하는 예산과 인력을 정당화하기 힘들다.

문제를 재고찰하는 건 정말 중요하다 가장자리 다듬기라는 말도 맘에 드는데 플랫폼이 고도화되고 가만히 놔두면 이쪽으로 자연스레 흘러가게 되는 거 같다. 실제로 이게 의미가 있기 때문에 더 이렇게 된다. 그래서 계속 환기하고 해결하려는 본질적인 문제가 무엇인지 고민해 봐야 한다.

애초에, 고객들이 실무 그룹에 참석해서 제품이 어떤 모습이어야 하는지 정확히 말해주길 기대해선 안 된다. 그런 시도가 잘 안되는 이유는 여러 가지이다. 우선 고객들은 바쁘다. 그리고 상세한 요구사항 문서를 작성할 수 있는 제품 관리자도 아니다. 또한 고객이 현재 겪고 있는 문제를 설명할 수는 있다고 해도, 미래의 시스템을 어떻게 사용할지 추상적으로 추론하기는 어렵다. 대부분의 사람은 그 정도의 추상적 사고를 잘하지 못한다. 특히 한 번도 사용해 보지 않은 새로운 기술에 대해서는 더욱 그렇다.

어떤 경우이든, 고객에게 아이디어가 그들의 요구를 충족하는지 물어보는 대신 고객이 실제로 무엇을 원하고 필요로 하는지 파악하기 위해 더 큰 노력을 기울이는 것은 항상 필요한 일이다.

이건 취향이면서 내 약점이라고도 생각하는데 이쪽의 생각이 아주 강해서 난 잘 물어보지 않는다. 말로 나오는 것보다는 행동을 관찰하고 거기서 문제의 근원을 찾아봐야 한다고 생각하는 편이다. 그래도 물어봐서 쉽게 해결할 수 있는 부분도 있는데 이쪽으로 편향이 심한 거 같아서 고민하는 부분이기도 하다.

이 책에서 마이그레이션을 자주 다루는 이유는 이것이 플랫폼 엔지니어링의 핵심적인 부분이기 때문이다.

제품 관리자는 제품 결정을 내릴 때 마이그레이션 비용을 고려해야 한다. 이 점을 주의하지 않으면, 마이그레이션 비용 때문에 새로운 제품이 제공하는 가치가 사소하게 보일 수 있다.

마이그레이션은 정말 중요하다. 뭔가 만들 때 마이그레이션까지 한꺼번에 고려해야 하는데 마이그레이션 비용은 언제나 생각했던 것보다 너무 크다.

6장 플랫폼 운영

사내 코드나 OSS, 벤더 시스템, 또는 이들 간의 상호작용으로 인한 문제를 신속히 진단하고 해결할 수 있는 온콜 인력은 누구여야 하는가? 우리의 답은 통합된(merged) 팀만이 지속 가능한 방식으로 필요한 수준의 전문성을 갖춘 온콜 순환 근무 스케줄을 운영할 수 있다는 것이다.

지금 소속된 팀을 통합된 팀으로 운영하는 것이 여전히 맞다고 생각한다.

우리의 경험으로 볼 때, 24시간 연중무휴 온콜이 지속 가능하려면 비즈니스에 영향을 미치는 호출(이하 간단히 비즈니스 영향 호출)이 주당 5건 미만이어야 한다.

우리는 주당 5건을 넘는 요청들이 이어지는 온콜 업무는 지속 가능하지 않다고 굳게 믿는다.

5건? 5건? 흠... 나에게 온콜은 아직 고민 중인 영역이다.

사용자가 자신들만큼 플랫폼에 대해 생각하고 있다고 믿는 플랫폼 팀은 더 나은 플랫폼을 만드는 데 도움이 되는 방식으로 사용자의 문제에 접근하지 못하고 있는 것이다. 사용자의 문제로부터 격리된 채 일하는 엔지니어들은 그런 사고방식에 빠지기 쉽다.

플랫폼 팀이 기능 개발과 운영 투자의 균형을 맞춤으로써 운영 문제가 심각해지는 것을 미리 방지하는 데 도움이 되는 네 가지 필수 관행을 살펴본다. 이 관행들은 운영 중인 애플리케이션(프로덕션 애플리케이션)의 수명 주기(lifecycle)에 관한 것이다. 첫째는 SLO와 SLA를 요구사항들에 기반해서 작성하는 것이고, 둘째는 변경을 관리해서 릴리스의 고품질을 보장하는 것, 셋째는 합성 모니터링을 이용해서 기본적인 관측성을 제공할 뿐만 아니라 실행 중인 시스템의 장애를 적극적으로 감지하는 것, 마지막은 운영 검토를 통해 최근 이력을 살펴보고 잘된 점과 그렇지 않은 점을 검토하여 향후 작업과 주력 분야에 반영하는 것이다.

우리 저자들은 오류 예산이 과대 평가되었으며 활용 비용에 비해 충분한 이점을 주지 않는 경우가 많다고 생각한다.

SRE 책에서 오류 예산에 감명받기는 했지만 실제 적용을 고민할 때는 회의적으로 되었는데 오류 예산은 이제 크게 생각 안 해도 되겠단 생각이 들었다. 운영의 필수 관행을 꼽씹어 볼 가치가 있다.

플랫폼 팀이 내부적으로 SLO를 사용하는 방식과는 정반대라는 점이다. 내부적으로는 시스템의 운영 조건과 위험을 이해하는 것이 가장 중요하다. 따라서 대신 다음 세 가지 규칙을 따라야 한다.
• SLO가 많을수록 좋다(네댓 개보다는 훨씬 많이). 시스템 포괄도(coverage)를 최대화하기 위해서이다.
• 거짓 양성을 최소화하지 않는다. 중요한 문제를 놓칠 수 있기 때문이다.
• 거짓 음성과 거짓 양성 모두 설명과 개선이 필요하다. 거짓 양성 때문에 운영 부하가 너무 높아지지 않도록 하기 위해서이다.

내부 SLO에 대한 명확한 기준을 주어서 좋았다. 그리고 거짓 양성에 관해서 민감하게 다루던 편인데 이 말을 보고 다시 생각해 보게 되었다.

프로덕션에 대한 모든 변경(change) 사항은 코드 변경의 모범관행에서처럼 엄격한 관리가 필요하다.

정말 중요하다.

릴리스 엔지니어링에 몰두하면, 플랫폼 자동화가 어느새 완전한 기능을 갖춘 그림자 배포 플랫폼으로 바뀌게 된다. 이는 작업 중복의 비용을 넘어 정치적 문제까지 야기할 수 있다. 중복에 대한 기술적 이유가 타당하더라도 문제가 된다. 플랫폼 엔지니어링 팀이 자신들의 제품을 신뢰하지 않는다는 인상을 주며, 여분의 엔지니어가 많아서 자체 그림자 플랫폼까지 구축할 수 있다는 인상을 준다. 플랫폼 팀이 한 해에 12개월 이상의 개발자 시간을 릴리스 엔지니어링에 쓰고 있다면 과도하게 구축하고 있는 것일 수 있다.

릴리스 엔지니어링이라고 부르진 않지만 비슷한 일에 몰두하고 있어서 이 말의 의미를 고민해 보고 있다. 사실 저자의 의도를 명확하게 이해하진 못했다.

플랫폼에서 더 많은 투자가 필요한 관측성 측면이 하나 있다. 바로 합성 모니터링(synthetic monitoring)이다. 능동적 모니터링(active monitoring)이라고도 불리는 합성 모니터링은 실제 프로덕션 플랫폼과 상호작용하는 사용자를 시뮬레이션한다. 지연과 가용성뿐만 아니라 기능의 정확성도 측정하며, 목표치를 달성하지 못하면 경고를 발생한다.

합성 모니터링의 유용성은 알지만, 아직 잘 관리하는 방법은 못 찾았다.

여기에 운영 검토(operational review)라는 관행을 추가하면, 데이터를 바탕으로 행동을 이끌어내는 하나의 피드백 루프가 완성된다. 운영 검토는 숙련된 운영 조직들에서 배운 관행이다. 엔지니어와 관리자가 정기적으로(보통 매주) 모여서 SLO 지표 같은 광범위한 지표와 사고 사후 분석과 같은 구체적인 사항을 검토한다.

팀 수준 운영 검토는 단순하고 엄격하게 유지하라
팀 수준에서 운영 검토의 기본은 매주 30분 또는 60분 동안 다음 사항들을 검토하는 것이다.

조직 수준의 검토는 필수적이지만, 프로세스보다는 관행을 중시하라.

운영 검토라는 건 여기서 처음 배웠지만 포스트모텀이라고 하면 이해하기 어렵진 않다. 이런 운영 검토가 중요하다는 것은 동의하지만 실제로 하려면 또 회의가 너무 많아져서 조직 문화에 잘 자리 잡게 하는 건 쉽지 않다.

7장 계획과 전달

사용자들보다 자신들이 더 잘 안다고 가정하는 상아탑적 사고방식도 있었다

새로운 플랫폼 프로젝트를 시작할 때는 다음과 같은 골의 법칙(Gall's law)을 명심하는 것이 좋다.
잘 작동하는 복잡한 시스템은 모두 잘 작동하던 단순한 시스템을 진화시킨 것이다. 그 역도 마찬가지이다. 복잡한 시스템을 무無에서 출발해서 설계하면 절대로 잘 작동하지 않으며, 잘 작동하게 만들 수도 없다. 반드시 잘 작동하는 단순한 시스템에서 다시 시작해야 한다.

플랫폼이 고도화될수록 단순한 시스템에서 시작하는 건 중요한데 또 고도화되어 있기 때문에 잘 먹히지 않는 것도 사실이다.

플랫폼 팀은 모든 요구사항을 충족하는 범용 시스템을 구축함으로써 모두를 만족시키는 것이 자신들의 임무라고 생각하기 쉽다. 그래서 제2장에서 설명한 해결책 중 하나를 선택하는 대신, 포장도로(paved path) 방식과 철도(railway approach) 방식을 둘 다 선택하는 실수를 저지르곤 한다. 한 가지 접근 방식을 선택하지 못하면 결국 당면한 요구를 충족시키지 못하게 된다.

"빨리 움직이고 실수를 저질러라"라는 태도를 권장하는 스타트업에서 리더가 제품을 만들 때 제품 적합성을 찾아 허둥대는 것이 큰 흠이 아닐 수 있다. 하지만 플랫폼 세계에서는 이런 행동이 플랫폼 팀의 평판을 나쁘게 만든다.

범용 시스템은 안된다.

전달이나 운영상의 압박이 없는 팀이라면, 고객 가치의 전달이 제대로 이루어지는지 확인하는 계획 하나만 있어도 충분할 것이다. 하지만 팀이 전달이나 운영의 측면에서 압박을 받는 상황이라면 제품 로드맵 외에 상향식 로드맵(bottom-up roadmap)이라는 좀 더 세부적인 로드맵이 필요하다.

추정이 필요한 세 가지 작업 영역을 설명할 것이다. 첫째는 시스템과 서비스를 원활하게 유지하는 데 필수적인 운영 작업인 KTLO(keep the lights on; 점등 유지) 작업이다. 둘째는 경영진이 하달한, 타협이 (거의) 불가능한 프로젝트인 경영진 지시사항(executive mandates)이다. 셋째는 플랫폼의 운영, 효율성, 보안, 신뢰성, 규정 준수를 개선하는 시스템 개선(system improvement) 작업이다.

난 계획을 세밀하게 세우진 않는 편이라서 큰 맥락에서는 동의하지만, 제일 관심 간 건 KTLO이다.

핀옵스 작업이 복잡하긴 해도, 이를 전담 업무로 삼으라고 하면 대부분의 시스템 엔지니어는 반기지 않을 것이다. 프로덕션 시스템 측면에서 충분히 '실무적(hands-on)'이지 않기 때문이다. 그들이 정말 좋아하는 것은 효율성 개선의 둘째 범주인 성능 엔지니어링(performance engineering)이다.

핀옵스 업무도 현재 팀에서 하고 있는데 이건 정말 어렵다. 우리 업무인 듯 아닌 듯 묘한 위치에 있어서 핀옵스 팀이 따로 있는 다른 조직은 어떻게 운영하는지 정말 궁금하다.

플랫폼 팀이 KTLO가 아닌 프로젝트의 시간을 증분(점진적) 작업, 대규모 아키텍처 프로젝트, 전혀 새로운 플랫폼에 배분할 때는 구글의 70/20/10 모델(https://oreil.ly/zPJsK)을 참고하면 좋다.
• 70%는 핵심 이니셔티브(현재 플랫폼의 증분 작업)
• 20%는 핵심과 인접한 혁신(플랫폼 아키텍처 재구축)
• 10%는 변혁적 혁신(transformational innovation; 완전히 새로운 플랫폼)

이렇게 할 것은 아니지만 적당한 비율은 고민해 볼 때 도움이 된다.

문제가 된 라이브러리를 조사한 카미유의 팀은 이 작성자가 디스커버리 서비스 API 범위를 벗어난 주키퍼 기능을 사용하기 시작했다는 것을 알게 되었다. 이는 두 가지 교훈을 동시에 주었다. 하이럼의 법칙(Hyrum's law)이 진리임을 깨달았을 뿐만 아니라, 플랫폼 생태계의 일부인 코드를 내부소싱하는 것이 위험하다는 점도 배울 수 있었다.
내부소싱의 기본 개념은 오픈소스 소프트웨어처럼 누구나 코드베이스에 기여할 수 있게 함으로써 개발자들이 스스로 해금할 수 있게 하는 것이다. 경영진은 "기능을 기다리며 막혀있는 사람은 누구나 직접 코드를 작성하여 기여할 수 있다!"라고 말하면서 자신이 협업에 개방적으로 보일 수 있다는 점에서 이 모델을 선호한다.

여기서 내부 소싱이라는 것은 InnerSource를 얘기하는 것인데 경영진에게 이러한 문화가 매력적으로 보일 수 있다는 점은 생각해 본 적 없긴 하다.(실제로 그런가?) InnerSource에 대해서 발표한 적도 있고 어느 정도 지지하지만, 또 플랫폼 관점에서 나는 하이럼의 법칙을 피하려고 외부 호환성을 최대한 줄이고 있어서 실제 이 책이 말하는 것처럼 하고 있다는 걸 깨달았다.

8장 플랫폼 아키텍처 재구축

그런 영역 중 하나라도 계속해서 성장한다면, 시스템의 아키텍처가 결국 병목 지점이 될 것이다.
이것이 우리가 아키텍처 재구축(rearchitecting)이라고 부르는 접근 방식을 채택하는 이유이다. 이것은 시스템을 중단 없이 가동하면서(부하를 계속 처리해 나가면서) 아키텍처를 반복적, 점진적으로 재구현하는 과정이다.

일반적인 플랫폼 엔지니어링 팀 문화에서 v2를 설계하고 전달하는 것의 어려움을 고려하면, 아키텍처 재구축이 결국 올바른 접근 방식이라고 본다.
1964년에 처음 관찰된 제 2 시스템 효과(second-system effect)라는 잘 알려진 현상부터 살펴보자. 시스템의 버전을 하나만 구축한 팀은 두 번째 시도에서는 모든 결함을 해결할 수 있다고 가정하는 경향이 있다.

지금 플랫폼이 어찌 보면 완전히 새로 만든 v2라고도 할 수 있고 이 내에서 재구축을 해본 적도 있는데 결국 플랫폼의 접근을 했을 때는 재구축이 정답이라는 것에 동의한다.

애플리케이션 엔지니어가 억지로 '보안을 인식하도록' 요구하지 않는다. 대신 시스템 설계를 가장 강력한 레버리지 지점으로 삼아, 보안을 플랫폼의 기능과 아키텍처에 녹여내서 자연스럽게 만든다.

'설계에 의한 보안'이 아니라, '보안이 기본(secure by default)'인 애플리케이션을 만들어야 한다. 보안을 위한 회복력이 기본이 되게 하려면 개발자들이 반드시 안전한 옵션들을 옵트아웃으로 취급해야 한다. 여러분은 개발자들이 그런 쪽으로 이동하도록 계기를 제공하되('넛지nudge'), 예외는 허용해야 한다.

올해 국내에 보안 이슈가 많기도 했지만, 원래도 관심 있는 부분이라 이 말처럼 하고 싶은데 보안 쪽은 내 전문 영역은 아니라서 그런지 꽤 어렵다. 몇 년 내에 해결하고 싶은 이슈이기도 하다.

'최소 저항' 경로의 인기 있는 명칭이 포장도로(paved path)이다. 포장도로는 일반적인 문제들에 대한 잘 통합되고 지원되는 하나의 해결책으로, 사람들이 고유한 가치 창출에 집중할 수 있게 한다. 특정 옵션을 기본값으로 지정함으로써(이때 중요한 점은 회복력 있는 방법이 더 쉬운 방법이 되도록 하는 것이다), 여러분은 표준화를 촉진하고 선택의 과부하를 줄이게 된다. 이에 의해 조직의 기본값을 더욱 회복력 있게 구성할 수 있다(심지어 일부 팀이 안전한 옵션을 명시적으로 거부하는 경우에도).

아키텍처 재구축이 성공하려면 기존 사용자의 서비스 이용에 미치는 영향을 최소화해야 한다. 가장 이상적인 경우는 사용자가 변경 사실을 전혀 눈치채지 못하는 것이다.

이건 경험을 통해서도 동의한다. 항상 사용자가 변경을 모르도록 하는 것을 최우선으로 고민해야 하고 이를 통해서 플랫폼의 가치를 훨씬 더 증명할 수 있다.

플랫폼 팀이 범하는 안티패턴을 하나 짚고 넘어가려 한다. 바로, 새로 채용된 엔지니어들에게 플랫폼의 아키텍처 재구축을 맡기는 것이다. 특히 이전 직장에서 다음 단계의 플랫폼 성숙도를 경험했고 현재 상태에 대해 훌륭한 통찰력을 제시하는 신입 직원의 경우 더욱 그렇다.

이건 무조건 안티 패턴.

9장 플랫폼 마이그레이션과 폐지 처리

뛰어난 플랫폼 팀은 이러한 도전 속에서 마이그레이션을 오히려 자신들의 가치를 입증할 기회로 삼는다. 팀은 필수적인 마이그레이션에 따르는 고객의 고통을 덜어주고, 고객들이 핵심 기능의 전달에 집중할 수 있도록 작업량을 줄이거나 없애는 것을 자신들의 임무로 여긴다.

나도 마이그레이션을 힘들어하는 편인데, 여기에 가치를 주고 마이그레이션이 중요하다는 인식을 공유하는 것이 중요하다.

플랫폼 추상화(platform abstraction)를 잘 구축했다면, 바탕 구성요소들을 마이그레이션할 때 애플리케이션 팀이 변경해야 할 자체 접착제가 최소화된다. 같은 시스템의 서로 다른 버전의 수를 제한하면 해당 시스템을 변경할 때 수행해야 할 테스트가 줄어든다. 버전들을 표준화하고 제한할수록 이러한 변경 시 걱정해야 할 조합이 줄어든다.

고객에게 가장 좋은 마이그레이션 경험은 고객이 해야 할 일이 따로 없는 것, 더 나아가서 마이그레이션이 일어나는 것조차 알아차리지 못하는 것이다.

아까도 말했듯이 실제 이 방법으로 플랫폼의 가치를 증명하고 사람들이 플랫폼으로의 마이그레이션을 더 선호하도록 만들 수 있었다.

세계의 상태에 대한 메타데이터를 수집하고, 무엇이 어디에 배포되어 있는지 파악하며, 배포를 위한 코드를 사람과 팀에 연결하는 방법을 이해하는 것, 이 모든 것이 플랫폼 엔지니어링 여정의 초기에 수집해야 할 강력한 지식이다.

수년간 많은 사람이 입사와 퇴사를 거듭하다 보면, 여전히 쓰이고 있지만 누구도 소유권을 가지지 않은 기술 자산들이 생긴다.

이러한 '조직적 표류(organizational drift)' 때문에 플랫폼 자체의 발전이 저해되는 것은 플랫폼 엔지니어링의 숨겨진 난제 중 하나이다.

처음 만들 때 이런 장기적 고민까지 한 것은 아니지만 초기에 여기서 말하는 메타데이터를 추적하고 갱신한 방법을 준비해 놓은 것은 많은 도움이 된다고 생각한다.

많은 프로젝트가 그렇듯이, 마지막 20%가 처음 80%보다 더 어려워 보일 수 있다(그리고 마지막 5%는 거의 불가능해 보일 수도 있다). 아마도 남아 있는 것은 위험도가 가장 높거나, 가장 오래되었거나, 가장 중요하거나, 가장 많이 커스텀화된 애플리케이션일 것이다.

내가 만드는 플랫폼에서 지금 마지막 20% 마이그레이션을 고민하고 있는 시점이라서 더 공감된 부분이다.

어쩌면 이렇게 생각하는 독자도 있겠다: "이 마이그레이션은 아주 중요하니, CTO에게 말해서 모든 사람이 이 마이그레이션을 의무적으로 완료하라고 지시하게 만들면 되지 않을까?

우리의 조언은, 필수적인 사항에 대해서만 의무화를 요청하고, 가능하다면 다른 필수 과제를 만족시키는 것과 연계하라는 것이다

플랫폼 팀이 의무화 접근 방식을 너무 자주 사용하는 것은 바람직하지 않음을 유념하자. 너무 자주 사용하면, 애플리케이션 엔지니어들이 비즈니스를 위해 일하는 것이 아니라 플랫폼 팀의 프로젝트를 위해서만 존재하는 것처럼 보이는 문화가 조성될 수 있기 때문이다.

초기에 나도 이러고 싶은 충동을 많이 느꼈지만, 지금은 절대 선호하지 않는다. 선호하지 않는 이유는 내가 서비스팀에 있는데 이런 지시를 받는다면 동의하지 않을 것이기 때문이다.

10장 이해관계자 관리

제품 관리는 고객을 위해 올바른 것을 만드는 것이고, 이해관계자 관리는 리더들에게 여러분의 선택이 옳다고 납득시키는 것이다.

여러분의 팀이 다른 지도층이나 엔지니어링 팀들의 방해 없이 필요한 플랫폼을 구축할 수 있도록 보장하고 싶다면, 이해관계자들과의 관계를 잘 관리하는 것이 필수이다.

한쪽만이 원하는 것을 얻게 되는 중요한 의사결정 과정에 여러 번 참여했고, 동료들이 회사의 이익이 아니라 자신의 경력과 영향력을 위해 엉뚱한 주장을 펼치는 것처럼 보이는 모습도 목격했다. 하지만 우리가 존경하는 동료들도 이런 사리사욕으로 비난받는 것을 보았고, 심지어 우리 자신도 그런 비난을 받은 적이 있다. 우리는 여기에 회사가 '정치'를 만들어내는 '얼간이(jerk)'들을 채용한 실수 이상의 문제가 깔려 있음을 깨달았다.

이제 우리는 이 문제가 개인보다는 조직의 크기와 더 관련이 있다는 것을 이해한다.

이는 강력한 기업 문화가 있더라도, 여러분이 보기에 '회사를 위한' 올바른 결정이 다른 사람의 관점에서는 그렇지 않을 수 있는 상황이 필연적으로 발생한다는 것을 의미한다.

이해관계자 관리는 갈등이 발생했을 때 동료들이 자기 팀의 불만만 듣고 모든 것을 여러분의 탓으로 돌리지 않도록 여러분의 관점과 맥락을 이해시키는 활동이다.

이해관계자가 여러분을 내부 벤더(internal vendor)로 간주하고, 자신의 업무가 얼마나 중요한지를 여러분이 이해하지 못한다고 생각한다.

이해관계자가 여러분의 일을 자신이 더 잘할 수 있다고, 그래서 여러분의 팀을 더 잘 관리할 수 있다고 생각한다.

이해관계자에 관한 건 내가 잘 못하는 부분이라서 곱씹어보는 목적으로 남겨둔다.

이해관계자가 여러분의 성과를 인정하지 않는다. 어제 여러분이 해준 일이나 1년 전보다 얼마나 플랫폼이 개선되었는지를 잊어버리는 이해관계자들이 있다. 특히 더 많은 개선이 필요하거나 아직 해결되지 않은 문제가 있을 때, 문제가 없어진 것을 알아차리지 못하는 것은 인간의 본성이다.

인간의 본성이라는 것에 동의한다. 종종 서운한 맘이 들 수 있지만 그런 부분은 덜 신경 쓰는 게 좋다.

이해관계자들은 자신이 비즈니스 수익과 성장에 더 가까이 있으므로 비즈니스에 '옳은' 것을 내부용 플랫폼 팀보다 더 잘 이해한다고 생각하기 마련이다. 그런 이해관계자들이 비합리적이라는 생각도 들겠지만, 여러분이 그들의 관점을 잘 고려하고 있다고 느끼게 하도록 신중하게 대응해야 한다.

플랫폼 리더들은 종종 비즈니스 영향에 대해 안이한 태도를 보인다.

플랫폼 소유자로서 피해야 할 두 가지 극단이 있다.
항상 "예"라고 말하는 기능 공장이 되는 것
첫째는 들어오는 모든 요청에 즉각 반응하여 최대한 빨리 기능이나 서비스를 덧붙이려 하는 '반응적 극단(reactionary extreme)'이다.
비전에 대한 헌신보다 당장의 만족을 주려는 충동이 더 강하면 이런 상황이 될 수 있다.
회사에 대한 가치를 완벽하게 판단한다는 생각에서 항상 "아니요"라고 말하는 것
그 반대편 극단은 플랫폼 소유자가 완전히 경직되어서, 자신이 옳다고 생각하고 플랫폼 전략에 부합하는 것만 구축하는 것이다.

항상 고민하는 부분이다. 항상 예라고 하는 것은 쉽지만 결국 플랫폼에 문제가 생길 것이고 아니요라고 하면 잘못하면 신뢰를 잃게 된다.

아직은 안 됩니다, 우선순위 때문에요.
우선, 아예 안 되는 것인가, 지금 당장은 안 되는 것인가를 구분해야 한다. 때로는 가치 있고 하고 싶은 요청이지만 현재로서는 우선순위를 매기기 어려울 수 있다. 이런 경우 언제쯤 전달이 가능할지, 그리고 더 빨리 필요하다면 어떤 대안이 있는지 명확히 알려줘야 한다.

아직은 안 됩니다, 기술적인 문제로요.
"아직은 안 됩니다"의 다른 버전으로, 기술적으로 준비가 안 된 경우이다.

안 됩니다, 제품 전략상 문제로요.
모든 것을 플랫폼에 포함할 필요는 없다. 누군가 관심을 보인다고 해서 모든 기능을 수용하는 '제국 건설자(empire builder)'가 되려는 유혹을 이겨내야 한다. 제품의 핵심 임무를 이해하고, 그에 맞지 않는 것은 거절해야 한다.

안 됩니다, 기술적으로 불가능해요.
마찬가지로, 기술적으로 실현 불가능한 사항이라면 그 점을 지적해야 한다. 플랫폼 팀의 리더급 직책에 이전 엔지니어 출신을 포함하는 것이 바람직한 이유가 바로 이것이다.

도움을 주지 못하더라도, 그들의 문제에 관심이 있다는 것을 보여주는 것이 향후 관계에 중요하다. 따라서 아예 대화를 끊어버리는 태도는 피하는 것이 좋다.

아니요라고 하면서도 계속해서 기능 요청과 이슈를 편하게 요청하게 하는 신뢰 관계는 계속 필요하다. 이 관계가 구축되지 않는다면(보통 쉽지 않다) 인프라나 플랫폼 팀은 항상 아니요라고 말할 거니까 물어볼 필요도 없다고 판단하고 다른 방법을 찾게 된다.

이해관계자들과의 최악의 관계 중 일부는 '그림자 플랫폼(shadow platform)' 구축과 관련해서 빚어진다. 앞 장에서 설명했듯이 그림자 플랫폼은 현재 플랫폼의 기능을 복제한 시스템이다. 현재 플랫폼과는 다른 OSS와 벤더 기술을 사용할 때가 많으며, 기능 집합(feature set)이나 시스템 특성(비용, 성능, 신뢰성)이 조금 다를 때도 있다.

플랫폼 팀의 '거절' 뒤에 숨은 운영 비용을 이해하지 못한다.
때로는 팀이 여러분의 거절을 듣고도 그것을 구축하기로 결정한다. 운영 비용이 그들이 예상한 것보다 훨씬 클 것이라고 확신함에도 말이다. 플랫폼 팀의 관점에서, 그런 팀의 잘못된 판단은 대단히 짜증스럽다. 특히 이것이 결국 여러분이 지원해야 할 무언가로 부메랑처럼 돌아올 것을 알 때 더욱 그렇다.

문제에 가까이 있는 사람들로부터 좋은 아이디어를 많이 건질 수 있다는 점을 기억하자. 때때로 여러분의 팀은 구현은 의심스럽지만 아이디어 자체는 좋은 사례들을 발견하게 될 것이다. 뒷정리가 필요할 때는 그것을 기회로 받아들이자.

이 부분은 나에게는 스트레스인 부분이기도 하다. 특히 숨은 운영 비용에 대해 설명하는 것이 자칫하면 생색내는 거 같기도 해서 말하기가 쉽지 않은데 알아서 알아주지도 않는 부분이다. 그리고 예상한 대로 결국 부메랑처럼 지원해야 하는 영역으로 돌아올 때 더 힘들다. 이 부분은 마지막에서 좀 힌트를 얻었다. 너무 부정적으로만 보면 해결될 것도 없는데 거기서 아이디어를 발견할 수 있다는 생각을 해보는 것도 좋을거 같다.(어느 정도까지만..)

3부 성공은 어떤 모습일까?

80%의 사용자를 만족시키는 '포장도로'를 만들어도 나머지 20%는 자신의 요구사항이 반영되지 않았다며 불평한다.

실제로 그러하다. 그게 큰 문제라는 게 아니라 그냥 그러하다.

우리는 플랫폼 엔지니어링의 성공을 이야기할 때 교과서적인 '지표와 측정(metrics and measures)'을 주된 기준으로 삼는 것에 반대한다.

동의하는 부분이다. 지표와 측정은 중요하지만 조심하는 편이라 그런지 아래 말이 더 와닿았다.

우리는 다음 네 가지 영역에 초점을 두고 지속적인 성공을 평가하는 총체적인 접근 방식을 권장한다.
• 플랫폼이 정렬되어 있는가?
• 플랫폼이 신뢰받는가?
• 플랫폼이 복잡성을 관리하는가?
• 플랫폼이 사랑받는가?

11장 플랫폼의 정렬

정렬(alignment)은 플랫폼 엔지니어링 팀의 성공을 총체적으로 평가하는 첫째 기준이다. 모든 플랫폼 팀에 대해 "팀원들 모두가 팀이 하는 일에 정렬되어 있는가?"라는 질문을 던져야 한다.

정렬은 흔히 다음 세 영역에서 실패한다.
목적
제품 접근 방식에 따라 비즈니스의 토대가 되고 폭넓은 고객층을 지원하는 소프트웨어 기반 추상화를 개발한다는 총체적인 사고방식(holistic mindset)을 가지지 못하고 그보다 좁은 관점으로 운영되는 플랫폼 팀은 목적(purpose)에 대해 정렬되지 않은 것이다.
제품 전략
사일로로 운영되며, 특정 목적에는 좋지만 불필요하게 다른 것들과 중복되거나 플랫폼 간 용례(use case)를 어렵게 만드는 플랫폼을 구축하는 플랫폼 팀은 제품 전략(product strategy)에 대해 정렬되지 않은 것이다.
계획 수립
가장 중요한 프로젝트를 실행할 때 서로 지원하지 않고 오히려 서로의 길을 방해하며, 일정과 상황 변화에 대해 고객과 잘못된 소통을 하는 플랫폼 팀들은 계획 수립(planning)에 대해 정렬되지 않은 것이다.

조직에서 정렬은 어려운 일인데 이런 식으로 구분해서 고민해 보는 건 도움이 되는 거 같다.

도입률에 집중하다 보면 플랫폼 팀은 미래의 플랫폼을 결정하고, 그 사용률을 100%까지 끌어올리고, 다른 모든 것을 최대한 빨리 폐기하는 것이 자신의 유일한 임무라고 여기기 시작할 수 있다. 하지만 100% 도입률은 고객이 플랫폼 사용 여부를 선택할 수 있을 때만 진정한 성공의 지표가 된다.

다른 발표에서도 얘기한 적이 있지만 배포 플랫폼을 만들면서 의도는 아니었지만 기존 배포 플랫폼도 그대로 놔두게 되었는데 선택권이 있다는 면에서 결과적으로는 새 배포 플랫폼에도 좋은 영향을 주었다.

내부 사용자를 단순한 이해관계자가 아닌 고객으로 대하고 고객과의 파트너십 기회를 통해 새로운 제품을 발굴하는 제품 관리 문화를 조성함으로써 여러분은 '우리 대 그들'이라는 사고방식을 깨고, 훌륭한 플랫폼 제품을 만드는 데 필요한 공감(empathy)을 발전시킬 수 있다.

공통 기능의 중복이 항상 문제가 되는 것은 아니다. 하지만 플랫폼들이 단순히 중복을 넘어 충원을 정당화하기 위해 같은 고객을 놓고 적극적으로 경쟁한다면, 이는 전체적으로 제품 전략이 부실하다는 뜻이다.

기능 중복에 대한 고민의 원인을 좀 깨닫게 해주는 말이었다.

아키텍처 검토 위원회(architecture review board, ARB)에 만연한 관료주의는 우리도 그리 반기지 않지만, 플랫폼 엔지니어링 조직의 최고 '수석/우수(principal/distinguished)' 엔지니어가 제품 관리 책임자와 같은 상급 리더에게 보고하도록 하는 것이 유용하다.

조직 보고 체계에 대해서는 잘 이해 못했지만, 만연한 관료주의는 피해야 할 부분이다.

12장 플랫폼에 대한 신뢰 구축

대규모의 기반(토대) 시스템 운영 능력은 실제로 그것을 운영해 봐야만 얻을 수 있다는 점이다.

일반적인 80%의 용례를 위한 풍부한 플랫폼을 구축하고 그 밖의 용례는 예외 사례로 제한함으로써, 팀이 그런 병목을 더 빠르게 해결할 수 있었다.

플랫폼을 처음 만들 때 80%를 목표로 했는데 이 말에 더 힘을 얻었다. 물론 현실에서는 80%가 높다는 판단해서 지금은 그보다는 좀 더 낮게 잡고 있다.

우리는 신뢰 구축 실패를 플랫폼 리더가 회사를 실망시키는 가장 흔한 방식 중 하나로 간주한다. 잘못된 리더는 자신의 오만함 때문에 자신이 누구보다 더 잘 안다고 믿으며, 적절한 투명성을 가지고 소통하려 하지 않고, 고객과 이해관계자의 의견은 무시한 채 자신의 팀만 신뢰한다.

13장 복잡성을 관리하는 플랫폼

플랫폼 엔지니어링이 필요한가? 플랫폼 엔지니어링은 복잡성 문제에 총체적으로 접근하여, 소프트웨어 및 시스템 전문가 팀이 애플리케이션 팀에 대한 복잡성의 부담을 줄일 수 있게 해주기 때문이다.

플랫폼이 모든 복잡성을 제거하는 것은 아니다. 플랫폼은 복잡성을 없애는 것이 아니라 효과적으로 관리(managing)함으로써 레버리지를 만들어낸다.

플랫폼을 성공으로 이끄는 길에서 여러분이 관리해야 할 네 가지 영역의 복잡성을 살펴본다.
• 우발적 복잡성(accidental complexity). 플랫폼이 복잡성을 해결하려다 문제를 다른 곳으로 옮기기만 하고, 종종 사람들에게 새로운 작업을 만들어내기도 한다.
• 그림자 플랫폼. 애플리케이션 조직이 민첩성을 유지하면서도 유사한 그림자 플랫폼이 많이 생겨나는 복잡한 결과를 피하려면 균형을 섬세하게 맞추어야 한다.
• 통제되지 않은 성장. 플랫폼 조직이 오늘 만들어 낸 기술 부채를 내일 채용할 새로운 엔지니어가 해결할 것이라는 가정만으로 복잡성을 관리해서는 안 된다.
• 제품 발견. 일부 문제의 경우 고객과 플랫폼 팀 모두에게 복잡성을 줄여주는 제품을 만들기 위해서는 전달을 반복적으로 시도해야 한다.

모든 것을 하나의 UI로 통합해서 사용자의 인지 부하를 줄이는 것은 불필요한 복잡성을 제거하는 현명한 방법처럼 보인다.

시간이 지나면서 팀의 '단일 창구'는 개발자가 자신이 원하는 UI에 도달하기 위한 추가적인 경유지로, 또는 기존 도구의 열등한 버전으로 전락했다.

다양한 개발자 요구를 창구를 단일화해서 통합하는 것은 바람직하지 않다. 다른 방식으로 일반화하는 것이 좋다. 그런 방식으로 개발자 경험을 구축하는 것이 가능한 시나리오도 있겠지만, 어떤 경우이든 목표는 단일 창구 자체가 아니라 사용자가 필요한 모든 것에 손쉽게 접근할 수 있는 인체공학적 설정이다.

단일 창구는 계속 목표로 해왔던 부분이라서 책에서 얘기하는 것과는 약간 다르다고 생각하지만, 다시 생각해 보게 되었다. 그럼에도 여전히 창구가 너무 많은 건 문제라고 생각하는 편이다.

접착제를 줄이려면 플랫폼은 각 애플리케이션 팀이 자체적으로 구축할 필요가 없는 추상화를 만들어 내야 한다. 접착제가 전체적으로 줄어든다는 것은 플랫폼이 애플리케이션 팀을 위한 인프라 복잡성을 줄였다는 신호다

인간 접착제 혹은 접착제 작업은 팀이 해야 할 일과 실제로 하는 일 사이의 간극을 해결하기 위해 필요한 모든 수동적 해결책, 문서화, 협업을 말한다.

그림자 플랫폼을 관리하려면 신뢰(제12장 참고)를 바탕으로 해야 한다. 해당 팀들과의 신뢰가 있어야 여러분이 상황을 파악할 수 있게 해준다. 다른 팀이 여러분을 믿고 관련 정보를 제공한다면, 여러분은 해당 프로젝트에 엔지니어를 파견하거나, 그 팀으로부터 정기적인 업데이트를 받거나, 향후 그 팀이 프로젝트를 이관하고자 할 때 필요한 사항에 대한 기대치를 설정하는 등 다양한 방식으로 대비할 수 있게 된다.

성장(growth)은 중독성이 있다. 플랫폼 팀을 초기 단계에서 안정적인 조직으로 성장시켰다면, 더 많은 일을 하기 위해서는 더 많은 인력을 투입하는 것이 유일한 방법이라고 생각하기 쉽다.

팀을 계속 키워가면서 이 부분을 곱씹어보게 되었다. 난 성장 중독에 빠진 것은 아닌지...

우리는 대부분의 혁신이 플랫폼 팀 자체가 아니라 자신에게 필요한 것을 구축하는 애플리케이션 팀에서 나올 것으로 기대한다.

팀들이 선택한 도구를 사용하는 이유가 단순한 습관인지 아니면 꼭 필요한 특정 기능 때문인지를 탐구해야 한다.

14 사랑받는 플랫폼

우리는 플랫폼의 핵심 지표를 '더 단순하게, 더 빠르게, 더 저렴하게, 그리고 사용자가 사랑하게'로 요약하는 플랫폼 제품 관리자를 본 적이 있다.

내부 플랫폼에서 '사랑'은 생산성 향상을 나타내는 좋은 지표이다.

'도입률'이나 '효율성' 같은 단순한 지표에만 집중하다 보면 복잡성을 관리하는 것이 아니라 제거하는 것을 목표로 삼게 된다. 그러면 애플리케이션 팀이 사랑하는 시스템이 아니라 플랫폼 팀이 통제하기 쉬운 시스템을 만드는 결과로 이어지는 것이 대부분이다.

측정은 어렵지만 좋은 접근이라고 생각한다.

주의할 점이 여럿 있지만, 잘 설계된 고객 설문조사는 가치 있는 통찰과 지원을 많이 제공한다.

주의할 점이 너무 많아서 설문조사는 전혀 안 하는데 최근에는 이런 방법도 사용해 볼지 생각하고 있다.

이런 종류의 시스템을 물려받았다면, 시스템에 결함이 있고 플랫폼 팀에 고통을 준다는 이유로 시스템을 폐지하거나 완전히 변경하기로 결정하고 싶을 수도 있을 것이다. 우리도 이해는 간다. 하지만 그런 큰 변경을 계획하기 전에, 물려받은 괴상한 시스템 중 사람들이 사랑하는 것들이 있는지 파악하고(고객 만족도 조사 등을 통해), 그리고 왜 그것을 사랑하는지 이해하려 노력해야 한다.

목표는 사용자가 작업을 제대로 하기는 쉽게, 잘못 하기는 어렵게 만드는 것이다.

플랫폼의 핵심을 관통하는 목표라고 생각한다.

우리는 플랫폼 도입을 그저 '만들면 알아서 올 것'이라는 사고방식에 맡겨두었다는 점을 깨달았다. 사람들이 플랫폼을 어떻게 도입할지, 플랫폼 배포 조직이 어느 정도 수준의 투자를 감당하게 될지를 적극적으로 고려하지 않았던 것이다.

이를 해결하기 위해 우리는 기존 플랫폼에서의 퇴로(off-ramp)와 새 플랫폼으로의 진입로(on-ramp)를 고려해서 상세한 마이그레이션 전략을 수립했다.

성공적인 플랫폼이 조직에 제공할 수 있는 최고의 레버리지는 사용자의 속도를 높이고, 사용자에게 즐거움을 주며, 사용자가 자신의 일을 멋지게 해내도록 하는 것이다. 이를 위해서는 플랫폼을 구축할 때 제품 중심의 사고방식을 도입해야 할 뿐만 아니라, '만들면 알아서 찾아올 것'이라는 사고방식에서 벗어나 초기 단계부터 도입을 목표로 하는 좀 더 적극적이고 집중된 접근 방식으로 전환해야 한다.

우리가 만드는 대부분의 플랫폼은 뻔하지만 유용할 것이다. 재미있지는 않더라도 사용자가 기대하는 대로 동작할 것이라고 신뢰할 수 있다.

책은 너무 잘 읽었지만 아무래도 플랫폼 엔지니어링을 다루면서 영역을 넓게 잡다 보니 모호해진 부분도 있다고 생각한다. 내가 꼭 정답이라는 것은 아니지만 내가 이해하는 플랫폼 엔지니어링은 DevOps에 그 기반이 있고 결국 엔지니어보다 컴포넌트의 수가 많아져서 복잡성이 제어하기 어려워지는 마이크로 서비스 때문에 플랫폼 엔지니어링의 필요성이 대두되었다고 생각하는 편인데 그런 얘기는 없어서 좀 아쉬웠다.(나만 그렇게 생각하는 걸지도...)