중국 개발자들은 업무를 위해 토큰 접근권을 구매하고 있지만, 고용 안정성 주장은 입증되지 않았다

중국 개발자들이 업무를 위해 토큰 접근권을 구매하고 있다는 보도가 나왔지만, 일자리를 지키기 위해 비용을 내야 한다는 바이럴 주장은 아직 검증되지 않았다.

이 주장은 2026년 8월 15일까지 Zhihu에 확산됐다. 프로그래머들이 고용 가능성을 유지하기 위해 매달 AI 사용료를 내고 있으며, 이는 일을 하기 위해 돈을 내는 관행으로 묘사됐다. 해당 페이지는 개발자, 고용주, 계약, 비용 상환 정책, 해고 위협을 뒷받침하는 문서를 특정하지 않았다.

이 같은 증거 공백은 중요하다. 개인 구독은 실험, 편의성, 또는 고용주가 필수 인프라 비용을 지원하지 않는 상황을 반영할 수 있다. 이 가운데 마지막 경우만이 가장 강한 형태의 주장을 뒷받침한다.

그러나 이 논란이 전혀 근거 없이 생겨난 것은 아니다. 개발자들은 더 많은 AI 코딩 에이전트를 사용하고 있고, 기업들은 높은 사용량을 치켜세우며, 컴퓨팅 비용은 개인 단위에서 가시화되고 있다. 이제 갈등은 단순히 근로자 대 자동화의 문제가 아니다. 고용주의 기대와 고용주의 책임 사이의 문제다.

바이럴 토큰 주장이 실제로 입증하는 것

현재 उपलब्ध한 증거는 개발자들이 고용 안정성을 구매했다는 검증된 사례가 아니라, 업무 비용을 둘러싼 논란을 뒷받침한다.

Zhihu의 질문은 우려스러운 인과관계를 제시한다. 프로그래머들은 높아지는 산출 기대치를 맞추기 위해 AI가 필요하다. 고용주는 충분한 사용량 비용을 부담하지 않는 것으로 알려졌다. 결국 근로자들은 뒤처지는 것이 고용을 위협할 수 있기 때문에 추가 용량을 구매한다.

이 흐름은 그럴듯하지만, 그럴듯함이 검증을 뜻하지는 않는다. 공개된 질문에는 급여 기록, 내부 정책 문서, 청구서, 또는 실명이 확인된 기업과 연결된 증언이 없다. 근로자들이 유료 도구를 사용하라는 지시를 받았는지도 입증하지 못한다.

7월 18일 보도된 기업 토큰 예산에 관한 기사는 가장 분명한 배경을 제공한다. 이 보도는 중국 기술 기업들이 AI 소비를 새로운 업무 자원으로 취급하고 있다고 설명했다. 일부 고용주는 접근권을 배정했고, 엔지니어들은 급여 및 기타 복리후생과 함께 토큰 할당량을 논의했다.

토큰은 AI 모델이 처리하거나 생성하는 텍스트의 작은 단위다. 코딩 에이전트는 저장소를 반복적으로 살피고, 변경 사항을 생성하며, 테스트를 실행하고, 오류를 읽고, 작업을 수정하기 때문에 많은 양을 소비할 수 있다.

즉, 에이전트 기반 코딩 세션은 하나의 단순한 질문이 아니다. 긴 소스 파일과 반복적인 추론을 자주 수반하는 모델 호출의 연쇄다. 따라서 최종 코드 변경이 작아 보여도, 더 자율적인 작업은 더 많은 사용량을 만들어낼 수 있다.

회사가 비용을 부담하는 접근권과 근로자가 비용을 부담하는 접근권의 차이는 핵심적이다. 자발적인 개인 계정은 직원이 선호하는 키보드를 선택하는 것과 비슷하다. 의무적이면서 비용 상환이 없는 접근권은 고용주가 근로자에게 생산 인프라를 제공하라고 요구하는 것과 같다.

중간 범주도 있다. 일부 기업은 승인된 보조 도구 하나를 제공하지만, 개발자들은 자신의 업무를 더 잘 처리한다는 이유로 다른 도구를 구매한다. 이 선택은 처음에는 자발적일 수 있지만, 관리자가 그에 따른 속도를 마감 일정에 반영한 뒤에는 포기하기 어려워질 수 있다.

바이럴 주장은 이처럼 서로 다른 배치를 하나의 극적인 표현으로 압축한다. 이는 해당 질문을 경고로서는 유용하게 만들지만, 광범위한 고용 관행의 증거로서는 신뢰하기 어렵게 만든다.

그럼에도 이 주장이 주요 논의로 떠오를 만큼 그럴듯하게 받아들여졌다는 점은 의미가 있다. 이 반응은 AI 접근권이 선택적 실험에서 비공식적인 직업 경쟁력의 조건으로 얼마나 빠르게 이동했는지를 보여준다.

토큰 접근권은 업무의 일부가 되고 있다

기업 정책이 여전히 이를 개인 생산성 선호로 취급하더라도, AI 코딩 역량은 업무 인프라처럼 기능하기 시작했다.

JetBrains는 2026년 1월 1만 명이 넘는 전문 개발자를 조사했다. 개발자 AI 설문조사에 따르면 90%가 코딩과 개발 업무에 적어도 하나의 AI 도구를 정기적으로 사용했다.

같은 조사에서는 74%가 일반 챗봇에만 의존하지 않고 전문 개발자 도구를 도입한 것으로 나타났다. GitHub Copilot은 가장 널리 사용된 전문 제품으로 남았다. Claude Code와 Cursor는 직장 내 도입률에서 그다음 순위를 공유했다.

이 수치는 누가 비용을 지불했는지는 보여주지 않는다. 다만 AI 보조 개발이 더 이상 얼리어답터에만 국한된 드문 관행이 아니라는 점은 보여준다.

더 이른 시기의 GitHub 설문조사도 다른 표본에서 비슷한 결론에 도달했다. 이 조사는 4개국의 엔터프라이즈 소프트웨어 종사자 2,000명을 대상으로 했다. 공개된 엔터프라이즈 사용 데이터에 따르면 97% 이상이 어느 시점에 업무에서 AI 코딩 도구를 사용했다고 답했다.

기업 지원은 일관적이지 않았다. 국가에 따라 59%에서 88%가 고용주가 AI 사용을 허용하거나 적극 장려한다고 답했다. 이는 도입과 제도적 지원 사이에 의미 있는 격차가 남아 있음을 뜻한다.

고용주는 라이선스, 사용 예산, 보안 통제, 교육, 평가 기준을 제공하지 않으면서 AI 사용이 허용된다고 말할 수 있다. 허용만으로는 위험이 근로자에게서 거의 이전되지 않는다.

관리자가 AI 보조 산출물을 본 뒤 기대치를 수정하면 압박은 더 강해진다. 과거에 며칠 걸리던 업무를 이제는 더 빨리 끝내라는 요구를 받을 수 있다. 무료 할당량이 소진되거나 선호 모델을 사용할 수 없게 되어도 새 마감일은 그대로 남을 수 있다.

이는 래칫 효과를 만든다. 일시적인 성과 향상은 영구적인 기대치가 되고, 도구 비용은 계속 변동한다. 근로자들은 개인적으로 비용을 내거나, 겉으로 보이는 성과 하락을 감수하거나, 제약을 숨기려 하는 선택에 놓인다.

이 역학은 구직자, 계약직 근로자, 성과 평가를 받는 직원에게 특히 날카롭게 작용한다. 이들은 생산성 의무화에 이의를 제기할 협상력이 더 낮고, 도구 지출을 방어적 비용으로 볼 이유는 더 많다.

AI 접근권은 직원이 어떤 업무를 수락하는지에도 영향을 줄 수 있다. 유능한 코딩 에이전트를 가진 개발자는 익숙하지 않은 코드베이스를 탐색하고, 테스트 초안을 작성하며, 언어 간 번역을 더 빠르게 수행할 수 있다. 접근권이 제한된 동료는 두 사람이 비슷한 엔지니어링 판단력을 갖고 있어도 같은 업무를 피할 수 있다.

그렇다고 더 많은 지원을 받는 개발자가 본질적으로 더 뛰어난 것은 아니다. 조직이 구매력이 측정된 성과에 영향을 미치도록 허용했다는 뜻이다.

기업들은 이미 클라우드 환경, 테스트 장비, 컴파일러, 관측성 시스템에 대해서는 이 원칙을 인정하고 있다. 더 나은 인프라를 쓰면 경쟁력이 높아진다는 이유로 직원들이 생산 데이터베이스 비용을 부담하리라고 기대하는 경우는 드물다.

에이전트가 일상적인 개발 업무에 더 깊이 들어갈수록 AI를 다르게 취급하기는 어려워진다. 도구 사용이 기대되거나, 모니터링되거나, 납품 목표에 반영된다면 접근권은 사업 투입요소다.

이는 논란이 드러낸 첫 번째 업계 문제다. 기업들은 누가 비용, 계정, 데이터, 그리고 그에 따른 책임을 부담하는지 정의하는 속도보다 더 빠르게 AI 기대치를 운영에 반영하고 있다.

토큰 지출이 나쁜 생산성 지표인 이유

토큰 소비는 고객 가치, 엔지니어링 품질, 또는 완료된 업무가 아니라 계산 활동을 측정한다.

기업의 열기는 소비를 일종의 지위 상징으로 바꾸는 데 일조했다. 경영진은 높은 사용량을 근로자들이 AI를 받아들이고 있다는 증거로 홍보했다. 일부 조직은 사용량을 중심으로 내부 캠페인이나 경쟁을 운영한 것으로 알려졌다.

논리는 직관적으로 들린다. 에이전트가 근로자의 생산성을 높인다면, 더 많은 에이전트를 실행하는 직원은 더 많은 가치를 만들어야 한다. 그러나 이 논증의 모든 단계에는 사용량 대시보드가 제공할 수 없는 증거가 필요하다.

더 많은 소비는 에이전트가 복잡한 업무를 처리했다는 의미일 수 있다. 반대로 프롬프트에 맥락이 부족했거나, 모델이 잘못된 경로를 택했거나, 사용자가 부실한 결과물을 반복해서 수정했다는 의미일 수도 있다. 두 개발자는 매우 다른 처리량으로 같은 결과에 도달할 수 있다.

생산성이 떨어질 때조차 사용량은 늘어날 수 있다. 에이전트는 불필요한 파일을 만들거나, 패치를 과도하게 복잡하게 하거나, 관련 없는 해결책을 탐색할 수 있다. 추가 시도마다 활동량은 늘지만 검토 작업도 더 많이 발생한다.

Associated Press는 7월 27일 tokenmaxxing의 한계를 둘러싼 기업의 열기가 비용 검토로 바뀌고 있다고 보도했다. 기업들은 더 높은 AI 소비가 자동으로 그에 상응하는 성과 향상을 만들지는 않는다는 사실을 발견하고 있었다.

이러한 전환은 직원이 개인적으로 사용량을 극대화해야 한다는 생각을 약화시킨다. 기업 스스로도 소비와 수익을 안정적으로 연결하지 못한다면, 근로자들이 헌신을 보여주기 위해 단순 활동량을 구매해야 할 이유는 없다.

소프트웨어 관리의 역사는 유용한 비교를 제공한다. 한때 코드 줄 수는 깔끔한 생산성 지표처럼 보였다. 팀들은 결국 더 많은 코드가 중복, 불필요한 복잡성, 또는 유지보수 부담을 뜻할 수 있음을 깨달았다.

토큰 수는 더 빠른 속도로 같은 실수를 반복할 위험이 있다. 중간 자원을 성과 목표로 바꾸기 때문이다.

좋은 엔지니어링은 미래의 작업을 줄이는 경우가 많다. 개발자는 더 이상 필요 없는 시스템을 삭제하거나, 요구사항을 좁히거나, 기능 자체가 만들어지지 않도록 막을 수 있다. 이런 결정은 AI 용량을 거의 소비하지 않으면서도 상당한 가치를 창출할 수 있다.

반면 에이전트는 몇 분 안에 큰 패치를 생성할 수 있다. 그 결과물 역시 사람이 동작을 검증하고, 보안을 평가하며, 아키텍처상 결과를 이해하고, 변경 사항이 제품에 포함되어야 하는지 결정해야 한다.

따라서 관리자는 소비 지표보다 결과 지표가 필요하다. 유용한 신호에는 리드타임, 유출 결함, 검토 부담, 신뢰성, 고객 영향, 완료된 변경 사항의 유지보수성이 포함된다.

이 지표들조차 주의가 필요하다. 더 빠른 납품은 미뤄진 테스트를 숨길 수 있고, 눈에 띄는 결함이 줄었다는 것은 탐지 역량이 약해졌음을 반영할 수도 있다. 어떤 단일 지표도 개발자가 AI를 효과적으로 사용했는지를 결정해서는 안 된다.

근로자 부담 모델은 측정을 더 어렵게 만든다. 직원들이 개인 비용으로 계정을 사용하면 고용주가 통제하거나 감사할 수 없는 계정을 쓸 수 있다. 관리자는 그 뒤의 프롬프트, 모델, 데이터 노출, 처리 경로를 보지 못한 채 산출물만 보게 된다.

이는 성숙한 엔지니어링 조직이 억제해야 할 행동을 오히려 보상할 수 있다. 겉으로 가장 빠르게 기여하는 사람이 지식재산권 또는 보안 측면에서 가장 큰 위험을 감수하고 있을 수 있다.

따라서 이 논쟁은 비용 상환을 넘어선 문제다. 기업이 AI를 통제된 생산 시스템으로 관리할지, 아니면 보이지 않는 개인적 이점으로 취급할지에 관한 문제다.

생산성 약속에는 여전히 검증 문제가 있다

AI는 일부 코딩 업무를 가속할 수 있지만, 유료 접근권을 저성과에 대한 보편적 방어책으로 취급할 만큼의 증거는 없다.

개발자들은 코딩 보조 도구에서 의미 있는 이점을 보고한다. GitHub의 엔터프라이즈 응답자들은 이 도구들이 코드베이스 탐색, 테스트 생성, 프로그래밍 언어 도입, 시스템 설계에 더 많은 시간을 쓰는 데 도움이 된다고 평가했다.

JetBrains 역시 여러 제품의 광범위한 도입과 높은 만족도를 기록했다. 개발자들은 계속 사용할 만큼 충분한 가치를 분명히 느끼고 있다.

그러나 체감 속도와 측정된 속도는 다를 수 있다. 연구기관 METR이 2025년에 친숙한 리포지터리에서 작업하는 경력 있는 오픈소스 개발자 16명을 대상으로 실시한 연구가 이를 보여준다. 참가자들은 AI가 자신들을 더 빠르게 만들 것이라고 예상했지만, 측정 결과는 정반대였다.

측정 기반 코딩 연구의 요약에 따르면, 참가자들은 AI가 업무 속도를 약 20% 높였다고 생각했다. 그러나 실험 결과 실제 작업 시간은 약 20% 더 길어졌다.

연구진은 이 결과를 모든 개발자나 모든 업무에 일반화해서는 안 된다고 경고했다. 표본 규모가 작았고, 참가자들은 숙련자였으며, 도구 역시 계속 변화하고 있기 때문이다.

이런 한계는 중요하다. 자신감과 측정치 사이의 격차 역시 중요하다.

에이전트가 즉시 눈에 보이는 코드를 만들어내면 직원은 자신이 더 빨라졌다고 느낄 수 있다. 그러나 더 느린 과정은 이후 코드 읽기, 테스트, 디버깅, 가정 수정 과정에서 찾아온다. 심리적 보상은 초기에 집중되지만, 검증 비용은 전체 워크플로 전반에 분산된다.

업무마다 효과도 다르게 나타난다. 보일러플레이트, 독립적인 테스트, API 예시, 마이그레이션 초안은 에이전트와 잘 맞을 수 있다. 반면 모호한 제품 요구사항, 레거시 동작, 보안에 민감한 코드, 아키텍처 결정에는 더 많은 맥락과 판단이 필요하다.

모델 선택도 중요하다. 더 큰 모델은 더 어려운 추론을 처리할 수 있지만 더 많은 리소스를 소비할 수 있다. 모든 작업을 가장 성능이 높은 옵션으로 라우팅하면 일상적인 업무 품질을 높이지 못한 채 비용만 증가할 수 있다.

직원에게 개인 비용 지출을 요구하는 조직은 이런 차이를 마주하지 않아도 된다. 각 직원이 통제되지 않은 실험을 하게 만든 뒤, 눈에 보이는 결과만 평가하면 되기 때문이다.

이런 방식은 실패한 사용 사례도 숨긴다. 특히 경영진이 이미 AI를 생산성 요건으로 선언한 상황에서는, 직원들이 에이전트의 결과물을 바로잡는 데 쓴 시간을 굳이 알리려 하지 않는다. 성공 사례는 위로 전달되지만, 낭비된 시간은 개인에게 남는다.

그 결과 선택 편향이 발생한다. 리더는 잘 다듬어진 데모와 더 빨라진 티켓 처리를 보지만, 중단된 시도나 이후의 유지보수 비용까지 항상 보지는 못한다.

공정한 성과 시스템은 접근성과 역량을 분리해야 한다. 회사가 비용을 부담하는 에이전트를 쓰는 개발자와 무료 접근만 가능한 개발자를 비교해서는 안 된다. 더 많은 비용을 쓰는 사람이 더 뛰어난 엔지니어라고 가정해서도 안 된다.

대신 고용주는 통제된 평가를 실시할 수 있다. 팀은 작업 범주를 식별하고, 엔드투엔드 제공 시간을 측정하며, 리뷰 시간을 추적하고, 결함 결과를 살필 수 있다. 개인별 사용량을 경쟁으로 만들지 않고도 워크플로를 비교할 수 있다.

개발자에게는 AI가 마찰만 더할 때 이를 거부할 여지도 필요하다. 한 리포지터리에서 도움이 되는 도구가 다른 리포지터리에서는 언어 지원, 문서 품질, 테스트 커버리지, 컨텍스트 크기 때문에 실패할 수 있다.

모든 거부를 변화에 대한 저항으로 규정하면 전문적 판단을 위축시킨다. 또한 기밀성이나 신뢰성이 우선되어야 하는 환경에서 직원들이 AI를 사용하도록 몰아갈 수 있다.

따라서 AI 코딩 도구를 지지하는 가장 강력한 논거는 조건부다. 작업에 적합하고, 모델이 충분한 맥락을 확보하며, 개발자가 결과를 검증할 수 있고, 주변 프로세스가 그 이득을 포착할 때 유용하다.

그 어느 것도 더 많은 접근 권한을 구매하면 직업이 더 안전해진다는 자동적인 결론을 뒷받침하지는 않는다.

직원 부담 AI는 보안 및 책임성 공백을 만든다

개발자가 업무용 AI를 독자적으로 구매하면 고용주는 조달 비용을 아낄 수 있지만, 더 큰 법적·보안·유지보수 위험을 떠안게 될 수 있다.

개인 AI 계정은 많은 기업 통제 체계 밖에 놓인다. 중앙화된 ID 관리, 승인된 보존 설정, 사용 로그, 제출 코드에 적용되는 계약 조건이 없을 수 있다.

마감 압박을 받는 개발자는 스택 트레이스, 소스 파일, 데이터베이스 스키마, 고객 세부 정보 또는 내부 문서를 모델에 붙여넣을 수 있다. 조직이 승인된 워크플로를 제공하지 않으면, 책임감 있는 직원조차 프롬프트가 무엇을 드러내는지 잘못 판단할 수 있다.

위험은 데이터가 회사를 떠나는 데만 국한되지 않는다. AI가 생성한 코드는 의존성을 추가하거나, 안전하지 않은 패턴을 복제하거나, 권한을 잘못 이해하거나, 리뷰어가 추적하기 어려운 동작을 만들 수 있다.

GitLab이 발표한 AI 거버넌스 조사 결과를 통해 보도된 2026년 연구는 개발자 1,500명 이상을 조사했다. 이 조사에서는 개인 개발자의 생산성만큼 소프트웨어 제공이 빨라지지는 않았다고 보는 응답자가 79%였다.

같은 보고서는 85%가 리뷰와 검증을 핵심 제약 요인으로 봤다고 전했다. 또한 43%는 AI 생성 코드와 사람이 작성한 코드를 구분하는 데 어려움을 겪는 것으로 나타났다.

이 결과는 벤더 연구에서 나온 것이므로 그 맥락을 고려해 읽어야 한다. 그럼에도 개인 구매만으로 해결할 수 없는 조직적 문제를 짚어낸다.

코드 생성은 개인 수준에서 이뤄지지만, 리뷰, 배포, 사고 대응, 유지보수는 팀 전체에 걸쳐 이뤄진다. 한 직원이 시간을 절약하는 동안 동료에게 더 큰 비용을 전가할 수 있다.

이는 로컬 생산성과 시스템 생산성의 차이다. 로컬 생산성은 한 사람이 초안을 더 빨리 완성했는지를 묻는다. 시스템 생산성은 조직이 더 적은 총 노력으로 신뢰할 수 있는 가치를 제공했는지를 묻는다.

비용을 보전받지 못하는 도구는 둘 다 왜곡할 수 있다. 직원들은 보안, 통합성, 장기 지원보다 개인적 구매 여력에 따라 제품을 고를 수 있다. 팀은 호환되지 않는 워크플로를 통해 코드를 생산하는 여러 에이전트를 쓰게 될 수 있다.

그 결과 책임 소재도 불분명해진다. 회사가 AI 사용을 기대하면서 도구를 승인하지 않는다면 데이터 유출의 책임은 누가 지는가? 관리자가 속도에는 보상하면서 출처는 무시한다면 AI 생성 결함의 책임은 누가 지는가?

대부분의 엔지니어링 문화에서 직원은 자신이 제출한 코드에 대해 책임을 진다. 이 원칙은 타당하지만, 경영진이 검증 시간을 제공하지 않은 채 도구 도입을 압박한다면 불공정해진다.

고용주가 모든 개인 도구를 금지하면서 AI를 반영한 마감 기한은 유지하는 방식으로 이를 해결해서는 안 된다. 그러면 생산성 기대치는 남고, 직원이 이를 충족할 수단만 사라진다.

실행 가능한 정책에는 네 가지 연결된 요소가 필요하다. 비용 지원 접근성, 승인된 데이터 처리 관행, 작업별 가이드라인, 현실적인 리뷰 시간이다. 이 가운데 하나라도 빠지면 허점이 생긴다.

비용 지원 접근성은 개인 소득이 업무 역량을 좌우하지 않도록 한다. 승인된 관행은 어떤 데이터를 모델에 입력할 수 있는지 정의한다. 작업 가이드라인은 유용한 적용 사례와 고위험 사례를 구분한다. 리뷰 시간은 생성된 코드가 완성된 코드가 아니라는 점을 인정한다.

팀에는 지속 가능한 기록도 필요하다. 프롬프트, 결정, 테스트, 아키텍처 맥락은 개인 세션이 끝난 뒤에도 남아 있어야 한다. 검색 가능한 엔지니어링 지식 기반은 원시 토큰 양을 업무 기록으로 삼지 않으면서도 추론 과정을 보존할 수 있다.

이 접근법은 AI를 소프트웨어 공급망의 일부로 다룬다. 또한 불확실성을 개별 직원에게 떠넘기는 대신, 조달 부문이 결과에 책임지게 만든다.

노동의 핵심 쟁점은 누가 이익을 가져가는가다

AI가 산출 기대치를 높이면서 직원이 도구 비용과 위험을 부담한다면, 고용주는 이익을 얻고 직원은 비용을 떠안는다.

기업은 전문가가 자신의 역량을 개발하기를 일상적으로 기대한다. 직원들은 책을 사고, 강좌를 수강하고, 소프트웨어를 실험하며, 개인 프로젝트를 유지한다. 모든 경력 관련 지출이 보상을 받아야 하는 것은 아니다.

하지만 의무적인 생산 투입물은 다르다. 구분은 통제, 필요성, 수혜에 달려 있다.

개발자가 학습이나 개인적 편의를 위해 자유롭게 도구를 구매한다면, 그 비용은 전문성 개발에 가깝다. 고용주가 도구를 요구하거나, AI 의존적인 목표를 설정하거나, 접근 권한이 없는 직원을 불이익 준다면 그 비용은 사업 장비에 더 가깝다.

비공식적 압박은 이 기준을 복잡하게 만든다. 관리자가 서면 지시를 내리지 않을 수도 있다. 팀이 더 빠른 산출을 당연시하게 되면서 직원들이 유료 접근이 필요하다고 결론내릴 수도 있다.

검증된 해고 위협이 없더라도, ‘일하기 위해 돈을 낸다’는 표현이 실질적인 우려를 포착하는 지점이 바로 여기다. 고용 압박은 명시적 지시보다 순위, 마감 기한, 계약 갱신, 배정 업무의 질을 통해 작동하는 경우가 많다.

소득이 높은 직원은 더 많은 역량을 구매하고, 여러 구독을 유지하거나, 추가 모델을 실험할 수 있다. 주니어 직원과 계약직은 선택지가 더 적을 수 있지만, 속도를 입증해야 한다는 압박은 더 클 수 있다.

그 결과 불평등은 스스로 재생산될 수 있다. 더 나은 접근성은 더 눈에 띄는 산출을 만들고, 눈에 띄는 산출은 더 좋은 업무 배정을 낳으며, 더 좋은 배정은 직원의 입지를 강화한다.

AI 벤더는 수요가 중앙 조달에서 수백만 명의 개인 구매자로 이동하기 때문에 이런 분절화의 혜택을 얻는다. 고용주는 어려운 거버넌스 결정을 미루는 동안 직원들이 도입 비용을 부담하게 할 수 있다.

다만 분산된 실험에는 장점도 있다. 개발자는 기업 조달이 따라오기 전에 새 제품을 시험할 수 있다. 소규모 팀은 긴 승인 절차를 기다리지 않고 유용한 워크플로를 발견할 수 있다.

문제는 실험이 기대치로 바뀔 때 시작된다. 경영진이 그 산출에 의존하기 시작하면, 회사는 접근성과 책임을 공식화해야 한다.

개인 협상력은 약하기 때문에 집단적 명확성이 중요하다. 도구 비용 부담을 거부하는 한 개발자는 비협조적으로 보일 수 있다. 그러나 그 반대는 회사 데이터를 보호하고 공정한 비용 경계를 세우는 일일 수 있다.

팀은 AI 사용이 선택 사항인지, 권장 사항인지, 의무 사항인지 명확히 해야 한다. 이 범주는 운영상 의미를 가져야 한다.

선택적 사용은 성과 기준이 접근 권한을 전제로 하지 않는다는 뜻이다. 권장 사용은 고용주가 승인된 경로를 제공하되 작업별 거부를 받아들인다는 뜻이다. 의무 사용은 고용주가 필요한 리소스, 교육, 리뷰 프로세스를 제공한다는 뜻이다.

보상도 주목할 필요가 있다. AI가 실제로 한 직원이 더 가치 있는 일을 생산하도록 한다면, 논의가 더 높은 할당량에서 끝나서는 안 된다. 조직은 생산성 향상이 인력 배치, 급여, 업무량, 경력 개발에 어떤 영향을 미칠지 결정해야 한다.

그렇지 않으면 직원들은 일방적인 거래를 마주하게 된다. 산출을 늘리기 위해 비용을 지불하고, 고용주는 기대치를 높이며, 절약된 시간은 추가 업무로 사라진다.

이런 패턴은 도입을 해칠 수 있다. 개발자가 AI를 감시, 보상 없는 지출, 고용 불안과 연관 짓게 되면 방어적으로 사용할 것이다. 워크플로를 숨기거나, 이점을 과장하거나, 실패를 보고하지 않을 수 있다.

신뢰는 더 나은 데이터를 만든다. 직원들이 성과 평가에 위협을 받지 않고 에이전트가 실패하는 지점을 논의할 수 있을 때, 기업은 어떤 작업에 투자할 가치가 있는지 배울 수 있다.

따라서 업계에는 기술 프레임워크와 함께 노동 프레임워크도 필요하다. 토큰 효율성, 모델 라우팅, 코드 품질도 중요하지만, 비용 배분과 협상력 역시 중요하다.

토큰 반발 이후 주목할 점

세 가지 신호는 직원 부담 AI가 비공식적 관행으로 남을지, 아니면 책임 있는 업무 인프라로 자리 잡을지를 보여줄 것이다.

첫 번째 신호는 조달 정책이다. 고용주는 어떤 코딩 도구에 비용을 지원하는지, 어떤 사용 제한이 적용되는지, 직원이 추가 용량을 어떻게 요청하는지 명시하기 시작해야 한다.

명확한 비용 보전 규정은 AI가 표준 업무 투입물이 되었다는 관점을 강화할 것이다. 지속적인 침묵은 직원들이 개인 계정을 통해 비용을 떠안게 할 것이다.

기업이 모델 선택을 어떻게 다루는지도 지켜봐야 한다. 작업별 라우팅이 없는 고정 수당은 복잡한 리포지터리에 배정된 사람들에게 여전히 불이익을 줄 수 있다. 공정한 접근성에는 동일한 할당량뿐 아니라 예외를 위한 절차도 필요하다.

두 번째 신호는 성과 측정이다. 기업은 토큰 양, 생성 코드 수, 원시 티켓 처리 속도에서 벗어나야 한다.

종단간 지표로의 전환은 보다 성숙한 도입 주기를 시사할 것이다. 관련 결과에는 리뷰 시간, 결함률, 사고 영향, 유지보수성, 고객 가치가 포함된다.

반대 신호는 사용량에 연동된 리더보드가 늘어나는 것이다. 이는 AI 사용이 결과로 평가되는 도구가 아니라 몰입의 대리 지표가 되고 있다는 우려를 강화할 것이다.

세 번째 신호는 거버넌스 적용 범위다. 고용주는 승인된 계정을 신원 통제, 데이터 규칙, 추적 가능성, 코드 리뷰와 연결해야 한다.

개인용 사용은 사라지지 않을 것이다. 중요한 질문은 기업이 직원의 개인 계정보다 더 안전하고 유용한, 지원되는 워크플로를 제공할 수 있느냐다.

거버넌스가 개선되면 이 논란에 대한 가장 가혹한 해석은 약화될 것이다. 이는 고용주가 근로자에게 사용을 요구하는 기술에 대한 책임을 받아들이고 있음을 보여줄 것이다.

징계 분쟁, 코드 유출, 또는 숨겨진 개인 계정이 증가한다면 반대 방향을 가리킬 것이다. 이는 조직이 필요한 운영 구조를 구축하지 않은 채 AI 중심의 기대치를 부과했음을 시사할 것이다.

식별 가능한 증거가 나오기 전까지는 원래의 Zhihu 주장을 검증되지 않은 것으로 표시해야 한다. 익명 토론을 프로그래머들이 해고를 피하기 위해 광범위하게 토큰 접근 권한을 구매한다는 증거로 제시할 책임 있는 근거는 없다.

그러나 이 논란을 일축하는 것 역시 더 큰 변화를 놓치는 일이다. AI 코딩 도구는 널리 보급됐고, 사용 비용은 눈에 띄며, 개인의 산출물은 점점 더 AI 지원을 받는 동료들과 비교해 평가되고 있다.

개발자는 업무 관련 용량에 비용을 지불하기 전에 직접적인 질문을 해야 한다. 이 도구는 선택 사항인가? 회사 데이터가 이 도구에 입력될 수 있는가? 비용은 상환되는가? 마감일은 이 도구의 사용을 전제로 하는가? 이를 통해 발생한 실수의 책임은 누구에게 있는가?

엔지니어링 리더는 더 높은 사용량을 축하하기 전에 이러한 질문에 답해야 한다. AI가 업무에 필수라면 회사가 비용을 부담하고 관리해야 한다. 선택 사항이라면 성과 시스템은 그 선택권을 보장해야 한다.

결정적인 문제는 프로그래머가 얼마나 많은 토큰 단위를 소비할 수 있느냐가 아니다. 조직이 비용, 위험, 불안을 업무 수행자에게 전가하지 않고 AI 활동을 신뢰할 수 있는 가치로 전환할 수 있느냐다.