[DevOps] 엔터프라이즈 데브옵스 (DevOps for the Modern Enterprise)

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

엔터프라이즈 데브옵스 | 미르코 헤링 | 에이콘출판사 - 예스24

 

기술보다 더 어려운 건 조직이었다

처음 이 책 제목을 봤을 때는 약간 뻔한 내용을 예상했다.
대기업에서 DevOps 도입하는 방법론 정도 아닐까 싶었다. CI/CD 구축 사례 나오고, 조직 협업 이야기 조금 하고, “문화가 중요합니다” 같은 이야기로 끝나는 그런 느낌.

근데 막상 읽어보면 생각보다 훨씬 현실적이다.

그리고 꽤 오래 전에 나온 책인데도 지금 엔터프라이즈 조직들이 겪는 문제랑 크게 다르지 않다는 게 더 흥미롭다.

책을 읽으면서 계속 들었던 생각은 하나였다.

“결국 기술보다 조직이 더 안 바뀐다.”

사실 기술은 생각보다 빨리 바뀐다.
새로운 툴 나오면 도입 검토하고, 조금 지나면 PoC 하고, 또 몇 년 지나면 어느새 표준처럼 굳어진다.

근데 조직은 그렇지 않다.

배포 프로세스 하나 바꾸는 데도 회의가 몇 번씩 열리고, 승인 체계 하나 줄이는 것도 엄청난 저항이 생긴다. 운영팀은 안정성을 이야기하고, 개발팀은 속도를 이야기하고, 보안팀은 위험성을 이야기한다.

다 틀린 말은 아니다.

문제는 모두가 자기 위치에서 맞는 말을 하고 있다는 거다.

그래서 엔터프라이즈 환경에서는 기술보다 조율 비용이 훨씬 커진다.

이 책이 재미있는 건 바로 그 부분을 굉장히 현실적으로 다룬다는 점이다.

DevOps를 무슨 마법 같은 문화 혁신으로 포장하지 않는다. 오히려 아주 건조하게 이야기한다.

“조직 구조 때문에 느려진다.”

이 메시지가 책 전체를 관통한다.

실제로 회사 규모가 커질수록 시스템보다 프로세스가 더 복잡해진다.

서비스는 늘어나고, 팀도 늘어나고, 관리해야 할 서버와 계정과 권한과 운영 정책도 계속 증가한다. 그러다 보면 어느 순간부터는 기술 문제가 아니라 “사람 사이 연결 비용”이 폭발하기 시작한다.

누가 승인해야 하고, 누가 책임지고, 누가 운영하며, 장애가 나면 누가 대응할지 같은 문제들.

결국 대부분의 병목은 여기서 생긴다.

책을 읽다 보면 당시 엔터프라이즈 운영 환경의 분위기가 꽤 생생하게 느껴진다.

배포 한번 하려면:
운영팀 확인 받고,
DBA 확인 받고,
변경 승인 등록하고,
점검 시간 잡고,
롤백 계획 쓰고,
새벽 시간 대기하고,
장애 대응 담당자 붙이고…

그러다 보면 자동화가 있어도 결국 사람이 중심이 된다.

이게 재미있는 부분이다.

당시에도 이미 자동화 기술은 존재했다.
스크립트도 있었고, CI 툴도 있었고, 배포 시스템도 있었다.

근데 조직이 그 속도를 따라가지 못했다.

그래서 책에서도 계속 반복해서 나오는 이야기가 있다.

“표준화와 반복 가능성.”

사람마다 다른 방식으로 운영하지 말고, 가능한 같은 방식으로 움직이게 만들어야 한다는 것.

왜냐하면 엔터프라이즈 규모에서는 개개인의 숙련도에 의존하는 순간 운영 복잡도가 폭발하기 때문이다.

어디는 shell script로 배포하고,
어디는 수동 배포하고,
어디는 특정 운영자만 아는 방식으로 시스템을 관리한다.

그러면 결국 시스템이 아니라 사람이 SPOF가 되기 시작한다.

이 책은 그걸 굉장히 경계한다.

특히 좋았던 건 DevOps를 단순 개발 문화로 보지 않았다는 점이었다.

보통 DevOps 이야기하면:

• 빠른 배포
• 개발 생산성
• Agile 문화

같은 방향으로 흐르는 경우가 많다.

근데 이 책은 운영 관점을 굉장히 중요하게 본다.

왜냐하면 엔터프라이즈 환경에서는 결국 운영 안정성이 비즈니스 안정성과 직결되기 때문이다.

아무리 배포가 빨라도 장애 한번 크게 나면 조직은 바로 다시 보수적으로 돌아간다.

그래서 결국 중요한 건:
“빠르게 바꾸되 안정적으로 유지하는 것”

이었다.

그리고 여기서 이 책이 단순 운영 효율 이야기를 넘어서기 시작한다.

후반부로 갈수록 반복적으로 등장하는 메시지가 있다.

사람을 반복 작업에서 해방시켜야 한다는 것.

이 부분이 꽤 인상 깊었다.

예전 엔터프라이즈 운영 조직은 사람이 직접 처리하는 업무가 굉장히 많았다.

• 서버 생성 요청
• 권한 변경
• 운영 티켓 처리
• 환경 설정 수정
• 수동 배포
• 점검 절차 수행

이런 것들이 대부분 운영자의 시간과 집중력을 계속 소모한다.

근데 규모가 커질수록 이 방식은 한계가 온다.

사람은 계속 반복 작업에 묶이고,
운영 속도는 점점 느려지고,
정작 중요한 개선 작업은 뒤로 밀리기 시작한다.

그래서 이 책은 DevOps의 중요한 목표 중 하나를:
“사람이 더 가치 있는 문제를 해결하게 만드는 것”
으로 바라본다.

여기서 등장하는 개념이 “Knowledge Worker”, 즉 지식 노동자다.

단순히 정해진 작업을 반복 수행하는 역할이 아니라:

• 시스템을 개선하고,
• 구조를 고민하고,
• 자동화를 설계하고,
• 더 큰 문제를 해결하는 방향으로 사람이 움직여야 한다는 이야기다.

이 부분이 굉장히 인상 깊었다.

왜냐하면 지금도 운영 조직이 성숙해질수록 결국 같은 방향으로 가기 때문이다.

반복 작업은 자동화되고,
사람은 점점:

• 플랫폼 설계,
• 운영 개선,
• 관측성,
• 비용 최적화,
• 아키텍처

같은 더 복잡한 문제를 다루게 된다.

지금 보면 너무 자연스러운 흐름처럼 보이지만, 당시 엔터프라이즈 운영 환경에서는 꽤 큰 변화였던 것 같다.

특히 운영 조직을 단순 유지보수 조직이 아니라:
지속적으로 시스템을 개선하는 엔지니어링 조직으로 바라봤다는 점이 인상적이었다.

읽고 나서 가장 크게 남았던 건 이거였다.

『Enterprise DevOps』는 단순 DevOps 도입서라기보다,
대규모 조직이 어떻게 복잡성을 줄이고,
사람이 더 가치 있는 일에 집중할 수 있게 만들 것인가에 대한 책에 더 가까웠다는 점이었다.