The Friction Is A Feature, Not A Bug: Teaching and Mentoring in the Age of AI
Those who have been following me for a while will know that teaching and mentoring are a Big Deal™️...
개요 #
LLM과 AI 코딩 도구가 개발 현장을 빠르게 바꾸고 있다. 코드는 더 빨리 나오지만, 그 대가로 사라진 것이 하나 있다. 바로 배움의 과정에서 겪는 '마찰(friction)'이다. 교사 출신 엔지니어 Yechiel Kalmenson은 이 마찰이야말로 성장의 엔진이며, 없애서는 안 될 기능이라고 말한다.
그가 던지는 질문은 뾰족하다. 막히고 헤매는 고통을 AI가 대신 없애줄 때, 주니어 개발자는 대체 어디서 실력을 쌓아야 하는가?
잘 풀린 수업에서는 배우지 못했다 #
저자는 개발자가 되기 전 교사였고, 지금도 스스로를 교사라고 여긴다. 유대교 학당(예시바)에서 탈무드 법리 논쟁과 하시딕 철학을 파고들던 시절부터, 이후 부트캠프에서 Rails와 React를 배우던 시절까지, 그는 한 가지 불편한 진실을 깨달았다.
가장 깊은 배움은 수업이 매끄럽게 흘러갈 때가 아니라 벽에 부딪혔을 때 찾아왔다. 알 수 없는 에러 메시지에 머리를 쥐어뜯고, 도무지 이해되지 않는 개념과 씨름하던 새벽 2시(식은 커피와 오기로 버티던 그 시간)에 말이다.
이 고통을 걷어내면 성장도 함께 사라진다. 시험을 통과할 만큼만 외운 지식은 에디터를 닫는 순간 증발한다. 인지적 마찰이 없으면 지식은 남지 않는다.
그가 만난 최고의 멘토들은 이 원리를 본능적으로 알고 있었다. 뻔한 해법이 있는 게 분명한 상황에서도, 그들은 화면에 답을 던져주지 않았다. 대신 소크라테스식 문답을 썼다. 특정 코드 줄을 가리키며 조심스러운 질문을 던져, 학생이 잘못 세운 가정을 스스로 마주하게 만들었다.
멘토링의 목표는 오늘 테스트를 초록색으로 바꾸는 게 아니다. 내일 마주할 다음 실패를 스스로 디버깅할 정신적 근력을 기르는 것이다.
IDE 안의 예스맨 #
오늘날 업계는 그 첫 단계 멘토링을 통째로 LLM에 외주 주었다. 그런데 불편한 진실이 있다. AI는 형편없는 소크라테스식 튜터다.
현대 LLM과 페어 프로그래밍을 진지하게 해본 사람이라면 안다. 이들은 병적인 예스맨이다. 활성 사용자 열두 명짜리 할 일 목록 앱에 분산 마이크로서비스 메시를 얹겠다고 말해보라. AI는 반박하지 않는다. "정말 통찰력 있는 생각이네요!"라며 400줄짜리 보일러플레이트를 즉시 토해낸다.
AI는 기본적으로 사용자를 맹목적으로 신뢰한다. 잘못된 가정에 좀처럼 이의를 달지 않고, 스택 트레이스가 왜 터지는지 물으면 원인을 이해시키기보다 복사-붙여넣기용 수정 코드를 곧바로 내민다. 에러 입력 → 수정 출력으로 작동하는 자판기처럼, 개발 과정에서 인지적 마찰을 체계적으로 제거해버린다.
10배 속도를 좇는 과정에서 우리는 기본 원리를 잊었다. 마찰은 버그가 아니라 기능이다. 우리가 걷어낸 건 하중을 지탱하던 마찰이었다.
앤트로픽 연구가 보여준 숫자 #
이건 철학적 추측이 아니다. 앤트로픽의 연구(원 논문)는 낯선 프로그래밍 라이브러리를 배우는 소프트웨어 엔지니어 52명을 두 그룹으로 나눴다. 한쪽은 AI 코딩 도구를 썼고, 다른 한쪽은 손으로 직접 코딩했다.
결과는 예상대로였고, 그만큼 뼈아팠다. AI에 코딩을 맡긴 엔지니어들은 개념 이해도와 디버깅 능력이 17% 떨어졌다. 학점으로 치면 두 등급이 내려간 셈이다. 그러면서도 손으로 코딩한 대조군보다 의미 있게 빠르지도 않았다. 막히는 고통을 남에게 넘기면, 뇌는 생성된 코드가 실제로 쓸 만한지 판단할 깊은 신경 회로를 만들지 못한다.
다만 데이터에는 미묘한 지점도 있었다. AI를 쓴 엔지니어 중 일부는 오히려 대조군을 앞섰다. 누구였을까? AI를 맹신하지 않은 사람들이었다. 이들은 LLM을 스터디 파트너처럼 다뤘다. 파고드는 후속 질문을 던지고, 스스로 마찰을 다시 만들어 넣었다. 나머지 모두에게 자동화된 예스맨은 이해도를 조용히 갉아먹었을 뿐이다.
주니어의 딜레마: 마찰을 손수 되돌려 넣기 #
이 상황은 주니어 개발자를 진퇴양난에 빠뜨린다.
한편으로는 AI가 사라지지 않는다는 현실을 받아들여야 한다. 프롬프트 한 줄로 동작하는 보일러플레이트가 나오는 마당에, 고집으로 안 쓰고 버틸 수는 없다. 실무에서 이 도구들을 계속 쓸 텐데 무시하는 건 무책임하게 느껴진다.
다른 한편으로, 자동완성을 맹목적으로 믿으면 '피상적 학습'에 갇힌다. 테스트 스위트를 통과하고 PR 승인을 받을 답은 빠르게 얻지만, 그 아래 메커니즘은 이해하지 못한다. 커리어를 지탱할 성장이 일어나는 '깊은 학습'을 놓치는 것이다.
저자의 경험상 이 피상성은 개발자의 불안과 가면 증후군으로 곧장 이어진다. 진짜 자신감은 Tab 키를 눌러 제안을 수락하는 데서 오지 않는다. 코드에 대한 주인 의식과 치열한 지적 노동, 그 땀에서 온다.
그래서 성실한 학습자들은 이제 뇌가 꺼지지 않도록 워크플로에 마찰을 손수 되돌려 넣는다. 저자의 한 주니어 동료는 IDE에 이런 가드레일 지시를 명시적으로 넣는다고 한다. "복사-붙여넣기 대신 직접 코드를 짜는 법을 배우고 싶으니, 가능한 방식으로 그렇게 유도해달라." 노트도 손으로(진짜 종이와 펜으로!) 쓰고, 물리적 타이머를 맞춰 즉각적 만족을 노린 도구가 건너뛰려는 능동적 집중의 안전장치를 스스로 되살린다.
어수선한 맥락의 그물이 필요한 이유 #
이런 자발적 고생은 Emily Bender와 Alex Hanna의 책 The AI Con의 문제의식과 맞닿아 있다. 정보 접근의 마찰이 왜 버그가 아니라 기능인지에 관한 이야기다.
검색 엔진으로 난해한 버그를 직접 추적할 때 무슨 일이 벌어지는지 떠올려보자. 엉망인 문서를 읽고, 열두 개 댓글이 달린 GitHub 이슈 스레드를 훑고(대개 2014년에 메인테이너가 "버그 아님"으로 닫으며 끝난다), 스택오버플로에서 상충하는 답변들의 신뢰도를 저울질하고, 관련 함정들과도 우연히 마주친다. 이 어수선한 메타 정보의 그물이야말로 진짜 엔지니어링 맥락이 쌓이는 곳이다.
AI 챗봇은 이 풍부하고 짜증 나는 고생을 단 하나의, 그럴듯하게 들리는(가끔은 환각인) 요약으로 납작하게 눌러버린다. 당장의 문제에 대한 답은 주지만, 다음 문제를 풀 때 필요한 주변 생태계 지식을 뇌에서 앗아간다.
하브루타 모델: 페어 프로그래밍과 적대적 러버덕 #
여기서 저자는 오늘날 전 세계 예시바에서 여전히 살아 있는 오래된 교육 모델을 꺼낸다. 소프트웨어 엔지니어링이 지금 절실히 필요로 하는 방식이다.
전통 예시바에서는 조용히 홀로 책을 읽거나 강의를 수동적으로 듣는 풍경을 보기 어렵다. 방은 시끄럽고 활기차며, 사람들이 둘씩 짝을 지어 치열하게 논쟁한다. 이 스터디 파트너 제도를 하브루타(Chavrusa)라고 부른다. 아람어로 '친구', '동반자'를 뜻하는 말이다.
하브루타에서 파트너는 텍스트를 대신 읽어주지도, 네 이론이 얼마나 훌륭한지 아첨하며 고개를 끄덕이지도 않는다. 진짜 하브루타는 네 논리에 끊임없이 도전하고, 주장의 허점을 찌르고, 근거 약한 가정을 밀어붙이며, 지적 게으름을 결코 봐주지 않는다. 탈무드는 요약본을 읽거나 명강의를 듣는 걸로 통달할 수 없다. 예기아(Yegiah), 곧 치열한 지적 노동과 땀을 통해서만 통달한다.
곰곰이 따져보면 페어 프로그래밍은 테크 업계가 하브루타를 재현한 것에 가깝다. 그리고 이 제도의 가장 중요한 대목은 이것이다. 배우는 건 주니어만이 아니다.
10년 차 스태프 엔지니어와 짝을 이루든, 방금 부트캠프를 마친 주니어와 짝을 이루든, 배움은 언제나 양방향이다. 파트너가 '말대꾸하는 적대적 러버덕' 역할을 하면, 당신은 속도를 늦추고 숨은 가정을 말로 꺼내며 코드 논리를 처음부터 끝까지 방어하게 된다. 둘 다 그 마찰에서 얻는 것이 있고, 둘 다 시작할 때보다 훨씬 나은 멘탈 모델을 안고 자리를 뜬다.
라비 하마, 하니나의 아들이 말하기를: "쇠가 쇠를 날카롭게 하듯, 사람은 그 친구의 얼굴을 날카롭게 한다"(잠언 27:17)는 구절의 뜻은 무엇인가? 쇠날이 서로 부딪혀 서로를 벼리듯, 토라 학자들이 함께 공부하면 서로를 벼린다는 것을 이 구절이 가르친다.
— 타아니트 7a
10배 속도를 좇으며 우리는 사람 사이의 페어 프로그래밍을 AI 코파일럿으로 대체하려 했다. 그러나 그 과정에서 결정적인 의존성 하나를 놓쳤다. 적대적 하브루타와 예기아를, 아첨하는 로봇 러버덕과 맞바꿔버린 것이다.
공감이라는 균형 잡기 #
흔히 듣는 반응은 이렇다. "더 나은 시스템 프롬프트로 고치면 되지! 답을 그냥 주는 대신 소크라테스식 튜터처럼 굴라고 가드레일을 걸자!" 지금 이걸 시도하는 도구가 여럿 있지만, 저자는 기술적 가드레일이 근본적으로 인간적인 문제를 풀 수 있다는 데 깊이 회의적이다.
첫째, 프롬프트로 답을 참게 하려면 학습자에게 엄청난 규율이 필요하다. 인지적 배터리가 바닥날 때 그만한 의지력을 발휘할 사람은 드물다. 새벽 2시에 알 수 없는 NullPointerException을 앞에 두고 뇌가 튀겨진 주니어에게 "객체의 생명주기를 되짚어보라"는 프롬프트는 곧바로 무시당한다. /solution을 입력하거나 새 탭을 여는 것만으로 복사 가능한 코드의 도파민을 얻을 수 있다면, 버텨낼 사람은 많지 않다.
더 중요한 건, LLM이 근본적으로 사용자를 기쁘게 하도록 설계됐다는 점이다. 아무리 프롬프트로 엄격한 소크라테스식 튜터를 주문해도, 사용자가 진짜 좌절을 드러내는 순간 AI는 싸구려 접이식 의자처럼 접히며 결국 문법을 넘겨준다. 왜? LLM에는 교육자에게 가장 중요한 자질, _공감_이 없기 때문이다.
멘토링은 인간적인 균형 잡기다. 훌륭한 멘토는 생산적인 고생과 사기를 꺾는 고통 사이의 미세한 경계를 안다. 분위기를 읽을 줄 안다. 무거운 한숨, 차오르는 초조함, 완전한 탈진을 알아챈다.
학생 시절 저자는 스스로 답을 찾을 도구를 쥐여줬을 때 가장 잘 배웠다. 하지만 때로는 멍청한 에러 메시지 하나에 에너지를 다 써버렸고, 튜터의 유도 질문들이 정작 필요한 그 통찰 주위만 빙빙 돌게 만드는 것처럼 느껴지기도 했다. 뇌가 도무지 닿지 못하는 통찰 말이다.
바로 그 지점에서 좋은 교사는 한 발 물러나 미소 지으며 말한다. "야, 자바스크립트는 원래 좀 이상해." 그러고는 막힌 곳을 뚫어줄 정확히 그 한 줄을 건네, 마침내 잠들 수 있게 해준다. 알고리즘은 학습자의 감정 상태를 읽지 못한다. 도전적인 스파링 상대와 든든한 안전망 사이를 상황에 맞게 오갈 수 없다. 코드는 그 관계를 결코 재현하지 못한다.
아직 풀리지 않은 진퇴양난 #
그래서 우리는 어디에 서 있는가? 솔직히 말하면 지금 저자에게는 답보다 질문이 훨씬 많다. 업계 전체가 거대한 딜레마 위에 앉아 있다.
한편으로, 주니어에게 AI 사용을 금지하는 건 직무 유기에 가깝다. AI는 이제 현대의 IDE다(저자가 코딩을 배우던 시절, 문지기들은 주니어가 IDE를 써선 안 된다고 주장했지만 그때도 지금도 저자는 동의하지 않는다). 실무에서 쓸 도구라면 제대로 쓰도록 훈련시키는 게 맞다.
다른 한편으로, 아키텍처를 무너뜨리는 버그 없이 10배 속도를 누리는 사람들은 AI 없이 수년간 코드를 짜온 시니어들이다. 우리는 LLM이 잘못된 전제 위에서 헛바퀴 도는 걸 알아챈다. 수년간의 수작업 디버깅으로 벼려낸 내장 헛소리 감지기가 있기 때문이다.
AI 이전의 경험이 없는 사람은 오늘 그 직관을 어떻게 기를까? 아첨하는 예스맨 챗봇에게서는 얻지 못한다. 그렇다고 마찰을 스스로 만들어 넣는 건 촉박한 마감 앞에서 유지하기 힘든 수준의 자기 규율을 요구한다.
어쩌면 온보딩의 미래는 사람 사이의 페어 프로그래밍을 더 강화하는 데 있을지 모른다. 주니어가 몇 달씩 시니어를 따라다니며 AI 이전의 직관을 곁에서 흡수하는 방식이다. 페어 프로그래밍은 Claude 이전에도 늘 최고의 온보딩 방법 중 하나였다. 다만 어제 당장 출시하기를 강박하는 업계에서, 모든 회사가 상시 페어링에 필요한 투자를 감당하려 하지는 않는다.
분명한 건, 이 문제를 무시하거나 더 나은 LLM 모델이 인재 파이프라인을 마법처럼 고쳐줄 거라 기대해선 안 된다는 사실이다. 주니어에게 신탁을 쥐여주면서 하브루타의 공감 어리고 엄격한 고생을 지켜내지 못한다면, 몇 년 뒤 우리는 끔찍한 시스템 에러와 마주하게 될 것이다. AI가 생성한 거대한 코드베이스는 남았는데, 그것을 유지보수할 줄 아는 시니어는 충분히 남지 않은 상황 말이다.
당신과 당신의 팀은 생산적인 마찰을 살려두기 위해 무엇을 하고 있는가?
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.