로그를 작성하는 기준이 있나요? "인포는 인포용, 디버그는 디버그용이요.."

2025. 5. 30. 23:14·Infra

로그, 제대로 써보고 있나요?

시니어 개발자 선배님과의 커피챗에서 느낀 부끄러움

얼마 전, 시니어 개발자 선배님과 커피를 마시며 이런 질문을 받았습니다.

“로그를 어떤 기준으로 작성하세요?”

당황한 저는 이렇게 대답했습니다.

“음… 인포는 인포용, 디버그는 디버그용이요...”

그 순간, 제 안에 울려 퍼진 한 마디.

"이게 뭐 하는 소리야, 나 지금까지 그냥 감으로 로그 쓴 거였잖아?"


로그는 선택이 아니라 생존이다

로그는 단순히 콘솔에 뿌려지는 문자열이 아닙니다. 로그는 문제 해결의 첫 번째 열쇠이자, 운영의 나침반, 배포 후 유일한 증거물입니다.

시스템에서 장애가 났다?

→ 로그가 없으면 디버깅은 하늘에 별 따기.

유저가 데이터가 사라졌다고 한다?

→ 로그 없으면 "죄송합니다..." 말밖에 못 한다.


로그 작성 기준이 없다면, 이건 재앙이다

우리는 보통 console.log() 혹은 logger.info() 같은 익숙한 API만 보고 로그를 작성하지만, 그 안에 철학이 빠져 있다면 결국 쓸모없는 노이즈만 남습니다.

"지금 내가 찍는 로그, 나중에 다시 봐도 유용할까?"

로그 레벨, 아무렇게나 쓰면 안 된다

레벨                          목적                                   언제 써야 하는가

 

DEBUG 상세한 내부 정보 변수 값, 흐름 추적, 조건 분기 등. 개발자만을 위한 정보. 운영 환경에서는 꺼두는 게 일반적.
INFO 상태 변화, 중요한 흐름 기록 유저 로그인 성공, 주문 완료 등 주요 이벤트 발생 시. 운영에도 포함되는 기본 레벨.
WARN 이상하지만 동작은 계속 가능 예외는 발생하지 않았지만 비정상. 예: 재시도된 요청, fallback 동작.
ERROR 시스템 오류, 예외 발생 예외가 터졌고, 원인을 추적해야 하는 상황. Alert의 근거가 될 수 있음.
FATAL / CRITICAL 시스템 자체의 작동 불가 더 이상 프로세스가 지속 불가능한 수준. ex: DB 연결 실패, 필수 의존성 부재 등.

성능 기반 로깅 전략: 시스템 응답 속도로 로그 레벨 구분하기

어플리케이션의 상태에 따른 로깅 레벨을 설정하는 방법도 있지만, 성능적인 측면에서 로깅을 활용하는 접근 방식도 있다는 것을 선배님께서 알려주셨는데요, 예를 들면 아래와 같습니다.

"응답 시간이 기준에 미달할 경우 WARN이나 ERROR로 남기자."

예를들면, API 응답 속도가 100ms 보다 느리다면(사용자가 불편함을 느낄만큼 느려지거나, 기준보다 느려진다면) WARN으로 로깅을 하여, 더 심각한 문제가 생기기 전에 준비를 할 수 있습니다.

응답 시간                           로그 레벨                                       의미

≤ 100ms INFO 또는 DEBUG 성능 양호, 정상 처리 범위.
100ms ~ 500ms WARN 주의 필요. 일정 수준의 지연 발생.
500ms ~ 1s ERROR 심각한 지연. 원인 분석이 필요.
> 1s CRITICAL 또는 FATAL 시스템 병목 또는 외부 장애 가능성 큼. 알람 필요.

 

왜 이 방식이 좋은가?

  • 병목 추적에 특화
    단순 기능 동작 로그보다, 어디서 응답이 느려졌는지 명확하게 보여주기 때문에 성능 이슈 디버깅에 훨씬 강력합니다.
  • SLA 기반 품질 모니터링 가능
    SLA나 SLO 기준을 수치화하고, 로그를 통해 이를 위반한 요청만 분류하여 추적할 수 있습니다.
  • 알람 시스템 연동
    일정 지연 시간 이상일 때 로그 수집기를 통해 알람을 발생시키거나, 대시보드에서 자동 필터링할 수 있습니다.

로그 작성, 이제는 전략적으로

로그는 단순한 메시지가 아니라 서비스 건강 상태를 알려주는 중요한 신호입니다.

오늘 배운 내용을 잊지 않고 감에 의존하던 로그 작성은 그만두고, 명확한 기준으로 실질적인 가치를 주는 로그를 남기도록 해야겠습니다...

 

개발을 하면서 항상 느끼는 것이지만, 내가 하는 일에 왜? 라는 질문을 던졌을 때 근거가 떠오르지 않는다면, 다시한번 지금 하고 있는 일이 올바른 방향으로 흘러가고 있는지를 생각해봐야 합니다. 

 

선배님과의 대화를 통해, 놓치고 있던 중요한 부분을 5분만에! 알게 되어서 정말 다행이라고 생각합니다. ㅎㅎ

  

'Infra' 카테고리의 다른 글

[AWS] 퍼블릭 액세스 가능한 RDS를 VPC에 생성하기  (3) 2025.06.29
클라우드 인프라에서 HA(High Availability)를 보장하는 방법 고민  (1) 2025.06.24
WSL2에서 Cockpit 환경 실습하기: systemd 설정부터 접속까지  (0) 2025.05.30
Jenkins에서 SSL 인증서 문제 해결하기: skip-certificate-check 플러그인, 괜찮은가요?  (1) 2025.05.28
LightSwitch 서비스 인프라 트러블 슈팅 - Docker Network  (0) 2024.05.28
'Infra' 카테고리의 다른 글
  • [AWS] 퍼블릭 액세스 가능한 RDS를 VPC에 생성하기
  • 클라우드 인프라에서 HA(High Availability)를 보장하는 방법 고민
  • WSL2에서 Cockpit 환경 실습하기: systemd 설정부터 접속까지
  • Jenkins에서 SSL 인증서 문제 해결하기: skip-certificate-check 플러그인, 괜찮은가요?
HWBB
HWBB
흥미주도개발자
  • HWBB
    코딩공부방
    HWBB
  • 전체
    오늘
    어제
    • 분류 전체보기 (169)
      • 알고리즘 (66)
      • Android (27)
      • Kotlin (0)
      • Java (2)
      • Design Pattern (2)
      • React Native (1)
      • Python (0)
      • TIL (21)
      • Unity (0)
      • React (2)
      • AWS (0)
      • Git (11)
      • MFC (1)
      • Spring (4)
      • Computer Science (4)
      • Vue (4)
      • Infra (6)
      • 박현우 (10)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

    • 승윤이
  • 공지사항

  • 인기 글

  • 태그

    안드로이드
    코딩테스트
    알고리즘
    백준
    GIT
    안드로이드 스튜디오
    Java
    Kotlin
    프로그래머스
    Android
    coding
    자바
    baekjoon
    AWS
    programmers
    깃허브
    github
    코틀린
    android studio
    algorithm
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
HWBB
로그를 작성하는 기준이 있나요? "인포는 인포용, 디버그는 디버그용이요.."
상단으로

티스토리툴바