기존 PR 방식에 지친다면? Ship, Show, Ask 브랜치 전략 소개

 

기존 PR 방식에 지친다면?

마틴파울러 블로그에 소개된 브랜치 전략을 소개하려고 한다. Rouan Wilsenach가 올해 9월 달에 작성한 따끈따끈한 글인데, 공감되기도 하면서도 필요한 팀들이 많을 것 같아 정리해본다.

 

CI 정책이 확실하게 있고 팀원들이 어느 정도 경력이 있다면, 그리고 기존의 PR 방식이 늘어지고 의미 없다고 느껴본 적이 있는 사람이라면 한 번쯤 읽어보면 좋을 것 같다.

 

Ship / Show / Ask

 

 

간단한 정리

Rouan Wilsenach가 제안하는 이유와 전략은 다음과 같다. 기존의 PR 방식은 팀원들의 리뷰 시간으로 반영이 늦어지고, 무의미한 인사를 위한 리뷰로 루즈해져 그저 merge를 위한 approve 인원수 채우기로 전락하기 좋다는 것이었다. 그래서 '작업자가 작업을 반영하는 방법을 직접 선택할 수 있게 하자'가 저자가 제안하는 ship, show, ask 방식이다.

 

간단히 ship은 작업하자마자 바로 반영하는 것이고, show는 선 반영, 후 리뷰를 받겠다는 방식, ask는 기존처럼 pr을 쏘고 리뷰를 받은 후에 반영하는 방식을 말한다. 그 전제로 CI 정책이 확실히 있어야 하고, 더 이상 최소 approve 수 같은 반영을 위한 리뷰 제도가 사라져야 한다고 말한다. 작업자가 직접 반영 방식을 골라서, 본인 스스로 한번 더 생각하게끔 만들 수 있어야 한다고 말한다.

 

팀이 그저 반영 조건을 채우기 위한 리뷰가 이어진다면 이미 그 팀은 사실상 ship 정책을, 팀이 모든 작업을 꼼꼼하게 확인하고 피드백 주는 리뷰가 이어지는다면 이미 그 팀은 사실상 ask 정책을 하고 있는 것이 아니냐라는 말과 함께 그 절충안으로 show 방식, 아니 ship, show, ask 중 하나를 선택할 수 있도록 하는 것은 어떤지 하는 제안으로 이해했다.

 

본문이 길지 않고 어렵지 않으니, 더 정확하고 자세한 설명은 본문을 읽어보길 추천드린다. 🙂

 

 

내 생각에는...

음 일단 문제 사항에 대해 크게 공감한다. 프로젝트가 길어져 단순히 merge 조건을 만족시키기 위한 리뷰가 눈에 보일 때도 있었고, 팀원들이 모두 바빠 리뷰에 시간을 못써 길게는 한달 이상 걸려 merge 되는 PR도 경험한 적 있다. 다만 내가 경험한 팀에 한정해선 당장 ship, show, ask 적용하기 어려울 것 같다는 생각이 든다. 

 

우선 저자의 전제대로, CI가 확실함이 보장되어야 할 것이다. merge의 제한을 풀고 CI가 제대로 안되어 있는 상황에서 ship 처럼 작업자가 바로 merge 할 수 있다? 다른 팀원만이 아니라 내 작업을 올리는 거 조차도 무서울 것 같다. 또 ship 같은 경우는 다른 팀원들에게 변경 내용을 어떻게 전달해야 할지 모호했다. PR 정책이 있다면 설령 무의미한 인사 차례 수준의 approve + review를 남기더라도, 다른 사람이 어떤 작업을 했는지 정도는 확인해야 하는 하나의 과정이 있으니 말이다.

 

나는 PR을 굉장히 꼼꼼하게 확인하는 편이다. 작업 안에서 실수를 찾은 경험도 많지만 PR 리뷰가 단순히 '동작하는지 확인'이라고 생각하지 않는다. 더 깔끔한 구조, 코드를 공유 할 수 있는 공간이 되기도 하고, 놓친 정책에 대한 생각을 공유하는 장이 되기도 한다. 하물며 어떤 작업을 누가 해왔는지 공유하는 것 자체로도 의미를 갖는다고 생각하고 있다. 그걸 꼭 저자의 단어대로 팀원간의 신뢰의 부족이라고 여기지 않았으면 한다.

 

나는 리뷰 문화 개선으로 풀 생각을 먼저할 것 같다. 예를 들어 작업 할당인을 정할 때 모든 팀원이 빡빡하게 이슈를 가져가고 있다면, 조금 여유 있게 작업 단위를 잡거나, 스프린트 별로 최소한의 리뷰 가능 인력을 보류해두고 작업을 할당하는 방식은 어떤가 싶다. 또는 PR이 merge 되어야 하는 기간을 작업자가 명시하는 방식으로 풀어갈 수 있지 않을까 생각한다. 

 

혹은 좀 급하게 작업을 쳐나가야 하는 상황에선 show를 섞어 사용하는 방식을 제안할 것 같다. hotfix와 같은 급한 불은 작업을 하고 미리 반영하되, 더 섬세한 정책과 구조 고민은 후에 하는 것이다.

 

생각해보니까 평소 PR의 리뷰가 많아지거나, 작업 요구 사항이 PR안에서 점점 많아져 어느 순간부터는 '작업은 여기서 반영하고, 이후부터는 새로 이슈를 파서 고민해보는건 어떨까요?' 식의 제안을 한 적이 많은데 저자가 원한 게 딱 이런 문제지 않았을까라는 생각이 스친다.

 

 

그럼에도 

이 글로 팀 리뷰 문화를 돌이켜 볼 수 있었다. 이렇게 전적 동의가 아님에도 이 글을 다른 사람들에게 소개하고 싶은 이유가 이것이다. 이전까지 모호하게만 인지했던, 그냥 '불편하네?' 정도의 문제였지, 처음으로 '그럼 어떻게 바꿔야하지? 그리고 이 글의 방식은 괜찮을까?' 식으로 브랜치 전략에 의문을 가진 것 같다.

 

상황에 따라서 필요한 문화, 전략이 다를 것 같다. 팀원에 따라서 다르고, 팀 분위기 따라 다르고, 프로젝트 상황에 따라 달라야 하고,,, 아마 명확한 규칙으로 정의하진 않았어도 팀마다 미묘하게 다른 문화가 있을 것이다. 당장 나만해도 현재 참여하고 있는 두 프로젝트의 리뷰 문화가 다르고, 한 팀 안에서도 팀원마다 리뷰를 바라보는 게 다르니 말이다.

 

이 소개도 누군가에게 좋은 인사이트가 되었으면 한다. Ship, Show, Ask 가 정확히 팀에 맞는 사람에게도, 나처럼 반만 채택해볼 생각하는 사람에게도, 절대 반대하는 사람에게도 말이다.

 

'기존의 PR 방식에 지친다면' 이라는 제목으로 Ship, Show, Ask 방식을 추천하고 싶다기보다, '글의 저자처럼 팀의 merge 과정 문제를 고민하고 더 좋은 방식을 찾아 공유해보는 건 어떨까요' 라는 얘기를 해보고 싶었다.

 

 

PS.

다른 사람들의 의견이 궁금해서 찾고 있었는데, ycombinator.hacker-news에서 토론이 열린 걸 찾을 수 있었는데 정말 사람마다 다른 경험을 했는지 찬반이 많이 오가는 게 되게 재밌었다.

 

심심한 사람은 한번 읽어보길 추천한다. PR 방식을 경험한 사람이라면 공감되는 말들이 되게 많을 것이다. 찬성쪽도 이해가 가고, 반대쪽도 이해가 가고. 댓글들 경험 얘기에 공감되는 말들이 많아서 웬만한 공감 웹툰만큼이나 재밌게 읽었다. 한번 읽어보시길.

 

https://news.ycombinator.com/item?id=28510212