개발자 도구와 데이터 수집에 대한 불편한 진실
사용하는 거의 모든 개발자 도구의 개인정보 보호정책을 열어보면 데이터 수집에 관한 섹션을 발견하게 됩니다. 사용 분석, 충돌 보고서, 기능 추적, 세션 지속 시간, 하드웨어 프로필 -- 목록은 계속됩니다. 대부분의 회사는 이를 필수 사항으로 설명합니다: 제품을 개선하고, 기능의 우선순위를 정하고, 버그를 수정하려면 데이터가 필요하다고 합니다. 그리고 공정하게 말하면, 그 논리가 완전히 틀린 것은 아닙니다. 데이터 기반 제품 결정은 더 나은 소프트웨어를 구축하기 위한 합법적인 접근 방식입니다.
하지만 거의 제기되지 않는 질문이 있습니다: 그 대가는 무엇입니까?
대부분의 개발자 도구가 분석 데이터를 수집하는 이유
개발자 도구에서 telemetry에 대한 표준적인 정당화는 몇 가지 범주로 나뉩니다:
- 제품 결정. 어떤 기능이 가장 많이 사용되는가? 어떤 기능이 무시되는가? 분석 데이터는 제품 팀이 다음에 무엇을 만들고 무엇을 폐지할지 우선순위를 정하는 데 도움을 줍니다.
- 충돌 보고서. 무언가가 고장났을 때, 자동 충돌 보고는 개발자가 문제를 더 빠르게 식별하고 수정할 수 있도록 도와줍니다. 때로는 사용자가 보고하기도 전에 말입니다.
- 성능 모니터링. 특정 작업이 다른 하드웨어에서 얼마나 걸리는가? 병목 현상은 어디에 있는가? telemetry는 합성 벤치마크로는 복제할 수 없는 실제 성능 데이터를 제공합니다.
- 비즈니스 지표. 유지율, 활성화 퍼널, 이탈 예측 -- 이러한 지표는 비즈니스 결정을 주도하며, 특히 성장을 보여야 하는 압박을 받는 벤처 캐피탈 지원 기업에서 그렇습니다.
이 중 어느 것도 본질적으로 악의적인 것은 아닙니다. 하지만 누적 효과로 인해 개발 환경이 행동 데이터의 소스가 됩니다. 모든 commit, 모든 브랜치 전환, 모든 merge 충돌, 열어보는 모든 파일 -- 이 모든 것이 잠재적으로 관찰 가능합니다. 워크플로의 중심에 있는 도구에 있어서, 이는 어떻게 일하고, 무엇을 작업하며, 언제 작업하는지에 대한 상당한 양의 정보입니다.
GitSquid가 다른 길을 선택한 이유
GitSquid를 만들기 시작했을 때, 우리는 의도적인 결정을 내렸습니다: zero telemetry. "최소한의 telemetry"가 아닙니다. "익명화된 telemetry"가 아닙니다. 제로입니다. 이것은 나중에 생각해낸 것도 마케팅 전략도 아니었습니다. 근본적인 설계 원칙이었으며, 그 이유는 다음과 같습니다.
개인정보 보호는 기능이다
우리는 개인정보 보호가 단순히 규정 준수 체크박스가 아니라고 믿습니다. 사용자가 신뢰할 수 있어야 하는 기능입니다. GitSquid를 사용할 때, 애플리케이션은 전적으로 여러분의 머신에서 실행됩니다. 리포지토리 데이터, commit 이력, 브랜치 구조, 워크플로 패턴 -- 그 어느 것도 여러분의 컴퓨터를 떠나지 않습니다. 이것은 기억해서 전환해야 하는 설정이 아닌, 보장입니다.
개발자 도구는 모든 것을 본다
Git 클라이언트는 가벼운 도구가 아닙니다. 전체 코드베이스, commit 메시지(종종 프로젝트 이름, 티켓 번호, 작업 내용에 대한 컨텍스트가 포함됨), 브랜치 이름, 협업 패턴에 접근할 수 있습니다. 어떤 리포지토리에서 작업하는지, 얼마나 자주 commit하는지, 언제 활동하는지 알고 있습니다. Git 클라이언트에서 telemetry를 수집한다는 것은 전문적인, 때로는 개인적인 작업과 깊이 얽혀 있는 데이터를 수집한다는 의미입니다. 우리는 그 책임을 원하지 않았으며, 여러분이 그것을 허용해야 한다고 생각하지 않습니다.
신뢰는 단순해야 한다
많은 도구에서 신뢰하려면 개인정보 보호정책을 읽고, 옵트아웃 설정을 확인하고, "익명화된" 데이터가 정말로 익명인지 기대하고, 다음 인수나 투자 라운드에서 데이터 처리 관행이 변경되지 않을 것이라 신뢰해야 합니다. 우리는 신뢰가 단순하기를 원했습니다: GitSquid는 여러분의 데이터를 수집하지 않습니다. 그것으로 끝입니다. 분석할 개인정보 보호정책도, 감사할 설정도, 검토할 데이터 처리 계약도 없습니다.
"Zero telemetry"가 구체적으로 의미하는 것
우리가 의미하는 바를 정확히 설명하면, GitSquid가 하는 것과 하지 않는 것은 다음과 같습니다:
수집하지 않는 것:
- 어떤 종류의 사용 분석도
- 충돌 보고서 또는 오류 로그
- 기능 사용 추적
- 세션 데이터 또는 활동 패턴
- 하드웨어 또는 OS 프로파일링
- 리포지토리 메타데이터 또는 콘텐츠
GitSquid가 수행하는 유일한 네트워크 요청:
- 라이선스 검증. 라이선스를 활성화할 때, GitSquid는 라이선스 서버에서 유효성을 확인합니다. 이것은 간단한 활성화 확인이며 사용 보고가 아닙니다.
- 업데이트 확인. GitSquid는 주기적으로 최신 버전이 있는지 확인하여 최신 상태를 유지할 수 있도록 합니다. 이 확인 중에 사용에 관한 데이터는 전송되지 않습니다.
이것이 전체 목록입니다. 분석 엔드포인트도, 백그라운드 데이터 업로드도, "익명" 사용 보고서도 없습니다. GitSquid를 사용하는 동안 네트워크 트래픽을 모니터링하면 정확히 이 두 가지 유형의 요청만 보이고 그 외에는 아무것도 없습니다.
우리가 수용하는 트레이드오프
단점이 없는 척하지 않겠습니다. telemetry 없이는 어떤 기능이 인기 있는지, 사용자가 어디에서 어려움을 겪는지, 특정 하드웨어 구성에서 무엇이 충돌을 유발하는지에 대한 자동적인 인사이트가 없습니다. 대신 사용자의 직접적인 피드백, 지원 대화, 그리고 자체적인 광범위한 테스트에 의존합니다. 이것은 더 느립니다. 덜 체계적입니다. 자동 충돌 보고가 있었다면 알 수 있었을 문제를 늦게 알게 되는 경우도 있습니다.
이것은 수용할 수 있는 트레이드오프라고 생각합니다. 사용자는 개인정보를 완전히 존중하는 도구를 얻고, 우리는 데이터 추출이 아닌 진정한 사용자 관계 위에 구축된 제품을 얻습니다. 추적당하고 있다는 사실을 모르는 사용자로부터의 백만 개의 데이터 포인트보다 우리를 깊이 신뢰하는 백 명의 사용자를 갖는 것이 낫습니다.
업계의 변화
이런 생각을 하는 것은 우리만이 아닙니다. 소프트웨어 산업 전반에 걸쳐 "모든 것을 수집하고 나중에 의미를 파악하는" 접근 방식이 실질적인 비용 -- 규제적, 명성적, 윤리적 비용 -- 을 수반한다는 인식이 커지고 있습니다. 브라우저, 이메일, 메시징, 검색에서 개인정보 보호 중심의 대안이 부상하는 것은 사용자가 자신의 경계를 존중하는 도구를 점점 더 중시하고 있음을 보여줍니다.
특히 개발자 도구 분야에서 이 변화는 더욱 중요합니다. 개발자는 기술을 이해합니다. telemetry가 무엇을 의미하는지, 사용 패턴에서 어떤 데이터가 도출될 수 있는지, "익명화된" 데이터가 다른 소스와 결합될 때 무엇을 드러낼 수 있는지 알고 있습니다. 이 대상을 위한 도구를 개인정보를 존중하지 않으며 구축하는 것은 단순히 윤리적 문제가 아닙니다. 신뢰성의 문제입니다.
단순한 약속
telemetry에 대한 우리의 입장은 새로운 제품 버전, 리더십 변경, 또는 투자 라운드로 바뀌지 않을 것입니다. Zero telemetry는 GitSquid의 일부입니다. 여러분의 코드는 여러분의 머신에 머물러 있습니다. 여러분의 워크플로는 비공개로 유지됩니다. 여러분의 신뢰는 단순하게 유지됩니다.
이것은 우리가 타협할 의향이 없는 기능입니다.