인지적 부채 - AI 시대의 코드 리뷰에서 살아남기

https://lobste.rs/s/7tpc5q/surviving_code_reviews_era_ai

2026.9.5
[Surviving Code Reviews in the era of AI]

이 소스는 AI 기반 개발 시대를 맞이한 소프트웨어 엔지니어들이 겪는 코드 리뷰의 위기와 그 대응 전략을 다룬 논의를 담고 있습니다. 주요 쟁점은 AI가 생성한 거대한 규모의 코드 변경분(Pull Request)이 인간의 검토 능력을 초과하면서 발생하는 엔지니어링 품질 저하와 이를 용인하는 기업 문화에 대한 비판적 시각입니다. 토론자들은 리뷰 단위를 잘게 나누는 스택형 PR(Stacked PRs) 기법이나 AI를 활용해 첫 번째 검토를 수행하는 방식을 대안으로 제시하지만, 동시에 인간의 시스템 이해력 상실과 '슬롭(Slop)'이라 불리는 저품질 코드의 양산을 깊이 우려합니다. 결국 이 텍스트는 기술적 해결책을 넘어, 소프트웨어의 신뢰성과 책임을 보장하기 위해 개발자가 지켜야 할 최소한의 직업 윤리와 조직적 경계 설정이 필요함을 역설하고 있습니다.

 

 

이 링크는 정식 챕터가 있는 기술 기사가 아니라 “AI가 생성한 대규모 코드를 사람이 어떻게 리뷰할 것인가?”를 묻는 Lobsters 질문·토론입니다. 아래는 질문과 주요 댓글을 주제별 8개 챕터로 재구성한 분석입니다. 원문에 있는 주장과 제 해석·권고를 구분했습니다.

핵심 결론은 다음과 같습니다.

AI 시대 코드 리뷰의 문제는 코드 생성 속도만이 아니라, 변경을 이해하고 검증하는 비용이 누구에게 전가되며, 누가 최종 책임을 지는가에 있다.

 

1장. 문제 제기 — 평균 약 6,000줄의 변경을 사람이 검토할 수 있는가?

원문 내용

질문자 mrpossoms는 동료들이 AI 코딩에 적극적으로 의존하면서, 자신에게 들어오는 PR의 diff가 평균 약 6,000줄이라고 설명합니다. PR은 코드 병합 요청이고, diff는 추가·삭제 등 변경 내용을 뜻합니다.[1]

그가 제기하는 문제는 두 가지입니다.

• 사람이 시스템의 작동 원리를 이해해야 한다고 생각하지만, 변경량이 지나치게 많다.
• AI의 설명도 장황하고 따라가기 어려워, AI 리뷰에 의존하는 것이 해결책인지 확신하지 못한다.[1]

분석

이 질문의 본질은 작성 능력과 검증 능력의 불균형입니다.

AI를 사용하면 많은 코드를 빠르게 만들 수 있지만, 리뷰어에게는 여전히 다음 작업이 남습니다.

• 변경 목적과 요구사항 파악
• 기존 시스템과의 상호작용 확인
• 실패 조건과 예외 처리 검토
• 테스트의 적절성 판단
• 유지보수 가능성과 설계 일관성 확인

따라서 코드 생산량 증가를 곧바로 팀 생산성 증가로 해석할 수는 없습니다. 검증·재작업·운영 단계로 비용이 이동했을 가능성도 함께 봐야 합니다.

근거의 한계

약 6,000줄이라는 수치는 질문자의 자기보고이지, 산업 전체의 평균이 아닙니다. 또한 질문자의 “그보다 훨씬 작은 PR도 효과적으로 리뷰하기 어렵다는 것은 잘 알려져 있다”는 주장에는 해당 글 안에서 연구 근거가 제시되지 않습니다. 댓글에서도 언어별 코드 밀도와 연구 근거를 묻는 반론이 나옵니다.[1]

실무 시사점: PR 크기만 기록하지 말고, 리뷰 시간·재작업·병합 후 결함까지 연결해서 관찰해야 합니다.

 

2장. PR 크기 제한 — AI 코드에도 기존 품질 기준을 적용해야 하는가?

원문 내용

wmoxam은 자신의 직장에서 400줄을 초과하는 diff를 제한하며, 코드 이동 같은 예외만 인정한다고 설명합니다. 이 기준은 사람이 작성했든 AI가 작성했든 동일하게 적용됩니다.[1]

다른 참여자들도 큰 PR을 반려하고, 작은 변경이나 stacked PR로 나누라고 권합니다. Stacked PR은 서로 의존하는 변경을 여러 PR로 나누어 순차적으로 검토하는 방식입니다.[1]

분석

이 접근의 핵심은 “AI 코드를 불신하자”가 아닙니다.

생성 방법과 관계없이, 검증 가능한 단위로 제출하라는 원칙입니다.

다만 줄 수 제한만으로 리뷰 가능성이 보장되지는 않습니다.

변경 유형	줄 수만으로 판단하기 어려운 이유
코드 이동·포맷 변경	diff는 커도 실제 동작 변경은 작을 수 있음
인증·권한 조건 변경	몇 줄만 바뀌어도 영향이 클 수 있음
데이터 스키마 변경	다른 서비스·배치·마이그레이션까지 영향을 줄 수 있음
기능 변경과 리팩터링 혼합	무엇이 동작을 바꾸는지 구분하기 어려움
생성 파일·반복적 테스트 데이터	전체 diff와 사람이 집중할 부분이 다를 수 있음

실무 시사점

400줄은 댓글 작성자의 조직 규칙이지, 보편적 표준이나 과학적으로 확정된 임계값이 아닙니다.

권고하는 관리 방식은 다음과 같습니다.

• 줄 수는 리뷰 부담을 알리는 경보값으로 사용
• 기능 변경과 기계적 변경 분리
• 변경 목적을 하나로 제한
• 위험도가 높은 변경에는 크기와 무관하게 전문 검토 적용
• 예외 승인 시 사유와 검증 방법 기록

[보완 필요] “작게 나눴다”는 형식적 조건뿐 아니라, 각 변경의 목적·의존성·검증 방법이 설명되는지 확인해야 합니다.

 

3장. 작성자 책임 — AI가 만들었어도 제출자가 이해해야 한다

원문 내용

여러 댓글은 PR 작성자가 자신의 변경을 이해하고, 본인의 말로 목적과 이유를 설명할 수 있어야 한다고 강조합니다.[1]

pyj는 PR에 “왜 필요한가?”와 “무엇을 바꿨는가?”에 대한 좋은 설명이 없으면 즉시 돌려보낸다고 말합니다. 리뷰어에게 변경 목적을 역공학하도록 떠넘겨서는 안 된다는 취지입니다.[1]

olliej는 작성자가 AI 생성 코드를 먼저 직접 검토하고, 발견·수정한 문제와 리뷰에 소요한 시간을 기록하라고 제안합니다.[1]

분석

여기서 구분해야 할 것은 생성 주체와 책임 주체입니다.

• AI가 코드를 생성할 수는 있습니다.
• 그러나 제출·병합·배포 판단에 대한 조직적 책임이 자동으로 AI에 이전되는 것은 아닙니다.

작성자 사전 검토가 없다면, 리뷰어는 단순한 두 번째 검토자가 아니라 다음 역할까지 떠맡게 됩니다.

1. 요구사항 해석자

1. 코드 이해 담당자

1. 최초 품질 검증자

1. 설계 수정자

이 상태에서는 작성자의 “빠른 완료”가 리뷰어의 추가 작업으로 만들어진 것일 수 있습니다.

실무 적용 — PR에 요구할 설명

다음은 토론을 바탕으로 재구성한 권고 항목입니다.

항목	작성자가 설명할 내용
목적	어떤 요구사항이나 문제를 해결하는가
변경 범위	무엇을 바꾸고, 무엇은 바꾸지 않았는가
설계 판단	왜 이 방식을 선택했는가
영향 범위	관련 호출부·데이터·권한·외부 연계는 무엇인가
검증 결과	어떤 테스트를 실행했고 결과는 무엇인가
잔여 위험	아직 검증하지 못한 조건은 무엇인가
사전 검토	작성자가 직접 확인하고 수정한 내용은 무엇인가

다만 사전 검토 시간은 보조 정보이지 품질의 증명은 아닙니다. 오래 읽었다고 올바르게 검토했다는 뜻은 아니므로, 구체적인 검토 결과와 실행 증거가 더 중요합니다.

 

4장. AI 리뷰의 역할 — 유용한 1차 점검인가, 새로운 잡음인가?

원문 내용

참여자들은 AI 리뷰 도구에 대해 상반된 경험을 보고합니다.

• 일부는 테스트 누락, 경계조건, 사람이 놓친 결함을 찾는 데 유용하다고 평가합니다.
• 일부는 비싼 비용과 불필요한 지적이 많다고 비판합니다.
• Claude, Codex, Copilot, Greptile, CodeRabbit, cubic 등의 사용 경험이 언급됩니다.[1]

viraptor는 변경 patch만 보는 도구보다 전체 코드베이스에 접근할 수 있는 도구를 사용하라고 권합니다. koreth는 수정하지 않은 코드와 관련된 다단계 사용자 시나리오의 결함을 Codex가 찾아낸 사례를 설명합니다.[1]

분석

여기에는 성격이 다른 AI 활용이 섞여 있습니다.

활용 방식	기대하는 역할	인간에게 남는 판단
변경 요약	목적과 주요 변경 위치 파악	요약의 정확성 확인
리뷰 안내서	읽을 순서·주의 지점 제시	누락된 위험 확인
결함 탐색	실패 시나리오 후보 발견	재현·타당성 판단
테스트 보조	누락된 사례 제안	기대 결과의 정당성 검토
병합 의견	변경의 적합성 평가	실제 승인과 위험 수용

토론에서 가장 방어 가능한 사용 방식은 AI가 검토 후보를 만들고, 사람이 근거를 판단하는 보조 모델입니다. 그러나 이것도 전체 코드의 안전성을 입증하는 것은 아닙니다.

근거의 한계

이 토론만으로 특정 도구가 다른 도구보다 우수하다고 결론 낼 수 없습니다.

사용자별 코드베이스, 모델, 프롬프트, 요구사항, 평가 기준이 다릅니다. 언급된 도구 평가는 개인·팀의 경험담이지 통제된 비교 실험 결과가 아닙니다.[1]

실무 시사점: AI 지적은 곧바로 수정 지시로 취급하지 말고, 재현 가능한 결함인지·조직 기준 위반인지·단순 취향인지 분류해야 합니다.

 

5장. 무한 리뷰 — AI가 계속 지적하면 품질도 계속 좋아지는가?

원문 내용

gkoos는 자신의 직장에서 있었던 AI 보조 리뷰 사례를 설명합니다.

• 첫 번째 리뷰: 유용한 경계조건과 합리적 제안
• 두 번째 리뷰: 주로 사소한 지적
• 세 번째 리뷰: 두 번째에 요구했던 변경을 사실상 되돌리는 제안

결국 의미 있는 완료 상태로 수렴하지 않는다고 판단해 중단했다고 합니다.[1]

그는 인간 리뷰어에게는 “내가 작성했을 방식과 같지는 않아도 병합할 만큼 충분히 좋다”는 종료 조건이 있지만, AI에는 감독자가 그런 기준을 제공해야 한다고 주장합니다.[1]

분석

이 사례는 리뷰 횟수와 품질 향상을 동일시해서는 안 된다는 점을 보여줍니다. 다만 단일 경험담이므로 모든 모델·도구가 같은 방식으로 작동한다고 일반화할 수는 없습니다.

AI에 계속 “문제를 찾아라”라고 요구하면, 객관적 결함과 주관적 선호가 혼재할 수 있습니다. 이때 팀은 다음과 같은 낭비를 겪을 수 있습니다.

• 근거가 약한 지적까지 모두 수정
• 이전 수정과 충돌하는 재수정
• 불필요한 변경으로 검증 범위 확대
• 실제 위험보다 표현·스타일에 시간 소모

실무 적용 — 종료 조건을 명시하기

다음은 분석자 권고입니다.

• 미해결 지적을 결함·위험·개선 제안·취향으로 구분
• 병합을 막는 문제에는 근거와 재현 조건 요구
• 스타일 문제는 가능한 한 정적 규칙으로 처리
• 새 지적이 이전 지적과 충돌하는지 확인
• 필수 검증이 완료되면, 취향 차이만으로 리뷰를 무한 반복하지 않음

핵심: “AI가 더 이상 할 말이 없다”보다 “합의한 수용 기준을 충족했다”가 종료 기준이어야 합니다.

 

6장. 의미 단위 분할 — 줄 수를 줄이는 것과 이해하기 쉽게 만드는 것은 다르다

원문 내용

sunshowers는 리팩터링과 기능 변경을 분리하는 방식을 설명합니다. 여러 준비 리팩터링을 거쳐 기능 변경이 자연스럽게 가능해지도록 만들고, 리뷰어가 실제 동작 변경에 집중하게 한다는 접근입니다.[1]

markerz는 AI가 분할 작업 자체는 잘 수행할 수 있지만, 좋은 분할 경계를 결정하는 능력은 부족하다고 평가합니다.[1]

반면 mandeep은 AI가 작은 커밋이나 stacked PR로 나누어도, 각 부분이 독립적으로 더 이해하기 쉬워지지는 않았다는 경험을 제시합니다.[1]

분석

이 논쟁은 “작은 PR”의 목적을 분명히 합니다.

목적은 줄 수 감소가 아니라 독립적으로 이해하고 판단할 수 있는 변경 단위의 형성입니다.

다음과 같은 분할은 효과가 제한적입니다.

• 단순히 파일별로 나누기
• 일정 줄 수마다 자르기
• 앞선 변경을 알아야만 이해되는 부분을 설명 없이 분리
• 테스트와 구현 사이의 관계를 끊어 놓기

좋은 분할에는 각 단위의 목적, 의존성, 검증 방법이 필요합니다.

실무 적용

예를 들어 데이터 처리 기능 변경이라면 다음 순서로 구성할 수 있습니다. 이는 원문의 실제 구현 사례가 아니라 설명용 예시입니다.

• 기존 동작과 실패 사례를 확인하는 테스트

• 동작을 유지하는 구조 정리

• 새 기능 구현과 관련 테스트

• 외부 연계·마이그레이션 변경

• 불필요해진 경로 제거

AI로 커밋 이력을 재구성할 때 최종 코드 상태가 동일한지도 확인해야 합니다. 다만 최종 diff가 같다는 사실은 결과 코드가 보존됐다는 증거이지, 중간 커밋마다 정상 동작한다는 증거는 아닙니다.

 

7장. 인지 부채와 소통 — 코드가 늘어나는 동안 팀의 이해는 줄어든다

원문 내용

Review Board 창업자라고 소개한 chipx86는 큰 diff뿐 아니라 변경 유입 증가와 사람 머릿속에 축적되는 맥락의 감소를 문제로 지적합니다. 그는 AI를 활용해 변경을 작은 부분으로 나누거나, 리뷰 시작 위치와 주의점을 안내하도록 하는 방안을 제안하며 “인지 부채(cognitive debt)”를 언급합니다.[1]

다른 참여자들은 AI 설명의 장황함, 불필요한 전문용어, 반복적 주석이 이해 비용을 높인다고 말합니다. 또 faassen은 이슈 작성과 최종 PR 사이에도 개발자들이 함께 논의하며 시스템 이해를 형성해야 한다고 주장합니다.[1]

분석

기술 부채와 인지 부채는 구분해서 볼 필요가 있습니다.

구분	핵심 문제
기술 부채	코드·설계가 향후 변경 비용을 높임
인지 부채	팀이 코드·설계의 이유와 작동 방식을 충분히 이해하지 못함

코드가 현재 정상 동작하더라도, 담당자가 다음 질문에 답하지 못하면 운영과 유지보수 위험은 남습니다.

• 왜 이 구조를 선택했는가?
• 어떤 전제를 유지해야 하는가?
• 장애가 나면 어디부터 확인해야 하는가?
• 무엇을 바꾸면 다른 기능이 깨지는가?

실무 시사점

AI 생성 설명을 길게 보존하는 것보다 다음 구조로 정리하는 편이 검증에 유리합니다.

사람이 확인한 의도 → 실제 코드 위치 → 실행·관찰 결과 → 남은 불확실성

특히 토론에는 AI 분석문을 로그·스택 트레이스처럼 첨부해도 되는지에 대한 논쟁이 있습니다. 한 참여자는 로그가 실제 발생 사건의 증거인 반면, AI 설명은 그렇지 않다고 지적합니다.[1]

따라서 AI 문서에는 관찰 사실, 추론, 제안을 나누어 표시하는 것이 좋습니다.

 

8장. 조직 운영과 책임 — 리뷰어 개인이 해결할 수 있는 문제인가?

원문 내용

bmo 등은 큰 PR을 거부해야 한다고 생각해도, 경영진이 속도를 우선하면 기준을 집행하기 어렵다고 설명합니다. 일부 참여자는 관리자의 리뷰 기대 수준을 확인하거나, 개인이 조직 전체의 품질 문제를 떠안지 말라고 조언합니다.[1]

munificent는 두 가지 개발 모델을 제시합니다.

1. 인간 이해 중심: AI가 도와도 사람이 소스코드를 이해하고 검토한다.

1. AI 위임 중심: 인간은 상위 수준에서 요구와 결과를 관리하고, 구현은 AI 에이전트에 맡긴다.[1]

이에 대해 abeyer는 기존 외주 개발에서는 발주자가 코드를 몰라도 개발사 내부에는 코드를 이해하는 사람이 있었다며, 전 과정에서 그런 이해가 없는 경우와는 다르다고 반박합니다.[1]

분석

이 토론에서 가장 중요한 조직적 질문은 다음입니다.

“리뷰어에게 최종 승인 책임을 요구하면서, 그 책임을 수행할 시간·정보·거부 권한도 주고 있는가?”

AI 위임 중심 운영을 택하더라도 “사람이 코드를 덜 읽는다”는 것과 “검증이 덜 필요하다”는 것은 다릅니다. 검증 방법과 위험 수용 책임을 별도로 설계해야 합니다.

또한 “AI 검토만 수행함”이라는 기록은 검토 범위를 알리는 데 유용할 수 있지만, 안전성과 책임 문제가 해결됐다는 뜻은 아닙니다.

실무 시사점

• 리뷰 목적을 명시: 기능 확인인지, 설계 검토인지, 보안 검토인지
• 검토 범위와 미검토 범위를 구분
• 반려·추가 검증 요구 권한 보장
• 중요한 위험의 수용 주체와 근거 기록
• 보안·개인정보·안전 관련 변경은 별도 통제 적용

주의: 댓글의 윤리·책임 논쟁은 참여자의 의견입니다. 이를 법적 책임에 대한 확정적 판단으로 읽어서는 안 됩니다.

 

종합 평가

이 토론이 설득력 있게 보여주는 것

• 대규모 AI 생성 변경이 리뷰어에게 부담을 전가할 수 있다는 현장 경험
• 작성자 사전 검토와 설명 책임의 중요성
• 의미 있는 분할과 개발 초기 협업의 필요성
• AI 리뷰의 유용성과 잡음이 동시에 존재한다는 점
• 리뷰 품질이 도구뿐 아니라 조직의 기대·권한에 좌우된다는 점[1]

이 토론만으로 입증되지 않는 것

• 모든 6,000줄 PR은 효과적으로 검토할 수 없다는 보편적 명제
• 400줄 또는 600줄이 과학적으로 확정된 최적 기준이라는 주장
• 특정 AI 리뷰 제품의 객관적 우위
• AI 코드는 인간 코드보다 항상 품질이 낮거나 높다는 주장
• 반복 AI 리뷰가 일정 횟수 뒤 품질을 보장한다는 주장

 

최종적으로 이 토론은 “AI 리뷰를 더 많이 사용하라”보다는, “AI로 늘어난 변경량에도 이해·검증·책임의 연결을 유지하라”는 문제 제기로 읽는 것이 타당합니다. 코드 생성 속도보다 중요한 것은, 팀이 변경을 검증 가능한 형태로 제출하고 실제 근거로 승인할 수 있는가  입니다.

Sources

[1] https://lobste.rs/s/7tpc5q/surviving_code_reviews_era_ai — Surviving Code Reviews in the era of AI | Lobsters