에이전트 코딩은 함정이다 — AI에게 운전대를 맡길 때 잃는 것들

모두가 에이전트로 달려갈 때

요즘 개발자 트위터나 블로그를 보면 분위기가 한 방향으로 쏠려 있어요. "Claude Code로 하루에 PR 10개 머지했다", "Cursor 에이전트한테 시키면 알아서 다 한다", "이제 코드 안 짜고 그냥 시키기만 한다" 같은 글들이요. 그런데 이런 분위기에 정면으로 의문을 던지는 글이 나왔어요. 제목부터 도발적이에요. "에이전트 코딩은 함정이다(Agentic Coding Is a Trap)". 단순한 러다이트 주장이 아니라, 실제로 에이전트를 써본 개발자가 "왜 이 방식이 장기적으로 위험한가"를 짚는 글이라 한번 자세히 들여다볼 만합니다.

에이전트 코딩이 뭐냐면요

잠깐 용어 정리부터 할게요. 에이전트 코딩(agentic coding)은 AI에게 "이 기능을 만들어줘"라고 작업을 던지면, AI가 알아서 파일을 읽고, 코드를 쓰고, 테스트를 돌리고, 에러가 나면 고치고, 결국 완성된 결과물을 가져다주는 방식이에요. 사람은 처음에 지시를 내리고 마지막에 결과를 검토하는 정도만 하는 거죠. Claude Code, Cursor Composer, Devin, Codex 같은 도구들이 이런 방식을 지향합니다.

반면 자동완성형 AI 코딩은 우리가 직접 코드를 짜면서 AI가 다음 줄, 다음 함수를 제안해주는 방식이에요. GitHub Copilot의 원래 모습이 그랬죠. 사람이 운전대를 잡고 있고, AI는 옆자리에서 도와주는 형태입니다. 이 둘은 비슷해 보여도 본질적으로 매우 달라요.

글쓴이가 지적하는 함정

글쓴이의 핵심 주장은 이거예요. 에이전트에게 일을 맡기는 순간, 우리는 코드를 "이해하는" 게 아니라 "검수하는" 입장이 된다. 그게 왜 문제일까요?

첫째, 이해의 깊이가 다릅니다. 직접 코드를 짤 때 우리는 수많은 결정을 내리거든요. 이 변수는 왜 이 이름인지, 이 함수를 왜 분리했는지, 이 에러는 왜 여기서 잡는지. 이 결정들이 쌓여서 시스템에 대한 멘탈 모델이 만들어져요. 에이전트가 만든 코드를 검수만 하면, 표면적으로는 동작 여부만 보게 되고 그 아래 깔린 결정의 맥락을 놓치게 됩니다.

둘째, 버그가 더 깊이 숨어요. 사람이 짠 코드의 버그는 보통 "내가 뭘 잘못 생각했지?"를 추적하면 나와요. 그런데 에이전트가 짠 코드의 버그는 "이게 왜 이렇게 되어 있지?"부터 시작해야 합니다. 에이전트의 의도(라고 부를 수 있다면)를 역추적해야 하는데, 그건 본인이 처음부터 짜는 것보다 오래 걸리는 경우가 많아요.

셋째, 점진적인 능력 위축이 일어나요. 글쓴이는 GPS에 비유합니다. GPS를 오래 쓰면 길눈이 어두워지잖아요. 코딩도 마찬가지로, 에이전트에 의존할수록 "빈 화면 앞에서 처음부터 설계하는 능력"이 무뎌진다는 거예요. 단기적으로는 생산성이 오르지만, 장기적으로는 위기 상황에서 대응 능력이 떨어집니다.

그럼 AI를 쓰지 말라는 건가요

그건 아니에요. 글쓴이도 AI 코딩 도구를 쓰는 데 찬성합니다. 다만 "운전대를 누가 잡고 있는가"가 핵심이에요. 자동완성, 코드 설명 요청, 리팩토링 제안, 테스트 작성 보조 같은 건 사람이 운전대를 쥐고 있는 거예요. 반면 "이 기능 만들어줘" → 검수만 하기는 운전대를 넘긴 상태죠.

글쓴이는 "흐름(flow) 상태"의 중요성도 강조해요. 직접 코드를 짤 때 들어가는 그 몰입 상태에서 우리는 가장 많이 배우고, 가장 창의적인 해법을 찾아요. 에이전트에 일을 맡기고 "기다리는" 시간은 그 흐름을 깨뜨립니다. 결과물은 빨리 나오지만, 그 과정에서 우리가 얻는 학습과 통찰은 사라져요.

비슷한 우려들

이런 비판은 글쓴이만 하는 게 아니에요. 댄 루(Dan Luu), 사이먼 윌리슨 같은 개발자들도 비슷한 톤으로 "AI를 쓰되 능력을 잃지 마라"는 글을 써왔고요. 마틴 파울러는 "AI 코딩 시대에 가장 중요한 건 코드 리뷰 스킬"이라고 했어요. 한편 반대편에는 "이미 흐름은 정해졌다, 적응하지 못하면 도태된다"는 가속주의자들도 있죠. 양쪽 다 일리가 있습니다.

흥미로운 점은, 에이전트 코딩의 효과가 작업 종류에 따라 극명하게 갈린다는 거예요. 정형화된 CRUD, 보일러플레이트, 마이그레이션 스크립트 같은 작업은 에이전트가 잘해요. 반면 도메인 깊은 비즈니스 로직, 성능 최적화, 분산 시스템의 미묘한 동시성 문제는 에이전트가 자신만만하게 틀린 답을 내놓는 경우가 많습니다.

한국 개발자에게는

실무에 적용할 만한 몇 가지 원칙을 뽑아보면요. 첫째, 본인의 핵심 도메인 코드는 직접 짜세요. 회사의 가장 중요한 비즈니스 로직, 본인이 책임지는 모듈은 에이전트에 넘기지 말고 직접 손에 익혀두는 게 장기적으로 유리합니다. 둘째, 에이전트가 짠 코드는 라인 단위로 읽으세요. "동작하니까 머지"가 아니라, "왜 이렇게 짰는지 설명할 수 있는가"를 기준으로 삼아야 해요. 셋째, 주니어 시기에는 특히 조심하세요. 기초 체력이 만들어지기 전에 에이전트에 의존하면, 시니어로 성장할 때 결정적인 약점이 생길 수 있어요.

반대로 잘 활용할 수 있는 영역도 분명해요. 익숙하지 않은 언어로 PoC를 빠르게 만들 때, 보일러플레이트를 줄일 때, 테스트 케이스를 양산할 때, 리팩토링 후보를 탐색할 때는 에이전트가 강력한 동맹이 됩니다.