AI 에이전트의 지식 노동 재편 연구 소개
새 업무를 맡았을 때 우리에게는 두 가지 길이 있습니다. 직접 붙잡고 한 단계씩 해내거나, 할 줄 아는 사람에게 통째로 맡긴 뒤 결과만 검토하거나. How AI Agents Reshape Knowledge Work: Autonomy, Efficiency, and Scope 는 이 선택이 AI 제품 안에서 벌어질 때 무엇이 달라지는지를 Perplexity 의 실제 사용 로그로 측정한 논문입니다. Perplexity 기술 스태프이면서 하버드 경영대학원 AI Institute 겸임 연구자인 Jeremy Yang 을 비롯한 4명이 2026년 6월에 공개했고, 대화형 답변 엔진인 Perplexity Search 와 자율 에이전트인 Perplexity Computer 에 같은 사용자가 사실상 같은 질의를 던진 1만 쌍의 세션 을 자연 실험으로 삼았습니다.
결과를 먼저 말하면 세 가지입니다. 같은 과업에서 Computer 는 세션당 26분의 자율 실행을 수행한 반면 Search 는 33초에 그쳤고, 사람이 Search 로 같은 일을 끝내려면 평균 269분이 필요한데 Computer 에 맡기면 36분으로 줄어 시간은 87\%, 비용은 94\% 감소했습니다. 그리고 저자들이 가장 무겁게 본 발견은 속도가 아니라 범위입니다. 같은 사용자가 Computer 를 쓸 때는 자기 직군 밖의 일, 더 높은 인지 수준의 일, 여러 전문 영역을 동시에 요구하는 일을 훨씬 자주 시도했습니다.
이 게시물에서는 논문이 세운 과업 기반 비용 모델, 1만 쌍 매칭 설계, 자율성과 효율성과 범위의 세 축 실증 결과, 그리고 저자들이 스스로 밝힌 한계를 차례로 정리합니다.
대화형 어시스턴트에서 코파일럿을 거쳐 에이전트로
논문은 먼저 최근 몇 년간 프런티어(frontier) AI 제품이 지나온 경로를 세 단계로 정리합니다. 대화형 어시스턴트 는 맥락도 행동 능력도 제한된 채 고립된 정보 교환을 주로 지원합니다. 코파일럿 은 그 능력을 기존 도구와 작업 흐름 안에 심어, 해당 도구의 인터페이스 안에서 사용자와 함께 일합니다. 에이전트 는 한 발 더 나아가 후단에서 훨씬 넓은 범위의 도구를 연결하고, 사람의 개입을 거의 받지 않은 채 완성된 산출물을 돌려줍니다. AI가 대화 상대에서 작업 실행 엔진으로 옮겨 가는 흐름입니다.
저자들은 이 흐름을 두 개의 축으로 좌표화합니다. 하나는 자율성(Autonomy), 곧 사람의 개입을 최소화한 채 계획하고 실행하는 능력입니다. 다른 하나는 맥락 통합(Context Integration), 곧 사용자의 디지털 환경에서 읽고 쓰는 능력입니다. 여기서 환경이란 브라우저와 파일 시스템, 그리고 외부 서비스 연결까지를 뜻합니다.
이 좌표 위에 세 제품이 놓입니다. 2022년에 나온 Perplexity Search 는 질문에 출처가 달린 답을 돌려주는 답변 엔진으로, 두 축 모두 낮은 자리에 있습니다. 2025년의 Comet Assistant 는 브라우저 안에서 사용자와 함께 일하며 맥락 통합을 크게 끌어올렸습니다. 같은 연구진이 Comet 도입 초기의 사용 양상을 분석한 논문을 2025년에 따로 냈고, 이번 연구는 그 후속에 해당합니다. 2026년 2월에 나온 Perplexity Computer 는 사용자가 결과물만 지정하면 검색과 브라우징, 코드 작성, 문서 생성, 외부 서비스 호출, 하위 에이전트 위임까지 스스로 이어가는 에이전트 오케스트레이션 시스템입니다.
이 구분이 중요한 이유는 실험 설계를 결정하기 때문입니다. Search 와 Computer 는 같은 회사가 같은 사용자 기반에 제공하는 제품이면서 자율성 축에서는 거의 반대편에 있습니다. 논문은 이 점을 이용해 대화형 모드와 에이전트 모드를 같은 조건에서 맞붙입니다.
기존 연구가 답하지 못한 질문
생성형 AI의 생산성 효과를 다룬 실험 연구는 이미 상당히 쌓여 있습니다. 논문이 인용하는 것만 봐도 전문직 453명을 대상으로 한 무작위 실험에서 ChatGPT가 글쓰기 시간을 40\% 줄이고 품질을 18\% 높였고, 고객 지원 상담원 5,172명 연구에서는 시간당 해결 건수가 15\% 늘었으며, BCG 컨설턴트 실험에서는 모델의 역량 경계 안쪽 과업에서 최대 34\% 의 성과 향상이 나타났습니다. 개발자 4,867명을 대상으로 한 세 건의 현장 실험에서는 GitHub Copilot이 완료 과업을 26\% 늘렸습니다.
이 연구들에는 공통점이 있습니다. 사람이 각 단계를 직접 수행하면서 AI가 그 단계를 거들어 주는 상황 을 측정한다는 점입니다. 그래서 경계 밖 과업에서는 오히려 성과가 떨어지는 "울퉁불퉁한 경계(jagged frontier)"가 관찰되고, 숙련된 오픈소스 개발자를 대상으로 한 METR의 무작위 시험에서는 AI 도구를 쓴 쪽이 오히려 19\% 느려지는 반례까지 나옵니다. 상호작용 루프 안에 사람이 계속 남아 있는 한, 이득은 그 사람의 숙련도와 과업 친숙도에 크게 좌우됩니다.
두 번째 계열은 직업 노출도(Occupational Exposure) 연구입니다. 미국 노동인구의 약 80\% 가 자기 업무 중 최소 10\% 를 LLM의 영향권에 두고 있다는 추정이 대표적입니다. 이런 연구는 잠재적 대체 가능성을 그려 주지만, 도구를 실제로 도입한 뒤 업무 구성이 어떻게 바뀌는지는 측정하지 않습니다.
세 번째 계열은 에이전트의 역량 자체를 재는 연구입니다. METR이 제안한 시간 지평(Time Horizon) 지표는 에이전트가 50\% 성공률을 내는 과업의 길이를 측정하는데, 2025년 초 약 1인시(human-hour)에서 2026년 초 약 12인시로 늘었습니다. 다만 이건 무엇을 할 수 있는가에 대한 답이지, 사람들이 실제로 무엇을 맡기고 그래서 일이 어떻게 재구성되는가에 대한 답은 아닙니다.
네 번째 계열이 이 논문과 가장 가깝습니다. 실제 제품에 배포된 에이전트의 사용 로그를 분석한 연구들인데, 대부분 코딩 영역에 몰려 있습니다. Cursor 사용자 약 12만 명을 에이전트 모드 도입 시점 전후로 분석한 연구는 에이전트가 기본값이 된 뒤 기업의 코드 변경 병합이 39\% 늘었고 숙련 개발자의 노력이 코드를 치는 일에서 계획과 감독으로 옮겨 갔다고 보고합니다. Claude Code 의 사람과 에이전트 상호작용 수백만 건을 분석한 연구에서는 자율 실행 턴의 99.9 분위 길이가 2025년 10월 25분 미만에서 2026년 1월 45분 초과로 거의 두 배가 되었고, 숙련 사용자는 세션의 40\% 이상에서 완전 자율을 허용했습니다. 코딩 밖으로 눈을 돌린 연구로는 다섯 개 직군에서 에이전트와 사람의 작업 방식을 나란히 비교한 논문이 있는데, 에이전트가 사람의 UI 중심 방식 대신 프로그램적 경로를 택하면서 88\% 빠르고 90\% 이상 저렴한 결과를 냈지만 품질은 아직 사람에 못 미친다고 보고합니다.
이 계열에서 이 논문을 읽을 때 반드시 함께 봐야 할 결과가 하나 있습니다. GitHub 개발자 10만여 명의 사용 데이터를 세대별 도구에 걸쳐 결합한 연구는 자동 완성이 코딩 활동을 40\%, 대화형 코딩 에이전트가 140\%, 자율 코딩 에이전트가 180\% 끌어올린다고 보고합니다. 그런데 이 과업 수준의 이득은 생산 사슬을 따라 내려가면서 급격히 줄어들어 프로젝트 단위에서는 50\%, 릴리즈 단위에서는 30\% 만 남습니다. 사람이 병목인 지점들이 실제로 출시되는 소프트웨어에 도달하는 양을 제한한다는 뜻입니다. 이 논문이 재는 것도 과업 수준의 이득이므로, 뒤에 나오는 87\% 라는 절감폭을 조직 전체의 산출로 곧장 환산해서는 안 됩니다.
논문의 발상 전환은 여기서 나옵니다. 대화형 제품과 에이전트 제품을 같은 사용자가 같은 기간에 함께 쓰고 있다면, 그 사용자가 두 제품에 거의 똑같은 문장을 던진 순간들을 골라내 과업을 고정한 채 도구만 바꾼 비교를 만들 수 있습니다.
개념 프레임워크: 고정비는 오르고 단계당 비용은 내려간다
실증 분석에 들어가기 전에 논문은 개인 노동자 수준의 과업 기반 모형을 세웁니다. 수식 자체는 단순하지만, 뒤에 나오는 모든 실증 결과가 이 틀 위에서 해석되므로 짚고 갈 가치가 있습니다.
과업을 단계 수로 모델링하기
과업 j 는 완료에 필요한 단계 수(step count) s_j 로 표현됩니다. 한 단계는 조회, 계산, 코드 실행, 종합처럼 더 쪼갤 수 없는 작업 단위입니다. 여기에 네 가지 가정이 붙습니다.
첫째, 단계가 많은 과업일수록 가치가 약하게라도 더 큽니다(v_1 \leq v_2 \leq \cdots \leq v_J ). 둘째, 가치는 모든 단계를 끝냈을 때만 실현됩니다. 절반만 한 과업은 아무 가치도 만들지 않습니다.
셋째와 넷째가 이 모형의 핵심입니다. 에이전트 모드는 대화형 모드보다 과업당 고정비가 높고(f_{\text{Agent}} > f_{\text{Conversational}} ) 단계당 한계비용이 낮습니다(m_{\text{Agent}} < m_{\text{Conversational}} ). 고정비가 높은 이유는 자율 시스템에 일을 맡기려면 목표를 제대로 정의하고 나중에 산출물을 검증해야 하기 때문이고, 한계비용이 낮은 이유는 각 단계의 계획과 실행을 사람이 아니라 시스템이 처리하기 때문입니다. 두 값의 차이를 저자들은 자율성 프리미엄(autonomy premium) 이라 부릅니다.
따라서 과업 j 를 모드 t 로 끝내는 총비용은 다음과 같이 단순한 선형 형태가 됩니다.
여기서 비용은 돈만이 아니라 시간과 노력을 포함한 자원 전체를 뜻합니다.
에이전트가 유리해지는 임계 단계 수
고정비가 높고 기울기가 낮은 직선과, 고정비가 낮고 기울기가 높은 직선은 반드시 한 번 만납니다. 그 교점이 논문의 보조정리 1 입니다.
단계 수가 s^{\ast} 보다 크면 에이전트가, 작으면 대화형이 엄밀하게 유리합니다. 단계당으로는 에이전트가 늘 싸지만, 짧은 과업에서는 위임에 드는 고정비를 상각할 단계가 부족해 손해라는 뜻입니다. 빠른 사실 확인이나 한 번의 개념 설명이 대화형 쪽에 남는 이유가 여기 있고, 이건 결함이 아니라 정렬(sorting)입니다. 사용자는 과업 길이에 따라 두 도구 사이에서 자연스럽게 갈라집니다.
프레임워크가 내놓는 예측
사용자에게 자원 예산 B 가 주어져 있고 어떤 과업을 시도할지 고른다고 하면, 문제는 표준적인 0/1 배낭 문제가 됩니다. 여기서 두 개의 명제가 나옵니다. 명제 1 은 에이전트 접근권이 추가되면 감당 가능한 과업의 경계가 넓어지면서 개인이 손댈 수 있는 최고 가치가 약하게라도 올라간다고 말합니다. 명제 2 는 실현되는 총가치가 약하게 증가한다고 말합니다. 대화형만으로 예산을 이미 다 쓰고 있던 사용자라면 총잉여와 가치 대비 비용 비율까지 함께 올라갑니다.
논문의 결론을 미리 떠받치는 것은 명제 3 입니다. 잉여의 변화량을 세 갈래로 분해할 수 있다는 내용인데, 원래도 하던 과업에서 아낀 비용, 새로 시도하게 된 과업에서 얻은 잉여, 더 이상 시도하지 않게 된 과업에서 잃은 잉여입니다. 이 가운데 첫 항은 언제나 0 이상이고, 나머지 두 항은 새로 시도하거나 그만둔 과업의 순잉여입니다. 에이전트의 가치가 같은 일을 싸게 하는 몫 과 안 하던 일을 하게 되는 몫 으로 갈라진다는 뜻이고, 논문이 뒤에서 속도보다 범위가 중요하다고 말할 때 근거로 삼는 것이 바로 이 분해입니다.
숫자로 보는 4개 과업 예시
추상적인 명제만으로는 감이 잘 오지 않으니, 논문이 부록에 실은 예시를 그대로 따라가 보겠습니다. 단계 수가 각각 1, 2, 3, 10인 과업 네 개가 있고 가치는 20, 50, 70, 200입니다. 비용 파라미터는 대화형이 f = 1, m = 17 이고 에이전트가 f = 18, m = 1 이며, 예산은 B = 87 입니다. 정렬 임계값은 s^{\ast} = (18-1)/(17-1) = 17/16 \approx 1.06 이 됩니다.
| 과업 | 단계 수 | 가치 | 대화형 비용 | 에이전트 비용 | 실제 선택 |
|---|---|---|---|---|---|
| 1 | 1 | 20 | 18 | 19 | 18 (대화형) |
| 2 | 2 | 50 | 35 | 20 | 20 (에이전트) |
| 3 | 3 | 70 | 52 | 21 | 21 (에이전트) |
| 4 | 10 | 200 | 171 | 28 | 28 (에이전트) |
대화형만 쓸 수 있을 때는 과업 4의 비용이 171이라 예산 87로는 아예 손댈 수 없고, 과업 1, 2, 3을 모두 하려면 105가 들어 예산을 넘깁니다. 그래서 최적 선택은 과업 2와 3만 하는 것이고 비용 87에 가치 120, 잉여 33이 남습니다.
에이전트가 더해지면 그림이 달라집니다. 과업 2와 3의 비용이 87에서 41로 내려가면서 46만큼의 예산이 풀리고, 그 여유가 정확히 과업 1(18)과 과업 4(28)를 채웁니다. 네 과업을 모두 하고도 총비용은 여전히 87로 예산에 딱 맞습니다. 가치는 340, 잉여는 253이 됩니다. 명제 3의 분해로 보면 잉여 증가분 220 가운데 46은 원래 하던 과업 2와 3에서 아낀 비용이고, 174는 새로 시도하게 된 과업 1과 4에서 나온 것입니다. 이득의 대부분이 절감이 아니라 진입에서 왔다는 점 이 이 예시의 핵심입니다.
눈여겨볼 지점이 하나 더 있습니다. 가장 짧은 과업 1은 에이전트가 쓸 수 있는 상황에서도 대화형에 남습니다. 비용이 18 대 19로 대화형이 여전히 싸기 때문이고, 단계 수 1이 임계값 1.06 보다 작다는 보조정리 1의 예측과 정확히 맞아떨어집니다.
문제는 과업의 가치 v_j 가 로그 데이터에 관측되지 않는다는 점입니다. 그래서 저자들은 가치와 잉여에 대한 명제는 직접 검증하지 않고, 관측 가능한 비용 과 범위 로 우회합니다. 7절이 비용 구조 가정과 비용 절감을, 8절이 낮아진 비용이 실제로 더 복잡한 일을 끌어냈는지를 검증하는 구조입니다.
자연 실험 설계: 같은 사용자, 같은 질의, 다른 제품
Computer 와 Search 를 그냥 비교하면 곧바로 내생성 문제에 부딪힙니다. 보조정리 1이 예측한 대로 사용자가 애초에 서로 다른 종류의 질의를 두 제품에 나눠 보내기 때문입니다. 짧은 조회는 Search 로, 긴 작업은 Computer 로 가는 상황에서 두 제품의 평균을 비교하면 도구의 효과가 아니라 과업 선택의 차이를 재게 됩니다.
논문의 해법은 사용자가 스스로 만들어 낸 자연 실험 을 찾아내는 것입니다. 절차는 다음과 같습니다.
- 2026년 2월 27일부터 5월 27일까지 두 제품 모두에 세션 첫 메시지를 보낸 적이 있는 사용자 10만 명을 뽑습니다.
- Computer 쪽은 실행 도구를 한 번이라도 호출한 세션만 남깁니다. 논문은 이를 "do" 도구 라 부르는데, 터미널 명령(
bash), 파일 생성(write), 코드 실행(js_repl), 브라우저 조작, 외부 커넥터 호출처럼 정보 검색을 넘어 실제로 무언가를 실행하는 도구들입니다. 이 게이트를 통과하지 못한 질의는 기능적으로 Search 와 다를 바 없으므로 제외됩니다. - 각 사용자의 Computer 질의 전부와 최근 Search 질의 최대 100건을 임베딩(embedding)으로 바꿔 사용자 내부에서 코사인 유사도를 계산합니다.
- 일대일 탐욕적 매칭으로 유사도 0.99 를 넘는 쌍만 남기고, 여기서 1만 쌍을 무작위 추출합니다.
유사도 기준을 0.99 로 높게 잡은 것은 공백이나 줄바꿈 같은 사소한 차이만 허용하겠다는 뜻입니다. 결과적으로 각 쌍은 사실상 동일한 과업을 두 제품으로 시도한 기록이 되고, 사용자와 과업 내용이 동시에 고정됩니다. 여기에 후속 턴 분석용으로 양쪽 모두 2턴 이상인 1,000쌍의 부분 표본이 추가로 쓰입니다.
프라이버시 측면에서는 원문 질의가 사람 분석자에게 노출되지 않도록 처리했고, 모든 결과는 고도로 집계된 형태로만 보고한다고 명시되어 있습니다.
3개월간의 도입 추이와 사용 사례
본격적인 비교에 들어가기 전에, 이 데이터가 어떤 상황에서 만들어졌는지 짚어 둘 필요가 있습니다. 관측 창 3개월 동안 Computer 의 누적 질의는 첫 주 대비 84\times 로 늘었습니다. 같은 기간 Search 의 누적 질의는 Computer 사용자에게서 14\times, Computer 를 쓰지 않은 사용자에게서 12\times 증가했습니다.
Search 가 Computer 사용자 쪽에서 더 빨리 자란 것을 두고는 두 가지 상반된 해석이 가능합니다. 긴 과업이 Computer 로 넘어가면서 Search 사용이 줄어드는 대체 효과가 있는 반면, Computer 가 예산을 덜어 준 덕분에 Search 가 더 싼 짧은 과업을 추가로 시도하게 되는 보완 효과도 있습니다. 앞의 4개 과업 예시에서 과업 1이 에이전트가 생긴 뒤에도 대화형에 남았을 뿐 아니라 새로 시도 가능해진 것과 같은 구조입니다.
저자들은 어느 쪽이 이겼는지를 직접 추정했습니다. 구독 등급, 주 검색 주제 20개 범주, 도입 이전 Search 사용 강도 사분위로 정확히 매칭해 Computer 도입자 61,913명과 비슷한 규모의 비도입자를 짝지은 뒤, 104일치 일별 패널에 이중차분을 돌렸습니다. 결과는 Computer 도입이 일평균 Search 질의를 1.05건 늘리는 것으로 나왔고, Computer 질의가 하루에 하나 늘 때마다 Search 질의가 0.019건 늘어나는 집약적 효과도 유의하게 확인됐습니다. 도입 시점이 엇갈리는 데서 오는 편의를 걱정해 누적 이중차분과 코호트별 추정으로도 확인했지만 계수는 1.05에서 1.12 사이로 안정적이었고, 20개 주제 범주 전부에서 부호가 양수였습니다. 두 제품이 서로를 잡아먹는 관계가 아니라는 뜻입니다.
무엇에 쓰이는지는 무작위 추출한 Computer 질의 10만 건을 과업 범주와 주제 영역 두 축으로 분류해 파악했습니다. 과업 범주에서는 조사 및 분석이 25.8\% 로 가장 많고 문서 및 산출물 제작이 18.6\% 로 뒤를 잇습니다. 기능 탐색에 해당하는 범주는 5.3\% 에서 6.0\% 를 차지하는데 시간이 갈수록 줄어들고 있습니다. 사용자들이 이것저것 눌러 보는 단계에서 실제 업무로 넘어가고 있다는 신호입니다. 주제 영역은 소프트웨어 및 IT(13.8\% ), 금융 및 투자(10.8\% ), 마케팅 및 영업(7.6\% ), 일반 경영(7.0\% ), 보건 및 생명과학(6.8\% ), 교육 및 학계(5.9\% ), 법무 및 컴플라이언스(5.5\% ), 미디어 및 크리에이티브(5.1\% ) 순으로 지식 노동 전반에 고르게 퍼져 있습니다.
자율성: 세션당 26분 대 33초
첫 번째 실증 축은 기계가 사람의 턴과 턴 사이에서 얼마나 많은 일을 하는가입니다.
실행 시간
Computer 는 사용자의 제출 시각부터 해당 턴의 마지막 응답이 끝날 때까지의 실제 경과 시간을 턴별로 합산하고 세션당 3시간에서 잘라 이상치의 영향을 줄였습니다. 상한에 걸리는 세션은 전체의 5\% 미만입니다. Search 는 질의 수신부터 마지막 토큰까지의 종단 지연을 같은 방식으로 합산했습니다.
여기서 한 가지 주의할 점이 있습니다. Computer 는 여러 작업을 병렬로 실행하는 경우가 많아서, 벽시계 기준 경과 시간은 사용자가 체감하는 대기 시간을 반영할 뿐 기계가 실제로 수행한 총 작업량은 오히려 과소평가합니다. 아래 숫자들은 그런 의미에서 보수적인 값입니다.
매칭된 쌍 전체를 평균하면 Computer 세션은 26분, Search 세션은 33초의 기계 실행 시간을 씁니다. 비율로는 48\times 입니다. 한 세션에 담긴 질의 수가 Computer 5.3건, Search 2.8건이므로 질의 단위로 환산해도 25\times 차이가 납니다. 분포로 보면 두 제품은 거의 겹치지 않습니다. Search 는 10초에서 30초 사이에 좁게 몰려 있고, Computer 는 5분에서 한 시간 남짓까지 넓게 퍼져 있습니다. 중앙값은 9분 대 14초로 40\times 입니다.
위 그림을 통해 도메인마다 격차가 꽤 다르다는 점을 알아볼 수 있습니다. Local 이 75\times 로 가장 크고 Politics 67\times, Finance 64\times, Business 60\times 가 뒤를 잇습니다. 반대로 Science 는 26\times, Education 은 27\times 로 가장 작은데, 이 영역에서는 개념 설명 같은 흔한 과업을 Search 의 한 번 응답이 이미 충분히 해결해 주기 때문입니다. 물량이 가장 많은 두 범주인 Technology 와 Business 는 각각 58\times 와 60\times 로, Computer 가 27분과 31분을 쓰는 동안 Search 는 28초와 31초를 씁니다.
일시정지, 중단, 그리고 커넥터 호출
자율성이 높아지면 시스템이 스스로 멈춰 서서 사람에게 물어보는 일도 늘어납니다. 질의 수준에서 Computer 질의의 13\% 가 사용자 확인용 일시정지 도구를 최소 한 번 호출했고 Search 는 0.3\% 였습니다. 세션 수준에서는 38\% 대 0.8\% 로 벌어집니다. 일시정지의 내역은 승인 요청이 세션의 24.2\% 로 가장 많고, 열린 형태의 확인 질문 16.9\%, 구조화된 입력 요청 2.3\%, 파일 업로드 대기 0.7\% 순입니다.
흥미로운 건 사용자가 먼저 중단시키는 비율입니다. Computer 세션의 3.7\%, Search 세션의 3.4\% 에서 사용자 중단이 발생해 사실상 차이가 없었습니다. 실행 시간이 수십 배 긴데도 도중에 끊고 나가는 비율이 늘지 않았다는 것은, 일단 시작된 자율 실행이 끝까지 가도록 대체로 신뢰받고 있다는 뜻입니다.
맥락 통합의 지표인 커넥터 호출에서도 격차가 큽니다. MCP(Model Context Protocol)나 API 엔드포인트로 외부 도구를 호출한 세션이 Computer 는 7.9\%, Search 는 1.8\% 로 4\times 차이입니다. 세션당 평균 호출 수는 1.19건 대 0.10건으로 12\times 이고, 커넥터를 실제로 쓴 세션만 보면 15.0건 대 5.5건입니다. 한쪽이라도 커넥터를 쓴 914쌍 중 80\% 인 735쌍에서는 Computer 만 커넥터를 사용했습니다. Finance 도메인이 23\% 대 1.2\% 로 가장 극단적입니다.
후속 턴의 성격이 바뀐다
사람이 어떤 이유로 다시 말을 거는지가 달라졌는지 보기 위해, 저자들은 1,000쌍의 다중 턴 세션에서 후속 질의 15,507건을 10개 범주 분류체계로 나눴습니다.
| 범주 | Search (%) | Computer (%) | 차이 (pp) |
|---|---|---|---|
| 심화 질문(drill-down) | 23.4 | 22.0 | -1.4 |
| 새 하위 과업 | 17.0 | 16.5 | -0.5 |
| 확장(extension) | 12.5 | 14.2 | +1.7 |
| 과업 진전 소계 | 52.9 | 52.7 | -0.2 |
| 수정(revision) | 13.9 | 14.1 | +0.2 |
| 검증(verification) | 9.7 | 10.5 | +0.8 |
| 산출물 검토 소계 | 23.6 | 24.6 | +1.0 |
| 데이터 입력 | 8.4 | 8.5 | +0.1 |
| 확인 | 6.8 | 6.5 | -0.3 |
| 형식 및 전달 요청 | 3.4 | 2.7 | -0.7 |
| 재시도 | 1.4 | 0.7 | -0.7 |
| 짧은 지시 소계 | 11.6 | 9.9 | -1.7 |
위 표를 통해 3가지를 알아볼 수 있습니다. 첫째, 일을 앞으로 밀고 나가려는 후속 턴의 총량은 두 제품이 거의 같습니다(52.7\% 대 52.9\% ). 달라지는 건 그 안의 구성입니다. Computer 쪽에서는 심화 질문이 줄고 확장이 늘었습니다. 논문은 두 범주의 차이를 이렇게 구분합니다. 심화 질문은 이미 나온 산출물에 대한 정보 요청("왜 이걸 골랐나요?")이라 사용자를 해명 루프 안에 붙잡아 두는 반면, 확장은 전달된 산출물 위에 새 구성요소를 얹으라는 요청("이제 X도 추가해 주세요")이라 결과물을 한 단계 더 밀어냅니다.
둘째, 검토와 수정이 조금 늘었습니다(24.6\% 대 23.6\% ). 셋째, 확인이나 형식 지정, 재시도 같은 짧은 지시는 Search 쪽이 더 많습니다(11.6\% 대 9.9\% ). Computer 는 그런 지시를 첫 실행 안에 흡수해 버리기 때문입니다. 수동 데이터 입력이 8.5\% 대 8.4\% 로 거의 같다는 점은 매칭 설계가 과업 내용을 제대로 고정했다는 방증이기도 합니다.
정리하면 사람이 다시 말을 거는 이유가 바뀌었습니다. Search 에서는 받아 읽고 다음 단계를 지시하는 짧은 루프가 반복되고, Computer 에서는 완성된 산출물을 검토하고 확장하는 긴 루프가 돕니다.
자율성이 품질을 깎지는 않았다
자율성이 올라가면 품질이 희생될 수 있습니다. 사람이 중간에 개입하지 않은 결과물이 더 자주 틀릴 수 있기 때문입니다. 저자들은 사용자가 다음 턴에서 하는 행동(재질문, 수정 요구, 오류 보고, 재시도 등)을 근거로 각 응답의 불만족도를 네 단계로 채점했습니다. 다음 턴이 있어야 채점이 가능하므로 이 지표는 다중 턴 세션에만 적용됩니다.
결과는 반대 방향이었습니다. 중간 이상의 불만족을 유발한 질의 비율이 Computer 는 1.3\%, Search 는 2.9\% 로 55\% 낮았고, 낮은 수준까지 포함한 전체 불만족 비율도 10.8\% 대 16.6\% 였습니다. 자율성과 응답 품질이 동시에 올라간 셈입니다.
효율성: 269분에서 36분으로
두 번째 축은 사람의 시간과 비용입니다. 여기서 비교되는 것은 두 가지 작업 방식입니다. Search + 사람 은 Search 가 정보 검색과 정리를 맡고 나머지 실행은 사람이 직접 하는 방식이고, Computer + 사람 은 모델이 전체 워크플로를 실행하고 사람은 감독만 하는 방식입니다.
세 갈래로 추정한 사람의 시간
현장 데이터에서 사람이 쓴 시간을 재는 것은 어려운 일이라, 저자들은 서로 독립적인 세 가지 방법으로 삼각 측량합니다.
도구 기반 추정 은 Computer 의 도구 호출을 두 부류로 나눕니다. search_web, fetch_url, navigate, read 처럼 Search 가 이미 제공하는 기능에 해당하는 도구는 사람의 시간을 0으로 계산합니다. 반대로 "do" 도구는 Search 사용자라면 직접 해야 했을 작업이므로, 숙련된 전문가가 손으로 했을 때 걸릴 시간을 호출별로 매겨 합산합니다. 도구 기반 추정의 결과는 사실상 이 환산값과 도구 호출 횟수만으로 정해지므로, 논문에 실린 값을 그대로 옮깁니다.
| "do" 도구 | 사람이 직접 한다면 | 호출당 분 |
|---|---|---|
write |
파일을 새로 작성 | 15 |
js_repl |
코드 조각을 작성하고 실행 | 15 |
edit |
기존 파일에서 위치를 찾아 수정 | 10 |
browser_task |
여러 단계의 브라우저 작업 완수 | 10 |
bash |
터미널 명령 실행 | 5 |
call_external_tool |
API 호출(인증, 요청, 파싱) | 5 |
deploy_website |
코드를 호스트나 서버에 배포 | 5 |
start_server |
로컬 개발 서버나 서비스 기동 | 5 |
find |
프로젝트에서 파일이나 문자열 찾기 | 3 |
system_diagnostic |
시스템 상태 점검, 로그 확인 | 3 |
share_file |
파일을 내보내 전달 | 2 |
computer (브라우저) |
웹 애플리케이션에서 클릭하고 입력 | 0.5 |
Computer 쪽 사람 시간은 프롬프트 작성과 산출물 검토를 합쳐 과업당 10분으로 고정했습니다. 비용은 모델 비용에 미국 노동통계국의 직종별 고용 및 임금 통계(BLS OEWS) 2025년 5월 기준 평균 시급을 18개 도메인에 매핑해 더했습니다. 시급은 법률이 시간당 67달러로 가장 높고 소프트웨어 및 IT 58달러, 보건 52달러, 경영과 금융이 각각 46달러이며, 교육 32달러를 거쳐 부동산과 여행 및 소비재 계열이 25달러로 가장 낮습니다.
개발자라면 위 표에서 곧바로 의문이 드는 값이 있을 겁니다. 파일 하나 쓰는 데 15분, 코드 조각 하나 실행하는 데 15분은 작은 작업 기준으로는 후한 값입니다. 이 환산이 조금만 커도 Search + 사람 쪽 시간이 통째로 부풀기 때문에, 도구 기반 추정의 신뢰도는 사실상 이 표에 달려 있습니다. 논문이 뒤에서 손익분기와 민감도 분석에 지면을 크게 쓰는 이유이고, 질의 텍스트만 보고 독립적으로 추정한 LLM 방식이 비슷한 크기의 값을 내놓는지 확인하는 이유이기도 합니다.
LLM 기반 추정 은 도구 매핑에 깔린 두 가지 가정, 곧 호출별 사람 시간 환산이 정확하다는 가정과 사람이 Computer 와 같은 절차를 밟는다는 가정을 검증하기 위한 독립 장치입니다. 1만 쌍 각각에 대해 질의 텍스트만 주고 Search + 사람 반사실을 설명한 뒤 총 소요 시간을 추정하게 했습니다.
사용자 자기 보고 는 누적 질의가 5건 이상인 활성 Computer 사용자 25명(기업 6명, 개인 19명)과 진행한 45분짜리 반구조화 인터뷰입니다. 참가자들은 구체적인 완료 과업을 짚으면서 Computer 도입 전의 작업 흐름과 그 흐름에 걸렸을 시간을 추정했습니다. 회상 편향과 선택 편향이 있지만, 앞의 두 방법과 달리 Search + 사람이라는 고정된 반사실이 아니라 사용자가 실제로 택했을 대안을 반영한다는 장점이 있습니다.
도메인별 시간과 비용
도구 기반 추정에서 Search + 사람 방식의 평균 과업 시간은 도메인에 따라 121분에서 596분 사이, 전체 평균 269분이었습니다. Computer + 사람은 25분에서 48분 사이, 전체 평균 36분입니다. 시간 절감은 79\% 에서 92\% 사이(전체 87\% ), 비용 절감은 87\% 에서 96\% 사이(전체 94\% )입니다. 배수로 환산하면 전체 기준으로 시간은 7.4\times, 비용은 16\times 가 됩니다.
절감폭은 손이 많이 가는 도메인일수록 큽니다. Programming 은 596분이 48분으로 줄어 92\% 를 아꼈고, Technology 는 280분에서 37분(87\% ), Social Media 는 224분에서 34분(85\% )이었습니다. 비용 절감이 시간 절감보다 큰 이유는 도메인별 임금이 효과를 증폭하기 때문입니다. 시급이 58 달러인 Programming 에서는 92\% 의 시간 절감이 96\% 의 비용 절감으로 이어집니다.
모델 비용을 따로 떼어 보면 구조가 분명해집니다. Computer 의 과업당 모델 비용은 2 달러에서 13 달러로 Search 의 0.05 달러보다 훨씬 비쌉니다. 그런데 Search + 사람 총비용에서 모델 비용이 차지하는 비중은 0.1\% 에도 미치지 못하는 반면 Computer + 사람에서는 31\% 에서 59\% 를 차지합니다. 값비싼 사람의 실행 시간이 상대적으로 싼 기계 연산으로 옮겨 간 결과이고, 이 대체가 비용 우위의 원천입니다.
손익분기점과 민감도 분석
이 추정이 얼마나 견고한지 확인하기 위해 저자들은 반대 방향의 질문을 던집니다. Search + 사람이 Computer + 사람의 총비용을 따라잡으려면 사람이 실행 단계를 얼마나 빨리 해치워야 할까요. 두 비용을 같게 놓고 풀면 손익분기 임계값은 도메인별로 14분에서 24분, 중앙값 18분입니다. 다시 말해 전문가가 모든 명령을 실행하고 파일을 편집하고 웹 애플리케이션을 조작하는 일을 통틀어 20분 안에 끝내야 본전이라는 뜻입니다.
민감도 분석은 두 가지 가정을 반대 방향으로 흔들어 봅니다. 첫째, 호출별 사람 시간 환산이 16\times 과대평가되어 있더라도 Computer + 사람은 평균적으로 비용 우위를 유지합니다. 가장 먼저 우위가 사라지는 Travel 도메인에서도 8\times 까지 버팁니다. 둘째, 10분으로 고정한 감독 시간을 26\times 부풀려 260분으로 잡아야 비로소 평균적인 비용 우위가 사라지고, 가장 빡빡한 Consumer Goods 에서는 12\times 가 경계입니다. 시간 우위는 비용 우위보다 여유가 적어 각각 7\times 와 24\times 에서 무너지며, 두 경우 모두 Consumer Goods 가 가장 먼저 경계에 닿습니다(5\times 와 11\times ).
LLM 기반 추정도 같은 방향을 가리켰습니다. 시간 절감 79\% 에서 88\% (전체 84\%, 배수로는 6.3\times ), 비용 절감 88\% 에서 94\% (전체 93\%, 13\times )입니다. 과업당 평균 사람 시간은 도구 기반이 269분, LLM 기반이 227분으로 규모가 비슷합니다. LLM 추정치에는 계획 수립이나 Search 응답을 소화하는 시간처럼 도구 매핑이 잡아내지 못하는 비용이 포함되어 있어, 두 방법이 서로의 사각지대를 메워 줍니다. 인터뷰에서 정량 비교를 제시한 참가자들의 자기 보고 속도 향상은 5\times 에서 300\times 이상까지 흩어졌고 참가자별 중앙값은 약 25\times 였습니다. 편차가 큰 것은 Computer 도입 전 기준선이 사람마다 크게 달랐기 때문으로 보입니다.
프레임워크 가정의 검증
효율성 절의 마지막에서 저자들은 3절의 가정으로 돌아갑니다. 단계 수 s 는 Computer 의 총 도구 호출 수로 대리하고, 고정비는 세션 전체의 질의 문자 수로 대리합니다.
고정비 쪽 결과는 가정대로였습니다. 매칭된 쌍 안에서 Computer 세션의 질의는 중앙값 기준 652자로 Search 의 448자보다 46\% 깁니다. 워크플로를 통째로 위임하려면 한 번의 질문을 던질 때보다 앞단에서 범위를 더 많이 규정해야 한다는 뜻입니다. 다만 논문은 이 대리 변수가 Computer 산출물의 검증 비용을 포함하지 못하므로 고정비가 과소평가되었을 수 있다고 스스로 짚습니다.
한계비용 쪽도 가정과 맞았습니다. 총 변동비를 총 도구 호출 수로 나누면 Computer + 사람은 단계당 0.16 달러, Search + 사람은 2.05 달러로 13\times 차이입니다. 시간으로 환산해도 단계당 0.46분 대 2.66분으로 6\times 입니다.
마지막으로 격차가 과업 복잡도에 따라 어떻게 커지는지도 회귀로 확인했습니다. 도구 호출이 하나 늘 때마다 시간 격차는 2.39분, 비용 격차는 1.94 달러씩 벌어집니다. 격차가 s 에 대해 단조 증가한다는 것은 보조정리 1의 정렬 임계값 s^{\ast} 를 만들어 내는 메커니즘이 데이터에서도 그대로 작동한다는 의미입니다.
범위: 수평 확장과 수직 확장
여기까지가 같은 과업을 두 도구로 처리했을 때의 비교였다면, 이제부터는 사용자가 애초에 어떤 일을 시도하는가 가 달라졌는지를 봅니다. 논문에서 가장 흥미로운 부분이기도 합니다.
수평 확장: 직군 경계를 넘는 작업
먼저 각 사용자의 주 직군을 Computer 도입 이전의 Search 사용 이력으로 추정합니다. O*NET이 쓰는 국가 직업군 체계를 바탕으로 디지털 기술, 금융, 보건 및 사회 서비스, 교육, 공공 서비스 및 안전, 경영 및 창업, 마케팅 및 영업, 예술 및 디자인의 8개 군집을 두고, 가장 자주 조회한 도메인이 속한 군집을 그 사용자의 직군으로 잡았습니다. 두 제품을 모두 활발히 쓰는 사용자 중 군집당 1,000명씩, 총 8,000명이 표본입니다.
결과를 보면 같은 사람이 Computer 를 쓸 때 자기 직군 밖의 일을 더 자주 시도합니다. 8개 군집 평균으로 직군 외 과업 비중이 Computer 는 59\%, Search 는 50\% 로 9%p 차이입니다. 격차는 경영 및 창업(+19%p), 디지털 기술(+13%p), 예술 및 디자인(+12%p), 보건(+10%p)에서 크고, 공공 서비스(+2%p)와 금융(+1%p)에서는 거의 없습니다.
목적지의 분포도 다릅니다. 위 그림에서 Search 쪽(왼쪽)은 디지털 기술 열이 사실상 모든 행의 최다 목적지로 나타나는 반면, Computer 쪽(오른쪽)은 대각선이 전반적으로 옅어지고 비대각 성분이 여러 군집으로 흩어집니다. 저자들의 해석은 이렇습니다. Search 의 직군 외 질의는 어디서나 필요한 기술적 사실을 조회하는 것이고, Computer 의 직군 외 질의는 원래 다른 분야 전문가가 필요했을 작업 자체를 위임하는 것입니다. 디지털 기술은 Computer 쪽에서도 네 개 군집(경영 17\%, 금융 15\%, 마케팅 13\%, 예술 및 디자인 13\% )의 최다 목적지로 남아 있지만 끌어당기는 힘이 눈에 띄게 약해집니다. 경영 군집 사용자는 공공 서비스와 금융에도 각각 14\% 씩 보내 디지털 기술로 보내는 양과 큰 차이가 없고, 디지털 기술 군집 사용자는 반대로 금융(12\% ), 교육(10\% ), 공공 서비스(10\% ) 쪽으로 일을 내보냅니다. 보건과 교육은 양방향으로 12\% 씩 작업을 주고받습니다.
수직 확장: 인지 복잡도
과업이 더 어려워졌는지도 봅니다. 표본은 두 제품을 모두 쓰는 사용자 5,000명에게서 Computer 질의와 Search 질의를 한 건씩 뽑은 1만 건입니다. 사용자 안에서 짝을 맞춘 비교라 개인차가 통제됩니다.
첫 번째 잣대는 Bloom의 개정 분류체계(Bloom's Revised Taxonomy)입니다. 기억, 이해, 적용을 하위 인지로, 분석, 평가, 창조를 상위 인지로 묶습니다.
상위 인지를 요구하는 질의가 Computer 는 76\%, Search 는 55\% 로 21%p 차이입니다. 차이는 맨 위 칸에 몰려 있습니다. 창조(Create) 수준, 곧 코드나 보고서나 디자인 같은 새 산출물을 만들어 내는 질의가 Computer 에서는 50\% 인데 Search 에서는 26\% 입니다. 반대로 단순 사실 조회에 해당하는 기억 수준은 Search 가 21\%, Computer 가 7\% 입니다. 비정형 인지 노동을 뜻하는 추상 과업 비중도 71\% 대 53\% 로 갈립니다.
주목할 만한 건 상승이 균일하지 않다는 점입니다. 중간 단계인 분석과 평가는 두 제품이 엇비슷합니다. 사용자가 같은 의도를 그저 더 야심차게 표현한 것이라면 전 구간이 고르게 올라갔어야 하는데, 실제로는 생성적 작업 한 칸만 크게 부풀었습니다. 자율 실행이 특별히 열어 주는 것은 질문의 난이도가 아니라 만들어 내는 일 이라는 해석이 여기서 나옵니다.
수직 확장: 지식의 폭
두 번째 잣대는 하나의 질의를 제대로 해내는 데 실질적 전문성이 필요한 O*NET 지식 영역의 개수입니다. O*NET은 미국 노동부가 관리하는 직업 정보 체계로 33개의 지식 영역을 정의합니다. 분류기에는 최소 집합을 돌려주도록 지시했습니다. 주제가 스쳐 지나가기만 해서는 안 되고 그 영역의 실제 지식이 있어야 일을 잘 해낼 수 있을 때만 세라는 뜻입니다. 예를 들어 2008년 금융위기를 묻는 단순 조회는 경제학 전문성을 요구하지 않지만, 어떤 기업의 10-K를 분석해 회계상 이상 징후를 짚어 달라는 요청은 요구합니다.
Computer 질의는 평균 2.40개 영역을, Search 질의는 1.74개를 요구해 38\% 차이입니다. 분포의 모양도 다릅니다. Search 는 1개에서 2개 영역에 77\% 가 몰려 있는 반면 Computer 는 2개에서 3개에 76\% 가 몰려 있고, 3개 이상을 요구하는 비율은 51\% 대 17\% 로 거의 세 배입니다. 이런 다중 역량 질의는 에이전트 이전이라면 여러 전문가의 협업이 필요했을 종류의 일입니다. 재무 모델을 위한 데이터 시각화 대시보드를 만드는 작업이라면 디자인과 수학, 경제 및 회계가 동시에 필요한 식입니다.
어떤 영역이 늘었는지도 방향이 뚜렷합니다. Computer 쪽에서 크게 오른 것은 디자인(+12%p), 수학(+9%p), 관리 및 경영(+9%p), 컴퓨터 및 전자(+7%p), 경제 및 회계(+6%p)처럼 무언가를 만들어 내는 일과 붙은 영역입니다. 반대로 Search 가 상대적으로 강한 영역은 식품 생산, 사회학 및 인류학, 기계, 의학, 외국어처럼 사람들이 실행보다 사실 확인을 하는 쪽입니다.
수직 확장: 과업 결합성
세 번째 잣대는 질의 하나가 몇 개의 구별되는 업무 활동으로 분해되는가입니다. O*NET 활동 위계의 네 단계를 씁니다. 가장 넓은 37개의 일반 업무 활동(GWA), 332개의 중간 업무 활동(IWA), 2,087개의 세부 업무 활동(DWA), 그리고 18,796개의 직업별 과업 기술문(TS)입니다. 상위 항목에서 하위 항목을 기계적으로 펼쳐 개수를 부풀리지 않도록, 각 단계는 상위에서 선택된 후보 안에서만 분류하게 했습니다.
| O*NET 단계 | Search | Computer | 격차 |
|---|---|---|---|
| 일반 업무 활동(GWA) | 2.24 | 2.95 | +32\% |
| 중간 업무 활동(IWA) | 2.87 | 4.01 | +40\% |
| 세부 업무 활동(DWA) | 2.29 | 3.64 | +59\% |
| 과업 기술문(TS) | 2.38 | 3.81 | +60\% |
위 표에서 격차가 아래로 갈수록 커진다는 점이 눈에 띕니다. 거친 단계에서는 32\% 차이지만 가장 세밀한 단계에서는 60\% 까지 벌어집니다. 저자들은 이를 Computer 의 차별성이 주제의 폭이 아니라 세밀한 실행 작업 에 있다는 신호로 읽습니다.
구성을 뜯어 보면 같은 대비가 반복됩니다. GWA 수준에서 "정보 획득"은 두 제품이 사실상 같지만(58\% 대 56\% ), Computer 의 증가분은 "정보 문서화 및 기록"(+30%p), "창의적 사고"(+24%p), "데이터 및 정보 분석"(+14%p)처럼 산출 지향적인 묶음에 몰립니다. IWA 수준에서도 "물리적 또는 전자적 출처에서 정보 수집"은 양쪽 모두 최다 활동이지만, Computer 의 증가분은 "시각 디자인 또는 전시물 제작"(+18%p), "안내 또는 교육 자료 준비"(+16%p), "운영 또는 절차 활동 보고서 준비"(+13%p)에 집중됩니다.
부록의 상위 활동 표를 보면 반대 방향도 눈에 띕니다. Search 가 오히려 앞서는 범주가 있습니다. GWA 수준의 "조직 외부 인원과의 소통"은 Search 가 17.5\% 인데 Computer 는 11.4\% 이고, "타인에게 자문과 조언 제공"도 11.9\% 대 6.5\% 로 Search 쪽이 높습니다. IWA 수준의 "대중에게 정보나 도움 제공"도 마찬가지입니다(12.7\% 대 9.1\% ). 정보 대 실행이라는 이분법보다 한 겹 더 들어간 그림인데, 사람들은 무언가를 만들어야 할 때 에이전트로 가고 판단을 구하거나 조언을 얻어야 할 때는 대화형에 남습니다. 논문 본문이 강조하지 않는 대목이지만, 두 제품을 함께 쓰는 이유를 설명해 주고 앞서 본 상보성 결과와도 앞뒤가 맞습니다.
수직 확장: 새로 열린 과업
마지막 잣대가 명제 1을 가장 직접적으로 겨냥합니다. 각 제품의 활동 목록을 집합으로 놓고, Computer 질의에는 k 회를 초과해 나타나지만 같은 사용자의 Search 질의에는 k 회 이하로만 나타나는 활동을 Computer 전용 집합 으로 정의합니다. k=0 은 Search 에서 단 한 번도 시도되지 않은 활동을 뜻합니다.
가장 엄격한 기준에서 과업 기술문을 하나 이상 건드리는 Computer 질의의 23\% 가 Computer 전용 과업 기술문을 포함합니다. 세부 업무 활동에서는 5\%, 중간 업무 활동에서는 1\% 미만, 일반 업무 활동에서는 사실상 0입니다. Search 허용 빈도를 k=5 로 풀면 각각 38\%, 18\%, 2\% 로 올라가고 과업 기술문 곡선은 k=7 부근에서 41\% 언저리에 안착합니다.
이 모양이 말하는 바는 분명합니다. 거친 단계에서 두 제품은 거의 같은 주제 영역을 덮고 있습니다. 사용자가 갑자기 새로운 분야에 관심을 갖게 된 것이 아니라는 뜻입니다. 차이는 세밀한 실행 단계에서만 벌어집니다. Computer 전용 집합이 몰리는 곳은 세 무리입니다. 소프트웨어 및 웹 개발("사내외 웹사이트 개발 또는 유지보수"), 문서 생산("사용자 지침, 절차서, 매뉴얼 작성 또는 개정"), 데이터 시각화 및 그래픽("분석 결과를 설명하고 해석하는 보고서, 차트, 그래프 편집")입니다. 모두 도구를 실제로 써서 산출물을 내놓아야 완성되는 종류의 일입니다.
부록의 상위 과업 기술문 표가 이 대비를 숫자로 확인해 줍니다. 두 제품 모두 가장 흔한 과업 기술문은 "데이터베이스나 저장소 등 전자적 출처에서 정보 검색"으로 Computer 16.5\%, Search 10.2\% 이고, 상위권에는 양쪽이 거의 같은 항목도 여럿 있습니다. 반면 "데이터 분석 결과를 전달하기 위한 그래프, 차트, 시각화 제작"은 4.6\% 대 0.5\%, "통계 분석 결과를 그래프나 차트 형태로 보고"는 4.5\% 대 0.5\% 로 아홉 배 가까이 벌어집니다. 차이가 상위권이 아니라 꼬리에서 난다는 앞의 설명과 정확히 맞물립니다.
게다가 이렇게 새로 열린 과업은 나머지 Computer 과업보다 더 어렵습니다. 과업 기술문을 하나 이상 건드린 Computer 질의 4,136건을 새로 열린 것 937건과 나머지 3,199건으로 갈라 비교하면, Bloom 분석 이상 비율이 81.9\% 대 75.4\%, 추상 과업 비율이 78.8\% 대 73.2\% 이고, 요구 지식 영역은 2.67개 대 2.50개, 과업 기술문 개수는 5.68개 대 4.29개입니다. 에이전트가 고유하게 열어 주는 일이 쉬운 잔업이 아니라 더 까다로운 작업 쪽으로 기울어 있다는 뜻입니다.
사용자 25명의 인터뷰에서 나온 이야기
여기까지가 로그로 측정한 결과라면, 논문은 부록에 사용자 25명(기업 6명, 개인 19명)과 진행한 45분짜리 인터뷰를 따로 정리해 두었습니다. 저자들은 이 내용을 다섯 갈래로 묶으면서, 회상 편향과 선택 편향이 있으니 본문 결과를 뒷받침하는 방증으로만 읽어 달라 고 분명히 못 박습니다. 그 전제 위에서 보면 앞의 숫자들이 실제 업무에서 어떤 모습인지 감을 잡는 데 도움이 됩니다.
첫째는 품질입니다. 법률, 창업, 제품 및 컨설팅 직군의 참가자들이 까다로운 과업에서 높은 품질을 보고했습니다. 법률 쪽에서는 초안과 가장 어려운 회계 작업의 결과물을, 창업자 쪽에서는 기술 리더십에게 좋은 평가를 받은 기술 명세 문서를, 컨설팅 쪽에서는 바로 발표에 쓸 수 있는 수준의 슬라이드를 언급했습니다. 6절에서 관찰된 낮은 불만족도와 방향이 맞는 진술들입니다.
둘째는 효율성인데, 가장 자주 나오고 가장 구체적으로 수치화된 주제였습니다. 참가자별 중앙값은 약 25\times 이고 범위는 5\times 에서 300\times 이상까지 벌어집니다.
| 업무 | Computer 이전 | Computer 이후 | 자기 보고 배수 |
|---|---|---|---|
| 법률 조사 및 작성 | 약 2시간 | 약 5분 | 24\times |
| 법률 문서 초안 작성 | 1~2일 | 5~10분 | 95\times |
| 후견 회계 정리 | 하루 종일 | 약 30분 | 16\times |
| 감정 비교 보고서 | 약 1주 | 약 15분 | 160\times |
| 리스크 보고 체계 수립 | 약 1주 | 1시간 미만 | 40\times |
| 1,000쪽 분량 자료 종합 | 약 2주 | 약 15분 | 320\times |
| 웹 제품 전체 구축 | 3~6개월 | 4~5일 | 15 \sim 35\times |
| 강의 콘텐츠 제작 | 1~3주 | 약 1일 | 5 \sim 15\times |
위 표에서 종합 작업의 배수가 유난히 크다는 점이 눈에 띕니다. 논문도 금융과 컨설팅 업무에서 자료를 종합하는 쪽의 이득이 가장 컸다고 정리합니다. 비용 쪽에서는 원래 외부 전문가나 외주 업체를 써야 했던 작업에서 절감이 가장 컸는데, 참가자들은 지출이 120\times 에서 750\times 가량 줄었다고 답했습니다.
셋째는 반복 작업의 자동화입니다. 일회성 프롬프트를 넘어 정기적으로 도는 자동화로 옮겨 간 사례들인데, 클라우드 문서를 모아 리더십 보고서를 만들어 검토 채널에 올리는 작업, 주말에 한 주치 메일과 일정과 프로젝트 트래커를 요약해 다음 주 우선순위를 제안하는 작업, CRM 동기화와 리드 생성 자동화 등이 나왔습니다. 참가자들이 공통으로 꼽은 이점은 속도가 아니라 그동안 방치하던 업무 줄기를 계속 최신 상태로 유지하게 됐다는 점 이었습니다. 밀린 메일함이나 미수금 회수처럼 몰아서 처리하던 일들이 여기 해당합니다.
넷째는 병렬 작업입니다. Computer 가 비동기로 실행되기 때문에 일을 던져 두고 다른 일을 계속하는 방식이 가능해졌고, 여러 작업을 한꺼번에 걸어 두었다가 나중에 확인하거나 자리를 비우기 전에 작업을 제출해 두는 사용 패턴이 보고됐습니다. 몇몇 참가자는 이렇게 일한 기간을 자기 경력에서 가장 생산적이었던 구간으로 꼽았습니다.
다섯째가 8절의 범위 분석과 직접 맞닿습니다. 참가자들은 자기 전문 분야 밖의 일을 맡게 됐다고 반복해서 이야기했습니다. 기술 배경 없이 소프트웨어 모듈을 만들거나, 정식 법률 교육 없이 법률 문서를 준비하거나, 소프트웨어와 데이터 엔지니어링 작업을 직접 처리한 사례들입니다. 회계와 법무, 컴플라이언스처럼 보통 각각 다른 전문가가 필요한 기능을 한 사람이 아우르게 됐다는 진술이 특히 자주 나왔습니다.
저자들이 밝힌 한계
논문은 결과의 크기만큼이나 해석의 조건을 분명히 적어 둡니다.
가장 큰 제약은 관측 창입니다. 2026년 2월 27일부터 5월 27일까지의 3개월은 제품 출시 직후의 초기 도입기이고, 이 시기 사용자는 헤비 유저와 유료 구독자에 크게 치우쳐 있습니다. 제품이 성숙하고 사용자층이 넓어져도 같은 패턴이 유지될지는 열린 질문입니다.
두 번째는 매칭 설계 자체의 사각지대입니다. 유사도 0.99 기준을 통과하려면 Search 쪽에 대응하는 질의가 있어야 하는데, 범위 분석이 보여준 대로 상당수의 Computer 질의에는 그런 대응물이 아예 없습니다. 자율성과 효율성 추정치는 대응물이 있는 부분집합에서만 얻어진 값입니다. 다만 Computer 질의가 대체로 더 복잡하다는 점을 고려하면, 대응물이 없는 과업에서의 이득은 오히려 더 클 가능성이 높습니다.
세 번째는 세션이라는 단위의 잡음입니다. 사용자가 하나의 과업을 여러 세션에 나눠 담거나 한 세션에서 무관한 여러 과업을 처리할 수 있어, 세션과 과업이 정확히 일대일로 대응하지는 않습니다.
네 번째는 효율성 추정에 들어간 가정들입니다. 호출별 사람 시간 환산, 10분으로 고정한 감독 시간, LLM 추정치는 모두 가정에 기대고 있습니다. 손익분기와 민감도 분석이 오측정에 대한 내성을 보여주기는 하지만, 저자들은 절대 수치를 근사값으로 읽으라고 명시합니다.
다섯 번째는 범위 분석이 LLM 분류에 크게 의존한다는 점이고, 마지막은 관측 범위가 Perplexity 생태계 안으로 제한된다는 점입니다. 사용자가 다른 도구로 무엇을 했는지는 데이터에 잡히지 않으므로, 작업 흐름 전체를 본 것은 아닙니다.
여기에 논문이 한계로 적지는 않았지만 읽는 쪽에서 감안할 점을 하나 덧붙이겠습니다. 저자 네 명이 모두 Perplexity 소속입니다. Jeremy Yang 은 기술 스태프이자 하버드 경영대학원 AI Institute 겸임이고, Kate Zyskowski 는 UX 리서치 총괄, Noah Yonack 은 데이터 사이언티스트, Jerry Ma 는 부최고기술책임자입니다. 분석 대상 역시 Perplexity 자사 제품의 자사 로그입니다. 측정 절차와 한계를 투명하게 적어 두었고 서로 독립적인 세 가지 추정으로 삼각 측량했다는 점에서 성실하게 설계된 연구이지만, 절감폭의 크기는 반사실을 무엇으로 잡느냐에 따라 크게 달라집니다.
이 점은 논문 안에서도 확인됩니다. 도구 기반과 LLM 기반 추정이 쓰는 반사실은 다른 AI 도구를 일절 쓰지 못하는 Search + 사람 으로 못 박혀 있습니다. 저자들 스스로 이 설정이 현실의 모든 작업 방식을 담아내지는 못한다고 적었고, 그래서 사용자가 실제로 택했을 대안을 반영하려고 인터뷰를 따로 진행했습니다. 즉 87\% 와 94\% 는 "AI 도구가 Search 하나뿐인 전문가"를 기준으로 한 숫자이며, 이미 다른 코딩 에이전트나 자동화를 쓰고 있는 팀에게 그대로 적용되는 값이 아닙니다.
이 연구가 남기는 것
논문의 결론부에서 저자들이 강조하는 것은 자율성이 나머지를 여는 열쇠라는 점입니다. 에이전트는 대화형 세션에서 사람이 손으로 돌리던 과업 분해와 실행 루프를 없애 버립니다. 그렇다면 에이전트 이전에 사용자가 시도할 수 있는 일을 묶고 있던 제약은 정보 접근이 아니라 실행 역량 이었다는 결론이 따라옵니다. 실행이 위임되는 순간 사용자의 역할은 작업자에서 감독자로 옮겨 가고, 시간은 방향 설정과 검증, 확장 같은 더 상위의 일로 재배분됩니다.
그래서 저자들은 생산성이라는 틀만으로는 에이전트의 영향을 과소평가할 수 있다고 봅니다. 시간과 비용 절감폭이 크기는 하지만, 더 중요한 것은 사람들이 자기 주 전문 분야 밖으로, 그리고 더 높은 복잡도로 손을 뻗기 시작했다는 사실입니다. 논문의 표현을 빌리면 "에이전트가 직군 경계와 전문성 수준을 가로지르는 진입 장벽을 낮추고 조율 비용을 줄인다면, 개인이 예전에는 팀이 필요했던 산출물을 만들어 낼 수 있다"는 것입니다.
다만 이 논문이 다루는 범위는 개인 노동자와 과업 수준에 머뭅니다. 기업이나 노동시장이 어떻게 반응할지, 이 미시적 변화가 조직 구조와 직무 묶음의 재편으로 어떻게 이어질지는 기업 단위의 생산 및 고용 데이터가 있어야 답할 수 있는 질문으로 남겨 두었습니다.
이 경계선은 실무에서 특히 중요합니다. 앞서 본 GitHub 개발자 10만여 명 연구에서 자율 코딩 에이전트의 과업 수준 이득 180\% 가 릴리즈 단위에서는 30\% 로 줄어들었듯이, 과업 하나를 아무리 빨리 끝내도 그 뒤에 사람이 병목으로 남아 있는 단계가 있으면 조직이 실제로 내보내는 산출물은 그만큼 늘지 않습니다. 논문이 인용하는 O링 모형 계열의 연구도 자동화의 수익이 공정 안의 사람 병목에 의해 제한된다는 같은 이야기를 합니다. 그러니 87\% 라는 숫자는 한 사람이 한 과업에 쓰는 시간 의 절감이지, 팀 산출량이 여덟 배가 된다는 뜻이 아닙니다.
오히려 이 논문에서 조직이 가져갈 만한 부분은 명제 3의 분해 쪽입니다. 4개 과업 예시에서 잉여 증가분 220 가운데 절감이 46이고 새로 시도한 과업이 174였던 것처럼, 실증 결과도 에이전트의 값어치가 기존 업무를 빨리 끝내는 데보다 원래 손대지 못하던 일을 하게 되는 데 더 크게 실려 있다고 가리킵니다. 검증과 통합을 누가 감당할지 정하지 않은 채 속도만 기대하면 병목이 그대로 남고, 반대로 한 사람이 어디까지 시도해도 되는지를 다시 그리면 이 연구가 측정한 종류의 변화가 나타납니다. 한국 개발자 입장에서 눈여겨볼 지점도 여기에 있습니다. 이 연구가 측정한 것은 특정 모델의 벤치마크 점수가 아니라 에이전트를 붙였을 때 한 사람이 시도하는 일의 목록이 어떻게 달라지는가 이고, 그 변화는 도구 도입 시점의 역량 평가보다 조직의 역할 설계 쪽에 더 큰 함의를 갖습니다.
How AI Agents Reshape Knowledge Work: Autonomy, Efficiency, and Scope 논문
How AI Agents Are Changing the Way We Work 소개 블로그 (HBS AI Institute)
How AI Agents Are Changing the Way We Work 영상 버전
O*NET Online
더 읽어보기
-
Anthropic Economic Index(2026/02): AI 활용의 학습 곡선과 경제적 파급 효과에 대한 분석
-
AI가 노동 시장에 미치는 영향: 새로운 측정 지표 '관측된 노출도'와 초기 증거 (feat. Anthropic)
-
'코딩 실력보다 도메인 전문성', Anthropic이 Claude Code 세션 40만 건으로 분석한 연구 보고서
-
사회과학 분야에 코딩 에이전트는 얼마나 퍼졌나: 사회과학자 1,260명 설문 분석 (feat. Anthropic)
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
논문의 주장이나 벤치마크에 대한 의견, 직접 재현해보신 결과가 있다면 
파이토치 한국 사용자 모임
회원들을 위해 댓글로 공유해주세요! 