▲

AI 코딩이 초래하는 비용

 (tomwojcik.com)
6P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 개발자들이 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 의존은 중독처럼 진행되며, 조용하지만 실질적인 기술 쇠퇴로 이어질 위험 존재
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 나는 여전히 직접 코드를 작성하고 머릿속에서 구조를 그려보는 과정이 내 일의 즐거움 중 하나임
    반복적이거나 귀찮은 리팩토링조차도 나에게는 의미 있는 과정임
    이런 고된 순간들이 다음엔 더 나은 방법을 찾게 해주는 배움의 재료가 됨
    언젠가 이 흐름이 다시 돌아올 거라는 희망으로 남아 있음

    • 완전히 공감함. 이런 생각을 가진 사람이 많지 않은 것 같지만, 당신은 혼자가 아님
      언젠가는 스스로 선택하고 판단하는 능력을 유지한 사람들의 가치가 다시 인정받을 것이라 믿음
    • 사람들이 “AI가 테스트를 다 써줘서 편하다”고 말할 때 웃음이 나옴
      테스트하기 어려운 코드라면 추상화나 인터페이스를 바꿔야 함
      테스트는 코드의 첫 번째 재사용이므로, 테스트에서 불편하면 실제 사용에서도 불편할 것임
    • 나도 직접 코드를 쓴 덕분에 디버깅이 훨씬 쉬워졌음
      내가 작성한 코드일수록 어디서 문제가 생길지 머릿속에 그리기 쉬움
      LLM은 로그를 아무리 던져도 이런 직관을 대신해주지 못함
    • 나도 Copilot을 주로 프런트엔드 JavaScript 작업할 때 사용함
      그런데 이 덕분에 프런트엔드 생태계 개선의 동기가 사라지는 건 아닐까 걱정됨
    • 나 역시 코딩 그 자체를 사랑함
      사람들이 LLM에 맡기고 싶어 하는 일조차 직접 하는 게 즐거움
      기업들이 이런 작은 즐거움을 서서히 빼앗아가는 걸 보면 슬픔

  • 지난 1년간 Claude Code를 많이 사용했는데, 최근 들어 동료들 사이에서 AI 사용에 대한 감정의 변화를 느꼈음
    AI를 과도하게 사용할 때 생기는 숨은 비용에 대해 글을 썼고, 여러 출처의 데이터를 모아봤음
    아직 명확한 데이터는 없지만 많은 개발자들이 같은 감정을 느끼는 듯함

    • 흥미롭게 읽었음. “AGI로 가는 타임라인”에서 Xeno’s Arrow가 보이는 시각적 표현이 인상적이었음
      다만 “소프트웨어는 단지 도구일 뿐”이라는 표현은 늘 이상하게 들림
      도구가 사고를 대신할 수 있을 때, 그걸 여전히 “도구”라 부를 수 있을까?
      “프롬프트 중독”이라는 솔직한 표현은 좋았음. 하지만 행동 중독의 측면도 탐구해보면 좋겠음
    • 글의 내용이 전부 공감됨. 특히 속도감과 효율성의 중독성이 문제임
      빠르고 통제된 듯하지만, 서서히 통제력을 잃어감
      진짜 어려운 건 “얼마나 지속 가능한 속도로 쓸 것인가”를 찾는 일임
    • “창작의 도파민 히트”라는 표현이 인상 깊었음
      나도 비슷한 주제로 블로그 글을 썼는데,
      리더가 조직이 지속 가능한 균형을 찾도록 돕는 관점에서 다뤘음
    • 나도 같은 주제로 글을 쓰려다 자료 조사만 했음
      작업 기억(working memory) 과 보상 시스템이 학습과 몰입에 미치는 영향에 대한 논문들을 찾아봤음
      예를 들어 Nature 논문에서는 작업 기억이 도파민 반응성을 가진다고 함
      또 Scientific American 기사에서는 손으로 쓰는 행위가 더 많은 뇌 영역을 활성화한다고 함
      결국 보상이 낮은, 수동적인 작업에서는 이런 인지적 이득이 거의 없다는 결론임
      따라서 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에 맡기고,
      진짜 중요한 문제에 두뇌 자원을 집중하는 방식임
답변달기