# Google Workspace CLI를 만든 개발자, 구글에서 해고됨 > Clean Markdown view of GeekNews topic #30790. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30790](https://news.hada.io/topic?id=30790) - GeekNews Markdown: [https://news.hada.io/topic/30790.md](https://news.hada.io/topic/30790.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-06-24T15:34:01+09:00 - Updated: 2026-06-24T15:34:01+09:00 - Original source: [twitter.com/JPoehnelt](https://twitter.com/JPoehnelt/status/2069482265953087602) - Points: 7 - Comments: 1 ## Topic Body - gws는 Google Drive, Gmail, Calendar 등 **모든 Workspace API**를 다루며 사람과 에이전트 양쪽을 위해 설계된 오픈소스 CLI - 공개 며칠 만에 **Hacker News 1위**에 오르고 수천 개의 GitHub 스타와 수천 명의 실사용자 확보 - 구글 내부 반응은 두갈래 였음: 여러 디렉터/리더들이 이 도구에서 배울 점을 문의했지만, **Google 로고와 브랜드 색상**이 GitHub 저장소에 들어갔다는 이유로 법무팀의 강도 높은 추궁을 받음 - 본인이 추정하는 해고 원인은 **Workspace 일부 리더·프로젝트가 느낀 disruption 공포**이며, 이는 특정 CLI가 아니라 **에이전트가 Workspace에 의미하는 바**에 대한 더 넓은 두려움이라고 생각함 - 해고 이틀 전 **Google Cloud Next에서 공식 Workspace CLI** 출시가 발표된 것은 아이러니함 - 자신의 이야기를 직접 설명하고 경험을 온전히 소유하기 위해 공개했으며, 이를 **치유 과정의 일부**라고 생각함 - 약 7년간의 Google 근무를 훌륭한 기회로 평가하고, 지지해 준 동료들과 매니저에게 감사 표명 - "20% 프로젝트였냐"는 질문에 아니라고 답하며, 자신은 **Workspace DevRel** 소속으로 API 위에 오픈소스 레이어·추상화를 정기적으로 제작한다고 추가 설명함 - 2026년 초에는 CLI에 대한 관심이 크지 않았음 ## Comments ### Comment 60253 - Author: neo - Created: 2026-06-24T15:34:02+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48649011) - Google에서 일했거나 일하는 듯한 사람들이 이 행동을 비판하는데, 이런 주제에 댓글을 달 때는 **재정적 이해관계**를 밝혀야 함 Chrome 산하 Google에서 일할 때는 개인이나 팀이 Google 관리 GitHub 조직에 오픈소스 프로젝트를 올리는 일이 흔했고, 2015~2021년 대부분 기간에는 오픈소스 오피스 승인 없이도 팀 단독으로 GitHub에 공개할 수 있었음 이런 오픈소스 공개는 Google 문화의 일부였다고 보고, 장기 근속 직원의 행동에 비해 **해고**는 너무 극단적인 결과로 보임 - 전직 Googler이고 Cloud에서 일하며 프로젝트를 오픈소스로 공개해 본 입장에서는, 다른 제품 영역에서는 전혀 그렇게 단순하지 않았고 특히 **Google 이름**을 쓰는 경우는 더 엄격했음 내 개인 계정의 작은 Discord 봇조차 IARC 위원회를 거쳐야 했다면, Google 이름을 쓰는 프로젝트는 IARC와 법무 승인, 정식 출시/개인정보 검토까지 필요했을 가능성이 큼 OP가 출시 당시 경쟁 제품이 내부에서 개발 중이었다고도 했으니 내부 혼란이 컸을 수 있고, 이런 건 검토 과정에서 잡혔을 것임 전체적으로는 일부러 진실을 다 말하지 않는 듯하고, **인지도 쫓기**처럼 보임 - Google에서 일한다면 외부 “작업”에 대한 정책은 매우 명확함: 자원봉사, 오픈소스 사이드 프로젝트, 사업, 이사회 활동 등 어떤 형태든 일상 업무나 Google 사업과 관련 있으면 **신고 양식**을 제출하고 법무 승인을 받아야 함 Google Workspace CLI는 명백히 Google과 관련 있는데, 왜 승인 없이 공개했는지 이해하기 어려움 사용자에게 관심 있는 유능한 엔지니어가 해고된 건 안타깝지만, 엔지니어 쪽의 판단이 좋지 않았던 것 같음 참고로 Google에서 일하지만 이 글은 개인 글이고 고용주와 무관함 - 여기서는 특히 Apple 주주들이 Apple이 악의적으로 보일 일을 했을 때, 예컨대 사용자 휴대폰을 느리게 만들거나 Siri 녹음을 엿본 일을 대수롭지 않게 넘기면서 **보유 주식**을 밝히는 걸 본 적이 없음 - 핵심은 회사 권한 없이 회사에 영향을 주는 일을 했다는 것임 그 행동은 제품이 Google 승인 제품처럼 보이게 했고, Google은 평판을 지키는 데 수십억 달러를 써 왔는데 임의의 직원이 회사도 모르는 자체 제품을 내놓은 셈임 Google은 민사상 거액 소송이나 형사상 사기까지 걸 여지가 있었고, 실제 회수는 어렵더라도 당사자에게는 지옥이 됐을 것임 결국 **해고만 당한 것**도 운이 좋은 편으로 보임 - 보통 Google 소속이 아닌 저장소를 **Google 브랜드** 아래 공개하는 게 허용되는지 궁금함 이상하게 느껴지고, 왜 자기 이름으로 하지 않았는지 이해가 안 됨 1년 전까지 Google에서 일하다 퇴사하고 주식도 팔았지만, 오픈소스와 관련 있는 팀은 아니어서 내부 절차는 잘 모름 - 고용주의 공식 출시물로 혼동될 수 있는 것을 개인적으로 공개한 판단 부족은 앞으로도 큰 **예측 불가능한 위험**으로 보임 절차를 따르지 않았다면 상당한 징계가 예상되고, 어느 시점에든 직접 경고를 받았다면 해고도 가능해 보임 - 진짜 문제는 OP가 예전식 **파괴적 혁신가**로, 한때 흥미롭고 파괴적이었던 고용주에서 일하고 싶어 했다는 데 있음 OP는 커뮤니티가 꽤 잘 받아들인 괜찮은 제품을 만들었지만, 지금 Google이 어떻게 돌아가는지와 맞지 않아 잘린 것임 Google에서는 보상 없는 위험을 감수하지 않고, 흥미로워 보이는 움직임조차 조심해야 함 회계에 집착하는 사람들에게 대차대조표와 손익계산서가 흥미로운 것 말고는, Google은 더 이상 재미있는 회사가 아닌 듯함 안타깝게도 바이럴이 항상 좋은 건 아니며, 나쁜 바이러스를 겪어본 사람이라면 알 것임 - Google에서 직원이 오픈소스 프로젝트를 공개하고 소유권을 표시하는 절차는 매우 명확하고 잘 정립돼 있어서, 이 일이 저자에게 혼란스럽거나 갑작스럽게 벌어졌다는 게 상상하기 어렵다 그런 절차와 정책의 타당성을 따지는 건 완전히 가능하지만, **문제가 될 줄 몰랐다**는 서사에는 회의적임 - 나도 그런 인상을 받았고, 상사에게 먼저 확인했어야 했다고 봄 지금처럼 책임을 돌리기보다 여기서 뭔가 배웠으면 함 - 대량의 사소하거나 악의적인 소송과 브랜드 공격을 상대해야 하는 회사라면 특히 더 민감할 수밖에 없음 비슷한 상황에서 법무와 함께 말도 안 되는 제품 관련 공격을 방어해 본 적이 있고, 입사할 때 이런 일을 하지 않겠다는 문서에도 서명함 다만 이걸 공개적으로 떠드는 목적은 잘 모르겠음 - 이게 “개인적으로” 공개한 것이고, 절차가 지켜지지 않았다고 가정하고 있음 - 여기서 해고된 사람에게 동정적인 분위기가 흥미로움 고용주 이름으로 된 프로젝트를, 실제로는 고용주와 연관도 없고 승인도 받지 않은 채 공개했다면 해고를 예상하는 게 자연스럽지 않나 싶음 Google 직원이라는 점은 오히려 더 나쁘고, 이름을 찾아보면 실제 Google 직원임이 드러나니 공식처럼 보이기 쉬움 이게 나쁜 생각이라는 건 꽤 명백해 보임 - 그는 개발자 관계(DevRel)에서 일했고, 이런 오픈소스 도구를 만드는 게 흔한 일이었다고 말했음: [https://x.com/JPoehnelt/status/2069535183158812698]() 법적 상황은 모르지만, 책임을 피하려고 그렇게 했을 수도 있음 그래도 엔지니어들이 처음부터 다시 만들게 하거나 Google 소속으로 덜 보이는 곳으로 옮기는 쪽보다, 해고는 잘못된 결과처럼 느껴짐 승인되지 않은 프로젝트에 고용주 브랜딩을 쓰면 안 되므로 Google의 권리는 분명하지만, 고용주의 사명과 제품을 홍보하려던 사람에게는 **지나치게 보수적**인 대응으로 보임 - 별로 그렇지 않음 엄한 질책 정도는 예상하겠지만, **해고**는 과하다고 봄 Google이 아직 매력적인 직장인지 모르겠지만, 이번 일은 확실히 그쪽으로 저울을 기울이게 만들지는 않음 - 그는 코딩은 잘하지만 판단력이 부족해 보임 다만 본인이 잘못을 인정한다면 해고보다 더 잘 관리하는 편이 현명했을 것 같음 clueless하지만 뛰어난 코더에게는 조금 관대한 편임 - 이 프로젝트가 승인되지 않았다는 정보는 어디서 나온 건지 궁금함 꽤 큰 가정처럼 보이고, 링크된 트윗이나 답글, 연결된 페이지들에서는 그걸 뒷받침하는 내용을 못 봤음 - Google에서 7년 일한 사람이 이 결과에 놀랐다는 건 믿기 어렵다 Google은 직원의 오픈소스 기여 절차가 매우 명확하고, 그 정도 기간 동안 go/opensource 같은 내부 문서를 한 번도 안 봤을 가능성은 낮아 보임 이 정책이나 집행을 옹호하는 건 아니지만, 무엇을 할 수 있고 없는지와 “올바른” 절차가 잘 문서화돼 있음 많은 사람이 그 규칙에 답답함을 느끼는 건 이해되지만, 그냥 무시하고 밀어붙였을 때의 결과도 꽤 예측 가능함 - **Pournelle의 관료제 철칙**의 교과서적인 예처럼 보임 Justin Poehnelt처럼 스스로 동기부여를 받아 멋진 것을 만들고 사람들이 흥미로워하며 쓰고 싶어 하는 사람은, 이제 Google 내부 관료제와 그 안에서 자기 역할과 중요성을 더 중시하는 사람들에게 좌우됨 그들에게 OP의 프로젝트가 GitHub에서 즉시 인기를 얻었다는 사실은 아무 의미가 없었을 것임 다만 Justin이 승인 없이 Google 브랜딩으로 코드를 공개한 게 사실이라면 잘못이고, 해고도 정당화될 수 있음: [https://news.ycombinator.com/item?id=48650310]() 및 [https://news.ycombinator.com/item?id=48650192]() 참고: [https://jerrypournelle.com/reports/jerryp/iron.html]() - 전직 Googler들이 예전에는 직원이 Google 브랜딩으로 GitHub에 코드를 올리도록 허용하는 일이 오래도록 흔했다고 하니, 그렇다면 해고는 정당화되기 어렵다고 봄: [https://news.ycombinator.com/item?id=48652851]() 사실이 바뀌면 생각을 바꾸는 데 거리낌 없음 - Google은 **4조 달러 이상** 가치가 있는 회사이고, 그걸 지키기 위한 자연스럽고 필요한 관료제가 있음 선의였을 수는 있지만 이런 카우보이식 행동은 Google이 감수할 가치가 없는 위험임 - 오히려 0보다 더 낮은, 부정적 의미를 가질 수 있음 시스템 밖에서 일해도 인기를 얻고 사용자를 빼앗을 수 있다는 걸 보여주기 때문에, 조직의 우위를 위협함 - 수정 내용은 말이 안 된다고 봄 Google은 상표를 제거하라고 요구해서 모든 걸 정리할 수 있었지만 그렇게 하지 않았음 사람들이 좋아한 유용한 것을 만든 사람을 본보기로 삼았고, 이제 Google의 다른 엔지니어들은 사전 승인되지 않은 가치를 사업에 더하기 전에 두 번 생각하게 될 것임 수정 전 판단이 맞았음 - Google에서 일한 적은 없지만 이런 상황을 꽤 많이 겪어 본 입장에서는, 해고까지 갔다면 **더 많은 배경**이 있을 것이라고 봄 보통 유능한 직원이 이런 일을 하면 “주도성은 고맙고 계속 장려하고 싶지만, 이건 내려야 하고 다시는 이런 일이 없게 하라”는 식으로 끝남 대개 경력 종료급 사건이 아니고, 오히려 “카우보이”로 찍혀도 그런 사람을 밀어주는 임원이 있어서 승진으로 이어질 수도 있음 그래서 Google이 이 일을 매우 잘못 처리했거나 조직이 망가졌거나, 아니면 OP가 회사 최선의 이익에 반해 행동했고 특정 지시를 의도적으로 따르지 않았을 가능성이 있음 - “나를 해고시킨 트윗”의 내용은 다음과 같음 > Introducing the Google Workspace CLI: [https://github.com/googleworkspac]() e/cli - built for humans and agents. > Google Drive, Gmail, Calendar, and every Workspace API. 40+ agent skills included. 이건 완전히 Google의 **공식 제품 발표**처럼 보이고, 실제로도 그렇게 착각할 만함 당연히 문제가 될 걸 알았어야 함 - Justin이 이걸 올린 걸 봤고, 자세히 말하기 어렵겠지만 정말 말도 안 되는 이야기임 Google은 20% 시간을 장려하며 이런 멋진 프로젝트를 만들게 하던 곳에서, 이제 그런 일을 했다고 사람을 해고하는 곳이 됐음 Google 안에서 악의적인 무언가가 돌아가는 듯함 이런 일도 있고, 오픈소스 Gemini CLI가 더 형편없는 비공개 Antigravity CLI로 대체되는 일도 있음 대체 무슨 일이 벌어지는 건지 모르겠음 - 해고된 큰 이유는 업무와 관련된 제품을 만들었고, 아마 **20% 시간**을 써서 근무 중 만들었으며, Google 브랜딩과 로고를 붙여 회사 승인 없이 공개했기 때문으로 들림 이름도 회사와 연결된 상태였으니, 갑자기 Google 직원이 Google 브랜딩으로 공개한 바이럴 Google Workspace 도구가 등장했고 모두가 뒤통수를 맞은 셈임 반드시 해고돼야 했다는 건 아니지만, 이런 방식은 극도로 판단이 좋지 않았고 매니저와 주변 모두를 매우 난처하게 만들었음 - 20% 프로젝트가 언제부터 모든 **출시 절차**를 우회하고 제품을 그냥 공개하는 의미였는지 모르겠음 Google이 지금은 큰 관료제일 수 있지만, 출시 승인과 절차에는 이유가 있음 - 회사가 아이디어가 바닥나고 대부분 MBA 출신들이 운영하게 되면 이런 일이 생김 좋은 아이디어도 이제 누군가의 영지를 침범할 수 있어서 위험해짐 - 20% 시간 프로젝트를 그냥 공개적으로 출시하면 안 된다는 정책일 수도 있음 - 정당성, 스트라이샌드 효과, 홍보 피해나 반대로 득이 되는지는 제쳐두고, 이 일이 **다음 Gmail**을 만들고 싶은 젊은 Google 엔지니어에게 어떤 신호를 보내는지 봐야 함 내부 정책을 전부 위반했다 해도 사람들이 실제로 원하는 것을 만든 사람을 해고하는 건 내부와 외부 모두에 매우 불길한 메시지임 이게 Addy Osmani의 최근 Google 퇴사와도 관련 있는지 궁금함 동조 차원의 퇴사였는지, 아니면 이 일이 “OP를 해고시킨 트윗”이었기 때문에 보복이었는지도 의문임 - 이미 공유한 것보다 더 많이 말하진 않겠지만, 이 일은 대형 기술 기업에서 일하는 경험과 **AI가 만드는 혼란**을 보여준다고 봄 팀, 로드맵, 인센티브 차원에서도 그렇고 사용자 행동 변화 차원에서도 그렇다 - 명확하게 문서화된 **오픈소스 출시 절차** 지침을 따랐는지 밝혀주면 도움이 될 것 같음 “무언가를 만들었다고 해고”와 “규칙을 따르지 않아 해고”는 다름 - 안타깝다 그 도구는 개인적으로 G Workspace를 훨씬 더 유용하게 만들어 줬고, 어떤 캘린더 프로젝트를 쓸지 결정하는 요소이기도 했음 고객에게 제품을 더 유용하게 만든 일로 해고되는 건 꽤 아이러니함 내가 만든 Claude skill과 함께 쓰면 중요한 회의용 Logseq 회의록 페이지를 만드는 시간이 크게 줄어듦 G보다 훨씬 더 가치를 알아주는 곳에 잘 안착하길 바람 - FAANG에서 일해 본 적이 없어서 궁금한데, Google은 제품 출시 전에 엄격한 절차와 승인이 있는지, 그리고 이 프로젝트가 그 절차를 거쳤는지 알고 싶음 - 자세히 따라보진 못했으니 이미 말한 걸 반복하게 하는 질문일 수 있지만, 갑자기 해고된 건지 아니면 회사와 대화가 있었고 그게 잘 풀리지 않았던 건지 궁금함 - 5년 전 필요 때문에 비공개 제품 API를 역공학해서 복잡한 로그인까지 처리하는 **CLI**를 만들었고, 공개되지 않은 관리 기능을 다룰 수 있게 했음 전 세계 약 100명에게 매우 유용했지만 그 정도가 전부였고, 공개 출시에는 전혀 추진력을 얻지 못했음 그러다 내 조직과 멀리 떨어진 Distinguished Engineer가 바로 그 도구를 필요로 하게 되자, 갑자기 회사 리더십에게 혁신상을 받고 법무가 오픈소스 공개를 빠르게 처리해 줬음 이런 걸 **법무 검토 없이 공개 저장소**에 밀어 넣는 건 자살행위임