분산 추적과 안전한 운영 로그를 함께 설계하는 법

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

운영 로그는 관련 사건을 연결할 수 있으면서 보관하면 안 되는 데이터를 노출하지 않을 때 가치가 있다. 분산된 요청 경로에서는 공통 트레이스 식별자로 처음부터 끝까지 연결하고, 그 흐름을 진단하는 데 필요한 최소 정보만 기록해야 한다. 로그 용량, 접근 권한, 보관 기간, 민감 필드는 한 설계 안에서 다뤄야 한다.

“상위로 예외를 던지기 전에 에러 로그를 남긴다” 같은 엄격한 규칙만으로는 유용한 증거가 생기지 않는다. 일관성도 중요하지만 운영에서 먼저 물을 것은 하나다. 실패한 요청 한 건이 거친 여러 서비스를 팀이 다시 구성할 수 있는가?

서비스 경계를 넘어 요청 하나를 따라간다

A 서비스가 B를 호출하고 B가 C를 호출한다면 세 서버의 분리된 로그만으로 같은 요청의 항목을 찾기 어렵다. 사용자가 비슷한 요청을 여러 번 보냈다면 시각과 사용자 ID만으로 어떤 결제 호출이 어느 주문 시도에서 나왔는지 추측해야 한다.

전체 경로에 하나의 트레이스 식별자를 전파한다. 각 로컬 작업은 다른 스팬 식별자를 가질 수 있지만 같은 트레이스를 공유한다. 중앙 로그 검색에서는 세 조각이 아니라 하나의 장애 흐름으로 사건을 볼 수 있다.

구체적인 추적 라이브러리는 바뀔 수 있는 구현 선택이다. 오래 남는 요구는 실제 HTTP나 RPC 경계를 넘어 상관관계를 유지하는 것이다. 이 부분의 불일치는 운영 가능성을 직접 해치므로 공통 계측을 작은 공유 구성 요소로 만드는 선택도 정당화될 수 있다.

편리한 직렬화가 비밀을 흘리지 않게 한다

요청과 응답 객체 전체를 범용 문자열 변환으로 로깅하면 위험하다. 데이터 클래스가 만들어준 표현을 그대로 남겼다는 이유만으로 비밀번호, 전화번호 같은 민감 값이 중앙 저장소에 쌓일 수 있다.

안전한 로그는 필드를 의도적으로 고른다. 민감 타입이 자체 표현을 통제하게 하거나, 공통 로깅 코드가 표시된 값을 마스킹하거나 제외할 수 있다. 방법보다 중요한 불변 조건은 새 필드가 추가됐다는 이유만으로 전체 객체 로그를 통해 운영자에게 노출되지 않는 것이다.

그렇다고 아무것도 남기지 않으면 안 된다. 요청 상관관계와 의미 있는 상태가 없으면 운영은 추측이 된다. 사건의 경로를 설명하는 식별자와 이벤트는 남기되 해결에 필요 없는 페이로드 세부 정보는 제외한다.

예외적인 감사 요구는 일반 로그와 분리한다

운영 환경의 전체 SQL 로그는 많은 용량을 만들고 파라미터를 노출하면서도 그에 맞는 운영 가치를 주지 못할 수 있다. 이는 기본적인 주의점이지 모든 시스템에 적용되는 금지는 아니다. 감사나 고객 지원 때문에 상세 증거가 꼭 필요한 경우도 있다.

정말 필요한 세부 정보라면 모든 애플리케이션 로그를 민감정보 저장소로 만들지 말고 별도로 격리한다. 허가된 역할만 접근하게 하고 필요한 기간만 보관하며, 적용되는 요구사항은 보안과 법무 담당자와 확인해야 한다. 운영 질문에 답하지 못하는 마스킹 데이터는 자동으로 유용하지 않고, 엄격한 통제 없이 원문을 남기는 것도 허용할 수 없다.

좋은 로그 정책은 네 가지를 함께 답한다. 요청을 어떻게 추적하는가, 어떤 필드를 남기는가, 누가 볼 수 있는가, 얼마나 오래 보관하는가. 하나만 최적화하면 다른 실패가 생긴다. 프라이버시 없는 추적은 데이터를 흘리고, 유용한 상관관계 없는 마스킹은 서비스를 운영할 수 없게 만든다.