배포 환경을 묶어 보여주되, 존재하지 않는 대상을 만들지 않기

배포 화면에는 여러 프로젝트의 길고 비슷한 환경 이름이 한 목록에 섞여 있었습니다. 프로젝트와 환경을 차례로 고르게 만들면 찾기는 쉬워집니다. 하지만 화면의 그룹이 실제로 존재하지 않는 배포 대상을 만들어도 되는가는 다른 문제였습니다.

저는 처음에 제품 이름 규칙을 공용 배포 도구 코드에 담은 선택기를 만들었습니다. 동료 리뷰에서 한 제품의 규칙이 여러 팀의 도구에 들어간다는 지적을 받아, 표시 규칙을 해당 제품의 저장소 설정으로 옮겼습니다. 이 글의 중심은 화면에서 묶는 규칙과 실제 배포할 대상의 출처를 분리한 판단입니다.

첫 구현은 실행 입력을 바꾸지 않았다

첫 단계에서는 화면에서 프로젝트를 고르면 기존 배포 환경 목록을 좁히도록 했습니다. 각 선택지는 서버가 제공한 원래 환경 식별자를 유지했습니다. 그룹 이름은 화면에만 쓰고 배포 요청에는 기존 환경 이름을 보냈습니다. 분류할 수 없는 이름이 있으면 일부 환경을 조용히 숨기지 않고 원래 목록으로 돌아갔습니다.

리뷰는 규칙을 둘 위치를 바꿨다

한 제품의 이름 순서를 공용 코드가 해석하면 다른 저장소가 다른 규칙을 쓸 때마다 도구를 고쳐야 합니다. 리뷰를 받아 제품 저장소가 두 단계 표시 규칙을 선언하고, 공용 도구가 그 선언을 읽도록 바꿨습니다. 저는 화면뿐 아니라 필요한 Go 설정·API·명령행 도구의 연결과 제품 저장소의 선언을 함께 다뤘습니다. AI의 구현 도움을 받았고, 변경 범위와 검증할 도구·설정 버전의 조합은 제가 정했습니다.

설정은 환경의 표시 방법만 정했습니다. 존재하는 배포 대상은 계속 원본 환경 목록에서 가져왔습니다. 예를 들어 프로젝트 A에 운영 환경만 있는데 설정의 프로젝트 값과 환경 값을 곱해 검증 환경까지 만들면, 화면이 배포할 수 없는 대상을 발명합니다.

잘못된 표시 설정과 잘못된 실행 설정은 다르게 취급했다

표시 규칙이 잘못됐다면 경고를 남기고 원래 목록으로 돌아갈 수 있습니다. 반면 실제 배포에 필요한 설정이 잘못됐는데도 정상 목록처럼 보여주면 위험합니다. 실행 오류까지 목록으로 돌아가는 방식으로 숨기지 않았습니다. 그룹별 이력 조회도 그 그룹에 실제 존재하는 환경 이름으로만 요청했습니다.

공용 도구와 제품 설정을 한 조합으로 검증했다

새 설정이 들어가도 제품 전용 분기가 남아 있으면 같은 화면이 보일 수 있습니다. 그러면 새 선언이 실제로 쓰이는지 검증할 수 없습니다. 그래서 제품 저장소의 선언이 포함된 버전과 제품 분기를 제거한 공용 도구 버전을 함께 놓고 환경 선택과 실제 배포를 직접 확인했습니다. 로컬 UI 모양만으로 성공을 판정하지 않은 이유입니다.

후속 Lock·Rollback 화면도 같은 원본 환경 목록을 사용하게 했고, 환경을 바꾼 뒤 이전 요청의 늦은 응답이 현재 선택을 덮지 않도록 제한했습니다. 오래된 SHA의 branch guard는 DevOps 동료가 맡은 별도 작업입니다.

확인한 결과와 범위

도구와 제품 설정의 해당 조합에서 환경 선택과 실제 배포, 최근 대상의 Rollback 경로를 확인했습니다. 모든 팀의 저장소 설정에서 같은 결과가 나는지까지 검증한 것은 아닙니다. 이 작업의 핵심은 제품이 표시 규칙을 소유하고, 배포의 실체는 원본 환경 목록이 정한다는 경계를 공용 도구의 사용 경로에서 확인한 것입니다.