▲

GitHub CLI가 이제 가명 기반 텔레메트리를 수집함

 (cli.github.com/telemetry)
2P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 가명 기반 텔레메트리를 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 안내

함께 보면 좋은 글 β

▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • 왜 기업 개발팀이 늘 텔레메트리로 사용자를 들여다보려 하는지 궁금함
    좋은 엔지니어링과 디자인만으로는 충분하지 않은지 묻고 싶음
    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
    내용도 간단해서, 텔레메트리를 막던 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가 붙고, 그걸 기준으로 기계를 식별하는 구조처럼 보임
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.