Sentry에 배포 릴리스가 안 잡힐 때, Railway 커밋 SHA 직접 주입하기

에러 알림은 오는데, 이게 어제 배포에서 생긴 건지 지난주 코드에서 생긴 건지 구분이 안 되던 적 없나요? 저도 Railway에 올려 둔 서버가 한참 그 상태였어요.

라이프케어로그의 법령·판례 검색 서비스인 플랜엘(plan-l) 서버를 Railway에서 운영하는데, Sentry 대시보드의 릴리스 탭이 계속 비어 있었어요. 배포는 잘 되고 에러도 잡히는데 릴리스만 0개였죠.

원인은 환경변수 이름 하나였어요

직접 확인해 보니 Railway는 배포마다 RAILWAY_GIT_COMMIT_SHA라는 환경변수에 커밋 해시를 넣어줘요. 문제는 Sentry SDK가 이 이름을 모른다는 거예요. SDK가 자동으로 읽는 건 SENTRY_RELEASE처럼 자기 규칙을 따르는 변수라서, Railway가 주는 값은 그냥 무시돼요.

배포 로그에 값을 찍어 보니 해시 자체는 매번 잘 들어와 있었어요. 값은 있는데 아무도 안 읽는 상태였던 거죠.

해결은 코드 한 줄이에요

Sentry 초기화에 release를 명시하면 끝나요.

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  release: process.env.RAILWAY_GIT_COMMIT_SHA,
});

넣고 다시 배포해 보니 릴리스 탭에 커밋 해시가 바로 잡혔어요. 고치는 데 걸린 시간은 10분이 안 됐는데, 원인을 찾기까지가 훨씬 길었죠. 테스트로 에러를 하나 일부러 던져 보니 방금 만든 릴리스에 정확히 묶였어요.

해시 40자가 그대로 보이는 게 길다 싶으면 slice로 7자리만 잘라 써도 돼요. 깃 로그의 짧은 해시와 같은 형태라 눈으로 대조하기 편해요.

릴리스가 잡히면 뭐가 달라지나

에러마다 처음 나타난 릴리스가 붙어요. 새 에러가 어느 배포에서 시작됐는지 역추적이 되니까, 최근 배포 두 번 중 어느 쪽이 문제인지 바로 갈라지죠. 혼자 운영하면 되돌릴 배포를 빨리 정하는 게 제일 큰 이득이에요.

정리하면, 플랫폼이 주는 환경변수와 SDK가 읽는 환경변수는 다를 수 있어요. 값이 있다는 것과 읽힌다는 건 별개라는 걸, 이번에 비어 있는 릴리스 탭을 보면서 배웠어요. 배포 파이프라인을 손볼 때 한 번쯤 릴리스 탭을 열어 확인해 보세요.