변경 내용으로 커밋 메시지 쓰기

차단 회원 관점·최소 포인트 기준 관점·기존 고객 영향 관점으로 3안이 나왔고, diff 에서 읽히지 않는 값은 [이유 확인 필요]로 남았다.

fix: 차단 회원에게 포인트 할인이 적용되던 문제 수정 포인트 잔액만 확인하고 회원 상태는 보지 않아, 차단된 회원도 포인트가 남아 있으면 할인을 받았습니다. 이제 차단 회원은 포인트와 무관하게 할인에서 제외됩니다. MIN_POINT 값을 정한 근거는 [이유 확인 필요]

한 안을 고른 뒤 "본문을 두 줄로 줄여 줘"라고 이어 요청하면 바로 쓸 수 있다.

커밋 메시지 프롬프트에서 규칙을 말로만 설명하면, 매번 조금씩 다른 형식이 돌아옵니다. 어제는 "fix: ~"였는데 오늘은 "[Fix] ~"가 나오고, 어떤 날은 제목만, 어떤 날은 목록 다섯 줄이 붙습니다. 저장소 기록은 형식이 흔들리는 순간 훑어보기 어려워집니다.

그래서 두 번째 문단에 규칙 설명과 함께 실제 메시지 예시 두 줄을 넣습니다. 사람도 그렇듯 AI도 "50자 이내, 명령형"이라는 설명보다 완성된 문장 하나를 훨씬 정확히 따라 합니다. 예시가 두 개인 이유는 하나만 주면 그 문장의 주제까지 흉내 내기 때문입니다.

과제에서 3개를 요구하되 "관점이 달라야 한다"고 못 박은 것은, 그냥 3개를 달라고 하면 어미만 바꾼 세 줄이 오기 때문입니다. 형식의 "왜 바꿨는지"는 본문의 존재 이유입니다. 무엇을 바꿨는지는 diff 를 보면 되고, 기록에 남겨야 할 것은 그 판단입니다.

첫 문단의 "몇 달 뒤 이 줄이 왜 바뀌었는지 찾는 사람이 읽는다"는 한 줄도 그냥 두지 마세요. 읽을 사람을 정하면 문장의 길이와 어휘가 함께 정해집니다. 이 한 줄이 없으면 오늘의 저에게만 통하는 축약어와 작업 번호가 제목에 들어갑니다.

제약의 "이슈 번호를 지어내지 마세요"는 실제로 자주 겪는 사고입니다. 커밋 메시지 자동 생성에 맡기면 있지도 않은 번호가 그럴듯하게 붙습니다. 변경 내용을 """ 로 감싸는 것은 diff 안의 주석이나 문자열이 지시로 읽히는 것을 막습니다.

"Update cart.js" 같은 한 줄이 나오거나, 반대로 바뀐 줄을 그대로 옮겨 적은 목록이 나옵니다. 팀 규칙을 모르니 접두어도 언어도 매번 달라지고, 왜 바꿨는지는 어디에도 남지 않아 몇 달 뒤 이 커밋을 열어 본 사람이 다시 코드를 읽어야 합니다.

diff 를 그대로 붙이면 기호가 많아 변경의 방향을 반대로 읽는 일이 있습니다. 맨 앞에 "이번 변경의 요지는 ~"라고 한 줄 적어 주면 정확도가 올라갑니다.