에이전트 코딩은 엔지니어링의 가장 쉬운 부분을 해결하지만, 가장 어려운 부분은 무너뜨린다

솔직히 말하자면: 에이전트 덕분에 코드 작성 비용은 엄청나게 싸졌지만, 사실 코드 작성이 소프트웨어 엔지니어링에서 비싼 부분이 아니었다. 어려운 부분은 문법을 타이핑하는 것이 아니다. 무엇을 만들지 파악하고, 그것을 설계하며, 이것이 복잡하고 살아있는 시스템에 어떻게 들어맞는지 이해하는 것이다. 코드를 작성하는 것은 실제로 엔지니어가 시스템을 배우는 방식이다—그의 엣지 케이스(edge cases), 특이점(quirks), 그리고 왜 그렇게 작동하는지를 말이다. 에이전트를 사용해 작성을 자동화하면, 당신은 쉬운 부분만 자동화할 뿐, 어려운 부분을 비워낸다. 만약 AI가 코드베이스의 80%를 작성한다면, 당신은 타이핑 속도를 팀 자체 소프트웨어에 대한 이해력과 맞바꾼 것이다. 이 도구들을 사용하면서 시간을 보내고 나니 몇 가지 큰 문제점들이 보인다. AI 에이전트에게 컴파일러와 테스트 스위트를 주면, 인간이 감당할 수 없는 속도로 반복 작업을 수행한다. 하지만 에이전트는 당신이 주는 신호(signal)에 대해서만 엄격하게 최적화한다. 실패하는 테스트를 녹색으로 바꾸는 가장 저렴한 방법은 근본적인 문제를 해결하는 가장 좋은 방법인 경우는 드물다. 진정한 리팩토링(refactoring) 대신, 그들은 종종 특수한 케이스(special cases)를 추가하거나, 지나치게 장황하게 만들거나, 때로는 통과하도록 테스트 자체를 수정하기도 한다. 에이전트는 실제로 일을 없애는 것이 아니라, 단지 작성하는 것에서 읽는 것으로 옮길 뿐이다. 그리고 코드를 읽는 것은 작가보다 악명 높게 더 어렵다. 에이전트가 작업을 수행하면, 20줄짜리 수정 사항이 지나치게 복잡한 로직의 200줄로 돌아올 수 있고, 미묘한 아키텍처 선택 뒤에 숨겨진 '왜'라는 이유가 완전히 빠져있다. 생성된 코드는 속임수처럼 깨끗하고 관용적으로 보여서, 치명적인 버그들을 흘려보내기 쉽다. 도구의 목적 자체가 속도이기 때문에, 개발자들은 모든 줄을 읽지 않는다.

운영 환경(production)이 다운되고 고객들은 분노하며, 문제가 발생한 코드 경로는 팀 누구도 실제로 작성했거나 이해하지 못하는 경우입니다. 읽지 않은 코드는 병합되는 순간 기술 부채(technical debt)가 되며, 장애(outages) 기간 동안 그 이자를 지불하게 됩니다. 흔히 사용하는 방어책은 매우 상세한 명세서(specs)를 작성하고 에이전트에게 이를 실행하도록 하는 것입니다. 하지만 AI에게 아주 작은 결정조차 남기지 않을 만큼 정밀한 명세서는 이미 이름이 있습니다: 코드입니다. 운영 환경 장애를 일으키는 결정들은 보통 계획 단계에서 아무도 예상하지 못한 것들입니다. 코드를 작성하는 것이 바로 그러한 것을 발견하는 방법입니다. 제게 있어 엔지니어링이란 장기적인 관리(stewardship)에 관한 것입니다. 시스템이 왜 작동하는지, 어떻게 실패하는지, 그리고 그것을 변경하면 무엇이 망가질지 아는 것입니다. 타이핑은 아무리 위임할 수 있지만, 이해(understanding)를 위임한다면 가장 필요할 때 시스템을 고칠 능력을 잃게 됩니다. 우리가 물어봐야 할 질문은 우리 AI가 이번 주에 얼마나 많은 코드를 작성했느냐가 아닙니다. 질문은 이것입니다: 만약 오늘 밤에 문제가 생기면, 우리 팀 누구든 그것을 고칠 수 있는가?
submitted by /u/cgouguen [link] [comments]