L-Hotel 프로젝트 복기

2020년 마지막 프로젝트를 마쳤다. 어려운 프로젝트들이 많았지만 이번엔 좀 특별했다. 프로젝트를 마치고 나오면서 작성한 글의 백업을 잊고 포맷해버려서 애써 작성한 글이 날아갔다. 아쉽지만 그래도 내가 목표한 일이기에 간단하게나마 다시 작성한다.

요구사항 - 개선요건의 프로젝트는 요건을 확실하게 짚자

이번 프로젝트의 목적은 UI, UX 개선이었다. 프로젝트 투입하기 전에 들었던 업무 내용은 단순했다, “그냥 간단한 화면 UI(디자인) 변경만 있을 거야” 정확한 프로젝트의 목적과 요건은 모른 채 프로젝트에 투입이 됐고, 내부에선 모 컨설팅 업체가 UI, UX 컨설팅을 먼저 진행하고 기획, 디자인을 담당했다. 컨설팅을 위한 것이었는지 잘 모르겠지만 프로젝트의 요구사항에 대한 내용이 없어 보였다. 실제로도 관련 문서가 없었고 화면 설계만 보고 개발을 진행했다. 요구사항에 대한 내용을 파악하지 않은 나비효과는 엄청났다 다음엔 반드시 정확한 요구사항을 짚고 넘어가야 한다, 요구사항 관련 문서가 없다면 문제를 제기해야 하고 문제가 되지 않는다면 요구사항에 준하는 문서를 근거로 잡아야 한다. ex) 화면 설계서?, 개발을 할 땐 기준이 필요하고 그 기준은 화면 설계서나 SB지만 그 문서들이 정답은 아니다. 요구사항 관련 문서를 파악하자.

개발환경 - 처음 경험하는 환경은 지향하자

개인적으로 처음 경험하는 개발 환경(언어, 프레임워크)으로 진행하는 프로젝트는 지향한다. 과거 ExtJS로 고생했던 경험 때문인데 이번엔 어도비의 AEM이었다. AEM 관리자의 일부분이 ExtJS로 구현되어있어서 옛 생각에 좀 반가우면서 불안했고 결과는 역시 처음 경험해보는 환경의 프로젝트는 좀 더 보수적으로 지향해야겠다. 기본적인 문법도 모른 채 학습도 없이 기존 소스만 참고해서 업무를 진행하는 건 고객에게도 민폐 나도 고통스럽다.

History - 모든걸 기록하자

회의록, 업무일지, 업무 내용 등 구두로 오가는 모든 내용들을 기록하자. 업무 내용을 구두로 전달받았다면 정리해서 메일로 보내든 메신저로 보내든 재확인하고 그걸 이력으로 남기고 기록하자. 최소한의 개인적인 방어 행동이고 훗날 일어날지도 모를 상황에서 근거가 될 수 있다. 개발자는 최후방 전선이고 우리도 모르는 사이 그리고 어쩌면 상대도 모르는 사이에 발생한 또는 준비된 융단폭격의 제일 큰 희생양이 될 수 있다.

일정관리 - 어필 하자

이번 프로젝트에서 기획 전체 일정이 2달 정도 딜레이 됐다. 다시 생각해보니 말도 안 되는 상황이다. 나와 우리(개발팀)는 조금 안일하게 대처한 거 같다. 좀 더 강하게 어필했어야 했다고 생각된다 단순하게 늘 그래 왔듯이 ‘어쩔 수 없이 야근으로 때우겠구나’라고 생각한 거 같다. 그리고 야근으로 때워서 개발 일정은 맞췄다. 경주마처럼 되어 앞만 보고 달려 개발 일정을 마무리하니 이후의 요건 변경, 수정사항, 추가사항을 유연하게 대처하기 힘들었다. 내 코드는 유연하게 대처하기 쉽도록 작성되지 않았고 고통만 늘어갔다.

데이터 - 충분한 데이터를 요구하자

처음부터 새롭게 구축하는 프로젝트가 아니라면 기존 레거시 시스템의 개발환경에 대한 데이터는 충분히 확보한 채 개발하자. 이번 프로젝트도 역시 테스트 데이터가 충분하지 않았다, 적어도 단위 테스트 시작할 때의 데이터만 미리 확보되었어도 테스트 기간의 고통은 조금 줄어들었지 싶다.

반응형 화면

가끔 반응형 화면인데 WEB, Mobile WEB 화면이 나뉘어서 구현이되는 경우가 있다. 이 경우엔 이벤트 처리를 함께 처리하겠다는 생각은 접자. 나뉘어져서 구현된 이유는 분명히 있을거고 그 나뉜 부분의 이벤트 처리를 한번에 하는건 오히려 더 복잡하게만 만들더라, 나뉘어진 화면의 이벤트 처리는 개별로 개발하자.

화면설계서 - 정답은 아니지만 기준으로 만들자

처음의 요구사항과 관련된 내용인데 화면 설계서가 정답은 아니다. 프로젝트 막바지 우리를 힘들게 했던 이유 중 한 가지가 기존에 적용된 기능이 빠졌다는 내용이다. 개선 프로젝트 특성상 화면 설계서에서 누락될 수도 있다. 누락된 기능 등은 개발자가 분석 중에 빠진 내용을 알려줄 수 있고, 확인할 수도 있다. 개발 일정이 그나마 넉넉하다면.. 개발 일정도 촉박한데 AS-IS 소스는 분석하기 힘들게 구현돼있고(Javascript innerHTML), 주석도 없고 하면 난감한 상황이 발생한다. 개발을 진행하는 문서를 기준으로 만들고 확인을 받자. 기획자에게 현업한테 컨펌을 받든 운영팀한테 확인을 받든 개발자가 개발을 진행할 때 참고하는 문서를 기준으로 만들어야 한다. 그리고 그 기준의 문서가 변경되거나 추가되는 요구사항이 발생한다면 발생한 요구사항에 대한 일정을 확보하자.

SI 개발 - 이바닥 참 힘들다

이번 프로젝트의 History를 이야기해보면 현업에서 원래 담당하던 부서가 있었지만 새로운 개혁? 혁신? 을 위해 원래 담당하던 부서가 아닌 다른 부서가 프로젝트를 진행했다. 진행하던 부서가 끝까지 진행하면 문제가 없었을 건데 개발 일정이 끝날 때쯤 그 두 개의 부서가 합쳐지게 됐고, 원래 담당하던 사람들이 프로젝트에 배정되면서 요구사항이 뒤틀렸다. 따지고 보면 개발자들이 이런 상황을 예방하거나 예측하고 일을 할 순 없다. 오랜만에 일을 미친 듯이 하면서 현타가 쌔게 찾아왔었는데 모르겠다. 제대로 큰 문제없이 재미있게 프로젝트를 진행한 게 오래돼서 그런지 가끔은 SI 개발일을 하는 게 참 힘들다. 개발자라면 SI 개발을 하지 말라는 말을 인터넷에서 쉽게 볼 수 있는데 그 말이 요즘은 많이 이해된다.