스택 트레이스를 읽지 않는 주니어 개발자

AI가 우리 신입 개발자를 더 나쁘게 만든 것이 아니다. 그들을 미완성 상태로 만들었고, 아무도 프로덕션 환경에서 알아차리지 못했다.

몇 달 전, 제 팀의 한 주니어 개발자가 목요일 늦은 시간에 저에게 메시지를 보냈습니다.

"API가 계속 500 에러를 반환해요. AI한테 네 번이나 물어봤어요. 고칠 때마다 다른 게 망가지고요."

저는 그에게 다가가서 한 가지 질문을 했습니다.

"트레이스백(traceback)이 뭐라고 말해?”"

그는 잠시 저를 쳐다보았습니다. 그리고 빨간 글씨로 된 40줄을 스크롤했습니다. 그는 그것을 복사해서 채팅창에 네 번이나 붙여 넣었지만, 실제로 읽어본 적은 없었습니다.

답변은 맨 아래에서 세 줄 떨어진 곳에 있었습니다. 시리얼라이저(serializer)가 예상했지만 최근 마이그레이션(migration)으로 이름이 바뀐 필드에 대한 KeyError였습니다.

우리는 2분 만에 그것을 고쳤습니다.

그는 게으르지 않았고, 부주의하지도 않았습니다. 그는 그해 우리가 채용한 사람 중 가장 뛰어난 인재 중 한 명이었고, 첫 3개월 동안 제가 첫 1년 동안 달성한 것보다 더 많은 기능을 배포했습니다.

하지만 그는 스택 트레이스를 제대로 읽어본 적이 없었습니다. 단 한 번도요.

그것은 어떤 스프린트 리포트(sprint report)로도 보여줄 수 없는 문제가 있다는 것을 깨달았던 밤이었습니다.

모두가 찬양하는 속도

지금 우리 업계가 이야기하고 있는 이야기가 여기에 있습니다.

AI는 주니어 개발자를 첫날부터 생산적으로 만듭니다. 신입과 미드 레벨 엔지니어 간의 격차가 줄어들고 있습니다. 신규 채용 인력은 티켓을 더 빨리 닫고, 풀 리퀘스트(pull request)를 더 많이 열며, 손이 덜 갑니다.

그리고 서류상으로는 사실입니다. 저는 제 팀에서도 그것을 목격했습니다.

하지만 그 아래에는 두 번째 이야기가 있고, 이것이 여러분 커리어의 다음 10년을 위해 중요한 이야기입니다.

수십 년 동안, 산출량(output)과 이해도(understanding)는 함께 성장해 왔습니다. 요청(requests), 모델(models), 쿼리셋(querysets)이 어떻게 함께 작동하는지 먼저 배우지 않고서는 작동하는 Django 뷰를 배포할 수 없었습니다. 그 과정은 느렸지만, 무언가를 남겼습니다.

이제 이 둘은 분리되었습니다. 주니어는 예전에는 이해도와 함께 왔던 것을 구축하지 않으면서 시니어처럼 보이는 산출물을 만들어낼 수 있습니다.

저는 이것을 **공허한 속도(Hollow Velocity)**라고 부르기 시작했습니다.

허위 속도(Hollow Velocity): 경험처럼 보이는 배포 속도이지만, 그 경험이 구축했던 정신적 모델은 없는 상태를 의미합니다.

스프린트 리뷰에서는 훌륭해 보입니다. AI가 자신감 있게 틀리는 순간에 균열이 생기고, 방에 있는 누구도 그 이유를 알아낼 방법을 모릅니다.

허위 속도의 세 가지 징후 (Three Signs of Hollow Velocity)

저는 이 개념의 이름을 붙인 후, 사방에서 이를 발견하기 시작했습니다. 단지 한 개발자에게서만 나타나는 것이 아니라 패턴 속에서 말입니다.

1. 구현은 할 수 있지만 설명할 수는 없다.

"여기서 왜 select_related를 사용했나요?"라고 물으면 침묵하거나 "AI가 제안해서요"라는 대답을 듣게 됩니다. 코드는 정확합니다. 하지만 그 추론 과정은 결코 그들의 것이 아니었습니다.

2. 범위를 좁히는 것이 아니라 재생성(regenerating)하며 디버깅한다.

경험 많은 엔지니어는 버그를 검색처럼 다룹니다: 가설을 세우고, 테스트하고, 문제를 반으로 나눕니다. 허위 속도의 개발자는 슬롯머신처럼 다룹니다. 오류 메시지를 붙여넣고(paste), 레버를 당기고, 새로운 답변을 시도하며 반복합니다.

3. AI가 자신감 있게 틀릴 때 얼어붙는다.

이것이 가장 위험한 부분입니다. 모델이 존재하지 않는 설정을 만들거나, 코드베이스의 오래된 패턴을 잘못 해석할 때, 내부 경고 시스템이 없습니다. "뭔가 이상한데"라고 말하는 본능적인 감각을 그들이 결코 구축해본 적이 없기 때문에 아무것도 어색하게 느껴지지 않습니다.

왜 이런 현상이 발생하는가 (Why It's Happening)

디버깅을 배우는 과정은 예전에는 다음과 같은 루프를 따랐습니다:

무언가가 고장 난다
오류 메시지를 읽는다
추측을 세운다
테스트한다
이전보다 조금 더 이해하게 된다

AI는 이 루프를 세 단계로 축소시킵니다:

오류 → 붙여넣기(paste) → 답변

제거된 단계(읽기, 추측하기, 테스트하기)가 바로 학습이 일어나던 지점입니다. 답변은 도착하지만, 이해도는 결코 구축되지 않습니다.

그리고 솔직히 말해서, 주니어 개발자의 잘못이 아닙니다.

우리(회사/시스템)가 이렇게 만들었습니다. 많은 팀들에서, 특히 클라이언트 마감일이 모든 것을 좌우하는 서비스 회사에서는, 우리는 사람들을 처리된 티켓 수와 전달된 기능으로 측정합니다. 스탠드업 미팅에서 속도를 칭찬합니다. 한 시간이 걸리더라도 왜 쿼리가 느렸는지 이해하기 위해 Django 소스 코드를 읽는 사람은 아무도 칭찬받지 못합니다.

우리는 결과물에만 보상을 했고, 이해는 자연스럽게 따라올 것이라고 가정했습니다. 하지만 그렇지 않았습니다.

팀에서 바꾼 것들

저는 AI 반대론자가 아닙니다. 저도 매일 사용하고, 제 팀원들도 마찬가지입니다. 이걸 금지하는 것은 무의미할 뿐만 아니라 약간 부정직합니다.

하지만 우리가 집중하는 것을 바꿨습니다.

'되돌려 설명하기(explain it back)' 규칙. 코드 리뷰 시, 사소하지 않은 변경 사항은 PR을 연 사람이 두세 문장으로 설명할 수 있어야 합니다. 완벽할 필요는 없습니다. 그냥 솔직하게요. 만약 설명할 수 없다면 병합(merging) 전에 함께 검토합니다.
프롬프트하기 전에 읽기(Read before you prompt). 무언가 문제가 생겼을 때, 처음 10분은 트레이스백(traceback), 로그, 그리고 코드를 살펴보는 데 사용하세요. 하나의 추측을 적어보세요. 그런 다음 AI에게 물어보고, 그 답변과 자신의 추측을 비교해 보세요.
주간 디버깅 세션. 일주일에 한 번씩, 누군가 우리 코드베이스의 실제 버그를 공유하고 그것을 어떻게 찾았는지 과정을 설명합니다. 수정하는 방법은 중요하지 않습니다. 찾는 과정이 중요합니다.
일대일 면담에서 다른 질문하기. '무엇을 배포했니?' 대신, '이번 주에 무엇이 고장 났고, 그것이 너에게 무엇을 가르쳐줬니?'라고 질문합니다.

이 모든 것이 우리를 크게 느리게 만들지는 않습니다. 단지 속도가 기반 위에서 이루어지고 있는지 확인시켜 줄 뿐입니다.

이 글을 읽는 주니어 개발자라면

당신은 뒤처진 것이 아닙니다. 당신은 누구도 전에 겪지 않았던 이상한 순간에 있습니다. 제가 당신이라면 이렇게 할 것입니다:

모든 트레이스백의 마지막 세 줄부터 먼저 읽으세요. 대부분의 경우, 답은 이미 그곳에 있습니다.
AI에게 물어보기 전에 자신의 추측을 적으세요. 비록 틀리더라도, 의도적으로 틀리는 것이 배우는 방법입니다.
수정하는 것뿐만 아니라 설명하는 데 AI를 사용하세요. '이것이 왜 실패하나요?'라는 질문은 '이것을 고쳐줘'보다 더 많이 가르쳐줍니다.
도움 없이 일주일에 작은 것을 하나 만드세요. 뷰(view), 쿼리(query), 관리 명령어(management command) 같은 것들입니다. 의도적으로 마찰(friction)을 느껴보세요.
소스 코드를 읽으세요. Django의 코드는 공개되어 있습니다. 무언가가 당신을 놀라게 할 때, 그것을 열어보고 살펴보세요.

목표는 AI 사용을 멈추는 것이 아닙니다. AI가 틀릴 때, 당신이 틀리지 않도록 하는 것입니다.

그 목요일 밤으로 돌아가서

그 주니어는 여전히 매일 AI를 사용합니다. 그는 그 어느 때보다 빠릅니다.

하지만 지난달에 그는 또다시 실패한 배포 건으로 저에게 메시지를 보냈습니다. 이번에는 내용이 달랐습니다.

"연결 풀(connection pool) 문제인 것 같아요. 트레이스백(traceback)을 보니 워커 타임아웃(worker timeout) 지점입니다. 제가 맞는지 확인해 주실 수 있나요?"

그가 옳았습니다.

그 메시지는 그가 배포한 어떤 기능보다 저를 더 행복하게 만들었습니다. 버그를 해결했기 때문이 아니라, 그가 먼저 그것을 읽었기 때문에 말입니다.

시니어(Seniority)는 코드를 얼마나 빨리 작성하는지에 관한 것이 아니었습니다. 코드가 이해되지 않을 때 무엇을 해야 하는지 아는 것에 관한 것이었습니다.

AI는 주니어들에게 속도를 줄 수 있습니다. 리드로서 우리의 역할은 그들이 나머지 것을 얻도록 보장하는 것입니다.

여러분 차례입니다

팀에서, 혹은 스스로에게 '할로 비벨로시티(Hollow Velocity)'를 느끼고 계신가요? 다른 리더분들께서 이 상황을 어떻게 대처하고 계신지 정말 듣고 싶습니다. 댓글에 알려주세요 👇