로깅 · 모니터링
Logging / Monitoring
로깅이란?
- 로깅=일어난 일 기록
- 모니터링=실시간 감시
- 문제 조기 감지
로깅·모니터링이 자리를 잡으면 장애를 다루는 언어부터 바뀝니다. '아침부터 서비스가 좀 이상한 것 같다'는 보고가 '10시 12분부터 결제 API 응답이 0.8초에서 4.6초로 늘었고 오류율은 0.3%에서 7%로 올랐다'로 바뀝니다. 추측 대신 숫자로 시작하는 회의가 되니 개발·인프라·CS가 같은 화면을 보며 움직이고, 고객센터도 '확인 중입니다' 대신 예상 복구 시점을 안내할 수 있습니다. 경영진이 들여다볼 지표도 장애가 난 횟수가 아니라 인지까지 걸린 시간으로 옮겨갑니다.
실무에서는 세 가지를 구분해서 씁니다. 로그는 사건 하나하나의 기록(주문 실패, 인증 거부)이고, 지표는 분 단위로 집계한 숫자(CPU 70%, 오류율 2%)이며, 추적은 요청 하나가 서비스 다섯 개를 거치는 동안 어디서 3초를 썼는지 보여주는 경로입니다. 이 셋을 함께 보는 것을 관측성이라고 부릅니다. 로그는 DEBUG·INFO·WARN·ERROR로 레벨을 나눠 남기고, 경보 기준은 '서버가 살아 있나'가 아니라 '고객이 불편을 느끼나'로 잡아야 합니다. '5분 연속 결제 오류율 5% 초과' 같은 조건이 그래서 유효합니다. 보관 기간도 미리 정해 상세 로그 30일, 요약 지표 13개월처럼 비용과 추적 가능성을 맞바꾸는 설계를 해두는 편이 좋습니다.
가장 흔한 어긋남은 '일단 다 쌓고 보자'입니다. 저장 비용은 월 수백만 원씩 불어나는데 정작 장애가 터지면 로그가 너무 많아 검색이 안 되고, 결국 서버에 직접 들어가 tail 명령을 칩니다. 알림도 같습니다. 하루 200건씩 울리는 경보는 사흘이면 아무도 열어보지 않고, 진짜 장애 신호가 소음에 묻히는 상태는 알림이 아예 없는 것보다 위험합니다. 여기에 주민등록번호나 카드번호를 그대로 로그에 남겼다가 운영 장애가 개인정보 유출 사고로 번지는 사례도 적지 않습니다. 민감정보 마스킹 규칙은 도구를 고르기 전, 로깅 설계 첫날에 정해야 합니다.
시스템 운영의 기본 관행으로 오래 존재했고, 클라우드·마이크로서비스의 복잡성이 커지며 통합 로깅·모니터링(관측성, Observability)이 중요해졌습니다.
가상의 사례로 살펴보겠습니다. 수도권에서 온라인 식자재를 파는 A사는 임직원 180명, 연매출 약 900억 원 규모입니다. 새벽배송 주문 마감 직전인 밤 10~11시에 결제 실패 문의가 하루 40~50건씩 들어왔지만, 개발팀 답변은 늘 '서버를 재시작하면 되더라'였습니다. 원인을 못 찾은 채 3개월이 흘렀습니다.
- CTO가 서버에 직접 들어가 로그를 뒤지던 방식을 접고, 주문·결제·배송 API에 요청ID를 붙여 한곳에 모으게 했습니다. "누가 언제 어디서 막혔는지 한 화면에서 봅시다"가 지시의 전부였습니다.
- 인프라 담당 김 과장이 대시보드를 오류율·p95 응답시간·결제 대기열·DB 커넥션 네 개로 줄였더니, 첫 주 만에 밤 10시 20분마다 DB 커넥션이 상한 100개에 닿는 그래프가 눈에 들어왔습니다.
- '5분 연속 결제 오류율 5% 초과' 조건으로 슬랙 알림을 걸었는데 첫날 60건이 쏟아졌습니다. 임계치와 대상을 두 차례 손봐 하루 3건으로 줄인 뒤에야 팀원들이 알림을 열어보기 시작했습니다.
- 추적 데이터를 따라가 보니 재고 조회 쿼리 하나가 2.8초를 잡아먹고 있었습니다. 백엔드 이 책임이 인덱스를 추가해 0.3초로 떨어뜨렸고, 커넥션 풀도 100개에서 250개로 올렸습니다.
- 두 달 뒤 결제 실패 문의는 하루 45건에서 4건으로, 장애 인지 시간은 평균 40분에서 3분으로 줄었습니다. 복구까지 걸린 시간도 2시간에서 25분으로 짧아져 CS팀 야간 대기 인원을 2명에서 1명으로 조정했습니다.