lifecarelog
개발일지

CI 롤백이 엉뚱한 배포 ID를 집은 이유 (grep과 UUID 두 개)

배포 실패 시 자동 롤백을 붙이다 grep이 한 줄에서 UUID 두 개를 집는 버그를 만났어요. 사람용 CLI 출력을 파싱할 때의 함정과 수정 과정을 정리했어요.

5분 읽기

CI 롤백이 엉뚱한 배포 ID를 집은 이유

배포가 실패하면 자동으로 직전 버전으로 돌아가게 해두면 마음이 편해요. 그런데 그 "직전 버전"을 스크립트가 잘못 집는다면요? 어제 새벽에 제가 겪은 일이에요.

저장소 3개의 CI를 한 번에 정리했어요

혼자 여러 서비스를 굴리다 보면 파이프라인이 제각각이 돼요. 그래서 품질 게이트를 재사용 워크플로로 묶고 알림, 롤백, 커버리지 체크를 붙이는 작업을 저장소 3개에 같은 구조로 적용했어요. 로그인 없이 쓰는 무료 금융계산기 플랜씨(plan-c) 쪽만 해도 워크플로 파일 5개를 손봤어요. 계산기가 조용히 깨진 채 배포돼 있으면 안 되는 서비스거든요.

핵심은 롤백 단계였어요. 배포가 실패하면 직전 배포 ID를 찾아 그 버전으로 되돌리는 흐름인데, 배포 플랫폼 CLI가 보여주는 목록에서 grep으로 UUID를 뽑는, 어디서나 볼 법한 방식으로 만들었어요.

돌려 보니 한 줄에 UUID가 두 개

적용해 봤더니 롤백 단계가 이상한 ID를 집었어요. 출력을 다시 읽어 보니 목록 한 줄에 UUID가 두 개 찍히는 경우가 있었어요. 배포 ID 옆에 또 다른 UUID가 같은 줄에 나란히 나온 거예요.

UUID는 하이픈 포함 36자라 패턴 자체는 정확했어요. 문제는 grep이 패턴에 맞는 걸 전부 돌려준다는 점이었죠. "한 줄에는 UUID가 하나만 있다"는 가정이 스크립트에 몰래 들어가 있었던 거예요.

배포 목록 출력UUID 패턴 grep한 줄에 UUID 2개엉뚱한 ID가 롤백 대상

수정 자체는 작았어요. 줄에서 아무 UUID나 집는 대신 원하는 값 하나만 골라내도록 추출 기준을 좁혔고, 고친 파일은 deploy.yml 1개였어요. 파이프라인 정리 커밋을 올리고 5분 뒤에 수정 커밋을 다시 올렸죠. 테스트해 보면 금방 드러나는 버그인데, 만들 때는 왜 안 보였을까 싶었어요.

사람용 출력은 계약이 아니에요

직접 만들어 보니 이런 스크립트의 버그는 로직이 아니라 가정에서 나와요. CLI의 사람용 출력은 형식이 언제든 바뀔 수 있고, 지금 형식조차 내 가정과 다를 수 있어요. 뽑아낸 값이 기대한 형식의 값 하나인지 확인하고, 아니면 그 자리에서 실패하게 만드는 편이 엉뚱한 배포로 조용히 롤백되는 것보다 나아요.

  • 사람용 출력 파싱은 가정을 명시
  • 뽑은 값의 형식 검증
  • 틀리면 조용히 진행하지 말고 즉시 실패

롤백 스크립트는 평소엔 안 돌다가 가장 급한 순간에 처음 돌아요. 그래서 "성공했다"는 로그보다 스크립트가 집은 값이 진짜 맞는 값인지 한 번 더 의심하는 게 남는 장사였어요. 여러분의 롤백 스크립트는 마지막으로 언제 실제로 돌려 보셨나요?

#CI/CD#롤백#grep#빌드로그

라이프케어로그 서비스가 궁금하신가요?

AI 기반 건강·일정·재활 관리 앱을 직접 써보세요.

서비스 살펴보기

관련 글

댓글

아직 댓글이 없어요. 첫 댓글을 남겨주세요.