이 책은 플랫폼을 단순히 기술 인프라로만 보지 않고, 비즈니스 성장을 이끄는 핵심 동력으로 활용하는 방법을 제시해 주어서 좋았다. 또한 플랫폼의 추상화와 캡술화를 통해 개발 생산성을 높이고, 안정적인 운영을 위한 체계적인 접근법을 소개해 주었다. 저자들의 풍부한 실무 경험에서 나온 체크포인트와 해결 방안을 구체적으로 제시해 주어 깊이 있는 통찰을 배울 수 있어 유익하다. 이 책의 또 다른 강점은 플랫품 엔지니어링의 기초부터 팀 구성, 운영 전략, 아키텍처 재구축 및 마이그레이션까지 실무적인 경험과 사례를 바탕으로 설명하는 점이다. 특히 제품 접근 방식을 통해 내부 고객의 요구를 중심으로 플랫폼을 발전시키는 전략은 금융 IT환경에서의 서비스 안정성과ㄷ 혁신을 동시에 추구하는 데 큰 도움이 될 것으로 기대된다. 플랫폼 엔지니어링의 중요성을 인식한 기술 리더와 프로젝트 관리자가 체계적인 구현 방법을 찾고 있다면, 이 책을 꼭 읽어보기를 바란다. 실무 현장에서 바로 적용할 수 있는 구체적이고 실질적인 지침을 통해, 플랫폼이 비즈니스 성장을 위한 든든한 토대가 될 것을 직접 느껴볼 수 있다. #플랫폼엔지니어링 #한빛미디어 #책스타그램 #북스타그램 #서평 #독서 #독서스타그램 #신간 #북리뷰 #책리뷰 #추천 #제공받은책
|
|
"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다." 이번 달에 읽은 도서는 "플랫폼 엔지니어링"이라는 이름을 가진 도서이다. 처음에 도서를 받아보기 전까지 이 책의 제목에서 언급하고 있는 "플랫폼"이란 말을 개인적으로 "Android"나 "iOS"와 같은 OS 레벨의 S/W Stack 정도로 생각했었다. 내가 현재 몸담고 있는 회사에서 개발하고 있는 특정 consumer device에 올라가는 Tizen OS가 그러하듯이, 각종 기능을 위한 API와 라이브러리를 제공하고 전체 시스템을 관리하는 그러한 S/W 플랫폼 말이다. 그러나, 본 도서에서 다루는 플랫폼의 관점에서 보면 얼추 비슷해보일 수도 있겠지만, 개념에 있어서는 약간의 차이가 있다. 본 도서에서 언급하고 있는 플랫폼이란, 셀프서비스 API, 도구, 서비스, 지식 및 지원으로 구성된 하나의 토대(foundation)로서 내가 생각한 개념보다 좀 더 넓다고 볼 수 있다. 특히 저자는 어떤 대상을 플랫폼이라고 부를 수 있으려면 "플랫폼 엔지니어링"이라는 요소가 필요하다고 보고 있는데, 여기에서의 엔지니어링이란 비즈니스 측면에서 안정적이고 확장 가능한 플랫폼을 구축하고 이를 위한 인프라를 운영하는 업무를 말하며, 조직적인 문화와 인력, 그리고 비용을 관리하는 부분까지 아우르는 개념이다.  본 도서는 총 14개의 chapter로 구성되어 있으며, 이러한 chapter들을 통해 플랫폼 엔지니어링의 정의와 필요성, 그리고 팀 구성과 제품 개발, 운영, 인력 관리에 이르는 실질적인 플랫폼 엔지니어링에 대한 실무, 그리고 성공하는 플랫폼이 되기 위한 방향성과 전략에 대하여 설명하고 있다. 어떻게 보면, 본 도서는 분명 개발 업무에 대해 이야기를 하고는 있지만, 개발 서적이라기 보다는 일종의 IT 경영 도서에 가깝다는 생각도 든다. 플랫폼 엔지니어가 갖추어야 할 기술 스킬이 무엇이고, 절차와 프로세스는 어떻게 구성되어야 하고, 또한 구축해야 할 사내 문화와 개발 외적으로 갖추어야 할 소프트스킬에 대해서 저자 두 분이 그 동안 크고 작은 회사에 몸담으며 느낀 교훈들에 대해 설명하고 있다.  특히 개인적으로 공감이 갔던 부분은 "전통적 인프라 조직의 변혁"에 대한 내용이다. 시대가 달라졌고 분명 변화가 필요하다는 것이다. 기존의 비용과 프로세스 중심의 문화도 중요하지만, 사용자와 플랫폼 사용성에 대한 중요성의 비중을 이제는 훨씬 높여야 한다는 것이 저자가 말하고 있는 플랫폼 엔지니어링 철학의 일환이다. 또한, 전통적인 관리자 업무를 수행하는 프로젝트 관리자 수를 제한하고, 관리 업무를 플랫폼 엔지니어에게 상당부분 이관함으로써 해당 관리 업무를 효율화, 자동화시키고, 자연스럽게 플랫폼 엔지니어로 하여금 고객에게 더 많은 시간을 보낼 수 있도록 시간을 투자시키도록 만들라는 부분도 의미있게 다가온 부분이다.  여담이지만, 도서의 내용 중에 대기업에서 온 신규 엔지니어들을 주의하라는 부분이 있는데, 표면적으로는 그들의 과도한 자신감을 주의해야 한다는 뜻에서라고 언급은 되어 있지만, 그 보이지 않는 이면에는 관리 위주의 업무를 수행하는 관리자의 수를 제한하는 것과 같은 맥락에서 언급하고 있는게 아닌가 하는 생각도 든다. 나도 현재 대기업의 일원으로서 슬프지만 일정 부분 공감이 가기도 한다. (그래서 연차가 쌓일 수록 실무 능력이 더 중요하다고 난 생각한다. ^^)  또한, 본 도서에서는 조직의 구성 방법과 개개인의 역할에 대한 이야기가 많이 나오는데, 그만큼 플랫폼 엔지니어링은 사람이 중요하고 사람에 따라 흥망성쇄가 결정되기 때문이라는 생각이 든다. (사실 생각해보면 뭐든 다 사람이 중요한 듯 하다.) 특히 고객을 대하는 자세에 대한 내용이 많이 언급되고 있는데, 플랫폼이란 것이 누군가 사용을 해야 의미가 있는 제품이라는 태생적인 이유 때문에, 플랫폼 비즈니스의 라이프사이클 자체가 고객과 뗄래야 뗄 수 없는 밀접한 연관성을 갖기 때문인 것 같다. 본 도서에서는 고객의 특성 파악, 고객과의 협업, 고객과의 공감 등 고객에 초점을 둔 제품 문화를 강조하고 있으며, 항상 제품 기획을 위한 시장 조사 시 제품과의 적합성, 시장/고객의 필요성에 대한 고려가 중요하다고도 언급하고 있다.  그리하여, 결국 플랫폼 엔지니어링의 목표는 고객으로부터 사랑받는 플랫폼을 개발하고 운영하는 것이다. 이러한 고객의 사랑을 구하기 위해 저자가 필요하다고 이야기하고 있는 건 사실 다 아는 내용들이다. 정확한 동작과 훌륭한 UI, 그리고 자동화 인터페이스, 소신 있는 정책, 더 나은 성능과 호환성을 위한 아키텍처 재설계, 보안 및 규정 준수 등 등이 바로 그것들이다. 본 도서에서는 이러한 플랫폼 엔지니어링 활동들을 진행함에 있어, 유념해야 할 각종 교훈과 주의사항(간과하면 실패하는 사항)들을 소개하고 있어서, 마치 이제 막 개발자에서 관리자로 업무가 변경되었거나 관리 업무를 병행하고 있는 분들에게 좋은 조언이 될 것이라 생각된다. 특히 CTO와 같은 C레벨 관리자들이 이 책을 보면 매우 도움이 될 것이라는 생각이 든다. |
|
한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. 플랫폼 엔지니어링(한빛미디어, 2025)  책 소개저자 : 카미유 푸르니에(Camille Fournier), 이언 놀런드(Ian Nowland) 제목 : 플랫폼 엔지니어링: 개발과 운영을 아우르는 플랫폼 관리의 핵심 원칙 번역 : 류광, 307번역랩 출판사 : 한빛미디어 출간 연도 : 2025.03. 페이지 : 424쪽 원문 제목 : Platform Engineering: A Guide for Technical, Product, and People Leaders (O'Reilly Media, 2024) www.yes24.com https://www.yes24.com/product/goods/143896301  데브옵스와 SRE에 이어 '플랫폼 엔지니어링'이 등장했다. 기술의 발달, 소프트웨어와 하드웨어의 발전에 따라 개발자들의 업무 환경이 변화하고 동시에 업무 요구사항이 증가하고 있다. 이러한 상황에서 '플랫폼' 구축을 통한 복잡성 관리의 아이디어는 개발자의 생산성 확대는 물론, 비즈니스 혁신을 지원하는 요인으로 대두된다. 총 3개의 파트로 구성된 책은 part1. '플랫폼 엔지니어링의 정의와 필요성'에서 '플랫폼 엔지니어링'이 무엇인지를 설명하고, part2. '플랫폼 엔지니어링 실무'에서 플랫폼 구축과 운영에 대해 안내한다. 마지막 part3. '성공은 어떤 모습일까?' 에서는 플랫폼에 대한 신뢰와 복잡성 관리에 초점을 두고 플랫폼 엔지니어링을 설명한다.
이 책의 장점은 플랫폼 엔지니어링에 대해 특정 언어의 '코드'로 설명이 아닌, 플랫폼 엔지니어링 필요성에서 시작하여 팀 빌딩, 플랫폼 운영, 실패 사례와 성공 사례를 화두로 플랫폼 엔지니어링의 개념부터 실무 적용까지를 모두 설명하는 점이다.(플랫폼 제품 관리와 이해관리자 관리 챕터를 읽으며, 비즈니스와 플랫폼 그리고 개발자에 대해 다시 한 번 생각해 볼 수 있었다.) 명확하게 설명하는 플랫폼 엔지니어링이 궁금하다면, 플랫폼 구축과 운영의 조언과 팁이 궁금한 모든분께 책을 추천한다. 한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
|
스마트폰이 등장하고 세상은 큰 변화가 있습니다. 전단을 보고 직접 전화번호를 눌러 짜장면과 치킨을 주문하는 광경은 드물고, 가게에 픽업으로 물건을 가져가도 수수료를 내는 시대입니다. 이를 통해 자영업자들은 배달부를 직접 고용하지 않고 깃발을 꽂아 앱 상단에 노출하려고 애씁니다. 그래야 고객들이 주문을 한 건이라도 더하기 때문이죠. 이뿐만이 아닙니다. 로켓배송과 새벽 배송의 등장으로 유통업은 크게 달라졌습니다. 인터넷을 통해 오픈마켓에 주문을 하면 적어도 이틀은 걸렸는데 주말까지 하면 3~4일이었죠. 요즘은 다릅니다. 하루 만에 오거나 주말에도 배송을 해줍니다. 더구나 새벽에도 자는데 배송해 주는 시대죠. 이러한 가운데 플랫폼 엔지니어링이 대두되고 있습니다. 관련된 책에 대해서 자세히 알아보도록 하겠습니다. 1) 기차역에서 빅테크로 플랫폼은 본래 기차역의 승강장이나 무대처럼 '무언가가 오르내리고, 만나는 공간'이라는 뜻에서 출발했습니다. 현재는 기차역을 핵심 요소로 바라보기보다는 디지털 경제에서 훨씬 더 넓고 깊은 의미로 뜻합니다. 즉 플랫폼 뜻은 디지털 공간에서 다양한 행위자들이 네트워크에 참여해 서로 연결된 관계를 맺으며 가치를 만들어내는 체계로 가치 창출의 장입니다. 이 장에서는 생산자와 소비자와 공급자 그리고 수요자 등 서로 다른 집단이 자유롭게 만나 거래를 통해 상호작용을 하며 새로운 가치를 만들어냅니다. 국내의 플랫폼 기업은 네이버, 카카오, 라인, 쿠팡 등이 있습니다. 이 기업은 셀프서비스 API, 지식 및 지원 등을 사용자에게 제공합니다. 그리고 다양한 비즈니스모델이 만들고 있습니다. 2) 서비스는 지속적으로 달라지기 때문 플랫폼을 개발하고 운영하는 하나의 분야를 플랫폼 엔지니어링이라고 합니다. 이 분야의 목표는 비즈니스 레버리지를 전달하기 위해 전체 시스템의 복잡성을 관리하는 것인데요. 폭넓은 애플리케이션 개발자층을 위한 소프트웨어 기반 추상화로서의 플랫폼을 개발하고 이를 비즈니스의 토대로 운영하는 큐레이션 제품 접근 방식을 통해서 목표를 달성하는 데 집중합니다. 즉 제품이 24시간 동안 팔려야 되는 경우 누군가는 시스템이 멈추지 않게끔 관리를 해야 합니다. 새벽 시간에 예상치 못하는 장애가 발생할 수도 있기 때문이죠. 플랫폼 엔지니어링 책은 빅테크 기업에서 일어날 만한 일들이 잘 정리된 책입니다. 특히 인프라 등 기술적인 점도 있으며 팀을 만들고 운영하는 내용이 자세히 적어져 있습니다. |
"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다."플랫폼 엔지니어링
플랫폼 팀에 대한 이야기를 다룬 책입니다. 저자들은 꽤 규모가 있는 플랫폼 조직에서 일한 경험이 있는 분들인데요. 그 경험을 바탕으로 플랫폼 조직을 구축하고, 키우고, 플랫폼 조직이 어떤 결과를 만들어야 하는지, 플랫폼 조직에 대한 모든 걸 설명하고 있습니다. 그래서, 책을 읽다 보면 책의 두께에 비해 내용이 상당히 많다는 걸 느끼게 됩니다. 심지어 저자들의 경험, 조언이나 내용 정리가 있는 박스에는 활자가 더 작아지더군요. 꽤 많은 시간을 투자해서 읽었던 것 같네요. 책의 서두에는 플랫폼을 설계하고 운영하는 리더가 대상 독자라고 쓰여있더군요. 그런데 플랫폼 설계를 하고 운영하는 사람은 그리 많지 않습니다. 저자들은 책으로 돈 벌 생각은 없는 사람들이 아닐까 싶었습니다. 그리고 책을 읽어가면서 그 판단이 정말 맞다는 생각을 하게 되었는데요. 사실 이 책은 플랫폼을 설계하고 운영하는 리더뿐만 아니라 스스로 소프트웨어 개발자라고 생각하는 사람이라면 읽어보는 게 좋을 것 같은데 저자들이 나서서 독자 층을 줄이는 말을 해버렸으니까 말이죠.
"프로젝트 관리자를 너무 일찍 투입하지 말라"는 소제목을 가진 섹션에서 나오는 말인데요. 프로젝트 관리자가 일정을 관리하면서 하는 기대가 잘 이루어지지 않을 거라는 의미입니다. 프로젝트 관리자들은 간트 차트 같은 걸 열심히 그리면서 그 일정대로 일이 진행될 거라 기대합니다. 하지만 그런 일은 벌어지지 않거든요. 그 이유는 소프트웨어 개발이라는 게 어떤 일정에 얽매일 만큼 단순한 작업이 아니기 때문입니다. 이런 조언은 사실 플랫폼에 국한되는 이야기가 아닙니다. 소프트웨어 개발의 전반에서 귀담아들어야 할 이야기거든요. 게다가 다른 개발팀을 지원하는 플랫폼 팀, 일정을 가장 많이 따질 것 같은 팀에서 오랜 경험을 가진 리더들이 이런 말을 한다는 건, 플랫폼 팀 리더들만 읽을 책이 아니라는 반증인 셈입니다. 게다가 50년 전 '존 갈'이라는 사람이 했다는 말은 이 부분을 더 확고하게 이해하게 해줍니다.
플랫폼과 같이 왠지 대규모 프로젝트인 것 같은 작업은 시작부터 거대한 구조로 세세하게 설계되어서 시작했을 것으로 여겨지는데요. 실상은 그렇지 않다는 말인 것입니다. 실상은 최소단위로 실행 가능한 소프트웨어에서 시작해서 점차 그 기능과 영향력을 성장시켜서 결국 대규모 시스템으로 진화시켜가야 한다는 것이죠. 소프트웨어 개발은 공산품을 만들어내는 것 같은 개념보다는 정원을 가꾸는 것과 같은 개념이 더 잘 들어맞습니다. 작은 묘목을 좋은 땅에 심어 두고 성장시켜나가는 일이 정원사의 일이거든요. 나무가 자라서 팔수 있는 시기가 된다는 건, 일정을 잡아서 될 일이 아닙니다. 나무가 팔만큼 자라야 팔 수 있는 것이죠. 그러니 떡잎부터 '잘 작동하는 시스템'으로 만들어서 진화시켜나가고 일정이 아니라 품질을 더 신경 써야 하는 것이죠. 그럼 어떤 품질을 가진 소프트웨어로 성장시켜야 하는 것일까요? 이는 책의 마지막 파트에서 다룬 '플랫폼 성공 정의'부분에서 힌트를 얻을 수 있습니다. 저자들은 교과서적인 성과 측정으로 플랫폼의 성공을 정의하는 것보다 다음 네 가지 항목으로 플랫폼의 성공을 정의하는 게 맞다고 봤습니다.
이는 플랫폼의 성공을 정의하는 것뿐만 아니라 소프트웨어의 품질이라고 바꿔 말해도 맞는 부분이라고 생각되더군요. 소프트웨어는 결국 소프트웨어를 사용하는 사람의 필요를 충족시켜야 하기 때문에 '정렬' 즉 '필요'라는 기준에 의해 나열되어야 하고, 신뢰성이 있으며, 유지 보수하기 좋게 복잡성도 관리가 되어야 하거든요. 오랜 시간 개발자로 일해오면서, 상당히 많이 들었던 말은 '모듈화', '컴포넌트화' 같은 말이었습니다. 뭔가 표준적인 것을 만들어서 이걸 끼워 맞추게 작업하면 소프트웨어 개발이 점점 더 빨라질 거라는 기대에서 나오는 말이었죠. 하지만 이런 과정을 제대로 해내고 성공하는 회사는 그리 많이 보지 못했습니다. 그 이유는 나무를 성장시키는 방식으로 소프트웨어를 개발하지 않고, 공장에서 제품을 찍어내는 것과 같은 방식으로 소프트웨어 개발을 바라보았기 때문이라고 생각합니다. 특히 플랫폼을 만드는 건, 왠지 나무를 키우는 것보다는 제품을 조립하는 개념으로 작업해야 할 것 같은 분야로 보이는데요. 이 책을 읽으면서, 플랫폼 분야도 그게 아니라는걸, 새삼 이해하게 되었습니다. 플랫폼 조직의 리더가 아니더라도, 많은 개발자들이 이 책을 읽고, 소프트웨어 개발에 대해서 생각해 보지 못했던 접근 방법을 깨닫는 기회가 되었으면 좋겠습니다. |
한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.플랫폼 엔지니어링이라는 말을 아마도 작년부터 좀 들어왔던 것 같다. 처음엔 단순히 DevOps나 SRE를 포괄하는 의미라고 생각했는데, 완전히 틀린 말은 아니지만 일종의 사내 개발자 도구를 만드는 개념으로 이해하는 편이 좋은 것 같다. 실제로 실무에서 '플랫폼'이라는 단어는 정말 흔하게 사용되는데, 정작 '플랫폼 엔지니어링'의 본질과 중요성에 대한 체계적인 지식은 부족했던 것이 사실이다. 이 책은 내가 갖고 있던 그 간극을 메워주는 역할을 하며, 개념부터 실무적인 적용 방법까지 포괄적으로 다루고 있다. 이 책은 단순히 기술 인프라만 다루는 것이 아니라 조직 내에서 어떤 협력의 태도로 접근할 것인가, 그리고 비즈니스 성장 동력으로서의 인프라를 어떻게 바라볼 것인가에 대한 관점이 담겨 있다. 1부에서는 플랫폼 엔지니어링의 주요 용어나 정의, 필요성을 명확하게 설명하고, ‘과도한 일반화의 늪’에 빠지게 되는 과정과 이를 어떻게 해소해 나갈 수 있는지 설득력 있게 제안한다. ‘플랫폼 엔지니어링의 기둥들’이라는 타이틀로 부연하고 있는데, 크게 큐레이션된 제품 접근 방식 채택, 소프트웨어 기반 추상화 개발, 폭넓은 애플리케이션 개발자층 지원, 비즈니스 토대로서 운영이라는 네 가지 핵심 원칙을 제시한다. 두 번째 파트에 들어서는 실무 적용에 초점을 맞추고 있다. 전통적인 인프라 조직일지라도 팀 구성과 운영, 계획 수립, 아키텍처 재구축, 마이그레이션 등에 이르기까지 현장에서 바로 적용할 수 있는 구체적인 방법론을 소개한다. 소유권 중앙화의 이점이나 집단역학의 사라짐부터, 대기업 출신의 신규 엔지니어를 주의하고 제품 관리자 채용에 신중해지라는 조언까지, 플랫폼 팀 내에서 일하는 구성원이라면 현실적인 조언으로 느껴질 포인트들이 많다. 앞서 얘기한 것처럼 이는 단순히 기술적 도구에 관한 것이 아니라, 조직 내부에서 우리가 어떻게 협업해 나가야 할 것인지에 대한 현실적인 통찰과 조언으로 느껴졌다. 플랫폼을 하나의 제품으로 바라보고 고객의 관점에서 쓰인 부분이 이해를 돕기도 했다. 훌륭한 플랫폼 팀을 만들기 위해서 단일 초점 플랫폼 팀의 위험성에 대해 경고하고, 다양한 역할의 엔지니어의 필요성을 강조한다. 동시에 엔지니어를 어떻게 채용하고 식별할 것인지에 대한 직접적인 조언 등이 챕터 내에 소제목으로 나뉘어 있기 때문에 목차를 살펴보고 당장 현실에 맞는 조언을 찾아보기에도 용이하다. 장기 프로젝트의 계획부터 이해관계자의 관리, 비용과 예산에 대한 고려 등 협업의 핵심 요소들을 꽤 상세하게 언급하고 있다. 세 번째 파트에서 ‘성공은 어떤 모습일까?’라는 질문처럼 플랫폼의 정렬, 신뢰 구축, 복잡성 관리, 그리고 끝내 사랑받는 플랫폼이 무엇인지에 대해 다룬다. 더 단순하고 빠르고 저렴한 것을 넘어 사용자가 사랑하게 만드는 플랫폼이 무엇인지 다루는 맥락에서 단순한 기술적 완성도를 넘어서 사용자가 강력한 신뢰를 바탕으로 온전한 사랑을 느끼게 하려면 어떻게 접근해야 하는지를 이야기한다. 이 책의 미덕은 통합적인 시선에 있다. 기술에 국한된 것이 아닌 기술적 결정이 조직 전체에 어떻게 영향을 미치고 있는지 폭넓은 시각을 보여주고 있다. 단순한 인프라 관리를 넘어 조직 문화와 협업 방식까지 아우르는 포괄적인 분야임을 반복적으로 상기시킨다. 플랫폼 엔지니어링 팀의 고유한 특수성을 언급하며 명확한 성공 지표가 아니라 팀 전체의 정렬이 중요함을 언급하기도 한다. 단순히 새로운 기술 트렌드를 소개하는 책에 불과한 것이 아니라 현대의 소프트웨어 개발 조직이 지속 가능한 성장을 이뤄내기 위해서는 어떻게 체계적으로 접근해야 하는지를 제시하는 지침이기도 하다. 특히 플랫폼 엔지니어링 자체에 익숙하지 않았던 나 같은 사람에게도 접근하기 쉽게 쓰여 있고, 조직 내에서 이를 올바르게 이해하고 구축할 방법에 대해서 순차적으로 다루고 있다. 그런 면에서 이 분야의 중요성을 이해하고자 하거나 실질적으로 팀을 구성하고자 하는 기술 리더나 개발자에게 적합한 책이라는 생각이 든다. |
"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다." 얇은 책이지만 밀도는 상당하다. 플랫폼 엔지니어링이라는 단어를 단순히 ‘공통 인프라를 만드는 팀’ 정도로 생각했다면, 이 책은 그 개념을 훨씬 더 넓고 깊게 바라보게 해준다. 특히 리더의 입장에서 플랫폼을 어떻게 정의하고 운영해야 하는지, 고객 중심 사고와 조직 전체 최적화를 동시에 고민해야 하는 이유를 분명히 알려준다. 플랫폼 팀은 더 이상 실험적이고 신기술 위주의 개발자 집단이 아니다. 조직 전체의 기술 운영 효율을 책임지는 핵심 전략 조직이며, 이를 위해 자유도를 제한하고, 적절한 추상화를 제공해야 하는 ‘설계자’다. 최근 팀 이름이 ‘서비스팀’에서 ‘플랫폼팀’으로 바뀌면서 자연스럽게 역할과 방향성에 대한 고민이 많았는데, 이 책은 그 질문에 대한 방향을 제시해줬다. 아직은 내게 먼 이야기처럼 느껴지는 부분도 있지만, 언젠가 내가 조직의 기술 방향을 결정할 위치에 섰을 때 꼭 다시 펼쳐보고 지침을 얻고싶은 책이다. |
|
|
** 한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다. 플랫폼에 대해서 생각해보면 내가 개발을 처음 시작한 때에도 물론 존재했던 개념이었으며 그것을 잘 활용하고 구축하던 곳이 있었을 것이다. 그렇지만 대체로 자신들의 영역에서 최선을 다했으며, 그것이 하나의 플랫폼화 되기보다는 각 특성에 맞도록 각 업무와 분야에서 그것에 맞도록 개발해온 것들이 더 많았던 것 같다. 그러다가 비슷한 일들이 반복되고, 다른 산업과는 다르게 공유 문화가 매우 활발히 일어나는 SW 업계의 특성에 따라 이것을 어떻게 공통화할 수 있을지에 대한 고민이 많이 있던 것 같다. 그런 결과물로 각종 인프라에 대한 통합이 이루어지기도 하였고, 사용하는 소프트웨어들도 점점 더 편한 방향으로 모아졌다. 가급적 개발은 공통화하여 사용하는 것을 고려하기 시작하였고, 개발하는 프로세스도 좀 더 효과적이고 효율적인 방향으로 발전되어갔다. 그래서 현재는 플랫폼이라는 것 자체는 비중에 대한 차이만 있을 뿐 SW를 다루는 곳이라면 빼놓을 수 없는 개념이 되었다. 이것이 이렇게 발전되어왔으니 이것을 체계화시켜가는 과정에서 한번쯤은 엔지니어링이라는 관점에서 정리하는 그런 책이 있었으면 하는 생각도 하곤 했다. 책 정보
플랫폼을 어떻게 관리하는지에 대한 책이라고 부제가 적혀있다. 이 말의 의미처럼 플랫폼 시작부터 전반적으로 어떻게 관리하는 것이 좋을지, 그리고 각 구성원들은 어떻게 되며 고려할 부분은 어떤 것이 있는지도 이야기 하고 있다. 심지어 폐지하는 시점에 대한 이야기도 함께 하고 있다. 그리고 책의 뒷면의 마지막에 이야기 하고 있는 한가지가 인상적이었다. 이 책을 가장 잘 설명하고 있는 문장이다. '플랫폼 엔지니어링은 팀 스포츠다. 이 책이 당신의 플레이북이다.' - 정가: 32,000원 - 분량: 368쪽 - 저자 및 옮긴이: 카미유 푸르니에, 이언 놀런드 / 류광, 307번역랩 인상받은 부분
플랫폼의 각 구성요소에 대해서 접착제라는 표현을 사용하여 서로관의 커플링을 설명한 부분에 대한 내용이다. 이 경우 끈적이는 혼란을 변경하기 어렵다고 표현하고 있다. 이처럼 깊이 서로 관여되어 있어도 이것을 최대한 접착면을 줄이면 해결이 가능하다. 접착제의 양을 줄여가는 방법으로 말이다. '상자는 늘리고 연결선은 줄인다.(more boxes, fewer lines)' 이는 소프트웨어 설계 원칙과도 일맥상통하는 부분이기도 하다. 관심사의 분리라고 하는 것에 해당한다. 사실 플랫폼을 개발하고 사용하는 과정도 사람이 진행하는 것이다보니 이상적이면 좋겠지만 그렇게 진행되기는 쉽지 않다. 이런 인간적인 부분을 통한 히스토리까지 같이 이야기하니 꽤나 인간미가 있었다.
역할에 대한 부분을 언급하지 않을 수 없다. 물론 전반적으로 다루고 있는 내용은 많지만 사람이 엮인 일이다. 그래서 각 역할을 어떻게 나누는지, 그리고 여기에는 일부만 적혀있지만, TPM을 비롯하여 각 역할은 언제 도입하면 좋은지, 도입할 때에는 어떤 역할로 시작할 것인지, 그런것을 마치 팀빌딩하는 과정에 빗대어 표현한다. 그래서 한국에서는 실제 잘 언급하지 않는 스태프 엔지니어에 대한 이야기도 함께 하고 있다. 단순히 기술적인 높이만 높다고 이야기 하지 않으며, 관리자도 아니지만 리더의 역할을 함께 담당하는 시니어의 위치를 이야기 하는 것이다. 현재 회사에서 요구하고 있는 위치도 함께 떠올려보며 수긍하는 부분이었다. 추가로 어떤 일을 진행할 때 경계해야 하는 방식으로는 하향식 방식을 이야기 한다. 상향식으로 발전할 때 새로운 기능을 추가할 때 효과적이다. 상향식으로 진행한다면 단순히 실무자에게서 시작한 의견을 경영진으로 올린다는 것으로 해석하기 쉽지만, 여기에서는 로드맵 계획을 수립하고 진행하는 것의 중요성부터 이야기한다. KTLO(Keep The Lights On)라는 용어도 여기에서 처음 접했다. 이것을 비롯하여 많은 작업이 필요한데 체계적이어야만 정상 진행이 된다는 이야기이다. 매우 공감이 간다. 이 책을 추천하고 싶은 독자매우 다양한 사람들에게 추천하고 싶다. 플랫폼을 개발하는 과정에서 무엇이라도 하고 있는 사람이라면 필요하다. 개발이라고 하는 것은 설계와 운영까지 포함한다. 제품 리더, 인력 리더는 물론이고, 아키텍트, 제품관리자, 프로그램 관리자, 엔지니어링 관리자가 이에 해당한다. 이 책에서는 이정도를 언급하고 있지만, 사실 실제 엔지니어들도 중요하다. 그래야 작업 자체에 대한 목적의식과 이해도를 확보할 수 있기 때문이다. 사실상 시니어급 이상의 SW 개발 회사에서 연구/개발 직종 및 그와 연관된 사람 모두 해당된다. 총평이 책은 생각보다 난이도가 높은 책이다. 실무적인 내용을 기대하고 온 입장에서 보면, 그것보다는 전체적인 시야에서 바라봐야만 하는 부분이 훨씬 많다. 그래서 사실 초반에 잘 읽히지는 않을 수 있다. 초반 부분을 잘 넘어가면 실무적인 관점에서 볼 수 있는 부분도 나오니 좀 낫다. 그래서 막연하게 플랫폼이라는 단어에 꽂혀서 읽는 것은 권하고 싶지 않다. 플랫폼 자체에 대한 설명이 나온 책이 아닌 그것을 어찌 설계, 개발, 운영, 도입, 직무 분배와 채용까지 다루고 있는 책이니 그 점을 잘 인지하고 보면 도움이 될 것이다. 그래서 아쉬운 부분 또한 이와 같다. 조금 더 쉽고 누구든 도입하기 쉬운 언어를 사용하여(가령 상황을 가정한 예시를 든다든가) 설명했더라면 흥미를 유발하기 쉽지 않았을까 싶다. 그런데 유익하지 않다고 생각하진 않는다. 큰 그림을 보고 이해하기 위해선 유용한 내용이 꽤 많다. 그래서 이해를 제대로 하고, 업무 현장에서 잘 반영하기만 한다면 매우 유용한 도구가 될 것이다. 많은 실무 경험을 바탕으로, 한 단계 크게 도약하기 원하는 플랫폼 엔지니어를 위한 지침서 |
한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다
아마도 작년부터 업계에서 핫하게 들려오는 플랫폼 엔지니어링에 대해 아주 잘 정리된 책이 한빛미디어에서 번역서로 출간되었다. 플랫폼 엔지니어링이란 무엇인지부터 시작해서 플랫폼 엔지니어링 팀의 업무를 설명해 나간다. 그리고 어떤 이해관계자와 얽혀있는지, 업무 방식은 어떤 식으로 진행이 되어야 하는지 구체적인 사례가 책에 고스란히 녹아있다. 사실 이 책은 굳이 플랫폼 엔지니어어가 아니더라도 재밌게 읽힐만하다. DevOps나 SRE라면 더욱 그럴 것이고, 소프트웨어 엔지니어라도 분명 재밌을 거다. 왜냐하면 플랫폼 엔지니어링이라는 것도 결국은 (내부) 고객을 위한 플랫폼을 만들고 운영하는 것이기 때문이다. 책에 담긴 아래 글귀를 살펴보자. 잘 작동하는 복잡한 시스템은 모두 잘 작동하던 단순한 시스템을 진화시킨 것이다. 그 역도 마찬가지이다. 복잡한 시스템을 무에서 출발해서 설계하면 절대로 잘 작동하지 않으며, 잘 작동하게 만들 수도 없다. 반드시 잘 작동하는 단순한 시스템에서 다시 시작해야 한다
이 내용은 플랫폼 엔지니어가 만드는 플랫폼에 대한 이야기인데 소프트웨어 엔지니어가 만드는 그 어떤 것에 빗대어도 동일하다. 결국 우리가 만들어내는 모든 것은 단순하게 시작한다. 그리고 그 단순한 것들이 모든 상황에서 잘 작동하는지 테스트를 하고, 작은 규모로 만들어서 배포한다. 어디서 들어본 것 같지 않나? 결국 마이크로 서비스에 대한 이야기다(위에 글귀에 대한 본인의 의견이다). 플랫폼 엔지니어링은 소프트웨어 엔지니어와 아주 많은 교집합을 갖고 있다. 또한 플랫폼 엔지니어링 팀은 소프트웨어 엔지니어를 보유하기도 한다. 또 하나의 글귀를 살펴보자. 팀의 목적(purpose)은 목표 달성(goal attainment)이 아니라 목표 정렬 (goal alignment)이다. 팀이 목표와 정렬되면 팀원들이 올바른 방향으로 나아가게 되므로 좀 더 효과적으로 일할 수 있다.
플랫폼 엔지니어링 팀의 조직 관점의 이야기다. 목표를 정렬하면 효과적으로, 그리고 자연스럽게 목표를 달성할 수 있다. 하지만 이것 역시 플랫폼 엔지니어링 조직에만 국한되는 이야기가 아니다. 심지어 엔지니어링 조직을 넘어서도 통용될 수 있는 말이다. 이렇듯 이 책은 개발/운영/관리 아주 많은 영역을 플랫폼 엔지니어링 관점에서 다룬다(하지만 서술했듯이 다른 분야라도 재밌게 읽힌다). 플랫폼 엔지니어가 어떤 지표를 살펴야 하는지, 그것들은 어떻게 관리해야 하는지(한 번 정하고 끝이 아니다) 아주 상세하게 설명한다. 그리고 필자들은 플랫폼 엔지니어링이라는 표현이 일시적 유행으로 끝날지 자문해봤다고 한다. 나는 유행으로 끝나지 않을 거라고 생각한다. "플랫폼"이 존재하는 한 플랫폼 엔지니어링은 지속 가능한 표현일 것이기 때문이다. 플랫폼을 지탱하는 플랫폼 엔지니어링이 궁금하다면 일독을 권한다. :) |