Google Workspace CLI를 만든 개발자가 구글에서 해고된 사연
2026년 6월 현재, 오픈소스 개발자 한 명이 회사 이름으로 공개한 CLI 도구 하나 때문에 7년 경력을 정리하는 일이 벌어졌다. 주인공은 Google Workspace DevRel 소속 Justin Poehnelt. 그가 만든 gws라는 도구는 공개 며칠 만에 Hacker News 1위에 올랐고, GitHub 스타 수천 개와 실사용자 수천 명을 확보했지만, 동시에 법무팀의 강도 높은 추궁을 받아 결국 퇴사 길에 올라탔다.

흥미로운 건 시점이다. 그가 해고된 이틀 전, Google Cloud Next에서 정식 Workspace CLI가 발표됐다. 본인 추측에 따르면 해고 원인은 특정 CLI가 아니라, 에이전트가 Workspace에 어떤 의미인지에 대한 더 넓은 두려움이었다고 한다. 이 글에서는 사건의 배경과 커뮤니티 반응, 양측 주장을 정리한다.
- --
사건의 발단 — `gws`는 어떤 도구인가
공개 1주일 만에 일어난 일
gws는 Google Drive, Gmail, Calendar 등 Workspace API를 다루는 오픈소스 CLI다. 핵심 차별점은 사람과 에이전트 양쪽을 위해 설계됐다는 점이다. README에 따르면 gws 저장소에는 40개 이상의 에이전트 스킬이 포함돼 있어, LLM 에이전트가 자연어로 Workspace를 조작할 수 있다. Agent Skills를 대량 내장한 점이 기존 CLI 도구들과의 결정적 차이다.
공개 직후 Hacker News 1위, GitHub 스타 수천 개, 실사용자 수천 명이 모였다. 사람들은 "드디어 Workspace에 정식 CLI가 나왔구나"라며 환영했다. 문제는 그 다음 단계였다.
두 갈래로 갈린 구글 내부 반응
긱뉴스가 정리한 내부 분위기는 두 갈래였다. 여러 디렉터와 리더들이 이 도구에서 배울 점을 문의하는가 하면, 동시에 Google 로고와 브랜드 색상이 GitHub 저장소에 들어가 있다는 이유로 법무팀이 강도 높은 추궁을 했다. 같은 도구를 두고 일부는 영감을 받고 일부는 위협을 느낀 것이다.
본인은 자신의 트위터에서 Introducing the Google Workspace CLI: built for humans and agents. Google Drive, Gmail, Calendar, and every Workspace API. 40+ agent skills included.라는 문구로 도구를 소개했다. 이 문구는 Google의 공식 제품 발표처럼 보일 수 있고, 실제로도 그렇게 착각하기 쉽다.
- --
본인이 추정한 해고 원인
disruption 공포가 진짜 이유일까
Justin Poehnelt는 해고 원인을 Workspace 일부 리더와 프로젝트가 느낀 disruption 공포라고 추정했다. 이는 특정 CLI가 아니라, 에이전트가 Workspace에 의미하는 바에 대한 더 넓은 두려움이라는 게 그의 분석이다. 에이전트 자동화가 Workspace API 위에서 직접 돌아가기 시작하면, 기존 Workspace 제품의 가치 제안이 흔들릴 수 있다는 우려다.
흥미로운 건 그가 "20% 프로젝트였냐"는 질문에 아니라고 답했다는 점이다. 본인은 Workspace DevRel 소속으로, API 위에 오픈소스 레이어와 추상화를 정기적으로 만든다고 덧붙였다. 즉 업무 범위 안에서 만든 도구라는 설명이다. 2026년 초에는 CLI에 대한 관심이 크지 않았고, 그가 만든 도구가 갑자기 바이럴하면서 문제가 커졌다는 게 그의 서사다.
Google Cloud Next의 아이러니
해고 이틀 전 Google Cloud Next에서 공식 Workspace CLI가 발표된 건 명백한 아이러니다. 같은 시기에 회사가 같은 카테고리의 정식 제품을 발표했는데, 본인은 회사 승인 없이 Google 브랜딩으로 비공식 CLI를 공개한 상태였다. 본인은 이 사건을 자신의 이야기를 직접 설명하고 경험을 온전히 소유하기 위한 공개로 규정하며, 치유 과정의 일부라고 표현했다.
- --
Hacker News 댓글 — 양측의 주장이 팽팽하다
비평가 측 — 정책 위반은 명확했다
전직 Googler이자 Cloud에서 일한 경험이 있는 댓글 작성자는 "다른 제품 영역에서는 전혀 단순하지 않았고, 특히 Google 이름을 쓰는 경우는 더 엄격했다"고 지적했다. 내 개인 계정의 작은 Discord 봇조차 IARC 위원회를 거쳐야 했다면서, Google 이름을 쓰는 프로젝트는 IARC와 법무 승인, 정식 출시/개인정보 검토까지 필요했을 가능성이 크다고 봤다.
그가 제시한 핵심 쟁점은 "왜 승인 없이 공개했는지 이해하기 어렵다"는 점이다. Google에서 7년 일한 사람이 이 결과에 놀랐다는 건 믿기 어렵고, 직원 오픈소스 기여 절차는 매우 명확하다는 게 비평가들의 일치된 시각이다. go/opensource 같은 내부 문서를 한 번도 안 봤을 가능성이 낮다는 것이다.
| 정책 단계 | 필요한 절차 | 비평가 평가 |
|----------|------------|------------|
| 자원봉사·사이드 프로젝트 | 신고 양식 제출 | 일상 업무/사업과 관련 시 필수 |
| 오픈소스 공개 | 법무 승인 | Google 이름 사용 시 엄격 적용 |
| 정식 출시 | 개인정보 검토 | IARC 위원회 거쳐야 |
| 브랜드 사용 | 법무팀 사전 승인 | Google 로고·색상 사용 시 |
옹호 측 — 해고는 너무 극단적이었다

반대 시각도 분명히 존재한다. 2015~2021년 대부분 기간에는 오픈소스 오피스 승인 없이도 팀 단독으로 GitHub에 공개할 수 있었다는 게 옹호 측의 주장이다. Chrome 산하 Google에서 일할 때는 개인이나 팀이 Google 관리 GitHub 조직에 오픈소스 프로젝트를 올리는 일이 흔했고, 이런 오픈소스 공개는 Google 문화의 일부였다.
7년 장기 근속 직원의 행동에 비해 해고는 너무 극단적인 결과라는 시각이다. 코딩을 잘하지만 판단력이 부족해 보인다는 점은 인정하면서도, 본인이 잘못을 인정한다면 해고보다 더 잘 관리하는 편이 현명했을 거라는 의견이 있었다. 좋은 아이디어도 이제 누군가의 영지를 침범할 수 있어서 위험해지는 Google의 현재 분위기를 안타깝게 보는 시각도 함께 제기됐다.
- --
양측 시각 비교 — 핵심 쟁점은 어디인가
| 쟁점 | 비평가 측 (전직 Googler 다수) | 옹호 측 (개발자 커뮤니티 다수) |
|------|------------------------------|--------------------------------|
| 승인 절차 | IARC·법무 승인 없이 Google 이름 사용은 위반 | 2015~2021년엔 팀 단위 공개가 흔했음 |
| 행동의 심각성 | 브랜드 훼손, 내부 혼란, 민사·형사 소송 위험 가능 | 내부 경고 후 단계적 징계가 적절 |
| 재산권 침해 | 회사가 모르게 자체 제품 출시 = 재산권 문제 | 코드 자체는 공개 API 기반, 신규 창작물 |
| 결과의 적절성 | 정책 위반은 명확하므로 해고 정당화 가능 | 7년 근속 직원에게 과도한 반응 |
| 문화적 신호 | 절차 무시하면 결과 따른다는 경고 필요 | 다음 Gmail을 만들고 싶은 젊은 엔지니어에게 나쁜 신호 |
핵심은 "무언가를 만들었다고 해고"와 "규칙을 따르지 않아 해고"는 다르다는 점이다. 긱뉴스가 정리한 쟁점 중 가장 많이 반복되는 게 이 구분이다. 커뮤니티가 공감하는 건 후자보다는 전자의 사례가 명확하지 않다는 데 있다.
- --
이 사건이 보여주는 더 큰 그림
AI 에이전트 시대의 회사-직원 경계
이 사건은 단순한 해고 사례가 아니다. 대형 기술 기업에서 일하는 경험과 AI가 만드는 혼란을 동시에 보여준다. 팀, 로드맵, 인센티브 차원에서 그렇고 사용자 행동 변화 차원에서 그렇다. 에이전트가 Workspace 같은 기업용 SaaS를 직접 자동화하기 시작하면, 회사 입장에서는 통제권을 잃을 수 있다.
일부 댓글에서는 이 사건이 Addy Osmani의 최근 Google 퇴사와도 관련 있는지 궁금하다는 반응도 나왔다. 동조 차원의 퇴사였는지, 아니면 보복이었는지는 알 수 없지만, Google 안에서 악의적인 무언가가 돌아가는 듯하다는 시각이 존재한다. 오픈소스 Gemini CLI가 형편없는 비공개 Antigravity CLI로 대체되는 일과 같은 맥락에서 보는 시각이다.
오픈소스 공개의 새로운 기준점
이 사건은 20% 프로젝트가 언제부터 모든 출시 절차를 우회하고 제품을 그냥 공개하는 의미였는지 묻는다. 정당성, 스트라이샌드 효과, 홍보 피해나 반대로 득이 되는지는 제쳐두고, 이 일이 다음 Gmail을 만들고 싶은 젊은 Google 엔지니어에게 어떤 신호를 보내는지 봐야 한다. 내부 정책을 전부 위반했다 해도 사람들이 실제로 원하는 것을 만든 사람을 해고하는 건 내부와 외부 모두에 매우 불길한 메시지라는 평가가 일각에서 나왔다.
비평가 중 한 명은 과거에 비슷한 일을 겪고 법무 검토 없이 공개 저장소에 밀어 넣는 건 자살행위라고 단언했다. 비공개 제품 API를 역공학해서 CLI를 만든 후, 법무가 오픈소스 공개를 빠르게 처리해 준 선례가 있었기 때문에 그 절차의 중요성을 강조한 것이다.
- --
결론 — 2026년 6월 기준으로 남는 교훈
2026년 6월 기준으로 이 사건은 에이전트 시대의 오픈소스와 회사 브랜드 사이 경계를 다시 묻는 사례다. 본인은 7년간의 Google 근무를 훌륭한 기회로 평가하고, 지지해 준 동료들과 매니저에게 감사 표명을 했다. 자신의 이야기를 직접 설명하고 경험을 온전히 소유하기 위해 공개한 것이며, 이를 치유 과정의 일부로 본다는 입장이다.
커뮤니티는 양쪽으로 갈렸다. 정책 위반이라는 비판이 있는가 하면, 7년 근속 직원에 대한 해고라는 과도한 조치라는 시각도 있다. 다만 결정적으로 기억해야 할 건, 구글은 4조 달러 이상 가치가 있는 회사이고, 그걸 지키기 위한 자연스럽고 필요한 관료제가 있다는 점이다. 선의였을 수는 있지만 이런 카우보이식 행동은 Google이 감수할 가치가 없는 위험일 수 있다. 그리고 무엇보다 중요한 건, 회사 이름으로 된 프로젝트를, 실제로는 고용주와 연관도 없고 승인도 받지 않은 채 공개했다면 해고를 예상하는 게 자연스럽다는 현실이다.
이 도구는 개인적으로 G Workspace를 훨씬 더 유용하게 만들어 줬고, 어떤 캘린더 프로젝트를 쓸지 결정하는 요소이기도 했다. 고객에게 제품을 더 유용하게 만든 일로 퇴사 길에 올라탄 건 명백한 아이러니다. 그가 Claude skill과 함께 쓰는 도구들을 잘 활용할 수 있는 곳에 잘 안착하길 바라는 시각이 커뮤니티에 남아 있다.
'자동화&툴 리뷰' 카테고리의 다른 글
| Flock 카메라, 번호판을 넘어 사람까지 추적하며 빠르게 확산 중 — 개발자가 알아야 할 기술 구조 (0) | 2026.06.30 |
|---|---|
| EU, 비공개로 Chat Control 입법 추진 — 개발자가 주목해야 할 양대 쟁점 (0) | 2026.06.30 |
| 취약점 보고서는 더 이상 특별하지 않다 — 2026년 LLM 시대 보안 분류학 (0) | 2026.06.25 |
| F3 - 미래를 위한 오픈소스 데이터 파일 형식, Parquet 이후의 차세대 컬럼 포맷 (0) | 2026.06.25 |
| AI로 구글이 만든 1,500개 API를 자동 해킹해 3개월 만에 7억원 번다 (0) | 2026.06.24 |