위기나 난관을 헤쳐나가는 데, 여러가지 방식이 있고 사람들은 그들만의 최적화된 방식을 찾고 그것대로 헤쳐나가곤 한다.
스필버그형이 감독을 맡은 영화 ‘인디아나 존스 시리즈’에서의 주인공인 인디아나는 대학에서 고고학을 전문으로 한 교수(학자)이며, 프로 도굴꾼이기도 하다. 그의 방식은 일단 유물이 있는 유적지로 탐사를 떠나 주변을 탐사하고 직접 혈혈단신으로 유적지의 함정들을 돌파, 악당들을 물리치는 액션활극을 펼치며 원하는 유물을 쟁취하고 탈출한다.
주인공인 인디아나의 액션활극만을 보고 즐기자면 뭐 신나고 재미있을 뿐이지만, 그가 걸어온 흔적들을 보고 있으면 유적지는 파괴되고 유물들은 유실되며 지키는 자들은 대부분 요단강을 건너버리고 만다.
IT가 주요 메인인 소규모 업체에서 이런 일들은 비일비재 하게 일어나는데, 그에 대한 내용을 써보고자 한다.
사례 1.
한 작은 동네 학원이 있다. 교육쪽에 꽤 작은 성공이 있었고, 그를 기반으로 교육쪽 IT 사업을 해보고 싶어 여러 업체과 대표들을 만나, 이런저런 조율을 하고 난 후 결심이 서서 한 SI 업체와 프로젝트를 진행하려 했다.
그 SI 업체는 한 때 꽤 큰 규모의 프로젝트를 성공시킨적이 있고 지금도 그런 노하우가 충분히 있긴 했지만, 최근 자금난에 빠져 Core 한 개발인력들이 죄다 빠져버려 새로 성장하기 위한 동력을 찾고 있을 때 위의 프로젝트를 맡아 진행하기로 한다.
당장 프로젝트를 진행할 코어(Core) 인력들이 없었으므로 구직사이트를 통해 인디아나존스를 영입했다. 그의 기록을 화려했고, 진행된 프로젝트들중 SI 쪽 일도 어마어마 했기 때문에 대표입장에서는 이만큼 좋은 사람은 없다고 생각했다.
인디아나존스는 그렇게 채용이 됐고 프로젝트에 관련된 SW는 그양반 마음대로 해도 된다고 협상이 되어 일이 진행이 되고 있었다. 프로젝트 기간은 6개월이었으며 1개월 내에 결정될 기획이 질질끌고 늘어져 2개월동안 진행이 됐고 그만큼 개발시작이 늦어지기는 했지만, 인디아나 존스가 기획때부터 참여를 했기 때문에 충분히 개발기간을 조정 할 수 있을거라 대표는 믿었다.
프로젝트 기간 5개월 즈음 (실제로 코딩이 들어가기 시작한지 3개월 때) 실제 개발사항을 학원관계자에게 시연을 하게 됐는데, 굉장히 말끔하게 잘 진행이 됐다. 하지만, 학원관계자의 의문하나에 SI업체 대표는 억장이 무너지는 개발자의 답변을 듣는다.
학원 : “네 학원 홈페이지 디자인 변경이나 외관은 잘 봤습니다. 그런데 회원관리나 문제은행 기능은 아직 못본것 같군요. 그것을 보았으면 합니다.”
인디아나존스 : “네 그부분은 아직 시작 안되었습니다.”
학원 : (?! 다음달 까지 완료인데?) “기간내에 가능할까요?”
인디아나존스 : “그것에 대해서는 대표님과 조율해서 말씀드리겠습니다.”
아니 이게 뭔 X소리인가!!! 어떤 프로젝트든 가장 중요한 뿌리에 해당하는 데이터를 설계한 이후에 나무가지를 하나씩 붙여야 하는 방식이 정석인데, 단순히 보여주는 부분이 개발되지 않았다 수준이 아니라 계획조차 성립되지 않았다니…
물어보니 인디아나는 당장 눈앞에 학원관계자의 시연이 더 중요했었기에 그것 먼저 개발을 시작한 것이었다. 물론 그것의 반응이 좋아야 다음 개발이 가능할거라 스스로 생각했으리라…
어쨋든 상황이 이렇게 된것에 일정을 조율해 보니 3개월 정도 더 소요될 것이라 결정됐고 그에 맞추어 보조해줄 프로그래머를 새로 구하게 된다.
근데 이게 왠일?
새로운 프로그래머가 소스나 기획문서등을 본 이후 입사를 취소 요청하게 된다.
그의 왈
“아무리 개발기간을 줄이거나 속도 혹은 개발자 수급을 용이하게 하기위해 PHP를 이용해서 개발한 것은 이해가 되지만, 지금 개발된 기반은 제로보드라고 하는 웹 게시판 시스템이다. 이것으로 스킨, 회원 시스템은 개발하기 용이했을지 모르나 문제은행이나 교육 컨텐츠를 운영하기에는 말도 안되는 선택이다. 난 이 프로젝트 맡을 수 없다.”
“게다가 기획문서 라고 하는 문서는 1버전이고 구두로만 10버전 이상 진행된 상태인데 그것을 일일이 기존 개발자에게 물어봐서 하는것도 말이 안되고 정작 그 개발자는 본인이 하는 파트 말고는 기억이 확실하지 않다. 문제가 발생하면 그때그때 학원관계자와 구두로만 협의하면서 진행했다고 하는데 이건 상식적이지 못하다.”
뒤를 이어 채용한 프로그래머들도 거의 다 비슷한 의견으로 입사를 취소하거나 프로젝트를 거부하기 시작하면서 결국 이 프로젝트는 흐지부지 되고 말았다.
인디아나 존스는 그 회사의 프로젝트를 완성시키지 못했지만 본인의 이력에 SI 프로젝트 참여 라는 글귀를 남기는 데 성공했다.
사례 2.
IT 플랫폼 기반 사업을 하려는 스타트업에서 초기 기획단계의 프로토타입 개발을 외주 SI에 맡겨 진행했다.
운좋게 성실한 외주업체였고, 시장반응은 좋았으며, 투자를 진행하는데 있어 내부 개발팀이 필수였기 때문에 CTO 급 개발자를 채용하게 된다. 이 CTO 급 개발자인 인디아나존스는 한 회사에 굉장히 오래 근무했고 특정분야에 매우 많은 지식을 가지고 있었으며, 주로 관리직으로 종사했던 덕에 많은 인적 네트워크를 보유하고 있었다.
다만, 이 CTO 는 관리직보다는 현장에서 직접 프로그래밍을 하고 싶어하는 욕구가 강했고 그동안 쌓아오기만 했던 최신예 플랫폼들을 들여오고자 했다.
기본적으로 JAVA와 PHP로 구성된 기존 플랫폼을 Rust 혹은 Go로 컨버전하길 원했다.
기존 임원진들은 IT 기술에 대한 내용을 잘 모르기도 했지만, 최신예 언어이고 구글 등 인터넷 공룡들이 지원하는 언어라는 말에 CTO에 대한 믿음이 높아지면서 개발분야에 관련된 내용은 전적으로 일임하게 된다.
하지만 이 인디아나존스가 그토록 하고 싶어했던 새 플랫폼은 미처 실무에 적용해본적이 없었고, 실무에 적용해본적이 없는 만큼의 시간을 시행착오로 소모하게 된다.
기존에 채용했던 엔지니어들은 본인의 경력과 숙련도를 멀리한채 새로운 플랫폼을 익히는데 시간이 더 들었으며, 당면한 눈앞의 과제마저 수정하는데 오랜 시간이 걸리는것을 보고 포기하여 퇴사하게 된다.
새로운 인력을 추가하고 싶었지만, 라이브러리나 정보가 범용적으로 쓰이지 않는 플랫폼이기 때문에 아무리 업계에서 높은 수준의 연봉을 제시한다고 해도 리스크를 안고 도전을 할 사람은 많지 않았다.
결국 수급되지 않는 인력과 이미 저질러 놓은 컨버전작업들 그리고 당장 본인의 일에 급급한 인디아나존스만을 남긴 프로젝트는 지지부진해 가고 있다. 본인의 사소한 욕망을 실행하기 위해 하나의 거의 완성된 환경을 깨부수는 그의 모험은 아직도 진행중이다.
사례 3.
직원수 100명에 개발팀 10여명을 둔 한 회사의 대표가 골머리를 썩히고 있다.
여러개의 웹서비스를 구축하여 운영하고 있는 회사에서 꼭 3개의 웹서비스만 고질적인 문제점이 발생이 되고 있는데, 이렇다할 방법이 없다. 그 문제가 되는 서비스를 개발 담당자인 인디아나존스는 할 말이 많다.
“혼자서 이 3개의 서비스를 이 정도까지 운영한게 쉬운 줄 아느냐. 나를 대신할수 있는 사람을 구할 수 있다면 쿨하게 정리하고 나가 주겠다.”
분명 틀린말은 아니었지만, 그에게 직원을 2명 붙여주고 난 이후에도 그 상황은 변하지 않는다. 그가 팀원으로 소속되어 업무를 분배하거나 분배받아 본 적이 없기 때문에 붙여준 2명의 직원은 일을 진행하는데 있어 그다지 큰 도움이 되지 않았기 때문이다.
하지만 대표입장에서 이런 방식으로 상황을 질질끌고 갈수는 없기에 결단을 내린다. 어느정도 시간과 비용이 소모되기는 하겠지만, 문제가 지속되고 있는 서비스 3개를 다른 담당자에게 맡기기로 한 것이다.
자연히 그 인디아나존스는 스스로 회사를 떠나게 되는데, 진짜 중요한 이야기는 지금부터 시작이다.
그가 떠난 자리에 새로 업무를 부여받은 ‘머트 윌리엄스’는 난감한 상황에 빠져있다. A, B, C 서비스의 고질적인 문제를 찾았기 때문이다. (문제를 찾았는데, 왜 난감하냐고?) 고질적인 문제를 쉽게 설명하자면 3개의 서비스가 하나의 데이터에 종속되어 사용되어 지는데, 그 데이터의 형식을 A 형식으로 바꾸면 B 서비스에 문제가 되고 B 형식으로 바꾸면 C 서비스에 문제가 되고 C 형식으로 바꾸면 A 서비스에 문제가 되기 때문이다.
한마디로 문제가 제기될때마다 저런식으로 땜빵을 해 가면서 위기를 헤쳐나갔고, 셋다 완전히 안되는 것은 아니었기에 그날그날 위기대처만(땜빵) 하고 넘어갔던 것이다. 가장 근본적인 문제인 저 종속된 데이터의 형태에 대해 문제를 해결하지 않고 있었던 것이다.
머트 윌리암스는 ‘세상에 이런 개발자도 있구나’라고 생각하며 개똥같은 버그정글 숲을 헤멘다. 저런 버그 아닌 버그솔루션이 하나뿐이 아닐 것은 이미 예상을 했기 때문에…
위 3개의 사례를 통해서 ‘인디아나존스’ 형태의 개발자의 문제점을 짚어보자면
1. 범용적으로 사용되는 개발 플랫폼을 인정하지 않는다.
왜 이런 형태로 개발됐는지에 대한 고민을 하지 않는다.
2. 팀웍 보다는 개인플레이에 더 최적화 되어 있다.
혹은 팀워크 업무를 진행해본 적이 없다.
3. 오늘의 문제는 오늘 해결하고 내일의 문제는 모르겠다.
근본적인 문제 해결을 등한시 한다.
이외에도 많은 점을 지적하고 싶지만, 사례를 통해 나온 큰 문제점은 위 세가지로 나눌수 있다. 여러 개발 소프트웨어 플랫폼들로 개발이 되어지고 있고, 그것들은 각각의 매우 다른 특성. 즉, 장단점이 존재하여 그에 맞는 선택을 하는 것이 개발자 혹은 설계자에게 있어서 매우 중요한 요소다.
그 장단점에는 서비스의 확정성이나 퍼포먼스가 어떤 상황에서의 유불리의 판단의 기준이 될 수도 있고, 관련 라이브러리나 인터넷상에서의 정보를 취득하기 편하다는 이유일수도 있으며, 전문으로 하는 종사자들을 쉽게 채용할 수 있다라는 점도 큰 이유가 될 수 있다.
이러한 특성과 장단점이 맞물려 서비스가 개발되고 팀웍이 조성되며 하나의 회사 시스템이 구축이 되어져야하고 되어져 왔지만, 개개인의 잘못된 판단과 욕망과 충분하지 않은 이해를 바탕으로 눈앞에만 보이는 혹은 존재하지 않을지도 모르는 무언가를 얻기위해 최단 루트를 달리면서 분명 존재 이유가 있을 벽과 object 들을 파괴하며 내달린다.
