Code Review에서의 영어

코드 리뷰에 특별한 영어가 필요한 이유

코드 리뷰는 단순한 기술 피드백이 아닙니다 — 팀 커뮤니케이션입니다. 부적절한 표현은:

• 거만하거나 비꼬는 것처럼 보일 수 있습니다
• 동료의 적극성을 해칠 수 있습니다
• 오해를 야기합니다 (특히 다문화 팀에서)
• “트집 잡기”로 보이지 진심으로 돕는 것처럼 보이지 않을 수 있습니다

좋은 소식은: 모두가 이해할 수 있는 표준 표현 세트가 있습니다.

팁

코드 리뷰의 영어에는 “규범”이 있습니다. 배우면 예의 바르고, 효율적이며, 전문적으로 피드백할 수 있습니다.

반드시 배워야 할 10가지 코드 리뷰 표현

1. Nit (사소한 문제)

“Nit”은 “nitpick”(트집 잡기)에서 왔지만, 코드 리뷰에서는 긍정적인 용어로 “작고 대세에 영향은 없지만 개선할 가치가 있는” 것을 의미합니다.

❌ "This variable name is bad"
✅ "Nit: could we rename this to `userCount`?"
✅ "Minor: I'd prefer `userCount` for clarity"

사용 시기:

• 네이밍, 포맷, 스타일 문제
• 리팩터링 제안 (필수는 아니지만 더 나은)
• 문서 보완

2. LGTM (Looks Good To Me)

약어, 리뷰를 마쳤고 병합에 동의한다는 표시입니다.

LGTM!

더 격식적으로:

LGTM. Great implementation.

참고

Slack과 GitHub에서 “LGTM”은 국제 팀에서 통용됩니다. 코드 리뷰에서 반드시 보게 됩니다.

3. Blocker (차단 문제)

심각한 문제로, 반드시 수정해야 병합 가능합니다.

Blocker: This will cause a race condition in `handleUserLogin`.
Here's why: ...

사용 시기:

• 보안 문제
• 성능 회귀
• 기능 결함
• 데이터 손실 위험

4. Nice catch (잘 발견했네)

누군가 버그, 성능 문제 또는 숨겨진 요구사항을 찾았을 때 맞다고 확인하는 표현입니다.

Nice catch! I didn't think about the edge case where `null` ...

또는:

Good eye! This would definitely break on large datasets.

5. Could you elaborate (자세히 설명해 줄 수 있나요)

왜 이렇게 작성했는지 모르겠거나 설계 결정을 이해하고 싶을 때.

Could you elaborate on why we're using `Map` instead of `Object`?

더 친근한 버전:

I'm curious about the choice to use `Map` here. Could you walk me through the reasoning?

6. Nitpick (더 강한 “사소한 문제”)

“nit”보다 더 직접적이며, 정말 세부사항이지만 개선할 가치가 있다는 의미입니다.

Nitpick: Could we add a blank line here for readability?

7. Looks good (이 부분은 동의)

부분적 동의에 사용합니다. 예를 들어 로직에는 동의하지만 다른 부분에 대해 질문하고 싶을 때.

This part looks good. One question about line 42: why are we...?

8. We should probably (제안)

완곡한 제안, 필수는 아니지만 권장합니다.

We should probably add error handling here for the case where the API call fails.

9. Have you considered (개방적 질문)

대안을 직접 “이렇게 해야 한다”고 말하지 않고 제안합니다. 작성자에게 생각할 여지를 줍니다.

Have you considered using `useCallback` to prevent unnecessary re-renders?

10. Ship it (이대로 배포합시다)

가장 캐주얼한 동의로, 리뷰를 마쳤고 문제가 없으며 배포 가능하다는 의미입니다.

Ship it!

코드 리뷰의 예의 공식

문제를 지적할 때

공식: Context → Issue → Suggestion

❌ "This code is inefficient"

✅ "In `processUserData`, iterating `O(n²)` might be slow with large datasets.
   Could we use a `Set` to get `O(n)` instead?"

다른 의견이 있을 때

설계 결정에 동의하지 않는 경우:

❌ "That's wrong"

✅ "I see your approach. One concern: `Math.random()` isn't cryptographically
   secure for auth tokens. Should we use `crypto.getRandomValues()`?"

동의하면서도 질문하기

“좋다”고만 말하지 마세요. 건설적인 질문을 하세요:

❌ LGTM

✅ LGTM! Curious: did you benchmark this against the regex approach we discussed?
   I'm wondering if it's noticeably faster for production scale.

Express 모드의 코드 리뷰 활용

한국어 생각 → 3단계 영어 옵션 → 가장 적절한 것 선택

시나리오 1: 버그 지적

“여기 레이스 컨디션이 있어, 여러 요청이 충돌할 거야”

DevGlish Express 모드 활성화:

Input: "여기 레이스 컨디션이 있어, 여러 요청이 충돌할 거야"

Basic (Direct):
  "There is a race condition here, multiple requests will conflict"

Intermediate (Natural):
  "Multiple concurrent requests could cause a race condition"

Native (Idiomatic):
  "Concurrent requests might race here. Consider using a lock or queue."
  Tip: 문제만 지적하지 말고 해결 방향을 직접 제시하세요

“Native”를 선택하거나 여러 수준을 융합:

✅ Blocker: Multiple concurrent requests could race here.
   Consider adding a lock or queue to serialize writes.

시나리오 2: 예의 바르게 이름 변경 제안

“이 변수명이 너무 길어, 짧게 바꿀 수 있어”

Input: "이 변수명이 너무 길어, 짧게 바꿀 수 있어"

Basic (Direct):
  "This variable name is too long"

Intermediate (Natural):
  "Could we use a shorter variable name?"

Native (Idiomatic):
  "Nit: `getCurrentUserAuthenticationStatusFlag` is a bit verbose.
   How about `isAuthenticated`?"
  Tip: "짧게 해"라고만 말하는 것보다 구체적 제안이 더 유용합니다

코드 리뷰의 리뷰어 관점

좋은 코드를 볼 때

Nice implementation! Love how you're using `reduce()` here to avoid
intermediate arrays. Makes the intent really clear.

창의적인 해결책을 볼 때

Clever! I like this approach better than the nested loops we had before.

배우고 싶을 때

I haven't seen this pattern before. Could you explain the benefits
of using `Proxy` here? Curious to learn.

확실하지 않을 때

I'm not sure about this. Could we discuss it sync? Happy to do a quick call.

흔한 코드 리뷰 실수

한국어 사용자에게 흔한 간섭

잘못된 표현	원인	더 나은 버전
”This code is not good”	너무 직접적, 거만해 보임	”Could we refactor this for clarity?"
"You must change this”	명령처럼 들림	”We should probably change this"
"This is wrong”	상처를 줌	”This might cause X in scenario Y"
"Please to fix this”	문법 오류	”Could you fix this?"
"The code of the function is bad"	"of” 과다 사용	”The function could be clearer”

팁

코드 리뷰에서 “Could/Should/Might”는 항상 “Must/Must not”보다 낫습니다.

코드 리뷰 표현 목록

대규모 코드 리뷰를 준비하시나요? 이 표현들을 단어장의 code-review 태그에 저장하세요:

Essential Phrases (15 entries)
  ├─ "Nit: "
  ├─ "LGTM"
  ├─ "Nice catch"
  ├─ "Blocker: "
  ├─ "Could you elaborate on..."
  ├─ "Have you considered..."
  ├─ "We should probably..."
  └─ [more...]

Questions & Suggestions (10 entries)
  ├─ "I'm not sure about X. Could we discuss?"
  ├─ "Did you benchmark this?"
  ├─ "Any edge cases we should handle?"
  └─ [more...]

Praise (5 entries)
  ├─ "Great implementation"
  ├─ "Love this pattern"
  └─ [more...]

리뷰를 작성하기 전에 이 목록을 한번 훑어보고, 어조가 전문적이면서도 친근한지 확인하세요.

빠른 참조표

상황	표현
동의 + 사소한 문제	LGTM, just one nit: …
설계 결정에 동의하지 않음	I see your approach, but have we considered…?
심각한 문제	Blocker: This will cause…
작은 제안	Nit: Could we…?
동의 + 배우고 싶음	Nice! Could you explain why you chose…?
확실하지 않음	I’m not sure about this. Could we discuss?
완전 동의	LGTM! Ship it.