---
title: "에이전트 코딩은 함정일 수 있다는 꽤 불편한 주장"
published: 2026-05-03T22:52:07.000Z
canonical: https://jeff.news/article/2148
---
# 에이전트 코딩은 함정일 수 있다는 꽤 불편한 주장

이 글은 AI 코딩 에이전트가 생산성을 올리는 동시에, 개발자의 코드 이해력과 디버깅 능력을 갉아먹을 수 있다고 경고한다. 특히 '사람은 오케스트레이터만 하면 된다'는 흐름이 실제로는 더 높은 수준의 판단력을 요구하면서도, 그 판단력 자체를 약화시킬 수 있다는 모순을 짚는다.

## 'AI가 코딩하고 인간은 지휘한다'는 말의 빈틈

- 요즘 업계에서 미는 그림은 꽤 선명함: 전통적인 코딩은 죽고, 사람은 명세와 계획을 만들고, 에이전트가 구현한다는 흐름임
  - 작성자는 이걸 Spec Driven Development(SDD)와 에이전트 코딩 hype로 묶어 봄
  - 사람은 '좋은 취향'과 리뷰 능력으로 AI를 조율하고, 여러 에이전트 인스턴스를 돌리며 슬롯머신 레버를 계속 당기는 역할이 됨

- 문제는 이 방식이 사람과 코드 사이의 거리를 계속 벌린다는 점임
  - 생성되는 코드는 수천 줄 단위로 늘어나는데, 사람은 점점 '내가 쓴 코드'가 아니라 '내가 승인한 코드'를 보게 됨
  - 작성자는 이 흐름이 주변 시스템 복잡도 증가, 기술 퇴화, 벤더 종속, 토큰 비용 불확실성을 같이 데려온다고 봄

- 에이전트 코딩이 제대로 굴러가려면 역설적으로 아주 숙련된 개발자가 필요함
  - 아키텍처 수준에서 생각할 수 있고, 대량 생성 코드의 문제를 사고 나기 전에 잡아낼 수 있어야 함
  - 그런데 과도한 AI 사용이 바로 그 비판적 사고와 코드 감각을 약화시킨다는 게 글의 핵심 경고임

> [!IMPORTANT]
> 작성자가 인용한 Anthropic 쪽 표현은 '감독의 역설'에 가깝다. Claude를 잘 쓰려면 감독이 필요한데, Claude를 감독하려면 AI 과사용으로 약해질 수 있는 바로 그 코딩 실력이 필요하다는 얘기임.

## 이건 그냥 '추상화 단계가 올라간 것'과 다르다는 주장

- 흔한 반론은 '프로그래머가 또 한 단계 위 추상화로 올라갔을 뿐'이라는 말임
  - FORTRAN, 컴파일러, 클라우드가 나올 때도 비슷한 불안이 있었다는 식의 비교임
  - 작성자는 여기에 선을 긋고, 모호성이 높아진 걸 추상화가 높아진 것과 같게 보면 안 된다고 말함

- 과거 기술 전환의 우려는 대체로 추측이었지만, AI 코딩은 이미 영향이 관찰되고 있다는 게 작성자의 주장임
  - 주니어는 코드를 직접 다루며 배우는 마찰을 건너뛰고, 생성된 코드를 리뷰하는 쪽으로 밀려남
  - 리뷰는 중요하지만 학습의 전부가 아니고, 직접 구현·디버깅하면서 생기는 감각을 대체하기 어렵다는 얘기임

- 시니어도 안전지대는 아님
  - 작성자는 Simon Willison이 AI로 만든 앱에 대해 '무엇을 할 수 있고 어떻게 동작하는지에 대한 단단한 정신 모델이 없다'고 말한 사례를 듦
  - 기능을 추가할수록 추론이 어려워지는 건, 코드 소유감이 약해질 때 바로 나타나는 증상임

- LinkedIn에서 50명의 엔지니어를 이끄는 Sandor Nyako 사례도 나옴
  - 그는 팀에 '비판적 사고나 문제 해결이 필요한 작업'에는 AI를 쓰지 말라고 요청했다고 함
  - 이유는 단순함: 정확한지 의심할 능력이 없으면 AI 결과도 제대로 의심할 수 없음

## LLM은 우리가 급하게 만들 필요가 없던 부분을 가속한다

- 작성자는 좋은 개발자의 우선순위가 원래는 이랬다고 봄
  - 코드와 코드베이스의 관계를 이해하는 것
  - 문서화된 표준과 효율적인 방식에 맞추는 것
  - 읽을 수 있으면서도 필요한 만큼만 적은 코드
  - 그다음이 처리 속도

- 그런데 에이전트 코딩은 이 순서를 뒤집기 쉽다고 말함
  - 얼마나 빨리, 얼마나 많은 코드를 뽑아내느냐가 앞에 오고, 깊은 이해와 간결성은 뒤로 밀림
  - 속도는 높은 숙련도의 부산물이어야 하는데, 억지로 앞당기면 정확도가 떨어진다는 논리임

- 물론 LLM을 이해 중심으로 쓸 수도 있음
  - 작성자도 가능성 자체를 부정하지 않음
  - 다만 조직의 강제 도입, 토큰 사용량 중심의 hype, 대량 생성 워크플로는 실제로 그 방향으로 잘 안 간다고 봄

> [!WARNING]
> Anthropic 연구에서 공격적인 AI 도입이 디버깅 능력 47% 하락과 연결될 수 있다는 내용도 언급됨. 이 수치가 사실이라면, 팀 생산성 대시보드에 안 보이는 장기 부채가 꽤 크다는 뜻임.

## 코딩은 구현이 아니라 사고 과정이기도 함

- 글에서 제일 개발자답게 와닿는 대목은 '나는 코드로 계획한다'는 주장임
  - 어떤 개발자는 거대한 명세 문서를 먼저 쓰는 것보다, 타입을 만들고 함수 관계를 만져보고 폴더 구조를 바꿔보면서 문제를 이해함
  - OpenCode 제작자 Dax도 새롭거나 어려운 작업에서는 코드를 타이핑하는 과정 자체가 '무엇을 해야 하는지 알아내는 방법'이라고 말했다고 인용됨

- 프롬프트는 생각보다 자주 의도를 정확히 담지 못함
  - 사람이 말한 것과 실제로 원하는 것이 다를 때, LLM은 빈칸을 가정이나 환각으로 채움
  - 완벽해 보이는 프롬프트를 줘도, LLM은 컴파일러가 아니라 다음 토큰 예측 엔진이라서 없는 메서드를 만들어낼 수 있음

- 그래서 확률적 시스템을 결정적 시스템처럼 쓰면 모호성이 사라지지 않음
  - 오히려 더 많은 리뷰, 더 많은 재시도, 더 많은 토큰, 더 큰 코드와의 거리로 이어질 수 있음
  - 이 지점이 'AI가 다 해주면 편하다'는 말이 현장에서 자주 피곤해지는 이유임

## 벤더 종속은 비용 문제가 아니라 기술 생태계 문제로 번질 수 있음

- Claude 장애 때 일부 개발자와 팀이 멈춰 섰다는 사례도 언급됨
  - 예전에는 키보드와 텍스트 에디터만 있으면 실행할 수 있던 능력이, 갑자기 특정 모델 제공자 구독에 묶인 셈임
  - 팀의 기본 개발 흐름이 에이전트 중심이면 장애와 가격 정책이 곧 개발 속도가 됨

- 토큰 비용은 직원 월급처럼 예측하기 어렵다는 지적도 나옴
  - 모델 제공자는 현재 보조금이 많이 들어간 상태고, 새 모델은 높은 벤치마크와 hype 이후 실제 사용에서 비용·성능 논란을 겪는 패턴을 반복함
  - 같은 일을 하는데 토큰이 2~3배 더 든다는 불만이 나오는 것도 이 맥락임

- 작성자는 이걸 개인 도구 종속을 넘어 산업 전체의 역량 종속으로 봄
  - 코딩과 문제 해결이 원래 개인과 팀의 사고 능력에서 나오던 영역인데, 그 실행 비용이 토큰 소비로 바뀔 수 있다는 우려임
  - 로컬 LLM이 이 사용량을 흡수할 만큼 준비되지 않았다는 점도 리스크로 봄

## 대안은 AI 금지가 아니라 역할 강등

- 작성자는 LLM 자체를 거부하지 않음
  - 오히려 학습, 조사, 개념 탐색, 실험 범위 확장에는 매우 강력한 도구라고 봄
  - 문제는 AI를 주 구현자로 올려놓고 사람이 뒤늦게 검수만 하는 구조임

- 제안하는 워크플로는 AI를 보조 프로세스로 낮추는 것임
  - LLM으로 스펙과 계획을 만들되, 구현은 사람이 주도함
  - 작업에 따라 직접 코딩 비율은 20%에서 100%까지 달라질 수 있다고 함
  - 모델을 쓸 때도 의사코드를 자주 적어서 요청과 생성 코드 사이의 거리를 좁힘

- 대량 생성을 피하는 원칙도 중요함
  - 한 번에 앉아서 리뷰할 수 있는 양보다 많이 생성하지 않음
  - 너무 크면 작업을 쪼개고, 필요한 부분은 직접 리팩터링해서 결과를 이해함
  - 자기가 해본 적 없거나 스스로 못 할 구현은 교육 목적이 아니라면 에이전트에게 맡기지 않음

- 한 줄 요약은 이거임: AI를 Data가 아니라 Ship's Computer처럼 쓰자
  - 알아서 임무를 수행하는 동료 장교가 아니라, 필요한 정보를 꺼내주고 보조 작업을 처리하는 컴퓨터로 두자는 뜻임
  - 작성자는 이 방식이 더 빠르진 않아도, 더 나은 품질의 작업을 만든다고 봄

---

## 기술 맥락

- 이 글의 기술적 선택은 '에이전트에게 구현을 맡길 것인가'가 아니라 'AI를 개발 과정의 어느 위치에 둘 것인가'예요. 작성자는 AI를 주 구현자로 올리면 코드 이해가 뒤로 밀리기 때문에, 계획과 조사 쪽에 두고 구현 접촉면은 사람이 유지해야 한다고 봐요.

- 왜 이게 중요하냐면 코딩은 결과물을 타이핑하는 행위만이 아니기 때문이에요. 타입을 만들고, 함수 경계를 잡고, 폴더 구조를 바꾸는 과정에서 개발자는 문제의 모양을 이해하거든요. 이 마찰을 전부 에이전트에게 넘기면 나중에 리뷰할 기준도 약해질 수 있어요.

- 대안으로 제시된 방식은 꽤 실무적이에요. LLM에게 스펙 초안, 조사, 작은 코드 조각, 문서 탐색을 맡기되, 한 번에 생성되는 코드는 사람이 실제로 검토 가능한 크기로 제한해요. 그래서 속도보다 이해 가능한 단위를 우선하는 전략이에요.

- 벤더 종속 문제도 단순한 비용 이야기가 아니에요. 팀의 기본 개발 능력이 특정 모델 제공자와 토큰 가격에 묶이면, 장애나 가격 변동이 곧 엔지니어링 처리량에 영향을 줘요. 작성자가 말하는 위험은 도구 종속을 넘어 문제 해결 능력 자체의 외주화에 가까워요.

## 핵심 포인트

- 작성자는 에이전트 코딩이 속도 중심으로 흐르면서 코드 이해, 간결성, 유지보수성의 우선순위를 뒤집는다고 본다.
- AI를 감독하려면 강한 코딩 실력이 필요한데, 과도한 AI 사용이 바로 그 실력을 약화시킬 수 있다는 '감독의 역설'을 핵심 문제로 제시한다.
- 주니어뿐 아니라 시니어도 대량 생성된 코드를 충분히 이해하지 못한 채 기능을 쌓으면 정신 모델이 흐려질 수 있다고 지적한다.
- 대안으로 AI를 구현 주체가 아니라 계획, 조사, 보조 생성, 문서 탐색 도구로 낮춰 쓰자고 제안한다.

## 인사이트

AI 코딩 논쟁에서 진짜 쟁점은 '쓸까 말까'가 아니라 '어느 레이어까지 맡길 것인가'에 가깝다. 이 글은 생산성보다 코드와 계속 접촉하는 능력을 더 중요한 장기 자산으로 본다는 점에서, 팀 리더들이 꽤 진지하게 읽어볼 만하다.