리뷰의 단위는 곧 이해의 단위

읽지 않은 계약서에 사인한 적이 있으신가요?

AI 에이전트가 만든 1,800줄짜리 PR에 "Approve"를 누르는 일도 이와 다르지 않습니다. 에이전트는 점점 빨라지고, 한 번에 더 큰 변경을 만들어 냅니다. 하지만 사람이 한 번에 이해할 수 있는 양은 그대로입니다.

인지적 항복

리뷰어가 PR을 열고 디프를 확인합니다. 처음 100줄은 꼼꼼하게 읽습니다. 200줄을 넘어가면 전체적인 흐름만 따라갑니다. 500줄쯤에서는 변수명과 함수 시그니처만 훑어보다가, 1,000줄이 넘으면 결국 "테스트는 통과했네"라고 말하며 리뷰를 끝냅니다.

한 번에 이해할 수 있는 양을 넘어서면, 리뷰어는 변경 내용을 이해하기를 포기합니다. 이런 상태를 인지적 항복(Cognitive Surrender)이라고 합니다. "Approve"를 누르는 일도 검토 결과에 따른 판단이 아니라 형식적인 절차가 됩니다.

문제는 이런 항복이 점점 더 자주 일어난다는 사실입니다. 에이전트는 새벽에도 일하고 점심시간에도 일합니다. 자고 일어나면 새로운 PR이 도착해 있습니다. 사람의 검토 속도는 에이전트의 생산 속도를 따라잡을 수 없습니다.

이해하지 못한 코드를 머지하면, 나중에 그 코드를 파악해야 하는 일이 남습니다. 이런 부담이 쌓이는 것을 이해 부채(Understanding Debt)라고 합니다.

부채에는 이자가 붙습니다. 한 달 뒤에 비슷한 기능을 추가할 때, 누군가는 그 코드를 처음부터 다시 읽어야 합니다. 버그가 발생하면 디버깅에 두 배의 시간이 듭니다. 리팩터링을 시도하더라도 어디까지 안전하게 고칠 수 있는지 아무도 알지 못합니다.

이해 부채는 기술 부채와 성격이 다릅니다. 기술 부채는 "알면서도 미뤄 둔 것"이지만, 이해 부채는 "처음부터 모르는 것"입니다. 알지 못하는 부채에 대해서는 상환 계획조차 세울 수 없습니다.

에이전트가 만든 코드라고 해서 책임의 소재가 바뀌지는 않습니다. 머지 버튼을 누른 사람이 그 코드의 소유자입니다. 모르는 코드를 소유한다는 것은 작동 원리를 이해하지 못한 기계를 떠맡는 일과 같습니다.

리뷰의 단위는 곧 이해의 단위입니다. 사람이 한 번에 이해하고 검증할 수 있는 크기로 변경을 나누어야 합니다.

PR이 1,800줄이라면, 그것은 에이전트가 효율적이라는 신호가 아니라 검토자가 감당할 수 있는 양을 넘어섰다는 신호입니다. 에이전트가 한 번에 만드는 코드의 양과 사람이 한 번에 이해할 수 있는 양은 다릅니다.

변경을 얼마나 나눌지는 사람이 검토할 수 있는 양에 맞춰 정해야 합니다. 에이전트가 1,000줄을 30분 만에 만들어도, 그 코드를 PR 하나에 모두 담을 이유는 없습니다. PR 다섯 개로 나누거나 커밋 다섯 개로 분리해 단계별로 검토할 수 있게 해야 합니다.

에이전트와 함께 일할 때 가장 큰 함정은 "빨라진 것 같은 느낌"입니다.

PR을 머지하는 시점만 보면 분명히 빠릅니다. 하지만 그 코드가 한 달 뒤에 누군가의 디버깅 시간을 두 배로 늘린다면, 당장 빨리 머지한 대신 나중에 갚을 빚을 늘린 것입니다.

에이전트 덕분에 작업이 얼마나 빨라졌는지 판단할 때는 머지한 뒤 코드를 이해하는 데 드는 비용까지 포함해야 합니다. 그 비용을 줄이는 가장 단순한 방법은 사람이 이해할 수 있는 크기로 PR을 나누는 것입니다.

리뷰는 통과 의례가 아닙니다. 코드의 소유권을 이전하는 의식입니다. 내용을 이해하지 못한 채로 사인한 계약서가 그렇듯, 모르는 코드에 대한 청구서도 언젠가 반드시 도착합니다.