생산성이 올라갈수록 이상하게도 개발자가 약해진다
Claude Code 앞에 앉아서 20분 만에 동작하는 피처를 만들어냈을 때, 우리는 본능적으로 '내가 더 잘하게 됐다'고 느낀다. 그 느낌은 틀렸다. dev.to의 AI Won't Make You a Better Developer는 이 감각의 정체를 날카롭게 짚는다. 나아진 건 당신의 산출물이지, 당신이 아니다. 속도는 기술이 아니고, 결과물은 이해가 아니다.
이 문장이 불편하게 느껴진다면, 그게 정확한 반응이다. AI-First 팀을 만들면서 내가 가장 자주 마주치는 착각이 바로 여기 있다. 팀원들의 커밋 수가 늘고, PR 사이클이 짧아지고, 스프린트 완료율이 오른다. 지표는 좋아 보인다. 그런데 어느 순간 팀에서 "왜 이렇게 짰지?"라는 질문에 아무도 대답을 못 한다.
AI는 '좋은 것'이 아니라 '흔한 것'을 안다
핵심은 여기에 있다. LLM은 인터넷에 존재하는 코드의 평균값을 학습했다. 질문을 던지면 분포의 중앙값, 즉 '가장 흔한 답'이 돌아온다. 흔한 코드는 대부분의 경우 나쁘지 않다. 컴파일되고, 테스트를 통과하고, 다른 코드들과 비슷하게 생겼다. 문제는 좋은 코드가 거의 언제나 '흔하지 않은' 코드라는 점이다. 특정 도메인을 깊이 이해한 누군가가, 평균이 틀리는 지점을 알기 때문에 의도적으로 벗어난 결과물이 좋은 코드다. AI는 그 판단을 내릴 수 없다. 도메인을 모르기 때문이다.
더 위험한 건 팀원이 '흔한 것'과 '좋은 것'을 구분하지 못할 때다. 코드가 돌아가고, 리뷰어도 별말이 없고, 비슷한 패턴이 코드베이스 전체에 깔려 있으면—그게 좋은 거라고 믿게 된다. AI가 흔한 것을 계속 주입하는 동안, 팀의 품질 기준선이 조용히 흔한 것으로 수렴한다.
Ira Glass의 갭, 그리고 AI가 그것을 숨기는 방식
AI Won't Make You a Better Developer가 인용하는 Ira Glass의 '갭' 개념이 여기서 중요해진다. 성장 초기에는 취향이 실력보다 앞선다. 내 결과물이 내가 존경하는 것보다 못하다는 걸 알기 때문에 불편하고, 그 불편이 반복 훈련의 동력이 된다. 실수하고, 망가뜨리고, 이틀 동안 버그를 추적하고 나서야 비로소 '이해했다고 착각했던 것'을 실제로 이해하게 된다. 그 마찰이 학습이었다.
AI는 이 갭을 닫지 않는다. 숨긴다. 취향이 '괜찮다'고 인식할 수준의 결과물을 즉시 만들어내지만, 그걸 만들어낼 실력은 여전히 없다. 불편이 사라지니 반복 훈련도 멈춘다. 2년 뒤 복잡한 문제를 혼자 해결해야 할 버전의 그 개발자는, 그 2년 동안 자라지 못했다.
워크플로우 통합은 계속 깊어지고 있다
아이러니하게도, 도구는 점점 더 깊숙이 파고든다. 3 MCP Servers I Actually Use Daily는 Filesystem, GitHub, PostgreSQL 세 가지 MCP 서버를 Claude Desktop에 연결해 실제 개발 워크플로우를 직접 통합하는 방식을 보여준다. 프로젝트 파일을 직접 읽고, PR 변경 이력을 요약하고, DB 쿼리를 대화 안에서 실행한다. 설정은 각각 2분이면 충분하다.
이런 통합은 실제로 강력하다. 나도 비슷한 워크플로우를 팀에서 쓴다. 반복 작업의 마찰을 줄이고, 컨텍스트 스위칭 비용을 낮추는 효과는 명확하다. 하지만 바로 이 지점이 문제다. 도구가 강력해질수록, 개발자가 직접 해결해야 할 영역이 줄어든다. 그리고 그 줄어든 영역이 바로 성장이 일어나던 곳이다.
AI Engineer World's Fair가 보여주는 역할의 분화
AI Engineer World's Fair의 현장 보고는 다른 각도에서 이 문제를 조명한다. 실용적인 에이전트 워크플로우를 다루는 세션과 커널 최적화·강화학습을 파고드는 세션이 같은 컨퍼런스 안에 공존한다. 'AI 엔지니어'라는 타이틀 아래 전혀 다른 일을 하는 사람들이 한 자리에 앉아 있다. 이 풍경은 역할 경계가 빠르게 재편되고 있다는 신호다.
도구를 쓰는 사람과 도구를 이해하는 사람, 그리고 도구가 틀렸을 때 그걸 알아보는 사람—이 세 역할은 갈수록 명확하게 분리될 것이다. 세 번째 역할이 가장 희소해지고, 가장 가치 있어질 것이다. 그리고 그 역할은 AI를 많이 써서 만들어지지 않는다.
팀이 직접 설계해야 하는 성장 구조
그렇다면 AI-First 팀 리드로서 내가 실제로 하고 있는 것은 무엇인가. 도구 도입을 막는 게 아니다. 반대로, 도구를 전략적으로 배치한다.
첫째, 이해 없는 산출물은 팀 자산이 아니다는 규칙을 명시적으로 세운다. AI가 작성한 코드는 반드시 작성자가 설명할 수 있어야 한다. "왜 이 구조인가?"에 대답하지 못하면 코드는 머지되지 않는다. 코드 리뷰의 기준을 '동작하는가'에서 '설명할 수 있는가'로 바꾼다.
둘째, 학습 중인 영역과 이미 아는 영역을 구분한다. 이미 완전히 이해한 영역에서는 AI로 속도를 최대화한다. 아직 학습 중인 영역에서는 의도적으로 AI를 늦게 꺼낸다. 마찰이 사라지기 전에, 그 마찰에서 뭔가를 가져가도록 한다.
셋째, 채팅창을 열기 전에 생각하는 습관을 팀 문화로 만든다. DDD, Clean Architecture, SOLID—이것들을 규칙이 아니라 '기계한테 넘기기 전에 문제를 정직하게 보는 방법'으로 프레임한다. 증폭기는 입력의 품질을 바꾸지 않는다. 명확하지 않은 생각을 넣으면, 빠르고 아름답고 테스트된 혼란이 나온다.
도구를 설계할 때, 성장 구조도 함께 설계하라
AI 도구의 ROI를 속도로만 측정하면, 팀은 분기 안에 빨라지고 2년 뒤에 약해진다. 진짜 질문은 이것이다: AI 도구를 도입한 다음, 팀원들의 실력이 어떻게 자라도록 구조를 만들었는가?
이 질문에 답이 없으면, 지금 쌓고 있는 속도는 나중에 해결하기 어려운 역량 부채가 된다. 도구를 팀에 넣는 것과 팀이 도구를 통해 성장하도록 설계하는 것은 완전히 다른 일이다. 전자는 쉽다. 후자가 리드의 일이다.