브랜치 전략 도입에도 전략이 필요합니다 #1
구글 검색으로도 못 찾는 브랜치 전략 성공 방법 7가지
여러분이 급속도로 성장하는 스타트업에 취업하거나 새롭게 출발한 팀에서 개발을 하게 된다면, 증가하는 팀원 숫자만큼이나 다양한 문제에 직면하게 됩니다. 어딜 가나 시니어는 희귀하고 또 개발에 진심인 시니어는 더욱더 희귀하죠. 또 그런 사람들은 특정 회사에 몰려 있으니, 우리 팀에 그런 분을 모셔오기란 쉽지 않습니다. 결국 내부의 주니어가 성장해주어야 팀이 굴러갑니다. 이렇게 팀 내부에 시니어가 없다면 팀은 다양한 시행착오를 겪게 될 텐데요. 시행착오 자체는 나쁜 것이 아니며, 여러분을 한 단계 성장하도록 해주지만 걔 중에는 종종 치명적인 것들이 있게 마련입니다. 오늘은 그중에 하나인 브랜치 전략에 다뤄볼 텐데요. 브랜치 전략이 실패했을 때 초래되는 결과나 실패하는 주요 요인에 대해서는 아래 글에 서술했습니다. 오늘은 어떻게 브랜치 전략을 성공적으로 우리 팀에 안착시킬 수 있는지에 대한 내용을 다뤄보려고 합니다.
https://brunch.co.kr/@domini95/140
1. 브랜치 전략이 왜 필요한지에 대한 이해입니다.
브랜치 전략을 도입하기 전에 가장 먼저 고민해봐야 할 것은 지금 왜 브랜치 전략이 필요한지에 대한 이해입니다. 현재 내가 개발하고 있는 앱이 복잡한 기능을 요구하지 않는다거나, 한 두 사람에 의해 가끔씩 개발되고 있다면 브랜치 전략이 필요하지 않을 수 있습니다. 그러한 상황에서 도입하는 브랜치 전략은 오히려 독이 될 수 있습니다. 브랜치 전략을 고민할 시간에 기능 하나라도 더 추가해서 테스트해 보는 것이 이득일 수 있는 상황인 거죠. 브랜치 전략이 필요한 순간은 머지 컨플릭트가 너무 많이 발생하거나, 내가 고쳐놓은 버그가 다른 사람의 머지 후에 다시 생기거나, 내가 한 작업을 배포하기 위해 다른 사람의 배포가 끝날 때까지 기다려야 하는 등의 문제점이 나타날 때를 위함입니다. 이런 문제가 없다면 브랜치 전략을 고려하지 않아도 됩니다. 다만, 분명히 이런 문제들이 나타나고 있는데 바쁘고 번거롭다는 이유로 애써 외면하거나 이런 부분에 대해 민감도가 낮은 조직이 있습니다. 내가 프로덕트에 대해 애정을 가지고 있다면 프로덕트의 성장을 위해 반드시 해결되어야 하는 문제 중 하나라고 생각하고, 현상을 잘 관찰해야 합니다. 물론 모두가 꼭 그렇게 할 필요는 없지만 애정의 가장 큰 증거 중 하나는 관찰의 여부입니다. 아래는 제가 Gitflow 브랜치 전략을 도입하면서 해결하고자 했던 문제였습니다.
1. 여러 기능이 동시에 배포 및 테스트가 되어야 한다.
2. 치명적인 버그 또는 이슈가 발생했을 경우 핫픽스와 롤백이 쉬워야 한다.
3. 핫픽스는 다른 커밋의 영향 없이 단독으로 운영환경에 배포가 가능해야 한다.
4. 핫픽스가 운영환경에 배포되기 전에 사전에 테스트가 될 수 있어야 한다.
2. 저는 앱 개발자이고 Gitflow 전략이 필요했습니다.
브랜치 전략을 조사하다 보면, 여러 가지 브랜치 전략이 존재한다는 것을 알게 됩니다. 최근 각광받고 Best Practice로 여겨지는 것은 크게 3가지인데, GitFlow, GithubFlow, GitlabFlow가 그것입니다. 물론 각 전략의 변형도 존재하며, 아주 옛날에 쓰던 요즘은 추천하지 않는 브랜치 전략도 있습니다. 또 대기업에서나 쓸법한 브랜치 전략도 존재하고, 회사에 따라 마스터 브랜치에서만 작업하는 회사도 있습니다. 사실 선택지는 너무나 많고, 우리가 처한 상황은 모두 다릅니다. 따라서 적절한 브랜치 전략을 택하시는 것을 추천합니다. 단, 주니어로만 이루어진 개발팀은 경험이 없기 때문에, Best Practice 중에서 하나를 선택한 후 상황에 맞게 점점 바꾸어나가는 것을 추천합니다. 또 특정 브랜치 전략을 사용해보고 실패한 경우, 포기하지 마시고 다른 브랜치 전략도 시도해 보며 끊임없이 맞는 방식을 찾아나가는 것이 좋습니다.
3. 동료의 공감을 얻어야 합니다.
브랜치 전략은 나 혼자서 할 수 있는 것은 아닙니다. 동료들도 함께 문제의식을 가지고 한 팀처럼 같이 움직여야 도입할 수 있습니다. 예를 들어, 나는 GitFlow 방식이 현재 팀에 가장 맞다고 생각하는데 동료는 GithubFlow 방식을 마음에 들어 한다면 먼저 협의가 되어야 합니다. 최종적으로 서로의 의견에 동의하지 않더라도 서로 신뢰하고 협업할 수 있는 구조를 만들어야 합니다. "A 방법을 X월 XX일까지 시도해보고 효과가 없으면 B방법을 시도해 보자!"가 좋은 하나의 방법이 될 수 있습니다. 기한이 없는 시도는 지치고, 시도가 없는 논쟁은 파국입니다.
4. 팀원들의 상황을 어느 정도 파악하고 있는 사람이 필요합니다.
브랜치 전략을 모든 팀원이 함께 만들어나가는 문화입니다. 한 사람이 규칙을 어기면 꽤 심각한 문제가 발생하고 다른 동료에게도 영향을 줍니다. 처음에는 브랜치 전략에 맞추어 작업을 하는 것이 어색하고 번거롭게 느껴질 수도 있습니다. 또는 규칙을 착각하여 브랜치를 잘못 생성하고 머지할 수도 있습니다. 이러한 경우 팀원이 브랜치 전략을 따를 수 있도록 지켜보고 유도하는 사람이 필요합니다. 또한 팀원의 리소스를 관리하는 것도 중요합니다. 일이 너무 많아 특정 기능을 빠르게 개발하려고 시도하는 사람은 문제를 발생시킬 소지가 있습니다. 브랜치 전략이고 뭐고 내일 당장 기능 하나를 완성시키지 못하면 질책을 받는 사람은 브랜치 전략을 신경 쓰는 것이 번거롭습니다. 만약 당신의 팀의 리소스 분배나 일정 추정에 문제가 있다면 해당 문제를 먼저 해결하거나, 적어도 그 부분이 앞으로 해결될 것이라는 메시지를 전해야 합니다. 브랜치 전략을 정하는 것도 장기적으로는 개발자의 리소스 부담을 경감하고 다가오는 일정에 원활하게 대응하기 위함입니다.
5. Pull Request의 사이즈가 너무 크면 곤란합니다.
브랜치 전략은 본질적으로 CI/CD라는 단어와 밀접한 연관이 있습니다. CI/CD는 단순히 배포 자동화나 테스트 케이스를 의미하는 것은 아닙니다. 그보다는 코드의 통합과 테스트, 배포 방법을 아우르는 일종의 철학입니다. Continuous Integration이란 내가 작성하는 코드가 지속적으로 공동 작업공간에 통합(머지)된다는 것에 의미가 있습니다. 따라서 개별 작업자의 Pull Request 사이즈가 너무 크면 CI이라는 철학 자체가 무의미해집니다. 논리적으로 생각해봐도 PR 사이즈가 크면 머지 컨플릭트가 더 많이 발생하고 테스트와 통합에 드는 비용이 증가합니다. 이 내용을 인지하고 있더라도 큰 기능을 개발하고 있거나, 코드 베이스 자체가 오염되어 있는 경우, 또는 작업자의 마음의 여유가 충분하지 않은 경우에는 지속적으로 Pull Request를 작성하는 것이 여의치 않을 수 있습니다. 리더는 동료의 감정 상태까지도 고려해야 합니다.
다음 편에 계속
