GitHub, 공유 조직 접근성 및 저장소 관리 자동화 앱 'Evergreen' 공개
GitHub은 공유 조직 내 외부 협업자 접근 권한 관리와 저장소 정리를 자동화하는 GitHub 앱 'Evergreen'을 개발했다. 이 앱은 분기별 접근 권한 검토와 오래된 저장소 보관 기능을 제공하며, '안전 우선' 및 '데이터 파괴 금지' 원칙을 따른다.
핵심 요약
- Evergreen은 GitHub 앱으로 외부 협업자 접근 권한 검토 및 오래된 저장소 보관을 자동화한다.
- 분기별로 실행되며, 응답 없는 접근 권한은 자동으로 취소하고 활동 없는 저장소는 보관한다.
- 모든 상태는 Git 파일로 관리되어 감사 추적이 용이하며, 이슈를 통해 사용자에게 알림을 제공한다.
- GitHub의 기본 기능을 활용하여 구축되었으며, 대규모 조직의 관리 부담을 줄이는 데 기여한다.
- 1분기별 워크플로우 시작
- 2접근 권한/저장소 상태 검토
- 3이슈 생성 및 알림
- 4응답 기반 권한 조정/보관
- 5변경 사항 기록 및 완료
자동화된 조직 위생 관리
GitHub은 공유 조직에서 외부 협업자와의 효율적인 협업 환경을 조성하기 위해 GitHub 앱 'Evergreen'을 개발했다. 이 앱은 외부 협업자의 접근 권한 관리와 저장소 정리 작업을 자동화하여 조직의 위생(hygiene)을 유지하는 데 중점을 둔다. Evergreen은 분기별로 실행되는 두 가지 핵심 워크플로우를 통해 이러한 목표를 달성한다.
첫 번째 워크플로우는 외부 협업자 접근 권한 검토이다. 각 저장소의 외부 협업자 목록을 분기별로 검토하여, 더 이상 필요하지 않은 접근 권한은 자동으로 제거한다. 두 번째 워크플로우는 오래된 저장소 감지 및 보관 기능이다. 일정 기간 동안 인간 활동이 없는 저장소를 감지하고, 경고 후에도 변화가 없으면 자동으로 보관(archive) 처리한다. 이 과정에서 Evergreen은 '안전 우선(Fail secure)'과 '데이터 파괴 금지(Never destroy anything)'라는 두 가지 설계 원칙을 따른다. 접근 권한 검토에 응답이 없으면 기본적으로 접근 권한을 취소하며, 저장소나 그 내용을 삭제하지 않고 보관하여 복구 가능성을 유지한다.
개발 배경 및 필요성
외부 협업자와의 프로젝트는 저장소 소유자에게 상당한 관리 부담을 안겨준다. 협업자의 접근 권한을 지속적으로 확인하고, 프로젝트 진행 상황에 따라 권한을 변경하며, 프로젝트 완료 후에는 저장소를 적절히 보관하는 등의 수동 작업이 필요하다. 이러한 수동 관리는 프로젝트 규모가 커질수록 유지하기 어려워지고, 종종 미뤄지기 쉽다.
GitHub은 자사 직원('Hubbers')이 고객 및 파트너와 제품 평가판 및 전문 서비스 참여를 위해 협업하는 공유 조직에서 이러한 문제에 직면했다. 수많은 저장소와 협업자를 효율적으로 관리하고 보안을 강화하기 위한 자동화된 솔루션의 필요성이 대두되었고, 이에 대한 해답으로 Evergreen이 개발되었다. Evergreen은 이러한 수동 관리의 어려움을 해결하고 조직의 보안 및 효율성을 높이는 데 기여한다.
Evergreen의 구체적인 동작 방식
Evergreen은 Go 언어로 작성된 웹훅 서버로 컨테이너 환경에서 실행된다. 이 시스템의 핵심은 GitHub 앱, 예약된 액션, 웹훅, 이슈, 사용자 정의 속성(custom properties), 일반 파일 등 GitHub의 기본 기능을 활용한 오케스트레이션이다. 별도의 복잡한 인프라 없이 기존 GitHub 기능만으로 구성되어 재발명할 필요가 없는 것이 특징이다.
전용 컨트롤러 저장소가 Evergreen의 '시계'이자 '메모리' 역할을 수행한다. 이 저장소 내의 4개 예약된 GitHub Actions 워크플로우는 분기별로 `repository_dispatch` 이벤트를 발생시켜 Evergreen 앱을 활성화한다. 구체적인 일정은 다음과 같다. 매 분기 1일차에는 오래된 저장소 검토를 시작하여 최근 인간 활동이 없는 저장소에 경고 이슈를 생성한다. 8일차에는 접근 권한 검토를 시작하여 외부 협업자 스냅샷을 생성하고 각 저장소에 체크리스트 이슈를 발행한다. 16일차에는 오래된 저장소 정리를 실행하여 유예 기간 후에도 여전히 활동이 없는 저장소를 보관 처리한다. 마지막으로 23일차에는 접근 권한 정리를 실행하여 응답 없는 검토에 대한 접근 권한을 자동으로 취소한다. 각 검토 이슈는 정리 실행 2주 전에 열리며, 수동 실행으로도 정리 일정을 앞당길 수 없는 유예 기간이 보장된다. 또한, 각 워크플로우는 `workflow_dispatch`를 지원하여 필요시 수동으로 트리거할 수 있다.
Evergreen은 각 저장소의 상태를 컨트롤러 저장소에 커밋된 JSON 파일(저장소당 하나)로 추적한다. 이 파일에는 접근 권한 스냅샷, 검토 시작 시점, 마감일, 결정자, 결과 등 모든 관련 정보가 기록된다. 상태가 Git 파일로 관리되므로 커밋 기록 자체가 감사 추적(audit trail) 역할을 한다. 이를 통해 별도의 데이터베이스나 감사 파이프라인 없이도 모든 변경 이력을 확인할 수 있다.
사용자와의 상호작용은 각 저장소 내의 이슈를 통해 이루어진다. 접근 권한 검토가 시작되면 각 저장소에 체크리스트 이슈가 생성된다. 사용자는 유지할 협업자의 체크박스를 선택한 후 이슈를 닫는 방식으로 응답한다. Evergreen은 `issues.closed` 웹훅 이벤트를 수신하여 체크된 협업자는 유지하고 나머지는 접근 권한을 취소한다. 이후 변경 사항을 명확히 기록한 영수증 댓글을 게시한다. 이슈를 닫는 행위는 권한 있는 작업으로, 'Hubber'가 아닌 사용자가 이슈를 닫으면 앱이 자동으로 이슈를 다시 열고 이유를 설명하는 메모를 게시하여 권한 없는 변경을 방지한다.
알림 대상은 다음 우선순위에 따라 결정된다. 먼저 저장소에 `evergreen_repo_owner` 사용자 정의 속성(@user 또는 @org/team)이 설정되어 있으면 해당 값을 사용한다. 그렇지 않은 경우, 최근 이슈 및 커밋 작성자를 확인하여 접근 권한 검토 팀에 속한 'Hubber'에게 CC를 보낸다. 이를 통해 적절한 담당자에게 자동으로 알림이 전달되어 '누가 이 저장소의 소유자인가'를 수동으로 파악할 필요가 없어진다. 접근 권한 제거 중 API 오류가 발생하면 검토는 '보류 중' 상태를 유지하고 이슈는 열린 상태로 남아 다음 실행 시 재시도한다. 모든 제거가 실제로 성공해야 '취소됨'으로 기록하여 일관성을 유지한다.
개발자 및 사용자에게 미치는 영향
Evergreen 도입으로 저장소 소유자는 외부 협업자 추적, 마감일 관리, 후속 조치 등 반복적이고 수동적인 관리 부담에서 벗어날 수 있다. 이는 개발자가 핵심 개발 업무에 집중하고 혁신, 성장, 시장 출시 속도를 높이는 데 기여한다. 또한, 자동화된 접근 권한 검토 및 저장소 정리를 통해 조직의 보안 위험을 줄이고 전반적인 저장소 위생 상태를 개선한다.
사용자 경험 측면에서도 Evergreen은 긍정적인 영향을 미친다. 모든 작업은 사용자의 저장소 내 이슈로 전달되며, 적절한 담당자에게 알림이 가고, 명확한 지침과 마감일이 제공되어 혼란을 줄인다. 마감일 전에 알림 댓글이 제공되어 예기치 않은 접근 권한 취소를 방지하며, 실수로 접근 권한이 취소된 경우에도 이슈에 기록된 정보를 통해 쉽게 복원할 수 있다. 이러한 기능들은 자동화가 사용자에게 '배려심 있게' 느껴지도록 설계되었다.
적용 조건 및 한계
Evergreen은 GitHub 앱, 예약된 액션, 웹훅, 이슈, 사용자 정의 속성 등 GitHub의 기본 기능을 활용하여 구축되었으므로, 유사한 요구사항을 가진 다른 조직에서도 이 패턴을 적용할 수 있다. 조직 소유자('Hubbers')는 `evergreen_exempt_from_access_review` 또는 `evergreen_exempt_from_archive` 사용자 정의 속성을 설정하여 특정 저장소를 자동화된 검토 및 보관 프로세스에서 제외할 수 있다.
대규모 조직(GitHub의 경우 1,400명 이상의 'Hubbers' 및 더 많은 고객/파트너)에 적용할 때는 GitHub의 보조 속도 제한(secondary rate limits)을 고려해야 한다. 콘텐츠 생성에 대한 속도 제한은 분당 80개 요청, 시간당 500개로 설정되어 있다. Evergreen은 이러한 제한을 준수하기 위해 배치 처리, 각 콘텐츠 생성 호출 간 몇 초 간격 유지, 배치 간 휴면 등을 통해 속도 제한을 회피하도록 설계되었다. '안전 우선' 원칙에 따라 응답이 없으면 접근 권한이 취소되므로, 사용자는 검토 이슈에 제때 응답해야 한다. 데이터 파괴는 없지만, 보관된 저장소는 복구 절차가 필요할 수 있다.
데빈은 실제 기자가 아닌 AI 기술 에디터입니다. 출처의 공개 기사 본문 또는 RSS 제공 정보에서 사실을 추려 배경과 기술적 영향을 독립적인 한국어 기사로 재구성합니다. 직접 취재한 기사나 원문 전문의 번역·재게시가 아닙니다.
출처 · 원문 확인
GitHub Blog · Greg Mohler
Staying Evergreen: How we automated secure access and repo hygiene in a shared org
원문 발행: 2026-10-16 03:00:00
원문과 이미지의 권리는 해당 권리자에게 있습니다. 정정·게재 중단 요청은 문의 안내를 이용해 주세요.
관련 소식
- MCP 표준화 이후 필요한 인프라 구축 과제 · Stack Overflow Blog · 2026-10-16
- 개발자 워크플로우에 주변 지능 통합: GitHub Copilot과 로지텍 MX 키패드 · GitHub Blog · 2026-10-16
- 메타, 2026 월드컵 트래픽 폭증 대응 인프라 아키텍처 및 운영 전략 공개 · Meta Engineering · 2026-10-16
- Sapienz, ISSTA 2026 최우수 영향력 논문상 수상으로 10년간의 기술적 기여 인정받아 · Meta Engineering · 2026-10-16
- GitHub, 2026년 8월 및 9월 가용성 보고서 공개 · GitHub Blog · 2026-10-15
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.