에이전트 코딩의 네 가지 폐해

AI 요약

에이전트 코딩은 유용하지만, 그 대가로 개발자의 작업 방식과 팀 문화에 부정적인 영향을 준다고 글쓴이는 주장합니다. 문제를 네 가지 ‘기수’로 묶어 살펴보며, 아직 뚜렷한 해법은 찾지 못했다고 밝힙니다.

슬롭

LLM이 만든 코드는 인간이 쓴 코드와 문체와 구조가 다르고, 글쓴이는 이런 특유의 결과물을 ‘슬롭(slop)’이라고 부릅니다. 코드가 도구인 만큼 AI 문장처럼 무조건 나쁘다고 단정하기는 어렵지만, 최근 모델도 사람이 이해하기 힘든 장황한 표현이나 경쟁적인 코드 골프(code golf)식 코드를 내놓는다고 지적합니다. 슬롭이 일시적인 성장통이 아니라 LLM 출력의 지속적인 특징처럼 보인다는 설명입니다.

이런 코드가 쌓이면 팀원이 함께 들여다보고 익히던 코드베이스가 사람들이 머물고 싶지 않은 공간으로 바뀔 수 있습니다. 글쓴이는 “코드를 읽지 않아도 된다”는 기대가 현실이 되지 않는 한, 에이전트가 만든 코드의 유지보수와 팀의 공동 소유감이 문제로 남는다고 봅니다. 코드를 직접 살피는 대신 채팅 인터페이스에서 에이전트 무리를 지휘하는 역할만 맡게 되는 상황도 우려합니다.

소외

과거 소프트웨어 엔지니어링에는 도구와 코드를 직접 다루는 감각이 있었습니다. 편집기와 색상 테마, 프로그래밍 글꼴, 분할 키보드에 애정을 쏟았고, 코드를 직접 작성하면서 결과물에 주인의식을 느꼈습니다. 에이전트 코딩은 개발자와 결과물 사이의 거리를 크게 벌립니다. 모호한 지시를 에이전트에 넘긴 뒤 보고서를 훑는 방식이 늘고, 음성으로 지시하면 키보드 입력마저 필요하지 않습니다.

글쓴이는 이 거리가 커질수록 개발자가 결과물에 덜 애착을 느끼고 작업의 뿌리에서 멀어진다고 말합니다. 충분히 검토되지 않은 기능이 통과하거나 근본 원인을 해결하지 못한 임시 수정이 반복되고, 하루가 끝나도 성취감을 느끼기 어려워진다는 주장입니다. 소프트웨어에서 기쁨을 얻으려면 만든 사람의 애정이 코드에 담겨야 한다고 덧붙입니다.

기술 퇴화

기술 퇴화(deskilling)는 기존 기술을 약화하고 학습을 방해하며, 그에 걸맞은 기술 발전을 제공하지 않는 문제입니다. 글쓴이는 AI를 오래 쓰면서 사고력이 무뎌진다고 말하는 사람이 적지 않다고 짚습니다. 전문 기술도 쓰지 않으면 잃을 수 있으며, 숙련 엔지니어가 LLM을 능숙하게 활용하는 현재 상황은 오랜 기간 어려운 일을 직접 해 온 사람들의 경험에 기대고 있다고 봅니다. AI 시대의 학습법을 찾지 못하면 그런 숙련자의 공급은 계속되지 않습니다.

초보자는 AI를 쓰지 말라는 조언에 글쓴이는 동의하지만, 이를 모두에게 적용할 수는 없다고 말합니다. 쉬운 해결책이 생기면 학습에 투자할 유인이 바뀌고, 사람들은 그 유인을 따른다는 설명입니다. LLM 활용에도 학습 곡선이 있다는 반론에는 회의적입니다. 마크다운 파일을 내려받거나 에이전트를 조율하는 일을 배운다고 해도, 그 과정이 기존 전문 기술의 발전과 같은 수준의 학습은 아니라는 주장입니다. 인쇄기나 전기톱은 다루는 기술이 필요하지만, 새로운 AI 도구는 읽고 쓰는 능력조차 없이 B2B SaaS를 만들 수 있을 만큼 진입 장벽이 낮다고 과장 섞인 비유를 듭니다.

팀의 균열

에이전트는 동료에게 질문하는 일을 줄이고 각자가 혼자 문제를 해결하도록 이끕니다. 예전에는 고무 오리가 답하지 못하는 질문을 팀 채널에 올렸지만, 이제 채팅은 에이전트 대화와 LLM이 만든 문서, 동료에게 의견을 묻는 짧은 말로 채워진다고 글쓴이는 설명합니다. 동료의 사소한 질문을 돕는 일은 방해가 아니라 관계를 만들고 유지하는 과정인데, 그 기회가 줄어든다는 관점입니다.

팀에서 전문성을 드러내고 서로 다른 기술을 인정하던 방식도 달라집니다. 과거에는 Git이나 Rust, 기계식 키보드에 각자 능숙한 동료가 있었지만, 이제는 Claude나 Codex를 잘 다루는 사람으로 구성원이 묘사된다고 꼬집습니다. 프롬프트나 에이전트 사용법을 동료에게 보여주는 일도 매력적으로 느껴지지 않는다고 말합니다. 조직도상으로는 동료여도 함께 일하며 쌓던 유대는 약해질 수 있다는 우려입니다.

글쓴이는 네 가지 문제를 나열한 뒤 무엇을 해야 할지는 모르겠다고 씁니다. AI의 이점은 인정하면서도 호기심과 장인정신, 사회적 연결을 대가로 치르고 있다고 말합니다.

Lobsters 반응

• @zem — 팀에서 마크다운 파일을 저장소에 올려 사람들을 짜증 나게 하는 사람이 아마 저일 겁니다. 아이러니하게도 저는 프롬프트 엔지니어링을 전혀 믿지 않습니다. 올리고 싶은 건 봇의 계획 메모입니다. LLM과 기능 계획을 세우고 몇 차례 다듬은 뒤, 각각 독립된 단계로 나눠 커밋을 쌓아 구현하게 합니다. 마크다운 파일은 거의 읽지 않습니다. 대신 모든 커밋을 꼼꼼히 읽고 고칩니다. Claude 같은 모델에게 개별 커밋을 계속 다듬고 다시 쌓게 해 결과가 괜찮아지면 코드 리뷰를 요청합니다. 리뷰 과정에서도 때로는 상당히 많이 다듬습니다. 계획 파일을 저장소에 올리고 코드와 함께 수정하면 봇의 작업 메모리 역할을 해 작업 방향을 유지한다고 봅니다. 저희 팀은 LLM이 만든 코드에도 사람이 쓴 코드와 똑같이 모든 줄을 읽고 커밋을 확인하는 기준을 적용해서 아주 만족스럽습니다.
  • @carlana — 요즘은 봇에게 사람이나 봇이 구현할 수 있을 만큼 구체적인 마크다운 계획을 쓰게 한 뒤, 제가 직접 구현하는 편이 더 잘 됩니다. 제가 직접 만들면 최종 결과물을 승인받기 위해 다듬어야 할 부분이 줄어듭니다.
• @emk — 에이전트 코딩에 이곳의 많은 사람보다 관대한 편인데도 이 글이 훌륭하다고 생각했습니다. 저는 에이전트를 가상 페어 프로그래밍 상대 정도로 제한하고, 진행을 지켜보면서 코드 절반은 직접 씁니다. 좋든 나쁘든 정말 쓸 만한 고무 오리입니다. 감독 없이 작업하게 두면 문제를 일으킵니다.

원문: Distant Province / 번역·요약: Trawling