Git 푸시 403 에러 원인과 3분 만에 해결하는 완벽 가이드

Posted on by steve

 

Git 푸시 중 발생한 403 에러로 막히셨나요? 터미널에 나타나는 “The requested URL returned error: 403” 또는 “Permission denied” 문제의 명확한 원인 4가지와 즉시 해결 가능한 현실적인 해결책을 친절하게 정리해 드립니다!

 

프로젝트 마감을 앞두고 열심히 코드를 수정한 뒤 기분 좋게 git push origin main 명령어를 입력했는데, 갑자기 빨간 글씨로 403 에러가 튀어나와 식은땀을 흘려본 경험 다들 한 번쯤 있으실 거예요. 비밀번호도 분명 맞게 입력한 것 같고 네트워크도 멀쩡한데 도대체 왜 권한이 없다고 막아서는 건지 정말 답답하셨을 텐데요. 저 역시 예전에 회사 프로젝트 저장소에 커밋을 올리려다 이 에러 때문에 한 시간 넘게 헤맸던 기억이 있답니다. 오늘 포스팅에서는 깃허브 푸시 403 에러의 근본적인 이유부터 운영체제별 자격 증명 초기화, 토큰 재설정까지 한 방에 해결하는 실전 노하우를 아낌없이 풀어보겠습니다! 😊

 

1. Git 푸시 403 에러란 무엇인가요? 🤔

HTTP 응답 코드에서 403 Forbidden(금지됨)은 서버가 클라이언트가 누구인지는 알고 있거나 요청 자체는 이해했지만, 해당 요청을 수행할 권한을 부여하지 않겠다는 단호한 거절의 의미를 담고 있어요. 많은 분들이 401 Unauthorized(인증 실패)와 혼동하시곤 하는데요. 401이 “당신이 누구인지 신원을 증명하세요”라는 의미라면, 403은 “당신이 누구인지는 알겠는데, 이 저장소에 쓰기 작업을 할 자격은 없어요”라는 뜻에 가깝습니다.

특히 GitHub는 지난 2021년 8월부터 보안 강화를 이유로 일반 계정 비밀번호를 이용한 Git Git 작업 인증 방식을 완전히 중단했어요. 그 대신 개인용 액세스 토큰(Personal Access Token, PAT)이나 SSH 키 기반의 인증을 강제하고 있는데요. 이 때문에 오래전에 저장해 둔 비밀번호를 사용하거나 토큰의 유효 기간이 만료되었을 때, 혹은 저장소 권한이 없는 엉뚱한 부계정 정보가 로컬에 남아있을 때 바로 이 403 오류가 집중적으로 발생하게 됩니다.

💡 알아두세요!
터미널에 remote: Permission to [사용자A/저장소] denied to [사용자B]라는 메시지가 찍힌다면, 십중팔구 여러분의 컴퓨터가 ‘사용자B’의 자격 증명으로 깃허브에 접속을 시도하고 있다는 결정적인 증거예요!

 

2. 403 에러가 발생하는 4가지 핵심 원인 📊

원인을 정확히 파악해야 불필요한 삽질을 줄일 수 있겠죠? 실무에서 403 푸시 오류를 유발하는 대표적인 상황 네 가지를 알기 쉽게 비교 표로 정리해 보았습니다.

원인 분류 주요 증상 및 에러 메시지 발생 배경 해결 우선순위
1. 토큰 만료 및 권한 누락 The requested URL returned error: 403 PAT 유효기간 경과 또는 ‘repo’ 스코프 체크 해제 매우 높음 (1순위)
2. 로컬 자격 증명 꼬임 Permission to user/repo denied to other_user Windows 자격 증명 또는 Mac 키체인에 타 계정 캐시 잔존 매우 높음 (2순위)
3. 협업 권한(Collaborator) 미등록 Repository not found 또는 403 Forbidden 저장소 소유자가 내 계정을 팀원으로 초대하지 않음 보통 (3순위)
4. 원격지 주소(URL) 설정 오류 Permission denied to upstream repository Fork한 내 레포가 아닌 원본 upstream에 직접 push 시도 보통 (4순위)
⚠️ 주의하세요!
팀 프로젝트 진행 중 다른 사람의 리포지토리를 Fork하지 않고 직접 클론한 뒤 main 브랜치로 바로 push하려 하면 100% 확률로 403 오류를 마주치게 됩니다. 쓰기 권한을 부여받았는지 반드시 먼저 확인하세요.

 

3. 403 에러 완벽 해결 3단계 실전 가이드 🛠️

이제 에러를 시원하게 해결할 차례예요. 가장 빈번하게 발생하는 토큰 재발급부터 자격 증명 청소까지 순서대로 차근차근 따라와 주세요.

1단계: GitHub Personal Access Token (PAT) 재발급

GitHub 계정의 비밀번호 대신 사용되는 개인 액세스 토큰을 새롭게 발급하고 올바른 권한을 부여해야 합니다.

  1. GitHub 웹사이트에 로그인한 후 우측 상단 프로필 클릭 > Settings로 이동합니다.
  2. 좌측 최하단의 Developer Settings를 누르고 Personal access tokens > Tokens (classic)을 클릭합니다.
  3. Generate new token (classic)을 선택하고 Note에 용도(예: my-dev-token)를 적어줍니다.
  4. Select scopes 항목에서 가장 중요한 ‘repo’ (Full control of private repositories) 체크박스를 반드시 체크합니다.
  5. 초록색 Generate token 버튼을 누른 뒤 생성된 ghp_로 시작하는 토큰 문자열을 즉시 복사해 안전한 곳에 메모합니다. (이 창을 벗어나면 다시는 볼 수 없어요!)
📌 알아두세요!
토큰의 Expiration(만료 기간)은 보안상 30일이나 90일로 지정하는 것이 권장되지만, 잦은 재발급이 번거롭다면 개인 학습용에 한해 No expiration으로 지정할 수도 있습니다. 단, 토큰 유출에 극도로 유의해야 합니다.

2단계: 운영체제별 저장된 구 자격 증명 삭제

새 토큰을 만들었어도 컴퓨터의 자격 증명 관리자에 예전 만료된 비밀번호나 다른 계정 정보가 캐시되어 있으면 Git은 계속 그 오래된 정보로 인증을 시도해 403을 뿜어냅니다.

💻 Windows 환경에서 삭제하기

1) 시작 메뉴 검색창에 ‘자격 증명 관리자’를 입력하고 실행합니다.

2) ‘Windows 자격 증명’을 선택한 후 일반 자격 증명 목록에서 git:https://github.com 항목을 찾습니다.

3) 해당 항목을 클릭하여 ‘제거’를 누르거나, 편집을 눌러 암호 칸에 새로 발급받은 PAT 토큰을 붙여넣습니다.

🍎 macOS 환경에서 삭제하기

1) Spotlight(Cmd + Space)를 열고 ‘키체인 접근(Keychain Access)’ 앱을 실행합니다.

2) 우측 상단 검색창에 github.com을 검색합니다.

3) 검색된 github.com 인터넷 암호 항목을 우클릭하여 ‘삭제’를 진행합니다.

3단계: 터미널에서 신규 토큰으로 재인증 및 푸시

자격 증명을 지운 뒤 터미널 프로젝트 폴더에서 다시 푸시 명령어를 입력해 보세요:

$ git push origin main

Username for ‘https://github.com’: [본인의 GitHub 사용자명 또는 이메일 입력]

Password for ‘https://[사용자명]@github.com’: [1단계에서 복사한 PAT 토큰 붙여넣기]

화면에 비밀번호를 칠 때 글자가 안 보여도 정상적으로 입력되고 있는 것이니 당황하지 마시고 토큰을 붙여넣고 엔터를 치시면 됩니다. 이제 깔끔하게 원격 저장소로 푸시가 성공할 거예요!

 

4. 내 상황에 맞는 403 해결책 즉시 진단기 🧮

내가 겪고 있는 증상에 따라 어떤 방법이 가장 효과적인지 빠르게 체크해 볼 수 있는 간이 진단 도구입니다. 현재 본인의 상황을 선택한 뒤 진단하기 버튼을 눌러보세요.

🔢 Git 403 에러 맞춤 처방 진단기

현재 발생 상황:

 

실전 사례: 다중 계정(회사 vs 개인) 충돌로 인한 403 해결 👩💻👨💻

실무 개발자분들이 가장 고통받는 시나리오 중 하나가 바로 노트북 한 대로 회사 업무와 개인 사이드 프로젝트를 병행할 때 발생하는 계정 꼬임 현상이에요. 제 실제 경험 사례를 통해 어떻게 이 굴레를 영구히 벗어났는지 소개해 드릴게요.

상황 요약: 개인 프로젝트에 회사 계정으로 인증 시도

  • 사용자 환경: M2 맥북 프로, 글로벌 git config는 회사 이메일로 세팅됨
  • 발생 증상: 주말에 개인 오픈소스 레포에 push하자 Permission to my-personal/repo denied to company-user 발생

원인 분석 및 조치 과정

1) 키체인에 회사 계정의 토큰이 기본 자격 증명으로 등록되어 있어 HTTPS 요청 시 무조건 회사 계정 권한으로 전송되고 있었음.

2) 매번 키체인을 지우고 다시 로그인하는 방식은 업무 효율을 심각하게 떨어뜨리므로 SSH Key를 계정별로 2개 생성하여 분리하기로 결정.

3) ~/.ssh/config 파일에 아래와 같이 호스트 별칭을 설정:

# 개인 계정용 SSH
Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal

# 회사 계정용 SSH
Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_work

최종 결과

– 개인 프로젝트 원격 주소를 git remote set-url origin git@github.com-personal:my-personal/repo.git으로 변경 완료.

– 이후 계정 간섭이나 토큰 만료 문제 없이 두 계정 모두 완벽하게 독립적으로 푸시 성공!

컴퓨터 한 대에서 복수의 GitHub 계정을 다루셔야 한다면 HTTPS 주소 대신 이렇게 SSH 키와 config 파일을 활용해 호스트를 나누는 것이 정신 건강에 아주 이롭습니다.

 

마무리: 핵심 내용 요약 📝

Git 푸시 도중 403 Forbidden 에러를 마주했을 때 반드시 점검해야 할 핵심 수칙을 정리해 드립니다.

  1. 403 에러의 본질: 인증 자체가 안 된 것이 아니라, 현재 접속된 계정에 리포지토리 쓰기 권한이 없음을 뜻합니다.
  2. 토큰 만료 점검: GitHub의 일반 패스워드 인증 지원 중단 이후 PAT 토큰의 유효기간 및 ‘repo’ 권한 체크 여부가 가장 흔한 원인입니다.
  3. OS 자격 증명 캐시 초기화: Windows 자격 증명 관리자 또는 Mac 키체인에서 github.com 기록을 삭제해야 새 인증 정보를 묻는 창이 열립니다.
  4. 다중 계정은 SSH 분리 권장: 회사와 개인 계정을 함께 쓴다면 HTTPS 대신 SSH 키별 config 분리를 구성하세요.
💡

Git 푸시 403 에러 해결 한눈에 보기

✨ 1단계 진단: 누구의 계정으로 인증되는지 에러 문구 확인!
🔑 2단계 처방: GitHub PAT 토큰(repo 권한) 재발급
🧹 3단계 초기화:

Windows 자격 증명 / macOS 키체인에서 github.com 항목 즉시 삭제

🚀 다중 계정 솔루션: ~/.ssh/config 파일로 SSH 분리 관리

토큰 문자열은 비밀번호 창에 붙여넣어도 보안상 화면에 표시되지 않으니 바로 엔터를 치세요!

자주 묻는 질문 ❓

Q: GitHub 비밀번호를 정확히 입력했는데 왜 계속 403이나 401 에러가 발생하나요?
A: GitHub는 2021년 8월 13일부터 보안상의 이유로 Git 작업 시 계정 비밀번호 인증 지원을 전면 중단했습니다. 따라서 비밀번호 입력 창에는 실제 로그인 비밀번호가 아니라 발급받은 ‘개인용 액세스 토큰(PAT)’을 입력하셔야 정상 인증됩니다.

Q: PAT 토큰을 만들 때 어떤 권한(Scope)을 선택해야 푸시할 수 있나요?
A: 가장 상단에 위치한 ‘repo’ (Full control of private repositories) 전체 항목을 반드시 체크하셔야 원격 저장소에 커밋을 푸시하고 브랜치를 생성할 수 있는 쓰기 권한이 부여됩니다.

Q: Mac 키체인에서 github.com 항목을 지웠는데도 푸시할 때 여전히 동일한 403 에러가 뜹니다.
A: 키체인 외에도 터미널 전역에 자격 증명 헬퍼가 설정되어 있을 수 있습니다. 터미널에 git config --global --unset credential.helper 명령을 입력하여 캐시 헬퍼를 비활성화한 뒤 다시 푸시해 보세요.

Q: 오픈소스 프로젝트에 기여하고 싶은데 푸시할 때 403 에러가 나는 이유는 무엇인가요?
A: 오픈소스 원본 저장소는 메인테이너 외에는 직접 푸시 권한이 없습니다. GitHub 웹사이트에서 해당 저장소를 본인 계정으로 Fork(포크)한 후, 본인의 포크 저장소로 푸시하고 Pull Request(PR)를 보내셔야 합니다.

Q: HTTPS 방식과 SSH 방식 중 장기적으로 어떤 방식이 403 에러 방지에 더 유리한가요?
A: 장기적으로는 SSH 방식을 강력히 추천합니다. SSH 방식은 공개키/개인키 암호화 방식을 사용하여 토큰 만료 기간에 구애받지 않으며, 여러 계정을 전환할 때도 config 파일로 안전하게 관리할 수 있어 403 에러를 원천 차단하기 좋습니다.

오늘 알려드린 세 단계 가이드와 다중 계정 분리법을 활용하시면 더 이상 갑작스러운 403 에러 앞에서 당황하지 않고 여유롭게 대처하실 수 있을 거예요. 실습 도중 풀리지 않는 오류가 있거나 설명이 더 필요한 부분이 있다면 언제든 편하게 댓글로 남겨주세요~ 즐거운 코딩 생활 응원합니다! 😊