챗GPT 워크, 직원 98%가 쓰는데 외부는 1%도 안 썼다

챗GPT 워크는 지난달 오픈AI 최저 유료 구독 등급에 포함돼 나온 제품인데요, 회계사·투자자·의사처럼 컴퓨터 앞에서 하루를 보내는 화이트칼라 직군에 에이전트를 붙이는 게 목표예요. 개발자들이 이미 코딩 도구로 누리고 있는 자율 작업 능력을, 코딩을 모르는 사람도 쓸 수 있게 코덱스를 개조한 버전이죠. 저희는 지난 8월 11일 챗GPT 워크와 코덱스 간 작업을 자동 동기화하는 기능을 다룬 적이 있는데, 프로젝트·대화·스킬·플러그인을 두 제품 사이에서 옮기는 기능이 이미 그 무렵부터 정비되고 있었어요.

오픈AI는 자사 발표 글에서 "인공지능이 질문에 답하는 걸 넘어 모두가 가장 큰 아이디어를 현실로 만들도록 돕는 세상"을 목표로 내걸었어요. 코딩 분야에서는 이미 벌어지고 있는 변화지만, 다른 부서로 퍼지는 속도는 더뎠다는 게 오픈AI 내부의 진단이에요.

왜 이렇게까지 매달리나

오래 도는 에이전트일수록 토큰을 더 많이 태우기 때문에 오픈AI 입장에서는 이용자당 수익성이 높아져요. 코딩이 그동안 AI 업계에 돈이 되는 영역이었다지만, 훈련과 연산에 쏟아부은 막대한 투자를 정당화하려면 전문직 업무 전반으로 넓혀야 하는 상황이죠. 그사이 하비(법률), 클레이(영업) 같은 버티컬 특화 경쟁사들은 특정 모델에 얽매이지 않고 그때그때 가장 잘 맞는 AI를 갈아 끼우는 방식으로 같은 고객을 노리고 있어요. a16z의 크리스티안 카탈리니는 자신의 블로그 글에서 "거대 모델 기업들이 시장에서 AI를 확장하는 데 필요한 핵심 보완 자산을 빠르게 확보하지 못하면 가치는 다른 곳으로 흘러간다"고 짚었어요.

안에서는 98%, 밖에서는 1%

오픈AI가 뒷받침한 조사에 따르면 6월 기준 오픈AI 직원의 98%가 코덱스를 쓰고 있었어요. 반면 조직 구독자는 17%, 개인 구독자는 1%도 채 안 됐죠. 이 격차가 오픈AI가 풀어야 할 숙제이자 기회예요.

구분	코덱스 사용률(6월 기준)
오픈AI 직원	98%
조직 구독자	17%
개인 구독자	1% 미만

앰브로시노는 비개발 부서 직원들이 코덱스를 처음 쓰기 시작했을 때 "코드가 뭐냐고 묻고 빈 diff가 있다고 알려주는 식으로 적대적으로 굴었다"고 돌아봤어요. 그래서 지난 2월부터 지금까지 범용적으로 쓸 수 있게 다듬어 왔다는 거예요. 오픈AI는 이 격차를 메우는 잣대로 GDPval이라는 자체 벤치마크를 쓰는데, 44개 직업에 걸친 수백 개 지식노동 과제로 구성돼 있고 여기에 이용자 피드백을 더해 무엇을 다듬을지 정한다고 밝혔어요.

실제로 써보니

테크크런치 기자가 직접 써 본 결과는 엇갈렸어요. 자녀의 이상하게 짜인 유치원 일정표를 이메일에서 꺼내 구글 캘린더로 옮기는 작업은 반복 입력을 덜어줄 만큼 잘 됐고, 공개기업 재무 분석 대시보드나 우주발사 데이터베이스처럼 예전엔 파이썬 스크립트를 짜야 했던 일도 자동으로 처리했어요. 반면 클라우드 드라이브에 "읽기 전용"만 허용하려던 시도는 계속 오류가 났고, 결국 모바일 앱에서 전체 접근권을 줘야만 작동한다는 안내를 받았어요. 구글 캘린더에 일정은 만들 수 있지만 새 캘린더 자체는 만들지 못하는 등 어디까지 되고 안 되는지도 뒤죽박죽이었죠.

기능	현재 상태
구글 캘린더 일정 생성	가능
새 캘린더 생성	불가
읽기 전용 권한 부여	미지원(전체 접근만 가능)
주요 설정 변경	웹 앱에서만 가능

샘 올트먼도 이 도구로 자기 휴가 계획을 짠다는 사실이 눈에 띄는데, 코딩 자동화를 넘어 일상 업무 조율까지 넓히려는 방향과 맞닿아 있어요. 오픈AI 프로덕트 엔지니어링팀을 이끄는 아크샤이 나단은 정보가 넘치는 상황에서 "살펴보고 행동으로 옮기는 능력이 오히려 부족하다"며, 챗GPT의 가치는 이미 갖고 있던 접근권을 "진짜로 쓸 수 있게" 만드는 데 있다고 설명했어요.

경쟁 구도

같은 방향을 겨냥한 제품은 챗GPT 워크만이 아니에요. 클로드 코워크나 퍼플렉시티의 브라우징 에이전트도 이메일·브라우저·SaaS 플랫폼을 하나로 엮어 이용자의 기존 업무 맥락에 접근하는 구조를 취하고 있어요. 그런데 오픈AI 하네스 엔지니어링을 이끄는 조 거센슨은 코덱스와 클로드 코워크의 차이를 묻자 "솔직히 다른 회사가 만드는 하네스는 잘 안 본다"고 답했어요. 코딩용 CLI가 개발자의 작업 방식을 바꿔 놓은 것처럼, 화면 뒤에서 무엇을 볼 수 있고 어떤 도구를 쓸 수 있는지 정하는 "하네스" 설계가 이 경쟁의 핵심 승부처인데도 말이에요.

에디터의 시선

이 격차의 본질은 기술이 아니라 평가 가능성에 있어요. 코드는 돌아가거나 안 돌아가거나 둘 중 하나지만, 좋은 보고서나 영업 전략은 그렇게 딱 떨어지지 않죠. 오픈AI가 코딩 밖으로 나가려는 순간 마주치는 건 "정답이 뭔가"를 정의하기 어려운 세계고, GDPval 같은 벤치마크로 그 틈을 메우려는 시도 자체가 이 회사가 얼마나 절박하게 화이트칼라 시장을 원하는지를 보여줘요.

코딩 에이전트를 실무에 붙여 본 경험이 있는 사람이라면 이 기사의 권한 설정 대목이 낯설지 않을 거예요. 읽기 전용을 원했는데 전체 접근만 되는 상황, 웹에서만 바뀌는 설정값 — 새로운 도구가 대중에게 넘어가는 길목에서는 항상 이런 종류의 마찰이 남아 있어요. 코딩 도구가 처음 나왔을 때도 파워유저는 CLI만으로 충분했지만, 일반 사용자에게 가려면 결국 버튼과 안내 문구가 필요했던 것과 같은 이치죠.

국내에서 에이전트 도입을 검토하는 팀이라면 이 98% 대 1%라는 숫자를 채택 실패의 신호가 아니라 온보딩 설계의 신호로 읽는 게 맞아요. 내부 직원에게는 이미 익숙한 워크플로우를 코덱스가 그대로 흉내 냈지만, 외부 이용자에게는 권한 설정부터 막히는 경험이 첫인상이 됐다는 뜻이니까요. 도구를 도입하기 전에 권한 범위를 먼저 문서화하고, 읽기 전용이 필요한 업무와 전체 접근이 필요한 업무를 구분해 두는 작업이 실제로 시간을 아껴줘요.

앞으로 몇 달 안에는 하네스 설계 자체가 경쟁의 축으로 떠오를 가능성이 커요. 모델 성능 격차가 좁혀질수록, 어떤 화면과 버튼으로 그 성능을 꺼내 쓰게 하느냐가 승부를 가르게 될 거예요.