배포는 끝났는데 CI가 실패한다면 성공 판정과 대기 예산을 나눈다

CI가 배포를 요청하고 30초 뒤 시간 초과로 실패한다고 하자. 플랫폼이 180초 뒤 배포를 완료한다면 실패한 것은 배포일 수도, CI의 관찰일 수도 있다. 두 숫자는 대기 예산을 설명하기 위한 값이다.

이 글의 질문은 CI는 어느 상태까지 확인해야 원하는 버전의 배포를 성공으로 판정할까다. GitHub Actions에서 Elastic Beanstalk 배포를 기다리는 흐름을 예로 들어 성공 조건과 관찰 예산을 정의한다.

하나의 배포를 여섯 시점으로 나눈다

배포 API의 성공 응답은 요청을 수락했다는 의미일 수 있다. 그 뒤에도 인스턴스가 파일을 받고 프로세스를 시작하며, 로드 밸런서의 health 검사까지 통과해야 한다.

CI 실패 시각을 이 흐름과 맞추면 원격 배포 실패와 대기 종료를 구별할 수 있다. job 전체 제한, 액션의 polling 제한, 플랫폼 배포 command 제한, 단일 HTTP 읽기 제한도 따로 적는다. 한 값을 늘려 다른 구간의 실패를 숨기지 않는다.

Ready만 기다리면 버전 확인이 빠진다

AWS CLI의 environment-updated waiter는 describe-environments의 환경 상태가 Ready인지 확인한다. 공식 문서 기준으로 20초 간격, 실패 확인 20회 뒤 종료 코드 255를 반환한다. 사용한 CLI·액션이 같은 대기기를 호출하는지는 작업 설정에서 확인해야 한다. Waiter의 성공 조건.

환경이 Ready여도 기대한 버전이 배포됐다는 별도 확인이 필요하다. 다음은 환경 이름과 기대 버전을 입력받은 polling 핵심 예제다.

deadline = time.monotonic() + 600
while time.monotonic() < deadline:
    env = eb.describe_environments(
        EnvironmentNames=[environment_name]
    )["Environments"][0]
    if env["Status"] == "Terminated":
        raise RuntimeError("environment terminated")
    if (env["Status"] == "Ready"
            and env.get("VersionLabel") == expected_version):
        break
    time.sleep(10)
else:
    raise TimeoutError("expected version was not ready")

eb 클라이언트, 모듈 import와 입력 변수는 바깥에서 준비한다. 600초는 전체 관찰 예산이고 10초는 조회 간격이다. 네트워크 오류, 빈 환경 목록, API 제한에 대한 처리는 이 핵심 코드 밖에서 추가한다. 이 루프의 성공은 환경 상태와 버전 라벨 확인이며 모든 인스턴스의 업무 요청 성공을 증명하지 않는다.

상태 확인 뒤 서비스 응답을 연결한다

성공 판정은 플랫폼 상태, 애플리케이션 준비, 기대 버전의 응답으로 이어진다.

readiness가 통과한 뒤 서비스 경로로 작은 읽기 요청을 보내고 응답에서 빌드 ID나 버전을 확인한다. 캐시된 응답이나 이전 인스턴스의 한 번의 성공만으로 전체 전환을 판단하지 않는다. 배포 정책에 따라 모든 대상의 버전과 health를 확인하거나, 허용된 혼합 버전 구간을 명시한다.

smoke test에는 입력·예상 응답·인증 조건을 고정한다. 쓰기 요청이 필요하면 테스트 데이터의 생성·정리와 중복 방지 조건도 정한다. 단순 root 200은 프로세스 생존만 확인하고 핵심 의존성은 통과하지 않을 수 있다.

시간 초과 다음에 곧바로 재배포하지 않는다

CI가 관찰을 멈춰도 원격 배포는 진행 중일 수 있다. 재시도가 이전 배포와 겹치면 어느 버전의 이벤트인지 더 불분명해진다. 먼저 Beanstalk 이벤트, 환경 상태, 현재 버전과 instance health를 모아 진행·완료·롤백·실패를 구별한다.

실제 측정에서 정상 배포가 관찰 예산을 넘는다면 예산을 조정할 근거가 생긴다. 반대로 애플리케이션 시작이나 health 실패 때문에 오래 걸린다면 대기 시간 확대보다 해당 단계의 오류를 해결해야 한다. 같은 환경으로 들어가는 배포 작업의 동시 실행 정책도 함께 확인한다.

이 방식은 CI 실패와 원격 배포 완료가 다른 시점에 기록되는 상황에서 유효하다. 다음 점검에서는 실제 액션·대기기의 성공 조건과 종료 예산을 먼저 읽는다. 원하는 버전이 응답하는 확인 단계까지 정의해야 성공과 실패가 운영자가 같은 의미로 읽는 결과가 된다.