쉬운 설명
운영 시스템에는 매초 수많은 일이 벌어집니다. 사용자가 로그인했고, API가 응답했고, DB 쿼리가 실패했고, 결제가 들어왔습니다. 그 흐름이 시간 순서대로 기록되어 있어야, 나중에 '어제 새벽 3시에 결제 오류가 왜 났나'를 답할 수 있습니다. 로그는 그 기록입니다.
좋은 로그는 단순한 텍스트가 아니라 구조화돼 있습니다. JSON 형태로 'timestamp·level·user_id·request_id·event·error_code' 같은 필드가 일관되게 들어 있어야, 도구가 검색·필터·집계할 수 있습니다. 또 모든 요청에 고유 ID(trace ID·correlation ID)를 붙여 두면, 한 사용자의 한 요청이 여러 서비스를 지나가는 흐름을 끝까지 따라갈 수 있습니다.
로그 레벨은 보통 다섯 단계입니다. DEBUG(개발 시 자세한 정보), INFO(정상 동작 기록), WARN(주의해야 할 일), ERROR(에러 발생), FATAL(즉시 대응 필요). 운영 환경에선 보통 INFO 이상만 남기고, 디버깅이 필요하면 DEBUG를 잠시 켭니다. 너무 많은 로그는 보관 비용이 늘 뿐 아니라 진짜 중요한 신호를 묻어 버립니다.
도구: 로컬에선 stdout에 출력, 운영에선 Fluentd·Logstash가 수집해 ELK(Elasticsearch·Logstash·Kibana)·Loki·Splunk·Datadog 같은 중앙 시스템에 보냅니다. 클라우드에선 AWS CloudWatch·GCP Cloud Logging이 매니지드로 제공됩니다. 어느 도구든 핵심은 '검색이 빠르고 보관 정책이 합리적인가'입니다.
주의: 로그에는 비밀번호·결제 번호·주민등록번호 같은 민감 정보를 절대 그대로 남기지 않습니다. 로그가 유출되면 그게 곧 사용자 정보 유출입니다. 마스킹·해싱·필드 제외 같은 정책을 처음부터 정해 두는 것이 안전합니다. 또 로그 보관 기간이 너무 짧으면 사고 추적이 어렵고, 너무 길면 GDPR 같은 규정 위반·비용 증가가 될 수 있어 균형이 필요합니다.
비유로 보면
로깅은 비행기의 블랙박스와 같습니다. 평소엔 그저 기록만 쌓이지만, 사고가 났을 때 그 안의 정보가 사고 원인 규명의 거의 전부가 됩니다. 잘 만든 블랙박스는 무엇을, 언제, 어떤 순서로 기록할지가 명확하게 정해져 있고, 보관 기간과 보안도 함께 고려돼 있습니다.
어디에서 만나나
모든 운영 시스템의 필수 인프라. 디버깅·사고 분석·감사 추적·보안 모니터링·성능 분석에 두루 쓰입니다. 마이크로서비스에서는 분산 트레이싱(OpenTelemetry)과 결합해, 여러 서비스를 거치는 한 요청의 흐름을 한꺼번에 볼 수 있게 합니다.
작은 예시
결제 실패 신고가 들어왔을 때, 운영팀이 'request_id=abc123' 한 줄로 로그를 검색하면 그 요청이 게이트웨이 → 결제 서비스 → 외부 PG → 알림 서비스를 거치며 남긴 모든 흔적이 시간 순서대로 따라옵니다. 어디서 5초 지연됐는지, 어느 응답이 500을 반환했는지가 1분 안에 보입니다.
자주 하는 오해
한 줄 정리
로그의 진짜 가치는 '사고가 났을 때의 1차 자료'에 있습니다. 평소엔 보이지 않다가 사고 5분 안에 답을 줘야 하기에, 잘 만든 로그 한 줄이 운영 비용을 크게 줄여 줍니다.