들어가며

글로벌 팀에서 일하거나 오픈소스에 기여할 때, **코드 리뷰 영어**는 필수 스킬입니다. 하지만 많은 한국 개발자가 "이걸 영어로 어떻게 말하지?"라는 고민에 빠집니다.

이 글에서는 상황별 코드 리뷰 영어 표현을 정리하고, 실제 PR 리뷰에서 바로 복사해서 쓸 수 있는 템플릿을 제공합니다.

1. 변경 요청 (Requesting Changes)

직접적 요청

명확한 변경 요청

- "Please rename this variable to something more descriptive."

- "This should be extracted into a separate function."

- "We need to add error handling here."

- "Please add a comment explaining why this is necessary."

- "This constant should be defined at the module level."

부드러운 요청 (더 선호됨)

"I wonder..." 패턴 — 부드럽게 제안

- "I wonder if we could simplify this by using a list comprehension."

- "I wonder if this would be clearer as a named function."

"What do you think about..." 패턴

- "What do you think about extracting this into a helper function?"

- "What do you think about using a dataclass here instead?"

"Consider..." 패턴

- "Consider using `defaultdict` here to avoid the key check."

- "Consider adding a timeout to this HTTP call."

"It might be worth..." 패턴

- "It might be worth adding a docstring to this class."

- "It might be worth caching this result since it's called frequently."

Nit (사소한 지적)

사소한 것은 "nit:" 접두사로 표시 (non-blocking)

- "nit: trailing whitespace on line 42"

- "nit: this could be a one-liner: `return x if x > 0 else 0`"

- "nit: inconsistent naming — other functions use snake_case"

- "nit: missing newline at end of file"

2. 질문하기 (Asking Questions)

의도/이유 묻기

왜 이렇게 했는지 물을 때

- "Could you explain why we need this check here?"

- "What's the reasoning behind using a raw SQL query instead of the ORM?"

- "Is there a specific reason for choosing `threading` over `asyncio`?"

- "I'm curious — why did you go with this approach?"

동작 확인

코드가 어떻게 동작하는지 확인할 때

- "What happens if `user` is None here?"

- "How does this behave when the list is empty?"

- "Does this handle the case where the API returns a 429?"

- "Will this work correctly with concurrent requests?"

테스트/엣지 케이스

테스트 관련 질문

- "Do we have test coverage for the error path?"

- "Have you considered adding a test for the edge case where input is empty?"

- "How was this tested? I couldn't find a corresponding test file."

- "Could you add a regression test for this fix?"

3. 칭찬하기 (Giving Praise)

구체적으로 칭찬하기 (구체적일수록 좋음)

- "Nice refactoring! This is much more readable now."

- "Great use of the Strategy pattern here."

- "Love the comprehensive error handling."

- "This is a really elegant solution. Well done!"

- "Excellent test coverage — especially the edge cases."

- "Good catch on that race condition!"

- "TIL about this API — thanks for introducing it!"

- "This abstraction is going to save us a lot of time."

4. 제안하기 (Making Suggestions)

대안 제시

코드와 함께 대안을 제시하는 예시

기존 코드:

for item in items:

if item.status == 'active':

result.append(item.name)

리뷰 코멘트:

"We could simplify this with a list comprehension:

`result = [item.name for item in items if item.status == 'active']`"

대안 제시 표현들

- "An alternative approach would be to use..."

- "You might want to look into using X instead."

- "One option is to..., which would give us..."

- "Have you considered using X? It handles Y automatically."

- "A simpler way to achieve this would be..."

성능/안전성 관련

성능 이슈 지적

- "This creates a new list on every iteration. Consider moving it outside the loop."

- "This O(n²) approach might be slow for large datasets. A set-based lookup would be O(n)."

- "We should use `str.join()` instead of string concatenation in a loop."

안전성 이슈 지적

- "This looks like it could be vulnerable to SQL injection."

- "We should validate the input before passing it to the shell command."

- "This secret should not be hardcoded — let's use environment variables."

5. 승인하기 (Approving)

LGTM (Looks Good To Me) 변형들

- "LGTM! 🚀"

- "LGTM — just one minor nit, but nothing blocking."

- "Looks good to me! Nice work."

- "Approved! Clean implementation."

- "LGTM with the suggested change. Feel free to merge after."

- "Ship it! 🛳️"

조건부 승인

- "LGTM once the test is added."

- "Approved with minor suggestions — up to you whether to address them."

- "Looks good overall. Just the one blocking comment about error handling."

6. 유용한 약어와 관용표현

코드 리뷰에서 자주 쓰이는 약어

LGTM = Looks Good To Me (승인)

PTAL = Please Take A Look (리뷰 요청)

WIP = Work In Progress (작업 중)

RFC = Request For Comments (의견 요청)

TIL = Today I Learned (오늘 배운 것)

IIRC = If I Remember/Recall Correctly (기억이 맞다면)

AFAIK = As Far As I Know (내가 알기로는)

IMO = In My Opinion (내 의견으로는)

IMHO = In My Humble Opinion (겸손한 의견으로는)

FYI = For Your Information (참고로)

WDYT = What Do You Think? (어떻게 생각해?)

ACK = Acknowledged (확인함)

NACK = Negative Acknowledgment (반대)

7. PR 설명 작성하기

PR Title 패턴

Conventional Commits 스타일

feat: add user authentication via OAuth2

fix: resolve race condition in cache invalidation

refactor: extract payment logic into separate service

docs: update API documentation for v2 endpoints

perf: optimize database queries for user dashboard

test: add integration tests for payment flow

chore: upgrade dependencies to latest versions

PR Description 템플릿

What

Brief description of what this PR does.

Why

Explain the motivation. Link to issue/ticket if applicable.

How

Describe the approach taken and any important design decisions.

Testing

- [ ] Unit tests added/updated

- [ ] Integration tests pass

- [ ] Manual testing done (describe what was tested)

Screenshots (if applicable)

Before / After screenshots for UI changes.

Notes for Reviewers

Any specific areas where you'd like focused feedback.

8. 어려운 상황 대처하기

의견 충돌 시

정중하게 반대 의견 표현

- "I see your point, but I think X might be more appropriate here because..."

- "I respectfully disagree — here's my reasoning: ..."

- "That's a valid approach, but I have concerns about..."

- "I understand the trade-off. Let me explain why I went this route..."

이해가 안 될 때

솔직하게 모른다고 할 때

- "I'm not familiar with this pattern — could you point me to a reference?"

- "I'm not sure I understand this part. Could you walk me through it?"

- "This is a bit over my head. Can you add a comment explaining the logic?"

리뷰가 오래 걸릴 때

리뷰 지연에 대해

- "Sorry for the delayed review — I'll take a look today."

- "Apologies, this slipped through my notifications. Reviewing now."

- "I need a bit more time to review this thoroughly. ETA: tomorrow morning."

실전 연습: 리뷰 시나리오

시나리오 1: 에러 처리 미흡

리뷰 대상 코드:

def get_user(user_id):

response = requests.get(f"https://api.example.com/users/{user_id}")

return response.json()["data"]

좋은 리뷰 코멘트:

"What happens if the API returns a non-200 status code?

We should add error handling here. Something like:

response.raise_for_status() # Raises HTTPError for 4xx/5xx

Also, `response.json()["data"]` will raise a KeyError

if the response doesn't contain a "data" field.

Consider using `.get("data")` with a sensible default."

시나리오 2: 성능 이슈

리뷰 대상 코드:

def find_duplicates(items):

duplicates = []

for i in range(len(items)):

for j in range(i + 1, len(items)):

if items[i] == items[j] and items[i] not in duplicates:

duplicates.append(items[i])

return duplicates

좋은 리뷰 코멘트:

"This has O(n²) time complexity, which could be a problem

for large lists. Here's a more efficient approach using

Counter from collections:

from collections import Counter

def find_duplicates(items):

return [item for item, count in Counter(items).items() if count > 1]

This runs in O(n) time. WDYT?"

마무리

코드 리뷰는 코드 품질뿐 아니라 **팀 커뮤니케이션**의 핵심입니다. 핵심 원칙:

1. **부드럽게 제안**: "Consider..." / "What do you think about..." / "I wonder if..."

2. **구체적으로 피드백**: 코드 예시와 이유를 함께 제시

3. **사소한 건 nit로 표시**: Blocking vs non-blocking 구분

4. **칭찬도 구체적으로**: "Nice!" 보다 "Great use of the Strategy pattern"

5. **약어 활용**: LGTM, PTAL, nit 등으로 효율적 소통

**Q1. LGTM의 의미는?**

Looks Good To Me (승인)

**Q2. "nit:" 접두사의 의미는?**

사소한 지적으로, 수정하지 않아도 머지를 막지 않는(non-blocking) 코멘트

**Q3. "What do you think about..." 패턴을 사용하는 이유는?**

직접적인 명령보다 부드럽게 제안하여 건설적인 대화를 유도하기 위해

**Q4. PTAL의 의미는?**

Please Take A Look (리뷰 요청)

**Q5. PR Title에 "feat:", "fix:" 접두사를 붙이는 컨벤션 이름은?**

Conventional Commits

**Q6. "I respectfully disagree"는 어떤 상황에서 사용하나?**

리뷰어의 의견에 정중하게 반대할 때

**Q7. SQL injection 취약점을 발견했을 때 적절한 영어 표현은?**

"This looks like it could be vulnerable to SQL injection."

**Q8. WDYT의 의미는?**

What Do You Think? (어떻게 생각해?)