|
AI가 코드를 작성하고 클라우드 서비스를 쉽게 사용할 수 있는 시대지만, 결국 시스템을 이해하는 기본기는 여전히 개발자의 중요한 역량이라는 사실을 다시 한번 느끼게 해준 책입니다. 『누구나 이해하는 클라우드 인프라 지식 사전』은 AWS나 Kubernetes 같은 특정 기술의 사용법을 설명하는 실습서가 아니라, 클라우드 환경을 구성하는 핵심 개념과 인프라 전반을 이해하기 쉽게 풀어낸 책입니다. 가용성, 신뢰성, 성능, 네트워크, 운영체제, Docker, Kubernetes, 모니터링, DevOps, SRE, 보안 등 실무에서 반드시 접하게 되는 내용을 폭넓게 다루면서도 하나의 흐름으로 연결해 설명해 주는 점이 인상적이었습니다. 특히 필요한 부분을 찾아가며 읽을 수 있도록 구성되어 있어 한 번 읽고 끝나는 책이 아니라 실무에서 계속 참고할 수 있는 레퍼런스 북으로 활용하기 좋습니다. 클라우드를 처음 공부하는 분은 물론, 백엔드 개발자나 시스템 운영에 대한 이해를 넓히고 싶은 개발자에게도 추천하고 싶은 책입니다. 최신 기술을 익히는 것만큼 기본 원리를 이해하는 것이 중요하다는 저자의 메시지가 오래 남는 좋은 기술서였습니다. |
|
AI가 코드를 만들어주는 시대가 되었지만, 서비스가 실제로 안정적으로 돌아가려면 결국 서버와 네트워크, 운영에 대한 기본 지식이 필요하다. 이 책은 서버와 OS 같은 기초부터 컨테이너, 클라우드, 모니터링, SRE, 보안, 백업까지 개발자가 알아야 할 인프라 지식을 폭넓게 다룬다. 내용의 범위는 상당히 넓지만, 단순히 용어를 나열하기보다는 하나의 서비스가 만들어지고 운영되는 흐름을 따라 설명해 전체적인 그림을 잡는 데 도움이 됐다. 특히 개발은 할 수 있지만 인프라나 운영 영역은 막연하게 느껴졌던 사람에게 좋은 입문서라고 생각한다. AI 개발 도구를 자주 사용하는 개발자일수록 한 번쯤 읽어볼 만한 책이다. "한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다." |
|
안녕하세요, 웹 시스템 개발하는 5년 차 백엔드 개발자입니다. 솔직하게 시작할게요. 저 인프라 그렇게 깊이 있게 알지는 못했습니다 대게 개발자는 코드는 짭니다. API 만들고, 쿼리 튜닝하고, 테스트 짜고, 배포까지는 해요. 근데 그 배포된 코드가 도대체 어디서 어떻게 돌아가는지는 알기가 쉽지않습니다. 일을 하는중에 인프라, 아키텍처가 해주는 부분이 보기 쉽지않고 프로젝트 특성상 그렇게 까지 여유롭지가 못합니다..그러던 와중에 이 책을 만났어요.결론부터 말하면, 이건백엔드 개발자가 인프라라고 부르며 눈 감고 있던 영역을 정면으로 마주 보게 만드는 책이었습니다 누구나 이해하는 클라우드 인프라 지식 사전 목차를 펼쳐보고 놀란 게, 이게 총 23장이에요.1장 정보 시스템과 인프라부터 시작해서 가용성·신뢰성, 용량과 부하 관리, 성능 튜닝, IaC·캐시·프록시 같은 기본 용어, 인터넷, HTTPS, OS, 가상화·컨테이너, 데이터 센터, 클라우드 서비스, 모니터링, 데브옵스와 SRE, 보안, 로깅, 백업, 릴리스 엔지니어링… 마지막엔 심지어 취업까지 다뤄요. "이걸 한 권에 다 담는다고?" 싶었는데, 읽다 보니 알겠더라고요. 이건 깊게 파는 전문서가 아니라, 인프라라는 지도의 전체 그림을 그려주는 책입니다. 각 챕터가 "이 용어 들어본 적 있죠? 이게 이런 거예요" 하고 정확히 필요한 만큼만 짚어줘요. "백엔드 엔지니어 관점에서는 '자신이 개발한 애플리케이션 외에는 모두 인프라'라고 생각하기 쉽지만, 사실 내부를 들여다보면 여러 구성 요소로 이루어져 있다." 읽으면서 뜨끔했습니다. 저 정확히 그랬거든요. 내 코드 = 개발, 나머지 전부 = 인프라(=남의 일). 이렇게 선을 그어놓고 살았어요. 근데 책에서 시스템 계층 구조 표를 딱 보여주는데, 애플리케이션 프로그램 → 애플리케이션 라이브러리 → 런타임 → 시스템 라이브러리 → OS → 네트워크 → 하드웨어 → 코로케이션. 이렇게 층층이 쌓여 있고, **"낮은 계층일수록 물리 법칙의 영향을 많이 받는다"**는 설명이 나와요.건물 없으면 기기를 둘 수 없고, 전기 없으면 기기가 안 돌아간다. 너무 당연한 말인데, 이걸 계층으로 정리해서 보니까 "아, 내 API 응답이 느린 게 코드 문제가 아니라 두세 계층 아래에서 시작됐을 수도 있겠구나" 하는 시야가 생기더라고요. 이 시스템 구성도 한 장이 책 전체의 뼈대예요. 브라우저 → DNS/CDN → 로드 밸런서 → 웹 서버 / BFF / 애플리케이션 서버 → DB / KVS / 객체 스토리지. 실무에서 흩어져 있던 조각들이 이 그림 하나로 연결됩니다. 2장 가용성 챕터는 진짜 실무 필살기였어요.기획자나 상사가 "우리 서비스 가용성 몇 %예요?" 물어보면 저는 늘 "어… 거의 안 죽어요" 이 수준으로 답했거든요. 근데 책에 가동률 공식이 딱 나와요. 가동률 = MTBF ÷ (MTBF + MTTR) × 100 MTBF(평균 고장 간격)랑 MTTR(평균 복구 시간)로 계산한다는 거. 그리고 여기서 진짜 중요한 포인트가 나오는데 동작에 필요한 구성 요소가 많을수록 가용성의 기대치가 내려간다예로 가용성 99% 장비 3개가 연동되면 0.99 × 0.99 × 0.99 ≒ 0.97, 즉 97%로 떨어진다는 거예요. 저는 막연히 "좋은 장비 여러 개 = 더 안정적"이라고 생각했는데, 직렬로 엮이면 오히려 곱해져서 내려간다는 거. 이거 보고 우리 시스템 구성 다시 그려봤습니다.그리고 9'를 한 자리 늘리려면 예산·공수가 10배가 된다.는 문장. 99.9%에서 99.99%로 가는 게 그냥 소수점 하나 더 붙이는 게 아니라는 걸, 왜 우리 팀이 그 한 자리 때문에 그렇게 고생했는지 이제 이해했어요. 3장 용량·부하 관리 스케일 아웃/업, 샤딩을 "그림으로" 이해했다수평 확장(스케일 아웃/인), 수직 확장(스케일 업/다운). 말은 백 번 들었죠. 근데 데이터베이스 분할(샤딩)의 수평 분할 vs 수직 분할을 그림으로 보니까 그제서야 딱 들어왔어요.수평 분할은 행(row) 단위로 나누고, 수직 분할은 테이블·열(column) 단위로 나눈다. 그리고 특정 위치에 데이터나 처리가 몰리는 핫 파티션(Hot partition) 문제가 샤딩에서 제일 어려운 문제라는 것.읽으면서 예전에 특정 사용자 ID 구간에 트래픽 쏠려서 밤새 원인 찾던 기억이 딱 떠올랐어요. 그게 핫 파티션이라는 이름이 붙은 현상이었구나. 이름을 아니까 검색도 되고, 대응책도 찾을 수 있게 됐습니다. 5장 IaC "사람이 하면 반드시 실수한다"는 뼈아픈 진실Infrastructure as Code(IaC) 챕터에서 이 문장 보고 조용히 고개 끄덕였습니다. 저희 팀도 콘솔에서 수동으로 설정 바꾸다가 사고 낸 적 여러 번이에요. 그때마다 "다음엔 조심하자"였는데, 책은 조심의 문제가 아니라 구조의 문제라고 딱 잘라 말해요. 사람이 손대는 한 실수는 나온다. 그러니 코드로 정의하고 툴(컴퓨터)이 변경을 처리하게 하라. 그리고 절차형(Procedural) vs 선언형(Declarative) 방식 구분. 절차형은 "무엇을 하는가", 선언형은 "어떻게 되었으면 하는가(기대 상태)"를 기술한다. 테라폼·클라우드 포메이션·쿠버네티스 매니페스트가 선언형 IaC라는 것. 그동안 테라폼 쓰면서도 "이게 왜 선언형이지?"를 제대로 설명 못 했는데 이제 됩니다.IaC의 진짜 이점이 시간·비용 절감이 아니라 **"품질과 보안 관리 수준이 향상된다"**는 점이라는 것도 좋았어요. 재현성·재사용성·버전 관리·코드 리뷰·CI/CD를 인프라에도 그대로 적용할 수 있다는 거죠. 베스트 에폿(Best effort), RTT, 지터(Jitter), 대역 보장 서비스… 네트워크 품질 용어들이 정리돼 있어요. "1Gbps 회선인데 왜 1Gbps가 안 나오냐"는 그 흔한 질문의 답이 여기 있습니다. 베스트 에폿은 최대 1Gbps를 쓸 수 있지만 최저는 보장 못 한다는 의미라는 것. DNS 파트에서는 권한 서버 vs 풀 리졸버(Full resolver) 구분, 정방향/역방향 조회, AWS Route 53 같은 예시까지. 저는 DNS를 그냥 "도메인을 IP로 바꿔주는 마법"쯤으로 알고 있었는데, 이름 해석(Name resolution)이라는 정식 이름과 구조를 알고 나니 장애 대응할 때 완전히 다릅니다. 9장 가상화와 컨테이너 하이퍼바이저 2층 구조가 드디어 그려졌다서버 가상화가 2층 구조라는 것. 1층이 호스트, 2층이 게스트, 그 사이를 만들어주는 소프트웨어가 하이퍼바이저(Hypervisor). VMware, Hyper-V, KVM, Xen 같은 게 하이퍼바이저라는 것.도커 매일 쓰면서도 "가상 머신이랑 컨테이너가 뭐가 다른데?"를 명확히 설명 못 했는데, 이 계층 그림 보고 정리됐어요. 그림 하나가 텍스트 열 페이지를 이깁니다. 15장 데브옵스와 SRE 이 챕터가 사실 이 책의 심장입니다 이거 뼈 맞았어요. 저희 팀도 "SRE 도입하자, 모니터링 툴 깔자, 자동화하자" 이렇게 수단부터 얘기하다가 정작 "그래서 이게 사용자한테 뭐가 좋은데?"에서 막힌 적 많거든요.그리고 SRE 도입 순서를 8단계로 딱 정리해줘요. 감시·모니터링 → 장애 대응 연락망 → 정기 모니터링 회의 → 자동 테스트 → 반자동 배포 → SLI 임시 결정 → 사고 관리 시스템 → 포스트모템. **"하위 계층부터 한 단계씩 완벽하게 마무리하려는 방식은 오히려 잘못된 접근"**이고, 순차적으로 진행하되 각 단계를 견고하게 쌓아가라는 조언이 현실적이었습니다.. 19장 릴리스 기법(빅뱅·카나리·피처 플래그)을 나란히 정리하면서 피처 플래그가 트렁크 기반 개발과 세트로 쓰여 문제 시 플래그만 바꿔 빠르게 롤백할 수 있다는 강점과 함께 플래그가 쌓일수록 코드가 난잡해진다는 단점까지 균형 있게 짚어주고, 21장에선 회원가입·비밀번호 재설정 메일이 스팸함 직행당하는 그 흔한 고통을 SPF·DKIM·DMARC 검증, 발신 도메인·IP 평판, 바운스 관리, "평소 적게 보내다 갑자기 대량 발송하면 스팸 처리된다"는 실전 포인트로 명쾌하게 풀어줘서, 릴리스부터 메일 발송까지 백엔드 개발자가 매일 부딪히는 문제들의 교본 같은 두 챕터였습니다. 그래서 이 책 누구한테 추천하냐면, 인프라를 "남의 일"이라 선 긋고 코드만 짜던 백엔드 개발자(← 저요), AWS 콘솔 용어는 아는데 ALB·Multi-AZ·Auto Scaling이 왜 그렇게 묶이는지는 모르던 사람, 나중에 특정 주제 깊게 팔 때 "아 그거 그 책에 있었지" 하고 돌아올 23장짜리 인프라 지도가 필요한 신입~주니어 개발자, 그리고 15장 하나만으로도 값어치를 뽑을 SRE·데브옵스 도입 고민 중인 팀 리더까지입니다. 마치며, 이 책의 가장 큰 미덕은 "넓게, 그러나 정확히 필요한 만큼"이에요. 쿠버네티스 마스터하려고 이 책 사면 실망합니다. 깊게 파는 책이 아니라 인프라라는 거대한 대륙의 전체 지도를 그려주는 책이거든요. 근데 지도가 있어야 어디를 깊게 파야 할지 알게 되죠. 5년 차인데도 "이걸 이제야 알았네" 싶은 순간이 계속 나왔고, 반대로 말하면 그동안 감으로 때우던 걸 이제 언어로 설명할 수 있게 됐다는 뜻이에요. 회의에서, 코드 리뷰에서, 장애 대응에서 인프라 얘기가 나올 때 더 이상 눈을 피하지 않게 됐습니다. 인프라, 이제는 도망 못 칩니다. 그리고 도망칠 이유도 없어졌고요. |
|
** 한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다. 역사적으로 보면 요즘만 그런 것은 아니겠지만, 채용과 관련된 이야기 중 좀 더 강조되어 이야기 하는 부분이 있다. 바로 신입은 뽑으려 하지 않고, 경력만 뽑으려 한다는 것이다. 사실 채용하려는 입장에서는 당연한 부분으로 보이긴 한다. 대상 인재에 대해 제대로 알지 못한 상황에서, 비어있는 상태로 하나씩 채우려면 얼마나 많은 시행착오를 거쳐야 할지 막막하기 때문이다. 그래서 시간이라는 비용을 지불하고 다양한 경험을 누적한 인재를 선호하는 것은 자연스러운 현상일 것이다. 물론 대학이나 정규 학습과정을 통해 얻는 지식의 깊이도 무시할 수는 없지만, 어디까지나 학문적인 부분은 학문적인 요소들로 가득차있다. 그것이 옳고 그름을 떠나 그렇게 되어 있다는 것이다. 학문적인 분야가 너무 실무 중심으로만 되어 있어도 문제이기 때문에 학교나 시대에 따라 그 비율은 다를 수 있으나 실무만으로 채워진 경우는 찾기 어렵다. 많은 실무 지식은 실제로 일하면서 겪게되는 경험이 많기 때문에, 그 경험을 토대로 많은 것을 누적하게 된다. 그런 지식이 한번씩 휘발되고, 다시 누적되기를 반복하지만, 이따금 리마인드 하고 싶을 때, 나는 책을 통해 그 부분을 메우곤 한다. 책 정보 표지는 상당히 스테디한 느낌을 준다. 그렇게 유행을 타거나 여러 키워드의 나열로 보이는 것이 아닌, 이 책의 모든 내용을 포괄하는 수식어와 함께 사전이라는 접미어를 붙여서 표현하였다. 이 책을 고르게 된 것도 인프라에 대한 지식을 어떤 것이든 다 전달하지 않을까 하는 생각에서 시작했는데, 이 책의 제목과 부제가 한 몫을 했다고 생각한다. - 정가: 33,000원(전자책 27,600원) - 분량: 576쪽 - 저자: 바바 도시아키 - 옮긴이: 김완섭 특징(1) 용량과 부하 관리 용량과 부하 관리 그 자체에는 어려운 부분도 많고, 사실 실제로 닥쳐야 와 닿는 부분이 많다고 생각되었다. 그래서 쉽게 읽히기는 어렵기도 하고, 읽혔다 하더라도 기억에 많이 남지 않을 것 같다. 하지만, 이 부분은 중요할 것 같아서 별도로 체크를 해 두었다. The Twelve Factor이다. 1. 코드 기반: 버전 관리되는 하나의 코드 기반을 가지고 여러 환경에 배포한다. 이 부분은 원칙에 관한 부분이기에 별도로 숙지해야, 문제를 예방하기에 좋다는 생각이 든다. 개발자로서 개발 원칙은 많이 알고 있지만, 이렇게 인프라 관리를 위한 원칙은 생소하여 인상적인 부분이었다. (2) 인터넷 URL을 구성하기 위해 각 구문을 어떤 요소로 채워져 있는지 쉽게 지나치는 편이 많다. 이런 것을 잘 안다고 하는 나조차도 Fragment는 생소하다. 그리고 ssh 접속할때야 사용했지만, password도 이 구성 요소 중 하나라는 생각을 이어서 하지는 못했었다. 이걸 잘 알고 있으면 나중에 각 요소별로 따져서 분석하기에도 좋다. 애초에 주소를 구성할 때도 효율적으로 할 수 있다. 그리고 well known port도 조금 나와 있는데, 이 부분도 알아두면 좋다.  그리고, 도메인 명 구조도 대부분의 경우는 그냥 도메인 업체에서 검색해서 하나 부여받고 사용하면 그만이지 않나 싶지만, 나의 도메인을 좀 더 확장해서 쓴다거나, 긴 이름으로 사용하려고 할 때 어느정도까지 쓸 수 있는지도 모르면 낭패를 볼 수 있기 때문에 이런 규칙은 중요하다. 또한 Top level 도메인 뿐 아니라 보통 4차레벨까지 있다는 것은 간과하기 쉬운데, 우리가 사용하는 도메인에 별 생각없이 사용해도 3차나 4차까지는 그냥 사용하는 수준임을 알고 있어야 편하다. 그리고 이 구조는 트리구조를 갖고 있어서, 1차부터(엄밀히 말하면 dot 부터) 시작하여 내가 가진 주소를 탐색하는 것임을 알고 있다면 효과적인 라우팅을 고민할수도 있을 것이다.  OSI 7계층에 대한 부분은 실무도 중요하지만, 대학교에서 교과과정으로도 쉽게 다루었던 부분이다. L2 스위치, L4 스위치 등의 단어도 실무에서는 쉽게 들을 수 있는데, 이것이 무슨 모델명인가 하고 생각할 수도 있다. 하지만 이 역시 OSI 7계층에 의한 레이어를 나타내는 부분이며, 어느 레이어에서 관리하여 이중화를 하고 있는지 알 수 있는 부분이다. 이것을 정확하게 알아야 장애든, 배포든 쉽게 핸들링 할 수 있기 때문에 용어도 개념도 모르면 실무가 어려워진다.  그리고 개발자로서 자주 맞닥뜨리는 부분이기도 한 HTTP 응답에 대한 상태코드도 중요하다. 쉽게 볼 수 있는 200 OK 뿐 아니라, 404에러는 에러로써 쉽게 볼 수 있는 부분이기도 하다. 그 외에도 다양한 오류코드가 있는데, 여기에서 언급한 코드만 미리 알아도 해당 부분에서 사용자에게 당혹감을 주지 않도록 할 수 있다. 이것을 간과하면 맞는 길 외에는 다른 오류의 상황에서 제대로 대응할 수 없게 되어 사용자의 경험을 매우 좋지 않도록 하게 된다. (3) HTTPS 단순 도메인을 구입해서 사용하는 수준이라면 인증서에 대한 생각을 못할 수 있다. 하지만, 진짜 운영하는 서비스를 계획중이라면 SSL 인증서는 필수이다. 안그래도 피싱이나 해킹 등의 다양한 보안사고가 잇따르고 있는데, 그 대열에 동참할수는 없지 않은가. 애초에 사용자가 이런 것에 대응도 되지 않은 사이트에 접근도 꺼려하게 된다. Let's encrypt가 유명해지기 전에는 인증서는 비용때문에 접근이 어려웠는데, 이제는 마음만 먹으면 쉽게 적용할 수 있다. 각종 클라우드를 사용하든, 개인 홈서버를 사용하든, 각 서비스에도 기본적으로 SSL 연동을 쉽게 할 수 있도록 되어 있기 때문에 기술적인 어려움은 없을 것이다. 하지만, 인증서의 개념 자체를 모르면 이야기는 다르다. 필요성도 모르고, 도입도 하지 않을 가능성이 높기 때문이다. SSL은 무엇인지, 그리고 얼마나 자주 갱신해야 하는 것인지 그 이유와 함께 파악해 놓으면 도움이 된다. (4) 운영 운영환경 구성시 나의 서비스를 다양한 고객에게 제공하는 경우들이 있다. 이 책의 비유를 빌자면, 백화점이나 쇼핑몰의 인프라라면, 그 안에 입점한 의류 매장이나 식품 매장 같은 각 점포가 테넌트에 해당한다는 것이다. 이 개념은 각 어카운트 개념으로도 볼 수 있다. 하나의 서버를 구성하며 테넌트를 제공하는 것을 멀티 테넌트 모델이라고 하는데, 이 부분이 개발 관점에서는 잘만 설계한다면 유용해 보인다. 대형 서비스를 제공하는 곳이 아니라면 멀티서버 관리에 대한 이슈가 있진 않기 때문이다. 요즘 AI 서비스를 사용하면서, 나역시 작은 서비스를 하나 만들고 있는데, 이 부분에 테넌트 모델을 적용했다. 이것을 모르고 사용했었는데, 개념적으로 알고 사용해야 나중에 취약한 부분에서 큰 손해를 입지 않을 것이기 때문에 이 부분을 유의해야 한다. 이 외에도 싱글 테넌트 모델 및 하이브리드 테넌트 모델이 존재한다. 각 필요에 따라 사용하면 된다.  서비스가 어느정도 자리를 잡으면 반드시 신경써야 하는 부분이 컴플라이언스이다. 애초에 모바일 앱 서비스라면, 각 스토어에 배포시 기본적으로 챙겨야 할 이용약관들이 있다. 그런 부분으로 이미 참여를 하고 있는 부분이겠지만, 그 외에도 다양한 컴플라이언스에 대응해야 한다. 특히 국가별, 지역별, 연령별 대응이 다르게 존재할 수 있기 때문에 중요하다. (5) 기타 이 부분은 좀 특이해서 꼽아보았다. 서버 주문에 관한 일정까지 고려해야 한다는 사실이다. 사실 요즘은 클라우드를 사용하는 케이스가 매우 많기 때문에 이 부분을 고려할 경우가 얼마나 되겠냐 하겠지만, 그럼에도 클라우드를 도입하는 것이 좋은지, 서버를 신규 구성하거나 증설하는 것이 좋은지에 대한 효율성을 따져보는 측면에서는 고려해야만 하는 영역이다. 이 부분이 특히 인상적이었던 사실은, 이론적인 것보다 좀 더 실무적인 부분을 챙겨주는 느낌이 들어서이다. 물론 이 책이 번역서이고, 원서 그대로 차용한 부분으로 보이기 때문에, 아마 국내 사정으로 보면 다를 수 있겠지만, 어느정도는 참고할만하다고 생각한다. 각 단계별로 어떤 것들이 있는지는 알아야 하기 때문이다.  그 외에도 모든 내용의 끝에 나와있는, 함께 읽으면 좋은 장에 대한 부분이 마음에 들어서 가져왔다. 지금 보고 있는 내용이 단독으로 끝나는 것이 아니라, 다른 부분들과 연결되어 있음을 알 수 있다. 혹시나 내가 이해가 덜 가거나, 아니면 다른 부분으로 생각을 확장하고 싶다면, 이 부분을 참고해서 찾아가면 좋다. 이 책을 추천하고 싶은 독자- 웹, 모바일 등의 서비스를 제공하고 있는 회사의 담당 직원 또는 대표 - 신규 서비스를 만들기 위해 계획 또는 작업 중인 개인(개발자) - 인프라 전반에 관심있는 취업 준비생 - 나의 지식을 점검해보고자 하는 실무 관련 담당자 총평AI를 이용한 개발이 발달하며 나의 지식이 좀 부족하더라도 이제는 쉽게 웹 서비스 및 모바일 서비스를 만들 수 있는 시대가 되었다. 나 역시도 커서AI를 구독중임과 동시에 코덱스를 간간히 구독하며 나의 생각을 코드화하는 것 뿐 아니라 서비스로 만드는 것에 관심을 갖게 되었고, 실제로 작게나마 서비스를 운영하기 시작했다. 이것까지는 어렵지 않았지만, 문제는 그 다음이었다. 각종 인프라에 대한 부분은 AI 개발로 쉽게 도움받기 어려웠고, 그래서 확장성 부분에서는 두려움이 올라갔다. 결국 이 책을 찾게 되었고, 어느정도는 해소가 되는 부분이 있었다. 사전적인 특성을 가진 책이기 때문에 모든 것을 상세히 다루지는 않고 있지만, 적어도 관련 키워드나 원리원칙들은 알 수 있었다. 최소한 내가 알고 있는 지식이 어떤 것인지, 부족한 부분은 어떤 영역인지 채워가는데에도 도움이 된다. 나와 비슷한 고민을 하고 있는 누군가에게 이 책을 추천한다. AI 개발 너머에 있는 인프라의 장벽을 낮춰주는 도우미 |
|
IT 인프라를 처음 공부하는 사람도 전체 흐름을 이해할 수 있도록 기초부터 클라우드, 가상화, 컨테이너, 보안, 로깅, DevOps까지 폭넓게 다루는 책입니다. 단순히 개념만 설명하는 것이 아니라 Docker를 활용한 실습도 함께 제공해 이론과 실무를 자연스럽게 연결해 학습할 수 있었습니다. 특히 AI 개발이나 백엔드 개발을 준비하는 분이라면 서비스가 실제로 운영되는 인프라의 구조를 이해하는 데 많은 도움이 될 것입니다. 분량은 적지 않아 처음에는 다소 부담스러울 수 있지만, 필요한 내용을 다시 찾아보며 활용하기 좋은 참고서라는 점이 큰 장점입니다. 인프라를 어디서부터 공부해야 할지 고민하는 개발자와 취업 준비생에게 추천하고 싶은 책입니다. ※ 한빛미디어 서평단 '나는 리뷰어다' 활동을 통해 도서를 제공받아 직접 읽고 작성한 리뷰입니다. |
|
"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다." https://www.hanbit.co.kr/store/books/look.php?p_code=B3616948053 누구나 이해하는 클라우드 인프라 지식 사전 - 한빛+ 개발자가 알아야 할 신뢰성, 성능, 보안, 운영의 핵심 원리 www.hanbit.co.kr 인프라 관련된 책은 항상 손이 가는것 같다. 많은 것들이 추상화되면서, 사용자는 편해지졌지만 개발자는 모르는 것이 많아졌다. 이 책과 다른 책의 차이점은 이 책은 다양한 개념들을 모두 알려주려고 한다는 것이다. 깊이보다는 넓게 알려준다. 나는 조금 더 궁금한 부분은 AI 와 대화하면서 더 알아갔다.  지은이의 말에도 이 책은 지식 사전이라고 언급하고 있다. 어떤 문제를 해결하기 위해서는 어떤 지식이 필요한지를 알아야한다. AI 에게 그냥 물어봐도 아주 잘 대답해주지만, AI 에게 내가 알고 지식을 조금 더 넣어 물어보면 더 좋은 대답을 얻을 수 있다. 내가 어떤 것이 있는지를 알고 있는지가 정말 중요하다고 생각한다. 그런 의미에서 이 책 아주 많은 도움이 되었다.  아키텍처 책이든, 보안 책이든, 자격증 책이든 다양한 책을 읽다보면 유용성, 가용성 등등 ~~성 하는 용어를 많이 언급한다. 처음 공부할 떄는 그냥 귀찮네하고 넘겼지만, 지금 되돌아보면 이것만큼 중요하게 고려해야하는 사항이 없는 것 같다.  저자는 가치라는 개념이 ~~성으로 나타났고, 서버의 입장에서는 유용성과 안정성에 대해 중요하게 이야기한다. - 유용성 : 생산성을 높이는 기능이나 불가능한 것을 가능하게 만드는 기능을 제공하는 것 - 안전성 : 사용자가 안심하고 신뢰할 수 있는 환경을 제공하는 것 최근에는 오래된 시스템이 너무 느려서 속도를 개선하기 위한 작업을 하고 있다. 어디서 병목이 걸리는지 찾고 어떻게 해결하면 좋을지 책을 보면서 참고 했다.    개발하면서 어려운 것 중 하나가 다양한 것들을 고려해야한다는 것이다. 그래서 이 책의 내용을 체크리스트로 활용했다. 각 내용이 길지 않고 핵심만 적어줄려고 했기 때문에 이렇게 사용하기 좋은 것 같다. 배포/릴리즈 관련된 부분 체크리스트에 대한 이야기가 나온다. 안심할 수 있는 상태를 만들어야하는데, 시스템이 복잡할수록 시스템으로 모두 커버하기엔 비효율적이라고 한다. 품질과 신뢰성을 뒷받침하는 수단으로 체크리스트와 리뷰의 중요성을 언급한다. 먼가를 개발할 때 여러가지 체크리스트를 만들면서 최종적으로 점검하는데, 다른 곳에서도 이렇게 한다는 것을 보니 내가 하는 방법이 틀리지 않았구나 하고 생각해볼 수 있었다.   기술적인 문제 외에 어떻게 운영하는지 등에 대한 내용도 많이 나온다. 마지막엔 취업에 대한 이야기도 한다. 취업을 위해서는 어떻게 공부해야하는가?   취업뿐만이 아니라 일반적인 공부에서도 동일하다.
가장 기초적인 것이지만 지루하다. 그러나 막상 공부하고 나면 시야가 많이 달라져 있을 것이다. |
|
한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.  개발자는 코드를 만들지만, 사용자는 운영되는 서비스를 사용한다 처음 백엔드 개발을 시작했을 때는 요구사항에 맞는 기능을 구현하고, 유지보수가 쉬운 코드를 작성하는 것이 개발자의 가장 중요한 역할이라고 생각했습니다. 하지만 실무에서 여러 외부 시스템을 연동하고 운영 중 발생하는 문제들을 겪으면서, 코드만 잘 작성한다고 해서 서비스가 안정적으로 동작하는 것은 아니라는 점을 알게 되었습니다. 애플리케이션에서 오류가 발생하더라도 실제 원인은 서버나 네트워크, 외부 시스템에 있을 수 있었기 때문입니다. 처음에는 문제가 발생하면 애플리케이션 로그와 제가 작성한 코드부터 확인했습니다. 그러나 코드에는 문제가 없는데도 요청이 실패하거나 응답이 늦어지는 상황을 겪으면서, 코드가 실행되는 환경을 이해하지 못하면 문제를 해결하는 데 한계가 있다는 것을 체감했습니다. 결국 사용자는 개발자가 작성한 코드를 직접 사용하는 것이 아니라, 서버와 네트워크, 데이터베이스 등 여러 요소가 함께 동작한 결과인 서비스를 사용합니다. 아무리 좋은 코드를 작성했더라도 실제 환경에서 제대로 동작하지 않는다면 사용자에게는 실패한 기능과 다르지 않습니다. 이 책을 읽으면서 백엔드 개발자는 기능을 구현하는 것뿐만 아니라, 자신이 만든 기능이 실제 환경에서 안정적으로 제공될 수 있는지까지 살펴봐야 한다는 점을 다시 생각하게 되었습니다. 클라우드는 인프라를 없앤 것이 아니라, 보이지 않게 만들었다 처음에는 AWS와 같은 클라우드 서비스를 이용하면 서버와 데이터베이스를 빠르게 만들 수 있고, 필요한 기능도 관리형 서비스로 제공되기에, 클라우드를 사용하면 인프라에 대한 깊은 지식이 없어도 서비스를 만들 수 있다고 생각했습니다. 하지만 클라우드가 서버와 네트워크를 없앤 것은 아니었습니다. 개발자가 직접 관리해야 하는 영역을 줄이고, 복잡한 부분을 보이지 않게 만들어 주었을 뿐이었습니다. 화면에서는 간단하게 설정할 수 있어도, 그 안에서는 여전히 운영체제가 동작하고 네트워크를 통해 요청과 응답이 오갑니다. 저도 업무에서 여러 클라우드 서비스를 사용하면서 각각의 설정 방법에는 익숙해졌지만, 왜 이런 구성이 필요한지 또는 내부적으로 어떤 원리로 동작하는지까지는 명확하게 설명하지 못할 때가 있었습니다. 이 책을 읽으면서 클라우드를 잘 사용한다는 것은 많은 서비스의 이름과 설정 방법을 아는 것이 아니라, 각 서비스가 어떤 문제를 해결하기 위해 존재하는지 이해하는 것에 가깝다는 생각이 들었습니다. 모든 지식을 외울 수는 없어도, 어디를 봐야 하는지는 알아야 한다 인프라는 서버, 네트워크, 운영체제, 데이터베이스, 보안 등 다뤄야 할 범위가 매우 넓습니다. 백엔드 개발자가 이 모든 영역을 전문가 수준으로 이해하는 것은 현실적으로 어렵다고 생각합니다. 저도 업무에서 S3, EventBridge 등 AWS의 여러 서비스와 인프라 관련 용어를 접해 왔지만, 알고 있는 지식이 대부분 사용 경험을 통해 단편적으로 쌓여 있었습니다. 새로운 문제가 생기면 정확한 원리를 바탕으로 접근하기보다, 이미 비슷한 문제를 해결한 사람의 기록부터 찾아보는 경우가 많았습니다. 이 책은 하나의 주제를 깊게 설명하기보다는 인프라 전반의 개념을 넓게 다루고 있습니다. 덕분에 그동안 따로 알고 있던 기술들이 전체 시스템 안에서 어떻게 연결되는지를 정리하는 데 도움이 되었습니다. 한 권의 책을 읽었다고 해서 모든 문제를 해결할 수 있는 것은 아닙니다. 하지만 적어도 낯선 문제가 생겼을 때 무엇을 공부해야 하고, 어떤 키워드로 찾아봐야 하는지를 아는 것만으로도 문제를 해결하는 속도는 달라질 수 있다고 생각합니다. 그런 의미에서 이 책은 모든 내용을 외우기 위한 책이라기보다, 필요할 때 다시 찾아보고 다음 공부의 방향을 잡을 수 있는 지식 사전에 가까운 책이라고 느꼈습니다. 결론이 책은 특정 클라우드 서비스의 사용 방법을 깊게 설명하는 책보다는 서버와 네트워크, 운영체제, 보안, 모니터링 등 인프라 전반의 개념을 폭넓게 이해할 수 있도록 도와주는 책에 가깝습니다. 특히 실무에서 여러 기술을 접해 왔지만 각각의 지식이 따로 흩어져 있다고 느꼈던 저에게, 인프라의 전체적인 구조를 정리할 수 있는 계기가 되었습니다. 이미 알고 있다고 생각했던 개념도 다시 살펴보면서, 제가 원리까지 이해하고 있었는지 돌아볼 수 있었습니다. 앞으로는 요구사항에 맞는 기능을 구현하는 것에 그치지 않고, 장애와 성능 저하, 외부 시스템의 실패까지 고려할 수 있는 개발자가 되고 싶다는 목표가 생겼고, 이를 위해 문제가 발생한 뒤에 대응하는 것뿐만 아니라 문제가 생길 가능성을 미리 예상하고 대비하는 습관도 갖추려고 합니다. 그런 의미에서 이 책은 클라우드 인프라를 처음 공부하는 분들뿐만 아니라, 실무에서 클라우드를 사용하고 있지만 기반 지식을 다시 정리하고 싶은 백엔드 개발자에게도 도움이 될 수 있는 책이라고 생각합니다. 마지막으로 책 구매 링크를 남겨드리면서 글을 마무리하겠습니다 : ) |
|
"한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."
이번에 읽은 책은 《누구나 이해하는 클라우드 인프라 지식 사전》입니다. (바바 도시아키 지음, 김완섭 번역, 한빛미디어, 2026) 로컬에서 스프링 프로젝트 돌릴 때는 문제가 없었는데, AWS에 배포하고 나서부터 이상하게 막히는 부분이 많았습니다. VPC 설정 하나 잘못돼서 서비스가 안 열리는데, 대시보드 영문 버튼들 앞에서 며칠을 검색만 한 적도 있었습니다. 인프라에 대해서 어느 정도 안다고 생각했는데, 막상 부딪혀보니 아는 것과 다루는 것 사이 간극이 생각보다 컸습니다.
이 책을 받았을 때는 예전에 읽었던 《시작! AWS》처럼 EC2 만드는 법, S3 권한 설정 같은 서비스별 사용법 위주 책일 거라 예상했는데 처음부터 방향이 달랐습니다. 로드밸런서 얘기를 하기 전에 왜 부하 분산이 필요한지, 수평 확장과 수직 확장이 뭐가 다른 지부터 짚고 넘어갑니다. 클라우드 DB 얘기하기 전에 디스크 I/O와 메모리 관계를 먼저 설명하는 식이라, 이름은 계속 바뀌어도 밑바탕은 안 바뀐다는 걸 계속 확인시켜 줬습니다. 이 책에서 특히 좋았던 건 각 챕터가 끝날 때마다 '함께 읽으면 좋은 장'을 알려준다는 점입니다. 예를 들어 수평 확장 챕터를 읽으면 라운드 로빈 같은 분산 알고리즘부터, DNS·HTTP·인터넷 같은 네트워크 기본 지식, 리눅스에서 용량을 확장하는 간단한 설정 예시까지 이어보라고 안내합니다. 상태 정보를 유지하는 스테이트풀(stateful) 대신 스테이트리스(stateless)를 쓰는 이유, 클라우드에서 빠질 수 없는 가상화와 컨테이너, 멀티 테넌시 모델까지 연달아 읽다 보면 개념 하나가 왜 다른 개념과 묶여야 하는지 자연스럽게 잡혔습니다.
개인적으로 알차게 읽은 챕터는 3-2-1 백업 전략과 관찰 가능성(observability)이었습니다. 책에서는 이 원칙이 왜 필요한지 배경부터 설명해 줘서 암기가 아니라 실무에서 왜 중요한지 이해가 됐습니다. 서비스 초기 단계에서 적용하면 좋을 감시·모니터링 포인트 5가지 중에서는, 무턱대고 알림을 다 켜두지 말고 '강한 알림'은 최소화하면서 담당자와 대응 방법을 미리 정해두라는 조언이 가장 실용적으로 느껴졌습니다. 포스트모템(사후 분석) 챕터도 비슷했는데, 장애가 끝나면 끝이 아니라 회고를 통해 시스템을 더 견고하게 만드는 과정이라는 걸 책을 통해 제대로 배웠습니다. 여기에 더해 보안 업데이트를 놓치지 않고 적용하는 원칙이나, 평소 신경 쓰지 않았던 메일의 구조, 저자의 실무 경험을 바탕에 둔 GDPR과 개인정보보호법 같은 컴플라이언스까지 다루는 걸 보니, 다루는 범위가 생각보다 훨씬 넓었습니다.
 23장이라는 분량에 네트워크, OS, 미들웨어, 보안, 법률 컴플라이언스까지 담다 보니 한 주제를 깊게 파고들지는 못합니다. 쿠버네티스 챕터를 읽으면서 실전 설정값이나 코드 예제를 더 보고 싶었는데, 이론 설명하고 다음 장으로 바로 넘어가서 아쉬운 순간이 몇 번 있었습니다. 코드는 어느 정도 짜지만 배포하고 나면 뭐가 어떻게 돌아가는지 감이 없는 사람한테는, 이 책이 지도 역할을 잘해줬습니다. 취업 준비하면서 인프라 개념을 체계적으로 정리하고 싶은 분, 클라우드 환경에 서버를 막 올려봤는데 기초가 부족하다고 느끼는 분한테 추천합니다. #누구나이해하는클라우드인프라지식사전 #클라우드인프라 #개발 #DevOps #SRE #운영 #인프라기초 #한빛미디어 #나는리뷰어다 #서평 |
|
제목은 클라우드 인프라 지식사전이지만, 다 읽고 난 뒤의 느낌은 단순한 클라우드 서비스 안내서가 아니었습니다. 특정 클라우드 vendor의 콘솔 화면이나 사용법을 다루기보다는, 현대 컴퓨터 시스템 분야 전반을 넓게 아우르는 시스템 종합 요약서에 가깝습니다. 개인적으로 박사과정 연구분야가 분산 시스템쪽이었고, 현재도 시스템 분야 연구를 인더스트리에서 이어나가고 있어서 이런 책을 보면 반가운 것 같습니다 :) 이 책에서는, 서버, OS, 네트워크 같은 하위 레이어부터 시작해 가용성, 시스템 성능지표 및 튜닝, 관찰 가능성(Observability), Site Reliability Engineering (SRE), 데이터센터, 보안, 그리고 관련 법령에 이르기까지 시스템을 구성하는 대부분의 주제를 두루 훑어봅니다. 말 그대로 필요할 때 찾아보는 지식사전 본연의 역할에 충실한 구성이라 생각합니다. 다만 다루는 범위가 넓다 보니, 책을 접하는 방식에 따라 느껴지는 난이도나 활용도가 꽤 달라질 수 있는 책이기도 합니다. 이번 글에서는 이 책을 읽을 때 알아두면 좋은 독법과, 현업 개발자 및 면접 준비생 입장에서 어떻게 활용하면 좋을지 개인적인 생각을 적어봅니다. 추천하는 독서법: 모르는 부분은 가볍게 넘어가도 괜찮다 앞서말했듯, 이 책은 다루는 스펙트럼이 매우 넓습니다. OS와 네트워크의 하부 구조부터 Docker, Kubernetes 같은 컨테이너 생태계, 그리고 Observability와 SRE의 운용 철학까지 한 권에 담겨 있습니다. 그러다 보니 읽다 보면 특정 장에서 갑자기 심도 깊은 개념이나 세부적인 동작 원리가 훅 들어오는 구간을 만나게 됩니다. 만약 이 분야를 처음 접하는 입문자라면, 갑작스러운 깊이에 막혀 완독을 포기하고 싶은 생각이 들 수도 있습니다. 하지만 이 책을 읽을 때는 "모든 내용을 완벽히 이해하겠다"는 욕심을 내려놓는 것을 추천합니다. 이해가 잘 안 가는 세부적인 구현이나 깊은 내용이 나오더라도 '이런 개념이 있구나' 정도로 가볍게 넘어가며 교양서를 읽듯 읽어나가는 편이 훨씬 유익합니다. 이 책의 가장 큰 가치는 특정 기술 하나를 깊게 파고드는 데 있는 것이 아니라, 시스템 전체를 한눈에 둘러볼 수 있는 시야(Bird's-eye view)를 제공한다는 점에 있습니다. 전체적인 지도의 틀을 그려둔 뒤, 나중에 필요할 때마다 해당 파트를 다시 찾아보며 하나씩 메꿔나가는 식으로 활용할 때 이 책의 진가가 발휘된다고 생각합니다. 이 책에서 제공하는 내용보다 더 깊은 스터디가 필요하면, 해당 전문서적이나 논문등을 추가로 찾아보면 되니까요. 현업 개발자 관점: 내 코드 밖의 시스템 이해하기 현업에서 개발을 하다 보면 자연스럽게 자신이 담당하는 특정 영역(예: API 서비스, 백엔드 로직, 데이터베이스 등)에 깊게 파고들게 됩니다. 물론 자신의 분야를 전문적으로 다루는 것도 중요하지만, 내가 하는 일이 회사 전체 서비스 생태계에서 어떤 위치를 차지하고 어떤 인프라 위에서 돌아가는지 놓치기 쉽습니다. 이 책은 개발자에게 자신이 다루는 레이어 너머의 시스템 전체가 어떻게 맞물려 돌아가는지 조망할 수 있는 맥락을 제공합니다. 내가 만든 서비스가 어떤 경로를 거쳐 사용자에게 전달되는지뿐만 아니라, 보안, 백업, Observability, SRE 등 다른 부서가 관리하는 시스템들과 내 코드가 기존 인프라 안에서 어떤 연관성을 갖는지 이해할 수 있게 해줍니다. 결국 전체적인 시스템의 흐름과 팀 간의 연결고리를 파악하게 되면, 단순한 기능 구현을 넘어 "내 일이 전체 시스템에 어떤 영향을 미칠까?"를 고려하게 됩니다. 이는 타 부서나 동료들과 협업할 때 원활하게 공통의 언어로 소통하는 데도 큰 도움이 됩니다. 그런 점에서 현업 개발자에게 시야를 확장해 주는 훌륭한 길잡이가 되어 줄 것이라 생각합니다. 면접 대비 관점: 시스템 디자인(System Design) 인터뷰의 기초 체력 최근 개발자 채용 과정에서 시스템 디자인(System Design) 면접의 비중이 점점 더 커지고 있습니다. 한국에서의 동향은 잘 모르지만, 미국 테크인터뷰에서 처음 스크리닝 이후, 4~5시간에 걸쳐서 진행되는 Virtual On-site(Full-loop) 면접에선 코딩 테스트와 함께 시스템 디자인 라운드를 거의 필수적으로 거치게 됩니다. 사실 이 책 한 권을 읽었다고 해서 바로 시스템 디자인 인터뷰를 완전히 준비할 수 있는 것은 아닙니다. 실전 인터뷰에서는 특정 요구사항에 맞춰 아키텍처를 직접 설계하고 트레이드오프(Trade-off)를 논의해야 하기 때문입니다. 하지만 이 책은 시스템 디자인 인터뷰를 치르기 위해 반드시 갖춰야 할 기초 체력을 다지는 데 매우 유용합니다. 가용성(Availability), 스케일링(Scale-out/Scale-up), 병목 지점 제어, 캐시, 관찰 가능성(Observability) 등 면접에서 다루는 주요 개념들의 전반을 아우르고 있기 때문입니다. 전체적인 시스템의 구성 요소들이 어떻게 연결되어 동작하는지 기본 뼈대를 세워두면, 실전 시스템 디자인 문제를 접했을 때 훨씬 수월하게 논리를 펼쳐나갈 수 있다 생각합니다. 총평 및 추천 대상 "누구나 이해하는 클라우드 인프라 지식사전"은 단 하나의 주제를 깊게 다루는 전문서라기보다는, 모던 컴퓨터 시스템이라는 생태계의 전체 지도를 펼쳐 보여주는 길잡이 같은 책입니다. 책장에 두고 필요할 때마다 발췌해서 읽거나, 주기적으로 전체 흐름을 점검하는 용도로 활용하기에 적합합니다. 다음과 같은 분들에게 추천하고 싶습니다.
전체 시스템의 구조가 머릿속에 잘 그려지지 않거나, 내 코드가 작동하는 인프라 환경의 큰 그림을 보고 싶다면 가볍게 일독해 보시기를 권합니다. --- *한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다. |
이번에 리뷰할 책은 "누구나 이해하는 클라우드 인프라 지식사전" 입니다.|
📚 한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다 프론트엔드 개발을 하면서 API, Docker, 캐시, 배포, 성능 최적화를 다루는 일은 많았지만, '왜 이렇게 해야 하는가'를 시스템 관점에서 설명하기는 어려웠습니다. 이 책은 서버, 네트워크, 운영체제, 컨테이너, 클라우드, DevOps, SRE를 하나의 흐름으로 연결해 주면서 지금까지 단편적으로 알고 있던 개념들을 하나의 그림으로 정리해 준 책이었습니다. 읽으면서 특히 인상 깊었던 점은, • TanStack Query의 `staleTime`을 HTTP 캐시와 같은 관점에서 이해하게 된 것 • Docker가 단순한 "환경 맞추기"가 아니라 시스템 계층을 고정하는 기술이라는 점 • 성능 최적화는 감이 아니라 측정과 병목 분석에서 시작해야 한다는 원칙 • 배포(Deploy)와 릴리스(Release)는 서로 다른 개념이며, 운영은 배포 이후부터 시작된다는 사실 무엇보다 "기술을 사용할 줄 아는 것"과 "기술을 이해하는 것"의 차이를 다시 생각하게 되었습니다. 앞으로는 새로운 기술을 배울 때도 사용법보다 왜 존재하는지, 어떤 문제를 해결하는지, 시스템에서 어떤 역할을 하는지를 함께 고민하는 개발자가 되고 싶습니다. 프론트엔드 개발자이지만 더 넓게는 백엔드와 인프라까지 이해하며, 안정적인 서비스를 만드는 엔지니어로 성장해 나가고 싶습니다. |
