운영 로그는 어떻게 설계하고 봐야 하는가
운영 로그는 장애 대응과 실시간 관찰의 기본 도구였습니다. 문제는 로그를 많이 남기는 것 자체가 목적이 아니라, 필요할 때 해석 가능한 형태로 남기는 것이었습니다.
로그를 설계한다는 것
운영 로그를 설계할 때는 서비스 단위로 로그 관점을 다르게 가져가야 했습니다. site, api, admin, omni처럼 역할이 다른 서비스는 애초에 관찰해야 할 지점이 달랐기 때문입니다. 고객 요청을 다루는 흐름과 운영자가 쓰는 관리자 기능은 같은 기준으로 보면 안 됐습니다.
로그를 설계할 때 중요했던 건 다음과 같습니다.
- 어디서 문제가 났는지 빠르게 좁힐 수 있는가
- 운영자가 요청 흐름을 따라갈 수 있는가
- 상시 로그량을 감당할 수 있는가
- 필요할 때 더 많은 단서를 확보할 수 있는가
즉 로그는 단순 텍스트 출력이 아니라 운영용 인터페이스였습니다.
로그를 나중에 읽는 사람은 대부분 로그를 남긴 사람이 아닙니다. 운영자이거나, 다른 개발자이거나, 몇 달 뒤의 미래의 나일 가능성이 큽니다. 그래서 로그는 “지금 내가 찍기 편한 문자열”보다 “나중에 누가 봐도 흐름이 이어지는 단서”가 되어야 했습니다.
서비스별 로그 관점이 달랐던 이유
site는 사용자 경험과 직결되고, api는 시스템 간 호출과 연동 흐름이 중요하고, admin은 운영자 액션과 권한 흐름이 중요합니다. 같은 에러라도 어느 레이어에서 봤는지에 따라 의미가 달라집니다.
그래서 로그는 “모든 걸 한 군데에 많이 남기는 방식”보다, 서비스별 관점을 나누고 필요한 순간에 깊이를 조절하는 방식이 더 유효했습니다.
이 구분이 중요한 이유는, 문제를 좁히는 순서 자체가 달라지기 때문입니다. site에서 보이는 이상 징후가 꼭 site 레이어 문제라는 뜻은 아니고, api나 배치, 캐시, 연동 시스템의 문제일 수도 있습니다. 로그가 서비스별 관점으로 정리돼 있지 않으면 이런 흐름을 추적하기가 훨씬 어려워집니다.
운영 중 로그를 다루는 방식
상시로 디버그 로그를 많이 남기기는 어렵습니다. 그래서 필요한 순간에만 로그 레벨을 올려 더 많은 단서를 확보하는 방식이 중요해졌습니다. 이 지점은 다음 글에서 다룰 log4j 기반 런타임 동적 로그 레벨 조정 도구와 직접 연결됩니다.
결국 운영 로그 설계의 핵심은 두 가지 균형입니다.
- 평소에는 너무 무겁지 않게 유지할 것
- 필요할 때는 충분히 깊게 들어갈 수 있을 것
이 균형을 잡지 못하면 로그는 either 소음이 되거나, 반대로 아무 단서도 남기지 못하는 장식이 됩니다.
실제 운영을 돌리다 보면 TTL 적용 및 간헐적 발생 메모리 수정 같은 문제가 같이 따라옵니다. 운영 로그는 단지 에러를 기록하는 용도가 아니라, 메모리 문제나 세션 최적화처럼 당장 눈앞에서 재현되지 않는 문제를 다시 좁혀갈 수 있게 해주는 단서여야 했습니다. 그래서 로그 설계와 운영 도구화는 따로 떨어진 주제가 아니라 같은 축에 있었습니다.
다음 글에서는 어드민 세션 관리 기능이 왜 필요했는지를 통해 운영 도구화 관점을 이어서 정리합니다: 어드민 세션 관리 기능은 왜 필요했는가