기본 기능은 거의 같으나, 일부 customization이 필요한 module이 있을 경우를 가정하자.
이 경우, 소프트웨어 공학적으로 보면, 기존 module에 melt-in해서 넣는게 좋다.(코드 중복은 가능하면 피해야 한다.)
하지만, 대부분의 일반적인 회사에서, 많은 경우, code를 fork하거나, 비슷한 다른 모듈을 만들게 된다.
왜 그럴까? 내 생각에는 조직논리가 가장 큰 이유로 보인다.

SW 코드에는 여러가지 철학적인 가치판단이 반영되기 마련이다.(변수 명, 함수 명, 코드 설계 방식 등.)
그런데, 하나의 코드를 여러 조직이 관리하게 될 경우, 의사결정시 조율해야 하는 것들이 많아진다.
하나의 조직 혹은 극단적으로 한명이 코드를 관리하면 이런 문제가 없거나, 있더라도, 조직의 leader에 의해 쉽게 조율된다.
그러나, 여러 조직이 엮이는 경우, 의사결정을 위한 협의 과정을 거쳐야 하는데, 이건 거의 모든 개발자들이 피하고 싶어한다.
그러니, 이리저리 논란에 엮이는 것 보다는 코드를 fork하고, 자체 관리를 하는 방향을 택하게 되는 것이다.

즉, 코드 유지보수 비용 vs. 조직간 communication / 조율 비용. 에서 내가 경험한 대부분의 회사에는 개발자들이 후자를 택하게 된다.

그런데, 향후, fork된 코드간 Gap이 커지고, 다양한 fork가 추가적으로 계속해서 이루어지는 과정이 진행되게 마련이다.
그리고 어느 순간, 각 개발자들 입장에서는 여전히 위의 선택(code fork)이 유효하겠지만, 조직(회사) 전체로 놓고 보면 코드 유지 보수 비용이 조직간 조율을 위한 비용을 현저하게 넘어서게 된다.
이때가 되면, 문제를 인지하고, 코드를 정리하는 과정을 거치게 되는데, 이미 refactoring debt 로 인해 상당한 비용을 지불해야할 상황이 된다.

위와 같이, 별도의 조치가 없다면, 결국 조직 혹은 협업의 문제로 인해, 코드 중복은 자연스럽게 발생하게 된다.
그리고, 대부분의 경우, 뒤늦은 refactoring으로 인해 많은 비용을 지불하게 된다.(refactoring debt)

이 문제를 해결하기 위해서는, 결국 중앙 집중적인 의사결정 기구 및 monitoring 기구가 필요하게 되는데, 이 역시 쉽지 않다.
신속하고, 때로는 강력하게 의사결정을 해 나가더라도, 다른 개발자들이 이를 존중해 줄 수 있어야 하는데... 이게 쉬울 리 없다...ㅜ.ㅜ

이상이, 내 개인적인 "문제에 대한 진단" 이다.
해결책은... 각 회사/조직/집단 의 상황에 맞게 알아서 잘~~~



+ Recent posts