[GN⁺] Agentic Coding은 함정이다

9bow · 5월 7, 2026, 12:30오후

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 에이전트에 전부를 거는 사람은 자신의 쓸모없어짐을 보장한다고 말함
모든 사고를 컴퓨터에 외주화하면 역량을 높이고 배우고 더 유능해지는 과정을 멈추게 됨

Hacker News 의견들

지난 몇 년간 에이전트형 코딩으로 일하면서, 35년간 손으로 직접 프로그래밍할 때보다 내가 쓰는 언어, 시스템, 도구에 대해 더 많이 배웠음. 시스템, 기법, 접근을 결정하는 능력은 여전히 내가 도구보다 훨씬 낫지만, 이 도구들은 잡다한 세부사항을 많이 아는 아주 박식한 인턴 같음. 작업하는 모든 것을 전부 알아야 한다는 주장은 매우 순진하며, 둘 이상 팀에서 일하면 완전히 이해하지 못하는 부분이 많음
- 보통 모든 것을 알 필요는 없지만, 내가 작업하는 프로젝트나 시스템에 대해 필요한 것은 빠르게 찾아내고 이해할 수 있어야 함. 사소한 문제라도 저수준 언어, 어셈블리, 덜 흔한 알고리즘, 네트워크 프로토콜 같은 추가 기술이 필요해지는 순간 해결하지 못해 멈춰버린 소프트웨어 팀을 많이 봤음
- 35년 경력이 있으니 새 지식을 얻는 학습 능력과 일반적인 틀이 이미 쌓여 있고, 에이전트형 코딩을 보조 도구로 쓰는 법도 알고 있음. 오늘 시작하는 주니어들은 그게 없어서 에이전트형 코딩에 과하게 의존하고, 자신이 모르는 게 뭔지도 모름
- 이 글은 "작업하는 모든 것을 전부 알아야 한다"고 말하는 게 아니라, 코드를 쓰는 능력과 코드를 효과적으로 읽는 능력이 본질적으로 연결돼 있다고 말하는 것임
- 여기서 문제는, 어떤 의미에서는 코드를 쓴 에이전트와 그 코드에 대한 질문에 답하는 에이전트가 같은 에이전트가 아니라는 것임. 원래 에이전트가 추론 과정을 남기지 않았다면 대체로 막막해짐. git-ai 같은 도구는 LLM 세션을 캡처하고 각 파일 편집을 특정 에이전트 동작과 연결함
25년 이상 된 시니어 개발자로서 최근 "5분만 들어와 줄 수 있나요"라는 식으로 회의에 던져졌는데, 중간에 아무 맥락 없이 끌려 들어가는 이런 회의를 정말 싫어함. 이 연동들을 만들 때 모델에 크게 의존했기 때문에 질문을 이해하는 데 매우 힘들었음. 인지 부채는 정말 현실이고, 개인적으로는 기술 부채보다 더 아픔. 기술 부채는 팀 전체가 공유하지만 인지 부채는 개인적이며, 그걸 만든 사람이 바로 나였다면 더 잘 알고 있어야 함
- 시니어 개발자라면 마음에 들지 않는 행동에 제동을 걸어야 하는 사람임. "흥미로운 질문이네요. 제 관점을 말하려면 맥락이 더 필요합니다"라고 하면 됨
- 그런 대우를 받았을 때 "이 질문에 제대로 답하려면 문서와 코드를 검토해야 합니다"는 완전히 괜찮고, 꽤 외교적인 답변임
- 자존심 내려놓고 신경 쓰지 않아도 됨. "모르겠네요, AI에 물어보겠습니다"라고 하면 간단함
생성된 코드에서 문제를 찾으려면 개발자가 신경을 써야 함. 많은 개발자들, 특히 대기업 개발자들은 이미 일에서 상당히 빠져 있고, 가능한 최소 노력으로 티켓을 닫고 책임을 넘길 방법만 찾고 있음
- 맞음. 생성된 코드는 인간 작성자의 정신 모델에 기대는 모든 의미적 기대를 어기기 때문에 읽기가 더 어려움. 생성된 코드는 언어적으로는 그럴듯하지만, 흔한 관용구를 자신도 모르게 incoherent하게 흉내 내는 경우가 많아서 실제 버그가 정상적인 인간이라면 떠올리기 힘든 방식으로 우연히 숨겨질 수 있음
- 큰 회사에서는 예외도 있지만, 많은 팀의 많은 개발자들이 신경 쓰는 것 자체로 처벌받기도 함
이 글은 조금 핵심을 비껴간 것 같음. AI를 많이 쓰면 기술 손실은 있음. 하지만 방 안의 어색한 코끼리를 인정하고 싶음. AI는 사람들을 너무 빠르게 만들고 있고, 코드를 만들어낸 전체 이해와 경험보다 빠른 산출물과 코드가 앞서고 있음. 우리는 사업 주도 개발의 오물탕에 있고, 나쁜 결정에 대해 충분히 가혹한 평판상 처벌이 돌아가지 않고 있음
- 기술 손실은 현실임. 하지만 나는 말 그대로 10년 동안 상사들에게 기술 손실을 불평해 왔음. C++ 표준을 줄줄 외우고 수백 가지 기능을 올바르게 쓰는 능력보다 좋은 아키텍처를 아는 능력이 더 높게 평가되는 시대가 될지도 모름
- "너무 빠르다"는 것의 또 다른 측면은 우리 문제들의 순서를 바꾼다는 점임. 일반적인 개발에서는 "정말 이걸 만들고 싶은가", "이렇게 하면 뭐가 잘못될 수 있는가"를 더 오가며 따지는데, 그 일부가 "나중에 누가 불평하는지 보자"로 옮겨가고 있음. 예방 1온스가 치료 1파운드보다 낫다는 것임
- 기업만 그러는 것도 아님. 오픈소스 프로젝트에서도 겉보기에는 괜찮지만 자잘한 버그가 천 개쯤 들어 있는 큰 PR이 병합되는 걸 자주 봄
더 빠르게 가려고 AI를 쓰는 건 잘못된 것을 최적화하는 것임. 내가 일한 모든 곳에서 기능을 구현하는 데 필요한 다른 모든 일에 비해 "코드 작성" 자체가 가장 적은 시간을 차지했음. 계획 의식, JIRA 티켓, 설계 문서, 동료 리뷰, 다른 팀들과의 합의, 코드 리뷰, 법무/개인정보/성능/접근성/QA 리뷰, 스테이징 숙성, 점진적 롤아웃까지 합치면 두 달이 걸린 기능에서 우리는 하루 걸린 부분을 5분으로 줄이려고 난리 치는 셈임
- 모델은 이제 의존성 업데이트, 빌드/배포 스크립트, 단위 테스트 같은 지루한 작업을 거의 완전히 자동화하는 데 매우 뛰어남. 예전에는 며칠 걸리던 일이 이제 몇 분 걸릴 수 있고, 여기서는 쉽게 50배 속도 향상이 가능함
- 설명한 모든 프로세스는 소프트웨어 엔지니어가 코드를 쓰는 시간을 극대화하기 위해 존재함. 소프트웨어 엔지니어가 충분히 싸지면 이런 프로세스의 많은 필요성이 사라짐
- 모든 회사가 그렇게 일하지는 않음. 빅테크에는 그런 허세 섞인 절차가 많지만, 작은 회사들은 빠르고 거칠게 움직일 수 있음
코드 품질은 결국 당신에게 달려 있음. 에이전트와 반복해서 작업해, 자신이 직접 썼을 때와 똑같은 품질의 코드가 될 때까지 다듬는 걸 막는 건 없음
- 내 기준의 코드 품질을 목표로 한다면, 그냥 내가 직접 쓰는 편이 더 빠르고 덜 답답했음
- 나는 내 코드 품질을 원하는 게 아니라 AGI 코드 품질을 원함. 그렇게 약속받았고, 제트팩과 하늘을 나는 자동차도 약속받았음
- 막는 건 없지만, 애초에 직접 쓰는 것보다 느림. AI 생산성 향상은 신화임
AI 도구는 접근법을 브레인스토밍하고 가끔 코드를 생성하는 데 쓰지만, 실제 타이핑은 내가 직접 함. 그러면 시간이 지나며 메커니즘과 프로그래밍 언어를 잊을 가능성이 줄어듦
- 나도 대부분은 구현 계획을 요청하되, 코드는 최소화하거나 아예 코드 없이, 또는 의사코드로 달라고 하고 실제 코드는 직접 작성함. 솔직히 전체가 LLM에게 코드를 쓰게 프롬프트하고 리뷰하는 일뿐이라면 오픈소스 메인테이너를 굳이 할 것 같지 않음
- 쓸 수 있는 접근 중 하나는 절대 코드를 대신 쓰지 말라고 요청하는 것임. 그러면 설명을 강제하게 되고, 이후 직접 코딩해 그 아이디어를 시도하면서 더 잘 이해하게 됨
- 나도 시스템 프롬프트에 전체 해법이나 코드를 절대 주지 말라고 설정해 뒀음. AI 제안의 50% 이상은 여전히 거절함
웃긴 점은 이 기술이 둘 중 하나라는 것임. 전문성 없이 위임은 할 수 있지만 틀렸거나 아예 불가능한지 알 수 없는 관리자용 기술이거나, 전문성은 있지만 그 전문성을 점점 잃게 될 코더용 기술임
약간 주제에서 벗어나지만, 글에서 Spec Driven Development가 미래라고 말하는 게 웃김. 기술적으로는 우리가 Waterfall을 하던 시절 이미 그렇게 했음. 좋은 문서가 있던 시절이 조금 그립기도 함
- 원격 모델들은 점점 더 비싸질 것임. 그들의 사업 미래는 추론 비용 개선에 대한 기대에 달려 있음. 이런 감옥에 스스로 묶이고 싶어 해서는 안 됨

원문

출처 / GeekNews

더 읽어보기

[GN] 함께 보면 좋은 글β

알려드립니다

이 글은 국내외 IT 소식들을 공유하는 GeekNews의 운영자이신 xguru님께 허락을 받아 GeekNews에 게제된 AI 관련된 소식을 공유한 것입니다.

출처의 GeekNews 링크를 방문하시면 이 글과 관련한 추가적인 의견들을 보시거나 공유하실 수 있습니다!

아래쪽에 좋아요를 눌러주시면 새로운 소식을 정리하고 공유하는데 힘이 됩니다~