저쪽에서도 여기를 뜯는다고요?
프로젝트간 영향도 파악과 merge 이야기
네?저쪽에서도 주문서를 뜯는다고요?
담당 개발PM님의 이야기는 당황스러웠다.
꽤 긴 장기 프로젝트를 진행한지 한참이나 되었는데 똑같은 화면을 수정해야하는 다른 프로젝트가 있다는 것이었다.
쉽게 말하면 내가 된장찌개 끓이고 있는 냄비에 누군가 계란을 삶겠다고 선언한것이나 다름없었다. 찌개와 계란은 그 사이즈도 다르지만 만드는 사람도 다르다. 게다가 음식을 만드는 과정도 완전히 다르다. 문제는 냄비가 같아야만 한다는 것이었다.
정신없이 여러가지 프로젝트가 동시다발적으로 진행되다보면 이런 일은 종종 발생한다. 이미 기획도 얼추 끝냈고 한참 개발을 한다고 마음을 놓을 수만은 없다. 내가 하는 플젝은 주문서 개선이었고 다른 사람은 주문서에 특정 요소를 추가하는 일이 생겨날 수 있다. 오픈 예정 일자를 기준으로 몇가지 케이스가 생겨나기 마련이다.
사실 냄비요리보다 상황은 심각하다.
주문서라는 웹화면은 겉보기에는 UI로 이루어진 하나의 평면으로 보인다. 하지만 모든 화면은 사실 코딩으로 이루어진 글짓기다. 웹브라우저라는 뛰어난 예술가가 코딩글을 읽어내서 이미지화하여 보여주는 것뿐이다.
만약에 누가 하나의 글을 동시에 수정하고 있다면 어떻게 될까? 어쩌다보니 같은 문장을 수정했다면 마지막에 저장된 문장에 따라 다른 한사람의 글은 앞뒤가 맞지 않게 될 수 있다.
부랴부랴 양측의 담당자들을 모았다. 어차피 둘 다 오픈 날짜가 정해진 것이고 개발이며 테스트며 기간이 겹치면 소스 merge일정을 협의해야하기 때문이다.
Merge : 합치다. 병합하다
언제,누가,어떤 식으로 합칠 것인가
먼저 기획의도에서 서로의 프로젝트가 상충하는지 보는 것은 기본중에 기본이다. 의도와 로직이 다르다면 여기에 대해서는 두 프로젝트가 컨센서스를 이뤄야한다.
기획적이 합의가 되었다면 이제 Product managing이슈가 남는다. 바로 merge에 대한 논의다.
이 회의에서 체크해야할 것들은 몇가지가 있다.
서로 겹치는 개발범위를 파악한다
개발용 코딩 소스를 다운로드한 시점을 확인한다
누가 더 많은 범위 작업인지 난이도와 소스 복잡도를 확인한다.
최종적으로 어느 프로젝트에서 merge할 것인지 결정한다.
Merge일정을 협의한다.
1) 서로 겹치는 개발범위를 파악한다
가장 먼저 해야할 일은 두가지 프로젝트의 관여범위를 체크하는 것이다. 한마디로 소스가 얼마나 섞이는지 보는 것이다.
의외로 동일 페이지라도 전혀 안겹치는 부분이면 단순하게 붙여넣기가 되는 쉬운 케이스도 있다.
2) 개발용 코딩 소스를 다운로드한 시점을 확인한다
그 다음은 누가 더 최신 소스인지 확인한다. 흔히 프로젝트 개발시에는 기존 운영 코드를 언제 다운로드 받아서 개발용 작업 서버와 로컬컴퓨터 환경에서 수정 코딩 작업을 하도록 되어있다. 누군가 먼저 다운 받은 사람과 나중에 받은 사람이 있을거고 가능하면 나중에 받은 최신 코드를 기준으로 merge하는게 더 안전하다.
3) 누가 더 많은 범위 작업인지 난이도와 소스 복잡도를 확인한다.
하지만 항상 나중에 다운로드 받은 쪽을 기준으로 merge하진 않는다. 사실 개발 일정이 훨씬 긴 프로젝트라면 그만큼 난이도나 개발범위가 넓을 수 있기 때문이다. 전체 글이 100줄인데 80줄 고친 프로젝트와 10줄 수정한 프로젝트가 있다면 80줄 고친 코딩소스를 기본으로 엎는게 더 편하다. 게다가 로직도 더 복잡할 가능성이 높기에 로직을 보호하려는 측면도 있다.
4)최종적으로 어느 프로젝트에서 merge할 것인지 결정한다.
이런 여러 논의를 토대로 누가 상대방 소스를 받아서 하나의 파일에 합칠 것인지 논의한다. 보통은 가장 전체 시스템 파악이 잘 되어 있고 누구보다도 솔선수범해주시는 개발자분이 이 일을 맡아주시는 경우가 많다. 일정과 프로젝트간 이슈를 조정해야하는 PM입장에서는 감사하고 죄송할 뿐이다.
Merge용 프로그램의 예시 : 2개의 소스를 비교하여 하나의 소스로 다시 수정 작성한다. 이게 코딩이 아니면 그냥 워드에서 문서 여러개 펴놓은 거나 비슷하다.5)Merge일정을 협의한다.
마지막으로 실행을 위한 일정을 논의해야한다. 일정은 테스트 기간과 오픈 일자를 고려한다. (참고로 현재 운영중인 실제 소스는 제일 마지막에 비교해서 맞춰야한다)
오픈 일자가 완전히 같은 경우 테스트를 통합하여 진행할 수도 있다. 즉, 애초에 소스를 완전머지하여 같은 테스트서버에 올리고 각자의 프로젝트의 개발이 정상적으로 작동하는지 테스트를 진행하는 것이다. 그럴 때는 오류수정 시에도 계속 머지된 형태로 수정하면 된다.
안좋은 경우는 테스트기간이 겹치는데 오픈일자는 다른 경우다. 이럴때는 나중에 오픈하는 프로젝트는 소스까지도 merge된 상태로 테스트해야하지만 먼저 오픈되는 프로젝트는 오픈 전까지 최신 운영기 소스에만합쳐서 테스트하고 다른 개발서버를 이용하는 경우도 있다. 때문에 머징 절차가 복잡해진다.
하지만 명확한건 기존에 반영된 소스는 다음에 어떤 소스가 반영되도 작동되어야된다는 점이다.
Merge가 중요한 이유
Merge를 하는 것이 너무나 자연스러워보여도 사실 되도록 이 경우는 피할 수 있으면 피하는 것이 좋다. 앞서 예시처럼 두개의 서로 다른 글을 하나로 합치려면 두글의 문맥(=로직)과 말하고자하는 바(=기능)를 정확히 알아야하는데 그걸 누군가 1명이서 해야하기 때문이다. 할 수 있는 분이 있다면 감사하지만 그런 감사한 경우만 생기진 않는다. 운이 나쁘면 서로간 악영향으로 오류가 잔뜩 생길 수도 있다.
프로젝트간에만 문제가 되는건 아니다. 프로젝트 진행중에 운영기의 소스가 너무 많이 변해도 동일한 이슈는 발생한다. 만약 이를 최소화해야하고 변화의 양이 너무 커서 변수를 조금이라도 줄여야한다면 '소스 프리징 (source freezing)'을 논의 해볼 수도 있다. 프로젝트가 끝날 때까지 소스를 변경하지 못하게 하는 것이다.
https://en.m.wikipedia.org/wiki/Freeze_(software_engineering)
자, 이 모든 단계에서 Product managing을 하는 기획자라면 조율이 필요하다. 하지만 제일 중요한건 개발담당자들이 의견을 청취하고 제일 좋은 방법을 도출해내는 것이다. 각 프로젝트의 PM들만 협의해서 결론을 내지말고 소스 전체를 직접 작정하는 분들이 서로 대화해보면 작업에 가장 적합한 일정과 프로세스를 정할 수 있다.
