프로젝트가 오랫 동안 진행되고 소스 코드가 어느 정도 안정화 되다보면,
비슷한 유형의 다른 새 프로젝트를 시작하는 경우가 흔히 있을 것이다.
사실 내가 처음 입사했을 때, 왜 그렇게 비슷비슷한 제품들이 많은 지 이해할 수 없었다
겉보기만 해도 다 비슷해 보이고 이름도 숫자 한 두 자리 다른,
내가 보기엔 하나같이 같은 것들이었는데 그 종류가 무려 10가지가 넘었던 것 같다.
약 1년간 이쪽 문화에 젖어 살다 보니, 저절로 그 이유를 이해하게 되었다.

쉽게 말 하자면, 500원짜리 새우깡, 1000원짜리 새우깡이 따로 있는 이유이고,
매운 새우깡이 새로 나오게된 배경과 비슷한 경우라고도 할 수 있다.
그만큼 시장의 요구는 다양하다는 의미가 되겠다.

하지만 덕분에 프로그래머들은 그러한 미묘한 고객의 요구 사항들을 다 들어 주기에
골치가 이만저만 아픈 게 아니다.

사실은 브랜치 이야기를 하려다 너무 거창해 버려서, 이 이야기는 못 할 것 같다 -_-;

아 과장이 좀 심했다. 물론 실제로 내가 말들고 있는 제품이 걸레가 되었다는 뜻은 아니다. -_-;;
하지만 점점 괴물같이 되어가는 코드를 보면서 우리 스스로도 혀를 내두를 정도이다.
단순히 소스 코드가 길어진다는 문제가 아니다.
간단한 코드는 #ifdef #endif 따위로 별 부담 없이 처리 할 수 있지만,
이런 것들이 점점 많아지면 파일 단위, 디렉토리 단위로 구분해 주어야 하며
최악의 경우 결국 별도의 브랜치가 만들어 지기도 할 것이다.
이때부터 소프트웨어 오류는 엄청나게 증가하게 될 것이다.

한 브랜치에 버그 수정을 한 것이 다른 브랜치에 적용이 되지 않는 실수도 생기고,
엉뚱한 소스가 들어가는 경우도 생기고,
소스가 뒤바뀌는 경우도 드물긴 하지만 생기기도 한다.
아무리 신경써도 이런 일들은 쉽게 처리되는 문제가 아니므로 프로그래머의 사기는 떨어질 것이다.

ODM 생산을 해야 하는 나의 직장에서는 이런 실수가 있었다.
심지어 커널 소스가 관리 되지 않아 엉뚱한 디바이스 드라이버가 들어가
제품이 오작동 하는 일도 있었다. 이런 문제는 쉽사리 원인파악도 힘들다.
처음 이 문제를 발견했을 때, 이런 원인일 거라고는 전혀 상상하지 못 했다.
단순한 소프트웨어 관리 상의 문제이긴 하지만, 프로그래머들은 당연히
소스부터 들여다 보거나 디버거를 돌릴 것이기 때문이다.
물론 나같은 풋내기보다 좀 더 경험이 많은 뛰어난 인재라면 1분 정도 곰곰히 생각하다가
'아하!'하고 금방 원인 분석을 해 낼지도 모르겠다 -_-;;