AI가 코드를 짜주면 업무 속도는 분명 빨라집니다. 그런데 그게 전부일 수 있습니다. 버그는 사라집니다. 그런데 왜 그 버그가 생겼는지 이해하는 능력은 그대로입니다. Addy Osmani 구글 엔지니어가 “AI에게 학습을 외주 주지 말라”는 글에서 이 문제를 정면으로 다뤘습니다.
출처: Don’t Outsource the Learning – Addy Osmani
세 가지 연구가 같은 방향을 가리킨다
최근 AI 보조 작업의 학습 효과를 측정한 연구들이 나오고 있는데, 결론이 놀랍도록 일치합니다.
Anthropic이 2026년 초 진행한 실험에서는 개발자들을 두 그룹으로 나눠 새로운 파이썬 라이브러리를 학습하게 했습니다. 한 그룹은 AI 도움을 받고, 다른 그룹은 혼자 해결했어요. 작업 완료 속도는 두 그룹이 비슷했습니다. 그런데 이후 이해도 테스트에서 AI 그룹은 50%, 비AI 그룹은 67%를 기록했고, 디버깅 문제에서 격차는 더 벌어졌습니다. 흥미로운 건 AI 그룹 내부 결과입니다. AI를 활용해 개념을 질문한 사람들은 65% 이상을 기록한 반면, 생성된 코드를 그냥 붙여넣은 사람들은 40% 미만에 그쳤습니다. 도구가 결과를 결정한 게 아니라, 도구를 쓰는 태도가 결과를 결정했습니다.
MIT의 ‘Your Brain on ChatGPT’ 연구도 비슷한 지점을 짚습니다. 세 그룹(LLM 사용, 검색엔진 사용, 혼자 작성)으로 나눠 에세이를 쓰게 하고 뇌파(EEG)를 측정했더니, LLM 그룹의 뇌 연결성이 가장 약하게 나타났습니다. 에세이 작성 후 자신이 쓴 내용을 인용할 수 없었던 비율이 83%에 달했습니다. 연구진은 이를 “인지 부채(cognitive debt)”라고 불렀습니다. 지금 정신적 수고를 아끼면, 나중에 비판적 사고로 갚아야 한다는 뜻이죠.
CHI 2026 연구는 또 다른 각도를 보여줍니다. 작업 시작 시점에 LLM을 쓰면 LLM이 문제 전체의 틀을 잡아버립니다. 이후 인간이 직접 작업을 마무리해도, 그 초기 틀 설정의 영향으로 의사결정 품질이 낮아진다는 결과가 나왔습니다. AI를 얼마나 많이 쓰느냐보다, 언제 쓰느냐가 더 중요하다는 이야기입니다.
기본값이 학습을 막는다
코딩 에이전트를 켜고 기본 설정으로 사용하면, 모든 것이 단 하나의 지표를 향해 최적화됩니다. 바로 태스크 완료입니다. 모델이 코드를 쓰고, 당신이 수락하고, 루프가 반복됩니다. 어느 순간에도 도구가 “당신은 이 문제를 어떻게 분석했나요?”라고 묻지 않습니다.
Osmani는 이를 “UX 중력”이라고 부릅니다. 제품팀은 코드 병합 건수와 사이클 타임으로 보상을 받지, 당신을 더 날카로운 엔지니어로 만드는 것으로 보상을 받지 않습니다. 우리 모두 더 적은 키 입력을 원하기 때문에, 도구는 마찰을 없애는 방향으로 진화했습니다. 문제는 그 마찰이 바로 학습이 일어나던 공간이었다는 겁니다.
Anthropic의 Learning Mode나 OpenAI의 Study Mode 같은 기능이 이미 존재하지만, 대부분의 개발자는 “학생용”이라고 생각하고 프로덕션 작업에서는 외면합니다. Osmani는 이게 실수라고 말합니다. React를 배우는 대학생에게 효과적인 기능이 Rust를 익히려는 시니어 엔지니어에게도 똑같이 작동합니다.
학습을 외주주면 실력이 손상되는 지점
Osmani는 AI에게 무엇이든 맡겨도 된다고 말하지 않습니다. 다시 볼 일 없는 YAML 설정이나 CI 스크립트 같은 보일러플레이트는 과감히 맡겨도 됩니다. 그러나 실제 소프트웨어에서 순수한 위임이 무너지는 지점이 있습니다.
뭔가 고장났을 때입니다. AI가 만든 코드도 사람이 만든 코드와 똑같이 터집니다. “에이전트가 짰어요”는 디버깅에 아무런 도움이 안 됩니다. 자신 있게 틀린 답을 내놓을 때도 마찬가지입니다. LLM은 그럴듯하게 잘못된 답을 냅니다. 그걸 걸러낼 수 있는 유일한 방어막은 충분한 전문성입니다. 그리고 2022년 이후 주니어 개발자 채용이 20% 감소했다는 Stack Overflow 데이터가 보여주듯이, AI 없이는 일 못 하는 엔지니어가 늘어날수록 그 자리의 가격이 내려갑니다.
도구를 어떻게 쓰느냐가 전부다
결론은 AI를 쓰지 말라는 게 아닙니다. Osmani 본인도 AI 도구를 매일 씁니다. 그가 제안하는 건 태도의 전환입니다.
답을 요청하기 전에 먼저 가설을 세우세요. 문제가 무엇이라고 생각하는지 두세 문장으로 적어보고, 모델의 답변으로 그 이론을 검증합니다. 낯선 영역에서는 코드를 요청하기 전에 먼저 설명을 구합니다. “이게 어떻게 작동하는지, 대안은 뭔지, 트레이드오프는 뭔지 설명해줘”가 먼저입니다. AI가 짠 코드는 주니어 개발자의 PR처럼 다룹니다. 읽고, 비판하고, 테스트가 통과했다는 이유만으로 머지하지 않습니다.
Osmani는 코딩 세션이 끝날 때마다 스스로에게 질문한다고 합니다. “오늘 뭔가 배웠나, 아니면 그냥 티켓만 닫았나?” 때로 정직한 답이 “그냥 이슈만 닫았다”일 때도 있고, 그건 괜찮습니다. 그 답이 몇 달씩 반복된다면, 인지 부채가 쌓이고 있다는 신호입니다.
출하(ship)와 학습(learn)은 별개의 지표입니다. 매니저와 고객은 전자만 물어봅니다. 후자는 오롯이 자신이 책임져야 합니다.
참고자료:
답글 남기기