Agentic Coding은 함정이다

• Agentic coding은 사람이 요구사항과 계획을 만들고 여러 코딩 에이전트가 구현하는 방식이지만, 생성·커밋되는 코드와 사람 사이의 거리를 계속 벌리는 구조임
• 이 방식은 숙련된 개발자가 아키텍처 수준에서 비판적으로 검토해야 성공하지만, AI 과사용은 그에 필요한 기술을 약화시키는 인지 부채(cognitive debt) 를 낳을 수 있음
• Anthropic 연구가 다룬 감독의 역설처럼 Claude를 효과적으로 쓰려면 감독할 코딩 역량이 필요하고, 코딩 에이전트 사용은 바로 그 역량을 약화시킬 수 있음
• LLM은 깊은 이해와 간결성보다 일정 시간 안에 생성되는 코드량을 늘리는 방향으로 쓰이기 쉬우며, 모호한 요구를 가정이나 환각으로 채워 더 많은 리뷰와 수정, 토큰 사용을 만들 수 있음
• Claude 장애와 토큰 비용 변동은 벤더 종속과 비용 불확실성을 드러내며, AI는 구현을 대체하는 오케스트레이터보다 계획 보조·문서·리서치·제한적 위임 도구로 쓰는 편이 이해 부채를 줄일 수 있음

구조적 트레이드오프

• 코딩 에이전트는 유용하고 강력하지만, 이미 정량적·실무적으로 따져야 할 트레이드오프가 있음
  • AI의 비결정성에서 오는 모호성을 완화하려면 주변 시스템의 복잡도가 증가함
  • 많은 개발자의 기술이 위축될 수 있음
  • Claude Code 장애처럼 특정 벤더 장애가 팀 전체를 멈춰 세울 수 있음
  • 직원 비용은 고정적이지만 토큰 비용은 계속 변동하고 증가할 수 있음
• 이 방식이 성공하려면 숙련된 개발자가 아키텍처 수준에서 비판적으로 사고하며, 수천 줄의 생성 코드에서 문제가 커지기 전에 발견할 수 있어야 함
• 하지만 AI 도구는 그에 필요한 비판적 사고와 인지적 명료성에 부정적 영향을 줄 수 있으며, 인지 부채(cognitive debt)가 커질 수 있음

단순한 새 추상화가 아님

• “프로그래머가 더 높은 추상화 계층으로 올라가는 것”이라는 해석만으로는 충분하지 않음
• 모호성이 높아지는 것이 곧 더 높은 수준의 추상화를 뜻하지는 않음
• FORTRAN, 컴파일러, 고수준 언어가 등장했을 때도 버그, 불안정성, 효율 저하, “마법” 증가를 걱정하는 반응은 있었음
• 과거의 우려는 대부분 새 기술을 받아들이면 무엇을 잃을지에 대한 규범적·이론적 걱정이었지만, AI 도구는 등장 후 몇 년 만에 이미 실질적 영향을 드러내고 있음
• 영향은 주니어 개발자에게만 국한되지 않고 10년 이상 경험을 가진 개발자에게도 나타남
• 주니어 개발자는 코드를 직접 다루는 과정이 줄고 생성 코드를 리뷰하는 역할로 밀려나면서 더 가파른 학습 곡선을 마주함
• 코드 리뷰는 중요하지만 학습 과정의 절반에 그치며, 코드를 직접 작성·디버깅하며 겪는 마찰이 사라지면 학습 능력이 크게 약해짐
• 이 현상은 연구에 시간이 걸리기 때문에 실시간 상황을 파악하려면 일화적 증거도 중요하지만, MIT Media Lab 보고서와 Microsoft 관련 보도처럼 뒷받침하는 자료도 있음

이번 변화가 다른 이유

• C++ 개발자가 Java나 Python으로 옮겼다고 해서 “브레인 포그”를 호소하지는 않았고, 시스템 관리자가 AWS로 옮겼다고 해서 네트워킹 이해 능력을 잃는다고 느끼지도 않았음
• 시니어 엔지니어가 관리 역할로 이동하며 코딩을 덜 하고 시간이 지나 “rusty”해지는 현상은 새롭지 않음
• 기존 경로에서는 수십 년 동안 코딩, 마찰, 문제 해결을 축적한 엔지니어가 문법보다 아키텍처 결정을 더 많이 다루는 역할로 이동했음
• 지금은 그런 장기적 경험 없이도 개발자들이 AI 에이전트를 관리해야 하는 더 높은 수준의 워크플로로 이동하고 있음
• 문제는 이런 워크플로가 수십 년의 경험으로 얻은 것과 같은 기술을 요구한다는 데 있음
• 시니어 엔지니어도 예외가 아님
  • Simon Willison은 거의 30년 경력의 개발자지만, 애플리케이션이 무엇을 할 수 있고 어떻게 동작하는지에 대한 “확고한 정신 모델”이 없으면 기능이 추가될수록 추론이 어려워진다고 밝힘

숙련된 오케스트레이터의 역설

• Anthropic의 최근 연구는 코딩 에이전트를 자주 사용할 때의 위험으로 “감독의 역설”을 다룸
• 핵심은 Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 AI 과사용으로 약화될 수 있는 바로 그 코딩 기술이 필요하다는 점임
• LinkedIn에서 50명의 엔지니어를 관리하는 Sandor Nyako는 조직 안에서 기술 위축이 퍼지는 것을 보고, 팀에 “비판적 사고나 문제 해결이 필요한 작업”에는 AI를 쓰지 말라고 요청함
• 그는 기술을 키우려면 어려움을 겪고 문제를 깊이 생각하는 근육을 길러야 하며, 비판적 사고가 없으면 AI가 정확한지 질문하기 어렵다고 봄
• “과사용”의 기준도 불분명하지만, 데이터 기반 연구와 일화적 자료는 몇 달 안에도 기술이 빠르게 약화될 수 있음을 보여줌
• 코딩 에이전트 사용은 에이전트를 잘 관리하는 데 필요한 기술 자체를 약화시키는 모순을 만듦

LLM은 잘못된 부분을 가속함

• 반드시 더 빠르게 코드를 작성해야 했던 것은 아님
• 특히 완전히 이해하지 못한 코드나 합리적인 시간 안에 리뷰할 수 없는 대량의 코드를 더 빠르게 만드는 것이 필요한 것은 아니었음
• AI 이전의 좋은 개발자 우선순위는 대체로 다음과 같았음
  • 코드와 코드베이스의 관계를 이해함
  • 문서화된 효율적 표준에 맞는지 확인함
  • 가독성을 유지하면서 목표 달성에 필요한 코드 줄 수를 최소화함
  • 처리 시간을 고려함
• Agentic coding과 LLM은 이 우선순위를 사실상 뒤집음
• 현재의 역량과 사용 방식은 일정 시간 안에 생성되는 코드량을 늘려 속도를 높이는 데 초점을 맞추는 경향이 있음
• 속도는 높은 숙련도의 자연스러운 부산물이지만, 강제로 밀어붙이면 정확도 저하로 이어짐
• LLM을 깊은 이해와 간결성을 높이는 방식으로 쓸 수는 있지만, 강제 도입과 조직 전반의 토큰 사용량 중심 과열은 실제 사용이 그렇게 흘러가지 않음을 보여줌

코딩은 계획이기도 함

• 일부 개발자는 코드로 더 잘 계획하고 더 잘 생각함
• 코드로 사고하고 작업하는 일은 무의미한 반복 노동이 아니라, 보안·성능·사용자 경험·유지보수성까지 기술적 수준에서 생각하게 만드는 과정임
• OpenCode를 만든 Dax는 Spec Driven Development 관련 인터뷰에서, 새롭거나 어려운 작업을 할 때 직접 코드를 입력하는 과정으로 무엇을 해야 하는지 알아낸다고 말함
• 그는 거대한 스펙을 먼저 쓰기보다 타입, 함수 간 상호작용, 폴더 구조를 직접 만져보며 개념을 잡는 방식을 선호함
• 사람이 말한 것이 실제 의도와 항상 같지는 않으며, LLM은 모호성을 가정이나 환각으로 채움
• 그 결과 더 많은 리뷰, 더 많은 에이전트 수정, 더 많은 토큰 사용, 생성물과의 더 큰 단절이 발생함
• 반대로 매우 명확하고 구조화된 프롬프트를 작성해도 LLM은 환각 메서드를 출력할 수 있음
• LLM은 컴파일러가 아니라 다음 토큰 예측 엔진이기 때문에, 결정적 시스템을 확률적 시스템으로 대체하고 모호성이 0이 되기를 기대할 수 없음
• AI에 적극적인 시니어 개발자들도 이런 단절을 커지는 문제로 보기 시작함

벤더 종속과 비용 불확실성

• Claude 장애 당시 일부 개발자와 엔지니어링 팀이 멈춰 섰다는 게시물들이 나왔음
• 일부 워크플로와 코딩 능력은 이미 특정 AI 벤더에 크게 의존하는 수준에 도달했음
• 예전에는 키보드와 텍스트 편집기만 있으면 수행할 수 있던 기술이 AI 모델 제공자 구독을 필요로 하게 됨

• 토큰 비용은 예측하기 어려움

  • 모델 제공자들은 크게 보조금을 받고, 모델 자체도 계속 변하는 기반 위에 있음
  • 새 모델 출시는 높은 벤치마크, 과열, 실제 사용 후 “너프됐다”는 불만과 같은 패턴을 반복함
  • 같은 일을 처리하는 데 2~3배 더 많은 토큰을 태운다는 불만도 뒤따름
  • 직원 비용은 알 수 있지만, 토큰 비용은 일별·월별·연도별로 예측하기 어려움
  • 팀 전체가 agentic coding을 기본값으로 사용하면 비용 계정은 매우 유연하게 유지되어야 함
  • Primeagen은 완전한 agentic workflow를 쓰면 “모델 제공자가 사실상 당신을 소유한다”고 말함
  • 토큰 소비 비용을 지불해야만 예전에는 비판적 사고와 문제 해결 능력으로 하던 일을 수행하는 산업 구조가 만들어질 수 있음
  • 이는 단순한 제품 벤더 종속이 아니라 산업 전체의 기술 역량에 대한 벤더 종속에 가까움
  • 재정적·지적 기반이 언제든 흔들릴 수 있으며, 로컬 LLM은 그 수준의 사용량을 흡수할 만큼 준비되지 않았음
  • 이 문제는 이론이 아니라 이미 보도되고 있으며, 모델 제공자들도 직접 조명하고 있음
  • Anthropic의 또 다른 연구는 디버깅 기술이 47% 급감했다고 밝힘
  • AI를 직장, 특히 소프트웨어 엔지니어링에 공격적으로 도입하면 빠른 결과를 위해 AI에 기대는 대신, 문제가 생겼을 때 디버깅하는 핵심 기술을 쌓지 못할 수 있음

AI의 역할을 낮추는 접근

• LLM은 학습과 역량 향상을 위한 강력한 도구가 될 수 있음
• 개념과 기법을 더 깊고 넓게 탐색하게 하고, 예전보다 더 적은 수고로 새 아이디어를 실험하게 해줄 수 있음
• 코드 생성 도구 자체는 새로운 것이 아님
  • Emmet, 자동완성, 스니펫은 코드를 직접 덜 쓰고 생성하기 위한 도구였음
  • COBOL도 MOVE, WRITE 같은 영어식 단어로 더 적은 작성량에 더 많은 명령을 담으려 했음
  • jQuery의 모토도 “write less, do more”였음
• LLM은 이런 코드 생성 도구의 또 다른 추가물로 볼 수 있음
• 중요한 차이는 LLM과 코딩 에이전트를 보조 프로세스로 활용하는 데 있음
• 생산성을 위해 개인의 기술을 희생하지 않고, 계획 단계의 브레인스토밍에는 AI를 활용하되 구현에는 계속 적극적으로 관여하는 방식이 가능함
• 필요할 때만 위임하면 생산성 이득을 얻으면서 이해 부채를 줄일 수 있음

일상적인 사용 방식

• LLM을 스펙과 계획 생성에 사용하되, 구현은 사람이 주도함
• 이는 “오케스트레이션” 워크플로를 뒤집는 방식이며, 작업에 따라 20%에서 100%까지 직접 코딩함
• 모델을 사용할 때도 자주 의사 코드를 작성해 요청과 생성 코드 사이의 거리를 줄임
• 모델은 임시 코드 생성, 대화형 문서, 리서치 도구로 활용함
• 책임 있는 위임 도구처럼 사용해 질문하고, 반복하고, 리팩터링하고, 접근법을 더 명확히 함
• 한 번에 리뷰할 수 있는 양보다 더 많은 코드는 생성하지 않음
• 리뷰하기에 너무 많으면 속도를 늦추고 작업을 쪼개며, 필요하면 직접 리팩터링해 최종 결과를 포괄적으로 이해함
• 직접 해본 적이 없거나 혼자서는 할 수 없는 구현을 LLM이나 에이전트에 맡기지 않음
• 예외는 교육이나 튜토리얼 목적이며, 그 결과물은 이후 버리는 경우가 많음
• 요약하면 AI를 Star Trek의 Data가 아니라 Ship’s Computer처럼 사용해야 함

더 빠르기보다 더 좋은 작업

• 모델의 생산성 향상은 실제로 존재함
• 동시에 작업을 직접적이고 자주 다루며 생기는 마찰과 이해도 실제로 중요함
• 코딩을 이해하지 못한 채 코딩을 민주화하려는 시도들은 반복적으로 실패해 왔음
• 코드를 이해하려면 코드와 직접 맞물려야 함
• 계속 코드에 관여하고 작성하지 않으면 그 이해와 연결을 잃을 수 있음
• 이해를 잃으면 에이전트를 더 잘 관리하는 능력도 약해지고, AI 코딩 단계는 이상하고 불필요하게 스트레스가 큰 과도기가 됨

더 큰 실험이 될 수 있음

• 현재 흐름은 장기적 영향을 충분히 이해하지 못한 채 스스로에게 실행하는 또 하나의 대규모 실험처럼 보임
• 소셜 미디어 도입 당시에도 장기적 함의를 이해하지 못했고, 이후 광범위한 주의력 결핍 등 여러 문제가 나타남
• 이번에는 더 위험한 것을 걸고 있음
• fast.ai를 만든 Jeremy Howard는 AI 에이전트에 전부를 거는 사람은 자신의 쓸모없어짐을 보장한다고 말함
• 모든 사고를 컴퓨터에 외주화하면 역량을 높이고 배우고 더 유능해지는 과정을 멈추게 됨