코드는 나왔는데, 이해는 남지 않았다
Dev.to에 올라온 한 시니어 개발자의 고백은 불편하게 정확하다. 그는 지난 한 해 동안 수많은 앱을 만들었고, 그 코드 대부분을 직접 승인했다. 문제는 그 코드 중 상당 부분을 자기 자신에게도 설명할 수 없었다는 것이다. 테스트는 초록색이었고, diff는 그럴듯해 보였고, 그는 approve를 눌렀다. 40분 뒤 누군가 "왜 이 함수에 락이 필요해요?"라고 물으면, 처음 보는 코드처럼 다시 읽어야 했다. 어떤 의미에서 그건 실제로 처음 보는 코드였다.
이 이야기가 낯설지 않다면, 그건 당신 팀에도 같은 일이 벌어지고 있기 때문이다. 2025 Stack Overflow 설문에서 개발자 5명 중 1명이 AI 도구의 가장 큰 불만으로 "내 문제 해결 능력에 대한 자신감이 줄었다"를 꼽았다. 이 불안은 이미 충분히 보고되고 있다. 진단은 끝났다. 지금 우리에게 필요한 건 그다음 질문의 답이다.
썩는 건 타이핑이 아니라 판단이다
항공 연구가 이 문제를 가장 정확하게 설명한다. 자동화된 항공기를 오래 운항한 조종사들을 대상으로 한 연구(Casner et al., 2014)에서, 절차적 스킬—계기 스캔, 수동 조종—은 녹슬긴 했지만 대체로 유지됐다. 정작 무너진 건 인지 스킬이었다. 현재 항공기가 어디에 있는지 파악하는 상황 인식, 다음에 뭘 해야 하는지 추적하는 능력, 계기 고장을 감지하고 대응하는 능력. FAA는 이에 대응해 조종사들이 비행 시간의 대부분을 수동 조종으로 채울 것을 권고했다.
이걸 개발자로 바꿔 읽으면 섬뜩하다. 타이핑은 살아남는다. 머릿속 모델이 사라진다. 2024년 Brooke Macnamara 연구팀의 리뷰는 여기서 한 발 더 나간다. AI는 물리적 작업이 아니라 인지 작업을 흉내 내고, 인지 스킬은 물리적 스킬보다 빠르게 퇴화하기 때문에 AI가 유발하는 스킬 감퇴는 조종석에서 확인된 자동화 감퇴보다 더 심각할 수 있다고 결론짓는다. AI가 코드를 느리게 쓰게 만드는 게 아니다. 판단력을 키우는 반복 훈련을 조용히 가져가버리는 것이다.
그리고 아이러니하게도, 지금 개발자에게 남은 핵심 업무는 전부 그 인지 영역에 있다. 모델이 자신 있게 틀린 부분을 잡아내는 리뷰. 무엇을 만들지 판단하는 기획. 그럴듯한 답이 실제로는 틀렸을 때 알아채는 감각. 우리는 정작 보수를 받는 스킬을 만들어내던 반복 훈련을 자동화로 없애버린 셈이다.
당신은 이게 일어나고 있다는 걸 느낄 수 없다
이 문제를 더 불편하게 만드는 건 세 가지 독립적인 연구가 동시에 가리키는 지점이다. 당신은 구조적으로 이걸 스스로 감지할 수 없다.
첫째, Macnamara 연구팀은 그 메커니즘을 명확히 짚는다. 보통의 스킬 감퇴는 눈에 띈다. 일을 멈췄으니까. 하지만 AI가 유발하는 감퇴는 숨는다. 당신은 계속 배포했고, 계속 리뷰했고, 계속 티켓을 닫았다. 인지적 개입만 멈췄을 뿐이다. CI 배지가 초록색인 한, 아무 신호도 오지 않는다.
둘째, METR이 2025년에 진행한 무작위 대조 실험이 있다. 5년 이상 기여한 자신의 오픈소스 레포에서 246개의 실제 태스크를 수행한 숙련 개발자 16명이 대상이었다. 개발자들은 AI로 24% 빨라질 거라 예측했다. 작업 후 체감은 20% 빨라진 것 같았다. 실제 결과는 19% 느렸다. 자신이 가장 잘 아는 코드에서, 경험이 많을수록 더 느렸다. 자기 자신의 경험을 방금 끝내고도 정반대로 보고했다는 게 핵심이다.
셋째, 스톡홀름대·홍콩대 연구팀이 중국 중·고등학생 2만 6천여 명을 30개월 추적한 연구(The Economist 보도)는 이 패턴을 교육 현장에서 대규모로 실증했다. AI로 숙제를 한 학생들은 숙제 점수가 18% 올랐고 소요 시간은 64분에서 45분으로 줄었다. 그런데 6개월 뒤 월별 시험 점수는 20% 떨어졌고, 고입·대입에서는 18~24% 하락했다. 단, AI를 쓰면서도 충분히 시간을 들여 문제를 고민한 학생들에게는 손해가 크지 않았다. '얼마나 성찰적으로 활용했는가'가 결과를 갈랐다. 개발자도 다르지 않다.
diff를 다시 읽을수록 이해한다는 착각만 강해진다
인지과학에는 이 현상의 이름이 있다. 설명 깊이의 착각(Rozenblit & Keil, 2002). 사람들은 어떤 것이 어떻게 작동하는지 잘 안다고 자가 평가한다. 실제로 인과적 설명을 요청받으면 자기 평가를 급격히 낮춘다. 이 효과는 절차나 사실 지식보다 설명적 지식에서 훨씬 강하게 나타난다. 코드 리뷰가 요구하는 바로 그 종류의 이해에서 가장 심하다는 뜻이다.
Roediger & Karpicke(2006)의 테스팅 효과 연구는 한 걸음 더 나간다. 같은 자료를 반복해서 읽은 학생들은 자기 테스트를 한 학생들보다 더 자신 있어 했다. 1주일 뒤 실제 기억률은 40% 대 61%였다. 반복 독해는 이해 대신 자신감만 쌓는다. diff를 계속 읽다가 "괜찮아 보이네"라고 느끼는 순간이 정확히 그 구조다.
팀 리드가 설계해야 할 가드레일
문제는 진단됐다. 이제 설계다. 개인의 의지나 대시보드 기반 점수표는 답이 아니다. 외재적 보상은 행동을 앱에 붙여버리고, 앱을 닫는 순간 행동도 사라진다(CHI 2016, Lift/Coach.me 연구). 팀 리드가 구조로 풀어야 한다.
1. 가드레일을 환경에 내장하라. Dev.to의 AI 코드 리뷰 확장 전략 기고에서 Xebia의 Florian Buetow가 제안한 프레임워크는 명확하다. AI 생성 코드의 검증을 사람의 판단력에 의존하지 말고 환경 자체에 강제하라. Semgrep 룰로 금지 패턴을 코드화하고, 아키텍처 유닛 테스트로 의존성 위반을 사전 차단하고, stop hook으로 에이전트가 생성을 끝내는 즉시 테스트 스위트를 강제 실행하라. 실패 메시지는 곧바로 에이전트에게 피드백돼 스스로 수정하게 한다. 이렇게 하면 인간 리뷰어의 판단력이 낮아지더라도 기본 품질 바닥이 유지된다.
2. 스펙과 테스트를 앞으로 당겨라. AI는 모호한 명세 앞에서 5분 안에 의도에서 벗어난다. 작업의 어려운 부분이 파이프라인 앞으로 이동한다는 뜻이다. TDD와 Specification-Driven Development가 지금 AI-First 워크플로우에서 다시 주목받는 이유가 여기에 있다. 행동 테스트를 먼저 작성하면 AI가 빠르게 반복하면서도 사람의 의도에서 벗어날 수 없게 구조가 잡힌다. 명세 작성과 테스트 설계가 시니어 개발자의 핵심 업무로 재편되는 것이다.
3. 리뷰어에게 '설명 부담'을 의도적으로 부여하라. 스킬 감퇴가 보이지 않는 이유는 계속 일하면서도 인지 개입이 없기 때문이다. 반대로 설계하면 된다. PR 승인 전 "이 함수가 하는 일을 두 문장으로 써라"는 조건을 넣는 것만으로도 차이가 난다. diff를 읽고 느낌으로 승인하는 루틴을 끊고, 설명을 강제하는 체크포인트를 구조 안에 넣어야 한다. 팀 세션에서 AI 생성 코드를 랜덤 선택해 작성자가 구두로 설명하게 하는 것도 같은 효과다. 불편하지만, 그 불편함이 판단력이 살아 있다는 신호다.
4. 세션 로그를 데이터로 만들어라. .claude나 로컬 AI 채팅 로그를 주기적으로 감사해 팀이 반복적으로 같은 수정을 가하는 패턴을 찾아라. 그 패턴을 Semgrep 룰이나 정적 분석 체크로 전환하면, 반복되는 실수는 자동으로 막히고 인간 리뷰어는 더 복잡한 판단에 집중할 수 있다.
빠른 것과 좋은 것 사이의 설계
학생들이 AI로 숙제 점수를 18% 올리는 동안 시험 점수를 20% 깎아먹은 것처럼, 개발자도 배포 속도를 높이면서 리뷰 판단력을 조용히 소진하고 있을 수 있다. 지표는 초록색이고, 속도는 빨라지고, 당신은 자신이 느려지고 있다는 걸 느끼지 못한다. 그래서 이건 개인의 수양 문제가 아니다. 팀 리드가 시스템 수준에서 설계해야 하는 문제다.
AI가 생산성을 높이는 동시에 판단력을 잠식하는 이 긴장은 해소되지 않는다. 다만 관리될 수 있다. 가드레일을 환경에 내장하고, 스펙과 테스트를 앞으로 당기고, 리뷰에 설명 부담을 구조적으로 넣는 것. 이 세 축이 동시에 설계되지 않으면, AI는 팀의 속도를 높이는 게 아니라 팀이 자신의 코드를 모르는 상태를 유지하는 비용을 뒤로 미루는 도구가 된다.