AI 페어 프로그래머가 당신의 코딩 실력을 조용히 갉아먹고 있다

코드 작성법을 잊어버리겠다고 작정하는 사람은 없다. 대부분의 기술 상실이 그렇듯, 그것은 편리한 지름길을 하나씩 택하는 과정에서 일어난다. 예전에는 정규식을 직접 작성했지만, 이제는 원하는 것을 설명하고 모델이 내놓는 결과를 그대로 붙여넣는다. 예전에는 스택 트레이스를 한 줄씩 추적했지만, 이제는 그것을 채팅창에 넣고 요약을 읽는다. 각각의 대체는 개별적으로 보면 합리적이다. 하지만 AI의 도움을 받으며 일한 지 1년이 지나고 나면, 그 합은 도구를 켰을 때는 기능을 빠르게 출시할 수 있지만 도구를 껐을 때는 살짝 얼어붙는 개발자가 된다.

이것이 이번 달 바이브 코딩 붐 이면에 깔린 불편한 진실이다 — Lovable은 보도에 따르면 130억 달러 밸류에이션에 근접하고 있고, Replit과 Factory는 각각 수십억 달러 규모의 투자를 유치했으며, SpaceX는 '자율 에이전트'를 위해 만들어진 Grok 4.5로 최전선 가격을 깎아내리고 있다. 이 모든 것은 한 가지 목표에 최적화되어 있다: 여러분이 직접 코드를 덜 쓰게 만드는 것. 그게 핵심이고, 많은 작업에서 그것은 정당한 거래다. 하지만 이는 업계가 지난 2년간 '수작업 코딩 능력을 얼마나 외주화해야 대가를 치르게 되는가'에 대한 통제되지 않은 실험을 해왔다는 뜻이기도 하며, 그 청구서는 이제 구체적이고 확인 가능한 방식으로 날아오기 시작했다.

그 격차가 실제로 발목을 잡는 지점

기술 퇴화는 막연한 불안이 아니다 — 그것은 세 가지 구체적인 상황에서 모습을 드러내며, 자신이 그중 어디에 노출되어 있는지 솔직하게 짚어볼 필요가 있다:

• 면접. 과제형 테스트를 제외하면 대부분의 기술 면접은 여전히 AI 지원을 제한하거나 금지한다. 만약 일상적인 숙련도가 "내가 이것을 쓸 수 있다"에서 "내가 모델에게 이것을 쓰라고 지시할 수 있다"로 조용히 옮겨갔다면, 화이트보드 면접이나 라이브 코딩 라운드는 채용 여부를 결정하는 사람 앞에서 실시간으로 그 격차를 드러낼 것이다.
• 장애. 프로덕션이 다운되었을 때 가장 빠른 해결책은 대개 압박 속에서 낯선 코드를 읽고 직접 추론하는 것이지, 설명할 시간도 없는 시스템에 대해 좋은 프롬프트를 작성하는 것이 아니다. 사고 대응은 바로 이런 능력들 — 빠른 코드 읽기, 머릿속 디버깅, API 구조를 암기하고 있는 것 — 을 요구하는데, 이는 평소 모델이 대신 처리해주면 가장 적게 단련되는 능력들이다.
• 연결 끊김, 어시스턴트 없음. 비행기 안, 네트워크가 차단된 고객사, 모델 제공업체 측의 서비스 장애 — 이런 상황들은 모두 한동안 여러분을 도움 없이 코딩해야 하는 처지로 되돌려 놓는다. 이것이 문제가 되기 위해 영구적일 필요는 없다. 그저 무언가를 출시해야 하는 날에 일어나기만 하면 된다.

이것들은 제품을 팔기 위해 지어낸 가상의 극단적 사례가 아니다. 이는 직장 생활에서 흔히 벌어지는 평범한 상황들이다. 문제는 이런 상황 중 하나가 여러분을 궁지에 몰아넣기 전에, 그 퇴화를 스스로 알아차릴 수 있느냐다.

훈련 도구의 등장

바로 이 격차를 겨냥한 것이 이번 달 The Register의 기사에 소개된 Atrophy CLI라는 신규 도구다. 그 접근 방식은 노골적이다: 코딩 능력을 '코딩할 수 있다/없다'는 이분법이 아니라 체스의 엘로 레이팅처럼 다루는 것이다. 먼저 현재 자신의 위치를 파악하는 기준 시험으로 시작한 다음, 이 도구는 문법 암기, 디버깅, 코드 읽기, API 기억, 문제 분해 등 몇 가지 구분된 기술 범주에 걸쳐 훈련을 시키고, 체스 엔진이 실제로 실력이 느는 것인지 아니면 그저 그렇게 느껴지는 것뿐인지를 추적하듯 시간에 따른 레이팅을 추적한다. 태그라인 한 줄에 이 도구의 논지 전체가 담겨 있다: "AI 지원이 조용히 여러분의 무보조 코딩 능력을 갉아먹고 있다면, 면접이나 장애나 와이파이 없는 하루가 그것을 알려주기 전에 이 차트가 먼저 알려준다."

주목할 만한 설계상의 선택은 하나의 종합 점수가 아니라 별도의 범주로 나누어 놓았다는 점이다. 바이브 코딩이 모든 코딩 능력을 고르게 갉아먹는 것은 아니다 — 문제 분해(문제를 단계별로 쪼개는 것) 능력은 AI 어시스턴트를 쓰더라도 여전히 대체로 여러분 자신의 몫이기 때문에 예리함을 유지할 수 있는 반면, 문법 암기력과 코파일럿 없이 디버깅하는 순수한 근력은 조용히 무뎌진다. 바로 그 부분들을 위임해왔기 때문이다. 단일 점수라면 이런 차이를 가려버렸을 것이다. 범주별 레이팅은 적어도 어떤 근육을 다시 단련해야 하는지 알려주며, 이는 막연히 실력이 녹슬었다는 느낌보다 훨씬 유용한 신호다.

필요한 유보

솔직히 말해두자면: Atrophy CLI는 아직 새로운 도구이며, 그 레이팅이 실제로 면접이나 장애 대응 성과를 예측하는지, 혹은 정기적인 훈련이 기술 퇴화를 의미 있게 되돌리는 것인지 아니면 그저 훈련 자체에만 능숙해지게 만드는 것인지에 대한 독립적인 데이터는 아직 보지 못했다 — 이는 실제 과제가 아닌 어떤 연습 도구에도 존재하는 현실적인 위험이다. 이를 검증된 해결책이 아니라 한번 시도해볼 만한 진단 도구 정도로 여기는 편이 좋다. 이 도구가 개척하고 있는 영역 — AI 지원 생산성과 별개로 AI 지원으로 인한 기술 퇴화를 측정한다는 것 — 자체는, 이 특정 도구가 결국 살아남을 것인지 여부와 무관하게 유용한 아이디어다.

생산성을 포기하지 않으면서 이 문제에 대처하는 법

이 문제로부터 자신을 지키기 위해 AI 지원 코딩을 완전히 끊을 필요는 없다. 그것은 더 저렴하게 관리할 수 있는 위험을 회피하기 위해 실질적인 생산성 이득을 포기하는 셈이 될 것이다. 몇 가지 구체적인 습관만으로도 대부분의 역할을 해낼 수 있다:

• 평소라면 모델에게 맡겼을 법한 것 — 버그, 작은 함수, 데이터 변환 같은 것 — 을 주기적으로 완전히 혼자 힘으로 풀어보고 시간을 재보라. 어디서 망설이게 되는지 눈여겨보라.
• 면접 일정이나 온콜 순번을 앞두고 있다면, 몇 달간 손대지 않은 시험 범위를 벼락치기하듯, 의도적으로 일정 기간 AI를 끄고 코딩하는 시간을 가져라.
• AI의 도움을 받을 때는, 붙여넣고 그냥 넘어가기보다 다른 사람에게 설명할 수 있을 만큼 생성된 코드를 꼼꼼히 읽어라 — 그 접함이 여러분의 이해를 쌓아주는지 아니면 그저 겉핥기로 지나가는지를 가르는 것은 바로 이 단계다.
• Atrophy CLI 같은 레이팅 방식의 도구가 자신에게 잘 맞는다면, 그것을 훈련 프로그램 자체가 아니라 화재경보기처럼 사용하라 — 주기적으로 확인하고, 어떤 범주의 점수가 떨어지고 있다면 그 부분에 대해 플래시카드를 반복하기보다 실제로 도움 없이 작업해보라.

솔직하게 말하자면, AI 지원 코딩과 무보조 코딩 능력은 이제 지름길이 있는 하나의 기술이 아니라 여러분이 각각 관리해야 할 두 가지 별개의 기술이다. 고용주도, 면접관도, 새벽 3시의 장애 대응 채널도 아직 이 사실을 완전히 따라잡지는 못했지만, 결국 어느 지원자가 두 기술을 모두 살려두었는지는 알아차리게 될 것이다.