에이전트형 코딩: 효율의 덫, 전문성의 위기
최근 개발 현장에서 ‘에이전트형 코딩’이라는 개념이 뜨거운 감자다. 요구사항만 던지면 AI가 뚝딱 코드를 만들어내는 이상적인 그림. 하지만 마냥 환영할 수만은 없는 어두운 그림자도 함께 드리운다. 우리는 지금 효율이라는 미명 아래 무엇을 놓치고 있는지 냉철히 들여다볼 때다.
에이전트형 코딩, 그 이면의 그림자
에이전트형 코딩은 사람이 요구사항과 계획을 세우면 여러 AI 코딩 에이전트가 이를 구현하는 방식이다. 그러나 이 방식은 생성 코드와 사람 사이의 거리를 계속 벌린다. 본질적으로, 이는 언뜻 생산성을 높이는 지름길 같지만, 인간의 핵심 역량을 위협하는 구조적 문제를 안고 간다.
이러한 구조는 숙련된 개발자가 아키텍처 수준에서 비판적으로 검토할 때 비로소 성공 가능성을 보인다. 하지만 AI의 과도한 사용은 그에 필요한 기술을 약화시키는 인지 부채(cognitive debt)를 낳는다. 교육 현장에서도 단순히 AI가 과제를 대신하게 두는 방식은 학생들의 사고력 발달을 저해하는 문제와 직접적으로 맞닿아 있다. 우리는 지금 편의를 위해 무엇을 포기하고 있는지를 정확히 이해해야 한다.
개발 역량의 역설, 감독자의 딜레마
감독의 역설은 에이전트형 코딩의 핵심적인 문제로 지적된다. 앤스로픽(Anthropic) 연구에 따르면, 클로드(Claude)와 같은 코딩 에이전트를 효과적으로 사용하려면 이를 감독할 코딩 역량이 필수다. 문제는 에이전트 사용이 바로 그 역량을 약화시킬 수 있다는 점이다. 링그드인(LinkedIn)에서 50명의 엔지니어를 관리하는 샌더 냐코(Sandor Nyako)는 조직 내 기술 위축을 보고 “비판적 사고나 문제 해결이 필요한 작업”에는 AI 사용을 금지한다고 말한다. 그는 기술을 키우려면 어려움을 겪고 문제를 깊이 생각하는 근육을 길러야 한다고 단언한다.
실제 디버깅 기술이 47% 급감했다는 앤스로픽의 또 다른 연구 결과는 충격적이다. AI 과사용이 몇 달 안에도 기술을 빠르게 약화시킬 수 있음을 입증한다. 이 역설은 AI를 협력자로 보기보다 대리자로 삼을 때 나타나는 필연적인 결과다. 교육 현장의 교사들에게도 이 문제는 다르지 않다. AI의 설명을 맹목적으로 받아들이기 시작하면, 학습 내용을 비판적으로 검토하고 재구성하는 교사의 능력 또한 빠르게 무뎌진다.
속도에 매몰된 대가, 인지 부채의 확장
LLM(대규모 언어 모델)은 잘못된 부분을 가속하는 경향을 보인다. 과거 좋은 개발자의 우선순위는 코드베이스 이해, 효율적 표준 준수, 가독성 유지, 최소한의 코드 줄 수, 처리 시간 고려 등이었다. 하지만 에이전트형 코딩과 LLM은 이 우선순위를 사실상 뒤집는다. 현재 역량과 사용 방식은 일정 시간 안에 생성되는 코드량을 늘려 속도를 높이는 데 초점을 맞추는 경향이 있다.
그러나 속도는 높은 숙련도의 자연스러운 부산물이다. 이를 강제로 밀어붙이면 정확도 저하로 이어진다. LLM은 깊은 이해와 간결성보다 생성되는 코드의 양을 늘리는 방향으로 쓰이기 쉽다. 모호한 요구를 가정이나 환각(hallucination)으로 채워 더 많은 리뷰와 수정, 토큰 사용을 유발한다. 여기서 우리는 소프트웨어 개발의 본질적 가치를 망각한다. 진정한 속도는 깊은 이해에서 오는 부산물이지, 강제로 밀어붙여 얻는 결과가 아니다. 교육에서 진도만을 위한 양적 학습이 학습자에게 인지 부채만 남기듯, 코딩도 마찬가지다.
단순한 추상화 그 이상의 변화
일각에서는 AI 코딩 도구를 “프로그래머가 더 높은 추상화 계층으로 올라가는 것”이라고 해석한다. 그러나 모호성이 높아지는 것이 곧 더 높은 수준의 추상화를 뜻하지는 않는다. 과거 포트란(FORTRAN), 컴파일러, 고수준 언어가 등장했을 때도 버그, 불안정성, 효율 저하, “마법” 증가를 걱정하는 반응은 있었다. 그러나 과거의 우려는 대부분 새 기술을 받아들이면 무엇을 잃을지에 대한 규범적, 이론적 걱정이었다. AI 도구는 등장 후 몇 년 만에 이미 실질적 영향을 드러낸다.
이러한 영향은 주니어 개발자에게만 국한되지 않는다. 10년 이상 경험을 가진 시니어 개발자에게도 나타난다. 시니어 엔지니어가 관리 역할로 이동하며 코딩을 덜 하고 “녹슬어 가는” 현상은 새롭지 않다. 기존 경로에서는 수십 년 동안 코딩, 마찰, 문제 해결을 축적한 엔지니어가 문법보다 아키텍처 결정을 더 많이 다루는 역할로 이동했다. 지금은 그런 장기적 경험 없이도 개발자들이 AI 에이전트를 관리해야 하는 더 높은 수준의 워크플로로 이동한다. 문제는 이런 워크플로가 수십 년의 경험으로 얻은 것과 같은 기술을 요구한다는 데 있다. 심지어 30년 경력의 사이먼 윌리슨(Simon Willison)조차 애플리케이션이 무엇을 할 수 있고 어떻게 동작하는지에 대한 “확고한 정신 모델”이 없으면 기능이 추가될수록 추론이 어렵다고 밝힌다. 기술 발전이 늘 더 높은 추상화로 이어지는 것은 아니다. 때로는 더 깊은 모호성을 낳고, 문제 해결에 필요한 근본적인 인지 메커니즘을 마비시킨다. 이는 마치 문제 풀이 과정을 생략하고 답만 받아 적는 것과 같다.
AI 의존성이 낳는 시스템 리스크
AI 모델에 대한 의존성은 벤더 종속과 비용 불확실성이라는 구조적 위험을 초래한다. 클로드(Claude) 장애 당시 일부 개발자와 엔지니어링 팀이 멈춰 섰다는 게시물들은, 일부 워크플로와 코딩 능력이 이미 특정 AI 벤더에 크게 의존하는 수준에 도달했음을 보여준다. 예전에는 키보드와 텍스트 편집기만 있으면 수행할 수 있던 기술이 AI 모델 제공자 구독을 필요로 하는 상황이다.
| 구분 | 직원 비용 | 토큰 비용 |
|---|---|---|
| 예측 가능성 | 비교적 고정적이고 예측 가능 | 일별, 월별, 연도별로 예측하기 매우 어려움 |
| 변동성 | 낮은 변동성 | 모델 출시, “너프” 등으로 2~3배 변동 가능 |
| 종속성 | 회사 내부 관리 가능 | 모델 제공자에 절대적으로 종속 |
| 사업 구조 | 역량 기반의 인력 운영 | 추론 비용 지불을 통한 기능 수행 산업 구조 |
이러한 구조는 단순한 제품 종속을 넘어선다. 산업 전체의 기술 역량이 소수 벤더에 종속되는 위험천만한 상황이다. 교육 현장에서도 특정 AI 플랫폼에 모든 교육 과정을 의존하면, 서비스 중단, 비용 인상, 기능 변경 등에 매우 취약해진다. 재정적, 지적 기반이 언제든 흔들릴 수 있다는 것은 이론이 아닌 현실이다.
생산성을 지키면서 전문성을 키우는 법
LLM은 학습과 역량 향상을 위한 강력한 도구가 될 수 있다. 개념과 기법을 더 깊고 넓게 탐색하게 하고, 예전보다 적은 수고로 새 아이디어를 실험하게 해줄 수 있다. 에멧(Emmet), 자동완성, 스니펫은 이미 코드를 직접 덜 쓰고 생성하기 위한 도구였다. jQuery의 모토 또한 “write less, do more”였다. LLM은 이런 코드 생성 도구의 또 다른 추가물로 본다.
중요한 차이는 LLM과 코딩 에이전트를 보조 프로세스로 활용하는 데 있다. 생산성을 위해 개인의 기술을 희생하지 않고, 계획 단계의 브레인스토밍에 AI를 활용하되 구현에는 계속 적극적으로 관여하는 방식이 가능하다. 필요할 때만 위임하면 생산성 이득을 얻으면서 이해 부채(understanding debt)를 줄일 수 있다. 핵심은 AI를 ‘스타트렉(Star Trek)’의 데이터(Data) 같은 선원이 아니라, 우주선 컴퓨터(Ship’s Computer)처럼 사용하는 것이다. 즉, 지시를 받으면 정확히 실행하되, 전체적인 방향과 의사결정은 인간이 책임지는 방식이다.
다음은 일상적인 AI 활용 방식과 그렇지 못한 방식을 비교한다.
| 구분 | 비효율적 AI 활용 (Agentic Coding의 함정) | 효과적 AI 활용 (생산성 + 전문성) |
|---|---|---|
| 역할 배분 | AI가 스펙과 코드 구현 전체를 주도 | AI는 스펙/계획 생성 보조, 사람은 구현 주도 |
| 코딩 관여도 | 구현을 거의 전적으로 AI에 위임 | 작업에 따라 20~100% 직접 코딩 |
| 프롬프트 작성 | 모호한 요구사항 제시, AI가 가정으로 채움 | 자주 의사 코드를 작성, 요청과 생성 코드 간 거리 좁힘 |
| AI 도구 사용 | 대량 코드 생성, 무조건적인 속도 증대 | 임시 코드 생성, 대화형 문서, 리서치, 제한적 위임 |
| 코드 리뷰 | 대량 생성 코드에 대한 피상적 검토 | 한 번에 리뷰 가능한 양만 생성, 필요시 직접 리팩터링 |
| 전문성 개발 | 코딩 경험 감소로 학습 능력 약화 | 직접 코딩으로 메커니즘/언어 이해 심화 |
| 위임 범위 | 직접 해본 적 없거나 혼자 불가능한 구현 위임 | 해봤거나 혼자 가능한 작업에서만 책임감 있게 위임 |
이러한 전환은 단순히 도구를 바꾸는 행위를 넘어, 개발자의 사고방식과 역할 재정립을 요구한다. 교육 현장에서도 AI를 활용할 때, 교사가 직접 학습 과정에 개입하고, AI가 생성한 자료를 비판적으로 검토하며, 학생들의 주도적인 학습 경험을 설계하는 역할이 무엇보다 중요하다.
진정한 역량은 마찰에서 온다
모델의 생산성 향상은 실제로 존재한다. 동시에 작업을 직접적이고 자주 다루며 생기는 마찰과 이해도 실제로 중요하다. 코딩을 이해하지 못한 채 코딩을 민주화하려는 시도들은 반복적으로 실패해 왔다. 코드를 이해하려면 코드와 직접 맞물려야 한다. 계속 코드에 관여하고 작성하지 않으면 그 이해와 연결고리를 잃을 수 있다. 이해를 잃으면 에이전트를 더 잘 관리하는 능력도 약해지고, AI 코딩 단계는 이상하고 불필요하게 스트레스가 큰 과도기가 된다.
현재 흐름은 장기적 영향을 충분히 이해하지 못한 채 스스로에게 실행하는 또 하나의 대규모 실험처럼 보인다. 소셜 미디어 도입 당시에도 장기적 함의를 이해하지 못했고, 이후 광범위한 주의력 결핍 등 여러 문제가 나타났다. 이번에는 더 위험한 것을 걸고 있다. fast.ai를 만든 제레미 하워드(Jeremy Howard)는 AI 에이전트에 전부를 거는 사람은 자신의 쓸모없어짐을 보장한다고 말한다. 모든 사고를 컴퓨터에 외주화하면 역량을 높이고 배우고 더 유능해지는 과정을 멈추게 된다.
지금 당신의 업무에서, 혹은 당신이 가르치는 학습 현장에서, AI가 단순히 ‘빨리’ 해주는 역할을 넘어 ‘깊이’ 이해하게 돕는 도구가 되려면 어떤 변화가 필요하다고 보는가? 당신의 팀과 학교는 이 변화를 어떻게 설계할 것인가?