개발자가 아니어도 성공률이 비슷하다면, AI 시대 핵심 역량은 무엇인가

Claude Code 세션 약 40만 건 분석에서 성공률은 직군보다 작업 전문성과 더 관련 있었습니다. 수치의 의미와 한계를 정리합니다.

Share
도메인 지식과 AI 활용 역량을 다룬 AXMOS AX 전략 썸네일

저자 및 인사이트: 이동훈(코드프레소 대표) · 편집 및 재구성: AXMOS 콘텐츠팀 | 최종 수정 2026-10-02

💡
핵심 요약AI 시대 핵심 역량을 묻는 질문에 대해 Anthropic의 2026년 분석은 코딩 직군 여부보다 작업 전문성이 성공률과 더 크게 관련되어 있었다는 근거를 내놓았습니다.2025년 10월부터 2026년 4월까지 Claude Code 세션 약 40만 건을 분석한 결과, 코드를 만든 세션의 검증된 성공률은 소프트웨어 직군 약 34%, 그 밖의 직군 약 29%였습니다.같은 조건끼리 비교했을 때 초보로 평가된 세션의 검증된 성공률은 15%, 중급 이상은 28~33%였습니다. 차이의 대부분은 초보와 중급 사이에서 나타났습니다.이 수치는 세션 기록을 모델이 판정한 예비 결과이며, 코드가 실제 업무에 쓰였는지는 측정하지 않았습니다. AXMOS는 업무 기준을 정의하는 역할과 코드를 검증하고 운영하는 역할을 나눠 설계해야 한다고 봅니다.

개발자가 아니어도 성공률이 비슷하다는 말은 무엇을 뜻하나?

AI 코딩의 성공률은 개발 직군 여부보다 해당 작업을 얼마나 아는지와 더 뚜렷하게 관련되어 있었습니다.

Anthropic은 2026년 6월 16일 「Agentic coding and persistent returns to expertise」라는 연구를 공개했습니다. Anthropic 연구 원문에 따르면 분석 대상은 2025년 10월부터 2026년 4월 사이에 사람이 대화하며 진행한 Claude Code 세션 약 40만 건이며, 이용자는 약 23만 5천 명입니다. 연구진은 코드를 만든 세션에서 주요 직군 모두가 평균적으로 소프트웨어 엔지니어와 거의 비슷한 비율로 성공했다고 정리했습니다.

여기서 주의할 표현이 있습니다. 연구가 비교한 것은 "코딩을 할 줄 아는 사람과 모르는 사람"이 아니고, 세션 기록에서 추정한 직군입니다. 법무 담당자가 계약서 누락 조항을 찾는 스크립트를 만들었다면 그 세션은 법무 직군으로 분류됩니다. 그래서 이 결과는 "개발 직군이 아닌 사람도 AI 코딩 도구로 비슷한 비율의 성공을 거두었다"로 읽는 것이 정확합니다.

이 글에서 다루는 질문은 그다음입니다. 개발 경력 대신 무엇이 성공의 조건이 되는지, 그리고 그 조건이 기업의 운영 환경에서도 같은 의미를 갖는지입니다. 조사 결과는 도메인 지식이 중요하다는 주장을 뒷받침합니다. 그러나 코드 검증과 운영 책임까지 필요 없다고 말하지는 않습니다.

여기서 도메인 지식은 자기 업무의 기준을 아는 능력을 뜻합니다. Anthropic도 비슷한 예를 들었습니다. 파이썬을 써 본 적 없는 회계 담당자라도 월말 결산에서 스크립트가 지켜야 할 대사 규칙을 정확히 설명하고 놓친 예외를 잡아낸다면, 그 작업에서는 전문가로 평가된다는 설명입니다. 전문성은 직함으로 정해지지 않고 작업마다 따로 평가된다는 뜻입니다.

Anthropic 조사는 무엇을 어떻게 측정했나?

이 조사는 약 40만 건의 Claude Code 세션 기록을 개인정보를 보호하는 방식으로 분류해 성공 여부를 추정했습니다.

성공 여부는 사용자에게 직접 묻지 않았고, 모델이 대화 기록을 읽어 판정했습니다. 연구진은 실제 업무 성과를 관찰하지 못했다고 한계를 밝혔습니다. 그래서 수치를 읽기 전에 무엇을 성공으로 쳤는지부터 확인해야 합니다.

구분내용
분석 대상2025년 10월~2026년 4월 Claude Code 세션 약 40만 건, 이용자 약 23만 5천 명
포함 범위터미널(CLI), Claude.ai, 데스크톱 앱에서 사람이 대화하며 진행한 세션
제외 범위외부 개발 도구와 SDK를 거친 사용, 사람이 없는 비대화형(headless) 실행
직군 판정세션 기록에서 추정했으며 전체 세션의 약 70%에서 직군을 식별
판정 성공모델이 기록을 읽고 하려던 일을 해냈는지 판정
검증된 성공판정 성공에 더해 테스트 통과, 커밋, 사용자의 명시적 확인 같은 객관적 신호가 1개 이상 있는 경우
전문성 평가지시의 구체성, 검증을 요청한 항목, 오류를 누가 바로잡는지를 보고 다섯 단계로 평가

이 표에서 기억할 점은 두 가지입니다. 첫째, 성공의 기준은 코드의 품질 자체가 아니고 세션 안에서 확인되는 신호입니다. 둘째, 전문성은 사람 단위가 아닌 세션 단위로 평가됩니다. 같은 사람도 익숙한 업무에서는 전문가로, 낯선 업무에서는 초보로 평가될 수 있습니다.

직군과 전문성 중 무엇이 성공률과 더 관련 있었나?

코드 작성 세션에서 직군 사이의 차이는 약 5%포인트였고, 전문성 수준 사이의 차이는 그보다 컸습니다.

코드를 한 줄 이상 추가하거나 수정한 세션만 보면 소프트웨어 관련 직군의 검증된 성공률은 약 34%, 그 밖의 직군은 약 29%였습니다. 부분 성공 이상으로 기준을 넓히면 각각 89%와 88%입니다. 연구진은 이 5%포인트 격차가 관찰한 7개월 동안 벌어지지도 좁아지지도 않았다고 적었습니다. 규모가 큰 상위 10개 직군은 모두 소프트웨어 직군과 7%포인트 이내였고, 관리직은 검증된 성공률이 소프트웨어 직군보다 약간 높았습니다. 연구진은 관리자가 결과를 명시적으로 확인해 주는 경향이 측정에 반영되었을 수 있다고 단서를 달았습니다.

전문성으로 나누면 차이가 더 크게 보입니다. 다음 표는 Anthropic이 같은 작업 유형, 같은 추정 가치 구간, 같은 달, 같은 주제, 같은 직군 범주의 세션끼리 비교해 보고한 값입니다. 직군 비교와 조정 방식이 다르므로 두 격차를 같은 저울에 올려 놓고 단순 비교하지는 않는 편이 좋습니다.

지표초보로 평가된 세션중급 이상으로 평가된 세션
검증된 성공15%28~33%
부분 성공 이상77%91~92%
어려움을 겪은 세션 중 검증된 성공4%15%(전문가 기준)
어려움을 겪고 코드 없이 포기한 비율19%5~7%
프롬프트 1회당 에이전트 행동과 출력행동 약 5회, 출력 약 600단어전문가 기준 행동 약 12회, 출력 약 3,200단어

표에서 눈에 띄는 부분은 초보에서 중급으로 올라갈 때 차이가 가장 크고, 중급에서 전문가로 올라갈 때는 차이가 작다는 점입니다. 연구진은 깊은 숙련보다 업무를 다룰 수 있는 기본 역량이 효과의 대부분을 차지한다고 해석했습니다. 모든 직원이 최고 전문가가 될 필요는 없고, 자기 업무의 기준을 말로 설명할 수 있는 수준이 분기점이라는 뜻입니다.

왜 도메인 지식이 AI 시대 핵심 역량으로 꼽히나?

세션 안에서 사람은 무엇을 할지 정하고, 에이전트는 어떻게 할지 정하는 분업이 뚜렷했기 때문입니다.

Anthropic의 분류에 따르면 사용자는 계획 결정의 약 70%를 내렸고 실행 결정은 약 20%만 내렸습니다. 어떤 결과를 완료로 볼지, 어떤 접근을 택할지 정하는 일은 사람에게 남아 있었다는 뜻입니다. 이 구조에서는 업무 기준이 모호한 사용자일수록 에이전트에게 방향을 주기 어렵습니다.

포기하는 양상에서도 차이가 보였습니다. 어려움을 겪은 세션에서 초보로 평가된 사용자는 19%가 코드를 한 줄도 쓰지 못한 채 포기했고, 나머지 집단은 5~7%였습니다. 연구진은 전문성의 가치 가운데 일부가 에이전트를 올바른 방향으로 이끄는 능력에 있다고 해석했습니다. 다만 원문 각주는 전문가가 막히는 문제가 대체로 더 어려운 문제이므로, 복구율 차이의 일부는 이런 선택 효과일 수 있다고 밝혔습니다.

이 분업을 현장에 옮겨 보겠습니다. 생산관리 담당자가 불량 이력 파일을 정리하는 스크립트를 에이전트에게 맡긴다고 가정합니다. 이때 결과를 좌우하는 지식은 반복문이나 라이브러리 사용법보다, 어떤 불량 코드를 같은 종류로 묶어야 하는지, 결측값을 지워도 되는지, 보고서 합계가 어느 시스템 수치와 맞아야 하는지에 관한 것입니다. 이 예시는 설명을 위한 가상의 상황이며 조사 데이터에는 포함되어 있지 않습니다.

이 결과를 과대 해석하면 안 되는 이유는 무엇인가?

이 조사는 한 회사 도구의 이용 기록을 분석한 예비 결과이며, 실제 업무 성과와 운영 품질을 측정하지 않았습니다.

연구진은 원문에서 결과가 예비적이라고 직접 밝혔습니다. 작성한 코드가 실제로 쓰였는지 버려졌는지, 경제적 가치가 있는 결과물이 되었는지는 관찰할 수 없다고 적었고, 모든 분류가 모델의 대화 기록 해석에 의존한다는 점도 한계로 꼽았습니다. 이 글을 쓰는 2026년 10월 기준으로 제3자가 같은 방법으로 재현한 결과는 확인하지 못했습니다.

해석할 때 지켜야 할 선은 네 가지입니다.

  • 성공률 29~34%는 엄격한 기준의 값입니다. 부분 성공 이상은 88~89%여서, 어느 기준을 보느냐에 따라 체감이 달라집니다.
  • 분석 대상은 Claude Code를 쓰는 사람에 한정됩니다. 다른 도구 이용자나 전체 직장인에게 그대로 일반화할 수 없습니다.
  • 세션 단위 결과입니다. 코드가 보안 검토, 데이터 권한, 유지보수 체계를 통과했는지는 알 수 없습니다.
  • 상관관계입니다. 연구진은 작업 유형과 가치 등을 맞춰 비교했지만, 전문성이 성공을 만든다고 단정할 근거로 쓰기는 어렵습니다.

정보 출처도 함께 고려해야 합니다. 이 분석은 도구를 제공하는 회사가 자사 이용 기록으로 수행했습니다. 수치는 참고하되, 우리 조직의 업무로 다시 재는 절차를 거쳐야 합니다.

현장 전문성과 코드 검증은 어떻게 나누고, 팀 역량은 어떻게 진단하나?

업무 기준을 정의하고 결과를 판정하는 일은 현장 전문가가 맡고, 코드 검증과 운영 권한은 별도 통제 대상으로 두어야 합니다.

Anthropic 조사가 보여 주는 것은 앞의 영역입니다. 뒤의 영역은 다른 자료가 다룹니다. Google Cloud가 소개한 2025년 DORA 보고서에 따르면 기술 전문가 약 5,000명 응답자 가운데 90%가 업무에 AI를 쓰고 80% 이상이 생산성이 올랐다고 답했지만, 30%는 AI가 만든 코드를 거의 또는 전혀 신뢰하지 않는다고 답했습니다. 미국 NIST의 보안 소프트웨어 개발 프레임워크(SSDF, SP 800-218)는 사람이 읽을 수 있는 코드를 검토·분석하는 실천(PW.7), 실행 코드를 시험하는 실천(PW.8), 코드를 무단 접근과 변조로부터 보호하는 실천(PS.1)을 별도 항목으로 둡니다. SSDF는 소프트웨어 개발 전반에 적용되는 보안 기준이며, 아래 표의 구분은 이 기준을 참고해 AXMOS가 정리한 것입니다.

구분현장 전문성이 맡는 일코드 검증이 필요한 일운영 권한이 필요한 일
핵심 질문무엇이 맞는 결과인가이 코드가 그 기준대로 동작하는가이 코드를 실제 데이터와 시스템에서 돌려도 되는가
대표 작업업무 규칙 정의, 예외 사례 제시, 결과 값 대조코드 리뷰, 자동 테스트, 취약점 분석(SSDF PW.7, PW.8 참고)접근 권한 부여, 배포 승인, 로그 보관, 장애 대응
적임자해당 업무를 오래 해 온 담당자개발자 또는 검증 도구와 절차IT 보안, 운영 조직, 데이터 소유 부서
확인 기준현장 수치와 일치하는지테스트 통과와 리뷰 기록이 남았는지승인권자와 되돌리는 방법이 정해졌는지

표를 쓰는 방법은 간단합니다. AI 코딩 과제마다 세 열에 담당자를 적어 보십시오. 한 칸이라도 비어 있다면 그 과제는 개인 실험의 범위를 넘는 순간부터 위험해집니다. 첫 칸만 채워진 과제는 프로토타입으로는 충분하지만, 업무 시스템에 연결하는 일은 나머지 칸을 채운 뒤로 미루는 편이 안전합니다.

팀 역량을 진단하는 다섯 가지 질문

아래 질문은 Anthropic이 전문성을 평가할 때 본 신호(지시의 구체성, 검증 요청, 오류 교정)를 기업 상황에 맞게 옮긴 AXMOS의 자체 점검표입니다. 통계적으로 검증된 척도가 아니므로 팀 토론의 출발점으로 쓰시기 바랍니다.

  1. 이 업무의 완료 기준을 세 줄 이내로 쓸 수 있습니까?
  2. AI가 낸 결과에서 틀린 값을 찾아낼 대조 기준이 있습니까?
  3. 자주 생기는 예외 사례를 다섯 가지 이상 말할 수 있습니까?
  4. 결과를 어느 시스템의 수치와 맞춰 봐야 하는지 알고 있습니까?
  5. 결과물이 잘못됐을 때 되돌리는 방법과 승인권자가 정해져 있습니까?

네 개 이상에 "예"라고 답했다면 현장 담당자가 AI와 함께 작은 프로토타입을 시도해 볼 수 있는 상태입니다. 두세 개라면 업무 기준부터 글로 정리하는 것이 순서입니다. 한 개 이하라면 도구를 늘리기 전에 업무의 완료 기준과 예외 목록을 만드는 일이 먼저입니다. 이 정리는 비개발자 AI 자동화 가이드에서 다룬 엑셀·PDF 업무 정리와 같은 방식으로 시작할 수 있습니다.

역량을 키우는 순서

  1. 현장 담당자가 자기 업무의 완료 기준과 예외를 문서로 작성합니다.
  2. AI가 만든 결과를 기존 수치와 대조하는 절차를 정합니다.
  3. 과제마다 코드 검증 담당자와 운영 승인 담당자를 지정합니다.
  4. 작은 과제에서 판정 결과와 수정 횟수를 기록해 다음 과제의 기준으로 씁니다.

조직 전체로 넓힐 때는 역할 설계도 함께 봐야 합니다. 역할 분담은 AI 도입 후 조직도는 어떻게 바뀌나에서, 파일럿을 운영으로 넘기는 단계는 한국 기업 AI 도입은 왜 PoC에서 멈추는가에서 이어서 볼 수 있습니다. 관련 글은 AX 전략 태그에 모아 두었습니다.

자주 묻는 질문

Q. 코딩을 못해도 AI 코딩에서 성공할 수 있나요?

Anthropic의 2026년 분석에서 코드를 만든 세션의 검증된 성공률은 소프트웨어 직군이 약 34%, 그 밖의 직군이 약 29%였습니다. 다만 직군은 세션 기록에서 추정한 값이라서 코딩 실력과 같지 않고, 만든 코드가 실제 업무에서 쓰였는지도 측정하지 않았습니다.

Q. AI 시대 핵심 역량은 코딩보다 도메인 지식인가요?

Anthropic 조사에서는 직군보다 세션에서 드러난 작업 전문성이 성공률과 더 크게 관련되어 있었습니다. 초보로 평가된 세션의 검증된 성공률은 15%, 중급 이상은 28~33%였습니다. 상관관계이므로 AXMOS는 이를 가설로 삼아 자기 조직의 업무로 다시 확인할 것을 권합니다.

Q. 도메인 지식이 있으면 개발자를 채용하지 않아도 되나요?

그렇게 판단하기는 어렵습니다. 이 조사는 개인이 에이전트에게 작업을 지시한 세션을 다루며, 운영 환경의 보안 검토, 장애 대응, 유지보수 책임은 측정 범위에 들어 있지 않습니다. 현장 전문가가 요구사항과 판정 기준을 맡고, 코드 검증과 운영은 별도 담당자가 맡는 분업을 먼저 검토하시기 바랍니다.

Q. 우리 팀의 도메인 지식 수준은 어떻게 진단하나요?

Anthropic은 지시의 구체성, 사용자가 검증을 요청한 항목, 오류를 누가 바로잡는지를 신호로 삼아 세션별 전문성을 평가했습니다. 기업에서는 업무의 완료 기준을 글로 쓸 수 있는지, AI 결과의 오류를 대조 기준으로 찾아낼 수 있는지를 직접 점검하는 편이 현실적입니다.

Q. AI 코딩 성공률 29%는 낮은 수치 아닌가요?

검증된 성공은 판정 결과에 더해 테스트 통과, 커밋, 사용자 확인 같은 객관적 신호가 있어야 인정하는 엄격한 기준입니다. 같은 코드 작성 세션에서 부분 성공 이상에 해당한 비율은 두 집단이 각각 89%와 88%였으므로, 어느 기준을 보느냐에 따라 해석이 달라집니다.

그래서 기업은 무엇을 해야 하나?

개발자가 아니어도 성공률이 비슷하다는 결과를 AXMOS는 "업무 기준을 아는 사람이 AI를 직접 쓸 수 있는 범위가 넓어졌다"는 신호로 읽습니다. AXMOS는 기업이 다음 세 가지를 먼저 정해야 한다고 봅니다.

  • 진단: 어떤 업무에 기준을 글로 쓸 수 있는 담당자가 있는지 확인합니다.
  • 실행 구조: 과제마다 현장 담당자, 코드 검증 담당자, 운영 승인 담당자를 나눠 지정합니다.
  • 검증: 세션 단위 성공에 그치지 않고, 결과물이 실제 업무에서 쓰였는지와 오류율·수정 횟수가 줄었는지를 측정합니다.

세 가지가 정해지면 어디까지 현장에 맡기고 어디부터 통제할지가 과제별로 분명해집니다. 우리 회사 업무에서 그 경계를 어디에 그어야 할지 함께 점검하고 싶으시다면 AX 진단 문의하기로 연락해 주십시오. AXMOS 소개는 AXMOS 알아보기에서 확인하실 수 있습니다.

출처

  1. Anthropic, Agentic coding and persistent returns to expertise (2026-06-16)
  2. Google Cloud Blog, Announcing the 2025 DORA Report (2025-09-24)
  3. DORA, State of AI-assisted Software Development 2025
  4. NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 (2022-02)