AI 코딩을 멈춘 20년 차 개발자, 속도 뒤에서 잃은 것들

AI 코딩을 멈춘 20년 차 개발자, 속도 뒤에서 잃은 것들

AI 뉴스 썸네일

AI 코딩 도구로 더 빨리 일하면서도 개발 자체와 멀어질 수 있어요. 20년 경력의 개발자 브렛은 Claude Code로 프로젝트를 끝까지 만들 만큼 도구를 깊게 썼지만, 1년여 만에 모든 AI 사용을 멈추기로 했어요. 이 선택은 보편적인 결론보다 한 개발자가 겪은 생산성, 품질, 학습의 충돌을 보여주는 사례에 가까워요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
개발 방식	직접 구현하는 시간이 줄고 생성된 코드를 검토하는 시간이 늘었어요	속도 지표만으로는 개발자가 제품을 얼마나 이해하는지 알기 어려워요
학습과 건강	어려운 문제를 넘긴 뒤 학습 정체와 우울감, 실존적 불안을 겪었다고 밝혔어요	도구 도입이 개인의 집중력과 직업 만족도에 미치는 영향도 살펴야 해요
품질 관리	생성량이 사람의 검토 속도를 넘어섰다고 느꼈어요	코드 생성량보다 검토할 수 있는 변경 규모와 책임 범위가 더 중요할 수 있어요
사용 중단	제한적으로 쓰려고 했지만 다시 의존하게 돼 전면 중단을 택했어요	팀마다 허용 범위와 중단 기준을 미리 정할 필요가 있어요

1. 빠른 개발이 즐거운 개발을 대신하지 못했어요

브렛은 처음부터 AI 코딩을 좋아한 개발자는 아니었어요. GitHub Copilot의 자동완성은 산만했고, 초기 채팅 도구는 존재하지 않는 라이브러리 버전을 제안하기도 했어요. 회사가 AI 도구 사용을 요구한 뒤에는 Zed와 Claude Code를 본격적으로 쓰기 시작했어요. 2026년 중반에는 Linear의 작업을 Claude Code에 연결해 코드 한 줄을 직접 고치지 않고도 규모 있는 프로젝트를 마쳤다고 해요. 혼자 만들 때보다 빨랐고 생각할 일도 크게 줄었어요. 2

속도가 붙은 뒤 맡은 일은 달라졌어요. 직접 설계하고 구현하는 시간보다 생성된 기능을 확인하고 테스트하는 시간이 늘었어요. 생성 코드가 너무 많아 사람이 모두 읽기 어렵다고 느꼈고, 다른 AI 도구로 코드를 다시 검토하는 방식까지 썼어요. 작업 티켓은 빨리 닫혔지만 제품이 어떻게 움직이는지 설명하려면 도구에 다시 물어봐야 했어요. 자신이 만든 소프트웨어라는 감각도 옅어졌다고 적었어요.

728x90

이 경험은 AI 코딩 도구가 언제나 품질을 낮춘다는 실증 연구가 아니에요. 한 개발자의 긴 사용기이자 개인적인 판단이에요. 그래도 팀이 처리한 작업 수만 측정하면 놓치기 쉬운 문제가 분명히 보여요. 개발자가 변경 내용을 충분히 이해하는지, 검토할 수 있는 분량인지, 몇 달 뒤 직접 유지보수할 수 있는지도 함께 확인해야 해요.

어려운 작업을 넘기자 학습도 줄었어요

브렛이 가장 크게 느낀 손실은 학습이었어요. 까다로운 문제를 직접 붙잡는 시간이 줄면서 실력이 나빠졌다고 느꼈어요. 개발자의 역할이 생성 코드의 실수를 찾는 일로 좁아지자 무기력과 우울감도 겪었다고 밝혔어요. Linear 작업을 명령줄 도구에 전달하는 역할만 남는다면 개발자가 왜 필요한지 고민했고, 다른 직업을 알아봐야 할지 생각할 만큼 불안해졌어요.

취미로 게임 프로그래밍을 다시 시작하면서 반대 경험을 했어요. Playdate 게임 개발 책을 마무리하고 Rust로 2D Lua 게임 엔진 Usagi를 만들었어요. 코드를 직접 쓰자 프로그래밍을 좋아했던 감각이 돌아왔다고 해요. 그에게 수동 코딩은 낡은 방식이 아니라 문제를 이해하고 기술을 유지하는 과정이었어요.

일상 판단까지 맡긴 경험도 경계선이 됐어요

일반 AI 채팅에는 책과 진로, 사업 아이디어를 물었어요. 아플 때 증상을 설명하자 응급실에 가라는 답을 받았고, 자정에 병원을 찾았어요. 의료진은 집에서 쉬어도 된다고 안내했고 비용은 수백 달러가 들었다고 해요. 이 일은 의료 조언의 정확도를 평가한 사례가 아니지만, 친근한 답변을 실제 전문가의 진단처럼 받아들이면 위험할 수 있다는 개인적 경고예요. 이후 일반 채팅 사용은 먼저 끊었고 업무용 AI 코딩도 중단하기로 했어요. 2

제한적 사용은 자신에게 맞지 않았어요

사소한 작업에만 AI를 쓰려는 시도도 했어요. 테스트 전체를 몇 초 만에 만들 수 있다는 사실을 알고 나면 직접 작성하는 선택을 유지하기 어려웠다고 해요. 결국 사용 범위가 다시 넓어졌고, 자신에게는 제한적 사용보다 전면 중단이 현실적인 방법이라고 판단했어요.

이 결정에는 환경과 사회적 비용에 대한 문제의식도 들어 있어요. 데이터센터의 전력과 물 사용, 학습 자료의 권리 문제를 이유로 들었어요. 다만 원문은 관련 수치를 제시하거나 여러 연구를 비교하지 않아요. 환경·경제적 영향에 관한 부분은 저자의 가치 판단으로 읽는 편이 정확해요.

왜 중요한가요

회사에서 AI 코딩을 도입할 때 생산성은 쉽게 숫자로 만들 수 있어요. 완료한 작업 수와 배포 횟수는 바로 늘어날 수 있어요. 반면 코드 이해도, 학습 속도, 제품에 대한 애착, 검토 피로는 늦게 드러나요. 브렛의 경험은 이 네 가지를 도입 평가에 함께 넣어야 한다는 구체적인 질문을 남겨요. 2

팀은 모든 개발자에게 같은 사용량을 요구하기보다 작업별 경계를 정할 수 있어요. 생성 코드는 담당자가 설명할 수 있는 범위에서만 받는지, 변경량이 리뷰 가능한 크기인지, 핵심 설계와 보안 판단은 누가 맡는지 확인해야 해요. 도구 없이 문제를 푸는 시간이나 학습용 작업도 남겨둘 수 있어요. 사용 후 집중력과 직업 만족도가 계속 떨어진다면 사용량을 줄이거나 중단할 기준도 필요해요.

브렛의 전면 중단이 모든 개발자에게 맞는 답은 아니에요. 원문을 둘러싼 토론에서도 AI를 짝 프로그래밍처럼 제한해 쓰거나, 반복 작업과 사전 검토에만 활용한다는 반론이 나왔어요. 이 기록을 읽으면 실제 사용자가 어디에서 한계를 느꼈는지 알 수 있어요. 도구를 계속 쓰는 팀도 같은 위험이 없는지 점검할 수 있어요. 1

참고 자료

1. AI 사용을 그만두기로 한 이유 — GeekNews
2. I'm done using AI — Brett Codes