AI 학습 지름길이 도제식 교육의 부채가 될 수 있는 이유

AI는 이제 많은 개발자들이 과거에 Google, Stack Overflow, 문서(docs), 팀원의 Slack DM, 그리고 때로는 절박한 순간에 Confluence 내부의 검색창에 입력하곤 했던 질문들에 대한 해답이 되었습니다.

이것은 진보입니다. 또한, 분명히 함정이기도 합니다. 소프트웨어 분야의 대부분의 유용한 것들은 상자 안에 무료 함정을 포함하여 제공됩니다.

AI 보조 학습에 대한 Stack Overflow의 2026년 동향(pulse) 수치는 엔지니어링 리더들이 즉각적으로 공포 슬라이드를 만들지 않으면서도 주의를 기울여야 할 정도의 수치를 보여줍니다. 더 많은 개발자들이 학습을 위해 AI를 사용하고 있습니다. 일상적인 업무에서의 AI 사용량이 증가했습니다. 경력 초기 단계의 개발자들은 AI를 가장 먼저 찾을 가능성이 더 높습니다. 동시에, 신뢰(trust)는 여전히 주요 장벽이며, 거의 아무도 AI를 단독으로 사용하지 않습니다.

이 마지막 세부 사항이 중요합니다.

AI는 유일한 정착지가 아니라, 첫 번째 정착지가 되어가고 있습니다. 아직은 말이죠.

developer asking ai one innocent question before lunch

위험은 개발자들이 학습을 위해 AI를 사용하는 것이 아닙니다. 그들은 사용할 것이고, 이미 사용하고 있습니다. 위험은 기업들이 더 빠른 답변을 더 강력한 엔지니어와 혼동하는 것입니다.

이 둘은 서로 다른 것입니다.

속도는 이해와 같지 않다

소프트웨어를 배우는 것은 항상 약간 짜증 나는 물리적 과정을 동반해 왔습니다.

문서(docs)를 읽습니다. 문서를 오해합니다. 예제를 시도합니다. 버전이 달라서 실패합니다. 에러를 조사합니다. 2021년의 GitHub issue를 발견합니다. alex라는 이름의 누군가가 공식 문서에 있었어야 할 댓글에 실제 동작 방식을 설명해 놓았습니다. 다시 테스트합니다. 근처의 무언가를 망가뜨립니다. 마침내 개인적인 고통을 겪고 나서야 그 추상화(abstraction)를 이해하게 됩니다.

이것은 낭만적인 것이 아닙니다. 고결한 고난도 아닙니다. 그것은 단지 많은 엔지니어링 판단(engineering judgment)이 형성되는 방식일 뿐입니다.

AI는 그 루프(loop)를 압축합니다.

Kubernetes readiness probe(준비성 프로브)가 왜 실패하는지 모델에게 물어보면, 10초 안에 꽤 괜찮은 체크리스트를 제공할 수도 있습니다. 결제 재시도를 위한 멱등성(idempotency)을 어떻게 구현하는지 물어보면, 멱등성 키(idempotency key), 내구성이 있는 저장소(durable storage), 충돌 동작(conflict behavior), 재시도 윈도우(retry window), 제공자 타임아웃(provider timeouts), 관찰 가능성(observability)과 같은 구조를 그려줄 수도 있습니다. 그것은 진정으로 유용합니다.

위험은 그 답변이 마치 '학습'처럼 느껴질 때 시작되지만, 개발자가 그 답변에 반박하는 데 필요한 내부 모델(internal model)을 아직 구축하지 못했을 때 발생합니다.

그 내부 모델이 중요한 부분입니다.

그것이 여러분으로 하여금 다음과 같이 말할 수 있게 해줍니다:

"이 조언은 토이 앱(toy app)에는 괜찮지만, 우리의 트랜잭션 흐름(transaction flow)에는 맞지 않습니다."
"이 캐시 무효화(cache invalidation) 전략은 멀티 리전 쓰기(multi-region writes)를 무시하고 있습니다."
"이 마이그레이션 계획은 우리가 허용할 수 없는 다운타임(downtime)을 가정하고 있습니다."
"이 생성된 테스트는 모크(mock)가 작동한다는 것을 증명할 뿐입니다. 모크에게 축하를 전하죠."

그것이 없다면, AI는 답변 자판기가 됩니다. 매우 정중하고, 매우 빠르며, 가끔은 매우 틀립니다. 마치 에스프레소를 세 잔 마시고 운영 환경(production context)에 대한 정보가 전혀 없는 시니어 엔지니어처럼 말이죠.

도제식 교육(apprenticeship)은 대부분 검증하는 법을 배우는 과정이다

과거 주니어 개발자의 경로는 단순히 코드를 작성하는 것만이 아니었습니다.

그것은 어떤 질문이 중요한지를 배우는 과정이었습니다.

이 에러는 왜 발생하는가? 무엇이 변했는가? 시스템이 보장하는 것은 무엇인가? 동시 쓰기(concurrent writes) 상황에서 데이터베이스는 어떻게 동작하는가? 외부 API가 돈을 가져간 후 응답을 보내기 전에 타임아웃이 발생하면 어떻게 되는가? 고객들은 화가 나 있는데 왜 대시보드는 초록색인가? 누군가 "그냥 크론 잡(cron job)을 추가하자"라고 말했을 때 왜 시니어 엔지니어는 한숨을 쉬었는가?

이러한 질문들은 튜토리얼에 항상 적혀 있는 것이 아닙니다. 그것은 코드 리뷰, 장애(incidents), 페어링 세션(pairing sessions), 디버깅 세션, 그리고 여러분이 만든 첫 번째 우아한 추상화(abstraction)가 실제 고객의 워크플로우(workflow)와 맞닥뜨려 즉시 매니저를 불러달라고 요구하는 그 끔찍한 순간으로부터 얻어지는 것입니다.

[

when the generated solution meets production context]

AI는 주니어 개발자가 컨텍스트(context)를 더 빨리 파악하도록 도울 수 있습니다. 이것은 좋은 일입니다.

하지만 만약 AI가 도제식 교육 과정(apprenticeship loop)을 대체하게 된다면, 팀들은 '도제식 부채(apprenticeship debt)'를 만들 위험이 있습니다.

여기서 말하는 도제식 부채란, 개발자가 도움을 받아 생산해낼 수 있는 결과물과 그들이 실제로 6개월 후에 설명하고 디버깅하며 유지보수하고 안전하게 변경할 수 있는 능력 사이의 격차를 의미합니다.

이는 인지적 부채(cognitive debt)와 유사하지만, 커리어 개발 측면의 냄새가 납니다. 코드는 작동할 수 있습니다. 풀 리퀘스트(pull request)는 통과할 수도 있습니다. 개발자는 생산적이라고 느낄 것입니다. 팀은 한동안 더 빠르게 배포할 수도 있습니다.

그러다가 기묘한 버그가 나타납니다.

이제 누군가가 '왜' 그런지 이해해야 합니다.

만약 팀이 학습 과정(learning loop)을 건너뛰었다면, 그 '왜'라는 부분이 빠져버린 것입니다. 그것은 구축되어야 할 바로 그 순간에 외부로 아웃소싱된 셈입니다.

이것은 AI 반대 논리가 아닙니다

저는

그것은 레퍼런스(references)를 찾아보라는 의미입니다. 공식 문서(official docs)를 읽는 것. 명령어를 직접 실행해 보는 것. 테스트 코드를 스스로 작성하는 것. 엣지 케이스(edge cases)를 확인하는 것. 두 가지 설명을 비교하는 것. 첫 번째 답변이 왜 틀렸을 수도 있는지 질문하는 것. 모델이 스스로 가설(assumptions)을 명시하도록 강제하는 것. 문서화가 지나치게 낙관적일 때 소스 코드(source code)를 들여다보는 것 말입니다.

이것은 더 느리게 들립니다.

좋습니다.

학습은 흔적을 남겨야 하기 때문입니다.

팀은 AI 학습 루프(learning loops)를 설계해야 합니다

만약 제가 오늘날 주니어 엔지니어들을 관리하는 매니저라면, AI를 금지하지는 않을 것입니다. 그것은 보여주기식 행위(theater)일 뿐입니다. 그들은 여전히 AI를 사용할 것이고, 다만 이제는 더 정직하지 못한 방식으로 사용할 것입니다.

대신 저는 학습 루프(learning loop)를 명시적으로 만들 것입니다.

예를 들면 다음과 같습니다:

AI를 사용하여 첫 번째 설명을 생성하되, 이를 확인해 줄 수 있는 문서나 소스(source)를 링크할 것.
코드 리뷰(code review) 시, "AI가 이걸 작성했나요?"라고 묻는 대신 "수동으로 무엇을 검증했나요?"라고 물을 것.
까다로운 변경 사항의 경우, 단순히 차이점(diff)만 제출하는 것이 아니라 시스템 동작을 설명하는 짧은 노트를 요구할 것.
주니어와 시니어를 디버깅(debugging) 시에 페어링할 것. 단순히 구현(implementation)만을 위해서가 아니라.
장애 사후 보고서(post-incident writeups)의 작성 권한을 순환시켜, 사람들이 시스템이 어떻게 실패하는지 배우게 할 것.
"모델에게 물어봤는데 이렇게 말했어요..."라는 말을 조사의 끝이 아닌 조사의 시작으로 취급할 것.

목표는 재미를 위해 사람들의 속도를 늦추는 것이 아닙니다. 목표는 스스로 추론할 수 있는 속도보다 코드를 생성하는 속도가 더 빠른 엔지니어 세대가 탄생하는 것을 방지하는 것입니다.

이 문장은 다소 극적으로 들릴 수 있지만, 모든 엔지니어링 조직은 이미 이 문제의 축소판을 가지고 있습니다. 아무도 이해하지 못하는 라이브러리. 아무도 읽어본 적 없는 템플릿에서 생성된 서비스. 모두가 사용하지만 아무도 안전하게 수정할 수 없는 Terraform 모듈. 다섯 개의 패널이 있지만 소유자가 아무도 없는 대시보드 같은 것들 말입니다.

AI는 개발자의 속도로 그러한 격차(gaps)를 더 쉽게 만들 뿐입니다.

최고의 주니어는 더 나은 회의론자가 될 것입니다

좋은 소식은 AI가 호기심 많은 개발자들을 더 강하게 만들 수 있다는 점입니다.

AI를 사용하여 더 나은 질문을 던지고, 설명을 비교하며, 작은 실험을 구축하고, 생소한 코드를 읽는 주니어는 매우 빠르게 성장할 수 있습니다. 모델은 인내심 있는 튜터 (tutor)가 될 수 있습니다. 스택 트레이스 (stack trace)를 열 가지 다른 방식으로 설명할 수도 있고, 무서운 빈 페이지를 논의 가능한 무언가로 바꿔줄 수도 있습니다.

그것은 가치 있는 일입니다.

하지만 최고의 주니어는 답변을 가장 빨리 받아들이는 사람이 아닙니다.

그들은 답변에 의문을 제기하는 법을 배우는 사람들일 것입니다.

그들은 다음과 같이 질문할 것입니다:

여기에 숨겨진 가정 (assumption)은 무엇인가?
무엇이 이 솔루션을 망가뜨릴 것인가?
이것이 작동한다는 것을 어떻게 증명할 것인가?
공식 문서 (official source)에서는 뭐라고 말하는가?
실제 운영 환경의 장애 (production incident)가 이 답변이 숨기고 있는 무엇을 가르쳐 줄 것인가?

이것이 새로운 도제식 교육의 근육입니다.

모든 것을 손으로 직접 타이핑하는 것이 아닙니다. 2016년의 Stack Overflow 검색이 신성한 의식이었던 것처럼 행동하는 것도 아닙니다. 우리가 고통을 겪어야 했기에 그 고난을 숭배하는 것도 아닙니다.

그저 기계가 허세를 부리고 있을 때를 알아챌 수 있을 만큼의 현실을 배우는 것입니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위한 20달러(USD)를 원하신다면, 이 링크를 사용하세요.

Insights

AI 학습 지름길이 도제식 교육의 부채가 될 수 있는 이유

요약

핵심 포인트