**AI를 활용한 프로그래밍 (Programar con IA)**은 작업을 더 빨리 끝내게 해주지만, 이해도는 낮아지게 만듭니다. 이것은 Anthropic이 52명의 엔지니어를 대상으로 실시한 통제된 실험에서 도출된 불편한 결론입니다. AI 어시스턴트에 의존한 그룹은 이해도 테스트에서 평균 50%를 기록한 반면, 수동으로 코드를 작성한 그룹은 67%를 기록했습니다. 거의 두 단계의 성적 차이가 난 것입니다.

이 연구는 AI가 나쁘다고 말하는 것이 아닙니다. 그보다 더 미묘하고 유용한 사실을 말하고 있습니다. 즉, 결과는 당신이 AI를 어떻게 사용하는지에 달려 있다는 것입니다. 개념을 질문한 사람들은 배웠지만, 모든 것을 위임한 사람들은 배우지 못했습니다.

요약 (TL;DR)

• Anthropic은 52명의 엔지니어를 대상으로, 그들이 알지 못하는 Python의 비동기 (async) 라이브러리인 Trio를 학습하는 통제된 실험을 진행했습니다.
• AI를 사용한 그룹은 이해도 테스트에서 평균 50%를 기록했고, 수동 그룹은 67%를 기록했습니다. 이는 거의 두 단계의 차이입니다.
• AI 그룹은 약 2분 일찍 작업을 마쳤으나, 이는 통계적으로 유의미한 차이는 아니었습니다.
• 가장 큰 격차는 디버깅 (debugging) 질문에서 나타났습니다. AI에 위임하는 것은 오류를 찾는 능력을 약화시킵니다.
• 사용 방식이 중요합니다. 개념을 질문한 사람들은 65-86%를 기록한 반면, 코드 전체를 위임한 사람들은 40% 미만을 기록했습니다.
• 일부 참가자들은 프롬프트 (prompts)를 작성하는 데 최대 11분을 소비하여, 절약한 시간을 상쇄하기도 했습니다.
• 이 발견은 더 큰 논쟁에 불을 지핍니다. Meta는 직원당 AI 토큰 (tokens) 사용량을 측정하고 있으며, 프로그래밍하는 법을 잊어버리고 있다고 보고하는 개발자들도 있습니다.

발생한 상황

Anthropic은 많은 팀이 낮은 목소리로 자문하는 질문에 답하기 위해 설계된 실험 결과를 발표했습니다. 즉, 개발자가 AI 어시스턴트에 의존하여 새로운 것을 배울 때, 실제로 배우는 것인가 아니면 단순히 과업을 제출하는 것인가 하는 점입니다. 이 회사는 주로 주니어 프로필을 가진 52명의 소프트웨어 엔지니어를 모집했으며, 이들은 모두 매주 Python을 사용하는 최소 1년 이상의 경력을 가지고 있었고 프로그래밍을 위한 AI 도구에 익숙한 상태였습니다.

설계의 핵심 트릭은 아무도 숙달하지 않은 주제를 선택하는 것이었습니다: 바로 비동기 프로그래밍 (asynchronous programming)을 위한 Python 라이브러리인 Trio였습니다. 제로 베이스에서 시작함으로써, 연구진은 사전 지식이 결과에 영향을 미치지 않도록 하면서 각 그룹이 과제를 수행하는 동안 얼마나 학습하는지를 측정할 수 있었습니다. 참가자의 절반은 AI 어시스턴트를 자유롭게 사용할 수 있었고, 나머지 절반은 문서(documentation)만 참고하며 수동으로 코드를 작성했습니다. 그 후, 모두가 동일한 테스트에 응시했습니다.

결과는 명확하고 측정 가능했습니다. **AI를 활용한 프로그래밍 (Programming with AI)**은 결과물 제출 속도를 약간 가속화했지만, 참가자들이 방금 구축한 내용에 대해 현저히 낮은 이해도를 갖게 만들었습니다. 그리고 이 테스트는 단순한 상식을 묻는 것이 아니었습니다: 디버깅 (debugging), 코드 읽기, 코드 작성, 그리고 개념적 이해, 즉 훌륭한 엔지니어를 정의하는 역량들을 평가했습니다.

어시스턴트는 제출을 가속화하지만, 지식의 습득을 보장하지는 않습니다.

실험 방식

연구는 세 단계로 구성되었습니다. 먼저 모두가 적응할 수 있도록 하는 워밍업 단계가 있었습니다. 그다음 주요 과제: Trio를 사용하여 두 가지 기능을 구현하는 것이었는데, 이는 동시성 (concurrency) 및 비동기 실행 (asynchronous execution) 개념을 이해하도록 강제했습니다. 마지막으로, 어떤 참가자도 외부의 도움 없이 해결할 수 없는 개별 설문 조사가 진행되었습니다.

Trio는 사소한 주제가 아닙니다. 비동기 프로그래밍은 코드가 직관적이지 않은 방식으로 "작동하거나" 혹은 "작동하지 않는" 주제 중 하나입니다. 잘못 조정된 코루틴 (coroutine) 하나가 명백한 에러를 발생시키지 않고 프로그램을 멈추게 할 수 있기 때문입니다. 교차로 실행되는 작업들에 대해 추론하는 법을 배우려면 복사해서 붙여넣는 것이 아니라 정신적 모델 (mental model)을 구축해야 합니다. 그렇기에 이곳은 이해한 사람과 단순히 결과물만 제출한 사람을 구분하기 위한 이상적인 영역이었습니다.

그들이 이해해야 했던 코드의 유형은 다음과 같습니다:

import trio

async def tarea(nombre, segundos):
...

[IMG:1]

"B"가 "A"보다 왜 먼저 종료되는지, 또는 nursery 내부에서 작업 중 하나가 예외(exception)를 발생시키면 어떤 일이 일어나는지를 이해하는 것이 바로 이 설문 조사가 평가하고자 했던 추론의 유형입니다. AI는 이 코드 블록을 몇 초 만에 작성할 수 있습니다. 연구의 핵심 질문은 이미 완성된 코드를 받은 사람이 나중에 이를 설명할 수 있느냐는 것이었습니다.

💭 핵심: AI를 사용한 그룹은 약 2분 일찍 끝났지만, 그 차이는 통계적으로 유의미하지 않았습니다. 실제 시간 절약은 거의 없었던 반면, 이해도 측면에서의 17포인트 손실은 매우 컸습니다.

수치

가장 핵심적인 수치는 설문 조사에서의 격차입니다: AI 사용 그룹의 정답률은 50%인 반면, 수동 그룹은 67%였습니다. 연구진은 이를 성적 등급으로 환산하면 거의 두 단계 차이에 해당한다고 설명합니다. 즉, 턱걸이 합격에서 낙제로, 또는 우수(notable)에서 합격(aprobado)으로 떨어지는 수준의 차이입니다.

두 번째 데이터는 위임(delegating)을 옹호하는 가장 흔한 논거인 '속도'를 반박합니다. 네, AI 그룹이 더 빨리 끝내긴 했지만 고작 2분 정도였으며, 분석 자체에서도 이를 유의미하지 않은 차이로 규정했습니다. 게다가 일부 참가자들은 프롬프트(prompt)를 작성하는 데만 최대 11분을 소비했는데, 이는 단순히 코드를 직접 작성하는 것과 비교했을 때 시간 절약 효과를 완전히 상쇄해 버렸습니다.

세 번째 발견은 팀을 관리하는 사람에게 가장 시사하는 바가 큽니다. 성능 격차가 가장 크게 나타난 부분은 바로 디버깅(debugging) 관련 질문이었습니다. 수동 그룹은 작업 중에 더 많은 실수를 저질렀지만 스스로 이를 해결했으며, 그러한 시행착오 과정이 결함(fault)을 찾아내고 수정하는 능력을 정확히 강화했습니다. 반면 AI 그룹은 연습 과정에서 덜 넘어졌지만, 정작 그 근육을 단련하지 못한 채 테스트에 임하게 되었습니다.

AI의 문제가 아니라, 어떻게 사용하는가의 문제

이것이 이 소식이 단순한 공포 조장용 헤드라인이 되지 않게 만드는 미묘한 차이입니다. 연구에서는 AI 사용의 여섯 가지 뚜렷한 패턴을 식별했으며, 성능은 사용 패턴에 따라 두 갈래로 나뉘었습니다. 어시스턴트를 사용하여 **개념적인 질문 (conceptual questions)**을 하거나 코드와 함께 **설명 (explanations)**을 요청한 사람들은 65%에서 86% 사이의 성적을 거두었습니다. 반면, **전체 코드 생성을 위임 (delegating complete code generation)**하거나 AI와 함께 맹목적으로 반복하며 디버깅을 수행한 사람들은 40% 미만으로 떨어졌습니다.

다시 말해, 동일한 도구를 동일한 주니어 개발자가 사용하더라도 의도에 따라 정반대의 결과가 나타났습니다. 설명해 주는 튜터(tutor)로서의 AI는 작동하지만, 결과물만 전달하는 노동자로서의 AI는 작동하지 않습니다. 차이는 모델에 있는 것이 아니라, 인간이 계속해서 사고하고 있는지에 달려 있습니다.

graph LR
  A["AI 어시스턴트 사용"] --> B{"사용 방식"}
  B -->|"개념 질문"| C["테스트 성적 65-86%"]
...

💡 팁: AI로 새로운 것을 배우고 있다면, AI에게 왜 그 솔루션이 작동하는지, 그리고 코드 한 줄을 바꾼다면 어떤 일이 일어날지 설명해 달라고 요청하세요. 어시스턴트를 공급자가 아닌 교사로 만드세요.

얼마나 배우느냐를 예측하는 것은 도구가 아니라 사용 패턴입니다.

더 넓은 논쟁

Anthropic의 실험은 진공 상태에서 발생한 것이 아닙니다. 대기업들이 모든 키보드에 AI를 밀어 넣는 것이 직업에 어떤 영향을 미칠지에 대한 점점 더 격렬해지는 논쟁의 한복판에서 나왔습니다. 최근 보고에 따르면, Meta는 직원당 AI 토큰 소비량을 측정하는 내부 대시보드를 도입했는데, 이는 항상 어시스턴트를 켠 상태로 프로그래밍하도록 압박하는 지표입니다. Cursor와 같은 도구들은 팀 전체에 표준으로 보급되고 있습니다.

이와 병행하여, Futurism과 같은 매체들은 자신의 기술이 침식되고 있다고 설명하는 엔지니어들의 증언을 수집했습니다. 익명을 요구한 한 엔지니어는 Laravel에서 API를 구현하는 방법을 잊어버렸다는 사실을 깨닫고 겁이 났던 순간을 다음과 같이 전했습니다: "이를 위해 대학에 갔고, 수년간 소프트웨어 엔지니어로 일해 왔는데, 마치 첫 번째 코드 라인을 쓰기 전의 상태로 돌아간 것 같은 기분이 듭니다". 또 다른 이는 이를 휴대전화가 보급되면서 전화번호를 외우지 않게 된 것에 비유하며, 다만 이번에는 '생각하는 것'을 외주화하고 있는 것이라고 요약했습니다.

사실과 허구를 구분할 필요가 있습니다. 이러한 증언들은 일화(anecdote)일 뿐, 데이터는 아닙니다. Anthropic 연구의 가치는 바로 많은 이들이 증거 없이 설명해 온 막연한 느낌 아래에, 통제된 실험을 통해 도출된 엄격한 수치를 제시했다는 점에 있습니다. 그리고 그 수치는 현재의 불안감과 같은 방향을 가리키고 있습니다.

⚠️ 주의: 위험은 주니어(junior) 프로필에 집중됩니다. 아직 자신의 멘탈 모델(mental models)을 형성하고 있는 사람은 악순환에 빠질 수 있습니다. 검증과 디버깅을 위해 AI에 의존하게 되고, 이는 의존성을 끊을 수 있게 해주는 비판적 사고(criterium)를 개발하는 것을 방해합니다.

영향 및 분석

엔지니어링 팀에게 실질적인 시사점은 "AI를 금지하라"가 아닙니다. 그것은 터무니없고 역효과를 낼 것입니다. 핵심은 배포 속도로 측정된 생산성 이면에, 특히 경력 초기 단계에서의 교육이라는 보이지 않는 비용이 숨겨져 있다는 점입니다. 빠르게 결과물을 내놓지만 자신이 무엇을 내놓는지 이해하지 못하는 주니어는 중기적으로 자산(asset)이 아니라 부채(liability)입니다.

이 연구는 구체적인 개입 방안을 제안합니다. AI가 단순히 결과물을 생성하는 것이 아니라 설명하도록 워크플로우(workflow)를 설계해야 합니다. 어시스턴트의 역할을 개념적인 질문에 답하는 것으로 제한하는 의도적 학습(deliberate learning) 과제를 따로 마련해야 합니다. 그리고 사람을 평가할 때 완료된 코드 라인이 아니라 이해도를 기준으로 평가해야 합니다. 토큰 대시보드처럼 오직 속도만을 측정하는 조직은 정확히 잘못된 변수를 최적화할 위험이 있습니다.

데이터 자체가 뒷받침하는 낙관적인 해석도 존재합니다. AI를 소크라테스식 도구 (Socratic tool)로 사용할 경우, 결과는 수동 작업의 평균을 상회하여 최대 86%의 점수를 기록했습니다. 제대로 사용된 AI를 통한 학습의 천장은 더 낮아지는 것이 아니라 더 높아집니다. 문제는 '위임 (delegating)'이라는 쉬운 길이 바로 학습을 꺼버리는 길이라는 점입니다.

향후 과제

52명을 대상으로 단 하나의 라이브러리를 사용한 실험은 시작점일 뿐, 최종 결론은 아닙니다. 다음과 같은 질문들이 여전히 남아 있습니다. 이해도 결핍이 시간이 지나도 유지되는가, 아니면 AI 없이 동일한 문제에 다시 부딪혔을 때 회복되는가? 이미 공고한 멘탈 모델 (mental models)을 갖추고 있고 어쩌면 이미 알고 있는 것을 가속화하기 위해서만 AI를 사용하는 시니어 엔지니어들에게도 동일하게 적용되는가? 가르치기 위해 명시적으로 설계된 어시스턴트 (assistants)를 사용하면 결과가 달라지는가?

예상되는 흐름은 이러한 유형의 연구가 더 많아지고, 바라건대 이 발견을 통합한 도구들이 등장하는 것입니다. 즉, 기본적으로 자신의 추론 과정을 설명하고, 역으로 질문을 던지며, 사용자가 이해 없이 위임하고 있는지를 감지하는 어시스턴트들 말입니다. 해당 연구를 둘러싼 Hacker News의 논의도 이미 그 방향으로 흐르고 있었으며, 종단적 데이터 (longitudinal data)를 요구하고 학습을 위한 사용과 생산을 위한 사용을 구분할 것을 요청하고 있습니다. 그동안 권장되는 사항은 오래되었으면서도 동시에 새로운 것입니다. AI를 더 잘 생각하기 위해 사용하되, 생각을 멈추기 위해 사용하지 마십시오.

📖 Telegram 요약: 요약 보기

자주 묻는 질문 (FAQ)

Anthropic의 연구는 정확히 무엇을 측정했나요?

52명의 엔지니어가 그들에게 생소한 새로운 Python async 라이브러리인 Trio를 사용하여 기능을 구현할 때 얼마나 학습하는지를 측정했습니다. 최종 테스트는 디버깅 (debugging), 코드 읽기 (code reading), 코드 작성 (code writing), 그리고 개념적 이해 (conceptual understanding)라는 네 가지 역량을 평가했습니다.

AI가 프로그래머를 더 못하게 만드나요?

자동으로 그러지는 않습니다. 연구 결과에 따르면, 코드 생성 전체를 위임하는 것은 더 낮은 이해도(40% 미만)를 초래했지만, 설명을 요청하거나 개념을 묻는 데 AI를 사용하는 것은 65%에서 86%의 점수로 이어졌습니다. 결정적인 요인은 도구가 아니라 사용 패턴입니다.

왜 디버깅(debugging)이 가장 큰 영향을 받는 분야인가요?

디버깅은 시행착오를 통해 배우기 때문입니다. 수동 그룹은 더 많은 실수를 저질렀고 이를 스스로 해결하며 해당 기술을 훈련했습니다. 반면 AI 그룹은 작업 중에 오류를 덜 발견했으며, 실제 진단 연습 없이 테스트에 임하게 되었습니다.

주니어 개발자가 기술을 잃지 않으려면 AI를 어떻게 사용해야 하나요?

AI를 노동자가 아닌 튜터(tutor)로 대해야 합니다. 자신의 솔루션이 왜 작동하는지, 어떤 대안이 있는지, 코드의 일부를 변경하면 어떤 일이 발생하는지 설명해 달라고 요청하세요. 보조 도구 없이 문제를 해결하고 자신만의 판단 기준을 구축하는 시간을 따로 확보해야 합니다.

이 결과가 시니어 프로그래머에게도 적용되나요?

연구는 주로 주니어 프로필에 집중되었으므로, 시니어에게 적용된다는 점은 확인되지 않았습니다. 합리적인 가설은 이미 견고한 멘탈 모델(mental models)을 가진 사람은 이해도를 잃지 않으면서 AI를 사용하여 속도를 높일 수 있다는 것이지만, 이를 확정하기 위해서는 더 많은 연구가 필요합니다.

AI 그룹이 적어도 더 빨랐나요?

거의 그렇지 않았습니다. 약 2분 정도 일찍 끝났는데, 이는 통계적으로 유의미한 차이가 아니며, 일부 참가자들은 프롬프트(prompt)를 작성하는 데 최대 11분을 소비하여 예상되는 시간 절약 효과를 상쇄했습니다.

참고 문헌