5. 로그 없으면 추측뿐

사고 시나리오

사용자가 “어제 저장한 게 사라졌어요”라고 한다. 로그가 없다. 저장이 실패한 건지, 저장 후 누가 지운 건지, 애초에 저장을 안 한 건지 — 전부 추측이다. 추측으로 응대하니 고객 신뢰가 깎이고, 원인 파악에 하루가 넘게 걸린다.

원칙

로그는 두 종류가 필요하고, 서로 대체하지 못한다. 하나는 작업 감사 로그(누가 언제 무엇을 바꿨나), 하나는 런타임 에러 로그(무엇이 어디서 터졌나). 전자는 고객 응대와 분쟁 대응용, 후자는 장애 원인 파악용이다.

실무 처방

• 호스팅 플랫폼의 에러 로그·observability 기능부터 켠다. 설정 한 줄인데 꺼진 채 운영되는 경우가 많다.
• 돈·재고·권한이 걸린 핵심 쓰기 작업은 변경 이력 테이블에 남긴다: 실행자, 시각, 대상, 변경 전후 값.
• 에러를 잡아서(catch) 무시하는 코드를 금지한다. 최소한 로그는 남기고 삼킨다.
• 요청 단위 상관관계(request id)가 있으면 장애 시 한 사용자의 흐름을 이어 볼 수 있다 — 프레임워크가 주는 걸 그대로 써도 된다.
• 로그에 비밀번호·토큰·개인정보를 남기지 않는다. 로그는 오래 남고 넓게 공유된다.

체크리스트

• 플랫폼 에러 로그(observability)가 켜져 있다
• 핵심 쓰기 작업의 감사 로그(실행자·시각·전후 값)가 남는다
• 에러를 로그 없이 삼키는 catch가 없다
• 로그에 비밀·개인정보가 남지 않는다