당신의 30분 아침 모니터링 루틴? 문제는 데이터가 너무 많은 것이 아니다.

Source: Dev.to

왜 신경 써야 할까

아침에 AWS 콘솔, 로그 대시보드, 상태 페이지를 클릭하면서 “모든 게 괜찮은지” 확인하는 데 시간을 많이 쓴다면—이 글이 도움이 될 수 있습니다.

같은 문제를 겪고 있던 팀과 함께 일한 적이 있습니다. 문제는 정보 과부하가 아니라 볼 곳이 너무 많다는 것이었습니다.

상황

외부 컨설턴트로 프로젝트에 합류했습니다. 요청은 간단했습니다: “우리 모니터링 환경을 개선해 주세요.”

기본적인 것들은 이미 갖춰져 있었습니다:

• CloudWatch ✓
• 로그 ✓
• 대시보드 ✓

사건은 드물었습니다—몇 달에 한 번 정도. 깨진 것은 없었습니다.

하지만 뭔가 어색했습니다. 팀은 모니터링을 “올바르게” 하고 있지 않다는 느낌을 떨칠 수 없었습니다.

내가 발견한 점

인터뷰를 통해 몇 가지 우려 사항이 떠올랐습니다:

• 알림 임계값이 너무 느슨할 수 있다
• 메트릭이 잘 정리되지 않았다
• 외부 API 모니터링이 부족했다
• 비용 가시성이 필요했다

모두 타당한 지적이었습니다. 그런데 한 가지가 눈에 띄었습니다:

“매일 아침, 누군가가 약 30분을 수동으로 여러 화면을 확인하는 데 사용한다.”

실제 문제

그 30분을 파헤쳐 보았습니다.

대부분은 생각하는 시간이 아니라 탐색 시간이었습니다.

• AWS 콘솔 열기
• 대시보드 이동
• 시간 범위 변경
• 다른 서비스로 전환
• 외부 API 상태 페이지 열기
• 비용 탐색기 확인
• …

정보는 모두 존재했습니다. 단지 너무 많은 곳에 흩어져 있었을 뿐이었습니다.

인사이트

이것은 “모니터링이 부족한” 문제가 아니라
“컨텍스트 전환이 너무 많은” 문제였습니다.

현재 상태 (Pull 모델):
당신 → 확인 → CloudWatch, 로그, 외부 API, 비용…

목표 (Push 모델):
자동 생성 보고서 → 도착 → 당신

해결책? 보는 것을 줄이는 것이 아니라 보는 위치를 줄이는 것입니다.

계획

Pull에서 Push로 전환합니다.

매일 아침 대시보드에 직접 들어가는 대신, 보고서를 받아보게 합니다.

예전에 Jenkins를 이용해 다른 프로젝트에서 이 방식을 구현한 적이 있습니다. 예약 작업이 아침 요약을 생성해 채팅에 올렸고, 설정이 끝난 뒤 아침 체크는 “도착한 것을 읽는” 단계가 되었습니다.

다음 단계

• 목록 작성 — 확인하고 있는 모든 항목과 위치를 정리
• 우선순위 지정 — 핵심 메트릭만 선택
• 자동화 — Jenkins 작업을 만들어 보고서를 생성·전송
• 반복 — 실제 사용에 따라 추가·제거

작게 시작하세요. 완벽을 목표로 하지 마세요.

왜 아침 체크를 그냥 건너뛰지 않을까?

좋은 질문입니다.

모니터링에는 두 가지 역할이 있습니다:

알림은 문제가 발생했을 때 알려줍니다. 하지만 “보통”이 어떤지 감을 잃으면 알림이 얼마나 심각한지 판단하기 어렵습니다.

아침 체크는 문제를 잡기 위한 것이 아니라 캘리브레이션을 유지하기 위한 것입니다.

이를 쉽게 만든다고 해서 절차를 줄이는 것이 아니라, 실제로 체크가 지속되도록 만드는 것입니다.

마무리

이것이 만능 해결책은 아닙니다. 100 % 확신도 없지만 논리는 설득력 있습니다:

• 과도한 모니터링 투자는 현재 단계에 맞지 않는다
• “보통”에 대한 인식 상실은 실제 위험이다
• 따라서 습관을 지속 가능하게 만든다

구현 세부 사항은 추후에 다룰 예정입니다. 지금은 방향이 잡혔으니 진행해 보세요.

이와 같은 엔지니어링 결정과 사고 과정을 제 블로그에 기록하고 있습니다: