회사 도구를 더 좋게 만든 죄? 구글이 사이드 프로젝트 만든 개발자를 해고한 사건

회사에서 쓰는 도구가 불편해서, 퇴근 후에 더 나은 버전을 직접 만들었습니다. 그리고 그걸 오픈소스로 공개했습니다. 칭찬받을 일 같죠. 그런데 해고됐습니다. 최근 개발자 커뮤니티에서 돌고 있는 이 이야기는 단순한 가십이 아닙니다. 우리 모두가 한 번쯤 마주치는 질문을 정면으로 건드리기 때문입니다. 내가 퇴근 후에 만든 코드는 과연 누구의 것일까요.

먼저 솔직하게 말씀드리겠습니다. 이 사건은 아직 대형 커뮤니티에서 충분히 검증된 단계는 아닙니다. 지난 30일간 관련 토론 데이터가 매우 제한적이었습니다. 그래서 오늘 글은 특정 회사를 단죄하는 데 초점을 두지 않겠습니다. 대신 이 사건이 던지는 본질적인 논쟁 자체를 파고들어 보겠습니다. 사실 이 주제는 어제오늘 일이 아니라 IT 업계의 해묵은 뇌관이거든요.

무슨 일이 있었나: ‘회사 도구를 개선한 죄’

사건의 구조는 단순합니다. 한 엔지니어가 구글 워크스페이스(Gmail, 드라이브, 캘린더 같은 업무 도구 묶음)를 명령어로 다룰 수 있는 CLI 도구를 만들었습니다.

CLI가 뭔지 잠깐 짚고 가겠습니다. Command Line Interface, 즉 마우스 클릭 대신 키보드로 명령어를 입력해 작업하는 방식입니다. 개발자들이 반복 작업을 자동화할 때 가장 선호하는 형태입니다. 메일 정리, 파일 이동 같은 걸 클릭 수십 번 대신 명령어 한 줄로 끝내는 거죠.

문제는 이 도구가 회사 업무와 너무 가까웠다는 점입니다. 회사 제품을 더 편하게 쓰기 위한 도구였고, 그걸 회사 밖 세상에 오픈소스로 공개했습니다. 회사 입장에서는 내부 자산과 외부 공개의 경계를 넘었다고 본 겁니다. 만든 사람 입장에서는 그저 불편함을 해결한 사이드 프로젝트였고요. 같은 행동을 두고 두 진영의 해석이 정반대입니다.

핵심 쟁점: 사이드 프로젝트는 누구의 것인가

여기서 진짜 논쟁이 시작됩니다. 많은 분이 모르고 계시는데, 대부분의 IT 기업 고용 계약서에는 지식재산권 양도 조항이 들어 있습니다.

쉽게 풀면 이렇습니다. 직원이 재직 중에 만든 발명이나 코드 가운데, 회사 사업과 관련이 있거나 회사 자원을 사용해 만든 것은 회사 소유가 된다는 내용입니다. 미국 캘리포니아 같은 곳은 노동법으로 직원을 어느 정도 보호해주지만, 그 보호의 핵심 단서가 바로 “회사 사업과 무관할 것"입니다.

이번 사건이 까다로운 이유가 여기 있습니다. 구글 워크스페이스용 도구는 누가 봐도 구글의 사업 영역 한가운데에 있습니다. 취미로 만든 게임이나 전혀 다른 분야의 앱이었다면 보호받았을 가능성이 높습니다. 하지만 회사 제품을 직접 다루는 도구는 그 경계가 흐릿합니다. “퇴근 후 내 시간에 만들었다"는 항변이 법적으로는 생각보다 약할 수 있다는 뜻입니다.

회사는 왜 이렇게 민감하게 반응할까

직원 입장에서는 과한 반응처럼 보입니다. 하지만 회사 관점에서 보면 나름의 논리가 있습니다.

첫째, 보안과 데이터 노출 문제입니다. 내부 API나 인증 방식을 다루는 도구가 외부에 공개되면, 의도와 무관하게 회사 시스템의 작동 방식이 드러날 수 있습니다. 공격자에게 힌트를 주는 셈이 되기도 합니다.

둘째, 지원과 책임의 문제입니다. 직원이 만든 비공식 도구를 외부 사용자들이 쓰기 시작하면, “구글 직원이 만든 도구"라는 후광이 생깁니다. 문제가 터지면 회사가 책임 논란에 휘말립니다. 공식 제품이 아닌데도 말입니다.

셋째, 선례입니다. 한 명을 묵인하면 수만 명의 엔지니어가 각자 내부 도구를 들고 나가도 막을 명분이 사라집니다. 회사가 강경하게 나오는 건 개인을 응징하기보다 전체에 보내는 신호인 경우가 많습니다.

이해는 됩니다. 다만 이해가 된다는 것과 그 방식이 옳다는 건 다른 문제겠죠.

개발자 커뮤니티가 진짜 분노하는 지점

이런 사건이 터질 때마다 개발자 커뮤니티가 들끓는 이유는 단순히 “동료가 잘렸다"는 동정심 때문만이 아닙니다. 더 깊은 곳에 신뢰의 붕괴가 있습니다.

많은 회사가 채용할 때 “오픈소스 기여를 장려한다”, “사이드 프로젝트를 환영한다"고 말합니다. 개발자들은 그 말을 믿고 입사합니다. 그런데 막상 무언가를 만들면 계약서의 깨알 같은 조항이 발목을 잡습니다. 말과 계약서가 다르다는 배신감, 이게 핵심입니다.

또 하나는 자기 자신에게 던지는 질문입니다. “그럼 내가 주말에 만든 저 프로젝트도 위험한 건가?” 이 사건은 모든 직장인 개발자를 잠재적 당사자로 만듭니다. 남의 일이 아니라 내 일이 될 수 있다는 불안이 분노를 키우는 겁니다.

우리가 챙겨야 할 실질적 교훈

법정 다툼의 승패를 떠나, 직장에 다니며 무언가를 만드는 사람이라면 챙겨둘 게 있습니다.

가장 중요한 건 회사 사업과의 거리입니다. 내가 만들려는 사이드 프로젝트가 회사 제품과 가까울수록 위험합니다. 멀수록 안전합니다. 회사 노트북, 회사 계정, 회사 시간을 단 하나라도 썼다면 회색지대로 들어선다고 봐야 합니다.

다음은 사전 동의입니다. 애매하다 싶으면 공개하기 전에 회사에 서면으로 확인받는 게 가장 확실합니다. 번거롭지만, 만든 다음에 통보하는 것과 만들기 전에 묻는 것은 결과가 완전히 다릅니다.

마지막으로 입사할 때 고용 계약서의 IP 조항을 한 번이라도 읽어보시기 바랍니다. 대부분 그냥 서명하지만, 바로 그 한 페이지가 몇 년 뒤 내 사이드 프로젝트의 운명을 결정합니다.

회사 도구를 더 좋게 만든 게 정말 해고당할 죄인지, 아니면 회사가 자기 자산을 지킨 정당한 결정인지는 보는 각도에 따라 다릅니다. 다만 분명한 건, 이 모호한 경계 위에 수많은 개발자가 매일 무언가를 만들며 서 있다는 사실입니다. 여러분이 지난 주말에 만든 그 프로젝트는, 과연 온전히 여러분의 것인가요?