에이전트 코딩은 함정일 수 있다는 꽤 불편한 주장

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

• 요즘 업계에서 미는 그림은 꽤 선명함: 전통적인 코딩은 죽고, 사람은 명세와 계획을 만들고, 에이전트가 구현한다는 흐름임

  • 작성자는 이걸 Spec Driven Development(SDD)와 에이전트 코딩 hype로 묶어 봄
  • 사람은 '좋은 취향'과 리뷰 능력으로 AI를 조율하고, 여러 에이전트 인스턴스를 돌리며 슬롯머신 레버를 계속 당기는 역할이 됨

• 문제는 이 방식이 사람과 코드 사이의 거리를 계속 벌린다는 점임

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

• 에이전트 코딩이 제대로 굴러가려면 역설적으로 아주 숙련된 개발자가 필요함

  • 아키텍처 수준에서 생각할 수 있고, 대량 생성 코드의 문제를 사고 나기 전에 잡아낼 수 있어야 함
  • 그런데 과도한 AI 사용이 바로 그 비판적 사고와 코드 감각을 약화시킨다는 게 글의 핵심 경고임

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

• 흔한 반론은 '프로그래머가 또 한 단계 위 추상화로 올라갔을 뿐'이라는 말임

  • FORTRAN, 컴파일러, 클라우드가 나올 때도 비슷한 불안이 있었다는 식의 비교임
  • 작성자는 여기에 선을 긋고, 모호성이 높아진 걸 추상화가 높아진 것과 같게 보면 안 된다고 말함

• 과거 기술 전환의 우려는 대체로 추측이었지만, AI 코딩은 이미 영향이 관찰되고 있다는 게 작성자의 주장임

  • 주니어는 코드를 직접 다루며 배우는 마찰을 건너뛰고, 생성된 코드를 리뷰하는 쪽으로 밀려남
  • 리뷰는 중요하지만 학습의 전부가 아니고, 직접 구현·디버깅하면서 생기는 감각을 대체하기 어렵다는 얘기임

• 시니어도 안전지대는 아님

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

• LinkedIn에서 50명의 엔지니어를 이끄는 Sandor Nyako 사례도 나옴

  • 그는 팀에 '비판적 사고나 문제 해결이 필요한 작업'에는 AI를 쓰지 말라고 요청했다고 함
  • 이유는 단순함: 정확한지 의심할 능력이 없으면 AI 결과도 제대로 의심할 수 없음

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

• 작성자는 좋은 개발자의 우선순위가 원래는 이랬다고 봄

  • 코드와 코드베이스의 관계를 이해하는 것
  • 문서화된 표준과 효율적인 방식에 맞추는 것
  • 읽을 수 있으면서도 필요한 만큼만 적은 코드
  • 그다음이 처리 속도

• 그런데 에이전트 코딩은 이 순서를 뒤집기 쉽다고 말함

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

• 물론 LLM을 이해 중심으로 쓸 수도 있음

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

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

• 글에서 제일 개발자답게 와닿는 대목은 '나는 코드로 계획한다'는 주장임

  • 어떤 개발자는 거대한 명세 문서를 먼저 쓰는 것보다, 타입을 만들고 함수 관계를 만져보고 폴더 구조를 바꿔보면서 문제를 이해함
  • 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에게 스펙 초안, 조사, 작은 코드 조각, 문서 탐색을 맡기되, 한 번에 생성되는 코드는 사람이 실제로 검토 가능한 크기로 제한해요. 그래서 속도보다 이해 가능한 단위를 우선하는 전략이에요.

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