AI를 쓸수록 실력이 떨어진다 썸네일

AI를 쓸수록 실력이 떨어진다

arXiv Judy Hanwen Shen, Alex Tamkin (Anthropic) How AI Impacts Skill Formation ↗

Anthropic이 개발자 52명을 실험한 결과, AI를 보조로 쓴 그룹은 학습 점수가 17% 낮았습니다.

AI가 코드를 대신 작성하면 개발자가 오류를 직접 겪을 기회가 사라지고, 디버깅 능력이 가장 크게 떨어집니다.

실력을 키우려면 AI에게 답을 맡기지 말고, 개념을 묻는 방식으로 활용해야 합니다.

AI가 코드를 대신 써준다고 좋아했습니까?
실력은 17% 빠지고, 속도는 빨라지지도 않았습니다.
감독 능력까지 잃으면 누가 AI를 감시합니까?

많은 사람이 AI를 쓰면 일이 빨라진다고 믿습니다. Anthropic 연구진은 이 믿음을 무작위 대조 실험으로 검증했습니다. 결과는 불편합니다. AI를 쓴 개발자는 더 빨라지지 않았고, 실력은 17% 떨어졌습니다. "AI로 생산성을 높이겠다"는 전략 뒤에 어떤 비용이 숨어 있는지, 이 연구가 보여줍니다.

기업마다 AI 코딩 보조 도구를 전사적으로 도입하고 있습니다. 그런데 AI가 코드를 대신 써주면 개발자의 실력은 떨어지고, 결국 AI가 만든 결과물을 검증할 사람까지 사라집니다. Anthropic의 Judy Hanwen Shen과 Alex Tamkin은 이 문제를 개발자 52명을 대상으로 한 무작위 대조 실험(RCT)으로 검증했습니다. AI 보조가 실력 형성(Skill Formation)에 미치는 영향을 정량적으로 측정한 최초의 연구 중 하나입니다.

연구 방법론
무작위 대조 실험(RCT)으로, 참가자 52명을 AI 보조 그룹(26명)과 대조 그룹(26명)으로 나눴습니다. 본 실험 전에 4차례 파일럿(A~D, 총 186명)을 진행하며 실험 설계를 정교하게 다듬었습니다.

참가자: Python 경력 1년 이상인 현직 개발자와 프리랜서 52명이 참여했습니다. 모두 매주 Python을 사용하고, AI 도구 경험이 있으며, Trio 라이브러리는 써본 적이 없는 사람들입니다. 경력 분포는 1~3년 4명, 4~6년 19명, 7년 이상 29명으로, 대다수가 시니어급이었습니다.

과제: 참가자들은 비동기 Python 라이브러리 Trio를 처음 학습하면서 2가지 코딩 과제(35분 제한)를 수행했습니다. 과제가 끝난 뒤 14문항 퀴즈(27점 만점)로 학습 성과를 측정했습니다. AI 그룹에는 GPT-4o 채팅 인터페이스를 제공했고, 대조 그룹은 공식 문서만 참조할 수 있었습니다.

보상: 참가자에게 $150를 정액 지급했습니다(약 75분 소요). 성과에 따른 추가 보상은 없었기 때문에, "빨리 끝내야 더 받는다"는 동기 왜곡을 방지했습니다.

52명
참가자 (각 26명)
35분
코딩 과제 제한시간
14문항
퀴즈 (27점 만점)
4회
파일럿 실험 (n=186)

경영 리더가 이 연구에서 주목해야 할 포인트는 4가지입니다.

첫째, AI를 쓴 개발자의 학습 점수가 17% 낮았습니다. AI 그룹은 27점 만점 퀴즈에서 평균 18.8점을 받았고, 대조 그룹은 22.95점을 받았습니다. 4.15점 차이입니다. 효과 크기(Cohen's d)는 0.738로, 통계적으로 유의미합니다(p = 0.010). 사전 워밍업 점수를 통제해도 결과는 거의 같았습니다(d = 0.725, p = 0.016).

퀴즈 점수 비교: AI 그룹 vs 대조 그룹 (27점 만점)
출처: Shen & Tamkin (2025), Figure 6. Cohen's d = 0.738, p = 0.010

둘째, AI를 써도 작업 속도는 빨라지지 않았습니다. AI 그룹의 과제 완료 중앙값은 19.5분, 대조 그룹은 23분이었지만, 이 차이는 통계적으로 유의미하지 않았습니다. 이유가 있습니다. 일부 참가자는 AI에게 보낼 질문을 작성하는 데만 전체 시간의 30%(최대 11분)를 소비했습니다. 코드 생성으로 아낀 시간을, AI와의 대화에 고스란히 다시 쓴 셈입니다. 생산성은 그대로인데 실력만 떨어졌습니다.

셋째, 디버깅 능력에서 격차가 가장 컸습니다. AI 그룹은 오류를 직접 겪을 일이 적었습니다. 대조 그룹의 오류 중앙값이 3.0건(IQR: 2~5건)인 데 비해, AI 그룹은 1.0건(IQR: 0~3건)에 그쳤습니다. 오류 없이 과제를 끝낸 12명 가운데 10명이 AI 그룹이었습니다. 오류를 겪지 않으니 해결 능력도 쌓이지 않았고, 퀴즈에서도 디버깅 문항의 점수 격차가 가장 벌어졌습니다.

오류 발생 빈도 (중앙값): AI 그룹 vs 대조 그룹
출처: Shen & Tamkin (2025), Table 4. 오류 없이 완료한 참가자: AI 그룹 10명, 대조 그룹 2명

넷째, AI를 어떻게 쓰느냐에 따라 결과가 완전히 갈렸습니다. 연구진은 AI 그룹에서 6가지 사용 패턴을 발견했습니다. 코드 생성을 통째로 맡긴 참가자들은 점수가 40% 미만이었고, 개념적 질문만 던진 참가자 7명은 65~86%를 기록했습니다. AI에게 무엇을 시키느냐가 실력이 남느냐 사라지느냐를 결정합니다.

문항 유형별 점수 격차 (대조 그룹 대비 AI 그룹 감소폭)
출처: Shen & Tamkin (2025), Figure 8. 디버깅 영역에서 가장 큰 격차 발생

연구진은 AI 그룹 25명의 대화 로그를 분석해 6가지 사용 패턴을 찾아냈습니다. 흥미로운 점은, 점수가 40% 미만이거나 65% 이상으로 극단적으로 갈렸다는 것입니다. 중간 지대가 거의 없었습니다.

6가지 AI 사용 패턴별 퀴즈 점수 범위 (%)
출처: Shen & Tamkin (2025), Figure 11. 빨간색 = 저성과 패턴, 초록색 = 고성과 패턴

저성과 패턴 (점수 40% 미만):

1. AI 위임(AI Delegation, 4명): 코딩을 통째로 AI에게 맡겼습니다. 과제는 가장 빨리 끝났지만(약 19.5분), 오류를 거의 겪지 않았기 때문에 학습이 일어나지 않았습니다.

2. 점진적 의존(Progressive AI Reliance, 4명): 처음에는 1~2개 질문으로 시작했다가 점차 AI에게 전부 맡기는 쪽으로 기울었습니다. Task 2의 핵심 개념을 끝내 숙달하지 못했습니다.

3. 반복적 AI 디버깅(Iterative AI Debugging, 4명): 오류가 날 때마다 에러 메시지를 AI에게 붙여넣었습니다. 질의 횟수는 가장 많았지만, 점수는 가장 낮았습니다.

고성과 패턴 (점수 65~86%):

4. 생성-후-이해(Generation-Then-Comprehension, 2명): AI가 생성한 코드를 직접 타이핑하면서 옮긴 뒤, "이 부분은 왜 이렇게 쓰나?"라는 후속 질문을 던졌습니다. 코드를 받되 이해를 확인하는 단계가 핵심이었습니다.

5. 하이브리드 코드-설명(Hybrid Code-Explanation, 3명): 코드 생성과 설명을 동시에 요청했습니다. 설명을 읽느라 시간이 더 걸렸지만, 개념 이해도는 높았습니다.

6. 개념적 질의(Conceptual Inquiry, 7명): AI에게는 개념만 물어보고, 코드는 직접 작성했습니다. 오류를 많이 겪었지만 스스로 해결했고, 고성과 패턴 중 가장 빠른 완료 시간(약 21.5분)을 기록했습니다.

"게을러진 것 같아요. Trio 라이브러리 소개와 코드 예제를 평소처럼 꼼꼼히 읽지 않았습니다." — AI 그룹 참가자 (실험 후 설문)

메커니즘 1: 오류를 겪을 기회가 차단됩니다. 대조 그룹은 Trio 고유의 개념적 오류를 직접 만났습니다. "코루틴을 대기하지 않았다"는 RuntimeWarning, 타입이 맞지 않는다는 TypeError 같은 오류입니다. 이런 오류를 직접 해결하는 과정 자체가 학습이었습니다. 반면 AI 그룹은 오타 수준의 문법 오류(NameError, AttributeError)만 경험했습니다. AI가 개념적 시행착오를 미리 막아버린 것입니다.

메커니즘 2: 생각을 AI에게 떠넘깁니다(Cognitive Offloading). AI 그룹은 코드를 직접 쓰는 시간이 줄어든 대신, AI 출력을 읽고 이해하는 시간이 늘어났습니다. 문제는 "읽는 것"과 "직접 해보는 것"의 학습 효과가 다르다는 점입니다. 실제로 능동적 코딩 시간이 많은 참가자일수록 퀴즈 점수가 높았습니다.

메커니즘 3: AI와의 대화가 시간을 잡아먹습니다. 일부 참가자는 질문 하나를 쓰는 데 6분, 전체 AI 대화에 11분 넘게 썼습니다. 35분짜리 과제에서 이는 전체 시간의 30%가 넘습니다. 코드 생성으로 아낀 시간을 질문 작성과 응답 이해에 고스란히 되돌려준 셈입니다.

"아직 이해에 많은 빈틈이 있습니다. AI 설명을 좀 더 시간을 들여 이해했어야 했는데..." — AI 그룹 참가자 (실험 후 설문)
"'start_soon' 메서드 같은 단순한 것도 이해하지 못했습니다. 아무것도 남지 않은 느낌입니다." — AI 그룹 참가자 (실험 후 설문)

AI 보조 도구가 실력을 깎는다는 사실을 방치하면, 그 대가는 조직 전체로 돌아옵니다.

주니어 개발자의 성장이 느려집니다. AI에 의존하는 주니어 개발자는 디버깅과 코드 이해 능력을 키우기 어렵습니다. 시니어로 성장하는 데 시간이 더 걸리고, 교육에 투자한 만큼 역량이 따라오지 않습니다.

AI가 만든 코드를 검증할 사람이 부족해집니다. 이 연구에서 가장 큰 격차를 보인 영역이 디버깅입니다. 디버깅 능력이 약한 개발자가 AI 생성 코드를 리뷰하면, AI의 실수가 프로덕션까지 그대로 흘러갑니다. 안전이 중요한 시스템에서 이는 곧 사고 비용으로 이어집니다.

조직의 기술 부채가 쌓입니다. AI가 작성한 코드를 이해하지 못하는 개발자가 늘어나면, 유지보수와 장애 대응이 점점 어려워집니다. 코드를 이해하는 사람이 줄수록 기술 부채 해소 비용은 기하급수적으로 커집니다.

1
AI 코딩 도구 사용 가이드라인을 팀에 배포하세요.
"코드 생성 위임"과 "개념 질문"을 구분하는 것이 핵심입니다. 새로운 기술을 배울 때는 코드 생성 요청을 자제하고, 개념 설명을 먼저 요청하도록 안내하세요. 이 연구에서 개념적 질문 패턴을 쓴 참가자는 학습 점수가 65~86%로 높았습니다. (15분)
이 라이브러리의 핵심 개념(Nursery 패턴, 메모리 채널)이 어떤 문제를 해결하는지, 코드 없이 개념만 설명해 주세요. 기존 asyncio와 어떻게 다른지도 비교해 주세요.
2
코드 리뷰에 "이해도 확인" 질문을 추가하세요.
AI가 생성한 코드를 제출할 때, "이 코드에서 에러가 나면 어디를 먼저 확인할 것인가?"라고 물어보세요. 답하지 못하면, 그 개발자는 AI 위임 패턴에 빠져 있다는 신호입니다. (10분)
3
새로운 기술을 도입할 때 "AI 없는 학습 시간"을 확보하세요.
처음 1~2시간은 공식 문서를 읽고 직접 코딩하면서 개념을 잡으세요. 오류를 직접 겪고 해결하는 과정이 학습의 핵심입니다. 그 이후에 AI 보조를 활용하면 생산성과 실력을 모두 지킬 수 있습니다. (즉시 적용)

52명을 대상으로 한 단일 실험입니다. 처음 보는 라이브러리를 35분 동안 학습하는, 다소 특수한 상황에서 나온 결과입니다. 실무 환경에서 수개월~수년간 같은 패턴이 반복되는지는 추가 검증이 필요합니다. 다만 파일럿 D(n=20)에서도 같은 방향의 결과가 나왔고, 효과 크기는 오히려 더 컸습니다(d = 1.7).

AI를 전면 금지하는 것은 답이 아닙니다. 이 연구의 핵심 메시지는 "AI를 쓰지 마라"가 아니라 "쓰는 방식을 바꿔라"입니다. 개념적 질문 패턴을 쓴 7명은 학습 손실 없이 과제를 마쳤습니다. AI를 금지하면 생산성의 이점까지 함께 사라집니다.

이미 잘 아는 분야에서는 결과가 다를 수 있습니다. 이 연구는 새로운 기술을 배우는 상황만 다뤘습니다. 익숙한 분야에서 AI를 쓸 때 실력에 어떤 영향이 있는지는 아직 모릅니다. 참가자 대부분이 7년 넘게 코딩한 경력자였지만, Trio 라이브러리는 모두에게 처음이었습니다.

채팅 기반 인터페이스만 실험했습니다. 연구진도 인정한 부분입니다. Cursor나 Copilot 같은 에이전틱(Agentic) AI 도구는 사람의 개입을 더 적게 요구합니다. 이런 도구에서는 인지적 부하 전가가 더 심해질 수 있어, 실력 저하 효과가 이 연구보다 클 가능성이 있습니다.

인간 멘토링과의 비교는 빠져 있습니다. 이 연구는 AI 보조 vs 무보조만 비교했습니다. 같은 상황에서 페어 프로그래밍이나 코드 리뷰 같은 인간 보조를 받았다면 어땠을지는 열린 질문으로 남아 있습니다.

AI는 생산성 도구이지, 학습 도구가 아닙니다. 실력 없이 AI를 쓰면 AI를 감독할 능력까지 잃게 됩니다.

창업자 AI 코딩 도구를 도입할 때, 주니어 개발자의 학습 경로에 "AI 없는 구간"을 설계하세요.
팀장 코드 리뷰에서 AI 생성 코드의 비율과 개발자의 이해도를 함께 확인하는 체크리스트를 만드세요.
임원 AI 도구의 생산성 지표뿐 아니라, 인력 역량 지표도 함께 추적하는 대시보드를 구축하세요.
  • Shen, J. H., & Tamkin, A. (2025). How AI Impacts Skill Formation [Preprint]. arXiv:2601.20245v2. (원문 보기 ↗)
라운드테이블
R
레드 · 저널리스트
개발자 52명 실험인데, 이게 전사 도입 근거가 될 수 있나요? 샘플이 너무 작지 않습니까. Cohen's d 0.738이 "유의미"하다고 바로 결론 내리기엔 맥락이 필요합니다.
N
네이비 · 시니어 엔지니어
RCT 설계에 파일럿 4회(n=186)까지 거쳤어요. p=0.010이면 심리학 기준으로 충분히 유의미합니다. 샘플 크기보다 설계 엄밀성이 중요해요.
R
레드 · 저널리스트
35분짜리 단일 과제 결과가 실제 업무 환경까지 일반화되는지는 여전히 물음표입니다. 연구 자체는 인정하지만 "전사 도입 재검토"까지 가는 건 비약 아닌가요.
B
블랙 · 중견기업 임원
결론은 하나입니다. "코드 생성 위임"은 금지, "개념 질문"만 허용. 점수 65~86%가 이걸 증명하니까요. 사용 가이드라인을 지금 당장 팀에 배포하세요.
G
골드 · 창업자
저도 똑같이 느꼈어요. 근데 솔직히 "개념 질문만 해"라는 가이드라인을 팀원들이 실제로 지키는지가 문제예요. 질문 하나 쓰는 데 6분 쓰는 사람이 현실에 수두룩하거든요.
P
퍼플 · 마케터
가이드라인 배포보다 프레이밍이 먼저예요. "AI는 코치다, 선수가 아니다"라고 팀원한테 말해보세요. 코드를 직접 짜야 하는 이유가 납득이 돼야 따르거든요.
W
화이트 · 조직장
위에서는 AI 쓰라고 하는데, 쓸수록 실력이 떨어진다는 연구가 나오네요. 그럼 저는 뭘 근거로 팀에 AI 쓰라고 해야 합니까?
N
네이비 · 시니어 엔지니어
쓰는 방식이 문제입니다. AI에게 코드 통째로 생성 → 점수 40% 미만. 개념 질문 → 65~86%. 도구가 나쁜 게 아니라 사용법이 잘못된 겁니다.
B
블랙 · 중견기업 임원
AI 생산성 지표와 인력 역량 지표를 함께 추적하는 대시보드부터 만드세요. 수치 없이 방향을 정하면 흔들립니다.
_posts/2026-02-01-ai-skill-erosion-anthropic-study.md