BOOK, REVIEW, 한빛미디어, 나는리뷰어다, 누구나 이해하는 클라우드 인프라 지식 사전, 클라우드 인프라, 백엔드 개발자, 성능 튜닝, SRE

누구나 이해하는 클라우드 인프라 지식 사전 - 인프라가 막막한 백엔드 주니어에게 지도가 되어줄까

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

목차

  1. 왜 이 책을 집어 들었나 - 파편으로 모은 지식은 늘 점이었다
  2. 23장 한눈에 보기 - 이 책이 실제로 다루는 범위
  3. 4장 성능 튜닝 - 추측하지 말고 측정해라
  4. 사전이라는 제목에 대하여 - 원제는 대전이었다
  5. 이런 분께 추천합니다
  6. 이런 분께는 권하지 않습니다
  7. 정리 - 남은 건 지식이 아니라 어휘였다

왜 이 책을 집어 들었나 - 파편으로 모은 지식은 늘 점이었다

기능 개발은 어떻게든 한다. API를 만들고 쿼리를 짜고 테스트를 붙이는 일은, 막히더라도 결국 길이 보인다.

문제는 그 바깥이었다.

응답이 느려졌다는 얘기가 나오면 어디를 봐야 할지 감이 안 왔다. 로그를 켜보고, 인덱스를 의심하고, 인스턴스를 한 단계 올려보고. 그러다 어쩌다 나아지면 “아마 이게 문제였겠지” 하고 넘어갔다. 왜 나아졌는지는 끝까지 모른 채로.

인프라 지식은 대체로 이런 식으로 쌓인다. 문제가 터질 때마다 그때 필요한 조각만 검색해서 급하게 주워 담는다. 그렇게 모은 지식은 언제나 점이었다. 선으로 이어지지 않았다.

한빛미디어의 누구나 이해하는 클라우드 인프라 지식 사전은 그 점들을 이어보려고 집어 든 책이다. 576페이지, 23장 두께에 겁먹었는데, 서문에서 저자가 먼저 이렇게 말한다.

모든 내용을 세세하게 이해하려고 하기보다는, 우선 한 번 전체를 훑어보는 것만으로도 자신의 시야가 넓어졌음을 느낄 수 있다.

23장 한눈에 보기 - 이 책이 실제로 다루는 범위

서평을 읽는 입장에서 제일 궁금한 건 결국 “이 책에 뭐가 들었나”일 것이다. 23장을 주제별로 묶으면 이렇게 정리된다.

구분 장 다루는 것
기초 원리 1~5장 정보 시스템과 인프라 / 가용성과 신뢰성 / 용량과 부하 관리 / 성능 튜닝 / IaC·캐시·프록시·리트라이
네트워크 6~7장 URL·DNS·HTTP·네트워크 품질 / HTTPS와 SSL/TLS
실행 환경 8~11장 OS(프로세스·메모리·권한) / 가상화와 컨테이너·도커·쿠버네티스 / 데이터 센터와 서버 장비 / 프로덕션·스테이징·테넌시
클라우드·미들웨어 12~13장 클라우드 서비스 선택 기준과 과금 / 웹 서버·앱 서버·RDB·KVS
운영 14~15장 감시·모니터링·관찰 가능성·포스트모템 / 데브옵스와 SRE·플랫폼 엔지니어링
보안·기록·복구 16~18장 정보 보안과 인증 / 로그 및 구조화 로깅 / 백업과 3-2-1 전략
배포·관리 19~20장 배포와 릴리스 기법·CI/CD / 구성 관리
그 외 21~23장 메일 / 컴플라이언스 / 취업

이렇게 놓고 보면 책의 성격이 분명해진다. 특정 벤더의 콘솔 사용법이 아니라, 서비스가 굴러가는 데 필요한 계층 전체를 한 번씩 훑는 구성이다. 1장이 “시스템은 계층 구조를 이룬다”로 시작하는 것도 우연이 아니다.

그리고 각 장 끝에는 ‘함께 읽으면 좋은 장’ 이 붙어 있다. 순서대로 읽지 않아도 되게 만든 장치인데, 개인적으로는 이게 이 책에서 제일 마음에 든 구조였다. 3장 ‘용량과 부하 관리’를 읽다가 3.6 성능 튜닝에서 자연스럽게 4장으로 넘어가는 식이다. 점을 선으로 잇는 작업을 독자에게 떠넘기지 않는다.

4장 성능 튜닝 - 추측하지 말고 측정해라

이 책에서 가장 오래 붙잡고 있었던 챕터다. 정확히는, 내가 그동안 뭘 잘못하고 있었는지를 알려준 챕터다.

4장은 이렇게 구성되어 있다.

  • 4.1 성능 튜닝의 기본 흐름
  • 4.2 부하 테스트
  • 4.3 성능 개선 기술
  • 4.4 용량 부족에 대처하는 기술

저자는 성능 튜닝의 원칙을 이렇게 못 박는다.

성능 튜닝 원칙: 추측하지 않고 측정해라

그리고 왜 인터넷의 ‘튜닝 레시피’가 잘 안 먹히는지를 설명한다. 레시피는 특정 상황의 병목을 해결하기 위한 수단인데, 우리는 보통 그 전제를 확인하지 않고 가져다 쓴다. 내 병목과 그 글의 병목이 같은지 모른 채로 커넥션 풀을 늘리고 캐시를 붙이는 것이다.

읽으면서 뼈를 맞았다. 나는 늘 원인을 찾은 게 아니라 증상이 사라질 때까지 뭔가를 바꿔본 것에 가까웠다.

포화 상태라는 어휘를 얻었다

이 챕터가 좋았던 이유는 원칙만 외치고 끝나지 않는다는 점이다. 포화(Saturation) 상태라는 개념을 먼저 잡아준다. 단위 시간당 처리량 대비 리소스 성능이 부족한 상태고, CPU 사용률·네트워크 IOPS·스토리지 IOPS 같은 곳에서 나타나며, 일련의 처리 중 어딘가가 포화 상태면 그 지점이 전체 성능을 결정하는 병목이 된다.

그리고 실전에서 놓치기 쉬운 함정도 짚는다.

때로는 과부하로 인해 모니터링 자체가 제대로 동작하지 않을 수도 있다.

이건 겪어본 사람만 쓸 수 있는 문장이다. 장애 때 대시보드가 텅 비어 있어서 “다행히 트래픽이 없네”라고 착각했던 기억이 겹쳤다.

부하 테스트는 절차다

부하 테스트 절차도 구체적이다. 시나리오를 만들고, 모니터링을 먼저 붙이고, 부하를 걸고, 시작·종료 일시와 병렬 수, 트래픽양, 메트릭, 로그, 오류를 기록해 두라고 한다. 반복 실행이 전제이니 손으로 적지 말고 셸 스크립트 정도로라도 자동화하라는 조언까지 붙는다.

그리고 마지막에 이 말이 남았다.

데이터를 기반으로 하기 때문에 감이나 재능, 운이 아니라 구조의 이해와 논리적인 사고, 지식 및 경험의 축적으로 결과를 낼 수 있다.

4장을 관통하는 문장이라고 생각한다. 성능 튜닝이 감각의 영역이 아니라 절차의 영역이라면, 타고난 감각이 아니라 반복과 기록으로 쌓아 올릴 수 있다는 뜻이니까.

사전이라는 제목에 대하여 - 원제는 대전이었다

이 책의 원제는 『バックエンドエンジニアのためのインフラ・クラウド大全』, 직역하면 ‘백엔드 엔지니어를 위한 인프라·클라우드 대전(大全)’ 이다. 한국어판 제목의 ‘사전’보다 원제의 ‘대전’이 책의 성격에 더 가깝다고 느꼈다.

사전은 모르는 단어를 찾는 도구지만, 이 책은 한 번은 통독해야 그다음부터 찾아 쓸 수 있는 종류의 책이기 때문이다. 저자가 서문에서 “우선 한 번 전체를 훑어보라”고 한 것도 같은 맥락일 것이다.

한 가지 더 참고할 점은, 이 책이 실습서가 아니라는 것이다. Docker 명령어나 Kubernetes 매니페스트를 따라 치면서 배우는 책을 기대한다면 결이 다르다. 개념과 판단 기준을 다루는 책이라, 손을 움직이는 학습은 별도로 병행하는 편이 좋다.

추천하는 읽기 순서는 이렇다.

  1. 1장(계층 구조)을 먼저 읽어 전체 지도를 잡는다.
  2. 지금 내 발등에 떨어진 장으로 바로 점프한다. (느리다 → 3~4장, 장애 → 14장, 배포 → 19장)
  3. 각 장 끝의 ‘함께 읽으면 좋은 장’을 따라간다.

이런 분께 추천합니다

읽으면서 두 부류가 계속 떠올랐다.

첫째, 기능은 만드는데 그 바깥이 막막한 백엔드 주니어

API도 짜고 쿼리도 짜지만, “응답이 느려요”라는 말 한마디에 어디를 봐야 할지 모르겠는 1~3년 차. 특히 필요할 때마다 검색으로 지식을 파편처럼 모아온 경우라면, 이 책이 그 파편에 목차를 달아준다.

4장 하나만 제대로 읽어도 “일단 스펙을 올려보자”에서 벗어날 수 있다.

둘째, 이직 면접을 준비하는 주니어~미들 개발자

23장 ‘취업’이 이 책에서 가장 예상 밖의 챕터였다. 저자는 이렇게 준비하라고 한다.

자신이 속한 시스템의 계층 구조를 떠올리며, 지금 알고 있는 범위의 한 계층 위와 아래까지 이해하려고 노력해 보면 좋다.

구체적으로는 지금 쓰는 기술의 정식 명칭, 버전, 아키텍처상의 역할, 왜 그 아키텍처를 택했는지, 왜 그 제품을 골랐는지, 왜 아직 그대로 쓰는지를 설명할 수 있어야 한다고 한다. “후배에게 설명한다는 마음으로 정리하라”는 조언이 붙는데, 이게 사실 면접 답변을 만드는 방법 그 자체다.

대체재를 찾아보라는 조언도 좋았다. PostgreSQL을 쓰고 있다면 MySQL과 뭐가 다른지, Redis와는 어떻게 다른지, NewSQL인 TiDB와는 무엇이 다른지로 시야를 넓혀 가라고 한다. 기술 선택 이유를 묻는 면접 질문에 매번 얼버무렸다면, 이 방식이 답을 만들어 준다.

이런 분께는 권하지 않습니다

솔직하게 적어두는 편이 도움이 될 것 같다.

  • 손을 움직이며 배우고 싶은 분 — 실습 예제가 목적이라면 다른 책이 맞다. 이 책은 개념과 판단 기준을 다룬다.
  • 특정 클라우드의 자격증을 준비하는 분 — AWS/GCP 서비스명을 외우는 책이 아니다. 벤더 중립적인 원리를 다룬다.
  • 이미 인프라를 업으로 하는 분 — 넓게 훑는 구성이라 각 주제의 깊이는 얕은 편이다. 다만 신입 온보딩 교재로는 좋아 보인다.

정리 - 남은 건 지식이 아니라 어휘였다

누구나 이해하는 클라우드 인프라 지식 사전을 한 문장으로 정리하면 이렇다.

“성능도 가용성도 감이 아니라 측정과 기준의 문제다.”

576페이지를 훑고 나서 남은 건 개별 지식이 아니라 어휘였다.

전에 부르던 말 지금 부를 수 있는 말
“느리다” 포화(Saturation), 병목
“안 죽어야 한다” 가동률, SLO
“장애 보고서” 포스트모템
“서버 늘리자” 스케일 아웃 / 스케일 업, 분할

이름을 붙일 수 있으면 검색할 수 있고, 검색할 수 있으면 그다음으로 넘어갈 수 있다.

다음에 응답이 느려졌다는 얘기가 나오면, 인스턴스 스펙을 올리기 전에 어디가 포화 상태인지부터 측정해 볼 생각이다.

피드백은 언제나 환영입니다.