Sign in
Development

GitHub Enterprise Server 3.22 RC: 운영 서버 대신 시험 환경에서 볼 변화

GitHub Enterprise Server 3.22 릴리스 후보가 나왔다. 저장소 규칙·검토·권한 관리 변화와 함께, 운영 환경에 적용하기 전 반드시 확인할 시험 절차를 정리했다.

GitHub Enterprise Server 3.22 RC: 운영 서버 대신 시험 환경에서 볼 변화

GitHub가 2026년 8월 11일 GitHub Enterprise Server 3.22 릴리스 후보(GitHub Enterprise Server 3.22 release candidate, 이하 GHES 3.22 RC)1를 공개했다. 이번 버전은 저장소 거버넌스와 검토 절차, 기업 단위 사용자 관리, 보안 요청 처리에 변화를 더한다. 다만 이름 그대로 정식 버전이 아니다. GitHub는 운영 환경에 설치하지 말고 새 시험 환경에서만 검증하라고 명시한다.

무엇이 바뀌었나

가장 눈에 띄는 변화는 저장소 규칙 세분화다. 저장소 규칙 집합2에서 특정 사용자에게 우회 권한을 줄 수 있고, 브랜치·파일·폴더 패턴에 따라 특정 팀의 검토를 요구할 수 있다. 예를 들어 *.sql 변경에는 데이터 플랫폼 팀, 기본 브랜치 변경에는 보안 팀의 검토를 요구하는 식이다. 기존 코드 소유자(CODEOWNERS) 검토와 함께 적용할 수 있다.

기업 팀(Enterprise Teams)은 공개 시험을 마치고 정식 제공 단계에 들어갔다. 기업 소유자는 여러 조직과 저장소에 걸친 사용자 접근을 하나의 팀 구조에서 관리할 수 있다. 비밀 스캔의 푸시 보호 우회 요청과 경고 기각 요청을 날짜순으로 정렬하는 기능, 이슈 사이드바에서 연결된 풀 리퀘스트가 최신 릴리스나 시험 릴리스에 포함됐는지 확인하는 표시도 추가됐다.

망 분리 또는 인터넷 연결이 제한된 환경에서는 관리자가 자체 모델 제공자를 구성해 Copilot CLI를 GHES 자격 증명으로 쓰는 기술 시험 기능도 제공된다. 이 기능은 변경될 수 있는 시험 단계이며, 3.22 RC 전체를 운영 배포해도 된다는 뜻은 아니다.

개발자와 운영팀에 왜 중요한가

규칙 집합의 검토 조건이 정교해지면 저장소마다 봇·서비스 계정용 역할이나 임시 팀을 만드는 부담을 줄일 수 있다. 동시에 우회 권한을 개인에게 직접 줄 수 있다는 점은 권한 회수와 감사 기록의 중요성을 높인다. 편의 때문에 예외 사용자가 늘어나면 조직 정책의 일관성이 약해질 수 있다.

특정 경로나 파일 형식에 검토 팀을 연결하는 기능은 데이터베이스 스키마, 배포 설정, 보안 정책처럼 전문 검토가 필요한 변경에 유용하다. 그러나 기존 CODEOWNERS와 새 규칙이 겹치면 필요한 승인 수와 병합 조건이 예상보다 늘어날 수 있다. 시험 저장소에서 실제 풀 리퀘스트 흐름을 재현해야 하는 이유다.

기존 프로젝트에 미치는 영향

GHES 3.22 RC는 애플리케이션 런타임이나 언어 버전을 직접 바꾸는 업데이트가 아니다. 영향은 주로 GitHub Enterprise Server 인스턴스의 관리 정책과 협업 절차에 있다. 조직·저장소 관리자, 보안 분석가, 릴리스 담당자가 먼저 확인해야 한다.

지원 범위도 분명히 구분해야 한다. 릴리스 후보는 완성된 기능 집합을 미리 시험하는 빌드이지만, 고객 환경에서만 드러나는 문제가 남아 있을 수 있다. GitHub 공식 문서는 지원 중인 이전 버전에서 RC로 직접 업그레이드하지 말고, RC에서 이후 정식 버전으로 이어서 업그레이드하지도 말라고 안내한다. 즉 기존 운영 인스턴스의 일반적인 업그레이드 경로로 취급하면 안 된다.

적용·업데이트 전 확인 사항

  • 별도 시험 인스턴스를 만든다. 운영 데이터와 트래픽에서 분리하고, RC 시험이 끝나면 환경을 폐기할 계획까지 세운다.
  • 규칙 충돌을 재현한다. CODEOWNERS, 기존 브랜치 보호, 조직 규칙 집합, 새 필수 검토 규칙을 함께 적용한 풀 리퀘스트를 시험한다.
  • 우회 권한을 최소화한다. 개인 사용자와 서비스 계정의 필요성을 구분하고 소유자·만료일·감사 절차를 기록한다.
  • 기업 팀 매핑을 점검한다. 여러 조직의 기존 팀과 새 기업 팀 사이에 중복 권한이나 예상치 못한 접근 확대가 없는지 확인한다.
  • 정식 출시를 기다린다. 성능·안정성·보안 검증을 마쳐도 운영 반영은 일반 제공(GA) 버전과 해당 버전의 최종 릴리스 노트를 기준으로 다시 판단한다.

출처

1 릴리스 후보(RC): 기능 구성이 완료됐지만 정식 배포 전에 안정성과 호환성을 확인하는 시험 버전.
2 규칙 집합(ruleset): 여러 브랜치나 태그에 병합·푸시·검토 조건을 묶어 적용하는 저장소 정책 단위.

Read next