브랜치(작업 갈래)
실서비스를 안 건드리고 고치는 기본 장치예요. 손님이 쓰는 판은 그대로 두고 이름표 붙인 갈래에서만 손을 대다가, 다 되면 그때 본판에 합쳐요.
쉽게 말하면
메뉴판을 새로 짜는 일이에요. 지금 손님이 보는 판에 바로 덧칠하지 않고, 같은 내용을 옮겨 적은 판을 한 벌 더 꺼내서 거기에만 손을 대요. 새 판에는 이름표를 붙여 둬요. "여름 메뉴"처럼요. 짜는 동안 손님은 원래 판을 그대로 봐요. 다 짜고 마음에 들면 그때 원래 판에 옮겨 적고, 마음에 안 들면 새 판만 버리면 돼요. 원래 판에는 처음부터 아무 일도 없었어요.
갈래를 하나 만든다는 건 지금 코드를 통째로 복사해 이름표를 붙이는 일이에요. 복사본이라 아무리 부숴도 손님이 쓰는 쪽은 멀쩡해요.
손님이 쓰는 쪽에 해당하는 갈래를 본판이라고 불러요. 개발자들은 보통 main 이라는 이름을 붙여 둬요.
화면 개편을 사흘째 하는 중에 결제 오류 신고가 들어오면, 반쯤 뜯어 놓은 상태 위에서 급한 수정을 해야 해요. 둘이 한 덩어리가 돼서 뭘 되돌려야 할지 모르게 돼요.
급한 수정만 먼저 본판에 합쳐서 내보낼 수 있어요. 사흘째 뜯고 있던 개편은 손도 안 대고 그대로 자기 갈래에 남아 있어요.
갈래에 붙는 이름들
갈래 이름은 사람이 정해요. 다만 업계에서 굳어진 이름이 몇 개 있어서, 화면에서 목록을 보면 대개 이 다섯 종류가 섞여 있어요.
| 목록에서 보이는 이름 | 무슨 갈래인가 | 사장님이 알아야 할 것 |
|---|---|---|
| main 또는 master | 본판이에요. 손님에게 나가는 것의 기준이 되는 갈래예요 | 여기에 들어간 것만 손님에게 갈 자격이 생겨요. 아무나 바로 못 넣게 막아 두는 게 보통이에요 |
| feature/예약-알림 | 기능 하나를 만드는 작업 갈래예요. 빗금 뒤가 그 작업의 이름이에요 | 이름만 봐도 무슨 작업인지 알 수 있어야 해요. 이름이 부실하면 목록이 곧 쓰레기가 돼요 |
| hotfix/결제-오류 | 지금 안 되는 것을 급히 고치는 갈래예요 | 이 이름이 보이면 급한 수정이 도는 중이라는 뜻이에요. 진행 상황을 물어봐도 되는 자리예요 |
| develop | 여러 작업을 일단 모아 두는 중간 갈래예요. 사람이 여럿일 때 씁니다 | 혼자이거나 둘이면 없어도 돼요. 갈래가 많다고 잘 굴러가는 건 아니에요 |
| 사람 이름이 붙은 갈래 | 각자가 자기 작업을 쌓아 두는 개인 갈래예요 | 석 달째 안 합쳐진 개인 갈래가 있으면 그건 잊힌 작업이에요. 물어볼 값이 있어요 |
이름표가 곧 작업 목록이에요
갈래 목록을 열면 지금 무슨 작업이 돌고 있는지가 한 화면에 나와요. 맡기고 있다면 이 화면이 진행 보고서 대신이에요. 이름이 "test2", "새폴더" 같은 것들로 채워져 있으면 보고서로 쓸 수 없다는 뜻이라, 이름 규칙 한 줄을 처음에 정해 두는 편이 싸요.
실제로 진행되는 순서
직접 하든 맡기든 순서는 같아요. 사장님이 명령어를 칠 일은 없지만, 지금 어느 걸음에 있는지는 물어볼 수 있어야 해요. 여섯 걸음이에요.
- 1본판이 멀쩡한 상태에서 갈래를 떠요. 갈래는 뜨는 그 순간의 본판을 복사해요. 부서진 상태에서 뜨면 그 부서짐까지 같이 복사돼요.
- 2이름을 붙여요. 무슨 작업인지 읽히는 이름이면 충분해요. 나중에 목록에서 이 이름 하나로 찾게 돼요.
- 3그 갈래에서만 고치고 [[commit|커밋]]을 쌓아요. 이 동안 본판은 한 글자도 안 바뀌어요. 손님 화면도 그대로예요.
- 4다 됐으면 본판의 최신 내용을 갈래로 먼저 가져와요. 작업하는 사이에 본판이 앞서 나갔을 수 있어요. 여기서 부딪힘이 나면 지금 푸는 게 훨씬 싸요.
- 5합칠지 남이 한 번 보게 해요. 혼자면 자기 눈으로 한 번 더 보고, 사람이 있으면 반영 요청을 걸어요. 본판에 들어가기 전 마지막 관문이에요.
- 6합친 뒤 갈래를 지워요. 합쳐진 갈래를 남겨 두면 목록이 곧 어지러워져요. 기록은 본판에 이미 남아 있어서 지워도 사라지지 않아요.
네 번째 걸음을 미루면 값이 커져요
갈래를 오래 안 합칠수록 본판과의 차이가 벌어져요. 하루 벌어진 차이는 몇 분이면 맞추지만, 3주 벌어진 차이는 며칠짜리 일이 돼요. 갈래는 짧게 살다 가는 게 좋아요. 큰 작업이라면 갈래를 크게 하나 파지 말고 작게 여러 번 나누는 편이 안전해요.
확인해 보세요
화면 개편을 사흘째 하고 있는데 결제가 안 된다는 신고가 들어왔어요. 갈래를 나눠 뒀다면 무엇이 가능할까요?
합치기·배포·되돌리기와 뭐가 달라요
여기서 오해가 가장 많이 생겨요. "합쳤어요"를 "손님 화면이 바뀌었어요"로 알아들으면 대화가 계속 어긋나요. 네 가지는 각각 다른 일이에요.
| 하는 일 | 무엇이 일어나나 | 손님 화면은 |
|---|---|---|
| 갈래 뜨기 | 지금 코드를 복사해 이름표를 붙여요. 아무것도 바뀌지 않아요 | 그대로예요 |
| 갈래에서 커밋 | 그 갈래에만 기록이 쌓여요. 본판은 안 건드려요 | 그대로예요 |
| 본판에 합치기 | 갈래에 쌓인 것이 본판으로 들어와요. 이제 나갈 자격이 생겼어요 | 아직 그대로예요 |
| 배포 | 본판의 내용을 실제로 손님이 보는 곳에 올려요 | 이때 바뀌어요 |
그래서 되돌릴 때도 자리가 둘로 갈려요. 손님 화면을 급히 옛날 것으로 되돌리는 건 이전 버전으로 돌리기고, 잘못 합쳐진 코드를 본판에서 걷어내는 건 그다음 일이에요.
실제로 겪는 장면
장면 1 · 외주 개발자가 말했다
“그 기능은 브랜치에 다 올려놨어요. 확인해 보세요.”
아직 본판에 안 들어갔고 손님 화면도 안 바뀌었다는 뜻이에요. 코드가 어딘가에 있다는 것과 손님이 쓸 수 있다는 것은 다른 상태예요. 되물을 한마디는 정해져 있어요. "그럼 지금 제가 눌러 볼 수 있는 주소가 있나요." 갈래 상태의 작업을 미리 보려면 별도의 주소가 필요하고, 그게 없으면 확인은 합친 뒤에나 가능해요.
장면 2 · 합치는 날 작업이 멈췄다
“충돌이 나서 오늘은 못 합칠 것 같아요.”
두 갈래가 같은 부분을 서로 다르게 고쳤다는 뜻이에요. 고장이 아니라 어느 쪽을 살릴지 사람이 정해 달라는 질문이에요. 여기서 물을 건 원인이 아니라 범위예요. "몇 군데인가요." 몇 군데면 그날 안에 끝나고, 수십 군데면 갈래를 너무 오래 안 합친 결과라 다음부터 주기를 줄이는 게 답이에요.
두 장면의 교훈이 같아요. 갈래는 작업을 안전하게 만드는 대신, 합치는 날을 만들어요. 그 날을 자주 만들수록 하루가 가벼워지고, 미룰수록 하루가 무거워져요.
언제부터 갈래가 필요한가
여기가 정직해야 하는 자리예요. 갈래는 공짜가 아니에요. 관리할 것이 늘고 합치는 날이 생겨요. 규모에 안 맞으면 그냥 번거로움이에요.
| 내 상황 | 갈래를 어떻게 다뤄도 되나 | 왜 |
|---|---|---|
| 혼자 만들고 아직 손님이 없어요 | 본판 하나로 충분해요. 갈래는 안 나눠도 돼요 | 부숴도 다치는 사람이 없어요. 지금은 속도가 더 값져요 |
| 손님이 쓰기 시작했어요 | 여기서부터 나눠요. 고치는 일마다 갈래 하나예요 | 본판이 늘 멀쩡해야 급한 일이 생겼을 때 그 자리에서 대응할 수 있어요 |
| 결제나 예약이 돌아가고 있어요 | 본판에 아무나 바로 못 넣게 막아 둬요 | 돈이 걸린 화면은 실수 한 번의 값이 커요. 관문이 하나는 있어야 해요 |
| 사람이 둘 이상 손대요 | 각자 갈래에서 일하고 합칠 때 서로 봐 줘요 | 같은 파일을 동시에 고치는 일이 생겨요. 갈래가 없으면 서로의 작업을 덮어써요 |
| 외주에게 맡기고 있어요 | 본판은 사장님 쪽 창고에 두고, 작업은 갈래로 받아요 | 합치기 전에 볼 기회가 생겨요. 받고 나서 보는 것과 넣기 전에 보는 것은 값이 달라요 |
갈래가 많은 것도 문제예요
갈래는 늘리기 쉬워서 금방 스무 개가 돼요. 그중 절반은 누가 왜 만들었는지 아무도 모르는 것들이에요. 기준 하나면 정리돼요. 지금 사람이 손대고 있지 않은 갈래는 살아 있을 이유가 없어요. 합쳤으면 지우고, 버린 것이면 지워요.
자주 묻는 것
- Q. 코드를 볼 줄 모르는데 갈래를 알아야 하나요?
- 만드는 건 AI나 개발자가 해요. 사장님이 알아야 하는 건 두 가지예요. 지금 작업이 본판에 들어갔는지, 그리고 갈래 목록을 어디서 보는지요. 이 둘만 알면 "다 됐다"는 말이 어느 단계를 뜻하는지 스스로 확인할 수 있어요.
- Q. 갈래를 지우면 그동안 한 작업이 사라지나요?
- 합친 뒤에 지우는 거면 안 사라져요. 작업은 이미 본판 기록에 들어가 있고, 지우는 건 이름표 하나예요. 다만 합치지 않은 갈래를 지우면 거기 쌓인 것이 갈 곳을 잃어요. 그래서 지우기 전에 합쳤는지부터 확인하는 순서가 있어요.
- Q. 본판에 아무나 못 넣게 막는다는 게 무슨 뜻인가요?
- 창고 설정에서 본판을 잠가 두는 거예요. 잠가 두면 본판에 바로 쓸 수 없고, 반드시 갈래를 거쳐 반영 요청으로만 들어갈 수 있어요. 사람이 늘거나 결제가 걸린 뒤에는 이 설정 하나가 사고를 크게 줄여요. 설정 위치는 깃허브 쪽에 있어요.
- Q. 갈래에서 만든 걸 미리 눌러 볼 수는 없나요?
- 가능한데 준비가 필요해요. 갈래마다 임시 주소를 만들어 주는 방식이 흔하고, 아니면 연습 무대에 올려서 봐요. 그런 준비가 없으면 갈래 상태의 작업은 눈으로 못 봐요. 맡길 때 "확인은 어디서 하나요"를 처음에 정해 두세요.
- Q. 충돌이 났다는데 제가 할 수 있는 게 있나요?
- 코드 자체는 손댈 일이 아니에요. 대신 사장님만 답할 수 있는 게 하나 있어요. 두 판본이 다르게 고쳐진 대목이 문구나 가격 같은 것이면 어느 쪽이 맞는지는 사장님이 정해요. 개발자가 물어보러 오면 그 자리에서 답해 주는 게 가장 빠른 길이에요.
- Q. 갈래 이름은 한글로 지어도 되나요?
- 되긴 하는데 권하지 않아요. 도구나 서버에 따라 한글 이름을 다르게 처리하는 경우가 있어서, 나중에 원인 찾기 어려운 문제로 돌아올 수 있어요. 영문 소문자와 빗금, 하이픈 정도로 짓고 뜻은 이름 안에 담으면 충분해요.
하나 더
"작업 다 끝나서 브랜치에 커밋까지 했어요"라는 말을 들었어요. 지금 손님 화면은 어떤 상태일까요?
직접 해보기
고칠 것을 갈래로 나눠 달라고 해보세요
만들고 있는 것이 있으면 스튜디오에서 이렇게 말해 보세요. "이건 지금 쓰는 것과 따로 두고, 잘 되면 그때 합치는 방식으로 진행해 주세요." 갈래라는 단어를 몰라도 돼요. 중요한 건 지키고 싶은 쪽이 무엇인지를 먼저 말하는 거예요. 이 한 줄이 실서비스를 건드리지 않게 만드는 첫 습관이에요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
갈래를 뜨는 데 왜 시간이 안 걸리나 · 코드를 통째로 복사한다고 했는데, 실제로 파일이 두 배로 늘어나는 건 아니에요. 갈래는 "이 지점부터 시작한다"는 표식 하나에 가까워요. 그래서 갈래를 뜨는 건 순식간이고, 개수가 늘어도 무거워지지 않아요. 이 성질 때문에 "작업 하나에 갈래 하나"라는 습관이 부담 없이 굴러가요. 파일을 폴더째 복사해 두던 방식과 결정적으로 다른 점이 여기예요.
합치는 방식이 두 가지인 이유 · 갈래를 본판에 합칠 때, 갈래가 있었다는 사실을 기록에 남기는 방식과 한 줄로 펴서 남기지 않는 방식이 있어요. 앞은 언제 무엇이 갈라졌다 합쳐졌는지 그대로 보여서 사고 추적에 유리하고, 뒤는 기록이 한 줄로 깔끔해서 읽기 쉬워요. 정답은 없고 팀이 하나로 정해 두면 돼요. 사장님이 챙길 건 방식이 아니라 팀 안에서 한 가지로 통일돼 있는가예요. 섞이면 기록을 읽는 사람이 매번 헷갈려요.
본판 이름이 두 가지인 이유 · 본판 이름으로 master 와 main 이 둘 다 보여요. 오래된 창고는 master, 최근에 만든 창고는 main 인 경우가 많아요. 뜻은 같아요. 문제는 문서나 자동 설정이 한쪽 이름만 알고 있을 때예요. 배포 설정이 master 를 보고 있는데 창고의 본판은 main 이면, 합쳤는데 아무 일도 안 일어나요. 배포가 안 도는 원인을 찾을 때 이 이름 두 개가 어긋났는지부터 보면 빨라요.
이것만 기억하세요
- ·갈래는 지금 코드를 복사해 이름표를 붙인 것이에요. 거기서 뭘 해도 손님 쪽은 멀쩡해요
- ·본판은 늘 멀쩡하게 둬요. 그래야 급한 일이 생긴 날 그 자리에서 대응할 수 있어요
- ·합쳤다는 말은 손님 화면이 바뀌었다는 뜻이 아니에요. 배포가 따로 있어요
- ·갈래는 짧게 살다 가는 게 좋아요. 오래 묵힐수록 합치는 날이 무거워져요
- ·혼자에 손님이 없으면 본판 하나로 충분해요. 손님이 쓰기 시작한 날부터 나눠요