관측성 도구 선택 기준표 작성법과 템플릿

풀려는 질문부터 쓰기

관측성 도구는 “무엇이든 다 본다”를 목표로 고르면 비용이 끝없이 늘어납니다. 먼저 장애를 몇 분 안에 알아야 하는지, 요청 하나가 어떤 서비스를 거쳤는지 따라가야 하는지를 정합니다. 이 사이트에 모인 관측성 주제 글은 2편입니다.

서비스 구조를 먼저 그려 보기

넷플릭스는 대규모 분산 서비스의 토폴로지를 분석하는 플랫폼을 만들었습니다. 서비스가 많을수록 “누가 누구를 호출하는가”가 가장 먼저 필요한 정보가 됩니다. 기준표에 토폴로지를 보여 줄 수 있는지 항목으로 넣습니다. 다만 이 글 요약에는 규모 수치가 없어서, 우리 규모에서의 비용은 직접 확인해야 합니다.

여러 클라우드와 클러스터를 나눠 볼 때

머니포워드는 핀테크 멀티 클러스터 환경에서 GitOps 기반 플랫폼을 고도화했습니다. 클러스터가 여럿이면 기준표에 “클러스터 경계를 넘어 한 화면에 볼 수 있는가”를 넣어야 합니다. 이 사례는 관측성과 배포 체계가 같은 문제로 묶인다는 점을 보여 줍니다.

도입 뒤 검증하기

도구를 고른 뒤에는 실제 장애를 기준으로 알림을 검증합니다. 알림이 울렸어야 할 장애를 몇 건 잡았는지, 울리지 않아도 됐던 알림이 몇 건인지 세어 기록합니다. 이 두 숫자가 다음 검토의 출발점입니다.

템플릿(복사용)

## 1. 풀려는 질문

- 장애를 몇 분 안에 알아야 하는가
- 어떤 요청 하나가 어디를 거쳤는지 따라갈 수 있어야 하는가

## 2. 기준표

| 기준 | 가중치 | 후보 A | 후보 B | 확인 방법 |
|---|---|---|---|---|
| 데이터량 대비 비용 | | | | |
| 로그·지표·추적 통합 | | | | |
| 우리 팀이 아는 질의 언어 | | | | |
| 운영 부담 | | | | |

## 3. 도입 뒤 확인

- 알림이 실제 장애를 잡았는지, 오탐은 얼마나 되는지

## 4. 되돌림 조건

- 비용 상한, 알림 누락 기준