장애 재현을 위해 요청 로그를 늘리려는데 처리 지연과 개인정보 노출이 걱정됩니다. 어떤 필드를 남기고, 로그가 밀리면 무엇을 버리거나 보존하나요?

로그는 양보다 장애 때 답해야 할 질문에 맞는 맥락이 중요합니다. 결제 재시도라면 요청 ID, 결제 ID, 시도 번호, 결과 상태, 오류 분류와 지연이 유용하지만 전체 요청 본문을 그대로 남길 필요는 없습니다. 구조화된 로그는 검색·집계를 쉽게 하고, 토큰·비밀번호·결제정보·개인정보는 마스킹하거나 기록하지 않습니다. 동일 오류를 모든 계층이 반복 출력하면 저장 비용만 늘고 원인을 찾기 어려워집니다.

동기 로그는 요청 경로를 저장소 지연에 묶을 수 있고, 비동기 큐는 요청 지연을 줄이는 대신 큐 포화 시 대기·샘플링·드롭 중 정책이 필요합니다. 감사상 반드시 보존해야 하는 기록은 일반 debug 로그와 다른 내구성·접근권한·보관기간을 가져야 합니다. 상관 ID가 외부 입력이면 길이·문자 집합·개행을 제한해 로그 주입과 폭주를 막겠습니다.

로그 저장소가 느려지거나 장애가 나도 핵심 요청이 함께 무너지지 않도록 backpressure와 rate limit, 오류 집계를 둡니다. 부하와 로그 폭주를 재현해 요청 p95/p99(느린 요청의 95·99번째 백분위수), 큐 깊이, 유실률, 저장 비용을 확인하고, 오류 샘플 하나에는 충분한 stack·상관 ID를 남기되 민감값은 없도록 검증하겠습니다. 같은 결제 오류를 여러 계층이 각각 출력하는 사례에서는 한 계층이 원인과 상관 ID를 남기고 나머지는 중복 출력하지 않게 합니다. 좋은 로그는 장애 때 사용할 수 있으면서 장애를 증폭시키지 않아야 합니다.

기록할 질문을 먼저 정합니다

결제 재시도 원인을 찾으려면 요청 ID·결제 ID·시도 번호·오류 분류·지연·서비스 버전이 필요하지만 토큰·비밀번호·결제 수단·전체 본문은 남기지 않습니다. 외부 상관 ID는 길이·문자·개행을 제한하고, 사용자 식별자는 필요한 범위로 축약합니다. 최초 원인 계층은 stack과 원인을 남기고 상위 계층은 동일 ID와 요약만 기록해 한 오류가 수십 번 복제되지 않게 합니다.

포화 때 보존 우선순위를 둡니다

동기 로그는 저장소 지연을 요청에 전파하고, 비동기 로그는 큐가 차면 버릴 정책이 필요합니다. debug·정상 성공 로그는 샘플링할 수 있지만 결제 확정·보안 감사는 별도 내구성 채널과 접근권한·보관기간을 둡니다. 로그 sink 장애가 핵심 요청을 막지 않도록 큐 상한과 rate limit을 적용하되 유실량을 메트릭으로 남깁니다. 로그 폭주에서 p99, 큐 깊이, 유실률, 저장비용, 민감정보 탐지를 함께 측정해 상세화가 장애를 키우지 않는지 확인하겠습니다.

구체적인 경계 사례

로그를 호출하지 않는 수준으로 설정해도 문자열 보간이나 큰 객체 직렬화를 호출 전에 수행하면 CPU와 할당 비용은 이미 발생합니다. 지연 평가나 로그 수준 검사를 이용해 비활성 로그의 구성 비용도 줄입니다. stack을 매 요청 수집하는 비용과 동일 오류를 집계하는 비용을 비교하고, 반복 오류의 최초 사례와 누적 횟수를 함께 남기겠습니다.

감사 기록을 반드시 보존해야 하는 변경은 일반 비동기 로그 큐의 drop 정책에 맡길 수 없습니다. 같은 DB 트랜잭션의 감사 테이블이나 outbox에 기록하고 전송은 재시도할 수 있게 합니다. 기록에 실패했을 때 업무 변경도 거절할지 정책을 명시합니다. 로그 접근권한·보존기간·삭제·암호화뿐 아니라 검색 쿼리에 다시 민감값을 노출하는 경로까지 확인하겠습니다.