website: 인스턴스 이름도 네이밍에 신경쓰자

확인해보니 원인은 인스턴스 이름 자체였다. OCI Compute 인스턴스의 표시 이름이 "likelion-prod"였는데, 실제로 이 인스턴스 하나가 stage와 prod 백엔드 컨테이너를 같이 호스팅하고 있었다. 그러니까 디스크 용량이나 메모리 사용률, git 드리프트처럼 호스트 전체에 걸리는 알람들도 인스턴스 이름을 그대로 따라가면서 "likelion-prod ..."로 붙었고, 이게 마치 prod 환경 전용 알람인 것처럼 보이게 만들었다. 반면 DB 백업, 이메일 실패, ERROR 로그 알람은 실제로 prod/stage가 나뉘어서 값이 따로 찍히는 것들이라 이름이 맞았다. 같은 "prod"라는 접두어를 붙였는데 하나는 호스트를 가리키고 하나는 환경을 가리키는 상황이었던 거다.

이 구분이 헷갈리는 이유가 인스턴스 이름 자체에 있었기 때문에, 코드보다 먼저 OCI 콘솔에서 인스턴스 표시 이름을 "likelion-server"로 바꿨다. OCID는 그대로 유지되는 순수 라벨 변경이라 재부팅은 필요 없었다. 호스트 전체를 가리키는 알람 3개(디스크·메모리·git 드리프트)의 display-name과 notification-title도 같이 "likelion-server ..."로 바꿔서, 이제 이름만 봐도 이게 물리 호스트에 대한 알람인지 특정 환경에 대한 알람인지 구분되게 했다. 이 부분은 OCI CLI로 직접 처리하고 서버 검증까지 마친 다음 PR을 올렸다.

코드에서 손댈 부분은 두 갈래였다. 하나는 custom_likelion 네임스페이스로 메트릭을 쏘는 push-*.py 스크립트 6개였는데, 여기 resourceDisplayName 차원에 하드코딩된 "likelion-prod" 문자열을 전부 "likelion-server"로 맞췄다. 이 값은 알람 판정에 쓰이는 resourceId와는 무관하고 그냥 "어느 호스트가 이 값을 보냈나"를 나타내는 라벨이라, 값만 바꾸면 되는 작업이었다.

dimensions={"resourceId": instance_id, "resourceDisplayName": "likelion-server"},

다른 하나는 어드민 알람 상태 화면(/admin/infra/alarms)이었다. 이 화면을 보다가 발견한 문제였으니, 같은 화면에 재발 방지 장치를 붙이는 게 맞다고 판단했다. AlarmStatusPanel.tsx에 likelion-server와 likelion-prod/likelion-stage가 각각 무엇을 가리키는지 짧게 설명하는 범례를 추가했다. 다음에 이 화면을 볼 사람(미래의 나 포함)이 다시 같은 혼동을 겪지 않도록 하려는 목적이다.

마지막으로 infra/docs/observability.md에 이번 경위와 새 규칙을 기록했다. "likelion-server = 알람을 실행·측정하는 물리 호스트 하나(stage·prod를 같이 서빙)", "likelion-prod/likelion-stage = 알람이 가리키는 환경(백업·이메일·ERROR 로그처럼 환경별로 값이 갈리는 것들만)"이라고 명시적으로 적어뒀다. 이름 하나 바꾸는 걸로 끝내지 않고, 앞으로 알람을 새로 추가할 때 같은 실수를 반복하지 않도록 규칙을 문서에 남겨두는 게 중요하다고 봤다. IAM 정책 쪽에도 read alarms verb가 이번에 추가된 걸 문서에 같이 반영했는데, 이건 어드민 화면이 알람 상태를 조회할 수 있어야 해서 필요했던 부분이다.

변경 규모 자체는 크지 않았다(추가 31줄, 삭제 13줄). 하지만 인프라 쪽 이름 하나가 알람 화면의 가독성과 판단 속도에 영향을 준다는 걸 실감한 작업이었다. 이름은 라벨일 뿐이지만, 그 라벨이 실제로 무엇을 가리키는지에 대한 합의가 깨지면 알람을 보는 사람이 매번 다시 판단해야 하는 비용이 생긴다. lint와 tsc 통과를 확인하고 OCI 콘솔에서 이름 변경도 재확인한 뒤 바로 병합했다.