AI가 작성한 코드를 모두 리뷰해야 할까?

최근 애디 오스마니_{(Addy Osmani)}가 쓴 “AI 에이전트가 일을 할 때의 비판적 사고_{(Critical thinking when agents do the work)}“라는 글이 개발자들 사이에서 큰 관심을 받았습니다.

애디 오스마니는 구글에서 14년 이상 근무한 뒤, 구글 클라우드 AI 총괄 책임자를 거쳐 현재는 앤트로픽에서 클로드 코드_{(Claude Code)} 개발에 참여하고 있습니다. AI 시대의 소프트웨어 개발 방법을 다룬 《바이브 코딩을 넘어서_{(Beyond Vibe Coding)}》_{(오라일리, 2025년 8월)}의 저자이기도 합니다.

그는 이 글에서 AI 에이전트에 많은 작업을 위임하더라도 개발자가 비판적 사고와 독립적인 판단 능력을 잃지 않아야 한다고 강조합니다.

이 글을 읽고 한 개발자와 대화를 나눴습니다. 그 개발자는 AI에게 코드를 작성하게 하더라도 개발자가 요구사항을 정확하게 전달하고 결과물을 꼼꼼하게 검토해야 하며, 최종 책임은 사람이 져야 한다는 주장에 동의했습니다.

그러면서 이런 질문을 던졌습니다.

자신이 선택한 해결 방법을 다른 개발자 앞에서 설명하고 방어할 수 있어야 한다면, AI가 작성한 각 클래스와 메서드를 모두 리뷰해야 하지 않을까요? 특히 백엔드에서는 내부 구현을 일일이 확인하지 않으면 올바르게 작동하는지 확신하기 어렵지 않을까요?

아래 글은 이에 대한 저의 생각을 정리한 것입니다.

다만, 이 문제는 저도 고민하면서 시험해 보고 있는 문제이므로 이 글은 현재 제가 실무에서 적용하고 있는 잠정적인 견해라고 봐 주시면 됩니다.

해결 방법을 설명하는 것과 모든 코드를 아는 것은 다르다

저는 자신이 선택한 해결 방법을 설명하고 방어할 수 있어야 한다는 원칙에 동의합니다. 그러나 이것이 모든 메서드의 구현을 설명할 수 있어야 한다는 뜻은 아니라고 생각합니다.

해결 방법의 타당성을 설명하는 것과 구현의 모든 세부사항을 아는 것은 다른 문제이기 때문입니다. AI 시대에 모든 메서드와 세부 로직을 일일이 검토하는 것은 현실적으로 불가능하기도 합니다.

그렇다면 어떻게 해야 할까요?

저는 전체적인 로직과 핵심 로직을 반드시 파악해야 한다고 생각합니다.

실제로 AI가 작성한 코드를 어떻게 검토하는가?

최근 제가 작업한 웹 애플리케이션 성능 개선 사례를 들어 보겠습니다.

기존 시스템은 일정한 간격으로 수많은 요소의 데이터를 통째로 계산하고 전송했으며, 화면에서도 전체 요소를 반복해서 그렸습니다.

AI는 이를 다음과 같이 개선했다고 보고했습니다.

요소가 많이 보일 때는 GPU에 올린 좌표를 재사용하고, 적게 보일 때는 화면에 보이는 요소만 그리도록 했습니다. 데이터 전송은 변경된 요소만 일정한 크기로 나눠 보내도록 바꿨습니다. 화면에서는 큰 작업을 잘게 나눠 처리하고, 서버에서는 계산 결과를 재사용하며 일부 작업을 병렬화했습니다. 그 결과 화면을 움직일 때의 프레임 속도가 크게 향상됐고, 데이터 갱신으로 화면이 멈추는 시간도 대폭 줄었습니다.

저는 이 설명을 읽고 전체적인 로직을 이해합니다. 그러나 몇 가지 이해되지 않는 말은 질문할 것입니다. 데이터를 일정한 크기로 나눠 보낸다는 게 무슨 말인지, 큰 작업을 잘게 나누는 방법은 무엇인지, 계산 결과를 어떻게 재사용한다는 것인지 말이죠.

그리고 핵심 로직에 대해서는 좀 더 파고듭니다.

AI는 핵심적인 개선 사항으로 “전체를 다시 계산하고 그리는 대신 변경된 부분만 갱신한다”, “화면에 보이는 요소만 그린다”는 방식을 제시했습니다.

이 방향 자체에 이견이 있다면 저는 바꾸라고 지시할 것입니다. 이번 작업에서는 합리적이라고 판단했습니다.

그다음에는 “변경된 부분만 갱신하는” 방법에 대해 질문합니다. 실수가 발생할 가능성은 얼마나 되는지, 변경된 요소를 빠뜨릴 위험은 없는지, AI가 이를 어떻게 처리했는지 설명을 듣기 위해서입니다.

AI가 최종적으로 제출하게 해 둔 완료 보고서에 이미 충분한 설명이 있다면 묻지 않을 수도 있습니다. 그렇지 않다면 AI의 설명에 모순이 없는지 몇 가지 질문을 더 던질 것입니다.

“화면에 보이는 요소만 그린다”는 방식에 대해서도 마찬가지입니다. 화면 밖에 있던 요소가 다시 화면에 들어오면 언제, 어떻게 갱신되는지 물을 것입니다.

이렇게 전체적인 설계와 핵심 로직을 이해하고 검토합니다.

그러나 메서드의 구체적인 구현까지 일일이 읽지는 않을 것입니다.

그렇게 한다면 손코딩에 비해 AI 코딩으로 얻는 효율이 매우 적을 것이기 때문입니다.

물론 완료 보고서에 있는 메서드명과 테스트명은 훑어봅니다. 예상하지 못한 메서드가 있다면 왜 필요한지 질문할 것입니다. 테스트명에서도 이상한 점이 발견되면 확인할 것입니다.

예외적으로 구체적인 구현을 직접 살펴보는 경우도 있습니다. 기능 구현에 실패했거나, 이상한 점에 대한 질문에 AI가 제대로 답하지 못할 때입니다. 그럴 때는 해당 코드를 직접 확인합니다.

중요한 것은 모든 구현을 이해하는 것이 아니라, 시스템이 어떤 원리로 작동하며 중요한 설계 결정이 타당한지 이해하는 것입니다.

AI를 팀원처럼 대한다는 것

저는 AI를 대하는 관점을 팀장처럼 가져야 한다고 생각합니다.

팀장으로 일할 때 저는 신입 개발자의 코드를 일일이 살펴보며 교육합니다. 그러나 신입이 성장해 믿을 만한 동료가 되면 그의 코드를 모두 살펴보지는 않습니다.

어떻게 구현했는지 묻고, 설명에 이상이 없으며 기능이 정상 작동한다면 코드를 믿고 병합합니다.

그렇게 하지 않으면 여러 명의 개발자와 함께 일할 수 없습니다. 팀장이 모든 팀원의 코드를 일일이 검토한다면 팀의 생산성은 팀장의 검토 속도에 묶일 것입니다.

AI 코딩도 비슷하다고 생각합니다.

물론 AI는 사람과 다릅니다. 따라서 AI 모델 자체의 능력뿐 아니라 테스트와 검증 체계까지 포함해 신뢰한다고 하는 것이 적절할 것입니다.

그렇다면 AI를 어떻게 믿을 수 있을까?

여기에는 중요한 문제가 있습니다.

AI는 할루시네이션을 일으킬 수 있고, 보상 함수 하이재킹으로 인해 실제 문제를 해결하지 않고도 해결한 것처럼 만들 수 있습니다.

따라서 AI가 설명을 잘한다고 해서 실제 구현도 올바르다고 믿을 수는 없습니다.

저는 이 문제에 대한 답이 모델의 성능 향상, 3중의 독립 검증, AI의 테스트 주도 개발이라고 봅니다.

올해 상반기까지만 해도 저는 AI를 지금만큼 신뢰하지 않았습니다.

그래서 AI가 작성한 코드를 일일이 살펴봤습니다. AI가 30분 만에 작성한 코드를 제가 3시간에서 4시간 동안 검토하는 일도 있었습니다.

그러나 지금은 방식이 달라졌습니다.

AI가 작성한 보고서를 읽고 질문하는 데 1시간 정도를 사용합니다. 그 대신 테스트와 여러 에이전트의 교차 검증을 통해 결과물의 신뢰성을 확보하려고 합니다.

모델의 성능이 향상됐고, 테스트와 독립 검증을 거치면 충분히 믿을 만한 결과를 얻을 수 있다고 판단하게 됐기 때문입니다.

물론 문제가 완전히 사라지는 것은 아닙니다. 그러나 사람도 코딩하다 보면 실수합니다. 저는 AI가 만든 코드에서도 일정한 오류 가능성을 받아들이되, 이를 발견할 수 있는 검증 체계를 갖추는 방향을 선택했습니다.

이 정도로 신뢰하지 못한다면 AI 코딩을 통한 생산성 향상은 크게 제약받을 수밖에 없다고 생각합니다.

개발자는 무엇을 이해하고 책임져야 할까?

그렇다면 나중에 다른 개발자가 특정 메서드의 구현 이유를 물으면 어떻게 해야 할까요?

저는 질문의 성격에 따라 다르게 답할 것입니다.

설계 결정에 관한 질문이라면, 전체적인 설계와 연관해 그 이유를 설명할 수 있어야 합니다. 그러나 부차적인 구현 세부사항에 관한 질문이라면 저는 AI에게 물어보라고 답할 것입니다. 그걸 개발자가 모두 알고 있을 필요는 없다고요. 사실 직접 짠 코드도 몇 개월이 지나면 기억나지 않는 경우가 많습니다.

핵심은 모든 코드에 똑같은 관심을 기울이는 것이 아니라, 무엇이 중요한지 판단하고 필요한 곳에 집중하는 것입니다.