Claude를 만든 앤트로픽은 엔지니어들에게 클로드 코드로 만드는것을 적극 권장하는 것으로 유명한데요. 그들의 일하는 방식이 어떻게 바뀌었는지 스스로 돌아본 리포트(How AI is transforming work at Anthropic)가 공개되었습니다. AI는 정말 인간의 일을 줄여줄까요? Gemini가 친절하게 번역했습니다.
AI는 우리가 일하는 방식을 어떻게 변화시키고 있을까요?
AI의 경제적 영향에 대한 앤트로픽의 지난 연구는 노동 시장 전체를 조망하며 다양한 직업군을 다루었습니다. 하지만 이번에는 AI 기술을 가장 먼저 받아들인 사람들, 즉 ‘우리 자신’을 좀 더 자세히 연구해 본다면 어떨까요?
우리는 시선을 내부로 돌려 2025년 8월, 132명의 앤트로픽 엔지니어와 연구원을 대상으로 설문조사를 실시하고, 53명과 심층 인터뷰를 진행했으며, 내부의 ‘클로드 코드(Claude Code)’ 사용 데이터를 분석했습니다. 이를 통해 AI 사용이 앤스로픽 내부의 상황을 어떻게 바꾸고 있는지 알아보았습니다. 그 결과, AI 사용이 소프트웨어 개발자의 업무 본질을 근본적으로 바꾸고 있으며, 이는 희망과 우려를 동시에 낳고 있음을 발견했습니다.
우리의 연구는 큰 변화에 직면한 직장의 모습을 보여줍니다. 엔지니어들은 훨씬 더 많은 일을 처리하고 있고, 자신의 주 전문 분야를 넘어선 작업까지 수행하는 ‘풀스택(Full-stack, 다방면의 기술을 갖춘)’ 개발자가 되고 있으며, 학습과 작업 수정(iteration) 속도를 높이고, 이전에는 방치했던 과제들을 해결하고 있습니다.
하지만 이러한 업무 범위의 확장은 사람들이 ‘득과 실(trade-offs)’에 대해 고민하게 만듭니다. 어떤 이들은 깊이 있는 기술적 역량을 잃거나 AI가 내놓은 결과물을 제대로 감독할 능력이 떨어질까 봐 걱정합니다. 반면, 더 넓은 시야에서 높은 수준의 사고를 할 수 있는 기회라며 이를 반기는 이들도 있습니다. AI와의 협업이 늘어나면서 동료와의 협업이 줄었다는 의견도 있었고, 결국에는 자신의 일자리를 스스로 자동화하여 없애버리는 것은 아닌지 우려하는 목소리도 있었습니다.
물론, AI를 만드는 회사에서 AI의 영향을 연구한다는 것은 특수한 위치(privileged position)에 있음을 의미한다는 점을 인정합니다. 우리 엔지니어들은 최첨단 도구를 가장 먼저 접하고, 비교적 안정적인 분야에서 일하며, 스스로가 다른 산업에 영향을 미치는 AI 변화를 주도하는 당사자들입니다. 그럼에도 불구하고 이 결과를 발표하는 것이 전반적으로 유익하다고 판단했습니다. 앤로픽 내부 엔지니어들에게 일어나는 일이 앞으로 더 넓은 사회적 변화의 ‘전조(harbinger)’가 될 수 있기 때문입니다. 우리의 발견은 여러 분야에서 조기에 주목해야 할 과제와 고려 사항들을 시사합니다 (다만, 주의 사항은 부록의 ‘한계점’ 섹션을 참조해 주세요). 데이터 수집 당시 사용 가능한 최고 성능 모델은 클로드 소네트 4(Claude Sonnet 4)와 클로드 오퍼스 4(Claude Opus 4)였으며, 성능은 계속 발전하고 있습니다.
더 강력해진 AI는 생산성의 이점을 가져오지만, 동시에 기술적 전문성 유지, 의미 있는 협업의 보존, 그리고 AI와 공존하는 직장에서 필요한 새로운 학습, 멘토링, 경력 개발 방식 등 불확실한 미래에 대한 질문을 던집니다. 우리는 ‘향후 전망’ 섹션에서 이러한 질문들을 내부적으로 탐구하기 위해 취하고 있는 초기 단계들을 논의합니다. 또한 최근 블로그 포스트인 ‘AI 관련 경제 정책 아이디어’를 통해 잠재적인 정책 대응 방안도 모색했습니다.
주요 발견 (Key findings)
이 섹션에서는 설문조사, 인터뷰, 클로드 코드 데이터에서 나온 결과를 간략히 요약합니다. 상세한 결과, 방법론, 주의 사항은 아래 섹션에서 다룹니다.
설문조사 데이터
- 주요 용도: 앤로픽 엔지니어와 연구원들은 주로 **코드 오류 수정(디버깅)**과 코드베이스(전체 소스 코드) 파악을 위해 클로드를 가장 자주 사용합니다. 디버깅과 코드 이해가 가장 흔한 사용 사례입니다(그림 1).
- 사용량 및 생산성 증가: 직원들은 업무의 60%에 클로드를 사용하며, 이를 통해 50%의 생산성 향상을 경험했다고 답했습니다. 이는 작년 이맘때보다 2~3배 증가한 수치입니다. 생산성 향상은 작업 카테고리당 소요 시간이 약간 줄어든 형태보다는, 산출물의 양(Output volume)이 상당히 늘어난 형태로 나타났습니다(그림 2).
- 새로운 업무 수행: 클로드의 도움을 받은 업무 중 27%는 AI 없이는 하지 않았을 일들이었습니다. 예를 들어 프로젝트 규모 확장, 있으면 좋지만 필수는 아니었던 도구 제작(예: 대화형 데이터 대시보드), 사람이 직접 하기엔 비용 효율이 떨어지는 탐색적 작업 등이 포함됩니다.
- 완전 위임은 제한적: 대부분의 직원이 클로드를 빈번하게 사용하지만, ‘완전히 믿고 맡길 수 있는(검증 없이 위임 가능한)’ 업무는 0~20% 수준이라고 답했습니다. 클로드는 끊임없는 협업자이지만, 검증 없이 업무를 넘기기보다는 특히 중요한 업무일수록 적극적인 감독과 검증이 필요합니다.
심층 인터뷰 (Qualitative interviews)
- 위임에 대한 감각 발달: 엔지니어들은 검증하기 쉬운 작업(“맞는지 틀린지 딱 보면 알 수 있는 것”), 실패해도 위험이 적은 작업(“일회성 디버깅이나 연구용 코드”), 또는 지루한 작업(“내가 그 일을 하고 싶은 마음이 클수록 클로드를 사용하지 않을 가능성이 높습니다”)을 위임하는 경향이 있습니다. 많은 이들이 단순한 작업으로 시작해 점차 복잡한 작업을 맡기는 ‘신뢰 구축 과정’을 묘사했습니다. 현재 설계나 ‘취향(taste)’이 필요한 작업은 대부분 직접 하고 있지만, 모델이 발전함에 따라 이 경계도 다시 조정되고 있습니다.
- 기술의 확장과 일부 위축: 클로드는 사람들이 더 많은 영역으로 기술을 확장하게 해줍니다(예: “프론트엔드나 트랜잭션 데이터베이스 등 예전에는 건드리기 무서워했던 분야도 능숙하게 작업할 수 있습니다”). 하지만 역설적으로 코드를 직접 작성하고 비평하는 데 필요한 깊이 있는 기술이 퇴화할까 우려하는 직원들도 있습니다. (“결과물을 만드는 게 너무 쉽고 빠르다 보니, 시간을 들여 무언가를 깊이 배우기가 점점 어려워집니다.”)
- 코딩이라는 ‘장인정신’과의 관계 변화: 어떤 엔지니어들은 AI의 도움을 받아들이고 결과에 집중합니다(“저는 제가 코딩하는 것 자체를 즐긴다고 생각했는데, 사실은 코딩을 통해 얻는 결과물을 즐기는 것이었습니다”). 반면 다른 이들은 “코딩 과정의 일부분이 그리운 건 사실”이라고 말합니다.
- 직장 내 사회적 역학 변화: 동료에게 물어보던 질문들이 이제 클로드에게 먼저 향합니다. 그 결과 멘토링이나 협업 기회가 줄어들었다는 보고가 있습니다. (“사람들과 일하는 걸 좋아하는데 그들을 덜 ‘필요’로 하게 되어 슬픕니다… 주니어들이 예전만큼 질문하러 오지 않습니다.”)
- 커리어의 변화와 불확실성: 엔지니어들은 AI 시스템을 관리하는 상위 레벨의 업무로 이동하고 있으며 큰 생산성 향상을 보고 있습니다. 하지만 이러한 변화는 소프트웨어 엔지니어링 직업의 장기적인 궤적에 대한 의문을 제기합니다. 어떤 이들은 상반된 감정을 표현합니다. “단기적으로는 낙관적이지만, 장기적으로는 AI가 모든 걸 하게 되어 저를 포함한 많은 사람이 쓸모없어질 것 같습니다.” 또 다른 이들은 미래의 역할이 어떻게 될지 “말하기 어렵다”며 진정한 불확실성을 강조했습니다.
Claude Code 사용 트렌드
- 자율성 증가: 클로드는 점점 더 복잡한 작업을 자율적으로 처리하고 있습니다. 6개월 전 클로드 코드는 사람의 개입 없이 약 10가지 작업을 수행했으나, 지금은 약 20가지 작업을 수행하며 더 복잡한 워크플로를 처리하는 데 사람의 조종이 덜 필요해졌습니다(그림 3). 엔지니어들은 코드 설계/기획(사용의 1%에서 10%로 증가)이나 새로운 기능 구현(14%에서 37%로 증가) 같은 복잡한 작업에 클로드를 점점 더 많이 사용하고 있습니다(그림 4).
- ‘페이퍼컷(Papercuts)’ 해결: 클로드 코드 작업의 8.6%는 삶의 질을 높이는 사소한 문제 해결, 즉 ‘페이퍼컷 고치기’에 쓰입니다. 예를 들어 유지보수를 위해 코드를 재구성하는 일처럼 보통은 우선순위에서 밀리는 작업들입니다. 이런 작은 수정들이 모여 더 큰 생산성과 효율성을 만듭니다.
- 모두가 ‘풀스택’화: 팀마다 클로드를 사용하는 방식이 다르며, 종종 자신의 핵심 전문성을 보완하는 데 사용합니다. 보안팀은 낯선 코드를 분석하는 데, 정렬(Alignment) 및 안전 팀은 데이터를 시각화하는 프론트엔드 작업에 사용하는 식입니다(그림 5).
설문조사 데이터 (Survey data)
우리는 조직 전체의 엔지니어와 연구원 132명을 대상으로 설문조사를 실시하여, 그들이 매일 클로드를 정확히 어떻게 사용하는지 파악했습니다. 연구 및 제품 기능을 담당하는 다양한 팀의 직원들에게 사내 커뮤니케이션 채널과 직접 연락을 통해 설문을 배포했습니다. 방법론적 세부 사항은 부록의 ‘한계점’ 섹션에 포함되어 있으며, 다른 사람들이 우리의 접근 방식을 평가하고 자신의 연구에 적용할 수 있도록 설문 질문지를 공유합니다.
사람들은 어떤 코딩 작업에 클로드를 사용하는가?
설문에 참여한 엔지니어와 연구원들에게 “디버깅”(코드 오류 수정), “코드 이해”(기존 코드를 설명받아 파악하기), “리팩터링”(기존 코드 구조 개선), “데이터 사이언스”(데이터 분석 및 차트 작성 등)와 같은 다양한 코딩 작업에 클로드를 얼마나 자주 사용하는지 평가해달라고 요청했습니다.
가장 흔한 일일 작업은 다음과 같습니다. 대부분의 직원(55%)은 매일 디버깅을 위해 클로드를 사용했습니다. 42%는 코드 이해를 위해, 37%는 새로운 기능 구현을 위해 매일 사용했습니다. 사용 빈도가 낮은 작업은 고수준의 설계/기획(사람이 직접 주도하는 경향이 있는 작업)과 데이터 사이언스 및 프론트엔드 개발(전체적으로 덜 흔한 작업)이었습니다. 이는 ‘Claude Code 사용 트렌드’ 섹션에서 보고된 데이터 분포와 대략 일치합니다.
사용량과 생산성
직원들은 12개월 전에는 업무의 28%에 클로드를 사용하여 20%의 생산성 향상을 얻었다고 자가 보고했습니다. 반면 현재는 업무의 59%에 클로드를 사용하며 평균 50%의 생산성 향상을 달성했다고 답했습니다. (이는 우리 엔지니어링 조직 전체에 클로드 코드를 도입했을 때 엔지니어 1인당 하루에 병합된 풀 리퀘스트가 67% 증가한 것과 대략 일치합니다.) 전년 대비 비교는 상당히 극적이며, 두 지표 모두 1년 만에 2배 이상 증가했음을 시사합니다. 사용량과 생산성은 강한 상관관계를 보이며, 분포의 끝부분에 있는 14%의 응답자는 클로드를 통해 생산성을 100% 이상 높이고 있다고 답했습니다. 이들이 우리의 사내 ‘파워 유저’들입니다.
이 결과(및 아래의 자가 보고된 생산성 결과)에 대해 주의할 점은 생산성을 정확히 측정하기 어렵다는 것입니다. 최근 AI 연구 비영리 단체인 METR의 연구에 따르면, 숙련된 개발자들이 익숙한 코드베이스에서 AI와 작업할 때 생산성 향상을 과대평가하는 경향이 있었습니다. 하지만 METR이 예상보다 낮은 생산성의 원인으로 지목한 요인들(예: 크고 복잡한 환경에서 AI 성능 저하, 암묵적 지식/맥락이 많이 필요한 경우)은 우리 직원들이 클로드에게 위임하지 않는다고 답한 작업 유형과 밀접하게 일치합니다(아래 ‘AI 위임 접근 방식’ 참조). 여러 작업에 걸쳐 자가 보고된 우리의 생산성 향상은 직원들이 전략적인 AI 위임 기술을 개발했음을 반영할 수 있으며, 이는 METR 연구에서는 고려되지 않은 부분입니다.
직원들에게 현재 클로드를 사용하는 작업 카테고리에서 전체 소요 시간과 작업 산출량이 어떻게 변했는지 물었을 때 흥미로운 생산성 패턴이 나타났습니다. 거의 모든 작업 카테고리에서 소요 시간은 순감소했고, 산출물 양(output volume)은 더 큰 폭으로 순증가했습니다.
하지만 원본 데이터를 더 깊이 들여다보면, 시간 절약 응답이 양극단으로 나뉘는 것을 볼 수 있습니다. 어떤 사람들은 클로드의 도움을 받는 작업에 오히려 더 많은 시간을 쓰고 있습니다.
왜 그럴까요? 사람들은 일반적으로 클로드가 짠 코드를 디버깅하고 정리하는 데 더 많은 시간이 든다고 설명했습니다(예: “직관(vibe)에만 의존해 코딩하다가 수습 불가능한 상황에 빠졌을 때”). 또한 자신이 직접 짜지 않았기 때문에 코드를 이해하는 데 더 많은 인지적 부담을 져야 한다고 했습니다. 일부는 ‘가능하게 하는(enabling)’ 측면에서 시간을 더 쓴다고 언급했습니다. 한 명은 클로드 덕분에 “예전 같으면 바로 포기했을 작업을 끝까지 붙들고 있게 해준다”고 했고, 다른 이는 더 철저한 테스트와 새로운 코드베이스에 대한 학습 및 탐색을 가능하게 한다고 했습니다. 일반적으로 시간을 절약하는 엔지니어들은 검증하기 쉬운 작업을 클로드에게 맡기는 반면, 시간을 더 쓰는 사람들은 AI가 생성한 코드를 디버깅하거나 클로드에게 더 많은 지침이 필요한 영역에서 작업하는 것으로 보입니다.
또한 보고된 시간 절약분이 어디에 재투자되는지는 데이터상 명확하지 않습니다. 추가적인 엔지니어링 작업인지, 비엔지니어링 업무인지, 클로드와의 상호작용 및 결과 검토인지, 아니면 업무 외 활동인지 알 수 없습니다. 우리의 작업 분류 체계는 엔지니어들이 시간을 쓰는 모든 방식을 포착하지 못합니다. 게다가 시간 절약은 자가 보고의 인식 편향을 반영할 수도 있습니다. 이러한 효과들을 분리해내기 위해서는 추가 연구가 필요합니다.
산출물 양의 증가는 더 직관적이고 실질적입니다. 모든 작업 카테고리에서 더 큰 폭의 순증가가 있었습니다. 이는 사람들이 개별 작업이 아닌 작업 카테고리(예: ‘디버깅’ 전체)에 대해 보고한다는 점을 고려하면 말이 됩니다. 즉, 디버깅이라는 카테고리에 쓰는 시간은 약간 줄어들면서도, 전체적인 디버깅 산출물은 훨씬 더 많이 만들어낼 수 있다는 뜻입니다. 생산성을 직접 측정하기는 매우 어렵지만, 이 자가 보고 데이터는 앤로픽에서 AI가 주로 산출물 양의 증가를 통해 생산성을 높이고 있음을 시사합니다.
클로드가 가능하게 한 새로운 업무
우리가 궁금했던 한 가지는, 클로드가 질적으로 새로운 종류의 업무를 가능하게 하는가, 아니면 어차피 직원들이 했을 일(속도는 더 느렸겠지만)을 돕는 것인가 하는 점이었습니다.
직원들은 클로드 지원 업무의 27%가 클로드 없이는 하지 않았을 일이라고 추정했습니다. 엔지니어들은 프로젝트 규모 확장, ‘있으면 좋은(nice-to-haves)’ 도구(예: 대화형 데이터 대시보드), 문서화나 테스트처럼 유용하지만 지루한 작업, 그리고 수동으로 하기엔 비용 효율이 안 나오는 탐색적 작업 등을 예로 들었습니다. 한 사람은 나쁜 구조의 코드를 리팩터링하거나 “다른 작업을 더 빨리 끝내게 도와주는 작은 도구”를 만드는 등, 예전에는 삶의 질을 떨어뜨렸던 더 많은 “페이퍼컷(papercuts)”을 고칠 수 있게 되었다고 설명했습니다. 사용 데이터 분석에서도 클로드 코드 작업의 8.6%가 ‘페이퍼컷 수정’과 관련된 것임을 확인했습니다.
다른 연구원은 여러 버전의 클로드를 동시에 실행하여 한 문제에 대해 다양한 접근 방식을 탐색한다고 설명했습니다.
“사람들은 고성능 모델을 마치 ‘더 빠른 자동차’ 한 대를 얻은 것처럼 생각합니다. 하지만 백만 마리의 말을 갖게 되면… 수많은 아이디어를 테스트해 볼 수 있습니다… 탐험할 수 있는 여력이 생기면 훨씬 흥미롭고 창의적인 작업이 가능해집니다.”
다음 섹션에서 보겠지만, 이러한 새로운 업무는 종종 엔지니어가 자신의 핵심 전문 분야 밖의 과제를 해결하는 것을 포함합니다.
얼마나 많은 업무를 클로드에게 완전히 위임할 수 있는가?
엔지니어들은 클로드를 빈번하게 사용하지만, 절반 이상은 클로드에게 “완전히 위임(fully delegate)”할 수 있는 업무가 0~20%에 불과하다고 답했습니다. (응답자들이 ‘완전 위임’을 어떻게 해석하느냐에 따라 차이가 있을 수 있습니다. 전혀 검증이 필요 없는 작업부터 가벼운 감독만 필요한 작업까지 다양할 수 있습니다.) 그 이유를 설명하면서 엔지니어들은 클로드와 능동적이고 반복적으로 작업하며, 특히 복잡하거나 코드 품질 기준이 중요한 고위험 영역에서는 결과물을 철저히 검증한다고 묘사했습니다. 이는 엔지니어들이 검증 없이 업무를 넘기기보다는 클로드와 긴밀히 협업하며 작업을 확인하고 있으며, “완전 위임”에 대해 높은 기준을 가지고 있음을 시사합니다.
심층 인터뷰 (Qualitative interviews)
이러한 설문조사 결과는 상당한 생산성 향상과 업무 패턴의 변화를 보여주지만, 엔지니어들이 실제로 매일 이러한 변화를 어떻게 경험하고 있는지에 대한 의문을 남깁니다. 이 지표 뒤에 있는 인간적인 차원을 이해하기 위해, 설문에 응답한 앤로픽 엔지니어 및 연구원 중 53명과 심층 인터뷰를 진행하여 그들의 생각과 감정을 더 깊이 들여다보았습니다.
AI 위임 접근 방식
엔지니어와 연구원들은 워크플로에서 클로드를 생산적으로 활용하기 위해 다양한 전략을 개발하고 있습니다. 사람들은 일반적으로 다음과 같은 작업을 위임합니다.
- 사용자의 배경지식이 없고 복잡도가 낮은 작업:
“제 배경지식이 부족하지만 전체적인 복잡도 역시 낮다고 생각되는 일에 클로드를 씁니다.””제가 가진 인프라(infrastructure) 문제의 대부분은 어렵지 않아서 클로드가 처리할 수 있습니다… 저는 Git이나 리눅스를 잘 모르는데… 클로드가 이 분야에서 저의 경험 부족을 잘 메워줍니다.” - 검증하기 쉬운 작업:
“생성 노력에 비해 검증 노력이 크지 않은 모든 작업에 절대적으로 훌륭합니다.” - 잘 정의되거나 독립적인 작업:
“프로젝트의 하위 구성 요소가 나머지 부분과 충분히 분리되어 있다면, 클로드에게 한번 해보라고 시킵니다.” - 코드 품질이 중요하지 않은 작업:
“일회성 디버깅이나 연구용 코드라면 바로 클로드에게 보냅니다. 개념적으로 어렵거나, 아주 구체적인 디버그 주입이 필요하거나, 설계 문제라면 제가 직접 합니다.” - 반복적이거나 지루한 작업:
“내가 그 일을 하고 싶은 마음이 클수록 클로드를 사용하지 않을 가능성이 높습니다. 반면 저항감이 크게 느껴진다면… 종종 클로드와 그 작업에 대해 대화를 시작하는 게 더 쉽다는 걸 발견합니다.”(설문조사에서 사람들은 평균적으로 클로드 지원 업무의 44%가 자신이 직접 하고 싶지 않았을 작업들로 구성되어 있다고 답했습니다.) - 직접 하는 것보다 프롬프트 입력이 더 빠를 때:
“10분 안에 끝날 것으로 예상되는 작업이라면… 굳이 클로드를 쓰지 않을 겁니다.””지금 가장 큰 걸림돌은 아마도 ‘콜드 스타트(cold start)’ 문제일 겁니다. 콜드 스타트란, 우리 팀의 코드베이스가 어떻게 작동하는지에 대해 저는 본능적으로 알고 있지만 클로드는 기본적으로 알지 못하는 방대한 내부 정보를 의미합니다… 완벽한 프롬프트를 짜느라 시간을 보낼 수도 있겠지만, 그냥 제가 가서 직접 하는 게 낫습니다.”
직원들이 위임을 결정할 때 언급한 이러한 요인들은 외부 연구(METR)에서 AI 관련 생산성 저하를 설명하는 요인들(코드베이스에 대한 높은 숙련도, 거대하고 복잡한 저장소 등)과 유사했습니다. 인터뷰 전반에 걸친 이러한 위임 기준의 수렴은 적절한 작업 선택이 AI 생산성 향상의 중요한 요인임을 시사합니다 (이는 향후 생산성 연구에서 신중하게 통제되어야 할 변수입니다).
신뢰하되 검증하라 (Trust but verify)
많은 사용자가 클로드 사용이 시간이 지남에 따라 점점 더 복잡한 작업을 위임하는 과정으로 발전했다고 묘사했습니다. “처음에는 Rust 프로그래밍 언어에 대한 기초적인 질문으로 AI 도구를 썼지만… 최근에는 모든 코딩에 클로드 코드를 사용하고 있습니다.”
한 엔지니어는 신뢰 구축 과정을 구글 맵(Google Maps) 같은 기술을 받아들이는 것에 비유했습니다.
“처음에는 모르는 길을 갈 때만 구글 맵을 썼습니다… 이건 제가 모르는 SQL을 짤 때 클로드를 쓰지만 아는 파이썬을 짤 때는 안 쓰는 것과 같습니다. 그러다 대충은 알지만 ‘마지막 1마일’을 모르는 길에도 구글 맵을 쓰기 시작했죠… 오늘날 저는 매일 출퇴근할 때조차 구글 맵을 씁니다. 다른 길로 가라고 하면 그냥 믿고 따릅니다… 오늘날 클로드 코드도 비슷하게 사용합니다.”
엔지니어들은 클로드를 자신의 전문 분야 내에서 쓸지 밖에서 쓸지에 대해 의견이 갈립니다. 일부는 구현 시간을 줄이기 위해 “주변부” 영역에 사용합니다. 다른 이들은 결과물을 검증할 수 있는 익숙한 영역을 선호합니다(“저는 클로드가 무엇을 하는지 완전히 이해할 수 있는 방식으로 사용합니다”). 한 보안 엔지니어는 클로드가 “정말 위험한 방식으로 똑똑한, 재능 있는 주니어 엔지니어가 제안할 법한” 해결책을 내놓았을 때 경험의 중요성을 강조했습니다. 즉, 판단력과 경험이 있는 사용자만이 문제점을 인식할 수 있는 경우였습니다.
다른 엔지니어들은 두 가지 유형의 작업 모두에 클로드를 사용합니다. 실험적인 방식(“어떤 코딩 문제든 기본적으로 클로드에게 초안을 맡깁니다”)으로 사용하거나, 작업의 숙련도에 따라 접근 방식을 조정합니다.
“저는 제 전문성의 핵심인 작업(예상 가능하고 효과적으로 지시할 수 있어 가속기 역할을 하는 경우)과, 제 전문 분야에서 약간 벗어난 작업(대충은 알지만 구체적인 정의에 대한 기억이나 익숙함의 공백을 클로드가 채워줄 수 있는 경우) 모두에 도구를 사용합니다.”
“제가 잘 아는 분야라면 더 단호하게 클로드에게 무엇을 찾아야 할지 말합니다. 잘 모르는 분야라면 종종 클로드에게 전문가가 되어 제가 고려하고 연구해야 할 옵션과 통찰력을 달라고 요청합니다.”
사람들이 직접 하는 작업은 무엇인가?
사람들은 고수준의 전략적 사고가 필요한 작업이나, 조직적 맥락이나 “취향(taste)”이 필요한 설계 결정에는 클로드를 사용하지 않는다고 일관되게 말했습니다. 한 엔지니어는 설명했습니다. “저는 보통 고수준의 사고와 설계는 직접 합니다. 새로운 기능 개발부터 디버깅까지 위임할 수 있는 건 다 위임합니다.” 이는 설계 및 기획 작업에서 생산성 향상이 가장 적게 나타난 설문 데이터(그림 2)와 일치합니다. 하지만 많은 사람은 모델이 개선됨에 따라 위임의 경계가 정기적으로 재조정되는 “움직이는 과녁”이라고 묘사했습니다(아래 클로드 코드 사용 데이터는 6개월 전보다 현재 코딩 설계/기획 사용량이 상대적으로 더 많음을 보여줍니다).
기술의 변화 (Skill transformations)
새로운 능력…
설문 조사에서 클로드 지원 업무의 27%가 그렇지 않았다면 수행되지 않았을 것이라는 결과는 더 넓은 패턴을 반영합니다. 바로 엔지니어들이 AI를 사용하여 자신의 핵심 전문 분야 밖에서 작업한다는 것입니다. 많은 직원이 자신의 전문성을 벗어난 작업을 완료했다고 보고합니다. 백엔드 엔지니어가 UI를 만들고, 연구원이 시각화 도구를 만드는 식입니다. 한 백엔드 엔지니어는 클로드와 반복 작업을 통해 복잡한 UI를 구축한 경험을 설명했습니다. “제가 할 수 있는 것보다 훨씬 잘했습니다. 저는 절대 못 했을 겁니다. 제시간에는 더더욱이요… [디자이너들이] ‘잠깐, 이걸 당신이 했어요?’라고 묻길래 ‘아니요, 클로드가 했어요. 저는 그냥 프롬프트만 줬죠’라고 했습니다.”
엔지니어들은 “내 역할이 더욱 풀스택(full-stack)이 되어가고 있다… 프론트엔드, 트랜잭션 데이터베이스, API 코드 등 예전에는 전문가가 아니라서 건드리기 무서워했던 것들도 아주 능숙하게 작업할 수 있다”고 보고합니다. 이러한 능력 확장은 피드백 루프를 긴밀하게 하고 학습 속도를 높입니다. 한 엔지니어는 구축하고, 회의 잡고, 수정하는 “몇 주짜리 과정”이 동료들과 실시간 피드백을 주고받는 “몇 시간짜리 작업 세션”으로 바뀔 수 있다고 말했습니다.
일반적으로 사람들은 빠르게 프로토타입을 만들고, 작업을 병렬로 처리하고, 노가다(toil)을 줄이며, 전반적으로 야망의 수준을 높일 수 있는 새로운 능력에 열광했습니다. 한 수석 엔지니어는 “도구들이 확실히 주니어 엔지니어들을 더 생산적으로 만들고, 그들이 맡을 프로젝트의 유형에 대해 더 대담하게 만들고 있다”고 말했습니다. 또한 클로드 사용으로 인한 “활성화 에너지(activation energy)” 감소가 미루는 습관을 더 쉽게 이겨내게 해준다고 했습니다. “문제를 해결하기 위해 시작하는 데 필요한 에너지를 극적으로 줄여줘서 훨씬 많은 추가적인 일들을 기꺼이 처리하게 됩니다.”
…그리고 줄어드는 직접 학습 기회
동시에 일부는 “더 많이 위임할수록 기술이 퇴화(atrophy)하는 것”과 수동으로 문제를 해결할 때 발생하는 우발적인(또는 “부수적인”) 학습 기회를 잃는 것에 대해 걱정했습니다.
“어려운 문제를 직접 디버깅하다 보면 문제 해결에 직접적으로 쓸모없는 문서와 코드도 읽게 되는데, 이 모든 시간 동안 시스템이 어떻게 작동하는지에 대한 모델을 머릿속에 구축하게 됩니다. 클로드가 바로 문제로 데려다주기 때문에 그런 과정이 훨씬 줄어들었습니다.”
“예전에는 도구가 무엇을 할 수 있는지 이해하기 위해 모든 설정을 탐색했지만, 지금은 AI에게 새 도구 사용법을 알려달라고 의존하다 보니 전문성이 부족해집니다. 동료와의 대화에서 예전엔 즉시 기억해 냈던 것들을 이제는 AI에게 물어봐야 합니다.”
“클로드를 사용하면 쉬운 사례를 해결하며 과업 수행 방법을 배우는 단계를 건너뛰게 될 잠재적 위험이 있습니다. 그러면 나중에 더 복잡한 사례를 해결할 때 어려움을 겪게 됩니다.”
한 수석 엔지니어는 자신이 더 주니어였다면 기술에 대해 더 걱정했을 것이라고 말했습니다.
“저는 주로 답이 무엇이어야 하거나 어떻게 보여야 하는지 아는 경우에 AI를 사용합니다. 저는 ‘힘든 방식’으로 소프트웨어 엔지니어링을 하며 그 능력을 개발했습니다… 하지만 제가 [커리어 초기]였다면, 모델의 출력을 맹목적으로 받아들이기보다 내 능력을 키우기 위해 의도적인 노력을 많이 해야 한다고 생각했을 겁니다.”
코딩 기술의 퇴화가 우려되는 이유 중 하나는 “감독의 역설(paradox of supervision)” 때문입니다. 앞서 언급했듯이 클로드를 효과적으로 사용하려면 감독이 필요한데, 클로드를 감독하려면 AI 과잉 사용으로 퇴화할지도 모르는 바로 그 코딩 기술이 필요합니다. 한 사람은 이렇게 말했습니다.
“솔직히 제 기술 세트 자체보다는 감독과 관리 문제에 대해 훨씬 더 걱정합니다… 기술이 퇴화하거나 발전하지 못하는 것은, 작업을 독립적으로 수행하는 능력보다는 제가 관심 있는 작업에 대해 AI를 안전하게 사용할 수 있는 능력과 관련해서 주로 문제가 될 것입니다.”
이에 대항하기 위해 일부 엔지니어는 의도적으로 AI 없이 연습합니다. “가끔은 클로드가 완벽하게 해결할 수 있다는 걸 알면서도 시키지 않습니다. 저 자신을 날카롭게 유지하는 데 도움이 됩니다.”
우리는 여전히 직접 코딩하는 기술이 필요할까?
어쩌면 소프트웨어 엔지니어링은 과거에 그랬던 것처럼 더 높은 수준의 추상화로 이동하고 있는지도 모릅니다. 초기 프로그래머들은 기계와 훨씬 가까운 곳에서 작업했습니다. 메모리를 직접 관리하고, 어셈블리어로 작성하고, 심지어 물리적 스위치를 조작했습니다. 시간이 지나며 복잡한 저수준 작업을 자동으로 처리하는 더 인간 친화적인 고수준 언어가 등장했습니다. 특히 “바이브 코딩(vibe coding, 직관적 코딩)”의 부상과 함께, 우리는 이제 영어가 프로그래밍 언어가 되는 시대로 이동하고 있는지도 모릅니다. 우리 직원 중 한 명은 엔지니어 지망생들에게 “AI에게 [코드를 작성하게] 시키는 것을 잘하고, 더 높은 수준의 개념과 패턴을 배우는 데 집중하라”고 제안했습니다.
몇몇 직원들은 이러한 변화가 코드 자체가 아니라 “최종 제품과 최종 사용자”에 대해 더 높은 수준에서 생각할 힘을 준다고 느꼈습니다. 한 사람은 현재의 변화를 컴퓨터 공학에서 연결 리스트(linked-lists)를 배워야 했던 것에 비유했습니다. 이는 고수준 언어가 이제 자동으로 처리하는 기본 구조입니다. “그걸 할 줄 알아서 정말 다행이지만… 그런 저수준 작업을 수행하는 것이 정서적으로 특별히 중요한 건 아닙니다. 저는 코드가 저에게 무엇을 가능하게 해주는지에 더 관심을 갖고 싶습니다.” 다른 엔지니어는 비슷한 비교를 하면서도, 추상화에는 대가가 따른다고 지적했습니다. 고수준 언어로 이동하면서 대부분의 엔지니어는 메모리 처리에 대한 깊은 이해를 잃었습니다.
한 분야에서 기술을 계속 개발하면 클로드를 더 잘 감독하고 더 효율적으로 일할 수 있습니다(“제가 익숙한 분야일 때 제가 직접 하는 게 종종 더 빠르다는 걸 느낍니다”). 하지만 엔지니어들은 이것이 중요한지에 대해 의견이 갈립니다. 일부는 낙관적입니다.
“기술 침식에 대해 너무 걱정하지 않습니다. AI는 여전히 제가 문제를 신중하게 생각하게 만들고 새로운 접근 방식을 배우도록 돕습니다. 오히려 아이디어를 더 빨리 탐색하고 테스트할 수 있어서 일부 영역에서는 학습이 가속화되었습니다.”
다른 사람은 더 실용적이었습니다. “소프트웨어 엔지니어로서의 기술이 퇴화하고 있는 건 확실합니다… 하지만 필요하다면 그 기술들은 다시 돌아올 수 있고, 지금은 그냥 더 이상 필요하지 않을 뿐입니다!” 한 사람은 차트 만들기 같은 덜 중요한 기술만 잃었고, “중요한 코드는 여전히 아주 잘 짤 수 있다”고 언급했습니다.
가장 흥미로운 점은 한 엔지니어가 전제 자체에 도전했다는 것입니다. ” ‘녹슬어간다’는 프레임은 언젠가 코딩이 클로드 3.5 이전의 방식으로 돌아갈 것이라는 가정에 기반합니다. 저는 그렇게 되지 않을 것이라고 생각합니다.”
소프트웨어 엔지니어링의 장인정신과 의미
엔지니어들은 직접 코딩하는 것을 그리워하는지에 대해 의견이 극명하게 갈립니다. 어떤 이들은 진정한 상실감을 느낍니다. “저에게는 한 시대의 종말입니다. 25년 동안 프로그래밍을 해왔고, 그 기술에 유능함을 느끼는 것이 제 직업적 만족의 핵심 부분이었습니다.” 다른 이들은 새로운 업무 성격을 즐기지 못할까 봐 걱정합니다. “하루 종일 클로드에게 프롬프트만 입력하는 건 별로 재미없고 성취감도 없습니다. 음악을 틀고 몰입해서 직접 구현하는 게 훨씬 재미있고 보람찹니다.”
일부는 트레이드오프를 직시하고 받아들입니다. “그리운 부분(코드를 리팩터링할 때 느끼는 ‘젠(Zen)’ 같은 몰입 상태)이 분명히 있지만, 전반적으로 지금 훨씬 더 생산적이기 때문에 기꺼이 포기하겠습니다.”
한 사람은 클로드와 반복 작업을 하는 것이 더 재밌다고 했습니다. 사람보다 더 까다롭게 피드백을 줄 수 있기 때문입니다. 다른 이들은 결과물에 더 관심이 있습니다. 한 엔지니어는 말했습니다.
“이쯤 되면 두렵거나 지루할 거라고 예상했는데… 사실 별로 그렇지 않습니다. 오히려 훨씬 더 많은 것을 할 수 있어서 꽤 설렙니다. 저는 제가 코딩하는 걸 정말 즐긴다고 생각했는데, 사실은 코딩을 통해 얻는 결과물을 즐기는 것이었습니다.“
사람들이 AI의 도움을 받아들이느냐 아니면 직접 코딩의 상실을 슬퍼하느냐는 소프트웨어 엔지니어링의 어떤 측면을 가장 의미 있게 여기느냐에 달려 있는 것 같습니다.
직장 내 사회적 역학의 변화
가장 두드러진 주제 중 하나는 클로드가 동료에게 가던 질문들의 첫 번째 창구가 되었다는 것입니다. 한 직원은 “전반적으로 질문을 훨씬 많이 하지만, 그중 80~90%는 클로드에게 합니다”라고 언급했습니다. 이는 필터링 메커니즘을 만들어, 클로드가 일상적인 문의를 처리하고 동료들은 AI 능력을 넘어서는 더 복잡하고 전략적이거나 맥락이 중요한 문제를 다루게 합니다(“팀에 대한 의존도를 80% 줄였지만, 나머지 20%는 결정적이라 가서 이야기합니다”). 사람들은 또한 인간 협력자와 상호작용하듯 클로드와 “아이디어를 주고받습니다(bounce ideas off)”.
약 절반은 팀 협업 패턴이 변하지 않았다고 보고했습니다. 한 엔지니어는 여전히 사람들을 만나고, 맥락을 공유하고, 방향을 정하고 있으며, 가까운 미래에도 여전히 많은 협업이 있겠지만 “표준적인 집중 업무를 하는 대신 수많은 클로드들과 대화하게 될 것”이라고 생각했습니다.
그러나 다른 이들은 동료와의 상호작용이 줄었다고 묘사했습니다(“동료들보다 클로드와 훨씬 더 많이 일합니다”). 일부는 줄어든 사회적 마찰을 반깁니다(“동료의 시간을 뺏는 것에 대해 미안해하지 않아도 됩니다”). 다른 이들은 변화에 저항하거나(“흔한 반응이 ‘클로드한테 물어봤어?’인 게 별로입니다. 저는 사람들과 직접 대면해서 일하는 걸 즐기고 높게 평가합니다”), 예전 방식을 그리워합니다(“사람들과 일하는 걸 좋아하는데 그들을 덜 ‘필요’로 하게 되어 슬픕니다”). 몇몇은 시니어 엔지니어 대신 “클로드가 주니어 직원들에게 많은 코칭을 제공할 수 있기 때문에” 전통적인 멘토링 역학에 미치는 영향을 지적했습니다. 한 수석 엔지니어는 말했습니다.
“주니어들이 질문하러 오는 빈도가 줄어든 건 슬픈 일입니다. 물론 그들이 확실히 더 효과적으로 답을 얻고 더 빨리 배우고 있긴 하지만요.”
커리어의 불확실성과 적응
많은 엔지니어가 자신의 역할이 코드 작성에서 AI 관리로 바뀌고 있다고 묘사합니다. 엔지니어들은 점점 자신을 “AI 에이전트의 관리자”로 보고 있으며, 일부는 이미 “상시적으로 최소 몇 개의 [클로드] 인스턴스를 실행”하고 있습니다. 한 사람은 자신의 업무가 “70% 이상 새로운 코드 작성자보다는 코드 검토자/수정자”로 바뀌었다고 추정했고, 다른 사람은 “1명, 5명, 또는 100명의 클로드 작업에 대해 책임을 지는 것”을 미래 역할의 일부로 보았습니다.
장기적으로 커리어 불확실성은 광범위합니다. 엔지니어들은 이러한 변화를 더 넓은 산업 변화의 전조로 보았고, 많은 이들이 몇 년 뒤 자신의 커리어가 어떻게 될지 “말하기 어렵다”고 했습니다. 일부는 단기적 낙관론과 장기적 불확실성 사이의 갈등을 표현했습니다. “단기적으로는 낙관적이지만, 장기적으로는 AI가 결국 모든 것을 하게 되어 저와 다른 많은 사람을 무용지물로 만들 것이라고 생각합니다,”라고 한 명은 말했습니다. 다른 이들은 더 날카롭게 지적했습니다. “매일 출근해서 제 일자리를 없애는 일을 하는 기분입니다.”
일부 엔지니어는 더 낙관적이었습니다. 한 명은 “주니어 개발자들이 걱정되지만, 한편으로 주니어들이야말로 신기술에 가장 목말라 있다는 점을 높이 삽니다. 저는 직업의 궤적에 대해 전반적으로 매우 낙관적입니다”라고 말했습니다. 그들은 미숙한 엔지니어가 문제 있는 코드를 배포할 잠재적 위험이 있지만, 더 나은 AI 가드레일(안전장치), 내장된 교육 리소스, 실수로부터의 자연스러운 학습이 결합되어 분야가 적응해 나갈 것이라고 주장했습니다.
우리는 사람들이 자신의 미래 역할을 어떻게 그리고 있으며 적응 전략이 있는지 물었습니다. 일부는 더 전문화할 계획을 언급했고(“AI의 작업을 의미 있게 검토하는 능력을 기르는 데는 더 오랜 시간이 걸리고 더 많은 전문화가 필요할 것입니다”), 일부는 미래에 더 대인 관계적이고 전략적인 업무에 집중할 것이라고 예상했습니다(“우리는 합의점을 찾는 데 더 많은 시간을 쓰고, AI가 구현에 더 많은 시간을 쓰게 할 것입니다”). 한 사람은 클로드를 커리어 개발에 사용하여 업무와 리더십 기술에 대한 피드백을 받는다고 했습니다(“무언가를 배우거나 완전히 배우지 않고도 효과적으로 일할 수 있는 속도가 완전히 바뀌었습니다. 마치 제 한계(ceiling)가 산산조각 난 기분입니다”).
전반적으로 많은 이들이 깊은 불확실성을 인정합니다. “미래에 어떤 구체적인 기술이 유용할지에 대해 확신이 매우 낮습니다.” 한 팀 리더는 말했습니다. “아무도 무슨 일이 일어날지 모릅니다… 중요한 건 그저 정말로 적응력을 갖추는 것입니다.”
Claude Code 사용 트렌드 (Claude Code usage trends)
설문조사와 인터뷰 데이터는 클로드 사용 증가가 사람들이 더 빨리 일하고 새로운 유형의 업무를 맡는 데 도움을 주지만, AI 위임과 기술 개발을 둘러싼 긴장도 동반한다는 것을 보여줍니다. 하지만 자가 보고 데이터는 이야기의 일부만 들려줍니다. 이를 보완하기 위해 우리는 앤로픽 팀 전반의 실제 클로드 사용 데이터를 분석했습니다. 설문 응답자들이 클로드 코드(Claude Code)를 주로 사용한다고 답했기 때문에, 개인 정보 보호 분석 도구를 사용하여 2025년 2월과 8월의 클로드 코드 내부 기록(transcript) 20만 건을 분석했습니다.
더 적은 감독으로 더 어려운 문제 해결
지난 6개월 동안 클로드 코드 사용은 더 어렵고 자율적인 코딩 작업으로 이동했습니다(그림 3).
- 직원들은 클로드 코드로 점점 더 복잡한 작업을 처리하고 있습니다. 각 기록의 작업 복잡도를 1~5점 척도로 추정했습니다(1은 ‘기초적인 편집’, 5는 ‘전문가가 몇 주/몇 달 걸려야 하는 수준의 작업’). 평균 작업 복잡도는 3.2에서 3.8로 증가했습니다. 차이를 설명하자면, 평균 3.2점 작업은 “파이썬 모듈 임포트 오류 해결”을 포함하고, 평균 3.8점 작업은 “캐싱 시스템 구현 및 최적화”를 포함했습니다.
- 기록당 클로드 코드가 수행하는 최대 연속 도구 호출(tool calls) 수가 116% 증가했습니다. 도구 호출은 파일 편집이나 명령어 실행 같은 외부 도구를 사용하여 클로드가 취하는 행동을 의미합니다. 클로드는 이제 6개월 전의 9.8회에 비해 사람의 개입 없이 21.2회의 독립적인 도구 호출을 연결하여 수행합니다.
- 사람의 턴(turn) 수는 33% 감소했습니다. 기록당 평균 사람의 턴 수는 6.2회에서 4.1회로 감소했습니다. 이는 6개월 전보다 주어진 작업을 완수하는 데 더 적은 사람의 입력이 필요함을 시사합니다.
이러한 사용 데이터는 설문 데이터를 뒷받침합니다. 엔지니어들은 점점 더 복잡한 작업을 클로드에게 위임하고 있으며, 클로드는 더 적은 감독을 필요로 합니다. 이것이 관찰된 생산성 향상을 주도하고 있을 가능성이 큽니다.
작업의 분포 – 어떤 작업을 클로드로 처리하나?
우리는 클로드 코드 기록을 하나 이상의 코딩 작업 유형으로 분류하여, 지난 6개월 동안 다양한 작업에 대한 사용이 어떻게 진화했는지 연구했습니다.
사용 데이터에서 추정된 전체 작업 빈도 분포는 자가 보고된 작업 빈도 분포와 대략 일치합니다. 2025년 2월과 8월 사이의 가장 눈에 띄는 변화는 새로운 기능 구현(14.3% → 36.9%)과 코드 설계 또는 기획(1.0% → 9.9%)에 클로드를 사용하는 비율이 상대적으로 훨씬 많아졌다는 점입니다. 클로드 코드 작업의 상대적 분포에서의 이러한 변화는 클로드가 이러한 더 복잡한 작업에서 더 나아졌음을 시사할 수 있지만, 절대적인 업무량의 증가보다는 팀들이 다양한 워크플로에 클로드 코드를 채택하는 방식의 변화를 반영할 수도 있습니다.
페이퍼컷 고치기 (Fixing papercuts)
설문조사에서 엔지니어들이 이제 삶의 질을 높이는 작은 개선에 더 많은 시간을 쓴다는 것을 발견했습니다. 이와 일맥상통하게 현재 클로드 코드 작업의 8.6%는 “페이퍼컷 수정”으로 분류됩니다. 여기에는 성능 시각화 도구 생성이나 유지보수성을 위한 코드 리팩터링 같은 큰 작업뿐만 아니라, 터미널 단축키 생성 같은 작은 작업도 포함됩니다. 이는 엔지니어들의 보고된 생산성 향상(이전에 방치된 삶의 질 개선을 다루면 시간이 지남에 따라 더 효율적이 됨)에 기여하고 잠재적으로 일상 업무의 마찰과 좌절을 줄일 수 있습니다.
팀별 작업 다양성
현재 팀별로 작업이 어떻게 다른지 연구하기 위해, 우리는 각 8월 기록을 하나의 주요 코딩 작업으로 할당하는 분류 접근 방식을 정교화하고 데이터를 내부 팀별로 나누었습니다(Y축). 누적 막대그래프는 각 팀의 코딩 작업 내역을 보여줍니다.
“All Teams” 막대는 전체 분포를 보여주며, 가장 흔한 작업은 새로운 기능 구축, 디버깅, 코드 이해입니다. 이는 팀별 비교를 위한 기준점을 제공합니다.
주목할 만한 팀별 패턴:
- 사전 훈련(Pre-training) 팀 (클로드 훈련을 돕는 팀)은 새로운 기능 구축(54.6%)에 클로드 코드를 자주 사용하며, 그중 많은 부분은 추가적인 실험 실행입니다.
- 정렬 및 안전(Alignment & Safety) 팀과 사후 훈련(Post-training) 팀은 클로드 코드로 가장 많은 프론트엔드 개발(7.5% 및 7.4%)을 수행하며, 종종 데이터 시각화를 위해 사용합니다.
- 보안(Security) 팀은 코드 이해(48.9%)에 클로드 코드를 자주 사용하며, 특히 코드베이스의 다른 부분들이 보안에 미치는 영향을 분석하고 이해하는 데 사용합니다.
- 비기술(Non-technical) 직원들은 종종 네트워크 문제나 Git 운영 문제 해결 같은 디버깅(51.5%)과 데이터 사이언스(12.7%)에 클로드 코드를 사용합니다. 클로드는 기술적 지식의 격차를 메우는 데 가치가 있어 보입니다.
이러한 팀별 패턴 중 다수는 설문조사와 인터뷰에서 관찰된 것과 같은 능력 확장을 보여줍니다. 즉, 팀원들이 시간이나 기술 부족으로 인해 그렇지 않았으면 하지 못했을 새로운 종류의 업무를 가능하게 하는 것입니다. 예를 들어 사전 훈련 팀은 수많은 추가 실험을 실행했고, 비기술 직원들은 코드 오류를 수정할 수 있었습니다. 또한 데이터에 따르면 팀들이 핵심 업무에 클로드를 사용하기도 하지만(예: 인프라 팀은 인프라 및 데브옵스 작업에 클로드 코드를 가장 일반적으로 사용), 클로드는 종종 그들의 핵심 업무를 증강(augment)하기도 합니다(예: 연구원들이 데이터를 더 잘 시각화하기 위해 프론트엔드 개발에 클로드를 사용). 이는 클로드가 모든 사람이 자신의 업무에서 더 ‘풀스택’이 되도록 돕고 있음을 시사합니다.
앞으로의 전망
앤트로픽 직원들은 지난 1년 동안 클로드 사용을 대폭 늘려, 기존 업무를 가속화할 뿐만 아니라 새로운 코드베이스를 배우고, 노가다를 줄이며, 새로운 영역으로 확장하고, 이전에 방치했던 개선 사항들을 해결했습니다. 클로드가 더 자율적이고 유능해짐에 따라 엔지니어들은 AI 위임을 사용하는 새로운 방법을 발견하는 동시에 미래에 어떤 기술이 필요할지 파악해 나가고 있습니다. 이러한 변화는 명확한 생산성 및 학습 혜택과 함께, 소프트웨어 엔지니어링 업무의 장기적 궤적에 대한 진정한 불확실성을 가져옵니다. AI는 과거의 소프트웨어 엔지니어링 전환(저수준 언어에서 고수준 언어로, 또는 여러 엔지니어가 제안했듯 개별 기여자에서 관리자로)과 닮아 있을까요? 아니면 그보다 더 나아갈까요?
아직은 초기 단계입니다. 앤로픽 내부에는 많은 얼리 어답터(early adopters)들이 있고, 환경은 급변하고 있으며, 우리의 발견은 지금 당장 다른 조직이나 상황에 일반화되지 않을 가능성이 높습니다(부록의 한계점 참조). 이 연구는 그 불확실성을 반영합니다. 발견된 내용들은 미묘하고 복합적이며, 단일한 합의나 명확한 지침이 드러나지 않습니다. 하지만 이는 우리가 이러한 변화를 어떻게 사려 깊고 효과적으로 헤쳐 나갈 수 있을지에 대한 질문을 제기합니다.
이 초기 연구에 이어 우리는 몇 가지 조치를 취하고 있습니다. 앤트로픽 엔지니어, 연구원, 리더십과 대화하며 제기된 기회와 과제를 다루고 있습니다. 여기에는 팀을 어떻게 구성하고 협업할지, 전문성 개발을 어떻게 지원할지, 또는 AI 증강 업무를 위한 모범 사례(예: 우리의 AI 유창성 프레임워크에 기반한)를 어떻게 확립할지 검토하는 것이 포함됩니다. 또한 이 연구를 엔지니어 너머로 확장하여 AI 변화가 조직 전체의 역할에 어떤 영향을 미치는지 이해하고, CodePath와 같은 외부 조직이 AI 지원 미래를 위해 컴퓨터 과학 커리큘럼을 조정하는 것을 지원하고 있습니다. 앞을 내다보며, 우리는 AI 역량이 발전함에 따라 점점 더 관련성이 높아질 구조적 접근 방식(예: 조직 내 역할 진화나 재교육을 위한 새로운 경로)도 고려하고 있습니다.
생각이 더 무르익으면 2026년에 더 구체적인 계획을 공유할 수 있기를 기대합니다. 앤트로픽은 책임감 있는 직장 내 전환을 위한 실험실입니다. 우리는 AI가 업무를 어떻게 변화시키는지 연구하는 데 그치지 않고, 우리 자신부터 시작하여 그 변화를 사려 깊게 헤쳐 나가는 방법을 실험하고 싶습니다.
리포트의 중간에 어떤 엔지니어의 인터뷰에 ‘네비게이션이 처음 나왔을 땐 믿지 않았겠지만 지금은 아는 길도 네비게이션이 보내는대로만 간다’라는 말이 있는데요, 궁극적으로는 이것이 AI와 함께 일하는 우리의 미래겠네요. – eddie
- 원문 : How AI is transforming work at Anthropic, 2025.12.03
- 번역 : Gemini 3 Pro / 편집 : 에디
같이 읽기
이바닥늬우스 