Git - remote: The project you were looking for could not be found or you don't have permission to view it.

2023-07-20

회사에서 운영 중인 프로젝트를 급하게 수정해서 배포해야 하는 상황이 생겼어요. 작업을 끝내고 push까지 성공해서 다 됐다고 생각했는데, 갑자기 GitLab CI/CD에서 이런 오류가 발생했어요.

remote: The project you were looking for could not be found or you don't have permission to view it.
fatal: repository '저장소주소' not found

원인을 찾기까지

처음에는 로컬 환경 문제라고 생각해서 로컬의 git origin 주소를 바꿔봤어요. 해결 안 됐어요. 그다음엔 GitLab Runner에 문제가 있다고 생각해서 Runner를 재등록했어요. 이것도 아니었고요.

몇 시간 고민한 끝에 찾아낸 원인은 생각보다 단순했어요. EC2 서버의 git origin 설정이 업데이트되어 있지 않았던 거였어요.

배포 환경이 EC2 + GitLab CI/CD로 구성돼 있었는데, CI/CD 파이프라인이 실행될 때 실제로 저장소에 접근하는 주체는 EC2 인스턴스예요. Runner가 파이프라인을 실행하면 EC2에서 git pull 같은 명령이 수행되는데, 이때 EC2 로컬에 설정된 remote URL을 써요. 여기에 인증 정보가 빠져 있으니 GitLab 입장에선 신원을 알 수 없는 요청이 된 거고, 권한 오류로 튕겨낸 거죠. 로컬 환경이나 Runner 자체는 아무 문제가 없었고, 처음부터 EC2의 git 설정만 봤어야 했어요.

인증 정보 포함 방법

EC2에 접속한 뒤 git remote set-url origin 명령으로 인증 정보가 담긴 URL로 교체해야 해요.

처음엔 가장 빠른 방법으로 아이디와 비밀번호를 URL에 직접 넣었어요.

# 이 방법은 보안상 위험해요
https://깃랩아이디:비밀번호@gitlab.com/프로젝트/프로젝트명.git

이렇게 하면 당장은 동작하지만, git remote -v 출력, CI/CD 로그, shell history 어디에서든 그대로 노출돼요. 나중에 이 문제를 알게 돼서 더 안전한 방법으로 교체했죠.

Deploy Token 사용

GitLab은 저장소 단위로 Deploy Token을 발급할 수 있어요. 계정 비밀번호와 달리 접근 범위를 읽기 전용으로 제한할 수 있고, 언제든 폐기도 가능해요.

GitLab 저장소의 Settings → Repository → Deploy tokens에서 토큰을 발급하고, Scopes에서 read_repository를 선택해요. 이후 EC2에서 remote URL을 교체하면 돼요.

git remote set-url origin \
  https://gitlab+deploy-token-{토큰ID}:{토큰값}@gitlab.com/프로젝트/프로젝트명.git

SSH Key 사용

EC2에서 키를 생성하고 공개 키를 GitLab에 등록하는 방식이에요.

# EC2에서 SSH 키 생성
ssh-keygen -t ed25519 -C "deploy-ec2"

# 공개 키 확인
cat ~/.ssh/id_ed25519.pub

공개 키를 GitLab 저장소의 Settings → Repository → Deploy keys에 등록한 뒤, remote를 SSH URL로 바꿔주면 돼요.

git remote set-url origin git@gitlab.com:프로젝트/프로젝트명.git

두 방법 모두 실제 계정 비밀번호를 노출하지 않고 접근 범위를 제어할 수 있어요.

CI/CD 인증의 전체 그림

이번 이슈를 계기로 "누가 git에 접근하는가"를 정리해봤어요. 파이프라인에서 에러가 나면 어디를 봐야 하는지 헷갈리는 이유가 이 구조를 명확히 이해하지 못해서인 경우가 많거든요.

개발자 로컬           GitLab            EC2 서버
─────────           ───────           ─────────
git push   →  저장소 업데이트  →  Runner가 파이프라인 트리거
                                  ↓
                              EC2에서 git pull
                              (EC2의 git 설정으로 GitLab 접근)

여기서 인증이 필요한 지점은 두 곳이에요.

개발자 → GitLab: 로컬에서 push/pull할 때. SSH 키나 계정 자격증명으로 처리해요.
EC2 → GitLab: 배포 스크립트에서 git pull할 때. Deploy Token이나 Deploy Key로 처리하고요.

이 두 지점은 완전히 독립적이에요. 개발자의 로컬 인증이 EC2 인증과 연결돼 있지 않거든요. 이번처럼 "로컬에서는 잘 되는데 배포에서 실패한다"는 상황이 오면, EC2의 git 인증 설정을 별도로 확인해야 해요.

돌아보며

이번 이슈에서 시간을 많이 쓴 이유는 "배포가 실패했으니 배포 관련 도구(Runner)가 문제겠지"라는 선입견 때문이었어요. 그런데 실제로는 파이프라인이 실행되는 EC2 환경 자체의 git 인증 설정이 문제였죠.

에러 메시지에 "not found or you don't have permission"이라고 분명히 적혀 있었는데, "권한 없음"을 "내 계정 권한 없음"으로만 해석하고 EC2 서버 자체의 인증 설정을 전혀 떠올리지 못했어요. 에러 메시지를 문자 그대로 읽고, "누가 이 요청을 보내고 있는가"를 먼저 파악했다면 훨씬 빨리 찾았을 거예요.