# AI 코딩이 초래하는 비용 > Clean Markdown view of GeekNews topic #27099. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27099](https://news.hada.io/topic?id=27099) - GeekNews Markdown: [https://news.hada.io/topic/27099.md](https://news.hada.io/topic/27099.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-03-01T10:44:43+09:00 - Updated: 2026-03-01T10:44:43+09:00 - Original source: [tomwojcik.com](https://tomwojcik.com/posts/2026-02-15/finding-the-right-amount-of-ai/) - Points: 27 - Comments: 1 ## Summary AI 코딩 도구의 확산은 개발 생산성을 높였지만, 동시에 **인지 부채**와 **조직적 기술 퇴화**라는 보이지 않는 비용을 낳고 있습니다. 자율형 에이전트가 코드를 작성하고 인간이 검토만 하는 구조에서는 문제 해결력과 디버깅 능력이 빠르게 약화되며, 시니어 육성 경로도 붕괴됩니다. AI 활용의 핵심은 사용량이 아니라 **‘인지적 참여를 유지하는 방식’**에 있으며, 인간의 이해와 학습을 보존하는 선에서 균형을 재설정해야 합니다. ## Topic Body - 개발자들이 **AI 코딩 도구를 광범위하게 사용**하면서 생산성이 높아졌지만, 눈에 보이지 않는 **인지적·조직적 비용**이 발생하고 있음 - 초기의 **Copilot·Cursor** 같은 보조형 도구에서, 최근에는 **자율형 에이전트**로 진화하며 인간이 AI를 돕는 구조로 전환됨 - 그러나 완전 위임형 사용은 **인지 부채(cognitive debt)** 와 **디버깅 능력 저하**를 초래하며, 개발자의 **문제 해결력과 코드 이해력**이 약화됨 - AI가 작성한 코드를 검토만 하는 구조는 **시니어 육성 경로 붕괴**와 **창의적 몰입(flow)** 상실로 이어져, 조직의 기술 역량이 장기적으로 침식됨 - AI 활용은 필수적이지만, **‘적정 사용 임계점’을 스스로 설정**하고, 인간의 이해와 학습을 유지하는 방식으로 조정해야 함 --- ### AI 코딩 도입의 진화 - 2022~2023년 등장한 **Copilot·Cursor** 등은 코드베이스를 인덱싱해 문맥 기반 자동완성·채팅 기능을 제공 - 구글링이나 StackOverflow 검색이 불필요해졌으며, **AI 내장 IDE** 환경이 확산됨 - 이후 등장한 **에이전트형 워크플로**는 인간 보조가 아닌 **AI 주도 개발**로 전환 - 그러나 에이전트는 루프, 환각, 의존성 오류 등으로 신뢰성 문제가 발생 - **Opus 4.5** 이후 자동화 수준이 높아지며, 일부 기업은 개발자가 직접 코드를 작성하지 않는 사례도 등장 - 예: Spotify 공동 CEO는 엔지니어가 **Slack에서 Claude에게 명령해 기능 수정·배포**까지 수행한다고 언급 ### 인지 부채와 기술 퇴화 - **Manfred Spitzer**의 ‘Digital Dementia’와 **Margaret-Anne Storey**의 ‘Cognitive Debt’ 개념을 인용 - 반복적 사고를 AI에 위임하면 **두뇌 경로가 약화**되고, 코드 이해력이 감소 - **Shen·Tamkin(2026)** 연구: 52명의 개발자 중 AI 보조 그룹은 **개념 이해·디버깅·코드 읽기 능력에서 17% 낮은 점수** - 특히 디버깅 능력 저하가 두드러졌으며, **1시간의 수동적 AI 사용만으로도 측정 가능한 기술 침식** 발생 - AI가 도전 과제를 대신 처리하면 **‘진짜 몰입(flow)’이 아닌 ‘dark flow’** 상태가 유발되어, 학습 없이 의존만 강화됨 ### 코드 리뷰 역설과 시니어 붕괴 - AI가 코드를 작성하고 인간이 검토만 하면, **검토 능력의 근원이 사라지는 역설** 발생 - AI에 전적으로 의존한 개발자는 빠르게 작업하지만 **평가 점수는 최하위** - **Storey**는 “배포 전 AI 생성 변경사항을 인간이 완전히 이해해야 한다”고 제안 - AI가 초보자에게 **시니어급 산출물**을 제공하지만, **이해 없는 복제**에 불과 - 시니어는 코드를 직접 작성하지 않아 깊이를 잃고, 주니어는 시행착오를 거치지 않아 성장하지 못함 - 결과적으로 **시니어 육성 파이프라인이 붕괴** ### 경영진의 오판과 조직적 부작용 - **Microsoft, Anthropic, Google** 등 경영진은 AI가 수개월 내 **엔지니어를 대체**할 것이라 예측 - Google은 2024년 말 **신규 코드의 50%가 AI 생성**이라 보고 - 그러나 이런 수치는 **AI 판매·주가 부양 목적의 과장**이며, 일반 조직에는 적용 불가 - 일부 기업은 **AI 사용량을 KPI로 측정**하며 개발자에게 강제 - Reddit 사례: 개발자들이 **무의미한 명령으로 AI 사용량을 조작** - 결과적으로 **Goodhart의 법칙**이 작동, 생산성 향상 대신 **형식적 순응**만 남음 ### 인간적 비용과 창의성 상실 - 코드 작성은 **몰입과 창조의 즐거움**을 제공하지만, AI 코드 검토는 **정신적 피로**를 유발 - 창작의 도파민 보상이 사라지면 **번아웃 가속** - 개발이 **품질관리(QA)** 로 전락하며, **창의적 만족감**이 소멸 - AI가 모든 예술을 수행하고 인간이 ‘세탁물만 개는’ 상황에 비유됨 ### 적정 AI 사용 임계점 - AI는 강력한 도구이지만, **사용량이 많거나 적다고 좋은 것이 아님** - **Shen·Tamkin 연구**는 6가지 AI 상호작용 패턴 중, - ‘완전 위임·점진적 의존·디버깅 위탁’은 학습 저해 - ‘설명 요청·개념 질문·독립적 코딩 후 확인’은 학습 유지 - **핵심은 인지적 참여 유지**이며, 단순 사용 여부가 아니라 **사용 방식**이 중요 - AI를 전혀 쓰지 않으면 **검색·보일러플레이트·탐색 효율**을 잃고, 과도하게 쓰면 **이해력·시니어 육성·버그 탐지·몰입감**이 손상됨 ### 조용한 쇠퇴 - 지표상으로는 **PR 수·기능 수·사이클 타임**이 개선되지만, **내면의 기술력·집중력·문제 해결력**은 서서히 약화 - 개발자는 **AI가 만든 구조를 이해하지 못한 채 승인만 클릭**하는 ‘버터 로봇’이 됨 - **Simon Willison**도 프로젝트에서 AI가 만든 기능을 검토하지 않아 “더 이상 내부 작동을 명확히 이해하지 못한다”고 언급 - 결국 **도구가 아니라 인간이 퇴화**하며, 이 변화는 **측정되지도 관리되지도 않음** - AI 의존은 중독처럼 진행되며, **조용하지만 실질적인 기술 쇠퇴**로 이어질 위험 존재 ## Comments ### Comment 52118 - Author: neo - Created: 2026-03-01T10:44:43+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47194847) - 나는 여전히 **직접 코드를 작성하고 머릿속에서 구조를 그려보는 과정**이 내 일의 즐거움 중 하나임 반복적이거나 귀찮은 리팩토링조차도 나에게는 의미 있는 과정임 이런 고된 순간들이 다음엔 더 나은 방법을 찾게 해주는 배움의 재료가 됨 언젠가 이 흐름이 다시 돌아올 거라는 **희망**으로 남아 있음 - 완전히 공감함. 이런 생각을 가진 사람이 많지 않은 것 같지만, 당신은 혼자가 아님 언젠가는 **스스로 선택하고 판단하는 능력**을 유지한 사람들의 가치가 다시 인정받을 것이라 믿음 - 사람들이 “AI가 테스트를 다 써줘서 편하다”고 말할 때 웃음이 나옴 테스트하기 어려운 코드라면 **추상화나 인터페이스**를 바꿔야 함 테스트는 코드의 첫 번째 재사용이므로, 테스트에서 불편하면 실제 사용에서도 불편할 것임 - 나도 직접 코드를 쓴 덕분에 **디버깅**이 훨씬 쉬워졌음 내가 작성한 코드일수록 어디서 문제가 생길지 머릿속에 그리기 쉬움 LLM은 로그를 아무리 던져도 이런 직관을 대신해주지 못함 - 나도 Copilot을 주로 프런트엔드 JavaScript 작업할 때 사용함 그런데 이 덕분에 **프런트엔드 생태계 개선의 동기**가 사라지는 건 아닐까 걱정됨 - 나 역시 코딩 그 자체를 사랑함 사람들이 LLM에 맡기고 싶어 하는 일조차 직접 하는 게 즐거움 기업들이 이런 **작은 즐거움**을 서서히 빼앗아가는 걸 보면 슬픔 - 지난 1년간 **Claude Code**를 많이 사용했는데, 최근 들어 동료들 사이에서 AI 사용에 대한 **감정의 변화**를 느꼈음 AI를 과도하게 사용할 때 생기는 **숨은 비용**에 대해 글을 썼고, 여러 출처의 데이터를 모아봤음 아직 명확한 데이터는 없지만 많은 개발자들이 같은 감정을 느끼는 듯함 - 흥미롭게 읽었음. “AGI로 가는 타임라인”에서 **Xeno’s Arrow**가 보이는 시각적 표현이 인상적이었음 다만 “소프트웨어는 단지 도구일 뿐”이라는 표현은 늘 이상하게 들림 도구가 사고를 대신할 수 있을 때, 그걸 여전히 “도구”라 부를 수 있을까? “프롬프트 중독”이라는 솔직한 표현은 좋았음. 하지만 **행동 중독**의 측면도 탐구해보면 좋겠음 - 글의 내용이 전부 공감됨. 특히 **속도감과 효율성의 중독성**이 문제임 빠르고 통제된 듯하지만, 서서히 통제력을 잃어감 진짜 어려운 건 “얼마나 지속 가능한 속도로 쓸 것인가”를 찾는 일임 - “**창작의 도파민 히트**”라는 표현이 인상 깊었음 나도 비슷한 주제로 [블로그 글](https://www.exploravention.com/blogs/soft_arch_agentic_ai/)을 썼는데, 리더가 조직이 **지속 가능한 균형**을 찾도록 돕는 관점에서 다뤘음 - 나도 같은 주제로 글을 쓰려다 자료 조사만 했음 **작업 기억(working memory)** 과 **보상 시스템**이 학습과 몰입에 미치는 영향에 대한 논문들을 찾아봤음 예를 들어 [Nature 논문](https://www.nature.com/articles/nrn.2016.43)에서는 작업 기억이 **도파민 반응성**을 가진다고 함 또 [Scientific American 기사](https://www.scientificamerican.com/article/why-writing-by-hand-is-better-for-memory-and-learning/)에서는 손으로 쓰는 행위가 더 많은 뇌 영역을 활성화한다고 함 결국 **보상이 낮은, 수동적인 작업**에서는 이런 인지적 이득이 거의 없다는 결론임 따라서 AI 사용의 기준은 “얼마나 고통스럽고 보상이 낮은 작업인가”로 삼는 게 좋다고 생각함 - 나는 여전히 **직접 코드를 작성**하고 그 결과를 완전히 이해함 속도 향상 따위는 상관없음. 이게 내 코드라는 **소유감**이 중요함 예전부터 외주를 줄 수도 있었지만, 그건 내가 코드를 읽기만 하는 사람이 되는 길이었음 - 만약 속도와 효율이 그렇게 중요했다면, 왜 개발자들을 **시끄러운 오픈 오피스**에 몰아넣었겠음? - 사실 **퇴화(atrophy)** 를 걱정할 필요는 없음. 필요 없어진 능력만 퇴화함 - 혹시 회사에서 이런 도구 사용을 **강요**받는지 궁금함. 나와 주변 개발자 대부분이 그런 압박을 느끼고 있음 - IT 세계에서는 늘 **빠른 변화와 적응**이 있었음. 이런 고집은 오래가지 않음 - 나도 퇴화가 일어나지 않을 수도 있다고 생각함 키보드를 써도 글씨를 잊지 않고, 커피를 사 마신다고 커피 내리는 법을 잊지 않음 - 80년대 초 **LSI-11 어셈블리**로 코딩을 배우며 모든 **8진수 오퍼코드**를 외웠음 하지만 FORTRAN 83을 배우자 생산성이 10배 높아졌고, 그때의 기술이 퇴화해도 전혀 후회하지 않음 언젠가 C++이나 Java 같은 언어도 마찬가지로 **필요 없어질 기술**이 될 것임 - 하지만 그건 **잘못된 비교**라고 생각함 오퍼코드를 다루며 쌓은 **논리적 사고력**이 이후 언어 학습을 쉽게 만든 것임 이런 **형식 언어(formal language)** 를 다루는 사고는 LLM 프롬프트 작성보다 훨씬 인지적으로 깊음 - 모든 프로그래밍 언어는 **정확한 계산 표현 언어**였지만, AI와의 협업은 **모호한 자연어**로 의도를 전달하는 과정임 영어로 의사코드를 쓰지 않는 이상, 정확성이 떨어짐 - 지금은 단순한 기술 변화가 아니라 **논리에서 직감(vibe)** 으로의 전환임 게다가 이번엔 **대체될지도 모른다는 두려움**이 함께 있음 - LLM이 코드를 짜면, 그건 **프로그래머가 아니라 PM**의 역할에 가까움 - AI를 적절히 사용하는 **세 가지 패턴**을 지키면 생산성과 학습을 모두 얻을 수 있음 하지만 **반패턴**을 따르면 도구 의존, 불안, 디버깅 능력 저하, 즉각적 보상 중독으로 이어짐 결국 **인지적 퇴화의 악순환**이 생김 - 최근 **AI 중심 기업**에 입사했는데, 수동 코딩이 거의 금지된 분위기임 Claude에게 API 문서를 읽히고 래퍼를 만들게 했더니, 결과물은 완벽했지만 정작 나는 **API의 감각이나 구조**를 전혀 이해하지 못했음 이렇게 “많이 할 수 있지만 아무것도 모르는 상태”가 **불편하고 공허함** 반사적 기억이 쌓이지 않음. 그래서 글의 내용에 깊이 공감함 - 여러 **AI가 작성한 사이드 프로젝트**를 진행 중임 1. 생존형 게임은 빠르게 완성됐지만 **애착이 없음** 2. MacOS용 웹앱은 동작하지만 **UI 품질**이 낮아 직접 손볼 예정임 3. 유틸리티 라이브러리는 직접 코드를 쓰지 않았지만 **이상하게 자부심**이 생김 다만 “좋다고 생각하지만 확신은 없는” 묘한 감정임 결론적으로, AI와 함께 만들더라도 **자신의 흔적**을 남겨야 성취감을 느낄 수 있음 - 나는 코딩을 시작한 지 8개월밖에 안 됐고, **AI 덕분에 배웠음** 하지만 Claude가 코드를 써줄 때 70%만 이해하고, 나머지는 그냥 넘어가게 됨 속도감은 중독적이지만, **전체 구조를 머릿속에 유지하는 능력**이 떨어짐 그래도 AI 없이는 지금의 결과물을 만들지 못했을 테니, 이 **트레이드오프**는 인정함 - 문제는 AI가 **비효율적인 습관**을 가르칠 수 있다는 점임 예를 들어 불필요한 **fallback 코드**를 남발함 경험이 없으면 그게 잘못된 줄 모를 수 있음 - 모델은 학습하지 않음. 재훈련은 느리고, 인간은 훨씬 빠르게 성장함 현재 LLM의 수준은 **인턴~주니어 개발자** 정도임 - 모델에게 **아키텍처 리포트**를 작성하게 하고 스스로 설명하게 하면 좋음 병목은 모델이 아니라 **우리의 검증 능력**임 - Claude Code에는 **“학습 모드”** 가 있어서, 코드에 “TODO(human)”를 남기며 설명해줌 - **보일러플레이트 자동화**를 위해 굳이 LLM을 써야 하는지 의문임 기존의 **메타프로그래밍**이나 스크립트로도 충분히 가능하지 않을까? 또, AI를 원칙적으로 거부하는 것도 일종의 **만족감 있는 선택**일 수 있음 - 다른 개발자들과 함께 작업하며 느낀 건, 많은 이들이 **도구 숙련도 부족**으로 속도를 잃는다는 것임 마우스와 키보드 사용, 파일 탐색, 명령어 검색 등 기본기가 약함 그래서 “그냥 LLM에게 물어보자”는 유혹이 커짐 하지만 진짜 해결책은 **도구 숙련도 향상**과 **템플릿 엔진 학습**임 - AI로 인해 **기술 퇴화**가 생길 수 있지만, 내가 집중하지 않는 영역이라면 괜찮다고 생각함 예를 들어 컴파일러의 내부 최적화까지 알 필요는 없음 - 하지만 **도메인 경계**를 명확히 나누긴 어려움 시스템 간 상호작용을 이해하려면 어느 정도 **컴파일러 동작 원리**도 알아야 함 - **Mitchell Hashimoto**의 접근이 합리적이라 생각함 신경 쓰고 싶지 않은 부분은 LLM에 맡기고, 진짜 중요한 문제에 **두뇌 자원을 집중**하는 방식임