GitHub CLI가 텔레메트리 수집을 시작했어요 — 뭐가 바뀌고 어떻게 꺼야 할까

조용히 바뀐 정책 하나

GitHub의 공식 커맨드라인 도구 GitHub CLI(gh)가 이번에 정책을 바꿨어요. 이제 의사익명화된(pseudoanonymous) 텔레메트리 데이터를 기본으로 수집한다고 공식 문서에 올라왔거든요. gh issue list, gh pr create 같은 명령을 쓸 때마다 일부 정보가 GitHub 쪽으로 전송된다는 얘기예요.

이게 왜 이슈가 되냐면, 개발자들이 평소에 제일 민감하게 반응하는 주제가 '내 도구가 내 뒤에서 뭘 보내고 있는가' 거든요. VS Code 텔레메트리 논쟁, Homebrew의 analytics 기본값, Next.js의 익명 분석 등등, 이런 문제가 터질 때마다 커뮤니티가 들끓었죠. 이번에도 마찬가지 결의 반응이 나왔어요.

구체적으로 뭘 수집하나

공식 문서를 찬찬히 보면 수집 항목이 꽤 자세히 적혀 있어요. 요약하면 어떤 명령어를 썼는지(예: gh repo clone), 명령이 성공했는지 실패했는지, 실행에 걸린 시간, 사용 중인 버전, 운영체제와 아키텍처, CI 환경인지 여부 같은 것들이에요. 중요한 건 명령어의 인자나 레포지토리 이름, 파일 내용 같은 실제 사용자 데이터는 수집하지 않는다고 명시돼 있다는 점이에요. 즉 gh pr create --title "비밀 프로젝트"라고 했을 때 '비밀 프로젝트'라는 문자열은 안 가져간다는 거죠.

'의사익명'이라는 표현이 쓰인 이유도 있어요. 완전한 익명은 아니고, 설치 단위로 생성된 임의의 ID가 붙어서 같은 사용자의 여러 명령을 연결할 수 있거든요. 그래야 "이 사용자가 pr create를 실패한 다음에 뭘 시도했는지" 같은 UX 분석이 가능하니까요. 다만 GitHub 계정 ID나 이메일과는 직접 연결되지 않는다고 해요.

전송 주기는 명령 실행 시점에 비동기로 보내는 방식이고, 네트워크 실패 시에는 버퍼링하거나 버린다고 하네요.

끄는 방법 — 이걸 꼭 알아두세요

개발자 입장에서 제일 궁금한 건 '어떻게 끄냐'일 거예요. 공식적으로 제공되는 옵트아웃 방법은 두 가지예요.

환경 변수로 끌 수 있어요. 셸 설정 파일(~/.zshrc, ~/.bashrc 등)에 export GH_DISABLE_TELEMETRY=1을 추가하면 돼요. 또는 gh 설정 명령으로 gh config set telemetry disabled를 실행해도 되고요. 둘 중 어느 쪽이든 가능하지만, 팀 단위로 관리한다면 환경 변수 쪽이 dotfiles 공유나 CI 설정에 넣기 편해요.

CI 환경에서는 더 신경 써야 해요. GitHub Actions나 다른 CI에서 gh 명령을 쓰는 경우가 많은데, 이때 수많은 실행 이벤트가 텔레메트리로 잡힐 수 있거든요. 팀 차원에서 수집을 원치 않으면 워크플로우의 env 블록에 GH_DISABLE_TELEMETRY: 1을 박아두는 게 안전해요.

왜 이런 걸 도입하는가 — 공급자의 논리

이 결정 자체를 비난하기 전에, 공급자 입장도 한번 짚어볼 필요가 있어요. CLI 도구를 만드는 팀이 텔레메트리를 원하는 이유는 대부분 제품 의사결정 때문이에요. 어떤 명령어가 얼마나 쓰이는지, 어떤 플래그가 자주 실패하는지, 특정 OS에서만 에러가 나는지 같은 데이터가 없으면 개선 우선순위를 정하기가 어렵거든요. 이슈 트래커에 올라오는 버그는 빙산의 일각이고, 실제로는 대다수 사용자가 조용히 포기하고 떠나기 때문이에요.

그래서 많은 도구가 '익명 분석'이라는 이름으로 비슷한 걸 도입하고 있어요. npm, Homebrew, Next.js, Angular, .NET CLI, PowerShell 등등 거의 다 켜놨죠. 문제는 기본값이 켜져 있느냐(opt-out), 꺼져 있느냐(opt-in) 이거예요. Homebrew는 기본 켜짐에서 사용자 반발이 컸고, Next.js도 꾸준히 논란의 대상이에요. 반대로 일부 도구는 opt-in 방식을 택해 신뢰를 얻고 있고요.

GitHub CLI의 선택은 기본 켜짐 + 명확한 옵트아웃이에요. 수집 항목과 끄는 방법을 공개 문서로 투명하게 공개했다는 점은 긍정적이지만, 많은 개발자가 "왜 기본값이 수집이냐"에 불만을 갖는 건 충분히 이해할 만해요.

한국 개발자가 체크해야 할 포인트

첫째, 회사 보안 정책과의 충돌을 먼저 확인하세요. 금융권이나 공공, 일부 대기업은 사내 도구가 외부로 텔레메트리를 보내는 걸 원천 금지하는 경우가 많아요. 이런 환경에서는 사내 표준 개발 환경 이미지에 GH_DISABLE_TELEMETRY=1을 기본으로 박아두는 게 안전해요. 지금도 늦지 않았으니 팀 공용 dotfiles나 온보딩 스크립트를 한번 점검해보세요.

둘째, CI 파이프라인 전수 점검을 권해요. gh 명령을 쓰는 워크플로우가 꽤 많을 텐데, 전부 다 꺼야 할 필요는 없더라도 최소한 어디서 쓰이는지는 파악해두는 게 좋아요.

셋째, 개인 개발자라면 각자의 판단이에요. 개인적으로는 도구를 만드는 팀이 방향을 잘 잡도록 데이터를 제공하는 것도 일종의 기여라고 보는 시각도 있어요. 오픈소스 생태계에서 피드백 루프는 소중하니까요. 반대로 최소 침해 원칙을 지키고 싶다면 끄고 쓰면 되고요.

마무리

기본 켜짐 텔레메트리는 편의와 프라이버시 사이의 오래된 줄다리기인데요, 이번 GitHub CLI 결정이 그 긴장을 다시 한번 전면에 드러냈어요. 여러분은 개발 도구의 익명 텔레메트리, 기본으로 켜두는 게 합리적이라고 보세요? 아니면 무조건 opt-in이어야 한다고 생각하세요?