Why? - 개발자 성장

나는 개발을 하면서 "왜?"라는 질문을 자주한다. "왜?"라는 질문을 많이 하게 되면 깊게 들어가게 된다. 그리고 기술 선택을 하는데 있어서 좋기도 하다. "이 기술이 요즘 뜨고 있기 때문이 아닌, 이 기술을 도입했을 때 개발하면서 겪고 있는 문제를 해결해줄 수 있겠다"는 근거가 되기도 한다. 나의 몇 가지 경험을 한 번 얘기해보겠다.

왜 React를 많이 쓰는 거지?

나는 작년에 JavaScript를 처음 접했다. 멋쟁이 사자처럼을 통해서 HTML, CSS를 했었다. 프론트엔드 개발자가 되려는 팀원이 React가 좋다는 얘기를 했다. 실제로 채용 시장에서 많은 React 개발자를 원하고 있었다.

근데 왜 회사들은 리액트를 원하는 거지?

프론트엔드 개발을 배운 사람이라면 HTML, CSS, JS로 충분히 프론트 페이지를 만들 수 있다는 것을 알 것이다. (최근에 알게 된 사실인데, GitHub는 SPA 프레임워크를 안 쓴다고 한다.) 그래서 Vanilla JS의 불편함을 겪어보기로 했다. 내가 느낀 것은 다음과 같았다.

  • HTML 파일을 모듈화할 수 없음.
  • CSS 파일을 모듈화할 수 없음.
  • JavaScript 파일이 난잡해짐.
  • JSX처럼 선언적으로 표현할 수 없음.
  • DOM을 직접 조작하면서 생기는 문제점들
    • 데이터의 흐름을 추적하기 어려움. 나는 괜찮지만, 협업하는 다른 개발자가 본다면?
    • DOM을 직접적으로 조작하는 일은 성능에 문제를 일으킨다. 항목을 추가하거나 삭제할 때마다 브라우저가 레이아웃을 다시 그려하기 때문이다.
    • DOM 조작을 잘못해서 메모리 누수가 발생할지도 모른다.

물론 나는 작은 TODO을 만들면서 느낀 것이었지만, 프로젝트가 커지면 더 많은 문제점을 맞이할 것이다. 페이스북 같은 대규모 웹 사이트는 이런 문제를 해결해야 했을 것이다. 그 해결책이 바로 React 였던 것이다.

왜 TypeScript를 쓰는 거지?

처음에 TypeScript를 배울 때는 '귀찮게 타입을 왜 지정해야하는 거지?'라는 생각을 했다.(지금은 TypeScript를 매우 좋아한다.) 타입만 지정했다 하면 에러가 발생했다. 너무 화가 났다. 그러나 TypeScript가 좋다는 사람들이 너무 많았다. 이제 내가 TypeScript를 좋아하게 된 경험을 소개하겠다.

나는 회사에서 JavaScript로 개발하는 데 익숙했다. 어느 날 버그가 올라와서 확인을 했다. 버그가 나오면 나는 다음과 같은 순서로 추적을 한다.

  1. 어떤 페이지에서 버그가 발생을 했는지 파악한다.
  2. 버그와 연관된 컴포넌트를 추려낸다.
  3. 그리고 버그가 발생하게 된 가설을 세운다.
    • 렌더링이 되어야하는데, 되지 않았을 것이다.
    • undefined가 떠서 에러가 발생했을 것이다.
    • 조건문에 엣지 케이스를 고려하지 못해서 발생한 것이다.

이렇게 버그를 추적하는데, 아무리 해도 어디인지 모르겠다. 그래서 관련된 컴포넌트에 console.log를 찍으면서 추적을 했다. 이게 잘못된 방법은 아니다. 그러나 시간을 많이 잡아먹는 방법이다. JavaScript가 너무 편했지만, 버그를 수정할 때는 너무 어려웠다. 그래서 에러가 나면 아예 컴파일이 되지 않았으면 좋겠다고 생각했다.

그리고나서 내가 진행했던 프로젝트에서 TypeScript를 썼다. 처음에는 타입 맞추는 것이 어려웠지만, 나중에는 TypeScript 없이는 개발이 어려울 정도로 됐다. 그리고 공부하면서 개발하는 것이 오래 걸렸지만 버그 발생률이 낮아져서 오히려 여유가 있었다.

왜 React-Query나 SWR이 필요한 거지?

회사에서 Next.js로 되어있는 프로젝트를 도와주게 되었다. 코드 파악하는 게 정말 힘들었다. 모든 비동기 처리 로직들이 useEffect에 있었기 때문이다. 그래서 문제점을 인지하고 비동기 처리의 대안을 찾고 있었다. 많은 대안들이 있었다.

  1. usePromise로 추상화 한다.
  2. Redux 미들웨어를 사용한다.(redux-thunk, redux-saga, redux-observable)
  3. 나중에 다른 프로젝트에 적용을 위해 다른 라이브러리를 찾아본다.

일단 기본적인 전제는 TypeScript와 호환이 잘 되어야하는 점이다. usePromise로 추상화하는 것은 좋지만 확장성 있게 추상화 하기 위해서는 함수 시그니처를 잘 추상화해야한다. JavaScript로 한다면 그렇게 신경쓰지 않아도 되지만 React로 만들어진 프로젝트는 TypeScript로 쓰여있어서 그렇게 할 수 없었다.(any를 쓰고 싶지는 않았다.) 함수 시그니처를 잘 추상화하는 것이 어렵다고 생각하여 Redux 미들웨어를 살펴봤다. Redux 미들웨어는 너무 과한 느낌을 받았다. 단순 Data Fetching이나 단순 Mutation을 하고 싶은 건데, Redux 미들웨어를 쓴다는 게 과하다고 생각했다. 그러다가 SWR을 발견하게 되었다. 훅처럼 쓸 수 있다는 게 가장 마음에 들었다. 비교 대상으로 React-Query를 알게 되었고, SWR보다 훨씬 편했다. React-Query로 커버하지 못하는 것도 있을 것이다. 예를 들어서 요청 취소 같은 것들이 그렇다. 요청 취소를 하는 것은 redux-saga나 redux-observable를 사용한다고 하니 나중을 위해서 공부를 해야겠다.

왜 데이터 관리에 신경을 써야하는 거지?

백오피스를 혼자서 개발해보니까 데이터 관리가 중요하면서 어렵다는 생각을 하게 되었다. Page Component에서 관리를 해서 내려줘야하는지, Children Component에서 관리해도 좋을지, 전역 상태로 관리하는 게 좋을지 등등 말이다. 그리고 어떤 로직을 들어내고, 어떤 로직을 숨겨야하는지도 고민하게 되었다. 프론트엔드 개발자라고 해서 눈이 보이는 것만 개발하는 게 아니라는 것을 알았다.

결론

개발을 하거나 새로운 기술을 도입할 때 "왜?" 써야하는가 질문을 하는 게 좋다고 생각한다. 공부해야할 방향이 잡히고 개발해야하는 방향이 잡히기 때문이다.

Back to the blog