리뷰의 단위는 곧 이해의 단위
seonest읽지 않은 계약서에 사인한 적이 있으신가요?
AI 에이전트가 만든 1,800줄짜리 PR에 "Approve"를 누르는 일도 이와 다르지 않습니다. 에이전트는 점점 빨라지고, 한 번에 더 큰 변경을 만들어 냅니다. 그러나 그 변경을 책임지는 사람의 인지 용량은 그대로 유지됩니다.
인지적 항복
리뷰어가 PR을 열고 디프를 확인합니다. 처음 100줄은 꼼꼼하게 읽습니다. 200줄을 넘어가면 전체적인 흐름만 따라갑니다. 500줄쯤에서는 변수명과 함수 시그니처만 훑어보다가, 1,000줄이 넘으면 결국 "테스트는 통과했네"라고 말하며 리뷰를 끝냅니다.
이때 리뷰어는 인지적 항복(Cognitive Surrender) 에 이릅니다. 변경량이 머릿속에 담아 둘 수 있는 임계치를 넘어서면, 리뷰어는 이해하기를 포기하고 리뷰를 통과 의례처럼 치르게 됩니다. 리뷰는 형식적인 절차로 변하고, "Approve"는 검토의 결과가 아니라 절차의 일부가 됩니다.
문제는 이런 항복이 점점 더 자주 일어난다는 사실입니다. 에이전트는 새벽에도 일하고 점심시간에도 일합니다. 자고 일어나면 새로운 PR이 도착해 있습니다. 사람의 검토 속도는 에이전트의 생산 속도를 따라잡을 수 없습니다.
이해 부채
이해하지 못한 채로 머지된 코드는 사라지지 않습니다. 이해 부채(Understanding Debt) 가 되어 코드베이스에 축적됩니다.
부채에는 이자가 붙습니다. 한 달 뒤에 비슷한 기능을 추가할 때, 누군가는 그 코드를 처음부터 다시 읽어야 합니다. 버그가 발생하면 디버깅에 두 배의 시간이 듭니다. 리팩토링을 시도하더라도 어디까지 안전하게 고칠 수 있는지 아무도 알지 못합니다.
이해 부채는 기술 부채와 성격이 다릅니다. 기술 부채는 "알면서도 미뤄 둔 것"이지만, 이해 부채는 "처음부터 모르는 것"입니다. 알지 못하는 부채에 대해서는 상환 계획조차 세울 수 없습니다.
에이전트가 만든 코드라고 해서 책임의 소재가 바뀌지는 않습니다. 머지 버튼을 누른 사람이 그 코드의 소유자입니다. 모르는 코드를 소유한다는 것은 작동 원리를 이해하지 못한 기계를 떠맡는 일과 같습니다.
리뷰의 단위는 이해의 단위
리뷰의 단위는 곧 이해의 단위입니다. 한 번에 머릿속에 담아서 검증할 수 있는 크기, 바로 그 지점까지가 리뷰의 단위가 되어야 합니다.
PR이 1,800줄이라면, 그것은 에이전트가 효율적이라는 신호가 아니라 검토자가 감당할 수 있는 양을 넘어섰다는 신호입니다. 에이전트의 출력 크기와 사람의 입력 크기가 서로 다르다는 사실을 인정해야 합니다.
대략적인 가이드는 다음과 같습니다.
- PR 하나에는 의도 하나만 담습니다. 변경 의도가 두 가지 섞여 있으면 PR을 둘로 나눕니다.
- 커밋 단위로도 이해할 수 있어야 합니다. 머지한 뒤에
git log만 확인하고도 변경의 흐름을 따라갈 수 있어야 합니다. - PR 본문만 읽어도 이 변경이 왜 필요한지 이해되어야 합니다. 디프를 열어 보기 전에 이미 그 이유를 파악할 수 있어야 합니다.
이 단위는 도구가 아니라 사람의 한계가 결정합니다. 에이전트가 1,000줄을 30분 만에 만들어 낼 수 있다고 해도, 그것을 1,000줄짜리 PR 하나로 올릴 이유는 없습니다. PR 다섯 개로 나누거나 커밋 다섯 개로 분리해서 단계별로 검토할 수 있게 만드는 편이 옳습니다.
머지 후 이해 부채까지가 속도입니다
에이전트와 함께 일할 때 가장 큰 함정은 "빨라진 것 같은 느낌"입니다.
PR을 머지하는 시점만 보면 분명히 빠릅니다. 하지만 그 코드가 한 달 뒤에 누군가의 디버깅 시간을 두 배로 늘린다면, 그것은 빠른 것이 아니라 빚을 미리 당겨 쓴 것입니다.
에이전트의 속도는 머지 시점이 아니라, 머지 후 이해 부채까지 포함한 총 비용으로 측정해야 합니다. 그 비용을 줄이는 가장 단순한 방법은 사람이 이해할 수 있는 크기까지 PR을 나누는 것입니다.
리뷰는 통과 의례가 아닙니다. 코드의 소유권을 이전하는 의식입니다. 내용을 이해하지 못한 채로 사인한 계약서가 그렇듯, 모르는 코드에 대한 청구서도 언젠가 반드시 도착합니다.