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가 붙고, 그걸 기준으로 기계를 식별하는 구조처럼 보임