20년 경력의 소프트웨어 개발자 브렛(Brett)이 지난 8월 10일 자신의 블로그 브렛코드(Brett Codes)에 "나는 AI 사용을 그만둔다(I'm done using AI)"는 글을 올렸다. 그는 지난 18개월 동안 클로드 코드(Claude Code) 같은 LLM 기반 코딩 도구와 이른바 "에이전틱 프로그래밍"을 업무에 적극적으로 써 왔다. 그런데 정신 건강, 소프트웨어 품질, 환경과 사회에 미치는 비용을 이유로 코딩을 포함한 모든 영역에서 AI 사용을 끊기로 했다고 밝혔다.
그가 처음 LLM 코딩 도구를 접한 것은 몇 년 전 깃허브 코파일럿(Copilot)을 비주얼 스튜디오 코드에 붙여 쓰던 때였다. 자동완성을 강화한 정도로만 느껴져 산만하고 별 쓸모가 없다고 판단했다. 두 번째 계기는 동료가 초기 챗 인터페이스로 이슈를 조사하다가, 존재하지 않는 소프트웨어 라이브러리 버전을 LLM이 지어내는 바람에 그 답을 설치조차 할 수 없었던 사건이었다.
왜 회사 전체가 갑자기 AI 도구로 옮겨갔나
당시 다니던 회사에 AI를 신봉하는 인물이 제품팀장으로 들어오면서 상황이 바뀌었다. 그는 시스템 전반에 미칠 영향을 이해하지 못한 채 LLM 코딩 도구로 만든 변경 사항을 밀어 넣기 시작했고, 조직의 대화는 점점 "고객이 쓰는 소프트웨어에 AI를 어떻게 넣을 것인가"로만 좁혀졌다. 브렛은 이 흐름이 조직에 바이러스처럼 퍼지는 것을 지켜보면서도, 스스로는 수십 년간 해 온 방식대로 테스트를 쓰고 기능을 만들며 일했다.
지금 다니는 10인 미만 규모의 새 회사에서도 처음에는 타이핑스크립트, 루비, CSS 같은 언어를 예전 방식대로 코딩했다. 동료들이 커서(Cursor) 에디터에서 탭 완성과 인라인 프롬프트로 코드를 빠르게 짜는 모습을 신기하게만 지켜봤을 뿐, 네오빔(Neovim)과 tmux를 떠날 생각은 없었다. 2025년 초 경영진이 "이 AI 코딩이라는 것을 어떻게 생각하느냐"고 묻자 그는 "종종 틀리고 방해만 되며 코딩 속도를 높여 주지 않는다"고 답했다. 그러나 경영진이 한 콘퍼런스에 다녀온 뒤 LLM이 지식 노동 전체를 바꿀 것이라는 확신을 갖게 됐고, 곧 "AI 도구를 쓰지 않으면 뒤처진다"는 지침이 내려왔다.
AI에 얼마나 많은 일을 맡겼길래 이렇게 됐나
지침에 따라 브렛은 진지하게 AI를 써 보기로 했다. 커서는 리눅스에서 성능이 나빠 맞지 않았고, 대신 젯(Zed) 에디터의 사이드바 챗과 자동 편집 기능으로 LLM이 코드를 직접 바꾸게 하는 방식을 쓰기 시작했다. 2025년 중반에는 자동완성 중심 작업 방식이 에이전틱 편집으로 대체됐고, AI 회사들이 코딩 전용 모델과 실행 환경(harness)에 투자하면서 성능은 계속 좋아졌다. 2026년 중반에 이르러서는 리니어(Linear)의 작업 티켓을 클로드 코드에 연결해, 코드를 한 줄도 직접 고치지 않고 규모 있는 프로젝트를 처음부터 끝까지 완성하는 수준까지 왔다고 그는 적었다.
AI 챗봇에 의료 상담까지 맡긴 결과는 무엇이었나
코딩 도구를 쓰기 시작한 시점부터 브렛은 챗 기능도 함께 썼다. 책 추천, 커리어 조언, 사업 아이디어까지 친구에게 말하듯 AI에 털어놓았고, AI는 늘 그를 지지하는 답만 내놓았다. 문제가 된 것은 의료 상담이었다. 몸이 아픈 어느 날 밤, 그는 증상을 설명한 챗봇이 응급실에 가라고 하자 자정에 차를 몰고 병원에 갔다. 대기실에서 두 시간을 기다린 끝에 만난 의료진은 응급실에 올 필요는 없었다고 말했고, 이 방문에는 수백 달러가 들었다. 그는 이 일을 계기로 AI 챗과의 대화가 자신을 망상에 가까운 상태로 몰아넣고 있다는 것을 깨닫고 챗 사용은 중단했다.
코드 리뷰어로만 남는다는 것은 어떤 경험인가
챗은 끊었지만 코딩에서는 AI에 점점 더 많은 작업을 맡겼고, 어느 순간 그는 AI 실행 환경이 뽑아낸 결과물을 검토하고 품질을 확인하는 역할만 남았다. 처음에는 할 일을 빠르게 해치우는 데서 오는 쾌감이 있었지만, 곧 자신이 아무 목적 없이 티켓을 처리하는 "쳇바퀴 위의 햄스터"라는 사실을 깨달았다고 썼다. 문제를 발견할 때도 있었지만, AI가 쓴 코드의 양을 사람이 다 검토하는 것은 애초에 불가능했고, 그 검토조차 다른 AI에게 맡기는 구조였다. 그 결과 그는 게을러졌고, 신경을 덜 쓰게 됐고, 실력이 줄었으며, 우울해졌다. 직접 어려운 일을 하지 않으니 배움도 성장도 멈췄다는 것이다.
왜 소프트웨어 품질이 떨어진다고 판단했나
경영진과의 대화에서 그는 이제 개발자의 역할이 "AI가 실수를 덜 하도록 가르치고, 코드를 리뷰하고, 변경 사항을 테스트하는 것"이라는 말을 들었다. 그는 이 존재 방식을 견딜 수 없다고 느꼈다. AI를 많이 쓸수록 자신이 만드는 소프트웨어와의 거리도 멀어졌다. 직접 짜지 않은 코드는 AI에게 물어보지 않고서는 어떻게 작동하는지 설명할 수 없었고, 코드와 제품에 대한 애정도 옅어졌다. 그가 내린 결론은 좋은 소프트웨어는 기능이 얼마나 많은지, 얼마나 빨리 만들어졌는지가 아니라 그것을 만드는 사람들이 얼마나 정성을 쏟았는지에서 나온다는 것이었다. AI로 만들면 처음에는 빠르지만, 코드 품질과 사용자 경험은 그만큼 희생된다고 그는 판단했다.
결국 그가 꼽은 세 가지 이유는 무엇인가
브렛은 그만두기로 한 이유를 정신 건강, 소프트웨어 품질, 그리고 환경·사회적 비용 세 가지로 정리했다. 자신이 필요한 존재인지에 대한 실존적 불안, 소프트웨어 엔지니어라는 직업 자체가 몇 년 안에 사라질지 모른다는 두려움도 함께 왔다. 또한 데이터센터의 전력과 물 사용량, 그리고 AI 모델이 동의 없이 가져온 자료로 학습됐다는 사실을 알게 되면서, 이런 비용 대부분이 데이터센터가 자기 동네에 들어서기 전까지는 눈에 띄지 않는다는 점도 지적했다.
AI를 내려놓은 뒤 무엇을 하고 있나
가장 힘들었던 시기에 그는 게임 프로그래밍이라는 원래 취미로 돌아갔다. 플레이데이트(Playdate) 콘솔용 코딩을 다룬 자신의 책을 마무리하고, 작은 게임 몇 개를 만들었으며, 러스트(Rust)로 2D 루아(Lua) 게임 엔진 우사기(Usagi)를 직접 만들었다. AI 없이 기초로 돌아가 코드를 짜면서, 자신이 코딩을 얼마나 좋아하는지와 AI 사용이 스스로를 얼마나 나쁜 프로그래머로 만들고 있었는지를 동시에 깨달았다고 적었다. 그는 업무에서 AI를 "사소한 작업에만" 줄여서 써 보려 했지만 결국 거의 모든 일에 다시 의존하게 됐고, 그에게는 이 선택이 전부 쓰거나 전부 끊거나 둘 중 하나일 수밖에 없었다고 결론지었다.
그는 이 결정이 어떤 결과로 이어질지 모른다고 인정한다. 해고될 수도 있고, 별 탈 없이 넘어갈 수도 있다. 다만 이런 방식으로 계속 일하는 것이 자신의 삶을 망가뜨리고 있었다는 것만은 분명했다고 썼다. 앞으로는 프로그래밍을 배우려는 사람들을 돕는 글과 영상을 더 쓰고 싶다는 계획도 덧붙였다.