Anthropic에서 AI가 업무를 변화시키는 방식

https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic

AI는 어떻게 우리의 업무 방식을 바꾸고 있을까요? 우리가 이전에 수행한 연구는 AI의 경제적 영향에 대해 노동시장 전체를 대상으로 다양한 직업을 포괄하여 살펴봤습니다. 그렇다면 AI 기술의 가장 초기 수용자들—즉, 우리 자신—을 더 자세히 연구하면 어떨까요?

시선을 내부로 돌려, 2025년 8월에 우리는 Anthropic의 엔지니어와 연구원 132명을 설문조사하고, 53건의 심층 정성 인터뷰를 실시했으며, 내부 Claude Code 사용 데이터를 분석하여 AI 사용이 Anthropic 내에서 어떻게 변화를 일으키는지 알아보았습니다. 우리는 AI 사용이 소프트웨어 개발자의 업무 본질을 급격히 변화시키고 있으며, 희망과 우려를 동시에 낳고 있음을 발견했습니다.

우리의 연구는 상당한 변화를 겪는 직장을 드러냅니다: 엔지니어들은 더 많은 일을 해내고, 보다 “풀스택”으로(평소 전문 영역을 넘어서는 과제에서도 성공할 수 있게) 변하며, 학습과 반복 속도를 가속하고, 그동안 미뤄왔던 과제들을 처리하고 있습니다. 이러한 폭의 확장은 여러 고민을 불러옵니다—일부는 이것이 깊은 기술 역량을 잃거나, Claude의 출력을 효과적으로 감독하는 능력이 떨어질 수 있음을 걱정하는 반면, 다른 이들은 더 넓고 높은 수준에서 사고할 수 있는 기회를 받아들입니다. 일부는 AI와의 협업이 많아질수록 동료와의 협업이 줄었다고 느꼈고; 일부는 결국 자신들의 일을 자동화하게 될지에 대해 고민했습니다.

AI를 구축하는 회사에서 AI의 영향을 연구한다는 것은 특권적 위치를 반영함을 우리는 인지합니다—우리 엔지니어들은 최첨단 도구에 조기 접근권을 갖고, 비교적 안정적인 분야에서 일하며, 다른 산업에 영향을 미치는 AI 변혁에 직접 기여하고 있습니다. 그럼에도 불구하고, 우리는 이러한 발견을 연구하고 공개하는 것이 대체로 유익하다고 느꼈습니다. 왜냐하면 엔지니어를 대상으로 Anthropic 내부에서 일어나는 일이 더 넓은 사회적 변혁의 초기 신호로서 여전히 유의미할 수 있기 때문입니다. 우리의 발견은 여러 부문에서 조기 주목이 필요할 수 있는 과제와 고려사항을 시사합니다(단, 부록의 한계 섹션 참조). 데이터가 수집되던 당시에는 Claude Sonnet 4와 Claude Opus 4가 가장 강력한 모델이었고, 그 이후로도 능력은 계속 발전해 왔습니다.

더 강력한 AI는 생산성 이점을 가져오지만, 기술 전문성 유지, 의미 있는 협업 보존, 그리고 불확실한 미래에 대비하기 위한 새로운 학습, 멘토십, 경력 개발 접근법이 필요할 수 있다는 질문도 제기합니다. 우리는 아래의 Looking Forward 섹션에서 이러한 질문을 내부적으로 탐색하기 위해 취하고 있는 초기 단계들을 논의합니다. 또한 최근 블로그 글인 AI 관련 경제 정책 아이디어에서 잠재적 정책 대응도 탐구했습니다.

핵심 발견

이 섹션에서는 설문조사, 인터뷰, Claude Code 데이터로부터의 발견을 간략히 요약합니다. 자세한 발견, 방법론, 한계는 이후 섹션에 제공합니다.

설문 데이터

1. Anthropic 엔지니어와 연구원은 코드 오류 수정과 코드베이스 학습에 Claude를 가장 자주 사용합니다. 디버깅과 코드 이해가 가장 일반적인 사용 사례입니다(그림 1).
2. 사용자들은 Claude 사용 증가와 생산성 향상을 보고합니다. 직원들은 업무의 60%에서 Claude를 사용하고 50%의 생산성 향상을 달성했다고 자가 보고했으며, 이는 1년 전 대비 2-3배 증가입니다. 이 생산성은 각 작업 범주에 소요되는 시간이 약간 줄어드는 형태이지만, 산출량은 상당히 증가하는 형태를 띱니다(그림 2).
3. Claude가 보조한 업무의 27%는 원래는 수행되지 않았을 과제로 구성됩니다. 프로젝트 확장, 있어도 좋은 도구(예: 대화형 데이터 대시보드) 제작, 수작업으로는 비용 효과적이지 않은 탐색적 작업 등이 이에 해당합니다.
4. 대부분의 직원은 Claude를 자주 사용하지만 “완전 위임” 가능한 업무는 0-20%라고 보고합니다. Claude는 지속적인 협업자로 기능하지만, 특히 고위험 업무에서는 검증이 필요 없는 완전한 업무 인계보다는 적극적인 감독과 확인을 수반합니다.

정성 인터뷰

1. 직원들은 AI 위임에 대한 직관을 개발하고 있습니다. 엔지니어들은 비교적 쉽게 정확성을 ‘냄새 맡듯’ 확인할 수 있는 업무, 저위험(예: “버릴 디버그 또는 연구용 코드”), 혹은 지루한 업무를 위임하는 경향이 있습니다(“내가 그 일을 하려는 흥분이 클수록 Claude를 덜 사용한다”). 많은 이들은 간단한 업무부터 시작해 점차 더 복잡한 업무로 위임 범위를 넓히는 신뢰 진행 과정을 설명합니다—현재 대부분은 설계나 “취향” 업무를 인간이 보유하지만, 모델이 발전함에 따라 이 경계는 재협상 중입니다.
2. 역량 범위는 더 넓어지지만, 일부는 연습량이 줄고 있습니다. Claude는 사람들로 하여금 소프트웨어 엔지니어링의 더 넓은 영역으로 역량을 확장하게 하지만(“이전에 건드리기 겁났던 프런트엔드나 트랜잭션 DB…에도 매우 능숙하게 일할 수 있다”), 일부 직원은 코드 작성과 비평에 필요한 더 깊은 기술 역량이 역설적으로 약화될 수 있음을 우려합니다—“출력 생산이 너무 쉽고 빠르면, 실제로 시간을 들여 무언가를 배우기가 점점 어려워진다.”
3. 코딩 장인의식과의 관계 변화. 일부 엔지니어는 AI 보조를 받아들이고 결과에 집중합니다(“난 정말 코드를 쓰는 걸 좋아한다고 생각했지만, 사실은 코드 작성으로 얻는 결과를 좋아하는 거였다”); 다른 이들은 “[코드 작성]의 일부는 분명 그립다”고 말합니다.
4. 직장 내 사회적 역학 변화 가능성. 예전에는 동료에게 갔던 질문이 이제 Claude로 향합니다—그 결과 멘토링과 협업 기회가 줄었다고 보고하는 이들도 있습니다.(“사람들과 함께 일하는 걸 좋아하는데, 이제 그들이 덜 ‘필요’하다는 게 슬프다… 주니어들이 내게 질문하러 덜 온다.”)
5. 커리어의 진화와 불확실성. 엔지니어들은 AI 시스템을 관리하는 더 높은 수준의 업무로 이동하고 있으며, 상당한 생산성 향상을 보고합니다. 그러나 이러한 변화는 소프트웨어 엔지니어링 직업의 장기적 궤적에 대한 질문도 제기합니다. 일부는 “단기적으로는 낙관적이지만 장기적으로는 AI가 모든 것을 하게 되어 나와 많은 사람들이 무의미해질 것 같다”고 상반된 감정을 표합니다. 다른 이들은 진정한 불확실성을 강조하며 몇 년 후 자신의 역할이 어떻게 될지 “말하기 어렵다”고만 합니다.

Claude Code 사용 추세

1. Claude는 점점 더 복잡한 작업을 보다 자율적으로 처리하고 있습니다. 6개월 전만 해도 Claude Code는 인간 입력 없이 자체적으로 약 10개의 액션을 완료했으나, 현재는 대략 20개를 처리하며 더 복잡한 워크플로우를 완료하기 위해 인간의 방향 제시가 덜 필요합니다(그림 3). 엔지니어들은 코드 설계/기획(사용 비중 1%→10%)이나 신규 기능 구현(14%→37%) 같은 복잡한 작업에 Claude를 점점 더 많이 사용합니다(그림 4).
2. Claude는 많은 ‘사소한 불편(papercuts)’을 해결합니다. Claude Code 작업의 8.6%가 유지보수성을 위한 리팩토링과 같은 삶의 질 개선을 위한 사소한 이슈 해결에 해당합니다(즉, “사소한 불편” 해결). 이러한 작은 수정들이 누적되어 더 큰 생산성과 효율성 향상으로 이어질 수 있습니다.
3. 모두가 더 “풀스택”이 되어가고 있습니다. 팀마다 Claude를 서로 다른 방식으로 사용하며, 종종 핵심 전문성을 보완합니다—보안팀은 낯선 코드를 분석하는 데, 정렬 & 안전팀은 데이터의 프런트엔드 시각화 구축에 사용하는 식입니다(그림 5).

설문 데이터

우리는 조직 전반의 Anthropic 엔지니어와 연구원 132명을 대상으로 Claude 사용에 관한 설문조사를 실시하여, 일상에서 정확히 어떻게 사용하는지 더 잘 이해하고자 했습니다. 설문은 내부 커뮤니케이션 채널을 통해 배포했고, 연구 및 제품 기능을 대표하는 다양한 팀의 직원들에게 직접 연락했습니다. 방법론적 세부사항은 부록의 한계 섹션에 포함했으며, 다른 이들이 우리의 접근을 평가하고 자신의 연구에 맞게 변형할 수 있도록 설문 질문을 공유합니다.

사람들이 Claude를 어떤 코딩 작업에 사용하나요?

설문 대상 엔지니어와 연구원들에게 “디버깅”(Claude를 사용하여 코드 오류를 수정), “코드 이해”(Claude가 기존 코드를 설명하여 사람이 코드베이스를 이해하도록 돕는 것), “리팩토링”(기존 코드 구조 재편), “데이터 사이언스”(예: Claude가 데이터셋을 분석하고 막대 그래프를 만드는 것) 등의 다양한 코딩 작업 유형에서 Claude 사용 빈도를 평가하도록 요청했습니다.

아래는 가장 흔한 일상 작업입니다. 직원의 55%는 매일 디버깅에 Claude를 사용했습니다. 42%는 매일 코드 이해에, 37%는 매일 신규 기능 구현에 Claude를 사용했습니다. 덜 빈번한 작업은 고수준 설계/기획(사람들이 대체로 인간에게 남기는 경향이 있는 작업), 데이터 사이언스, 프런트엔드 개발이었습니다(전체적으로 덜 일반적인 작업이기 때문). 이는 “Claude Code 사용 추세” 섹션에서 보고한 사용 데이터 분포와 대략 일치합니다.

그림 1: 다양한 코딩 작업(세로축)에 대한 일일 사용자 비율(가로축).

사용과 생산성

직원들은 12개월 전에는 일상 업무의 28%에서 Claude를 사용해 +20% 생산성 향상을 얻었으나, 현재는 업무의 59%에서 Claude를 사용해 평균 +50% 생산성 향상을 달성했다고 자가 보고했습니다. (이는 우리가 엔지니어링 조직 전체에서 Claude Code를 도입했을 때 엔지니어 1인당 하루 기준 머지된 PR—즉, 코드 변경사항의 성공적 반영—이 67% 증가했다는 수치와 대략 상관됩니다.) 전년 대비 비교는 매우 극적입니다—이는 1년 사이 두 지표가 2배 이상 증가했음을 시사합니다. 사용과 생산성은 또한 강하게 상관하며, 분포의 극단부에서는 14%의 응답자가 Claude 사용을 통해 100% 이상의 생산성 향상을 보고했습니다—이들이 내부의 “파워 유저”입니다.

단, 이 발견(및 아래의 다른 자기보고 생산성 발견)에 대해 주의할 점은 생산성은 정확히 측정하기가 어렵다는 것입니다(자세한 한계는 부록 참조). METR라는 AI 연구 비영리기관의 최근 연구는 AI와 협업하는 숙련 개발자들이 매우 익숙한 코드베이스에서 생산성 향상을 과대평가했다고 보여줍니다. 그럼에도 METR가 지적한 생산성 기대보다 낮았던 요인들(예: 대규모 복잡한 환경에서 AI 성능 저하, 암묵적 지식/맥락이 많은 경우)이 우리 직원들이 Claude에 위임하지 않는 업무 유형과 정확히 대응합니다. 작업 전반에 걸친 자기보고 생산성 증가는, METR 연구에서 고려되지 않은 전략적 AI 위임 기술을 직원들이 개발했음을 반영할 수 있습니다.

Claude를 사용하는 작업 범주에서, 해당 범주 내 전체 시간 사용과 산출량에 어떤 영향을 미치는지 물었을 때 흥미로운 생산성 패턴이 나타났습니다. 거의 모든 작업 범주에서 시간 사용은 순감소, 산출량은 더 크게 순증가했습니다:

그림 2: 작업(세로축)별 시간 사용(좌)과 산출량(우)에 대한 영향. 각 도표의 가로축은 Claude 미사용 대비 Claude 보조 작업에서의 자기보고 감소(음수), 증가(양수), 변화 없음(세로점선)을 나타냅니다. 오차 막대는 95% 신뢰구간. 원 크기는 각 평가점에서의 응답 수에 비례. 각 작업 범주에서 Claude를 사용한다고 응답한 사람만 포함.

그러나 원시 데이터를 더 깊게 보면, 시간 절감 응답이 양 극단에 클러스터링되어—일부는 Claude 보조 작업에 더 많은 시간을 쓴다고 보고합니다.

왜 그럴까요? 사람들은 일반적으로 Claude의 코드를 더 디버깅하고 정리해야 했다고 설명합니다(예: “내가 바이브 코딩하다 막다른 길로 들어갈 때”). 자신이 직접 작성하지 않은 Claude의 코드를 이해하려는 인지적 부담도 더 짊어졌다고 말합니다. 더 많은 시간을 쓰는 경우가 “가능하게 하는” 의미일 때도 있습니다—누군가는 Claude 사용 덕분에 “이전에 바로 포기했을 과제에 계속 매달릴 수 있다”고 했고; 또 다른 이는 더 철저한 테스트뿐 아니라 새로운 코드베이스에서 더 많은 학습과 탐색을 하게 된다고 말했습니다. 일반적으로, 시간 절감을 경험하는 엔지니어는 Claude에게 빠르게 검증 가능한 작업을 잘 스코핑하는 반면, 더 많은 시간을 쓰는 엔지니어는 AI 생성 코드를 디버깅하거나 Claude가 더 많은 안내를 필요로 하는 도메인에서 일하는 듯합니다.

또한, 보고된 시간 절감이 어디에 재투자되는지도 데이터상 명확하지 않습니다—추가 엔지니어링 작업, 비엔지니어링 작업, Claude와의 상호작용이나 출력 검토, 혹은 업무 외 활동일 수 있습니다. 우리의 작업 범주화 틀은 엔지니어가 시간을 배분하는 모든 방식을 포착하지 못합니다. 추가로, 시간 절감은 자기보고의 지각 편향을 반영할 수 있습니다. 이러한 효과를 분리하기 위해 향후 더 많은 연구가 필요합니다.

산출량 증가는 더 직관적이고 큽니다; 모든 작업 범주에 걸쳐 순증가가 더 크게 관찰됩니다. 이는 사람들이 개별 작업이 아니라 작업 범주(예: “디버깅” 전반)에 대해 보고한다는 점을 고려하면 타당합니다—즉, 사람들은 디버깅 범주에 약간 덜 시간을 쓰면서도 전체 디버깅 산출물은 훨씬 더 많이 생산할 수 있습니다. 생산성은 직접 측정하기 매우 어렵지만, 이러한 자기보고 데이터는 Anthropic에서 AI가 주로 산출량 증가를 통해 생산성을 높인다는 점을 시사합니다.

Claude가 새로운 작업을 가능케 함

우리가 궁금했던 것 중 하나: Claude가 질적으로 새로운 종류의 작업을 가능하게 하는가, 아니면 어차피 직원들이 결국 하게 될 일을(비록 더 느린 속도로) 돕는가?

직원들은 Claude 보조 업무의 27%가 없었더라면 수행되지 않았을 것이라고 추정했습니다. 엔지니어들은 AI를 사용해 프로젝트를 확장하고, 문서화와 테스트 같은 유용하지만 지루한 작업을 하고, 수작업으로는 비용 효과적이지 않은 탐색적 작업을 한다고 했습니다. 한 사람은 이전에는 삶의 질을 저해하던 “사소한 불편”들을 더 많이 고칠 수 있게 되었다고 설명했습니다. 예컨대 구조가 나쁜 코드를 리팩토링하거나 “다른 작업을 더 빠르게 수행하는 데 도움이 되는 작은 도구”를 만드는 일입니다. 우리는 사용 데이터 분석에서도 이를 찾았고, 확인한 바에 따르면 Claude Code 작업의 8.6%가 ‘사소한 불편 해결’에 해당합니다.

다른 연구원은 서로 다른 접근법을 탐색하도록 여러 버전의 Claude를 동시에 실행했다고 설명했습니다:

사람들은 매우 유능한 모델을 단일 인스턴스로 생각하는 경향이 있는데, 이는 더 빠른 차를 얻는 것과 같습니다. 그러나 수백만 마리의 말…을 갖는 것은 다양한 아이디어를 시험할 수 있게 합니다… 그 추가적인 폭을 탐색할 수 있을 때 더 흥미롭고 창의적입니다.

아래 섹션에서 보겠지만, 이러한 새로운 작업은 종종 엔지니어들이 자신의 핵심 전문 영역 밖의 과제를 다루는 것을 포함합니다.

얼마나 많은 작업을 Claude에게 완전 위임할 수 있나요?

엔지니어들은 Claude를 자주 사용하지만, 절반 이상은 Claude에게 “완전 위임”할 수 있는 업무가 0-20% 사이라고 말했습니다. (“완전 위임”을 응답자가 어떻게 해석하는지에 변이가 있음을 주의해야 합니다—전혀 검증이 필요 없는 작업에서, 가벼운 감독만으로 충분히 신뢰할 수 있는 작업까지.) 이유를 설명하면서, 엔지니어들은 Claude와 능동적·반복적으로 일하고, 특히 복잡하거나 코드 품질 기준이 중요한 고위험 영역에서 샘플을 검증한다고 말했습니다. 이는 엔지니어들이 일반적으로 Claude와 긴밀히 협업하고 그의 작업을 점검하며, 검증 없이 과제를 넘기기보다는 “완전 위임”에 대해 높은 기준을 설정한다는 점을 시사합니다.

정성 인터뷰

설문결과는 상당한 생산성 향상과 변화하는 업무 패턴을 보여주지만, 엔지니어들이 실제로 이러한 변화를 일상에서 어떻게 경험하는지에 대한 질문을 제기합니다. 우리는 설문에 응답한 Anthropic 엔지니어 및 연구원 53명을 대상으로 심층 인터뷰를 실시하여, 직장에서 이러한 변화에 대해 그들이 어떻게 생각하고 느끼는지 더 많은 통찰을 얻고자 했습니다.

AI 위임 접근법

엔지니어와 연구원들은 워크플로에서 Claude를 생산적으로 활용하기 위한 다양한 전략을 개발하고 있습니다. 사람들은 일반적으로 다음과 같은 과제를 위임합니다:

사용자 맥락 밖이면서 저복잡도:
“내가 맥락을 잘 모르는 일이더라도, 전체 복잡도가 낮다고 판단되는 경우에는 Claude를 사용합니다.”
“내가 겪는 인프라 문제 대부분은 어렵지 않고 Claude로 처리할 수 있습니다… 나는 Git이나 Linux를 잘 모릅니다… Claude는 이 영역에서 내 경험 부족을 잘 보완합니다.”

쉽게 검증 가능:
“생성 노력에 비해 검증 노력이 크지 않은 모든 것에서 정말 놀라운 성능을 보입니다.”

정의가 명확하거나 자체 포함:
“프로젝트의 하위 구성 요소가 충분히 다른 부분과 분리되어 있으면, Claude에게 시도를 맡깁니다.”

코드 품질이 핵심이 아님:
“버릴 디버깅이나 연구용 코드라면 곧바로 Claude에 맡깁니다. 개념적으로 어렵거나 아주 특정한 디버그 주입이 필요하거나, 설계 문제인 경우에는 내가 직접 합니다.”

반복적이거나 지루함:
“내가 그 일을 하려는 열의가 클수록 Claude를 덜 사용하게 됩니다. 반대로 많은 저항감을 느낄 때는… 그 과제에 대해 Claude와 대화를 시작하는 것이 더 쉽다고 종종 느낍니다.”

우리 설문에서, 평균적으로 사람들은 Claude가 보조한 작업의 44%가 자신들이 직접 하는 것을 즐기지 않았을 과제로 구성되어 있다고 답했습니다.

프롬프트가 실행보다 더 빠름:
“10분 이내에 끝날 것으로 예상되는 작업이라면… 아마 Claude를 굳이 사용하지 않을 것입니다.”
“콜드 스타트 문제가 지금 가장 큰 장애물인 듯합니다. 콜드 스타트란, 내 팀의 코드베이스가 어떻게 작동하는지에 대해 내가 본질적으로 갖고 있는 많은 정보가 Claude에는 기본적으로 없다는 뜻입니다… 완벽한 프롬프트를 만들기 위해 시간을 들일 수도 있겠지만 [그보다는] 그냥 내가 직접 해버릴 겁니다.”

우리 직원들이 위임 여부를 결정할 때 언급한 이러한 요인들은, METR의 외부 연구에서 AI 관련 생산성 둔화를 설명하는 요인들(예: 개발자의 코드베이스 친숙도가 높은 경우, 대규모 복잡한 리포지토리)과 유사합니다. 인터뷰 전반에서 이러한 위임 기준의 수렴은, 적절한 과제 선택이 AI 생산성 향상의 중요한 요소임을 시사합니다(향후 생산성 연구에서는 이를 면밀히 통제해야 합니다).

신뢰하되 검증하라

많은 사용자는 Claude 사용에서 시간이 지나며 점차 더 복잡한 과제를 위임하는 진행을 설명합니다: “처음에는 Rust 프로그래밍 언어에 관한 기초적인 질문에만 AI 도구를 사용했습니다… 최근에는 코딩의 모든 부분에 Claude Code를 사용합니다.”

어느 엔지니어는 신뢰의 진행을 Google 지도 같은 다른 기술 채택에 비유했습니다:

처음에는 모르는 경로에만 [Google 지도를] 사용했습니다… 이는 내가 Claude에게 모르는 SQL을 쓰게 했지만, 내가 아는 Python을 쓰게 하지는 않았던 것과 같습니다. 그다음에는 대체로 아는 경로에도 사용했지만, 마지막 1마일은 모를 수 있었습니다… 오늘날에는 매일 이용합니다. 다른 길로 가라면 그렇게 합니다. 모든 옵션을 고려했으리라 믿고… 오늘 나는 Claude Code를 비슷한 방식으로 사용합니다.

엔지니어들은 전문 영역 내에서 사용할지, 밖에서 사용할지에 대해 갈립니다. 일부는 구현 시간을 절약하기 위해 “주변” 도메인에 사용하고; 다른 이들은 출력 검증이 가능한 친숙한 영역을 선호합니다(“나는 여전히 그것이 하는 일을 완전히 이해하는 방식으로 Claude를 사용한다”). 보안 엔지니어 한 명은 Claude가 제안한 솔루션이 “위험하긴 하지만 매우 영리한 방식—아주 재능 있는 주니어 엔지니어가 제안할 법한 것”이었다고 강조하며, 이는 판단과 경험을 가진 사용자가 아니면 문제로 인식하기 어렵다고 했습니다.

다른 엔지니어들은 두 유형의 작업 모두에 Claude를 사용합니다. 어떤 경우에는 실험적으로(“나는 사실상 모든 코딩 문제에 대해 Claude가 첫 시도를 하도록 한다”), 혹은 과제에 대한 자신의 전문성 수준에 따라 접근을 조정합니다:

내 전문성의 핵심인 것들에는(가속기로서, 예상되는 바를 알고 에이전트를 효과적으로 안내할 수 있는 경우) 도구를 사용하고, 내 전문성 밖의 것들에는 대략 무엇을 기대해야 하는지 알고 있지만 Claude가 내 기억의 빈틈이나 특정 정의에 대한 친숙함의 빈틈을 메워줄 수 있습니다.

내가 특히 잘 아는 것이라면 더 단호하게 Claude에게 무엇을 추적해야 하는지 지시합니다. 내가 확실치 않은 것이라면 종종 Claude에게 전문가 역할을 맡기고 고려·조사해야 할 옵션과 통찰을 제시하도록 요청합니다.

사람들이 스스로도 남겨두는 작업은?

사람들은 일관되게, 고수준 또는 전략적 사고가 필요한 작업, 조직적 맥락이나 “취향”이 필요한 설계 결정과 관련된 작업에는 Claude를 사용하지 않는다고 말합니다. 한 엔지니어는 “대개 고수준의 사고와 설계를 내가 보유합니다. 신규 기능 개발부터 디버깅까지 가능한 모든 것을 위임합니다”라고 설명했습니다. 이는 설문 데이터에서 설계와 기획 작업의 생산성 향상이 가장 적다는 사실(그림 2)에 반영됩니다. 많은 사람들은 위임 경계를 “움직이는 표적”이라고 설명하며, 모델이 발전함에 따라 이를 정기적으로 재협상한다고 합니다(아래 Claude Code 사용 데이터는 6개월 전보다 현재 코딩 설계/기획 사용 비중이 상대적으로 더 높음을 보여줍니다).

역량의 변형

새로운 역량…

Claude 보조 작업의 27%가 없었더라도 수행되지 않았을 것이라는 설문 결과는 더 넓은 패턴을 반영합니다: 엔지니어들은 AI를 사용해 자신의 핵심 전문 영역 밖에서 일합니다. 많은 직원이 이전에는 전문성 밖이던 일을 완료합니다—백엔드 엔지니어가 UI를 만들고; 연구자가 시각화를 만듭니다. 한 백엔드 엔지니어는 Claude와의 반복으로 복잡한 UI를 구축한 일을 설명했습니다: “내가 혼자 했다면 절대 못했을 겁니다. 제때 끝내는 건 더더욱… [디자이너들이] ‘잠깐, 이거 네가 했어?’라고 묻기에 ‘아니요, Claude가 했고—난 프롬프트만 했어요’라고 답했습니다.”

엔지니어들은 “더 풀스택이 되어가고 있다… 프런트엔드, 트랜잭션 DB, API 코드 등 이전에 ‘겁났던’ 것들에서도 매우 능숙하게 일할 수 있다”고 보고합니다. 이러한 역량 확장은 더 촘촘한 피드백 루프와 더 빠른 학습을 가능케 합니다—한 엔지니어는 빌드, 회의 일정 잡기, 반복의 “몇 주 걸리는 과정”이 동료들이 실시간 피드백을 위해 참석한 상태에서 “몇 시간짜리 작업 세션”으로 바뀔 수 있다고 했습니다.

일반적으로 사람들은 빠른 프로토타이핑, 작업 병렬화, 고된 반복 작업의 감소, 그리고 전반적 야망 수준 상승에 고무되었습니다. 한 시니어 엔지니어는 “이 도구들이 분명 주니어 엔지니어를 더 생산적으로 만들고, 그들이 도전할 프로젝트 유형에서 더 대담하게 만든다”고 했습니다. 일부는 Claude 사용의 “활성화 에너지”가 낮아져 미루는 습관을 더 쉽게 이길 수 있게 되었고, “문제를 시작해 해결하려는 데 필요한 에너지가 극적으로 줄어들어, 훨씬 더 많은 것들을 기꺼이 시도하게 된다”고 말했습니다.

…그리고 ‘손으로’ 하는 연습의 감소 

동시에, 일부는 “[업무를] 더 많이 위임할수록 기술이 약화된다”는 점과, 수동으로 문제를 해결하는 과정에서 발생하는 부수적(또는 “부대”) 학습을 잃게 될 것을 걱정했습니다:

스스로 나가서 어려운 이슈를 디버깅한다면, 문제 해결에 직접적으로 유용하지 않은 문서와 코드를 읽는 데 시간을 쓸 것입니다—하지만 그 전체 시간이 시스템이 어떻게 동작하는지에 대한 모델을 구축하는 시간입니다. Claude가 곧바로 문제로 데려다 줄 수 있기 때문에, 그런 일이 훨씬 줄어들었습니다.

예전에는 도구가 무엇을 할 수 있는지 이해하려고 모든 설정을 탐색했지만, 이제는 새로운 도구를 어떻게 사용하는지 AI가 알려주는 데 의존하기 때문에 전문성이 부족합니다. 다른 팀원들과의 대화에서 예전에는 즉시 떠올릴 수 있었던 것을, 지금은 AI에 물어봐야 합니다.

Claude를 사용하면 쉬운 사례를 풀면서 작업 수행법을 배우는 부분을 건너뛸 가능성이 있어, 나중에 더 복잡한 사례를 풀 때 어려움을 겪을 수 있습니다.

한 시니어 엔지니어는 자신이 더 주니어였다면 기술에 대해 더 걱정했을 것이라고 말했습니다:

나는 주로 답이 무엇이어야 하는지, 어떻게 보여야 하는지 알고 있는 경우에만 AI를 사용합니다. 그 능력은 소프트웨어 엔지니어링을 ‘힘든 방식’으로 하며 개발했습니다… 하지만 만약 [커리어 초기에] 있었다면, 모델 출력을 맹목적으로 받아들이지 않고 내 능력을 계속 성장시키는 데 많은 의도적 노력이 필요하다고 생각했을 겁니다.

코딩 기술의 약화가 우려되는 또 다른 이유는 “감독의 역설” 때문입니다—앞서 언급했듯, Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 AI 과사용으로 약화될 수 있는 바로 그 코딩 기술이 필요합니다. 한 사람은 이렇게 말했습니다:

솔직히 말해, 나는 내 특정 기술셋 그 자체보다 감독과 관리 문제를 훨씬 더 걱정합니다… 내 기술이 약화되거나 발전하지 않는 것은, 내가 관심 있는 작업에 AI를 안전하게 사용하기 위한 능력과 관련해서 주된 문제가 될 것이지, 내가 그 작업을 독립적으로 수행하는 능력 그 자체와는 덜 관련될 것입니다.

이에 맞서 일부 엔지니어는 의도적으로 AI 없이 연습합니다: “가끔은, Claude가 문제를 완벽히 풀 수 있다는 걸 알아도 요청하지 않습니다. 스스로를 날카롭게 유지하는 데 도움이 됩니다.”

핸즈온 코딩 기술이 여전히 필요할까?

아마 소프트웨어 엔지니어링은 과거에도 그랬듯 더 높은 추상화 수준으로 이동 중일 것입니다. 초기 프로그래머들은 기계에 훨씬 가까운 곳에서 작업했습니다—메모리를 수동으로 관리하고, 어셈블리로 작성하며, 심지어 물리적 스위치를 토글해 명령을 입력했습니다. 시간이 지나면서, 더 높은 수준의 사람 친화적 언어가 등장해 복잡한 저수준 작업을 자동으로 처리했습니다. 특히 “바이브 코딩”이 부상하면서, 이제는 영어가 프로그래밍 언어가 되어가는 것일 수도 있습니다. 우리 팀의 한 사람은 미래의 엔지니어 지망생들에게 “AI로 [코드를] 잘 작성하게 만들고, 더 높은 수준의 개념과 패턴을 학습하는 데 집중하라”고 제안했습니다.

몇몇 직원은 이 변화가 자신들을 더 높은 수준에서—코드 그 자체가 아니라 최종 결과물과 최종 사용자에 대해—사고하도록 한다고 말했습니다. 한 사람은 현재의 변화를, 과거 컴퓨터 과학에서 연결 리스트를 배워야 했던 시절과 비교했습니다—지금은 더 높은 수준의 언어가 이를 자동으로 처리합니다. “그걸 알게 되어 정말 기뻤습니다… [하지만] 그런 저수준 연산을 직접 하는 것은 정서적으로 그다지 중요하지 않습니다. 나는 코드가 무엇을 가능하게 하는지에 더 관심이 있습니다.” 다른 엔지니어도 유사한 비교를 했지만, 추상화에는 대가가 따른다고 지적했습니다—더 높은 수준의 언어로 이동하며 대부분의 엔지니어는 메모리 처리에 대한 깊은 이해를 잃었습니다.

특정 영역의 기술을 계속 발전시키면 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 Code 사용 추세

설문과 인터뷰 데이터는 Claude 사용 증대가 사람들이 더 빠르게 일하고 새로운 유형의 작업을 맡도록 돕는다는 점을 보여주며, 동시에 AI 위임과 기술 개발을 둘러싼 긴장도 동반합니다. 여전히 자기보고 데이터는 이야기의 일부만 전달합니다. 이를 보완하기 위해, 우리는 Anthropic 전 팀에 걸친 실제 Claude 사용 데이터를 추가로 분석했습니다. 설문 응답자들이 사용의 대부분을 Claude Code라고 보고했기 때문에, 우리는 2025년 2월과 8월의 Claude Code 내부 대화 20만 건을 우리의 프라이버시 보호 분석 도구로 분석했습니다.

더 적은 감독으로 더 어려운 문제 해결

지난 6개월 동안 Claude Code 사용은 더 어렵고 자율적인 코딩 작업 쪽으로 이동했습니다(그림 3):

• 직원들은 Claude Code로 점점 더 복잡한 작업을 다루고 있습니다. 각 대화의 작업 복잡도를 1-5 척도로 추정했으며, 1은 “기초적 편집”, 5는 “수주/수개월의 인간 전문가 작업이 필요한 전문가 수준”입니다. 평균 작업 복잡도는 3.2에서 3.8로 상승했습니다. 예시로, 평균 3.2에는 “Python 모듈 임포트 오류 해결”이, 평균 3.8에는 “캐싱 시스템 구현 및 최적화”가 포함되었습니다.
• 대화당 최대 연속 도구 호출 수가 116% 증가했습니다. 도구 호출은 파일 편집, 명령 실행 같은 외부 도구 사용 행동을 의미합니다. Claude는 6개월 전의 9.8회 대비, 이제는 21.2회를 인간 개입 없이 연쇄적으로 수행합니다.
• 인간 턴 수는 33% 감소했습니다. 대화당 평균 인간 턴이 6.2에서 4.1로 줄어, 동일 과제를 완료하는 데 필요한 인간 입력이 6개월 전보다 적음을 시사합니다.

그림 3. 2025년 8월과 2025년 2월 사이의 Claude Code 사용 변화(가로축). 평균 작업 복잡도는 시간이 지나며 증가했습니다(왼쪽 패널). 대화당 최대 연속 도구 호출 수의 평균도 시간이 지나며 증가했습니다(가운데 패널). 인간 턴 수는 시간이 지나며 감소했습니다(오른쪽 패널). 오차 막대는 95% 신뢰구간을 표시합니다. 데이터는 시간이 지날수록 사람들이 Claude에게 더 많은 자율성을 위임하고 있음을 시사합니다.

이 사용 데이터는 설문 결과를 뒷받침합니다: 엔지니어들은 점점 더 복잡한 일을 Claude에 위임하고, Claude는 더 적은 감독을 필요로 합니다. 이는 관찰된 생산성 향상을 설명하는 개연적 요인입니다.

작업 분포

우리는 Claude Code 대화를 하나 이상의 코딩 작업 유형으로 분류하고, 지난 6개월 사이 작업별 사용이 어떻게 변했는지 연구했습니다(그림 4):

그림 4. 레코드(가로축). 6개월 전(분홍색)과 현재(보라색)의 분포를 비교합니다. 세로축은 2025년 2월의 빈도 순으로 정렬되어 있습니다.

전체 작업 빈도 분포는 자기보고 분포와 대략 일치합니다. 2025년 2월과 8월 사이 가장 두드러진 변화는, 신규 기능 구현(14.3% → 36.9%)과 코드 설계/기획(1.0% → 9.9%)에 Claude를 사용하는 대화가 비율상 훨씬 더 많아졌다는 점입니다. 이 상대적 분포 변화는 Claude가 이러한 더 복잡한 작업에서 더 능숙해졌음을 시사할 수 있지만, 절대 작업량 증가가 아니라 팀별 워크플로 채택 변화일 수도 있습니다(자세한 한계는 부록 참조).

‘사소한 불편’ 해결

설문에서 엔지니어들이 작은 삶의 질 개선에 더 많은 시간을 쓴다고 밝혔고, 이에 부합하게 현재 Claude Code 작업의 **8.6%**가 “사소한 불편(papercut) 수정”으로 분류되었습니다. 여기에는 성능 시각화 도구 생성, 유지보수성 향상을 위한 리팩토링 같은 큰 작업과, 터미널 단축키 생성 같은 작은 작업이 포함됩니다. 이는 보고된 생산성 향상에 기여하고(그동안 미뤄졌던 삶의 질 개선이 장기적으로 효율성을 올릴 수 있음), 일상 업무의 마찰과 좌절을 줄일 가능성이 있습니다.

팀 간 작업 변이

팀별 현재 작업 차이를 분석하기 위해, 우리는 분류 방식을 정교화하여 8월의 각 기록을 단일 주요 코딩 작업에 할당하고, 내부 팀(세로축)별로 데이터를 분할했습니다. 누적 막대 차트는 각 팀의 코딩 작업 분포를 보여줍니다:

그림 5. 해당 팀의 Claude Code 사용이 다양한 코딩 작업(가로축)별로 어떻게 분포되는지 보여주며, 범례에 따라 작업 유형별로 색상으로 구분되어 있습니다. 맨 위 막대(“All Teams”)는 전체 분포를 나타냅니다.

가장 흔한 작업은 신규 기능 구현, 디버깅, 그리고 코드 이해입니다. 이는 팀별 비교를 위한 기준선을 제공합니다.

주요 팀별 패턴:

• 사전학습(Pre-training) 팀은 신규 기능 구현(54.6%)에 Claude Code를 자주 사용하며, 많은 부분이 추가 실험 수행입니다.
• 정렬 & 안전(Alignment & Safety) 및 후학습(Post-training) 팀은 프런트엔드 개발(각각 7.5%, 7.4%)을 가장 많이 수행하며, 주로 데이터 시각화 생성에 활용합니다.
• 보안(Security) 팀은 코드 이해(48.9%)에 Claude Code를 자주 사용하며, 코드베이스의 다양한 부분의 보안 함의를 분석·이해하는 데 집중합니다.
• 비기술(Non-technical) 직원은 디버깅(51.5%)—네트워크 이슈나 Git 작업 해결—과 데이터 사이언스(12.7%)에 Claude Code를 자주 사용합니다. Claude는 기술 지식의 격차를 메우는 데 가치가 있어 보입니다.

이러한 팀별 패턴 다수는 설문과 인터뷰에서 관찰한 역량 확장을 재현합니다: 팀이 시간이나 기술셋 부족으로 못 했을 새로운 종류의 일을 가능하게 한 것입니다. 예컨대 사전학습 팀은 많은 추가 실험을 수행했고, 비기술 직원은 코드 오류를 고칠 수 있었습니다. 데이터는 팀이 핵심 작업에 Claude를 사용함을 시사하면서도(예: 인프라 팀은 인프라/DevOps 작업에 가장 흔히 사용), 종종 핵심 작업을 보강한다는 점도 보여줍니다(예: 연구자는 데이터 시각화를 위해 프런트엔드를 구축). 이는 Claude가 모든 사람을 더 풀스택으로 만드는 데 기여하고 있음을 시사합니다.

앞으로의 방향

지난 1년간 Anthropic 직원들은 Claude 사용을 크게 늘려, 기존 작업을 가속할 뿐 아니라 새로운 코드베이스 학습, 고된 작업 감소, 새로운 도메인 확장, 그동안 미뤄진 개선 과제 해결에 활용했습니다. Claude가 더 자율적이고 유능해짐에 따라, 엔지니어들은 AI 위임을 새로운 방식으로 사용하면서도 미래에 필요한 기술이 무엇인지 모색하고 있습니다. 이러한 변화는 명확한 생산성과 학습의 이점을 가져오지만, 소프트웨어 엔지니어링의 장기 궤적에 대한 진정한 불확실성도 동반합니다. AI가 과거의 전환—저수준에서 고수준 언어로, 혹은 개인 기여자에서 관리자 역할로—을 닮게 될까요, 아니면 더 멀리 나아갈까요?

아직은 초기입니다—Anthropic 내부에는 조기 수용자가 많고, 환경은 급변하며, 우리의 발견은 지금 당장 다른 조직이나 맥락에 일반화되지 않을 수 있습니다(한계는 부록 참조). 연구는 이러한 불확실성을 반영합니다: 발견은 미묘하며, 단일한 합의나 명확한 지침이 나오지 않습니다. 그러나 이 변화들을 사려 깊고 효과적으로 탐색하는 방법에 대한 중요한 질문을 제기합니다.

이 초기 작업을 이어가기 위해 우리는 여러 단계를 밟고 있습니다. 엔지니어, 연구자, 리더십과 논의해 제기된 기회와 과제를 다룹니다. 여기에는 팀을 어떻게 연결하고 협업할지, 전문성 개발을 어떻게 지원할지, AI 증강 업무에 대한 모범 사례를 어떻게 세울지(예: 우리의 AI 유창성 프레임워크)가 포함됩니다. 또한 엔지니어를 넘어 조직 전반의 역할에 대한 AI 변혁을 이해하고, CodePath 같은 외부 기관이 AI 지원 미래에 맞게 컴퓨터 과학 커리큘럼을 적응하도록 지원합니다. 앞으로는 AI 역량이 발전함에 따라 점점 중요해질 수 있는 역할 진화 경로나 재교육 같은 구조적 접근도 고려하고 있습니다.

우리는 2026년에 더 구체적 계획을 공유할 것으로 예상합니다. Anthropic은 책임 있는 직장 전환을 위한 실험실입니다; 우리는 AI가 업무를 어떻게 변혁하는지 연구할 뿐 아니라, 그 변혁을 사려 깊게 탐색하는 방법을 우리로부터 시작해 실험하고자 합니다.

선택한 문구를 한국어로 번역했습니다.

부록

한계

우리의 설문 결과에는 여러 방법론적 한계가 있습니다. 우리는 광범위한 조직 대표성을 보장하기 위해 편의 표본추출과 목적 표본추출을 모두 통해 응답자를 선정했습니다. 설문을 여러 내부 Slack 채널에 게시해 68개의 응답을 얻었고, 또한 조직도에서 연구 및 제품 기능에 걸친 20개의 다양한 팀을 선정해 팀당 5-10명에게 직접 메시지를 보냈습니다(총 아웃리치 n=207) — 최종 64개의 응답으로 31%의 응답률을 기록했습니다. 우리는 응답한 첫 53명을 인터뷰했습니다. 여기에는 선택 편향이 존재할 가능성이 큽니다. Claude에 특히 적극적으로 참여했거나 강한 의견(긍정적 혹은 부정적)을 가진 사람들이 더 응답했을 수 있으며, 보다 중립적인 경험을 가진 사람들은 과소대표되었을 수 있습니다.

추가로, 응답은 사회적 바람직성 편향의 영향을 받을 수 있습니다(응답이 익명이지 않고 모든 참여자가 Anthropic 직원이므로, Claude의 영향에 대한 긍정적 평가가 과대화되었을 가능성). 또한 최근성 편향도 있을 수 있습니다(참여자에게 12개월 전의 생산성과 사용 패턴을 회상하도록 요청하는 것은 기억 왜곡의 영향을 받습니다). 더 나아가, 논의했듯 생산성은 일반적으로 정확히 추정하기 매우 어렵기 때문에, 이러한 자기보고 결과는 어느 정도 유보적으로 받아들여야 합니다. 자기보고 인식은 보다 객관적인 Claude Code 사용 데이터와 함께 해석되어야 하며, 향후 연구는 익명 데이터 수집과 더 견고하게 검증된 측정 도구로부터 이점을 얻을 것입니다.

우리의 Claude Code 분석은 기간별 비례 표본추출을 사용하므로, 작업 분포의 상대적 변화만 측정할 수 있고 절대적인 작업 물량 변화는 측정할 수 없습니다. 예를 들어, 기능 구현이 Claude Code 사용의 14%에서 37%로 증가했다고 보고할 때, 이것이 총 기능 작업량이 더 많아졌다는 것을 반드시 의미하지는 않습니다.

마지막으로, 이 연구는 2025년 8월에 수행되었으며 당시 Claude Sonnet 4와 Claude Opus 4가 최첨단 모델이었습니다. AI 발전의 급속한 속도를 고려할 때, 우리가 관찰한 패턴은 더 새로운 모델이 등장함에 따라 이미 변했을 가능성이 있습니다.