로그(log)가 중요한 이유와 보는 방법: 장애 때 “감” 대신 근거로 움직이는 법

서비스가 느려지거나, 특정 기능이 안 되거나, 사용자 문의가 갑자기 늘면 개발팀이 가장 먼저 하는 일이 있습니다. “일단 로그부터 보자”입니다. 처음엔 이 말이 막연하게 들립니다. 로그가 뭐길래, 그리고 그 많은 글자들 사이에서 뭘 찾으라는 건지 감이 안 오죠.

하지만 실무에서는 로그가 사실상 “현장 CCTV”에 가깝습니다. 무슨 일이 언제, 어디서, 어떤 조건으로 일어났는지 남아 있기 때문입니다. 장애 대응에서도, 버그 수정에서도, 성능 개선에서도 로그 없이는 추측이 늘고 시간이 길어집니다. 그래서 로그(log)가 중요한 이유는 단순합니다. 감이 아니라 근거로 움직이게 해주기 때문입니다.

 

 

 

 

로그는 “무슨 일이 있었는지” 남기는 기록입니다

로그는 시스템이 남기는 사건 기록입니다. 사용자가 로그인 버튼을 눌렀다, 서버가 DB에서 데이터를 조회했다, 외부 결제사 응답이 늦었다, 특정 에러가 발생했다 같은 내용이 시간순으로 쌓입니다. 흔히 콘솔에 찍히는 출력도 로그고, 서버 파일로 남는 기록도 로그입니다.

중요한 건 로그가 단순한 텍스트가 아니라 “상황”이라는 점입니다. 운영 중인 서비스에서는 모든 문제를 눈으로 볼 수 없습니다. 사용자 화면은 안 보이고, 서버는 멀리 있고, 외부 연동은 더 멀리 있습니다. 그때 로그가 “지금 그쪽에서 무슨 일이 벌어졌는지” 알려줍니다.

체크 포인트

• 로그는 사건(이벤트)의 기록입니다
• 장애/버그/성능 이슈의 단서를 제공합니다
• 로그가 없으면 문제 해결이 추측 게임이 되기 쉽습니다

기록이 남으면 되짚을 수 있습니다.

 

왜 중요한가? 로그가 없으면 “원인 추적”이 거의 불가능해집니다

사용자 문의는 대부분 이렇게 들어옵니다. “아까 결제가 안 됐어요.” “로그인이 가끔 풀려요.” “저장 버튼을 누르면 튕겨요.” 여기에는 결정적인 정보가 거의 없습니다. 어느 시각인지, 어떤 계정인지, 어떤 기기인지, 어떤 화면 흐름이었는지 빠진 경우가 많습니다.

이때 로그가 있으면 이야기가 달라집니다. 같은 시간대의 요청을 찾아보고, 에러 코드가 있었는지, 응답 시간이 튀었는지, DB 쿼리가 느렸는지, 외부 API가 타임아웃이 났는지 확인할 수 있습니다. 즉, 로그는 “문제의 범위를 좁히는 도구”입니다. 범위를 좁히면 해결은 빨라집니다.

 

로그 레벨(level)을 알면 “무슨 성격의 메시지인지” 알 수 있습니다

로그는 보통 중요도에 따라 레벨로 나뉩니다. 제품이나 팀마다 이름은 조금 다를 수 있지만, 자주 쓰는 개념은 비슷합니다.

• ERROR: 실패/예외로 인해 기능이 제대로 수행되지 않은 상태
• WARN: 지금은 돌아가지만 위험 신호가 보이는 상태(곧 장애로 이어질 수 있음)
• INFO: 정상 흐름 기록(요청 시작/종료, 주요 이벤트 등)
• DEBUG: 개발/디버깅용 상세 정보(운영에선 과하면 부담이 될 수 있음)

초보자에게 추천하는 시작점은 ERROR부터입니다. 장애 상황에서는 WARN도 같이 봅니다. 그리고 “정상 흐름이 어디까지 진행됐는지” 확인하려면 INFO가 도움이 됩니다. DEBUG는 너무 많아서 오히려 길을 잃을 수 있으니, 필요할 때 켜는 방식이 일반적입니다.

 

로그를 보는 기본 순서: 시간 → 사용자/요청 → 에러 → 주변 맥락

로그를 처음 보면 한 줄 한 줄 읽다가 지치기 쉽습니다. 실무에서는 거꾸로 갑니다. 전체를 읽는 게 아니라, 필터링으로 좁힌 뒤 필요한 구간만 봅니다.

1) 시간부터 잡습니다
사용자가 “언제” 문제를 겪었는지 알면 그 시간대 로그를 좁힙니다. 시간이 없으면 범위가 끝없이 넓어집니다.

2) 사용자/요청 단서를 잡습니다
가능하면 사용자 ID, 주문번호, 세션 ID, 요청 URL 같은 키워드로 찾습니다. 이게 있으면 “그 사람의 흐름”을 따라갈 수 있습니다.

3) ERROR/WARN을 찾습니다
해당 시간대에 ERROR가 있는지, 어떤 메시지인지 봅니다. 에러 메시지는 대체로 원인을 바로 말해주진 않지만, “어느 구간에서 터졌는지”는 알려줍니다.

4) 앞뒤 로그(맥락)를 같이 봅니다
에러 한 줄만 보면 오해하기 쉽습니다. 에러가 터지기 직전 어떤 요청이 있었는지, 직후 어떤 처리로 이어졌는지 같이 보면서 흐름을 맞춥니다.

핵심은 ‘읽기’가 아니라 ‘추적’입니다.

 

추적 ID(Trace ID)

실무에서 로그를 잘 보는 팀은 보통 추적 ID를 씁니다. 한 번의 사용자 요청이 서버 여러 곳(게이트웨이 → 백엔드 → DB → 외부 API)을 거치면서 로그가 여러 시스템에 남는데, 추적 ID가 있으면 이 로그들을 한 줄로 묶어 따라갈 수 있습니다.

예를 들어 결제 요청 하나가 서버 A에서 시작되어 서버 B를 거쳐 외부 결제사 호출까지 갔다면, 각 서버 로그에 같은 trace_id가 찍히게 만드는 방식입니다. 그러면 장애 상황에서도 “이 요청이 어디에서 느려졌는지/터졌는지”를 빠르게 찾을 수 있습니다. 반대로 추적 ID가 없으면 서버마다 시간을 맞춰가며 추측해야 해서 시간이 늘어납니다.

 

실무에서 자주 보는 패턴: 타임아웃, 권한, 데이터 꼬임

로그를 보다 보면 비슷한 에러가 반복됩니다. 특히 아래 세 가지는 자주 등장합니다.

• 타임아웃: 외부 API나 DB가 느려져서 제한 시간 안에 응답을 못 받는 상황
• 권한/인증 문제: 토큰 만료, 권한 부족, 잘못된 인증 정보
• 데이터 문제: null 값, 예상과 다른 형식, 누락된 필드로 인한 예외

이런 패턴을 알고 있으면 로그에서 “아, 이쪽이구나” 감이 빠르게 옵니다. 물론 감으로 끝내는 게 아니라, 지표(에러율/응답시간)와 같이 확인하면서 근거를 쌓는 게 좋습니다.

 

로그를 ‘잘 남기는 법’도 중요합니다

로그는 보는 것도 중요하지만, 남기는 방식이 더 중요할 때가 많습니다. 로그가 너무 없으면 추적이 안 되고, 너무 많으면 바늘 찾기가 됩니다. 실무에서는 아래 요소가 들어간 로그를 선호하는 편입니다.

• 시간(타임스탬프)
• 레벨(ERROR/WARN/INFO 등)
• 요청 정보(엔드포인트, 메서드)
• 사용자/주문 등 식별자(개인정보는 마스킹)
• trace_id 같은 추적 키
• 에러의 원인(예외 메시지/스택 트레이스)

여기서 꼭 짚고 싶은 부분이 있습니다. 개인정보(비밀번호, 카드번호, 주민번호 등)는 로그에 남기면 안 됩니다. 실무에서 사고가 가장 크게 나는 지점이 이쪽입니다. 필요한 식별자는 마스킹하거나 대체 키를 쓰는 방식이 안전합니다.

 

로그 볼 때 “이렇게만” 해도 체감이 큽니다

처음부터 로그 시스템을 완벽히 이해하려고 하면 오히려 지칩니다. 아래 습관만 가져도 실무 대화가 편해집니다.

• 문제가 발생한 시간을 먼저 확보하기
• 가능하면 사용자/주문/요청 URL 같은 키워드 확보하기
• ERROR부터 찾고, 그 앞뒤 흐름을 보기
• 응답이 느리면 “에러”가 없어도 타임아웃/지연 로그를 의심하기

이 정도만 해도 “안 됩니다”에서 “어디에서 안 되는지”로 대화가 바뀝니다. 그 변화가 문제 해결 속도를 좌우합니다.

 

---

 

로그(log)가 중요한 이유는 서비스를 운영하는 동안 눈으로 볼 수 없는 일을 기록으로 남겨주기 때문입니다. 로그를 보는 방법은 결국 “읽기”가 아니라 “필터링하고 추적하는 습관”에 가깝습니다. 시간과 식별자부터 잡고, ERROR/WARN을 확인하고, 맥락을 따라가면 초보자도 충분히 길을 찾을 수 있습니다.