반영 요청(PR)
외주가 PR 올렸다고 할 때의 그것이에요. 따로 판 갈래에서 한 작업을 손님이 쓰는 본판에 합쳐 달라고 올리는 요청서예요. 검토 없이 실서비스로 못 들어가게 막는 문턱이에요.
쉽게 말하면
진열대를 바꾸기 전에 올리는 확인서 한 장이에요. 직원이 새 진열을 창고에서 미리 짜 두고, 매장으로 옮기기 전에 사진을 붙인 종이를 내밀어요. "이렇게 바꿔도 될까요. 손대는 건 이 세 칸이에요." 사장님이 보고 좋다고 하면 그때 매장 진열이 바뀌어요. 확인서가 없는 가게는 아침에 문을 열었을 때 진열이 이미 바뀌어 있고, 무엇이 바뀌었는지 물어볼 종이조차 없어요.
개발에서 그 확인서를 반영 요청이라고 불러요. 영어로 pull request, 줄여서 PR이에요. 따로 판 갈래에서 해 둔 작업을 손님이 쓰는 본판에 합쳐 달라고 올리는 요청이에요.
요청이라는 말이 핵심이에요. 올렸다고 들어간 게 아니에요. 누군가 읽고 합치기 버튼을 눌러야 그때 본판이 바뀌어요.
빠르긴 해요. 대신 다음 주에 화면이 이상해졌을 때 언제 무엇이 들어갔는지 되짚을 자리가 없어요.
하루가 더 걸릴 수 있어요. 대신 사고가 났을 때 "이 요청부터 이상하다"고 한 건을 짚을 수 있어요.
요청서 한 장에 무엇이 적혀 있나
코드를 못 읽어도 요청서의 절반은 읽을 수 있어요. 코드가 아닌 칸이 절반이거든요. 사장님이 볼 자리만 추리면 여섯 칸이에요.
| 요청서의 칸 | 무엇이 적혀 있나 | 사장님이 여기서 보는 것 |
|---|---|---|
| 제목 | 이 요청이 무엇을 하는지 한 줄 | 한 줄로 안 적히면 한 요청에 여러 일이 섞여 있다는 신호예요 |
| 설명 | 왜 이렇게 고쳤는지, 무엇을 확인했는지 적는 자리 | 비어 있으면 그것부터 채워 달라고 하세요. 승인은 그다음이에요 |
| 바뀐 내용 | 어느 파일의 어느 줄이 어떻게 바뀌었는지 좌우 비교 | 줄 수와 파일 수. 한 줄 고친다더니 파일 스무 개면 물어야 해요 |
| 자동 점검 결과 | 미리 짜 둔 시험이 통과했는지 실패했는지 | 빨간 표시가 남아 있는 요청은 아직 합칠 때가 아니에요 |
| 의견 | 줄마다 달 수 있는 질문과 답 | 사장님도 여기에 한국어로 질문을 남길 수 있어요. 코드 얘기가 아니어도 돼요 |
| 합칠 곳 | 이 갈래를 어느 판에 넣을 것인지 | 본판인지 연습용 판인지. 여기가 본판이면 손님 화면과 이어져요 |
요청은 작을수록 좋아요
요청 하나에 열 가지가 들어 있으면 아무도 제대로 못 봐요. 그러면 승인은 요식 행위가 되고, 문턱을 세운 값이 사라져요. 한 요청에 한 가지 일이 원칙이에요. "작게 여러 번 올려 주세요"는 사장님이 해도 되는 요구예요.
사장님이 실제로 하는 일
코드를 읽어 승인하라는 뜻이 아니에요. 사장님이 확인할 수 있는 것은 따로 있어요. 화면과 말이에요. 여섯 걸음이면 끝나요.
- 1제목 한 줄을 읽어요. 이 요청이 무슨 일을 하는지 한 문장으로 이해되면 통과예요. 안 되면 그 자리에서 되물어요.
- 2바뀐 파일 수와 줄 수를 봐요. 숫자만 봐도 돼요. 요청 제목과 규모가 안 맞으면 무엇이 더 들어갔는지 물어요.
- 3자동 점검이 다 통과했는지 봐요. 빨간 표시가 있으면 사람이 볼 차례가 아직 아니에요.
- 4눌러 볼 주소가 있는지 물어요. 배포 방식에 따라 요청마다 임시 주소를 만들어 주는 곳이 있어요. 있으면 사장님이 직접 눌러 보는 게 가장 확실해요.
- 5바뀌면 안 되는 것을 확인해요. 결제·로그인·손님 정보처럼 건드리면 안 되는 자리를 말로 짚어요. "이 요청이 결제 화면을 건드리나요" 한 줄이면 돼요.
- 6승인 또는 질문을 남겨요. 승인은 "합쳐도 좋다"는 뜻이에요. 확신이 없으면 승인 대신 질문을 남겨요. 미루는 건 실수가 아니에요.
듣게 되는 말들
이 자리에서 오가는 말은 여섯 개면 충분해요. 오른쪽 칸은 그 말을 들었을 때 그대로 되물을 한마디예요.
| 듣게 되는 말 | 실제로 무슨 뜻인가 | 그 자리에서 되물을 한마디 |
|---|---|---|
| PR 올렸어요 | 요청서를 만들어 뒀다는 뜻이에요. 아직 본판은 그대로예요 | "제가 눌러 볼 주소가 있나요" |
| 리뷰 부탁드려요 | 읽고 의견이나 승인을 달라는 요청이에요 | "제가 봐야 할 화면은 어디인가요" |
| 머지했어요 | 요청을 본판에 합쳤다는 뜻이에요 | "손님 화면에도 이미 반영됐나요" |
| 충돌 났어요 | 같은 자리를 둘이 고쳐서 자동으로 못 합치는 상태예요 | "어느 쪽 내용을 살릴지 제가 정할 게 있나요" |
| 드래프트로 올렸어요 | 아직 작업 중이라 검토 전이라는 표시예요 | "언제쯤 봐 드리면 되나요" |
| 리베이스했어요 | 본판의 최신 내용을 먼저 얹어 요청을 정리했다는 뜻이에요 | "정리 후에도 점검이 다 통과했나요" |
확인해 보세요
외주 개발자가 "PR 머지했습니다"라고 알려 왔어요. 손님 화면을 확인했는데 그대로예요. 가장 먼저 물을 말은?
실제로 겪는 장면
장면 1 · 외주 개발자가 메시지를 보냈다
“PR 올려 뒀습니다. 확인하시고 승인해 주세요.”
코드를 읽으라는 뜻이 아니에요. 여기서 할 일은 두 가지예요. 눌러 볼 주소가 있는지 묻고, 이 요청이 건드리는 화면 목록을 말로 받는 것이에요. 코드를 못 읽어도 화면은 사장님이 제일 잘 알아요. 승인은 "코드가 맞다"가 아니라 "내 가게에 이렇게 들어가도 좋다"는 뜻으로 누르면 돼요.
장면 2 · 개발자가 승인 없이 합친 다음에 말했다
“급해서 먼저 반영했습니다. 요청은 형식적으로 올려 뒀어요.”
급한 수정은 있을 수 있어요. 문제는 그게 기본값이 되는 것이에요. 여기서 정할 건 하나예요. 급하게 먼저 넣어도 되는 경우를 미리 정해 두는 거예요. 보통은 손님이 지금 못 쓰는 급한 수정만이에요. 그 밖에는 승인 뒤에 합치기로 한 줄 합의해 두세요. 규칙은 사고가 나기 전에 정할 때만 값이 있어요.
두 장면 모두 사장님이 코드를 볼 필요가 없어요. 누가 언제 무엇을 넣기로 했는지만 정해져 있으면 돼요. 요청서는 그 합의를 종이로 남기는 도구예요.
언제부터 필요한가
여기가 이 문서에서 가장 정직해야 하는 자리예요. 혼자 만드는 동안에는 이 문턱이 그냥 번거로움이에요. 상황별로 갈라 보면 답이 분명해져요.
| 내 상황 | 반영 요청이 필요한가 | 왜 |
|---|---|---|
| 스튜디오에서 혼자 채팅으로 만들고 있어요 | 아직 필요 없어요 | 고치다 망쳤을 때는 되돌리기가 그 자리를 맡아요 |
| 코드를 내려받아 깃허브에 올려 뒀어요 | 혼자면 아직은 선택이에요 | 요청을 안 써도 기록은 남아요. 다만 습관을 지금 들여 두면 사람이 늘 때 안 흔들려요 |
| 외주나 프리랜서가 코드를 고치기 시작했어요 | 여기서부터 필요해요 | 남이 내 서비스에 넣는 것을 사장님이 보는 유일한 자리예요 |
| 손님이 실제로 쓰고 결제가 돌아요 | 본판을 잠그고 요청만 통하게 하세요 | 실수 한 번의 값이 매출이에요. 문턱 하나가 가장 싼 보험이에요 |
| 고치는 사람이 두 명 이상이에요 | 필요해요 | 같은 자리를 동시에 고치면 충돌이 나요. 요청 단위로 나눠야 순서가 생겨요 |
본판을 잠그는 설정이 따로 있어요
코드 보관 서비스에는 본판에 직접 못 넣게 막고 요청을 거치게 하는 설정이 있어요. 승인이 한 명 이상 있어야 합치기 버튼이 열리게 할 수도 있어요. 사람에게 지키자고 부탁하는 것보다 설정으로 막는 게 훨씬 확실해요. 개발자에게 "본판 직접 반영을 막아 주세요" 한 줄만 요청하면 돼요.
자주 묻는 것
- Q. 코드를 하나도 못 읽는데 승인해도 되나요?
- 돼요. 사장님의 승인은 "코드가 정확하다"는 보증이 아니라 "이 변경이 내 가게에 들어가도 좋다"는 결정이에요. 코드 자체를 봐 줄 사람이 필요하면 그건 다른 개발자의 몫이에요. 사장님은 화면·문구·건드리면 안 되는 자리를 보면 돼요.
- Q. 합친 다음에 문제가 생기면 되돌릴 수 있나요?
- 돼요. 합친 것을 되돌리는 기능이 따로 있어요. 다만 그 뒤에 다른 작업이 여러 건 더 들어갔으면 되돌리기가 복잡해져요. 그래서 사고가 의심되면 빨리 말하는 게 중요해요. 손님 화면 기준으로 급할 때는 이전 버전으로 돌리기가 더 빠른 경우도 있어요.
- Q. 요청을 열어 두면 손님 화면에 영향이 있나요?
- 없어요. 요청은 갈래에 있는 작업을 본판에 넣어 달라는 종이일 뿐이에요. 합치기 전까지 본판은 그대로예요. 다만 요청마다 임시 주소를 만들어 주는 배포 설정을 쓰고 있다면, 그 주소는 검색에 노출되지 않게 해 달라고 부탁해 두세요.
- Q. 승인을 미루면 개발자가 곤란해지지 않나요?
- 요청이 오래 열려 있으면 그동안 본판이 앞서 나가서 충돌이 늘어요. 그래서 미루기보다 작게 나눠 달라고 요구하는 쪽이 서로 편해요. 하루 안에 볼 수 있는 크기로 올려 달라고 기준을 정해 두세요.
- Q. 저는 요청을 안 쓰는데 개발자만 쓰면 안 되나요?
- 그렇게 해도 돼요. 사장님이 요청을 직접 만들 일은 거의 없어요. 사장님 자리는 받는 쪽이에요. 다만 알림이 어디로 오는지는 정해 두세요. 메일이 스팸함으로 가면 승인이 며칠씩 밀려요.
- Q. 연습용 판에서 먼저 확인하는 것과 뭐가 다른가요?
- 성격이 달라요. 요청은 사람이 보는 문턱이고, 연습 무대는 화면으로 확인하는 자리예요. 둘은 겹치지 않아요. 요청을 열어 두고 연습용 주소에서 눌러 본 다음 승인하는 순서가 가장 안전해요.
직접 해보기
지금은 되돌리기가 사장님의 문턱이에요
아직 혼자 만들고 있다면 반영 요청을 만들 자리가 없어요. 대신 같은 역할을 하는 것이 있어요. 스튜디오에서 만든 것을 고치기 전에, 지금 상태가 되돌릴 수 있는 지점으로 남아 있는지 확인해 두세요. 남이 코드를 고치기 시작하는 날 그 자리를 요청서가 이어받아요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
왜 이름이 당겨 오기 요청인가 · pull은 당겨 온다는 뜻이에요. 내가 본판에 밀어 넣는 게 아니라, 본판을 관리하는 쪽에 "내 갈래를 당겨 가 주세요"라고 청하는 구조라 이런 이름이 붙었어요. 이름 자체가 권한이 요청하는 쪽에 없다는 걸 말해 줘요. 서비스에 따라 같은 것을 merge request라고 부르기도 해요. 이름만 다르고 하는 일은 같아요.
승인 한 명이 왜 그렇게 큰 차이를 내나 · 고친 사람은 자기 실수를 잘 못 봐요. 머릿속에 의도가 있어서 화면을 읽는 게 아니라 기억을 재생하거든요. 다른 눈이 한 번 지나가면 그 재생이 끊겨요. 그래서 오래된 관행이 "승인 한 명"이에요. 두 명 세 명으로 늘리면 좋아지기보다 서로 미루는 일이 생겨요. 작은 팀에서는 한 명이 가장 잘 돌아가요.
자동 점검을 붙여 두면 사람이 볼 것이 줄어요 · 요청마다 자동으로 도는 점검을 걸어 두면, 화면이 아예 안 열리는 수준의 사고는 사람 눈에 오기 전에 걸러져요. 사람은 그때부터 "맞게 만들었나"만 보면 돼요. 이 설정을 자동 배포 쪽에서 같이 잡는 경우가 많아요. 외주에게 맡길 때 "점검이 통과해야 합칠 수 있게 해 주세요"를 계약 시작할 때 말해 두면 나중에 추가 비용이 안 붙어요.
이것만 기억하세요
- ·반영 요청은 갈래에서 한 작업을 본판에 넣어 달라고 올리는 요청서예요. 올렸다고 들어간 게 아니에요
- ·사장님이 볼 자리는 코드가 아니라 제목·바뀐 규모·자동 점검·눌러 볼 주소예요
- ·합쳤다와 손님 화면에 나갔다는 다른 말이에요. 내 가게가 자동인지 수동인지 한 번 확인해 두세요
- ·남이 내 코드를 고치기 시작하는 날부터 필요해요. 본판 직접 반영을 막는 설정까지 같이 걸어요
- ·요청은 작게, 승인은 한 명, 급하게 먼저 넣어도 되는 경우는 미리 정해 둬요