작업 단위에 관하여

요즘 졸업작품을 진행하며 3명이 같이 작업을 하고 있다. 작업 단위를 잘 나누는 것에 대한 중요성을 간과하며 초반을 진행했다. 작업 단위를 왜 잘 나눠야 하는지 생각해보려고 한다.

일단 왜 작업 단위를 잘 나눠야 할까? 아래의 이유들이 존재한다.

코드 병합의 어려움

만약 내가 진행하던 작업의 단위가 너무 크고 꽤 오랜기간 작업을 진행해온 경우 상당한 커밋이 쌓였을 것이다. 그러다 다른 사람의 PR이 main 브런치에 병합되었다고 가정해보자. 내 작업 브런치와 main 브런치와 충돌이 발생한 경우 머지 혹은 리베이스를 진행해야 한다. 이때 모든 커밋마다 충돌을 제거해야 할 수도 있다. 이는 여간 번거로운 일이 아니다.

물론 작업하는 영역을 잘 나눈다면 충돌을 피할 수 있다. 하지만 코드 충돌은 완벽히 피하기 어렵다.

리뷰의 어려움

작업의 단위가 엄청 큰 PR을 만든다고 생각해보자. 이렇게 되는 경우 코드의 변경량이 1000줄 이상으로 많아질 것이며 이는 리뷰하기 어렵게 만든다.

그리고 작업의 단위가 큰 경우 보통 여러 이슈를 동시에 해결하는 PR이 되기 마련이다. 때문에 리뷰어는 이 코드가 어느 작업을 처리하는지 계속 생각하며 리뷰를 진행해야 해서 리뷰 몰입도가 떨어진다.

어떻게 작업을 나눌까?

그렇다면 작업을 어떻게 나눠야 할까? 개인적인 생각으로는 하루 혹은 이틀 안에 끝낼 수 있도록 작업을 나누는 게 좋다고 생각한다. 코드 변경량으로 따진다면 500줄 이내이다.

작업을 잘 나누기 위해서는 더욱 중요한 점은 요구사항 분석을 철저히 진행하는 것이다. 해당 이슈의 요구사항을 분석한 뒤 구현해야할 항목이 너무 많아보인다면 하위 이슈로 쪼개면 된다. 혹은 너무 작다면 더 큰 단위로 작업을 만들 수 있다.

하나의 브런치는 하나의 이슈를 해결해야한다. 하나의 브런치에서 여러 이슈를 동시에 해결하지 말자.