결과 예시
다섯 소제목이 순서대로 나왔고, 이슈 번호와 배포 일정은 지어내지 않고 "작성자 확인 필요" 3건으로 빠졌다.
리뷰어가 특히 봐 줬으면 하는 곳
- 재시도 횟수를 세는 위치가 요청 단위인지 (src/payment/retry.ts)
- 2초 고정 간격이 적절한지 — 백오프를 쓰지 않은 선택입니다
- 실패 안내 문구의 표현과 위치 (src/payment/messages.ts)
"이번에 하지 않은 일"에는 백오프 도입과 실패 원인 조사가 들어갔다.
Claude에서 실제로 실행해 확인 · 2026-09
왜 이렇게 쓰는가
pr 설명 작성에서 대부분의 사람은 무엇을 바꿨는지만 적습니다. 그런데 파일 목록과 diff 는 이미 화면에 있습니다. 리뷰어가 정작 알 수 없는 것은 왜 이 방법을 골랐는가이고, 그것이 없으면 리뷰는 "이거 왜 이렇게 하셨어요?"라는 질문으로 시작해 하루가 갑니다.
역할을 "리뷰어의 시간을 아끼는 개발자"로 둔 이유는 분량을 정하기 위해서입니다. 지정하지 않으면 변경 파일마다 한 문단씩 붙은 긴 글이 나오는데, 그런 글은 아무도 끝까지 읽지 않습니다. 맥락의 "배경을 모르고 오늘 처음 본다"는 한 줄은 사내 용어와 생략을 걷어냅니다.
형식의 다섯 소제목이 이 프롬프트의 뼈대입니다. 특히 "리뷰어가 특히 봐 줬으면 하는 곳"과 "이번에 하지 않은 일"이 중요합니다. 앞의 것은 리뷰의 초점을 정해 주고, 뒤의 것은 "이건 왜 안 고쳤나요"라는 되돌이 질문을 미리 막습니다. 소제목마다 줄 수를 정해 둔 것도 같은 이유입니다.
지어내지 말라는 문장은 pull request 설명 chatgpt 로 만들 때 특히 필요합니다. 성능이 얼마나 좋아졌다거나 관련 이슈 번호처럼 그럴듯한 문장이 저절로 붙는데, 그대로 올리면 리뷰어가 사실로 믿습니다. 대신 "작성자 확인 필요" 자리를 만들어 두면 모르는 것을 지어내는 대신 그쪽으로 보냅니다.
확인 방법을 변수로 받아 앞쪽에 둔 것은 리뷰어가 실제로 받는 질문이 "이거 돌려 봤어요?"이기 때문입니다. 무엇을 어떻게 확인했는지 한 줄이 있으면 리뷰어가 같은 절차를 따라 하거나, 빠진 경우를 짚어 줄 수 있습니다.
용어가 낯설면 아하AI에서: role-prompting, context-window
나쁜 예와 비교
PR 설명 좀 써줘
(변경 파일 목록 붙여넣기)
파일 이름을 한 줄씩 풀어 쓴 목록이 나옵니다. 읽어도 diff 를 보는 것과 다를 게 없고, 배경이 없으니 리뷰어는 결국 채팅으로 물어봅니다. 어디를 집중해서 봐야 하는지도 없어 리뷰가 오탈자 지적에서 끝나거나, 승인 버튼만 눌리고 넘어가기도 합니다.
변형
급한 수정을 빨리 올려야 할 때
아래 메모로 짧은 풀 리퀘스트 본문을 써 주세요. 한 문장 요약, 왜 급한지 두 줄, 확인 방법, 되돌리는 방법 순서로만 적고 그 외에는 넣지 마세요. 확인 방법은 다음과 같습니다. {{테스트 방법}}
""" {{작업 내용}} """
장애 대응처럼 먼저 올리고 나중에 설명할 때 씁니다. "되돌리는 방법"을 넣는 것이 급한 배포에서는 가장 중요합니다.
리뷰어에게 질문이 있을 때
아래 작업 내용에서 제가 확신하지 못한 선택이 무엇인지 찾아, 리뷰어에게 물어볼 질문 3개로 바꿔 주세요. 질문마다 제가 고려한 선택지와 지금 고른 이유를 한 줄씩 붙여 주세요. 답을 대신 정해 주지는 마세요.
""" {{작업 내용}} """
설계가 애매한 채로 올릴 때 씁니다. 질문을 본문에 적어 두면 리뷰가 그 지점에서 시작됩니다.
관련 프롬프트
마지막 수정 2026-09-02 · 잘못된 점이 있나요? 알려 주세요