AI가 바꿔 놓은 Anthropic의 업무 방식
AI는 우리의 일하는 방식을 어떻게 바꾸고 있을까요? Anthropic은 이전 연구에서 다양한 직군을 아우르며 AI가 노동 시장 전체에 미치는 경제적 영향을 분석한 바 있습니다. 그렇다면 AI 기술을 가장 먼저 받아들인 사람들, 바로 우리 자신을 좀 더 깊이 들여다보면 어떨까요?
시선을 안으로 돌려, 2025년 8월 Anthropic 엔지니어 및 연구원 132명을 대상으로 설문 조사를 실시하고, 53건의 심층 인터뷰를 진행했으며, 내부 Claude Code 사용 데이터를 분석해 AI가 Anthropic의 업무를 어떻게 변화시키고 있는지 살펴봤습니다. 그 결과, AI가 소프트웨어 개발자의 업무 본질을 근본적으로 바꾸고 있으며, 이에 대한 기대와 우려가 공존하고 있음을 확인했습니다.
이번 연구에서 드러난 핵심 변화는 다음과 같습니다. 엔지니어들의 업무 생산량이 크게 늘었고, 자기 전문 분야 외의 업무도 소화할 수 있는 '풀스택(full-stack)' 역량이 확대되고 있으며, 학습과 반복 작업의 속도가 빨라졌고, 기존에 미뤄둔 작업까지 처리하고 있습니다. 이처럼 업무 범위가 넓어지면서 트레이드오프에 대한 고민도 커지고 있습니다. 일부는 깊은 기술 역량을 잃거나 Claude의 산출물을 효과적으로 검토하는 능력이 약해질 수 있다고 우려하는 반면, 다른 이들은 더 넓은 시각에서 한 단계 높은 수준으로 사고할 기회가 생겼다고 반기고 있습니다. AI와 협업이 늘면서 동료와의 협업은 줄었다는 목소리도 있었고, 결국 자기 일자리를 스스로 자동화하는 게 아닌지 고민하는 사람도 있었습니다.
AI를 만드는 회사에서 AI의 영향을 연구하는 만큼, 이 연구가 특수한 위치에서 이루어졌다는 점은 인식하고 있습니다. Anthropic 엔지니어들은 최첨단 도구를 일찍 접할 수 있고, 비교적 안정적인 업계에 종사하며, 다른 산업에 영향을 미치는 AI 전환에 스스로 기여하고 있기 때문입니다. 그럼에도 이 결과를 연구·공개하는 것이 전반적으로 유의미하다고 판단했습니다. Anthropic 엔지니어에게 벌어지고 있는 일이 더 넓은 사회적 변화를 미리 보여주는 선행 지표가 될 수 있기 때문입니다. 연구 결과는 여러 산업 분야에서 조기 대응이 필요할 수 있는 과제와 시사점을 제시하고 있습니다(단, 부록의 한계점 섹션을 함께 참고해 주세요). 이 데이터가 수집된 시점에는 Claude Sonnet 4와 Claude Opus 4가 가장 뛰어난 모델이었으며, 이후로도 모델 성능은 계속 발전하고 있습니다.
더 뛰어난 AI는 생산성 향상을 가져다주지만, 기술 전문성 유지, 의미 있는 협업 보존, 그리고 AI 기반 업무 환경에서 학습·멘토십·경력 개발에 새로운 접근 방식이 필요할 수 있는 불확실한 미래에 대한 준비라는 과제를 함께 제기합니다. 이 질문들에 대해 내부적으로 탐색 중인 초기 조치는 아래 '향후 계획' 섹션에서 다루겠습니다. 또한 최근 블로그 게시물에서 AI 관련 경제 정책 아이디어를 통해 정책적 대응 방안도 검토한 바 있습니다.
이 섹션에서는 설문 조사, 인터뷰, Claude Code 데이터에서 도출한 결과를 간략히 요약합니다. 세부 결과, 방법론, 한계점은 이어지는 섹션에서 자세히 다룹니다.
설문 조사 데이터
정성 인터뷰
Claude Code 사용 추세
Anthropic 전 조직의 엔지니어 및 연구원 132명을 대상으로 Claude 사용 실태를 설문 조사해, 일상 업무에서 구체적으로 어떻게 활용하고 있는지 파악했습니다. 내부 커뮤니케이션 채널과 다양한 팀 직원에 대한 직접 연락을 통해 설문을 배포했으며, 연구·제품 양쪽 기능을 대표하는 다양한 팀을 포함시켰습니다. 부록에 방법론 세부사항을 포함한 한계점 섹션을 수록했으며, 다른 연구자들이 접근 방식을 평가하고 자체 연구에 활용할 수 있도록 설문 문항도 공개합니다.
설문 대상 엔지니어와 연구원에게 다양한 코딩 작업 유형별 Claude 사용 빈도를 평가해 달라고 요청했습니다. 작업 유형에는 '디버깅'(Claude를 활용한 코드 오류 수정), '코드 이해'(기존 코드를 Claude가 설명해 사용자의 코드베이스 이해를 돕는 것), '리팩터링'(Claude를 활용한 기존 코드 구조 개선), '데이터 사이언스'(예: Claude로 데이터셋 분석 및 차트 생성) 등이 포함됩니다.
아래는 가장 빈번한 일일 작업입니다. 직원의 55%가 매일 디버깅에 Claude를 사용했고, 42%는 코드 이해에, 37%는 새 기능 구현에 매일 Claude를 활용했습니다. 상대적으로 덜 자주 사용되는 작업은 고수준 설계/기획(사람이 직접 하려는 경향이 있는 작업이므로)과 데이터 사이언스 및 프론트엔드 개발(전체적으로 덜 일반적인 작업이므로)이었습니다. 이는 'Claude Code 사용 추세' 섹션에서 보고한 실제 사용 데이터 분포와 대체로 일치합니다.

직원 자가 보고에 따르면, 12개월 전에는 일일 업무의 28%에서 Claude를 사용하고 생산성 향상 효과는 +20% 수준이었으나, 현재는 업무의 59%에서 Claude를 활용하며 평균 +50%의 생산성 향상을 달성하고 있습니다. (이는 엔지니어링 조직 전체에 Claude Code를 도입한 이후 엔지니어 1인당 일일 병합 풀 리퀘스트(merged pull request), 즉 코드에 성공적으로 반영된 변경 사항이 67% 증가한 수치와 대체로 부합합니다.) 전년 대비 비교 결과는 상당히 극적입니다. 두 지표 모두 1년 만에 2배 이상 증가했음을 시사합니다. 사용량과 생산성 간에는 강한 상관관계가 있으며, 분포의 상위 극단에서는 응답자의 14%가 Claude를 통해 100% 이상의 생산성 향상을 보고했습니다. 이들이 내부 '파워 유저'에 해당합니다.
이 결과(그리고 아래의 다른 자가 보고 생산성 결과)에는 단서를 달아야 합니다. 생산성은 정밀하게 측정하기 어렵기 때문입니다(더 자세한 한계점은 부록 참고). AI 연구 비영리 기관인 METR의 최근 연구에 따르면, 잘 알고 있는 코드베이스에서 AI를 활용하는 숙련 개발자들이 AI로 인한 생산성 향상을 과대 추정하는 것으로 나타났습니다. 다만, METR이 예상보다 낮은 생산성의 원인으로 지목한 요인들(예: 대규모·복잡한 환경에서 AI 성능 저하, 많은 암묵지/맥락이 필요한 경우)은 Anthropic 직원들이 Claude에 맡기지 않는다고 응답한 작업 유형과 정확히 일치합니다(아래 AI 위임 접근법 참고). 전체 작업에 걸쳐 자가 보고된 우리의 생산성 향상은, METR 연구에서 고려하지 않았던 전략적 AI 위임 역량을 직원들이 개발해 온 결과일 수 있습니다.
직원들에게 Claude를 현재 사용 중인 작업 유형별로, Claude가 해당 유형의 전체 소요 시간과 산출물 규모에 어떤 영향을 주는지 물었을 때, 흥미로운 생산성 패턴이 나타납니다. 거의 모든 작업 유형에서 소요 시간은 순감소하고, 산출물 규모는 그보다 더 크게 순증가합니다:

하지만 원시 데이터를 더 깊이 들여다보면, 시간 절감 응답이 양극단에 몰려 있습니다. Claude를 활용하는 작업에 오히려 시간이 더 걸리는 사람도 상당수입니다.
왜 그럴까요? 많은 이가 Claude가 생성한 코드의 디버깅과 정리에 추가 시간이 들고(예: "바이브 코딩을 하다 막다른 골목에 몰렸을 때"), 직접 작성하지 않은 코드를 이해하는 데 인지적 부담이 크다고 설명했습니다. 일부는 '활성화' 측면에서 오히려 더 많은 시간을 쓰게 됐다고 말합니다. "이전에는 바로 포기했을 작업도 끈기 있게 밀어붙일 수 있게 됐다"는 사람도 있었고, 더 철저한 테스트와 새 코드베이스에서의 학습·탐색에 시간을 쓰게 됐다는 사람도 있었습니다. 종합하면, 빠르게 검증할 수 있는 작업을 Claude에 맡기는 엔지니어는 시간을 절약하는 반면, AI가 생성한 코드를 디버깅하거나 Claude의 가이드가 더 많이 필요한 영역에서 작업하는 엔지니어는 오히려 시간이 늘어나는 것으로 보입니다.
절약된 시간이 어디에 재투자되는지도 데이터만으로는 명확하지 않습니다. 추가 엔지니어링 작업에 쓰이는지, 비엔지니어링 업무에 쓰이는지, Claude와의 상호작용이나 산출물 검토에 쓰이는지, 아니면 업무 외 활동에 쓰이는지 구분하기 어렵습니다. 현재 작업 분류 체계가 엔지니어의 시간 배분 방식을 모두 포착하지는 못합니다. 또한 시간 절약 수치에는 자가 보고에 따른 인식 편향이 반영됐을 수 있습니다. 이러한 효과를 분리하려면 추가 연구가 필요합니다.
산출물 규모 증가는 보다 직관적이고 뚜렷합니다. 모든 작업 유형에서 더 큰 순증가가 나타납니다. 이 패턴은, 응답이 개별 작업이 아니라 작업 유형(예: '디버깅' 전체)을 기준으로 이루어졌다는 점을 고려하면 자연스럽습니다. 즉, 디버깅이라는 카테고리에 투입하는 전체 시간은 약간 줄이면서도 디버깅 산출물은 훨씬 더 많이 만들어낼 수 있다는 것입니다. 생산성을 직접 측정하기는 매우 어렵지만, 이 자가 보고 데이터는 Anthropic에서의 AI 기반 생산성 향상이 주로 산출물 규모 확대를 통해 이루어지고 있음을 시사합니다.
궁금했던 점이 있습니다. Claude가 질적으로 완전히 새로운 종류의 업무를 가능하게 하는 걸까요, 아니면 Claude의 도움을 받는 업무가 결국 (더 느리더라도) 직원들이 언젠가 처리했을 일인 걸까요?
직원들은 Claude 지원 업무의 27%가 Claude 없이는 수행되지 않았을 것이라고 추정했습니다. 엔지니어들은 프로젝트 확장, 있으면 좋은 기능(예: 인터랙티브 데이터 대시보드), 문서화나 테스트 같은 유용하지만 지루한 작업, 수작업으로는 비용 대비 효율이 맞지 않는 탐색적 작업 등에 AI를 활용한다고 말했습니다. 한 직원은 이전에는 삶의 질을 저해했지만 미뤄뒀던 '자잘한 불편'을 이제 더 많이 해결할 수 있다고 설명했습니다. 예를 들어 구조가 엉망인 코드를 리팩터링하거나 "다른 작업을 더 빠르게 완수하는 데 도움이 되는 작은 도구"를 만드는 식입니다. 실제 사용 데이터 분석에서도 이를 확인할 수 있었으며, Claude Code 작업의 8.6%가 '자잘한 불편 해결'에 해당하는 것으로 나타났습니다.
한 연구원은 여러 Claude 인스턴스를 동시에 실행해, 각각 다른 접근 방식으로 문제를 탐색했다고 설명했습니다:
사람들은 초고성능 모델을 하나의 인스턴스, 말하자면 더 빠른 자동차 한 대 정도로 생각하는 경향이 있다. 하지만 말 백만 마리를 가진 것과 같아서… 서로 다른 아이디어를 동시에 시험할 수 있다… 그 넓은 탐색 폭이 있으면 더 흥미롭고 창의적이 된다.
이어지는 섹션에서 살펴보겠지만, 이런 새로운 업무에는 엔지니어가 핵심 전문 분야 외의 작업에 도전하는 경우가 많습니다.
Claude를 자주 사용하고 있음에도 불구하고, 절반 이상의 엔지니어가 Claude에 '완전히 위임'할 수 있는 업무는 0~20%에 불과하다고 답했습니다. ('완전히 위임'의 해석에는 응답자마다 편차가 있을 수 있습니다. 검증이 전혀 필요 없는 작업부터, 가벼운 감독만으로도 충분히 신뢰할 수 있는 작업까지 범위가 다양합니다.) 그 이유를 설명할 때, 엔지니어들은 Claude와 능동적·반복적으로 작업하며 산출물을 검증한다고 말했습니다. 특히 복잡한 작업이나 코드 품질 기준이 엄격한 고위험 영역에서 그렇습니다. 이는 엔지니어들이 검증 없이 작업을 넘기기보다 Claude와 긴밀하게 협업하며 결과물을 점검하고, '완전한 위임'에 대해 높은 기준을 적용하고 있음을 보여줍니다.
설문 결과가 상당한 생산성 향상과 업무 패턴 변화를 보여주지만, 엔지니어들이 일상에서 이러한 변화를 실제로 어떻게 체감하고 있는지에 대한 의문이 남습니다. 수치 이면의 인간적 측면을 이해하기 위해, 설문에 응답한 Anthropic 엔지니어 및 연구원 53명과 심층 인터뷰를 진행하고, 이들이 직장 내 변화에 대해 어떻게 생각하고 느끼는지 더 깊이 파악했습니다.
엔지니어와 연구원들은 워크플로에서 Claude를 생산적으로 활용하기 위한 다양한 전략을 개발해 가고 있습니다. 대체로 다음과 같은 특성의 작업을 위임하는 경향이 있습니다:
| 사용자의 맥락 밖에 있으면서 동시에 복잡도가 낮은 작업: "내 맥락이 부족하지만 전체적인 복잡도도 낮다고 판단되는 작업에 Claude를 쓴다." "내가 마주치는 인프라 문제 대부분은 어렵지 않아서 Claude가 처리할 수 있다… Git이나 Linux를 잘 모르는데… Claude가 이 분야의 경험 부족을 잘 보완해 준다." |
| 검증이 쉬운 작업: "검증에 드는 노력이 생성 노력에 비해 크지 않은 모든 작업에서 정말 놀라울 정도로 뛰어나다." |
| 명확하게 정의되거나 독립적인 작업: "프로젝트의 하위 컴포넌트가 나머지와 충분히 분리되어 있으면, Claude에 먼저 시도시킨다." |
| 코드 품질이 중요하지 않은 작업: "일회성 디버깅이나 연구용 코드면 바로 Claude에 맡긴다. 개념적으로 어렵거나 아주 특수한 디버그 인젝션이 필요한 경우, 또는 설계 문제라면 직접 한다." |
| 반복적이거나 지루한 작업: "작업이 재미있을수록 Claude를 안 쓰게 된다. 반대로 진입 장벽이 크게 느껴지면… Claude와 그 작업에 대해 대화를 시작하는 게 더 쉽다." 설문에서 응답자들은 Claude 지원 업무의 평균 44%가 직접 하기 싫은 작업이었다고 답했습니다. |
| 프롬프트를 입력하는 것이 직접 실행보다 빠른 작업: "10분 이내에 끝날 것 같은 작업은… 굳이 Claude를 쓰지 않는다." "콜드 스타트 문제가 현재 가장 큰 걸림돌이다. 콜드 스타트라는 건, 우리 팀 코드베이스의 작동 방식에 대해 내가 내재적으로 알고 있는 정보가 많은데 Claude는 기본적으로 그걸 모른다는 뜻이다… 완벽한 프롬프트를 만들려고 반복할 바에는 그냥 직접 하겠다." |
직원들이 위임 결정에서 언급한 이러한 요인들은, METR의 외부 연구에서 AI 관련 생산성 저하를 설명하는 요인(예: 개발자의 높은 코드베이스 숙련도, 대규모·복잡한 리포지토리)과 유사했습니다. 인터뷰 전반에서 이런 위임 기준이 수렴한다는 것은, 적절한 작업 선택이 AI 생산성 향상의 핵심 요인임을 시사합니다(향후 생산성 연구에서 이 요인을 면밀히 통제할 필요가 있습니다).
많은 사용자가 시간이 지남에 따라 점점 더 복잡한 작업을 위임하는 과정을 거쳤다고 설명합니다. "처음에는 Rust 프로그래밍 언어에 대한 기본적인 질문에 AI 도구를 썼다… 최근에는 모든 코딩에 Claude Code를 사용하고 있다."
한 엔지니어는 이 신뢰 확장 과정을 구글 맵스 같은 다른 기술의 도입과 비교했습니다:
처음에는 모르는 경로에만 [구글 맵스를] 썼다… 내가 모르는 SQL은 Claude에 맡기면서 내가 아는 Python은 맡기지 않았던 것과 같다. 그러다 대체로 아는 경로인데 마지막 구간만 모를 때도 쓰기 시작했다… 지금은 매일 출퇴근길에도 항상 구글 맵스를 쓴다. 다른 길을 안내하면 그냥 따르고, 모든 옵션을 고려했을 거라고 신뢰한다… 오늘날 Claude Code도 비슷하게 쓰고 있다.
Claude를 자기 전문 분야 안에서 사용할지, 밖에서 사용할지에 대해서는 엔지니어들의 의견이 갈립니다. 일부는 구현 시간을 절약하기 위해 '주변부' 영역에서 사용하고, 다른 이들은 산출물을 검증할 수 있는 익숙한 영역을 선호합니다("Claude가 하는 일을 내가 완전히 이해할 수 있는 방식으로 사용한다"). 한 보안 엔지니어는, Claude가 제안한 솔루션이 "위험할 정도로 똑똑한, 재능 있는 주니어 엔지니어가 내놓을 법한 것"이었을 때 경험의 중요성을 강조했습니다. 즉, 판단력과 경험이 있는 사용자만이 문제가 있다고 인식할 수 있는 유형의 솔루션이었다는 것입니다.
다른 엔지니어들은 두 유형의 작업 모두에 Claude를 사용합니다. 탐색적 방식으로 쓰는 경우("기본적으로 모든 코딩 문제에 대해 항상 Claude가 먼저 시도하게 한다")도 있고, 해당 작업에 대한 전문성 수준에 따라 접근 방식을 조절하는 경우도 있습니다:
내 핵심 전문 분야(가속 수단으로 활용 — 결과를 예상할 수 있고 에이전트를 효과적으로 안내할 수 있는 영역)와, 전문 분야에서 약간 벗어난 영역(대략 무엇을 기대해야 하는지는 알지만, 구체적인 정의에 대한 기억이나 친숙도의 빈틈을 Claude가 채워주는 영역) 모두에서 도구를 사용한다.
특히 잘 아는 분야라면 더 주도적으로 Claude에게 무엇을 추적해야 하는지 지시한다. 잘 모르는 분야라면 Claude에게 전문가 역할을 맡기고, 선택지와 내가 고려하고 조사해야 할 사항에 대한 인사이트를 달라고 요청한다.
사람들은 일관되게, 고수준·전략적 사고가 필요하거나 조직적 맥락이나 '안목'이 요구되는 설계 결정에는 Claude를 사용하지 않는다고 답했습니다. 한 엔지니어는 이렇게 설명합니다. "보통 고수준 사고와 설계는 내가 맡는다. 새 기능 개발에서 디버깅까지, 맡길 수 있는 건 다 위임한다." 이는 설문 데이터에서 설계 및 기획 작업의 생산성 향상이 가장 낮게 나타난 것과도 일치합니다(그림 2). 많은 이가 이 위임 경계를 '움직이는 과녁'이라고 표현했으며, 모델이 개선됨에 따라 꾸준히 재조정하고 있습니다(아래 Claude Code 사용 데이터에서도 6개월 전 대비 코드 설계/기획 관련 사용 비중이 상대적으로 높아진 것을 확인할 수 있습니다).
Claude 지원 업무의 27%가 Claude 없이는 수행되지 않았을 것이라는 설문 결과는 더 넓은 패턴을 반영합니다. 엔지니어가 AI를 활용해 핵심 전문 분야 밖의 작업에 도전하는 것입니다. 많은 직원이 이전에는 자기 영역 밖이었던 작업을 해내고 있다고 보고합니다. 백엔드 엔지니어가 UI를 만들고, 연구원이 시각화를 구현하는 식입니다. 한 백엔드 엔지니어는 Claude와 반복 작업을 통해 복잡한 UI를 만든 경험을 이렇게 묘사합니다. "내가 직접 했으면 도저히 안 될 수준이었다. 절대 마감에 맞추지 못했을 거다… 디자이너들이 '이거 당신이 한 거예요?'라고 하길래 '아뇨, Claude가 했어요 — 저는 프롬프트만 넣었습니다'라고 했다."
엔지니어들은 "점점 더 풀스택이 되어가고 있다… 프론트엔드, 트랜잭션 데이터베이스, API 코드까지 능숙하게 다룰 수 있게 됐다. 예전에는 전문성이 부족한 영역은 건드리기 무서웠다"고 말합니다. 이런 역량 확장은 더 빠른 피드백 루프와 학습을 가능하게 합니다. 한 엔지니어는 구현하고, 미팅 일정을 잡고, 반복하는 "몇 주짜리 과정"이 동료들이 실시간 피드백을 주는 "몇 시간짜리 작업 세션"으로 바뀔 수 있다고 말했습니다.
전반적으로 사람들은 빠른 프로토타이핑, 작업 병렬화, 단순 반복 작업 감소, 전체적인 목표 수준 상향에 열의를 보였습니다. 한 시니어 엔지니어는 "이 도구들 덕분에 주니어 엔지니어들의 생산성이 확실히 높아졌고, 도전하는 프로젝트의 범위도 대담해졌다"고 말했습니다. 또한 Claude를 사용할 때 '진입 장벽(activation energy)'이 낮아져 미루기 습관을 더 쉽게 극복할 수 있다는 의견도 있었습니다. "문제를 풀고 싶은 의지를 갖는 데 필요한 에너지가 극적으로 줄었고, 그래서 훨씬 더 많은 일에 기꺼이 착수하게 된다."
동시에 일부는 "더 많이 위임할수록 역량이 퇴화하는 것" 같다며, 직접 문제를 해결하는 과정에서 부수적으로(또는 '부산물로') 얻던 학습이 줄어들고 있다고 우려했습니다:
직접 어려운 이슈를 디버깅하러 가면, 당장 문제 해결에 직접 필요하지 않은 문서와 코드를 읽으며 시간을 보내게 된다. 하지만 그 과정 전체에서 시스템 작동 방식에 대한 멘탈 모델을 쌓게 된다. Claude가 문제를 바로 짚어주기 때문에 이런 학습이 훨씬 줄었다.
예전에는 모든 설정을 직접 탐색하면서 도구가 뭘 할 수 있는지 이해했는데, 이제는 새 도구 사용법을 AI에 의존하다 보니 전문성이 부족하다. 동료와 대화할 때 예전에는 즉시 떠올리던 것들을 이제는 AI에 물어봐야 한다.
Claude를 쓰면 쉬운 사례를 풀면서 작업 수행 방법을 학습하는 단계를 건너뛸 수 있는데, 나중에 더 복잡한 사례를 풀어야 할 때 어려움을 겪을 수 있다.
한 시니어 엔지니어는 자신보다 주니어였다면 더 걱정이 됐을 거라고 말했습니다:
나는 주로 답이 어떤 모습이어야 하는지 아는 경우에 AI를 쓴다. 그 능력은 '어려운 방식으로' 소프트웨어 엔지니어링을 하면서 길렀다… 하지만 [경력 초기였다면], 모델 산출물을 무비판적으로 수용하지 않고 자기 역량을 계속 키우려면 상당한 의도적 노력이 필요할 거라고 생각한다.
코딩 역량 퇴화가 우려되는 이유 중 하나는 '감독의 역설'입니다. 앞서 언급한 것처럼 Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 바로 AI 과다 사용으로 퇴화할 수 있는 코딩 역량이 필요합니다. 한 직원은 이렇게 말했습니다:
솔직히 나는 내 역량 자체보다 감독과 감시 문제가 훨씬 더 걱정된다… 역량이 퇴화하거나 제대로 발전하지 못하는 게 문제인 건, 주로 내가 중요하게 여기는 작업에 AI를 안전하게 쓰는 능력 측면에서이지, 그 작업을 독립적으로 수행하는 능력 측면에서가 아니다.
이에 대응해 일부 엔지니어는 의도적으로 AI 없이 연습합니다. "가끔은 Claude가 완벽히 풀 수 있다는 걸 알면서도 일부러 맡기지 않는다. 감을 유지하는 데 도움이 된다."
소프트웨어 엔지니어링이 과거에도 그랬듯 더 높은 추상화 수준으로 이동하고 있는 것일 수 있습니다. 초기 프로그래머들은 메모리를 수동으로 관리하고, 어셈블리 언어로 코딩하며, 심지어 물리적 스위치를 조작해 명령을 입력하는 등 기계에 훨씬 가까이서 작업했습니다. 시간이 흐르며 복잡한 저수준 연산을 자동으로 처리하는 고수준의 인간 친화적 언어가 등장했습니다. 특히 '바이브 코딩(vibe coding)'의 부상과 함께, 이제 영어 자체가 프로그래밍 언어가 되는 단계로 넘어가고 있는지도 모릅니다. 한 직원은 예비 엔지니어들에게 "AI가 코드를 작성하게 하는 데 능숙해지고, 상위 수준의 개념과 패턴 학습에 집중하라"고 조언했습니다.
일부 직원은 이 변화가 더 높은 수준에서 사고할 수 있게 해준다고 느꼈습니다. 코드 자체가 아니라 "최종 제품과 최종 사용자에 대해" 생각할 수 있게 된 것입니다. 한 직원은 현재의 변화를, 과거 컴퓨터 과학에서 연결 리스트(linked list)를 배워야 했던 것에 비유했습니다. 고수준 프로그래밍 언어가 이제는 자동으로 처리하는 기본 자료구조입니다. "그걸 할 줄 알게 된 건 정말 다행이다… 하지만 그 저수준 연산을 직접 하는 것 자체가 감정적으로 중요한 건 아니다. 그보다는 코드가 나에게 가능하게 해주는 것에 관심이 있다." 다른 엔지니어도 비슷한 비교를 했지만, 추상화에는 대가가 따른다고 지적했습니다. 고수준 언어로 전환하면서 대부분의 엔지니어가 메모리 관리에 대한 깊은 이해를 잃었다는 것입니다.
해당 분야의 역량을 계속 키우면 Claude 감독과 효율적 업무 수행에 도움이 됩니다("익숙한 분야일수록 직접 하는 게 더 빠른 경우가 많다는 걸 느낀다"). 하지만 이것이 정말 중요한지에 대해서는 엔지니어들의 의견이 나뉩니다. 낙관적인 쪽은 이렇게 말합니다:
역량 퇴화가 그렇게 걱정되지는 않는다. AI를 써도 문제를 깊이 생각하게 되고, 새로운 접근 방식도 배울 수 있다. 오히려 아이디어를 더 빠르게 탐색하고 테스트할 수 있게 되면서, 일부 영역에서는 학습이 가속됐다.
더 현실적인 시각도 있었습니다. "소프트웨어 엔지니어로서의 역량은 분명 퇴화하고 있다… 하지만 필요하면 다시 살릴 수 있는 역량이고, 지금은 그냥 필요 없을 뿐이다!" 또 다른 사람은 잃어버린 것이 차트 만들기 같은 덜 중요한 역량 정도이며, "중요한 코드는 여전히 잘 작성할 수 있다"고 말했습니다.
가장 흥미로운 의견을 낸 한 엔지니어는 전제 자체에 의문을 제기했습니다. "'감이 무뎌진다'는 프레이밍은 코딩이 언젠가 Claude 3.5 이전으로 돌아갈 거라는 가정에 기반한다. 나는 그렇게 되지 않을 거라고 생각한다."
직접 코딩하는 것을 그리워하는지에 대해 엔지니어들의 의견이 크게 갈립니다. 일부는 진정한 상실감을 느낍니다. "나에게는 하나의 시대가 끝난 것이다 — 25년간 프로그래밍을 해왔고, 그 역량에서 오는 유능감은 직업적 만족의 핵심이었다." 다른 이들은 변화된 업무 성격을 즐기기 어렵다고 걱정합니다. "하루 종일 Claude에 프롬프트를 입력하는 건 재미있지도, 보람차지도 않다. 음악 틀어놓고 몰입해서 직접 구현하는 게 훨씬 즐겁고 만족스럽다."
트레이드오프를 정면으로 인정하고 수용하는 사람도 있습니다. "코드를 짤 때 그리운 부분이 분명 있다 — 리팩터링 중 선(禪)적 몰입 상태에 빠지는 것 같은. 하지만 지금 생산성이 훨씬 높아졌으니 기꺼이 포기하겠다."
Claude와 반복 작업을 하는 것이 오히려 더 재미있다는 사람도 있었습니다. 사람에게보다 더 까다롭게 피드백을 줄 수 있기 때문이라는 것입니다. 결과에 더 관심을 두는 사람도 있습니다. 한 엔지니어는 이렇게 말합니다:
이쯤 되면 겁이 나거나 지루할 줄 알았다… 하지만 어느 쪽도 아니다. 오히려 훨씬 더 많은 일을 할 수 있다는 데 꽤 흥분된다. 나는 코드 짜는 것 자체를 좋아한다고 생각했는데, 실은 코드를 짜서 얻는 결과를 좋아했던 거였다.
AI 지원을 적극 수용하는지, 직접 코딩의 상실을 아쉬워하는지는 결국 소프트웨어 엔지니어링의 어떤 측면에서 가장 큰 의미를 찾는지에 달려 있는 것으로 보입니다.
가장 두드러진 주제 중 하나는 이전에 동료에게 갔을 질문이 이제 Claude에 먼저 가게 됐다는 것입니다. "전반적으로 질문을 훨씬 많이 하게 됐는데, 80~90%는 Claude에 한다"고 한 직원이 말했습니다. 이는 일종의 필터링 역할을 해서, Claude가 일상적인 질문을 처리하고 동료에게는 AI의 한계를 넘는 복잡하고 전략적이며 맥락이 많이 필요한 이슈만 남깁니다("팀에 대한 의존도가 80% 줄었지만, 나머지 20%가 핵심이라 그건 꼭 찾아가서 대화한다"). 인간 동료와의 상호작용처럼 Claude에 "아이디어를 던져보기도" 합니다.
약 절반은 팀 협업 패턴에 변화가 없다고 응답했습니다. 한 엔지니어는 여전히 사람들과 미팅하고, 맥락을 공유하고, 방향을 결정하고 있으며, 가까운 미래에도 협업은 계속 많을 것이라고 말했습니다. 다만 "일반적인 집중 작업 대신 여러 Claude와 대화하게 될 것"이라고 덧붙였습니다.
반면 동료와의 교류가 줄었다는 경험을 전하는 이들도 있었습니다("어떤 동료보다 Claude와 훨씬 더 많이 일한다"). 줄어든 사회적 마찰을 긍정적으로 보는 사람("동료의 시간을 빼앗는 것 같은 부담감이 없다")도 있지만, 변화에 저항감을 보이는 사람("'Claude한테 물어봤어?'가 기본 반응이 되는 게 솔직히 달갑지 않다. 사람과 직접 일하는 걸 정말 좋아하고 그 가치를 높이 산다")이나 이전 방식을 그리워하는 사람도 있습니다. "사람들과 일하는 걸 좋아하는데, 그들이 덜 '필요'해졌다니 아쉽다." 여럿이 전통적 멘토십 역학에 미치는 영향도 지적했는데, "Claude가 주니어 직원에게 상당한 코칭을 해줄 수 있기" 때문에 시니어 엔지니어의 역할이 줄어든다는 것입니다. 한 시니어 엔지니어는 이렇게 말했습니다:
주니어분들이 질문을 가지고 덜 찾아오는 게 아쉽다. 물론 질문에 대한 답은 더 효과적으로 얻고, 학습 속도도 빨라졌지만.
많은 엔지니어가 자신의 역할이 코드 작성에서 AI 관리로 이동하고 있다고 설명합니다. "AI 에이전트의 관리자"로 자신을 인식하는 엔지니어가 늘고 있으며, 이미 "항상 최소 여러 개의 [Claude] 인스턴스를 동시에 돌리는" 사람도 있습니다. 한 사람은 업무의 "70% 이상이 새 코드를 직접 작성하는 게 아니라 코드 리뷰어/수정자가 됐다"고 추정했고, 다른 사람은 "1개, 5개, 또는 100개 Claude의 작업에 책임을 지는 것"을 미래 역할의 일부로 봤습니다.
장기적으로 경력에 대한 불확실성은 광범위합니다. 엔지니어들은 이러한 변화를 더 넓은 산업 변혁의 전조로 보았으며, 몇 년 후 자기 경력이 어떤 모습일지 "말하기 어렵다"는 반응이 많았습니다. 일부는 단기적 낙관과 장기적 불확실성 사이의 갈등을 표현했습니다. "단기적으로는 낙관적이지만, 장기적으로는 AI가 모든 것을 해내고 나를 포함한 많은 사람을 불필요하게 만들 거라고 생각한다." 더 직설적인 표현도 있었습니다. "매일 출근해서 내 일자리를 없애는 작업을 하는 기분이다."
더 낙관적인 엔지니어도 있었습니다. "주니어 개발자들이 걱정되기도 하지만, 주니어야말로 새로운 기술에 가장 목마른 사람들이기도 하다. 이 직업의 향후 궤적에 대해 전반적으로 매우 낙관적이다." 경험이 부족한 엔지니어가 문제 있는 코드를 배포할 위험이 있지만, 더 나은 AI 가드레일, 더 많은 내장형 학습 자원, 그리고 실수로부터의 자연스러운 학습이 결합돼 업계가 시간이 지나며 적응할 것이라는 주장입니다.
미래 역할을 어떻게 전망하는지, 적응 전략이 있는지도 물었습니다. 일부는 더 깊은 전문화를 계획하고 있다고 답했습니다("AI의 작업을 의미 있게 검토하는 역량을 개발하려면 더 오래 걸리고 더 많은 전문화가 필요할 것"). 대인 관계 및 전략적 업무에 집중할 것이라는 전망도 있었습니다("합의를 찾는 데 더 많은 시간을 쓰고, 구현은 AI에 맡기게 될 것"). Claude를 경력 개발에 직접 활용한다는 사람도 있었는데, 업무와 리더십 역량에 대해 Claude에서 피드백을 받는 식입니다("학습 속도나 완전히 숙달하지 않아도 효과적으로 일할 수 있는 능력이 완전히 달라졌다. 한계의 천장이 산산이 부서진 느낌이다").
전반적으로 깊은 불확실성을 인정하는 목소리가 많았습니다. "앞으로 어떤 역량이 유용할지에 대해 확신이 거의 없다." 한 팀 리드는 이렇게 말했습니다. "아무도 앞으로 어떻게 될지 모른다… 중요한 건 정말 적응력을 갖추는 것이다."
설문과 인터뷰 데이터를 보면 Claude 사용 증가가 업무 속도 향상과 새로운 유형의 업무 수행에 기여하면서도, AI 위임과 역량 개발을 둘러싼 긴장 또한 수반하고 있음을 알 수 있습니다. 하지만 자가 보고 데이터만으로는 전체 그림을 볼 수 없습니다. 이를 보완하기 위해 Anthropic 팀 전반의 실제 Claude 사용 데이터도 분석했습니다. 설문 응답자들이 Claude Code를 사용량의 대부분으로 보고했기 때문에, 프라이버시 보호 분석 도구를 활용해 2025년 2월과 8월의 내부 Claude Code 트랜스크립트 20만 건을 분석했습니다.
지난 6개월간 Claude Code 사용은 더 어렵고 자율적인 코딩 작업 쪽으로 이동했습니다(그림 3):

이 사용 데이터는 설문 데이터를 뒷받침합니다. 엔지니어들이 점점 더 복잡한 작업을 Claude에 위임하고, Claude에 필요한 감독도 줄고 있습니다. 이것이 관찰된 생산성 향상을 견인하고 있을 가능성이 높습니다.
Claude Code 트랜스크립트를 하나 이상의 코딩 작업 유형으로 분류하고, 지난 6개월간 각 작업별 사용이 어떻게 변화했는지 살펴봤습니다:

사용 데이터에서 추정한 전체 작업 빈도 분포는 자가 보고 작업 빈도 분포와 대체로 일치합니다. 2025년 2월과 8월 사이 가장 눈에 띄는 변화는 새 기능 구현(14.3%→36.9%)과 코드 설계/기획(1.0%→9.9%)에 Claude를 활용하는 트랜스크립트 비중이 크게 늘었다는 점입니다. Claude Code 작업의 상대적 분포 변화는 Claude가 이러한 복잡한 작업에서 더 뛰어나졌음을 시사할 수 있지만, 절대적 작업량 증가가 아니라 팀들이 다양한 워크플로에 Claude Code를 도입하는 방식이 변한 것일 수도 있습니다(한계점은 부록 참고).
설문에서 엔지니어들이 삶의 질을 높이는 소소한 개선에 더 많은 시간을 쓰게 됐다는 결과와 일관되게, 현재 Claude Code 작업의 8.6%가 '자잘한 불편 수정(papercut fix)'으로 분류됩니다. 여기에는 성능 시각화 도구 생성이나 유지보수를 위한 코드 리팩터링 같은 비교적 큰 작업부터, 터미널 단축키 만들기 같은 작은 작업까지 포함됩니다. 이는 엔지니어들이 보고한 생산성 향상에 기여할 수 있으며(그동안 방치됐던 삶의 질 개선을 해소하면 시간이 지남에 따라 효율이 높아질 수 있고), 일상 업무에서의 마찰과 스트레스를 줄이는 데도 도움이 될 수 있습니다.
현재 팀별로 작업이 어떻게 다른지 살펴보기 위해, 분류 방식을 세분화해 8월 트랜스크립트 각각에 단일 주요 코딩 작업을 할당하고 내부 팀(y축) 별로 데이터를 분리했습니다. 누적 막대 차트로 각 팀의 코딩 작업 구성을 보여줍니다:

"All Teams" 막대는 전체 분포를 보여주며, 가장 많은 작업은 새 기능 구축, 디버깅, 코드 이해 순입니다. 이는 팀별 비교를 위한 기준선 역할을 합니다.
주목할 만한 팀별 패턴:
이러한 팀별 패턴 상당수는 설문과 인터뷰에서 관찰한 것과 동일한 역량 확장을 보여줍니다. 즉, 팀원들이 시간이나 역량 부족으로 하지 못했을 새로운 종류의 업무를 가능하게 하는 것입니다. 예를 들어 Pre-training 팀은 추가 실험을 대량 수행했고, 비기술직 직원들은 코드 오류를 스스로 수정할 수 있게 됐습니다. 데이터를 보면 각 팀이 핵심 업무에 Claude를 사용하는 것은 물론이지만(예: Infrastructure 팀은 인프라 및 DevOps 작업에 가장 많이 사용), 핵심 업무를 보완하는 데도 활용합니다(예: 연구원이 데이터를 더 잘 시각화하기 위해 프론트엔드 개발에 Claude 사용). 이는 Claude가 모든 사람이 업무에서 더 풀스택이 되도록 돕고 있음을 시사합니다.
Anthropic 직원들은 지난 1년간 Claude 사용을 크게 늘렸으며, 기존 업무 가속화뿐 아니라 새로운 코드베이스 학습, 단순 반복 작업 감소, 새 영역 진출, 그동안 미뤄뒀던 개선 작업 처리에 활용하고 있습니다. Claude가 더 자율적이고 유능해지면서, 엔지니어들은 AI 위임의 새로운 방법을 발견하는 동시에 앞으로 어떤 역량이 필요할지 고민하고 있습니다. 이런 변화는 생산성과 학습 면에서 명확한 이점을 가져다주면서도, 소프트웨어 엔지니어링 업무의 장기적 궤적에 대한 진지한 불확실성을 동반합니다. 여러 엔지니어가 제안한 것처럼, AI가 저수준에서 고수준 프로그래밍 언어로의 전환이나, 개인 기여자에서 관리자로의 역할 변화와 같은 과거 소프트웨어 엔지니어링 전환과 비슷한 양상을 띨까요? 아니면 그 이상으로 갈까요?
아직 초기 단계입니다. Anthropic 내부에는 얼리 어답터가 많고, 환경은 급변하고 있으며, 이 결과가 다른 조직이나 맥락에 당장 일반화되기는 어렵습니다(한계점은 부록 참고). 이번 연구는 바로 그 불확실성을 반영합니다. 하나의 합의나 명확한 지침이 도출되지 않는, 미묘하고 다층적인 결과입니다. 하지만 이 변화를 어떻게 신중하고 효과적으로 헤쳐나갈 수 있을지에 대한 물음은 던지고 있습니다.
이 초기 작업의 후속으로 몇 가지 조치를 진행 중입니다. Anthropic 엔지니어, 연구원, 리더십과 논의하며 제기된 기회와 과제에 대응하고 있습니다. 팀 간 협업 방식, 전문성 개발 지원 방식, AI 기반 업무의 모범 사례 수립(예: AI 활용 역량 프레임워크 기반) 등을 검토하고 있습니다. 또한 이 연구를 엔지니어 이외의 직군으로 확대해 AI 전환이 조직 전반의 역할에 미치는 영향을 파악하고, AI 시대에 맞는 컴퓨터 과학 교육과정을 준비하는 CodePath 같은 외부 단체도 지원하고 있습니다. 나아가 AI 역량이 발전함에 따라 점점 중요해질 수 있는 구조적 접근, 이를테면 조직 내 역할 전환이나 리스킬링을 위한 새로운 경로도 검토하고 있습니다.
구체적인 계획은 2026년에 내부 논의가 무르익는 대로 더 공유할 예정입니다. Anthropic은 책임 있는 직장 전환을 위한 실험실이고자 합니다. AI가 업무를 어떻게 변화시키는지 연구하는 데 그치지 않고, 그 전환을 어떻게 신중하게 헤쳐나갈 수 있는지 직접 실험하고자 합니다. 우리 자신부터 시작해서.
이 글을 인용하고 싶으시다면 아래 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께도 감사의 뜻을 전합니다.
이번 설문 결과에는 몇 가지 방법론적 한계가 있습니다. 응답자 선정은 편의 표집(convenience sampling)과 목적적 표집(purposive sampling, 조직 전반의 폭넓은 대표성 확보)을 병행했습니다. 내부 Slack 채널 여러 곳에 설문을 게시해 68건의 응답을 얻었고, 조직도에서 연구·제품 기능을 아우르는 20개 다양한 팀을 선정해 팀당 5~10명에게 직접 메시지를 보내(총 207명 접촉) 31% 응답률로 나머지 64건의 응답을 확보했습니다. 인터뷰는 가장 먼저 응답한 53명을 대상으로 진행했습니다. 선택 편향이 있을 가능성이 있는데, Claude에 특히 적극적이거나 강한 의견(긍정적이든 부정적이든)을 가진 사람이 더 많이 응답했을 수 있고, 중립적 경험을 가진 사람은 과소 대표됐을 수 있습니다.
또한 사회적 바람직성 편향(응답이 익명이 아니고 모든 참여자가 Anthropic 직원이므로 Claude의 영향을 긍정적으로 부풀렸을 가능성)과 회상 편향(12개월 전 생산성과 사용 패턴을 기억에 의존해 답하므로 기억 왜곡 가능)의 영향을 받았을 수 있습니다. 또한 앞서 논의한 것처럼 생산성은 전반적으로 추정이 매우 어렵기 때문에, 이 자가 보고 결과는 어느 정도 여유를 두고 해석해야 합니다. 자가 보고 인식은 보다 객관적인 Claude Code 사용 데이터와 함께 해석해야 하며, 향후 연구에서는 익명 데이터 수집과 더 견고하게 검증된 측정 도구를 활용하는 것이 바람직합니다.
Claude Code 분석은 기간별 비례 샘플링을 사용하므로, 작업 분포의 상대적 변화만 측정할 수 있고 절대적 작업량 변화는 측정할 수 없습니다. 예를 들어, 기능 구현이 Claude Code 사용의 14%에서 37%로 증가했다고 보고할 때, 기능 관련 작업의 총량이 실제로 더 많아졌다는 의미는 아닙니다.
마지막으로, 이 연구는 2025년 8월에 Claude Sonnet 4와 Claude Opus 4가 최신 모델이던 시기에 수행됐습니다. AI 발전 속도가 매우 빠른 만큼, 관찰된 패턴은 새로운 모델이 출시되면서 이미 달라졌을 수 있습니다.