|
※ 한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. 장점
단점
후기
|
|
서비스 개발 조직과 운영 조직의 경계는 어디일까? 누가 어디까지를 책임지고, 누가 어떤 역할을 맡아야 하는가? 오랬동안 지속되어 온 이 질문들에 대한 대답중 가장 현명하면서도 모호한 대답은 "데브옵스"입니다. 개발과 운영의 경계가 낮아지면서 개발자는 운영의 영역에 발담그기 시작했고 운영자는 개발의 영역에 관여하기 시작했습니다. 그 사이에서 누가 무엇을 해야 하는가는 헤게모니를 누가 가질 것이냐의 싸움인 동시에 서비스를 위해 모두가 서로의 부족한 부분을 채워줘야 한다는 시대의 당면 과제를 이야기 해주는 것이기도 했습니다. 데브옵스는 대체 무얼까? 코드를 통해 관리되는 인프라(Infrasturcture as a code)라는 용어는 데브옵스를 이야기 하는 가장 대표적인 단어 중 하나입니다. 전통적으로 인프라, 시스템, 네트워크 엔지니어가 담당해오던 영역을 누구든 "코드를 작성할 수 있으면서 인프라를 이해할 수 있는" 사람이라면 그 역할을 해도 된다는 의미를 갖고 있는 단어라고 봐도 무방합니다. 그 "누군가"는 개발자가 될 수도 있고 "운영자"가 될 수도 있으며 "인프라 엔지니어"나 "SRE"가 될 수 도 있습니다. 데브옵스는 누가 무엇을 해야 한다는 것을 강력하고 엄밀하게 규정하는 용어가 아니라 목적 지향적인, 성과 지향적인 의미를 가진 단어라고 보는 것이 맞을 것 같습니다. 컨테이너, 모놀리스, CI, 보안, CD, 그리고 워크플로 데브옵스가 담당하는 영역은 굉장히 넓습니다. 인프라에 가까운 컨테이너 관련 기술에서부터 마이크로서비스의 대두로 찬밥 신세가 된 것 같지만 여전히 강력한 힘을 가진 모놀리스까지. 데브옵스가 관여하지 않는 영역은 없습니다. 지속적인 빌드와 산출물의 작성을 담당하는 CI는 물론이고 코드에서부터 산출물까지의 안전성을 담보하는 보안과 지속적으로 인프라에 배포되어 사용자에게 제공되도록 해주는 CD까지 데브옵스가 바라봐야 하는 영역은 상당히 깊고 광범위합니다. 이 책에서는 기본 소양이 될 수 있는 이러한 키워드에 대한 이야기를 쉽지만 결코 얕지 않은 수준으로 다루면서 데브옵스가 해야하는 일들에 대한 서사를 풀어나가고 있습니다. 데브옵스는 더이상 트렌드한 용어가 아닌 현실의 이야기입니다. SRE와 다른점이 무어냐를 따지는 것은 중요하지 않습니다. 조직이나 회사, 서비스나 산출물에 따라 데브옵스는 저마다의 정의를 갖고 있습니다. SRE 또한 데브옵스와 밀접하게 관계되어 있기 때문에 따로 뗴어놓고 생각하기 어렵다는 특징을 갖고 있기도 합니다. 다만 중요한 것은, 서비스의 안정적인 개발과 운영을 위해 필요한 많은 역할을 수행해야 하고 각자가 속한 조직에서 요구되는 기대수준에 맞추어 생각보다 많은 기술과 영역을 다뤄야 할 수도 있다는 것입니다. 책의 타이틀은 "자바개발자를 위한"이라고 되어 있긴 하지만 전반적인 내용은 꼭 자바를 다루는 사람이 아니어도 활용가치가 충분합니다. 데브옵스 혹은 SRE를 꿈꾸는 사람이라면 한번쯤 읽어보길 권하고픈 책입니다! 본 포스팅은 한빛미디어 ＜나는 리뷰어다＞ 활동의 일환으로 해당 도서를 무상으로 제공받아 읽고 작성했습니다. 20여년간의 현업 경험을 바탕으로 리뷰를 진행했고 이 분야로의 진출을 꿈꾸는 분들에게 도움이 될 수 있는 내용이 많아 긍정적인 관점에서 리뷰를 작성했음을 공유합니다. |
|
데브옵스? DevOps 란? development(개발) 과 operations(운영) 합쳐진 단어라고 합니다. 데브옵스는 개발과 운영의 차이를 줄이라고 생각했다고 합니다. DeVOps란? 신속한 고품질 서비스 제공을 통해 비즈니스 가치를 높이고 대응 능력을 개선할 목적으로 기업 문화, 자동화, 플랫폼 설계를 접근하는 방식입니다. 백엔드와 차이점을 무엇일까요? 백엔드를 계속해서 하다보면 개념적으로 늘어나면서 데브옵스를 경험할수 있습니다. 즉 어느정도 백엔드의 경험과 실력이 있어야 가능하다고 볼 수 가 있습니다. 자바 개발자를 위한 데브옵스는 데브옵스의 개념부터 배포까지 즉 모든것을 배울 수 있습니다. 데브옵스가 어렵나요? 데브옵스는 한창 주목받고 있고 많은 개발자를 원하고 있습니다. 클라우드 서비스가 활성화되면서 더욱더 시장규모가 커졌고 데브옵스 개발자는 백엔드개발자 같지만 더욱더 진화되고 진보된 개발자라고 볼수가 있습니다. 개발과 운영을 같이 생각해야 합니다. 즉 서버까지 만져야 하는 일이 생기는거죠. 그래서 저는 Application Architect 와 Technical Architect 합친 것이 아닌가 싶습니다. 즉 모든지 잘해야하고 잘 만들어야 하는거죠
데브옵스 개발자가 하는일을 상당히 많습니다. 개발을 시작으로 배포까지 모든것을 관여하기 때문에 많은것을 알아야 합니다. "자바 개발자를 위한 데브옵스 툴" 책에서는 각각 파트별로 설정부터 어떻게 해야하는지 나옵니다. 소스 관리 시스템설정에서부터 신뢰성, 성능, 각종툴 지원 뿐 아니라 통합 업그레이드 툴 까지 모든것을 관리하여야 합니다. 이렇게 하나하나 어떻게 하는지 나오고 빌드 또한 메이븐 그레이들 둘중에 어떻게 사용하는지 나옵니다. 그렇기 때문에 실제로 구성을 하면서 따라보는것만으로도 많은것을 배울수 있습니다. 데브옵스 변화 데브옵스는 클라우드 컴퓨팅 및 컨테이너 기술 등장으로 인한 개발방식의 큰견벽 그리고 데브옵스로 변화하고 있습니다. 데브옵스의 개발자가 요즘 많이 필요로 하고 나무가 아닌 숲을 볼줄 아는 사람 즉 데브옵스 개발자 라고 생각을 합니다. 끝판왕이 될수 있다. 높은 연봉 채용기회가 있습니다. 클라우드 사업이 먹거리 입니다.데브옵스는 컨테이너도 알야야 합니다 클라우드 서비스의 핵심적이기 때문에 배워야 합니다. 이 책에서는 데브옵스의에서 구성하는것들을 하나하나 설명하고 있습니다. 데브옵스 개발자
#자바 #데브옵스 #한빛미디어 #자바개발자를위한데브옵스툴 #데브옵스툴 #도서 #ORELLY |
|
이 책은 데브옵스를 성공적으로 도입시키고 안정화시키기 위해 필요한 툴들에 대해 설명합니다. 데브옵스를 잘 정착시키기 위해 위해 회사와 조직 구성원 무엇을 어떻게 해야 하는지에 대해 전반적으로 소개합니다. 소스 코드를 관리하고, 도커 컨테이너, MSA 구성, 서비리스, CI/CD, 테스트 자동화, 모니터링, 로깅, 빌드도구, 보안과 품질등 데브옵스 구성에 필요한 모든 구성에 대해서 다룹니다. DevOps의 정의
Chapter1. 개발자와 데브옵스 데브옵스(Devops)는 소프트웨어(Development)과 운영(Operation)의 합성어로서, 소프트웨어 개발자와 정보기술간의 소통, 협업및 통합을 강조하는 개발환경이나 문화를 말한다. 데브옵스는 완벽한 코드를 생성, 보호, 배포하기 위한 노력의 결정체이다. 데브옵스는 협업이며, 유기적이고 순환적인 소통을 위한 노력이다. Chpater2. 진실시스템 효과적인 데브옵스 파이프라인을 갖추려면 프로덕션에 배포되는 결과물을 속속들이 파악 할 수 있는 통일 된 시스템이 필요하다. 이른바 진실(truth) 시스템이다. 프로덕션 배포를 목표로 빌드, 컴파일 되는 모든 코드는 소스관리시스템에서 통제되고 제어되어야 한다. 배포된 소스의 리비전을 추적해 버그, 취약점, 성능저하의 근본 원인을 분석 할 수 있다. Chapter3. 컨테이너 컨테이너는 주로 클라우드 네이티브 환경을 향한 서비스 배포 분야의 관심사이다. 컨테이너는 애플리케이션 일관성, 프로세스 격리, OS 수준 의존성에 관련된 대부분의 문제를 해결하도록 고안된 경량 솔루션이다. 서비스나 애플리케이션을 컨테이너로 패키징하면 캐싱 매커니즘을 통해 배포 및 구동 시간을 극적으로 단축시킬 수 있다. Chapter4. 모놀리스 해부 모놀리식 아키텍처는 모든 요구사항을 하나의 소스에 담는 동시에 모든 부품을 하나의 유닛에 담아 전달한다. 외부 또는 사용자 입장에서 보는 모놀리스는 자신과 연결되지 않는 컴포넌트의 정의 , 인터페이스, 데이터, 서비스에 대해 거의 알지 못하는 존재이다. 마이크로 서비스 아키텍처는 서비스 지향 아키텍의 진화물이며 애플리케이션을 경량 모듈형 서비스 집합으로 재배치 한다. Chapter5. 지속적 통합 지속적 통합(CI)에 대한 일반적 정의는 여러 기여자의 코드 변경 사항을 프로젝트의 메인 소스 코드 리포지터리에 수시로 통합하는 것이다. CI의 철학은 모든 팀원이 코딩을 완료한 후 프로젝트를 조합하는 것에서, 개발 도중에 정기적으로 프로젝트를 빌드하는 것으로 진화했다. Chapter6. 패키지 관리 아티팩트는 일반적으로 빌드 시간, 의존성 버전, 환경 정보 등의 메타데이터를 보유하고 잇다. 메타 데이터는 특정 아티팩트의 출처를 추척하거나, 재현성을 높이거나, 소프트웨어 BOM을 생성할 때 요긴하게 사용할 수 있다. Chapter7. 바이너리 보안 소프트웨어 보안은 종합 데브옵스 롤아웃의 핵심 과제다. 지난 몇 년간 발생한 전대미문의 침해 사고들은 소프트웨어 보안 취약점에 대한 각계의 경각심을 다시금 불러일으키고 정부 차원의 대응과 새로운 보안 규정을 촉발했다. 개발에서 프로덕션에 이르는 소프트웨어 라이프 사이클을 통틀어 이 규정에 자유로운 영역은 없다. Chapter8. 개발자와 배포 개발자는 주로 애플리케이션 코드의 성능을 높이는데 주력하지만 데브옵스는 원활한 협업에 중점을 둔다. 데브옵스의 활동으로 말미암아 모두의 작업은 하나의 인프라 속에서 안정적이고 고르게 혼합될 수 있다. Chapter9. 모바일 워크 플로 스마트폰은 데브옵수를 필수 불가결한 요소로 만드는 특성을 지녔다. 태생적으로 스마트폰은 항상 인터넷에 접속하고 지속적으로 업데이트되어야 하는 장치다. 앱을 업데이트 하는 목적으로 사용자 대상 신 기술 추가, 버그 수정 및 애플리케이션 안정성 향상, 보안 취약점 또는 악용 방지 패치등이 있다. Chapter10. 지속적 배포 패턴과 안티패턴 지속적 업데이트는 더 이상 소프트웨어 개발의 선택 사항이 아니다. 이제 모든 주요 프로젝트는 지속적 업데이트를 모범 사레로 채택한다. 지속적 업데이트 전략은 프로젝트의 기능적 요구 사항만큼 중요하며, 고도로 자동화된 프로세스가 있어야만 안정적인 결과를 보장 할 수 있다. |
스티븐 친, 멜리사 맥케이, 익스헬 루이츠, 바루크 사도구르스키 지음 정병열 옮김
"한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다."
2023년 5월 2023 나는 리뷰어다 활동의 네 번째 리뷰
이번에 리뷰할 책은 "자바 개발자를 위한 데브옵스 툴"이다.
데브옵스란 무언인가? ``` 데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다. ``` 어렵게 써놓은 것 같지만 쉽게 말하자면 백엔드 개발자 혹은 서버 개발자가 운영에 관여하는 영역을 점차 넓혀가야 한다는 이야기며 현재까지 개발자들의 업무 영역은 개발과 배포까지 커버하고 있다.
프론트엔드와 백엔드가 점점 명확하게 구분되어 가는 시기에 데브옵스는 왜 필요한 걸까?
클라우드와 데브옵스 기술이 짧은 기간 내에 눈부시게 발전하면서, 개발자의 로컬 코드와 프로덕션 코드의 거리는 점점 더 좁혀지게 되었다. 애자일이 자리 잡아가면서 배포 주기는 점차 짧아지게 되었고, 배포의 자동화는 선택이 아닌 필수가 되었다.
운영과의 거리가 가까워지면서 개발과 배포의 라이프 사이클을 정밀하게 관리하게 되면서 이에 필요한 툴의 활용도도 늘어나게 되었다. 데브옵스의 영역마다 혁신적인 툴들이 지속적으로 등장하면서 개발자는 협업, 효율성, 자동화라는 데브옵스의 지향점에 맞추어 선택하여 관리할 수 있게 되었다.
하지만 데브옵스가 항상 추앙을 받는 것만은 아니다. 데브옵스의 모호한 정의에 피로감을 호소하며 도리어 개발과 운영의 분리를 역설하는 이도 있다. 이들은 데브옵스 이후 세계는 책임의 분할, SRE, 플랫폼 엔지니어링이 주도권을 쥘 것이라고 한다. 기술적인 면에 집중한 나머지 관계와 협업을 등한시하는 경우가 많기 때문이다. 어설프게 도입을 했다가 실패하는 사례가 많기 때문에 어느 정도 설득력이 있다.
그럼에도 불구하고, 데브옵스는 15년 넘게 통용된 용어이며, 개발자를 중심으로 플랫폼을 구축하는 조직이 점점 늘어가고 있다. 개발자의 아이디어를 빠르게 코드와 프로덕션에 반영하고 고객에게 빠르게 선보이기 위한 선택이다. 데브옵스의 구축이 없다면 신속하고 안정적으로 서비스를 제공하고 피드백을 수집하기가 어렵다.
이 책은 가장 근본적이면서 실용적인 기술만 잘 정리가 되어 있다. 책이 다루는 주제들은 각각의 라이프 사이클, 복잡도, 성숙도 등이 증가하는 순서로 구성되어 있다. 장마다 이론, 예시, 모범 사례를 골고루 배치하여 독자가 어느 지점에서 시작하든 해당 주제에 충분히 몰입하고 필요한 지식을 얻을 수 있도록 하였다.
팀이 오케이를 한다면 같이 스터디를 하고 싶을 정도로 도움이 많이 되는 책이라 생각한다. 다음 스터디는 데브옵스와 함께 해야겠다.
Love Yourself. |
|
작년에 사이드 프로젝트를 하면서 매번 수동으로 배포하다보니 귀찮기도 하고 여러 이유들로 CI/CD에 관심을 갖게 되었다. 관련 스터디도 참여하고 혼자 강의 보면서 실습도 하면서 공부하고 있다가 마침 이 책을 보게 되었다. 데브옵스가 왜 나오게 되었는지부터 시작해서 소스 코드 관리 시스템, 도커, 쿠버네티스 사용법, 자바 프레임워크, 패키지 관리 툴을 다양하게 소개하고 있다. 그냥 '이건 이거고 저건 저거다' 식으로 소개하는 게 아니라 이 툴들이 왜 나오게 되었는지, 장단점이 무엇인지, 베스트 프랙티스와 안티패턴을 같이 알려주고 있어서 전체적인 흐름을 이해하기가 좋았다. 깃 협업 패턴도 나오는데 프로젝트 초반에 잘 정리하고 가야 나중에 개발 들어가서 협업해야 할 때 서로 편한 것 같다. 부트캠프때는 깃 협업 패턴을 어떤 방식으로 할건지 정리하는 데에만 상당히 시간을 썼는데, 초반에는 깃 플로 방식으로 진행하다가 중간에 불필요하게 복잡하다는 의견이 많아서 좀 더 간단한 깃헙 플로 방식으로 변경했던 기억이 있다. 이 책만 읽고 갑자기 데브옵스를 잘하게 되는건 아니다. 다만 회사에 데브옵스 팀이 따로 없어서 어디서부터 시작해야 할지 모르겠는 개발자들에게 길잡이 역할이 되어주는 책이다. 현재 우리 팀의 상황이 어디쯤인지, CI/CD를 적용하려면 어디서부터 시작해야 할지에 대한 많은 힌트를 얻어갈 수 있을 거라고 생각한다.
|
|
SpringBoot 혹은 이와 관련된 실무 경험이 있는 개발자들에게는 훌륭한 복습 교재로써, 그리고 막 신입 사원으로 입사하려는 사람들에게는 훌륭한 서비스 개발 지침서가 될 책
시간이 흐를수록 IT 업계의 동향도 크게 변화하고 있다. 그 과정에서 수많은 기법의 흥망성쇠를 반복하고 있고 그중에 살아남은 몇 안 되는 오픈소스 프로젝트나 솔루션들이 업계의 표준으로 잡혀가고 있다.
근래의 서비스 개발의 트렌드는 컨테이너를 기반으로 한 Micro architecture와 자동화 CI/CD를 이용한 반복적인 QA 및 안정적인 서비스 개발에 있는듯하다.
물론 위의 내용들은 꼭 근래에만 주목받았던 기술이라 할 순 없다. 10년 전에도 20년 전에도 위와 비슷한 주제의 기술들이 언급되었고 지금의 기술들의 기반이 되는 것들이 당시에 탄생하였으니 말이다. 다만 그 옛날에는 지금과 같은 수준의 기술 고도화를 이루기에는 환경이 마땅치 못하였고, 기술력 역시 지금에 이르지 못하였기에 현실화하는 데에는 한계가 있었다.
하지만, 시간은 흘렀고 기술은 일취월장하여 10년 전과는 비교할 수 없을 정도의 컴퓨팅 능력이 세상에 출현하게 되었다. 이 말인즉슨, 옛날에는 말로써 존재하였던 기술들이 이제는 현실화가 가능해졌음을 시사하리라..
이 책은 위에서 언급한 세 가지의 기술을 비롯한 자바 기반의 서비스 개발자들이 기본적으로 알아두면 좋을법한 수많은 기법과 피해야 할 안티 패턴 그리고 각광받는 기술들에 대해 술 한 책이다.
따라서 서비스 개발자를 이제 시작한 신입 개발자이거나 혹은 연차가 5~7년 차 정도되는 중니어 개발자라면 꼭 읽어보길 권한다.
【책의 구성】 "자바 개발자를 위한 데브옵스 툴"의 구성은? 이 책은 챕터별로 주제를 정하고 이에 대해서 상세히 기술을 나열한 후, 이에 대해서 술 한 방식을 고수하고 있다.
어떤 챕터의 경우에는 직접 간이 프로젝트를 만들어 테스트해 볼 수 있는 실습 챕터도 있고, 최신 트렌드가 되는 기술과 동향에 대해서 작가 나름의 생각과 전망에 대해서 아낌없이 설파하고 있다는 점에서 여러 참고서와 그 맥을 같게 하고 있다.
이 책에서 다루는 챕터의 각각의 내용들은 그 주제만으로도 책 한 권이 나올 정도의 방대한 내용들이다. 다만 그만큼 요지를 잘 파악하여 정리해두었으므로 이 책 한 권만 잘 정독한다면 서비스 개발에 대한 어느 정도 틀이 잡혔다고 평해도 무방하리라 보인다.
1 챕터 : 개발자와 데브옵스 회사 어플라이 사이트에 들어가면 수많은 개발 부서에서 "데브 옵스" 개발자 혹은 기획자, 리더 개발자를 채용한다고 하고 있다.
"데브 옵스" 어디선가 들어봤지만 확실히 이거다!라고 선을 긋고 평하기엔 뭔가 애매한 감이 있는 그런 용어이다.
이 챕터에서는 저자가 바로 이런 부분을 시원하게 자신의 논리를 더해 정의하고 있다. 과연 데브 옵스는 무엇일지? 직접 책을 통해 확인해 보도록 하자.
3 챕터 : 컨테이너 요즘은 컨테이너를 사용하지 않는 회사를 찾는 것이 사용하는 회사를 찾는 것보다 어려운 시대리라 생각된다.
그만큼 수많은 회사들이 컨테이너 기술을 서비스에 도입하였고, 이를 기반으로 MSA 도입 및 인프라 비용 절감을 시도하고 있는 것이라 평해진다.
이 챕터에서는 Docker를 기반으로 컨테이너가 무엇인지 기존의 VM과 어떤 면에서 차이가 있고 탄생 배경과 역사가 무엇인지 자세히 술하고 있다. 또한 나아가 컨테이너를 사용한 시스템에서 주의해야 할 안티 패턴이 무엇이 있는지에 대해서도 자세히 술하고 있다.
하나 버릴 내용이 없으므로 꼭 잘 정리해서 머릿속에 새기도록 하자.
5챕터 : 지속적 통합 "서비스 개발은 나 혼자 하는 것이 아니다.!"
이제 막 회사에 입사하는 신입 개발자들에게 꼭 해주고 싶은 말이다.
여러 대회 공모나 혹은 학교 과제를 많이 리딩 해본 새내기 개발자들이라면 막 입사하여 멋진 프로젝트를 혼자서 잘 리딩 할 거야!라는 광대한 야심을 갖는 것이 보통이다. (아니라면.. 뭐 그것 나름 좋은 부분이다.)
하지만, 회사에서 진행하는 프로젝트들은 학부 때 경험해 보았을 법한 프로젝트와는 그 규모에서 제법 차이가 있다. 훨씬 크거나 훨씬 복잡하거나 아니면 둘 다이거나 보통이 그러하다.
그렇기에 회사에서는 절대로 혼자 일하는 프로젝트를 새내기에게 맡기지 않는다. 또한 경력직이라도 페어 혹은 다수의 개발자들이 같이 일하는 형태를 취하지 절대로 혼자서만 프로젝트를 진행하게 하진 않는다. (만약 혼자서만 개발하고 있는 분이 계시다면, 솔직히 나의 관점에서는 일하는 곳을 옮기시길 권장한다. 혼자 일하면서 향상시킬 수 있는 능력에는 한계가 있다. 물론 빌게이츠럼 예외는 있긴 마련이지만..)
이 챕터에서는 왜 회사에서는 혼자 일하지 않는지, 그리고 여럿이 일하면 어떤 어려움에 직면하고 이를 돕는 도구들이 무엇이 있는지 체계적으로 술하고 있다.
【 자바 개발자를 위한 데브옵스 툴을 읽고 나서 】 개발자라는 직업은 피로도가 꽤 있는 직업이다. 왜냐하면 하루가 멀다 하고 새로운 기술이 끊임없이 태동하고 탄생하며 다시 사라지길 반복하는 그런 생태계에 있기 때문이다.
하지만, 이는 단연 IT 학문에만 국한된 것이 아니다. 의학도 그렇고 법학도 그렇고 모든 학문은 그 시대에 맞게 변화해야만 살아남을 수 있다. 특히, 지금과 같이 기술 발전이 더더 고도화되어가는 사회에서는 학문이 그 자리에 정체한다는 것은 어찌 보면 나라의 존폐가 달린 일이라 할 수 있다.
그렇기에 바다를 향하는 물이 끊임없이 흐리고, 바다에 도착하여 다시 비가 되어 대륙부터 다시 시작하듯. 우리 개발자들도 항시 이 업계를 떠나는 그 순간까지 수학함에 게으름이 있어선 안 될 것이다.
|
|
"한빛미디어 ＜나는 리뷰어다＞활동을 위해서 책을 제공받아 작성된 서평입니다." 이 책은 막연하게 개념만 파악하고 있는 데브옵스에 대해서 역사적 이야기와 함께 전반적인 내용을 설명해 간다. 초급 개발자에서 중급개발자로 성장해 가면서 개발과 운영에 대한 고민을 하는 개발자들에게 추천해 주고 싶은 책이다. 이 책 만으로 데브옵스를 구축할 수는 없을 것이다. 다만 데브옵스를 위해 어떤 요소를 알아야 하고 어떤 요소를 더 깊게 찾아봐야 할지에 대한 가이드를 제공받을 수는 있을 것으로 생각한다. 앞에서 얘기한 것과 같이 내용은 역사적 이야기와 함께 필자의 경험 등을 소개해 나가면서 딱딱하지 않게 이야기를 풀어 나가기 때문에 너무 부담을 갖지 않고 읽어 나갈 수 있다. 언제나 그렇듯 큰 그림을 보는 방법을 아는 것은 매우 중요한 문제이다. |
|
안그래도 요즘 업무를 하면서 네트워크쪽으로 확인이 필요한 업무가 발생하였을 때 어디가 어떻게 문제인지, 어떤 방식으로 문의를 해야 효율적인지 몰라서, 내가 제대로 모르다보니 너무 비효율적으로 돌아돌아 질문을 하는 것 같아서 스트레스를 받던 차에 이 책을 받아 읽게되었다. 총 393페이지의 얇다면 얇고 두껍다면 두꺼운 책. 개발자 중 절대 다수는 이제 더 이상 '개발만' 하지 않는다. 라는 해외 추천사가 눈에 들어왔다. 개발만 하면되지, 나정도면 어느정도는 아는거지 라고 생각했었는데 요즘 여러군데서 항상 부족함을 느끼는 차에 제공받아 읽게된 책.
--------------------------------------------------------------- 기본적으로 두루두루 알고싶을 때 좋은 책이다. 깃허브내에 소스를 제공한다. 책과 함께 보면서 따라하기 좋다. 전체적인 데브옵스의 흐름을 알기에 좋다. 특정 내용들에 대해서 간단한 기초 지식들만 다루고 있기 때문에 심도있게 알고 싶으면 관련된 도서나 소스를 보는 것이 좋겠다. 나처럼 데브옵스 직무는 아니나 데브옵스와 관련된 내용을 알고싶거나, 데브옵스를 관장하는 팀에 요청을 명확하게 하고 싶을 때, 혹은 신입 데브옵스 개발자들에게 추천한다.
한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다. |
|
작년 연말에 ＜디지털 트랜스포메이션 엔진＞이라는 책을 읽고, 한참 고무됐었습니다. "고성과 조직은 다른 많은 기업보다 현저하게 나은 방식으로 지속적으로 발전한다는 것"이 이 책의 중심주제였는데요. 심지어 "기술의 전략적 사용이 인수 합병 이나 기업가 정신보다 수익과 생산성의 증가를 더 잘 설명한다"는 학술 연구 결과까지 소개하고 있었기 때문이었습니다. ＜디지털 트랜스포메이션 엔진＞의 주장이 맞다면, 우리는 어떤 회사의 기술조직이 어떤 문화를 가지고 있고, 어떤 방식으로 일하느냐에 따라서, 그 회사의 과거,현재,미래를 이해할 수 있기 때문입니다. 그러면, 우리가 인생의 진로를 정할때, 어떤 회사에 합류해야 하는지, 그리고 회사에 합류하면 어떤 부분을 힘써야 하는지 알 수 있게 됩니다. 단언컨데, 그런 회사는 빠르게 학습하고 변화하는 회사입니다. 그리고 이를 뒷받침하는 가장 소중한 도구가 "데브옵스"이죠. ＜자바 개발자를 위한 데브옵스 툴＞은 "데브옵스"를 다루는 책입니다. 여러 전문가들이 모여서 현재까지 쌓여온 "데브옵스"와 관련된 주변 기술들과 특히 자바와 관련된 다양한 툴에 대해서 소개하고 있습니다. 사실 저는 프론트엔드 개발자로 일하고 있어서, 제가 다루는 툴과는 좀 거리가 있었는데요. 책의 저자들이 자기가 다루는 주제에 대해서 설명할 때면, 먼저 이론적인 이해를 돕는 이야기를 앞에서 하고, 뒤에 툴에 대해서 소개하기 때문에, 꼭 자바계열 백엔드 개발자가 아니더라도 도움이 되는 구조였습니다. 특히, 번역자의 문체가 마음에 들었습니다. 사실 저는 꽤 많은 책을 읽어왔는데요. 책을 읽다보면, 번역한 분의 문체에 따라서 책을 읽는 노력이 많이 필요한 경우가 있었습니다. 하지만 (개인적인 느낌인지는 몰라도) 상당히 읽기 편한 문체로 번역하셨더군요. 그냥 국내저자의 책 같았습니다. 그리고, 정말 반가웠던건, 1장에서 ＜디지털 트랜스포메이션 엔진＞을 언급하고 있다는 것이었습니다. 우리가 책을 읽을 때 그 책에서 도움을 받는 경우는 저자가 그런 이야기를 할 수 있게 되었던 배경이 된 책을 언급해 줄 때입니다. 꽤 많은 저자들이 이 부분에서 친절하지 못해서, 독자가 더 깊이 이해하고 싶더라도 할 수 없게 만드는데요. 이 책의 저자들은 그 부분에서 상당히 친절하더군요. 데브옵스가 무엇인지, 개발자와 어떤 연관을 가지고 있는지, 근거를 가지고 설명하고 있어서 데브옵스 자체에 대해 접근하기 좋게 설명하고 있습니다. 또한, 자바 개발자로서 사용하는 데브옵스 툴들에 대해서도, 간략하게 코드 셈플을 제시하면서, 나름의 실험 결과를 보여주고 있는데요. 컴파일 결과와 실행 속도 같은 것, 그리고 그 툴의 장단점을 정리해서 소개해주고 있습니다. 이렇게 정리해주면, 사용하는 입장에서 다음에 어떤 툴을 써야 할지 모를때 크게 도움을 받을 수 있겠죠. 보안에 대해서 다루는 부분은 정말 인상깊었습니다. 사실 저는 데브옵스에 대해서 안정적으로 개발 결과를 서비스로 반영하는 과정이라고 이해하고 있었는데요. 요즘 소프트웨어 산업의 구조는 사용하는 모든 라이브러리를 해당 조직에서 모두 만들어서 쓰지 않기 때문에 보안적으로 취약할 부분이 있다는 설명이 있었고, 그런 보안의 취약성이 알려지면 이를 빠르게 수정하는 게 중요하다는 걸, 사례를 들어서 설명하고 있습니다. 만약 보안적으로 취약한 라이브러리가 발견되었고, 그걸 주요 코드에서 사용했다면, 빠르게 라이브러리를 제거하고 우회하는 코드를 넣어야 하는데요. 데브옵스 체계가 제대로 갖춰져있지 않은 회사는 그 속도가 현저하게 느릴 수 있습니다. 그렇게 되면 악의적인 의도를 가진 침입자들이 들어와서 시스템에서 중요한 정보를 빼가기 쉽게 되겠죠. 직접적으로 사용하는 툴들을 소개하는 책이 아님에도 의외로 많은 것을 얻을 수 있었고, 기분좋게, 재미있게 읽을 수 있었던 책이었습니다. "한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다." |