Cloudflare에서 GitHub 저장소가 안 보일 때: 사용자별 목록과 앱 승인·설치 점검

사용자 확인과 저장소 접근 범위를 두 개의 입구로 표현한 AI 생성 편집 이미지다. 실제 Cloudflare 화면이나 내부 구조도가 아니다.

같은 Cloudflare 계정에 들어갔는데 동료에게 보이는 GitHub 저장소가 내 화면에는 없을 수 있다. 이때 기존 연동을 지우거나 앱의 접근 범위를 모든 저장소로 넓히기 전에, 어떤 GitHub 사용자로 연결하고 있는지부터 확인해야 한다.

Cloudflare는 2026년 11월 10일 Workers Builds와 Pages의 저장소 선택 목록을 변경했다. 이전에는 Cloudflare 계정에 연결된 GitHub App 설치를 기준으로 목록을 구성했지만, 이제는 연결하는 사람의 GitHub 계정과 접근 권한을 반영한다. 이미 연결된 프로젝트는 이번 목록 변경의 영향을 받지 않고 계속 빌드된다. 공식 변경 기록

이 글은 새 프로젝트를 연결할 때 저장소가 사라진 것처럼 보이는 상황을 위한 점검 순서다. 실제 운영 계정의 권한이나 설치를 변경한 실험 결과는 아니며, 공식 발표와 문서를 기준으로 정리했다.

1. 앱 설치와 개인 승인은 서로 다른 설정이다

GitHub App을 설치하면 앱이 접근할 계정과 저장소 범위를 정한다. 개인 승인은 앱이 사용자를 식별하고 해당 사용자의 권한을 확인하는 별도 절차다. GitHub도 설치와 승인을 구분하며, 승인 과정에서 앱이 요청하는 권한을 확인하도록 안내한다. GitHub Apps 사용 안내

Cloudflare 연동에서는 다음 두 곳을 따로 본다.

조직 관리자가 앱을 설치했더라도, 새 저장소를 연결하는 사람은 자신의 GitHub 사용자로 한 번 승인해야 한다. 반대로 개인 승인을 완료했다고 조직 저장소에 앱이 설치되거나 저장소 접근 권한이 생기는 것도 아니다. Workers 설치·승인 문서

GitHub 설정의 두 탭을 혼동하면 “설치돼 있는데 왜 또 승인하라고 하지?” 또는 “승인했는데 왜 저장소가 없지?”라는 문제가 반복된다.

2. 다른 사람의 개인 계정은 협업 권한이 있어도 목록에 나오지 않는다

새 목록에는 앱이 설치된 내 GitHub 계정, 그리고 앱이 설치되어 있고 내가 저장소에 접근할 수 있는 조직이 표시된다. 다른 사람의 개인 계정은 그 사람이 저장소 협업 권한을 줬더라도 계정 목록에 표시되지 않는다. 공식 변경 기록

예를 들어 다음처럼 구분할 수 있다. 아래 이름은 설명용이다.

• 내 개인 계정의 my-user/site: 개인 계정에 앱이 설치되어 있고 해당 저장소가 설치 범위에 포함되는지 확인한다.

• 조직의 example-team/site: 내 저장소 접근 권한과 조직의 앱 설치 범위를 각각 확인한다.

• 동료 개인 계정의 colleague/site: GitHub에서 열리더라도 이번 계정 목록의 제외 조건에 해당할 수 있다.

마지막 경우를 해결하려고 앱을 반복 재설치하는 것은 우선순위가 아니다. 소유자에게 연결 담당자와 저장소 소유 구조를 확인하자. 이 항목들은 공식 목록 규칙을 적용한 점검 예시이며, 저장소 이전이나 권한 확대를 일괄 권장하는 뜻은 아니다.

3. 저장소가 보이지 않을 때 확인할 순서

먼저 현재 사용자와 저장소 소유자를 확인한다

브라우저의 GitHub 프로필에서 로그인 계정을 확인하고, 대상 저장소의 owner/repository를 기록한다. 회사 계정과 개인 계정을 함께 쓰는 경우에는 저장소 페이지를 열 수 있는 계정과 Cloudflare 연결에 승인한 계정이 같은지 비교한다.

이 단계에서는 승인 취소나 앱 삭제 없이 현재 상태만 확인한다.

개인 승인과 앱 설치를 각각 확인한다

Authorized GitHub Apps에서 Cloudflare Workers & Pages의 개인 승인을 살핀다. Cloudflare는 승인이 필요하면 저장소 연결 과정에서 GitHub로 안내한다.

그다음 Installed GitHub Apps에서 해당 소유 계정의 설치를 확인한다. 조직 저장소라면 설정의 계정 문맥을 조직으로 바꾼 뒤 확인한다. 내 계정이나 조직이 빠졌다면 Cloudflare의 Add GitHub account를 통해 설치를 진행하는 경로가 안내되어 있다. Workers 저장소 접근 문서

설치할 권한이 없는 조직에서는 관리자에게 해당 저장소의 앱 설치 범위를 확인해 달라고 요청한다. 단순 목록 확인을 위해 전체 저장소 접근을 열 필요는 없다. Cloudflare는 실제 빌드할 저장소만 선택하는 구성을 권장한다. Pages 조직 접근 문서

4. 목록 문제를 고치려다 정상 빌드까지 끊지 않기

개인 승인 취소(Revoke)와 앱 제거(Uninstall)는 영향 범위가 다르다. Cloudflare 문서는 GitHub 사용자를 바꿀 때 개인 승인을 취소하고 다시 연결하는 절차를 설명한다. 계정을 바꾸려는 목적이 맞는지 먼저 확인한 뒤 적용해야 한다. Workers 저장소 접근 문서

앱 자체를 제거하면 그 GitHub 계정의 저장소에 대한 Cloudflare 접근이 해제된다. Workers와 Pages가 같은 앱을 공유하므로, 이 저장소들에 연결된 프로젝트의 새 빌드가 중단될 수 있다. 이전에 배포한 사이트가 계속 열리더라도 새 배포 경로가 정상이라는 뜻은 아니다. Pages 접근 제거 문서

따라서 재설치를 고려한다면, 먼저 연결된 프로젝트와 마지막 성공 빌드를 기록한다. 운영 중인 연동을 삭제해 보는 방식보다 사용자·소유자·승인·선택 저장소 범위를 좁혀 확인하는 편이 안전하다. 이는 문서에 나온 영향 범위를 고려한 운영 제안이다.

5. 팀에서 남겨 둘 최소 점검 기록

다음 항목만 남겨도 담당자가 바뀔 때 확인할 수 있다. 토큰이나 비밀 키는 적지 않는다.

• 연결 작업에 사용하는 GitHub 사용자

• 저장소의 소유 계정 또는 조직과 이름

• 앱 설치를 관리할 담당자

• 설치 범위에 포함된 저장소

• 개인 승인 확인 여부

• 기존 프로젝트의 최근 빌드 상태

• 변경이 필요하다면 대상과 되돌릴 방법

연결 화면에 저장소가 나타나는 것, 기존 프로젝트가 빌드되는 것, 배포된 사이트가 응답하는 것은 각각 따로 확인한다. 점검 과정에서 새 빌드를 실행할 경우에는 운영 배포 여부와 비용을 먼저 확인하고, 팀에서 허용한 테스트 경로를 사용한다.

정리

이번 변경 이후에는 같은 Cloudflare 계정을 공유해도 저장소 목록이 같다고 가정할 수 없다. 현재 GitHub 사용자, 개인 승인, 앱 설치 범위, 저장소 소유 형태를 순서대로 살피면 불필요한 재설치와 권한 확대를 줄일 수 있다.

확인 기준일: November 11, 2026. 공식 발표일은 11월 10일이다.