프로덕션은 잘 나간다. 배포 속도도 올랐다. 그런데 6개월 후, 팀에서 가장 오래된 주니어에게 낯선 에러를 혼자 디버깅하게 해보면 어떻게 될까. AI 없이, 혼자, 처음 보는 문제 앞에서. 이 질문에 자신 있게 답할 수 있는 팀 리드가 얼마나 될까.
이 불편한 질문의 핵심을 dev.to에 올라온 글 'Using AI Without Deskilling'이 정확하게 짚는다. 저자의 논점은 단순하다. AI가 개발자를 게으르게 만드는 게 문제가 아니라는 것. 진짜 문제는, AI가 실력을 키워주던 바로 그 어려움을 제거한다는 데 있다. 그리고 그걸 아무도 눈치채지 못한다. 결과물이 똑같이 나오기 때문에.
학습 연구에는 '바람직한 어려움(Desirable Difficulties)'이라는 개념이 있다. 1994년 Robert & Elizabeth Bjork가 명명한 이 개념의 핵심은 역설적이다. 학습 과정에서 속도를 늦추는 조건이 오히려 장기 기억과 전이 능력을 높인다. 반대로 매끄럽게 느껴지는 학습은 나중에 기억이 더 약하다. 쉽게 얻은 답은 뇌에 덜 새겨진다.
디버깅을 예로 들어보자. 가설을 세우고, 틀리고, 왜 틀렸는지 찾고, 더 나은 가설을 세우는 그 루프. 아무도 그걸 훈련이라고 설계하지 않았다. 그냥 일이 어려웠기 때문에 자연스럽게 생긴 루프였다. 문서를 읽을 때도 마찬가지다. 한 가지 답을 찾으러 들어갔다가 네 가지를 더 이해하고 나오는 그 경험. AI는 이 두 가지를 모두 줄인다. 없애는 게 아니라 빈도를 낮춘다. 그래서 더 위험하다.
누가 얼마나 잃는가
피해가 착지하는 지점은 경력에 따라 다르다.
주니어는 실력이 아예 형성되지 않는다. 비교할 '이전의 나'가 없기 때문에 본인도 모른다. 낯선 문제 앞에서야 비로소 드러나는데, 그때는 이미 늦다.
미드레벨은 기존 실력은 유지되지만 성장이 멈춘다. 아웃풋은 오르니 괜찮아 보인다. 격차는 루틴한 작업이 아니라 처음 보는 문제에서 벌어진다. 천천히, 조용히.
시니어는 자기 실력이 대체로 유지된다. 문제는 팀이다. 18개월 후 팀이 무엇을 할 수 있는지는 배포 메트릭에 나오지 않는다. 이게 팀 리드가 가장 먼저 경계해야 할 지점이다.
이건 개인의 규율 문제가 아니다. 구조적 문제다. 단기 아웃풋은 올라가고, 장기 역량이 떨어지는 변화는 관리자 눈에도, 개발자 본인 눈에도 보이지 않는다. 둘 다 그냥 '생산성이 올랐네'라고 읽는다.
어떤 마찰을 남길 것인가
그렇다고 AI를 덜 쓰라는 말이 아니다. 같은 글에서 저자가 제안하는 방법은 훨씬 구체적이다.
1단계: 이번 주에 무엇이 쉬워졌는지 나열한다. 보일러플레이트 작성, 문법 기억, 에러 원인 탐색, 설계 선택, 낯선 코드 읽기—추상적으로 말고, 실제 내 작업 기준으로.
2단계: 각 항목이 무엇을 가르쳐주고 있었는지 묻는다. 보일러플레이트는 가르치는 게 없다. 에러 원인을 찾는 과정은 많이 가르쳤다. 설계를 선택하는 과정은 가장 많이 가르쳤다. 솔직하게 구분한다.
3단계: 그중 두세 가지를 의도적으로 남긴다. 전부가 아니라 두세 가지. 작은 시간 제한을 두고, 반드시 혼자 끝까지 시도한 다음, AI의 답과 비교한다. 비교하는 순간이 실제 학습이 일어나는 순간이다.
핵심 조건이 하나 있다. 애써도 답에 닿지 못하면 아무것도 가르쳐주지 않는다. 루프가 완결돼야 한다. 혼자 시도하고, AI 답을 확인하고, 내 답과 비교하는 것—이 세 단계가 세트여야 한다.
LLM으로 잘 배우는 사람들은 뭐가 다른가
비슷한 시기에 Hacker News에서 443 포인트를 받으며 1위에 오른 글이 있다. 'How I Use LLMs to Learn Complex Topics'. 257개의 댓글을 분석한 후속 글이 그 핵심을 잘 정리했다.
가장 많이 지적된 실패 패턴은 하나다. LLM이 설명해주는 글을 읽는 것 자체가 너무 피곤하다. 유용한 정보가 노이즈에 묻힌다. LLM은 청중이 얼마나 알고 있는지 파악하지 못한 채 모든 것을 넣으려 한다.
그런데 댓글 스레드에서 '잘 된다'고 수렴한 패턴은 정반대였다. 설명을 읽는 게 아니라 질문을 받는 것. 여러 사람이 독립적으로 같은 방식을 묘사했다. LLM에게 내가 약한 영역의 질문을 만들게 하고, 답하고, 채점받고, 더 어려운 질문을 받는 루프. 이건 소크라테스 방식의 학습이다. LLM이 선생이 아니라 요구하는 튜터가 되는 순간.
또 하나는 '가르치기 위해 배우기'다. 해당 주제를 남에게 가르치는 것을 목표로 삼고, LLM에게 초안의 허점을 찌르게 하는 것. 이 방식이 효과적인 이유는 간단하다. 수동적 읽기를 능동적 인출로 전환하기 때문이다.
HN 스레드의 실질적 결론은 이것이다. LLM은 학습을 대체하지 않는다. 학습 주변의 마찰을 제거한다. 맞는 자료를 찾는 마찰, 새벽 2시에 막히는 마찰, 나를 테스트해줄 사람이 없는 마찰. 그 마찰은 제거해도 된다. 하지만 학습 자체는 여전히 본인 머릿속에서 일어나야 한다.
중국 개발자 커뮤니티가 던지는 다른 각도의 질문
흥미로운 대조가 있다. dev.to에 올라온 'What AI Anxiety Sounds Like in Chinese Developer Communities'라는 글에서 저자는 영어권과 중국 개발자 커뮤니티의 AI 불안이 결이 다르다고 말한다.
영어권: "AI가 내 실력을 쓸모없게 만들까?" 중국 커뮤니티(쥬진, V2EX, 위챗 그룹): "AI로 무장한 다른 사람이 나를 대체할까?"
이 차이는 단순한 뉘앙스 차이가 아니다. 전혀 다른 실천적 행동으로 이어진다. 중국 커뮤니티에서 AI 불안은 대체로 도구 FOMO로 표출된다. "어떤 모델 쓰냐?" "Tongyi Lingma 써봤냐?" "Cursor 유료 쓸 가치 있냐?" 논쟁이 아니라 빠른 채택이다.
한 스레드에서 어떤 개발자가 이렇게 물었다. "팀 전체가 AI를 쓰기 시작했다. 나는 거부했다. 실력을 지키고 싶어서. 지금 나는 팀에서 가장 느린 사람이 됐다. 내가 틀린 건가?" 최고 추천 댓글: "당신은 틀리지 않았다. 그냥 실직할 것이다."
이 답변은 냉혹하지만 팀 리드에게 중요한 신호를 담고 있다. AI 도구를 거부하는 것은 선택지가 아니다. 하지만 어떻게 쓸 것인가가 실력을 키우느냐 깎느냐를 결정한다. 그 설계를 팀 리드가 하지 않으면 아무도 하지 않는다.
팀 리드가 지금 당장 해야 할 설계
세 개의 소스가 공통으로 가리키는 결론은 하나다. AI가 제거하는 마찰이 전부 불필요한 마찰은 아니다. 어떤 마찰은 실력이 만들어지는 자리였다. 그걸 구분하고 보존하는 설계를 조직 차원에서 해야 한다.
팀 리드가 할 수 있는 구체적 액션 세 가지:
1. 온보딩에 '의도적 어려움' 구간을 설계한다. AI 없이 먼저 시도하고, AI 답과 비교하는 루프를 온보딩 태스크에 명시적으로 넣는다. 단순히 "AI 쓰지 마"가 아니라, "먼저 30분 혼자 해본 다음 AI 답 확인하고 비교해봐"라는 구조.
2. 코드 리뷰에서 '왜'를 묻는 문화를 유지한다. AI가 짠 코드도 리뷰어는 작성자에게 "왜 이 방식을 선택했냐"를 물어야 한다. 설명하지 못하면 이해한 게 아니다. 이 루프를 지키는 것이 팀 역량 보존의 가장 저비용 방법이다.
3. LLM을 '설명 소비' 도구가 아니라 '퀴즈 생성' 도구로 팀에 가르친다. HN 스레드의 결론을 팀 온보딩 자료에 넣는다. AI에게 설명을 받는 게 아니라, AI에게 질문을 받는 것. 이 패턴만 바꿔도 학습 효과가 달라진다.
모든 마찰이 지킬 가치가 있는 건 아니다. 보일러플레이트, 문법 검색, 단순 반복—이건 없애도 된다. 하지만 에러를 추적하는 과정, 설계를 선택하는 과정, 낯선 시스템을 이해하는 과정—이건 팀 역량의 토대다. 이 구분을 팀 리드가 의도적으로 설계하지 않으면, AI는 그냥 전부 제거한다. 효율적으로.