코드가 작동해도 AI 코드를 반려하는 이유
AI 코딩 에이전트의 도입으로 코드 작성 속도는 크게 빨라졌지만, 진정한 병목 현상은 생성된 방대한 코드를 리뷰하는 과정으로 넘어왔습니다. 단순히 코드가 작동하는 것을 넘어, 시스템의 복잡성을 높이거나 스스로 설명할 수 없는 AI 코드는 과감히 반려해야 한다는 실무자의 인사이트를 제공합니다. 이는 AI가 자율적으로 소프트웨어를 개발하기보다는, 훌륭한 엔지니어의 통제 아래에서 보조 도구로 사용되어야 함을 시사합니다.
코드 구현 속도가 점점 더 빨라지면서, 이제 진짜 병목 현상은 AI가 생성한 방대한 양의 코드를 리뷰하는 과정으로 넘어왔습니다. 여기서 말하는 건 동료(및 그들의 에이전트)의 PR(Pull Request)만이 아닙니다. 코딩 에이전트가 작업을 마친 뒤 여러분 자신의 git diff(Git 변경 사항)를 리뷰할 때 발생하는 문제입니다. 계획 모드로 시작하고, 큰 작업을 단계별로 나누며, 작은 단위로 배포하는 등 좋은 관행을 따르더라도, 내가 온전히 이해하지 못한 코드를 리뷰할 때는 여전히 심한 인지 부하를 느낍니다.
코딩 에이전트를 쓰기 전에는, 작업을 받으면 코드베이스를 탐색하고 여러 해결책을 고민하며 실험을 해본 후에야 구현에 들어갔습니다. 이런 과정을 통해 모든 맥락을 이해하는 데 며칠이 걸리기도 했죠. 최종적으로 PR을 제출할 때가 되면 자신감은 훨씬 높았고, 동료들에게 각 변경 사항을 설명하기도 수월했습니다. 인정해야 할 것은, AI를 사용해도 큰 작업을 완료하는 데 여전히 며칠이 걸린다는 점입니다. 게다가 대부분의 경우 AI가 만든 변경 사항을 모두 반려하고 처음부터 다시 시작합니다.
첫 번째 시도와 두 번째 시도의 차이는 LLM(대형 언어 모델) 모델이 아니라 화면 앞에 있는 사람에게 있습니다. 내가 풀고자 하는 문제를 숙고할 시간이 더 주어질수록, 나는 AI 에이전트에 끌려가는 대신 에이전트를 더 나은 해결책으로 이끌 수 있습니다. 점점 더 같은 이유로 AI 코드를 반려하고 있습니다. 내 말로 그 접근 방식을 설명할 수 없을 때, 코드 변경 사항(diff)이 문제 자체보다 더 클 때, 필요성이 증명되기도 전에 불필요한 추상화를 도입할 때, 로컬에서는 잘 작동하지만 시스템을 더 복잡하게 만들 때, 그리고 내 이해력보다 결과물을 더 맹신하게 될 때 저는 AI 코드를 반려합니다.
엔지니어들이 AI가 생성한 변경 사항을 너무 성급하게 승인하는 경우가 흔하며, 그렇기 때문에 AI 리뷰와 함께 필수적인 인간 리뷰를 주장하는 것입니다. 현실적으로 실행되어 CI(지속적 통합)를 통과시키는 코드도 여전히 나쁜 해결책일 수 있으며, 엔지니어링이란 언제나 적절하고 확장 가능하며 유연한 솔루션을 구현하는 것에 관한 것입니다. 저는 코딩 에이전트를 사용한 지 꽤 오래되었고 그 성능에 감탄하지만, 여전히 훌륭한 솔루션을 이끌어내기 위해서는 훌륭한 엔지니어의 통제가 필요합니다. 그렇습니다. 코딩 에이전트는 단순한 코드 작성 이상으로 이 작업을 수행하는 데 도움을 줄 수 있습니다. 하지만 그렇다고 해서 아직까지 그들이 지속 가능한 방식으로 이를 자율적으로 해낼 수 있다는 의미는 아닙니다.