프로젝트 회고.

모든 프로젝트는 한번에 2개를 같이 하고 있을 때가 많다

1. a프로젝트: 입사하고 한 달 정도 지나 백오피스 프론트엔드 개발을 담당하게 된다. 이미 사용화 된 서비스의 백오피스를 신규 개발한다. 신입 세 명이서 나누어 개발을 했지만 전체적인 구조는 내가 잡았다. 백오피스인데 퍼블리싱 파일을 별도로 받았고 어쩐지 제이쿼리가 붙어있었다. 2~3주 소요했던 것으로 기억한다. 후에, 2회 더 수정 및 추가 개발을 했다. 자바스크립트, vue2와 vuex, vue-bootstrap으로 개발되었다. 처음부터 끝까지 70~80%의 프론트엔드를 개발했다.

2. b프로젝트: 다른 데서 외주로 개발한 cms를 받아와서 수정 및 추가 개발을 했다 vue3(options api), vuex, javascript . 단순 추가 개발건이지만 모든 동일한 기능을 페이지마다 수동으로 추가 해 주어야 했고 동적으로 추가해야 하는 항목이 복잡성이 있었고 기존 코드는 확장을 고려하지 않았다. 예를 들어, 다국어 데이터를 입력하기 위한 다국어 탭이 추가 개발되어야 했는데 언어 탭이 하드코딩 되어 있었다든가 하는 식이다. 다국어 목록을 불러오는 api라는 것은 개발 후반에 나오게 되었으며 기존 DB와 맞지 않는 기획서로 인한 어려움도 있었지만 큰 문제는 없었다. 다만 일정 막바지에 모종의 문제로 다른 동료의 개발건이 거의 전부 나에게 넘어오게 된다. 주어진 몫의 일을 빨리 쳐내도 결국 막바지엔 급해진다.

3. c 프로젝트: 프론트와 어드민의 두 쪽 다 운영 및 고도화 개발을 담당했다. 어드민은 마찬가지로 외주 개발사에서 프론트를 개발했다. 프론트는 최초 사내 신입 개발자가 입사한지 얼마 안 되었을 때 개발하고, 내가 입사 하기 전 퇴사했다. 어드민은 vue3(composition api), vuex, typescript로 개발되었으며 프론트는 nuxt2, vuex, typescript(vue decorator 써드파티 라이브러리 사용)로 개발되어 있었다. 퍼블리싱 역시 외주였는데 모던 프론트엔드와는 맞지 않는 방식으로 (예를 들어 모달이 바닐라자바스크립트로 동적으로 추가된 클래스명에 해당하는 css를 통해 표시된다든가...)유지보수가 거의 불가능했다.
   대부분의 코드는 재사용성은 불가능하며 너덜너덜했다. 사람이 쓴 코드인데도 함수 이름이 코드의 흐름을 이해하지 못하게 한다. close 라는 이름의 함수에, true라는 인자를 보내면 모달이 "열린"다는 건 그리 대수로운 일도 아니었다.
   나는 프로젝트에 kcb 본인인증 모듈을 추가로 붙여야 했는데 받은 문서는 jsp 가이드만 존재했다. 야근과 불안장애와 신경안정제 처방을 얻었다. 나도 왜 이 프로젝트를 나 혼자 담당하고 있는지 모른다. (음, 죽고 싶다)

4. d프로젝트: 신규 프로젝트이지만 기존에 존재하는 서비스의 하위 페이지에 해당된다. 그런데 부모는 jsp이며 그 안에서 돌아가는 몇 개의 페이지를 vue로 개발해 iframe 안에 넣어야 한다는 것이었다. 단, 토큰이나 테마값은 부모에서 자식으로 전달 되어야 한다. 그런데 고객사에서 자식으로 어떻게 데이터를 전달하는지는 알려주지 않았다. url의 쿼리 파라미터로 넘긴다든가 한다고 했다. 나는 그게 아니라 토큰도 테마값도 postMessage 메소드로 줘야 달라고 요청하며 예제 코드도 바닐라자바스크립트로 작성해서 보냈다. 퍼블리싱도 c 프로젝트와 같은 뷰로 다루긴 어려운 파일이었다. c프로젝트에서 얻은 교훈으로, 컴포넌트를 다 독립적으로 만들어 불필요한 사이드이펙트를 최소화 하겠다는 의지로 컴포넌트를 열심히 쪼갰지만, 갑자기 예고없이 퍼블리싱 변경이라며 전역 css를 다시 보내왔을 때의 절망감에 눈앞이 캄캄해졌다.

느낀 점.

1. 현실적으로, 인프라 문제가 터졌을 때 대응하기가 어렵다. 내게는 "인수인계" 같은 건 존재하지 않고 오직 코드와, 파일 디렉토리를 (이건 여기다 넣으세요...) 명시한 리드미 파일만 덩그러니 남아있다. api 문서도 나중가서 받았는데 규격은 이미 변경되어 맞지 않았다. 이것의 인프라 담당은... 퇴사했다고 한다.
2. 아무도 이게 이렇게 설정된 이유를 모른다.
3. 대대적인 리팩토링이 필요하다 하더라도 현실적으로 불가능하며 설령 한다 하더라도 그 리스크와 책임은 오직 테스트에 소홀한 나의 몫이다.