한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

“프론트엔드 개발 경력 8년차, 임대 플랫폼을 개발하는 스타트업의 R&D팀장으로 일하고 있습니다.
 다양한 개발과 운영 환경을 경험했지만, ‘플랫폼 엔지니어링’이라는 주제를 이처럼 체계적이고 현실적으로 다룬 책은 처음이었습니다. 『Platform Engineering: Building Internal Developer Platforms』는 단순히 인프라를 다루는 기술서가 아닙니다.

스타트업, 특히 빠른 성장을 목표로 하는 조직이 어떻게 개발자 생산성을 극대화하고, 개발 경험을 향상시키며, 복잡한 인프라 관리를 자동화할 수 있을지 명확하게 알려줍니다.

특히 내부 개발자 플랫폼(IDP) 구축 방법론과 DevOps, SRE와의 연계성을 현실적인 사례와 함께 설명해주어 실질적인 통찰을 얻을 수 있었습니다.

R&D팀을 이끄는 입장에서 개발자들이 최고의 퍼포먼스를 낼 수 있는 환경을 고민하고 있었는데, 이 책이 명확한 방향성을 제시해주었습니다.

플랫폼 엔지니어링에 대해 처음 접하는 사람은 물론, 스타트업 CTO나 팀 리더라면 반드시 읽어야 할 책입니다. 개발자의 시간을 아끼고, 조직의 기술 역량을 강화하고자 하는 모든 분께 강력 추천합니다.”

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

이번 달에 읽은 도서는 "플랫폼 엔지니어링"이라는 이름을 가진 도서이다. 처음에 도서를 받아보기 전까지 이 책의 제목에서 언급하고 있는 "플랫폼"이란 말을 개인적으로 "Android"나 "iOS"와 같은 OS 레벨의 S/W Stack 정도로 생각했었다. 내가 현재 몸담고 있는 회사에서 개발하고 있는 특정 consumer device에 올라가는 Tizen OS가 그러하듯이, 각종 기능을 위한 API와 라이브러리를 제공하고 전체 시스템을 관리하는 그러한 S/W 플랫폼 말이다.

그러나, 본 도서에서 다루는 플랫폼의 관점에서 보면 얼추 비슷해보일 수도 있겠지만, 개념에 있어서는 약간의 차이가 있다. 본 도서에서 언급하고 있는 플랫폼이란, 셀프서비스 API, 도구, 서비스, 지식 및 지원으로 구성된 하나의 토대(foundation)로서 내가 생각한 개념보다 좀 더 넓다고 볼 수 있다. 특히 저자는 어떤 대상을 플랫폼이라고 부를 수 있으려면 "플랫폼 엔지니어링"이라는 요소가 필요하다고 보고 있는데, 여기에서의 엔지니어링이란 비즈니스 측면에서 안정적이고 확장 가능한 플랫폼을 구축하고 이를 위한 인프라를 운영하는 업무를 말하며, 조직적인 문화와 인력, 그리고 비용을 관리하는 부분까지 아우르는 개념이다.

본 도서는 총 14개의 chapter로 구성되어 있으며, 이러한 chapter들을 통해 플랫폼 엔지니어링의 정의와 필요성, 그리고 팀 구성과 제품 개발, 운영, 인력 관리에 이르는 실질적인 플랫폼 엔지니어링에 대한 실무, 그리고 성공하는 플랫폼이 되기 위한 방향성과 전략에 대하여 설명하고 있다.

어떻게 보면, 본 도서는 분명 개발 업무에 대해 이야기를 하고는 있지만, 개발 서적이라기 보다는 일종의 IT 경영 도서에 가깝다는 생각도 든다. 플랫폼 엔지니어가 갖추어야 할 기술 스킬이 무엇이고, 절차와 프로세스는 어떻게 구성되어야 하고, 또한 구축해야 할 사내 문화와 개발 외적으로 갖추어야 할 소프트스킬에 대해서 저자 두 분이 그 동안 크고 작은 회사에 몸담으며 느낀 교훈들에 대해 설명하고 있다.

특히 개인적으로 공감이 갔던 부분은 "전통적 인프라 조직의 변혁"에 대한 내용이다. 시대가 달라졌고 분명 변화가 필요하다는 것이다. 기존의 비용과 프로세스 중심의 문화도 중요하지만, 사용자와 플랫폼 사용성에 대한 중요성의 비중을 이제는 훨씬 높여야 한다는 것이 저자가 말하고 있는 플랫폼 엔지니어링 철학의 일환이다.

또한, 전통적인 관리자 업무를 수행하는 프로젝트 관리자 수를 제한하고, 관리 업무를 플랫폼 엔지니어에게 상당부분 이관함으로써 해당 관리 업무를 효율화, 자동화시키고, 자연스럽게 플랫폼 엔지니어로 하여금 고객에게 더 많은 시간을 보낼 수 있도록 시간을 투자시키도록 만들라는 부분도 의미있게 다가온 부분이다.

여담이지만, 도서의 내용 중에 대기업에서 온 신규 엔지니어들을 주의하라는 부분이 있는데, 표면적으로는 그들의 과도한 자신감을 주의해야 한다는 뜻에서라고 언급은 되어 있지만, 그 보이지 않는 이면에는 관리 위주의 업무를 수행하는 관리자의 수를 제한하는 것과 같은 맥락에서 언급하고 있는게 아닌가 하는 생각도 든다. 나도 현재 대기업의 일원으로서 슬프지만 일정 부분 공감이 가기도 한다. (그래서 연차가 쌓일 수록 실무 능력이 더 중요하다고 난 생각한다. ^^)

또한, 본 도서에서는 조직의 구성 방법과 개개인의 역할에 대한 이야기가 많이 나오는데, 그만큼 플랫폼 엔지니어링은 사람이 중요하고 사람에 따라 흥망성쇄가 결정되기 때문이라는 생각이 든다. (사실 생각해보면 뭐든 다 사람이 중요한 듯 하다.)

특히 고객을 대하는 자세에 대한 내용이 많이 언급되고 있는데, 플랫폼이란 것이 누군가 사용을 해야 의미가 있는 제품이라는 태생적인 이유 때문에, 플랫폼 비즈니스의 라이프사이클 자체가 고객과 뗄래야 뗄 수 없는 밀접한 연관성을 갖기 때문인 것 같다. 본 도서에서는 고객의 특성 파악, 고객과의 협업, 고객과의 공감 등 고객에 초점을 둔 제품 문화를 강조하고 있으며, 항상 제품 기획을 위한 시장 조사 시 제품과의 적합성, 시장/고객의 필요성에 대한 고려가 중요하다고도 언급하고 있다.

그리하여, 결국 플랫폼 엔지니어링의 목표는 고객으로부터 사랑받는 플랫폼을 개발하고 운영하는 것이다. 이러한 고객의 사랑을 구하기 위해 저자가 필요하다고 이야기하고 있는 건 사실 다 아는 내용들이다. 정확한 동작과 훌륭한 UI, 그리고 자동화 인터페이스, 소신 있는 정책, 더 나은 성능과 호환성을 위한 아키텍처 재설계, 보안 및 규정 준수 등 등이 바로 그것들이다.

본 도서에서는 이러한 플랫폼 엔지니어링 활동들을 진행함에 있어, 유념해야 할 각종 교훈과 주의사항(간과하면 실패하는 사항)들을 소개하고 있어서, 마치 이제 막 개발자에서 관리자로 업무가 변경되었거나 관리 업무를 병행하고 있는 분들에게 좋은 조언이 될 것이라 생각된다. 특히 CTO와 같은 C레벨 관리자들이 이 책을 보면 매우 도움이 될 것이라는 생각이 든다.



플랫폼 엔지니어링이라는 용어를 올해 처음 알게 되었고 한빛미디어의 "플랫폼 엔지니어링" 책을 운이 좋게도 선택하여 읽어 보게 되었습니다.  내용을 읽기 전에는 아키텍처, DevOps나 그밖의 개발 방법론의 책이라고 생각하였는데  읽어 보니 그런 기술적인 내용보다는 더 큰  사상과 변화의 움직임을 설명하는 책이라고 생각되었습니다.

플랫폼 엔지니어링을 정의하면 개발자 생산성을 높이고 소프트웨어 개발 프로세스를 효율적으로 만들기 위한 기술 및 프로세스 집합으로 설명할 수 있습니다. 
하지만 "플랫폼 엔지니어링" 책은 사람과 조직 , 제품의 철학에 대해 좀 더 집중해서 이야기 하는 책이라고 생각됩니다.

"플랫폼 엔지니어링" 책은 플랫폼 엔지니어링의 정의와 필요성, 실무, 운영, 신뢰 구축에 대한 전반적인 플랫폼 엔지니어링을 설명하고 있습니다. 그리고 사례를 들어 플랫폼 엔지니어링의 방향성 및 기본 엔지니어링의 문제점을 설명하고 앞으로 플랫폼 엔지니어링을 통해 IT , 서비스, 플랫폼이 어떻게 변경하고 나아가야 할지 상세히 설명하고 있습니다. Devops,. SRE 보다 좀더 철학적인 접근 및 방식의 전환을 이야기 하고 있다고 생각됩니다. 책 전반에 플랫폼 엔지니어링과 고민해야 할 여러 사항을 설명하고 있습니다. 예를들어 10.1 이해관계자 매핑 : 권력 - 관심도 그리드 처럼  사용자 중심으로 플랫폼의 하나의 요소를 상세히 설명하고 있어서 흥미로웠습니다.  여러부분에서 플랫폼 엔지니어링을 통해 생각해 볼 내용이 많았습니다.

"플랫폼 엔지니어링" 책은 3개의 PART, 14개의 Chapter로 구성되어 있습니다. 
PART 01. 플랫폼 엔지니어링의 정의와 필요성 
Chapter 01. 플랫폼 엔지니어링이 점점 더 중요해지는 이유
Chapter 02. 플랫폼 엔지니어링의 기둥들

​PART 02. 플랫폼 엔지니어링 실무
Chapter 03. 착수 시기와 방법
Chapter 04. 훌륭한 플랫폼 팀 만들기
Chapter 05. 제품으로서의 플랫폼
Chapter 06. 플랫폼 운영
Chapter 07. 계획과 전달
Chapter 08. 플랫폼 아키텍처 재구축
Chapter 09. 플랫폼 마이그레이션과 폐지 처리 
Chapter 10. 이해관계자 관리

​PART03. 성공은 어떤 모습일까?
Chapter 11. 플랫폼의 정렬
Chapter 12. 플랫폼에 대한 신뢰 구축
Chapter 13. 복잡성을 관리하는 플랫폼
Chapter 14. 사랑받는 플랫폼 
으로 구성되어 있습니다. PART 01에서는 플랫폼 엔지니어링의 정의와 관련 기술 용어  필요성 등을 확인할 수 있고 PART 02 플랫폼 엔지니어링 실무에서는 플랫폼 엔지니어링을 적용하기 위한  실무 과정 및 여러 사례 중심으로 실무적인 사항을 알 수 있도록 되어 있습니다.  

"플랫폼 엔지니어링" 책의 장점
1. 플랫폼 엔지니어링의 전반적인 가이드
2. 실패하는 플랫폼의 설명을 통해 앞으로 플랫폼이 나아가야 할 길 제시  
3. 실무 관점에서 운영, 재구축, 이해관계자 관리 설명
4. 용어, 그림을 통한 구성 
으로 설명할 수 있습니다. 막연한 플랫폼 엔지니어링을 쉽게 그리고 실무에서 발생할 수 있는 이야기가 섞여있어서 끝까지 재미있게 읽을 수 있었습니다.

"플랫폼 엔지니어링" 책의 단점 
1. 개발 경험이 있는 중급자 이상의 책 
"플랫폼 엔지니어링" 책은 중급자 이상에게는 많은 도움이 될 거라고 생각합니다. 아키텍처를 공부했거나 Devops , 개발방법론 등을 공부했다면 해당 책의 내용은 흥미롭게 읽을 수 있습니다.. 
앞으로는 IT 방향과 그리고 플랫폼이 어떻게 발전해야 할지 확실히 알 수 있는 내용으로 구성되어 있습니다.  초급자에게는 조금 어려울 것 같습니다.

"플랫폼 엔지니어링" 책은 기술적이지 않은 사상과 플랫폼 엔지니어링을 왜 해야 하는지 설명하는 책입니다. 인프라 구축 및 DevOps, SRE 를 포함한 앞으로 더 나아야 할 길을 제시하는 책이 "플랫폼 엔지니어링" 책입니다. 조금은 어려운 내용이지만 앞으로 트렌드가 될  내용 이라고 생각합니다.  플랫폼을 개발, 운영 미래에 작업을 꿈꾼다면 꼭 한번 읽어보기를 추천합니다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

현대 소프트웨어 세계에서 복잡성은 피할 수 없는 존재다. 작은 스타트업이든 대규모 기업이든, 시스템은 점점 더 복잡해지고, 이를 관리하는 방법 역시 끊임없이 진화해 왔다. 데브옵스가 등장했을 때 우리는 한 줄기 희망을 보았지만 시간이 지나면서 데브옵스조차 한계에 부딪히게 되었고, 조직은 다시금 새로운 해법을 찾아야 했다. 이 책, '플랫폼 엔지니어링'은 바로 그러한 배경 속에서 등장한다. 플랫폼 엔지니어링은 더 이상 선택이 아니라 필수가 되어 가고 있다. 플랫폼 엔지니어링 팀은 견고하고 사용자 친화적인 플랫폼을 구축하여 복잡성이라는 괴물을 길들이고, 개발자들의 생산성을 극대화하는 역할을 맡는다. 즉, 단순히 인프라를 관리하는 데 그치지 않고, 이를 하나의 제품처럼 다루어 조직 전체의 역량을 한 단계 끌어올리는 데 집중한다. 이 책은 엔지니어, 관리자, 제품 관리자, 그리고 기술 리더 모두에게 이 변화의 흐름을 이해시키고, 실제로 적용할 수 있도록 돕는다.

책은 크게 세 부분으로 구성되어 있다. 1부에서는 플랫폼 엔지니어링이 왜 필요한지, 그리고 기존 접근 방식의 한계가 무엇인지를 진단한다. 우리가 흔히 빠지는 과도한 일반화의 함정, 그리고 그것이 어떻게 조직 전체를 늪으로 빠뜨리는지를 설명한다. 그 늪에서 빠져나오기 위해 필요한 것이 바로 플랫폼 엔지니어링이다. 단순한 기술적 해결책이 아니라, 권한 부여와 조직 문화까지 포괄하는 변화가 필요한 이유를 설득력 있게 풀어 내고 있다. 2부에서는 플랫폼 엔지니어링을 실천하는 방법을 구체적으로 다룬다. 작은 조직에서 어떻게 시작할 것인지, 훌륭한 플랫폼 팀은 어떤 모습이어야 하는지, 그리고 플랫폼을 진정한 제품으로 바라보기 위해 필요한 사고방식은 무엇인지를 상세히 설명한다. 여기서 특히 인상적인 부분은, 플랫폼 팀을 구성하는 다양한 역할과 그 역할 간의 협력 방식을 구체적으로 제시한다는 점이다. 또한 플랫폼 운영, 장기적인 계획 수립, 아키텍처 재구축과 마이그레이션까지 실제로 조직이 부딪히는 복잡한 문제들을 현실적으로 다룬다. 3부는 플랫폼 엔지니어링이 조직 내에서 성공적으로 자리 잡았을 때 어떤 모습이 전개되는지를 보여준다. 단순히 잘 구축된 플랫폼이 목표가 아니라 조직 전체가 정렬되고, 플랫폼에 대한 신뢰가 쌓이며 궁극적으로 사용자가 원하는 플랫폼을 만들어야 한다는 점을 강조한다. 복잡성을 어떻게 관리할 것인가, 그리고 그 복잡성이 조직의 성장에 어떻게 긍정적으로 기여할 수 있을지를 성찰하게 만든다. 무엇보다 이 책이 돋보이는 점은 단순한 이론서가 아니라는 것이다. 플랫폼을 구축해 온 다양한 조직 사례와 실무 경험을 녹여 냈고, 현장에서 실제로 마주치는 문제와 해결책을 구체적으로 제시한다. 기능 플래그, A/B 테스트 같은 안전한 배포 전략은 물론, 레거시 시스템을 현대화하는 방법, 장기적인 플랫폼 아키텍처 재설계 방법까지 폭넓게 다룬다. 이 모든 내용이 개발자 중심, 사용자 중심이라는 관점 위에 탄탄히 자리잡고 있다.

'플랫폼 엔지니어링'은 복잡한 퍼즐 같은 현대 소프트웨어 개발 세계에서 길을 잃지 않게 해주는 나침반 같은 책이다. 플랫폼이라는 단어가 아직 막연하게만 느껴지는 이들에게도, 이미 플랫폼 구축을 고민하고 있는 이들에게도, 이 책은 분명 탄탄한 지침이 되어줄 것이다. 비록 이 책 한 권만으로 플랫폼 엔지니어링의 모든 여정을 끝낼 수는 없겠지만, 적어도 그 여정의 첫걸음을 힘차게 내딛는 데 필요한 지적 근육을 단단히 단련시켜줄 것이다. 만약 지금, 복잡성과 씨름하며 방향을 잃고 있다면, 이 책과 함께 플랫폼이라는 새로운 길을 모색해 보는 건 어떨까.

* 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 솔직한 서평입니다.

플랫폼 엔지니어링은 개발자, 데브옵스 (DevOps) 엔지니어, 기술 리더를 비롯하여 기술에 종사하는 모든 분들께 꼭 필요한 개념이라 생각합니다. 빠르게 성장하는 스타트업은 물론, 복잡한 시스템을 운영하는 대기업에서도 플랫폼 엔지니어링 없이는 효율적인 개발과 운영이 어려워졌습니다. 따라서 플랫폼 구축과 내부 개발자 경험 (Internal Developer Experience, IDX)을 개선하고 싶은 분들이라면, 플랫폼 엔지니어링에 대해서 깊이 있게 이해하고 적용해보면 좋을 것 같습니다.​ 플랫폼 엔지니어링에 대해서 더 자세히 알고 싶으신 분들이라면, 이 책을 꼭 한번 읽어보시길 바랍니다.

  한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

플랫폼 엔지니어링(한빛미디어, 2025)

책 소개

저자 : 카미유 푸르니에(Camille Fournier), 이언 놀런드(Ian Nowland)

제목 : 플랫폼 엔지니어링: 개발과 운영을 아우르는 플랫폼 관리의 핵심 원칙

번역 : 류광, 307번역랩

출판사 : 한빛미디어

출간 연도 : 2025.03. 

페이지 : 424쪽

원문 제목 : Platform Engineering: A Guide for Technical, Product, and People Leaders (O'Reilly Media, 2024)

데브옵스와 SRE에 이어 '플랫폼 엔지니어링'이 등장했다. 기술의 발달, 소프트웨어와 하드웨어의 발전에 따라 개발자들의 업무 환경이 변화하고 동시에 업무 요구사항이 증가하고 있다. 이러한 상황에서 '플랫폼' 구축을 통한 복잡성 관리의 아이디어는 개발자의 생산성 확대는 물론, 비즈니스 혁신을 지원하는 요인으로 대두된다.

총 3개의 파트로 구성된 책은

part1. '플랫폼 엔지니어링의 정의와 필요성'에서 '플랫폼 엔지니어링'이 무엇인지를 설명하고,

part2. '플랫폼 엔지니어링 실무'에서 플랫폼 구축과 운영에 대해 안내한다.

마지막 part3. '성공은 어떤 모습일까?' 에서는 플랫폼에 대한 신뢰와 복잡성 관리에 초점을 두고 플랫폼 엔지니어링을 설명한다.

책은 8개의 챕터가 속한 part2를 중심으로 구성된다. 훌륭한 플랫폼 엔지니어링 조직을 만드는 방법과 저자들이 목격한 주요 실패 사례를 담고 있는 2부는, 규모에 따른 조직별 플랫폼 조직 구성 시나리오와 플랫폼 엔지니어링 팀 구성에 필요한 역할, 팀 빌딩 과정(채용)을 서두로 플랫폼 운영 방안을 설명한다.(특히 챕터6, 7에서 다루는 플랫폼 운영 관련 주제는 이 책의 핵심을 담고 있다.)

이 책의 장점은 플랫폼 엔지니어링에 대해 특정 언어의 '코드'로 설명이 아닌, 플랫폼 엔지니어링 필요성에서 시작하여 팀 빌딩, 플랫폼 운영, 실패 사례와 성공 사례를 화두로 플랫폼 엔지니어링의 개념부터 실무 적용까지를 모두 설명하는 점이다.(플랫폼 제품 관리와 이해관리자 관리 챕터를 읽으며, 비즈니스와 플랫폼 그리고 개발자에 대해 다시 한 번 생각해 볼 수 있었다.)

명확하게 설명하는 플랫폼 엔지니어링이 궁금하다면, 플랫폼 구축과 운영의 조언과 팁이 궁금한 모든분께 책을 추천한다.

  한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

플랫폼 엔지니어링에 대해 전반적으로 알 수 있었습니다.
내용은 어렵지 않지만, 주니어 레벨 보다는 어느정도 경험과 매니징을 경험해본 입장에서 보면 좋을거 같습니다.

플랫폼 엔지니어링을 위한 방법, 자세, 경험 등에 대한 내용을 담고 있어 시스템 전반적인 아키텍처를 구성할 계획을 가진다면 읽어보기를 추천합니다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

개발자 채용 공고는 크게 두 가지로 분류되는데 하나가 플랫폼 개발이고 다른 하나가 서비스 개발이다. 일반적으로 플랫폼은 조직, 혹은 특정 제품 내부에서 사용하는 어떤 기능을 제공한다. 서비스 개발, 애플리케이션 개발 조직은 이 플랫폼을 활용해서 빠른 속도로 새 기능을 구현한다.  이 책은 플랫폼 개발 조직에 엔지니어링 기법이자 문화인 플랫폼 엔지니어링에 대해 다루는 책이다.

플랫폼 조직은 아래와 같은 특징을 가지고 있다.

• 개발 산출물(플랫폼)을 사용하는 고객이 같은 회사의 다른 팀이다.
• 여러 서비스 개발 팀에서 공통적으로 필요한 기능을 추상화해서 이를 쉽게 사용할 수 있도록 제공하는 한다.
• 플랫폼 또한 소프트웨어이고 지속적으로 유지보수해야 하는 대상이다. 특히 이를 의존하는 사내 제품이 많이 질수록 영향도가 커진다.
• 플랫폼에서 제공하는 기능은 범용적이어야 한다.
• 플랫폼의 경쟁 상대는 비슷한 기능을 하는 오픈소스다.

이러한 플랫폼을 개발하는 플랫폼 조직이 가지는 특징들을 잘 이해하고 이에 맞는 적절한 개발 방법론을 사용하고 조직 운영을 해야 하는데 책에선 구체적으로 어떻게 하면 될지에 대해서 다루고 있다. 실무자가 읽어도 좋지만 관리자, 특히 플랫폼 조직을 만들지에 대한 의사 결정을 해야 하는 상황에서 읽으면 좋은 책이다.

이 책은 이런 내용을 담고 있다.

• 왜 플랫폼 조직을 만들 때 신중해야 하는지?
• 플랫폼 조직은 어떤 역할의 구성원들로 구성해야 하는지? 이 구성원들은 어떤 특징을 가지고 있고 어떻게 채용해야 하는지?
• 어떤 기능을 플랫폼으로 만들 것인지?
• 플랫폼을 어떻게 유지보수 할 것인지?
• 플랫폼 조직에 필요한 자원을 확보할 수 있도록 경영진을 어떻게 하면 설득할 수 있을지?

플랫폼 조직을 운영하고 있거나, 혹은 운영해야 하거나 플랫폼 조직을 만들어야 하는 테크니컬 리드나 매니저가 읽으면 많은 인사이트를 얻을 수 있을 것이다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

이 책은 플랫폼 엔지니어링의 본질과 실제 조직에서는 어떻게 역할을 가져가야 되는지 설명해줍니다. 이런 플랫폼 엔지니어링을 하려면 리더들은 어떤 것을 꼭 알고 행동해야 하는지 조언도 담고 있었습니다.

플랫폼팀이 내부 고객인 개발자의 효율성과 생산성을 높이기 위해 어떤 고민과 결정을 해야 하는지 실제 사례와 함께 다룹니다. 저처럼 플랫폼 엔지니어링이 막연한 사람에게 좋은 지침서가 될 수 있을 것 같습니다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

스마트폰이 등장하고 세상은 큰 변화가 있습니다. 전단을 보고 직접 전화번호를 눌러 짜장면과 치킨을 주문하는 광경은 드물고, 가게에 픽업으로 물건을 가져가도 수수료를 내는 시대입니다. 이를 통해 자영업자들은 배달부를 직접 고용하지 않고 깃발을 꽂아 앱 상단에 노출하려고 애씁니다. 그래야 고객들이 주문을 한 건이라도 더하기 때문이죠.

이뿐만이 아닙니다. 로켓배송과 새벽 배송의 등장으로 유통업은 크게 달라졌습니다. 인터넷을 통해 오픈마켓에 주문을 하면 적어도 이틀은 걸렸는데 주말까지 하면 3~4일이었죠. 요즘은 다릅니다. 하루 만에 오거나 주말에도 배송을 해줍니다. 더구나 새벽에도 자는데 배송해 주는 시대죠. 이러한 가운데 플랫폼 엔지니어링이 대두되고 있습니다. 관련된 책에 대해서 자세히 알아보도록 하겠습니다.

1) 기차역에서 빅테크로
플랫폼은 본래 기차역의 승강장이나 무대처럼 '무언가가 오르내리고, 만나는 공간'이라는 뜻에서 출발했습니다. 현재는 기차역을 핵심 요소로 바라보기보다는 디지털 경제에서 훨씬 더 넓고 깊은 의미로 뜻합니다. 즉 플랫폼 뜻은 디지털 공간에서 다양한 행위자들이 네트워크에 참여해 서로 연결된 관계를 맺으며 가치를 만들어내는 체계로 가치 창출의 장입니다.  

이 장에서는 생산자와 소비자와 공급자 그리고 수요자 등 서로 다른 집단이 자유롭게 만나 거래를 통해 상호작용을 하며 새로운 가치를 만들어냅니다. 국내의 플랫폼 기업은 네이버, 카카오, 라인, 쿠팡 등이 있습니다. 이 기업은 셀프서비스 API, 지식 및 지원 등을 사용자에게 제공합니다. 그리고 다양한 비즈니스모델이 만들고 있습니다.


2) 서비스는 지속적으로 달라지기 때문 
플랫폼을 개발하고 운영하는 하나의 분야를 플랫폼 엔지니어링이라고 합니다. 이 분야의 목표는 비즈니스 레버리지를 전달하기 위해 전체 시스템의 복잡성을 관리하는 것인데요. 폭넓은 애플리케이션 개발자층을 위한 소프트웨어 기반 추상화로서의 플랫폼을 개발하고 이를 비즈니스의 토대로 운영하는 큐레이션 제품 접근 방식을 통해서 목표를 달성하는 데 집중합니다.  즉 제품이 24시간 동안 팔려야 되는 경우 누군가는 시스템이 멈추지 않게끔 관리를 해야 합니다. 새벽 시간에 예상치 못하는 장애가 발생할 수도 있기 때문이죠. 플랫폼 엔지니어링 책은 빅테크 기업에서 일어날 만한 일들이 잘 정리된 책입니다. 특히 인프라 등 기술적인 점도 있으며 팀을 만들고 운영하는 내용이 자세히 적어져 있습니다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

플랫폼 팀에 대한 이야기를 다룬 책입니다. 저자들은 꽤 규모가 있는 플랫폼 조직에서 일한 경험이 있는 분들인데요. 그 경험을 바탕으로 플랫폼 조직을 구축하고, 키우고, 플랫폼 조직이 어떤 결과를 만들어야 하는지, 플랫폼 조직에 대한 모든 걸 설명하고 있습니다.

그래서, 책을 읽다 보면 책의 두께에 비해 내용이 상당히 많다는 걸 느끼게 됩니다. 심지어 저자들의 경험, 조언이나 내용 정리가 있는 박스에는 활자가 더 작아지더군요. 꽤 많은 시간을 투자해서 읽었던 것 같네요.

​

책의 서두에는

플랫폼을 설계하고 운영하는 리더가 대상 독자라고 쓰여있더군요. 그런데 플랫폼 설계를 하고 운영하는 사람은 그리 많지 않습니다. 저자들은 책으로 돈 벌 생각은 없는 사람들이 아닐까 싶었습니다. 그리고 책을 읽어가면서 그 판단이 정말 맞다는 생각을 하게 되었는데요. 사실 이 책은 플랫폼을 설계하고 운영하는 리더뿐만 아니라 스스로 소프트웨어 개발자라고 생각하는 사람이라면 읽어보는 게 좋을 것 같은데 저자들이 나서서 독자 층을 줄이는 말을 해버렸으니까 말이죠.

우리의 경험상 이는 보통 잘 작동하지 않는다

본문 202

"프로젝트 관리자를 너무 일찍 투입하지 말라"는 소제목을 가진 섹션에서 나오는 말인데요. 프로젝트 관리자가 일정을 관리하면서 하는 기대가 잘 이루어지지 않을 거라는 의미입니다. 프로젝트 관리자들은 간트 차트 같은 걸 열심히 그리면서 그 일정대로 일이 진행될 거라 기대합니다. 하지만 그런 일은 벌어지지 않거든요. 그 이유는 소프트웨어 개발이라는 게 어떤 일정에 얽매일 만큼 단순한 작업이 아니기 때문입니다.

​

이런 조언은 사실 플랫폼에 국한되는 이야기가 아닙니다. 소프트웨어 개발의 전반에서 귀담아들어야 할 이야기거든요. 게다가 다른 개발팀을 지원하는 플랫폼 팀, 일정을 가장 많이 따질 것 같은 팀에서 오랜 경험을 가진 리더들이 이런 말을 한다는 건, 플랫폼 팀 리더들만 읽을 책이 아니라는 반증인 셈입니다.

​

게다가 50년 전 '존 갈'이라는 사람이 했다는 말은 이 부분을 더 확고하게 이해하게 해줍니다.

잘 작동하는 복잡한 시스템은 모두 잘 작동하던 단순한 시스템을 진화시킨 것이다.

1975년 존 갈

플랫폼과 같이 왠지 대규모 프로젝트인 것 같은 작업은 시작부터 거대한 구조로 세세하게 설계되어서 시작했을 것으로 여겨지는데요. 실상은 그렇지 않다는 말인 것입니다. 실상은 최소단위로 실행 가능한 소프트웨어에서 시작해서 점차 그 기능과 영향력을 성장시켜서 결국 대규모 시스템으로 진화시켜가야 한다는 것이죠.

​

소프트웨어 개발은 공산품을 만들어내는 것 같은 개념보다는 정원을 가꾸는 것과 같은 개념이 더 잘 들어맞습니다. 작은 묘목을 좋은 땅에 심어 두고 성장시켜나가는 일이 정원사의 일이거든요. 나무가 자라서 팔수 있는 시기가 된다는 건, 일정을 잡아서 될 일이 아닙니다. 나무가 팔만큼 자라야 팔 수 있는 것이죠. 그러니 떡잎부터 '잘 작동하는 시스템'으로 만들어서 진화시켜나가고 일정이 아니라 품질을 더 신경 써야 하는 것이죠.

​

그럼 어떤 품질을 가진 소프트웨어로 성장시켜야 하는 것일까요? 이는 책의 마지막 파트에서 다룬 '플랫폼 성공 정의'부분에서 힌트를 얻을 수 있습니다. 저자들은 교과서적인 성과 측정으로 플랫폼의 성공을 정의하는 것보다 다음 네 가지 항목으로 플랫폼의 성공을 정의하는 게 맞다고 봤습니다.

​

플랫폼이 정렬되어 있는가?

플랫폼이 신뢰받는가?

플랫폼이 복잡성을 관리하는가?

플랫폼이 사랑받는가?

​

이는 플랫폼의 성공을 정의하는 것뿐만 아니라 소프트웨어의 품질이라고 바꿔 말해도 맞는 부분이라고 생각되더군요. 소프트웨어는 결국 소프트웨어를 사용하는 사람의 필요를 충족시켜야 하기 때문에 '정렬' 즉 '필요'라는 기준에 의해 나열되어야 하고, 신뢰성이 있으며, 유지 보수하기 좋게 복잡성도 관리가 되어야 하거든요.

​

오랜 시간 개발자로 일해오면서,

상당히 많이 들었던 말은 '모듈화', '컴포넌트화' 같은 말이었습니다. 뭔가 표준적인 것을 만들어서 이걸 끼워 맞추게 작업하면 소프트웨어 개발이 점점 더 빨라질 거라는 기대에서 나오는 말이었죠. 하지만 이런 과정을 제대로 해내고 성공하는 회사는 그리 많이 보지 못했습니다. 그 이유는 나무를 성장시키는 방식으로 소프트웨어를 개발하지 않고, 공장에서 제품을 찍어내는 것과 같은 방식으로 소프트웨어 개발을 바라보았기 때문이라고 생각합니다.

​

특히 플랫폼을 만드는 건, 왠지 나무를 키우는 것보다는 제품을 조립하는 개념으로 작업해야 할 것 같은 분야로 보이는데요. 이 책을 읽으면서, 플랫폼 분야도 그게 아니라는걸, 새삼 이해하게 되었습니다.

​

플랫폼 조직의 리더가 아니더라도, 많은 개발자들이 이 책을 읽고, 소프트웨어 개발에 대해서 생각해 보지 못했던 접근 방법을 깨닫는 기회가 되었으면 좋겠습니다.

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

1. 어떤 동기로 이 책을 선택했는가?

개발 인프라에 대해 깊게 파는 내용이라 생각했습니다. 예를 들어, 배포 시스템, 클라우드 인프라, 공통 라이브러리, CI/CD 파이프라인, 서버 환경 셋업, 개발 환경 구성 등이라 생각하였죠. 때문에 이 책을 통해 깊게 지식을 익힐 수 있겠다고 생각했습니다.

하지만 이 책은 사실 그런 개념이나 사용 기술들을 알려주는 내용이 아니었어요. '플랫폼'이 단순 인프라와 어떤 차이가 있고, 어떤 배경에서 탄생했으며, 어떤 전략으로 접근해야하는지를 다루었습니다.

오히려 생각지 못한 즐거운 발견이었어요. 아직 실무적으로도 접할 수 없던 분야이기에 이번 기회로 정확히 이해하고 싶었습니다.

2. 이 책은 어떤 내용을 담고 있는가?

이 책은 ‘플랫폼’이라는 개념을 단순한 기술적 인프라가 아닌, 제품 철학과 조직 전략의 관점에서 해석합니다. 플랫폼 팀은 단순한 기술 지원팀이 아니라, 내부 개발자들이 효율적으로 제품을 만들 수 있도록 돕는 프로덕트 팀이어야 한다는 점을 반복해서 강조해요.

또한 플랫폼은 단지 기술 구성요소가 아니라, 명확한 고객(내부 개발자)이 존재하는 하나의 제품이며, 이 제품을 관리하고 발전시켜야 할 전략이 필요하다는 사실을 깨닫게 되었어요.

책은 다음과 같은 구조로 이야기를 풀어나갑니다.

• 플랫폼 팀이 실제로 어떤 문제를 해결해야 하며, 무엇을 하지 않아야 하는지 구체적으로 알려줍니다.
• 플랫폼 팀의 역할, 책임, 범위에 대해 명확히 선을 그으며, 제품처럼 사용자 중심으로 운영되어야 함을 강조합니다.
• 온콜 관행, SLO/SLA 관리, 내부 고객 팀과의 관계 등 운영의 영역까지 포함해서 플랫폼 팀이 가져야 할 사고방식을 제시합니다.
• 플랫폼이 실패하는 여러 이유를 설명하며, 왜 사일로화되기 쉬운지, 그리고 ‘잘 만든 플랫폼’이 조직 전체에 어떤 영향을 미치는지를 다양한 관점에서 다룹니다.

유독 흥미롭게 다가온 점은, 애플리케이션 팀과 플랫폼 팀의 차이에 대한 설명이었어요. 저 또한 플랫폼보다는 애플리케이션 팀의 사람이라는 점에서 더더욱 플랫폼 영역을 이해하고 배경을 쌓아야한다는 생각이 들었어요.

3. 좋았던 점

1) 플랫폼을 ‘제품’으로 바라보는 관점

이 책은 플랫폼은 철저히 고객 중심으로 설계되고, 진화해야 한다고 말합니다. 그들의 고객은 내부 개발자란 점도 흥미로웠어요. 개발자 경험(DX)이나 사용자 여정(User Journey)도 철저히 고려되어야 했습니다. 그 과정에서 “이건 우리가 만든 거니까 써야 해”라는 식의 접근은 실패로 이어진다는 점도 실감 있게 설명됩니다.

2) 조직 내 관계에 대한 내용

플랫폼 팀은 독립된 기능을 수행하는 팀이 아니라, 애플리케이션 팀과 지속적으로 신뢰를 구축해야 합니다. “우리는 당신들이 더 나은 코드를 쓰고 더 빠르게 배포할 수 있도록 돕는 팀입니다”라는 정체성을 조직 전체에 어떻게 퍼뜨릴 수 있는지에 대한 고민이 아주 구체적으로 담겨 있어요.

3) 실패하는 플랫폼의 공통 패턴

많은 조직이 ‘표준화’라는 명분으로 플랫폼 팀을 만들지만, 실제론 내부 고객을 무시한 채 팀의 욕심만 반영된 경우가 많아요. 책에서는 그런 상황에서 어떻게 플랫폼이 외면받는지, 실제 예시 없이도 독자가 상상할 수 있을 정도로 잘 풀어냅니다.

4) 운영 관점

단지 플랫폼을 만드는 것뿐 아니라, 운영까지도 플랫폼 팀의 중요한 역할이라고 말합니다. 예를 들어, 온콜 체계나, SLO, 장애 대응, 실패 복구 등의 책임도 플랫폼 팀의 일부여야 하며, 이를 통해 전체 시스템의 안정성과 신뢰도를 유지할 수 있다고 말합니다.

4. 아쉬웠던 점

1) 플랫폼 경험이 없는 독자에게는 어려운 내용

이 책은 실제로 플랫폼 팀에 속해 있거나, 조직 내에서 플랫폼을 기획하고 있는 사람에게는 정말 유용한 가이드입니다. 하지만 저처럼 플랫폼이라는 개념을 막 접한 입장에서는 많은 부분이 뜬구름 잡는 얘기로 느껴졌어요. 아직은 공감보다는 관찰에 가까운 독서가 되었어요.

2) 부족한 실사례 혹은 케이스 스터디

이 책이 전하는 메시지는 굉장히 탄탄하고 설득력 있어요. 하지만 구체적인 기업 사례나, 실무적인 경험이 좀 더 들어 있었다면 훨씬 생생했을 거라 생각해요. 현재 상태로는 ‘원칙 중심’의 글이기 때문에, 실무 적용을 고민하는 독자에게는 약간 아쉽게 느껴질 수 있어요.

3) 번역의 아쉬움

몇몇 용어들은 번역이 다소 어색했어요. 예를 들어 ‘거짓양성(오탐)’, ‘거짓음성(미탐)’ 같은 표현은 배경이 없는 독자로서는 이해가 어려운 표현이었습니다.

마치며

『플랫폼 엔지니어링』은 단순히 기술적인 지식을 쌓는 책이 아니었어요. 플랫폼 팀이라는 존재가 왜 중요한지, 그리고 어떻게 잘 기능할 수 있는지를 집요하게 파고들었어요. 플랫폼이 단순히 인프라 구축 선에서 끝나는 것이 아니라 어떤 전략으로 어떻게 구성되어야 하는지를 알려주었어요.

플랫폼에 대한 배경지식이 없는 저에게 어려운 책이었지만, 언젠가 제가 플랫폼을 현업에서 마주하고 깊이 알아야할 때, 이 책은 분명 아주 단단한 길잡이가 되어줄 거라 생각합니다.

** 한빛미디어 서평단 <나는 리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.

플랫폼에 대해서 생각해보면

내가 개발을 처음 시작한 때에도 물론 존재했던 개념이었으며 그것을 잘 활용하고 구축하던 곳이 있었을 것이다.

그렇지만 대체로 자신들의 영역에서 최선을 다했으며, 그것이 하나의 플랫폼화 되기보다는 각 특성에 맞도록 각 업무와 분야에서 그것에 맞도록 개발해온 것들이 더 많았던 것 같다.

그러다가 비슷한 일들이 반복되고, 다른 산업과는 다르게 공유 문화가 매우 활발히 일어나는 SW 업계의 특성에 따라 이것을 어떻게 공통화할 수 있을지에 대한 고민이 많이 있던 것 같다.

그런 결과물로 각종 인프라에 대한 통합이 이루어지기도 하였고, 사용하는 소프트웨어들도 점점 더 편한 방향으로 모아졌다. 가급적 개발은 공통화하여 사용하는 것을 고려하기 시작하였고, 개발하는 프로세스도 좀 더 효과적이고 효율적인 방향으로 발전되어갔다.

그래서 현재는 플랫폼이라는 것 자체는 비중에 대한 차이만 있을 뿐 SW를 다루는 곳이라면 빼놓을 수 없는 개념이 되었다.

이것이 이렇게 발전되어왔으니 이것을 체계화시켜가는 과정에서 한번쯤은 엔지니어링이라는 관점에서 정리하는 그런 책이 있었으면 하는 생각도 하곤 했다.

책 정보

플랫폼을 어떻게 관리하는지에 대한 책이라고 부제가 적혀있다.

이 말의 의미처럼 플랫폼 시작부터 전반적으로 어떻게 관리하는 것이 좋을지, 그리고 각 구성원들은 어떻게 되며 고려할 부분은 어떤 것이 있는지도 이야기 하고 있다. 심지어 폐지하는 시점에 대한 이야기도 함께 하고 있다.

그리고 책의 뒷면의 마지막에 이야기 하고 있는 한가지가 인상적이었다. 이 책을 가장 잘 설명하고 있는 문장이다.

'플랫폼 엔지니어링은 팀 스포츠다. 이 책이 당신의 플레이북이다.'

- 정가: 32,000원

- 분량: 368쪽

- 저자 및 옮긴이: 카미유 푸르니에, 이언 놀런드 / 류광, 307번역랩

인상받은 부분

플랫폼의 각 구성요소에 대해서 접착제라는 표현을 사용하여 서로관의 커플링을 설명한 부분에 대한 내용이다. 이 경우 끈적이는 혼란을 변경하기 어렵다고 표현하고 있다. 이처럼 깊이 서로 관여되어 있어도 이것을 최대한 접착면을 줄이면 해결이 가능하다. 접착제의 양을 줄여가는 방법으로 말이다.

'상자는 늘리고 연결선은 줄인다.(more boxes, fewer lines)' (책에서는 fower라고 되어있는데 오타같다.)

이는 소프트웨어 설계 원칙과도 일맥상통하는 부분이기도 하다. 관심사의 분리라고 하는 것에 해당한다.

사실 플랫폼을 개발하고 사용하는 과정도 사람이 진행하는 것이다보니 이상적이면 좋겠지만 그렇게 진행되기는 쉽지 않다.

이런 인간적인 부분을 통한 히스토리까지 같이 이야기하니 꽤나 인간미가 있었다.

역할에 대한 부분을 언급하지 않을 수 없다.

물론 전반적으로 다루고 있는 내용은 많지만 사람이 엮인 일이다.

그래서 각 역할을 어떻게 나누는지, 그리고 여기에는 일부만 적혀있지만, TPM을 비롯하여 각 역할은 언제 도입하면 좋은지, 도입할 때에는 어떤 역할로 시작할 것인지, 그런것을 마치 팀빌딩하는 과정에 빗대어 표현한다.

그래서 한국에서는 실제 잘 언급하지 않는 스태프 엔지니어에 대한 이야기도 함께 하고 있다. 단순히 기술적인 높이만 높다고 이야기 하지 않으며, 관리자도 아니지만 리더의 역할을 함께 담당하는 시니어의 위치를 이야기 하는 것이다. 현재 회사에서 요구하고 있는 위치도 함께 떠올려보며 수긍하는 부분이었다.

추가로 어떤 일을 진행할 때 경계해야 하는 방식으로는 하향식 방식을 이야기 한다. 상향식으로 발전할 때 새로운 기능을 추가할 때 효과적이다. 상향식으로 진행한다면 단순히 실무자에게서 시작한 의견을 경영진으로 올린다는 것으로 해석하기 쉽지만, 여기에서는 로드맵 계획을 수립하고 진행하는 것의 중요성부터 이야기한다. KTLO(Keep The Lights On)라는 용어도 여기에서 처음 접했다. 이것을 비롯하여 많은 작업이 필요한데 체계적이어야만 정상 진행이 된다는 이야기이다. 매우 공감이 간다.

이 책을 추천하고 싶은 독자

매우 다양한 사람들에게 추천하고 싶다.

플랫폼을 개발하는 과정에서 무엇이라도 하고 있는 사람이라면 필요하다. 개발이라고 하는 것은 설계와 운영까지 포함한다. 제품 리더, 인력 리더는 물론이고, 아키텍트, 제품관리자, 프로그램 관리자, 엔지니어링 관리자가 이에 해당한다.

이 책에서는 이정도를 언급하고 있지만, 사실 실제 엔지니어들도 중요하다. 그래야 작업 자체에 대한 목적의식과 이해도를 확보할 수 있기 때문이다. 사실상 시니어급 이상의 SW 개발 회사에서 연구/개발 직종 및 그와 연관된 사람 모두 해당된다.

총평

이 책은 생각보다 난이도가 높은 책이다. 실무적인 내용을 기대하고 온 입장에서 보면, 그것보다는 전체적인 시야에서 바라봐야만 하는 부분이 훨씬 많다.

그래서 사실 초반에 잘 읽히지는 않을 수 있다. 초반 부분을 잘 넘어가면 실무적인 관점에서 볼 수 있는 부분도 나오니 좀 낫다. 그래서 막연하게 플랫폼이라는 단어에 꽂혀서 읽는 것은 권하고 싶지 않다. 플랫폼 자체에 대한 설명이 나온 책이 아닌 그것을 어찌 설계, 개발, 운영, 도입, 직무 분배와 채용까지 다루고 있는 책이니 그 점을 잘 인지하고 보면 도움이 될 것이다.

그래서 아쉬운 부분 또한 이와 같다. 조금 더 쉽고 누구든 도입하기 쉬운 언어를 사용하여(가령 상황을 가정한 예시를 든다든가) 설명했더라면 흥미를 유발하기 쉽지 않았을까 싶다.

그런데 유익하지 않다고 생각하진 않는다. 큰 그림을 보고 이해하기 위해선 유용한 내용이 꽤 많다. 그래서 이해를 제대로 하고, 업무 현장에서 잘 반영하기만 한다면 매우 유용한 도구가 될 것이다.

많은 실무 경험을 바탕으로, 한 단계 크게 도약하기 원하는 플랫폼 엔지니어를 위한 지침서
 

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다."

처음  데브옵스에 대한 개념이 태어났을 떄 그 업무에 대한 범위와 책임에 대하여 (지금도 그런 것 같지만) 혼돈의 시기가 있있습니다. 단순히 기술에 대한 역할이 아닌 문화적/조직적 방법론이라는 것에 대하여 이견은 없습니다. 그리고 이제 또 다시 플랫폼 엔지니어링 이라는 개념이 탄생하였습니다.

그래서 이 책은 엔지니어링 책이지만 기술문서는 전혀 아닙니다. 또한 외부고객이 아닌 내부고객을 초점으로 맞춰져 있습니다.

개인적으로 책에서 재밌게 읽은 몇 가지 부분이 있는데 바로 "8.1 새로운 v2를 만드는 것 보다 아키텍처 재구축이 나은 이유" 였습니다. 왜냐하면 지금 바로 몇 주 전 부터 제 경험이 그대로 들어 있었기 때문 입니다.  "v1 의 모든 결점에 대응하려다 보니 v2설계가 계속 커지게 된다"

현재 내부 시스템의 v2를 생각하면서 정말 모든 문제를 해결하려다 보니 눈덩이 처럼 커져서 거의 손도 대지 못할 정도로 기획이 커졌기 때문입니다. 어떻게든 v2에서 문제를 해결하려는 저의 고집을 어루만져 주면서 다른 시각과 넓은 시야로 문제 해결을 키워주는 것 같습니다.

또 한 가지 이름만 보고도 웃음이 빵 터지는 파트3이었습니다. "성공은 어떤 모습일까?" 
플랫폼 엔지니어링에 있어서 성공이란 장애가 전혀 안나는 시스템을 구축하는 것도 아니고, 요청사항에 빠르게 배포해주는 플랫폼을 배포하는 것도 아닐 것입니다.

내가 만든 시스템이 플랫폼이 모두에게 진심어린 애정을 갖게 된다면, 그것이 바로 성공이 아닐까 라는 주제로 이 책은 끝맺습니다. 엔지니어링과 사랑, 정말 공존하기 어려운 단어의 조합이지만 플랫폼 엔지니어링은 이를 가능하게 합니다.

책을 리뷰하면서 다른 분들께 추천하는 책은 많이 없지만 IT 분야에 있는 분들이라면 꼭 한번 읽어보시기를 권장드립니다. 

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

플랫폼 엔지니어링이라는 말을 아마도 작년부터 좀 들어왔던 것 같다. 처음엔 단순히 DevOps나 SRE를 포괄하는 의미라고 생각했는데, 완전히 틀린 말은 아니지만 일종의 사내 개발자 도구를 만드는 개념으로 이해하는 편이 좋은 것 같다.

실제로 실무에서 '플랫폼'이라는 단어는 정말 흔하게 사용되는데, 정작 '플랫폼 엔지니어링'의 본질과 중요성에 대한 체계적인 지식은 부족했던 것이 사실이다. 이 책은 내가 갖고 있던 그 간극을 메워주는 역할을 하며, 개념부터 실무적인 적용 방법까지 포괄적으로 다루고 있다.

이 책은 단순히 기술 인프라만 다루는 것이 아니라 조직 내에서 어떤 협력의 태도로 접근할 것인가, 그리고 비즈니스 성장 동력으로서의 인프라를 어떻게 바라볼 것인가에 대한 관점이 담겨 있다. 1부에서는 플랫폼 엔지니어링의 주요 용어나 정의, 필요성을 명확하게 설명하고, ‘과도한 일반화의 늪’에 빠지게 되는 과정과 이를 어떻게 해소해 나갈 수 있는지 설득력 있게 제안한다. ‘플랫폼 엔지니어링의 기둥들’이라는 타이틀로 부연하고 있는데, 크게 큐레이션된 제품 접근 방식 채택, 소프트웨어 기반 추상화 개발, 폭넓은 애플리케이션 개발자층 지원, 비즈니스 토대로서 운영이라는 네 가지 핵심 원칙을 제시한다.

두 번째 파트에 들어서는 실무 적용에 초점을 맞추고 있다. 전통적인 인프라 조직일지라도 팀 구성과 운영, 계획 수립, 아키텍처 재구축, 마이그레이션 등에 이르기까지 현장에서 바로 적용할 수 있는 구체적인 방법론을 소개한다. 소유권 중앙화의 이점이나 집단역학의 사라짐부터, 대기업 출신의 신규 엔지니어를 주의하고 제품 관리자 채용에 신중해지라는 조언까지, 플랫폼 팀 내에서 일하는 구성원이라면 현실적인 조언으로 느껴질 포인트들이 많다. 앞서 얘기한 것처럼 이는 단순히 기술적 도구에 관한 것이 아니라, 조직 내부에서 우리가 어떻게 협업해 나가야 할 것인지에 대한 현실적인 통찰과 조언으로 느껴졌다.

플랫폼을 하나의 제품으로 바라보고 고객의 관점에서 쓰인 부분이 이해를 돕기도 했다. 훌륭한 플랫폼 팀을 만들기 위해서 단일 초점 플랫폼 팀의 위험성에 대해 경고하고, 다양한 역할의 엔지니어의 필요성을 강조한다. 동시에 엔지니어를 어떻게 채용하고 식별할 것인지에 대한 직접적인 조언 등이 챕터 내에 소제목으로 나뉘어 있기 때문에 목차를 살펴보고 당장 현실에 맞는 조언을 찾아보기에도 용이하다. 장기 프로젝트의 계획부터 이해관계자의 관리, 비용과 예산에 대한 고려 등 협업의 핵심 요소들을 꽤 상세하게 언급하고 있다.

세 번째 파트에서 ‘성공은 어떤 모습일까?’라는 질문처럼 플랫폼의 정렬, 신뢰 구축, 복잡성 관리, 그리고 끝내 사랑받는 플랫폼이 무엇인지에 대해 다룬다. 더 단순하고 빠르고 저렴한 것을 넘어 사용자가 사랑하게 만드는 플랫폼이 무엇인지 다루는 맥락에서 단순한 기술적 완성도를 넘어서 사용자가 강력한 신뢰를 바탕으로 온전한 사랑을 느끼게 하려면 어떻게 접근해야 하는지를 이야기한다.

이 책의 미덕은 통합적인 시선에 있다. 기술에 국한된 것이 아닌 기술적 결정이 조직 전체에 어떻게 영향을 미치고 있는지 폭넓은 시각을 보여주고 있다. 단순한 인프라 관리를 넘어 조직 문화와 협업 방식까지 아우르는 포괄적인 분야임을 반복적으로 상기시킨다. 플랫폼 엔지니어링 팀의 고유한 특수성을 언급하며 명확한 성공 지표가 아니라 팀 전체의 정렬이 중요함을 언급하기도 한다.

단순히 새로운 기술 트렌드를 소개하는 책에 불과한 것이 아니라 현대의 소프트웨어 개발 조직이 지속 가능한 성장을 이뤄내기 위해서는 어떻게 체계적으로 접근해야 하는지를 제시하는 지침이기도 하다. 특히 플랫폼 엔지니어링 자체에 익숙하지 않았던 나 같은 사람에게도 접근하기 쉽게 쓰여 있고, 조직 내에서 이를 올바르게 이해하고 구축할 방법에 대해서 순차적으로 다루고 있다. 그런 면에서 이 분야의 중요성을 이해하고자 하거나 실질적으로 팀을 구성하고자 하는 기술 리더나 개발자에게 적합한 책이라는 생각이 든다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

썬 마이크로 시스템즈의 전 CEO는 오픈소스 소프트웨어를 두고 "강아지처럼 공짜(free, like a puppy)" 라는 표현을 사용했다.

강아지를 누군가로부터 무료로 분양받았더라도 강아지를 기르는데에는 비용이 든다는 것을 오픈소스 소프트웨어에 빗대어 표현한 것이다.

오픈소스 소프트웨어는 누구나 무료로 사용할 수 있지만 그 소프트웨어로 구성한 인프라나 서비스를 유지보수 하는데에는 필연적으로 비용이 따른다.

그 비용은 운영에 필요한 클라우드 서버의 이용료일수도 있고, 관련된 다른 소프트웨어 라이센스 비용일수도 있다.

플랫폼 엔지니어링에 등장한 저 짧은 문장은 최근 내가 하고 있는 고민을 적절히 짚어주었다.

최근 AI의 눈부신 발전으로 나는 아주 수월하게 하나의 서비스를 만들 수 있게 되었고,

거의 찍어내듯이 필요한 서비스들을 제작하고 있는데, 이런 서비스들을 운영하는 것이 쉽지 않았기 때문이다.

쉽지 않다고 느낀 것은 단순히 서버 셋팅이나 배포환경 셋팅 등의 초기 셋팅과 관련된 요소에서 비롯한 것은 아니었다.

초기 셋팅이 초기 셋팅이라고 불리는 것은 초기에 셋팅하면 크게 건드릴 필요가 없기 때문이라고 생각하는데

실제 서비스 운영 환경에서는 초기 셋팅과는 무관한 새로운 변경 사항이 계속해서 생기기 마련이고

그 변경사항들을 그때그때 안전하게 적용해줘야 한다.

예를 들어 DB를 사용하는 웹앱을 제작하였다면,

서비스를 개선하는 과정에서 DB에 저장하는 데이터의 종류나 방법에 변경 사항이 생길수도 있다.

이때 기존 서비스에서 사용하던 데이터를 소실하지 않은채로 새로운 서비스에 적용할 수 있어야 한다.

그렇지 않으면 이용자가 큰 불편을 겪을 수 있기 때문이다.

또다른 고민거리로는 하나의 서비스를 구현하기 위해 사용되는 수많은 다른 서비스들의 연결 방법이다.

이 책에서는 접착제라는 표현을 사용하는데,

서비스의 구성요소들이 연결되기 위해서는 접착제가 필요하고

접착제를 남발하면 서비스 유지보수가 어려워지게 된다.

이러한 고민들에 대한 해결책을 작가는 본인의 경험에 빗대어 솔루션을 제시해준다.

"플랫폼 엔지니어링"이라는 단어는 얼핏 거창해보여 시니어 개발자나 PM들이나 관심을 가질만한 내용같지만

달리말하면 주니어 개발자가 시니어 레벨로 올라가기 위해 필요한 덕목이라고 볼수도 있다.

최근 1인 개발자가 무척 많아지고 있는데 혼자서 개발과 운영을 두루두루 하는 것이 버겁게 느껴진다면

이 책을 추천해본다.

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다

플랫폼 엔지니어링

아마도 작년부터 업계에서 핫하게 들려오는 플랫폼 엔지니어링에 대해 아주 잘 정리된 책이 한빛미디어에서 번역서로 출간되었다. 플랫폼 엔지니어링이란 무엇인지부터 시작해서 플랫폼 엔지니어링 팀의 업무를 설명해 나간다. 그리고 어떤 이해관계자와 얽혀있는지, 업무 방식은 어떤 식으로 진행이 되어야 하는지 구체적인 사례가 책에 고스란히 녹아있다. 사실 이 책은 굳이 플랫폼 엔지니어어가 아니더라도 재밌게 읽힐만하다. DevOps나 SRE라면 더욱 그럴 것이고, 소프트웨어 엔지니어라도 분명 재밌을 거다. 왜냐하면 플랫폼 엔지니어링이라는 것도 결국은 (내부) 고객을 위한 플랫폼을 만들고 운영하는 것이기 때문이다. 책에 담긴 아래 글귀를 살펴보자.

잘 작동하는 복잡한 시스템은 모두 잘 작동하던 단순한 시스템을 진화시킨 것이다. 그 역도 마찬가지이다. 복잡한 시스템을 무에서 출발해서 설계하면 절대로 잘 작동하지 않으며, 잘 작동하게 만들 수도 없다. 반드시 잘 작동하는 단순한 시스템에서 다시 시작해야 한다

이 내용은 플랫폼 엔지니어가 만드는 플랫폼에 대한 이야기인데 소프트웨어 엔지니어가 만드는 그 어떤 것에 빗대어도 동일하다. 결국 우리가 만들어내는 모든 것은 단순하게 시작한다. 그리고 그 단순한 것들이 모든 상황에서 잘 작동하는지 테스트를 하고, 작은 규모로 만들어서 배포한다. 어디서 들어본 것 같지 않나? 결국 마이크로 서비스에 대한 이야기다(위에 글귀에 대한 본인의 의견이다). 플랫폼 엔지니어링은 소프트웨어 엔지니어와 아주 많은 교집합을 갖고 있다. 또한 플랫폼 엔지니어링 팀은 소프트웨어 엔지니어를 보유하기도 한다. 또 하나의 글귀를 살펴보자.

팀의 목적(purpose)은 목표 달성(goal attainment)이 아니라 목표 정렬 (goal alignment)이다. 팀이 목표와 정렬되면 팀원들이 올바른 방향으로 나아가게 되므로 좀 더 효과적으로 일할 수 있다.

플랫폼 엔지니어링 팀의 조직 관점의 이야기다. 목표를 정렬하면 효과적으로, 그리고 자연스럽게 목표를 달성할 수 있다. 하지만 이것 역시 플랫폼 엔지니어링 조직에만 국한되는 이야기가 아니다. 심지어 엔지니어링 조직을 넘어서도 통용될 수 있는 말이다. 이렇듯 이 책은 개발/운영/관리 아주 많은 영역을 플랫폼 엔지니어링 관점에서 다룬다(하지만 서술했듯이 다른 분야라도 재밌게 읽힌다). 플랫폼 엔지니어가 어떤 지표를 살펴야 하는지, 그것들은 어떻게 관리해야 하는지(한 번 정하고 끝이 아니다) 아주 상세하게 설명한다. 그리고 필자들은 플랫폼 엔지니어링이라는 표현이 일시적 유행으로 끝날지 자문해봤다고 한다. 나는 유행으로 끝나지 않을 거라고 생각한다. "플랫폼"이 존재하는 한 플랫폼 엔지니어링은 지속 가능한 표현일 것이기 때문이다. 플랫폼을 지탱하는 플랫폼 엔지니어링이 궁금하다면 일독을 권한다. :) 

※ 한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

​

이 책은 애플리케이션의 개발과 운영의 생산성을 높이기 위해 사용자의 친화적인 플랫폼을 만드는 기술에 대한 내용을 다룬다.

​

플랫폼 엔지니어링은 복잡한 서비스 환경에서 서비스를 이루는 여러 도구와 인프라, 그리고 개발의 작업흐름을 표준화하여 개발을 간소화하고 협업을 촉진하기 위한 즉 팀의 효율성도 함께 고려하여 개발 조직이 높은 수준의 성능을 유지하고 이에 대한 서비스의 고도화 과정에 대한 확장성과 신뢰성, 그리고 보안성을 보장하는 중요한 역할을 한다.

즉 이런 중요한 요소임에도 핵심적인 원칙들을 다루고 가이드를 받을 수 있는 정보들이 부족한 점이 있다. 하지만 이 책은 개발자의 경험 이상으로 전체적인 인프라를 아우르고 개발한 코드들을 운영 서비스에까지 배포한 이후 이를 운영하고 관리하기 위한 내용을 다룬다.

플랫폼에 대한 프로젝트의 착수와 이를 위한 조직의 구성 그리고 플랫폼 계획이 다른 여러 계획과 어떠한 점이 다른지에 대한 이해를 돕는다. 특히 팀에 대한 역할 정의와 여러 실무자들을 관리하는 내용도 다룬다.

플랫폼 엔지니어링에서의 팀의 주요 역할과 책임을 토대로 엔지니어링의 직급 체계와 방법을 소개하며 플랫폼을 제품처럼 다루어야 하는 이유를 토대로 이를 여러 실무자들에 맞는 조정 방법도 다룬다.

플랫폼을 제대로 만들기 위해 여러 실무자들이 어떠한 일을 해야 하는지 그리고 그에 대한 역할을 수행하기 위해 실천해야 하는 방법들이 어떠한 것이 있고 기술적인 구현 방법 이상으로 플랫폼 엔지니어링을 제대로 작동시키는 방법에 대한 소개를 단계별로 다룬다.

​

첫번째 장에서는 플랫폼 엔지니어링에 대한 개념을 다루는데 이 역할이 어떤 것인지 왜 필요한지 핵심적인 내용은 무엇인지 소개를 통해 독자들이 이해할 수 있도록 도와준다.

이후 플랫폼 영역에서 자주 접하게 되는 여러 문제들을 통해 이를 어떻게 해결해야 하는 지에 대한 내용을 다루고 운영과 실행 및 관행들을 설명한다.

​

이 책을 읽으면서 인상깊었던 부분은 아키텍처를 다시 새로 만들고 이를 위해 마이그레이션을 하는 실무적인 기술만 다루지 않고 기술 이외에 팀을 구성하고 서로 다른 입장에서 다른 동료들을 이해시키고 여러 실무자들이 나가야할 목표를 구체적으로 고민해볼 수 있도록 하는 부분이 기술적인 내용 뿐만 아니라 다양한 요소들에서 플랫폼 엔지니어링의 역할에 대해 폭넓은 이해를 도왔다.

​

플랫폼 엔지니어링 개념이 생소한 분들도 개념 이해를 도울 뿐만 아니라 이를 위한 여러 고려사항을 통해 플랫폼을 개발하고 이를 운영하기 위한 기술 리더 및 신입 개발자들까지 모두 도움이 될 내용이 많았다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

"개발과 운영을 아우르는 플랫폼 관리의 핵심 원칙"

"플랫폼 엔지니어링"의 목표는 비즈니스에 레버리지를 전달하기 위해

전체 시스템의 복잡성을 관리하는 것이다.

아래 그림에서 "복잡성"과 그것을 줄이는 것에 대한 개념을 아주 적절히 표현했다.

흥미로웠던 부분

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

"~그들의 기술과 태도를 면밀히 검토해야 하다. 단순히 대기업에서 일했다고 해서 해당 경험이 가치 있다고 생각해서는 안 된다. ~ 만약 이들이 어떤 문제에 대해 '대기업 X의 기술 Y'만 해결책으로 제시할 뿐 그 기술의 장단점을 충분히 고려하지 못한다면, 실제 업무에서도 상황에 맞는 판단을 내리기 어려울 것이다."

5.1.4 기능 공장의 함정에서 벗어나 고객을 더 폭럽게 지원하기

"플랫폼 팀이 좀 더 전략적인 제품 로드맵을 전달하는 데 필요한 타협안들을 밀어붙이는 대신, 고객들의 기능 요청을 처리하는 일에만 매몰되는 현상을 말한다"

5.2.1 잠재적 플랫폼 제품 식별

"우리 회사는 구글이 아니다, 필요하지 않다면 구축하지 말자"

5.4.4 엔지니어링 팀 규모에 비해 제품관리자가 너무 많다.

"제품 관리자가 너무 많으면 엔지니어가 아무 생각 없이 수동적으로 일하게 될 수 있다. ~ 스스로 고민하지 않는 것이다."

9.4.3 폐지가 타당하다면 과감하게 진행하자

"특수한 일회성 서비스를 지원하느라 팀이 너무 얇게 퍼져서 다른 모든 사람의 경험이 저하되는 것이 더 나쁘다"

어떤가? 뼈 때리는 말들에 웃음도 나오고, 잠깐이라도 되돌아보게 만드는 책이다. 알면서 못했던 것들, 아니 의도적으로 그냥 무시해 두던 것들을 체계적으로, 적나라하게 알려준다. 대기업이건 스타트업이건 누구나 공감할 만한 내용이 많다.

특히 현업과 IT 중간에서 조정 역할을 하는 사람, IT라면 관리자에게 큰 도움이 될 것 같다.

큰 개념으로 "플랫폼 엔지니어링" 을 보고, SRE에 대해 궁금하다면 "사이트 신뢰성 엔지니어링" 관련 책들을 보면 좋겠다

"OO 엔지니어링" 책이 늘어나는 게 반갑다. 공학적인 접근이 더더더 많아지면 좋겠다.