에이전틱 코딩은 함정이다 — 자율 AI에 코드를 맡길 때 개발자가 잃는 것들

요즘 개발자 트위터와 해커뉴스에서 가장 자주 보이는 단어가 “에이전틱 코딩(agentic coding)“입니다. 사람이 한 줄씩 짜는 게 아니라, AI 에이전트가 알아서 파일을 열고, 테스트를 돌리고, 커밋까지 찍는 그 워크플로우 말이죠. 그런데 몇 달 직접 써본 개발자들 사이에서 점점 같은 결론이 나오고 있습니다. “이거, 함정 아닌가?"

오늘은 이 회의론이 왜 지금 이 타이밍에 터지고 있는지, 그리고 자율 AI 코딩이 실제로 개발자에게 어떤 비용을 청구하고 있는지 정리해 봤습니다.

에이전틱 코딩이 뭐길래

먼저 용어부터 짚고 갑시다. 에이전틱 코딩은 단순한 코드 자동완성이 아닙니다. Cursor의 Composer, Claude Code, Devin, Aider 같은 도구가 대표적인데요. 사용자가 “결제 모듈에 환불 로직 추가해줘"라고 한 줄 던지면, AI가 알아서 관련 파일을 찾고, 의존성을 분석하고, 코드를 짜고, 테스트를 돌리는 일련의 흐름을 가리킵니다.

핵심은 자율성입니다. 개발자는 결과물을 검토하는 리뷰어 역할로 물러서고, 실제 손은 에이전트가 움직이는 구조죠. 이 패러다임이 처음 등장했을 때 모두가 흥분했던 이유도 분명합니다. “이제 진짜 10x 엔지니어가 가능하다"는 기대감이었으니까요.

진짜 빠른 게 맞을까

여기서 첫 번째 함정이 나옵니다. 속도의 착각입니다.

직접 키보드로 짜는 것과 AI가 짜는 걸 검토하는 것을 비교해 보세요. 표면적으로는 후자가 훨씬 빨라 보입니다. 30분 걸릴 작업이 5분이면 끝나니까요. 그런데 실제로 PR을 머지하기까지의 총 시간을 재 보면 이야기가 달라집니다.

검토 시간, 디버깅 시간, “왜 이렇게 짰지?” 추적 시간, 그리고 가장 큰 비중을 차지하는 맥락 복구 시간이 추가됩니다. 내가 짠 코드가 아니니까 한 달 뒤에 버그가 터지면 처음부터 다시 읽어야 하거든요. 결과적으로 누적 시간은 비슷하거나 오히려 더 길어진다는 회고가 늘고 있습니다.

코드가 아니라 부채를 만든다

두 번째 함정은 더 무겁습니다. 에이전트가 만들어내는 코드는 종종 “동작하는 부채”입니다.

테스트는 통과합니다. 기능도 됩니다. 그런데 6개월 뒤에 보면 비슷한 헬퍼 함수가 세 개씩 흩어져 있고, 네이밍 컨벤션은 파일마다 다르고, 에러 처리 패턴이 일관성이 없습니다. 에이전트는 매번 “지금 이 작업"에 최적화된 코드를 생성하지, 코드베이스 전체의 일관성을 책임지지 않거든요.

베테랑 개발자라면 이게 어떤 종류의 부채인지 압니다. 당장은 안 보이지만, 3년 뒤 신규 입사자가 “이 코드베이스 도대체 누가 짰어요?“라고 물을 때 비싸게 청구되는 그런 부채요.

가장 비싼 비용: 학습 곡선의 단절

저는 이 부분이 진짜 핵심이라고 봅니다. 주니어 개발자의 성장 경로가 끊긴다는 점입니다.

10년 차 개발자가 에이전트를 쓰는 건 괜찮습니다. 그 사람은 이미 머릿속에 시스템 모델이 있어서, AI가 짠 코드를 보자마자 “여기 N+1 쿼리 나오겠는데?“라고 잡아낼 수 있거든요. 검토 능력이 자산입니다.

문제는 1년 차 개발자입니다. 그 사람은 직접 삽질하면서 시스템 모델을 만들어야 하는 시기인데, 에이전트가 다 해주면 “코드는 머지되는데 왜 그렇게 됐는지는 모르는” 상태가 됩니다. 5년 뒤 시니어가 됐을 때 검토 능력이 비어 있는 거죠. 업계 전체로 보면 미래 시니어 풀이 얇아진다는 뜻입니다.

그럼 어떻게 써야 할까

그렇다고 에이전틱 코딩을 다 버리자는 건 아닙니다. 도구는 도구니까요. 다만 몇 가지 원칙은 합의가 모이고 있습니다.

첫째, 경계를 명확히. 보일러플레이트, 마이그레이션 스크립트, 테스트 스캐폴딩처럼 패턴이 뻔한 작업에는 에이전트가 강력합니다. 반면 도메인 로직, 동시성 처리, 보안 경계는 사람이 직접 짜는 게 여전히 안전합니다.

둘째, 검토를 진짜로 하기. AI 코드를 “어차피 테스트 통과했으니까"로 넘기는 순간 모든 함정이 시작됩니다. 라인 바이 라인으로 읽거나, 아니면 처음부터 쓰지 않는 게 낫습니다.

셋째, 스펙을 먼저 쓰기. 며칠 전 화제가 됐던 “specsmaxxing” 흐름처럼, YAML이든 마크다운이든 명세를 사람이 먼저 정확히 쓰고 그 안에서만 에이전트가 움직이게 하는 방식이 부채를 가장 줄여준다는 보고가 많습니다.

마무리

에이전틱 코딩이 함정이라는 건, 도구가 나쁘다는 뜻이 아닙니다. “AI가 짜주니까 나는 생각을 덜 해도 된다”는 그 한 발의 방심이 함정이라는 거죠. 코드를 짜는 행위는 사실 코드를 짜는 게 아니라 시스템을 머릿속에 짓는 행위였는데, 그 부분을 외주 주는 순간 개발자가 가진 가장 비싼 자산이 같이 사라집니다.

여러분의 워크플로우는 어떤가요? AI에게 핸들을 얼마나 넘기고 있는지, 그리고 그 대가로 무엇을 잃고 있는지 한번 점검해 볼 시점입니다.