지표는 올라가는데 팀이 이상하다
PR 수는 늘었고, 사이클 타임은 줄었고, 기능 배포 속도도 빨라졌다. 그런데 이상하게 팀이 점점 무거워지는 느낌이 든다. 시니어가 리뷰를 해도 코드를 '이해'했다는 확신이 없고, 주니어는 에러 메시지를 보고도 어디서 시작해야 할지 모른다. AI 코딩 도구를 적극 도입한 팀에서 공통적으로 나타나는 이 불편한 감각—그게 단순한 기분 탓이 아니라는 연구 결과가 나왔다.
17% 낮은 점수, 그리고 1시간의 법칙
Shen·Tamkin(2026) 연구는 꽤 충격적이다. 52명의 개발자를 대상으로 실험한 결과, AI 보조 그룹은 개념 이해·디버깅·코드 읽기 능력에서 비보조 그룹보다 17% 낮은 점수를 기록했다. 더 놀라운 건 1시간의 수동적 AI 사용만으로도 측정 가능한 기술 침식이 발생한다는 점이다. Manfred Spitzer의 'Digital Dementia'와 Margaret-Anne Storey의 'Cognitive Debt' 개념이 실험으로 입증된 셈이다. 반복적 사고를 AI에 위임하면 두뇌 경로가 약화되고, 코드 이해력이 실질적으로 감소한다.
이걸 테크 리드 관점에서 번역하면 이렇다: Claude Code에게 코드를 생성하게 하고 팀원이 클릭만 하는 구조는, 팀원을 성장시키는 게 아니라 팀원을 소모하고 있다.
코드 리뷰 역설과 시니어 파이프라인 붕괴
AI-First 워크플로우에서 가장 위험한 함정은 코드 리뷰 역설이다. AI가 코드를 작성하고 인간이 검토만 하면, 검토 능력의 근원 자체가 사라진다. 직접 짜본 적 없으니 무엇이 이상한지 감이 없고, 감이 없으니 리뷰는 형식적 승인 클릭으로 전락한다.
시니어는 코드를 직접 작성하지 않아 깊이를 잃어가고, 주니어는 시행착오를 거치지 않아 성장 경로 자체가 막힌다. AI가 초보자에게 시니어급 산출물을 제공하지만, 이해 없는 복제에 불과하다. 결과적으로 시니어 육성 파이프라인이 붕괴되는데, 이건 스프린트 단위 지표에는 절대 잡히지 않는다. Simon Willison조차 자신의 프로젝트에서 AI가 만든 기능을 검토하지 않아 "더 이상 내부 작동을 명확히 이해하지 못한다"고 고백했다.
Dark Flow: 창의적 몰입의 소멸
개발자가 직접 코드를 작성할 때 느끼는 몰입(flow)은 단순한 감정이 아니다. 그게 학습이고, 문제 해결력이 쌓이는 순간이다. AI가 도전 과제를 대신 처리하면 진짜 몰입 대신 dark flow 상태가 유발된다—속도감과 효율성에 중독되어 있지만, 학습 없이 의존만 강화되는 상태다.
코드 작성이 품질관리(QA) 업무로 전락하면 창의적 만족감이 사라지고 번아웃이 가속된다. Hacker News 커뮤니티의 반응도 이를 뒷받침한다. 한 개발자는 "AI가 API 문서를 읽고 래퍼를 만들었는데 결과물은 완벽했지만, 정작 나는 API의 감각이나 구조를 전혀 이해하지 못했다. 많이 할 수 있지만 아무것도 모르는 상태가 불편하고 공허하다"고 썼다. 이게 조직 전체로 번지면, 팀은 빠르게 움직이지만 아무도 시스템을 이해하지 못하는 상태가 된다.
경영진의 오판과 Goodhart의 법칙
AI 사용량을 KPI로 측정하는 기업들이 늘고 있다. Reddit 사례는 경고다: 개발자들이 무의미한 명령으로 AI 사용량을 조작했다. Goodhart의 법칙—측정 지표가 목표가 되는 순간 그 지표는 의미를 잃는다—이 그대로 작동한 셈이다. Spotify 공동 CEO가 "엔지니어가 Slack에서 Claude에게 명령해 기능 수정·배포까지 수행한다"고 자랑스럽게 언급한 것이 실제로 팀 역량 지표에서 무엇을 의미하는지는 아무도 검증하지 않는다.
Microsoft, Anthropic, Google 경영진의 "수개월 내 엔지니어 대체" 예측은 AI 판매와 주가 부양 목적의 과장일 가능성이 높다. 테크 리드는 이 숫자에 팀 전략을 맞추지 말아야 한다.
Claude Code 생태계는 빠르게 확장 중이다
아이러니하게도, 바로 이 시점에 Claude Code 생태계는 빠르게 확장되고 있다. /mobile-preview 스킬(geeknews)은 cloudflared 터널을 활용해 로컬 개발 서버를 모바일 Chrome에서 바로 확인할 수 있게 해준다—npx skills add mindori/mobile-preview 한 줄로 설치된다. Call-me 플러그인(geeknews)은 더 나아가 Claude Code가 작업 완료나 의사결정이 필요할 때 실제로 전화를 걸어온다. Telnyx나 Twilio를 활용해 조깅 중에도 Claude와 대화하며 작업 지시가 가능한 구조다.
도구는 점점 더 강력해지고, 개입 없이도 돌아가는 자동화 범위는 계속 넓어진다. 이 흐름을 거스를 수는 없다. 문제는 어떻게 쓰느냐다.
적정 사용 임계점: 사용 여부가 아니라 사용 방식이 핵심
Shen·Tamkin 연구는 6가지 AI 상호작용 패턴을 분석했다. 학습을 저해하는 패턴과 학습을 유지하는 패턴이 명확히 갈린다.
학습 저해 패턴: - 완전 위임 ("이 기능 다 만들어줘") - 점진적 의존 (이해 없이 결과만 받아쓰기) - 디버깅 위탁 (에러 로그를 그대로 붙여넣기)
학습 유지 패턴: - 설명 요청 ("이 코드가 왜 이렇게 동작해?") - 개념 질문 ("이 패턴의 트레이드오프가 뭐야?") - 독립적 코딩 후 확인 (내가 먼저 짜고, AI에게 리뷰 요청)
AI를 전혀 안 쓰면 검색·보일러플레이트·탐색 효율을 잃는다. 과도하게 쓰면 이해력·시니어 육성·버그 탐지·몰입감이 손상된다. 단순 사용 여부가 아니라 인지적 참여가 유지되는 방식으로 쓰는 것이 핵심이다.
AI 시대 아키텍트(테크 리드)의 역할 재정의
BeSA Cloud Academy의 Agentic AI 세션(dev.to)은 솔루션 아키텍트 역할 변화를 정확하게 짚었다. AI는 '산수(arithmetic)'—기술적 타당성 검증—를 담당하고, 아키텍트는 '수학(mathematics)'—판단과 맥락—을 담당한다. AI는 '무엇(what)'을 제시하고, 아키텍트는 '왜(why)'와 '어떻게(how)'를 결정한다.
지식 암기의 우위는 사라졌다. 이제 진짜 경쟁력은 종합(synthesis)—기술적 역량과 인간적 맥락, 조직 정치, 예산 현실을 통합하는 능력—이다. AI를 "빠른 여름 인턴"처럼 다루라는 조언이 와닿는다: 생산적이고, 방향이 필요하고, 배포 전 검증이 필수다.
테크 리드가 지금 해야 할 것
팀에 AI 도구를 도입했거나 도입 중이라면, 지금 당장 몇 가지를 점검해야 한다.
첫째, 팀 레벨의 사용 임계점을 명시적으로 설정하라. "AI로 이거 어떻게 하면 좋을까요?"를 고민하기 전에, 어떤 종류의 작업에 AI를 쓰고 어떤 작업은 반드시 직접 해야 하는지 팀 가이드라인이 필요하다. 특히 신규 도메인 탐색, 핵심 비즈니스 로직, 디버깅 사고 과정은 AI 완전 위임에서 제외하는 것을 권장한다.
둘째, 온보딩 프로세스에서 AI 사용 방식을 명시하라. AI-First 온보딩이라도 주니어가 이해 없이 결과물만 복사하는 구조가 되면 안 된다. "AI가 생성해준 걸 기반으로 우리가 다듬는" 협업 모델은, 팀원이 먼저 개념을 이해한 상태에서만 작동한다.
셋째, AI 사용량이 아니라 이해도를 측정하라. PR 수, AI 사용 횟수 대신 "이 코드를 설명할 수 있는가", "이 버그를 AI 없이 디버깅할 수 있는가"를 팀 역량 지표로 삼아야 한다.
전망: 조용한 쇠퇴를 막는 건 결국 테크 리드의 판단
Claude Code는 계속 강력해질 것이다. 전화로 연락하고, 모바일에서 결과를 확인하고, 자율적으로 배포까지 수행하는 방향으로. 이 흐름을 막을 수 없고, 막아서도 안 된다.
그러나 지표상으로는 PR 수와 기능 수가 올라가는 동안, 팀의 내면 기술력은 서서히 약화되는 '조용한 쇠퇴'는 테크 리드가 가장 경계해야 할 리스크다. 이건 스프린트 리뷰에서 잡히지 않고, 분기 OKR에서도 드러나지 않는다. 처음 대규모 장애가 났을 때, 또는 핵심 시니어가 떠났을 때 비로소 드러난다.
AI-First 팀 리빌딩의 진짜 목표는 AI 도구 사용률을 높이는 게 아니다. AI와 협업하면서도 팀원 각자가 판단력과 이해력을 유지하는 구조를 만드는 것이다. 이거 자동화하면 우리가 더 중요한 일에 집중할 수 있다는 말이 진짜가 되려면, 그 '더 중요한 일'을 해낼 역량이 팀에 남아 있어야 한다.