Split View: 코드 리뷰 완전 가이드: 리뷰를 프로세스로 설계하기

The Complete Guide to Code Review: Designing Review as a Process

• Introduction
• 1. The Four Reasons Review Actually Exists
• 2. Documenting the Approval Standard
  • 2-1. Without a standard, the reviewer's taste becomes the standard
  • 2-2. What counts as grounds
  • 2-3. The minimum to put in the team document
• 3. Change Size Decides Almost Everything
  • 3-1. Size sits upstream of every other metric
  • 3-2. Concrete ways to shrink it
  • 3-3. How to operate a size rule
• 4. Latency — the One-Business-Day Rule and Its Rationale
  • 4-1. The rule
  • 4-2. Why speed matters this much
  • 4-3. The conflict with focus time
• 5. What Humans Review and What Gets Pushed to Automation
• 6. Ownership and Approval Rules
  • 6-1. Who is allowed to approve
  • 6-2. Contested: how many approvals are required
  • 6-3. Contested: should review block merge at all
• 7. Comment Severity — What Blocks and What Does Not
  • 7-1. Without levels, every comment reads as blocking
  • 7-2. Contested: is approving with comments healthy
• 8. Escalation When Agreement Fails
• 9. Metrics for the Review Process, and How They Get Misused
  • 9-1. Metrics worth watching
  • 9-2. They break the moment they become individual metrics
• Quiz: Check Your Understanding
• Closing
• References
• Further reading

Introduction

This blog already has posts about code review. The Conversational Craft of Code Review and Reviews That Teach, Reviews That Wound are both about how words travel and how they land. They are good posts, but there is a layer they do not cover.

This post treats review as a system instead of a conversation: something with throughput, latency, a queue and ownership. In the same team, with the same people speaking with the same courtesy, review still fails if the change is 800 lines and the first response takes three days. Conversely, when the process is well designed, even an ordinary comment does its job. A large share of review quality problems are problems of arrangement, not tone.

The reference points are two pages from Google's engineering practices. Among publicly available material they specify the approval standard and the response-time expectation most concretely, and every quotation here comes from those originals.

1. The Four Reasons Review Actually Exists

Building a process on the premise that "review exists to catch bugs" usually fails. Defect discovery is one of four purposes, and it is not even the most reliable one.

• Defect discovery: what a human reader catches is mainly the mismatch between intent and implementation. Missing null checks and formatting issues are caught far better by tooling. What people catch well is "this function does something other than what it says it does."
• Design pressure: the mere fact that someone will read it raises the author's baseline. Half the effect lands before the review is even opened.
• Knowledge spread: it widens who knows which parts of the codebase. It is the cheapest way to lower the bus factor, and over the long run it is worth more than defect discovery.
• Collective ownership and record: the reasoning behind "why is it done this way" is preserved in the review thread. Six months later that record gets read more often than the commit message.

Different purposes imply different processes. If defect discovery is the purpose, one person who knows the domain reading deeply is better; if knowledge spread is the purpose, having someone unfamiliar read along is better. Stacking both onto one review makes both mediocre. If the team never states which purpose it is buying, each reviewer applies a different bar, and the author experiences that inconsistency as "everyone says something different."

2. Documenting the Approval Standard

2-1. Without a standard, the reviewer's taste becomes the standard

Review breaks down hardest when the approval standard is implicit. If one reviewer demands perfection and another waves things through, the author experiences pass or fail as a function of reviewer assignment. That is a predictability problem before it is a fairness problem, and an unpredictable process gets routed around.

Google's reviewer standard page offers one sentence for exactly this: "In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect."

Two parts of that sentence carry the weight. The object of judgment is the direction of overall system code health, not the polish of the change, and you approve even when it is not perfect. If the bar is perfection, approval depends on reviewer patience; if the bar is direction, the judgment becomes reproducible.

2-2. What counts as grounds

The same page also fixes the order for resolving disagreement. Technical facts and data override opinions and personal preferences. On style, the style guide is the authority, and where the guide is silent, consistency with existing code decides rather than personal taste. Making that order explicit naturally reduces comments of the form "personally I would prefer."

2-3. The minimum to put in the team document

Approval standard (one page)

Approve         when the code health of the system clearly improves,
                even if the change is not perfect
Do not approve  correctness defects / security issues /
                hard-to-reverse interface decisions /
                no rollback path / behavior changed with no tests
Order of grounds  technical facts and data > style guide >
                  consistency with existing code > personal taste
Non-blocking      prefix with "Nit:" — the author may skip it

With this one page, most review arguments end by pointing at the document. Without it, every one is renegotiated from scratch.

3. Change Size Decides Almost Everything

3-1. Size sits upstream of every other metric

Of all the variables you can adjust in a review process, the one with the largest effect is not reviewer diligence — it is change size. As size grows, several things degrade at once.

• Delayed start: an 800-line change becomes the thing there is never time for. The item that sits longest in the queue is usually the largest one.
• Lower inspection density: there is a limit to how much context a person can hold at once. Past a certain size, reading speed holds but discovery rate drops. A large change that gets only "LGTM" is a symptom of exceeded capacity, not laziness.
• Exploding rework cost: being told the design direction is wrong after 800 lines are written means too much to undo. So reviewers swallow the objection, and review becomes ceremony.
• Conflicts and rebases: a big change stays open longer, staying open produces conflicts, and resolving conflicts makes it bigger again.

3-2. Concrete ways to shrink it

• Separate behavior change from structural change: mixing refactoring with a feature hides the real change from the reviewer. Send pure moves and renames as a separate change first.
• Separate interface from implementation: agreeing on the interface and the contract first makes the implementation review far faster, and it pulls hard-to-reverse decisions earlier.
• Land slices behind a flag: merging in an inactive state until completion keeps each slice small. The approach in Feature Flags and Progressive Delivery applies directly.
• Keep generated code and bulk moves separate: send generated output or a formatting sweep as its own non-review change, with the reproducing command in the commit message.

3-3. How to operate a size rule

Hard-coding an absolute line limit invites evasion. What works better is changing the procedure by size: past a threshold, require design agreement before the review request, or require a splitting plan in the description. Just making the author explain in one line why it got this big causes a sizeable share of changes to split themselves.

4. Latency — the One-Business-Day Rule and Its Rationale

4-1. The rule

Google's review speed page states the ceiling explicitly: "One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning)." It adds: "If you are not in the middle of a focused task, you should do a code review shortly after it comes in."

Note that this rule is about response time, not approval time. The same page explains that the latency of an individual response matters more than total elapsed time. A review can go several rounds and still feel fine if each round-trip is fast; if one round-trip takes three days, two rounds erase a week.

4-2. Why speed matters this much

The page gives two reasons. One is that "Most complaints about the code review process are actually resolved by making the process faster." The other is the knock-on effect: "Slow reviews also discourage code cleanups, refactorings, and further improvements to existing CLs."

The second matters more. When review is slow, only expensive changes survive. Cleanups and refactorings are never urgent, so they sit in the queue, and people who know they will sit never start them. Code health erodes quietly. Review latency is not a review quality problem, it is a mechanism for accruing technical debt. The economics of that accrual are covered in The Economics of Refactoring.

4-3. The conflict with focus time

The same page also says not to break your flow for a review while you are in focused work. Satisfying both requirements means treating review as scheduled work rather than an interrupt.

• Fix review slots, for example twice a day. Handling them at random breaks flow; having no slot pushes them to the end of the day.
• Make the pending queue visible at team level. Anything that lives only in a personal inbox quietly ages.
• Auto-escalate requests past a threshold to another reviewer. Being parked on one specific person is the most common cause of delay.
• If the team spans time zones, rewrite the ceiling in that team's terms. The one-business-day rule assumes overlapping working hours.

5. What Humans Review and What Gets Pushed to Automation

Human review budget is finite. If people are looking at what machines do better, there is no time left for what only people can see.

There is one principle: any remark repeated even once in review is a candidate for automation. If you have written the same comment three times, it is the job of a rule, not a person. If it cannot be automated, at least move it into a document so it is not renegotiated each time.

AI review tooling belongs in the same frame — it widens the left column. Still, it is safer to treat automated suggestions as comments, not approvals. If the responsibility for judgment does not remain with a person, you accumulate approvals nobody read.

6. Ownership and Approval Rules

6-1. Who is allowed to approve

Without ownership rules, two failures alternate. If anyone can approve, someone without domain knowledge waves things through; if only one person can approve, that person becomes the bottleneck and the team stops when they take leave.

The arrangement that works in practice is a per-path owner list kept in the repository, with every owner group holding at least three people. If a path still has a single owner, that is a bus factor problem, not a review rule problem.

6-2. Contested: how many approvals are required

Teams genuinely differ here.

• The single-approval side: the marginal value of a second approval is low. Requiring two means two calendars have to align, which increases latency, and diffused responsibility means each reviewer reads less carefully.
• The two-approval side: in areas where the cost of a mistake is asymmetric — payments, permissions — the second pair of eyes earns its keep. Some organizations are required to have it by regulation.
• The real axes: reversal cost, regulatory requirements, team size and the distribution of domain knowledge, and how much latency headroom you currently have.

The common compromise is differentiation by path: one approval for most paths, two only for high-risk paths such as authentication, payments and migrations. Encoding the rule in the repository reduces case-by-case negotiation.

6-3. Contested: should review block merge at all

There is a more fundamental argument. Among teams doing trunk-based development or pair programming, some hold that review should not block merge. If it was written in a pair, two people have already read it, and post-merge review keeps batch size down and integration frequency up.

• The blocking side: post-merge review is in practice the path by which review disappears. Reversal is expensive, and when an objection does arrive, the follow-up work loses to other priorities.
• The non-blocking side: blocking merge creates a queue, and a queue grows batches. Safety is better bought with tests, flags, canaries and fast rollback than with a merge gate.
• The real axes: how cheap rollback is, how high the pairing rate is, whether regulation requires an approval record, and how evenly experience is distributed across the team.

A team with minute-scale rollback and a canary cannot have the same answer as a team that ships monthly and cannot easily revert. Whichever you choose, write down the premises the choice rests on.

7. Comment Severity — What Blocks and What Does Not

7-1. Without levels, every comment reads as blocking

The most draining situation for an author is not knowing which comments must be addressed. When ten comments carry equal apparent weight, the author either applies all of them or ignores all of them.

Google's document offers a simple convention here: prefix non-mandatory polish with "Nit: " so the author can skip it. Extending that slightly into explicit levels visibly reduces round-trips.

Blocking:  will not approve unless addressed
           (correctness, security, hard-to-reverse decisions)
Nit:       polish suggestion, the author may skip it
Question:  a question for understanding, an answer is enough
FYI:       information unrelated to this change
Later:     follow-up to file separately, not handled here

Introducing five prefixes costs almost nothing and pays off immediately. In particular, having a Later level reduces the "while we're in here" inflation of change size.

7-2. Contested: is approving with comments healthy

This one splits teams too.

• The healthy side: making someone wait another day over minor remarks is waste. Trust the author and hand the application over, and the round-trip disappears.
• The unhealthy side: in practice a substantial share never gets applied. After approval there is nobody left to check, so comments survive only as a record.
• The real axes: the team's actual follow-through rate, whether a comment severity scheme exists, and whether the change is easy to reverse.

With a severity scheme and a high follow-through rate, approve-with-comments works well; with neither a scheme nor anyone checking whether comments were applied, it is effectively unconditional approval. Measure the follow-through rate before adopting the practice.

8. Escalation When Agreement Fails

This is the part most often missing from a review process. Most teams write rules only for the case where agreement happens.

Google's document states the principle briefly: "Don't let a CL sit around because the author and the reviewer can't come to an agreement." The deadlock itself is the cost.

Translated into a working procedure:

Step 1  If two round-trips do not resolve it, stop commenting asynchronously
        (an argument that goes three rounds in text almost never converges)

Step 2  Move to a 15-minute call or a face-to-face,
        then summarize the conclusion back into the review thread
        (change the channel, but keep the record in the review)

Step 3  If it still stands, state the grounds explicitly
        technical facts and data > style guide > consistency with existing code

Step 4  If a decider is needed, a pre-assigned role decides
        (write the order in the document: area owner → tech lead)

Step 5  Feed the decision back into the document
        if the same argument happened twice, the guide is missing

Steps 3 and 5 are the core. With the order of grounds fixed in advance, the argument does not degenerate into a contest of taste; feeding conclusions back into documentation stops the same argument recurring. Without step 5, a team relitigates the same question every quarter. How to make an argument persuasive in writing is covered in Persuasive Writing for Engineers.

9. Metrics for the Review Process, and How They Get Misused

9-1. Metrics worth watching

• Time to first response: it maps directly onto the one-business-day rule. Watch the upper percentile, not the mean. A four-hour average with a three-day p90 means those three days dominate how the team feels.
• Change size distribution: watch the median and the upper percentile together. A long upper tail calls for the measures in section 3.
• Round-trip count: a rising number of changes going past three rounds signals an unclear approval standard or missing comment levels.
• Queue age: the count of items open a long time. When it rises, look at batching rules rather than individuals.
• Change lead time and change fail rate: DORA defines change lead time as "The amount of time it takes for a change to go from committed to version control to deployed in production" and change fail rate as "The ratio of deployments that require immediate intervention following a deployment." How those two move after a process change is the final verdict.

DORA states that speed and stability are not a trade-off: "DORA's research has repeatedly demonstrated that speed and stability are not tradeoffs." If you made review faster and the change fail rate rose, that is not an inevitable compromise — something else is wrong.

9-2. They break the moment they become individual metrics

Review metrics distort completely once attached to individual performance.

• Comments written produces meaningless comments.
• Approval speed produces approval without reading.
• Changes reviewed produces cherry-picking small ones.
• Objections per author makes review defensive and drives out candid feedback.

So attach metrics to the process, not to people. A bad first-response time is a problem of assignment rules and slot design, not of one person's laziness. A long tail in change size calls for a splitting procedure, not a word with the author.

One more thing matters: do not use defect counts as a proxy for review effectiveness. As section 1 showed, defect discovery is one of four purposes, and knowledge spread and design pressure never appear in that number. Fewer objections might mean review has gone toothless, or it might mean the upstream got better. The number alone cannot tell you which.

Quiz: Check Your Understanding

Closing

Most attempts to improve code review start with tone and end with tone. Tone matters, but the same person writing the same sentence produces a failed review when the change is 800 lines and the response arrives three days later. Review is a queued process before it is a conversation.

Seen as a process, the places to act are clear. Write the approval standard on one page so judgment becomes reproducible. Shrink change size to fix the upstream. Put a ceiling on first-response time. Take off human hands what machines do better. Attach severity levels to comments so it is obvious what blocks. Give deadlock a pre-agreed exit.

And attach metrics to the process, not to people. Review is usually slow not because someone is lazy but because the arrangement makes it so. Fixing the arrangement always beats hurrying the people.

References

• The Standard of Code Review — Google Engineering Practices — quoted for the standard of approving when code health definitely improves even if the change is not perfect, the precedence of technical facts and data over preference, the position of the style guide and consistency with existing code, the prefix convention for non-mandatory polish, and the instruction not to let a change sit because of disagreement. Checked 2026-08-15.
• Speed of Code Reviews — Google Engineering Practices — quoted for the one-business-day response ceiling, the recommendation to review promptly when not in focused work, the statement that most complaints are resolved by speed, the observation that slow reviews discourage cleanups and refactorings, and the point that individual response latency matters more than total elapsed time. Checked 2026-08-15.
• DORA — Four keys metrics — quoted for the definitions of change lead time and change fail rate, and the finding that speed and stability are not trade-offs. Checked 2026-08-15.
• The four purposes of review, the five comment severity levels, the five-step escalation procedure, and the human-versus-automation split table do not appear in the sources above — they are procedures assembled in this post.

Further reading

• Related post on this blog: The Conversational Craft of Code Review
• Related post on this blog: Reviews That Teach, Reviews That Wound
• Related post on this blog: Persuasive Writing for Engineers — How Design Docs and RFCs Get Approved
• Related post on this blog: The Economics of Refactoring: When It Pays
• Related tool: Collab RPG

Complete Guide Series

• Previous: The Complete Guide to Test Strategy: Decision Criteria Instead of the Pyramid Debate
• Next: The Complete Guide to Deployment Strategies: What You Can Undo and What You Cannot