<div id="readability-page-1" class="page"><div><figure data-ke-mobilestyle="widthOrigin" data-origin-width="4032" data-origin-height="2268"><img src="https://blog.kakaocdn.net/dn/RREbt/btsCAMcAsw9/BTxZJlCzsyKB3fPAwtHpv0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="4032" data-origin-height="2268"><figcaption>Release의 모든 것</figcaption>
</figure>


제목이 다소 오만해 보이지만 내용만은 아주 알찬 번역서가 한빛미디어에서 출간되었습니다. 바로 <a href="https://www.hanbit.co.kr/store/books/look.php?p_code=B1820128661" target="_blank" rel="noopener">Release의 모든 것</a> 입니다. 책이 세상에 나오기 전에 제목을 추천받기도 했던 것 같은데요. 책을 덮고 나서도 이것 이상의 제목은 떠오르지 않네요. 그리고 번역서지만 번역서 느낌이 별로 들지 않습니다. 외국 사례들이 나올 때서야 "아, 이 책이 번역서였지"하는 느낌을 받았으니까요. 전반적으로 매끄럽게 잘 읽힙니다.&nbsp;
책에는 아주 많은 내용이 담겨있습니다. 4장&nbsp;안정성&nbsp;안티&nbsp;패턴과 5장 안정성 패턴은 특히 여러 책에 걸쳐 소개되고 있는 내용들이 많습니다. <a href="https://jybaek.tistory.com/950" target="_blank" rel="noopener">소프트웨어 아키텍처 101</a>과 같은 책을 본 적이 있다면 아마도 한 번쯤은 접해본 적이 있을 내용일 겁니다. 여기서 다시 정리하는 느낌으로 읽으니 좋았습니다. 기승전결처럼 모든 장이 연결되는 것이 아니라서 책장에 꽂아두고 장을 넘기며 그때그때 흥미가 당기는 부분을 읽어도 상관없습니다.&nbsp;
<blockquote data-ke-style="style1">결국 이런 버그 하나하나가 모두 제거되기를 기대하는 것은 환상일 뿐이다. 버그는 발생한다. 버그는 말살되기는커녕 반드시 살아남을 것이다. 이 지점에서 가장 심각한 문제는 한 시스템의 버그가 관련이 있는 다른 모든 시 스템으로 전파될 수 있다는 사실이다. 버그를 예방할 방법을 찾는 것보다 더 나은 질문은 '한 시스템의 버그가 다른 시스템에 영향을 미치지 않게 하는 방법은 무엇인가?'이다. 오늘날 모든 기업의 내부에는 상호 연결되고 상호 의존하는 그물망 같은 시스템들이 있다. 이런 환경에서 버그가 연쇄적으로 장애를 일으키도록 허용해서는 안 된다.&nbsp;</blockquote>

이런 내용을 봐보세요. 모든 버그를 잡고 나서 혹은 모든 경우의 수를 테스트하고 나서 Release를 한다는 건 사실상 말이 안 됩니다. 버그는 발생할 수밖에 없다는 사실을 인정하되, 장애가 전파되지 않도록 막는 것을 최선으로 해야 합니다. 모놀리식 같은 경우에는 특히 더욱 그렇겠지요. 마이크로서비스로 가면서 장애가 전파되지 않도록 막는 여러 가지 수단이 있습니다. 이 책의 5장, 안정성 패턴에서 내용을 살펴보세요. 그렇다고 책에 언급되는 패턴을 많이 적용할수록 안정적인 시스템이 된다는 말은 아닙니다. 이건 책에서도 똑같이 이야기합니다.
<blockquote data-ke-style="style1">이 패턴들을 더 많이 적용한 시스템이 우월하다고 가정하는 실수를 범하지 말자. '적용된 패턴 수'는 결코 좋은 품질 지표가 아니다. 대신 복구 지향(recovery oreoncd) 의식을 길러야 한다. 고장 난 레코드판처럼 보이겠지만 다시 반복하겠다. 장애는 반드시 일어난다고 생각하자! 그리고 이러한 패턴을 현명하게 적용하여 각 장애로 입는 피해를 최소화하자.</blockquote>

개인적으로 요즘 카오스 공학에 관심을 갖고 있었는데 이 부분도 잘 정리가 되어 있습니다. 카오스 공학을 떠올리면 <a href="https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116" target="_blank" rel="noopener">넷플릭스의 카오스 몽키</a>가 먼저 떠오르는 건 어쩔 수 없습니다. 과연 우리 시스템에도 카오스 테스트를 할 수 있을까? 한다면 넷플릭스의 정책을 확인해 보세요. 카오스 테스트를 하지 않기를 원한다면 승인을 받아야 합니다. 그리고 테스트하지 못하는 이유에 대해서 지속적으로 설명해야 할 겁니다. 나아가 그 문제를 해결해야 할 거고요.&nbsp;
<blockquote data-ke-style="style1">넷플릭스에서는&nbsp;카오스&nbsp;테스트를&nbsp;선택적&nbsp;탈퇴&nbsp;방식으로&nbsp;진행한다.&nbsp;운영&nbsp;환경의&nbsp;모든&nbsp;서비스는&nbsp;카오스&nbsp;멍키의&nbsp;적용을&nbsp;받게&nbsp;된다는&nbsp;뜻이다.&nbsp;서비스&nbsp;담당자는&nbsp;적용받기를&nbsp;거부할&nbsp;수&nbsp;있지만&nbsp;승인이&nbsp;필요하다.&nbsp;탈퇴&nbsp;절차는&nbsp;단순한&nbsp;요식&nbsp;행위가&nbsp;아니다.&nbsp;면제되는&nbsp;서비스는&nbsp;카오스&nbsp;멍키가&nbsp;관리하는&nbsp;데이터베이스에&nbsp;등록된다.&nbsp;예외&nbsp;대상이&nbsp;되면&nbsp;낙인이&nbsp;찍힌다.&nbsp;기술&nbsp;책임&nbsp;경영진은&nbsp;이&nbsp;목록을&nbsp;정기적으로&nbsp;검토하고&nbsp;서비스&nbsp;담당자에게&nbsp;카오스&nbsp;멍키를&nbsp;적용하지&nbsp;못하는&nbsp;문제를&nbsp;해결하도록&nbsp;권고한다.</blockquote>

좀 더 작은 회사로 넘어가면 슈퍼 개발자 같은 사람들이 존재하는데요. 이 사람들이 빠졌을 때 어떤 혼란이 야기되는지 훈련하는 방법도 있습니다. 좋은 환경이라면 이미 암묵적으로 다 대응이 가능하겠지만 그렇지 않은 곳이라면 분명 필요한 절차입니다. 사실 누구 하나 빠져도 어떻게든 회사는 돌아간다는 생각은 있습니다만, 그렇지 않은 곳도 분명히 있을 테니까요. 불특정 다수의 공백이 어떤 문제를 일으킬 수 있는지 인지하고 있다면 조직을 세팅하는데 분명 도움이 될 겁니다.&nbsp;
<blockquote data-ke-style="style1">이&nbsp;훈련을&nbsp;좀비&nbsp;아포칼립스&nbsp;시뮬레이션'이라고&nbsp;칭해&nbsp;더&nbsp;재미있게&nbsp;만들&nbsp;수&nbsp;있다.&nbsp;구성원의&nbsp;50%를&nbsp;임의로&nbsp;선정해서&nbsp;좀비로&nbsp;간주한다.&nbsp;좀비로&nbsp;지정된&nbsp;사람이&nbsp;다른&nbsp;사람의&nbsp;두뇌를&nbsp;먹을&nbsp;필요는&nbsp;없지만&nbsp;업무를&nbsp;손에서&nbsp;놓고&nbsp;아무런&nbsp;요청에도&nbsp;응답하지&nbsp;말아야&nbsp;한다.</blockquote>

이렇게 재밌는 내용이 가득한 이 책의 유일한 단점이라면 난이도입니다. 서두에 언급되는 것처럼 이 책의 대상 독자는 "중급"입니다. 적어도 제가 느끼기에 이건 "최소"로 지정된 겁니다. 경험이 많은 아키텍트여야 그나마 책이 재밌게 읽힐 겁니다.&nbsp;
<figure data-ke-mobilestyle="widthOrigin" data-filename="blob" data-origin-width="3000" data-origin-height="1097"><img src="https://blog.kakaocdn.net/dn/bd1e2O/btsCycQZlNG/1DN6wGNPy6ysl5Z41kxtrK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="blob" data-origin-width="3000" data-origin-height="1097"><figcaption>대상 독자는 "중급" 입니다</figcaption>
</figure>


예를 들어 서버에서 tcpdump로 패킷을 캡처 한 걸 꺼내서 <a href="https://www.wireshark.org/" target="_blank" rel="noopener">와이어샤크(Wireshark)</a>로 본다거나, 와이어샤크의 옛 이름은 이더리얼(Ethereal)이었다거나(아무도 관심 없겠죠 하하하). 그리고 고수준의 추상화된 코드가 아니라 저수준 소켓 프로그래밍을 본 적이 있어야 좀 더 쏙쏙 박히는 open(), read() 같은 것들. 소켓 연결 과정에서 연결이 끊겼을 때 벌어지는 일들. 하나씩 경험해 본 적이 있다면 분명 아주 재밌게 읽힐 겁니다. 그렇지 않다면 건성으로 넘기게 되는 페이지가 많아질 것 같습니다. 저는 리눅스 커널 위에서 개발을 시작해서 위와 같은 내용들을 어느 정도 경험한 적이 있는데요. 덕분에 오랜만에 추억 여행 하듯이 읽어 내려간 부분이 많았습니다. 특히 와이어샤크는 추억 속에 묻어뒀던 이름인데 10년 만에 만나니 반갑더라고요.&nbsp;
각설하고 이 책은 쉬운 책은 아니지만, 앞서 언급한 것처럼 모든 페이지를 순서대로 읽을 필요가 없습니다. 어려운 내용은 넘어가고 잘 읽히는 장만 공략하는 것도 좋은 방법입니다. 그런 면에서 5장의 일부와 17장은 모든 개발자들에게 아주 재밌게 내용일 겁니다. 실제 운영서버에 우리 코드가 배포된 이후에 겪게 되는 문제와 그것들을 극복하기 위해 어떤 자세와 대응이 필요한지 궁금하시다면 이 책을 일독하시기를 바랍니다.&nbsp;

<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style2">
<div data-ke-size="size16">한빛미디어&nbsp;&lt;나는&nbsp;리뷰어다&gt;&nbsp;활동을&nbsp;위해서&nbsp;책을&nbsp;제공받아&nbsp;작성된&nbsp;서평입니다.</div>
</div></div>

컴맹 : 진화의 시작

제목이 다소 오만해 보이지만 내용만은 아주 알찬 번역서가 한빛미디어에서 출간되었습니다. 바로 Release의 모든 것 입니다. 책이 세상에 나오기 전에 제목을 추천받기도 했던 것 같은데요. 책을 덮고 나서도 이것 이상의 제목은 떠오르지 않네요. 그리고 번역서지만 번역서 느낌이 별로 들지 않습니다. 외국 사례들이 나올 때서야 "아, 이 책이 번역서였지"하는 느낌을 받았으니까요. 전반적으로 매끄럽게 잘 읽힙니다. 
책에는 아주 많은 내용이 담겨있습니다. 4장 안정성 안티 패턴과 5장 안정성 패턴은 특히 여러 책에 걸쳐 소개되고 있는 내용들이 많습니다. 소프트웨어 아키텍처 101과 같은 책을 본 적이 있다면 아마도 한 번쯤은 접해본 적이 있을 내용일 겁니다. 여기서 다시 정리하는 느낌으로 읽으니 좋았습니다. 기승전결처럼 모든 장이 연결되는 것이 아니라서 책장에 꽂아두고 장을 넘기며 그때그때 흥미가 당기는 부분을 읽어도 상관없습니다. 
결국 이런 버그 하나하나가 모두 제거되기를 기대하는 것은 환상일 뿐이다. 버그는 발생한다. 버그는 말살되기는커녕 반드시 살아남을 것이다. 이 지점에서 가장 심각한 문제는 한 시스템의 버그가 관련이 있는 다른 모든 시 스템으로 전파될 수 있다는 사실이다. 버그를 예방할 방법을 찾는 것보다 더 나은 질문은 '한 시스템의 버그가 다른 시스템에 영향을 미치지 않게 하는 방법은 무엇인가?'이다. 오늘날 모든 기업의 내부에는 상호 연결되고 상호 의존하는 그물망 같은 시스템들이 있다. 이런 환경에서 버그가 연쇄적으로 장애를 일으키도록 허용해서는 안 된다. 
 
이런 내용을 봐보세요. 모든 버그를 잡고 나서 혹은 모든 경우의 수를 테스트하고 나서 Release를 한다는 건 사실상 말이 안 됩니다. 버그는 발생할 수밖에 없다는 사실을 인정하되, 장애가 전파되지 않도록 막는 것을 최선으로 해야 합니다. 모놀리식 같은 경우에는 특히 더욱 그렇겠지요. 마이크로서비스로 가면서 장애가 전파되지 않도록 막는 여러 가지 수단이 있습니다. 이 책의 5장, 안정성 패턴에서 내용을 살펴보세요. 그렇다고 책에 언급되는 패턴을 많이 적용할수록 안정적인 시스템이 된다는 말은 아닙니다. 이건 책에서도 똑같이 이야기합니다.
이 패턴들을 더 많이 적용한 시스템이 우월하다고 가정하는 실수를 범하지 말자. '적용된 패턴 수'는 결코 좋은 품질 지표가 아니다. 대신 복구 지향(recovery oreoncd) 의식을 길러야 한다. 고장 난 레코드판처럼 보이겠지만 다시 반복하겠다. 장애는 반드시 일어난다고 생각하자! 그리고 이러한 패턴을 현명하게 적용하여 각 장애로 입는 피해를 최소화하자.
 
개인적으로 요즘 카오스 공학에 관심을 갖고 있었는데 이 부분도 잘 정리가 되어 있습니다. 카오스 공학을 떠올리면 넷플릭스의 카오스 몽키가 먼저 떠오르는 건 어쩔 수 없습니다. 과연 우리 시스템에도 카오스 테스트를 할 수 있을까? 한다면 넷플릭스의 정책을 확인해 보세요. 카오스 테스트를 하지 않기를 원한다면 승인을 받아야 합니다. 그리고 테스트하지 못하는 이유에 대해서 지속적으로 설명해야 할 겁니다. 나아가 그 문제를 해결해야 할 거고요. 
넷플릭스에서는 카오스 테스트를 선택적 탈퇴 방식으로 진행한다. 운영 환경의 모든 서비스는 카오스 멍키의 적용을 받게 된다는 뜻이다. 서비스 담당자는 적용받기를 거부할 수 있지만 승인이 필요하다. 탈퇴 절차는 단순한 요식 행위가 아니다. 면제되는 서비스는 카오스 멍키가 관리하는 데이터베이스에 등록된다. 예외 대상이 되면 낙인이 찍힌다. 기술 책임 경영진은 이 목록을 정기적으로 검토하고 서비스 담당자에게 카오스 멍키를 적용하지 못하는 문제를 해결하도록 권고한다.
 
좀 더 작은 회사로 넘어가면 슈퍼 개발자 같은 사람들이 존재하는데요. 이 사람들이 빠졌을 때 어떤 혼란이 야기되는지 훈련하는 방법도 있습니다. 좋은 환경이라면 이미 암묵적으로 다 대응이 가능하겠지만 그렇지 않은 곳이라면 분명 필요한 절차입니다. 사실 누구 하나 빠져도 어떻게든 회사는 돌아간다는 생각은 있습니다만, 그렇지 않은 곳도 분명히 있을 테니까요. 불특정 다수의 공백이 어떤 문제를 일으킬 수 있는지 인지하고 있다면 조직을 세팅하는데 분명 도움이 될 겁니다. 
이 훈련을 좀비 아포칼립스 시뮬레이션'이라고 칭해 더 재미있게 만들 수 있다. 구성원의 50%를 임의로 선정해서 좀비로 간주한다. 좀비로 지정된 사람이 다른 사람의 두뇌를 먹을 필요는 없지만 업무를 손에서 놓고 아무런 요청에도 응답하지 말아야 한다.
 
이렇게 재밌는 내용이 가득한 이 책의 유일한 단점이라면 난이도입니다. 서두에 언급되는 것처럼 이 책의 대상 독자는 "중급"입니다. 적어도 제가 느끼기에 이건 "최소"로 지정된 겁니다. 경험이 많은 아키텍트여야 그나마 책이 재밌게 읽힐 겁니다. 
 
예를 들어 서버에서 tcpdump로 패킷을 캡처 한 걸 꺼내서 와이어샤크(Wireshark)로 본다거나, 와이어샤크의 옛 이름은 이더리얼(Ethereal)이었다거나(아무도 관심 없겠죠 하하하). 그리고 고수준의 추상화된 코드가 아니라 저수준 소켓 프로그래밍을 본 적이 있어야 좀 더 쏙쏙 박히는 open(), read() 같은 것들. 소켓 연결 과정에서 연결이 끊겼을 때 벌어지는 일들. 하나씩 경험해 본 적이 있다면 분명 아주 재밌게 읽힐 겁니다. 그렇지 않다면 건성으로 넘기게 되는 페이지가 많아질 것 같습니다. 저는 리눅스 커널 위에서 개발을 시작해서 위와 같은 내용들을 어느 정도 경험한 적이 있는데요. 덕분에 오랜만에 추억 여행 하듯이 읽어 내려간 부분이 많았습니다. 특히 와이어샤크는 추억 속에 묻어뒀던 이름인데 10년 만에 만나니 반갑더라고요. 
각설하고 이 책은 쉬운 책은 아니지만, 앞서 언급한 것처럼 모든 페이지를 순서대로 읽을 필요가 없습니다. 어려운 내용은 넘어가고 잘 읽히는 장만 공략하는 것도 좋은 방법입니다. 그런 면에서 5장의 일부와 17장은 모든 개발자들에게 아주 재밌게 내용일 겁니다. 실제 운영서버에 우리 코드가 배포된 이후에 겪게 되는 문제와 그것들을 극복하기 위해 어떤 자세와 대응이 필요한지 궁금하시다면 이 책을 일독하시기를 바랍니다. 
 
한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.
 
'생활 > 책' 카테고리의 다른 글
[책] 그림으로 배우는 구글 클라우드 101  (0)
2023.12.25
[책] 알고리즘 인사이드 with 파이썬  (0)
2023.11.25
[책] 초보자도 프로처럼 만드는 플러터 앱 개발  (2)
2023.10.28
[책] 진화적 아키텍처  (0)
2023.09.24
[책] 견고한 데이터 엔지니어링  (2)
2023.08.27

[책] Release의 모든 것

댓글