Addy Osmani블로그
배움만큼은 외주 주지 마라
지금 이 순간, AI가 코드를 짜주는 동안 배움을 건너뛰기란 너무 쉽다. 버그는 해결되지만, 당신의 이해는 제자리를 맴돈다. 우리는 미래의 역량을 지금의 속도와 조용히 맞바꾸고 있다. 어떤 도구도 우리에게 다르게 행동하라고 강요하지 않는다. 그 선택은 오직 당신 몫이다.
우리 대부분은 어느새 같은 루프에 안착해 있다. 스펙이나 에러 메시지를 붙여 넣으면, 모델이 수정안을 내놓는다. 증상은 사라진다. 배포가 완료된다. 그 루프 어딘가에서, 문제와 해답 사이에서 벌어지던 지저분한 씨름은 아예 사라져버린다.
필자는 이전에 인지적 항복(cognitive surrender)에 대해 쓴 적이 있다. AI 리뷰어의 판단이 어느새 당신 자신의 판단을 조용히 대체해버리는 그 순간 말이다. 지금 이야기하는 건 그 루프의 1인용 버전이다. 당신과 모델, 둘뿐이다. 모델이 더 빠르니, 이해력으로 경쟁하려는 시도는 스스로 포기하게 된다. 이런 소소한 상호작용이 수천 번 쌓이고 나면, AI 없이 혼자 만들어낼 수 있는 것들이 매주 조금씩 줄어든다. 그 어떤 순간도, 그날그날만 보면 문제처럼 느껴지지 않는다.
필자는 AI에 반대하지 않는다. 이 도구들을 매일 쓰고 있고, 지난 1년간 이전 5년을 합친 것보다 더 많은 결과물을 냈다. 하지만 우리가 AI를 쓰는 기본 방식은 오직 하나에만 최적화되어 있다. 바로 태스크를 끝내는 것. 이는 수십 년에 걸친 커리어 내내 AI를 제대로 이끌 수 있는 역량을 유지하는 것과는 완전히 다른 목표다.
연구들이 같은 결론을 향해 수렴하고 있다
지난 1년간 나온 여러 연구들이 대략 같은 지점에 도달했다.
Anthropic은 2026년 초 무작위 대조 실험을 진행했다. 엔지니어들이 새로운 Python 라이브러리를 학습하는 과정에서, 절반은 AI 도움을 받고 나머지 절반은 받지 않았다. 두 그룹 모두 태스크 완료 속도는 같았다. 그러나 사후 이해도 평가에서는 AI 그룹이 훨씬 저조한 점수를 받았다. AI 그룹 50% 대 비AI 그룹 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도 유사한 기능을 내놓았다. 그러나 실제 프로덕션 작업에서 이를 사용하는 사람은 거의 없다. 우리는 이런 기능을 슬그머니 "학생용"으로 분류해버렸고, 그것은 실수다. 대학교 2학년생이 React를 배우는 데 도움이 되는 기능은, 시니어 엔지니어가 Rust를 배울 때도 똑같이 작동한다. 단지 다시 초보자가 된 기분을 기꺼이 감수할 의지가 있어야 한다.
"AI가 할 수 있는데, 내가 굳이 이해해야 할 이유가 있나요?"
충분히 타당한 질문이다. 어떤 작업에서는 답이 이렇다. 그럴 필요 없다. 보일러플레이트나 연결 코드, 다시는 들여다볼 일 없는 임시 CI 스크립트라면 맡겨도 된다. YAML 문법을 외우는 데 드는 기회비용은 너무 크다.
하지만 실제 소프트웨어에서 완전한 위임은 몇 가지 특정 지점에서 반드시 무너진다.
무언가 고장났을 때. AI가 생성한 코드는 사람이 짠 코드와 똑같이 터진다. "에이전트가 작성한 코드입니다"라는 말은 디버깅에 아무 도움이 되지 않는다. 팀 내 누군가는 아키텍처를 이해하고 있어야 한다.
AI가 자신 있게 틀렸을 때. LLM은 환각을 일으킨다. 그럴듯해 보이는 잘못된 답변을 걸러낼 수 있는 유일한 방어막은, 그것을 알아챌 만한 충분한 전문성이다.
기반이 바뀔 때. 코드는 일시적이지만, 시스템은 지속된다. 프레임워크가 업데이트되거나 보안 검토에서 구조적 문제가 발견되면, 프롬프트를 다시 작성하는 것으로는 빠져나올 수 없다. 시스템을 충분히 이해해 마이그레이션을 이끌 수 있는 엔지니어가 필요하다.
평균에서 벗어날 때. AI는 GitHub에서 수백만 번 풀렸던 문제에 탁월하다. 중앙값에서 멀어질수록 성능은 나빠진다. 문서화되지 않은 난해한 문제들, 시니어 엔지니어의 연봉을 정당화하는 그 문제들은 여전히 깊은 이해를 요구한다.
시장이 재편될 때. 2022년 이후 주니어 개발자 채용이 20% 감소한 것은 우연이 아니다. AI가 있을 때만 결과물을 낼 수 있고 없이는 못하는 엔지니어들은, 전문성의 가치가 이미 재산정되고 있는 노동 시장에 뛰어드는 것이다.
AI를 배움을 건너뛰는 수단으로 쓴다면, 미래의 경쟁력을 조금 더 편한 오늘과 맞바꾸는 셈이다.
핵심은 AI를 쓰느냐 마느냐가 아니라, 어떻게 프롬프트를 쓰느냐다
좋은 소식이 있다. 인지적 부채를 만들어내는 바로 그 도구가, 더 날카로운 엔지니어를 만들어낼 수도 있다. 차이는 도구에게 무엇을 요구하느냐에 달려 있다.
질문하기 전에 먼저 가설을 세워라. 수정을 요청하기 전, 문제가 무엇이라고 생각하는지 두세 문장으로 적어보자. 모델의 답변은 자신의 이론을 대체하는 것이 아니라, 검증하는 데 사용하라.
코드보다 설명을 먼저 요청하라. 낯선 영역에서 첫 프롬프트는 "이게 어떻게 동작하는지, 어떤 대안이 있는지, 각각의 트레이드오프는 무엇인지 설명해줘" 같은 형태여야 한다. 개념을 파악한 다음에야 코드를 요청하라.
자신의 깊이를 벗어날 때는 Learning Mode를 켜라. Claude에는 Learning Mode가 있고, ChatGPT에는 Study Mode가, Gemini에는 Guided Learning이 있다. 느리게 느껴질 것이다. 그게 바로 핵심이다.
AI의 결과물을 주니어 엔지니어의 PR처럼 다뤄라. 읽고, 비판하고, 반박하라. 테스트가 통과됐다는 이유만으로 머지하겠는가? 그렇지 않다면, 여기서도 마찬가지다.
때로는 직접 손으로 재현해보라. 모델이 당신을 위해 작성한 코드 한 조각을 가져다가, 처음부터 스스로 다시 만들어보자. 자신도 모르게 얼마나 잃었는지 알 수 있는 교정 테스트다.
모델에게 방금 한 일을 가르쳐달라고 요청하라. 모델이 영리한 함수를 작성한 뒤, 거기에 어떤 개념이 쓰였는지, 그 설계 결정을 이해하려면 무엇을 읽어야 하는지 물어보자. 프롬프트 하나를 더 추가하면, 그 세션에서 가져가는 것이 달라진다.
이것들 중 거창한 것은 없다. 지금 이미 쓰고 있는 도구 안에서 태도를 조금 바꾸는 것이다.
하나가 아닌, 두 가지 지표
필자는 요즘 코딩 세션을 마칠 때마다 간단한 질문을 던지는 습관을 들이고 있다. 오늘 뭔가를 배웠는가, 아니면 그냥 티켓만 닫았는가?
솔직한 대답이 "그냥 이슈만 처리했다"일 때도 있고, 그건 괜찮다. 하지만 몇 달 내내 같은 대답이 나온다면, 인지적 부채가 수면 아래에서 쌓이고 있는 것이다.
'배포'와 '배움'은 별개의 지표다. 매니저도, 고객도 첫 번째 것만 묻는다. 두 번째는 당신 몫이다.
가능한 것의 80%를 배포하고 필요한 것의 100%를 배우는 편이, 그 반대보다 낫다고 생각한다. 몇 년이 지나면, 두 전략은 매우 다른 엔지니어를 만들어낸다.
AI 사용과 배움 사이에서 하나를 고를 필요는 없다. 다만 둘 다 가능한 워크플로를 의식적으로 선택해야 한다. 기본값은 그 선택을 대신해주지 않기 때문이다. 도구는 언제든 준비되어 있다. 막 위임하려던 그 지루한 태스크가, 시작하기 딱 좋은 지점이다.
더 읽어보기: Anthropic의 역량 형성 연구, MIT의 Your Brain on ChatGPT (arXiv 2506.08872), 시간 제약 상황에서의 LLM 활용에 관한 CHI 2026 논문, Stack Overflow의 AI vs Gen Z 보고서, 그리고 필자의 이전 글 이해도 부채와 인지적 항복.