Railway 배포에서 Sentry release를 git SHA로 고정하는 법

AI 워크플로우를 운영하다 보면 오류 메시지만으로는 원인을 좁히기 어려워요. n8n에서 자동 생성한 요청이 실패했을 때, 어떤 배포의 어떤 코드가 실행됐는지 연결해야 다음 프롬프트 수정이나 재시도 규칙을 판단할 수 있어요.

Railway는 배포 환경에 RAILWAY_GIT_COMMIT_SHA를 제공할 수 있지만, Sentry SDK가 이 이름을 release로 자동 인식하지는 않아요. 그래서 애플리케이션 시작 시점이나 Sentry 초기화 설정에서 release 값을 직접 전달해야 해요.

제가 직접 만들어 보는 기준은 단순해요. 배포마다 release가 하나이고, 오류 이벤트에도 같은 값이 남아야 해요. git SHA 전체는 보통 40자지만, 화면에서 빠르게 비교할 때는 앞 7자만 별도로 표시해도 충분해요. 다만 Sentry release 값 자체는 짧게 자르지 않고 전체 SHA를 쓰는 편이 추적에 안전해요.

환경 변수는 최소 3개 흐름으로 확인해요. 로컬 개발값, Railway 배포값, Sentry에 실제 기록된 release예요. SENTRY_RELEASE를 우선 읽고 값이 없을 때 RAILWAY_GIT_COMMIT_SHA를 읽도록 두면, 실행 환경의 차이를 한곳에서 다룰 수 있어요.

const release =
  process.env.SENTRY_RELEASE ??
  process.env.RAILWAY_GIT_COMMIT_SHA
 
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  release,
})

테스트해 보면 release가 없는 오류와 SHA가 붙은 오류의 조사 속도 차이가 분명해요. 첫 번째는 배포 기록과 로그를 다시 대조해야 하지만, 두 번째는 오류 화면의 release로 배포 단위를 바로 찾을 수 있어요. 저는 자동화 오류를 볼 때 오류 시간, workflow 실행 ID, release의 3가지를 함께 확인해요.

돌려 보니 n8n 같은 자동화는 코드 변경보다 프롬프트나 입력 데이터 변경이 더 자주 원인처럼 보일 때가 있어요. 그래도 release를 먼저 고정하면, 같은 입력이 어느 배포부터 달라졌는지 분리할 수 있어요. 프롬프트 수정 전후를 비교하는 실험에도 유용해요.

라이프케어로그처럼 여러 제품을 운영할 때도 이 방식은 공통 기반이 돼요. 플랜비(plan-b)나 플랜엘(plan-l)처럼 서로 다른 서비스라도 배포 식별 규칙을 맞추면, 자동화 작업의 실패를 제품별로 흩어 보지 않고 같은 기준으로 살필 수 있어요. 적용해 볼 때는 먼저 10분 안에 오류 이벤트 하나를 만들어 release가 표시되는지만 확인해 보세요.