프론트엔드 설계 아이데이션

설계의 필요성

재직중인 회사에 자사 쇼핑몰도 생기고 커머셜 커뮤니티도 생길 것 같다. 나중에 유지보수에 허덕이지 않으려면 사용할 라이브러리 채택, 디렉토리 구조 등 간단한 설계를 미리 해놓는게 좋을 것 같다.

 

회사가 요구하는 기능 구현의 양은 선형적으로 증가하고 있다. 행복한 상황이지만, 아무래도 프론트엔드 개발자가 나 혼자뿐인 만큼 책임 소재도 그만큼 막중해지는듯 하다. 물론 백엔드 개발자분께서 간간히 도움을 주시고는 있다지만 도움을 받더라도 도와주시는 분께서 큰 고민 없이 코드만 치실 수 있도록 해드리는게 내 역할이지 않을까. 

 

아무튼 여러 필요로 인해 프론트엔드 설계에 대한 정보들을 이것저것 모으고 있다. 일단 정보를 착실히 모은 후, 내것으로 만들어서 개발환경에 잘 풀어내기 위해서다. 다행히 참고할만한 좋은 정보들이 매우 많더라.

 

많은 정보들 중에서도 내게 큰 영향을 준 컨텐츠는 

테오의 프론트엔드님께서 작성해주신 글과

https://yozm.wishket.com/magazine/detail/1663/

프론트엔드 아키텍처의 가장 최근 트렌드는? | 요즘IT

 

우아콘 프론트엔드 상태관리 실전편 유튜브 영상이었다.

https://www.youtube.com/watch?v=nkXIpGjVxWU

 

그 외에도 멋쟁이사자처럼 프론트엔드 3기 카톡방에서 이것 저것 정보들을 취합할 수 있었다.

 

현재 상황

현재 FE 산출물들은 퀄리티보다는 속도가 중요했다. 스타트업인 이상 어쩔 수 없는 부분이라고 생각된다. 그래도 만들었던 몇몇 프로젝트 산출물들이 유효했는지 사업이 조금씩 커지고 있음을 느낀다. 사업이 커지면 점차 절대적인 코드 양과 기능 구현도 많아질 것 같다.

 

문제는 앞으로도 퀄리티보다 속도를 중시할 것이냐는 것이다. 지금까지 만들었던 이벤트성, 단기 프로젝트성 산출물은 사실 설계를 빡세게 하는 것 보다는 그냥 유지보수를 해버리는게 비용이 덜 들었다. 하지만 회사 자체의 쇼핑몰과 커뮤니티 등은 오래오래 가져가야할 프로젝트이며, 그런 만큼 유지보수도 편해야하고 기능 탈부착도 쉬워야한다.

결론은 속도도 중요하지만 퀄리티도 중요하다.

 

아이데이션

그래서 설계에 대한 고민을 했고, 만든 아이디어를 도식화해보았다. 그 결과물은 아래와 같다.

 

excalidraw를 이용하면 쉽게 그릴 수 있다.

 

위 도식화한 그림을 줄글로 바꾸면 아래와 같다.

 

1. 비즈니스 로직과 결합해야하는 컴포넌트들은 아예 로직과 결합시켜 컨테이너로 만들어 하나의 모듈로써 사용 (변경이 필요할때는 컨테이너 자체를 바꿔버림)
2. 그 외 말단 UI들은 재사용이 가능하도록 설계함. 디자인, 기획 파트와 전사적인 소통이 필요
3. 서버, DB와 밀접한 관계를 가진 데이터들은 리액트 쿼리를 통해 서버 자체와 데이터를 연동
4. 계정 별로 이용하는 비즈니스 로직(결제 등)은 전역 상태로 만들어 도메인으로 관리(화면과 관심사 100% 분리)

(사실 쇼핑몰의 경우에는 당장 PG를 붙힐 것은 아니다. 하지만 나중에는 100% 붙는다고 봐야할 것이다. 만약 내가 붙이지 않더라도 회사가 성장한다면 언젠가는 붙히지 않을까. 그 때 내가 없더라도 내 다음 사람이 붙힐수 있도록 잘 정리해놓자는 생각이다.)

 

결론

쓰고나니 너무 간단한 설계다. 잘못된걸까? 라고 지금 자문해보기도 하지만... 굳이 설계가 복잡할 필요가 있는가? 간단한게 좋은 것일 수도 있지 않을까?

 

또 굳이 완벽한 설계가 필요한가? 라는 생각도 든다. 토대를 세워놓은 후 동료들과 토의하면서 조금씩 발전시켜나가면 되지 않을까. 이런 고민들을 맘 터놓고 편하게 할 수 있는 동료들을 만나서 다행이다.