[26년 독후감 15] 누구나 이해하는 클라우드 인프라 지식 사전 : “You build it, you run it”

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

📖 책 정보

• 책 제목: 누구나 이해하는 클라우드 인프라 지식 사전
• 저자: 바바 도시아키
• 출판 연도: 2026년 (2026년 6월 15일 출간)
• 장르: IT · 클라우드 인프라 · 서버/네트워크 · 백엔드 개발 · DevOps/SRE

---

❓ 책을 고른 이유 (물음표)

나는 백엔드 개발 → 클라우드 → 안정적인 서비스 운영 → 스타트업 CTO로 성장하는 것을 장기적인 목표 중 하나로 생각하고 있다. 현재 AWS와 클라우드에 대한 기본적인 개념은 알고 있지만 서비스가 실제로 어떻게 운영되고 왜 이러한 기술들이 필요한지에 대한 깊이 있는 이해는 아직 부족하다고 느끼고 있다.

이 책은 단순히 AWS 서비스의 사용법을 설명하는 것이 아니라 '왜 이러한 인프라 기술이 필요한가', '서비스는 어떤 원리로 동작하는가'를 중심으로 설명해 줄 것 같아 더욱 흥미를 느꼈다. 또한 목차를 살펴보니 서버, 네트워크, 운영체제, 컨테이너, 클라우드, 모니터링, DevOps, SRE, 보안 등 백엔드 개발자가 알아야 할 핵심 주제를 하나의 흐름으로 다루고 있어 마치 백엔드 개발자 로드맵을 따라가는 느낌이었다.

특히 최근 프로젝트를 진행하면서 서비스 운영과 인프라에 대한 중요성을 점점 체감하고 있었고 채용공고에서도 DevOps, SRE, 플랫폼 엔지니어링과 같은 키워드를 자주 접하면서 해당 분야에 대한 관심이 더욱 커졌다.

이번 기회를 통해 이미 알고 있는 개념은 다시 한번 체계적으로 정리하고 부족했던 인프라 지식을 보완하며 앞으로 직접 프로젝트에 적용할 수 있는 아이디어와 실무적인 관점을 얻고 싶다.

---

📚 독서 과정

• 읽은 기간: 2026.07.06 - 2026.07.21

목차 일부와 용어집

---

✍️ 책 내용 정리

 

 

 

이 책은 AWS나 특정 클라우드 서비스의 사용법을 알려주는 책이라기보다 애플리케이션이 실제 서비스로 동작하기 위해 필요한 기반과 운영 원리를 폭넓게 설명하는 책이다. 서버, 네트워크, 운영체제, 컨테이너처럼 익숙한 기술부터 가용성, 관찰 가능성, DevOps, SRE, 릴리스 엔지니어링처럼 실무에서 자주 접하게 되는 개념까지 하나의 시스템 안에서 연결해 보여준다.

책을 읽으며 가장 크게 느낀 점은 클라우드 인프라를 공부한다는 것이 단순히 AWS 서비스 이름을 외우는 일이 아니라는 것이다. 결국 중요한 것은 사용자에게 가치 있는 기능을 안정적으로 제공하기 위해 시스템이 어떻게 구성되고 운영되는지를 이해하는 것이다.

정보 시스템은 사용자 가치를 위해 존재한다

정보 시스템은 개발자가 원하는 기능을 구현했다고 완성되는 것이 아니다. 실제 사용자가 시스템을 통해 가치를 얻을 수 있어야 존재 의미가 생긴다.

책에서는 사용자 가치를 크게 유용성과 안정성으로 나누어 설명한다.

• 유용성: 생산성을 높이거나 기존에는 불가능했던 일을 가능하게 만드는 것
• 안정성: 사용자가 서비스를 안심하고 신뢰하며 이용할 수 있게 하는 것

유용성은 주로 기능 요구사항으로 드러난다. 검색, 저장, 추천, 결제처럼 사용자가 직접 사용하는 기능이 여기에 해당한다. 반면 안정성은 비기능 요구사항으로 나타난다. 서비스가 끊기지 않는지, 응답이 충분히 빠른지, 사용자 정보를 안전하게 보호하는지, 사용자가 늘어나도 견딜 수 있는지와 같은 부분이다.

학생 프로젝트를 진행할 때는 기능 구현에 집중하기 쉽다. 회원가입이 되고, 데이터가 저장되고, AI 분석 결과가 출력되면 서비스가 완성됐다고 생각하기도 한다. 그러나 실제 서비스에서는 다음과 같은 질문까지 답할 수 있어야 한다.

• 서비스가 계속 정상적으로 동작하는가?
• 사용자가 필요할 때 이용할 수 있는가?
• 사용자가 늘어나도 처리할 수 있는가?
• 응답 속도가 충분히 빠른가?
• 데이터를 안전하게 보호하는가?
• 장기간 운영 가능한 비용과 구조를 갖췄는가?

이 질문들은 각각 신뢰성, 가용성, 용량, 성능, 보안, 지속성과 연결된다. 결국 기능 요구사항과 비기능 요구사항은 서로 경쟁하는 것이 아니라, 사용자 가치를 완성하는 두 축이다.

시스템을 계층 구조로 바라보기

애플리케이션은 혼자서 실행되지 않는다. 내가 작성한 코드 아래에는 라이브러리, 런타임, 운영체제, 네트워크, 서버와 같은 여러 계층이 존재한다.

예를 들어 TypeScript로 작성한 웹 애플리케이션을 실행한다고 생각해 보면 다음과 같은 계층을 거치게 된다.

애플리케이션 → 라이브러리 → 런타임 → 운영체제 → 네트워크 → 하드웨어

실제 시스템은 이처럼 단순한 직선 구조는 아니며 여러 계층이 복잡하게 의존한다. 그래도 계층 구조를 먼저 파악해 두면 장애가 발생했을 때 문제의 범위를 좁힐 수 있다.

브라우저에서 API 요청이 실패했다고 해서 반드시 백엔드 코드에 문제가 있는 것은 아니다. DNS 설정, TLS 인증서, 프록시, 네트워크 연결, 애플리케이션 프로세스, 데이터베이스 연결 중 어느 한 곳에서 문제가 발생했을 수도 있다. 시스템의 전체 구조를 모르면 보이는 코드만 수정하게 되지만, 계층을 이해하면 문제가 어느 경계에서 발생했는지 추적할 수 있다.

각 계층은 정해진 인터페이스를 통해 상호작용한다. API도 넓게 보면 계층 사이의 약속이다. 인터페이스가 유지된다면 내부 구현을 다른 기술로 교체할 수 있고, 이것이 호환성과 이식성으로 이어진다.

내 맥북에서 작성한 프로그램이 리눅스 서버에서도 실행될 수 있는 것은 런타임과 운영체제가 환경 차이를 중간에서 해결해 주기 때문이다. 컨테이너 역시 실행에 필요한 환경을 함께 묶어 이식성을 높이는 방법이다.

클라우드의 IaaS, PaaS, SaaS도 결국 시스템의 어느 계층까지 클라우드 사업자가 책임지는가에 따라 구분할 수 있다. 따라서 클라우드를 이해하려면 서비스 이름을 외우기 전에 시스템 계층과 책임 경계를 이해해야 한다.

You build it, you run it

책 전체를 관통하는 문장 중 하나는 **“You build it, you run it”**이었다. 자신이 만든 소프트웨어의 운영까지 책임져야 한다는 의미다.

이는 개발자가 모든 서버와 네트워크를 혼자 관리해야 한다는 뜻은 아니다. 자신이 만든 기능이 운영 환경에서 어떻게 동작하고, 사용자에게 어떤 영향을 주며, 장애가 발생했을 때 어떻게 발견하고 복구할 것인지까지 관심을 가져야 한다는 뜻에 가깝다.

개발팀과 운영팀의 벽을 허무는 DevOps 역시 이러한 관점에서 출발한다. 개발자는 코드를 배포한 뒤 책임이 끝나는 사람이 아니며, 운영자는 개발자가 넘긴 결과물을 수동으로 관리하기만 하는 사람도 아니다. 두 영역이 함께 사용자 가치를 책임져야 한다.

백엔드 개발자는 API가 정상 응답하는 것뿐만 아니라 다음 과정까지 이해해야 한다.

코드 작성 → 테스트 → 배포 → 릴리스 → 모니터링 → 장애 대응 → 개선

이 흐름을 경험해야 단순히 기능을 구현하는 개발자에서 안정적인 서비스를 운영할 수 있는 개발자로 성장할 수 있다.

고장은 예외가 아니라 전제다

개별 장비의 고장 확률을 0으로 만드는 것은 불가능하다. 서버가 몇 대 되지 않는 작은 시스템에서는 오랫동안 장애를 겪지 않을 수도 있지만, 이는 시스템이 완벽해서가 아니라 아직 운이 좋았을 가능성이 크다.

수백 대, 수천 대의 장비를 사용하는 환경에서는 발생 가능한 문제가 언젠가는 대부분 실제로 발생한다. 따라서 엔지니어링의 목표는 고장을 완전히 제거하는 것이 아니라, 고장이 발생해도 사용자 피해로 이어지지 않도록 설계하고 빠르게 복구하는 것이다.

이 관점에서 가용성을 서버의 업타임만으로 판단해서는 부족하다. 서버와 운영체제가 실행 중이어도 애플리케이션이 요청을 처리하지 못하거나, 데이터베이스에 저장할 공간이 없거나, 외부 네트워크와 통신하지 못한다면 사용자는 서비스를 이용할 수 없다.

따라서 가용성은 시스템 중심이 아니라 사용자 경험 중심으로 측정해야 한다.

웹서비스라면 대표적으로 다음 지표를 활용할 수 있다.

• 요청의 지연 시간
• 오류율
• 정상 응답 비율
• 일정 기간 동안 목표 수준을 만족한 시간

데이터 처리 시스템이라면 데이터 최신성, 누락률, 처리 정확도, 처리량 등이 더 중요할 수 있다. 즉 모든 시스템에 동일한 가용성 기준을 적용하는 것이 아니라, 그 시스템이 사용자에게 제공하는 가치에 맞는 지표를 정의해야 한다.

이러한 지표가 SRE에서 말하는 SLI, 즉 서비스 수준 지표로 이어진다. 서버가 살아 있는지를 확인하는 것에서 끝나는 것이 아니라, 사용자가 실제로 서비스를 정상적으로 이용할 수 있는지를 측정하는 것이다.

용량과 성능은 비슷하지만 다른 개념이다

용량과 성능은 자주 함께 언급되지만 구분해서 이해해야 한다.

용량은 시스템이 감당할 수 있는 전체 허용량이다. 단위 시간당 처리 가능한 요청 수, 저장 가능한 데이터의 양, 동시에 연결 가능한 사용자 수 등이 포함된다.

성능은 하나의 처리를 얼마나 빠르고 효율적으로 수행하는가에 가깝다. 웹서비스에서는 주로 요청부터 응답까지 걸리는 지연 시간으로 판단한다.

시스템 사용량이 허용량에 가까워지거나 도달한 상태를 포화라고 한다. 포화 상태에서는 요청이 지연되고 오류가 증가하며 예상하지 못한 동작이 발생할 수 있다. 따라서 실제 운영에서는 이론적 최대 용량을 모두 사용하는 것이 아니라, 갑작스러운 트래픽 증가와 장애 상황에 대응할 여유 용량을 남겨두어야 한다.

시스템 전체의 처리량은 가장 느린 컴포넌트에 의해 제한된다. 이 지점을 병목 지점이라고 한다.

예를 들어 애플리케이션 서버를 열 대로 늘려도 데이터베이스 한 대가 모든 요청을 감당하지 못한다면 전체 처리량은 개선되지 않는다. 반대로 데이터베이스가 충분히 빠른데 네트워크 대역폭이 부족하다면 CPU를 업그레이드해도 효과가 없다.

병목 지점을 다루는 대표적인 방법은 다음 세 가지다.

• 수평 확장: 동일한 역할을 하는 서버나 인스턴스의 수를 늘린다.
• 수직 확장: CPU, 메모리 등 개별 장비의 성능을 높인다.
• 성능 튜닝: 코드, 쿼리, 캐시, 설정 등을 개선해 자원을 효율적으로 사용한다.

핵심은 무작정 확장하는 것이 아니라 현재 병목이 어디에 있는지 먼저 측정하는 것이다.

성능 튜닝은 추측이 아니라 측정이다

성능 튜닝은 단순히 빠른 코드를 작성하는 활동이 아니다. 서비스와 아키텍처를 이해하고 부하 테스트를 통해 병목 지점을 찾은 뒤, 개선과 검증을 반복하는 과정이다.

책에서 제시하는 흐름을 정리하면 다음과 같다.

1. 서비스의 목적과 사용 방식을 이해한다.
2. 측정 대상과 목표를 정한다.
3. 시스템 아키텍처와 데이터 흐름을 파악한다.
4. 부하 테스트를 통해 병목 지점을 찾는다.
5. 한 가지 개선안을 적용한다.
6. 동일한 조건으로 다시 측정한다.
7. 결과를 비교하고 다음 가설을 세운다.

특히 기억에 남았던 원칙은 한 번에 하나씩 변경하라는 것이다. 여러 설정과 코드를 동시에 바꾸면 결과가 좋아지거나 나빠져도 무엇이 원인인지 알 수 없다. 개선안끼리 서로 방해할 가능성도 있다.

또한 인터넷에서 발견한 성능 튜닝 방법을 그대로 적용해서도 안 된다. 어떤 최적화 방법은 특정 병목과 환경에서만 효과가 있기 때문이다. 다른 서비스에서 Redis 캐시를 도입해 성능이 좋아졌다고 해서 내 서비스에서도 반드시 같은 결과가 나오는 것은 아니다.

따라서 성능 튜닝의 핵심은 다음 문장으로 정리할 수 있다.

먼저 측정하고, 데이터를 바탕으로 가설을 세우며, 하나씩 검증한다.

이 방식은 감이나 운에 의존하지 않는다. 시스템 구조에 대한 이해와 논리적 사고, 측정 경험이 쌓일수록 반복적으로 좋은 결과를 만들 수 있다.

IaC는 인프라를 소프트웨어처럼 관리하는 방법이다

Infrastructure as Code, 즉 IaC는 서버, 네트워크, 데이터베이스, 컨테이너 등 인프라 구성을 코드로 정의하고 관리하는 방법이다.

IaC의 목적을 단순히 작업 자동화로만 이해해서는 부족하다. 코드로 관리하면 인프라에도 소프트웨어 개발의 장점을 적용할 수 있다.

• 동일한 환경을 다시 만들 수 있는 재현성
• 다른 프로젝트에서 활용할 수 있는 재사용성
• 변경 이력을 확인할 수 있는 버전 관리
• 변경 전에 검토할 수 있는 코드 리뷰
• 자동 테스트 및 CI/CD 연계
• 담당자의 수작업 실수 감소

특히 중요한 장점은 시간 절약보다 품질과 보안 수준을 일관되게 유지할 수 있다는 것이다.

다만 작은 프로젝트에서도 무조건 IaC를 도입해야 하는 것은 아니다. 도구를 배우고 관리하는 비용이 발생하기 때문이다. 여러 환경을 반복해서 구성하거나 여러 사람이 함께 인프라를 관리해야 할 때 IaC의 장점이 커진다.

캐시는 강력하지만 재사용 조건이 핵심이다

캐시는 처리 결과나 데이터를 저장해 두었다가 다시 사용하는 기술이다. 동일한 작업을 반복하지 않기 때문에 지연 시간과 서버 부하를 크게 줄일 수 있다.

캐시는 시스템 곳곳에서 사용된다.

• CPU와 메모리 내부의 캐시
• 데이터베이스 쿼리 결과 캐시
• 애플리케이션 서버의 데이터 캐시
• CDN의 콘텐츠 캐시
• 브라우저의 HTTP 캐시

캐시는 성능을 수십 배, 수백 배 높일 수도 있지만 잘못 사용하면 오래된 정보가 노출되거나 다른 사용자의 데이터가 전달되는 심각한 문제가 발생할 수 있다.

따라서 캐시를 적용할 때는 다음을 명확히 정해야 한다.

• 어떤 요청의 결과를 같은 데이터로 볼 것인가?
• 얼마 동안 재사용할 것인가?
• 원본 데이터가 변경됐을 때 어떻게 무효화할 것인가?
• 사용자별 데이터가 서로 섞이지 않는가?

HTTP 캐시에서는 주로 GET 요청의 응답을 재사용하며, 브라우저에 저장되는 프라이빗 캐시와 CDN 같은 중간 프록시에 저장되는 공유 캐시가 있다. 캐시가 실제로 적용됐는지는 브라우저 개발자 도구의 네트워크 탭과 HTTP 응답 헤더, CDN의 캐시 적중률 지표 등을 통해 확인할 수 있다.

프록시와 OODA 루프

프록시는 특정 컴포넌트 앞에서 요청을 대신 받아 처리하거나 전달하는 역할을 한다. 백엔드 시스템 앞에 배치된 리버스 프록시는 트래픽 분산, 캐시, HTTPS 종료, 보안 정책 적용 등의 역할을 할 수 있다. 반대로 포워드 프록시는 클라이언트를 대신해 외부 서버와 통신한다.

프록시를 이해하면서 느낀 점은 많은 인프라 기술이 완전히 새로운 기능을 만드는 것이 아니라, 기존 컴포넌트 사이에 계층을 추가해 책임을 분리하는 방식이라는 것이다.

OODA 루프는 관찰, 상황 판단, 의사결정, 행동을 빠르게 반복하는 의사결정 방식이다.

Observe → Orient → Decide → Act

중요한 것은 각 단계를 한 번 완벽하게 수행하는 것이 아니라 전체 순환 시간을 짧게 만들어 변화에 빠르게 대응하는 것이다. 이는 서비스 운영과도 잘 연결된다.

로그와 메트릭으로 상황을 관찰하고, 원인을 판단하고, 개선안을 결정하고, 배포한 뒤 다시 결과를 측정하는 과정이 하나의 OODA 루프가 된다.

인터넷과 네트워크를 이해해야 장애를 추적할 수 있다

인터넷과 웹은 동일한 개념이 아니다. 인터넷은 IP 프로토콜을 사용하는 여러 네트워크가 연결된 거대한 네트워크이고, 웹은 그 인터넷 위에서 제공되는 여러 서비스 중 하나다.

브라우저와 서버가 통신할 때 데이터는 네트워크 계층을 따라 이동한다. 송신 측에서는 상위 계층에서 하위 계층으로 내려가고, 수신 측에서는 다시 하위 계층에서 상위 계층으로 올라간다.

이 구조를 알고 있으면 장애 발생 시 어느 계층을 확인해야 하는지 판단할 수 있다. 케이블이나 무선 연결이 끊긴 것인지, IP 주소와 라우팅에 문제가 있는지, TCP 연결이 실패한 것인지, HTTP 요청이나 애플리케이션 로직에 문제가 있는지를 구분할 수 있다.

TCP는 연결을 맺고 데이터 손실 시 재전송하며 혼잡을 제어한다. UDP보다 정교하게 신뢰성을 보완하지만 연결과 상태 관리에 필요한 비용이 존재한다.

중요한 사실은 아무리 네트워크를 잘 설계해도 단절과 지연을 완전히 없앨 수 없다는 것이다. 따라서 애플리케이션은 네트워크 실패를 전제로 타임아웃, 재시도, 중복 요청 처리 등을 고려해야 한다.

네트워크 성능을 볼 때도 대역폭과 지연 시간을 구분해야 한다.

• 대역폭: 일정 시간 동안 얼마나 많은 데이터를 전송할 수 있는가
• 지연 시간: 데이터가 목적지까지 도달하고 돌아오는 데 얼마나 걸리는가
• 패킷 손실: 전송 과정에서 데이터가 얼마나 유실되는가
• 지터: 지연 시간이 얼마나 불규칙하게 변하는가

대역폭이 높아도 물리적 거리가 멀거나 네트워크 경로가 복잡하면 응답은 느릴 수 있다. 결국 네트워크 성능 역시 물리적 한계에서 자유로울 수 없다.

운영체제, 프로세스와 스레드

운영체제는 하드웨어와 애플리케이션 사이를 연결한다. 애플리케이션이 하드웨어 제조사나 물리적인 제어 방식을 직접 알지 않아도 파일, 메모리, 네트워크를 사용할 수 있도록 추상화한다.

애플리케이션은 시스템 콜을 통해 운영체제의 기능을 사용한다. Python이나 Go 같은 언어로 개발할 때 시스템 콜을 직접 작성하지 않더라도, 언어의 런타임과 라이브러리가 내부적으로 운영체제와 통신한다.

운영체제는 실행 중인 프로그램을 프로세스 단위로 관리한다. 프로세스마다 CPU 시간과 메모리 영역을 할당하며, 프로세스가 종료되면 사용하던 자원을 회수한다.

프로세스와 스레드의 핵심 차이는 메모리 공유 범위에 있다.

• 프로세스끼리는 기본적으로 메모리 영역이 분리된다.
• 같은 프로세스에 속한 스레드는 메모리를 공유한다.

스레드는 데이터를 쉽게 공유할 수 있지만, 동시에 같은 데이터에 접근하면서 경쟁 조건이나 동기화 문제가 발생할 수 있다. 반면 프로세스는 격리 수준이 높지만 프로세스 간 통신 비용이 더 필요하다.

백엔드 서버의 동시성 모델을 이해하려면 단순히 언어 문법뿐 아니라 운영체제가 프로세스와 스레드를 어떻게 관리하는지도 알아야 한다.

가상화, 도커와 쿠버네티스

가상화는 물리적인 컴퓨터 자원을 논리적으로 통합하거나 분리해 효율적으로 사용하는 기술이다. 여러 개의 디스크를 하나처럼 묶거나 하나의 물리 서버를 여러 가상 서버로 분리하는 것이 대표적이다.

가상화의 핵심 효과는 다음 두 가지다.

• 물리적 제약을 넘어 자원을 통합한다.
• 자원을 분할하고 격리해 효율성과 보안을 높인다.

도커는 애플리케이션 컨테이너를 만들고 공유하고 실행하기 쉽게 만든 대표적인 도구다. 이를 Build, Ship, Run으로 표현할 수 있다.

애플리케이션 코드와 실행에 필요한 환경을 컨테이너 이미지에 담아두면 개발 환경과 서버 환경의 차이를 줄일 수 있다. 이미지는 레지스트리에 저장하고, 필요한 환경에서 내려받아 컨테이너로 실행한다.

도커 컴포즈는 주로 한 호스트에서 여러 컨테이너를 함께 실행하는 데 사용한다. 반면 여러 호스트에 걸쳐 많은 컨테이너를 운영하려면 컨테이너 오케스트레이션 도구가 필요하며 대표적인 도구가 쿠버네티스다.

쿠버네티스에서는 하나 이상의 컨테이너를 포드 단위로 관리하고, 포드는 노드에서 실행된다. 클러스터의 전체 상태를 관리하고 지시하는 컨트롤 플레인과 실제 애플리케이션을 실행하는 데이터 플레인으로 구분할 수 있다.

쿠버네티스는 강력하지만 구성 요소가 많고 복잡하다. 따라서 단순히 유행하는 기술이라는 이유로 도입하기보다, 여러 서버와 컨테이너를 자동으로 배치하고 확장하고 복구해야 하는 요구가 있는지를 먼저 판단해야 한다.

클라우드를 안전하게 사용하는 세 가지 원칙

클라우드 서비스는 쉽게 생성할 수 있다는 점이 장점이지만, 그만큼 비용과 보안 사고도 쉽게 발생할 수 있다.

책에서 강조한 기본 원칙은 명확했다.

1. 과금 체계를 먼저 파악한다.
2. 자원의 정지와 삭제 방법을 미리 알아둔다.
3. 기본 설정을 비공개로 유지한다.

실습을 위해 만든 서버나 데이터베이스를 삭제하지 않으면 사용하지 않는 동안에도 비용이 발생할 수 있다. 저장소나 데이터베이스를 실수로 공개하면 개인정보나 인증 정보가 노출될 수도 있다.

비용 절감과 비용 최적화도 구분할 필요가 있다. 비용 절감은 사용자 가치나 안정성을 일부 포기하면서 지출 자체를 낮추는 것까지 포함한다. 반면 비용 최적화는 사용자 가치의 손실을 최소화하면서 불필요한 비용을 제거하는 것이다.

좋은 클라우드 운영은 무조건 가장 저렴한 구성을 선택하는 것이 아니라, 필요한 신뢰성과 성능을 만족하면서 낭비를 줄이는 것이다.

DevOps와 SRE의 중심에는 사용자 가치가 있다

DevOps는 개발 도구나 자동화 제품의 이름이 아니다. 개발과 운영 사이의 벽을 낮추고 사용자에게 가치를 더 빠르고 안정적으로 전달하기 위한 문화와 접근 방식이다.

SRE는 이러한 DevOps 원칙을 소프트웨어 엔지니어링으로 구현하는 대표적인 방법이다. 대규모 시스템이 성장할수록 운영 인력도 계속 늘어나는 문제를 해결하기 위해, 반복적인 운영 작업을 자동화하고 시스템의 신뢰성을 측정 가능한 지표로 관리한다.

SRE는 단순히 인프라 엔지니어의 다른 이름이 아니다. 다음과 같은 요소가 함께 포함된다.

• 신뢰성을 수치로 측정하는 지표와 목표
• 반복적인 운영 작업의 자동화
• 장애를 전제로 한 설계
• 개발팀과 운영팀의 협업 구조
• 모니터링과 관찰 가능성
• 장애 이후의 학습과 개선

무엇보다 DevOps와 SRE를 도입하는 것 자체가 목적이 되어서는 안 된다. 최종 목적은 사용자 가치다. 유명한 방법론과 도구를 사용하지 않더라도 사용자에게 더 빠르고 안정적으로 가치를 전달하려고 노력하다 보면 자연스럽게 비슷한 실천 방식에 도달할 수 있다.

배포와 릴리스는 다르다

책에서는 배포와 릴리스를 구분한다.

• 배포: 새로운 코드를 실행 환경에 배치하는 것
• 릴리스: 사용자가 새로운 기능을 실제로 사용할 수 있게 하는 것

코드가 서버에 배포됐더라도 피처 플래그로 기능을 비활성화해 두었다면 아직 릴리스된 것은 아니다. 이 둘을 분리하면 코드를 먼저 안전하게 배포한 뒤 일부 사용자에게만 기능을 공개하거나, 문제가 발생했을 때 기능만 빠르게 끌 수 있다.

릴리스 엔지니어링은 빠른 릴리스와 시스템의 신뢰성을 함께 달성하기 위한 기술과 프로세스다. 수작업을 자동화하면 실수를 줄일 수 있지만, 자동화했다고 결함이 사라지는 것은 아니다. 따라서 문제를 빠르게 발견하고 릴리스를 중단하거나 되돌릴 수 있어야 한다.

데이터베이스 변경에서는 특히 호환성이 중요하다. 예를 들어 컬럼을 즉시 삭제하기보다 다음과 같이 여러 단계로 나누는 것이 안전하다.

1. 애플리케이션에서 기존 컬럼 의존성을 제거한다.
2. 변경된 애플리케이션을 먼저 배포한다.
3. 더 이상 사용하지 않는 컬럼을 이후 배포에서 삭제한다.

새로운 컬럼으로 전환할 때도 기존 컬럼과 새 컬럼을 일정 기간 함께 처리하면 상위 버전과 하위 버전의 애플리케이션이 동시에 실행되는 상황에 대응할 수 있다.

결국 무중단 릴리스를 위해서는 코드뿐 아니라 세션, 데이터베이스 스키마, 데이터 상태의 호환성을 함께 고려해야 한다.

CI/CD와 GitOps

CI는 지속적 통합을 의미한다. 코드 포맷 검사, 린트, 정적 분석, 자동 테스트를 반복적으로 실행해 여러 개발자의 변경 사항을 지속적으로 통합한다.

CD는 배포 또는 전달 과정을 일상적으로 수행할 수 있도록 만드는 활동이다. 저장소에 특정 변경이 발생하면 빌드, 테스트, 배포가 자동으로 이어지도록 파이프라인을 구성할 수 있다.

GitOps는 코드 저장소를 시스템 상태의 단일 기준 정보로 두고, 운영 환경이 저장소에 정의된 상태와 일치하도록 관리하는 방식이다. 이 구조에서는 브랜치 전략과 운영 환경이 밀접하게 연결된다.

예를 들어 main 브랜치를 프로덕션 환경과 연결하거나, staging과 production 브랜치를 각각의 환경에 대응시킬 수 있다.

중요한 것은 CI/CD 도구 자체가 아니라 다음 질문에 답할 수 있는 구조를 만드는 것이다.

• 어떤 변경이 언제 배포됐는가?
• 테스트를 통과한 코드만 배포되는가?
• 문제가 발생하면 어느 버전으로 되돌릴 수 있는가?
• 배포 이후 이상을 빠르게 감지할 수 있는가?
• 운영 환경이 코드와 문서에 정의된 상태와 일치하는가?

릴리스 엔지니어링은 CI/CD만으로 완성되지 않는다. 모니터링, 관찰 가능성, 자동화, 데이터 호환성, 롤백 전략이 함께 작동해야 한다.

백엔드 개발자로 성장하는 방법

마지막 취업 파트는 현재 나에게 특히 현실적으로 다가왔다. 주니어 백엔드 개발자에게 깊은 인프라 경험까지 요구하는 경우는 많지 않지만, 아키텍처와 인프라를 적절히 이해하고 있다면 충분한 차별점이 될 수 있다. 리드급 엔지니어로 성장할수록 이러한 지식은 선택이 아니라 필수에 가까워진다.

책에서 제안한 학습 방법은 현재 사용하는 기술을 정확히 이해하는 것부터 시작한다.

어떤 기술을 사용하고 있다면 다음 질문에 답할 수 있어야 한다.

• 이 기술의 정확한 이름과 버전은 무엇인가?
• 시스템에서 어떤 역할을 담당하는가?
• 왜 이 기술을 선택했는가?
• 어떤 효과를 기대하고 있는가?
• 다른 대안은 무엇인가?
• 현재 방식의 장점과 한계는 무엇인가?
• 문제가 발생했을 때 어떻게 확인할 것인가?

그다음에는 자신이 담당하는 영역에서 한 계층 위와 아래로 시야를 넓혀야 한다.

백엔드 애플리케이션을 개발한다면 아래로는 런타임, 운영체제, 네트워크, 데이터베이스를 살펴볼 수 있다. 위로는 프론트엔드, 사용자 요청, 비즈니스 요구사항과 연결할 수 있다.

데이터 흐름을 따라 학습하는 방법도 유용하다.

브라우저 → DNS → CDN·프록시 → 웹 서버 → 애플리케이션 → 캐시 → 데이터베이스

개발 공정을 기준으로도 범위를 넓힐 수 있다.

요구사항 분석 → 설계 → 구현 → 테스트 → 배포 → 릴리스 → 모니터링 → 장애 대응

특정 기술을 사용하고 있다면 대체재를 비교해 보는 것도 좋은 공부가 된다. PostgreSQL을 사용한다면 MySQL과 어떤 차이가 있는지, Redis는 RDBMS와 어떤 문제를 다르게 해결하는지, 관리형 데이터베이스와 직접 운영하는 데이터베이스는 책임 범위가 어떻게 다른지 살펴볼 수 있다.

이러한 지식을 가장 효과적으로 연결하는 방법은 작은 서비스라도 직접 만들어 운영해 보는 것이다. 사용자를 받는 개인 프로젝트를 운영하면 책에서 외웠던 개념이 실제 문제로 나타난다.

도메인 연결, HTTPS 설정, 환경 변수 관리, 데이터베이스 마이그레이션, 로그 확인, 비용 관리, 장애 복구를 직접 경험하면서 비로소 “왜 이렇게 해야 하는가”를 이해하게 된다.

책 전체를 관통하는 핵심

이 책을 읽으며 클라우드 인프라는 개발과 분리된 별도의 영역이 아니라는 생각이 들었다. 코드는 인프라 위에서 실행되고, 인프라는 사용자가 서비스를 안정적으로 이용할 수 있도록 코드를 지탱한다.

책의 내용을 하나의 흐름으로 정리하면 다음과 같다.

사용자 가치 정의→ 기능·비기능 요구사항 설계→ 시스템 계층과 책임 경계 파악→ 가용성·용량·성능 목표 설정→ 측정과 모니터링→ 자동화된 배포와 안전한 릴리스→ 장애 대응과 지속적인 개선

결국 좋은 백엔드 개발자는 API와 비즈니스 로직만 구현하는 사람이 아니다. 자신의 코드가 어떤 환경에서 실행되고, 요청이 어떤 경로로 이동하며, 병목과 장애가 어디서 발생할 수 있는지 이해하는 사람이다.

그리고 더 나아가 사용자가 서비스를 계속 신뢰하고 이용할 수 있도록 시스템을 설계하고 운영하는 사람이 진정으로 서비스 전체를 바라보는 개발자라고 생각한다.

---

❗ 책을 덮으며 느낀 변화

이 책을 읽으며 클라우드와 백엔드 시스템에 대해 알고 있던 개념을 다시 정리할 수 있었고, 그동안 단편적으로 접했던 지식들이 하나의 구조로 연결되는 경험을 했다. 서버, 네트워크, 운영체제, 가상화, 컨테이너와 같은 소프트웨어적인 내용뿐만 아니라 데이터 센터, 서버 장비, 냉각과 같은 물리적인 영역까지 함께 다루고 있어 클라우드 서비스 뒤에서 실제로 어떤 인프라가 움직이고 있는지도 생각해 볼 수 있었다.

가장 크게 달라진 점은 배포와 운영을 바라보는 기준이다. 지금까지는 Vercel에 프로젝트를 배포하고 API가 정상적으로 동작하면 운영까지 어느 정도 해냈다고 생각했다. 하지만 이 책을 읽고 나니 로그, 장애 감지, 데이터 백업, 비용 관리 기준이 없는 상태는 단순히 서비스가 인터넷에서 실행되고 있을 뿐, 운영 가능한 서비스라고 부르기 어렵다는 생각이 들었다.

서비스를 운영한다는 것은 기능이 정상적으로 동작하는지만 확인하는 일이 아니었다. 응답 속도와 오류율을 측정하고, 장애가 발생했을 때 빠르게 감지하며, 데이터가 유실됐을 때 복구할 수 있어야 한다. 트래픽이 증가했을 때 어느 부분이 병목이 되는지 파악할 수 있어야 하고, 서비스의 안정성과 비용 사이에서 적절한 선택도 내려야 한다. 이전에는 배포를 개발의 마지막 단계처럼 생각했다면, 이제는 배포 이후부터 본격적인 운영과 개선이 시작된다고 보게 되었다.

책에 담긴 저자의 실무 경험을 통해 현업의 판단 과정을 간접적으로 접할 수 있었던 점도 좋았다. 서버와 네트워크에는 언제든 장애가 발생할 수 있으며, 중요한 것은 고장을 완전히 없애는 것이 아니라 고장이 발생하더라도 사용자에게 미치는 영향을 줄이고 빠르게 복구하는 것이라는 설명이 특히 기억에 남았다. 성능 튜닝 역시 감으로 설정을 변경하는 것이 아니라 데이터를 측정해 병목 지점을 찾고, 한 번에 하나씩 개선하며 결과를 검증하는 과정이라는 점을 배웠다.

기술을 공부하는 방식에 대해서도 다시 생각하게 되었다. 단순히 사용 방법을 익히는 것보다 해당 기술이 왜 필요하고 시스템 안에서 어떤 역할을 하는지 설명할 수 있어야 한다. Docker 명령어를 사용할 줄 아는 것보다 컨테이너가 어떤 문제를 해결하는지 알아야 하고, AWS나 클라우드 서비스에 애플리케이션을 배포하는 것보다 왜 해당 서비스를 선택했으며 다른 대안과 비교했을 때 어떤 장단점이 있는지 이해해야 한다.

특히 마지막 취업 파트는 현재의 나에게 가장 현실적으로 다가왔다. 주니어 백엔드 엔지니어에게 아키텍처, 인프라, DevOps에 대한 깊은 경험이 반드시 요구되는 것은 아니지만, 적절한 수준의 이해와 경험은 다른 지원자와 차별화할 수 있는 요소가 된다. 더 나아가 리드급 엔지니어로 성장하기 위해서는 코드뿐만 아니라 시스템의 구조, 데이터의 흐름, 배포와 운영 과정까지 폭넓게 이해해야 한다는 점이 인상 깊었다.

책에서는 자신이 현재 사용하고 있는 기술부터 정확히 설명할 수 있어야 한다고 말한다. 이 조언은 앞으로 프로젝트를 진행할 때 실제 습관으로 만들어 보고 싶다. 새로운 기술을 도입하면 단순히 “사용해 봤다”라고 기록하는 것이 아니라 다음 질문에 답할 수 있도록 정리할 생각이다.

• 이 기술의 정확한 역할과 사용한 버전은 무엇인가?
• 프로젝트의 어느 계층에서 사용되는가?
• 왜 이 기술과 아키텍처를 선택했는가?
• 어떤 문제를 해결하기 위해 도입했는가?
• 비교할 수 있는 다른 대안은 무엇인가?
• 현재 방식의 장점과 한계는 무엇인가?
• 운영 중 문제가 발생하면 무엇을 확인해야 하는가?

현재 알고 있는 영역에서 한 계층 위와 아래까지 공부하는 습관도 들이고 싶다. 백엔드 애플리케이션을 개발한다면 코드와 API만 보는 데서 멈추지 않고, 요청이 들어오는 앞단의 DNS, HTTP, 프록시부터 데이터가 전달되는 데이터베이스, 운영체제, 네트워크, 클라우드 환경까지 흐름을 따라가며 이해하려고 한다.

개발 공정의 앞뒤로 시야를 넓히는 연습도 필요하다. 요구사항이 어떻게 정의되는지, 어떤 기준으로 아키텍처를 선택하는지, 테스트와 QA는 어떻게 진행하는지, 배포와 릴리스는 어떻게 구분되는지, 운영 중 발생한 문제를 어떤 로그와 지표로 확인하는지까지 경험해야 한다.

이를 위해 지금 진행 중인 프로젝트와 앞으로 만들 개인 서비스를 단순히 배포된 결과물로 끝내지 않고, 일정 기간 실제로 운영하며 개선해 보고 싶다. 로그를 남기고 확인하는 구조를 만들고, 오류나 장애를 감지할 수 있는 모니터링을 적용하며, 데이터 백업과 복구 방법도 직접 점검해 볼 생각이다. 가능하다면 부하 테스트를 통해 병목 지점을 찾아보고, 장애 상황을 가정해 서비스가 어떻게 동작하는지도 확인해 보고 싶다.

Docker와 CI/CD 역시 포트폴리오에 기술 이름을 추가하기 위해 도입하는 것이 아니라, 실행 환경의 차이를 줄이고 반복적인 배포 과정을 안정적으로 관리하기 위한 목적으로 활용해야 한다. 데이터베이스나 클라우드 서비스를 선택할 때도 익숙하다는 이유만으로 결정하지 않고 비용, 성능, 확장성, 운영 난이도, 벤더 종속성과 같은 기준을 대안과 함께 비교해 보고 싶다.

이 책을 읽기 전에는 클라우드와 인프라를 백엔드 개발 이후에 추가로 공부해야 하는 영역으로 생각했던 부분이 있었다. 그러나 책을 덮은 뒤에는 백엔드 개발, 인프라, 배포, 운영이 서로 분리된 과정이 아니라 사용자에게 안정적인 가치를 전달하기 위해 함께 연결되어야 하는 하나의 흐름이라는 생각이 들었다.

앞으로는 새로운 기술을 빠르게 익히는 데만 집중하지 않고, 기술이 바뀌어도 남아 있는 시스템의 기본 원리를 꾸준히 공부하고 싶다. 기능을 구현하고 인터넷에 배포하는 데서 멈추지 않고, 내가 만든 서비스가 어떤 환경에서 실행되고 사용자의 요청이 어떤 경로를 거치며 문제가 발생했을 때 어떻게 발견하고 복구할 것인지까지 고민하는 개발자로 성장하고자 한다.

이러한 경험을 하나씩 쌓아 가는 과정이 안정적인 서비스를 설계하고 운영할 수 있는 백엔드 개발자, 그리고 장기적으로 기술과 비즈니스를 함께 판단할 수 있는 CTO로 성장하는 기반이 될 것이라고 생각한다.

---

🌟 총평 및 추천 여부

• 별점: ★★★★★ (5점 만점)
• 이 책을 추천하는 대상: 클라우드와 인프라를 단편적인 기술이 아닌 전체 시스템의 관점에서 이해하고 싶은 사람
• 한줄평: 기능을 구현하는 개발자에서 시스템 전체를 이해하고 안정적으로 운영하는 개발자로 성장하기 위한 클라우드 인프라 입문 사전