깃허브 조직 권한 설정하는 법의 시작은 현재 개인 계정에 직접 부여한 저장소 권한을 먼저 목록으로 정리하는 일이다. 지금 바로 조직의 People, Teams, Repositories 화면을 열어 누가 어느 저장소에 접근하는지 캡처하거나 표로 옮겨라. 이 작업이 빠지면 팀을 만든 뒤에도 예외 권한이 남는다.
핵심은 단순하다. 사람에게 권한을 주지 말고 팀에 권한을 준다. 입사·부서 이동·퇴사 때 계정 하나씩 수정하는 방식은 누락이 생기기 쉽고, 비공개 코드가 예상보다 오래 열려 있는 원인이 되기도 한다.
깃허브 조직 권한 설정하는 법의 기본 구조
GitHub Organization은 조직 역할, 팀, 저장소 권한을 구분해서 관리한다. 조직 소유자(Owner)는 결제와 보안 정책, 멤버 관리, 저장소 관리까지 폭넓게 다루므로 인원을 최소화하는 편이 좋다. 평소 개발 업무를 하는 구성원에게 Owner를 주는 설계는 피한다.
팀은 부서나 제품 단위로 묶는다. 예를 들어 backend, frontend, mobile, data, platform처럼 실제 협업 흐름에 맞춰 만들면 된다. 팀 안에 하위 팀을 둘 수 있지만 처음부터 너무 깊게 나누면 누가 어디에 속했는지 확인하기 어렵다.
저장소는 팀에 연결한다. 끝이다. 개인 초대는 외부 협력사, 단기 프로젝트 책임자처럼 팀 구조로 흡수하기 어려운 예외에만 남긴다.
| 권한 | 주요 용도 | 부여 대상 예시 |
|---|---|---|
| Read | 코드와 이슈 확인, 복제 | 참조만 필요한 운영·기획 인력 |
| Triage | 이슈·PR 분류와 관리 | 프로젝트 코디네이터, QA 리드 |
| Write | 브랜치 푸시와 PR 작업 | 해당 저장소 개발 팀 |
| Maintain | 저장소 운영 설정 관리 | 기술 리드, 저장소 관리자 |
| Admin | 접근 권한과 민감 설정 관리 | 제한된 책임자 |
권한 이름과 세부 동작은 GitHub 요금제나 화면 개편에 따라 달라질 수 있다. 특히 Actions secrets, 배포 환경, 웹훅, 규칙 세트처럼 코드 밖에 있는 설정은 Write 권한만 보고 판단하면 안 된다. 저장소 설정 화면에서 권한별 허용 범위를 함께 확인해야 한다.
팀별 저장소 접근을 설계하는 순서
- 저장소를 업무 성격으로 분류한다. 고객 서비스 코드, 내부 도구, 인프라 코드, 실험용 프로젝트를 한 덩어리로 보지 않는다. 민감한 인프라 저장소와 공개 예정 라이브러리는 접근 기준이 다르다.
- 팀 이름과 책임 범위를 정한다. 예를 들어 product-api 팀은 서비스 API 저장소에 Write, platform 팀은 인프라 저장소에 Maintain를 주는 식이다. 이름만 보고도 역할을 알 수 있게 만든다.
- 조직의 기본 저장소 권한을 확인한다. 모든 조직 멤버에게 Read를 주는 설정은 편하지만 비공개 저장소가 많다면 검토가 필요하다. 기본값을 No access로 두고 필요한 팀에만 권한을 주는 방식이 접근 범위를 파악하기 쉽다.
- 팀을 저장소에 연결하고 최소 권한부터 준다. 처음에는 Read나 Write로 시작한 뒤 업무상 막히는 기능이 확인되면 올린다. Admin부터 부여하고 나중에 내리는 방식은 위험 범위가 넓다.
- 개인 직접 권한과 외부 협력자 초대를 다시 확인한다. 팀 권한보다 강한 개인 권한이 남아 있으면 설계 의도가 무너진다. 계약 종료일이나 프로젝트 종료일을 기록해 두면 회수 작업도 빨라진다.
작은 조직이라도 팀을 쓰는 편이 낫다. 구성원이 10명이고 저장소가 8개라면 사람별로 80개의 접근 관계가 생길 수 있는데, 팀 4개와 저장소 권한 연결로 바꾸면 검토 대상이 훨씬 줄어든다. 실제 숫자는 팀 겸직과 저장소 구조에 따라 달라진다.
권한을 줄 때 놓치기 쉬운 항목
저장소 접근 권한은 코드 열람 권한과 완전히 같지 않다. GitHub Actions에 등록한 비밀 값, 배포 환경 승인, 패키지 배포 토큰, 외부 연동 웹훅은 별도 설정을 확인해야 한다. 비밀 값 원문을 읽지 못하는 권한이라도 워크플로를 바꿔 노출 위험이 생기는 구조인지 검토할 필요가 있다.
브랜치 보호나 규칙 세트도 같이 정한다. main이나 release 브랜치에는 직접 푸시를 제한하고, Pull Request 검토 인원과 필수 상태 검사를 지정하면 Write 권한자가 곧바로 운영 코드를 바꾸는 상황을 줄일 수 있다. 긴급 배포 예외 절차도 문서로 남겨야 현장에서 우회 권한을 남발하지 않는다.
조직 역할도 분리한다. 멤버 초대와 팀 관리를 맡는 사람, 결제와 소유자 권한을 맡는 사람, 저장소 운영을 맡는 사람의 책임이 모두 같을 필요는 없다. 다만 역할 구성이 복잡해지면 관리자가 설정을 이해하지 못하는 문제가 생기므로 실제 담당 업무만큼만 나눈다.
월 1회 점검 목록
- 퇴사자·휴직자·프로젝트 종료 인원이 조직과 팀에 남아 있는지 확인한다.
- Owner와 Admin 권한 보유자 명단을 별도로 검토한다.
- 개인에게 직접 부여한 저장소 권한이 늘지 않았는지 본다.
- 외부 협력자와 임시 계정의 종료일을 확인한다.
- 비공개 저장소의 기본 권한, Actions secrets, 배포 환경 권한을 다시 살핀다.
점검 기록은 거창할 필요 없다. 날짜, 확인자, 바뀐 팀, 회수한 권한, 남긴 예외 사유 다섯 칸이면 충분하다. 권한 사고 대응에서는 설정 자체만큼 변경 이력을 찾는 시간이 중요하다.
FAQ
개인에게 권한을 주면 정말 안 되나?
금지할 일은 아니다. 다만 개인 권한이 많아지면 인사 변동 때 빠뜨릴 가능성이 커진다. 지속적으로 협업하는 구성원은 팀에 넣고, 개인 권한은 예외 사유와 종료 시점을 남겨 관리하는 방식이 실무에 맞다.
Write 권한과 Maintain 권한은 어떻게 나누나?
개발자는 보통 Write부터 검토한다. Maintain는 라벨, 이슈, 일부 저장소 운영 설정을 관리해야 하는 기술 리드나 운영 담당자에게 맞는다. 조직마다 필요한 메뉴가 다르므로 테스트 저장소에서 역할별 화면을 확인한 뒤 적용한다.
조직 기본 권한을 Read로 두면 편하지 않나?
저장소 수가 적고 모든 멤버가 코드를 봐야 하는 조직이라면 운영 부담이 낮다. 반면 고객별 프로젝트, 인프라, 인사·재무 관련 코드처럼 열람 범위를 좁혀야 하는 저장소가 있다면 No access를 기준으로 팀 권한을 추가하는 편이 명확하다.
외부 개발자는 팀에 넣어도 되나?
업무 범위가 분명하고 여러 저장소를 써야 한다면 별도 외부 협력 팀을 만들어 필요한 저장소만 연결하는 방법이 관리하기 좋다. 내부 팀과 섞지 말고 계약 종료나 계정 회수 일정을 담당자가 확인하도록 정해 둔다.
권한 변경 전에는 무엇을 백업해야 하나?
코드 백업보다 먼저 현재 멤버, 팀, 저장소별 권한 목록과 중요 설정 화면을 보관한다. 권한을 일괄 변경할 때는 영향이 작은 저장소에서 먼저 시험하고, 배포와 자동화 작업이 멈추지 않는지 확인한 뒤 범위를 넓히는 편이 안전하다.
관련 글
이 글은 일반적인 정보 제공과 참고 목적으로 작성되었으며, 법률 자문·보안 컨설팅·컴플라이언스 판단을 대체하지 않습니다. 소개하는 설정과 절차는 소프트웨어 버전이나 조직 환경에 따라 다르게 동작할 수 있으며, 어떤 보안 조치도 완전한 안전을 보장하지는 않습니다. 실제 적용 전에는 반드시 소속 조직의 정책과 담당 부서(보안·IT·법무)의 확인을 거치고, 중요한 시스템에는 백업과 사전 테스트 후 적용하시기 바랍니다. 규제 해석과 합법·불법 여부는 사안과 시점마다 달라질 수 있으므로 공식 규정과 전문가 상담으로 확인이 필요합니다. 본 사이트는 내용의 정확성과 최신성을 보장하지 않으며, 이 글의 내용을 적용하여 발생하는 어떠한 결과에 대해서도 책임을 지지 않습니다.