내 코드 리뷰받고 고칠 순서 정하기

치명 2 · 중요 3 · 사소 1로 여섯 건이 심각도 순으로 나왔다. 관점을 "버그와 예외 처리"로 잡았는데도 SQL 문자열 결합이 치명 1번으로 올라왔고, 드라이버가 dict를 주는지는 "확인 필요"로 남았다.

관점을 보안으로 바꿔 한 번 더 돌리면 겹치지 않는 지적이 나온다.

혼자 만든 코드를 올리기 전에 봐 줄 사람이 없을 때 쓰는 코드 리뷰 프롬프트입니다. 그냥 "리뷰해 줘"라고 하면 변수 이름부터 들여쓰기까지 스무 개 넘는 지적이 평평하게 늘어서고, 무엇이 진짜 위험한지 구분되지 않아 결국 하나도 못 고친 채 창을 닫게 됩니다.

역할을 "고칠 곳을 먼저 짚는 시니어 개발자"로 못 박는 이유는, 지정하지 않으면 AI가 습관처럼 칭찬 세 줄로 시작하기 때문입니다. 맥락의 "팀 저장소에 올리기 전"은 기준선을 정합니다. 연습용 코드와 남이 읽을 코드는 봐야 할 것이 다릅니다.

과제에서 심각도를 세 단계로 강제한 것이 이 프롬프트의 핵심입니다. 등급이 없으면 SQL 인젝션과 빈 줄 하나가 같은 무게로 나옵니다. 형식의 네 칸 표와 "지금 바로 고칠 3가지"는 읽자마자 손이 움직이게 합니다. 코드 개선점 찾기는 목록을 받는 일이 아니라 순서를 정하는 일입니다.

제약의 "최대 8개"와 "스타일 지적 제외"는 분량을 눌러 둡니다. 마지막 문장은 답을 보여 주기 전에 스스로 점검하게 해서, 이 코드에서는 일어나지 않는 문제를 지어내 지적하는 일을 줄입니다. 코드를 """ 로 감싼 것은 주석에 적힌 문장이 지시로 읽히지 않게 하기 위해서입니다.

리뷰 관점을 변수로 뺀 것도 같은 이유입니다. 한 번에 보안·성능·가독성을 모두 보게 하면 어느 쪽도 깊이 들어가지 못합니다. 오늘 무엇이 걱정인지 하나만 골라 두 번 돌리는 편이 결과가 낫습니다. 회사 코드를 붙여 넣을 때는 사내 주소나 키 값이 남아 있지 않은지 먼저 확인하세요.

잘 짰다는 인사말과 함께 지적이 순서 없이 쏟아집니다. 네이밍 제안과 예외 처리 누락이 나란히 놓여 있어 어느 것이 배포를 막을 문제인지 알 수 없고, 어떤 언어·어떤 관점으로 보는지 정하지 않아 실제로 쓰지 않는 문법 규칙까지 붙습니다. 고친 코드도 함께 오지 않아 지적을 읽고 다시 방법을 찾아야 합니다.