면접장에서 마주친 현실
최근 백엔드 채용 면접을 진행한 시니어 엔지니어 Tuan의 글이 dev.to에서 화제다. 그가 목격한 장면은 단순히 불안한 신호가 아니라, 업계 전체가 외면하고 싶어 하는 진실을 건드렸다. 경력 몇 년의 지원자에게 Node.js 서비스의 500 에러를 디버깅하게 했더니, 40분 동안 Cursor에 에러를 붙여넣고 또 붙여넣기만 반복했다. 정작 버그는 3주 전 AI 어시스턴트가 만들어낸 존재하지도 않는 메서드였고, 그는 그 코드를 한 번도 제대로 읽지 않은 채 프로덕션에 올렸다.
이게 예외적인 사례였으면 좋겠지만, 그렇지 않다. METR의 2025년 연구에서 AI 도구를 쓴 개발자들은 주관적으로 20% 빠르다고 느꼈지만 실제 측정치는 19% 느렸다. GitClear의 2024년 분석에서는 Copilot이 보급된 이후 2주 안에 되돌려지는 코드 비율이 두 배가 됐다. 더 많이 짜고, 더 많이 뜯어내고 있는 것이다.
왜 하필 디버깅 근육인가
이 글에서 내가 주목하는 건 '코드 생성 품질' 문제가 아니다. 그건 이미 여러 번 다뤘다. 지금 이야기하고 싶은 건 역량 설계다.
디버깅은 코드를 고치는 행위가 아니다. 시스템 모델을 머릿속에 구성하고, 가설을 세우고, 가장 저렴한 방법으로 검증하는 인지 과정이다. 인지과학자 Robert Bjork의 '바람직한 어려움(desirable difficulty)' 연구는 오래전부터 이걸 증명했다. 학습은 마찰의 양에 비례해 공고해진다. 틀린 가설을 직접 검증해본 경험이 쌓여야 '이 버그는 여기서 났을 것 같다'는 직관이 생긴다. AI에 에러를 붙여넣으면 그 마찰이 제거된다. 마찰이 사라지면 학습도 사라진다.
같은 맥락에서 Tuan은 '24시간 테스트'를 제안한다. 오늘 내가 배포한 코드를 내일 AI 없이 다시 쓸 수 있는가? 쓸 수 없다면, 나는 그 코드를 쓴 게 아니다. AI가 쓴 것을 내 이름으로 배포한 것이다.
시니어도 예외가 아니다
문제는 주니어에게만 국한되지 않는다. Tuan은 스스로를 고발하는 이야기를 꺼낸다. 오랜 스프린트 말미, 지쳐있던 그는 트랜잭션 래퍼를 Cursor에 맡겼다. 결과물은 겉보기에 깔끔했고 테스트도 통과했다. 이틀 뒤 프로덕션에서 데드락이 터졌다. 원인은 기존 코드 경로와 락 획득 순서가 달랐기 때문이었다. AI는 주어진 범위 안에서 정확했다. 하지만 시스템 전체를 머릿속에 담은 사람만이 잡을 수 있는 버그를 그는 피로로 놓쳤다.
그는 이것을 '항공 자동화 유발 기술 퇴화(automation-induced skill decay)'에 비유한다. FAA가 장거리 비행 조종사들에게 실제 수동 조작 시간을 늘리라는 안전 권고(SAFO 13002)를 낸 건 우연이 아니다. 자동화 시스템에 의존한 조종사들은 스스로의 실력 저하를 자각하지 못한다. 개발자도 마찬가지다. AI가 속도를 올려주기 때문에 예리하다고 느끼지만, 실제로는 실력이 아니라 도구의 성능을 경험하고 있을 뿐이다.
도구 선택 논쟁이 놓친 것
AWS Kiro와 Cursor를 비교한 Velog 글이 한국 개발자 커뮤니티에서 회자되고 있다. Cursor가 즉각적인 응답으로 빠른 속도를 주는 반면, Kiro는 초기 Spec 문서 작성부터 시작하는 하향식 접근으로 코드 일관성을 높인다는 분석이다. 실제로 워크샵에서 단순한 요구사항의 프로젝트를 시작했는데도 첫 npm run dev까지 4~5시간이 걸렸고, 토큰 사용량도 상당했다고 한다.
이 비교 자체는 유용하다. 하지만 지금 이 맥락에서 나는 다른 질문을 하고 싶다. Cursor를 쓰든 Kiro를 쓰든, 그 도구를 사용하는 팀원이 무엇을 잃고 있는가. 도구가 더 능숙해질수록 팀원이 직접 판단해야 하는 영역이 줄어든다. Kiro의 Spec-Driven 방식은 아키텍처 결정을 구조화하지만, 그 구조를 AI가 채운다면 팀원의 설계 근육을 키우는 게 아니라 대체하는 것이다.
도구 선택의 기준이 '어떤 도구가 더 많이 해주는가'에서 '어떤 도구가 팀원의 판단을 어느 지점까지만 보조하는가'로 이동해야 하는 이유가 여기 있다.
AI-First 팀이 실제로 설계해야 할 것
현장에서 내일 당장 적용 가능한 기준으로 정리하면 세 가지다.
첫째, 위임 금지 구역을 명시적으로 설계하라. Tuan이 제안하는 세 가지—디버깅, 아키텍처 결정, 아직 모델이 없는 도메인—는 좋은 출발점이다. 팀 전체가 이 경계를 공유하지 않으면, 각자 다른 지점에서 다른 방식으로 근육을 잃는다. 팀 레벨의 합의가 필요하다.
둘째, '의도적 마찰'을 워크플로우에 구조적으로 집어넣어라. Tuan은 한 달에 하루, AI 자동완성 없이 풀 데이를 보낸다. 팀 단위에서는 레거시 디버깅 세션, 수동 트레이싱 리뷰, AI 없는 화이트보드 설계를 정기적으로 의무화할 수 있다. 학습이 일어나려면 마찰이 있어야 하고, 그 마찰은 의도적으로 설계해야 한다.
셋째, 온보딩 시퀀스를 뒤집어라. AI 도구를 처음부터 주지 마라. 시스템 모델이 먼저 형성된 다음에 AI를 번역기로 쓸 수 있다. 모델 없이 AI부터 주면, 도구가 튜터가 되고 개발자는 점점 수동적인 승인자로 전락한다.
지금이 역량 설계를 논의해야 할 타이밍인 이유
AI 코딩 도구 도입 초기엔 '속도'와 '품질 통제 구조'가 핵심 논의였다. 그 단계는 이미 지나가고 있다. 지금 업계 앞에 놓인 다음 질문은 이 도구들과 함께 1~2년을 보낸 팀이 어떤 역량을 갖고 있을 것인가다.
항공업계는 이 문제를 자동화 도입 40년 후에 깨달았고, 지금도 복구 중이다. 우리는 아직 5년도 안 됐다. 지금 역량 설계를 팀 운영의 의제로 올리지 않으면, 3~5년 후 AI 도구 없이는 프로덕션 장애를 대응할 수 없는 팀을 손에 쥐게 된다. 도구는 빨라지고, 팀은 물러지는 구조다.
빠름을 유지하면서 역량을 지키는 것—이것이 AI-First 팀 리빌딩의 진짜 난이도다. 그리고 그 설계는 도구 선택보다 먼저 이루어져야 한다.