개발 수정 요청 쓰는 법 — 재현 순서까지

개발에 보내는 수정 요청은 다섯 줄이면 끝납니다 — 어디서 · 무엇으로 · 어떻게 하면 · 무엇이 나와야 하는데 · 무엇이 나왔다. 이 다섯 줄이 있으면 되묻는 왕복이 사라지고, 없으면 고치는 시간보다 물어보는 시간이 더 깁니다. 가운데 있는 것이 재현입니다 — 재현이란 같은 문제를 상대의 화면에서 다시 나오게 하는 일입니다.

왜 되묻는 일이 생기나요

요청을 보내는 쪽과 받는 쪽은 서로 다른 화면을 보고 있습니다. 화면 크기 · 계정 종류 · 저장된 자료가 다르면 같은 버튼을 눌러도 다른 결과가 나옵니다. 그래서 「안 됩니다」 한 줄로는 상대 화면에서 아무 일도 일어나지 않습니다.

이렇게 적으면	되물어야 하는 것	미리 적어 둘 것
로그인이 안 됩니다	어떤 계정으로, 어느 화면에서	계정 종류와 화면 이름
화면이 이상합니다	무엇이 어떻게 이상한가	본 것과 기대한 것 각 한 줄
가끔 그럽니다	언제, 몇 번 중 몇 번	일어난 시각과 횟수
급합니다	얼마나 급한가	멈춘 일과 그 규모

그대로 쓰는 다섯 줄 틀은 무엇인가요

한 건에 한 장입니다. 두 건을 한 장에 적으면 하나만 고쳐지고 하나는 잊힙니다.

1. 어디서 — OO 화면 → OO 메뉴 → OO 버튼
2. 무엇으로 — 컴퓨터인지 휴대폰인지, 브라우저 이름과 버전, 로그인한 계정 종류(관리자 · 일반)
3. 어떻게 하면 — 1) OO을 누른다 2) OO을 입력한다 3) OO을 누른다 (3~5단계로)
4. 나와야 하는 것 — OO 화면으로 넘어가야 합니다
5. 나온 것 — 화면이 그대로입니다. 9월 1일 14시 10분, 화면 사진 1장 첨부

세 번째 줄이 가장 중요합니다. 단계를 적다가 「여기서 뭘 눌렀더라」에서 막히면 그 자리가 원인일 확률이 높습니다. 다시 처음부터 해 보면서 적으면 열에 두세 건은 적는 중에 원인이 나옵니다.

첨부는 화면 사진 1장이 기본이고, 눌렀을 때만 생기는 문제라면 10~20초짜리 화면 녹화가 사진보다 낫습니다. 오류 문구가 떴다면 사진으로만 두지 말고 글자 그대로 옮겨 적습니다 — 글자로 있어야 코드에서 찾을 수 있습니다.

급한 정도는 어떻게 적나요

전부 급하다고 적으면 순서가 없어집니다. 세 등급으로 나누고 등급마다 쓰는 문장을 정해 둡니다.

등급	기준	그대로 쓰는 한 줄
멈춤	돈이 오가는 일이나 접속이 안 됩니다	[멈춤] 결제가 안 됩니다 — 오늘 OO건 영향
불편	돌아가는 방법은 있지만 손이 갑니다	[불편] OO을 매번 다시 넣어야 합니다 — 하루 OO회
개선	지금도 되지만 바꾸면 낫습니다	[개선] OO 버튼을 위로 — 급하지 않습니다

등급 뒤에 영향을 받는 수를 붙이는 것이 요령입니다. 「하루 30회」 「오늘 4건」처럼 숫자가 하나 있으면 받는 쪽이 순서를 스스로 정할 수 있어 「이거 먼저 해 주세요」를 다시 보낼 일이 없습니다.

등급은 제목 맨 앞에 대괄호로 답니다. 목록을 위에서 아래로 훑을 때 대괄호만 보고도 오늘 볼 것과 다음 주에 볼 것이 갈립니다. 돌아가는 방법을 이미 찾아 뒀다면 그것도 한 줄 적습니다 — 「지금은 목록에서 다시 검색해 쓰고 있습니다」. 급한 정도가 한 단계 내려가고, 고칠 때 그 방법 자체가 실마리가 됩니다.

좋은 예와 아쉬운 예는 어떻게 다른가요

아쉬운 문장	왜 아쉬운가	고쳐 쓴 문장
저장이 안 돼요	어디서 무엇을 저장했는지 없습니다	주문 상세 화면에서 메모를 넣고 저장을 누르면 화면이 그대로입니다
이 부분 좀 수정해 주세요	바뀐 뒤의 모습이 없습니다	목록 정렬을 최신순으로 바꿔 주십시오. 지금은 이름순입니다
어제는 됐는데 오늘 안 됩니다	어제와 오늘의 차이가 없습니다	8월 31일 17시에는 됐고 9월 1일 9시부터 같은 순서로 안 됩니다
다들 그렇다고 합니다	몇 명인지 모릅니다	같은 화면에서 3명이 같은 증상을 봤습니다. 계정은 전부 일반입니다

고쳐 쓴 쪽은 전부 화면 이름 · 누른 것 · 나온 것 셋이 한 문장에 들어 있습니다. 두 번째 줄처럼 새로 만들어 달라는 요청도 같습니다 — 지금 어떤 상태이고 어떤 상태가 되어야 하는지를 나란히 적으면 그 자체가 확인 기준이 됩니다.

고쳤다는 회신을 받으면 무엇을 하나요

요청은 보내는 것보다 닫는 것이 어렵습니다. 「고쳤습니다」를 받으면 보냈던 세 번째 줄을 그대로 다시 해 봅니다. 같은 화면 · 같은 기기 · 같은 계정으로 1) 2) 3) 을 순서대로 눌러 보고, 이번에는 네 번째 줄에 적었던 화면이 나오는지 확인합니다.

확인했으면 한 줄로 닫습니다 — 「9월 2일 10시에 같은 순서로 확인했고 정상입니다. 닫습니다.」 닫는 문장이 없으면 그 건은 목록에 계속 남아 다음 요청과 섞입니다. 같은 문제가 다시 나면 새 건으로 올리지 말고 「9월 2일에 닫았던 건이 9월 5일에 다시 났습니다」로 이어 적습니다 — 두 번 난 기록이 한자리에 있어야 원인을 찾기 쉽습니다.

수정 요청은 언제 모아 보내나요

생각날 때마다 보내면 순서가 뒤섞이고, 한 달치를 모으면 원인을 찾기 어려워집니다. 등급별로 시점을 정해 둡니다.

등급	보내는 시점	한 번에
멈춤	확인 즉시	1건
불편	주 1회 정해진 요일	5건 이내, 번호를 매겨서
개선	2주에 한 번	목록으로 모아 순서만

주 1회 묶음에는 번호를 매겨 보냅니다 — 1번부터 5번까지. 번호가 없으면 받는 쪽이 순서를 정하게 되고, 그 순서가 이쪽 생각과 다르면 다시 이야기해야 합니다. 프로그램 개발이 진행 중인 동안에는 새 문서를 매번 만들기보다 이 목록 하나를 계속 이어서 쓰는 편이 찾기 쉽습니다.

오늘 할 일

지금 열려 있는 수정 요청 중 하나를 골라 세 번째 줄(어떻게 하면)을 다시 적습니다. 실제로 그 순서대로 해 보면서 1) 2) 3) 으로 번호를 붙입니다. 10분이면 되고, 적는 중에 원인이 나오는 경우가 자주 있습니다.