워크트리는 작은 단위로 끊고 버린다 — 병렬 개발 절차를 되짚은 밤

8월 30일 일요일 밤 8시 직전, 에르메스단에 자기 작업 방식이 맞는지 확인해 달라는 질문이 올라왔다. 한 참여자는 깃 워크트리(git worktree)를 나눠 병렬로 개발을 진행하고, PR(풀 리퀘스트)이 준비되면 코덱스 리뷰를 돌린 뒤 main에서 페이블(Fable)이 머지하는 흐름을 그대로 소개했다. 절차를 다 늘어놓은 끝에 그가 붙인 말은 확신이 아니라 확인 요청이었다.

"worktree나눠서 병렬로 개발 진행하고"

"보통 이런식으로 돌리는게 맞나요?"

무슨 일

곧 다른 참여자가 방 안의 통례를 전했다. 큰 기능을 통째로 맡길 때는 "ulw plan 이나 이런거 쓰시고서 mass ulw 이렇게 많이 쓰시더라고요"라며, 사람들이 즐겨 쓰는 지시 방식을 알려준 것이다. 여기 나온 ulw는 이 방에서 쓰는 은어로, 반복 수정·확인을 자동으로 도는 짧은 명령을 가리킨다. 다만 뒤에 plan을 붙이거나 앞에 mass를 붙인 형태가 각각 어디까지를 뜻하는지는 이날 대화에서 풀리지 않았고, 방에서 통용되는 지시 관용구로만 오갔다. 질문자가 실제로 걸려 있던 지점은 그다음에 나왔다. A부터 Z까지 만들고 싶은 기능이 있는데, 워크트리에서 A만 개발하고 날린 뒤 다시 만드는 일이 계속 반복된다는 것이었다.

그는 자신이 그렇게 하는 이유까지 함께 밝혔다. "근데 뭔가 얘기를 들어보니까 중간 중간 작은단위로 작업을 PR을 계속하고 작업했던 워크트리는 날리고 다시 만드는게 좋다고 하는것 같아서"라는 말처럼, 작은 단위로 PR을 올리고 쓰던 워크트리는 버리는 편이 낫다는 조언을 듣고 그대로 따르는 중이었다. 그러면서 하나의 워크트리에서 기능이 끝날 때까지 이어가면 안 좋은 점이 있는지 되물었다. 마지막으로 확인한 것은 절차의 시작 지점이었다.

"main에서 워크트리 만들어서 진행해줘 이렇게 진행하는분은 없으신가요"

맥락과 시사점

질문의 모양을 보면 이 질문에서 걸린 쟁점이 도구 사용법이 아니라 작업을 어디서 끊을지에 대한 감각이라는 게 드러난다. 워크트리를 병렬로 벌려 놓고 리뷰를 코덱스에 맡기고 머지까지 흐름에 태운 사람이, 정작 기능 하나를 한 워크트리에서 끝까지 밀어도 되는지라는 가장 기본적인 경계에서 멈춰 선다. 실행 속도보다 분할 단위가 먼저 걸린다는 뜻이다.

소개된 절차를 늘어놓고 보면 사람이 남아 있는 자리도 드러난다. 코드를 짜는 일도, 리뷰를 도는 일도, main에 합치는 일도 모두 도구 쪽으로 넘어가 있고, 사람이 정하는 것은 워크트리를 몇 개 벌릴지와 어디서 PR을 끊을지다. 그래서 이 질문은 명령어를 어떻게 쓰느냐가 아니라 작업을 어떻게 운영하느냐에 가깝다. 질문자가 호소한 불편도 도구가 실패했다는 이야기가 아니라, A만 만들고 워크트리를 날리는 일이 되풀이되면서 같은 자리를 다시 밟게 된다는 재작업의 문제였다.

또 하나 눈에 띄는 것은 그 분할 기준이 검증된 원칙이 아니라 전해 들은 관행의 형태로 옮겨 다닌다는 점이다. 질문자는 작은 단위 PR과 워크트리 폐기를 좋다고 하니까 따르고 있었고, 왜 좋은지는 확인하지 못한 채였다. 돌아온 답인 ulw plan과 mass ulw 역시 다들 그렇게 쓰더라는 관찰의 형태였다. 방식이 빠르게 도는 만큼 근거는 얇게 공유되며, 이 질문은 그 얇은 층을 한 번 두드려 본 시도에 가깝다.