IT 프로젝트 모집공고 수정해 보기 #8

원래 이 글을 연재하기로 한 동기는 고객과 개발자(사) 사이에 서로 오해할 소지가 있는 프로젝트 모집공고를 나라면 이렇게 쓰겠다는 컨셉으로 시작했습니다. 그런데 여러 공고들을 리뷰하다 보면 아직도 이런 일이 벌어지고 있구나 하는 생각이 들어 고개를 절래절래 흔들 수 밖에 없는 경우가 있습니다. 주먹구구 식으로 어떻게든 프로젝트를 수주해서 돈을 벌어보겠다는 SI 업체들이 난립하던 때에는 별의별일이 다 있었습니다. 이후에 똑똑하신 분들이 프로젝트 관리라던지 개발 방법론 등을 현장에 잘 적용하신 것으로 생각했는데 이런 일이 아직 있네요.

좋은 이론을 현장에 적용하는데는 인내와 비용이 많이 들어갑니다. 그래서 보편화 되기 힘든 이유가 아닐까 생각이 듭니다. 그래서 많은 개발자들이 소위 '네카라쿠베당토'라는 메이저 업체에 입사하고 싶어하는 이유가 되고 재수를 해서라도 인-서울에 있는 학교에 들어가려는 이유가 되겠죠.

---

<프로젝트 개요>

 

프로젝트 소개:

업무시스템을 만들고 있습니다. 기존에 운영 중인 CS환경의 업무시스템을 클라우드웹 환경으로 변환하여 적용하는 작업입니다.
어떤 업무에 사용되는 시스템일까요? 아래 내용으로 유추해 보건데 ERP가 아닐까 생각이 듭니다. 2000년대 IT버블 시대에 인트라넷으로 시스템을 교체하는 것이 붐이었습니다. 회사에 PC가 하나 늘어나면 라이선스를 하나 더 구입해야하고 어플이 업데이트 되면 모든 PC에서 다 다시 인스톨을 해야되던 때가 있었습니다. 웹이 보편화되고 웹 인터페이스를 통해 레거시를 구축할 수 있다는 말에 많은 기업들이 인트라넷으로 컨버전을 시도했습니다.

 

프로젝트 진행 상황:

• 95% 개발이 완료되었고, 다음 달 오픈을 위해 QA 및 보완개발을 하고 있습니다.
  95% 개발이 완료된 프로젝트에 결원으로 인한 인원보충은 아직 할 일이 많이 남았다고 해석이 됩니다.
  개발 막바지에는 필요 인원을 제외한 개발인원은 한명씩 이탈하는 것이 고객의 비용면에서도 회사의 사업을 위해서도 유리합니다.
• 오픈 후에는 다국어 개발이 예정되어 있습니다.

 

전체 시스템 구성:

• AWS, web, java, springboot, git, mysql
  아래와 같이 수정해보겠습니다.
• AWS
• Web(Java, Springboot)
• MySQL

 

전체 프로젝트 일정:

1. 전체 프로젝트 일정:
   
   • 지난해 1월부터 개발을 시작해서 12월 말까지 500페이지 정도를 개발했습니다.
     웹인터페이스로 500페이지면 엄청 많은 양 입니다.
   • 지난해 12월 오픈 예정이었으나, 현업의 요청으로 페이지를 수정/보완하여 2월 23일 오픈 예정입니다.
     오픈 1개월 전이면 통합테스트를 진행하면서 버그 수정을 해야할 시기 입니다. 자질구레한 UI를 수정하고 레거시에서 데이터를 어떻게 옮기고 오픈 스케줄을 잡을 시기에 개발 인력을 채용하는 건 리스크가 매우 커보입니다.
   • 이후 다국어 형태로 추가/변경하여 5월 말에 추가 오픈하고 6월까지 마무리하는 일정입니다.
     다국어 형태로 추가/변형 하는 것도 개발이 들어가야 할 일로 보입니다.
2. 인터뷰 및 계약 일정: 적합한 지원자 발생 후 인터뷰 진행, 2~3일 이내 계약 여부 공유드릴 예정입니다.
3. 계약 진행 프로세스: 프로젝트 지원 > 실무진 인터뷰 (코딩 테스트 x) > 계약 결정

 

 

<상세 업무 내용>

 

모집 인원 :

• 경력 5~9년 차 1명 (650~750만 원)
  범위가 크네요... 5~9년차면.

 

상세 업무 :

• 기존 공통 + 업무를 담당하시던 개발자분이 오픈이 연기되면서 다른 프로젝트로 이동하셨습니다.
  아마도 "공통"이라는 부분은 각 "업무" 모듈에서 공통으로 사용하는 모듈을 이야기하시는 것으로 추측합니다.
  "공통"모듈 작업을 하던 개발자라면 개발팀장 정도를 채용하고자 하시는 것으로 보입니다.
  
• 기존 개발하던 업무를 분석/개발하고, 공통부분을 보완하시며, 성공적인 오픈을 함께 진행하시는 업무입니다.
  이전 개발자에게 인수인계를 받을 수 없는 상황으로 해석됩니다.
  오픈이 연기되서 다른 프로젝트로 이동했을 뿐인데 인수인계가 안된다면 참 난감한 상황이 아닐 수 없습니다.
• 오픈 후에는 6월까지 다국어 페이지로 개발하는 업무입니다.

 

필수 기술:

• Aws, web, java, springboot, 이클립스, github, bootstrap, adminLTE, Readgrid
  이클립스???요즘엔 IntelliJ쓰던데...
  AdminLTE???

 

자격 요건 :

• Springboot 공통부분 개발경험, 대규모 사이트 오픈경험, java/spring, redis, mysql
  이 부분이었네요... 공통 모듈 개발경험이면 최소 팀장급 이상이었을텐데
  공통부분을 개발하려면 전체 시스템의 아키텍처를 머리 속에 외우고 있어야 한다는게 제 생각입니다.
  그러기엔 인건비를 너무 싸게 잡으신게 아닌가...예산이 이미 초과되신게 아닐까...

---

프로젝트에 상황에 대해 경험에 비추어 소설을 써 보겠습니다.

이 글을 작성하신 고객의 고객, 이제부터 대고객이라 부르겠습니다.
대고객은 기존 레거시 시스템을 업그레이드 해야할 필요가 발생했습니다. 사유는 아마도 해외 지사 또는 대리점의 설립이 아닐까 합니다. 그런 사유로 로컬에서 구동되던 ERP(아마도?) 시스템을 해외에서도 접속할 수 있도록 해야하고 CI/CD 측면에서도 C/S가 아닌 Web 기반 시스템이 유리하다 판단하셨을 것입니다. 
대고객께서는 이미 개발해 놓은 레거시가 있기 때문에 웹으로 컨버전할 수 있는 개발사만 있으면 되겠다고 생각하셨습니다. 어찌저찌 개발사를 구하고 레거시를 분석합니다. ERP라는 어느정도 정형화된 레거시에 대한 경험이 있는 개발사였을 것 입니다. 

그런데

ERP같은 대규모 시스템을 구축할 때는 디테일한 분석과 기획과 그리고 '낙장불입'의 정신이 필요합니다. 분석된 결과를 가지고 대고객과 협의가 끝나면 '낙장불입'으로 도장을 받아야 합니다. 그리고 무슨 일이 있어도 '그' 개발이 끝나기 전에는 바꾸거나 추가하면 안됩니다. 변경에 대한 관리를 철저하게(?) 굳건하게(?)하지 않으면 삐끗! 하는 순간에 프로젝트는 안드로메다로 갑니다.

PM은 고객과 밥먹고 술먹고 회의하고 하기 보다는 매일 커밋되는 소스를 적용해서 매일매일 QA를 하고 개발팀에 피드백 보내야 합니다. 단위 테스트가 통과되지 않으면 다음 개발을 시작하지 않아야 합니다. 그런 관점에서 보면 위에 기술한 프로젝트 '필수기술'에 없는게 Jira나 슬랙, 팀즈 같은 협업툴 사용 경험입니다. 작업 스케줄 관리, 문서 작성 등등을 개발 완료 이후로 잡으셨다면... 올해도 수고 많으시겠습니다.

다국어 페이지 관리는 어떻게 하실 것으로 기획했는지 궁금합니다...

 

이 소설을 '해피엔딩'으로 결말을 잡으면 천재적이고 능력이 출중한 새 개발자를 뽑아서 한 달정도 연기된 후에 마무리 짓는다가 될 수 있겠죠. 하지만 천재적이고 능력이 출중한 9년차 개발자가 1개월 750만원에 1년짜리 프로젝트를 마무리하러 들어올지가 의문입니다.

'새드엔딩'으로 결말을 잡으면 스프링을 해본 자바개발자가 750만원을 노리고 들어와서 매일 야근과 철야를 반복하다가 3개월 연장끝에 오픈을 합니다. '워스트'는 말씀드리지 않겠습니다. 아무튼 개발사 입장에서는 벌써부터 손해가 이만저만이 아닐 것 같습니다. 최악의 경우에 대한 시나리오를 미리 준비 하시는 것도 어느 정도 충격에 대한 대비는 될 것으로 생각합니다.

 

앞서 말씀드린 바와 같이 ERP는 꽤 정형화 된 레거시 입니다. 그래서 SaaS 형태로 서비스 하는 회사들도 많이 있습니다. 그래서 어쩌면 이 프로젝트의 개발사는 이미 Web(Java)기반의 ERP code 뭉치를 갖고 있었을 수도 있겠습니다. 여기서 문제가 발생합니다.

 

다른 글에서도 많이 말씀드렸지만 고객과 개발사 사이에 소통이 무엇보다 중요합니다. 그런데 ERP라는 공통 주제를 놓고 유창성 효과에 빠졌을 것 같습니다.

'그거 아시죠?'

'아 네! 그럼요. 저희 이미 갖고 있어요'

'오 그럼 시간이 많이 단축되겠네요. 이런기능도 있나요?'

'그럼요~! 식사하러 가실까요?'

유창성 효과는 '나는 이미 알고 있고, 나는 그걸 할 수 있다'는 착각에 관한 내용입니다. 거기서 빠져나오는 방법은 실제 해보면 된답니다.

그런데 이렇게 큰 일을 준비도 없이 부딪히는 건 무모하고 비용이 많이 듭니다.

 

고객의 요구사항을 하나하나, 작은 것 까지, 꼼꼼하게 확인하고 전체 그림에 대해 고객을 이해시키는 것이 프로젝트를 '혼돈의 카오스'로 빠드리지 않는 가장 좋은 방법입니다.