2026년 9월 15일에 구글이 전 엔지니어에게 Claude 를 쓰게 했다는 기사 제목을 봤습니다. 전원이 쓰게 됐다는 말은 그 앞에 일부만 쓰던 기간이 있었다는 뜻입니다. 그 일부가 누구였고 무슨 기준으로 갈렸는지가 제가 먼저 떠올린 질문이었습니다. 제미나이를 만드는 회사 안에서도 누구는 쓰고 누구는 못 썼다는 뜻이기도 합니다.
이 글은 어느 모델이 코드를 더 잘 쓰는지를 따지는 글은 아닙니다. 벤치마크 표도 없고 가격 비교도 없습니다. 제가 보려는 자리는 하나입니다. 도구를 막고, 예외를 주고, 회수하려다 무산된 이 결정이 어느 층위에서 내려왔는가.
먼저 밝혀 둘 것이 있습니다. 저는 구글 내부자도 업계 분석가도 아니고, 무엇을 쓸지 대부분 혼자 정해 온 개발자로 이 기록을 읽었습니다. 그리고 9월 15일 Business Insider 기사의 본문을 읽지 못했습니다. businessinsider.com 이 차단돼 있고 로이터 중계본은 페이월이라, 제가 확인한 것은 제목과 헤드라인뿐입니다. 그래서 9월 15일에 관해 이 글이 적을 수 있는 범위는 제목이 말해 주는 만큼이고, 그 경계는 뒤에 한 절을 따로 두어 적었습니다.
읽은 순서도 그대로 적자면, 저는 9월 제목을 보고 4월 보도부터 다시 읽었습니다.
2026년 4월 디지털투데이 보도에 적힌 사유는 보안 한 줄이었습니다
그 기간의 정책은 4월 보도에 남아 있습니다. 디지털투데이가 2026년 4월 22일에 블룸버그를 인용해 이렇게 적었습니다.
구글은 보안을 이유로 직원들에 클로드 코드, 오픈AI 코덱스 같은 경쟁사 툴을 쓰지 못하도록 하고 있지만 업무상 필요성을 증명하면 직원들이 예외를 신청할 수 있다.
한 줄에 두 가지가 들어 있습니다. 기본값은 금지였고, 예외 신청 제도가 따로 있었습니다.
저는 예외의 조건에서 멈췄습니다. 보안이 유일한 사유였다면 예외의 조건은 보안 요건 충족이어야 자연스럽습니다. 데이터가 어디로 나가는지, 프롬프트와 코드가 어느 사업자의 서버를 지나는지, 로그가 어디에 얼마나 남는지를 증명하면 열어 주는 형태 말입니다. 그런 제도라면 같은 요건을 충족한 팀은 전부 같은 답을 받습니다.
실제로 적힌 조건은 업무상 필요성입니다. 필요성을 증명하는 절차는 위험의 크기를 재지 않습니다. 재는 것은 이 사람에게 이 도구를 줄 만한가입니다. 그래서 같은 도구를 놓고도 팀마다 다른 답이 나올 수 있고, 답이 갈리는 기준은 데이터 경로에서 업무의 중요도 쪽으로 옮겨 갑니다. 저는 이 조건 한 줄에서 이 제도가 심사 창구보다 배분 창구에 가깝다고 봤습니다.
보안이 거짓 사유라는 말은 아닙니다. 경쟁사 서버로 사내 코드가 나가는 문제는 실재합니다. 다만 보안 요건은 충족 여부를 문서로 정의할 수 있는 항목이고, 필요성은 그렇지 않습니다. 정의할 수 있는 것을 정의하지 않고 남겨 둔 자리가 이 정책의 성격을 말해 줍니다.
예외 신청 제도가 조직에 남기는 것도 생각해 볼 만합니다. 누가 신청했고 어떤 사유를 적었고 승인이 났는지가 한 곳에 모입니다. 경쟁 도구를 쓰고 싶어 하는 사람과 그 이유의 목록이 저절로 쌓입니다. 보안 심사 창구를 운영하면 그 목록은 부산물이지만, 배분 창구를 운영하면 그 목록 자체가 쓸모 있는 자료가 됩니다. 어느 팀이 무엇을 아쉬워하는지를 회사가 취합할 수 있으니까요. 이건 제가 제도의 모양을 보고 떠올린 쓰임이고, 구글이 그 기록을 그렇게 썼다는 근거는 없습니다.
예외를 받아도 오픈소스에서만 클로드 코드를 썼다는 진술이 있습니다
예외를 받으면 무엇이 달라졌는지가 다음 질문입니다. 디지털투데이 영문판에 한 구글 엔지니어의 답변으로 전해진 내용이 있습니다. 클로드 코드 사용이 오픈소스 프로젝트에만 허용됐고 내부 작업에는 쓸 수 없었다는 진술입니다. 개인 엔지니어가 한 말이고 구글의 공식 정책 문서는 아니니, 여기서는 한 엔지니어가 이렇게 말했다는 정도로 두겠습니다.
예외라는 말을 들으면 제한이 사라진 상태를 떠올리게 되는데, 이 진술이 말하는 상태는 선이 한 칸 옮겨간 쪽에 가깝습니다. 사내 코드베이스는 계속 선 밖에 있었습니다.
그 선이 한 사람의 책상 위에서 어떤 모양이 되는지는 the-decoder 가 2026년 1월 3일에 옮긴 장면에 나와 있습니다. 구글 제미나이 API 팀의 principal engineer 인 Jaana Dogan 이 공개 게시물에서, 자기 팀이 1년 걸려 만든 분산 에이전트 오케스트레이터를 클로드 코드가 한 시간 남짓에 재현했다고 적었습니다.
제가 이 장면에서 오래 본 것은 그 한 시간 앞에 붙은 작업입니다. 재현에 걸린 시간보다 그쪽이 정책의 크기를 정확히 보여줍니다. the-decoder 는 그가 클로드 코드를 시험하면서 사내 세부 정보를 쓸 수 없어서(since she couldn't use internal company details) 기존 아이디어를 바탕으로 단순화한 판을 따로 만들었다고 적었습니다. X 원문 게시물은 제가 직접 열어 보지 못했고, 위 문장은 the-decoder 가 옮긴 서술입니다.
정책 한 줄이 실무에서 어떤 작업으로 바뀌는지가 여기 다 나와 있습니다. 경쟁 도구가 쓸 만한지 확인하려면, 확인하고 싶은 대상인 사내 시스템을 빼고 그와 닮은 판을 새로 만들어야 합니다. 만드는 시간은 시험 비용에 그대로 더해지고, 그렇게 얻은 결과는 정작 사내 코드베이스에서 그 도구가 어떨지를 말해 주지 못합니다. 예외를 받은 사람조차 자기 일로는 그 도구를 확인할 수 없었습니다.
같은 기사에 그가 남긴 평가도 옮겨져 있습니다.
Claude Code is impressive work, I'm excited and more motivated to push us all forward.
옮기면, 클로드 코드는 인상적인 작업이고 자신은 신이 나며 우리 모두를 더 나아가게 할 동기가 커졌다는 뜻입니다. 경쟁사 도구를 칭찬한 문장이 제미나이 API 담당자의 계정에서 공개로 나갔다는 사실은 뒤에서 다시 쓰겠습니다.
저는 Codex 로 옮기거나 계정을 하나 더 결제했습니다
도구가 멈추는 일은 저도 겪습니다. 개인 프로젝트로 게임을 여러 개 동시에 만들던 때는 토큰 한도가 빠르게 소진됐고, 출근길에 쓰던 ChatGPT 가 장애로 멈춘 날도 있었습니다. 그날 클로드는 정상이었고, 반대로 클로드 코드 쪽 장애로 세션이 붙지 않는 때도 꽤 있었습니다. 그럴 때 제가 한 일은 셋 중 하나입니다. 직접 코딩하거나, Codex 로 옮기거나, 한도가 문제일 때는 다른 계정을 하나 더 유료로 결제했습니다.
도구를 못 쓰게 되는 상황 자체는 개인에게도 흔합니다. 갈리는 자리는 그다음입니다. 저는 옆으로 옮길 데가 있었고, 옮길 데가 없으면 돈을 더 내서 만들었습니다. 8월에 정리한 글에서 병용이 합리적이라고 본 이유도 같았습니다. 하나만 쓰면 그 벤더의 제품 계층 사고를 그대로 뒤집어쓰니까요. 앞 절의 엔지니어에게는 그 옆자리가 정책으로 닫혀 있었고, 그래서 사내 정보를 빼고 단순화한 판을 따로 만들어야 경쟁 도구를 확인해 볼 수 있었습니다.
균등화 논의에서 먼저 나온 해법은 클로드 전원 회수였습니다
접근권이 고르지 않으면 내부에서 말이 나옵니다. Shopifreaks 가 2026년 4월 21일에 정리한 글에 그 대목이 있습니다.
When the question of equalizing access came up internally, one proposed solution was to remove Claude access from everyone, but DeepMind objected so strongly that several engineers reportedly threatened to leave over it.
옮기면, 접근권을 균등하게 하자는 질문이 내부에서 나왔을 때 제안된 해법 하나는 모두에게서 클로드 접근권을 회수하는 것이었는데, 딥마인드의 반대가 워낙 강해서 몇몇 엔지니어는 그 일로 퇴사를 거론했다고 전해질 정도였습니다.
저는 이 문장을 이 기록에서 가장 중요하게 봅니다. 도구 선택이 생산성 항목으로만 다뤄지는 조직이라면, 접근권 격차가 문제가 됐을 때 먼저 검토되는 해법은 잘 드는 도구를 더 많은 사람에게 주는 쪽입니다. 성과가 오르는 도구를 일부만 쓰고 있다는 사실은 더 사자는 근거가 되지, 있는 것도 걷자는 근거가 되기 어렵습니다.
여기서는 반대 방향이 먼저 나왔습니다. 무엇을 먼저 검토했는지가 그 결정을 어느 부서의 관점에서 다루고 있었는지를 말해 줍니다.
사내 엔지니어 집단이 제미나이의 가장 큰 도그푸딩 표본이라고 저는 봤습니다
이 절부터는 보도된 사실에서 제 해석으로 넘어갑니다. 4월 보도가 적은 공식 사유는 보안 한 줄뿐이고, 아래는 그 한 줄로 설명되지 않는다고 제가 본 자리입니다.
진입점은 앞 절에 적은 제 습관입니다. 개인은 한도가 막히면 계정을 하나 더 결제해서 풉니다. 구글이 클로드 라이선스 비용을 감당하지 못할 회사는 아닙니다. 실제로 구매를 검토했는지 여부는 제가 확인한 자료에 없으니 여기서 할 수 있는 말은 관찰까지인데, 돈으로 풀 수 있는 자리에서 그쪽으로 가지 않은 상태가 몇 달 이어졌습니다. 비용이 걸림돌이었다면 이 상태가 설명되지 않습니다.
그래서 제가 보는 쪽은 도그푸딩입니다. 자기 모델을 파는 회사에서 사내 엔지니어 집단은 그 모델의 가장 큰 사용자 표본입니다. 경쟁 도구를 사내에 허용하면 그 표본이 줄어듭니다. 줄어들었을 때 실제로 무엇이 안 오는지를 적어 보겠습니다. 제미나이로 실무를 돌렸을 때 어느 단계에서 멈췄는지의 사용 로그, 어떤 작업이 반복해서 실패했는지에 대한 사내 불만, 다음 버전에서 무엇을 고쳐 달라는 요청. 이것들이 안 옵니다. 대신 클로드로 하니까 됐다는 결과만 남습니다.
사외 사용자에게서 오는 피드백으로 그 자리를 메우기도 어렵습니다. 밖에서 들어오는 신호는 대부분 결과만 담고 있습니다. 어떤 요청을 넣었더니 잘 안 됐다는 보고는 오지만, 그 사람이 작업하던 코드베이스가 어떤 모양이었고 앞 단계에서 무엇을 이미 시도했는지는 오지 않습니다. 사내 엔지니어에게서는 그 앞뒤가 다 옵니다. 같은 저장소를 들여다볼 수 있고, 모델을 만든 팀에게 복도에서 물어볼 수도 있습니다. 표본의 크기보다 이 밀도가 더 대체하기 어렵습니다.
이 해석을 받치는 자료가 하나 있습니다. 세르게이 브린의 사내 메모가 유출돼 TechRadar 가 옮긴 문장입니다.
To win the final sprint, we must urgently bridge the gap in agentic execution and turn our models into primary developers
옮기면, 마지막 스프린트에서 이기려면 agentic execution 의 격차를 시급히 메우고 우리 모델을 주 개발자로 만들어야 한다는 뜻입니다. 최종 코드를 쓰는 주체를 자사 모델로 만들겠다는 목표가 경영진 메모에 적혀 있다면, 사내 엔지니어의 작업 흐름은 생산성 항목에만 머물지 않습니다. 그 흐름 자체가 제품 개발에 쓰이는 자원입니다.
앞에서 본 게시물도 이 맥락에 놓입니다. 1년짜리 결과물이 한 시간에 재현됐다는 이야기가 제미나이 API 를 담당하는 사람의 계정에서 공개로 나갔습니다. 성능 차가 사내에 알려지는 수준을 넘어 밖에서도 읽히는 형태가 됐습니다. 이런 일이 한 번 일어난 뒤에 경쟁 도구 접근권을 어떻게 할지는 생산성 계산만으로 정해지지 않습니다.
다시 적어 두겠습니다. 여기까지는 제 해석입니다. 구글이 밝힌 사유는 보안 한 줄이고, 그 한 줄이 거짓이라고 말하려는 게 아닙니다. 제가 적은 것은 보안만으로는 예외 제도의 조건도, 회수 제안이 먼저 나온 순서도 설명되지 않는다는 관찰입니다.
회수를 무산시킨 힘은 딥마인드 엔지니어들의 협상력이었습니다
회수 제안은 실행되지 않았습니다. 그 이유가 정책 논쟁의 승패였다면 이 글에 적을 것이 별로 없었을 겁니다. 보도에 남은 이유는 딥마인드의 강한 반대와, 몇몇 엔지니어가 퇴사를 거론했다고 전해지는 상황입니다.
그 거론이 협상력으로 작동한 배경은 같은 시기의 인재 이동입니다. 제미나이에 기여하던 Jonas Adler(AI 코딩)와 Alexander Pritzel(모델 학습)이 앤트로픽으로 옮긴다고 전해졌습니다. 제가 본 자료는 두 사람이 떠나는 중이라고 적은 시점의 것이고, 이후 실제로 합류했는지까지는 확인하지 못했습니다. 대체하기 어려운 사람들이 실제로 나가고 있는 상태에서 나온 퇴사 거론은 허풍으로 읽히지 않습니다.
규정이 사람을 이기지 못한 지점이 여기입니다. 회수는 전원에게 적용하자는 제안이었는데, 그 제안을 멈춘 쪽은 한 조직이었습니다. 도구를 지킬 힘을 가진 집단과 갖지 못한 집단이 같은 회사 안에서 갈렸고, 갈린 기준은 업무의 성격보다 대체 가능성에 가깝습니다. 균등화 논의가 시작된 지점을 생각하면 결과가 묘합니다. 고르게 하자는 말에서 출발해서, 고르지 않은 상태가 그대로 유지됐습니다.
딥마인드 예외가 직무 요건이었는지는 보도에 없습니다. 저는 직무 요건 쪽으로 봤습니다. 최전선 모델을 만드는 조직이 경쟁 모델을 만져 보지 못하면 비교 자체가 성립하지 않으니까요. 다만 이건 제 추론이고, 예외의 근거가 문서로 공개된 자료는 제가 찾지 못했습니다.
구글 CFO 의 발언으로 전해지는 대조도 하나 있습니다. 앤트로픽은 코드의 거의 전부를 AI 로 쓰고 구글은 절반 정도라는 비교인데, 저는 2차 인용으로만 확인했으니 이 숫자를 근거로 세우지는 않겠습니다. 이 발언에서 제가 읽은 것은 비율의 정확도보다 경영진이 격차를 바깥에 대고 인정하고 있었다는 사실입니다.
구글은 AI 사용을 인사 평가에 연동하면서 도구는 제한했습니다
같은 Shopifreaks 기사에 이런 문장이 있습니다.
a divide that has caused friction as Google simultaneously pressures more employees to use AI and ties AI usage to performance reviews
옮기면, 구글이 더 많은 직원에게 AI 를 쓰라고 압박하는 동시에 AI 사용을 인사 평가에 연동하면서 이 격차가 마찰을 일으켰다는 뜻입니다.
두 가지가 같은 시기에 성립합니다. 쓰라는 압박이 평가에 걸려 있고, 쓸 수 있는 도구는 지정돼 있습니다. 이 조합을 개인 쪽에서 계산해 보면 간단합니다. 지정된 도구가 내 작업에서 어디까지 해 주는지와 무관하게, 사용량과 산출물은 평가표에 올라갑니다. 도구가 덜 해 주는 만큼을 메우는 쪽은 사람입니다.
앞 절에서 제가 세운 해석을 여기에 얹으면 이렇습니다. 회사가 도그푸딩에서 얻는 것은 제품 개선에 쓸 신호이고, 그 신호를 만드느라 생기는 시간 차이는 회사 손익 계정에 잡히지 않고 개인의 평가 항목으로 갑니다. 저는 이 기록에서 이 조합을 제일 오래 봤습니다. 구글 안에서 무슨 일이 있었는지보다, 이 조합이 구글 바깥에서도 그대로 성립한다는 쪽이 더 마음에 걸렸습니다.
독자가 자기 회사에서 확인할 수 있는 것도 이 조합입니다. AI 사용률이 평가나 OKR 에 들어가 있는지, 그 평가가 전제하는 도구가 무엇인지, 그 도구로 못 하는 작업이 생겼을 때 산출물 기준이 조정되는지. 앞의 둘이 예이고 마지막이 아니오면, 그 회사도 도구 선택의 대가를 개인에게 옮기고 있는 상태입니다.
2026년 9월 15일 Business Insider 기사에서 제가 확인한 범위는 제목까지입니다
여기는 모르는 자리를 적는 절입니다.
확인한 것부터 적겠습니다. 기사 제목은 Google finally lets all engineers use Anthropic's Claude 입니다. 로이터가 이 기사를 중계했고 헤드라인이 걸려 있습니다. 제가 읽은 범위는 여기까지이고, 기사 본문은 열지 못했습니다.
제목에서 읽을 수 있는 것도 적어 두겠습니다. 대상은 Claude 입니다. Claude Code 라고 적혀 있지 않습니다. 이 글에서 4월 보도를 인용할 때만 클로드 코드로 적고 나머지 자리에서 Claude 로 적은 이유가 이것입니다. 모델을 쓰게 한 것과 코딩 도구를 쓰게 한 것은 사내 정책에서 다른 항목입니다.
제목의 finally 와 all 두 단어도 그 자체로는 시점과 범위를 말해 주지 않습니다. finally 는 기사를 쓴 쪽의 논평이고, all engineers 가 가리키는 범위가 계약직과 자회사까지인지, 아니면 정규 엔지니어 직군까지인지는 제목만으로 갈라지지 않습니다. 사내 정책 문서에서 이 두 단어에 해당하는 표현이 무엇인지도 제가 본 적이 없습니다.
모르는 것은 이만큼입니다. 확대의 조건을 모릅니다. 사내 코드베이스에서 쓸 수 있게 됐는지 모릅니다. 4월의 오픈소스 한정 제약이 지금도 유지되는지는 기사 제목으로 알 수 없습니다. 보안 요건이 어떻게 바뀌었는지, 구글 대변인이 무엇을 말했는지, 언제부터 적용됐는지도 모릅니다. 4월의 예외 신청 제도가 남아 있는지도 모릅니다.
이 자리는 비워 두는 편이 낫다고 봅니다. 구글이 제한을 해제했다는 문장은 제목에서 한 걸음 더 나간 서술이고, 그 한 걸음에 방금 적은 항목이 전부 딸려 옵니다. 제가 적을 수 있는 것은 전 엔지니어가 쓸 수 있게 됐다는 제목이 붙었다는 사실까지입니다. 확인하지 못한 자리를 확인한 것처럼 적기 시작하면 앞 절들의 인용도 같은 값이 됩니다.
구글 사례에서 제가 가져온 기준은 예외 목록과 회수 방향입니다
남의 회사 기록을 여기까지 읽을 이유는 자기 회사에서 쓸 자리가 있을 때뿐입니다. 저는 이 기록을 층위를 가르는 데 씁니다. 회사가 어떤 도구를 막아 놨을 때, 그 결정이 어디서 내려온 것이냐에 따라 할 수 있는 일이 달라지기 때문입니다.
보안 심사에서 온 결정은 문서로 알아볼 수 있습니다. 요건이 적혀 있고, 충족하면 열립니다. 예외 신청 창구가 있고 심사 기준이 공개돼 있습니다. 이 경우에 할 일은 요건을 맞춰 통과시키는 작업입니다. 시간은 걸려도 끝이 있습니다.
계약이나 라이선스에서 온 결정은 모양이 다릅니다. 특정 벤더나 특정 데이터 경로만 막혀 있고, 기능이 비슷한 다른 도구는 열려 있습니다. 이 경우에는 조달이나 법무 쪽에 붙는 편이 빠릅니다. 도구를 바꾸든 계약을 바꾸든 둘 중 하나로 정리됩니다.
자사 제품을 지키려는 결정이 세 번째입니다. 막힌 도구가 회사가 파는 물건과 같은 범주이고, 예외가 조직 단위로만 있고, 그 예외의 기준이 문서로 없습니다. 구글 기록에서 판별 신호가 그대로 나옵니다. 예외 목록을 열어 보고 그 목록이 사람 단위인지 요건 단위인지 조직 단위인지 봅니다. 그리고 접근권을 고르게 하자는 말이 나왔을 때 어느 방향이 먼저 나오는지 봅니다. 회수가 먼저 나오면 그건 위험을 재고 있는 자리가 아닙니다.
세 번째 층위라면 규정을 고치려고 붙어 봐야 잘 안 됩니다. 그 결정을 만든 자리가 규정 바깥이어서 그렇습니다. 그 대신 확인할 것은 대가가 어디로 가고 있는지입니다. 지정된 도구로 할 수 있는 만큼에 맞춰 평가 항목과 산출물 기준이 조정돼 있는지, 조정을 요청할 창구가 있는지. 조정돼 있지 않으면 차액은 개인이 냅니다. 제가 구글 기록에서 회수 제안을 제일 오래 본 이유도 여기에 있습니다. 그 제안이 통과됐다면, 전원이 같은 도구를 쓰는 상태에서 AI 사용률은 여전히 평가에 걸려 있었을 테니까요.
9월 15일 제목이 달라졌다고 말하는 것은 구글 안의 상태입니다. 그 바깥 회사들의 예외 목록은 그대로 있고, 저는 당분간 도구 이야기가 나오면 그 목록부터 보려고 합니다.
댓글
댓글 쓰기