[DevOps] 데브옵스 핸드북 2/e (The DevOps Handbook)

https://www.yes24.com/product/goods/61792775

데브옵스 핸드북 | 진 킴 | 에이콘출판사 - 예스24

이제 DevOps는 “배포 자동화” 정도의 이야기가 아니었다

이 책을 읽으면서 가장 크게 들었던 생각은 이거였다.

“아 이제 운영 자체가 하나의 시스템 공학이 됐구나.”

예전 DevOps 이야기들은 어딘가 좀 더 “변화 운동” 같은 느낌이 있었다.

개발과 운영이 협업하고,
배포를 자동화하고,
조직 문화를 바꾸고,
더 빠르게 움직이자는 흐름.

근데 이 책은 그 단계를 이미 지나온 느낌이 강하다.

읽다 보면 DevOps를 단순 배포 문화나 자동화 기법처럼 다루지 않는다.

거의:
“대규모 시스템 운영을 어떻게 안정적으로 흐르게 만들 것인가”
에 대한 이야기처럼 느껴진다.

그래서 책 자체 밀도도 굉장히 높다.

배포만 이야기하지 않는다.

• 장애 복구,
• 관측성,
• 피드백 속도,
• 변경 흐름,
• 조직 학습,
• 운영 안정성,
• 보안,
• 지속적 전달

같은 것들이 전부 하나로 연결되어 나온다.

읽다 보면 느껴지는 게 있다.

이 시점의 DevOps는 더 이상 개발팀 문화 이야기가 아니다.

운영 전체를 어떻게 설계할 것인가에 가까워졌다.

특히 인상 깊었던 건 Three Ways였다.

Flow,
Feedback,
Continuous Learning.

처음 보면 약간 추상적으로 느껴진다.

근데 읽다 보면 왜 이걸 계속 이야기하는지 이해된다.

결국 운영 시스템이라는 건:
변경이 얼마나 자연스럽게 흐르는지,
문제를 얼마나 빨리 감지하는지,
조직이 얼마나 빨리 학습하는지

이 세 가지로 계속 성숙도가 갈린다는 이야기였다.

특히 좋았던 건 이 책이 “속도”를 굉장히 다르게 바라본다는 점이었다.

예전 운영 방식에서는 보통 변경 자체를 위험하게 봤다.

배포는 최대한 줄이고,
점검 시간은 길게 잡고,
큰 변경을 한 번에 몰아서 처리하는 경우가 많았다.

근데 실제 운영하다 보면 오히려 그 방식이 더 무섭다.

몇 달 동안 쌓인 변경사항을 한 번에 배포하는 순간,
문제 생겨도 어디서 깨졌는지 찾기가 굉장히 어려워진다.

로그는 뒤엉키고,
영향 범위는 커지고,
롤백도 복잡해진다.

이 책은 오히려 반대로 본다.

작고 자주 변경할수록:

• 문제 범위가 줄어들고,
• 원인 추적이 쉬워지고,
• 롤백이 빨라지고,
• 장애 영향도도 낮아진다는 것.

이 부분이 꽤 공감됐다.

실제로 운영 오래 해보면:
“배포 횟수”
보다
“변경 크기”
가 더 무섭게 느껴질 때가 많다.

또 하나 기억에 남았던 건 “피드백 속도”였다.

예전 운영은 뭔가 항상 늦었다.

장애가 나고 한참 뒤에 로그 보고,
문제 생기고 나서 회의하고,
이슈가 터지고 나서 원인 분석 들어간다.

근데 현대 시스템은 규모가 커질수록 그렇게 운영하면 버티기가 힘들어진다.

그래서 이 책은 계속:
얼마나 빨리 시스템 상태를 이해할 수 있는가를 중요하게 본다.

여기서부터:
Monitoring,
Telemetry,
Alerting,
Observability

같은 이야기들이 굉장히 중요하게 나온다.

근데 읽다 보면 단순 모니터링 이야기랑은 느낌이 좀 다르다.

CPU 몇 퍼센트,
메모리 얼마나 사용 중,
이런 수준보다:
“지금 시스템에서 무슨 일이 일어나고 있는가”
를 얼마나 빨리 이해할 수 있느냐에 더 가까운 느낌이다.

이 부분도 굉장히 현대적인 운영 관점처럼 느껴졌다.

특히 운영 규모 커질수록:
“장애를 막는다”
보다
“장애를 빨리 이해한다”
가 훨씬 중요해지는 순간이 온다.

완벽하게 장애 없는 시스템은 현실적으로 어렵기 때문이다.

그래서 결국 중요한 건:
얼마나 빨리 감지하는지,
얼마나 빨리 복구하는지,
얼마나 빨리 원인을 파악하는지

같은 방향으로 계속 이동하게 된다.

읽으면서 계속 느꼈던 건 이 책이 “사람 탓”을 굉장히 경계한다는 점이었다.

보통 장애 터지면 조직은 자연스럽게:
누가 실수했는지,
왜 놓쳤는지,
누구 책임인지

분위기로 흘러가기 쉽다.

근데 이 책은 그런 접근보다:
“왜 시스템이 그렇게 동작했는가”
를 더 중요하게 본다.

이 관점이 꽤 좋았다.

실제로 장애는 특정 개인 실수 하나보다는:

• 복잡한 시스템 구조,
• 부족한 피드백,
• 운영 가시성 부족,
• 위험한 변경 흐름,
• 애매한 프로세스

같은 구조적인 문제에서 나오는 경우가 훨씬 많다.

그래서 단순히 사람을 혼내는 방식으로는 운영 품질이 좋아지지 않는다고 본다.

오히려:
장애를 통해 시스템을 더 이해하고,
다음 변경을 더 안전하게 만들고,
조직 전체가 계속 학습하는 흐름을 더 중요하게 본다.

이 부분이 특히 인상 깊었다.

운영 오래 하다 보면 결국 느끼게 된다.

장애 자체보다 더 위험한 건:
같은 장애를 반복하는 조직이라는 걸.

그래서 이 책은 단순히 “안정적인 시스템 만들기”보다:
계속 개선 가능한 운영 구조를 만드는 쪽에 훨씬 가까워 보였다.

읽다 보면 확실히 느껴진다.

이 시점의 DevOps는 더 이상 단순 배포 자동화 이야기가 아니다.

거의 운영 체계 전체를 다루는 이야기다.

특히:
SRE,
Observability,
Continuous Delivery,
Security,
Cloud 운영

같은 현대 운영 흐름들이 전부 자연스럽게 이어진다.

그래서 읽고 나면 약간 이런 느낌이 남는다.

“아 이제 운영은 진짜 감으로 버티는 영역이 아니구나.”

예전에는 경험 많은 운영자가 시스템을 지탱하는 느낌이었다면,
이 책에서는:

• 시스템 흐름을 측정하고,
• 변경을 제어하고,
• 피드백을 빠르게 만들고,
• 운영 자체를 계속 개선 가능한 구조로 만드는 방향에 더 가깝다.

개인적으로 가장 좋았던 건 이 책이 “속도와 안정성은 반대가 아니다”라는 걸 굉장히 설득력 있게 보여준다는 점이었다.

예전에는:
빠르면 위험하고,
안정적이면 느리다고 생각했다.

근데 이 책은 오히려:
자동화되고,
관측 가능하고,
피드백이 빠르고,
변경이 작아질수록

시스템은 더 안정적일 수 있다고 본다.

그리고 읽고 나면 그 말이 꽤 현실적으로 느껴진다.

아마 그래서 이 책이 지금까지도 DevOps 이야기할 때 계속 기준처럼 언급되는 것 같다.