12. 로그와 모니터링, 나중 말고 지금 설계해야 하는 이유

보안·개인정보 업무를 하다 보면
“로그는 나중에 여유 생기면 정리하죠”라는 말을 자주 듣게 됩니다.

개발 일정은 항상 빠듯하고,
당장 눈에 보이는 기능부터 만드는 게 급하니
로그와 모니터링은 자연스럽게 뒤로 밀립니다.

그런데 막상 사고가 나거나,
점검이나 분쟁 상황이 생기면
가장 먼저 찾는 것이 바로 그 로그입니다.

로그는 나중이 아니라, 제일 나중까지 남는 것

서비스는 언젠가 종료되거나 바뀝니다.
하지만 그 서비스가 어떻게 운영됐는지,
누가 무엇을 했는지는
로그에 남습니다.

사고 분석, 고객 민원, 법적 분쟁,
규제기관 조사, 내부 감사…

어떤 상황이든
마지막까지 근거가 되는 것은
말이 아니라 기록입니다.
그리고 그 기록의 중심에 로그가 있습니다.

어떤 로그를 남길지 먼저 정해야 하는 이유

개발이 이미 다 끝난 뒤에
“이제 로그 좀 남겨 주세요”라고 부탁하면,
대부분은 최소한의 정보만 추가하거나
아예 손대기 힘들다고 말하는 경우도 있습니다.

그래서 가능하면 초기에
아래 정도는 합의하고 들어가는 편이 좋았습니다.

• 인증·로그인 관련 로그
  (누가, 언제, 어떤 방식으로 로그인/실패 했는지)
• 중요 데이터 접근 로그
  (민감한 개인정보나 주요 정보 자산에 접근한 기록)
• 권한 변경, 설정 변경 로그
  (권한 부여/회수, 주요 설정 변경, 계정 상태 변경 등)
• 오류·예외 로그
  (시스템이 예상하지 못한 상황에 처했을 때의 기록)

너무 많은 로그는 비용과 노이즈를 늘리지만,
너무 적은 로그는 사고 시
원인을 알 수 없게 만듭니다.
이 사이에서 균형을 찾는 것이 중요했습니다.

로그는 “있느냐”보다 “보일 수 있느냐”가 더 중요하다

로그를 잘 남기는 것도 중요하지만,
그 로그를 실제로 볼 수 있는지도 별개의 문제입니다.

• 어디에 저장되는지
• 누가 열람할 수 있는지
• 필요한 시점에 얼마나 빨리 찾아볼 수 있는지

이 부분이 정리가 안 되어 있으면
로그를 남기고도 제대로 활용을 못 하게 됩니다.

그래서 쌓는 것과 함께
운영팀이나 보안팀 입장에서
실제로 확인할 수 있는 경로를 같이 정해 두는 게 좋았습니다.

보안과 개인정보 관점에서 로그를 볼 때 신경 쓰는 부분

보안·개인정보 측면에서는
로그의 존재 자체뿐 아니라
로그 안에 어떤 정보가 들어 있는지도 중요합니다.

예를 들어

• 로그에 개인정보를 과도하게 담고 있지 않은지
• 마스킹이나 가명처리가 필요한 정보는 없는지
• 로그 자체에 대한 접근 통제가 되어 있는지

같은 부분을 함께 봅니다.

사고를 분석하겠다고
로그 안에 민감한 정보를 그대로 넣어 두면,
로그가 또 다른 리스크가 되기도 합니다.

나중에 설명할 수 있는 구조를 지금 만들어 두기

결국 로그와 모니터링을 설계하는 이유는
언젠가 문제가 생겼을 때
“우리가 무엇을 했는지” 설명할 수 있도록 하기 위함입니다.

완벽한 구조를 한 번에 만들 수는 없지만,

• 어떤 경우에 어떤 로그를 남길지
• 그 로그를 누가 어떤 절차로 볼 수 있을지

를 서비스 초기 단계에서 한 번만 짚고 넘어가도
나중에 감당해야 할 부담이 크게 달라졌습니다.

저 역시 여러 번의 시행착오 끝에
로그 설계는 “나중에 할 일”이 아니라
“처음에 한 번은 꼭 짚고 가야 하는 일”이라는 쪽으로 생각이 바뀌었습니다.