상황과 원인
사내 버셀은 GitHub의 push 이벤트를 받아 개발 서버에서 프로젝트를 빌드하고 배포했습니다. 의존성을 받으려면 PyPI 같은 외부 저장소로 아웃바운드 연결을 허용해야 했습니다.
인바운드뿐 아니라 외부로 열린 아웃바운드도 보안상 위험 요소라고 판단했습니다. 개발 서버의 연결 목적지를 GitHub 계열과 사내 서비스로 좁히기 위해, 외부 의존성이 필요한 빌드를 분리하기로 했습니다.
해결
GitHub Actions가 빌드 작업을 관리하고, 사내 전용 runner가 실행하도록 바꿨습니다. runner는 이미지를 빌드하고 테스트한 뒤 Private GHCR에 게시하고, 개발 서버의 Worker는 성공한 빌드의 이미지를 pull해 테스트하고 배포합니다.
빌드를 분리하자 push 수신만으로는 빌드 결과를 알 수 없었습니다. 이에 따라 배포 처리를 시작하는 이벤트를 workflow_run으로 교체하고, 빌드 상태 기록과 배포 판단도 Actions 실행 결과를 따르도록 수정했습니다.
| 선택 | 얻은 점 | 트레이드오프와 한계 |
|---|---|---|
| 개발 서버 빌드 → 사내 runner 빌드와 GHCR 전달 | 개발 서버에서 프로젝트 빌드를 위한 외부 의존성 접근 제거 | runner 운영과 이미지 전달 과정이 추가됨. 외부 접근은 runner로 이동 |
push → workflow_run | Actions 실행 성공을 확인한 뒤 배포 | 이미지가 있어도 workflow는 실패할 수 있음. 결과 이벤트가 누락되면 상태 확인이 멈출 수 있음 |
결과와 남은 과제
빌드 분리와 workflow_run 전환은 적용했습니다. 플랫폼이 확인할 범위도 직접 실행한 빌드의 성공과 실패에서 Actions 실행 상태와 이벤트 수신 여부까지 늘어났습니다.
누락된 빌드 결과를 찾기 위한 Actions 상태 주기적으로 조회하기
workflow_run이 오지 않으면 배포가 빌드 대기에 남을 수 있습니다. 플랫폼에서 GitHub Actions API를 주기적으로 조회해 실행 실패와 시작 지연을 감지하고, 누락된 결과를 보충하는 동작을 추가해야 합니다.
주기적 조회는 후속 작업입니다. 조회 주기만큼 감지가 늦어질 수 있고 GitHub API에도 의존합니다. API 조회 실패나 이벤트 미수신만으로 빌드 실패 또는 Actions 장애를 단정할 수는 없습니다.