AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

AI 코딩 에이전트를 잘 쓰려면 코딩 실력이 필요한데, AI가 그 실력을 갉아먹는다

AI 에이전트에 코딩을 맡기는 방식이 확산되고 있습니다. 그런데 Anthropic이 자체 연구에서 스스로 인정한 것처럼, 이 방식을 잘 쓰려면 코딩 실력이 필요하고, 그 코딩 실력은 AI를 많이 쓸수록 퇴화합니다.

사진 출처: larsfaye.com

개발자 Lars Faye가 에이전트 코딩(Agentic Coding)의 구조적 문제를 짚었습니다. Claude Code, Cursor 같은 도구로 AI 에이전트에 코딩을 전적으로 맡기는 흐름이 개발자의 스킬을 빠르게 갉아먹고 있다는 내용입니다. MIT, Microsoft의 연구와 Anthropic 자체 데이터가 이미 이를 뒷받침하고 있습니다.

출처: Agentic Coding is a Trap – larsfaye.com

감독의 역설

에이전트 코딩 워크플로우의 핵심 논리는 이렇습니다. 개발자는 요구사항을 정의하고 계획을 세운 뒤, AI 에이전트가 생성한 코드를 검토하고 방향을 잡는 ‘오케스트레이터’ 역할을 맡는다는 것입니다. 그런데 여기에 불편한 역설이 있습니다.

Anthropic이 자사 연구에서 스스로 인정한 내용입니다. AI를 효과적으로 사용하려면 감독이 필요하고, 감독을 잘 하려면 코딩 실력이 필요합니다. 그런데 AI를 많이 쓸수록 그 코딩 실력이 퇴화한다는 겁니다. Anthropic은 이를 ‘감독의 역설(paradox of supervision)’이라 불렀습니다.

수치도 나왔습니다. Anthropic의 별도 연구에서 AI를 적극 활용한 개발자의 디버깅 실력이 47% 하락한 것으로 나타났습니다. LinkedIn의 소프트웨어 엔지니어링 디렉터 Sandor Nyako는 이 현상을 조직 전체에서 목격하고, 팀원들에게 비판적 사고가 필요한 작업에는 AI를 쓰지 말라고 요청했다고 합니다.

이번엔 정말 다르다

새로운 기술이 등장할 때마다 “이걸 쓰면 실력이 떨어지지 않을까”라는 걱정은 늘 있었습니다. FORTRAN이 나왔을 때, 컴파일러가 도입됐을 때도 마찬가지였습니다. 하지만 그 걱정들은 결국 이론에 그쳤습니다.

Lars는 지금은 다르다고 말합니다. C++에서 Python으로 넘어간 개발자는 뇌 안개(brain fog)를 호소하지 않았습니다. 서버 관리자가 AWS로 이동한다고 네트워킹 감각을 잃지 않았습니다. 반면 AI 코딩 도구에 대한 스킬 퇴화는 이미 수개월 만에 실증되고 있습니다. MIT, Microsoft 등의 연구들이 잇따라 이를 뒷받침하고 있고, 30년 경력의 개발자 Simon Willison도 자신이 만든 앱의 전체 구조에 대한 ‘확실한 정신 모델’을 잃어가고 있다고 밝혔습니다.

더 근본적인 문제도 있습니다. 시니어 엔지니어가 수십 년의 코딩 경험을 바탕으로 아키텍처 판단을 내리는 것과, 그 경험 없이 바로 AI 에이전트를 감독하는 역할을 맡는 건 전혀 다른 이야기입니다. 에이전트 코딩이 전제하는 ‘숙련된 오케스트레이터’는 코딩을 오래 한 사람이어야 하는데, 지금의 흐름은 그 경험을 쌓을 기회 자체를 줄이고 있습니다.

코딩은 도구가 아니라 사고다

Lars가 지적하는 또 하나의 핵심은 코드를 쓰는 행위 자체의 인지적 역할입니다. 오픈소스 코딩 에이전트 OpenCode를 만든 Dax조차 “새로운 기능을 개발할 때 코드를 직접 타이핑하는 과정이 내가 무엇을 해야 할지 파악하는 방법”이라고 말했습니다. 타입을 정의하고, 함수 구조를 잡아보고, 폴더 구조로 개념을 탐색하는 것 자체가 설계 작업이라는 것입니다.

LLM에 요청을 보낼 때, 내가 하고 싶은 말과 모델이 이해하는 말 사이에는 언제나 간극이 있습니다. 그 간극을 LLM이 추측이나 환각으로 채우면 더 많은 수정과 더 많은 토큰 소비로 이어집니다. 결정론적 시스템인 컴파일러를 확률론적 시스템인 LLM으로 대체한다고 해서 모호함이 사라지진 않습니다.

에이전트가 가속하는 건 속도지, 이해가 아니다

Lars에 따르면 좋은 개발자의 우선순위는 코드 이해 → 표준 준수 → 간결함 → 속도 순이었습니다. LLM은 이 순서를 정확히 뒤집습니다. 속도를 극대화하는 방향으로 설계됐고, 조직들도 토큰 사용량을 생산성 지표로 삼으며 그 방향을 강화하고 있습니다.

Claude Code 장애가 있던 날 LinkedIn에서는 팀 전체가 업무를 멈췄다는 포스팅이 잇따랐습니다. 키보드와 텍스트 에디터만 있으면 할 수 있었던 일이 AI 모델 구독 없이는 불가능해진 것입니다. 직원 비용은 예측 가능하지만 토큰 비용은 모델이 바뀔 때마다 달라집니다. 업계 전체가 특정 벤더에 종속되는 구조가 만들어지고 있다는 지적입니다.

속도보다 이해, AI는 보조로

Lars는 AI 코딩 도구 자체를 부정하지 않습니다. 그가 비판하는 건 AI를 주인공 자리에 두는 워크플로우입니다. 에이전트가 코딩을 주도하고 개발자가 검토하는 구조가 아니라, 개발자가 구현을 주도하고 AI는 보조하는 구조가 장기적으로 더 지속 가능하다는 게 그의 주장입니다.

fast.ai를 만든 Jeremy Howard의 말이 이 논지를 압축합니다. AI 에이전트에 모든 걸 맡기는 사람은 자신의 쓸모를 스스로 없애는 것이라고요. 사고를 외주화하면 성장도 멈춘다는 말입니다.

참고자료:


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다