글을 쓰기에 앞서 어떤 문제가 있다고 해서 무조건적으로 프로젝트를 재구축하거나, 리팩터링을 거쳐서 개선하자는 위험할 수 있다고 생각합니다. 개발자 이외의 사람들이 보기에는 문제없이 잘 진행되어 있는 프로젝트일 수 있고 재구축을 진행하면서 어떤 변수가 일어날지 알 수 없기 때문에 정말 많이 고민하고 신중해야 할 것 같습니다.
1년 전 어드민의 대한 문제가 제기되어 다른 사람 주도하에 어드민이 재구축 되었고 현재 재구축된 프로젝트에 대해 다시 문제가 제기되고 있는 상황입니다. 주도 했던 분의 개발 방식이 저희(현재 프론트 동료분과 저)와 맞지 않았고, 더 이상 이 프로젝트에 관여를 하지 않기 때문에 앞으로 어드민을 개발해 나가야 하는 저희의 개선 의견을 대표님께서 받아들여주셨던 것 같습니다.
문제점 파악하기
현재 불안한 어드민 상태를 개편하여 운영자(사용자), 개발자가 필요한 기능만을 갖추고 좀 더 효율적이면서 안정적인 환경을 갖춘다.
어드민을 다시 구축하고자 할 때 저희가 잡은 목표입니다. 그럼 무슨 문제가 있길래?
크게 4가지 문제점이 있습니다. 4가지 문제점과 별개로 현재에 충실하지 않고 추후에 개발할 걸 생각해 만들어놓은 기능들이 많은 불편함을 야기하고 있습니다. 사용자 측면에서는 아예 쓰지도 않는데 차지하는 공간 및 조건들 개발자 측면에서는 주석처리도 되어 있지 않고 이게 왜 필요하지?라고 생각되는 로직들이 곳곳에 분포하고 있습니다.
현재 어드민은 React + Typescript 조합으로 CRA 보일러 플레이트가 아닌 webpack으로 구성된 프로젝트이며 Mui를 사용하고 있습니다.
그럼 이제 본격적으로 어떤 문제점이 있는지 정리해보겠습니다.
1. Mui 사용과 코드 수정 시, Recompiling 시간이 너무 오래 걸린다.
(최소 5초 - 최대 10초 이상)
이렇게 간단히 텍스트 수정 및 console.log를 작성하고 저장을 누르면 최소 5초에서 10초이상까지 걸립니다. 이 부분이 너무나 많은 생산성 저하를 일으킵니다. 그렇다고 프로젝트가 엄청 큰 것도 아닌데 매 저장시마다 이러한 부분이 집중에 너무나 많은 방해를 합니다.
이렇게 webpack-bundle-analyzer라는 라이브러리를 이용해보면서 원인 분석을 하기도 하였고 webpack 설정 install 되어 있는 라이브러리, 컴포넌트를 의심해보면서 하나하나씩 제거해보니 대략적인 원인 파악을 할 수 있었습니다.
바로 Mui 컴포넌트를 사용할 때 이러한 문제가 생겼던 걸 확인할 수 있었습니다. Mui 컴포넌트를 제거하니 Recompiling 시간이 1-2초대로 감소하였습니다. 그렇다면 모든 Mui를 사용하는 프로젝트가 느려야 하는데 그렇지 않습니다. 아마 프로젝트 내에서 잘못 사용하고 있는 부분이 있거나 Mui를 import할 때 docs에 있는 최적화 방식이랑 다르게 import를 해서 번들 사이즈에도 영향을 주는 것으로 추정하고 있습니다.
게다가 Mui 컴포넌트를 커스터마이징 & 공통화한 컴포넌트들로 새롭게 래핑하여 쓰고 있기 때문에 기능을 추가할 때 많은 어려움을 겪게 하고 있습니다.
2. 백엔드에서 불러오는 Enum을 클라이언트의 SessionStorage에 저장하는 형태로 사용
이렇게 많은 enum이 로그인을 하면 SessionStorage에 저장되고 SessionStorage에서 get해서 사용하고 있습니다. 사실 이 각각의 Response에 대해서 Type을 지정하면 되지 않을까?란 생각이 있지만 이런 형태면 여러가지 문제점들을 발생시킵니다.
- 타입 추론이 되지 않습니다.
- 타입스크립트 + IDE 조합의 강력한 자동 완성 기능을 살리지 못하고 있습니다.
- 타입스크립트의 타입이 아닌 SessionStorage에 저장된 enum을 String to Object 방식으로 사용하고 있기 때문에 컴파일 에러를 발견할 수 없습니다.
- 매번 문제가 생길 때 SessionStorage에 들어가서 확인해야 합니다. (디버깅 과정이 번거롭고, 프로젝트 내에서 검색이 안됩니다.)
- 여기서 사용하고 있는 enum은 백엔드에서 데이터베이스와 연결되어 있는 enum 그자체
1,2,3번은 말 그대로의 문제점인데 4,5번에 대해서 좀 더 설명해보고자 합니다.
4번 매번 문제가 생길 때 SessionStorage에 들어가서 확인해야하는 문제는 타입 추론이 IDE 내에서 바로 되지 않아 디버깅 과정이 너무 번거롭습니다. 게다가 프로젝트 내에서 검색이 안되기 때문에 개발자 도구의 검색을 써서 일일이 찾아야 하는 불편함이 있습니다.
5번 사용하고 있는 enum은 백엔드에서 데이터베이스와 연결되어 있는 enum입니다. API의 Response 필드명이 변경되면 프론트에서 에러가 나는 것은 당연합니다. 그러나 현재 상태에서는 백엔드에서 사용하는 enum을 바꾸면 프론트에서 에러가 나게 됩니다. 백엔드에서 recruit라는 enum을 recruit_type으로 enum의 이름을 변경했더니, 어드민 프론트에서 공모, 사모를 선택할 수 있는 탭 자체가 사라져버리는 현상이 생겼습니다.
const recruitEnum = SessionStorageHelper.get("recruit");
//...
<XRadioGroup
control={control}
name="recruit"
items={filter(recruitEnum, (o) => return o.code !== ""; })}
label="모집 구분"
InputProps={{ readOnly: !isModifyMode }}
/>이렇게 SessionStorage에 있는 key값과 매칭시키고 있기 때문에 enum을 변경하게 되면 에러가 나게 됩니다.
3. 버그를 양산하는 코드가 많다.
현재 어드민은 하나를 수정하면 사이드 이펙트가 너무 많이 일어납니다. Mui 커스터마이징 & 공통화 뿐만 아니라 자체적으로 공통화 된 코드들이 많습니다. 공통화 자체가 나쁜것은 아니지만 무조건적으로 공통화 된 부분에 맞춰야 하기 때문에 생기는 불편함과 현재 저희는 수정 사항이 빈번하게 발생되고 있는데 이런 수정사항이 발생될 때마다 기존 공통화 되어있던 컴포넌트들이 방해가 될 때가 많습니다.
즉, 컴포넌트간의 결합도가 너무 높아서 사이드 이펙트가 발생되는 문제가 있습니다.
또한 데이터 수정 시, 다른 값이 초기화 되버리는 버그가 있습니다. 이 부분은 비단 개발자뿐만 아니라 기획자분도 문제를 겪어 제기해주셨는데, 어떠한 데이터를 바꿨을 때 다른 Input창에 있던 값이 초기화 되거나 다른 탭에 있는 값이 초기화되어 클라이언트에 있는 프로젝트 데이터가 제대로 나오지 않는 현상입니다.
즉, 어드민에서 어떠한 데이터를 수정하면 다른 부분에서 값이 초기화되어 클라이언트에도 영향이 가는 문제가 있습니다. 이 부분은 어디서부터 건드려야 할 지 감이 오지 않는 상태기도 합니다.
4. API 문제
옛날 블로그글에도 한번 적었었지만 레거시 API 문제입니다. 저희는 API 명세서를 스웨거를 사용하고 있는데, 스웨거에 명세서가 없는 API가 너무 많습니다. 구두로 전달 받거나, Response를 직접 확인하여 작업하는 불편함이 있습니다.
개발자라면 백엔드, 프론트 개발자 사이에 입출구가 명확해야 한다고 생각합니다. 하나의 API의 response가 명확하고, 필요한 스키마가 있다면 추가해주면 되는데, 프로젝트에 투입될 당시 히스토리는 프론트분께서 DB 스키마를 보고 작업할테니 DB를 던져줘라는 의견이 있었던 건지 API 자체가 DB느낌으로 덩어리가 너무 컸고 그 기반으로 개발된 상태에서는 API 명세서는 사실 필요가 없었던 것이죠. API 자체가 DB니까요. 만드려면 만들 순 있었으나 api = db인 느낌마냥 너무 큰 덩어리를 수정해야 했기에 명세서를 작성하는데 많은 어려움이 있었습니다.
또한 요청한 API Response를 set 해주는 부분에서 너무나 많은 코드라인 수가 발생하고 있습니다. 새로운 기능 추가 및 유지보수를 할 때마다 개발 생산성에도 영향이 있어 Data Fetching 라이브러리 (ex. react-query)를 도입하면 코드 라인수 & 복잡도가 크게 감소할거라고 예상되고 있습니다.
결론
여기까지 정리한 부분은 프론트 부분의 문제입니다. 백엔드 분들은 또 다른 백엔드만의 문제들로 어려움을 겪고 있는데, 차라리 프로젝트의 규모가 더 커지기 전에 작업을 하는게 좋겠다고 생각되어 문제 제기를 한 상태입니다. 또 가장 결정적인 부분은 클라이언트와 어드민의 연결되어 있는 많은 부분들이 안정적인 느낌이 아닌 불안하다고 느껴지는 점도 큰 것 같고요. (어떠한 기능을 개발했을 때 다른 부분에 영향이 없는지 눈으로 잘 되는 것처럼 보여도 중요한 부분에서 막혀버리는 현상)
아직 산정 회의도 거치지 않았고 문제에 대해 인지만 하고 있는 상태입니다. 백엔드 분들과 데이터 모델부터 타입 정의 등 API와 관련된 많은 부분들에 대해 얘기를 나눠야 하고 사용하시는 운영자분과 기획자분께 기능 정의와 화면에 제거되어야 할 요소 필요한 요소의 대한 정의도 이루어져야 합니다.
당연히 많은 공수와 어려움이 예상되지만 한 번 깔끔한 상태로 재구축을 하게 되면 생산성과 사용성에 좋은 영향을 끼칠 것으로 예상됩니다. 앞에서도 얘기했지만 문제가 있다고 무조건적으로 재구축을 하는건 옳다고 생각하진 않습니다. 적어도 정확한 문제 인식과 그로 인해 어떻게 할 지 판단은 다같이 하는 거기 때문에 생산적인 회의가 정말 중요할 것으로 생각되고 더욱더 좋은 영향을 줄 수 있는 개발자로서 성장하는 계기가 됐으면 좋겠다라고 생각이 듭니다!
'개발일지' 카테고리의 다른 글
| 웹뷰 및 인앱 브라우저 환경 고려하기 (WebView, in-app) (0) | 2023.01.05 |
|---|---|
| Admin 프로젝트 재구축 회고 (0) | 2022.08.30 |
| FE에서 OOP(Class)의 대한 고민 (Typescript + Next.js) (0) | 2022.06.17 |
| 웹뷰 및 인앱 브라우저 환경 고려하기 (WebView, in-app) 2 (0) | 2022.06.15 |
| 타입스크립트로 마이그레이션 여정기 2 (0) | 2022.05.05 |