AI 코딩 번아웃, Claude Code 탓일까 조직 문화 탓일까

AI 코딩 번아웃이라는 말이 요즘은 농담처럼 들리지 않는다. 며칠 전 긱뉴스에서 Reddit 글 하나를 읽었는데, 제목부터 "이딴 짓은 이제 못 해 먹겠다"였다. 대기업에 들어간 지 보름 된 개발자가 쓴 글이다. 읽는 내내 남 일 같지 않아서 원글과 댓글을 따라가며 생각을 좀 정리해 봤다. 먼저 말해 두자면, 도구도 문제지만 더 무거운 책임은 조직 쪽에 있다고 본다.

하루 12시간 넘게 엔터만 누르는 개발자

글쓴이의 회사에서는 명세와 코드, 테스트, 제품 요구사항, 티켓, 보고서까지 거의 모든 걸 Claude Code가 만든다고 한다.

경영진은 이렇게 묻는다고 한다. 코드 작성은 이제 병목도 아닌데 왜 아직도 느리냐고. 그 말에 떠밀린 개발자들은 하루 12~13시간씩 AI에 지시를 넣고 엔터를 누른다. 주니어든 시니어든 다르지 않다. 그러는 사이 생성된 내용을 읽고 시스템을 이해하는 시간은 통째로 사라졌다.

글쓴이를 괴롭힌 건 AI를 쓰는 일 자체가 아니었다. 만들어진 코드가 어떻게 동작하는지 들여다볼 시간조차 주지 않는다는 점이었다. 버그를 직접 잡고 무언가를 끝냈다는 감각이 없으니 사람이 빠르게 닳는다고 했다.

물론 한 직장의 이야기라 업계가 다 이렇다고 말할 수는 없다. 그런데 Hacker News에 달린 댓글을 읽어 보면 비슷한 일을 겪은 사람이 생각보다 많다.

도구 탓일까, 조직 탓일까

댓글은 크게 두 갈래로 나뉘었다. 한쪽은 이게 Claude Code의 문제가 아니라 납품 압박과 기업 문화의 문제라고 했다. AI가 없던 시절에도 티켓을 최대한 빨리 쳐내기만 하는 외주 현장은 있었고, AI는 그 강도를 올렸을 뿐이라는 얘기다. 한 번에 한 작업씩 AI와 처리하고 남는 시간에 큰 그림을 고민하는 팀은 오히려 덕을 보고 있다는 경험담도 있었다.

다른 쪽은 LLM으로 코딩하는 과정 자체가 사람을 지치게 한다고 했다. 혼자 일하는데도 슬롯머신과 말다툼하는 기분이라 가장 지독한 버그보다 더 진이 빠진다는 댓글이 기억에 남는다. 처음 80%는 쉬워져도 마지막 20%는 더 어려워진다는 말도 있었다. 바이브 코딩으로 빨리 만든 만큼 이해하지 못한 코드도 빨리 쌓인다는 얘기로 들렸다.

개인적으로 가장 오래 곱씹은 건 이 문장이었다. 이해하는 속도보다 빨리 출시하려면 결국 이해를 포기할 수밖에 없다. 시스템을 머릿속에 그려 가며 일하던 사람일수록 지금 방식이 더 어색하게 느껴진다는 이야기도 같은 맥락에서 나온다.

나는 두 쪽 말이 다 맞다고 생각한다. 다만 어느 쪽 책임이 더 크냐고 묻는다면 조직 쪽이다.

"AI로 하면 금방 되잖아"라는 말

소규모 팀에서 일하다 보니 프론트엔드부터 인프라까지 혼자 겪어 볼 기회가 많았다. 그 경험 자체는 좋았는데 요즘은 "AI로 하면 금방 되잖아"라는 분위기 속에서 우선순위도 없이 일이 막무가내로 내려오는 경우가 부쩍 늘었다. 원글을 읽으며 자꾸 고개를 끄덕인 것도 그래서다.

AI가 코드를 빨리 써 주는 건 사실이다. 하지만 무엇을 먼저 하고 무엇을 하지 않을지는 AI가 정해 주지 않는다. 그 판단 없이 속도만 올라가면 빨라진 만큼 일이 더 쌓일 뿐이다. 원글 댓글에 나온 인수합병 사례처럼 20명 넘게 하던 일을 5명에게 맡기는 식의 기대도 같은 구조에서 나온다.

경영진 말대로 코드 작성은 이제 병목이 아닐 수 있다. 그렇다고 병목이 사라지지는 않는다. 사람이 이해하고 판단하고 검토하는 쪽으로 옮겨 갈 뿐이다. 그 시간을 빼앗으면서 속도만 요구하는 건 병 입구를 막아 두고 물을 더 부으라는 것과 다르지 않다고 생각한다.

그래도 도구가 결백한 건 아니다

다만 원글의 피로를 전부 조직 탓으로만 돌리고 싶지는 않다. 조직이 아무리 건강해도 LLM 중심으로 일하는 방식에는 사람을 지치게 하는 면이 있다.

개발 실력은 결국 문제를 붙잡고 씨름하면서 쌓인다. 버그 원인을 쫓고 구조를 머릿속에 그리며 왜 이렇게 동작하는지 납득하는 과정이 곧 성장이다. 프롬프트를 넣고 엔터를 누른 뒤 대충 훑어보는 일이 반복되면 그 과정이 통째로 빠진다. 결과물은 나왔는데 정작 내가 한 일은 없는 것 같은 공허함도 아마 여기서 오지 싶다.

댓글에도 비슷한 이야기가 꽤 있었다. 쓸 만한 기능을 완성해도 동료들이 "어차피 Claude가 만들었겠지" 하고 넘겨서 직접 보탠 부분까지 묻힌다는 사람이 있었다. 신입인데 선배에게 물으면 "Claude한테 물어봐"라는 답만 돌아와서 결국 퇴근하고 혼자 공부하며 자기가 바꾼 코드를 따라잡는다는 사람도 있었다. 해낸 일은 계속 쌓이는데 그게 내 것이라는 감각은 점점 옅어지는 셈이다.

기술 부채처럼 이해 부채라는 것도 있다고 본다. 코드가 생성되는 속도는 기계의 속도인데, 이해하는 속도는 여전히 사람의 속도다. 그 격차가 쌓이면 장애가 났을 때 아무도 원인을 설명하지 못하는 팀이 된다. 그래서 AI가 멈추면 아무도 자기 일을 못 하게 될까 봐 불안하다는 댓글도 괜한 걱정으로 들리지 않았다.

AI 코딩 번아웃, 결국 사람에게 남는 것

댓글 중에 오래 남은 건 한 스타트업 이야기였다. 거기서도 코드와 문서는 전부 AI로 만든다. 다만 작업마다 책임자가 있고, 그 사람은 무엇을 왜 했는지 설명할 수 있어야 한다고 했다. AI가 사람을 위해 일하는 거지 사람이 AI를 위해 일하는 게 아니라는 말이었는데, 원글의 회사와 이 스타트업을 가르는 차이가 그 한 줄에 다 들어 있는 것 같았다.

원글을 다 읽고 떠오른 것도 거창한 해법은 아니었다. 일을 맡기기 전에 무엇이 먼저인지 한 번만 같이 정해 줬다면, 결과를 들여다볼 시간을 일정에 조금만 남겨 줬다면 그 개발자가 보름 만에 그렇게까지 닳지는 않았을 것 같다. 신입에게 "Claude한테 물어봐" 대신 잠깐이라도 옆에 앉아 주는 선배가 있었다면 퇴근 후의 공부도 조금은 덜 외로웠을 테고.

AI 코딩 번아웃이 도구와 조직이 같이 만든 문제라면 풀 수 있는 쪽도 사람이 일하는 방식 어딘가에 있지 않을까 싶다. 적어도 "AI로 하면 금방 되잖아"라는 말이 우선순위를 대신하는 일만큼은 없었으면 한다. AI가 코드를 아무리 빨리 써 줘도 그 코드를 이해하고 책임지는 건 여전히 사람이니까.

원문 출처