서비스 역할에 맞춰 운영 로그 확인하기

당시 운영 메모에는 사이트·API·어드민·옴니 연동 서비스의 로깅 옵션이 따로 정리돼 있었습니다. 역할이 다른 서비스에서 같은 옵션을 일괄 적용하기보다, 어느 요청을 확인하려는지에 따라 필요한 로그를 찾아야 했습니다.

사용자에게는 화면의 오류 하나로 보이더라도, 실제 원인은 API 호출이나 뒤에서 처리하는 연동 작업에 있을 수 있습니다. 화면에 나타난 증상에서 시작해 요청이 거친 서비스를 따라가는 방식으로 보는 것이 필요했습니다.

서비스 역할과 확인할 기록

다음은 당시 서비스 구분을 바탕으로 정리한 확인 관점입니다. 실제 로그 필드나 설정 키를 그대로 옮긴 표는 아닙니다.

각 서비스에서 오류를 찾았다고 요청 전체의 원인을 찾은 것은 아닙니다. 다른 서비스의 실패를 받아 같은 오류를 기록했을 수도 있으므로, 최초 실패와 후속 오류를 구분해야 합니다.

요청 흐름을 연결할 단서

시간과 식별자를 함께 사용하면 같은 요청에 해당하는 기록을 좁힐 수 있습니다. 시간만으로 찾으면 동시에 들어온 다른 요청이 섞이기 쉽고, 업무 식별자만으로 찾으면 여러 번의 시도나 후속 작업이 한꺼번에 나올 수 있습니다.

요청·작업 식별자가 서비스 사이에 전달되는지도 확인할 부분입니다. 전달되지 않는 구간에서는 다른 식별 정보와 시각을 함께 대조해야 합니다. 비동기 작업이라면 요청 종료 이후에 기록이 남을 수도 있습니다.

이런 단서를 로그에 넣을 때도 인증 정보나 요청 본문 전체를 그대로 남길 필요는 없습니다. 문제를 구분할 정보와 민감한 내용을 나눠야 로그를 공유하고 분석하기도 수월합니다.

평소 로그와 추가 진단

평소에 모든 상세 로그를 켜 두면 양이 늘어나고 처리 비용이 커집니다. 반대로 문제가 난 뒤 필요한 logger를 켜도 이미 지나간 요청의 상세 기록이 생기는 것은 아닙니다.

따라서 기본 로그에는 요청의 결과를 구분할 단서를 남기고, 추가 진단이 필요할 때는 관련 logger를 좁혀 확인하는 방식으로 나눌 수 있습니다. 당시 사용하던 log4jAdmin.jsp는 재배포 없이 logger 레벨을 바꾸는 도구였습니다.

로그를 더 보려는 목적과 설정을 유지할 시간도 함께 정해야 합니다. 동적 변경의 적용 범위와 복원은 운영 로그 레벨 조정 글에서 따로 다뤘습니다.

로그와 실제 처리 결과

로그는 코드가 남긴 기록입니다. 성공 로그가 출력된 시점이 DB 반영 전인지 후인지, 외부 시스템에 요청을 보낸 시점인지 응답까지 확인한 시점인지에 따라 의미가 달라집니다.

로그를 읽을 때는 해당 메시지가 어느 단계에서 남는지 확인하고, 필요한 경우 저장된 상태나 상대 시스템의 결과와 대조해야 합니다. 메시지의 표현과 실제 처리 단계를 맞추는 일이 로그를 많이 남기는 것보다 먼저였습니다.

다음 글에서는 어드민 세션 조회와 관리 권한을 살펴보겠습니다.