Lobsters 게시판에 vibecoding 태그가 달린 게시물이 올라와 114개의 추천과 71개의 댓글을 받으며 큰 화제를 모았다. 제목은 단 두 단어, “On AI”. 링크는 jcs.org를 가리키고 있지만(현재 접속 불가), 댓글창에서 벌어진 토론 자체가 개발자 커뮤니티의 뜨거운 관심사가 되었다.
댓글창 가장 상단에서 사용자 tmcb는 다음과 같은 비유를 남겼다:
“시시포스가 바위를 밀어 올리는 옆에서, 크레인으로 바위를 끌어 올리며 가끔 관객을 맞추는데도 신나서 구경하는 꼴이다. 시시포스가 분통을 터뜨리는 것도 당연하다.”
이 비유가 93개의 추천을 받은 이유는 수많은 프로그래머가 은연중에 느끼고 있던 불안감을 정확히 짚었기 때문이다. AI 코딩 도구가 너무 ‘유용’한 나머지, 자신이 정말로 무언가를 ‘배우고’ 있는지 의심스럽기 시작한 것이다.
이 글은 AI에게 코드 작성을 맡긴 후, 일상 업무 속에서 이루어지던 ‘덤으로 배우는’ 과정이 어디로 사라졌는지를 다룬다.
사진: 현대 프로그래밍 환경에서 AI 코드 생성은 표준 환경이 되었다. 하지만 생산성 향상 뒤편에서 배움의 기회는 간과되고 있다.
마법처럼 지워져 버린 배움의 단계
Lobsters 사용자 duck_tape는 토론의 가장 핵심적인 내용을 담은 댓글로 38개의 추천을 받았다:
“우리가 아직 직면하지 않은 현실이 있다. 우리의 배움 중 상당수는 일상 업무 속에서 ‘부수적으로’ 일어났다는 점이다. 임의의 기능을 구현하거나 새로운 빌드 대상을 위해 CI 환경을 설정할 때, 원하든 원치 않든 배움이 일어났다. 하지만 이제는 그 과정을 마법처럼 지워버릴 수 있다. 머릿속의 생각을 즉시 ‘생성’할 수 있게 되었다. 하지만 우리는 더 이상 ‘부수적으로 배울’ 수 없다. LLM이 버그를 지우는 동안 집중력을 유지하기란 매우 어렵다.”
‘부수적 학습(incidental learning)‘은 교육학의 생소한 개념이 아니다. 어떤 목적을 달성하는 과정에서 자연스럽게 다른 지식을 습득하는, 인간에게 가장 자연스러운 학습 방식이다. 프로그래밍은 오랫동안 이 구조에 깊이 의존해 왔다.
예를 들어 초급 개발자가 실제 버그 수정 작업을 맡았다고 하자. 그의 목표는 단지 버그를 고치는 것이지만, 그 과정에서 코드베이스의 구조를 이해하고, 디버거 사용법을 익히며, 특정 조건에서 버그가 발생하는 이유를 깨닫고, 관련 API 사용법을 자연스럽게 습득한다. 의도적으로 공부한 것이 아니라, 목표를 달성하는 과정에서 배움이 덤으로 일어난 것이다.
GitHub Copilot은 2022년 정식 출시된 이후 2025년 기준 2,000만 명 이상의 사용자를 확보했다. 마이크로소프트의 데이터에 따르면 사용자가 작성하는 코드의 46%가 AI 생성 코드이며, 일부 자바 프로젝트에서는 이 비율이 61%에 달한다. 이 숫자는 계속해서 증가하고 있다.
AI는 이 배움의 고리를 끊어 놓는다. AI의 작동 방식은 ‘실행을 통한 학습’의 고리를 정확히 우회한다. 프롬프트를 입력하면 코드가 출력될 뿐이다.
이러한 기회의 상실이 누적된 결과가 바로 마법처럼 사라진 배움의 단계다.
사진: AI 코드 완성은 개발자의 역할을 ‘창작자’에서 ‘검토자’로 전환시킨다. 검토는 직접 쓰는 것보다 빠르지만 배움의 깊이는 얕아진다.
왜 이것이 단순한 ‘Stack Overflow 2.0’이 아닌가
흔히 나오는 반론이 있다. 과거 Stack Overflow가 등장했을 때도 프로그래머가 문서를 읽지 않게 될 것이라 말했고, IDE 자동 완성이 나왔을 때도 API를 외우지 않게 될 것이라 경고했다는 점이다. 결과적으로 업계는 무너지지 않았다.
하지만 이 비유는 완전히 들어맞지 않는다. bendmorris는 댓글에서 명확한 차이점을 지적했다:
“Stack Overflow 코드를 복사해서 붙여넣으며 자신이 뭘 하는지도 모르고 버텨온 프로그래머들이 존재했던 건 사실이다. 저금리 시절의 고용 거품기에는 괜찮았을지 모르지만, 이제 그들이 LLM을 쓰면 평균 결과물의 품질은 올라갈 것이다. 하지만 좋은 결과라고 보지는 않는다. 인간으로서 실질적인 가치를 거의 더하지 못하고 있기 때문이다.”
Stack Overflow와 IDE 자동 완성은 이미 존재하는 지식 구조 위에서 효율을 높여주는 도구였다. 검색 결과를 이해하고 어떤 조각이 적합한지 판단해야 했으며, 자동 완성은 호출할 함수 이름을 이미 알고 있을 때만 유효했다. 실행 단계를 가속화했을 뿐, 이해 단계를 건너뛰지는 않았다.
반면 AI 코드 생성은 이해 과정 자체를 건너뛴다. 출력된 결과를 바라보는 것만으로 그 논리가 자동으로 습득되지는 않는다—특히 한 번도 본 적 없는 30줄의 추상화 패턴이라면 더더욱 그렇다.
인지심리학에는 ‘유창성 착각(fluency illusion)‘과 ‘바람직한 어려움(desirable difficulties)‘이라는 유명한 개념이 있다. UCLA의 인지심리학자 엘리자베스 비요크와 로버트 비요크 교수는 1990년대 연구를 통해 학습 과정이 ‘쉽게’ 느껴질수록 장기 기억 정착 효과는 가장 낮다는 사실을 증명했다. 반대로 기억해 내려 애쓰고 스스로 문제를 해결하는 식의 어려움이 동반될 때 장기적인 기억과 스킬 정착이 이루어진다.
AI 프로그래밍 도구가 제공하는 것은 극대화된 ‘유창함’과 최소화된 ‘수고’다. 이는 제품 디자인 측면에서는 뛰어난 선택이지만, 배움의 효과는 반감된다.
2025년 진행된 무작위 대조 실험은 이 가설을 직접 검증했다. 연구진은 학습자를 두 그룹으로 나누어 한 그룹은 ChatGPT의 도움을 받아 과제를 수행하게 하고, 다른 그룹은 전통적인 방식을 사용하게 했다. 결과적으로 AI의 도움을 받은 그룹이 당장의 과제 수행 성과는 좋았으나, 이후 진행된 독립 평가에서는 대조군보다 현저히 낮은 점수를 받았다. 이는 ‘인지적 외주화(cognitive offloading)’ 이론과 일치한다—답을 너무 쉽게 얻는 뇌는 정보를 저장하지 않는 선택을 한다.
”배우고 싶지만, 단순한 검토자로 남고 싶지는 않다”
Lobsters 댓글창에서 29표의 높은 추천을 받은 zetashift의 글은 커뮤니티 전반에 퍼진 피로감을 잘 표현하고 있다:
“리포지토리에
CLAUDE.md나AGENTS.md같은 파일이 있는 걸 보면 조건반사적으로 탭을 닫게 된다. … LLM으로 코딩을 한 후에는 내가 만든 것에 아무런 애착도 느끼지 못한다. 내가 이해했다는 느낌도 없고, 왠지 모르게 찝찝한 기분마저 든다.”
이러한 반응은 혼자만의 것이 아니다. 사용자 gered는 vibe coding을 해본 후의 느낌을 ‘찝찝하다(dirty)‘고 표현했으며, 사용자 lake는 자신의 이야기를 공유했다:
“1년 반 동안 오픈소스 프로젝트를 만들어 왔다. 그런데 누군가 AI를 써서 몇 달 만에 내가 도달하고 싶었던 위치에 오른 것을 보았다. 이런 도구가 존재하는 것은 기쁘지만, 시작하기 전에 있었다면 아예 시작하지 않았을지도 모른다. ‘손으로 짠 코드를 알아주는 사람이 있을 거야’, ‘오픈소스는 경주가 아니야’라고 스스로 다독여본다. 하지만 다른 사람이 가속기를 밟고 나를 앞질러 가는 것을 보는 것은 확실히 맥 빠지는 일이다.”
이러한 감정 뒤에는 간과하기 쉬운 구조적 문제가 숨어 있다. 10년, 20년의 경험을 가진 숙련된 프로그래머가 AI를 사용할 때는 출력 결과의 품질을 판단하고, AI의 오류를 잡아내며, 생성된 50줄의 코드를 10줄의 명확한 논리로 리팩터링할 지식적 기반이 있다. 하지만 초급자에게는 그런 판단력이 없다.
bendmorris의 요약은 날카롭다:
“Andreas Kling 같은 사람이라면 충분히 쌓인 스킬 덕분에 LLM으로 쉽게 전환할 수 있다. 품질을 담보하고 올바른 문제를 해결할 수 있기 때문이다. 하지만 처음부터 LLM을 사용하는 다음 세대 프로그래머는 어떻게 그 수준에 도달할 수 있는가? 스킬을 쌓아주는 기초 작업이야말로 가장 자동화하기 쉬운 작업이다. 업계 전체가 제 발등을 찍고 있는 셈이다.”
악역은 AI가 아니라, ‘이해가 필요 없는’ 워크플로다
여기서 신중한 구분이 필요하다. AI가 나쁜 도구라고 주장하려는 것이 아니다—그러한 입장은 무의미하며 사실과도 맞지 않다. AI 프로그래밍 도구는 생산성을 비약적으로 향상시켜 과거 10배의 인력이 필요했던 작업을 소규모 팀이 해낼 수 있게 해준다. 비전문가가 자연어로 간단한 앱을 만들 수 있게 된 가치도 분명하다.
문제는 도구의 작동 방식이 배움의 고리를 우회할 때, 배움이 지속되도록 관리할 주체가 누구인가라는 점이다.
현재 대부분의 AI 코딩 도구 상호작용 모델은 ‘요구 → 코드 생성 → 채택’으로 이루어진다. 도구의 목표는 완성일 뿐, 사용자의 이해를 돕는 것이 아니다.
논문 《Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development》(arXiv:2607.06101)는 이 문제를 체계적으로 분석하며 **‘지식 부채(Knowledge Debt)‘**라는 개념을 처음으로 제시했다:
AI 에이전트가 개발자가 완전히 이해하지 못한 코드 변경을 수행할 때, 이 이해의 공백은 시간이 지남에 따라 누적된다. 오늘 AI가 이해하지 못하는 버그를 고쳐주고, 내일 이해하지 못하는 최적화를 생성한다. 1년 후 시스템은 잘 돌아가지만, 당신은 더 이상 시스템을 유지보수할 수 없다—어떻게 작동하는지 모르기 때문이다.
이는 기술 부채(Technical Debt)보다 알아차리기 어렵다. 기술 부채는 코드 품질 지표나 정적 분석에 나타난다. 하지만 지식 부채는 지표가 없다—개발자의 머릿속에 숨어 있다가 혼자서 문제를 해결해야 하는 순간에야 비로소 드러난다.
생각을 외주화하는 대가
사용자 pyj의 질문은 매우 현실적이다:
“개인적인 문제는 AI를 사용한 후 기억에 남는 것이 훨씬 줄어들었다는 점이다. 작업은 끝낼 수 있지만, 예전만큼 배우거나 기억하지 못한다. AI 도구를 사용하면서도 학습 효과를 유지할 수 있는 좋은 전략이 있을까?”
이 질문에는 아직 명확한 답이 나오지 않았다. 일부 경험 많은 프로그래머들은 “먼저 Claude로 프로토타입을 만든 후, 직접 더 깔끔한 아키텍처로 리팩터링한다”와 같은 개인적 습관을 공유한다. 하지만 이를 위해서는 이미 ‘깔끔한 아키텍처’가 무엇인지 알고 있어야 한다.
Lobsters의 토론은 결국 두 가지 방향으로 갈렸다. 한쪽은 “손으로 하는 코딩이 목공이나 악기 연주처럼 ‘장인 정신의 영역’이 되어가고 있다”고 본다—전동 도구를 쓸지 손대패를 쓸지는 개인의 선택이며 옳고 그름이 없다는 입장이다. 다른 한쪽은 업계 전체의 보상 구조가 AI의 속도로 기울어질 때, 손코딩을 선택하는 비용이 점점 더 높아져 결국 극소수만이 감당할 수 있게 될 것이라 우려한다.
두 방향 모두 일리가 있지만, 핵심적인 질문을 피하고 있다: ‘덤으로 배우는’ 길 차단되었을 때, 신입 프로그래머는 이전 세대가 ‘덤으로’ 도달했던 수준에 이르기 위해 얼마나 먼 길을 돌아가야 하는가?
토론에서 아무도 완벽한 답을 내놓지 못했다. 하지만 이 질문을 던졌다는 사실 자체만으로도 대부분의 AI 제품 PR 문구보다 훨씬 더 가치 있다.
참고 링크:
- Lobsters: On AI (114△, 71 comments) (item?id=zljfgp/on_ai)
- Joshua Stein: On AI (jcs.org)
- Hacker News: On AI discussion
- Bjork & Bjork (2011): Desirable Difficulties in Theory and Practice
- Anthropic: ChatGPT as a Cognitive Crutch
- arXiv 2607.06101: Agents That Teach
- Bjork (1994): Memory and Metamemory Considerations in the Training of Human Beings
- GitHub Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness
