# GitHub CLI가 이제 가명 기반 텔레메트리를 수집함 > Clean Markdown view of GeekNews topic #28798. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28798](https://news.hada.io/topic?id=28798) - GeekNews Markdown: [https://news.hada.io/topic/28798.md](https://news.hada.io/topic/28798.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-23T09:57:47+09:00 - Updated: 2026-04-23T09:57:47+09:00 - Original source: [cli.github.com/telemetry](https://cli.github.com/telemetry) - Points: 2 - Comments: 1 ## Topic Body - **가명 기반 텔레메트리**를 GitHub CLI에서 전송하며, 목적은 기능 사용 가시성 확보와 제품 개선 지원 - **subcommand 채택 여부**와 flags 사용 패턴을 바탕으로 작업 우선순위 결정, 사용자 요구 충족 여부 평가, discoverability와 design 재검토에 활용됨 - **오픈소스 구현**으로 `cli/cli` 저장소에서 텔레메트리 코드를 직접 검토할 수 있으며, logging mode로 실제 전송 전 JSON payload 확인 가능 - **옵트아웃**은 환경 변수 `GH_TELEMETRY=false`, `DO_NOT_TRACK=true` 또는 `gh config set telemetry disabled`로 가능하며, 환경 변수가 config보다 우선 적용됨 - 텔레메트리 이벤트는 **GitHub 내부 분석 인프라**로 전송되며, 이 페이지는 `gh`의 클라이언트 측 데이터 수집만 다루고 extensions와 Copilot CLI는 별도 대상임 --- ### 텔레메트리 - GitHub CLI가 **가명 기반 텔레메트리**를 전송하며, 목적은 제품 개선 지원 - 어떤 데이터가 전송되는지와 그 이유를 사용자가 이해할 수 있도록 정보 제공 ### 텔레메트리 수집 이유 - **GitHub CLI 기능 사용 가시성** 확보 필요성 언급, 특히 agentic adoption 증가에 따라 실제 사용 방식 파악 목적 - 팀이 이 데이터를 사용해 작업 우선순위 결정 - 기능이 실제 사용자 요구를 충족하는지 평가 - 새 **subcommand 출시 후 채택 여부** 확인 목적 명시 - 사용자가 거의 없으면 해당 기능의 discoverability 또는 design 재검토 필요 - 특정 flags와 함께 높은 사용량이 확인되면 더 나은 경험에 투자할 지점 파악 가능 ### 텔레메트리 검토 - GitHub CLI가 **오픈소스**이며, 텔레메트리 구현을 `cli/cli` 저장소에서 직접 검토 가능 - 실제 전송 없이 전송 예정 데이터를 확인하려면 **logging mode** 사용 가능 - 환경 변수 방식 지원 - `export GH_TELEMETRY=log` - CLI 설정 방식 지원 - `gh config set telemetry log` - logging mode에서는 원래 전송될 **JSON payload**가 stderr에 출력됨 - 텔레메트리를 계속 활성화할지 결정하기 전에 각 필드 점검 가능 - 예시 명령으로 `GH_TELEMETRY=log gh repo list --archived` 제시 - 예시 payload에 포함된 이벤트 정보 명시 - 이벤트 타입 `command_invocation` - dimensions 항목으로 `agent`, `architecture`, `command`, `device_id`, `flags`, `invocation_id`, `is_tty`, `os`, `timestamp`, `version` 포함 - 예시 값으로 `architecture: arm64`, `command: gh repo list`, `flags: archived`, `os: darwin`, `version: 2.91.0` 표시 - 해당 명령은 실행된 **정확한 명령과 컨텍스트**에 대한 텔레메트리만 로그 가능 - 환경 변수 변경 시 payload에 포함되는 events와 event dimensions가 달라질 수 있음 - 인증된 계정 변경 시에도 포함 항목이 달라질 수 있음 ### 옵트아웃 방법 - logging mode에서 확인한 텔레메트리에 대해 **옵트아웃** 가능 - 환경 변수 방식 지원 - `export GH_TELEMETRY=false` - falsy 값으로 `0`, `false`, `disabled`, 빈 문자열 사용 가능 - `DO_NOT_TRACK` 관례도 지원하며 `export DO_NOT_TRACK=true` 예시 제공 - CLI 설정 방식 지원 - `gh config set telemetry disabled` - **환경 변수 우선순위**가 config 값보다 높음 ### 데이터 전송 위치 - 텔레메트리 이벤트가 GitHub의 **내부 분석 인프라**로 전송됨 - 데이터 처리 방식 관련 추가 정보는 **GitHub General Privacy Statement** 참고 안내 ### 추가 정보 - GitHub CLI는 GitHub 및 **서드파티 extensions** 설치를 통한 기능 추가 지원, agents 포함 - 이 extensions는 자체 사용 데이터 수집 가능성 존재 - 옵트아웃 설정으로 제어되지 않음 - 각 extension 문서를 통해 텔레메트리 보고 방식과 비활성화 가능 여부 확인 필요 - 이 페이지는 GitHub CLI `gh`의 **클라이언트 측 데이터 수집**만 다룸 - GitHub Copilot 및 Copilot CLI에는 적용되지 않음 - Copilot CLI는 별도로 데이터 수집 처리 - 관련 정보 위치로 `Using GitHub Copilot CLI`, `Responsible Use of the GitHub Copilot CLI` 안내 ## Comments ### Comment 56104 - Author: neo - Created: 2026-04-23T09:57:48+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47862331) - 왜 기업 개발팀이 늘 **텔레메트리**로 사용자를 들여다보려 하는지 궁금함 좋은 엔지니어링과 디자인만으로는 충분하지 않은지 묻고 싶음 Git은 20년 넘게 누가 어떤 기능과 명령을 쓰는지 세세한 분석 없이도 잘 돌아왔는데, 텔레메트리가 있었다고 해서 정말 더 나아졌을지 아니면 그냥 **산만한 데이터**만 늘었을지 의문임 - 예전엔 나도 불필요하다고 생각했는데, 직접 스타트업을 만들고 나서는 생각이 바뀜 **analytics** 없이는 눈을 가리고 운전하는 느낌임 사용자가 진짜 뭘 중요하게 여기는지, 어떤 흐름을 최적화해야 하는지 알 수 없고, 사람들이 말로 하는 것과 실제로 소프트웨어를 쓰는 방식의 차이가 놀라울 정도로 큼 - 개발자와 사용자는 필요와 생각이 다르기 때문에, 좋은 설계만으로는 부족하다고 봄 사람들에게서 **좋은 피드백**을 얻기 어려운 경우도 많고, 모두가 기능 X의 아이디어는 좋아한다고 해도 실제로는 전혀 안 쓸 수 있음 또 목소리 큰 팬층이 있어 보여도 매출이나 실사용으로 이어지지 않을 수 있음 Git도 텔레메트리가 있었다면 더 나아졌을 가능성이 높다고 생각함 Git은 유명할 정도로 **UI가 나쁨** 초반에 사람들이 얼마나 많이 헤매는지 데이터로 바로 드러났을 것이고, 예를 들어 `git checkout -- foo.txt` 같은 비직관적 명령 대신 `git restore` 같은 개선이 훨씬 일찍 들어왔을 것이라 봄 - 안타깝게도 이런 현상은 **비기술적 의사결정자**가 많기 때문이라고 봄 도구를 직접 쓰지 않는 사람들이 실제 사용 방식을 이해하지 못하니, 개발 도구를 맡은 PM이 자기 일을 하기 위해 이런 데이터를 요구하게 됨 전자상거래 PM이 프런트엔드에 추적 스크립트를 잔뜩 얹는 것과 비슷한 구조로 보임 엔지니어만으로도 충분히 사용자와 상호작용을 설계할 수 있었는데, VC 이후로 기술 제품을 깊이 비기술적인 사람이 이끄는 패러다임이 굳어진 점이 문제라고 느낌 결국 데이터는 그들에게 넘어가고, 누군가는 **PM 월급**을 정당화하게 되는 셈으로 보임 - Git에 텔레메트리가 있었으면 도움이 안 됐을 거라고 당연하게 말할 수는 없다고 느낌 나한테는 그게 **명확하지 않음** - Git은 **설계와 사용성**이 형편없다고 봄 엔지니어가 엔지니어를 위해 인터페이스를 만들고, 좋은 피드백 루프가 없었던 대표 사례처럼 보임 아이러니하게도 이 예시 자체가, 개발자가 자기 제품이 실제로 어떻게 쓰이는지 더 잘 이해해야 한다는 점을 보여준다고 느낌 개발자의 머릿속 사용 시나리오는 대개 현실과 꽤 다름 - `gh` CLI의 **opt-out** 문제는 생각보다 복잡하다고 봄 `gh`는 CI/CD 파이프라인이나 서버 환경에서도 돌아가는데, 그 환경에서는 프라이버시 때문이 아니라 네트워크 제약 때문에 `github.com`으로 나가는 연결 자체를 원하지 않을 수 있음 그런 곳에서는 텔레메트리가 기본 켜짐이면 CI가 실패하거나 Bastion host가 GitHub에 전혀 닿지 못할 수 있음 반면 Git 자체는 사용자가 명시적으로 push하기 전까지는 완전히 로컬에서 동작함 신뢰 모델이 다른 셈임 Git은 설정하지 않으면 절대 **phone home** 하지 않지만, `gh`는 GitHub API를 감싼 래퍼라 기능상 호출이 필요한 점은 인정함 다만 그 사실과 별개로, 명령 사용 패턴까지 추가로 수집해 업로드해야 하는지는 따로 따져야 한다고 봄 - 텔레메트리 제출이 안 된다고 프로그램이 **하드 에러**로 죽을 거라고는 생각하지 않음 - `gh`가 `GitHub.com`에 연결 못 하면 사실상 쓸모없는지 궁금함 아니면 **enterprise GitHub** 연결이 주된 사례인지 묻고 싶음 - 개발자 셋이 코드베이스의 어떤 영역에 시간의 80퍼센트를 쓰는데 정작 사용량이 없고, 앞으로도 현실적으로 늘 가능성이 안 보인다면 그 인력을 다른 곳으로 돌리거나 기능 자체를 다시 생각하는 편이 더 나을 수 있다고 봄 다만 이런 **analytics**의 문제는, 무해하게 쓸 수도 있지만 고유 식별자와 행동 패턴을 묶어서 기계학습으로 신원을 재구성할 수 있다는 이해가 깔려 있다는 점임 타임스탬프까지 포함되면 더 심각해짐 그래서 언제 어떤 텔레메트리가 전송되는지 정확히 드러내면 좋겠다고 생각함 예를 들어 전송은 하지 않되 **verbose 모드**로 무엇이 보내질지 보여주는 옵션을 두고, 사용자가 그걸 검토한 뒤 켤지 결정하게 하면 됨 Steam Hardware Survey처럼 무엇이 전송되는지 보여주는 방식이 맞다고 느낌 - 모든 `gh` 명령은 결국 GitHub **API 래퍼**일 뿐인데, 이 논의가 거기서 더 헷갈려진다고 느낌 - 이렇게 짧은 PR은 좋아함 [https://github.com/cli/cli/pull/13254](https://github.com/cli/cli/pull/13254) 내용도 간단해서, 텔레메트리를 막던 env var를 제거해 이제 **기본 활성화**로 바꾼다는 뜻으로 읽힘 - 기본 활성화일 뿐 아니라, 아예 **비활성화 불가**처럼 보인다고 느낌 enterprise를 제외하면 사실상 강제로 켜지는 구조처럼 보임 - 지난달 홈랩에 **gitea**를 배포한 게 정말 만족스러움 GitHub에서 가져오기 기능도 있고, 솔직히 GitHub보다 더 빠르고 uptime도 더 좋다고 느낌 Claude도 `tea` CLI와 Git으로 잘 붙고, 거의 GitHub 복제품 같지만 지금까지는 오히려 더 낫다고 봄 - 나는 **Forgejo**를 쓰는데 같은 코어 코드를 공유해서 그런지 정말 훌륭하다고 느낌 속도도 빠르고 uptime도 좋음 심지어 책상 옆 캐비닛의 Pi 4에서 돌아가서 인터넷이 끊겨도 계속 동작함 백업은 borg와 syncthing으로 오프사이트까지 보내고 있음 설정엔 약간 손이 가지만, 그 이후 유지보수 시간은 거의 제로에 가까움 2주에 한 번 정도만 SSH로 들어가서 SSD 공간, RAM 사용량, `apt update`, `upgrade`, 메이저 버전 업만 확인하면 됨 - GitHub가 이미 자기 서버로 들어오는 모든 요청을 수집하고 집계하고 있다고들 생각하지 않는지 궁금함 결국 `gh` CLI의 존재 이유도 그 서버와 상호작용하는 데 있음 요청 추적 자체를 원치 않는다면, 이 설정 하나보다 훨씬 더 많은 걸 **opt-out** 해야 할 것이라고 봄 - 서버에 데이터가 있으니 당연히 이미 보고 있을 것이라고 생각함 다만 이번에는 클라이언트 쪽 메트릭을 더해서, GitHub로 가는 것뿐 아니라 **GitLab, Codeberg** 같은 다른 곳으로 가는 흐름까지 더 잘 추적하려는 것처럼 보임 - GitHub 입장에서는 좋은 일일 수 있다고 봄 모든 회사는 이런 데이터가 필요하고, 어떤 곳은 제품 개선에 쓰고 어떤 곳은 덜 훌륭한 목적으로도 씀 HN 이용자들이 텔레메트리를 싫어하는 건 알지만, SaaS를 직접 만들어봤다면 **telemetry**가 사실상 필수라는 걸 알게 된다고 느낌 - GitHub CLI는 **SaaS**가 아니라 명령줄 유틸리티라고 봄 - 차라리 사용자에게 직접 묻는 방식이 먼저여야 하지 않나 싶음 결국 **대화**가 없는 점을 꼬집고 싶음 - 도구의 텔레메트리 내용을 어떻게 검증하는 게 **모범 사례**인지 궁금함 핵심은 디테일에 있고, 사용자와 제품 제작자 사이에서 양쪽 모두 납득할 만한 중간 지대를 만들어줄 신뢰 가능한 중개 서비스 같은 게 있을지 생각해보는 중임 Claude 도움으로 조사한 내용을 Gist로 정리하고 있다고 밝힘 - AI 옹호자들의 말투가 다 비슷하게 느껴진다고 봄 - Microsoft의 **Embrace, extend, extinguish**를 떠올리게 됨 앞의 두 단계는 이미 진행됐고, 5년 안에 GH CLI가 GitHub 저장소와 상호작용하는 유일한 방법이 될 거라고 예상함 그러면 세 번째 단계도 완성되고 사이클이 끝난다고 봄 - 그 예측에는 기꺼이 내기할 수 있음 얼마나 걸 건지 묻고 싶을 정도로 **비현실적 전망**처럼 느낌 - 이런 식의 주장은 정말 지치게 만든다고 느낌 사람들은 WSL, GPU 지원, WSLg, PowerShell에도 계속 **EEE** 프레임을 씌웠지만 실제로 그런 일은 벌어지지 않았음 지금도 그렇고, 애초에 계획된 흔적조차 잘 안 보임 감으로 해석할 수 있는 게 아니라, 90년대 Microsoft가 실제로 썼던 반복 가능한 수법이 지금 어디에 재현되고 있는지 **증거**를 보여달라는 입장임 Microsoft Git이 오픈소스보다 더 많은 기능으로 잠그고 있는지도 없고, Microsoft Linux 같은 것도 마찬가지임 GitHub는 Git 위의 래퍼이고 HTTP와 SSH 위에서 돌아가는 Git 서버라는 핵심 설계가 있음 그 기반을 깨고 저장소 접근을 `gh`로만 잠그는 건 너무 큰 변경이라 현실성이 낮다고 봄 `gh`는 그저 API 호출을 쉽게 해주는 도구일 뿐이고, 대다수 GitHub 사용자는 존재조차 잘 모른다고 느낌 오히려 GitHub를 망가뜨릴 가능성이 큰 건 악의적인 EEE가 아니라, **무능한 경영**이라고 봄 사용자와 제품을 이해하지 못하는 경영진 때문에 추락할 가능성이 더 크다고 느낌 - 나는 그 예측을 완전히 의심하지는 않음 이미 어떤 저장소들은 `gh` 없이 다루기 번거롭게 느껴지고, **강제 흐름**이 조금씩 생기고 있다고 봄 `gh`가 정확히 뭘 더 주는지는 안 써봐서 모르겠지만, 나한테는 표준 Git 명령만으로 충분함 - 여기서 말하는 `pseudonymous telemetry`가 **비식별 텔레메트리**를 뜻하는지, 아니면 사실은 익명이 아닌 텔레메트리라는 뜻인지 헷갈림 두 표현은 거의 반대 의미인데, 지금 문구대로라면 식별 가능한 데이터를 수집한다고 말하는 셈처럼 보임 - 해당 페이지에는 **pseudonymous**라는 표현만 있고, `pseudoanonymous`는 HN 글 작성자가 만든 표현으로 보임 - 그 뜻은 사람의 신원이나 GitHub 계정과 연결되지는 않지만, 한 기계에서 나온 모든 텔레메트리를 한데 볼 수 있다는 의미로 이해함 각 기계에 **UUID**가 붙고, 그걸 기준으로 기계를 식별하는 구조처럼 보임