모니터링 및 로깅 (Monitoring & Logging)

모니터링 및 로깅 설계란

모니터링 및 로깅 설계(Monitoring & Logging Design) 는 시스템이 느려지거나 실패할 때, 무엇이 문제인지 얼마나 빨리 감지하고 복구할 수 있는지를 미리 구조화하는 작업입니다.

이 문서는 시스템 설계 관점에서 무엇을 관측해야 하고, 어떤 신호를 어디까지 연결할지, 어떤 운영 목표를 둘지를 설명합니다.
Prometheus, Grafana, OpenTelemetry, Loki 같은 구현·운영 상세는 로깅 및 모니터링 문서를 함께 보면 더 직접적입니다.

시스템 디자인 면접에서 이 주제는 보통 다음 질문으로 이어집니다.

문제가 생겼을 때 얼마나 빨리 알 수 있는가
어디서부터 느려졌는지 추적할 수 있는가
사용자 영향과 내부 지표를 연결할 수 있는가
반복 장애에 대해 운영팀이 같은 방식으로 대응할 수 있는가

즉, 모니터링과 로깅은 디버깅 도구가 아니라 운영 가능성을 설계하는 문제에 가깝습니다.

왜 관측성을 먼저 설계해야 하는가

시스템이 단순할 때는 서버 한 대 로그만 봐도 문제를 찾을 수 있습니다. 하지만 서비스가 나뉘고 비동기 처리와 캐시, 외부 의존성이 늘어나면 상황이 달라집니다.

장애가 한 지점에서 시작해 여러 서비스로 퍼질 수 있음
배포 직후 문제가 생겨도 어디서 시작됐는지 바로 알기 어려움
일부 사용자의 특정 요청만 실패할 수도 있음
피크 트래픽과 평상시 증상이 다를 수 있음

그래서 운영에서는 다음을 구분해서 봐야 합니다.

문제가 있는가
어디서 시작됐는가
얼마나 많은 사용자에게 영향이 있는가
자동 복구가 가능한가

좋은 설계는 “문제 생기면 로그를 본다”가 아니라, 장애 감지, 원인 추적, 대응 우선순위를 미리 구조화한 설계입니다.

로그, 메트릭, 트레이스

관측성은 보통 로그(Log), 메트릭(Metric), 트레이스(Trace) 세 신호로 설명합니다.¹

신호	주로 답하는 질문	강점	주의점
로그	무슨 일이 있었는가	예외와 이벤트를 자세히 남김	너무 많으면 검색과 저장 비용이 커짐
메트릭	얼마나 느리고 얼마나 실패하는가	빠른 집계와 알림에 강함	원인을 세부적으로 설명하진 못함
트레이스	어디서 느려졌는가	요청 흐름과 병목 구간 파악에 유리	모든 요청을 다 저장하면 비용이 큼

이 셋은 대체 관계가 아니라 보완 관계입니다.

메트릭이 이상 징후를 먼저 감지합니다.
트레이스가 병목 구간을 좁혀 줍니다.
로그가 실제 원인과 맥락을 설명합니다.

면접에서는 “메트릭만 있으면 된다”보다는, 어떤 질문을 어떤 신호로 풀지를 같이 설명하는 편이 좋습니다.

분산 트레이싱

서비스가 여러 개로 나뉘면 하나의 요청이 여러 시스템을 거칩니다. 이때 분산 트레이싱(Distributed Tracing) 이 중요해집니다.

분산 트레이싱이 필요한 이유는 다음과 같습니다.

어느 서비스에서 지연이 시작됐는지 파악
재시도와 중복 호출을 구분
외부 의존성(API, DB, 메시징) 영향 추적
배포 전후 성능 변화 비교

핵심 설계 포인트는 다음과 같습니다.

컨텍스트 전파: trace id, span id, request id를 호출 체인에 실어 보냄²
표본 추출: 모든 요청을 저장할지 일부만 남길지 결정
상관관계: 로그와 메트릭이 trace id 기준으로 묶일 수 있어야 함

좋은 답변은 “트레이싱 도구를 쓴다”가 아니라, 요청 흐름을 하나의 단위로 묶어 병목을 추적할 수 있게 설계한다는 점을 말하는 답변입니다.

로그 집계와 분석

서비스가 늘어나면 로그를 개별 서버에만 두는 구조는 금방 한계가 옵니다. 그래서 보통은 중앙 수집과 구조화 로그를 함께 설계합니다.

대표 포인트는 다음과 같습니다.

중앙 수집: 여러 서비스 로그를 한곳으로 모음
구조화 로그: JSON 같은 포맷으로 남겨 검색과 필터링을 쉽게 함
민감정보 통제: 토큰, 비밀번호, 개인정보 마스킹
보존 정책: 얼마나 오래 저장하고 어떤 로그를 샘플링할지 결정

질문	설계 포인트
어떤 로그를 남길 것인가	비즈니스 이벤트, 예외, 보안 이벤트 구분
누가 볼 수 있는가	운영자, 개발자, 감사용 접근 권한 분리
얼마나 오래 보관할 것인가	비용과 규제 요구를 함께 고려
어떻게 찾을 것인가	구조화 필드와 correlation id 사용

중요한 점은 로그가 많을수록 좋은 것이 아니라, 필요한 이벤트가 검색 가능하고 상관관계가 살아 있어야 한다는 점입니다.

알림과 SLI/SLO 설계

운영에서 자주 실패하는 부분은 지표가 없는 것이 아니라, 알림이 너무 많거나 기준이 잘못된 경우입니다.

여기서 자주 나오는 개념이 다음입니다.³

SLI (Service Level Indicator): 실제로 측정하는 지표
SLO (Service Level Objective): 목표 수준
SLA (Service Level Agreement): 외부 계약 수준

예를 들면:

SLI: 성공률, p95 latency
SLO: 한 달 기준 99.9% 성공률
SLA: 고객 계약서에 명시된 보장 수준

좋은 알림 설계는 다음에 가깝습니다.

CPU 80% 자체보다 사용자 요청 실패율 증가를 먼저 봄
일시적 스파이크보다 지속적 문제에 알림을 걸음
운영자 조치가 필요한 항목만 paging 대상으로 올림

즉, 알림은 “서버가 바쁨”보다 사용자 영향과 연결된 운영 목표를 얼마나 위반했는지를 기준으로 설계하는 편이 더 좋습니다.

운영 대응과 런북

관측성 설계는 대시보드까지만으로 끝나지 않습니다. 실제 장애가 났을 때 누가 무엇을 보고 어떤 순서로 대응할지까지 연결돼야 합니다.

대표 포인트는 다음과 같습니다.

대시보드: 핵심 사용자 흐름 기준으로 구성
알림 우선순위: paging, ticket, informational 알림 구분
런북: 자주 나는 장애에 대한 대응 절차 문서화
배포 연계: 최근 배포와 장애 지표를 함께 볼 수 있어야 함
사후 분석: 장애 후 원인과 재발 방지 조치 정리

좋은 운영 설계는 “관측 도구를 많이 붙였다”가 아니라, 장애를 탐지하고, 범위를 좁히고, 대응 절차까지 일관되게 연결한 설계입니다.

모니터링 및 로깅의 트레이드오프

장점: 장애를 더 빨리 감지하고, 원인 파악과 복구 시간을 줄일 수 있습니다.
단점: 저장 비용, 고카디널리티 메트릭, 샘플링, 알림 피로도 같은 운영 비용이 커집니다.
주의점: 많은 데이터를 모으는 것보다, 어떤 질문에 답할 수 있는 구조인지가 더 중요합니다.

특히 다음 오해를 피해야 합니다.

로그를 많이 남기면 자동으로 관측성이 좋아지는 것은 아님
대시보드가 많다고 운영이 쉬워지는 것도 아님
모든 요청을 다 트레이싱해야 하는 것은 아님

좋은 답변은 무엇을 측정하고, 어떤 기준으로 알리고, 장애 때 어떤 흐름으로 대응할지를 함께 설명하는 답변입니다.

면접 포인트

모니터링과 로깅은 도구 도입보다 운영 가능성을 설계하는 문제입니다.
로그, 메트릭, 트레이스는 서로 다른 질문에 답하는 신호이므로 함께 설계해야 합니다.
분산 트레이싱은 병목 구간 추적과 상관관계 설계가 핵심입니다.
좋은 알림은 시스템 내부 상태보다 사용자 영향과 SLO 위반을 기준으로 잡습니다.
런북과 사후 분석까지 연결해야 운영 설계 답변이 실무적으로 보입니다.