강한 서사보다 정확한 사건 경계가 먼저다
배포 문제를 정리하다 보면 여러 실패를 하나의 원인과 결과로 연결하고 싶어집니다. 하지만 TravelPlanner에서 확인한 OIDC identity와 Launch Template 버전 문제는 같은 사건의 연속 단계라고 입증되지 않았습니다.
또한 별도의 Main Release 실패에는 테스트 컴파일과 변경 경로 분류 문제가 포함되어 있었고, ASG rollout은 그 범위 밖이었습니다.
그래서 이 글은 하나의 장애 연대기가 아니라 두 개의 배포 가드레일을 설명합니다.
가드레일 1: OIDC 신뢰는 repository identity까지 고정한다
GitHub OIDC를 사용하면 장기 AWS access key를 두지 않아도 됩니다. 그러나 federation을 쓴다는 사실만으로 신뢰 경계가 충분한 것은 아닙니다.
TravelPlanner에서는 role trust의 subject를 repository identity에 맞게 고정하고, Terraform 계획 단계에서 신뢰 조건을 검토했습니다. 이 변경은 read-only plan으로 확인한 범위와 실제 apply 또는 release 재실행으로 확인한 범위를 구분해 기록했습니다.
이 판단에서 중요한 점은 다음과 같습니다.
- 장기 키를 만들지 않는다
- repository와 branch 또는 environment 경계를 trust policy에 반영한다
- plan 성공을 배포 성공으로 확대 해석하지 않는다
- 로그에 credential이나 민감 식별자를 남기지 않는다
가드레일 2: ASG가 실제로 참조하는 버전을 고정한다
새 이미지 digest가 만들어져도 ASG가 기대한 Launch Template 버전을 참조하지 않으면 인스턴스 교체가 시작되지 않을 수 있습니다. 코드와 계획이 바뀌었다는 사실과 런타임이 새 버전으로 전환됐다는 사실은 다릅니다.
이를 분리하기 위해 이미지 digest 변경이 Launch Template revision과 Instance Refresh로 이어지도록 Terraform 경계를 보완했습니다. 이후 rollout 근거에서는 약 307초 뒤 두 target이 healthy였다는 기록을 확인했습니다.
다만 요청 연속성은 권한 제한 때문에 측정되지 않아 판정은 PASS_WITH_LIMITATIONS였습니다. 따라서 이 결과를 무중단 배포 성공이라고 쓰지 않습니다.
두 가드레일을 한 문장으로 합치지 않는 이유
OIDC subject는 누가 배포 권한을 얻는지에 관한 문제입니다. Launch Template version은 어떤 런타임 revision이 실제로 배포되는지에 관한 문제입니다.
identity guard
repository subject -> assumed role boundary
rollout guard
image digest -> launch template revision -> instance refresh -> target health
두 경계는 연결되지만 실패 원인과 검증 방법은 다릅니다.
- identity guard는 trust policy와 plan 검증이 중심
- rollout guard는 revision, refresh, target health가 중심
- release workflow의 test와 path classification은 또 다른 별도 경계
이렇게 나눠야 plan-only 확인, 런타임 확인, 측정하지 못한 항목을 섞지 않을 수 있습니다.
포트폴리오에 남긴 결론
개인 기여는 protove 비병합 커밋으로 확인되는 OIDC 신뢰 경계, ASG 이미지 갱신, CI 경로 정책, 관측과 recovery evaluator 범위로 한정했습니다. 두 target의 healthy 상태와 복구 판정은 팀 시스템의 측정 결과로 표현했습니다.
좋은 배포 설명은 모든 단계가 성공했다는 문장이 아닙니다. 누가 권한을 얻었는지, 어떤 revision이 배포됐는지, 무엇을 실제로 측정했는지, 무엇은 측정하지 못했는지를 서로 다른 증거로 연결하는 문장입니다.