코드 난이도의 비교 판단과 리뷰 범위 합의

1. ‘몇 줄인가’가 답하지 못하는 질문

리뷰 요청을 받았을 때 우리는 먼저 변경량, 파일 수, 순환 복잡도처럼 빨리 읽을 수 있는 표식을 본다. 이런 표식은 우선순위를 정할 때 유용하다. 다만 표식이 곧바로 ‘이 변경은 혼자 봐도 된다’ 또는 ‘이 변경은 위험하다’라는 결론이 되면 판단이 지나치게 단순해진다. 열 줄짜리 조건문도 도메인 규칙의 예외를 뒤집을 수 있고, 더 긴 변환 함수는 같은 패턴을 반복할 뿐일 수 있다. 코드의 양은 읽는 시간을 암시할 수 있어도, 어떤 지식을 호출해야 하는지까지 말해 주지는 않는다.

이 구분은 기분이나 취향의 문제가 아니다. ICER 2026의 사전등록 통제 연구는 대학생 551명이 Java·Python·C++ 코드 조각을 추적한 뒤 인지 부하를 보고하게 했다. 연구진은 여러 정적 복잡도 측정치를 비교했고, 그 연구 환경에서는 데이터 흐름 복잡도가 가장 강한 예측 변수라는 이전 결과를 확인하지 못했다고 보고했다. 반대로 단순 소스 코드 줄 수와 전문가의 쌍대 비교 평정이 더 강한 예측력을 보였다.

여기서 ‘줄 수가 최고의 리뷰 지표’라는 새 규칙을 뽑아내면 같은 실수를 반복한다. 연구의 과제는 전문 개발자의 실제 PR 검토가 아니라 학생의 코드 추적이며, 자기보고 인지 부하와 리뷰 결함 발견은 같은 결과가 아니다. 언어, 과제, 참가자, 측정 방식이 바뀌면 결과도 달라질 수 있다. 이 연구가 실무에 주는 더 조심스러운 신호는 정교해 보이는 정적 지표 하나를 인간 이해의 대리물로 확정하지 말라는 것이다.

그래서 리뷰 운영에서 더 적합한 질문은 ‘복잡도 점수가 얼마인가’보다 ‘이 변경을 이해하려면 어떤 사실을 동시에 붙들어야 하는가’다. 인증 정책과 이전 호환성, 장애 시 복구 경로가 한 작은 변경에 함께 들어가면 코드 줄 수가 적어도 검토 범위를 넓혀야 한다. 반대로 입력과 출력이 명확하고 독립 테스트가 있는 큰 리팩터링은 여러 사람이 같은 맥락을 새로 학습할 필요가 적을 수 있다. 이는 자동 분류 규칙이 아니라, 리뷰 시작 전에 꺼내 볼 판단 언어다.

2. 점수 대신 ‘대조 사례’를 만드는 방법

비교 판단은 모든 PR을 회의에 올리자는 뜻이 아니다. 팀이 최근에 보았던 두 변경을 짧게 나란히 놓고, 어느 쪽이 더 많은 추론을 요구했는지와 이유를 말해 보는 방식이다. 예를 들어 A는 한 파일의 짧은 null 처리 변경이지만 결제 취소 규칙을 바꾼다. B는 더 긴 데이터 정리 작업이지만 입력 형식과 되돌리기 절차가 명시돼 있다. 여기서 중요한 것은 A 또는 B에 난이도 등급을 붙이는 일이 아니라, 도메인 예외·영향 범위·되돌림 가능성·검증 근거 중 무엇이 리뷰어의 머릿속에 추가로 올라가는가를 드러내는 일이다.

다음은 측정 도구가 아니라 팀의 업무 점검 질문으로 쓸 수 있는 작은 기록 형식이다. 실제 성과나 결함 발견률을 보장하는 양식이 아니며, 팀의 맥락에 맞지 않으면 항목을 줄여도 된다.

# 비교 판단 메모

- 이번 변경의 의도: 사용자가 체감하는 동작을 한 문장으로 적는다.
- 대조할 이전 변경: 비슷한 결과물 또는 비슷한 위험을 가진 사례 링크를 적는다.
- 새로 필요한 추론: 도메인 규칙 / 영향 범위 / 복구 경로 / 테스트 해석 중 해당하는 것을 문장으로 적는다.
- 리뷰 경로: 독립 검토 / 함께 보기 / 추가 맥락 요청 중 하나와 이유를 적는다.
- 남은 불일치: 합의하지 못한 판단을 다음 비교에서 확인할 질문으로 남긴다.

이 기록은 티켓의 새 체크박스를 늘리는 장치가 아니다. 오히려 ‘큰 변경이니 많은 사람을 태그하자’ 같은 자동 반응을 멈추게 한다. 함께 보기가 필요한 이유가 정책의 뜻인지, 변경 전후의 운영 경로인지, 테스트가 포착하지 못하는 외부 계약인지 한 문장으로 적으면 필요한 사람과 자료가 더 선명해진다. 반대로 이유를 쓰기 어렵다면, 아직 리뷰 범위를 과장해서 정하고 있을 가능성도 살펴볼 수 있다.

대조 사례는 반드시 성공적으로 끝난 PR일 필요도 없다. 되돌린 변경, 리뷰 중 설계가 바뀐 변경, 테스트가 부족해 배포를 미룬 변경도 좋은 재료가 된다. 다만 결과만 보고 “처음부터 어렵던 변경”이라고 쓰면 사후 확신이 섞이기 쉽다. 당시 리뷰어가 실제로 볼 수 있었던 정보와, 나중에 알게 된 정보를 나눠 적는다. 예를 들어 배포 뒤 발견된 호환성 문제는 당시 코드만으로 보였는지, 문서나 계약 테스트에서 이미 단서가 있었는지를 구분한다. 그래야 대조 사례가 비난의 기록이 아니라 다음번에 필요한 맥락의 목록이 된다.

또한 비교 대상은 비슷한 줄 수보다 비슷한 판단을 요구하는 변경으로 고르는 편이 낫다. 결제 상태 변경과 사용자 권한 변경은 코드 모양이 다르더라도 외부 계약, 예외 처리, 되돌림의 판단을 함께 요구할 수 있다. 반면 같은 프레임워크 파일이라도 한쪽이 단순 이름 변경이고 다른 쪽이 기본 동작을 바꾸면 대조의 가치가 작다. 사례를 고를 때 “코드가 닮았는가” 다음에 “리뷰어가 확인해야 했던 전제가 닮았는가”를 묻는 이유다.

이 방식은 특히 새 구성원이 들어온 팀에서 유용할 수 있다. 새 구성원에게 과거 PR 링크만 주면 무엇을 봐야 하는지 알기 어렵다. 짧은 비교 메모는 코드 밖의 판단 맥락을 보여 준다. 그렇다고 메모가 온보딩 교재를 대체하지는 않는다. 현재의 서비스 경계와 운영 절차를 먼저 설명하고, 과거 사례는 그 경계가 실제 변경에서 어떻게 작동했는지 보여 주는 보조 자료로 사용해야 한다.

▲ 비교 판단은 변경 의도에서 출발해 대조 사례·리뷰 경로·불일치 기록으로 이어진다. 이것은 실측 효과를 표시한 도표가 아니라 운영 흐름의 개념도다.

3. 불일치를 다음 판단의 입력으로 남기기

두 리뷰어가 같은 변경을 두고 다른 범위를 제안하는 일은 이상하지 않다. 한 사람은 서비스 계약을, 다른 사람은 배포 시 되돌림을 먼저 떠올릴 수 있다. 이 차이를 ‘누가 더 꼼꼼한가’로 정리하면 팀은 다음번에도 같은 논쟁을 반복한다. 대신 차이를 만든 전제를 남겨야 한다. 예컨대 “이 API는 외부 고객이 호출한다는 전제라 함께 봤다” 또는 “플래그로 즉시 되돌릴 수 있다는 전제라 독립 검토로 충분하다고 봤다”처럼 쓴다.

이때 기록의 목적은 사람별 난이도 점수나 리뷰 속도 순위를 만드는 것이 아니다. 그런 지표는 방어적 행동을 부르고, 사례를 솔직히 남길 이유를 줄일 수 있다. 목적은 다음에 유사한 변경이 왔을 때 팀이 기억에만 기대지 않도록, 비교 가능한 근거를 하나 더 만드는 것이다. 사례가 쌓이면 ‘보안 관련이면 무조건 세 명’ 같은 규칙보다 ‘외부 계약과 되돌림 경로가 둘 다 바뀌면 함께 보자’처럼 맥락을 보존한 합의가 가능해진다.

운영은 아주 작게 시작할 수 있다. 한 스프린트에 한 번, 이미 끝난 두 PR을 15분 동안 대조한다. 진행자는 결과의 좋고 나쁨을 평가하지 않고, 각 변경에서 새로 요구된 추론을 받아 적는다. 팀이 의견을 모으지 못하면 억지로 다수결을 하지 말고 불일치와 전제를 남긴다. 다음 유사 사례가 왔을 때 그 메모를 열어 현재의 계약, 테스트, 배포 조건과 비교한다. 비교 대상이 늘면 오래된 사례가 현재 시스템과 맞지 않을 수 있으므로, 결정 근거가 바뀌었는지도 함께 표시한다.

4. 자동화가 맡을 일과 사람이 남겨야 할 일

정적 분석과 PR 자동화는 이 흐름에서 여전히 유용하다. 변경 파일, 의존 관계, 테스트 실행 결과, 공개 API 여부처럼 기계가 일관되게 모을 수 있는 사실을 먼저 제시하면 사람은 그 사실의 의미를 토론하는 데 시간을 쓸 수 있다. 자동화는 ‘이전과 다른 외부 계약이 있는가’를 알리는 신호가 될 수 있지만, 계약의 중요도나 팀이 감수할 수 있는 되돌림 비용까지 스스로 판정했다고 가정해서는 안 된다.

실무에서 이 구분을 지키려면 자동화 결과의 문장을 바꾸는 편이 도움이 된다. “이 PR은 고위험”이라는 라벨 대신 “공개 인터페이스 파일이 바뀌었음”, “마이그레이션 파일이 포함됨”, “테스트가 추가되지 않음”처럼 관찰된 사실을 보여 준다. 그러면 리뷰어는 그 사실이 이번 서비스에서 어떤 의미인지 판단할 수 있다. 같은 마이그레이션이라도 롤백 절차가 준비됐는지, 호환 기간이 있는지, 데이터가 재생성 가능한지에 따라 함께 봐야 할 이유는 달라진다. 자동화가 결론을 선점하지 않을수록, 사람의 검토는 근거와 예외에 집중할 수 있다.

비교 메모도 오래 보관할 문서일 필요는 없다. 저장소의 PR 템플릿이나 팀 위키에 최근 사례 몇 개만 남기고, 시스템 구조가 바뀌면 오래된 메모에는 ‘현재 조건과 다를 수 있음’을 붙인다. 중요한 것은 사례의 수가 아니라 비교를 가능하게 하는 맥락이다. 링크만 남기지 말고, 당시 어떤 외부 계약·되돌림 경로·테스트 한계가 판단을 넓혔는지를 한두 문장으로 적는다. 그래야 새 구성원이 과거 결론을 규칙처럼 복사하지 않고, 현재 변경과 무엇이 같은지 무엇이 다른지 검토할 수 있다.

리드나 리뷰 진행자는 이 과정에서 답을 빨리 내리는 사람보다 질문의 범위를 조절하는 사람에 가깝다. “이 변경을 승인할 수 있나”만 묻기보다 “독립적으로 확인 가능한 부분은 어디까지인가”, “같이 봐야 하는 전제는 무엇인가”, “지금 모르는 사실은 무엇인가”를 순서대로 묻는다. 이 질문들은 리뷰를 길게 만들기 위한 장치가 아니라, 필요 없는 동시 검토와 누락된 맥락 검토를 동시에 줄이기 위한 구분선이다. 팀의 시간과 집중력은 한정돼 있으므로, 범위 합의는 더 많은 절차가 아니라 더 정확한 배분을 목표로 해야 한다.

팀이 지켜야 할 경계도 있다. 비교 판단은 연구의 전문가 평정을 흉내 내는 인증 제도가 아니며, 학생 연구의 결과를 전문 개발 조직에 그대로 이전하는 것도 아니다. 특정 도구가 높은 점수를 받았다고 리뷰 시간을 줄이거나, 특정 사람이 낮은 점수를 매겼다고 역량을 평가하지 않는다. 이 글의 제안은 결과를 예측하는 모델이 아니라, 정적 지표가 놓치는 전제를 말로 꺼내는 운영 문서다.

코드 리뷰의 부담을 ‘작은 코드냐 큰 코드냐’로만 나누면, 팀은 이해의 어려움을 너무 늦게 발견한다. 반대로 모든 변경을 무겁게 다루면 협업 자체가 병목이 된다. 지표는 첫 신호로, 대조 사례는 질문을 만드는 재료로, 짧은 합의 메모는 다음 판단의 기억으로 두는 편이 낫다. 난이도를 정확하게 계산할 수는 없지만, 무엇을 함께 이해해야 하는지는 더 정직하게 드러낼 수 있다.

참고 자료

• How (and How Not) Do Code Complexity Measures Predict Cognitive Load? — ICER 2026