배움을 AI에게 아웃소싱하지 마세요

https://addyosmani.com/blog/dont-outsource-learning/

지금은 AI가 코드를 대신 써주는 동안, 우리는 학습을 건너뛰기 너무 쉬운 시기입니다. 버그는 고쳐지지만, 내 머릿속 모델은 전혀 달라지지 않습니다. 우리는 눈치채지 못한 채, 미래의 역량을 오늘의 속도와 바꾸고 있습니다. 도구들이 이걸 막아주지는 않을 겁니다. 그 부분은 결국 당신이 해야 할 몫입니다.

요즘 대부분이 비슷한 기본 루프에 머물러 있습니다. 스펙이나 에러 메시지를 붙여넣습니다. 모델이 해결책을 내줍니다. 증상이 사라집니다. 배포합니다. 이 루프 어딘가에서, 문제와 해답 사이의 지저분한 씨름은 아예 사라져 버립니다.

예전에 저는 인지적 항복(cognitive surrender)에 대해 쓴 적이 있습니다. AI 리뷰어의 판단이 조용히 당신 자신의 판단을 대체해 버리는 순간 말이죠. 지금 이야기하는 건 그 루프의 1인용 버전입니다. 이번엔 당신과 모델만 있습니다. 모델이 더 빠르니, 이해력으로 경쟁하는 시도 자체를 멈춰 버립니다. 이렇게 수많은 작은 상호작용이 쌓이면서, AI의 도움 없이 스스로 만들어낼 수 있는 것들이 매주 조금씩 약해집니다. 그 순간순간에는 전혀 문제처럼 느껴지지 않는데도 말입니다.

저는 반(反) AI가 아닙니다. 저도 매일 이 도구들을 쓰고 있고, 지난 1년 동안 이 도구들 덕분에 그 전 5년보다 더 많은 것을 실제로 만들었습니다. 다만 우리가 지금 기본값으로 쓰는 방식은 오직 한 가지에 최적화되어 있습니다. 바로 “태스크를 닫는 것”이죠. 그런데 이건, 수십 년에 걸친 커리어 동안 이 도구들을 제대로 조종할 수 있을 만큼 날카롭게 유지되는 것과는 완전히 다른 목표입니다.

여러 연구가 같은 결론을 향해 수렴하고 있다

지난 1년 사이에 나온 여러 연구들이 대체로 비슷한 지점에 도달했습니다.

Anthropic은 2026년 초에 무작위 대조 실험을 진행했습니다. 새로운 Python 라이브러리를 학습하는 실험이었고, 절반은 AI의 도움을 받게 하고 나머지 절반은 도움 없이 진행하게 했습니다. 두 그룹 모두 과제를 끝내는 속도는 비슷했습니다. 하지만 이후에 치른 이해도 테스트에서 AI 그룹은 참패했습니다. 점수는 50%, 수작업 그룹은 67%였고, 디버깅 문제에서는 이 격차가 더 벌어졌습니다. 흥미로운 지점은 AI 그룹 내부의 차이였습니다. AI를 “개념 질문”에 쓰던 엔지니어들은 65% 이상을 받았습니다. 반면 생성된 코드를 그대로 복사·붙여넣기만 한 사람들은 40% 미만이었습니다. 도구 자체가 결과를 결정한 게 아니라, 도구를 대하는 태도가 결과를 갈랐습니다.

MIT의 Your Brain on ChatGPT 연구는 에세이 쓰기를 LLM 그룹, 검색 엔진 그룹, 순수 두뇌 그룹으로 나눠 비교했습니다. EEG 측정 결과, 외부 지원 레이어가 하나씩 늘어날수록 뇌 연결성이 단계적으로 떨어지는 모습이 관찰되었습니다. LLM 그룹은 가장 약한 결합을 보였습니다. 에세이를 다 쓰고 난 뒤, LLM 사용자의 83%는 자신이 방금 쓴 글에서 한 줄도 인용하지 못했습니다. 연구진은 이를 ‘인지 부채(cognitive debt)’라고 불렀습니다. 오늘의 정신적 노력을 아끼는 대신, 내일의 비판적 사고력을 갚아야 하는 부채 말입니다.

CHI 2026 연구에서는 또 다른 관련 결과가 나왔습니다. 과제 시작 시점부터 LLM에 접근할 수 있었던 사람들은, LLM이 문제 전체를 어떻게 바라봐야 할지 ‘틀’을 잡아주었습니다. 이후 나머지 작업은 사람이 스스로 했더라도, 초반의 그 앵커링 때문에 의사결정 품질이 눈에 띄게 떨어졌습니다. AI를 얼마나 많이 썼는지보다, 어떤 ‘순서’로 썼는지가 더 중요하게 작용한 것입니다.

연구 방법은 달랐지만 결론은 같습니다. 배우겠다는 ‘능동적 의도’ 없이 AI를 쓰면, 당신이 돈을 받고 있는 바로 그 역량이 조용히 침식됩니다.

도구들의 기본 목표는 “가르치는 것”이 아니라 “배포하는 것”

코딩 에이전트를 켜고 기본 설정 그대로 쓰기 시작하면, 모든 것이 단 하나의 지표에 맞춰져 있음을 알게 됩니다. 태스크를 끝내는 것 말이죠. 모델이 코드를 씁니다. 당신은 그걸 받아들입니다. 이 루프가 계속 반복됩니다. 이 과정 어디에서도 도구는 “당신은 이 문제가 뭐라고 생각하나요?”라거나 “먼저 당신이 코드 다섯 줄을 써보세요”라고 멈춰 세우지 않습니다.

이건 음모론이 아니라 UX의 중력입니다. 프로덕트 팀은 당신을 더 날카로운 엔지니어로 만드는 것보다, 머지된 변경과 짧아진 사이클 타임으로 보상을 받습니다. 모두가 키스트로크를 줄이고 싶어 하고, 그 결과 도구들은 거의 모든 마찰을 깎아냈습니다. 문제는, 그 마찰이 바로 학습이 일어나던 자리였다는 겁니다.

몇몇 회사들은 여기에 반기를 들기 시작했습니다. Anthropic은 Claude에 학습 모드(Learning Mode)를 출시했습니다. 소크라테스식 질문을 던지고, 계속 진행하기 전에 당신에게 먼저 코드를 써보라고 요구하는 기능입니다. OpenAI와 Google도 비슷한 기능을 내놓았습니다. 하지만 실제 프로덕션 작업에서 이 기능들을 쓰는 사람은 거의 없습니다. 우리는 이 기능들을 조용히 “학생용” 폴더에 넣어두었고, 그건 실수입니다. React를 배우는 2학년 학생에게 도움이 되는 기능은 Rust를 배우는 시니어 엔지니어에게도 똑같이 유효합니다. 단지, 다시 초보자가 되는 느낌을 감수할 준비가 필요할 뿐입니다.

“AI가 할 수 있는데, 내가 이해할 필요가 있나요?”

그럴듯한 질문입니다. 어떤 종류의 일에서는 답이 “그럴 필요 없다”가 될 수도 있습니다. 보일러플레이트, 접착용 코드, 두 번 다시 열어볼 일 없는 CI 스크립트라면 그냥 맡기세요. YAML 문법을 외우는 데 쓰는 기회비용은 너무 큽니다.

하지만 진짜 소프트웨어에서는, 순수 위임이 딱 몇 지점에서 깨져 나갑니다.

문제가 생겼을 때. AI가 쓴 코드도 사람 코드와 똑같이 크래시합니다. “에이전트가 쓴 코드라서요”라는 말은 디버깅에 아무 도움이 되지 않습니다. 팀 안에서 누군가는 이 아키텍처를 실제로 이해하고 있어야 합니다.

자신감 있게 틀릴 때. LLM은 허구를 그럴듯하게 지어낼 수 있습니다. 그럴듯해 보이지만 틀린 답을 걸러낼 수 있는 유일한 방어막은, 그 분야에 대한 충분한 전문성입니다.

기반이 바뀔 때. 코드는 일시적이지만, 시스템은 오래갑니다. 프레임워크가 업데이트되거나 보안 리뷰에서 구조적인 이슈가 지적될 때, 프롬프트만 다시 친다고 해결되지는 않습니다. 시스템을 충분히 이해하고 있어야만 마이그레이션을 이끌 수 있습니다.

평균값에서 벗어날 때. AI는 GitHub에 수백만 번쯤 올라온 문제들에는 탁월합니다. 하지만 그 평균값에서 멀어질수록 성능이 급격히 떨어집니다. 문서화되지 않은, 정말 까다로운 문제들—시니어 엔지니어의 연봉이 정당화되는 문제들—은 여전히 깊은 이해를 요구합니다.

시장이 조정될 때. 2022년 이후 주니어 개발자 고용이 20% 감소한 건 우연이 아닙니다. AI 없이는 제대로 ship 할 수 없는 엔지니어들은, 이미 “전문성의 가치”가 재평가되고 있는 노동 시장으로 들어가고 있습니다.

AI를 공부 대신 요령 피우는 데 써버리면, 눈앞의 편한 하루를 위해 앞으로의 생존력을 싸게 넘겨버리는 셈입니다.

문제는 “AI를 쓰느냐 마느냐”가 아니라, “어떻게 프롬프트하느냐”에 있다

좋은 소식도 있습니다. 인지 부채를 쌓게 만드는 바로 그 도구들이, 반대로 더 날카로운 엔지니어를 만드는 데도 쓸 수 있습니다. 차이는, 그 도구에게 무엇을 요구하느냐에 있습니다.

질문하기 전에 스스로 가설을 세우세요. 수정 요청을 보내기 전에, 이 문제가 뭐라고 생각하는지 두세 줄 정도로 적어보세요. 모델의 답을 당신 가설을 검증하는 데 쓰는 것이지, 가설을 통째로 교체하는 데 쓰지 마세요.

코드보다 먼저 설명을 요구하세요. 낯선 영역에 들어갔다면, 첫 번째 프롬프트는 이런 식이어야 합니다. “이게 어떻게 동작하는지, 어떤 대안들이 있는지, 각각의 트레이드오프는 무엇인지 설명해줘.” 개념이 잡힌 뒤에야 코드를 요청하세요.

한계에 부딪혔을 땐 학습 모드를 켜세요. Claude에는 Learning Mode가 있고, ChatGPT에는 Study Mode가 있습니다. Gemini에는 Guided Learning이 있습니다. 느리게 느껴질 겁니다. 바로 그 느림이 핵심입니다.

AI 출력물을 주니어 엔지니어의 PR이라고 생각하세요. 코드를 읽고, 비판하고, 반론을 제기해보세요. 테스트만 통과했다고 그냥 머지하나요? 그렇지 않다면, 여기서도 똑같이 굴지 마세요.

가끔은 직접 손으로 다시 유도해 보세요. 모델이 작성해 준 코드 일부를 골라, 아무 도움 없이 처음부터 다시 만들어 보세요. 이건 당신이 조용히 잃어버린 것이 얼마나 되는지 알려주는 캘리브레이션 체크입니다.

모델이 방금 한 일을 당신에게 가르치게 하세요. 멋진 함수를 만들어 줬다면, 어떤 개념을 사용했고 그 설계 결정을 이해하려면 무엇을 읽어야 하는지 물어보세요. 프롬프트 한 줄만 더 써도, 그 세션에서 가져가는 것이 완전히 달라집니다.

이 어느 것도 거창한 변화는 아닙니다. 이미 쓰고 있는 같은 도구 안에서의 작은 ‘자세 변경’일 뿐입니다.

하나가 아니라, 두 개의 지표

저는 요즘 코딩 세션을 마칠 때마다 아주 단순한 질문을 던집니다. “오늘 나는 뭔가를 배웠는가, 아니면 그냥 티켓만 닫았는가?”

가끔은 솔직한 대답이 “그냥 이슈만 닫았네”일 때도 있습니다. 그건 괜찮습니다. 다만 그 답이 몇 달 내내 계속되고 있다면, 인지 부채가 조용히 쌓이고 있는 중일 겁니다.

Ship과 Learn은 서로 다른 두 개의 지표입니다. 매니저와 고객은 언제나 첫 번째 지표만 물을 겁니다. 두 번째 지표는 결국 당신 책임입니다.

저는 “배포할 수 있었던 것의 80%만 배포하더라도, 배워야 했던 것의 100%를 배우는 편”을 택하겠습니다. 그 반대 전략을 택했을 때와는, 몇 년이 지나면 완전히 다른 타입의 엔지니어가 만들어집니다.

AI 사용과 학습 중 하나만 고를 필요는 없습니다. 다만 둘 다를 해내는 워크플로를 ‘의식적으로’ 골라야 합니다. 기본 설정은 절대 그 선택을 대신해주지 않습니다. 도구들은 준비되어 있습니다. 선택은 당신 몫입니다. 그리고, 지금 막 AI에게 넘기려고 했던 그 지루한 태스크가 바로 시작하기 좋은 지점입니다.