ghqr CLI 사용법 2026 GitHub 조직 점검 설정 포인트

2026년 4월 28일 기준 microsoft/ghqr는 GitHub 조직, 엔터프라이즈, 저장소 설정을 CLI로 점검하는 오픈소스 도구다.

이 도구의 포인트는 “GitHub를 한 번 훑어준다”가 아니다.

조직의 보안 설정, 접근 제어, 브랜치 보호, Actions 정책, Copilot 정책, 감사 로그 같은 운영 항목을 한 번에 보고서로 뽑는 데 있다.

그래서 ghqr는 새 기능 구경용보다 운영 점검용에 가깝다.

회사 GitHub를 맡고 있는데 설정이 여기저기 흩어져 있다면 꽤 현실적인 도구다.

반대로 개인 저장소 하나를 예쁘게 관리하려고 쓰기에는 조금 크다.

망치가 좋아도 압정 하나 박겠다고 굴착기를 부르면 옆집에서 먼저 알아챈다.

이 글은 ghqr를 실제로 붙일 때 봐야 할 CLI 사용법과 핵심 설정 포인트를 정리한다.

설치 명령만 복붙하는 글은 아니다.

권한을 어디까지 줄지,

조직 스캔과 엔터프라이즈 스캔을 어떻게 나눌지,

출력물을 어디에 보관할지,

401, 403, rate limit이 나오면 어디부터 볼지,

MCP 서버 모드는 언제 켜면 위험한지까지 같이 본다.

먼저 알아둘 한 줄 판단

ghqr는 GitHub 운영 상태를 “감”이 아니라 “점검 결과”로 바꾸는 CLI다.

가장 먼저 볼 설정은 모델도 아니고 대시보드도 아니다.

GITHUB_TOKEN 권한이다.

토큰 권한이 부족하면 결과가 비어 보인다.

토큰 권한이 너무 넓으면 점검 도구가 또 하나의 위험 자산이 된다.

그러니까 ghqr를 붙일 때 순서는 단순하다.

먼저 읽기 권한 토큰을 설계한다.

그다음 작은 조직이나 샘플 저장소로 스캔한다.

그다음 출력 형식을 고른다.

마지막으로 정기 점검이나 MCP 연결을 검토한다.

이 순서가 바뀌면 설치는 쉬운데 운영이 피곤해진다.

개발자는 CLI를 좋아하지만, 보안팀은 “그 CLI 토큰 어디 있어요?”부터 물어본다.

그 질문에 답할 수 있어야 진짜 도입이다.

ghqr가 실제로 보는 것

공식 README 기준 ghqr는 GitHub enterprise, organization, repository를 대상으로 best practices와 security recommendation을 점검한다.

점검 영역은 꽤 넓다.

Security 항목에서는 Dependabot alerts, secret scanning, code scanning, GHAS 같은 기능을 본다.

Access Control 항목에서는 2FA enforcement, member privileges, SAML SSO, CODEOWNERS 같은 항목을 본다.

Branch Protection 항목에서는 required reviews, status checks, admin enforcement 같은 설정을 본다.

Copilot 항목에서는 seat usage, content exclusions, policy configuration, MCP settings를 본다.

Governance 항목에서는 IP allow lists, repository creation policies, fork policies를 본다.

Audit Log 항목에서는 enterprise와 organization의 audit log streaming configuration을 본다.

Community 항목에서는 contributing guide, issue templates, code of conduct를 본다.

Actions 항목에서는 workflow permissions, allowed actions, self-hosted runners를 본다.

Dependencies 항목에서는 Dependabot version updates와 security updates를 본다.

Metadata 항목에서는 description, topics, visibility, archival status를 본다.

이 목록을 보면 감이 온다.

ghqr는 “내 저장소 README가 예쁜가”를 보는 도구가 아니다.

조직 운영의 빠진 나사를 찾는 도구다.

나사가 빠졌다는 말은 무섭지만, 사실 대부분은 설정 화면 어딘가에 숨어 있던 평범한 체크박스다.

문제는 그 체크박스가 100개쯤 되면 사람 눈이 먼저 퇴근한다는 점이다.

설치 전에 정해야 할 것

설치 명령은 쉽다.

하지만 설치보다 먼저 정해야 할 것이 있다.

첫째, 누가 실행할지 정한다.

둘째, 어떤 범위를 스캔할지 정한다.

셋째, 어떤 권한의 토큰을 쓸지 정한다.

넷째, 결과 파일을 어디에 둘지 정한다.

다섯째, 결과를 누가 읽고 조치할지 정한다.

이 다섯 개를 안 정하면 ghqr는 “보고서는 뽑혔는데 아무도 안 보는 파일”이 된다.

그건 자동화가 아니라 파일 생성 취미다.

운영용 도구는 결과 이후의 행동이 있어야 한다.

특히 GitHub 조직 점검은 발견보다 조치가 더 어렵다.

예를 들어 branch protection 누락을 발견하는 건 쉽다.

하지만 모든 저장소에 같은 규칙을 바로 걸 수는 없다.

레거시 배포 저장소는 status check 이름이 다를 수 있다.

외부 벤더가 쓰는 저장소는 권한 구조가 다를 수 있다.

아카이브 예정 저장소는 고치기보다 닫는 게 맞을 수 있다.

그래서 ghqr 결과는 “즉시 수정 목록”이 아니라 “분류할 입력값”으로 봐야 한다.

설치 방법은 세 갈래

공식 README는 Linux/macOS, Windows, Docker, source build를 안내한다.

Linux와 macOS에서는 install script를 curl로 받아 bash에서 실행하는 방식이 제시돼 있다.

Windows에서는 PowerShell에서 install.ps1을 받아 실행하는 방식이 제시돼 있다.

Docker에서는 ghcr.io/microsoft/ghqr:latest 이미지를 pull하는 방식이 제시돼 있다.

source build는 GitHub 저장소를 clone한 뒤 make를 실행하는 흐름이다.

실무에서는 설치 방식보다 검증 방식이 더 중요하다.

curl pipe shell 방식은 편하지만, 보안팀이 싫어할 만한 냄새가 난다.

그 냄새는 대체로 정상이다.

냄새가 난다고 다 나쁜 건 아니지만, 창문은 열어야 한다.

조직 환경에서는 install script 내용을 먼저 확인하는 편이 좋다.

릴리스 페이지에서 OS별 zip과 sha256 파일을 받아 검증하는 방식도 고려할 수 있다.

Docker를 쓰면 로컬 설치 흔적을 줄일 수 있다.

다만 Docker에서도 토큰 주입 방식과 결과 파일 volume mount는 별도로 정해야 한다.

source build는 재현성과 내부 검토가 중요할 때 어울린다.

대신 Go 버전과 빌드 체인을 관리해야 한다.

공식 README에는 로컬 빌드 조건으로 Go 1.26.x 이상이 적혀 있다.

이 조건은 사내 빌드 이미지가 오래된 경우 바로 막히는 지점이다.

설치 명령을 그대로 쓰기 전에

README에 나온 Linux/macOS 설치 명령은 다음 흐름이다.

bash -c "$(curl -fsSL <https://raw.githubusercontent.com/microsoft/ghqr/main/scripts/install.sh)">

편하다.

하지만 회사 노트북에서는 바로 실행하기 전에 최소 세 가지를 확인하자.

첫째, URL이 microsoft/ghqr 공식 저장소의 raw 경로인지 본다.

둘째, install.sh 내용을 브라우저나 별도 curl로 먼저 확인한다.

셋째, 설치 결과물이 어디에 놓이는지 확인한다.

이건 겁이 많아서가 아니다.

CLI 설치 스크립트는 보통 PATH, binary, permission을 만진다.

한 번 실행하면 “아까 뭐 깔렸더라”가 된다.

그 순간부터 사람은 고고학자가 된다.

가능하면 아래처럼 먼저 스크립트만 내려받아 보는 흐름을 권한다.

curl -fsSL <https://raw.githubusercontent.com/microsoft/ghqr/main/scripts/install.sh> -o /tmp/ghqr-install.sh
less /tmp/ghqr-install.sh
bash /tmp/ghqr-install.sh

Windows에서도 같은 원칙이다.

공식 README는 PowerShell install.ps1 실행 흐름을 안내한다.

실무에서는 실행 정책을 우회하는 부분이 들어가기 때문에 더 조심해서 봐야 한다.

한 번만 쓰는 개인 테스트라면 빠른 설치도 괜찮다.

조직 점검용이면 다운로드, 검증, 승인, 실행 순서가 낫다.

토큰 권한이 제일 중요하다

ghqr 인증은 README 기준 Personal Access Token을 사용하고, GITHUB_TOKEN 환경 변수를 통해 전달한다.

필요 scope도 공식 문서에 적혀 있다.

read:org는 organization settings와 members를 읽는 데 필요하다.

read:enterprise는 enterprise settings를 읽는 데 필요하다.

repo는 repository settings, branch protection, security features를 읽는 데 필요하다.

read:audit_log는 audit log configuration을 읽는 데 필요하다.

read:user는 user information을 읽는 데 필요하다.

copilot은 Copilot seat와 policy information을 읽는 데 필요하다.

여기서 실무 포인트가 나온다.

모든 scope를 한 번에 넣으면 결과는 잘 나올 가능성이 높다.

하지만 토큰 위험도도 같이 올라간다.

특히 repo scope는 private repository 읽기와 연결될 수 있어 조직 정책에 따라 민감하다.

그래서 처음부터 전체 권한 토큰으로 돌리기보다 범위를 나눠서 생각하는 게 좋다.

조직 설정만 보고 싶다면 organization 중심 scope부터 본다.

엔터프라이즈 설정까지 보려면 enterprise 권한이 있는 계정과 승인 흐름을 분리한다.

저장소 설정까지 보려면 대상 저장소 범위와 보관 정책을 먼저 정한다.

Copilot 정책을 보려면 Copilot 관련 권한이 필요한지 확인한다.

감사 로그를 보려면 audit log 접근 권한이 있는 운영자와 같이 움직인다.

토큰은 “일단 내 계정으로 만들지 뭐”가 제일 편하다.

그리고 나중에 제일 많이 혼난다.

가능하면 전용 점검 계정이나 승인된 운영 계정으로 분리하는 편이 낫다.

환경 변수로 토큰 넣기

README의 quick start는 GITHUB_TOKEN을 export한 뒤 scan을 실행하는 방식이다.

export GITHUB_TOKEN=<your-personal-access-token>
ghqr scan -o my-org

이 방식은 간단하다.

다만 shell history와 터미널 로그에 토큰이 남지 않게 조심해야 한다.

토큰을 명령어에 직접 박아 넣는 방식은 피하자.

환경 변수도 완전한 금고는 아니다.

같은 세션에서 다른 프로세스나 로그가 환경을 노출할 수 있다.

CI에서 돌린다면 secret store를 써야 한다.

로컬에서 돌린다면 세션 종료 후 unset GITHUB_TOKEN까지 습관으로 두는 편이 좋다.

unset GITHUB_TOKEN

사소해 보이지만 이런 습관이 나중에 사고 범위를 줄인다.

보안은 대단한 의식이 아니라 귀찮은 습관의 묶음인 경우가 많다.

귀찮지만 효과는 있다.

비타민보다 맛은 없지만요.

첫 실행은 작게

처음부터 enterprise 전체를 스캔하지 말자.

작은 organization 하나로 시작하는 편이 좋다.

README에는 organization scan 예시로 ghqr scan -o my-org가 나온다.

enterprise scan 예시로는 ghqr scan -e my-enterprise가 나온다.

실무 첫 실행은 더 작게 가져가자.

조직 하나를 고른다.

저장소 수가 적은 조직이면 더 좋다.

토큰 scope를 최소화한다.

출력 파일이 어떤 형식으로 나오는지 본다.

finding의 severity와 category를 읽어본다.

false positive처럼 보이는 항목을 표시한다.

조치가 필요한 항목과 정책 예외 항목을 나눈다.

이 과정을 거치면 전체 스캔 전에 팀 내부 언어가 맞춰진다.

“이건 위험하다”와 “이건 우리 정책상 예외다”는 다르다.

도구는 이 둘을 자동으로 구분하지 못한다.

사람이 운영 맥락을 넣어야 한다.

출력 형식 선택

공식 README 기준 ghqr 결과는 Markdown, Excel, JSON으로 제공된다.

기본값은 Excel 형식으로 안내돼 있다.

각 형식은 쓰임새가 다르다.

Excel은 보안팀, 플랫폼팀, 리더십 공유에 좋다.

Markdown은 이슈나 내부 문서에 붙이기 좋다.

JSON은 후속 자동화와 대시보드 연결에 좋다.

처음 도입할 때는 Excel과 Markdown을 같이 보는 편이 편하다.

Excel은 행 단위로 필터링하기 좋다.

Markdown은 맥락 설명과 조치 기록을 붙이기 좋다.

JSON은 나중에 정기 실행으로 넘어갈 때 빛난다.

처음부터 JSON 파이프라인을 짜면 멋있다.

하지만 결과 해석 기준이 없으면 멋있는 쓰레기통이 된다.

먼저 사람이 읽고 기준을 만든 뒤 자동화하는 순서가 낫다.

결과 파일을 어떻게 읽을까

README는 출력 결과에 Recommendations, Organizations, Repositories, Issues Sheet가 포함된다고 설명한다.

Recommendations는 우선순위가 붙은 finding과 category를 보는 곳이다.

Organizations는 스캔한 organization의 posture를 요약해서 보는 곳이다.

Repositories는 branch protection, security features, access settings 같은 저장소별 항목을 보는 곳이다.

Issues Sheet는 finding, recommendation, documentation link를 함께 보는 곳이다.

운영자는 여기서 바로 “다 고쳐”라고 말하면 안 된다.

먼저 세 가지로 나누자.

첫째, 즉시 고쳐도 위험이 낮은 항목이다.

둘째, 서비스 영향 검토가 필요한 항목이다.

셋째, 조직 정책부터 정해야 하는 항목이다.

예를 들어 저장소 description 누락은 즉시 수정하기 쉽다.

branch protection 강화는 CI와 배포 흐름을 건드릴 수 있다.

repository creation policy는 팀의 개발 자율성과 연결된다.

Copilot policy는 개발자 경험, 보안, 라이선스 검토가 섞인다.

audit log streaming은 보안 운영 체계와 연결된다.

항목마다 속도가 다르다.

ghqr 보고서를 잘 쓰려면 finding보다 처리 속도를 먼저 나눠야 한다.

조직 스캔과 엔터프라이즈 스캔 구분

organization scan은 특정 조직의 설정과 저장소 상태를 보는 데 맞다.

enterprise scan은 여러 조직을 포함한 상위 관리 관점에 가깝다.

작은 회사는 조직 하나만 봐도 충분할 수 있다.

큰 회사는 enterprise 단위에서 정책 일관성을 봐야 한다.

하지만 enterprise scan은 권한 요구가 더 크다.

결과 범위도 더 넓다.

따라서 처음부터 enterprise scan을 자동화하면 논의 범위가 너무 커질 수 있다.

좋은 순서는 이렇다.

먼저 대표 조직 하나를 스캔한다.

그다음 조직별 차이를 확인한다.

그다음 enterprise scan으로 공통 정책을 본다.

마지막으로 예외 조직을 따로 관리한다.

GitHub 운영은 중앙 정책과 팀 자율성 사이의 줄타기다.

줄타기에서 제일 위험한 건 줄이 아니라 “내가 균형감각 좋다”는 착각이다.

도구는 착각을 조금 줄여준다.

저장소 단위로 봐야 하는 이유

조직 설정이 좋아도 저장소가 흩어져 있으면 위험은 남는다.

오래된 저장소는 branch protection이 빠져 있을 수 있다.

private 저장소인데 topics와 description이 없어 소유자가 불명확할 수 있다.

아카이브해야 할 저장소가 계속 열려 있을 수 있다.

CODEOWNERS가 없어서 리뷰 책임이 흐려질 수 있다.

Dependabot 설정이 빠져 dependency update가 멈출 수 있다.

Actions 권한이 넓게 열려 있을 수 있다.

self-hosted runner가 붙어 있는데 관리 기준이 약할 수 있다.

이런 문제는 조직 설정 한 장으로 잘 보이지 않는다.

저장소 목록을 실제 운영 단위로 나눠야 한다.

프로덕션 저장소,

라이브러리 저장소,

실험 저장소,

아카이브 후보 저장소,

외부 협업 저장소,

문서 저장소처럼 나누면 좋다.

같은 finding이라도 저장소 성격에 따라 우선순위가 달라진다.

프로덕션 저장소의 branch protection 누락은 빨리 봐야 한다.

실험 저장소의 description 누락은 급하지 않을 수 있다.

아카이브 후보 저장소는 설정 강화보다 archive 처리가 맞을 수 있다.

GHE.com 데이터 레지던시 환경

공식 README에는 GitHub Enterprise Cloud with Data Residency, 즉 GHE.com 환경을 위한 설정이 따로 있다.

이 환경에서는 API endpoint가 github.com이 아니라 custom ghe.com subdomain에 있다.

README는 --hostname 또는 -H 플래그를 안내한다.

예시는 ghqr scan -o my-org -H mycompany.ghe.com 형태다.

또는 GH_HOST 환경 변수를 사용할 수 있다.

export GH_HOST=mycompany.ghe.com
ghqr scan -o my-org

이 포인트는 은근히 중요하다.

권한이 맞는데도 401이나 403이 난다면 hostname이 잘못됐을 수 있다.

토큰은 GHE.com 쪽에서 유효한데 CLI가 github.com으로 요청하면 결과가 이상해진다.

운영자는 보통 권한부터 의심한다.

하지만 endpoint가 틀리면 권한을 아무리 넓혀도 해결되지 않는다.

헬스장 문 앞에서 회사 출입증 찍는 느낌이다.

카드는 멀쩡한데 문이 다르다.

데이터 레지던시 조직은 설치 문서보다 hostname 확인을 먼저 하자.

Docker로 돌릴 때의 체크포인트

Docker 방식은 로컬 환경을 덜 더럽힌다.

공식 README는 docker pull ghcr.io/microsoft/ghqr:latest를 안내한다.

하지만 Docker 실행에서는 두 가지가 중요하다.

첫째, GITHUB_TOKEN을 컨테이너에 어떻게 주입할지다.

둘째, 결과 파일을 호스트로 어떻게 빼낼지다.

환경 변수로 주입할 수 있지만, shell history와 CI log 노출을 조심해야 한다.

결과 파일은 volume mount를 써야 사라지지 않는다.

컨테이너 안에만 보고서가 생기면 “어디 갔지” 시간이 시작된다.

그 시간은 보통 회의 10분 전부터 찾아온다.

Docker를 쓴다면 실행 wrapper를 만들어두는 게 좋다.

wrapper에는 token 주입 방식, output directory, target org, hostname을 명시한다.

사람마다 임의 명령을 치게 두면 결과 파일 위치와 옵션이 매번 달라진다.

운영 점검은 재현성이 중요하다.

CLI도 결국 운영 문서의 일부다.

MCP 서버 모드는 조심해서

공식 README에 따르면 ghqr는 MCP server를 포함한다.

stdio mode는 IDE integration에 쓰는 흐름이다.

HTTP/SSE mode는 remote 또는 web access에 쓰는 흐름이다.

명령 예시는 ghqr mcp와 ghqr mcp --mode http --addr :8080이다.

VS Code 또는 GitHub Copilot 설정 예시도 README에 있다.

.vscode/mcp.json에 ghqr server를 등록하고 GITHUB_TOKEN을 env로 넘기는 방식이다.

여기서 운영 판단이 필요하다.

MCP로 붙이면 AI assistant가 ghqr 기능을 호출할 수 있다.

편하다.

하지만 토큰이 들어간 점검 도구를 AI 도구에서 호출하게 하는 구조다.

따라서 개인 로컬 실험과 조직 운영 연결은 다르게 봐야 한다.

stdio mode는 로컬 IDE 통합에 상대적으로 맞다.

HTTP mode는 네트워크 노출이 생기므로 더 보수적으로 봐야 한다.

remote access가 필요한 이유가 분명하지 않다면 HTTP mode부터 열 필요는 없다.

MCP를 켠다면 최소한 다음을 정하자.

어떤 workspace에서만 쓸지 정한다.

어떤 token scope를 넣을지 정한다.

어떤 대상 조직을 호출할지 제한한다.

결과 파일이 어디에 저장되는지 정한다.

프롬프트와 도구 실행 로그에 토큰이나 조직 정보가 남지 않는지 확인한다.

AI 도구는 손이 빠르다.

빠른 손에 넓은 권한을 주면 관리자는 갑자기 기도를 배우게 된다.

기도보다 allowlist가 낫다.

401과 403이 나올 때

공식 README는 authentication error가 나오면 네 가지를 확인하라고 안내한다.

첫째, GITHUB_TOKEN이 설정됐고 유효한지 확인한다.

둘째, required scope가 있는지 확인한다.

셋째, enterprise resource에서는 read:enterprise scope와 SSO authorization을 확인한다.

넷째, GHE.com data residency 환경에서는 --hostname 또는 GH_HOST를 확인한다.

실무에서는 이 순서가 꽤 좋다.

토큰이 비어 있는지 먼저 본다.

토큰이 만료됐는지 본다.

scope가 부족한지 본다.

SSO 승인이 빠졌는지 본다.

hostname이 틀렸는지 본다.

대상 조직에 실제 접근 가능한 계정인지 본다.

조직 정책상 PAT 사용이 제한돼 있는지 본다.

이 과정을 체크리스트로 남겨두면 다음 사람이 덜 헤맨다.

401은 대체로 “너 누구야”에 가깝다.

403은 대체로 “누군지는 알겠는데 여기까지는 안 돼”에 가깝다.

물론 API 세계는 가끔 예의가 없다.

그래서 --debug가 필요하다.

debug 옵션은 처음부터 알아두기

README는 문제가 생기면 --debug flag로 실행하라고 안내한다.

예시는 ghqr scan -o my-org --debug다.

debug는 실패 원인을 볼 때 유용하다.

하지만 debug log에는 민감한 경로, 조직 이름, 요청 정보가 남을 수 있다.

토큰이 직접 찍히지 않더라도 운영 정보는 충분히 민감할 수 있다.

따라서 debug log를 이슈에 그대로 붙이지 말자.

내부 채팅에 그대로 던지는 것도 조심하자.

공유하기 전에 token, org name, enterprise slug, repo name, user name을 가릴지 판단한다.

보안 점검 도구의 로그가 보안 사고 자료가 되면 조금 슬프다.

슬픔은 문학에만 두자.

운영에서는 redaction이 답이다.

rate limit을 운영 변수로 보기

공식 README는 GitHub API rate limit을 REST 5000 requests/hour, GraphQL 5000 points/hour로 설명한다.

큰 enterprise나 organization에서는 ghqr가 exponential backoff로 rate limiting을 처리한다고 안내한다.

그래도 운영자는 rate limit을 계획에 넣어야 한다.

저장소 수가 많으면 스캔 시간이 길어질 수 있다.

동시에 다른 자동화가 같은 토큰을 쓰면 limit을 같이 먹을 수 있다.

CI, 보안 스캐너, inventory collector, ghqr가 한 토큰을 나눠 쓰면 원인 추적이 어렵다.

토큰은 되도록 용도별로 분리하자.

스캔 시간도 업무 시간 한복판보다 덜 붐비는 시간대를 고려하자.

정기 실행을 한다면 주기와 대상 범위를 나누자.

매시간 전체 조직을 스캔하는 건 과할 수 있다.

매주 전체 점검,

매일 핵심 조직 점검,

변경 감지 후 특정 저장소 점검처럼 나눌 수 있다.

중요한 건 “자동화했으니 자주 돌리자”가 아니다.

“자주 돌려도 의미 있는 항목만 자주 돌리자”다.

자동화도 운동처럼 과하면 무릎이 먼저 아프다.

결과를 팀 workflow에 붙이는 방법

ghqr 결과는 혼자 보는 파일로 끝나면 아깝다.

팀 workflow에 붙여야 가치가 생긴다.

가장 단순한 방법은 월간 GitHub 운영 리뷰에 붙이는 것이다.

조직별 finding 수를 본다.

severity별 변화량을 본다.

오래 방치된 항목을 본다.

반복해서 나오는 저장소 유형을 본다.

정책으로 막을 항목과 교육으로 풀 항목을 나눈다.

다음 단계는 issue화다.

하지만 모든 finding을 issue로 만들면 backlog가 폭발한다.

폭발한 backlog는 아무도 보지 않는다.

언제 쓰면 좋은가

ghqr는 GitHub Enterprise나 여러 organization을 운영하는 팀에 잘 맞는다.

보안 점검 전에 현재 상태를 빠르게 보고 싶을 때 좋다.

인수인계 받은 GitHub 조직의 상태를 파악할 때 좋다.

Copilot, GHAS, Actions 정책을 같이 보고 싶을 때 좋다.

branch protection과 repository governance를 점검하고 싶을 때 좋다.

audit log streaming 같은 상위 운영 설정을 확인하고 싶을 때 좋다.

정기 점검 보고서를 Excel이나 Markdown으로 남기고 싶을 때 좋다.

MCP 기반 assistant에게 GitHub posture 점검 기능을 붙이고 싶을 때도 후보가 된다.

다만 마지막 경우는 권한 경계를 더 보수적으로 잡아야 한다.

AI assistant가 편하다고 해서 모든 운영 토큰을 맡길 필요는 없다.

편의성은 권한 설계 위에 얹어야 한다.

권한 설계 없이 편의성부터 얹으면 탑이 아니라 젠가가 된다.

그리고 젠가는 언젠가 무너진다.

보통 금요일 오후에 무너진다.

언제 쓰면 안 되는가

개인 공개 저장소 한두 개만 관리한다면 ghqr는 과할 수 있다.

GitHub 설정을 거의 바꾸지 않는 작은 팀도 처음부터 정기 스캔까지 갈 필요는 없다.

토큰 발급 정책이 정리되지 않은 조직도 바로 도입하지 않는 편이 낫다.

누가 결과를 읽고 조치할지 정해지지 않았다면 보고서만 쌓인다.

GitHub Enterprise 권한이 없는 상태에서 enterprise scan을 기대해도 결과가 제한된다.

GHE.com hostname을 모르는 상태에서 데이터 레지던시 환경을 스캔하려 하면 인증 오류가 반복될 수 있다.

민감한 조직 정보를 외부 로그나 AI 도구에 넘길 수 없는 환경에서는 MCP HTTP mode가 부담될 수 있다.

규정상 PAT 사용이 제한된 조직에서는 대체 인증과 승인 절차를 먼저 확인해야 한다.

보안 점검은 도구 선택보다 운영 승인 흐름이 먼저다.

도구가 좋아도 조직 정책을 우회하면 나중에 설명이 어렵다.

“좋은 의도였습니다”는 회의록에서 힘이 약하다.

처음부터 승인 흔적을 남기는 게 낫다.

실사용 체크리스트

아래 체크리스트는 도입 전 회의에서 그대로 써도 된다.

[ ] ghqr를 실행할 담당자를 정했다.
[ ] 스캔 대상 organization을 정했다.
[ ] enterprise scan이 필요한지 판단했다.
[ ] GHE.com data residency 사용 여부를 확인했다.
[ ] GH_HOST 또는 --hostname 필요 여부를 확인했다.
[ ] GITHUB_TOKEN을 어떤 계정에서 만들지 정했다.
[ ] token scope를 최소 단위로 설계했다.
[ ] SSO authorization 필요 여부를 확인했다.
[ ] PAT 사용이 조직 정책상 허용되는지 확인했다.
[ ] 설치 방식을 골랐다.
[ ] install script를 사전 확인할지 정했다.
[ ] release asset과 checksum 검증 여부를 정했다.
[ ] Docker 실행 시 volume mount 경로를 정했다.
[ ] source build 시 Go 버전을 확인했다.
[ ] 첫 스캔 대상을 작은 조직으로 정했다.
[ ] 출력 형식을 Excel, Markdown, JSON 중에서 골랐다.
[ ] 보고서 저장 위치를 정했다.
[ ] 보고서 접근 권한을 정했다.
[ ] debug log 공유 규칙을 정했다.
[ ] finding 분류 기준을 정했다.
[ ] 즉시 조치 항목 기준을 정했다.
[ ] 예외 처리 기준을 정했다.
[ ] 정책 변경이 필요한 항목을 따로 표시하기로 했다.
[ ] rate limit 영향을 확인했다.
[ ] 정기 실행 주기를 정했다.
[ ] MCP server 사용 여부를 정했다.
[ ] MCP HTTP mode 노출 여부를 별도로 승인받기로 했다.
[ ] 결과를 issue로 만들 때 묶음 단위를 정했다.
[ ] 다음 리뷰 날짜를 정했다.

체크리스트가 길어 보이지만 실제로는 대부분 10분 안에 답이 나온다.

답이 안 나오는 항목은 대체로 기술 문제가 아니라 운영 책임 문제다.

그리고 그게 더 중요하다.

권한 설계 예시

권한 설계는 조직마다 다르다.

그래도 시작점은 만들 수 있다.

목적	우선 scope	추가 검토
조직 설정 점검	`read:org`	member 정보 접근 범위
엔터프라이즈 설정 점검	`read:enterprise`	SSO 승인, enterprise owner 협의
저장소 설정 점검	`repo`	private repo 접근 민감도
감사 로그 설정 확인	`read:audit_log`	보안팀 승인
사용자 정보 확인	`read:user`	최소 필요성
Copilot 정책 확인	`copilot`	Copilot 관리자 권한

이 표는 공식 scope 목록을 운영 관점으로 다시 나눈 것이다.

핵심은 “필요하면 넣는다”다.

모든 scope를 기본값으로 넣는 게 아니다.

처음에는 조직 설정만 확인하고,

그다음 저장소 설정을 확인하고,

그다음 enterprise와 audit log까지 넓히는 방식이 안전하다.

물론 권한을 나누면 여러 번 실행해야 할 수 있다.

그래도 처음 한 번은 그렇게 해볼 만하다.

권한과 결과의 관계를 배울 수 있기 때문이다.

도구 도입 초반에는 속도보다 학습이 중요하다.

출력물 보관 규칙

ghqr 결과에는 조직과 저장소의 보안 설정 정보가 들어갈 수 있다.

따라서 공개 저장소에 그대로 올리면 안 된다.

내부 위키에 올릴 때도 접근 권한을 확인해야 한다.

Excel 파일은 다운로드와 재공유가 쉬워 더 조심해야 한다.

Markdown은 이슈나 문서로 붙이기 쉬워 편하지만, 검색에도 잘 걸린다.

JSON은 자동화에 좋지만, 원본 데이터가 그대로 남을 수 있다.

보관 규칙은 최소한 네 가지를 정하자.

어디에 저장할지,

누가 볼 수 있는지,

얼마나 보관할지,

외부 공유 전에 무엇을 가릴지다.

특히 외부 컨설턴트나 벤더와 공유할 때는 repo name과 org structure가 민감할 수 있다.

보안 설정 보고서는 보안 상태를 알려준다.

동시에 공격자에게도 힌트가 될 수 있다.

그러니까 “보고서니까 괜찮겠지”가 아니다.

보고서라서 더 조심해야 한다.

finding 처리 우선순위

모든 finding이 같은 무게는 아니다.

우선순위를 정할 때는 영향 범위와 수정 난이도를 같이 보자.

분류	예시	처리 방식
빠른 수정	metadata 누락, topic 누락	담당자 지정 후 일괄 정리
보안 핵심	secret scanning, code scanning, Dependabot alerts	보안팀과 우선 조치
배포 영향	branch protection, required status checks	CI 담당자와 검토
조직 정책	repository creation, fork policy, member privileges	플랫폼 정책 회의
비용·라이선스	Copilot seat usage, policy	관리자와 예산 검토
감사 체계	audit log streaming	보안 운영 프로세스 연결

이 표의 목적은 싸움을 줄이는 것이다.

개발팀은 배포가 막히는 걸 싫어한다.

보안팀은 열린 권한을 싫어한다.

플랫폼팀은 예외가 늘어나는 걸 싫어한다.

모두 각자 맞는 말을 한다.

그래서 finding을 기술 항목이 아니라 의사결정 항목으로 분류해야 한다.

ghqr는 대화를 시작하게 해주는 도구다.

대신 대화를 끝내주지는 않는다.

끝내는 건 사람 몫이다.

아쉽지만 아직 회의 자동 종료 버튼은 없다.

있으면 제가 먼저 삽니다.

CLI 실행 예시 흐름

아래는 안전한 첫 실행 흐름 예시다.

# 1. token을 현재 shell에만 넣는다.
export GITHUB_TOKEN="<approved-read-token>"

# 2. 필요하면 GHE.com hostname을 지정한다.
export GH_HOST="mycompany.ghe.com"

# 3. 작은 조직 하나부터 스캔한다.
ghqr scan -o my-org

# 4. 문제가 생기면 debug로 다시 확인한다.
ghqr scan -o my-org --debug

# 5. 작업이 끝나면 token을 제거한다.
unset GITHUB_TOKEN
unset GH_HOST

실제 옵션은 사용 중인 ghqr 버전의 ghqr -h로 확인해야 한다.

README도 ghqr -h를 통해 사용 가능한 commands와 options를 확인하라고 안내한다.

CLI 도구는 버전이 올라가면 옵션 이름이나 기본값이 바뀔 수 있다.

공식 릴리스 기준 2026년 4월 22일 v.0.2.0이 latest로 표시돼 있다.

이 글을 읽는 시점에는 더 새 버전이 있을 수 있다.

그래서 설치 후 ghqr -h와 release notes 확인은 습관으로 두는 게 좋다.

최신 버전 확인은 귀찮지만, 옵션 삽질보다 싸다.

삽질은 운동이 되지만 업무 시간에는 별로 반갑지 않다.

CI에 붙일 때

ghqr를 CI에 붙이고 싶을 수 있다.

가능은 하겠지만 처음부터 CI 자동화를 목표로 잡지는 않는 편이 좋다.

이유는 간단하다.

첫째, 토큰 scope가 민감하다.

둘째, 결과 파일 보관이 민감하다.

셋째, rate limit 영향이 있다.

넷째, finding이 바로 실패 조건으로 이어지면 팀이 피곤해진다.

처음에는 manual run으로 기준을 만든다.

그다음 scheduled workflow로 보고서만 생성한다.

그다음 threshold를 정한다.

그다음 일부 항목만 실패 조건으로 만든다.

예를 들어 critical security finding이 늘어나면 알림을 보낼 수 있다.

하지만 description 누락 하나로 pipeline을 실패시키는 건 과하다.

도구가 팀에게 미움받는 가장 빠른 방법은 사소한 항목으로 배포를 막는 것이다.

처음에는 관찰,

그다음 알림,

마지막에 차단이다.

차단은 마지막 카드다.

처음부터 꺼내면 분위기가 약간 카드게임 결승전 된다.

MCP와 CI는 분리해서 생각하기

MCP server mode와 CI scheduled scan은 목적이 다르다.

MCP는 assistant가 필요할 때 ghqr 기능을 호출하는 흐름이다.

CI는 정해진 시간이나 이벤트에 ghqr를 실행하는 흐름이다.

MCP는 상호작용성이 좋다.

CI는 재현성과 기록성이 좋다.

둘을 한 번에 도입하면 권한 설계가 복잡해진다.

처음에는 CLI manual run으로 기준을 만든다.

그다음 CI scheduled report를 붙인다.

마지막으로 MCP를 검토한다.

MCP를 먼저 붙이면 “AI에게 물어보면 되지”가 되기 쉽다.

그런데 AI가 어떤 token으로 무엇을 봤는지 모르면 감사가 어려워진다.

운영에서는 편한 질문보다 추적 가능한 답이 더 중요할 때가 많다.

특히 GitHub 조직 점검은 그렇다.

누가,

언제,

무슨 권한으로,

어떤 범위를 봤는지가 남아야 한다.

이 네 가지가 없으면 나중에 기억력 대회가 열린다.

대회 상품은 보통 야근이다.

팀에 설명할 때 쓰는 문장

ghqr를 팀에 소개할 때는 “보안 검사 도구”라고만 말하면 조금 딱딱하다.

아래처럼 설명하면 더 잘 통한다.

ghqr는 우리 GitHub 조직의 설정 상태를 정기적으로 캡처하는 CLI다.

저장소마다 branch protection과 security feature가 어떻게 되어 있는지 한 번에 본다.

조직 단위의 access control과 governance 설정도 확인한다.

Copilot 정책과 Actions 설정처럼 최근에 관리 포인트가 늘어난 항목도 같이 본다.

결과는 Excel, Markdown, JSON으로 뽑을 수 있다.

목적은 팀을 감시하는 것이 아니라 빠진 설정을 빨리 찾는 것이다.

발견된 항목은 위험도와 수정 난이도로 분류한다.

바로 차단하지 않고 먼저 기준을 만든다.

이 정도로 설명하면 반발이 줄어든다.

도구 도입에서 말투는 은근히 중요하다.

“감사합니다”와 “털겠습니다”는 같은 스캔이어도 느낌이 다르다.

우리는 전자를 택하자.

평화가 좋다.

운영 실패 패턴

ghqr 도입에서 흔한 실패 패턴도 정리해두자.

첫 번째 실패는 개인 PAT로 전체 조직을 스캔하는 것이다.

빠르지만 지속 가능하지 않다.

담당자가 퇴사하거나 권한이 바뀌면 흐름이 끊긴다.

두 번째 실패는 보고서를 만들고 아무도 안 읽는 것이다.

자동화가 아니라 장식품이 된다.

세 번째 실패는 모든 finding을 같은 우선순위로 보는 것이다.

그러면 중요한 항목이 사소한 항목에 묻힌다.

네 번째 실패는 첫 주부터 차단 정책을 거는 것이다.

팀이 도구를 우회하려고 한다.

다섯 번째 실패는 MCP HTTP mode를 별도 검토 없이 여는 것이다.

편하지만 네트워크 노출과 토큰 주입을 같이 봐야 한다.

여섯 번째 실패는 debug log를 그대로 공유하는 것이다.

문제 해결은 빨라질 수 있지만 민감 정보가 퍼질 수 있다.

일곱 번째 실패는 rate limit을 무시하는 것이다.

큰 조직에서는 시간이 길어지고 다른 자동화에 영향을 줄 수 있다.

여덟 번째 실패는 예외 정책을 안 만드는 것이다.

모든 저장소가 같은 기준을 만족할 수는 없다.

예외가 없다면 현실이 문서를 이긴다.

문서가 지면 보통 아무도 문서를 안 본다.

도입 순서 추천

작은 팀이라면 이렇게만 해도 된다

작은 팀은 모든 기능을 다 쓰지 않아도 된다.

조직 하나를 대상으로 월 1회 manual scan을 한다.

Excel 결과를 내부 드라이브에 저장한다.

상위 finding 10개만 본다.

branch protection과 Dependabot 설정만 먼저 본다.

CODEOWNERS와 Actions 권한을 다음 달에 본다.

Copilot 정책은 실제로 Copilot을 조직 단위로 쓰는 경우에만 본다.

audit log streaming은 enterprise 운영 단계에서 본다.

MCP는 당장 붙이지 않는다.

이 정도면 충분히 시작할 수 있다.

도구 도입은 크게 시작하는 것보다 계속 볼 수 있게 시작하는 게 중요하다.

작은 반복이 큰 선언보다 오래 간다.

선언은 멋있고,

반복은 이긴다.

둘 다 있으면 좋지만, 하나만 고르라면 반복이다.

큰 조직이라면 이렇게 나누자

큰 조직은 대상과 책임을 나눠야 한다.

enterprise owner는 enterprise scan 결과를 본다.

organization owner는 org-level setting을 본다.

repository admin은 repo-level finding을 본다.

security team은 security, audit log, secret scanning, code scanning 항목을 본다.

platform team은 Actions, branch protection, repository creation policy를 본다.

developer productivity team은 Copilot policy와 MCP setting을 본다.

이렇게 나누지 않으면 보고서가 너무 커진다.

큰 보고서는 보통 안 읽힌다.

잘게 나눈 보고서가 더 잘 움직인다.

분류 기준은 category와 owner를 함께 둔다.

예를 들어 Security / Security Team,

Branch Protection / Platform Team,

Repository Metadata / Repo Owner,

Copilot / Dev Productivity,

Audit Log / Security Operations처럼 둔다.

이 매핑표가 있으면 finding을 issue로 만들 때 편하다.

없으면 매번 “이거 누구 거예요?”가 된다.

그 문장은 조직 운영에서 꽤 비싼 문장이다.

ghqr를 AI workflow에 붙일 때

ghqr가 MCP server를 제공한다는 점은 흥미롭다.

AI assistant가 조직이나 저장소 스캔을 호출하고 결과를 요약할 수 있기 때문이다.

하지만 여기서 중요한 건 assistant가 아니라 경계다.

AI workflow에 붙일 때는 전용 workspace를 쓰자.

민감한 저장소와 실험 workspace를 섞지 말자.

토큰 scope는 assistant용으로 더 좁게 잡자.

HTTP mode는 localhost나 내부망 제한 없이 열지 말자.

결과 요약을 외부 LLM에 보내는 구조라면 데이터 반출 정책을 확인하자.

AI가 요약한 finding과 원본 report를 구분하자.

조치 결정은 원본 report 기준으로 하자.

AI summary는 빠른 탐색에는 좋다.

하지만 감사 자료로는 원본이 필요하다.

요약은 길을 알려주는 표지판이다.

표지판이 목적지는 아니다.

운영에서는 목적지 좌표도 남겨야 한다.

릴리스 확인 포인트

공식 GitHub releases 페이지 기준 latest는 2026년 4월 22일 v.0.2.0으로 표시됐다.

이 릴리스에는 GHE.com data residency를 위한 --hostname flag 추가가 포함돼 있다.

repository scan 관련 변경도 포함돼 있다.

릴리스 자산은 darwin, linux, windows용 zip과 sha256 파일로 제공된다.

따라서 설치 스크립트를 쓰지 않고 직접 asset을 받아 검증하는 선택지도 있다.

릴리스 확인 때는 세 가지를 보자.

현재 latest version이 무엇인지 본다.

내 OS와 architecture에 맞는 asset이 있는지 본다.

sha256 파일이 함께 있는지 본다.

릴리스 노트에 breaking change나 인증 관련 변경이 있는지 본다.

특히 CLI 도구는 작은 버전에서도 옵션이 늘거나 기본 동작이 바뀔 수 있다.

운영 문서에는 사용한 버전을 적어두자.

“그때는 됐는데요”는 버전이 없으면 추리소설이 된다.

버전이 있으면 사건 기록이 된다.

우리는 사건 기록 쪽이 좋다.

실제 조치 표 예시

보고서가 나온 뒤에는 아래처럼 조치 표를 만들면 좋다.

우선순위	항목	담당	마감	처리 방식
P0	secret scanning 비활성	Security	7일	정책 확인 후 활성화
P1	branch protection 누락	Platform	14일	프로덕션 저장소부터 적용
P1	CODEOWNERS 누락	Repo Owner	14일	주요 저장소 우선
P2	repository description 누락	Repo Owner	30일	일괄 정리
P2	Dependabot update 누락	Platform	30일	템플릿 배포
P3	topic 누락	Repo Owner	60일	문서 정비와 함께 처리

이 표는 예시다.

정답은 아니다.

조직마다 기준이 다르다.

하지만 이런 표가 있어야 결과가 움직인다.

finding만 있으면 사람은 부담을 느낀다.

담당, 마감, 처리 방식이 있으면 일이 된다.

일이 되는 순간 귀찮아지지만, 그래도 해결된다.

부담은 오래 남고,

일은 끝낼 수 있다.

WordPress 글감으로 보면 무엇이 중요한가

TECHTAEK 관점에서 ghqr는 “새 CLI 나왔습니다”로 끝내면 약하다.

중요한 건 운영 기준이다.

독자는 설치 명령보다 실패 지점을 더 궁금해한다.

권한은 어디까지 줘야 하는지,

GHE.com은 왜 hostname을 따로 줘야 하는지,

MCP를 켜도 되는지,

결과 파일은 어디에 둬야 하는지,

rate limit은 실제로 문제가 되는지,

보고서를 누가 읽어야 하는지가 더 중요하다.

그래서 ghqr 글은 뉴스 요약보다 체크리스트가 맞다.

특히 GitHub 운영자는 이미 설정 메뉴를 알고 있다.

필요한 건 “어떤 순서로 볼 것인가”다.

도구는 순서를 만들어줄 때 가치가 커진다.

ghqr도 마찬가지다.

설치보다 운영 순서가 본체다.

팀 도입용 30분 플랜

30분 안에 첫 검토를 한다면 이렇게 하면 된다.

0분부터 5분까지 공식 README를 읽는다.

5분부터 10분까지 token scope를 확인한다.

10분부터 15분까지 작은 organization을 고른다.

15분부터 20분까지 설치 방식과 실행 환경을 정한다.

20분부터 25분까지 첫 scan을 실행한다.

25분부터 30분까지 상위 finding만 읽는다.

이 짧은 플랜의 목적은 완벽한 보고서가 아니다.

도구가 우리 조직에서 돌아가는지 확인하는 것이다.

첫날에는 finding을 고치려 하지 않아도 된다.

먼저 실행 가능성을 확인한다.

그다음 결과 해석 회의를 잡는다.

그다음 조치 기준을 만든다.

첫날부터 다 고치려 하면 지친다.

지치면 다음 달에 안 한다.

운영 도구는 다음 달에도 해야 의미가 있다.

보안팀과 개발팀 사이에서

ghqr 결과는 보안팀과 개발팀 사이의 번역 도구가 될 수 있다.

보안팀은 control과 risk를 본다.

개발팀은 배포 흐름과 생산성을 본다.

플랫폼팀은 표준화와 예외 관리를 본다.

같은 finding도 보는 관점이 다르다.

branch protection 강화는 보안팀에게 좋은 소식이다.

하지만 개발팀에게는 긴급 hotfix 흐름 변경일 수 있다.

Actions permission 축소는 보안상 좋다.

하지만 일부 workflow가 깨질 수 있다.

Copilot content exclusion은 민감 코드 보호에 좋다.

하지만 개발자 경험과 문서화가 필요하다.

따라서 ghqr 결과를 공유할 때는 “문제”보다 “결정”으로 표현하자.

예를 들어 “branch protection 없음”보다 “프로덕션 저장소 branch protection 기준을 정해야 함”이 낫다.

그 문장이 팀을 움직인다.

말은 도구보다 느리지만, 방향을 정한다.

방향 없는 자동화는 빨리 길을 잃는다.

이 글의 적용 범위

이 글은 2026년 4월 28일에 확인한 microsoft/ghqr 공식 README와 GitHub releases 페이지를 기준으로 썼다.

로컬 inbox note의 요약도 참고했다.

다만 최종 사실 확인은 공식 GitHub repo와 README를 우선했다.

GitHub CLI 옵션과 release 상태는 이후 바뀔 수 있다.

따라서 실제 도입 전에는 repo README, release notes, ghqr -h를 다시 확인해야 한다.

특히 보안 관련 scope와 authentication 동작은 조직 정책에 따라 다르게 적용될 수 있다.

이 글은 법적 감사 기준이 아니다.

운영 점검을 시작하기 위한 실무 체크리스트다.

정책 결정은 각 조직의 보안팀, 플랫폼팀, 법무·컴플라이언스 기준과 함께 봐야 한다.

그래도 한 가지는 꽤 확실하다.

ghqr를 잘 쓰려면 CLI 명령보다 운영 질문을 먼저 세워야 한다.

무엇을 볼지,

누가 볼지,

어디까지 권한을 줄지,

발견 뒤 무엇을 할지가 핵심이다.

그 네 가지가 정리되면 ghqr는 꽤 쓸 만한 GitHub 운영 점검 도구가 된다.

FAQ

ghqr는 GitHub CLI와 같은 도구인가?

같은 GitHub 생태계 CLI처럼 보이지만 목적이 다르다.

GitHub CLI는 issue, pull request, repository 작업을 직접 다루는 범용 도구에 가깝다.

ghqr는 GitHub 조직, 엔터프라이즈, 저장소의 운영 설정을 점검하는 보고서형 도구에 가깝다.

그래서 gh는 매일 쓰는 조작 도구,

ghqr는 주기적으로 돌리는 점검 도구로 보는 편이 자연스럽다.

개인 개발자도 ghqr를 써야 하나?

개인 공개 저장소 몇 개만 있다면 우선순위가 높지 않다.

branch protection, Dependabot, CODEOWNERS, Actions 권한 정도는 GitHub UI와 기본 문서로도 점검할 수 있다.

다만 여러 private repository를 운영하거나 작은 조직을 맡고 있다면 한 번쯤 실행해볼 만하다.

핵심은 저장소 수보다 운영 복잡도다.

`repo` scope를 꼭 넣어야 하나?

저장소 설정, branch protection, security feature까지 보려면 README 기준 repo scope가 필요하다.

하지만 처음부터 모든 scope를 넣는 방식은 권하지 않는다.

조직 설정만 먼저 볼지,

저장소 설정까지 볼지,

enterprise 설정까지 볼지를 나눠서 토큰을 설계하는 편이 좋다.

권한이 넓을수록 결과는 풍부해지지만 관리해야 할 위험도 같이 커진다.

MCP server는 바로 켜도 되나?

개인 로컬 실험이라면 stdio mode부터 작게 테스트할 수 있다.

조직 운영 환경에서는 별도 검토가 필요하다.

MCP server에는 ghqr 기능과 GitHub token이 연결될 수 있다.

특히 HTTP/SSE mode는 네트워크 노출을 동반하므로 더 보수적으로 봐야 한다.

remote access가 꼭 필요한 이유가 없다면 처음부터 HTTP mode를 열 필요는 없다.

ghqr 결과가 나오면 바로 설정을 바꿔야 하나?

아니다.

먼저 finding을 즉시 수정, 영향 검토, 정책 결정, 예외 관리로 나눠야 한다.

예를 들어 metadata 누락은 빠르게 고칠 수 있다.

branch protection 강화는 CI와 배포 흐름을 확인해야 한다.

repository creation policy나 Copilot policy는 조직 정책 논의가 먼저일 수 있다.

ghqr 결과는 조치 명령서가 아니라 운영 판단의 입력값이다.

공식 출처

microsoft/ghqr GitHub repository
microsoft/ghqr README
microsoft/ghqr releases
로컬 inbox 요약: 00.Inbox/260428_[요약] GitHub - microsoft ghqr GitHub Quick Review. Evaluate your enterprise and organizations wi.md