구현 속도가 점점 빨라지면서, 진짜 병목 현상은 AI가 생성한 방대한 양의 코드를 검토하는 단계로 이동하고 있습니다. 동료들(그리고 그들의 에이전트들)의 PR(Pull Request)뿐만 아니라, 본인의 코딩 에이전트(coding agent)가 작업을 마친 후의 git diff에 대해서도 마찬가지입니다.

플랜 모드(plan mode)로 시작하기, 큰 작업을 단계별로 나누기, 작은 변경 사항을 배포하기와 같은 좋은 관행(good practices)을 따를 때조차, 내가 실제로 직접 고민하지 않은 내용을 검토할 때는 여전히 인지적 과부하(cognitive overload)를 느낍니다.

코딩 에이전트가 등장하기 전에는, 작업이 주어지면 코드베이스를 탐색하고, 다양한 해결책을 생각하고, 실험을 거친 뒤에야 구현에 들어갔습니다. 그 모든 맥락(context)을 통합하는 데 며칠이 걸릴 수도 있었습니다. 하지만 마침내 PR을 제출했을 때는 확신이 더 높았고, 동료들에게 각 변경 사항을 설명하는 것도 더 쉬웠습니다.

인정해야 할 점은, AI를 사용하더라도 큰 작업을 완료하는 데는 여전히 며칠이 걸린다는 것입니다. 저는 AI가 만든 모든 변경 사항을 거절하고 처음부터 다시 시작하는 경우가 더 많습니다. 첫 번째 세션과 두 번째 세션의 차이는 LLM(Large Language Model) 모델이 아니라, 화면 뒤에 있는 사람입니다. 해결하려는 문제를 통합할 수 있는 시간이 더 많아질수록, 저는 에이전트에 끌려가는 대신 에이전트를 더 나은 솔루션으로 이끌 수 있습니다.

Can you trust the diff?

저는 점점 더 다음과 같은 동일한 이유로 AI 코드를 거절하고 있습니다:

• 접근 방식을 내 자신의 언어로 설명할 수 없을 때 AI 코드를 거절합니다.
• diff가 문제 자체보다 더 클 때 AI 코드를 거절합니다.
• 추상화(abstractions)가 필요하다는 것이 증명되기 전에 도입될 때 AI 코드를 거절합니다.
• 로컬에서는 작동하지만 시스템을 추론(reasoning)하기 더 어렵게 만들 때 AI 코드를 거절합니다.
• 나의 이해도보다 출력 결과물을 더 신뢰하게 될 때 AI 코드를 거절합니다.

엔지니어들이 AI가 생성한 변경 사항을 너무 빨리 수용하는 모습을 보는 것은 드문 일이 아니며, 이것이 바로 제가 AI 리뷰와 병행하여 필수적인 인간 리뷰(human review)를 옹호하는 이유입니다. 현실은 코드가 실행되고 CI(Continuous Integration)를 통과(green)시킨다고 해서 그것이 반드시 좋은 솔루션이라는 뜻은 아닙니다. 엔지니어링은 언제나 적절하고, 확장 가능하며(scalable), 확장성 있는(extensible) 솔루션을 구현하는 것에 관한 것이었습니다.

저는 한동안 코딩 에이전트(coding agents)를 사용해 왔으며, 이들이 얼마나 인상적인지에도 불구하고 여전히 훌륭한 솔루션으로 이끌어줄 뛰어난 엔지니어가 필요합니다. 네, 코딩 에이전트는 단순히 코드를 작성하는 것 이상의 도움을 이 작업에 줄 수 있지만, 그렇다고 해서 이들이 아직은 지속 가능한 방식으로 자율적으로(autonomously) 수행할 수 있다는 뜻은 아닙니다.