로그와 지표와 알림을 병원 기록처럼 나누는 법

서비스가 멈추면 처음에는 화면에 보이는 오류 문장만 붙잡기 쉽습니다. 그러나 한 사람의 실패인지 전체 사용자의 문제인지, 지금도 이어지는지 이미 끝났는지를 알려면 서로 다른 기록이 필요합니다.

병원에서 진료 기록, 체온 변화표, 응급 호출을 따로 쓰는 것처럼 서비스도 로그, 지표, 알림을 나눕니다. 이 셋을 한 대시보드에 모을 수는 있어도 역할까지 같아지는 것은 아닙니다.

로그는 한 사건을 시간순으로 남긴 기록이다

로그는 프로그램에서 일어난 사건을 시각과 함께 남긴 기록입니다. OpenTelemetry는 로그를 구성 요소가 내보낸 시간 표시 메시지로 설명합니다. 주문 요청이 들어왔는지, 어느 단계에서 실패했는지, 어떤 오류 종류였는지를 한 건씩 추적할 때 유용합니다.

구조화 로그는 필드 이름과 값의 뜻을 일정하게 정한 기록입니다. 단순히 JSON 모양이라고 구조화되는 것이 아니라 시간, 심각도, 서비스, 요청 식별자 같은 칸이 계속 같은 뜻을 가져야 검색과 집계가 가능합니다.

{"time":"2026-09-12T04:40:00+09:00","level":"error","service":"checkout","event":"payment_status_unavailable","requestId":"demo-42"}

이 예시는 실제 고객 자료가 없는 연습용입니다. 요청 식별자는 여러 로그를 이어 보는 끈이지 이메일이나 카드 번호를 넣는 칸이 아닙니다.

지표는 많은 사건의 변화를 숫자로 모은다

지표는 metric, 즉 일정 시간 동안 측정한 값을 모아 서비스 상태를 보는 숫자입니다. 요청 수, 실패 비율, 응답 시간, 대기 작업 수처럼 여러 사건을 합쳐 흐름을 봅니다. 로그 한 줄이 진료 기록이라면 지표는 하루 체온 변화표에 가깝습니다.

서버가 켜져 있다는 숫자만으로 서비스가 쓸 만하다고 말할 수 없습니다. 사용자가 가입을 끝내는 비율, 결제 상태를 확인하는 데 걸린 시간처럼 실제 기대와 연결된 값을 함께 봐야 합니다. 평균만 보면 소수의 매우 느린 요청이 숨을 수 있으므로 구간이나 상위 지연도 필요할 수 있습니다.

알림은 사람이 확인할 조건과 행동을 묶는다

알림은 alert, 즉 정한 조건을 넘으면 담당자가 확인하도록 보내는 신호입니다. 모든 오류 로그를 알림으로 바꾸면 같은 문제가 수백 번 울려 정작 중요한 신호를 놓칩니다. 증상, 지속 시간, 영향 범위, 확인할 첫 화면을 함께 정해야 합니다.

좋은 첫 알림은 “오류가 있다”보다 “최근 일정 구간에 결제 상태 확인 실패가 계속되어 사용자의 완료를 막고 있다”에 가깝습니다. 알림을 받는 사람이 확인할 로그와 지표, 임시 대응, 연락 기준도 연결합니다. 자동 재시작은 알림과 다른 변경 작업이므로 영향 범위를 모르면 켜지 않습니다.

경고와 장애도 나눕니다. 경고는 추세가 나빠져 확인이 필요한 상태이고, 장애는 사용자가 약속한 기능을 쓰지 못하는 상태로 정할 수 있습니다. CPU 숫자가 높아도 사용자가 정상적으로 끝내고 있다면 조사 순서가 달라질 수 있고, 서버 숫자가 평온해도 저장 결과가 사라진다면 사용자 관점에서는 큰 장애입니다. 그래서 기술 자원 지표 하나가 아니라 성공한 사용자 행동의 비율과 지연을 함께 둡니다.

세 기록을 같은 요청 식별자로 이어 본다

한 사용자의 요청이 실패했을 때 먼저 로그에서 요청 식별자를 찾습니다. 같은 시각의 오류율과 응답 시간 지표를 보고 전체 문제인지 좁힙니다. 조건이 지속되면 알림이 울렸는지, 담당자가 어떤 결정을 했는지 사건 기록에 남깁니다.

• 로그에는 사건 시각과 종류와 요청 식별자를 둡니다.
• 지표에는 요청 수와 실패 수와 지연을 같은 단위로 모읍니다.
• 알림에는 조건과 지속 시간과 확인 담당을 적습니다.
• 배포 시각을 함께 남겨 전후 변화를 비교합니다.
• 사용자가 겪은 화면 증상을 내부 오류명과 분리해 기록합니다.
• 해결 뒤 알림이 실제로 멈췄는지 다시 확인합니다.

비밀값과 개인정보는 관측 자료에 남기지 않는다

로그는 여러 사람이 보고 오래 보관될 수 있습니다. 비밀번호, 세션 쿠키, API 키, 카드 정보, 주민번호, 요청 본문 전체를 그대로 기록하면 진단 도구가 새로운 유출 경로가 됩니다. 필요한 필드만 허용하고 민감한 값은 수집 전에 제외하거나 되돌릴 수 없게 가립니다.

로그 수준을 바꾸거나 모든 요청 본문을 켜는 명령은 뜻과 보관 위치를 모르면 실행하지 마세요. 알림 테스트도 실제 결제나 문자 발송을 일으킬 수 있으므로 테스트 환경과 대상 계정을 확인합니다. 자동 삭제 설정은 보관 의무와 조사 기간을 검토하기 전 바꾸지 않습니다.

오늘 바로 해볼 작은 실습

실제 서비스 설정을 바꾸지 않고 종이에 첫 관측표를 만듭니다.

1. 사용자가 꼭 끝내야 하는 행동 하나를 고릅니다.
2. 성공 한 건과 실패 한 건의 연습 로그 문장을 씁니다.
3. 5분마다 셀 숫자로 볼 지표 두 개를 고릅니다.
4. 언제 사람이 봐야 하는지 조건과 지속 시간을 적습니다.
5. 알림을 받은 뒤 열 첫 로그와 첫 지표를 연결합니다.
6. 기록에서 비밀번호, 토큰, 개인정보 칸을 지웁니다.

완성 기준은 화려한 대시보드가 아니라 한 증상을 로그 한 줄, 지표 변화, 행동 가능한 알림으로 이어 설명할 수 있는지입니다. 도구 이름보다 사용자 실패를 먼저 정하면 필요한 기록도 작고 분명해집니다.