주제
팀에서 공유하는 develop 브랜치가 업데이트될 때, 작업 중인 사람의 자산을 손상시키지 않고 업데이트하는 방법을 숙련(skill)하면서 개발 경험이 크게 향상되었기에 그 이야기를 전하고자 합니다.
브랜치 전략
저희 팀에서는 개발 시 주로 아래 두 가지 브랜치를 사용하고 있습니다.
| 브랜치 | 역할 | 규칙 |
|---|
| develop | 클라우드 환경이 갖춰진, 시험적으로 동작 확인 가능한 공간 | 자유롭게 망가뜨려도 OK. force push 가능 |
| main | 그대로 stg / prd에 반영됨 | 사람의 승인이 있는 PR(Pull Request)을 내야 병합할 수 있음 |
develop는 마음껏 망가뜨릴 수 있는 곳이지만, 팀원 모두가 하나의 환경을 공유하고 있기 때문에 충돌에는 주의를 기울일 필요가 있었습니다.
과제
temp 브랜치로 '추가 작업'하는 운영 방식
develop는 force push가 가능하지만, 다른 누군가가 동작 확인 중인 상태라면 그 사람의 변경 사항을 지워버리게 됩니다.
그래서 누가 작업 중일 때는 temp 브랜치를 거쳐 추가 작업을 하는 운영 방식을 사용하고 있습니다.
이렇게 함으로써 다른 사람의 변경 사항은 남겨둔 채, 자신의 변경 사항만 올릴 수 있게 되었습니다.
위 과정을 매번 수동으로 하는 것이 번거로웠다
충돌(Conflict)은 막을 수 있지만, develop를 업데이트할 때마다 아래와 같은 작업이 발생했습니다.
- 최신 develop를 pull 받기
- 다른 사람의 작업이 올라와 있는지 확인하기
- 올라와 있다면 develop에서 temp 브랜치를 만들기
- temp 브랜치에 자신의 작업 브랜치를 병합(merge)하기
- 충돌이 있으면 해결하기
- develop에 push 하기
- temp 브랜치 삭제하기
이를 개발 과정 중에 여러 번 반복하면 개발 경험이 매우 나빠집니다.
지금까지 이 과정을 숙련화(skillize)한다는 발상이 떠오르지 않아 수동으로 진행하고 있었습니다.
/deploy-dev
스킬(skill)
해결책: 위 흐름 전체를 Claude Code의 스킬로 만들고, /deploy-dev로 호출할 수 있도록 했습니다.
전체적인 흐름
1. develop 상태 판별하기
먼저 현재 develop에 다른 사람의 작업이 올라와 있는지 여부를 판별합니다.
- 최근 push가 본인의 force push인지: 자신이 마지막으로 force push를 했다면, develop는 자신의 상태 그대로입니다.
- develop에만 존재하는 커밋(commit)이 있는가: 작업 브랜치에 포함되지 않은 커밋이 있다면, 다른 사람의 변경 사항이 올라와 있다는 의미입니다.
이 결과에 따라 다음 두 가지 패턴 중 어느 것으로 업데이트할지 결정합니다.
2A. 작업 브랜치를 force push 하기
다른 사람의 작업이 올라와 있지 않다면, 신경 쓰지 않고 덮어써도 문제가 없으므로 작업 브랜치를 develop에 그대로 force push 합니다. 불필요한 병합 커밋(merge commit)이 늘어나지 않아, develop가 깨끗한 상태로 유지됩니다.
2B. temp 브랜치를 거쳐 병합하고 push 하기
다른 사람의 작업이 올라와 있는 경우에는 앞서 설명한 temp 브랜치 운영 방식을 따릅니다.
- develop에서 temp 브랜치를 생성하기
- temp 브랜치에 작업 브랜치를 병합하기
- develop에 push 하기
temp 브랜치는 worktree 상에서 작업을 진행하므로, 로컬 작업 디렉터리(local working directory)를 오염시키지 않아도 됩니다.
3. push 전에는 반드시 사람이 승인해야 한다
A 패턴이든 B 패턴이든, push 하기 전에 반드시 사람의 승인을 거치도록 했습니다.
판단이나 조작은 스킬에 맡기되, '정말로 push해도 괜찮은지'에 대한 최종 판단은 사람이 하도록 역할 분담을 했습니다.
4. 완료 보고
push가 끝나면 어떤 패턴으로 무엇이 반영되었는지 보고합니다.
5. cleanup은 별도의 스킬로 분리하기
temp 브랜치와 worktree의 삭제는 clean-up용 스킬로 따로 준비하여, 작업 완료 후에 해당 스킬을 호출하는 형태로 만들었습니다.
도입 효과
develop를 업데이트하고 싶을 때는 팀에 공지만 하고 /deploy-dev를 실행하기만 하면 되었습니다. 이전까지 수동으로 진행했던 6~7단계가 필요 없어졌고, 개발 경험이 크게 향상되었습니다.
왜 더 일찍 생각해내지 못했는지 정말 생각합니다..
맺음말
평소 업무 속에는 의외로 자동화하거나 간소화할 수 있는 부분이 숨어 있다는 것을 다시 한번 느꼈습니다.
매번 수행하지만, 다소 번거로운 작업들은 '스킬화(skillization)'나 자동화를 하려는 인식을 명확히 갖지 않으면 예상치 못한 곳에 개선할 여지가 있다는 것을 배웠습니다.
Discussion
