Anthropic에서 AI가 업무를 어떻게 변화시키고 있는가

AI는 우리가 일하는 방식을 어떻게 바꾸고 있는가? AI의 경제적 영향에 관한 Anthropic의 이전 연구는 노동시장 전체를 살피며 다양한 직무를 포괄했다. 그러나 AI 기술의 가장 이른 수용자들 가운데 일부, 곧 Anthropic 내부를 더 자세히 들여다본다면 어떨까?

시선을 내부로 돌려 보면, Anthropic은 2025년 8월 자사 엔지니어와 연구원 132명을 대상으로 설문을 실시하고, 53건의 심층 정성 인터뷰를 진행했으며, 내부 Claude Code 사용 데이터를 분석해 AI 사용이 Anthropic 내부에서 무엇을 어떻게 바꾸고 있는지 살폈다. 그 결과, AI 사용은 소프트웨어 개발자의 일의 성격을 급진적으로 바꾸고 있으며, 그 변화는 기대와 우려를 동시에 낳고 있었다.

이번 연구는 중대한 전환을 겪는 직장을 보여준다. 엔지니어들은 훨씬 더 많은 일을 해내고 있고, 더 "풀스택(full-stack)"화되고 있으며, 자신의 본래 전문성을 넘어서는 과업에서도 성과를 내고 있다. 또한 학습과 반복(iteration)의 속도를 높이고, 이전에는 방치되던 과업까지 수행하고 있다. 그러나 이러한 범위의 확장은 그에 따른 대가를 둘러싼 질문도 낳는다. 일부는 이것이 더 깊은 기술적 역량을 잃게 만들거나 Claude의 출력을 효과적으로 감독할 능력을 약화시킬 수 있다고 우려하는 반면, 다른 이들은 더 넓고 더 높은 수준에서 사고할 기회로 받아들인다. 더 많은 AI 협업이 동료와의 협업을 줄였다고 느끼는 사람도 있었고, 언젠가는 자신이 하는 일을 스스로 자동화하게 되는 것 아니냐고 생각하는 사람도 있었다.

Anthropic은 AI를 만드는 회사 안에서 AI의 영향을 연구한다는 것이 특권적인 위치를 반영한다는 점을 잘 알고 있다. 자사 엔지니어들은 최첨단 도구를 누구보다 먼저 접하고, 비교적 안정적인 분야에서 일하며, 다른 산업에 영향을 미치는 AI 전환 그 자체를 만들어내는 당사자이기도 하다. 그럼에도 Anthropic은 이 결과를 연구하고 공개하는 일이 전체적으로 보아 유익하다고 판단했다. Anthropic 내부 엔지니어들에게서 벌어지는 일이 더 넓은 사회적 전환의 전조가 될 수 있기 때문이다. 이 결과는 여러 부문에서 조기에 주목할 필요가 있을지 모르는 몇 가지 과제와 고려사항을 시사한다(다만 단서와 한계는 부록의 한계 절을 참조하기 바란다). 이 데이터를 수집하던 시점에 Claude Sonnet 4와 Claude Opus 4는 가장 뛰어난 모델이었고, 이후에도 성능은 계속 발전해 왔다.

더 유능한 AI는 생산성 향상을 가져오지만, 동시에 기술 전문성을 어떻게 유지할 것인지, 의미 있는 협업을 어떻게 보존할 것인지, 그리고 AI가 증강된 일터에서 학습, 멘토링, 경력 개발에 대한 새로운 접근이 필요할 수 있는 불확실한 미래에 어떻게 대비할 것인지라는 질문도 제기한다. Anthropic은 아래 "앞으로를 바라보며" 절에서, 이러한 질문을 내부적으로 탐색하기 위해 현재 취하고 있는 몇 가지 초기 조치를 논의한다. 또한 Anthropic은 최근 블로그 글에서 AI 관련 경제 정책 아이디어도 검토했다.

핵심 발견

이 절에서는 설문, 인터뷰, Claude Code 데이터에서 얻은 결과를 간략히 요약한다. 자세한 발견, 방법론, 주의사항은 아래 후속 절들에서 제시한다.

설문 데이터

Anthropic의 엔지니어와 연구원들은 Claude를 코드 오류 수정과 코드베이스 학습에 가장 자주 사용한다. 디버깅과 코드 이해가 가장 흔한 사용 방식이었다(그림 1).
Claude 사용량과 생산성 향상이 모두 증가하고 있다고 응답했다. 직원들은 자신의 업무 중 60%에서 Claude를 사용하며, 생산성이 50% 향상됐다고 자가 보고했다. 이는 지난해 같은 시점 대비 2배에서 3배 수준의 증가다. 이 생산성 증가는 과업 범주별 투입 시간이 약간 줄어드는 형태이기도 하지만, 무엇보다 산출량이 크게 늘어나는 형태로 나타났다(그림 2).
Claude의 도움을 받은 업무 가운데 27%는 Claude가 없었다면 애초에 수행되지 않았을 과업이었다. 여기에는 프로젝트 확장, 있으면 좋은 도구(예: 인터랙티브 데이터 대시보드) 제작, 수작업으로는 비용 대비 효율이 맞지 않는 탐색적 작업이 포함됐다.
대부분의 직원은 Claude를 자주 사용하지만, 자신의 업무 중 Claude에 "완전히 위임(fully delegate)"할 수 있는 비중은 0~20%라고 보고했다. Claude는 늘 함께 일하는 협업자이지만, 실제 사용은 대체로 능동적 감독과 검증을 수반하며, 특히 고위험 업무에서는 더욱 그렇다. 즉, 전혀 검증이 필요 없는 상태로 업무를 넘겨주는 경우와는 다르다.

정성 인터뷰

직원들은 AI 위임에 대한 직관을 발전시키고 있다. 엔지니어들은 비교적 쉽게 정확성을 점검할 수 있는 과업, 위험도가 낮은 과업(예: "버려도 되는 디버깅용 또는 연구용 코드"), 혹은 지루한 과업을 Claude에 맡기는 경향이 있었다. 많은 사람은 단순한 과업에서 시작해 더 복잡한 과업으로 위임 범위를 넓혀 가는 신뢰의 진전을 묘사했으며, 현재는 여전히 대부분의 설계나 "감각(taste)"이 필요한 과업은 사람이 맡고 있지만, 모델이 개선되면서 이 경계도 다시 협상되고 있다고 말했다.
기술 역량은 더 넓은 영역으로 확장되지만, 일부는 실제 연습 기회를 덜 얻고 있다. Claude는 사람들이 더 많은 영역으로 자신의 역량을 확장하게 해준다. 예를 들어 한 사람은 "예전에는 손대기 무서웠을" 프론트엔드나 트랜잭션 데이터베이스 같은 분야에서도 이제 상당히 유능하게 일할 수 있다고 했다. 동시에 일부 직원은 역설적으로, 코드를 작성하고 비평하는 데 필요한 더 깊은 역량이 쇠퇴할 수 있다는 점을 우려했다. "산출물을 만드는 일이 너무 쉽고 빨라지면, 실제로 무언가를 배우기 위해 시간을 들이기가 점점 더 어려워진다"는 것이다.
코딩이라는 작업 자체와의 관계가 바뀌고 있다. 어떤 엔지니어는 AI 지원을 받아들이고 결과에 초점을 맞춘다. 한 사람은 "나는 코드를 쓰는 일을 즐긴다고 생각했는데, 사실은 코드를 씀으로써 얻는 결과를 즐긴다는 걸 알게 됐다"고 말했다. 반면 "코드 쓰기에서 그리운 부분이 분명히 있다"고 말한 사람도 있었다.
직장 내 사회적 역학이 변하고 있을 수 있다. 이제 Claude는 예전 같으면 동료에게 했을 질문의 첫 번째 목적지가 되었다. 그 결과 멘토링과 협업의 기회가 줄었다고 보고한 사람들도 있었다. "나는 사람들과 일하는 걸 좋아하는데, 이제 그들이 덜 '필요해진' 것이 슬프다... 예전보다 주니어들이 질문하러 덜 온다"는 반응도 있었다.
경력의 진화와 불확실성이 커지고 있다. 엔지니어들은 AI 시스템을 관리하는 더 상위 수준의 업무로 이동하고 있다고 보고했으며, 상당한 생산성 향상도 경험하고 있었다. 그러나 이 변화는 동시에 소프트웨어 엔지니어링이라는 직업의 장기적 궤적에 대한 질문도 불러온다. 어떤 사람은 "단기적으로는 낙관적이지만, 장기적으로는 AI가 결국 모든 일을 하고 나와 많은 사람을 무관하게 만들 것 같다"고 말했고, 다른 사람은 몇 년 뒤 자신의 역할이 어떤 모습일지 "말하기 어렵다"고 했다.

Claude Code 사용 추세

Claude는 점점 더 복잡한 과업을 더 자율적으로 처리하고 있다. 6개월 전만 해도 Claude Code는 인간 입력이 필요해지기 전 약 10개의 행동을 스스로 수행했다. 지금은 대체로 약 20개 정도를 처리하며, 더 복잡한 워크플로를 완수하는 데 인간의 개입이 덜 필요하다(그림 3). 엔지니어들은 코드 설계/계획(사용 비중 1%에서 10%로 증가)이나 신규 기능 구현(14%에서 37%로 증가)처럼 더 복잡한 과업에 Claude를 점점 더 많이 사용하고 있다(그림 4).
Claude는 많은 "자잘한 불편 수정(papercut fixes)"을 처리한다. 현재 Claude Code 과업의 8.6%는 유지보수성을 높이기 위한 리팩터링처럼 보통 후순위로 밀렸을 사소한 문제 해결에 해당한다. 이런 작은 개선들이 누적되면 더 큰 생산성과 효율 향상으로 이어질 수 있다.
모두가 더 "풀스택"해지고 있다. 서로 다른 팀은 Claude를 각기 다른 방식으로 사용하며, 대체로 자신들의 핵심 전문성을 보완하는 방향으로 활용한다. 예를 들어 Security 팀은 낯선 코드를 분석하는 데, Alignment & Safety 팀은 데이터를 시각화하는 프론트엔드 작업에 Claude를 사용한다(그림 5).

설문 데이터

Anthropic은 조직 전반의 엔지니어와 연구원 132명을 대상으로 Claude 사용 실태를 설문해, 이들이 일상적으로 Claude를 정확히 어떻게 활용하고 있는지 더 잘 이해하고자 했다. 설문은 내부 커뮤니케이션 채널과, 연구 기능과 제품 기능을 모두 포함하는 다양한 팀의 직원들에게 직접 연락하는 방식으로 배포되었다. 방법론적 세부사항은 부록의 한계 절에 더 자세히 설명되어 있으며, 다른 연구자들이 접근법을 평가하고 각자 연구에 맞게 활용할 수 있도록 설문 문항도 함께 공개한다.

사람들이 Claude를 어떤 코딩 과업에 사용하고 있는가?

설문에서는 엔지니어와 연구원들에게 Claude를 다양한 종류의 코딩 과업에 얼마나 자주 사용하는지 평가해 달라고 요청했다. 여기에는 "디버깅"(Claude를 이용해 코드 오류를 수정하는 일), "코드 이해"(기존 코드를 Claude가 설명해 사용자가 코드베이스를 이해하도록 돕는 일), "리팩터링"(Claude가 기존 코드를 재구성하도록 돕는 일), "데이터 사이언스"(예: Claude가 데이터셋을 분석하고 막대그래프를 그리게 하는 일) 등이 포함됐다.

가장 흔한 일상 과업은 다음과 같았다. 직원들의 55%는 디버깅에 Claude를 매일 사용했고, 42%는 코드 이해에, 37%는 신규 기능 구현에 Claude를 매일 사용했다. 반대로 덜 빈번한 과업은 고수준 설계/계획과 데이터 사이언스, 프론트엔드 개발이었다. 이는 각각 사람들이 아직 인간이 맡겨 두는 경향이 있는 과업이거나, 전체적으로 발생 빈도가 낮은 과업이기 때문으로 보인다. 이러한 양상은 "Claude Code 사용 추세" 절에서 보고하는 Claude Code 사용 데이터의 분포와도 대체로 일치한다.

그림 1: 다양한 코딩 과업에 대한 일일 사용자 비율

그림 1: 다양한 코딩 과업(y축)에 대한 일일 사용자 비율(x축).

사용량과 생산성

직원들은 12개월 전에는 일상 업무의 28%에서 Claude를 사용했고, 그로 인한 생산성 향상은 +20% 수준이었다고 자가 보고했다. 반면 현재는 업무의 59%에서 Claude를 사용하며 평균 +50%의 생산성 향상을 얻고 있다고 응답했다. 이는 Anthropic이 Engineering 조직 전반에 Claude Code를 도입한 이후, 엔지니어 1인당 1일 기준 병합된 pull request 수가 67% 증가한 관측과도 대체로 부합한다. 연간 비교 폭은 상당히 크며, 이는 1년 만에 두 지표가 모두 2배 이상 증가했음을 시사한다. 사용량과 생산성은 강한 상관관계를 보였고, 분포의 극단에서는 응답자의 14%가 Claude 사용으로 생산성이 100% 이상 증가했다고 답했다. 이들은 Anthropic 내부의 "파워 유저(power users)"라고 할 수 있다.

다만 이 결과와 아래의 다른 자가 보고형 생산성 결과들을 해석할 때는 주의가 필요하다. 생산성은 본질적으로 정밀하게 측정하기 어려운 개념이다(더 자세한 한계는 부록 참조). AI 연구 비영리기관인 METR의 최근 연구는, 익숙한 코드베이스에서 AI와 함께 일한 숙련 개발자들이 AI가 주는 생산성 향상을 과대평가했다고 보고했다. 다만 METR이 예상보다 낮은 생산성을 설명하는 요인으로 지목한 항목들, 예컨대 대규모 복잡 환경에서 AI가 더 잘 작동하지 못한다는 점이나 암묵지/맥락 의존성이 큰 과업이라는 점은, Anthropic 직원들이 Claude에 위임하지 않는 과업 유형(AI 위임 접근 방식 절 참조)과 밀접하게 대응한다. Anthropic의 생산성 향상은 과업 전반에 걸친 자가 보고 수치이므로, 직원들이 전략적 AI 위임 기술을 발전시킨 결과를 반영하고 있을 수도 있다. 이는 METR 연구에서 포착되지 않은 요소다.

흥미로운 생산성 패턴은, 현재 Claude를 사용하고 있는 과업 범주별로 Claude가 해당 범주의 총 소요 시간과 산출량에 어떤 영향을 미치는지 묻는 과정에서 나타났다. 거의 모든 과업 범주에서 소요 시간은 순감소했고, 산출량은 그보다 더 크게 순증가했다.

그림 2: 과업별 시간 투입과 산출량 변화

그림 2: 과업(y축)별 시간 투입(좌측 패널)과 산출량(우측 패널)에 대한 영향. 각 그래프의 x축은 Claude를 사용하지 않을 때와 비교해, Claude 지원 과업 범주에서 시간 투입 또는 산출량이 자가 보고 기준으로 감소(음수), 증가(양수), 혹은 변화 없음(수직 점선)에 해당함을 나타낸다. 오차막대는 95% 신뢰구간을 뜻하며, 원의 면적은 각 평정 지점의 응답 수에 비례한다. 각 과업 범주에서 Claude를 사용한다고 보고한 응답자만 포함했다.

그러나 원자료를 더 자세히 들여다보면, 시간 절감 응답은 양 극단에 몰려 있었다. 즉, 어떤 사람들은 Claude의 도움을 받는 과업에 오히려 훨씬 더 많은 시간을 쓰고 있었다.

왜 그럴까? 사람들은 대체로 Claude가 작성한 코드를 더 많이 디버깅하고 정리해야 했으며(예: "내가 바이브 코딩(vibe coding) 하다가 막다른 골목에 몰리게 될 때"), 자신이 직접 작성하지 않은 Claude의 코드를 이해하는 데 더 큰 인지적 부담을 져야 했다고 설명했다. 또 다른 사람들은 시간을 더 쓴다는 것을 부정적으로만 보지 않았다. 어떤 이는 Claude를 쓰면 "예전 같으면 바로 포기했을 과업에서도 버틸 수 있게 된다"고 했고, 다른 이는 새로운 코드베이스에서 더 철저한 테스트와 더 많은 학습·탐색을 하게 해 준다고 말했다. 전반적으로 보면, 시간을 절감하는 엔지니어들은 Claude에 빠르게 검증 가능한 과업을 잘 범위 설정해 맡기는 반면, 더 많은 시간을 쓰는 이들은 AI가 생성한 코드를 디버깅하거나 Claude가 더 많은 지도가 필요한 영역에서 작업하는 경우일 가능성이 있다.

또한 보고된 시간 절감이 어디에 재투자되고 있는지도 명확하지 않다. 추가적인 엔지니어링 업무인지, 비엔지니어링 업무인지, Claude와 더 많이 상호작용하거나 그 출력을 검토하는 데 쓰이는 것인지, 아니면 업무 외 활동으로 향하는 것인지 데이터만으로는 알 수 없다. Anthropic의 과업 분류 체계는 엔지니어들이 시간을 배분하는 모든 방식을 포착하지 못한다. 더불어 시간 절감은 자가 보고에서 비롯되는 지각 편향을 반영할 수도 있다. 이러한 효과를 분리해 이해하려면 추가 연구가 필요하다.

반면 산출량 증가는 더 직접적이고 규모도 컸다. 거의 모든 과업 범주에서 순증가 폭이 더 크게 나타났다. 이는 사람들이 개별 과업이 아니라 "디버깅 전반" 같은 과업 범주에 대해 응답하고 있다는 점을 고려하면 이해하기 쉽다. 즉, 디버깅이라는 범주에 쓰는 시간은 조금 줄어들어도, 전체 디버깅 산출량은 훨씬 더 많아질 수 있다. 생산성은 직접 측정하기 매우 어렵지만, 이 자가 보고 데이터는 Anthropic에서 AI가 주로 더 큰 산출량을 통해 생산성을 높이고 있음을 시사한다.

Claude가 가능하게 하는 새로운 일

Anthropic이 궁금했던 한 가지는 이것이었다. Claude는 질적으로 새로운 종류의 일을 가능하게 하고 있는가, 아니면 Claude의 도움을 받은 일도 결국은 직원들이 언젠가 하게 됐을 일이지만 단지 더 느렸을 뿐인가?

직원들은 자신이 Claude의 도움을 받은 업무 가운데 27%는 Claude가 없었다면 수행되지 않았을 것이라고 추정했다. 엔지니어들은 프로젝트 확장, 있으면 좋은 기능(예: 인터랙티브 데이터 대시보드), 문서화와 테스트처럼 유용하지만 번거로운 작업, 수작업으로는 비용 효율이 맞지 않는 탐색적 업무에 AI를 활용한다고 말했다. 한 사람은 이전에는 삶의 질을 떨어뜨리던 "자잘한 불편"을 이제 더 많이 해결할 수 있게 됐다고 설명했다. 예를 들어 구조가 좋지 않은 코드를 리팩터링하거나, "다른 작업을 더 빨리 해내게 도와주는 작은 도구"를 만들 수 있게 되었다는 것이다. Anthropic은 이 점을 사용 데이터 분석에서도 확인하려 했고, 분석 결과 Claude Code 과업의 8.6%가 이러한 "자잘한 불편 수정"에 해당한다는 사실을 확인했다.

또 다른 연구원은 서로 다른 접근을 동시에 탐색하도록 Claude를 여러 버전으로 병렬 실행한다고 설명했다.

사람들은 초고성능 모델을 보통 더 빠른 자동차 한 대 같은 단일 인스턴스로 상상하는 경향이 있다. 하지만 말이 백만 마리 있다면... 아주 많은 아이디어를 시험해볼 수 있다... 그런 폭넓은 탐색 여지가 생기면 더 신나고 더 창의적이게 된다.

이후 절들에서 보듯, 이러한 새로운 일은 엔지니어들이 자신의 핵심 전문성 바깥의 과업을 다루는 경우와 자주 연결된다.

Claude에 얼마만큼의 일을 완전히 위임할 수 있는가?

엔지니어들은 Claude를 자주 사용하지만, 절반이 넘는 응답자는 자신의 업무 가운데 0~20%만 Claude에 "완전히 위임"할 수 있다고 말했다. 여기서 "완전히 위임"의 의미는 응답자마다 달랐을 수 있다. 전혀 검증이 필요 없는 과업부터, 가벼운 감독만 있으면 충분할 정도로 신뢰할 수 있는 과업까지 해석 폭이 있다. 다만 그 이유를 설명할 때 엔지니어들은 Claude와 능동적이고 반복적으로 함께 일하며, 그 출력을 검증한다고 말했다. 특히 복잡한 과업이나 코드 품질 기준이 중요한 고위험 영역에서는 더욱 그러했다. 이는 엔지니어들이 Claude에 일을 검증 없이 넘겨버리기보다, 그와 밀접하게 협업하며 결과를 점검하는 경향이 있고, "완전 위임"의 기준도 매우 높게 두고 있음을 시사한다.

정성 인터뷰

이 설문 결과는 생산성 향상과 업무 방식 변화가 상당하다는 점을 보여주지만, 동시에 엔지니어들이 이러한 변화를 일상에서 실제로 어떻게 경험하고 있는지라는 질문을 낳는다. Anthropic은 이 수치들 이면에 있는 인간적 차원을 이해하기 위해, 설문에 응답한 엔지니어와 연구원 가운데 53명을 심층 인터뷰하여 이들이 직장 내 변화에 대해 어떻게 생각하고 느끼는지 더 깊이 들여다보았다.

AI 위임 접근 방식

엔지니어와 연구원들은 워크플로 안에서 Claude를 생산적으로 활용하기 위한 다양한 전략을 발전시키고 있었다. 사람들은 대체로 다음과 같은 과업을 Claude에 위임한다고 말했다.

사용자의 맥락 바깥에 있으면서 복잡도가 낮은 과업

나는 내가 맥락을 거의 갖고 있지 않지만, 전체 복잡도는 낮다고 생각되는 일에 Claude를 쓴다.

내가 겪는 인프라 문제의 대부분은 어렵지 않고 Claude가 처리할 수 있다... 나는 Git이나 Linux를 아주 잘 아는 편이 아니다... Claude는 이런 부분에서 내 경험 부족을 잘 메워준다.

검증이 쉬운 과업

검증에 드는 노력이 생성에 드는 노력에 비해 크지 않은 모든 일에는 정말 놀라울 정도로 잘 맞는다.

명확하게 정의되어 있거나 독립적인 과업

프로젝트의 한 하위 구성요소가 나머지와 충분히 분리돼 있으면, Claude에게 먼저 한번 시도해 보게 한다.

코드 품질이 핵심적이지 않은 과업

버려도 되는 디버깅용 코드나 연구용 코드라면 바로 Claude로 간다. 하지만 개념적으로 어렵거나, 아주 특수한 형태의 디버그 인젝션이 필요하거나, 설계 문제라면 내가 직접 한다.

반복적이거나 지루한 과업

내가 그 과업을 하는 데 더 신이 날수록 Claude를 쓰지 않을 가능성이 높다. 반대로 저항감이 많이 느껴질 때는... 그 과업에 대해 Claude와 대화를 시작하는 편이 더 쉽다고 느낀다.

Anthropic의 설문에서, 사람들은 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를 자신의 전문성 안쪽에서 쓸지 바깥에서 쓸지를 두고 엔지니어들의 견해는 갈렸다. 어떤 사람은 구현 시간을 줄이기 위해 "주변부" 영역에 Claude를 사용했고, 다른 사람들은 자신이 출력을 검증할 수 있는 익숙한 영역을 선호했다. 한 보안 엔지니어는 Claude가 "위험한 방식으로 정말 똑똑한, 아주 유능한 주니어 엔지니어가 제안할 법한 종류의" 해결책을 내놓았을 때, 경험이 왜 중요한지를 강조했다. 즉, 판단력과 경험이 있는 사용자만이 그 제안의 문제점을 알아볼 수 있었다는 뜻이다.

다른 엔지니어들은 두 종류의 과업 모두에 Claude를 사용했다. 어떤 사람은 "나는 사실상 어떤 코딩 문제든 Claude에게 먼저 한 번 풀어 보게 한다"는 식으로 실험적으로 사용했고, 어떤 사람은 자신이 해당 과업에 얼마나 익숙한지에 따라 접근법을 바꿨다.

나는 도구를 두 종류 모두에 쓴다. 내 전문성의 핵심에 있는 일에는 가속 장치처럼 쓴다. 그 경우 나는 무엇을 기대해야 하는지 알고 있고, 에이전트를 효과적으로 이끌 수 있다. 동시에 내 전문영역에서 약간 벗어난 일에도 쓰는데, 그 경우에도 대략 무엇을 기대해야 하는지는 알고 있고, Claude는 내 기억이나 특정 정의에 대한 친숙성의 공백을 메워준다.

내가 특히 잘 아는 분야라면 더 단호하게 Claude에게 무엇을 추적해야 하는지 지시한다. 내가 확신이 없을 때는 오히려 Claude에게 전문가 역할을 맡기고, 고려하고 조사해야 할 점들에 대한 선택지와 통찰을 달라고 자주 요청한다.

사람들은 어떤 과업을 스스로 남겨두는가?

사람들은 대체로 고수준 사고나 전략적 사고가 필요한 과업, 혹은 조직 맥락이나 "감각(taste)"을 요구하는 설계 결정에는 Claude를 쓰지 않는다고 일관되게 말했다. 한 엔지니어는 "나는 보통 고수준 사고와 설계는 내가 맡아 두고, 신규 기능 개발부터 디버깅까지 위임할 수 있는 것은 다 위임한다"고 설명했다. 이는 설계와 계획 과업에서 생산성 향상이 가장 낮게 나타난 설문 결과(그림 2)와도 부합한다. 다만 많은 사람은 이러한 위임 경계를 "움직이는 표적"이라고 묘사했다. 모델이 개선될수록 그 경계는 계속 다시 협상되고 있다는 뜻이다. 실제로 아래 Claude Code 사용 데이터는 6개월 전보다 지금 설계/계획 과업에 Claude가 더 많이 쓰이고 있음을 보여준다.

기술 역량의 변화

새로운 역량...

Claude의 도움을 받은 업무 가운데 27%는 Claude가 없었다면 수행되지 않았을 것이라는 설문 결과는, 엔지니어들이 AI를 활용해 자신의 핵심 전문성 바깥의 일을 하고 있다는 더 넓은 패턴을 반영한다. 많은 직원은 이전까지는 자기 전문 바깥이라고 여겼던 일을 해내고 있었다. 백엔드 엔지니어가 UI를 만들고, 연구자가 시각화를 구현하는 식이다. 한 백엔드 엔지니어는 Claude와 반복적으로 상호작용하며 복잡한 UI를 만든 경험을 이렇게 설명했다. "내가 했을 때보다 훨씬 더 잘했다. 나는 아마 절대 못 했을 것이고, 특히 제시간에는 절대 못 했다... [디자이너들이] '잠깐, 이걸 네가 했다고?'라고 했다. 나는 '아니, Claude가 했고 나는 프롬프트만 줬어'라고 말했다."

엔지니어들은 자신이 "더 풀스택화되고 있다... 이전에는 덜 전문적이라서 손대기 무서웠던 프론트엔드나 트랜잭션 데이터베이스, API 코드도 이제는 꽤 능숙하게 다룰 수 있다"고 말했다. 이러한 역량 확장은 피드백 루프를 더 촘촘하게 만들고 학습을 더 빠르게 만든다. 한 엔지니어는, 빌드하고 회의를 잡고 반복하는 데 몇 주가 걸리던 과정이, 동료들이 곁에서 실시간 피드백을 주는 "몇 시간짜리 작업 세션"으로 바뀔 수 있다고 말했다.

전반적으로 사람들은 더 빠른 프로토타이핑, 병렬 작업, 잡무 감소, 그리고 자신이 시도할 수 있는 일의 수준 자체를 높일 수 있게 된 점에 고무되어 있었다. 한 시니어 엔지니어는 "이 도구들은 분명히 주니어 엔지니어들을 더 생산적으로 만들고, 그들이 맡는 프로젝트의 종류에서도 더 대담하게 만든다"고 말했다. 또 어떤 사람들은 Claude 사용으로 인한 낮아진 "활성화 에너지(activation energy)" 덕분에 미루는 습관을 더 쉽게 이길 수 있게 되었고, "문제 해결을 시작하고 싶어지기까지 필요한 에너지가 극적으로 줄어들어서, 훨씬 더 많은 일을 기꺼이 시작하게 됐다"고 말했다.

...직접 손대는 연습은 줄어들고

동시에 일부는 "더 많이 위임할수록 기술이 쇠퇴할 수 있다"는 점과, 수작업 문제 해결 과정에서 자연스럽게 발생하는 부수적 학습을 잃게 된다는 점을 걱정했다.

어려운 문제를 직접 디버깅하러 나가면, 당장 문제를 푸는 데 직접적으로 필요하지 않은 문서와 코드를 읽는 데도 시간을 쓰게 된다. 하지만 그 모든 시간 동안 시스템이 어떻게 작동하는지에 대한 모델을 머릿속에 쌓아 가게 된다. Claude는 바로 문제 지점으로 데려다주기 때문에, 그런 일이 훨씬 줄어든다.

예전에는 도구가 무엇을 할 수 있는지 이해하려고 모든 설정을 직접 탐색했는데, 이제는 새 도구 사용법을 AI에게 물어보게 되면서 내 전문성이 줄어든다. 팀원들과 대화할 때도 예전에는 바로 떠올릴 수 있던 것을, 이제는 AI에게 다시 물어봐야 한다.

Claude를 쓰면, 쉬운 예제를 직접 풀면서 과업 수행 방법을 배우고, 나중에 더 어려운 사례를 해결하기 위해 씨름하는 과정을 건너뛰게 될 수 있다.

한 시니어 엔지니어는 자신이 더 주니어였다면 이런 기술 쇠퇴를 더 심각하게 걱정했을 것이라고 말했다.

나는 주로 답이 어떤 모습이어야 하는지 내가 알고 있는 경우에 AI를 쓴다. 그 능력은 내가 소프트웨어 엔지니어링을 '어렵게' 배워 오면서 얻은 것이다... 하지만 내가 커리어 초반이었다면, 모델 출력을 맹목적으로 받아들이지 않고 내 능력을 계속 키우려면 상당한 의식적 노력이 필요하다고 느꼈을 것이다.

코딩 기술의 쇠퇴가 우려되는 이유 가운데 하나는 "감독의 역설(paradox of supervision)" 때문이다. 앞서 말했듯 Claude를 효과적으로 쓰려면 감독이 필요하고, Claude를 감독하려면 바로 AI 과용으로 인해 쇠퇴할 수 있는 그 코딩 기술이 필요하다. 한 사람은 이렇게 말했다.

솔직히 말하면, 나는 특정한 기술 자체보다도 감독과 오버사이트 문제를 훨씬 더 걱정한다... 내 기술이 쇠퇴하거나 충분히 발달하지 못하는 것이 문제인 이유는, 내가 중요하게 여기는 과업에 AI를 안전하게 사용할 수 있는 능력과 직접 연결되기 때문이지, 그 과업을 완전히 독립적으로 수행하는 능력 때문만은 아니다.

이런 문제를 막기 위해 일부 엔지니어는 의도적으로 AI 없이 연습한다. "가끔은 Claude가 문제를 완벽하게 풀 거라는 걸 알아도 일부러 묻지 않는다. 그래야 내가 무뎌지지 않는다."

여전히 직접 코딩하는 기술이 필요할까?

소프트웨어 엔지니어링은 과거에도 그랬듯 더 높은 수준의 추상화로 이동하고 있는 것일 수 있다. 초기 프로그래머들은 훨씬 더 기계에 가까운 위치에서 일했다. 메모리를 직접 관리하고, 어셈블리 언어로 코드를 쓰고, 심지어는 물리적 스위치를 토글해 명령을 입력하던 시절도 있었다. 시간이 지나면서, 복잡한 저수준 연산을 자동으로 처리해 주는 더 고수준이고 인간 친화적인 언어가 등장했다. 특히 "바이브 코딩(vibe coding)"의 부상과 함께, 이제는 영어가 하나의 프로그래밍 언어가 되어 가고 있는지도 모른다. Anthropic 직원 가운데 한 명은 예비 엔지니어들에게 "AI가 코드를 쓰게 하는 데 능숙해지고, 더 높은 수준의 개념과 패턴을 배우는 데 집중하라"고 조언했다.

몇몇 직원은 이러한 전환이 자신을 더 높은 수준에서 사고하게 만든다고 말했다. 즉, 코드 자체보다 "최종 산출물과 최종 사용자"를 생각하게 된다는 것이다. 한 사람은 현재의 변화를, 예전 컴퓨터과학 교육에서 연결 리스트 같은 기초 구조를 반드시 배워야 했던 것에 비유했다. 오늘날의 고수준 언어는 그러한 구조를 자동으로 처리해 준다. 그는 "그걸 아는 것이 매우 다행이라고 생각한다... 하지만 그런 저수준 작업 자체가 정서적으로 특별히 중요하지는 않다. 나는 오히려 코드가 내가 무엇을 하게 해 주는지를 더 중요하게 생각한다"고 말했다. 다른 엔지니어도 비슷한 비교를 했지만, 추상화에는 비용이 따른다고 지적했다. 고수준 언어로 이동하면서, 대부분의 엔지니어는 메모리 처리에 대한 깊은 이해를 잃었다는 것이다.

어떤 영역에서 기술을 계속 발전시키는 일은 Claude를 더 잘 감독하게 하고, 더 효율적으로 일하게도 해 준다. 한 사람은 "내가 익숙한 것이라면, 오히려 내가 직접 하는 게 더 빠를 때가 많다는 걸 느낀다"고 말했다. 그러나 이 점이 중요한지를 두고 엔지니어들 사이의 견해는 갈렸다. 어떤 사람들은 비교적 담담했다.

나는 기술이 닳아 없어지는 것을 크게 걱정하지 않는다. AI는 여전히 내가 문제를 신중하게 생각하게 만들고, 새로운 접근법을 배우도록 돕는다. 오히려 아이디어를 더 빨리 탐색하고 시험할 수 있게 되면서 어떤 영역에서는 학습이 가속되었다.

다른 한 사람은 더 실용적으로 말했다. "내 소프트웨어 엔지니어로서의 기술이 분명히 쇠퇴하고 있는 건 맞다... 하지만 정말 필요해지면 그 기술들은 다시 돌아올 수 있을 것이고, 지금은 더 이상 필요하지 않다!" 또 다른 사람은 자신이 잃어버린 것은 차트를 만드는 일 같은 덜 중요한 기술뿐이며, "정말 중요한 종류의 코드는 여전히 아주 잘 쓸 수 있다"고 말했다.

아마 가장 흥미로운 지적은, 한 엔지니어가 전제 자체에 문제를 제기했다는 점일 것이다. "기술이 녹슨다는 프레이밍은, 언젠가 코딩이 Claude 3.5 이전 방식으로 되돌아갈 것이라는 가정에 기대고 있다. 그런데 나는 그렇게 되지 않을 것이라고 본다."

소프트웨어 엔지니어링의 장인성과 의미

엔지니어들은 직접 손으로 코딩하는 일을 그리워하는지에 대해 크게 갈렸다. 어떤 사람들은 진정한 상실감을 느꼈다. "내게는 한 시대의 끝이다. 나는 25년 동안 프로그래밍을 해 왔고, 그 기술에 능숙하다는 감각은 내 직업적 만족의 핵심적인 부분이다." 다른 사람들은 변화한 일의 성격을 즐기지 못할까 봐 걱정했다. "하루 종일 Claude에게 프롬프트를 던지는 일은 별로 재미있지도, 충족감이 있지도 않다. 음악을 틀어 놓고 몰입해서 직접 뭔가를 구현하는 편이 훨씬 더 재미있고 충만하다."

어떤 사람들은 그 대가를 직접 언급하면서도 받아들였다. "코드를 쓰는 일에서 분명히 그리운 부분들이 있다. 리팩터링할 때 일종의 몰입 상태에 들어가는 것 같은 느낌 말이다. 하지만 지금은 전반적으로 생산성이 훨씬 높아졌기 때문에, 나는 기꺼이 그걸 포기할 수 있다."

한 사람은 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 가드레일, 더 풍부한 내장형 교육 자원, 실수에서 자연스럽게 배우는 과정이 결합되면 시간이 지나며 이 분야도 적응해 갈 것이라고 보았다.

Anthropic은 사람들이 자신의 미래 역할을 어떻게 상상하는지, 적응 전략이 있는지도 물었다. 어떤 사람들은 더 전문화할 계획을 언급했다. "AI의 작업을 의미 있게 검토하는 기술은 더 오래 걸리고, 더 많은 전문화를 요구할 것이다." 다른 사람들은 앞으로 더 인간관계적이고 전략적인 일에 초점을 맞추게 될 것이라고 봤다. "우리는 합의를 찾는 데 더 많은 시간을 쓰고, 구현에는 AI들이 더 많은 시간을 쓰게 될 것이다." 또 한 사람은 Claude를 커리어 개발에 직접 활용하고 있다고 말했다. Claude에게 자신의 업무와 리더십 기술에 대한 피드백을 구하는 것이다. 그는 "무언가를 배우는 속도, 혹은 완전히 배우지 못해도 효과적으로 일할 수 있는 수준 자체가 완전히 바뀌었다. 마치 내 한계치가 완전히 깨져 버린 것 같다"고 말했다.

전반적으로 많은 사람들은 깊은 불확실성을 인정했다. "미래에 어떤 구체적 기술이 유용할지에 대해 나는 거의 자신이 없다." 한 팀 리드는 이렇게 말했다. "아무도 무슨 일이 벌어질지 모른다... 중요한 것은 정말 유연하게 적응하는 것이다."

Claude Code 사용 추세

설문과 인터뷰 데이터는 Claude 사용 증가가 사람들을 더 빠르게 일하게 하고, 새로운 종류의 일까지 맡게 한다는 점을 보여준다. 그러나 동시에 AI 위임과 기술 발달을 둘러싼 긴장도 수반한다. 그럼에도 자가 보고 데이터만으로는 이야기의 일부만 알 수 있다. 이를 보완하기 위해 Anthropic은 실제 Anthropic 팀들의 Claude 사용 데이터도 분석했다. 설문 응답자들이 자신의 Claude 사용의 대부분이 Claude Code라고 답했기 때문에, Anthropic은 프라이버시 보존 분석 도구를 이용해 2025년 2월과 8월의 Claude Code 내부 대화 전사문 20만 건을 분석했다.

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

지난 6개월 동안 Claude Code 사용은 더 어렵고 더 자율적인 코딩 과업 쪽으로 이동해 왔다(그림 3).

직원들은 Claude Code와 함께 점점 더 복잡한 과업을 수행하고 있다. Anthropic은 각 전사문의 과업 복잡도를 1~5 척도로 추정했는데, 1은 "기본 편집", 5는 "인간 전문가가 수주 또는 수개월을 들여야 하는 전문가급 과업"에 해당한다. 평균 과업 복잡도는 3.2에서 3.8로 상승했다. 점수 차이를 예로 들면, 평균 3.2에 해당하는 과업은 "Python 모듈 import 오류 해결"이었고, 평균 3.8에 해당하는 과업은 "캐싱 시스템 구현 및 최적화"였다.
전사문당 Claude Code의 연속 도구 호출 최대 횟수는 116% 증가했다. 도구 호출은 Claude가 파일 편집이나 명령 실행처럼 외부 도구를 이용해 수행하는 행동에 해당한다. 지금의 Claude는 인간 개입 없이 평균 21.2회의 독립적 도구 호출을 연쇄적으로 수행하는데, 이는 6개월 전의 9.8회와 비교해 크게 늘어난 수치다.
인간 발화(turn) 수는 33% 감소했다. 전사문당 평균 인간 발화 수는 6.2에서 4.1로 줄었으며, 이는 6개월 전보다 같은 과업을 달성하는 데 필요한 인간 입력이 적어졌음을 시사한다.

그림 3: 2025년 2월과 8월 사이 Claude Code 사용 변화

그림 3: 2025년 2월과 8월 사이 Claude Code 사용 변화(x축). 평균 과업 복잡도는 시간이 지나며 증가했고(좌측 패널), 전사문당 평균 최대 연속 도구 호출 수는 증가했으며(가운데 패널), 인간 발화 수는 감소했다(우측 패널). 오차막대는 95% 신뢰구간이다. 이 데이터는 사람들이 시간이 갈수록 Claude에 더 많은 자율성을 위임하고 있음을 시사한다.

이 사용 데이터는 설문 결과를 뒷받침한다. 엔지니어들은 점점 더 복잡한 업무를 Claude에 위임하고 있으며, Claude는 점점 더 적은 감독으로 일하고 있다. 이는 관찰된 생산성 향상을 설명하는 요인일 가능성이 높다.

과업 분포

Anthropic은 Claude Code 전사문을 하나 이상의 코딩 과업 유형으로 분류하여, 서로 다른 과업에 대한 사용 방식이 지난 6개월 동안 어떻게 변화했는지를 살폈다.

그림 4: 코딩 과업 분포의 변화

그림 4: 전체 기록 수 대비 비율(x축)로 본 다양한 코딩 과업(y축)의 분포. 6개월 전(분홍색)과 현재(보라색)의 분포를 비교했으며, y축은 2025년 2월의 빈도순으로 정렬되어 있다.

사용 데이터에서 추정한 전체 과업 빈도 분포는 자가 보고된 과업 빈도 분포와 대체로 일치했다. 2025년 2월과 8월 사이 가장 두드러진 변화는, 신규 기능 구현(14.3% → 36.9%)과 코드 설계 또는 계획(1.0% → 9.9%)에 Claude를 사용하는 전사문의 비율이 비례적으로 크게 증가했다는 점이다. 이러한 상대적 과업 분포의 변화는 Claude가 더 복잡한 과업에서 더 나아졌음을 시사할 수 있다. 그러나 이것이 절대적 업무량의 증가를 뜻하는 것은 아니며, 서로 다른 팀이 서로 다른 워크플로에 Claude Code를 채택하는 방식이 변한 결과일 수도 있다(추가 한계는 부록 참조).

자잘한 불편(papercut) 고치기

설문 결과에 따르면 엔지니어들은 이제 삶의 질을 높이는 작은 개선에 더 많은 시간을 쓰고 있었다. 이에 부합하게, 현재 Claude Code 과업의 8.6%는 "자잘한 불편 수정"으로 분류된다. 여기에는 성능 시각화 도구 제작이나 유지보수성을 높이기 위한 리팩터링 같은 비교적 큰 과업도 있고, 터미널 단축키를 만드는 일처럼 더 작은 과업도 있다. 이는 엔지니어들이 보고한 생산성 향상에 기여할 수 있다. 이전에는 방치되던 삶의 질 개선 과업을 해소하면 시간이 흐르며 더 큰 효율 향상으로 이어질 수 있고, 일상 업무에서의 마찰과 좌절도 줄일 수 있기 때문이다.

팀별 과업 차이

현재 과업이 팀별로 어떻게 다른지 살펴보기 위해 Anthropic은 분류 방식을 더 정교하게 다듬어, 8월 전사문 각각에 하나의 주된 코딩 과업을 배정하고 이를 내부 팀(y축)별로 나누어 보았다. 누적 막대그래프는 각 팀의 코딩 과업 구성을 보여준다.

그림 5: 팀별 Claude Code 과업 구성

그림 5: 각 가로 막대는 하나의 팀(y축)을 나타내며, 막대 내부 구간은 그 팀의 Claude Code 사용 가운데 서로 다른 코딩 과업이 차지하는 비율(x축)을 보여준다. 색상은 코딩 과업 유형(범례)을 뜻한다. 맨 위의 "All Teams" 막대는 전체 분포를 나타낸다.

"All Teams" 막대는 전체 분포를 보여주며, 가장 흔한 과업은 신규 기능 구축, 디버깅, 코드 이해였다. 이는 팀별 비교를 위한 기준선을 제공한다.

주목할 만한 팀별 패턴은 다음과 같다.

Pre-training 팀(Claude 훈련을 돕는 팀)은 Claude Code를 신규 기능 구현에 자주 사용하며(54.6%), 그중 상당수는 추가 실험 수행에 해당한다.
Alignment & Safety 팀과 Post-training 팀은 Claude Code로 프론트엔드 개발을 가장 많이 수행하며(각각 7.5%, 7.4%), 주로 데이터 시각화를 만들기 위한 용도다.
Security 팀은 Claude Code를 코드 이해에 자주 사용하며(48.9%), 특히 코드베이스의 서로 다른 부분이 갖는 보안 함의를 분석하고 이해하는 데 활용한다.
비기술직(non-technical) 직원들은 Claude Code를 디버깅에 자주 사용한다(51.5%). 여기에는 네트워크 문제나 Git 작업 문제 해결이 포함되며, 데이터 사이언스 작업(12.7%)에도 많이 사용한다. Claude는 기술적 지식의 공백을 메우는 데 가치가 있어 보인다.

이러한 팀별 패턴 가운데 다수는, 설문과 인터뷰에서 보았던 역량 확장과 같은 현상을 보여준다. 곧, 그 팀의 사람들이 시간이 없거나 역량이 부족해서 원래는 하지 못했을 새로운 종류의 일을 가능하게 한다는 것이다. 예컨대 Pre-training 팀은 추가 실험을 대거 수행했고, 비기술직 직원들은 코드 오류를 직접 고칠 수 있었다. 또 데이터는 팀들이 Claude를 핵심 과업에도 사용하고 있음을 시사한다. 예를 들어 Infrastructure 팀은 Claude Code를 인프라 및 DevOps 작업에 가장 자주 사용한다. 그러나 동시에 Claude는 핵심 과업을 보완하기도 한다. 예를 들어 연구자들은 자신의 데이터를 더 잘 시각화하기 위해 프론트엔드 개발에 Claude를 사용한다. 이는 Claude가 모두를 더 풀스택화하고 있음을 시사한다.

앞으로를 바라보며

Anthropic 직원들은 지난 1년 동안 Claude 사용을 크게 늘렸다. 이는 기존 업무를 가속하는 데 그치지 않고, 새로운 코드베이스를 익히고, 잡무를 줄이며, 새로운 영역으로 확장하고, 이전에는 방치되던 개선까지 수행하게 했다. Claude가 더 자율적이고 더 유능해짐에 따라, 엔지니어들은 AI 위임을 활용하는 새로운 방식을 발견하는 동시에 미래에 자신에게 어떤 기술이 필요할지도 고민하고 있다. 이러한 변화는 분명한 생산성과 학습상의 이익을 가져오지만, 동시에 소프트웨어 엔지니어링 업무의 장기적 궤적에 대한 진짜 불확실성도 동반한다. 이 변화는 과거의 소프트웨어 엔지니어링 전환, 예컨대 저수준 언어에서 고수준 언어로의 이동, 혹은 개인 기여자에서 관리자로의 이동과 비슷한 것일까? 아니면 그보다 훨씬 더 멀리 갈 것인가?

아직은 초기 단계다. Anthropic 내부에는 조기 수용자가 많고, 환경도 빠르게 변하고 있으며, 이번 결과는 현재 시점에서 다른 조직이나 맥락으로 일반화되기 어려울 가능성이 높다(추가 한계는 부록 참조). 이 연구는 바로 그런 불확실성을 반영한다. 결과는 단선적인 합의나 명확한 행동 지침을 제시하기보다, 여러 결이 공존하는 미묘한 양상을 보여준다. 그럼에도 어떻게 이러한 변화를 사려 깊고 효과적으로 헤쳐 나갈 것인가라는 질문은 분명히 제기한다.

Anthropic은 이 초기 연구를 후속하기 위해 몇 가지 조치를 취하고 있다. Anthropic은 엔지니어, 연구원, 리더십과 대화를 이어 가며, 이번 연구가 제기한 기회와 과제를 다루고 있다. 여기에는 팀을 어떻게 함께 모으고 상호 협업하게 할 것인지, 전문성 개발을 어떻게 지원할 것인지, 그리고 AI fluency 프레임워크를 포함해 AI가 증강한 업무의 모범 사례를 어떻게 정립할 것인지가 포함된다. 또한 이 연구를 엔지니어 밖의 역할로 확장해 조직 전반의 역할에 AI 전환이 어떤 영향을 주는지 이해하려 하고 있으며, CodePath 같은 외부 조직이 AI 지원 미래에 맞춰 컴퓨터과학 교육과정을 적응시키는 일도 지원하고 있다. 더 앞을 보면, AI 역량이 발전함에 따라 점점 더 중요해질 수 있는 구조적 접근, 예컨대 조직 내 역할 전환의 새로운 경로나 재교육 방식도 검토하고 있다.

Anthropic은 2026년에 더 구체적인 계획을 공유할 수 있을 것으로 기대한다. Anthropic은 책임 있는 직장 전환을 위한 실험실이다. 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의 생산적인 논평과 토론에도 감사한다.

부록

한계

Anthropic의 설문 결과에는 몇 가지 방법론적 한계가 있다. Anthropic은 응답자를 편의 표집과 목적 표집(조직 전반의 폭넓은 대표성을 확보하기 위한 방식)을 병행해 선정했다. 설문은 여러 내부 Slack 채널에 게시되어 68개의 응답을 얻었고, 여기에 더해 조직도에서 연구 및 제품 기능 전반에 걸친 20개의 다양한 팀을 골라 팀당 5~10명에게 직접 메시지를 보냈다(총 접촉 인원 207명). 그 결과 최종적으로 64개의 응답이 추가되어 직접 접촉군의 응답률은 31%였다. 인터뷰는 응답한 사람들 가운데 처음 53명을 대상으로 진행했다. Claude에 특별히 적극적으로 관여하고 있거나, 강한 견해(긍정적이든 부정적이든)를 가진 사람들이 응답할 가능성이 더 높았고, 보다 중립적인 경험을 한 사람들은 덜 대표되었을 가능성이 있으므로 선택 편향(selection bias)이 존재할 수 있다.

또한 응답은 사회적 바람직성 편향의 영향을 받을 수 있다. 응답이 익명이 아니었고, 모든 참여자가 Anthropic 직원이었기 때문에 Claude의 영향을 실제보다 더 긍정적으로 평가했을 수 있다. 12개월 전의 생산성과 사용 패턴을 회상하게 했다는 점에서는 최근성 편향과 기억 왜곡 가능성도 있다. 더불어 앞서 논의했듯 생산성은 본질적으로 추정하기가 매우 어렵기 때문에, 이러한 자가 보고 수치는 일정한 유보를 두고 해석해야 한다. 이와 같은 자가 보고 인식은 더 객관적인 Claude Code 사용 데이터와 함께 해석되어야 하며, 향후 연구는 익명 데이터 수집과 더 강건하게 검증된 측정 도구를 통해 보완될 필요가 있다.

Anthropic의 Claude Code 분석은 시간 구간별 비례 표집을 사용하기 때문에, 절대적 업무량의 변화가 아니라 과업 분포의 상대적 변화만 측정할 수 있다. 예를 들어 신규 기능 구현이 Claude Code 사용의 14%에서 37%로 늘어났다고 보고하더라도, 이것이 전체 신규 기능 업무량 자체가 증가했음을 반드시 뜻하는 것은 아니다.

마지막으로, 이 연구는 2025년 8월에 수행되었으며, 당시 Claude Sonnet 4와 Claude Opus 4가 Anthropic의 최첨단 모델이었다. AI 개발 속도가 매우 빠르다는 점을 고려하면, Anthropic이 관찰한 패턴은 이후 더 새로운 모델이 등장하면서 이미 달라졌을 가능성도 있다.