Agentic Coding은 함정이다
핵심 요약
Agentic coding은 사람이 요구사항과 계획을 만들고, 여러 코딩 에이전트가 구현을 수행하는 개발 방식이다. 겉보기에는 개발자가 더 높은 추상화 계층으로 올라가는 것처럼 보이지만, 실제로는 생성된 코드와 사람의 이해 사이의 거리가 계속 벌어지는 구조가 될 수 있다.
이 글의 핵심 주장은 다음과 같다.
- 코딩 에이전트를 잘 쓰려면 숙련된 개발자의 감독 능력이 필요하다.
- 하지만 AI 과사용은 바로 그 감독 능력과 코딩 감각을 약화시킬 수 있다.
- 이 모순이 “감독의 역설”이다.
- LLM은 이해와 간결성보다 코드 생성량을 늘리는 방향으로 쓰이기 쉽다.
- 생성 코드가 많아질수록 리뷰, 수정, 토큰 비용, 인지 부채가 증가한다.
- AI는 구현 대체자가 아니라 계획 보조, 문서, 리서치, 제한적 위임 도구로 쓰는 편이 더 안전하다.
구조적 트레이드오프
코딩 에이전트는 강력하다. 하지만 그 대가도 명확하다.
- AI의 비결정성을 제어하기 위해 하네스와 주변 시스템 복잡도가 증가한다.
- 개발자의 직접 구현 경험이 줄어 기술이 위축될 수 있다.
- 특정 모델 제공자 장애가 팀 전체 개발을 멈출 수 있다.
- 직원 비용은 비교적 예측 가능하지만 토큰 비용은 변동성이 크다.
- 대량 생성 코드를 검토하려면 더 높은 수준의 아키텍처 감각이 필요하다.
즉, agentic coding은 “개발자가 코드를 덜 써도 되는 방식”이 아니라, “개발자가 더 많은 생성물을 더 빠르게 감독해야 하는 방식”이다.
단순한 추상화 상승이 아니다
AI 코딩을 “프로그래머가 더 높은 추상화 계층으로 올라가는 자연스러운 진화”라고 보는 해석이 있다. 하지만 글쓴이는 이 설명이 충분하지 않다고 본다.
고수준 언어, 컴파일러, 클라우드, 프레임워크도 추상화 상승이었다. 하지만 C++ 개발자가 Python으로 옮겼다고 해서 브레인 포그를 호소하지는 않았다. 시스템 관리자가 AWS를 쓴다고 해서 네트워킹 이해 능력을 곧바로 잃는다고 느끼지도 않았다.
이번 변화의 차이는 코드 작성과 디버깅의 마찰 자체가 사라진다는 데 있다. 코드를 직접 작성하며 생기는 이해, 시행착오, 작은 실패, 디버깅 경험이 줄어들면 코드 읽기와 판단 능력도 약해질 수 있다.
특히 주니어 개발자에게 치명적일 수 있다. 코드를 직접 쓰고 망가뜨리고 고치는 경험 없이 생성 코드를 리뷰하는 역할로 밀려나면, 리뷰에 필요한 감각 자체를 충분히 쌓기 어렵다.
감독의 역설
Anthropic 연구가 언급한 위험은 “감독의 역설”이다.
Claude 같은 코딩 에이전트를 효과적으로 쓰려면 감독 능력이 필요하다. 하지만 코딩 에이전트를 과사용하면 바로 그 감독 능력이 약화될 수 있다.
이 역설은 다음처럼 나타난다.
- 모델이 만든 코드를 검토하려면 직접 코드를 쓸 수 있어야 한다.
- 모델의 이상한 가정을 잡으려면 도메인과 코드베이스의 정신 모델이 필요하다.
- 생성 코드가 많아질수록 리뷰 부담은 커진다.
- 리뷰 부담이 커지면 더 많은 작업을 다시 에이전트에 넘긴다.
- 그 결과 사람의 이해는 더 멀어진다.
이것이 인지 부채(cognitive debt)다. 기술 부채는 코드베이스에 쌓이지만, 인지 부채는 개발자의 머릿속에 쌓인다. 나중에 누군가 “이 코드 왜 이렇게 됐나요?”라고 물었을 때, 만든 사람조차 제대로 설명하지 못하는 상태가 된다.
LLM은 잘못된 부분을 가속할 수 있다
소프트웨어 개발에서 항상 병목이 코드 타이핑은 아니다. 많은 팀에서 실제 병목은 다음에 있다.
- 요구사항 정리.
- 설계 결정.
- 이해관계자 합의.
- 보안 검토.
- 성능 검토.
- 개인정보와 법무 검토.
- QA.
- 롤아웃.
- 운영 피드백.
그런데 AI 코딩 도구는 가장 눈에 보이는 “코드 생성 속도”를 극적으로 높인다. 문제는 더 많은 코드가 항상 더 나은 결과를 뜻하지 않는다는 점이다.
AI 이전의 좋은 개발자 우선순위는 대체로 다음이었다.
- 코드와 코드베이스의 관계를 이해한다.
- 문서화된 표준에 맞춘다.
- 가독성을 유지하면서 필요한 코드량을 줄인다.
- 처리 시간과 운영 비용을 고려한다.
- 변경 범위를 최소화한다.
Agentic coding은 이 우선순위를 뒤집기 쉽다. 일정 시간 안에 더 많은 코드를 만들고, 나중에 리뷰와 수정으로 정리하는 방식이 된다. 이 과정에서 Over-Editing (과도한 코드 편집)과 비슷한 문제가 커질 수 있다.
코딩은 계획이다
일부 개발자에게 코딩은 구현이 아니라 사고 방식이다. 타입을 만들고, 함수 경계를 잡고, 폴더 구조를 만지고, 작은 실패를 보면서 무엇을 해야 하는지 이해한다.
즉, 코드는 계획의 산출물이 아니라 계획을 만드는 과정 자체다.
거대한 스펙을 먼저 쓰고 에이전트에게 넘기는 방식은 모든 작업에 맞지 않는다. 새롭거나 어려운 문제에서는 직접 코드를 만져보는 과정이 개념 형성에 필요하다.
LLM은 모호한 요구를 만나면 질문만 하지 않는다. 종종 가정으로 빈칸을 채운다. 그 가정이 틀리면 다음 비용이 발생한다.
- 더 많은 리뷰.
- 더 많은 수정 프롬프트.
- 더 많은 토큰 사용.
- 더 큰 diff.
- 더 큰 인지적 단절.
LLM은 컴파일러가 아니다. 결정적 시스템을 확률적 시스템으로 대체하고 모호성이 사라지기를 기대하면 안 된다.
벤더 종속과 비용 불확실성
Agentic coding은 특정 모델 제공자에 대한 의존을 키운다. Claude 장애 때 일부 개발자와 팀이 멈췄다는 사례는 이 리스크를 잘 보여준다.
과거에는 키보드와 편집기만 있으면 수행할 수 있던 기술이 이제는 모델 제공자 구독, 토큰 한도, API 상태에 의존하게 된다.
비용도 불확실하다.
- 모델 제공자는 가격과 한도를 바꿀 수 있다.
- 새 모델은 더 비쌀 수 있다.
- 같은 작업이 더 많은 토큰을 소모할 수 있다.
- 높은 추론 effort와 긴 컨텍스트는 비용을 빠르게 키운다.
- 팀 전체가 agentic workflow를 기본값으로 쓰면 비용 변동성이 커진다.
이는 단순한 SaaS 벤더 종속이 아니다. 산업 전체의 구현 능력과 디버깅 능력이 모델 제공자에게 의존하게 되는 문제에 가깝다.
Hacker News 논점
토론에는 반론도 많다.
일부 숙련 개발자는 에이전트형 코딩으로 35년간 손으로 코딩할 때보다 더 많이 배웠다고 말한다. AI는 잡다한 세부사항을 많이 아는 인턴처럼 작동하고, 사람은 시스템·기법·접근법을 결정하는 역할을 유지할 수 있다는 주장이다.
하지만 이 반론은 오히려 글의 핵심을 강화한다. 35년 경력자는 이미 학습 능력, 시스템 감각, 디버깅 경험, 판단 기준이 있다. 문제는 오늘 시작하는 주니어가 같은 기반 없이 에이전트를 관리하는 위치로 올라가는 경우다.
또 다른 논점은 생성 코드의 가독성이다. 생성 코드는 문법적으로 그럴듯하지만, 인간 작성자의 정신 모델에 기대는 의미적 일관성을 깨는 경우가 있다. 흔한 관용구를 incoherent하게 흉내 내며 버그를 숨길 수 있다.
큰 PR이 겉보기에는 괜찮지만 자잘한 버그를 많이 포함한 채 병합되는 사례도 오픈소스와 기업 모두에서 나타난다.
더 안전한 AI 사용 방식
글쓴이가 제안하는 방향은 AI를 버리자는 것이 아니다. 역할을 낮추자는 것이다.
AI를 Star Trek의 Data가 아니라 Ship’s Computer처럼 쓰라는 비유가 핵심이다.
적절한 사용 방식은 다음과 같다.
- 스펙과 계획 초안 생성.
- 브레인스토밍.
- 문서화.
- 리서치.
- 의사코드 작성.
- 작은 범위의 코드 생성.
- 테스트 케이스 아이디어.
- 리팩터링 방향 논의.
- 오류 메시지 해석.
피해야 할 방식은 다음과 같다.
- 한 번에 리뷰할 수 없는 양의 코드 생성.
- 직접 해본 적 없는 구현을 전부 위임.
- 이해하지 못한 코드를 병합.
- 모델 출력에 맞춰 설계를 끌려가기.
- 벤더 모델 장애 시 개발이 멈추는 구조.
실천 원칙
AI 코딩을 쓰더라도 다음 원칙이 필요하다.
- 한 번에 리뷰 가능한 코드량만 생성한다.
- 생성 코드가 많으면 작업을 쪼갠다.
- 직접 구현할 수 없는 것은 에이전트에게도 맡기지 않는다.
- 모델에게 전체 해법보다 계획, 의사코드, 대안을 요청한다.
- 최종 코드는 사람이 정신 모델을 가진 상태에서 병합한다.
- 어려운 문제는 직접 코딩하며 사고한다.
- 주니어에게는 AI보다 직접 디버깅 경험을 우선 제공한다.
- 팀 차원에서 토큰 비용과 벤더 장애 계획을 관리한다.
기존 노트와의 관계
이 노트는 Codex 내부 실험 (수동 코드 없는 5개월)이나 장기 실행 에이전트 (Long-Running Agents)와 반대되는 관점을 제공한다.
그 실험들은 강력한 하네스, 문서화, 린터, 테스트, 워크트리, 관측성, 에이전트 리뷰가 갖춰졌을 때 에이전트형 개발이 가능하다는 것을 보여준다.
반면 이 글은 대부분의 팀이 그런 하네스를 갖추기 전에 agentic coding을 기본값으로 삼을 때 생기는 리스크를 지적한다.
따라서 결론은 둘 중 하나가 아니다.
- 강한 하네스와 숙련된 감독자가 있으면 agentic coding은 강력하다.
- 하네스와 감독 능력이 없으면 agentic coding은 인지 부채를 만든다.