Written by

seonest

At

Wed May 06 2026

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

AI 에이전트가 만든 거대한 PR 앞에서 일어나는 인지적 항복과 이해 부채. 리뷰 단위가 곧 이해의 단위인 이유.

Back

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

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로 올릴 이유는 없습니다. 5개의 PR로 쪼개거나, 5개의 커밋으로 나누어 단계별로 검토 가능하게 만드는 것이 옳습니다.

머지 후 이해 부채까지가 속도입니다

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

PR 머지 시점만 보면 분명히 빠릅니다. 하지만 그 코드가 한 달 뒤 누군가의 디버깅 시간을 두 배로 만든다면, 그건 빠른 것이 아니라 빚을 미리 당겨 쓴 것입니다.

에이전트의 속도는 머지 시점이 아니라, 머지 후 이해 부채까지 포함한 총 비용으로 측정해야 합니다. 그 비용을 줄이는 가장 단순한 방법은 PR을 작게 쪼개는 것입니다. 사람이 이해할 수 있는 크기까지요.

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

참고 자료