두 달 전, 저는 Google Workspace CLI를 만들었다는 이유로 Google에서 해고됐습니다. 이 도구는 며칠 만에 입소문을 타고 Hacker News 1위에 올랐고, GitHub 스타 수천 개와 실제 사용자 수만 명을 얻었습니다.

정말 놀랍고도 혼란스러운 여정이었습니다. 임원들과 리더들이 이 도구에서 무엇을 배울 수 있는지 묻던 일부터, Google Workspace GitHub 코드 저장소에 왜 Google 로고와 브랜드 색상을 썼는지 법무팀에게 집요하게 추궁받던 일까지 있었습니다.

저는 Workspace와 일부 리더들, 그리고 일부 프로젝트가 방해받거나 대체될까 봐 두려워했던 것이 원인이라고 생각합니다. 다만 그 두려움은 제 CLI 하나만을 향한 것이 아니라, 에이전트가 Workspace에 어떤 의미를 갖는지에 대한 더 넓은 두려움이었습니다. 어느 쪽이든, 제가 해고되기 이틀 전 Google Cloud Next에서 공식 Workspace CLI가 나올 예정이라고 발표했다는 점은 아이러니했습니다.

이 이야기를 공개하는 이유는 제 이야기를 설명하기가 더 쉬워지기 때문이고, 제가 온전히 제 것으로 받아들이고 싶은 경험이기 때문입니다. 제 회복 과정의 일부이기도 합니다.

Google에서 보낸 거의 7년은 제게 정말 큰 기회였습니다. 저는 훌륭한 동료들과, 지난 몇 달 동안 저를 전적으로 지지해 준 매니저를 만난 행운을 누렸습니다. 감사합니다.

^source^{https://twitter.com/JPoehnelt/status/2069482265953087602}

HN에서는 이 사건을 단순히 유용한 도구를 만들었다가 해고된 이야기로만 보지 않았다. 핵심 쟁점은 구글이 내부 실험을 과도하게 처벌했는지, 아니면 직원이 회사 이름과 브랜드를 달고 공식 제품처럼 보일 수 있는 CLI를 공개한 판단 착오가 더 컸는지였다. 해고가 지나치다는 반응이 많았지만, 배포 방식 자체를 가볍게 볼 수 없다는 지적도 반복됐다.

실무 경험을 꺼낸 이들은 오픈소스 공개와 브랜드 사용을 분리해서 봤다. 과거 구글에서 개인이나 팀이 깃허브에 도구를 공개하는 일이 흔했다는 증언은 있었다. 그러나 구글 워크스페이스라는 이름, 로고, 브랜드 색상, 공식 저장소처럼 보이는 형태는 다른 문제라는 반론이 강했다. 법무, 개인정보, 출시 검토를 거치지 않은 도구가 갑자기 주목을 받으면, 조직은 먼저 사용자 오해와 책임 소재를 따질 수밖에 없다는 것이다.

반대로 처분이 과했다는 쪽은 이 CLI가 실제 사용자에게 가치를 줬고, 장기 근속 개발자가 회사 제품을 더 쓸모 있게 만들려 했다는 점을 봐야 한다고 했다. 질책, 이름 변경, 저장소 이전, 공식화 검토 같은 선택지가 있었는데 곧바로 해고까지 간 것은 조직 정치나 내부 로드맵 충돌이 얽힌 결과일 수 있다는 해석도 나왔다. 다만 공개된 설명만으로는 절차를 지켰는지, 경고나 시정 요구가 있었는지 알 수 없어 한쪽 이야기만으로 단정하기 어렵다는 신중론도 적지 않았다.

회사 업무와 맞닿은 도구를 공개할 때는 코드 품질이나 커뮤니티 반응만으로 충분하지 않다. 누가 소유하는지, 어떤 이름과 계정으로 배포하는지, 사용자가 공식 지원 제품으로 오해할 여지가 있는지 먼저 확인해야 한다. 동시에 조직도 내부의 유능한 실험을 규정 위반으로만 처리하면 제품 감각과 개발자 신뢰를 함께 잃을 수 있다. 이 사건은 CLI 하나보다 대기업 안에서 실험과 책임의 경계를 어디에 그을지 묻는 사례에 가깝다.