사이트 신뢰성 엔지니어링 (Site Reliability Engineering) _ 벳시 베이어 外

 



(낮은 이해도에 따른 오독의 가능성 있음)

 

서비스업에서 일하면서 느낀 점 중 하나는 서비스의 퀄리티를 좋게 평가받기란 힘들다는 것이었다. 서비스라는 개념이 생기고서부터, 고객을 만족시키기 위해 경쟁적으로 서비스 수준은 높아져만 갔고, 점점 더 고도의 서비스를 만들어내기는 힘들어져만 갔다. 그렇기 때문에 눈이 높아질 대로 높아진 고객에게 있어, 만족감을 줄 수 있는 서비스는 일단 눈에 띄기 힘들다. 힘들여 뭔가 좋아진 것 같은데, 뭐가 좋아졌는지는 알기 힘들다. 서비스업에서 너무나 많이 써먹어 이젠 닳고 닳아버린 비유 물 밑에서 쉴새없이 물장구를 치고 있는 우아한 백조처럼, “오버하지 않고 만족감을 줄 수 있는서비스는 그 뒤편에서 인적, 그리고 물적 자원을 갈아넣고 있다.

또한, 이 서비스가 왜 좋은지를 알아내면, 경쟁자들이 그 서비스를 복제하는 것은 쉽다. 인적, 물적 자원을 갈아넣고 있다는 것은 그와 비슷한 자원을 가지고 있다면 똑같이 갈아넣었을 때 비슷한 결과를 만들어낼 수 있다는 것이기 때문에, 오히려 서비스를 개발하는 데 있어 드는 비용을 절감할 수 있다는 것이다. 서비스업에서는 오히려 선구자들이 피해를 보는 경우가 많다. 공격적으로 R&D에 투입하기보다는 슬금슬금 업계의 눈치를 보는 것이 이미지상으로는 2등일 지라도 오히려 더 안정적으로 운영할 수 있는 것이기도 하다. IT 서비스도 마찬가지다. 점점 기술 평준화가 있는 지금, 서비스 수준을 획기적으로 높인다고 해도 금방 후발주자들이 치고 들어온다. 점점 경쟁은 가속화되고, 못버티는 사람이 먼저 떨어져나가는 구조가 되어가고 있지 않은가 생각이 든다. 이런 구조에서는 뭔가 해보려고 하는 사람보다는 있는 걸 잘 돌리는 사람이 일을 더 잘 해 보인다.

획기적인 서비스, 무언가 해보려고 하면 실수가 생기고, 장애가 발생한다. 장애는 질책하고 없애야만 하는 손실이 아니라, 활용하기에 따라 서비스 수준을 더욱 높일 수 있고, 향후 활용할 수 있는 자산이 된다. 구글의 SRE들은 이 책을 통해, 그리고 사이트에 있는 더욱 많은 문서들을 통해 장애를 자산으로 바꾸어나가는 방법론을 공유했다. 

가장 흥미있는 부분은 에러 예산이라고 하는 개념이었다. 이 개념은 기본적으로 모든 시스템에 대해 신뢰성 목표를 100%로 잡는 것이 잘못되었다고 하는 데서 출발한다. 100% 완벽하게 동작하는 시스템을 만든다고 해도, 그 시스템을 둘러싼 외부의 인프라 통신망, 전력선, 터미널 성능 등 가 그 시스템의 신뢰성을 100%가 되지 못하게 한다. 티끌이 없는 시스템을 만들기 위해 굳이 많은 자원을 쏟을 필요는 없다는 말이다. 차라리 어느 정도의 예산 (budget)을 두고, 그 예산 안에서 향상된 서비스를 위해 새로운 실험을 하는 것이 더욱 더 효과적으로 자원을 이용할 수 있다는 이야기다. 에러 예산을 활용하기 위해 SLI, SLO와 같은 지표를 활용해야 하며, 그 지표를 효율적으로 관측하기 위해 효율적인 모니터링 시스템과 조직을 구축하고, 확보한 예산을 바탕으로 실패를 두려워하지 않는 테스트 환경을 조성하는 것이 중요하다가 이 책의 요지라고 볼 수 있겠다.

그렇다면, 이와 같은 방법론을 제조업이 운영하는 IT서비스라고 하는 특수한 환경에서는 어떻게 구현할 수 있을까가 숙제가 될 것이다. 일단 구글과 같은 IT서비스업이 본업이 아니니만큼, 이 책에서 사용하는 방법론을 100% 적용하는 것보다는, 현재 운영하고 있는 인력의 역할을 조정하여 SRE의 업무를 수행할 수 있도록 하여야 한다. 신뢰성에 관련된 지표를 설정하고, 그 지표가 성과에 유도될 수 있도록 하여 SRE의 업무가 하고 있는 업무에 얹어진 것이 아닌, 자부심을 가지고 수행하는 본인의 업무라는 개념을 조직 안에 심어야 할 것이다. 단순히 지표로 모니터링만 하는 것이 아닌, 매출과 손익과 같은 성과 지표의 하나로 매김할 수 있도록 해야 할 것이다.

사실 조용한 것이 잘 하는 것이고, 잘해봐야 본전 못하면 욕을 겁나 얻어먹는 게 업의 숙명이라지만, 어떻게 프레젠테이션을 하느냐에 따라 사실은 응원단이 아니라 중요한 키 플레이어라고, 때로는 골도 넣을 수 있는 중요한 역할이라고 어필할 수 있는 환경을 만드는 것이 IT기획의 중요한 업무가 아닌가라고 생각해본다.


댓글

이 블로그의 인기 게시물