생성형 AI 코딩 도구와 에이전트가 나에게는 효과가 없는 이유

작성일: 2025-06-14

사람들이 나에게 종종 생성형 AI 코딩 도구를 사용하는지, 그리고 이에 대해 어떻게 생각하는지 묻곤 한다. 그래서 반복적으로 같은 답변을 하기보다는, 내 생각을 한 번에 정리해두기로 했다.

제목만 봐도 이 글이 AI를 옹호하는 글이 아니란 걸 알 수 있을 것이다. 하지만 그렇다고 반AI적인 글도 아니다. 이미 AI에 찬성하는 사람들과 비판하는 사람들의 글은 많으니, 나는 내 입장에서 순수하게 기술적 관점에서 내 경험을 공유하고자 한다.

AI는 더 빠르지 않다

생성형 AI 도구가 내게 맞지 않는 가장 큰, 그리고 본질적인 이유는 나를 더 빠르게 만들어주지 못한다는 점이다. 정말 단순하다.

AI 코딩 도구를 이용해 나 대신 코드를 작성하도록 하는 것은 쉽다. 코딩 에이전트가 파일을 직접 수정해준다면 더 편할 것이다. 겉보기엔 아주 좋아 보인다.

하지만 결국 그 코드에 대한 책임은 나에게 있다. AI가 만든 코드를 무작정 내 프로젝트에 넣고 운에 맡길 수는 없다. 반드시 코드 리뷰를 하고, 코드의 동작과 목적을 충분히 이해해야만 내 코드에 포함할 수 있다. 그래야 향후 수정이나 확장이 가능하기 때문이다.

아쉽게도, 코드 리뷰는 많은 사람들이 생각하는 것보다 훨씬 어렵다. 남이 쓴 코드를 이해하는 데 드는 시간은 내가 직접 코드를 작성하는 데 드는 시간과 같거나, 그 이상이다. 우리 업계에는 "코드 작성보다 읽는 것이 더 어렵다"라는 말도 있다. 아마 조엘 스폴스키(Joel Spolsky)가 Things You Should Never Do, Part I에서 처음 정식으로 소개했을 것이다.

일부 사람들은 AI가 작성한 코드를 일종의 블랙박스처럼 간주해, 목적만 달성된다면 코드 리뷰 없이 바로 써서 생산성을 높일 수 있다고 말한다. 하지만 이는 매우 무책임하다. 코드가 오작동해도 AI가 책임지지 않는다. 누구나 자신의 이름이 걸린 코드에 대해 책임을 져야 한다. 위험을 AI에게 전가하는 건 말이 안 된다.

특히 계약, 법적 의무, 금전적 거래가 있는 프로젝트에서는 더욱 그렇다. 내가 전문가로 고용됐다면 전문가로서 행동해야 한다. AI 도구로 돈을 더 벌거나 시간을 줄일 수는 없다. 그렇게 하려면 퀄리티를 희생시켜야 하고, 리스크만 키울 뿐이다.

AI는 곱셈기가 아니다

생성형 AI 코딩 도구가 자신에겐 생산성 증폭기(multiplier)나 촉진제(enabler)라고 말하는 사람들이 있다. 자신은 AI 덕분에 더 빠르고, 더 어려운 문제도 풀 수 있다고 말한다. 하지만 이는 오직 본인 관점의 체감일 뿐, 이를 뒷받침하는 데이터는 없다. 어떤 이들은 리뷰를 대충 건너뛰거나 아예 하지 않아 시간을 아끼는 것일 수도 있다. 나는 이런 방식에는 반대다.

또 다른 흔한 주장은, 익숙하지 않은 언어나 기술을 쓸 때 생성형 AI가 도움된다는 것이다. 하지만 나는 새로운 것을 배우는 과정 자체를 매우 좋아한다. 배울수록 더 잘, 더 빨리 적응하게 된다. 최근에는 Rust, Go, TypeScript, WASM, Java, C# 등을 새로 익혀야 했지만, 이것을 AI에게 맡기고 싶지 않다. 왜냐하면 코드는 결국 내 책임이고, 이전에 언급한 이유들 때문이다. 반복이지만 강조하고 싶다.

AI가 만든 코드는 사람이 만든 코드와 다르다

최근 친구에게 이런 논리를 설명하자, 그럼 왜 사람이 만든 오픈소스 PR은 받아들이냐고 물었다. 그것도 내 코드가 아니지 않느냐는 질문이다.

사실 오픈소스 PR도 시간이 절약되는 건 거의 없다. 엄격한 리뷰를 해야하기 때문이다. 하지만 내 프로젝트에 관심 가지는 사용자가 버그를 신고하거나, 기능을 제안하거나, PR을 보내며 함께 소통할 때 새로운 아이디어가 샘솟고, 더 나은 결과를 낼 수 있다. 나는 이런 과정을 정말 좋아한다.

그 친구는, 여러 AI 에이전트를 병렬로 돌려 모든 오픈 버그에 PR을 보내게 하면 혁신이라며 추천했다. 하지만 그렇게 하면 비용이 드는 것은 물론, 코드를 병합하려면 결국 모든 PR을 내가 리뷰해야 하기에 더 느려질 수도 있다. 게다가 AI가 충분히 똑똑해 이슈를 완벽히 해결한다 해도(지금은 아니다), 병목은 사람(나)이다.

게다가 요즘은 AI로 만든 질 낮은 PR이 오기도 한다. 이런 코드를 읽다 보면 uncanny valley(불쾌한 골짜기) 현상이 있다. 이상한 부분에 대해 PR 제출자에게 질문하면, 잘 답하지 않는 경우가 많다.

AI는 인턴과 다르다

많은 AI 옹호자들은 AI 코딩 도구를 열정적인 인턴처럼 대하라고 한다. 하지만 정작 인턴과 함께 일해본 적이 없는 것 같다.

처음에는 인턴에게 일을 시키면 오히려 생산성이 떨어진다. 모든 걸 일일이 가르치고, 코드도 꼼꼼히 리뷰해야 하기 때문이다.

하지만 인턴은 배운다. 피드백이 쌓일수록 성장하고, 독립적으로 일하게 된다. 나중엔 진짜 팀원으로 받아들여진다.

반면 AI는 신규 기억상실(anterograde amnesia)을 앓는 인턴과 비슷하다. 매번 같은 수준에서 새로 시작할 뿐, 학습이 남지 않는다!

결론

이 글에서 내가 생성형 AI 코딩 도구를 쓸 때 겪는 기술적 문제들을 분명히 밝혔길 바란다.

나의 경험상, AI 코딩에서 공짜 점심은 없다. AI 덕분에 더 빠르거나 생산성이 높아졌다고 말하는 사람들은 품질 기준을 의도적으로 낮추거나, 그 외 다른 목적(예를 들어 AI를 팔아서 이익을 챙기는 것) 때문이라고 생각한다.

커피 한 잔?

내 블로그를 방문해주셔서 감사합니다! 이 글이 도움이 되었다면, 커피 한 잔으로 저를 응원해 주세요. 고맙습니다!

댓글 모음(일부 발췌)

#1 Doug:

최근 AI 코딩에 완전히 빠졌고, 생산성이 크게 늘었다고 느낀다. 하지만 프로젝트가 복잡해질수록 관리가 더 어려워져 문제 해결이 중요해지고 있다. 여전히 미래에는 AI가 중요하다고 생각하지만, 모두에게 꼭 맞는 선택은 아닌 것 같다는 점에는 동의한다.

#2 Miguel Grinberg:

"어떤 AI 코딩 도구를 써봤느냐"는 질문이 많은데, 실제로 다양한 도구(GPT-2 이후 모든 OpenAI, Anthropic 모델, Github Copilot, 자체 LLM 등)를 써봤으나 툴의 품질 문제가 아니라 내 방식과 맞지 않는다.

#3 MJ:

AI는 지금 많은 '대충 만든 코드(agentic slop)'만 쏟아내고 있으며, 아직 실전 투입 단계가 아니다.

#4 Joseph LeBlanc 등:

AI가 제안해준 개념(예: Howard-Curry Correspondence 등)이 프로젝트 아키텍처와 코드 품질 개선에 도움을 줬다는 경험담, 단 AI의 신뢰성에는 한계가 있다고 인정.

#7 Kyle Wild:

AI에 대해 충분한 실전 경험 없이 너무 강한 의견 아니냐는 반론.

#8 Jon:

AI는 간단한 보일러플레이트나 '자동 완성'에서 Intellisense와 유사해 생산성에 도움이 된다. 하지만 작업이 복잡할수록 한계가 있다.

#9 Jane (번역가):

코딩뿐 아니라 번역에도 같은 문제가 있다. LLM 결과물을 쓰면 오히려 속도가 느려지고, 제대로 편집하지 않으면 정체불명의 어색한 결과가 나오니 결국 생산성엔 도움이 안 된다.

그 외:

AI 도구가 장기적으로 발전하면, 지금이라도 AI 적응/활용 능력을 키우는 게 미래에 더 유리할 수 있다는 의견도 있다.

블로그 소개 및 기타 안내

블로그 운영자: Miguel Grinberg (아이랜드 거주 소프트웨어 엔지니어, 테크니컬 라이터)
주요 SNS, 오픈소스, 강의/책 등 다양한 채널 활동
리액트 메가튜토리얼, Flask 등 다양한 기술 글과 오픈소스 프로젝트 다수

(본 페이지의 댓글, 블로그 메뉴, 카테고리 및 기타 링크는 생략)