공유 되어야한다.

공유 되어야한다.

 적어도 서비스가 확대되고, 성장하기를 원한다면...

 아주 예전에 코볼이였는지 스칼라였는지 정확하진 않지만 내가 잘 모르는 언어로 개발된 코어한 모듈이 존재 하고, 그 모듈로 만들어진 DB를 사용하여 JAVA로 구현된 서비스가 있었다.

 JAVA로 차세대를 하면서 왜 해당 모듈은 전환 하지 않았을까란 생각을 해 본적이 있다. AS-IS소스를 분석해서 JAVA로 변환 하는 작업의 어려움 때문이였을까? 시간이 많이 걸리기 때문일까? 라는 생각을 한 내가 너무 순진 했다는 사실을 알게 되었다. 나중에 안 사실이지만 정말 간단한 문제 였다.

 새로운 언어로 전환 되면 기존에 모듈을 담당하시던 분의 수익원이 없어 지는것.... 단지 그 것 뿐이였다. 나이가 많으셨던 그 선배 개발자는 새로운 언어로 바꿀 생각이 없었기 때문에 바꿀 준비를 전혀 하지 않았다. 새로운 언어로 바꿀 필요가 없었으니까.......새로 바꿀려면 공부 해야 했으니까....

 후에 내가 본 AS-IS소스는 굉장히 길었다.. 그리고 무수하게 박혀 있는 하드코딩들......논리적이지도 고성능을 발휘 할 수도 없고, 객체화 되거나 추상화 되어 있지도 않았다. 10년 이상 한 명의 담당자가 계속해서 수정해오고 기능을 추가 해 오면서 그 담당자가 아니면 유지보수가 거의 불가능 할 정도로 복잡해져 있었다. 직관적인 변수명, 메소드명이냐 아니냐?는 그 담당자에게 익숙한 형태이냐 아니냐의 문제였다. 처음 보는 사람은 네이밍 규칙부터 파악 할 수조차 없었다. 모두 비슷한 이름에 1,2,3이 붙어 있는 방식에.... 그런 코드들이 정의된 문서조차 없었다.

 최근에도 비슷한 상황을 몇번 겪었다. 주로 연차가 오래 되신 선배 개발자 분들이 이런 상황을 자주 만들어 낸다. 코어한 모듈을 본인만 갖고, 팀원들에게 공유 하지 않으며, 폐쇄적인 관리로 본인의 영향력을 유지 하려 한다. 그리고 이슈가 발생하여도 몇 십만 라인짜리 소스 분석 할 수 있겠냐며 본인이 계속해서 잡고 있다. 그리고 몇 일, 몇 주가 이 걸려 이슈가 해결 되면 결국 본인이 아니면 누구도 해결 할 수 없었다는 듯이 말한다. 하지만 근본적인 문제가 해결 될 리가 없다. 추상화건 객체화건 몇십만 라인짜리 소스를 바꿔서 개선 할 의지는 전혀 없기 때문에...  if와 하드코딩 몇줄이면 당장 시스템이 동작하는데에 이상이 없기 때문에... 

 결국 문제가 발생하면 그 사람만을 찾게 된다. 휴가 중이면 전화 한다. 그리고 그 담당자는 투덜 투덜 대지만 그 것을 즐긴다. 나 없으면 안돌아간다는 자기만족을 하면서....... 결코 누구에게도 인수 인계 하려 하지 않는다. SVN이건 GIT이건 버전관리하려고도 하지 않는다.. 그래야 본인의 입지를 유지 할 수 있으니깐...

 결국은 이런 서비스는 성장을 하면서도 해당 담당자를 모두 어려워 한다. 심지어 임직원 조차도 그 사람이 퇴사 하진 않을까? 전전긍긍한다. 그리고 능력을 인정받아 관리자가 된다. 그렇지만 관리자로써의 프로젝트 관리 능력을 보여 줄 의지가 없다. 어차피 본인만의 무기를 가지고 있기 떄문에...........

 서비스가 성장 하기위해서는 사람이 아닌 프로세스로 서비스가 개발되고, 유지보수 되어야만 한다. 시행착오를 겪을 지라도 몇몇 사람에 의존적인 부분은 반드시 개선을 해야만 한다.