[2021.SHB] 개발단계 - 퇴보하는 프로젝트

프로젝트 일지

2022.02.28 개발단계

퇴보하는 프로젝트

 

 

프로젝트의 기본 전제중 하나는 "화면은 그대로 유지한다" 였다.

프로젝트에 합류해서 그 말을 들을 때만해도 "아! 화면은 크게 신경쓰지 않아도 되겠구나" 라고 생각했다.

 

As-Is의 온라인이 Pro*C로 되어 있었고, To-Be는 Java F/W으로 변경되기 때문에

이 부분을 어떻게 처리할까? 라는 것에 포커싱이 잡혔다.

 

그런데...!

EIMS라는 전문관리시스템이 도입되며, 거래transaction 전송방식이 변경되었다.

프로젝트가 차세대이다 보니 어쩔수 없는 부분이라 생각했다.

※ EIMS : Electroic Interface Management System

 

But...

화면은 JavaScript기반의 툴을 사용하고 있는데, 툴에서 사용하는 API가 변경이 되었다.

UI 솔루션의 버전version이 변경되면서, API명이 바뀌어 버린 것이다.

이게 말이 되는가?!

※ API : Application Programming Interface

 

이 것만이라도 충분히 황당한 상황인데, 오늘 새로운 이슈issue가 발생했다.

어찌보면 이 이슈는 예견된 이슈가 아니었나 생각된다.

 

화면의 n개의 조회 거래가 있다면, 이것을 '하나의 전문'으로 통신을 한다.

이 거래들 중 거래마다 그리드grid를 각각 사용하고 있다면

A거래시 조회된 데이터가 B거래시 서비스에서 빈값을 리턴받기 때문에 모두 지워진다.

※ 솔루션 특성상 전문과 컴포넌트들을 매핑하여 사용한다.

   리턴값이 비어서 넘어오는 그리드는 빈값으로 재매핑되어 데이터가 삭제되어 버린다.

 

차세대를 제안하고 솔루션을 도입하면서 검토가 안됐던 것 같다.

As-Is에서 사용하던 거래방식 및 구조를 충분히 이해하고, 이를 수용해야 하는데

검토가 이뤄지지 않아, 결국 개발단계에서 이슈가 된 것이다.

 

솔루션 업체는 As-Is와 To-Be의 처리방식이 다르기 때문에 수용이 불가하다 한다.

결국 개발자가 "알아서, 잘" 개발을 해야 하는 것이다.

이 때 따른 개발가이드도 명시되어 있지 않다. 아예 검토나 고려를 안한 것이다.

 

모든 것을 사전에 예견하고 준비할 수 없기 때문에 어쩔 수 없는 부분들이 있다.

그렇다면, 지금이라도 빠르게 검토하여 표준을 정하고 가이드를 해야한다.

그런데, 결정을 해야 할 윗 분들은 '모르쇠'이거나 '나만 아니면 돼'하고 한발 물러서 있다.

또 일부는 개발자가 '알아서, 잘'해야 한다고 생각하는 듯 하다.

 

처음 프로젝트에 합류했을 때, 거래를 묶지 말고 분리하자는 의견을 개진했었다.

물론, 기각 당해서 지금에 왔지만...

 

프로젝트라는게 정해진 기간에 원하는 결과를 이끌어 내어야 하는 것이므로

공수와 일정은 굉장히 중요하다.

초반 공수 산정시 기본적으로 고려되었어야 할 이런 부분이 검토되지 않은게 너무 아쉽다.

화면을 '유지'라 하여 공수도 최소화하여 일정을 잡은 것 같은데...

이런 이슈로 일정은 지연되고, 안 그래도 빠듯한 공수인데 '유지'가 '개편'이 되면서 기하급수적으로 일정이 늘고 있다.

 

프로젝트를 수행하며 경력이 쌓이고 노하우가 쌓여 점점 발전을 해야 하는데...

이상하게 퇴보한 이 상황은 무었을까...

 

결국 이슈를 "어떻게?" 해결할지는 결정되지 않고, (결정자가 의사결정을 해야 하는데...)

개발자끼리만 이런 저런 방법론을 거론하다가 끝이났다.

어차피 현재로써는 안되니, 도가 됐던 모가 됐던 빨리 의사결정해서 방향성을 확정 지어줬음 좋겠다.