한빛미디어



항상 배포 전날은 긴장이 된다.

개발자는 아니지만 아니 개발자가 아니라서 더 긴장이 된다.

QA팀을 거쳐 일반적으로 발생하지 않는 케이스들 까지 모두 확인을 한 뒤라도

항상... 배포 전날은 굉장히 신경이 쓰이고

배포하는 시간이 언제든 상관없이 배포 직후에는 기본적인 테스트를 빠르게 수행해본다.

내 직무가 아님에도 불구하고..

개발에 버그가 없을 순 없지만

개발팀 친구들과 이야기를 나눌 때 종종 물어보던 부분이

모니터링에 대한 부분이다.

막상 문제가 터지기 전에 미리 알 수 있는 방법은 없나?

분명 문제가 될 것으로 예측이 되는데 왜 우리는 특정 기능에 대해서만 로드 및 밸런스 테스트 정도만 진행하는가.

여러번 배포 이후 라이브 서버에서 문제가 되었거나 문제 발생의 소지가 있어서 급하게 작업했던 기억이 있지 않나..

라는 질문에 대한 일종의 해답을 제시하는 책을 만났다.

결론 부터 말하자면 모니터링의 상위 개념인 옵저버빌러티(Observability) 에 대한 이야기이고

보다 라이브하게 말하자면 OpenTelemetry 사용법이다.

사용법에 가깝다! 가 아니라 그냥 대 놓고 사용법이다.

물론 사용법만 있는 것은 아니고

나처럼 Observability에 대한 개념이 생소한 사람을 위한 개론적인 설명도 충분히 있다.

그래 읽어보니 모니터링 그 이상인 것도 알겠고

필요하다는 것도 알겠다.

또한 책의 구성 역시 시각적인 자료의 구성부터 챕터 말미의 요약 섹션까지 나무랄데 없었으나

아무리 간단하고 아무리 쓸모 있어도

계측시스템을 OpenTelemetry 사용법 및 추천도서 하나만 보고 실제 서비스에 적용하기에는 무리가 있다고 판단이 되었다.

물론 독립적인 신규 서비스를 테스트 할 때 적용은 한 번 해볼 것 같긴한데

일단 내가 하고 싶다고 바로 적용할 수 있는 것도 아니니

개발팀장님부터 해서 이 책을 선물하며 우리도 신문물 적용좀 해보자고 잘 꼬드겨 봐야겠다.

책의 서두에서 밝히듯 모니터링 시스템 구축 및 Observavility 관련 스트럭쳐 구성은 이야기만 꺼내도 개발팀에서는 발작버튼과 같은 역할을 해 온터라 쉽지는 않겠지만

그래도 내가 집요하게 설득하느니 슬쩍 이 책을 한 번 들이밀어보고 이야기를 꺼내 볼까 한다.

잘.... 안될 것 같긴한데....

물론 이건 책이 부족해서가 아니라 밤잠을 줄여가며 작업하는 개발팀에서 새로운 무언가를 쉽사리 받아들여주지 않을 것 같다는 느낌적인 느낌 때문이다..

모니터링의 도입으로 문제 발생의 빈도가 확 줄어들거나 예측 가능성이 비약적으로 높아진다면

아니 높아져서 단 한번이라도 등골서늘한 경험을 피할 수 있다면

그 다음 부터는 잘 도입해서 쓸 것 같지만

아직은 미지수다...

특히 오픈소스 하나에 의존해서 모니터링 시스템을 구축한다..... 음.... 잘 모르겠다..

요즘엔 개발이라는 것이 대부분 외부 리소스의 조합으로 진행되지만 모니터링의 디펜던시가 유일한 오픈소스 솔루션에 걸린다면... 고민을 많이 하게 될 것 같다.

다만 이러한 Observability 관련 소스나 경험들이 더 많이 확산되어 개발팀의 야근이 줄어들고

긴급 상황 발생이 더 많이 줄어들길 바란다!

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