'코딩 실력보다 도메인 전문성', Anthropic이 Claude Code 세션 40만 건으로 분석한 연구 보고서

9bow · 6월 19, 2026, 5:30오전

Claude Code 사용 행태 연구 소개

Anthropic이 2026년 6월 16일 발표한 연구 보고서 Agentic coding and persistent returns to expertise는 약 40만 건의 Claude Code 세션을 분석해, 사람과 AI 에이전트가 실제로 어떻게 협업하고 있는지를 데이터로 들여다본 연구입니다. 지금까지 에이전틱 코딩(Agentic Coding)에 대한 논의는 주로 모델의 능력 한계, 즉 "에이전트가 얼마나 어려운 작업까지 자율적으로 해낼 수 있는가" 에 집중되어 왔습니다. 그러나 이 보고서는 질문의 방향을 바꿉니다. 벤치마크에서 측정하는 잠재 능력이 아니라, 수십만 명의 사용자가 일상적인 업무에서 실제로 무엇을 시키고 있으며, 그 결과가 성공으로 이어지는 조건이 무엇인지를 묻습니다.

연구의 배경에는 에이전틱 코딩의 폭발적인 확산이 있습니다. 보고서에 따르면 코딩 에이전트 활동이 감지된 GitHub 프로젝트의 비율은 2025년 말 이후 두 배 이상으로 늘었고(2025년 10월 말 기준 약 12.8만 개 공개 저장소 중 16~23%에서 에이전트 활동이 감지되었으며, 그 이후 생성된 프로젝트에서는 채택률이 두 배 이상으로 높았습니다), Claude Code 사용자들은 이제 주당 평균 20시간을 이 도구를 켜 둔 채 작업합니다. 이런 상황에서 "정식 코딩 경험이 없는 사람도 복잡한 기술 작업을 에이전트에게 지시해 성공시킬 수 있는가", 그리고 "이 도구의 빠른 보급이 지식 노동 전반에 무엇을 의미하는가" 라는 두 질문이 자연스럽게 떠오릅니다.

이를 확인하기 위해 연구진은 2025년 10월부터 2026년 4월까지 7개월간 약 23.5만 명이 만든 약 40만 건의 대화형(interactive) 세션을 분석했습니다. 분석에는 Anthropic이 개발한 프라이버시 보존 분석 도구 Clio가 사용되었습니다. 연구자가 개별 대화 기록을 직접 읽지 않고, 식별 가능한 사용자와 연결하지 않으며, 최소 인원 이상의 집계값만 관찰하는 방식입니다. 세션 분류에는 별도 언급이 없는 한 Claude Sonnet 4.6 모델이 분류기(classifier)로 쓰였습니다. 분석 대상은 명령줄 인터페이스(CLI), claude.ai, Claude Code 데스크톱 앱을 통한 사용이며, claude -p "<prompt>" 형태의 헤드리스(headless) 실행이나 서드파티 IDE 연동은 제외되었습니다. 후자는 상당수가 자동화 파이프라인에 내장된 프로그래밍적 호출이라 사람과 대화하는 양상과 다르기 때문입니다.

이 연구가 흥미로운 이유는, 코딩이라는 영역이 에이전트가 가장 먼저 깊숙이 침투한 분야라는 점에 있습니다. 보고서는 마지막 문장에서 이를 "코딩은 선도 사례다(coding is a leading case)" 라고 표현합니다. 즉 소프트웨어에서 벌어지는 일은, 에이전트 도구가 다른 형태의 지식 노동으로 확장될 때 무슨 일이 벌어질지를 미리 보여주는 예고편일 수 있다는 것입니다. 아래에서 보고서의 핵심 발견을 분업의 구조, 전문성의 역할, 성공의 조건, 직업과의 관계 순으로 정리합니다.

핵심 발견 요약

본격적인 분석에 앞서, 보고서가 제시하는 네 가지 핵심 발견을 먼저 정리합니다.

분업의 구조: 전형적인 세션에서 사람은 계획 결정(무엇을 할지)의 대부분을, Claude는 실행 결정(어떻게 할지)의 대부분을 맡습니다. 사람이 가진 도메인 전문성이 클수록 한 번의 지시로 Claude가 더 많은 일을 처리합니다.
직업보다 전문성: 코딩 작업에서 거의 모든 주요 직군이 소프트웨어 엔지니어와 거의 같은 비율로 성공합니다. 검증 가능한 증거(테스트 통과, 커밋된 작업 등)를 기준으로 봐도 그렇습니다.
전문성과 성공의 관계: 도메인 전문성이 높을수록 세션이 성공으로 끝날 확률이 높아집니다. 다만 중급자와 전문가 사이의 격차는 크지 않습니다. 7개월간 디버깅에 쓰인 세션 비중은 거의 절반으로 줄었고, 사용 양상은 배포와 실행, 데이터 분석, 비(非)코드 문서 작성처럼 더 종단간(end-to-end)에 가까운 에이전트 활용으로 옮겨갔습니다.
과제 가치의 상승: 같은 7개월간, 프리랜스 구인 공고와 비교해 추정한 전형적 작업의 가치는 거의 모든 종류의 작업에서 상승했으며, 평균 약 25%(다른 추정에서는 27%) 올랐습니다.

이 발견들을 한 문장으로 요약하면 다음과 같습니다.

"코딩 에이전트는 도메인 전문성을 대체하지 않습니다. 작업자가 에이전트에게 더 많은 이해를 가져올수록, 에이전트는 더 많은 양질의 작업을 해낼 수 있습니다."

"Coding agents are not substituting for domain expertise—the more understanding a worker brings to an agent, the more quality work the agent is able to do."

분업의 구조: 사람은 무엇을, Claude는 어떻게

Claude Code로 사람들은 무엇을 하는가

연구진은 각 세션을 "이 세션이 달성하려는 단일 활동" 을 기준으로 아홉 가지 작업 모드(work mode) 중 하나로 분류했습니다. 네 가지 모드는 코드를 직접 작성하거나 관리하는 일로, 새로운 것을 만들기(building), 망가진 것을 고치기(fixing), 코드를 테스트하기(testing), 그리고 다른 에이전트나 자동화 파이프라인을 오케스트레이션하기(orchestrating)입니다. 여기에 소프트웨어를 운영하기(operating), 즉 배포하고 설정하고 파이프라인을 돌리고 시스템을 모니터링하는 모드가 더해집니다. 또 무엇을 할지 파악하는 데 가까운 두 모드로 기존 시스템을 이해하기(understanding)와 변경 전에 계획하기(planning)가 있고, 마지막으로 코드와 무관하거나 코드가 부차적인 두 모드로 데이터를 분석하기(analyzing)와 발표 자료나 산문 문서로 소통하기(communicating)가 있습니다.

비중을 보면 망가진 것 고치기가 26%로 가장 많고, 새로 만들기가 25%로 그 뒤를 잇습니다. 소프트웨어 운영이 17%, 문서와 발표 자료 작성이 10%, 시스템 이해와 변경 계획이 각각 7%, 에이전트 오케스트레이션과 데이터 분석이 각각 3%, 코드 테스트가 2%입니다. 코드를 직접 쓰거나 다루는 세션(만들기, 고치기, 테스트와 오케스트레이션)이 전체의 약 56%를 차지합니다. 한편 대부분의 세션은 이미 존재하는 코드베이스에 묶여 있습니다. 48%는 주로 기존 코드를 수정하고, 또 다른 17%는 코드를 탐색하며, 14%만이 백지에서 새 코드를 만듭니다. 전체의 약 5분의 1은 코드베이스를 전혀 건드리지 않습니다.

이런 분류가 신뢰할 만한지 확인하기 위해, 연구진은 모델이 대화 기록을 읽고 내린 분류를 모든 세션에 자동 기록되는 텔레메트리(코드 줄이 추가되거나 삭제되었는지 등)와 교차 검증했습니다. 두 출처는 높은 일치도를 보였는데, 예를 들어 분류기가 "코드를 생성하거나 수정" 한다고 라벨링한 세션의 90% 이상이 실제 텔레메트리에서도 코드 변경을 보였습니다.

누가 무엇을 결정하는가

Claude Code는 얼마나 자율적일까요? METR의 시간 지평(time-horizon) 평가 같은 능력 벤치마크는 최신 모델이 사람이 몇 시간 걸릴 소프트웨어 작업을 중간 장애물을 헤쳐가며 자율적으로 완수할 수 있다는, 높고 계속 상승하는 천장을 보여줍니다. 그러나 실제 사용 양상은 다릅니다. 연구진은 이를 두 각도에서 살펴봤습니다. 첫째는 사람이 얼마나 많은 결정(decision) 을 Claude에게 맡기는가, 둘째는 사람이 얼마나 많은 행동(action) 을 Claude에게 넘기는가입니다.

결정의 분업을 파악하기 위해 연구진은 프라이버시 보존 결정 귀속 분류기(decision attribution classifier) 를 만들어, 세션 안의 모든 의미 있는 결정을 나열한 뒤 이를 계획(무엇을 할지, 어떤 접근을 택할지, 무엇을 완료로 볼지)과 실행(어떤 파일을 바꿀지, 어떤 코드를 쓸지, 어떤 언어로 쓸지, 어떤 명령을 실행할지)으로 나눴습니다. 그리고 각 결정을 Claude 또는 사용자에게 귀속시켜, 세션마다 사용자의 계획 결정 비중과 실행 결정 비중이라는 두 숫자를 얻었습니다.

결과는 명확합니다. 평균적으로 사람은 계획 결정의 약 70%를 내리지만 실행 결정은 약 20%만 내립니다. 나머지 80%의 실행 결정은 Claude의 몫입니다. 보고서는 이를 에이전틱 코딩의 분명한 분업으로 요약합니다.

"사람은 무엇을 만들지 결정하고, 에이전트는 어떻게 만들지 결정합니다."

"People decide what to build, and the agent decides how to build it."

행동의 위임은 세션의 내용이 아니라 구조를 보면 드러납니다. Claude Code 세션은 사용자의 프롬프트와 Claude의 행동이 오가는 형태로, 사용자가 프롬프트를 쓰면 Claude가 일을 하고 다시 사용자가 다음 프롬프트를 쓰는 식입니다. 전형적인 세션에는 이런 차례(turn)가 약 4번 있습니다. 그리고 2025년 10월부터 2026년 4월까지의 데이터에서, 사용자가 보내는 프롬프트 하나는 평균 약 10개의 Claude 행동으로 이어졌고 때로는 100개를 넘기도 했습니다. 각 차례에서 Claude는 파일을 읽고, 코드를 편집하고, 명령을 실행하며, 평균 2,400단어의 출력을 씁니다. 참고로 프롬프트당 행동 수의 꼬리는 매우 깁니다. 약 2%의 세션은 프롬프트당 평균 100개가 넘는 행동을, 약 270건 중 1건은 200개 이상을, 약 2,300건 중 1건은 500개 이상을 기록했습니다.

흥미롭게도 Claude가 한 번의 점검(check-in) 사이에 얼마나 많은 일을 하는지는 누가 결정을 내리는지와 거의 일치합니다. 사용자가 실행을 통제하면(실행 결정의 80% 이상을 직접 내리면) Claude는 차례당 더 적은 행동(약 8개)만 하고, 반대로 Claude가 계획을 장악하면(계획 결정의 80% 이상을 내리면) 가장 많은 행동(약 16개)을 합니다.

전문성이라는 변수: 직업이 아닌 과제별 숙련도

이 보고서에서 가장 독창적인 개념은 전문성(expertise) 의 정의입니다. 연구진은 각 대화 기록에서 Claude가 해당 과제에 대한 사용자의 전문성을 초보(novice)부터 전문가(expert)까지 5점 척도로 평가하게 했습니다. 전문성 분류기는 세 가지 신호를 봅니다. 사용자가 얼마나 정밀하게 지시를 구성하는지, 무엇을 검증해 달라고 요청하는지, 그리고 사용자가 Claude를 교정하는 경향이 있는지 아니면 Claude가 사용자를 교정하는 경향이 있는지입니다.

여기서 결정적인 점은, 이 전문성이 직책이나 일반적 능력과는 전혀 다른 것을 포착하며 과제별로 특정된다(task-specific) 는 것입니다. 보고서가 드는 비유가 명료합니다. 처음으로 Rust 질문을 하는 시니어 엔지니어는 Rust에 대해서는 초보입니다. 반면 Python을 한 번도 써 본 적 없지만 "Python 스크립트가 강제해야 할 정산 규칙을 정확히 지시하고, 월말 마감 때 스크립트가 잘못 처리하는 예외 케이스를 잡아내는" 회계사는 그 과제에 대해서는 전문가입니다. 즉 전문성은 코딩 능력이 아니라 풀려는 문제에 대한 이해의 깊이를 가리킵니다.

위 표는 다섯 단계를 분류기가 어떻게 정의했는지와, 공개 데이터셋 SWE-chat에서 가져온 실제 세션을 익명화하고 압축한 예시를 함께 보여줍니다. 초보로 분류된 대화는 도메인 특화 지식이 전혀 드러나지 않는 일반적인 지시를 줍니다.

"이 데이터를 분석해서 차트로 만들어 줄 수 있어?" (1번째 프롬프트)

"That's not what I expected please double-check what you did." (6번째 프롬프트)

반면 전문가로 분류된 대화는 코드베이스와 기술 환경에 대한 깊은 지식을 전달하며, 정밀하게 약점을 겨냥합니다.

"관리형(managed) 슬롯과 비관리형 슬롯을 나눠서 하드 리프레시 주기를 더 낮춰야 할 수도 있어. 예를 들어 관리형은 30분마다 갱신하지만 나머지는 하루 한 번이면 돼." (64번째 프롬프트)

"should we do retries instead of best effort? sync needs to reliably know what's on the lock. Remember the original bug where the valuedb was stale and it created a loop trying to set the pin over and over. retries aren't necessarily the best solution but neither is best effort" (108번째 프롬프트)

전문가일수록 한 번의 지시로 더 많은 일을 시킨다

전문성과 Claude의 활동량 사이에는 뚜렷한 관계가 있습니다. 전형적인 초보 세션에서는 프롬프트 하나가 약 5개(정확히는 4.9개)의 Claude 행동과 약 600단어(607단어)의 출력을 불러일으킵니다. 반면 전문가 세션에서는 그 두 배가 넘는 약 12개(11.7개)의 행동이 이어지고, 다섯 배에 달하는 약 3,200단어의 출력이 따라옵니다.

이 격차는 모든 종류의 작업과 모든 과제 가치 구간에서 동일하게 나타났습니다. 작업 모드, 과제 가치, 월, 직업, 모델 계열을 통제하고 사용자별로 표준오차를 군집화한 회귀분석에서도, 전문성 한 단계가 오를 때마다 행동 수는 약 9%, 출력량은 약 13% 증가하는 효과가 통계적으로 유의하게(p < 0.001) 유지되었습니다. 결국 도메인 전문성이 깊은 사용자는 한 번의 지시로 에이전트에게 더 멀리, 더 많이 일을 맡길 수 있다는 뜻입니다. 전문가는 무엇을 검증해야 하고 어디에 함정이 있는지 알기 때문에, Claude를 더 길게 풀어 놓아도 결과를 믿고 다룰 수 있는 것입니다.

누가 Claude Code를 쓰는가

이 작업을 하는 사람들이 누구인지 파악하기 위해, 연구진은 각 세션의 대화 기록에서 사용자의 직업을 추론해 미국 노동통계국(Bureau of Labor Statistics)의 표준직업분류(SOC) 23개 대분류 중 하나로 매핑했습니다. 분류기는 세션 시작 시 에이전트가 불러오는 프로젝트 맥락, 파일 이름과 구조, 참조하는 산출물(법률 문서, 임상 데이터, 재무 보고서, 커리큘럼 등), 사용하는 어휘 같은 신호에만 의존하도록 지시받았습니다.

특히 중요한 설계는 "코딩을 한다는 사실 자체를 코딩 직업의 증거로 취급하지 말라" 는 명시적 지침입니다. 소프트웨어나 데이터 작업이 사용자의 직업이라는 분명한 신호가 있을 때만 컴퓨터 및 수학 직군으로 분류되며, 변호사가 계약서 폴더 전체에서 누락된 조항을 자동으로 표시하는 스크립트를 만드는 세션은 그 작업이 주로 소프트웨어더라도 법률 직군으로 분류됩니다. 직업 신호가 전혀 없으면 미분류로 남깁니다.

연구진은 약 70%의 세션에서 직업을 추론할 수 있었습니다. 그 안에서 가장 큰 집단은 예상대로 대부분의 소프트웨어 관련 직업을 아우르는 컴퓨터 및 수학 직군이었고, 그 뒤를 비즈니스 및 재무 운영, 예술 디자인 및 미디어, 관리(management), 생명 물리 사회과학 직군이 이었습니다. 표본에서 가장 빠르게 늘어난 비(非)소프트웨어 직군은 관리, 영업, 법률 직업이었습니다.

7개월간 달라진 작업의 구성과 가치

분석 기간인 2025년 10월부터 2026년 4월 사이, Claude Code로 수행되는 작업의 구성은 상당히 달라졌습니다. 가장 뚜렷한 변화는 망가진 코드를 고치는 데 쓰인 세션 비중이 33%에서 19%로 떨어진 것입니다. 그 자리를 코드 주변 의 작업이 채웠습니다. 소프트웨어 운영은 14%에서 21%로 늘었고, 문서 작성과 데이터 분석은 약 10%에서 20%로 거의 두 배가 되었습니다.

작업 자체의 가치도 올랐습니다. 연구진은 각 세션의 경제적 가치를 "이 작업이 프리랜스 마켓플레이스에서 얼마에 거래될까" 라는 질문으로 근사했는데, 실제 구인 공고 공개 데이터셋에 맞춰 보정한 이 척도로 보면 평균 세션의 추정 가치는 10월과 4월 사이 27% 상승했습니다. 이 상승은 여러 종류의 작업에 걸쳐 나타나, 만들기 작업은 약 43%, 운영 작업은 약 34%, 고치기 작업은 약 32% 더 가치 있어졌습니다. 다만 소통(문서 작성) 작업은 +2%로 거의 변화가 없었습니다. 연구진은 이 가격 추정이 거칠기 때문에 절대적 금액으로 읽기보다는 시간에 따른 작업 간 상대 비교에 주로 쓴다고 밝히고 있습니다.

이 두 변화를 함께 읽으면 하나의 그림이 그려집니다. 사람들은 점점 더 단순한 버그 수정에서 벗어나, 배포와 운영, 분석, 문서화처럼 더 넓고 더 가치 있는 종단간 작업을 에이전트에게 맡기기 시작했습니다. 디버깅의 비중이 절반 가까이 줄었다는 사실은, 모델이 더 유능해지면서 사람이 자질구레한 오류 추적에 시간을 덜 쓰고 더 큰 그림에 집중하게 되었음을 시사합니다.

성공을 가르는 것: 사용자가 무엇을 가져오는가

작업의 추정 가치가 한 측면이라면, 또 다른 측면은 "얼마나 많은 세션이 성공하며, 어떤 특성이 성공과 연결되는가" 입니다. 모든 성공 척도에서 일관된 패턴이 나타납니다. 사람이 세션에서 더 많은 전문성을 보일수록 성공 가능성이 높아진다는 것입니다. 그리고 이득의 대부분은 척도의 아래쪽, 즉 초보에서 중급으로 가는 구간에 몰려 있습니다.

성공을 어떻게 측정했는지를 먼저 짚을 필요가 있습니다. 연구진은 사용자의 실제 현실 결과를 관찰할 수 없고 만족 여부를 직접 물을 수도 없으므로, 대화 기록에 기반한 두 가지 상호 보완적 척도에 의존합니다. 첫째는 판정된 성공(judged success) 으로, 전체 대화 기록을 읽은 분류기가 사용자가 의도한 바를 이뤘는지를 판단합니다(성공, 부분 성공, 실패, 명확한 목표 없음 중 선택). 둘째는 두 개의 동반 분류기가 그 판단의 증거 강도를 평가해 결정하는 검증된 성공(verified success)입니다. 성공 신호 분류기는 커밋과 풀 리퀘스트 같은 git 활동, 테스트 통과, 사용자의 명시적 확인처럼 검증 가능한 증거를 찾아 "신호 없음" 부터 "여러 개의 확실한 신호(5)" 까지 점수를 매기고, 별도의 실패 신호 분류기는 오류와 실패한 테스트, 재시도, 사용자의 반발 같은 증거를 점수화합니다. 검증된 성공은 세션이 성공으로 판정되고 동시에 적어도 하나의 확실한 성공 증거가 있을 때만 인정됩니다.

위 표는 각 척도의 정의와 실제 세션 예시를 보여줍니다. 예컨대 검증된 성공 의 사례는 "README의 배포 섹션을 고쳐 줘, 이제 GitHub Actions가 아니라 Docker와 Render를 쓰니까" 라는 요청에 Claude가 파일을 수정하고 사용자가 커밋과 푸시를 요청해 변경이 main에 반영된 경우입니다. 반면 포기됨(abandoned) 의 사례는 실패로 판정되고 코드가 한 줄도 작성되지 않은, 사용자가 "never mind" 를 입력하고 떠나는 세션입니다. 이후 분석에서는 "명확한 목표 없음" 으로 판정된 세션(전체의 약 7.7%)을 제외합니다.

전문성과 세션의 결말

그렇다면 어떤 세션이 가장 성공적일까요? 전문성 등급이 세션의 성공에 큰 영향을 미친다는 것이 답입니다. 전문가가 단지 다른 과제를 고르는 것은 아닐까 하는 우려에 대응하기 위해, 연구진은 같은 작업 모드, 같은 추정 가치 구간, 같은 월, 같은 주제, 같은 직업 대분류에 속한 세션끼리만 비교해 전문성에 따른 결과 차이를 측정했습니다.

결과는 인상적입니다. 초보로 평가된 세션은 가장 엄격한 척도인 검증된 성공 에 15%, 적어도 부분 성공에는 77% 도달합니다. 반면 중급 이상으로 평가된 세션은 검증된 성공에 28~33%, 부분 성공에는 91~92% 도달합니다. 전문가 세션은 검증된 성공 33%, 부분 성공 91%에 이릅니다. 다만 모든 척도에서 이득의 대부분은 초보에서 중급으로 이동할 때 발생하고, 중급에서 전문가로 갈 때는 기울기가 완만해집니다. 깊은 숙달보다는 도메인에 대한 작동 수준의 이해가 대부분의 효용을 가져온다는 뜻입니다.

위기에 빠진 세션에서의 회복력

전문성의 가치는 일이 꼬였을 때 더 분명하게 드러납니다. 연구진은 실패 신호가 검증된 실패 증거를 기록할 때 세션이 곤경에 빠졌다(hits trouble) 고 정의합니다. 오류, 실패한 테스트, 같은 일을 여러 번 시도하기, 사용자의 좌절이나 불만 표현 등이 여기에 해당합니다. 곤경에 빠진 세션 중에서 검증된 성공에 이르는 비율은 초보 세션의 4%에서 전문가 세션의 15%로 올라갑니다. 더 느슨한 척도로 봐도 적어도 부분 성공에 이르는 비율이 초보 60%, 중급에서 전문가 80~81%로 차이가 납니다.

반대 방향, 즉 실패와의 관계도 추적됩니다. 곤경에 빠진 세션이 실패로 판정되고 코드가 한 줄도 작성되지 않으면 포기됨(abandoned) 으로 분류하는데, 초보로 보이는 사용자의 세션은 19%가 포기로 끝나는 반면 나머지 모두는 5~7%에 그칩니다. 다시 말해, 경험이 가장 적은 사용자가 원하는 결과를 얻지 못할 때 더 쉽게 포기합니다. 전문성의 가치 일부는 바로 에이전트를 올바른 방향으로 조종(steer)하는 능력에 있는 것입니다.

다만 연구진은 한 가지 미묘한 단서를 덧붙입니다. 곤경에 빠진다는 조건 자체가 사용자별로 다른 세션을 선택한다는 점입니다. 전문가는 애초에 곤경에 덜 빠지므로, 그들이 겪는 곤경은 더 어려운 문제일 가능성이 높습니다. 세션의 가격 추정을 복잡도의 대리 지표로 보면, 곤경에 빠진 세션의 평균 추정 가치는 전문성 척도의 맨 아래에서 맨 위로 갈수록 대략 두 배가 됩니다. 즉 회복률 격차의 일부는 "초보는 일상적인 문제에서 막히고 전문가는 도전적인 난제에서 막힌다" 는 사실을 반영할 수 있습니다.

직업보다 전문성: 모든 직군이 비슷한 성공률

이 보고서에서 노동 시장에 가장 직접적인 함의를 던지는 발견은, 코딩 작업의 성공률이 직업에 거의 좌우되지 않는다는 점입니다. 소프트웨어 엔지니어를 비롯한 컴퓨터 및 수학 직군은 전체 세션의 약 30%에서 검증된 성공에 도달하고, 다른 직업의 사용자는 약 26%에 도달합니다. 코드를 생성하는 세션(적어도 한 줄 이상 추가하거나 수정한 세션)만 보면 각각 34%와 29%입니다. 이 5%포인트 차이는 작고, 두 집단의 성공률이 모두 오르는 7개월 동안 벌어지지도 좁혀지지도 않았습니다.

코드를 생성하는 세션에서, 데이터셋의 10대 직군은 모두 검증된 성공률에서 소프트웨어 엔지니어와 7%포인트 이내로 붙어 있습니다. 아래 표는 각 직군의 검증된 성공, 판정된 성공, 적어도 부분 성공 비율을 정리한 것입니다.

직군 (SOC 대분류)	검증된 성공	판정된 성공	적어도 부분 성공
컴퓨터 및 수학 (소프트웨어)	34%	60%	94%
관리(Management)	37%	55%	95%
법률(Legal)	33%	57%	95%
비즈니스 및 재무	29%	54%	93%
의료(Healthcare)	28%	56%	93%
예술, 디자인 및 미디어	28%	53%	92%
영업(Sales)	28%	51%	92%
건축 및 엔지니어링	27%	54%	93%
교육(Education)	27%	52%	92%
과학(Sciences)	27%	54%	94%

검증된 성공은 가장 엄격한 기준(판정된 성공 + 확실한 증거)이고, 적어도 부분 성공은 가장 느슨한 기준입니다. 가장 느슨한 척도에서는 모든 직군이 92~95%로 사실상 차이가 없으며, 가장 엄격한 척도에서도 27~37%의 좁은 범위 안에 모두 들어옵니다.

눈에 띄는 점은 관리 직군이 검증된 성공률(37%)에서 소프트웨어 엔지니어링 직군(34%)을 근소하게 앞선다는 것입니다. 보고서는 이를 에이전트를 지휘하는 데 전이되는 관리 기술의 효과로 해석할 수 있다고 보면서도, 측정상의 편향 가능성도 함께 언급합니다. 검증이 부분적으로 대화 기록 속 명시적 확인에 의존하는데, 관리자는 원하는 결과를 얻었을 때 그것을 말로 표현할 가능성이 더 높을 수 있기 때문입니다.

분석적 관점: 증폭과 대체의 양면성

이 보고서의 발견들을 관통하는 핵심 긴장은 "증폭(amplify)" 과 "대체(substitute)" 사이에 있습니다. 에이전틱 코딩은 어떤 형태의 지식과 기술은 증폭하고, 다른 것은 대체합니다.

대체되는 쪽은 코딩 능력 그 자체입니다. 코드를 생성하는 세션에서 거의 모든 주요 직군이 소프트웨어 직군과 몇 %포인트 이내로 성공한다는 사실은, 코딩 배경이 성공적인 프로그래밍에 점점 덜 중요해지고 있음을 시사합니다. 한때 소프트웨어 엔지니어의 전유물이던 구현 작업의 상당 부분을 에이전트가 흡수하고 있는 것입니다.

반면 증폭되는 쪽은 도메인 전문성입니다. 전문가로 평가된 세션은 초보로 평가된 세션보다 검증된 성공에 두 배 넘게 자주 도달하고, 세션이 곤경에 빠졌을 때 초보는 전문가의 몇 배에 달하는 비율로 포기합니다. 협업의 형태가 이 그림에 색을 더합니다. 도메인 전문가는 자신이 내리는 각 지시로 Claude가 더 많은 일을 하도록 이끌 수 있습니다. 그러니 Claude를 성공으로 이끄는 능력은 코드를 쓰는 능력보다 도메인에 대한 장악력에서 더 많이 나옵니다.

"그리고 이득은 대부분 숙달이 아니라 역량에서 나옵니다. 도메인에 대한 작동 수준의 이해가 대부분의 효용을 포착하며, 깊은 전문화는 그 너머로 약간을 더할 뿐입니다."

"And the gains come mostly from competence, not mastery—a working grasp of the domain captures most of the benefit, while deep specialization adds only a bit more beyond that."

이 양면성은 노동 시장에 대한 초기 신호로 읽힙니다. 자신이 풀려는 문제를 확실히 이해하는 사람이라면, 어떤 분야에 있든 이전에는 할 수 없던 기술 작업을 이제 해낼 수 있을지 모릅니다. 반대로 그런 전문성이 없는 사람은 같은 도구에서 훨씬 적은 것을 얻습니다.

시사점과 향후 전망

연구진은 이 발견들이 예비적(preliminary)이라는 점을 분명히 합니다. 대부분의 연구가 그렇듯, 세션에서 작성된 코드가 실제로 쓰였는지 폐기되었는지, 경제적으로 가치 있는 산출물을 만들어 냈는지 같은 현실 결과는 측정할 수 없습니다. 또한 이 보고서가 제외한 비대화형(non-interactive) 사용이 전체 활동의 상당 부분을 차지하므로, 이를 측정할 프레임워크를 개발하는 것이 향후 과제입니다. 그리고 모든 세션 분류가 모델의 대화 기록 해석에 의존한다는 한계도 있습니다. 부록에서 연구진은 분류기가 독립적인 텔레메트리와 예상되는 방향으로 일치하고 강력한 기준 모델과 대다수 세션에서 합의한다는 점을 보였지만, 대규모로 검증하기는 여전히 어렵다고 인정합니다.

그럼에도 이 보고서가 제시한 측정 지표들은 앞으로의 변화를 추적할 도구가 됩니다. 연구진은 두 가지 향후 시나리오를 제시합니다. 만약 전문성에 대한 보상(returns to expertise)이 시간이 지나며 줄어들기 시작한다면, 그것은 모델이 지금까지 사용자가 가져오던 본질적 판단을 스스로 공급하기 시작했고, 이 도구의 이득이 도메인 전문가를 넘어 넓어지고 있다는 신호일 것입니다. 반대로 소프트웨어 직업 바깥의 사용자가 성공적으로 완료하는 코딩 세션의 비중이 계속 늘어난다면, 그것은 소프트웨어 생산이 단일 직업의 산물이 아니라 모든 분야의 일상 업무의 일부가 되고 있다는 신호일 수 있습니다.

이러한 관점은 개발자와 IT 종사자에게도 시사하는 바가 큽니다. 코딩 자체의 진입 장벽이 낮아지는 흐름 속에서, 차별화의 원천은 "어떤 문제를 왜 풀어야 하는가" 를 정의하는 도메인 이해와, 에이전트의 작업을 검증하고 올바른 방향으로 조종하는 능력으로 옮겨가고 있습니다. 그리고 보고서가 강조하듯 코딩은 선도 사례일 뿐, 에이전트가 다른 지식 노동으로 확장될 때 같은 역학이 반복될 가능성이 높습니다.

Agentic coding and persistent returns to expertise 소개 블로그

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~

18NAO · 6월 19, 2026, 8:43오전

당연한 사실을 논문으로 검증까지 했네요.

9bow · 7월 3, 2026, 6:08오전

안녕하세요, @18NAO 님.

댓글을 작성해 주실 때에는 가이드라인을 읽고, 작성해주시기를 부탁드립니다.

더 나은 토론 문화를 만들고, 전체 대화의 수준을 한 단계 높일 수 있도록 사려 깊게 댓글을 작성해주시기를 부탁드립니다.

감사합니다.