CI 파이프라인 손보기: 재사용 게이트와 grep 한 줄의 함정

혼자 여러 프로젝트를 굴리다 보면 CI 설정이 프로젝트마다 조금씩 다르게 쌓여요. 이번 주에 플랜비(plan-b)·플랜씨(plan-c)·플랜엘(plan-l) 세 곳의 CI를 한 번에 손봤는데, 그 과정을 빌드로그로 남겨둡니다.

같은 로직을 세 번 복붙하지 않기

품질 게이트(테스트·린트·커버리지)를 세 프로젝트에 따로 적어두면, 한 곳을 고칠 때마다 나머지 두 곳도 똑같이 따라가야 해요. 그래서 이번엔 재사용 가능한 워크플로 하나로 묶고, 각 프로젝트는 그걸 불러 쓰게 바꿨어요. 2026-08-24에 세 저장소에 같은 방향으로 커밋을 넣었고, 품질 게이트·알림(notify)·롤백(rollback)·커버리지(coverage) 네 가지를 한 세트로 정리했습니다.

직접 적용해 봤더니, 게이트 규칙을 바꿀 때 한 곳만 고쳐도 세 프로젝트에 같이 반영돼서 손이 확실히 덜 갔어요.

• ✓재사용 품질 게이트
• ✓배포 알림
• ✓롤백 경로
• ✓커버리지 게이트

플랜비(plan-b) 쪽은 워크플로 파일 5개를 한꺼번에 건드렸어요. 의존성 업데이트 자동화(dependabot) 설정도 같이 넣어서, 업데이트 PR이 올라와도 같은 게이트를 통과하게 했고요.

grep 한 줄에서 UUID가 두 개 잡히던 일

롤백을 붙이려면 "직전 배포 id"를 알아야 하는데, 여기서 걸렸어요. 배포 목록에서 id를 grep으로 뽑았더니 한 줄에 UUID가 두 개 잡혀서, 롤백 대상 id가 두 개 붙은 채로 넘어왔어요. 직접 돌려 보니 값이 오염돼서 롤백이 엉뚱한 곳을 가리키더라고요.

증상만 보면 "grep 결과가 이상하다"지만, 원인은 한 줄에 후보가 여러 개일 수 있다는 걸 가정하지 않은 거였어요. 첫 UUID 하나만 확실히 집도록 파싱을 고쳐서(plan-c) 정리했습니다. 이런 건 로컬에서 한 번 돌려 보기 전엔 잘 안 드러나요.

배포 목록 조회→직전 id 추출→롤백 대상 확정

이번에 남긴 메모

• 게이트 로직은 한 곳에, 프로젝트는 호출만
• 롤백은 "직전 id 추출"이 제일 깨지기 쉬운 지점
• 파싱은 늘 "한 줄에 여러 개"를 의심하기

작은 도구를 여러 개 운영하다 보면, 공통 파이프라인을 한 번 정리해 두는 게 나중 반복을 줄여줘요. 플랜씨(plan-c) 같은 무료 계산기부터 플랜엘(plan-l) 법령 검색까지, 배포가 안전해야 다음 기능을 마음 편히 붙일 수 있으니까요. 완벽한 CI는 아니지만, "한 곳만 고치면 되는" 구조로 한 걸음 옮겨봤어요.