728x90

 개인 프로젝트를 할 때엔 Vuejs, React 라이브러리를 기본으로 또는 이를 쓰는 프레임워크를 이용해서 개발을 진행했었다. 하지만 취직한 곳에서는 NodeJs기반의 프론트 프로젝트를 진행하지 않았고 그런 이유도 어느정도 납득 가능한 부분이었다. 백엔드 개발과 프론트 엔드 개발을 나누는 것이 좋지만, 인력이 두 배 이상으로 들 수도 있고 꽤나 여러 사람이 피곤해질 수 도 있다고 생각한다. 사수분은 리액트를 사용해본 적이 없기 때문에 왜 좋냐고 물어보았을 때 구체적인 이유를 이야기할 수 없었다. 지금은 스코프에 대한 이해가 있어서 이를 설명하겠지만 그 당시에는 제이쿼리도 다른 프레임워크만큼 나쁘지 않게 보였기에 이야기 할 수 없었다.

 왜 제이쿼리가 좋아보였는가? 사실 그 이유보다는 타임리프에 대한 편리한 점이 크게 보였다. 리액트를 사용하면 백엔드 서버는 모든 것을 API 서버 역할을 수행해야 하기에 많은 API가 생길 수도 있다. 비슷한 행위를 하는 API가 여러개 생길 수도 있고 이름도 겹칠 수도 있고 여러모로 머리가 아플 수도 있다. 오히려 서비스 로직을 공유하기에 더 좋은 코드가 생길 것 같다는 생각도 들기도 한다. 이런 문제를 웹 컨트롤러에서 서비스를 호출하여 데이터를 넘겨주는 방법으로 개발한다면 필요없는 api를 만들지 않아도 된다. -> 이를 해결하려고 Web Controller에 구현 로직 들이 첨가되니 api로 빠져도 되는 부분들, Controller가 무거워졌다.

하지만 제이쿼리와 타임리프를 사용하면서 답답하고 야근을 하게 만드는 요인이 무엇일까?

 첫 번째로는 타임리프의 에러가 너무 길다.
타임리프에서 파싱 에러가 발생한다면 거의 한페이지만큼의 에러를 나열해주는데 보통 맨 하단 또는 중단 쯤에 에러 관련하여 나와 하나 하나 고쳐 나가야 한다. 그러다 안 고쳐지면 직접 타임리프에서 호출하는 모델 값을 출력하여 어떤 값이 왜 안 나오는지에 대해 하나씩 확인해야 한다.

 두 번째로는 컴포넌트화가 나쁘다.
리액트의 꽃은 컴포넌트가 아닐까? 디자인도 컴포넌트 단위로 진행되고 개발도 컴포넌트 단위로 진행할 수 있다. 그리고 제일 중요한 것은 코드를 재활용할 수 있고 동일한 코드에서 문제가 발생하였을 때 하나씩 찾아가서 고쳐야 한다. 타임리프에서 프래그먼트를 이용해서도 비슷한 효과를 볼 수 있겠지만 이 또한도 복잡하고 답답하다는 사실을 잊지 말자. IDE에서 컨트롤러에서 내려주는 모델의 객체의 변수를 다 알고 있어서 바로 쓸 수 있지만 페이지에서 프래그먼트에 값을 넘기면 프래그먼트에는 무슨 변수가 있는지에 대한 알려주지 않는다.
다만 같은 페이지에서 사용한다면 나올까..? 안 해봐서 모르겠다. 그렇게 쓸거면 프래그먼트를 사용하는 이유가 있을까?

 세 번째로는 렌더링이 답답하다.
리액트는 화면에 뿌려지는 것에 데이터를 넣어두고, 데이터가 변경되면 다시 렌더링이 된다. 그래서 편하다. 제이쿼리는 내가 직접 렌더링을 해줘야 하는 것이 꽤나 좀 그렇다. 데이터만 가지고 화면을 조작한다는 관점과 내가 직접 데이터와 화면을 조작한다는 것은 많이 다르다. 또한 화면에 있는 값이 내가 가지고 있는 값이란 생각을 하게 된다.따로 내부적으로 변수에 데이터를 가지고 있지 않아도 되겠다는 생각이 들 것이다.

 제이쿼리를 이용한다는 것은 자바스크립트의 버전때문에 복잡한 돔 요소 조작을 편리하게 하는 것이다. 그러니까 순수 JS를 쓰는 것과 같다는 것이다. 리액트를 사용하면 렌더링과 컴포넌트 등 신경을 써야 하기에 복잡할 수 있는 문제도 있기에 뭐.. 그렇다.

2024.03.02

You Don't know JS Yet과 Deep Dive React를 읽어보니 왜 내가 답답한 것인지에 대해 알 수 있었고, 아직도 js를 제대로 알고 있지 않는다란 생각이 들었다.

한번 읽어보길 추천한다.

반응형

+ Recent posts