오류 한 줄이 안 보였다
3월, 운영 중인 Lambda에 로그가 너무 많이 쌓였다. 요청마다 경로와 값을 길게 찍고 있어서, 특정 사용자의 오류를 찾으려면 비슷한 줄을 한참 넘겨야 했다.
Lambda를 쓰며 개별 서버의 설치·기동을 직접 관리하는 일은 줄었다. 그렇다고 로그 보관, DB 연결, 배포 버전, 장애 복구까지 없어지는 것은 아니었다. 문제가 나면 무엇이 어떻게 실행됐는지 설명해야 했다.
따라 나온 질문
로그를 정리하다 보니 다른 질문에서도 막혔다.
- 지금 운영에 올라간 함수는 어느 커밋으로 빌드한 건가?
- 문제가 나면 어느 버전으로 되돌리고, 뭘 보고 복구됐다고 판단하나?
- 로그를 얼마나 보관하고, 거기 드는 돈은 얼마인가?
예전에 운영을 검토하며 적어둔 목록에도 같은 질문이 있었다. 로그만 줄여서는 답이 안 나왔다.
배포할 때 남기기로 한 것
커밋 SHA → 빌드 결과물 → 운영에 올린 버전 → 되돌릴 버전과 확인 방법
배포할 때마다 이 네 가지를 이어 적어두면 운영 중인 코드와 저장소를 바로 맞춰볼 수 있다. 로그는 오류와 요청 ID 위주로 남기고, 보관 기간과 비용은 함수별로 보기로 했다.
요청 ID는 같은 요청에서 나온 로그를 다시 모아볼 단서다. 구조화 로그는 메시지 한 줄에 모든 정보를 섞기보다 요청 ID·오류 종류 같은 항목을 나눠 기록하는 방식이다. 많은 로그를 남기는 것과 필요한 요청을 찾을 수 있는 것은 달랐다.
커밋 SHA는 소스의 버전을 가리킨다. 하지만 같은 소스라도 빌드 설정이 다를 수 있어, 실제 산출물과 운영 버전을 함께 남겨야 한다. 되돌릴 파일이 있어도 확인할 요청과 DB 상태를 모르면 복구됐다고 말하기 어렵다.
당시 정한 기준과 적용 기록
이 글은 로그 정리에서 배포 추적 기준으로 질문이 넓어진 과정이다. 위의 연결을 모든 서비스에서 자동으로 완성했다는 뜻은 아니다. 이후 운영 배포물·소스·설정의 해시를 맞춰 DEV 환경을 복원하고 기동·DB 읽기를 확인한 기록은 있다. 업무 배치와 cron까지 모두 정상이라는 확인과는 구분했다.