당신의 코딩 어시스턴트는 당신 자신이 아닙니다

며칠 전 Twitter(저는 항상 Twitter라고 부를 것입니다...)를 스크롤하다가 또다시 그것을 보았습니다. 작업 흐름 도중에 Rate Limit(속도 제한)에 걸렸다는 또 다른 개발자의 게시물이었습니다. 공포. 좌절. **"안 돼, 안 돼, 안 돼, 지금은 안 돼"**라는 반응. 그러다 서비스 장애(Service outage)가 발생하면 제 WhatsApp 그룹들이 불이 납니다. Slack 커뮤니티들은 붕괴 상태에 빠집니다. 제가 어디를 보든, 개발자들은 AI 코딩 어시스턴트가 침묵하고 다음에 무엇을 해야 할지 모른다는 것을 깨닫는 그 순간에 대해 이야기하고 있습니다. Rate Limit, 장애, 성능 저하. 무엇이 원인이든 상관없습니다. 반응은 모두 같습니다.

그 반응 말인가요? 그것은 중독과 매우 닮아 있습니다. 임상적인 종류는 아닐지라도, 도구가 워크플로우(Workflow)에 너무 깊게 박혀 있어서 그것을 제거하는 것이 불가능하게 느껴지는 그런 종류의 중독 말입니다. 그리고 만약 당신이 일정 기간 AI 코딩 도구를 사용해 왔다면, 아마 당신 자신에게서도 그런 모습을 본 적이 있을 것입니다.

수치가 말해주는 이야기

규모 면에서 어떤 일이 일어나고 있는지부터 시작해 봅시다. 현재 개발자의 84-90%가 AI 코딩 도구를 사용하고 있습니다. 51%는 매일 사용합니다. Claude Code는 단 1년 만에 80배 성장했으며, 이는 Anthropic이 계획했던 10배를 훨씬 초과하는 수치입니다. Cursor는 3년 만에 ARR(연간 반복 매출) 20억 달러를 달성했습니다. Uber는 Claude Code가 예상보다 훨씬 빠르게 5,000명의 엔지니어에게 확산되면서 4월까지 2026년 AI 예산 전체를 소진했습니다. 이것들은 단순히 "있으면 좋은" 생산성 도구의 채택 곡선이 아닙니다. 이것은 깊은 통합(Deep integration)입니다. 이것은 조직적 수준에서의 의존성입니다.

Anthropic이 12월에 _"연말 선물"_로 사용 한도를 두 배로 늘렸다가 1월에 다시 정상 한도로 복구했을 때, 개발자들은 60%의 용량 감소를 경험한 것과 같은 상황을 겪었습니다. 한 개발자는 서비스 중단 중에 다음과 같이 적었습니다: "Claude의 서비스 중단은 당신의 뇌 절반을 그것에 외주 주었다는 사실을 깨닫는 순간 훨씬 더 강력하게 다가옵니다." 그 유혹은 실재합니다. 그리고 그것은 의도된 설계입니다.

AI 코딩 도구 벤더들이 만드는 락인(Lock-In)

엔지니어링 관점에서 제가 흥미롭다고 느끼는 지점은 이것입니다. 이러한 AI 코딩 도구 벤더들이 제품을 구축하는 방식은 의존성을 적극적으로 조장합니다. 불투명한 한도를 가진 크레딧 시스템, 예측할 수 없는 순환 리셋(Rolling resets), 그리고 실제로 리셋이 되었을 때 느끼는 안도감, 새로운 기준점을 설정했다가 다시 빼앗아 버리는 일시적인 프로모션 보너스 같은 것들 말입니다. 자세히 들여다보면, 이는 우리가 수년간 서로에게 경고해 온 벤더 락인(Vendor lock-in) 패턴과 매우 흡사해 보입니다. 다만 이번에는 락인이 인프라에 있는 것이 아니라, 당신의 워크플로(Workflow)에, 당신의 근육 기억(Muscle memory)에, 그리고 당신이 문제에 접근하는 방식에 자리 잡고 있다는 점이 다릅니다.

UBC CHI 2026 연구는 334건의 개발자 자기 보고를 분석하여 일관된 패턴을 발견했습니다: 사용량의 점진적 증가, 사용량을 줄이려는 시도의 실패, 접근이 제한될 때 느끼는 진정한 고통 등입니다. 이 연구의 수석 저자는 직설적으로 표현했습니다: "관련된 일부 기업들의 의도적인 설계 결정이 사용자의 건강이나 안전과 상관없이 사용자를 온라인 상태로 유지하는 데 기여하고 있습니다." 익숙하게 들리시나요? 그래야 합니다. 우리는 수십 년 동안 UX에서의 다크 패턴(Dark patterns)에 대해 이야기해 왔습니다. 이것은 동일한 플레이북(Playbook)이며, 이제 AI 코딩 도구 벤더들이 자신들의 고객인 개발자들에게 적용하고 있는 것입니다.

기술 침식(Skill Erosion) 문제

기술적인 관점에서 볼 때 여기서부터 불편한 상황이 발생합니다. Anthropic의 자체 무작위 대조 시험 (Randomized Controlled Trial)에 따르면, AI를 사용하는 개발자들은 기술 테스트에서 17% 더 낮은 점수를 받았습니다. 그들 자신의 연구입니다. 그들 자신의 도구입니다! 그들의 사용자를 코딩 실력이 측정 가능한 수준으로 더 나쁘게 만들고 있는 것입니다. 저는 AI가 작성한 코드를 검토 없이 방치할 때 발생하는 숨겨진 비용 (Hidden Costs)에 대해 이전에 작성한 적이 있습니다. 하지만 이것은 기술 부채 (Technical Debt)보다 더 깊은 문제입니다.

METR 시험은 훨씬 더 시사하는 바가 큽니다. 개발자들은 20% 더 빠르다고 느꼈습니다. 하지만 실제로는 19% 더 느렸습니다. 인지된 생산성과 실제 생산성 사이에 39%포인트의 격차가 발생한 것입니다. 이것이 실무에서 무엇을 의미하는지 생각해 보십시오. 당신은 자신이 직접 작성했다고 생각하는 코드를 더 빨리 배포하고 있습니다. 하지만 실제로는 그렇지 않습니다. 당신은 코드베이스 (Codebase)에 대한 이해가 부족한 상태에서 아키텍처 (Architectural) 결정을 내리고 있습니다. 디버깅 (Debugging)을 덜 하고 있으며, 이는 당신의 시스템이 실제로 어떻게 작동하는지에 대해 배우는 것이 줄어든다는 것을 의미합니다.

탈숙련화 (De-skilling) 파이프라인은 다음과 같습니다:

작업을 AI에게 위임한다
사용하지 않은 기술이 퇴화하기 시작한다
다음번에는 스스로 할 수 없기 때문에 반드시 위임해야만 한다
도구 없이는 아무것도 할 수 없게 될 때까지 반복한다

이것은 의존성 루프 (Dependency Loop)입니다. 코드에서의 모든 의존성 루프와 마찬가지로, 일단 그 안에 빠지면 빠져나오기 위해서는 의도적인 노력이 필요합니다.

그리고 이것이 진정한 의미에서 중독성을 갖게 만드는 지점입니다. 도구가 바로 그 도구의 사용을 멈추는 데 필요한 기술 자체를 저하시킵니다. 이것은 단순한 락인 (Lock-in)이 아닙니다. 그것은 함정입니다.

우리는 이전에 이런 경험을 한 적이 있습니다 (음... 어느 정도는요)

공포가 밀려오기 전에 관점을 좀 정리해 봅시다. 개발자들은 IDE가 명령줄 컴파일 (command-line compilation) 방식을 잊게 만들까 봐 걱정했습니다. Stack Overflow가 알고리즘을 잊게 만들까 봐 두려워했습니다. 프레임워크가 그 밑바탕이 되는 근본 원리 (fundamentals)를 잊게 만들까 봐 걱정했습니다. 그리고 솔직히 말하자면? 실제로 그런 일들이 일부 일어났습니다. 이제 정렬 알고리즘 (sorting algorithm)을 처음부터 직접 작성하지 못하는 개발자가 아주 많습니다. 저 역시 확실히 그렇습니다. 하지만 그들은 여전히 훌륭한 소프트웨어를 만들 수 있습니다. 기술이 사라진 것이 아니라 이동했기 때문입니다.

그렇다면 이번에는 무엇이 다를까요? 바로 **추상화의 수준 (level of abstraction)**입니다. 이전의 도구들은 타이핑을 자동화했습니다. AI 코딩 어시스턴트 (AI coding assistants)는 _사고 (thinking)_를 자동화합니다. 코드 완성 (code completion) 도구는 키 입력을 줄여줍니다. 하지만 여러분의 구현 (implementation), 테스트, 그리고 문서를 작성하는 AI 에이전트 (AI agent)는 인지적 수준 (cognitive level)에서 작동합니다. 이것은 우리가 이전에 다루었던 그 어떤 것과도 근본적으로 다른 종류의 의존성입니다. 바로 이 지점이 주의를 기울여야 할 부분입니다.

도구는 당신을 정의하지 않습니다

제가 계속해서 되풀이하는 핵심은 이것입니다. 당신의 지식은 당신의 것입니다. 당신의 창의성은 당신의 것입니다. 당신의 판단력은 당신의 것입니다.

코딩 어시스턴트는 코드를 생성할 수 있습니다. 사실, 아주 많은 양의 코드를 생성할 수 있죠. 하지만 어떤 코드를 작성해야 하는지, 혹은 왜 작성해야 하는지

그것은 여전히 당신의 몫입니다. 그것은 언제나 당신의 몫일 것입니다. 계산기가 당신을 수학자로 만들어주지 않습니다. GPS가 당신을 항해사로 만들어주지 않습니다. 그리고 코딩 어시스턴트(coding assistant)가 당신을 엔지니어로 만들어주지 않습니다. 이것들은 도구입니다. 진정으로 훌륭한 도구들이죠. 하지만 그것들이 당신이 누구인지, 혹은 당신이 무엇을 할 수 있는지를 정의하지는 않습니다. 당신이 그 도구들을 사고를 증강(augmenting)하는 대신 사고를 대체하도록 허용하는 순간, 당신은 본질을 놓치게 됩니다.

해결책은 인식입니다

이 문제에 대해 실제로 어떻게 해야 할까요? AI 어시스턴트 사용을 그만두는 것이 아닙니다. 그것은 현실적이지 않으며, 솔직히 그럴 필요도 없습니다. 해결책은 금욕이 아닙니다. 그것은 의도성 (intentionality) 입니다.

당신이 "도구를 사용하는 것"에서 "지팡이에 의존하는 것"으로 선을 넘었을지도 모른다는 몇 가지 신호들은 다음과 같습니다:

AI를 먼저 열지 않고는 작업을 시작할 수 없다
AI 없이는 디버깅(debugging)을 할 수 없다. "하고 싶지 않은 것"이 아니라 진정으로 "할 수 없는" 상태다
사용량 제한(rate limits)이 가벼운 짜증이 아닌 진정한 불안을 유발한다
"아마 괜찮을 거야"라는 생각에 AI의 결과물을 읽지도 않고 수락한다
몇 주 동안 무언가를 처음부터 직접 작성해 본 적이 없다
자신의 프로젝트에서 실행 중인 코드를 설명할 수 없다

이 중 익숙한 것이 있나요? 스스로에게 솔직해지세요. 해결책은 개념적으로는 간단하지만, 실천하기는 더 어렵습니다. 도구가 잘하는 일에는 도구를 사용하세요. 보일러플레이트(boilerplate), 스캐폴딩(scaffolding), 혹은 "무엇을 원하는지는 알지만 직접 타이핑하는 것이 지루한" 작업들 말이죠. 하지만 사고는 스스로 유지하세요. 설계 결정(design decisions), 디버깅, 그리고 "이게 왜 존재하는가"에 대한 질문들 말입니다. 자동차가 존재하더라도 달리기 운동을 하는 것과 마찬가지로, 이러한 근육들을 의도적으로 단련하세요.

당신을 향한 나의 도전

서두에서 언급했던 개발자들을 기억하시나요? 사용량 제한 때문에 패닉에 빠진 사람들 말이죠? 그 패닉은 하나의 신호입니다. 더 높은 등급의 요금제가 필요하다는 신호가 아닙니다. 어쩌면 그들이 지탱해야 할 부분에 도구가 하중을 견디는 구조물(load-bearing)이 되도록 허용해 버렸다는 신호입니다. 그리고 당신이 스스로에게 솔직하다면, 당신 또한 그 모습이 조금은 닮아 있음을 깨달을지도 모릅니다.

다음에 한계에 부딪히거나, 서비스가 중단되거나, 혹은 그저 좌절감이 치밀어 오를 때... AI 채팅창을 닫으세요. 빈 파일을 여세요. 그리고 직접 무언가를 작성해 보세요. 당신이 여전히 할 수 있다는 것을 증명하기 위해서라도 말입니다.

이 글에 대한 당신의 생각이나 의견을 듣는 것은 매우 흥미로울 것입니다. Twitter를 통해 저를 태그하거나 아래에 댓글을 남겨주세요.