바로 답변 artifact가 성공했다는 건 빌드 결과물 생성까지는 통과했다는 뜻입니다. 그래서 먼저 의심할 곳은 코드 자체보다 deploy step이 따로 필요로 하는 값입니다.

보통은 아래 순서로 보면 가장 빨리 원인이 잡힙니다.

1. deploy step 전용 환경변수/secret

• 예: VERCEL_TOKEN, AWS_ACCESS_KEY_ID, SSH_KEY, CLOUDFLARE_API_TOKEN
• 빌드에는 안 쓰지만 배포에서만 필요한 secret이 빠져 있거나, 이름이 바뀌었거나, 환경별로 다른 값일 수 있습니다.

2. deploy 대상 설정이 맞는지

• 어떤 브랜치에서만 배포되게 해놨는지
• production/staging 환경이 섞이지 않았는지
• 배포 대상 프로젝트 ID, 앱 이름, 버킷 이름, 서버 주소가 틀리지 않았는지

3. GitHub Actions 권한 문제

• permissions 설정이 너무 좁아서 OIDC 토큰 발급이나 repository read가 안 되는 경우가 있습니다.
• GitHub Environments를 쓰면 승인 대기, 환경 보호 규칙, environment secret 누락도 확인해야 합니다.

4. artifact 내용과 deploy step 기대값이 같은지

• artifact는 올라갔지만 deploy step이 찾는 경로가 다를 수 있습니다.
• 예: dist/를 업로드했는데 deploy에서는 build/를 찾는 경우
• 압축을 풀 위치나 working directory가 달라서 파일이 없다고 실패하기도 합니다.

제일 먼저 볼 로그 포인트 배포 step 로그에서 아래 표현을 먼저 찾으세요.

• permission denied / forbidden / unauthorized → 권한·토큰 문제
• not found / no such file or directory → artifact 경로·압축 해제·working directory 문제
• invalid token / bad credentials → secret 값 자체 문제
• domain/project/app not found → 배포 대상 식별자 문제
• timeout / ECONNRESET / ENOTFOUND → 네트워크 또는 외부 서비스 접속 문제

이렇게 에러 문구를 먼저 분류하면, 코드 다시 빌드해보는 것보다 훨씬 빨리 좁혀집니다.

먼저 해볼 것 - deploy step 바로 앞에 pwd, 결과물 디렉터리 확인, 필요한 env 존재 여부를 민감값 제외하고 찍어보세요. - artifact 다운로드 후 실제로 어떤 파일이 생겼는지 ls -R 수준으로 확인하세요. - 최근에 바뀐 것이 workflow yaml, secret 이름, 배포 대상 설정인지 먼저 diff로 보세요.

한 줄 정리 artifact 성공 + deploy 실패는 대개 빌드 문제가 아니라 배포 단계 전용 secret, 권한, 경로, 대상 환경 설정 중 하나입니다.