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

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

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

개인적으로 책에서 재밌게 읽은 몇 가지 부분이 있는데 바로 "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 엔지니어링" 책이 늘어나는 게 반갑다. 공학적인 접근이 더더더 많아지면 좋겠다.