Anthropic 엔지니어와 연구자들이 Claude를 활용해 어떻게 생산성을 높이고 업무 방식을 바꾸고 있는지, 설문·인터뷰·사용 데이터 분석을 통해 살펴본다.
AI는 우리의 업무 방식을 어떻게 바꾸고 있을까? Anthropic은 이전 연구에서 AI의 경제적 영향력을 노동시장 전체 관점에서 살펴보며, 다양한 직무를 포괄해 분석했다. 그렇다면 AI 기술의 가장 초기 수용자들 가운데 하나인 우리 자신을 좀 더 깊이 들여다보면 어떨까?
이를 위해 2025년 8월, 우리는 132명의 Anthropic 엔지니어·연구자를 대상으로 설문을 실시하고, 53건의 심층 정성 인터뷰를 진행했으며, 내부 Claude Code 사용 데이터를 분석해 AI 활용이 Anthropic 내부에서 어떤 변화를 만들어내고 있는지 살펴보았다. 분석 결과, AI 활용은 소프트웨어 개발자의 업무 본질을 급격히 변화시키고 있으며, 이 과정에서 기대와 우려가 함께 나타나고 있음을 확인했다.
연구 결과, Anthropic의 일터는 큰 변화를 겪고 있었다. 엔지니어들은 훨씬 더 많은 일을 해내고, 자신의 전문 영역을 넘어 다양한 작업을 수행하는 ‘풀스택’에 가까워지고 있으며, 학습과 반복(iteration)의 속도를 높이고, 그동안 우선순위에서 밀렸던 작업까지 해내고 있다. 이렇게 업무 폭이 넓어진 만큼, 그에 따른 트레이드오프에 대한 고민도 커지고 있다. 일부는 깊이 있는 기술 역량이 약해지거나, Claude의 출력을 효과적으로 감독하는 능력이 떨어질 것을 우려하는 반면, 다른 이들은 보다 넓고 높은 수준에서 사고할 수 있는 기회를 반기고 있다. 어떤 사람들은 AI와 더 많이 협업하게 되면서 동료와의 협업은 줄어들었다고 느끼기도 했고, 언젠가 자신이 스스로를 자동화해 일자리를 잃게 될지도 모른다는 질문을 던지기도 했다.
AI를 개발하는 회사에서 AI의 영향을 연구한다는 것은 특권적인 위치를 반영한다. 우리 엔지니어들은 최첨단 도구에 먼저 접근하고, 비교적 안정적인 분야에서 일하며, 동시에 다른 산업에 영향을 미치는 AI 전환을 직접 만들고 있다. 그럼에도 우리는 이러한 연구를 진행하고 공개하는 것이 전체적으로 유익하다고 판단했다. Anthropic 내부 엔지니어에게 일어나고 있는 변화는, 더 넓은 사회적 전환을 가늠해볼 수 있는 하나의 선행 신호가 될 수 있기 때문이다. 우리의 발견은 여러 산업에서 미리 주목할 만한 도전과 고려사항을 시사한다(단, 한계점은 부록 섹션을 참고). 이 데이터가 수집된 시점에는 Claude Sonnet 4와 Claude Opus 4가 가장 강력한 모델이었고, 그 이후로도 성능은 계속 발전해왔다.
더 강력한 AI는 생산성 향상이라는 이점을 가져오는 동시에, 기술 전문성을 어떻게 유지할 것인지, 의미 있는 협업을 어떻게 지킬 것인지, 그리고 학습·멘토십·커리어 개발에 새로운 접근이 필요할지도 모르는 불확실한 미래에 어떻게 대비할 것인지에 대한 질문도 던진다. 우리는 아래 ‘미래를 향해’ 섹션에서, 이러한 질문들을 내부적으로 탐색하기 위해 시작한 초기적 시도를 논의한다. 또한 최근 게시한 AI 관련 경제 정책 아이디어 글에서는 더 넓은 정책 대응 가능성도 탐구했다.
이 섹션에서는 설문, 인터뷰, Claude Code 데이터에서 도출한 결과를 간략히 요약한다. 이후 섹션에서 보다 자세한 결과·방법론·한계를 설명한다.
우리는 Claude 사용 실태를 좀 더 구체적으로 이해하기 위해, 조직 전반의 132명 엔지니어·연구자를 대상으로 Claude 활용에 관한 설문을 진행했다. 설문은 내부 커뮤니케이션 채널과 다양한 팀(연구·제품 기능 모두 포함)을 향한 직접 메시지를 통해 배포했다. 부록의 한계 섹션에서 더 자세한 방법론을 설명하며, 다른 연구자들이 접근 방식을 평가하거나 자체 연구에 참고할 수 있도록 설문 문항 전체를 공유한다.
우리는 설문 응답자들에게, 다양한 유형의 코딩 작업에 Claude를 얼마나 자주 사용하는지 평가해 달라고 요청했다. 예를 들어:
가장 흔한 일상적 작업은 다음과 같았다. 직원의 55%가 매일 디버깅에 Claude를 사용했고, 42%는 코드 이해에, 37%는 신규 기능 구현에 매일 Claude를 사용했다. 사용 빈도가 상대적으로 낮은 작업은 상위 수준의 설계/플래닝(이런 작업은 사람 손에 남겨두는 경향이 있기 때문으로 보인다), 그리고 데이터 사이언스·프론트엔드 개발(전반적으로 덜 빈번한 작업이기 때문으로 보인다)이었다. 이 분포는 “Claude Code 사용 추세” 섹션에서 보고하는 Claude Code 실제 사용 데이터와도 대체로 일치한다.
그림 1. 다양한 코딩 작업(세로축)에 대해, 매일 Claude를 사용하는 사용자 비율(가로축).
직원들은 12개월 전에는 일상 업무의 28%에서 Claude를 사용하고 평균 20% 생산성 향상을 얻었다고 보고한 반면, 현재는 업무의 59%에서 Claude를 사용하며 평균 50% 생산성 향상을 경험한다고 답했다. (이는 우리가 엔지니어링 조직 전체에 Claude Code를 도입했을 때, 엔지니어 1인당 하루당 머지된 풀 리퀘스트(즉, 코드 변경이 실제 반영된 PR)의 수가 67% 증가한 데이터와 대략 부합한다.) 연도별 비교는 상당히 극적이다. 1년 사이 두 지표 모두 2배 이상 증가한 셈이다. 사용량과 생산성은 강하게 상관되어 있으며, 분포의 상위 14% 응답자는 Claude를 사용해 생산성을 100% 이상 끌어올렸다고 보고했다. 이들은 내부의 ‘파워 유저’라고 볼 수 있다.
단, 이(및 이후의 자기보고식 생산성 결과)에 대한 주의점이 있다. 생산성은 정확하게 측정하기 매우 어렵다(자세한 한계는 부록 참고). 최근 AI 연구 비영리 단체 METR의 연구에 따르면, 익숙한 코드베이스에서 AI와 함께 일하는 숙련 개발자들은 자신의 생산성 향상을 실제보다 과대평가하는 경향이 있었다. 다만, METR가 지적한 생산성 저하 요인(예: 대규모·복잡한 환경에서의 AI 성능 저하, 많은 암묵적 지식/맥락이 필요한 작업 등)은 우리가 직원들에게 물었을 때 Claude에 위임하지 않는 작업 유형과 밀접하게 대응한다(아래 AI 위임 접근법 섹션 참조). 여러 작업을 포괄한 자기보고식 생산성 향상은, METR 연구에서 다루지 않은 전략적 AI 위임 능력 개발의 효과를 반영했을 수도 있다.
흥미로운 패턴은, 직원들에게 “현재 Claude를 사용하는 작업 범주에서, Claude가 그 범주의 총 소요 시간과 산출물 양에 어떤 영향을 미쳤는지”를 물었을 때 나타난다. 거의 모든 작업 범주에서, 소요 시간은 전반적으로 감소하는 반면, 산출물 양은 더 크게 증가하는 경향을 보였다.
그림 2. 작업별(세로축) 소요 시간(왼쪽 패널)과 산출물 양(오른쪽 패널)에 대한 영향. 각 그래프의 가로축은, Claude를 사용하지 않았을 때와 비교해 Claude 보조 작업 범주에서의 자기보고식 시간/산출물 변화량을 의미한다. 음수는 감소, 양수는 증가, 점선은 변화 없음이다. 에러바는 95% 신뢰구간. 원의 크기는 각 평점 구간의 응답 수에 비례한다. 각 작업 범주에 대해 Claude를 사용한다고 응답한 사람만 포함했다.
그러나 원자료를 자세히 보면, 시간 변화 응답이 양극단으로 갈리는 경향이 있다. 즉, Claude 보조 작업에 더 많은 시간을 쓴다고 응답한 사람들도 상당수 있다.
이유는 무엇일까? 사람들은 대체로, Claude가 작성한 코드를 디버깅하고 정리하는 데 더 많은 시간을 써야 했다고 설명했다(예: "내가 직접 ‘감각으로’ 코딩하다 막다른 길에 다다를 때" 같은 상황). 또한 자신이 직접 작성하지 않은 코드를 이해하느라 인지적 부담이 커진다고 말했다. 반대로, 더 많은 시간을 쓰는 것이 가능하게 한다는 의미인 경우도 있다. 한 사람은 Claude 덕분에 “예전 같으면 바로 포기했을 작업에도 끝까지 매달릴 수 있게 되었다”고 말했고, 또 다른 사람은 새로운 코드베이스에서 더 철저하게 테스트하고 학습·탐색하는 데 시간을 더 쓸 수 있게 되었다고 설명했다. 전반적으로 볼 때, 빠르게 검증 가능한 작업을 잘게 쪼개 Claude에게 맡기는 사람들은 시간 절약을 경험하는 반면, Claude가 생성한 코드를 더 많이 디버깅해야 하거나 Claude가 더 많은 안내를 필요로 하는 도메인에서 일하는 사람들은 오히려 시간을 더 쓰는 경향이 있는 것으로 보인다.
또한 데이터만으로는, 절약된 시간이 어디에 재투입되고 있는지 알기 어렵다. 추가적인 엔지니어링 작업, 비엔지니어링 업무, Claude와의 상호작용이나 출력 검토, 혹은 업무 외 활동 등 다양한 가능성이 있다. 우리가 사용한 작업 분류 체계는 엔지니어의 시간 사용 방식을 완전히 포착하지 못한다. 더불어, 시간 절약 보고에는 자기보고 과정에 내재한 인식 편향이 반영되었을 수 있다. 이러한 효과를 구분하기 위해서는 추가 연구가 필요하다.
반면 산출물 양 증가는 더 명확하고 크다. 모든 작업 범주에서 순증가를 보인다. 이는 사람들이 개별 작업이 아니라 디버깅 전체 같은 작업 범주에 대해 응답했다는 점을 감안하면 자연스럽다. 즉, 전체적으로 디버깅에 쓰는 시간은 약간 줄이면서도, 디버깅 결과물의 양은 크게 늘릴 수 있다는 뜻이다. 생산성은 직접 측정하기 매우 어렵지만, 이 자기보고 데이터는 Anthropic에서 AI가 주로 산출물 양 증가를 통해 생산성을 높이고 있음을 시사한다.
우리가 특히 궁금했던 점은 다음이다. Claude는 질적으로 새로운 종류의 작업을 가능하게 하는가, 아니면 Claude가 도와주는 작업은 결국 언젠가(단지 더 느린 속도로) 사람이 했을 일인가?
직원들은 Claude 보조 작업의 27%는 없었더라면 수행되지 않았으리라고 추정했다. 엔지니어들은 대규모 프로젝트 확장, 있으면 좋은 기능(예: 인터랙티브 데이터 대시보드), 문서화와 테스트 같은 유용하지만 지루한 업무, 수작업으로는 비용 대비 효율이 낮은 탐색적 작업에 AI를 활용한다고 답했다. 한 사람은 이제 삶의 질을 떨어뜨리는 “자잘한 불편(papercuts)”을 더 많이 고칠 수 있게 되었다고 설명했다. 예를 들어 구조가 나쁜 코드를 리팩터링하거나, “다른 작업을 더 빨리 수행하도록 돕는 작은 도구”를 만드는 작업들이다. 우리는 실제 사용 데이터 분석에서도 이런 효과를 찾았고, 그 결과 Claude Code 작업의 8.6%가 ‘papercut 수정’에 해당함을 확인했다.
또 다른 연구자는 문제 해결을 위해 여러 버전의 Claude를 병렬로 실행해 서로 다른 접근법을 탐색했다고 설명했다.
사람들은 매우 유능한 모델 하나를, 더 빠른 차 한 대를 얻는 것처럼 생각하는 경향이 있어요. 하지만 말 한 마리가 아니라 말 백만 마리를 가지게 되면… 아주 다양한 아이디어를 동시에 시험해 볼 수 있어요… 이렇게 탐색 폭이 넓어지면 더 신나고 창의적인 작업이 가능해집니다.
이후 섹션에서 보겠지만, 이런 새로운 작업들은 대개 엔지니어들이 본래 전문 분야 밖의 과업을 수행할 수 있게 된 상황과 맞물려 있다.
엔지니어들은 Claude를 자주 사용하지만, 절반 이상은 자신의 업무 중 0~20%만을 Claude에 “완전히 위임”할 수 있다고 답했다. (응답자들이 ‘완전히 위임’이라는 표현을 서로 다르게 해석했을 수 있다는 점은 고려할 필요가 있다. 전혀 검증이 필요 없는 작업부터, 가벼운 감독만으로 충분히 신뢰할 수 있는 작업까지 의미 범위가 넓기 때문이다.) 이유를 묻자, 엔지니어들은 보통 Claude와 능동적·반복적으로 상호작용하며, 특히 복잡하거나 코드 품질 기준이 중요한 고위험 영역에서는 출력을 검증한다고 설명했다. 이는 엔지니어들이 Claude에 작업을 넘기되, 검증 없이 통째로 맡기지는 않으며, “완전 위임”의 기준을 높게 설정하고 있음을 보여준다.
설문 결과는 상당한 생산성 향상과 업무 패턴 변화를 보여주지만, 이러한 변화가 엔지니어들의 일상 경험에서는 어떻게 나타나는지에 대한 질문을 남긴다. 이러한 인간적 측면을 이해하기 위해, 우리는 설문 응답자 가운데 53명의 엔지니어·연구자를 대상으로 심층 인터뷰를 진행해 이들이 직장에서의 변화를 어떻게 생각하고 느끼는지 더 깊이 탐구했다.
엔지니어와 연구자들은 Claude를 워크플로에 생산적으로 통합하기 위한 다양한 전략을 개발하고 있다. 사람들은 대체로 다음과 같은 작업을 위임하는 경향이 있다.
사용자 맥락 밖이면서 복잡도가 낮은 작업:
“맥락은 잘 모르지만, 전체적인 복잡도는 낮다고 판단되는 작업에 Claude를 사용해요.”
“제가 겪는 인프라 문제 대부분은 난이도가 높지 않고 Claude가 충분히 처리할 수 있습니다… Git이나 리눅스를 잘 알지 못하는데… Claude가 이런 경험 부족을 잘 메워줍니다.”
쉽게 검증 가능한 작업:
“검증에 드는 노력이 생성에 드는 노력보다 크지 않은 모든 것에 대해서는, Claude가 정말 엄청나게 잘해줍니다.”
잘 정의되었거나 독립적인 작업:
“프로젝트의 서브 컴포넌트가 나머지와 충분히 분리되어 있다면, 먼저 Claude에게 맡겨 봅니다.”
코드 품질이 결정적이지 않은 작업:
“버려질 디버그용이나 연구용 코드라면 바로 Claude에게 갑니다. 개념적으로 어렵거나 특정 방식의 디버그 삽입이 필요하거나, 설계 문제가 얽혀 있으면 제가 직접 합니다.”
반복적이거나 지루한 작업:
“과제가 재미있을수록 Claude를 덜 쓰게 돼요. 반대로 하기 싫은 저항감이 큰 작업일수록… Claude와 대화를 시작하는 편이 훨씬 수월하더라고요.”
설문에서, 사람들은 Claude 보조 작업의 평균 44%가 스스로는 즐겁게 하지 못할 작업이라고 답했다.
프롬프트가 직접 실행보다 더 빠른 작업:
“걸리는 시간이 10분 미만일 것 같은 작업이라면… 굳이 Claude를 쓰지 않을 수도 있어요.”
“지금 가장 큰 걸림돌은 콜드 스타트 문제입니다. 콜드 스타트라는 건, 제 팀의 코드베이스가 어떻게 동작하는지에 대해 제가 내재적으로 갖고 있는 정보가 많은데 Claude는 기본적으로 그걸 모른다는 거예요… 시간을 들여 완벽한 프롬프트를 만들 수도 있겠지만, 그냥 제가 직접 해버리는 게 더 빠른 경우가 많아요.”
직원들이 위임 여부를 판단할 때 언급한 요인들은, AI 사용 시 생산성 저하를 설명했던 외부 연구(METR의 연구)에서 지적된 요인(코드베이스에 대한 높은 친숙도, 크고 복잡한 리포지토리 등)과도 유사하다. 이렇게 서로 다른 맥락에서 동일한 기준이 수렴한다는 사실은, AI 생산성 향상에서 적절한 과업 선정이 매우 중요하며, 향후 생산성 연구에서 엄밀히 통제되어야 함을 시사한다.
많은 사용자는 Claude 사용 과정에서, 시간이 지남에 따라 점점 더 복잡한 작업을 위임하는 방향으로 진화한다고 설명했다. “처음에는 Rust 같은 프로그래밍 언어에 대한 기초적인 질문에만 AI 도구를 썼는데… 요즘은 코딩 전반에 Claude Code를 사용하고 있어요.”
한 엔지니어는 이 신뢰 형성 과정을 Google Maps 같은 다른 기술 채택과 비교했다.
처음에는 제가 모르는 길에서만 [Google Maps]를 썼어요… 이건 제가 모르는 SQL을 작성해 달라고 Claude에 요청하는 건데, 제가 잘 아는 Python은 직접 짜던 시기와 비슷하죠. 그러다 제가 대략 아는 길에서도, 마지막 구간 정도만 모를 때 Google Maps를 쓰기 시작했어요… 지금은 출퇴근길처럼 매일 가는 길도 Google Maps를 씁니다. 다른 길로 가라고 하면, 그냥 그렇게 해요. 모든 옵션을 고려했을 거라 신뢰하는 거죠… 지금 Claude Code를 쓰는 방식도 이와 비슷합니다.
엔지니어들은 자신의 전문 영역 안에서 Claude를 쓰는 것이 좋은지, 아니면 영역 밖에서 쓰는 것이 좋은지에 대해 의견이 갈린다. 어떤 사람은 주변 영역(peripheral domain)에서 구현 시간을 아끼기 위해 Claude를 사용하고, 또 다른 사람은 “Claude가 하는 일을 끝까지 이해할 수 있는” 익숙한 분야에서만 사용하는 것을 선호한다. 한 시큐리티 엔지니어는, Claude가 제시한 해결책이 “겉보기엔 매우 똑똑하지만 위험한 방식”이라고 지적했다. 이는 “아주 유능한 주니어 엔지니어”가 제안할 수 있는 해법에 가깝고, 충분한 판단력과 경험이 없으면 문제를 알아채기 어려운 유형이었다.
다른 엔지니어들은 두 경우 모두에 Claude를 사용한다. 어떤 이는 실험적으로 “사실상 모든 코딩 문제에, 먼저 Claude가 한 번 시도해 보게 한다”고 말했고, 또 어떤 이는 자신이 해당 작업에 갖고 있는 전문성 수준에 따라 접근을 바꾼다고 설명했다.
제 전문 영역인 작업에는 가속기처럼 도구를 씁니다. 무엇을 기대해야 하는지 알고 있고, 에이전트를 효과적으로 이끌어 줄 수 있죠. 전문 영역에서 약간 벗어난 작업에도 사용합니다. 대략 무엇을 기대해야 하는지는 알지만, Claude가 제 기억이나 특정 정의에 대한 친숙함의 빈틈을 메워줄 수 있기 때문이에요.
제가 잘 아는 영역이라면, 좀 더 단호하게 Claude에게 무엇을 추적해야 하는지 지시합니다. 잘 모르는 영역이라면, Claude에게 전문가 역할을 맡겨 여러 옵션과 고려해야 할 지점들을 제안해 달라고 요청하곤 합니다.
사람들은 일관되게, 상위 수준 또는 전략적 사고가 필요한 작업, 조직 맥락이나 ‘취향(taste)’이 중요한 설계 결정에는 Claude를 사용하지 않는다고 답했다. 한 엔지니어는 “보통 상위 레벨의 사고와 설계는 직접 맡습니다. 신규 기능 개발이나 디버깅 중 위임 가능한 건 다 맡기죠”라고 말한다. 이는 설문 데이터에서도 드러나는데, 설계·플래닝 작업에서 보고된 생산성 향상이 가장 적었다(그림 2). 다만 많은 사람들은 이러한 위임 경계를 “움직이는 목표(moving target)”라고 표현했고, 모델 성능이 나아질수록 경계는 계속 재설정되고 있다(아래 Claude Code 사용 데이터에서도, 6개월 전보다 코드 설계/플래닝 비중이 상대적으로 늘어난 것을 볼 수 있다).
Claude 보조 작업 중 27%는 없었더라면 수행되지 않았을 것이라는 설문 결과는, 보다 넓은 패턴을 반영한다. 즉, 엔지니어들이 자신의 핵심 전문 분야 밖의 일을 AI를 통해 수행하고 있다는 점이다. 많은 직원들이 이전에는 전문성 밖이었던 작업을 스스로 해낸다고 보고했다. 백엔드 엔지니어가 UI를 만들고, 연구자가 시각화를 직접 만든다. 한 백엔드 엔지니어는 Claude와 함께 복잡한 UI를 구현한 과정을 이렇게 설명했다. “제가 직접 했으면 절대 이만큼 못했을 거예요. 아마 못 만들었을 겁니다, 적어도 마감 기한 안에는… [디자이너들이] ‘잠깐, 이거 네가 했다고?’라고 묻더라고요. 그래서 ‘아니요, Claude가 했어요. 저는 프롬프트만 쳤습니다’라고 답했죠.”
엔지니어들은 “더 풀스택에 가까워지고 있다… 이제는 프론트엔드나 트랜잭션 데이터베이스, API 코드에도 꽤 능숙하게 손댈 수 있다. 예전에는 겁나서 건드리지 못했을 영역들”이라고 말한다. 이런 역량 확장은 피드백 루프를 더 빠르고 촘촘하게 만들며, 학습 속도도 높인다. 한 엔지니어는 예전 같으면 “기능을 만들고, 회의를 잡고, 피드백을 받은 뒤 다시 수정하는 데 몇 주가 걸리던 과정이, 이제는 몇 시간짜리 워킹 세션으로 줄어들었다”고 설명했다. 동료들이 실시간으로 옆에 앉아 피드백을 줄 수 있기 때문이다.
전반적으로, 사람들은 빠른 프로토타이핑, 작업 병렬화, 반복 업무 감소, 더 높은 수준의 야심을 실현할 수 있게 된 점을 매우 고무적으로 받아들였다. 한 시니어 엔지니어는 “이 도구들은 분명히 주니어 엔지니어들을 더 생산적이게 하고, 더 대담하게 큰 프로젝트를 시도하게 만든다”고 말했다. 또 다른 사람은 Claude 덕분에 ‘시작하기’ 위한 활성화 에너지(activation energy)가 줄어든 덕에 미루기(procrastination)를 이기기 쉬워졌고, “문제를 풀기 위해 마음먹는 데 필요한 에너지를 극적으로 줄여, 훨씬 더 많은 일을 기꺼이 시도하게 만든다”고 했다.
동시에, 일부는 “위임량이 늘어날수록 내 기술이 퇴화할 수 있다”고 우려하며, 수작업 문제 해결 과정에서 일어나는 부수적(또는 ‘부대’) 학습 기회를 잃고 있다고 느꼈다.
스스로 나가서 어려운 버그를 디버깅하려고 하면, 문제 해결에 직접적으로 도움이 되지 않는 문서나 코드를 읽는 데도 시간을 쓰게 됩니다. 하지만 그 시간 동안 시스템이 어떻게 동작하는지에 대한 머릿속 모델을 쌓게 되죠. 지금은 Claude가 곧바로 문제 지점까지 안내해 주기 때문에, 이런 과정이 훨씬 줄어들었어요.
예전에는 새로운 도구를 쓰기 전에 설정 메뉴를 전부 탐색하면서 이 도구가 뭘 할 수 있는지 스스로 파악했어요. 그런데 지금은 AI에게 사용법을 물어보니, 깊은 전문성이 부족해졌어요. 팀원들과 이야기할 때, 예전에는 바로바로 떠올리던 것들을 이제는 AI에게 물어봐야 하죠.
Claude를 쓰면, 쉬운 예제를 직접 풀어보며 과제를 수행하는 방법을 배우는 단계를 건너뛰게 됩니다. 그러면 나중에 더 복잡한 예제를 풀 때 고생하게 될 수 있어요.
한 시니어 엔지니어는, 자신이 더 주니어였다면 이 점을 더 걱정했을 것 같다고 말했다.
저는 주로, 답이 어떻게 생겨야 할지 이미 알고 있는 경우에 AI를 씁니다. 저는 소프트웨어 엔지니어링을 ‘힘들게’ 해내는 과정을 통해 이런 감각을 길렀어요… 하지만 제가 커리어 초반이었다면, 모델 출력을 맹목적으로 받아들이지 않고 스스로의 역량을 계속 성장시키기 위해 훨씬 더 의식적으로 노력해야 한다고 느꼈을 겁니다.
코딩 기술 퇴화에 대한 우려가 큰 이유 중 하나는 “감독의 역설(paradox of supervision)” 때문이다. 앞서 언급했듯, Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 바로 그 AI 사용 덕분에 퇴화할 수 있는 코딩 역량이 필요하다.
솔직히 말하면, 저는 제 기술 세트 자체보다 감독·감시 문제를 훨씬 더 걱정합니다… 제 기술이 퇴화하거나 잘 발달하지 못하는 것이 실제로 문제되는 지점은, 제가 관심 있는 작업에 AI를 안전하게 사용하는 능력이지, 제가 그 작업을 독립적으로 수행하는 능력이 아니라고 생각해요.
이를 완화하기 위해 일부 엔지니어들은 의도적으로 AI 없이 연습하기도 한다. “Claude가 확실히 잘해줄 문제라도, 일부러 묻지 않고 직접 풀어볼 때가 가끔 있어요. 제 실력을 유지하는 데 도움이 되죠.”
어쩌면 소프트웨어 공학은 과거에도 여러 번 그랬듯, 더 높은 추상화 단계로 이동하고 있을지도 모른다. 초기 프로그래머들은 기계와 훨씬 가까운 수준에서 일했으며, 메모리를 수동으로 관리하고, 어셈블리 언어를 쓰거나 심지어 물리 스위치를 조작해 명령을 입력해야 했다. 시간이 지나면서 더 인간 친화적인 고수준 언어들이 등장해, 복잡한 저수준 연산을 자동으로 처리해 주었다. 특히 ‘바이브 코딩(vibe coding)’의 부상과 함께, 이제 영어가 새로운 프로그래밍 언어가 되어가는 것일 수도 있다. 한 직원은 예비 엔지니어들에게 “AI에게 코드를 쓰게 만드는 데 능숙해지고, 더 높은 수준의 개념과 패턴 학습에 집중하라”고 조언했다.
몇몇 직원은 이 변화가 더 높은 레벨에서 생각할 수 있게 해준다고 말한다. “코드 그 자체”보다는 “최종 제품과 최종 사용자”에 더 초점을 맞출 수 있다는 것이다. 어떤 사람은 이번 변화를, 과거에 컴퓨터 과학에서 링크드 리스트를 배우던 시절과 비교했다. 링크드 리스트는 지금은 고수준 언어들이 자동 처리하는, 메모리 구조의 기초에 해당한다. “그걸 배워서 정말 기뻐요… [하지만] 그런 저수준 조작을 직접 할 줄 아는 건 감정적으로 그리 중요하지 않아요. 저는 코드가 어떤 일을 가능하게 해주는지에 더 신경 쓰고 싶습니다.” 또 다른 엔지니어도 비슷한 비교를 했지만, 추상화에는 대가가 따른다고 지적했다. 고수준 언어로 올라오면서, 대부분의 엔지니어는 메모리 관리에 대한 깊은 이해를 잃었다는 것이다.
어떤 영역에서 계속 기술을 연마하는 것은 Claude를 더 잘 감독하고, 더 효율적으로 일할 수 있게 해준다(“제가 익숙한 영역에서는, 오히려 제가 직접 하는 것이 더 빠른 경우가 많다고 느껴요”). 그러나 이것이 얼마나 중요한지에 대해서는 엔지니어들 사이에서도 의견이 갈린다. 어떤 이들은 비교적 여유롭다.
저는 기술 퇴화에 대해 크게 걱정하지 않습니다. AI 덕분에 여전히 문제를 신중하게 사고해야 하고, 새로운 접근법도 배웁니다. 오히려 아이디어를 더 빠르게 실험하고 검증할 수 있게 되면서, 어떤 영역에서는 제 학습 속도가 더 빨라졌다고 느껴요.
다른 사람은 좀 더 현실적이다. “소프트웨어 엔지니어로서 제 기술은 확실히 퇴화하고 있어요… 하지만 필요하다면 다시 되살릴 수 있을 거고, 지금은 그 기술들을 예전만큼 필요로 하지 않습니다!” 또 다른 사람은 차트 작성 같은 덜 중요한 기술만 잃었을 뿐이며, “정말 중요한 코드들은 여전히 아주 잘 쓸 수 있다”고 말했다.
아마 가장 흥미로운 의견은, 전제가 틀렸을 수도 있다는 지적이다. “‘녹슬고 있다’는 프레이밍은 언젠가 코딩이 Claude 3.5 이전 시대로 되돌아갈 것이라는 가정에 기반해 있어요. 저는 그런 일은 벌어지지 않을 거라고 생각합니다.”
엔지니어들은 손으로 코딩하는 경험을 그리워하는지 여부에서 크게 갈린다. 어떤 사람들은 진정한 상실감을 느낀다. “저에게는 하나의 시대가 끝난 느낌입니다. 25년 동안 프로그래밍을 해왔고, 그 기술에 능숙하다는 감각이 제 직업적 만족감의 중요한 부분이었어요.” 또 다른 사람은 새로운 업무의 성격을 즐기지 못할까 걱정한다. “하루 종일 Claude에게 프롬프트를 던지는 일은 그렇게 재미있거나 만족스럽지 않아요. 음악을 틀어놓고 몰입해서 스스로 무언가를 구현하는 편이 훨씬 더 즐겁고 보람됩니다.”
어떤 사람들은 트레이드오프를 인정하고 받아들인다. “코드를 직접 쓰는 과정에서 그리운 부분이 분명 있어요. 리팩터링할 때 완전히 몰입하는 ‘젠(zen)’ 상태 같은 거요. 하지만 지금은 훨씬 더 생산적이기 때문에, 기꺼이 그걸 포기할 수 있습니다.”
Claude와 함께 반복 작업을 하는 것이 오히려 더 재미있다고 말하는 사람도 있다. 사람 동료에게는 하기 미안할 정도로 까다로운 피드백을, Claude에게는 마음껏 줄 수 있기 때문이다. 또 어떤 사람은 결과에 더 관심이 있다. 한 엔지니어는 이렇게 말했다.
지금쯤이면 두려움이나 지루함을 느낄 거라고 예상했어요… 그런데 실제로는 둘 다 별로 느끼지 않아요. 대신 훨씬 더 많은 일을 해낼 수 있다는 사실이 매우 신납니다. 저는 제가 정말 코딩 자체를 좋아한다고 생각했는데, 사실은 코딩을 통해 얻는 결과를 좋아했던 거죠.
사람들이 AI 보조를 기꺼이 받아들이는지, 아니면 손으로 코딩하던 시절을 그리워하는지는, 소프트웨어 엔지니어링에서 어떤 측면을 가장 의미 있게 느끼는지에 달려 있는 듯하다.
가장 두드러진 주제 가운데 하나는, 예전에는 동료에게 갔던 질문들이 이제는 먼저 Claude에게 간다는 점이다. “지금은 전보다 훨씬 더 많은 질문을 하지만, 그중 80~90%는 Claude에게 물어봅니다”라고 한 직원이 말했다. 이로 인해 일종의 필터링 메커니즘이 생겼다. Claude가 일상적인 질문을 처리하고, 동료들은 AI가 해결하지 못하는 더 복잡·전략적·맥락 의존적인 이슈에 집중하게 되는 것이다. (“팀에 대한 의존도는 80% 줄었지만, 남은 20%는 여전히 결정적으로 중요해서 결국 동료들에게 가게 됩니다.”) 사람들은 아이디어를 구상할 때에도 Claude에게 “아이디어를 던져 본다”고 말하는데, 이는 인간 동료와의 브레인스토밍과 비슷하다.
응답자의 약 절반은 팀 협업 패턴이 크게 변하지 않았다고 답했다. 한 엔지니어는 여전히 사람들과 만나 맥락을 공유하고 방향을 정하고 있으며, 가까운 미래에도 협업 자체는 여전히 많을 것이라 예상했다. 다만 “표준적인 집중 업무 대신, 훨씬 많은 ‘Claude와의 대화’를 하게 될 것”이라고 덧붙였다.
하지만 다른 사람들은 동료와의 상호작용이 줄었다고 느꼈다. (“요즘 저는 동료들보다 Claude와 더 많이 일합니다.”) 일부는 줄어든 사회적 마찰(“동료의 시간을 뺏는다는 미안함이 줄었다”)을 환영하지만, 다른 이들은 이 변화를 달가워하지 않는다. (“‘Claude에게 물어봤어?’가 기본 반응이 된 게 사실 좋지는 않아요. 저는 직접 사람들과 함께 일하는 걸 정말 좋아하고, 그걸 매우 중요하게 생각합니다.”) 또 다른 사람은 “사람들과 함께 일하는 게 좋고, 예전보다 그들을 덜 필요로 하게 된 게 슬프다”고 말했다.
여러 사람들은 이런 변화가 전통적인 멘토십 역학에도 영향을 미친다고 지적했다. 이제 “주니어들이 많이 받는 코칭을, 시니어 엔지니어가 아니라 Claude가 제공할 수 있기 때문”이다. 한 시니어 엔지니어는 이렇게 말했다.
주니어들이 예전만큼 자주 나에게 질문하러 오지 않는 건 아쉽습니다. 물론 그들은 예전보다 질문에 더 잘, 더 빠르게 답을 얻고 더 빨리 배우고 있긴 하지만요.
많은 엔지니어들은 자신의 역할이 코드 작성에서 AI 관리로 이동하고 있다고 느낀다. 엔지니어들은 점점 더 스스로를 “AI 에이전트의 매니저”로 인식하고 있으며, 어떤 사람은 이미 “항상 최소 몇 개의 Claude 인스턴스를 동시에 띄워 놓는다”고 말한다. 한 사람은 자신의 업무 중 “70% 이상이 새로운 코드를 직접 작성하기보다는, Claude가 생성한 코드를 리뷰/수정하는 쪽으로 옮겨갔다”고 평가했고, 또 다른 사람은 “미래에는 1, 5, 100개의 Claude가 한 일에 대한 책임을 지는 역할”을 맡게 될 것이라고 내다봤다.
장기적으로는 커리어 불확실성이 광범위하다. 엔지니어들은 이런 변화를, 업계 전반이 겪을 더 큰 전환의 전조로 보고 있으며, 많은 사람들이 “몇 년 뒤 내 커리어가 어떻게 변해 있을지 말하기 어렵다”고 답했다. 일부는 단기적 낙관과 장기적 불안 사이에서 갈등을 느낀다. “단기적으로는 낙관적이지만, 장기적으로는 AI가 결국 모든 걸 하게 되어서 나와 많은 사람들이 무의미해질 것 같다”고 말한 사람도 있었다. 또 다른 사람은 “매일 출근해서 스스로를 실직시키는 일을 하고 있는 느낌”이라고 더욱 직접적으로 표현했다.
좀 더 낙관적인 시각도 있다. 한 엔지니어는 “주니어 개발자들이 걱정되기는 하지만, 동시에 주니어들이야말로 새로운 기술에 가장 목마른 사람들”이라며, “직업의 전반적인 방향성은 대체로 낙관적”이라고 말했다. 그는 경험이 부족한 엔지니어들이 문제 있는 코드를 배포할 위험이 있지만, 더 나은 AI 가드레일, 더 풍부한 내장 교육 리소스, 그리고 실수로부터의 자연스러운 학습이 결합되어 시간이 지나면서 업계가 적응할 수 있을 것이라 주장했다.
미래 역할을 어떻게 그리는지, 그리고 어떤 적응 전략을 갖고 있는지 물었을 때, 일부는 더 깊은 전문화를 계획한다고 답했다(“AI 작업을 의미 있게 리뷰하는 기술을 기르는 데는 더 긴 시간과 더 높은 수준의 전문화가 필요할 것”). 또 다른 이들은, 앞으로 더 많은 인간 중심·전략적 업무에 집중할 것으로 예상했다(“사람들은 합의를 찾는 데 더 많은 시간을 쓰고, 구현은 AI에게 더 많이 맡기게 될 것”). 한 사람은 Claude를 커리어 개발에 직접 활용한다고 답했다. 업무와 리더십 역량에 대해 Claude에게 피드백을 요청하는 것이다. “무언가를 배우거나, 혹은 완전히 다 배우지 않고도 효과적으로 일하는 속도가 완전히 달라졌어요. 제 커리어에서 천장이 뚫려 버린 느낌입니다.”
전반적으로, 많은 사람들은 깊은 불확실성을 인정한다. “앞으로 어떤 구체적인 기술이 유용할지에 대한 확신이 매우 낮습니다.” 한 팀 리드는 “아무도 무슨 일이 일어날지 모른다… 중요한 건 정말 유연하게 적응할 수 있는 상태를 유지하는 것”이라고 말했다.
설문과 인터뷰 데이터는 Claude 사용 증가가 사람들이 더 빠르게 일하고 새로운 유형의 작업에 도전하도록 돕고 있다는 점을 보여준다. 동시에, AI 위임과 기술 개발을 둘러싼 긴장도 존재한다. 그러나 자기보고식 데이터만으로는 전체상을 볼 수 없다. 이를 보완하기 위해, 우리는 조직 내 Claude 사용 실제 데이터를 분석했다. 설문 응답자들이 Claude 사용의 대부분이 Claude Code라고 보고했기 때문에, 개인정보 보호 분석 도구 Clio를 활용해 2025년 2월과 8월 사이의 내부 Claude Code 대화 20만 건을 분석했다.
지난 6개월 동안 Claude Code 사용은 더 어려운 코딩 작업과 더 높은 자율성 방향으로 이동했다(그림 3).
그림 3. 2025년 2월과 8월 사이 Claude Code 사용 변화(가로축이 시점). 평균 작업 난이도(왼쪽 패널)는 시간이 지날수록 증가했고, 트랜스크립트당 최대 연속 도구 호출 수(가운데 패널)는 늘어났으며, 인간 발화 수(오른쪽 패널)는 감소했다. 에러바는 95% 신뢰구간. 사람들은 점점 더 많은 자율성을 Claude에 위임하고 있음을 시사한다.
이 사용 데이터는 설문 데이터와도 일치한다. 엔지니어들은 점점 더 복잡한 작업을 Claude에 위임하고 있고, Claude는 더 적은 감독으로도 이를 수행하고 있다. 이는 관측된 생산성 향상을 이끄는 요인일 가능성이 크다.
우리는 Claude Code 트랜스크립트를 하나 이상의 코딩 작업 유형으로 분류한 뒤, 지난 6개월 동안 각 작업 유형의 사용 비중이 어떻게 변화했는지 살펴보았다.
그림 4. 다양한 코딩 작업 유형(세로축)의 분포를, 전체 레코드 수 대비 비율(가로축)로 나타냈다. 6개월 전(핑크)과 현재(보라)를 비교했으며, 세로축은 2025년 2월 빈도 기준으로 정렬했다.
전체 작업 빈도 분포는, 자기보고식 설문 데이터와 대체로 유사하다. 2025년 2월과 8월 사이 가장 두드러진 변화는, 신규 기능 구현(14.3% → 36.9%)과 코드 설계/플래닝(1.0% → 9.9%)에 Claude를 사용하는 트랜스크립트 비중이 크게 늘었다는 점이다. Claude Code 작업 분포가 이러한 방향으로 이동했다는 것은, Claude가 이런 복잡한 작업을 더 잘 처리하게 되었음을 시사할 수도 있고, 혹은 실제 업무량 변화보다는 팀들이 Claude Code를 워크플로에 도입하는 방식이 달라졌기 때문일 수도 있다(더 자세한 한계는 부록 참조).
설문에서 엔지니어들이 “자잘한 삶의 질 개선 작업”에 더 많은 시간을 쓰게 되었다고 보고했는데, 사용 데이터 분석에서도 이에 상응하는 결과가 나왔다. 현재 Claude Code 작업의 8.6%가 ‘papercut 수정’으로 분류된다. 여기에 포함되는 작업은, 성능 시각화 도구 만들기나 유지보수를 위한 코드 리팩터링 같은 비교적 큰 작업부터, 터미널 단축키 생성 같은 소규모 작업까지 다양하다. 이는 엔지니어들이 보고한 생산성 향상에 기여할 수 있으며(이전에는 방치되던 품질 개선이 쌓이면서 시간이 지날수록 효율이 좋아질 수 있기 때문), 일상 업무에서의 마찰과 좌절감을 줄이는 데도 도움이 될 수 있다.
현재 시점 팀별 작업 차이를 살펴보기 위해, 분류 방식을 정교화해 8월 트랜스크립트 각각에 하나의 주요 코딩 작업 라벨을 부여하고, 이를 내부 팀(세로축) 기준으로 나누어 보았다. 스택형 막대그래프는 각 팀의 Claude Code 사용이 어떤 작업에 얼마나 쓰였는지를 보여준다.
그림 5. 각 가로 막대는 하나의 팀(세로축)을 나타내며, 색깔로 구분된 구간은 해당 팀의 Claude Code 사용이 어떤 코딩 작업에 쓰였는지를 비율(가로축)로 보여준다. 맨 위 “All Teams” 막대는 전체 분포를 나타낸다.
“All Teams” 막대는 전체 분포를 보여주며, 가장 흔한 작업은 신규 기능 구현, 디버깅, 코드 이해였다. 이는 팀별 비교를 위한 기준선이 된다.
팀별로 눈에 띄는 패턴은 다음과 같다.
이러한 팀별 패턴의 상당수는, 설문·인터뷰에서 관찰한 것과 같은 **역량 확장(capability expansion)**을 보여준다. 해당 팀이 원래는 시간이나 기술 부족으로 하지 못했을 작업을 수행할 수 있게 해주는 것이다. 예를 들어 프리트레이닝 팀은 이전보다 훨씬 많은 추가 실험을 실행할 수 있게 되었고, 비기술직 직원들도 코드 오류를 스스로 해결할 수 있게 되었다. 데이터는 팀들이 Claude를 핵심 업무에 사용하는 동시에(예: 인프라 팀은 인프라·DevOps 작업에 가장 많이 사용), 그 핵심 업무를 보완·증폭하는 방식으로도 활용하고 있음을 보여준다(예: 연구자들은 데이터 시각화를 위한 프론트엔드 개발에 Claude를 사용). 이는 Claude가 모든 사람이 자신의 역할에서 더 풀스택에 가까워지도록 돕고 있음을 시사한다.
지난 1년 동안 Anthropic 직원들은 Claude 사용을 크게 늘려 왔다. Claude는 기존 작업을 가속할 뿐만 아니라, 새로운 코드베이스를 더 빨리 이해하고, 반복 업무를 줄이고, 새로운 도메인에 진출하고, 그동안 미뤄졌던 개선 과제를 수행하도록 돕고 있다. Claude가 더 자율적이고 유능해질수록, 엔지니어들은 AI 위임의 새로운 방식을 탐색하는 동시에, 미래에 어떤 기술이 필요할지에 대한 질문에도 직면하고 있다. 이러한 변화는 분명한 생산성·학습상의 이점을 가져오는 한편, 소프트웨어 엔지니어링 직업의 장기적 궤적에 대한 진지한 불확실성도 동반한다. 이 변화는 일부 엔지니어들이 말했듯, 과거 저수준에서 고수준 언어로의 전환이나, 개별 기여자(IC)에서 매니저로의 전환과 비슷한 패턴을 따를까? 아니면 그보다 더 나아갈까?
아직은 초기 단계다. Anthropic 내부에는 조기 수용자가 많고, 기술 환경은 빠르게 변하고 있으며, 지금의 발견이 다른 조직이나 맥락에 곧바로 일반화되지는 않을 수 있다(한계는 부록 참조). 이 연구 역시 그 불확실성을 반영한다. 결과는 미묘하고, 단일한 합의나 명확한 지침이 도출되지는 않는다. 하지만, 앞으로 이 변화를 어떻게 신중하고 효과적으로 헤쳐 나갈 수 있을지에 대한 중요한 질문을 던진다.
우리는 이 초기 작업을 바탕으로 몇 가지 후속 조치를 취하고 있다. Anthropic 엔지니어·연구자·리더십과 대화를 이어가며, 이번 연구가 제기한 기회와 도전을 다루고 있다. 여기에는 팀이 함께 모이고 협업하는 방식을 재검토하고, 전문성 개발을 어떻게 지원할지, 그리고 AI 리터러시(활용 역량) 프레임워크에 기반해 AI 보조 업무를 위한 모범 사례를 어떻게 정립할지 등이 포함된다. 또한 엔지니어뿐 아니라 조직 전체 역할에 대한 AI 전환의 영향을 이해하기 위해 연구 범위를 확장하고 있으며, CodePath와 같은 외부 단체가 AI 보조 시대에 맞게 컴퓨터 과학 교육과정을 조정하는 것을 지원하고 있다. 앞으로는 AI 역량이 더욱 발전함에 따라 중요성이 커질 수 있는 구조적 접근법도 고려 중이다. 예를 들어 조직 내 역할 진화 경로를 새로 설계하거나 재교육(reskilling) 기회를 제공하는 방안 등이 이에 해당한다.
우리는 2026년에, 내부 논의가 더 무르익는 대로 보다 구체적인 계획을 공유할 예정이다. Anthropic은 책임 있는 직장 전환을 위한 하나의 실험실이 되고자 한다. 우리는 AI가 업무를 어떻게 바꾸는지 연구하는 것에 그치지 않고, 이 전환을 어떻게 신중하게 탐색해 나갈 수 있을지 스스로에게서부터 실험해 보려 한다.
이 글을 인용하려면 아래 Bibtex 키를 사용할 수 있다.
bibtex@online{huang2025aiwork, author = {Saffron Huang and Bryan Seethor and Esin Durmus and Kunal Handa and Miles McCain and Michael Stern and Deep Ganguli}, title = {How AI Is Transforming Work at Anthropic}, date = {2025-12-02}, year = {2025}, url = {https://anthropic.com/research/how-ai-is-transforming-work-at-anthropic/}, }
이 프로젝트는 Saffron Huang이 리드했으며, 설문·인터뷰·데이터 분석을 설계·실행하고, 도표를 제작했으며, 블로그 글을 집필했다. Bryan Seethor는 설문·인터뷰 설계를 공동으로 진행하고, 설문·인터뷰 데이터 수집을 공동 리드했으며, 인터뷰 주제 분석과 글 작성에 기여하고, 프로젝트 타임라인을 관리했다. Esin Durmus는 실험 설계에 기여하고 전반에 걸쳐 구체적인 방향과 피드백을 제공했다. Kunal Handa는 인터뷰 프로세스를 위한 인프라를 지원했다. Deep Ganguli는 핵심적인 조언과 조직적 지원을 제공했다. 모든 저자는 전반적인 방향 설정과 세부 피드백에 기여했다.
추가로, Ruth Appel, Sally Aldous, Avital Balwit, Drew Bent, Zoe Blumenfeld, Miriam Chaum, Jack Clark, Jake Eaton, Sarah Heck, Kamya Jagadish, Jen Martinez, Peter McCrory, Jared Mueller, Christopher Nulty, Sasha de Marigny, Sarah Pollack, Hannah Pritchett, Stuart Ritchie, David Saunders, Alex Tamkin, Janel Thamkul, Sar Warner, Heather Whitney에게도 유익한 아이디어, 토론, 피드백, 지원에 감사드린다. 도표 일러스트레이션을 담당한 Casey Yamaguma에게도 감사의 뜻을 전한다. 또한 Anton Korinek, Ioana Marinescu, Silvana Tenreyro, Neil Thompson이 제공한 생산적인 코멘트와 토론에도 감사드린다.
이번 설문 결과에는 몇 가지 방법론적 한계가 있다. 우리는 편의표집과 목적표집을 함께 사용했다(조직 전반의 대표성을 확보하기 위해). 여러 내부 Slack 채널에 설문을 게시해 68개의 응답을 받았고, 조직도에서 연구/제품 기능에 걸쳐 다양한 20개 팀을 선정해 각 팀별로 5~10명에게 직접 메시지를 보냈다(총 207명에게 연락). 이 가운데 31%가 응답해 추가로 64개의 응답을 얻었다. 인터뷰는 설문에 응답한 사람들 가운데 가장 먼저 응답한 53명을 대상으로 진행했다. 이 과정에서 선택 편향이 발생했을 가능성이 크다. 특히 Claude 사용에 적극적이거나(혹은 부정적이거나) 강한 의견을 가진 사람들이 더 많이 응답했을 수 있고, 보다 중립적인 경험을 가진 사람들은 과소대표되었을 수 있다.
또한 응답은 사회적 바람직성 편향의 영향을 받았을 수 있다. 응답이 익명으로 수집되지 않았고, 모든 응답자가 Anthropic 직원이기 때문에, 사람들이 Claude의 영향을 실제보다 긍정적으로 평가했을 가능성이 있다. 12개월 전의 생산성과 사용 패턴을 회상하게 한 점 역시, 최근 경험에 치우친 회상 편향을 유발할 수 있다. 게다가 앞서 논의했듯, 일반적으로 생산성을 추정하는 것은 매우 어렵기 때문에, 자기보고식 결과는 어느 정도 의심을 가지고 봐야 한다. 이런 자기 인식은 보다 객관적인 Claude Code 사용 데이터와 함께 해석되어야 하며, 향후 연구에서는 익명 데이터 수집과 더 엄밀하게 검증된 측정 도구를 사용하는 것이 바람직하다.
Claude Code 분석은 시점별 비례표집(proportionate sampling)을 사용했기 때문에, 작업 분포의 상대적 변화만 측정할 수 있고, 실제 작업량의 절대적 변화는 알 수 없다. 예를 들어, 기능 구현 비중이 Claude Code 사용 내에서 14%에서 37%로 늘었다고 해도, 실제 기능 구현 업무의 총량이 늘었다는 뜻은 아니다.
마지막으로, 이 연구는 2025년 8월에, Claude Sonnet 4와 Claude Opus 4가 최신 모델이던 시점에 수행되었다. AI 발전 속도가 매우 빠르기 때문에, 우리가 관찰한 패턴은 더 강력한 모델이 출시되면서 이미 달라지고 있을 수 있다.
