Show Cover Slide

PR은 코드리뷰가 아니다: 대화에서 시작된 구조적 분리

1. 대화에서 시작된 오해

최근 코드리뷰에 대한 이야기를 나누던 중, 저 스스로 하나의 실수를 깨달았습니다.
PR(Pull Request)와 코드리뷰를 명확히 구분하지 않고 혼재된 개념으로 말하다 보니, 제 의도가 정확히 전달되지 않았던 것이죠.

예전 저는 이렇게 말한 적이 있습니다.

“PR을 통한 승인 절차보다는, 전체 코드를 돌아보고 기준을 점검하는 ‘리팩토링 데이’ 같은 회고 기반 접근을 더 중요하게 여깁니다.”

이에 대해 어떤 분이 “코드리뷰를 중요하게 생각하지 않으시나요?”라고 물었고,
저는 그 질문을 단순히 PR 리뷰의 중요성을 묻는 것이라 받아들였습니다.
그래서 “코드리뷰를 중요하게 여기지 않는다는 의미가 아니라,
공통된 기준을 합의하는 것이 더 본질적이라는 뜻이었다”는 식으로 답변을 이어갔습니다.

하지만 나중에 곰곰이 돌아보니
그분이 말씀하신 ‘코드리뷰’는 단지 PR 상의 리뷰가 아니라,
팀이 함께 코드의 기준을 만들고, 맥락을 공유하며, 더 나은 방향을 함께 모색하는 문화적 행위였을 수 있습니다.

결국 우리는 같은 단어를 쓰고 있었지만,
서로 다른 개념을 이야기하고 있었던 셈입니다.

2. PR과 코드리뷰의 정의

PR과 코드리뷰는 왜 혼동되는가

많은 팀에서 코드리뷰는 PR과 함께 이루어집니다.
GitHub, GitLab 등 대부분의 협업 도구는 PR 화면에서 리뷰 기능을 제공하기 때문에,
자연스럽게 두 개념이 하나의 흐름처럼 여겨지기도 합니다.
저 역시 그렇게 받아들이고 있었고, 그것이 때로는 오해의 시작이 되었습니다.

지금에 와서 저는 이 두 가지를 다음처럼 구분합니다:

PR은 형식이다

PR은 코드 변경을 요청하는 기술적 인터페이스입니다.

• 브랜치에서 작업한 결과물을 공유하고
• 머지 전 상태에서 리뷰를 요청하며
• 변경 이력과 테스트 결과를 함께 검토할 수 있습니다.

즉, PR은 검토와 승인을 위한 요청의 형식이며, 협업의 시작점입니다.
그 자체가 코드리뷰는 아니며, 리뷰를 담을 수 있는 그릇에 가깝습니다.

코드리뷰는 과정이다

코드리뷰는 코드의 의도, 맥락, 구조를 팀이 함께 해석하고 조율하는 협업의 과정입니다.

• 이 코드가 무엇을 해결하고자 했는지
• 팀의 기준에 맞게 작성되었는지
• 구조적으로 더 나은 방향이 있는지
• 미래의 팀원이 읽고 유지보수할 수 있을지를 함께 따져보는 일입니다.

코드리뷰는 PR 없이도 존재할 수 있습니다.
설계 리뷰, 페어프로그래밍, 리팩토링 회고 등 다양한 형태로도 이뤄질 수 있습니다.

PR과 코드리뷰의 차이 정리

오해와 한계가 발생하는 이유

하지만 이 두 구조가 자주 함께 쓰이다 보니,
PR을 열고 누군가 approve 버튼을 누르면 자연스럽게 리뷰도 끝났다고 생각하는 경우가 많습니다.
이는 흔한 오해입니다.

PR은 코드리뷰를 담을 수 있는 형식일 뿐,
그 안에서 의도를 이해하고, 기준을 점검하고, 구조를 논의하는 과정이 생략된다면
리뷰는 ‘하지 않은 것’과 다르지 않습니다.

그리고 또 하나의 오해는,
PR이라는 형식을 사용하면 언제나 리뷰가 포함될 것이라는 기대입니다.
하지만 실제로는 다음과 같은 경우가 자주 발생합니다:

• 리뷰 없이 바로 머지되는 긴급 PR
• 승인만 받고 피드백은 생략되는 형식적 리뷰
• 한 명의 승인만으로 넘어가는 구조적 단순화
• 코드 변경은 크지만 시간 부족으로 리뷰 생략

이런 상황에서 저는 자연스럽게
PR이라는 구조가 리뷰를 포함하지 못하는 경우를 더 많이 경험하게 되었고,
그로 인해 “PR이 반드시 필요한 구조인가?”에 대한 의문도 생겼습니다.

결국 제가 얻은 결론은 이렇습니다.

PR은 코드리뷰를 담을 수 있는 통합 구조이지만,
모든 상황에서 리뷰를 담을 수 있는 구조는 아닙니다.
리뷰의 의도와 목표를 확실히 작동시키기 위해서는
PR과 코드리뷰를 서로 다른 구조로 인식하고 설계해야 한다는 것이 저의 관점입니다.

3. PR과 코드리뷰의 혼동이 만들어내는 문제들

PR은 코드리뷰를 담을 수 있지만, 그 안에서 리뷰가 제대로 작동하지 않는 경우가 많습니다.
그럼에도 불구하고 두 개념을 동일시한 채 운영하다 보면,
팀은 아래와 같은 문제에 반복적으로 부딪히게 됩니다.

리뷰가 아닌데도 리뷰를 했다고 착각하고,
리뷰가 필요한데도 구조적으로 생략되며,
결국 코드리뷰는 문화가 아니라 절차로만 남게 됩니다.

3-1. 리뷰는 승인 절차로 축소된다

리뷰가 코드의 품질을 함께 논의하는 자리가 아니라,
머지 전 “통과 확인용 절차”로 축소됩니다.

• “테스트 통과했나요?” → ✅ → 머지
• 리뷰어는 컨벤션, 테스트 상태만 확인하고 승인
• 구조, 설계, 목적에 대한 논의는 생략됨

결국 리뷰는 품질 보장이 아닌, 승인용 체크리스트가 됩니다.

3-2. 피드백은 반복적으로 무력화된다

리뷰가 늦게 시작되거나, PR 분량이 많고 급한 경우
“지금 수정은 어렵습니다”라는 말로 끝나기 쉽습니다.

• 급한 기능 릴리스, 핫픽스 등에서는 “일단 머지하고 보자”는 문화가 반복
• 피드백은 작성자에게 부담이 되고, 방어적으로 반응하게 됨

이런 상황이 반복되면, 리뷰 자체가 피하고 싶은 존재가 됩니다.

3-3. 지식은 팀에 축적되지 않는다

리뷰가 특정인 간의 승인 절차로만 이뤄지면,
코드의 맥락은 팀 전체가 아닌 소수에게만 남습니다.

• 코드의 의도, 설계 배경이 팀원 전체에 공유되지 않음
• 결국 “코드는 있지만, 맥락은 없는” 코드베이스가 만들어짐

이런 팀은 온보딩 비용이 점점 높아지고,
“이건 왜 이렇게 만들었죠?”라는 질문이 반복됩니다.

3-4. 리뷰는 예외 처리되는 관행이 된다

• “리뷰해달라고 했는데 안 봤어요”
• “approve는 다른 사람이 했고, 저는 그냥 머지했어요”
• “급해서 그냥 넘어갔어요”

리뷰가 반복적으로 우회된다면,
그것은 이미 리뷰가 문화로 작동하지 않는다는 신호입니다.

4. 코드리뷰가 잘 작동하는 구조란 무엇인가

코드리뷰는 단순히 머지를 막기 위한 절차가 아닙니다.
그것은 팀이 코드의 품질을 함께 해석하고,
공통된 기준과 맥락을 정렬해가는 협업의 도구입니다.

잘 작동하는 코드리뷰는 아래와 같은 구조적 특징을 가집니다.

4-1. 코드의 ‘의도’를 함께 해석한다

• “이 설계는 어떤 문제를 해결하려고 했나요?”
• “왜 이런 분리 방식을 선택하셨나요?”
• “이 구조는 앞으로 확장될 가능성을 고려한 건가요?”

리뷰는 단순한 코드 감사가 아니라
작성자의 선택과 맥락을 함께 해석하는 대화입니다.

4-2. 팀의 ‘기준’에 따라 피드백이 오간다

• 컨벤션, 책임 분리, 테스트 포함 여부 등
• 개인의 판단이 아니라 팀이 사전에 합의한 기준에 따라 판단

기준이 명확할수록
리뷰는 간섭이 아니라 정렬이 됩니다.

4-3. 피드백은 ‘탐색과 제안’의 언어로 표현된다

• “이 방식도 괜찮지만, 이런 구조는 어떨까요?”
• “이 부분은 나중에 리팩토링 대상으로 볼 수 있겠네요”

지적이나 평가가 아닌,
대화와 탐색의 언어로 피드백이 오갈 때
작성자는 방어적이 되지 않고, 리뷰는 성장의 기회가 됩니다.

4-44. 리뷰는 PR 이전과 이후에도 이어진다

• 구현 전 설계 리뷰, 기능 간 인터페이스 논의
• 배포 이후 리팩토링 회고나 기술 부채 점검

리뷰는 PR 안에만 존재하는 절차가 아닙니다.
코드가 만들어지고 운영되는 전체 흐름에서
맥락을 되짚고 품질을 정렬하는 구조여야 합니다.

5. PR이 잘 작동하는 구조란 무엇인가

PR은 코드리뷰를 담을 수 있는 기술적 구조입니다.
하지만 그 자체로 리뷰가 잘 이뤄지는 건 아닙니다.
PR이 제대로 작동하기 위해서는 아래와 같은 조건들이 충족되어야 합니다.

5-1. 목적과 맥락이 명확히 서술되어 있다

• “이 변경은 어떤 문제를 해결하기 위한 것인가요?”
• “기존과 무엇이 달라졌고, 왜 이 방법을 택했나요?”

PR에는 코드 변경뿐만 아니라
그 변경이 생긴 배경과 의도가 서술되어야 합니다.
그래야 리뷰어가 맥락을 함께 이해할 수 있습니다.

5-2. 단일 목적, 적정 분량으로 구성된다

• 하나의 PR은 하나의 주제 또는 목적만 포함
• 리뷰 가능한 범위(기능 단위, 적정 코드량)를 유지

크고 복잡한 PR은 리뷰 자체를 어렵게 만들고,
결국 리뷰는 흐려지고, 승인만 남게 됩니다.

5-3. 리뷰어를 위한 흐름이 구성되어 있다

• 커밋 단위가 논리적으로 쪼개져 있음
• 설정 파일, 테스트 코드, 주요 변경이 구분되어 명확히 읽히는 구조

PR은 ‘검토를 위한 문서’입니다.
리뷰어가 자연스럽게 따라 읽을 수 있도록 배려된 구성이 필요합니다.

5-4. 머지 이후 흐름이 명확히 정의되어 있다

• 머지되면 자동 배포? 수동 릴리즈? QA는 어디에서?
• 리뷰가 끝났지만 아직 머지하면 안 되는 사유가 있다면 명시

PR은 코드 변경만이 아니라,
팀의 협업 흐름까지 포함하는 인터페이스입니다.

6. 리팩토링 데이와 코드리뷰는 충돌하는가?

가끔 “코드리뷰가 잘 작동하면 리팩토링 데이는 필요 없는 거 아닌가요?”라는 질문을 받습니다.
하지만 실제로는 이 둘은 충돌하는 개념이 아닙니다.

코드리뷰는 기능 개발의 흐름 안에서 발생하는 짧은 호흡의 점검이고,
리팩토링 데이는 전체 흐름을 돌아보며 기준을 재정렬하는 긴 호흡의 회고 구조입니다.

비교: 코드리뷰와 리팩토링 데이

정리

리팩토링 데이는 코드리뷰가 놓치는 흐름을 살펴보는 시간입니다.
그리고 코드리뷰는 리팩토링 데이가 끝난 후 기준을 다시 실천에 옮기는 통로가 됩니다.

이 둘은 각각

• 하나는 지금을 보고
• 다른 하나는 지금까지를 봅니다.

리듬은 다르지만,
함께 있을 때 팀의 품질은 유지되고, 기준은 진화할 수 있습니다.

7. 반복 가능한 리뷰 문화를 만들려면

좋은 코드리뷰는 단발성으로도 가능합니다.
하지만 그것이 팀의 문화로 반복되고 유지되기 위해서는,
개인의 성실함이나 책임감만으로는 부족합니다.

반복 가능한 리뷰 문화는 다음과 같은 구조적 기반 위에서 만들어집니다.

7-1. 리뷰의 목적과 관점이 팀 차원에서 합의되어 있다

• 리뷰는 무엇을 보기 위한 것인가?
• 어떤 기준과 우선순위로 피드백을 주고받는가?

이 질문에 대해 팀 전체가 같은 언어로 말할 수 있어야
리뷰가 사람마다 다르게 작동하지 않습니다.

7-2. 리뷰는 업무 시간 안에 포함된다

• “시간 날 때 봐주세요”는 반복되지 않습니다.
• 리뷰는 명확히 업무의 일부로 계획되고 측정되어야 합니다.

시간이 확보되지 않으면 리뷰는 항상 “급한 일 뒤로” 밀리게 됩니다.

7-3. 리뷰 결과는 기록되고 회고된다

• 좋은 피드백은 기준으로 정리되고,
• 놓친 포인트는 다음 리뷰에 반영됩니다.

리뷰는 코드만 남기지 않고,
팀의 판단과 기준도 함께 남아야
문화로 축적될 수 있습니다.

7-4. 사람보다 구조가 유지되도록 설계된다

• 특정 시니어나 열정적인 1인에게 의존하면
  그 사람이 빠지는 순간 리뷰 문화도 사라집니다.

리뷰의 기준과 책임은 역할과 구조 속에서 반복 가능하게 배치되어야 합니다.

7-5. 리뷰 자체에 대한 리뷰(회고)가 존재한다

• “이 리뷰는 왜 놓쳤을까?”
• “이번 리뷰는 잘 작동했나?”
• “우리가 놓친 공통 패턴이 있었나?”

코드리뷰도 결국 하나의 프로세스입니다.
이 프로세스에 대한 메타 리뷰가 정기적으로 수행되어야
조직은 리뷰 문화를 진화시킬 수 있습니다.

8. 리뷰 구조는 다양할 수 있다

지금까지 리뷰 문화를 구조적으로 설명해왔지만,
그렇다고 해서 PR 기반 코드리뷰만이 정답은 아닙니다.

조직의 형태, 협업 도구, 제품의 속도와 성격에 따라
리뷰가 작동하는 방식은 충분히 달라질 수 있습니다.

팀 구조에 따라 리뷰 방식도 달라진다

• 작은 스타트업은 구두로 빠르게 피드백을 주고받는 방식이 더 효과적일 수 있고,
• 원격 근무가 많은 팀은 PR 기반 비동기 리뷰가 더 안정적일 수 있습니다.

배포 방식에 따라 리뷰 지점이 달라진다

• 어떤 팀은 PR 머지가 곧 배포인 GitOps 구조를 갖고 있고,
• 어떤 팀은 별도 QA나 테스트 단계를 두고 사내 도구에서 릴리즈를 관리합니다.

리뷰가 반드시 PR에 묶일 필요는 없습니다.

사람마다 리뷰 경험이 다르다

• PR 없이 협업하던 경험이 있는 사람,
• 모든 변경이 리뷰 없이 머지되는 팀에서 일했던 사람,
• 반대로 승인 없이는 절대 머지가 불가능한 팀에 있던 사람.

이처럼 같은 ‘리뷰’라는 단어에도
사람마다 다른 맥락과 기억을 갖고 있습니다.

결국 중요한 것은 형식이 아니다

리뷰가 작동하고 있는가?
리뷰가 코드의 품질과 책임을 나누는 구조로 작동하고 있는가?

그렇다면 그것이 PR 기반이든, 대면 리뷰든, 회고 중심이든
그 방식은 유효합니다.

9. 마무리

PR은 코드리뷰를 담는 기술적인 형식이고,
코드리뷰는 팀의 문화와 기준을 담는 협업의 과정입니다.

이 둘은 같지 않지만, 함께 맞물릴 수 있습니다.
PR이 흐름을 만들고, 코드리뷰가 그 안에 의미를 채울 때
비로소 협업은 단순한 절차를 넘어섭니다.

리뷰가 잘 작동하는 팀은
단지 코드를 검토하는 것이 아니라,
사람 간의 신뢰와 기준을 함께 리뷰하는 팀입니다.

그 구조가 있을 때,
리뷰는 문화가 되고,
문화는 반복될 수 있습니다.

중요한 것은 형식이 아니라 구조이고,
절차가 아니라 의도이며,
무엇보다도
그것이 반복 가능한가입니다.

부록. 코드리뷰 기준 예시

• 이 코드는 의도가 읽히는가?
• 팀의 기준이나 흐름에 자연스럽게 어울리는가?
• 리뷰 이후의 팀원이 유지보수하기 쉬운 구조인가?
• 테스트나 영향 범위는 충분히 고려되었는가?

📌 코드리뷰는 ‘틀렸는가?’를 찾는 게 아니라,
‘같이 더 나아질 수 있는가?’를 묻는 시간입니다.

부록. PR 기준 예시

• 왜 이 변경을 했는지 설명이 담겨 있는가?
• 한 가지 목적만을 가진 PR인가?
• 리뷰어가 이해할 수 있도록 배려되어 있는가?
• 머지 범위와 타이밍은 적절한가?

📌 PR은 코드를 위한 게 아니라,
사람을 위한 인터페이스입니다.