에이전트 코딩은 코드 품질과 팀 문화를 갉아먹는다는 비판이 나왔다

Lobsters8일 전조회 2

AI 에이전트에게 코딩을 맡기는 방식이 빠르게 자리 잡으면서, 그 편익만큼이나 부작용을 정면으로 다루는 글이 나왔다. 개발자 Alex Martsinovich가 쓴 이 에세이는 에이전트 코딩을 "네 명의 기수"에 비유하며 slop, 소외, 탈숙련, 팀 붕괴라는 네 가지 문제를 제기한다. 결론부터 말하면 저자는 이 네 가지 모두에 대해 뾰족한 해법이 없다고 인정한다.

첫 번째는 코드의 질감 문제다. LLM이 만든 코드는 사람이 쓴 코드와 분명히 다른 결을 가지며, 이를 가리키는 'slop'이라는 말은 이미 부정적 뉘앙스를 굳혔다. 저자는 최신 세대 모델조차 기대에 못 미친다고 본다. 똑똑하기는 하지만 영감을 주는 쪽이 아니라 어디에도 고용하기 곤란한 쪽으로 진화하고 있다는 것이다. 실제로 Claude가 알아보기 힘든 문장 덩어리로 소통한다는 평이나, 특정 모델이 경쟁적으로 코드 골프를 하는 듯한 난해한 스타일로 코드를 쓴다는 관찰이 그 근거로 제시된다. 이런 출력물이 쌓인 저장소는 사람이 머물고 싶지 않은 공간이 되고, 에이전트를 한 번 허용한 팀에서는 사람의 영역이 순식간에 밀려난다는 지적이다.

두 번째는 코드로부터의 소외다. 소프트웨어 엔지니어링은 손으로 만지는 감각이 강한 직업이었다. 텍스트 에디터에는 광신적인 사용자층이 있었고, 색 테마와 프로그래밍 폰트, 스플릿 키보드, 타건음 비교 영상까지 취향과 애착이 촘촘하게 쌓여 있었다. 직접 코드를 생산했기 때문에 결과물에 대한 소유감도 자연스럽게 생겼다. 에이전트 코딩은 엔지니어와 산출물 사이의 거리를 감각 도구로는 건널 수 없을 만큼 벌려 놓았다. 이제는 모호한 지시를 던지고 돌아온 보고를 훑어보는 것이 전부이며, 심지어 타이핑도 필수가 아니다. 그 결과 기능 설계에 대한 반대 의견이 사라지고, 근본 원인을 건드리지 않는 임시 땀질식 수정이 늘고, 하루를 마칠 때의 충만감도 옅어진다는 것이 저자의 관찰이다.

세 번째는 탈숙련이다. 오래 AI를 쓰면 실력이 녹슨다는 보고는 이제 논쟁거리라기보다 흔한 경험담에 가깝다. 저자는 대부분의 전문 기술이 쓰지 않으면 잃는다는 원칙을 떠올린다. 지금은 오랜 세월 어려운 방식으로 일해 온 숙련 엔지니어들이 LLM을 정확히 다뤄 폭발적인 생산성을 내는 시기지만, AI 시대의 학습법을 정립하지 못하면 이 공급은 오래가지 않는다는 경고다. 신입은 AI를 쓰지 말라는 조언은 개인 차원에서는 타당하지만 인류 전체의 전략이 될 수는 없다. '쉬운 버튼'이 생기면 학습 유인 자체가 흔들리고, 사람은 유인을 따른다. LLM 활용법에 나름의 학습 곡선이 있다는 반론도 있지만, 저자는 그 곡선이 사실상 존재하지 않는다고 잘라 말한다. 인쇄기나 전기톱은 다루는 기술이 필요하지만 이 마법 상자는 읽고 쓰는 법조차 몰라도 쓸 수 있다는 것이다.

네 번째는 팀의 사회적 직물이 약해지는 문제다. 예전에는 팀 채팅방이 붐볐다. 러버덕에게 물어도 답이 안 나오는 문제가 채팅으로 올라왔고, 그 과정에서 관계가 만들어졌다. 지금은 각자 24시간 대기하는 똑똑한 동반자와 대화하느라 채팅방이 텅 빈다. 남아 있는 것은 에이전트 스레드와, LLM이 써 준 초안을 올리며 "다들 어떻게 생각해요?"라고 묻는 메시지 정도다. 팀원을 바라보는 시선도 달라졌다. Git 마법사, Rust 마법사, 기계식 키보드에 진심인 사람처럼 각자의 전문성이 드러나던 자리가 이제는 Claude 운영자, Codex 위스퍼러, .md 파일을 커밋하자고 우기는 사람으로 대체됐다는 조소 섞인 표현이 나온다. 남이 에이전트에게 프롬프트를 넣는 모습을 보고 싶어 하는 사람은 없다는 것이다.

이 글의 배경에는 에이전트 코딩 도입 속도와 생산성 담론에 대한 반작용이 있다. 모델은 계속 좋아질 것이고 곧 코드를 읽을 필요조차 없어질 것이라는 낙관론이 주류를 이루는 가운데, 저자는 그 낙관이 코드베이스와 사람 사이의 관계를 어떻게 바꾸는지는 설명하지 못한다고 본다. 조직도상으로는 여전히 동료지만 시간이 갈수록 서로 멀어지는 팀에 대한 물음이 글의 착점이다.

실무에 옮기면 점검할 지점은 분명하다. 에이전트가 만든 코드를 누가 어떤 기준으로 읽고 이해할 것인지, 리뷰가 형식적인 승인 절차로 전락하지 않았는지, 주니어가 실력을 쌓을 경로가 남아 있는지, 팀 대화가 에이전트 스레드로만 채워지고 있지는 않은지를 되짚어야 한다. 저자는 코드에 창작자의 애정이 스며들어야 소프트웨어가 즐거움을 준다고 말한다.

다만 이 글은 개인적 관찰과 정성적 주장에 기대고 있으며, 저자 스스로도 뚜렷한 해법을 제시하지 못한다. 모델이 계속 개선되고 코드를 직접 읽지 않아도 되는 시대가 온다면 네 가지 문제 중 일부는 완화될 수 있다는 반론도 가능하다.