커밋 작성자 때문에 Vercel 배포가 멈출 때 확인할 것

저는 GitHub 계정을 두 개 씁니다. 하나는 블로그와 자동화 같은 개인 작업용이고, 다른 하나는 웨어룸·위코스모처럼 손님이 실제로 쓰는 서비스용입니다. 무료 한도를 나눠 쓰고, 실제 서비스를 개인 작업과 떼어 두려고 나눴습니다.

8월 27일 새벽, 이 두 계정 사이에서 배포가 멈췄습니다. 웨어룸 이용권 페이지에 '구독 중' 상태를 보여 주는 수정이었습니다. 코드를 올린 뒤 Vercel 배포가 빌드 단계에도 들어가지 못하고 'UNKNOWN'이라는 상태로 10시간 가까이 서 있었습니다.

원인은 코드가 아니라 커밋에 찍힌 작성자 이름이었습니다. 이름을 고쳐 다시 올리자 배포는 46초 만에 끝났습니다. 계정을 둘로 나눠 쓰시거나 AI 코딩 도구에 커밋을 맡기고 계시다면 같은 길이 열려 있을 수 있어서, 지나간 경로를 적어 둡니다.

무슨 일이 있었나

제 작업 PC에서 코드 수정과 커밋은 대부분 AI 코딩 도구가 합니다. 도구는 커밋을 남길 때 PC에 설정된 이름과 이메일을 작성자로 씁니다. 사람이 직접 커밋할 때와 같습니다.

git의 작성자 설정은 두 겹입니다.

PC 전체 기본값 — 따로 정하지 않은 저장소는 모두 이 이름으로 커밋됩니다.

저장소별 설정 — 그 저장소 폴더 안에서만 쓰는 이름입니다. 있으면 기본값보다 먼저 쓰입니다.

새로 옮긴 작업 PC에서는 기본값이 개인 계정으로 잡혀 있었고, 서비스 저장소에는 저장소별 설정이 없었습니다. 그래서 웨어룸 저장소에 남긴 커밋이 아무 경고 없이 개인 계정 이름으로 찍혔습니다.

커밋도 정상이었고, 푸시도 정상이었습니다. 커밋에 적히는 작성자 이름은 푸시할 때 쓰는 로그인과 별개라서, git은 이름이 달라도 아무것도 막지 않습니다. 멈춘 곳은 그다음, 배포였습니다.

로그가 없으면 어디를 봐야 하나

배포가 실패하면 보통 빌드 로그에 이유가 남습니다. 이번에는 로그가 아예 없었습니다. 배포 상태를 자세히 조회해도 돌아오는 답은 'UNKNOWN' 한 단어였습니다. 실패라고도, 대기 중이라고도 하지 않았습니다.

단서는 비대칭에서 나왔습니다.

이미 만들어 둔 배포를 다시 배포하는 것은 성공했습니다. 예전에 만든 빌드를 그대로 다시 쓰는 방식입니다.

새 커밋으로 배포하는 것만 막혔습니다.

빌드 설정이 잘못됐거나 Vercel 쪽에 장애가 있었다면 둘 다 막혔을 것입니다. 새 커밋에만 걸린다면 새 커밋 자체에 무언가가 있다는 뜻입니다. 그 저장소의 커밋 기록을 펼쳐 보니, 그동안의 커밋은 전부 서비스 계정 이름이었고 문제의 커밋 하나만 개인 계정 이름이었습니다.

Vercel 공식 문서에도 이 규칙이 적혀 있습니다. 비공개 저장소는 커밋 작성자를 Vercel 팀과 대조합니다. 무료(Hobby) 팀이면 커밋 작성자가 그 팀의 소유자여야 하고, 유료(Pro) 팀이면 팀 멤버여야 배포됩니다. 웨어룸 저장소는 비공개이고, 작성자를 서비스 계정으로 고치자 곧바로 배포됐으니 이 대조에서 걸린 것으로 보입니다. 다만 저희 화면에는 그런 안내가 뜨지 않았습니다. 상태 칸에 'UNKNOWN'이 떠 있었을 뿐입니다.

고친 방법: 코드는 그대로, 이름만 바꿨다

코드는 한 줄도 바꾸지 않았습니다. 마지막 커밋의 작성자만 서비스 계정으로 고쳐 다시 올렸습니다. 이미 올라간 커밋을 고쳐 덮어쓰는 일이라, 그사이 다른 변경이 올라와 있으면 덮지 않고 멈추는 방식(force-with-lease)으로 올렸습니다.

커밋을 처음 만든 시각이 밤 12시 55분, 작성자를 고친 시각이 오전 10시 33분이었습니다. 10시간 가까이 서 있던 배포가 이름을 고친 뒤에는 46초 만에 끝났습니다.

그다음 웨어룸과 위코스모, 두 서비스 저장소 모두에 저장소별 작성자 설정을 넣었습니다. PC 전체 기본값이 무엇이든 그 폴더 안에서는 서비스 계정으로 커밋됩니다.

같은 뿌리의 다른 사고: 저장소가 '없다'고 나올 때

6월에도 비슷한 일이 있었습니다. 이번에는 반대 방향이었습니다. 개인 계정의 비공개 저장소에서 최신본을 받아오려는데 'Repository not found', 저장소를 찾을 수 없다는 오류가 났습니다. 같은 PC에서 GitHub 명령줄 도구로 그 저장소를 조회하면 멀쩡히 보였습니다.

원인은 윈도우 자격 증명 관리자였습니다. 어느 로그인 창에서 서비스 계정으로 승인한 적이 있었는데, 그 뒤로 git이 GitHub에 접속할 때마다 그 계정을 꺼내 썼습니다. 그리고 GitHub는 권한 없는 계정이 비공개 저장소를 찾으면 '권한이 없다'가 아니라 '없다'고 답합니다. 그래서 저장소가 사라진 것처럼 보입니다.

해결은 git이 GitHub 명령줄 도구에 로그인된 계정을 쓰도록 연결하는 것이었습니다(gh auth setup-git). 자격 증명 관리자에 저장된 서비스 계정은 다른 곳에서 쓰고 있어 지우지 않았습니다.

두 사고는 겉모습이 전혀 다릅니다. 하나는 배포가 멈췄고, 하나는 저장소가 사라진 것처럼 보였습니다. 뿌리는 같습니다. 컴퓨터는 계정이 둘이라는 사실을 모르고, 어딘가에 저장된 하나를 조용히 씁니다.

계정을 둘로 쓴다면 확인할 다섯 가지

저장소마다 작성자를 박아 둡니다. PC 전체 기본값에 맡기지 말고, 기본값과 다른 계정을 쓰는 저장소에는 그 폴더 안에서 git config user.name과 user.email을 따로 정합니다. 이메일은 그 GitHub 계정에 등록된 주소여야 합니다.

커밋 직전에 한 번 대조합니다. 그 저장소의 작성자 설정과 기존 커밋들의 작성자가 같은지 봅니다. 커밋 기록 몇 줄이면 됩니다.

배포가 로그 없이 멈추면 작성자부터 봅니다. 예전 배포를 다시 배포하는 것은 되는데 새 커밋만 막힌다면, 코드보다 커밋 작성자를 먼저 의심합니다.

'저장소를 찾을 수 없다'면 삭제보다 계정을 먼저 봅니다. 비공개 저장소는 권한 없는 계정에 '없다'고 답합니다. 지금 git이 어느 계정으로 접속하는지부터 확인합니다.

PC를 옮기면 첫 순서로 넣습니다. 이번 사고는 새로 옮긴 PC에서 났습니다. 저장소를 새로 받은 뒤 작업을 시작하기 전에 1번부터 합니다.

AI 코딩 도구에 커밋을 맡긴다면 하나가 더 있습니다. 도구는 PC에 설정된 이름을 의심하지 않습니다. 사실 어느 저장소가 어느 계정인지는 4월부터 작업 규칙 문서에 표로 적혀 있었습니다. 그래도 사고는 났습니다. 표를 아는 것과 지금 이 저장소의 설정이 표와 같은지 확인하는 것은 다른 일이었습니다.

그래서 에이전트들이 일을 시작할 때 함께 읽는 지침서에 "커밋 전 계정 확인은 의무"라는 규칙을 넣고, 새 PC에서 서비스 저장소 두 곳에 작성자 설정부터 넣는 순서를 함께 적었습니다.

마치며

계정을 나눈 이유는 분명했고, 지금도 나눠 쓰는 편이 맞다고 봅니다. 다만 나눈 만큼 확인할 곳도 늘어납니다. 사람은 "이 저장소는 서비스 계정"이라고 알고 있어도, 컴퓨터는 설정에 적힌 이름만 압니다.

자동화가 올린 결과를 공개 화면까지 확인하는 절차는 자동화는 저장에서 끝나지 않습니다에, 같은 Vercel에서 블로그 사진 때문에 사이트가 멈춘 일은 Vercel 배포 용량 초과로 사이트가 멈췄습니다에 정리해 두었습니다.