프로덕션 버그를 빠르게 해결하는 방법: 관측 가능성(Observability)을 통한 접근

John Gallagher, "Squash Production Defects Quickly - The Power of Structured Logging in Rails"

작성자
EuRuKo
발행일
2025년 01월 13일

핵심 요약

  • 1 생산 환경에서 발생하는 디버깅의 어려움을 해결하기 위해 'SOS(Steps to Observable Software)' 5단계 프로세스를 제안합니다.
  • 2 구조화된 로깅과 OpenTelemetry 표준을 적용하여 애플리케이션 가시성을 확보하고 문제를 신속하게 진단합니다.
  • 3 이러한 관측 가능성 도입으로 가동 중단 시간 98% 감소, 500 에러 83% 감소, 버그 해결 시간 20배 단축이라는 성과를 달성했습니다.

도입

BiggerPockets의 한 엔지니어는 프로덕션 환경에서 암호 재설정 이메일 전송 실패와 같은 반복적인 버그로 인해 겪었던 가시성 부족 문제와 그에 따른 좌절감을 공유합니다. 그는 유사한 문제에 대한 50명의 엔지니어 대상 설문조사를 통해 이러한 어려움이 특정 회사의 문제가 아닌 업계 전반의 공통적인 과제임을 밝힙니다. 이는 엔지니어의 개인적 역량 부족이 아닌, 시스템적 한계에서 비롯된 문제이며, 이로 인해 발생하는 좌절감과 업무 부담을 해소할 필요성을 강조합니다.

이러한 문제를 극복하기 위해 ‘SOS(Steps to Observable Software)’라는 5단계 프로세스를 제안합니다. 첫째, ‘어떤 질문에 답을 얻고 싶은가?’를 명확히 정의하고(예: 암호 재설정 이메일이 왜 전송되지 않는가?), 이에 대한 가설(예: 작업 지연)을 수립합니다. 둘째, 해당 질문에 답하는 데 필요한 데이터(이벤트, 필터, 그룹, 기간)를 결정합니다. 셋째, 이 데이터를 수집하기 위한 계측(Instrumentation)을 구축하고 배포합니다. 이 단계에서는 일반 텍스트 로그 대신 데이터베이스처럼 필터링 및 쿼리가 가능한 구조화된 로그의 중요성을 강조하며, Ruby 환경에서 ‘Semantic Logger’ 라이브러리를 최적의 선택으로 제시합니다. 또한, OpenTelemetry의 시맨틱 컨벤션을 따라 로그 속성 이름을 표준화하고, 헤더, 사용자 에이전트, 요청 ID, IP 주소 등 필수적인 추가 속성을 로그에 포함하는 방법을 설명합니다. 특히 Faraday와 같은 HTTP 클라이언트를 위한 미들웨어 추가를 통해 외부 API 요청에 대한 구조화된 로깅을 구현합니다. 넷째, 수집된 데이터를 그래프나 로그를 통해 분석합니다. 실제 사례를 통해 큐 지연을 유발하는 특정 작업(analytics_update_user_visits_job)과 그 원인이 되는 HTTP 리소스(profile_show 액션을 호출하는 스크래퍼)를 식별하는 과정을 시각적으로 보여줍니다. 마지막으로, ‘개선’ 단계에서는 지속적인 반복과 동료들과의 지식 공유를 통해 관측 가능성 문화를 조직 내에 확산시키고, 작은 개선이 큰 성과로 이어진다고 강조합니다.

결론

이러한 관측 가능성(Observability)의 구현은 프로덕션 버그 해결 방식에 혁신을 가져왔습니다. 실제 사례에서 암호 재설정 이메일 지연 문제를 단 5분 만에 스크래퍼 식별 및 차단으로 해결한 것처럼, 신속한 문제 진단과 해결이 가능해졌습니다. 이는 18개월 동안 가동 중단 시간 98% 감소, 500 에러 83% 감소, 버그 해결 시간 20배 단축이라는 놀라운 성과로 이어졌습니다. 연사는 관측 가능성이 개발자에게 애플리케이션의 어떤 문제든 해결할 수 있는 '초능력'을 부여하며, 예상치 못한 성능 개선(예: 404 에러 트래픽 차단으로 인한 응답 시간 19% 단축)까지 이끌어낼 수 있는 강력한 도구임을 역설합니다.

댓글 0

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!