AI 코딩 도구가 개발자를 10배 더 생산적으로 만든다는 말을 자주 듣습니다. 하지만 일부 개발자들은 정반대의 경험을 하고 있습니다. 코드를 더 빨리 생성하지만, 오히려 더 많은 시간을 쓰게 되고, 더 피곤해지고, 심지어 우울해지기까지 한다고 말합니다. 무엇이 잘못된 걸까요?

개발자 커뮤니티에서 AI 코딩 도구에 대한 회의적 목소리가 커지고 있습니다. 소프트웨어 엔지니어이자 기술 블로거인 여러 개발자들이 자신의 경험을 공유하며, AI가 약속한 생산성 향상이 실제로는 예상치 못한 부작용을 가져온다고 지적합니다.

출처: AI Makes the Easy Part Easier and the Hard Part Harder – blundergoat.com

쉬운 부분은 더 쉬워지고, 어려운 부분은 더 어려워진다

핵심 통찰은 간단합니다. 코드 작성은 원래 개발자에게 쉬운 부분이었습니다. 어려운 부분은 항상 조사하고, 맥락을 이해하고, 가정을 검증하고, 왜 특정 접근법이 이 상황에 적합한지 판단하는 일이었죠.

AI에게 코드 작성을 맡기면 개발자에게는 어려운 부분만 남습니다. 그런데 문제는 여기서 시작됩니다. AI가 이미 답을 줘버렸기 때문에 개발자는 조사 단계를 건너뛰게 되고, 그 코드를 평가할 맥락 자체가 없어지는 거죠.

다른 사람이 쓴 코드를 읽고 이해하는 건 자기가 코드를 작성하는 것보다 훨씬 어렵습니다. AI가 생성한 코드는 바로 ‘다른 사람의 코드’입니다. 개발자가 잘하는 일(작성)을 기계에 넘기고, 더 어려운 일(읽기와 리뷰)만 남긴 셈입니다. 게다가 직접 작성하면서 쌓았을 맥락도 없이 말이죠.

“AI가 했어요”라는 말의 위험성

예전에는 개발자들이 구글로 검색했습니다. StackOverflow 답변이나 기사를 읽고, 자기 상황에 맞춰 검증한 후 결론을 내렸죠. 아무도 “구글이 해줬어”라고 말하지 않았습니다.

하지만 지금은 “AI가 해줬어요”라는 말을 듣기 시작했습니다. 이건 두 가지 중 하나를 의미합니다. AI를 과대평가하거나, 아니면 개발자가 스스로 결론을 내리지 않았다는 뜻입니다. 둘 다 문제입니다. 팀원이 StackOverflow 답변을 복붙했다면서 “구글이 내 코드를 작성했다”고 말한다면 걱정스러울 겁니다. AI도 마찬가지로, “정말로 붙여넣은 내용을 이해했나?”라는 질문이 필요합니다.

한 개발자는 개인 프로젝트에서 AI 에이전트에게 특정 파일에 테스트를 추가해달라고 요청했습니다. 그 파일은 요청 전에 500줄이었는데, 작업 후에는 100줄이 됐습니다. 왜 나머지 내용을 지웠냐고 묻자 AI는 “안 지웠다”고 답했습니다. 그러다 “그 파일은 원래 존재하지 않았다”고 말을 바꿨죠. git 히스토리를 보여주자 그제야 “파일이 존재하는지 먼저 확인했어야 했다”며 사과했습니다.

다행히 개인 프로젝트였고 git으로 복구할 수 있었습니다. 하지만 만약 환자 데이터를 다루는 헬스케어 시스템이나 금융 거래 코드였다면 어땠을까요? 이 경우 AI 지원이 시간을 절약한 게 아니라 오히려 더 많은 시간이 걸렸습니다. 에이전트와 논쟁하고 파일을 복구하는 시간이 직접 테스트를 작성하는 것보다 더 오래 걸린 겁니다.

학습 기회를 잃는다는 것

소프트웨어 엔지니어 Abhinav Omprakash는 Claude Code를 사용하면서 우울감과 무기력함을 느꼈다고 고백합니다. 화면에서 AI가 코드를 생성하는 걸 지켜보다가 휴대폰을 들여다보게 되더라는 거죠. “이 모든 게 무슨 의미가 있을까?” 결국 세 번째 시도 끝에 Claude Code를 삭제했고, 그때마다 코딩의 즐거움을 되찾았다고 말합니다.

코드 작성은 단순히 타이핑이 아닙니다. 문제 영역과 씨름하는 과정이고, 초기 아이디어가 작동하지 않는다는 걸 발견하는 과정이며, 생각하는 방법입니다. 컴퓨터 과학자 레슬리 램포트의 말처럼 “글을 쓰지 않고 생각한다면, 당신은 생각하는 척만 하는 것”입니다.

직접 작성한 코드는 검증하기가 훨씬 쉽습니다. 코드를 쓰는 과정이 맥락을 내면화하는 과정이기 때문입니다. 이 과정을 LLM에 아웃소싱하면 문제 영역을 내면화하는 단계를 건너뛰게 되고, 생성된 코드가 정확한지 확신할 수 없게 됩니다.

바이브 코딩(vibe coding)은 설계상 중독성이 있습니다. 지시를 입력하고, 그럴듯해 보이는 코드가 생성됩니다. 도파민이 분비되죠! 코드가 정확하지 않으면 한 번의 프롬프트만 더 보내면 되니까요. 하지만 이 과정은 뇌를 끄고 변경사항을 수동적으로 받아들이게 만듭니다.

번아웃과 스프린트의 악순환

한 엔지니어링 패널에서 반복적으로 나온 주제가 있습니다. “품질을 희생하면 일에 자부심을 갖기 어렵다”, “현재 속도에 대한 인정이 없다”, “스프린트로 빠르게 전달하면, 그 기대가 영원히 스프린트하라는 압박이 된다.”

이건 관리 문제이지 엔지니어링 문제가 아닙니다. 리더십이 팀이 한 번 빠르게 전달하는 걸 보면(아마도 AI 도움으로) 그게 새로운 기준선이 됩니다. 대화는 “어떻게 했지?”에서 “왜 매번 못 하지?”로 바뀝니다.

한 개발자는 이렇게 말합니다. “AI가 누군가를 10배 생산적으로 만든다고 주장할 때, 어쩌면 0.1배 엔지니어를 1배 엔지니어로 만드는 거일 수도 있습니다. 기술적으로는 10배가 맞죠. 하지만 그게 생산성 향상인지, 아니면 원래 얼마나 조사를 안 했는지가 드러난 건지 질문해야 합니다.”

번아웃과 낮은 품질의 코드는 AI가 가져다주는 생산성 향상을 모두 잡아먹습니다.

그럼 AI는 언제 도움이 될까?

흥미롭게도, 같은 개발자가 AI가 실제로 도움이 된 사례를 공유합니다. 프로덕션 버그가 발생했을 때였습니다. 대규모 릴리스 직후 사용자가 문의를 보냈는데 타임존 표시 버그였습니다. 변경한 개발자는 30분 후 수업을 가르쳐야 했고, 글쓴이도 이미 퇴근해서 집에 있었습니다.

AI를 조사 도구로 활용했습니다. 버그가 최근 변경사항에 기반했을 거라고 알려주고 재현 방법을 설명했죠. 결과적으로 더 이상 사용하지 않는 메서드가 현재 타임존 인식 메서드보다 우선순위를 갖고 있어서 타임존 변환이 제대로 안 되는 문제였습니다. 15분 안에 근본 원인과 해결 아이디어, 조사 노트를 GitHub 이슈에 정리했습니다.

개발자가 솔루션을 확인하고, 다른 팀원들이 테스트하고 배포했습니다. 긴급 대응도 없었고, 야근도 없었습니다. AI가 조사의 반복 작업을 했고, 사람이 맥락을 제공하고 검증했으며, 개발자가 솔루션을 확인했습니다. 이것이 AI가 어려운 부분을 돕는 방식입니다.

생각을 외주화하지 말기

개발자 Sophie Koonin은 “Stop generating, start thinking”이라는 글에서 핵심을 짚습니다. AI 지원 개발에서 대부분의 사람들이 놓치는 점은, 소프트웨어 개발에서 어려운 부분이 조사하고, 맥락을 이해하고, 가정을 검증하고, 왜 특정 접근법이 이 상황에 적합한지 아는 것이라는 사실입니다.

AI에게 쉬운 부분을 맡기면 일이 줄어드는 게 아닙니다. 어려운 일만 남습니다. 그리고 AI가 이미 답을 줬기 때문에 조사를 건너뛰었다면, 그 답을 평가할 맥락조차 없습니다.

우리는 사람으로서 배우고 개선하는 대신, 실수를 생각 없는 알고리즘에 아웃소싱했습니다. LLM은 우리의 형편없는 코드로 학습했고, 그 형편없는 실수를 더 빠르게 반복하도록 훈련받았습니다.

개발자로서 핵심 역량은 생각하는 능력입니다. 도구가 그것을 방해한다면 매우 조심해야 합니다. 궁극적으로 인생은 너무 짧아서 행복을 최적화하지 않을 수 없습니다. 전체 기능을 생성하는 게 더 생산적일 수도 있지만, 그것이 실존적 공포와 우울감을 유발한다면 장기적으로 생산적이라 볼 수 있을까요?

참고자료:

• Stop generating, start thinking – localghost.dev
• I Am Happier Writing Code by Hand – Abhinav Omprakash
• I’m An AI Skeptic—Here’s How I Use AI – Atomic Object
• I’m Behind and I Don’t Care – kukicola.io