서평단 활동 소개
"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."
백엔드는 개발해봤는데, 인프라는 얼마나 알고 있을까?
두 달만에..! 리뷰로 읽은 책은 누구나 이해하는 클라우드 인프라 지식 사전 입니다. 저는 지금까지 백엔드 개발을 공부하면서 Java와 Spring Boot를 중심으로 API를 만들고, 데이터베이스를 연결하고, 인증/인가를 구현하는 등 애플리케이션 개발에 집중해왔습니다. 그리고 아시다시피, 백엔드 개발자 뿐만 아니라 모든 IT 개발 직무를 담당하시는 분들은 특이하게도 인프라 뿐만 아니라 솔루션 프로그램부터 문서 정리까지..? 전부 다 하는 경험은 모두 해봤을 거라고 슬픈 확신을 합니다... ㅎㅎ
그렇게 프로젝트를 진행하다 보면 자연스럽게 Docker도 사용하게 되고, 서버를 배포하면서 클라우드도 접하게 됩니다. Nginx, DNS, HTTPS, CI/CD 같은 기술들도 하나씩 사용하게 되고요. 그런데 어느 순간 이런 생각이 들었습니다. 나는 이것들을 정말 이해하고 사용하는 것이기 보다는, 그냥 필요한 순간마다 검색해서 사용하고 있는데... 올바른 태도가 맞는걸까? 이러한 "생각"과 함께 다음과 같은 "상황"에 놓이면 어떻게 될지 가끔 고민이 들었어요.
- 그런데 서비스가 갑자기 느려지면 어디부터 확인해야 할까?
- 사용자가 많아지면 서버 사양을 높여야 할까? 아니면 서버를 여러 대로 늘려야 할까?
- 애플리케이션에서는 정상적으로 처리됐는데 사용자에게 응답이 제대로 전달되지 않는다면 어디에서 문제가 발생한 걸까?
여기까지 생각해보니 단순히 백엔드 코드를 잘 작성하는 것과 서비스를 안정적으로 운영하는 것은 또 다른 영역이라는 생각이 들었습니다. 그래서 이번에는 애플리케이션을 만드는 방법보다, "내가 만든 애플리케이션은 실제로 어떤 환경에서 실행되고 운영되는가?" 이 부분을 제대로 공부해보고 싶었습니다. 이때 감사하게도, 서평으로 읽게 된 책이 바로 한빛미디에서 새롭게 출간된 누구나 이해하는 클라우드 인프라 지식 사전 입니다.
이 책의 가장 큰 특징은 수많은 인프라 관점에서 다루는 책들과 다르게, 인프라 담당자가 아니라 백엔드 개발자라는 입장에서 읽으면 정말 큰 도움이 되는 항목들로 구성을 했다는 점을 크게 느꼈습니다. 특히 개발만 하는 백엔드에서, 운영까지 생각하는 백엔드로 이 책을 읽으면서 가장 크게 느낀 부분은 개발자가 생각해야 하는 범위가 생각보다 훨씬 넓다는 것이었습니다. 평소 백엔드 프로젝트를 진행하면 아무래도 코드에 가장 많은 관심을 가지게 됩니다. API 설계는 괜찮은지, 객체의 책임은 적절하게 나누어져 있는지, 쿼리 성능은 괜찮은지, 예외 처리는 제대로 되어 있는지 등을 고민합니다. 하지만 실제 서비스는 애플리케이션 코드 하나만으로 동작하지 않습니다. 서버가 있고, OS가 있고, 네트워크가 있고, DNS와 HTTP/HTTPS가 있고, 데이터베이스가 있고, 그 위에서 애플리케이션이 실행됩니다. 여기에 Docker와 Kubernetes 같은 컨테이너 기술이 들어가고, 클라우드 환경이 들어가고, 실제 서비스를 운영하기 시작하면 모니터링과 로깅, 백업, 보안까지 필요해집니다.
책의 목차를 처음 봤을 때도 조금 놀랐습니다. 서버와 네트워크 정도를 다루는 책이라고 생각했는데, 가용성과 신뢰성부터 성능 튜닝, OS, Docker, Kubernetes, 클라우드, 모니터링, DevOps, SRE, 보안, 로그, 백업, 릴리스 엔지니어링까지 다루고 있었습니다. 결국 우리가 서비스 하나를 운영하기 위해 알아야 하는 영역을 전체적으로 보여주는 책에 가깝습니다.
스케일 업? 스케일 아웃? 그래서 왜 하는데...
개인적으로 재미있게 읽었던 부분 중 하나는 가용성, 신뢰성 그리고 용량과 부하 관리에 대한 내용이었습니다. 스케일 업과 스케일 아웃이라는 단어 자체는 백엔드를 공부하면서 정말 많이 들어봤습니다. 서버 성능을 높이는 것이 Scale Up이고, 서버의 수를 늘리는 것이 Scale Out..! 여기까지만 보면 사실 어려운 개념은 아닙니다. 그런데 실제 서비스에서는 단순히 서버를 늘린다고 모든 문제가 해결되는 것은 절대 아니라는 사실은 알고 있습니다. 어디에서 병목이 발생하고 있는지 확인해야 하고, 처리량과 응답 시간을 생각해야 하고, 어떤 부분을 수평 확장할 수 있는지도 체계적인 계획을 통해 여러 문제들을 고려해야 합니다. 특히 성능 튜닝 부분을 읽으면서 "느리니까 서버부터 늘리자"가 정답이 아니라는 것을 다시 한번 느꼈습니다.
결국 중요한 것은 현재 시스템의 병목 지점을 찾아내는 것입니다. 애플리케이션이 문제인지, 데이터베이스가 문제인지, 네트워크가 문제인지, 아니면 단순히 서버의 자원이 부족한 것인지 먼저 알아야 합니다. 백엔드 개발을 하면서 성능 최적화라고 하면 쿼리 튜닝이나 캐시부터 떠올렸는데, 이 책을 읽으면서 조금 더 넓은 관점에서 성능을 바라볼 수 있었습니다.
가장 관심 있게 본 모니터링과 관찰 가능성
이번 책에서 개인적으로 특히 관심 있게 본 부분은 모니터링과 관찰 가능성(Observability)이었습니다. 서비스를 만드는 것까지는 프로젝트를 통해 여러 번 경험할 수 있지만, 실제 운영 환경에서 장애를 발견하고 원인을 추적하는 경험은 상대적으로 접하기 어렵습니다. 개발 환경에서는 에러가 발생하면 IDE의 콘솔을 확인하면 됩니다. 하지만 실제 서비스에서는 그렇게 단순하지 않습니다. 여러 서버와 컨테이너에서 애플리케이션이 실행될 수도 있고, 특정 사용자에게만 문제가 발생할 수도 있고, CPU나 메모리 같은 시스템 자원이 원인일 수도 있습니다. 그래서 단순히 "서버가 살아 있는가?"를 확인하는 것을 넘어서 시스템 내부에서 어떤 일이 발생하고 있는지를 관찰할 수 있어야 한다는 점이 인상 깊었습니다. 로그, 메트릭과 같은 데이터를 통해 시스템의 상태를 확인하고 장애가 발생했을 때 원인을 추적할 수 있는 구조를 만드는 것 역시 개발자가 생각해야 하는 부분이라는 것을 알 수 있었습니다. 특히 장애 대응과 포스트 모템까지 연결해서 설명한다는 점도 좋았습니다. 장애를 단순히 고치고 끝내는 것이 아니라, 왜 발생했는지 → 어떻게 대응했는지 → 다시 발생하지 않으려면 무엇을 바꿔야 하는지까지 이어지는 과정 자체가 운영이라는 것을 이해할 수 있었습니다.
처음부터 끝까지 외울 필요가 없는 책
그리고 이 책의 장점 중 하나는 제목 그대로 '지식 사전'처럼 활용해야 좋다고 생각합니다. 23장까지 있기 때문에 처음 목차를 보면 공부해야 할 내용이 굉장히 많다는 것은 사실입니다. 하지만 모든 내용을 처음부터 끝까지 외울 필요는 없다고 강력하게 생각합니다! 오히려 항목마다 모두 외우려고 하지 않고, 여행 브로셔를 읽듯이 새로운 관점을 넓힌다는 생각으로 읽었습니다. Docker가 궁금하면 가상화와 컨테이너 부분을 읽고, 서비스가 느려졌다면 용량과 부하 관리, 성능 튜닝 부분을 찾아보고, 배포 이후 운영에 관심이 생겼다면 모니터링과 로그, DevOps와 SRE 부분을 읽어보는 식입니다. 그리고 하나의 개념을 공부하다 보면 다른 개념과 자연스럽게 연결됩니다. 성능을 공부하다 캐시를 만나고, HTTP를 공부하다 HTTPS와 TLS로 넘어가고, 서비스를 운영하다 보면 모니터링과 로그가 필요해지는 식입니다. 다시 한 번 말하지만, 각 토픽마다 깊게 공부하는 것은 이 책의 올바른 방향이 아니라고 생각하기 때문에 저처럼 다음 세 가지를 기준 삼아 책을 읽으면 훨씬 더 큰 도움이 될 것이라고 생각해요!!!!
- 모두 외우기 금지! 개발자가 알아야 할 영역을 훑어보며 시야 넓히기!
- 여행 브로셔처럼 읽으며, 내가 구현한 프로젝트 인프라의 전체 지도를 그리기
- 지금까지 흩어져 있던 기술 지식을 하나의 서비스 관점으로 연결하기
개발자로서 기본적으로 알아야 할 영역이 무엇인지 파악한 뒤, 그중 내가 관심 있는 분야를 선택해서 더 깊게 공부하는 것은 가능하다고 생각합니다. 그래서 저는 이 책을 단순히 클라우드 인프라 용어를 공부하기 위한 책보다는, 치열해지는 개발자 시장에서 앞으로 어떤 지식을 갖춰야 하는지 점검하고, 나만의 강점을 어디에서 더 깊게 만들어갈지 판단하기 위한 시작점이 될 수 있는 책으로 추천하고 싶습니다. 저 역시 앞으로 백엔드 프로젝트를 만들 때 단순히 "기능이 동작한다"에서 끝내는 것이 아니라, "이 기능이 실제 서비스 환경에서도 안정적으로 운영될 수 있을까?" 그리고 한 걸음 더 나아가, "나는 이것을 제대로 이해하고 설명할 수 있는 개발자인가?" 까지 고민하면서 공부해야겠다는 생각을 하게 된 책이었습니다 :)
학습에 도움이 되는 참고 사항
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along wit
datatracker.ietf.org
RFC 2026: The Internet Standards Process -- Revision 3
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used
datatracker.ietf.org
RFC 9293: Transmission Control Protocol (TCP)
This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of change
datatracker.ietf.org
RFC 9112: HTTP/1.1 | RFC Editor
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related securit
www.rfc-editor.org
RFC 5322: Internet Message Format
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itsel
datatracker.ietf.org