AI 에이전트가 코드를 쓸 때 개발자가 여전히 알아야 하는 것

AI 코딩 에이전트가 실무 코드베이스에 본격적으로 들어오면서, 개발자가 어디까지 코드를 이해해야 하는지가 새로운 쟁점으로 떠올랐다. 해커뉴스에 공유된 한 개발자의 경험담은 이 문제를 아주 구체적인 장면으로 보여준다. 에이전트가 뽑아낸 코드가 테스트를 통과했는데도 정적 분석 도구가 경고를 띄우면서, 직접 쓰지 않은 코드를 떠안게 된 개발자의 상황이 드러난다.

발단은 CI 실패였다. 문제를 일으킨 파일은 App.tsx였고, 지적 사항은 순환 복잡도(cyclomatic complexity)였다. 파일 자체는 30줄 남짓이었지만 그중 15줄이 각각 통째로 하나의 컴포넌트였다. Codex가 컴포넌트를 줄바꿈 없이 한 줄에 몰아서 작성해 둔 것이다. 포매터를 돌리면 정리될 일이었지만, 복잡도 경고는 사라지지 않았다. 각 컴포넌트가 화면 표시와 비즈니스 로직을 상당히 많이 품고 있었기 때문이다.

흥미로운 지점은 에이전트의 태도다. 사람 개발자라면 읽기 좋게 나누고 이름을 붙이는 데 시간을 썼을 자리에서, 에이전트는 가독성에도 복잡도에도 관심을 보이지 않았다. 대신 여러 기능을 거치며 그 파일을 조용히, 그리고 안정적으로 계속 고쳐왔다. 결국 작성자는 에이전트에게 정적 분석 도구가 만족할 만큼 리팩터링하라고 지시했고, 코드는 10개 파일로 쪼개진 뒤 CI를 통과해 배포됐다.

작성자가 주목한 것은 결과 자체가 아니라 그 뒤에 남는 불안이다. 문제가 된 코드는 자신이 한 번도 제대로 본 적 없는 코드였고, 이번에는 빠르게 정리됐지만 상황에 따라 훨씬 나쁘게 흘러갈 수도 있었다는 것이다. 에이전트가 만들어낸 복잡도는 대체로 요구사항에 정당화되는 수준이었지만, 그것을 확인하려면 결국 사람이 파일을 열어 로직을 따라가야 했다.

글은 업계가 두 진영으로 갈린다고 진단한다. 한쪽은 에이전트가 만들어낸 코드를 사람이 직접 손으로 쓸 수 있을 만큼 읽고 검증해야 통제권을 유지할 수 있다고 본다. 반대쪽은 코드는 모델이 알아서 하니 무엇을 만들지에만 집중하자는 입장이다. 작성자는 양쪽 모두 현실적이지 않다고 본다.

더 근본적인 문제는 인력 양성이다. 오늘날의 시니어들은 코드를 직접 쓰고, 밤새 디버깅하고, 장애를 수습하면서 시스템에 대한 감각을 쌓았다. 하지만 기업이 주니어에게 몇 년씩 손코딩 학습을 후원할 경제적 이유가 사실상 사라졌다는 것이 작성자의 판단이다. '에이전트가 쓴 모든 줄을 이해하라'거나 '시니어와 페어를 하라'는 조언도 일부 조직에서는 가능하겠지만 업계 전반의 표준이 되기는 어렵다고 잘라 말한다.

그가 제안하는 방향은 소유권의 정의를 다시 세우는 것이다. 시스템을 성공적으로 운영하는 아키텍트나 리드에게 필요한 것은 머릿속의 시스템 모델, 즉 어디가 어떻게 흘러가는지에 대한 지도다. 남는 질문은 그 지도가 어느 정도 해상도여야 하느냐다. 수백만 줄 규모의 레거시 코드를 한 줄 한 줄 다 기억하는 사람은 없으며, AI가 코드를 대량 생산하는 환경에서는 '직접 작성한 경험'이 이해의 근거가 될 수 없다는 점이 문제의 핵심이다.

실무적으로 달라지는 것은 리뷰의 초점이다. 테스트와 CI가 통과했다는 사실만으로 코드를 넘기기 어려워졌고, 복잡도·구조·의존성처럼 정적 분석이 잡아내는 신호를 읽는 능력의 가치가 커진다. 동시에 이상 징후가 보일 때 필요한 만큼 깊이 들어가 확인할 수 있는 사람이 시스템의 실질적 책임자가 된다는 뜻이기도 하다.

다만 이 글은 한 개발자의 개인 경험과 의견이며, 구체적인 해법을 제시하지는 않는다. 시스템 모델을 어느 수준의 세밀함으로 유지해야 하는지, 주니어가 어떤 경로로 그 모델을 습득할 수 있는지는 여전히 열린 질문으로 남아 있다.