website: 관측·알림 인프라 설정 완료, 실발동 검증은 내일로

요약

2026년 7월 8일, infra/#83-observability-alerts 브랜치 작업의 진행 상황을 infra/CLAUDE.md에 기록했습니다. 커밋 메시지 그대로 옮기면 "내일 할 일 정리 — 재부팅·Alarm 발동·백업 부재 실증 3건"인데, 요지는 이렇습니다. UptimeRobot으로 외부 가동 감시를 붙이고, OCI Monitoring/Alarms으로 디스크·메모리·백업을 감시하도록 설정하고, 재시작 정책 드리프트도 고쳐서 PR(infra/#83-observability-alerts)까지 올려놨는데, "설정만 됐지 실제 발동까진 검증이 안 된 상태"라는 게 핵심입니다. 변경된 파일은 infra/CLAUDE.md 하나고, 6줄이 추가됐습니다.

배경 및 목적

#83 이슈는 관측·알림 기반을 만드는 작업이었습니다. 이전에 #75(이메일 발송 기반)까지 완료한 상태였고, 그다음 순서로 서버가 죽었을 때, 디스크가 꽉 찼을 때, 백업이 안 될 때 팀이 알 수 있는 체계를 만드는 게 목표였습니다.

문제는 "알림 시스템을 만들었다"와 "알림이 실제로 온다"가 다른 이야기라는 점입니다. Alarm 규칙을 콘솔에서 설정했다고 해서 그게 정말 임계치를 넘었을 때 FIRING으로 바뀌고 이메일이 날아오는지는 별개로 확인해야 합니다. 특히 백업 Absence Alarm처럼 "N시간 동안 신호가 안 오면 울린다"는 유형은 실제로 그 시간을 기다려봐야 검증이 되는 성격이라, 설정 완료와 검증 완료 사이에 시간차가 생길 수밖에 없었습니다.

구현 내용

이번 커밋은 코드 변경이 아니라 infra/CLAUDE.md 문서에 진행 상황과 다음 할 일을 기록한 것입니다. diff를 보면 기존 문서의 진행 이력 목록(#75 이메일 발송 기반 완료 기록 등) 바로 아래에 새 항목을 추가했습니다.

추가된 내용을 정리하면:

• 관측·알림 기반 (#83, ~7/30) 항목을 신설하고, 지금까지 완료된 것 3가지를 명시: UptimeRobot 외부 가동 감시, OCI Monitoring/Alarms(디스크·메모리·백업), 재시작 정책 드리프트 수정. PR도 infra/#83-observability-alerts로 이미 올라간 상태.
• 다만 2026-07-08 기준으로 3개 항목이 "설정만 됐지 실제 발동까진 검증 안 된 상태"임을 명확히 표시.
• 2026-07-09 예정 다음 할 일로 3가지를 번호를 매겨 남김:
  1. 재부팅 복구력 실측 — 인스턴스를 실제로 재부팅해서 nginx, backend-stage, backend-prod가 자동으로 다시 뜨는지 확인 (트래픽 적은 시간대에)
  2. 디스크/메모리 Alarm 실발동 확인 — 임계치를 실제로 넘기거나 테스트용으로 낮춰서 FIRING 전환 및 ONS 이메일 수신 확인
  3. 백업 Absence Alarm 발동 확인 — 2026-07-08 18:00 UTC 백업 성공 신호 기준 26시간 경과 시점(2026-07-09 20:00 UTC경)에 알림이 왔는지 로그로 확인
• 셋 다 확인되면 PR 머지 후 이슈 닫기로 마무리. 관련 상세 문서로 uptime-monitoring.md, observability.md를 링크해뒀습니다.

전체 패치는 6줄 추가, 삭제 없이 기존 목록 끝에 이어붙이는 형태라 아주 단순합니다.

기술적 의사결정

이번 커밋 자체는 문서 기록이라 새로운 기술 선택은 없었지만, 검증 방식을 짚어볼 만합니다. 세 항목의 검증 성격이 조금씩 다릅니다.

재부팅 복구력은 즉시 실행하고 결과를 바로 볼 수 있는 능동적 테스트입니다. 반면 디스크/메모리 Alarm은 임계치를 인위로 조작하거나 테스트용 값으로 낮춰서 강제로 발동시키는 방식을 택했는데, 이건 실제 임계치까지 시스템 상태를 몰아가는 것보다 훨씬 안전하고 빠르게 확인할 수 있는 방법입니다.

백업 Absence Alarm은 성격이 다릅니다. "부재(absence)"를 감지하는 알림이라 정상적으로 신호가 안 오는 상황을 인위로 만들기보다, 실제 백업 주기(26시간 기준)를 기다려서 로그로 확인하는 방식을 택했습니다. 이건 억지로 앞당길 수 없는 유형의 검증이라 하루 정도의 대기 시간이 자연스럽게 필요했던 것으로 보입니다.

배운 점 및 개선점

설정 완료와 실동작 검증을 분리해서 기록해둔 게 나름 도움이 됐습니다. PR을 올려놓고 바로 머지하지 않고, "검증되지 않은 항목"을 명시적으로 남겨서 다음 날 할 일을 놓치지 않게 한 부분입니다. 특히 백업 Absence Alarm처럼 시간이 걸리는 검증은 기록해두지 않으면 언제 확인해야 할지 까먹기 쉬운데, 정확한 시각(2026-07-08 18:00 UTC 기준 26시간 후)까지 못박아둔 게 다음 작업을 명확하게 만들어줄 것 같습니다.

다음 단계는 명확합니다. 7월 9일에 인스턴스 재부팅 테스트, Alarm 강제 발동 테스트, 그리고 백업 Absence Alarm 로그 확인까지 3건을 모두 실증하고, 통과하면 PR을 머지해서 #83 이슈를 닫는 것입니다.

참고 자료

• infra/uptime-monitoring.md
• infra/observability.md