한국어 코드 리뷰 — 동료가 검토한 듯한 톤

예시는 사용자 목록을 필터링하는 짧은 JS 함수를 붙여 넣었을 때의 리뷰 형태입니다.

1. 정확성

라인 7에서 users.filter 안의 비교가 느슨한 동등 연산자(==)라 문자열 "0"과 숫자 0이 같게 취급됩니다. 상태값이 문자열로 들어오는 API라면 비활성 사용자가 통과합니다. 일치 비교(===)로 바꾸고, 상태값 타입을 진입 지점에서 한 번 정규화하는 편이 안전합니다.

2. 성능

filter 결과를 다시 map으로 도는 구조라 배열을 두 번 순회합니다. 목록이 수만 건이 아니면 체감 차이는 없지만, reduce 한 번으로 합치면 의도가 더 분명해집니다.

3. 가독성

변수명 d, u, x가 한 함수 안에 섞여 있어 추적이 어렵습니다. user, isActive처럼 풀어 주면 주석 없이도 읽힙니다.

4. 테스트 제안

• 빈 배열을 넘겼을 때 빈 배열을 반환하는가
• 상태값이 null/undefined인 항목이 섞였을 때 터지지 않는가
• 상태값이 문자열 "0"으로 들어온 경우 비활성으로 걸러지는가

전반적으로 로직 흐름은 명확합니다. 위 동등 비교만 잡으면 바로 머지해도 될 수준입니다.

구조가 결과를 끌어올리는 지점

"당신은 한국어 시니어 개발자입니다"로 역할을 못 박은 뒤, 리뷰 형식을 정확성·성능·가독성·테스트 제안 네 칸으로 강제합니다. 모델이 자유롭게 떠드는 대신 항목별로 답을 채우게 만드는 구조라 누락이 줄어요. 특히 정확성 항목은 "어디(라인 N)·무엇·왜·어떻게 고치면 좋은지"를 한 문단에 담으라고 못박아서, "여기가 좀 위험해 보여요" 같은 막연한 코멘트 대신 라인 번호와 수정 방향까지 나옵니다. 예시에서 느슨한 동등 연산자(==)를 일치 비교(===)로 바꾸라고 라인 7을 콕 집은 게 이 지시 덕분이죠. 톤 규칙("결론적으로", "여러분" 금지, 칭찬은 한 줄)이 PR 코멘트 같은 건조한 말투를 만들어 실무에 바로 붙습니다.

이럴 땐 다른 방법을 쓰세요

이건 한 함수나 짧은 코드 블록의 품질 리뷰에 맞춘 프롬프트입니다. 대괄호 변수가 [코드 붙여넣기] 하나뿐이라, 에러 스택을 던지고 원인을 찾거나 아키텍처 전체를 설계 검토하는 용도로는 부족해요. 팁에도 나오듯 한 번에 1,000줄을 넣으면 핵심을 놓치니, 대규모 리팩터링 검토나 다중 파일 의존성 분석에는 안 맞습니다. 또 "테스트 제안"이 형식에 박혀 있어, 설정 파일이나 순수 데이터처럼 테스트가 무의미한 코드에는 억지 항목이 붙을 수 있어요.

변수를 바꿔 쓰는 법

• 긴 코드 자르기: 팁대로 [코드 붙여넣기] 위에 "이 함수만 우선 리뷰"를 덧붙여 범위를 좁히면 라인 지목이 더 정확해집니다.
• 신참 개발자 리뷰용: 후배 코드라면 "칭찬은 한 줄" 대신 "왜 그렇게 고쳐야 하는지 근거를 더 풀어서"로 톤 문장을 바꿔 학습용으로 씁니다.
• 성능 집중 모드: 병목이 의심될 땐 성능 항목을 "1~2개만"에서 풀고, 시간/공간 복잡도를 함수별로 명시하라고 바꾸면 최적화 단계에 맞습니다.

흔히 빠지는 함정

가장 잦은 실수는 라인 번호 없는 코드를 붙여 놓고 "라인 N"을 기대하는 겁니다. 모델이 임의로 줄을 세니, 리뷰받을 코드를 줄 단위로 보존해 붙여야 정확성 항목이 제값을 합니다. 칭찬 한 줄 규칙을 빼먹으면 무난한 총평으로 끝나 개선점이 묻히니 톤 문장을 통째로 유지하세요. Cursor나 ChatGPT 같은 다른 도구에 넣을 때도 형식 네 칸을 지우지 않는 게 핵심입니다. 끝으로 예시처럼 reduce로 합치라는 제안이 나와도 무조건 따르지 말고, 목록 규모가 작으면 "체감 차이 없음"이라는 단서를 함께 읽어 과잉 최적화를 피하세요.