Pagelyze를 구축하며 React에 대해 배운 것들

Translated for your language. Read the original.

AI-assisted draft.

Pagelyze를 구축하면서 React를 바라보는 관점이 바뀌었습니다. 이론을 공부하는 것을 넘어 제품 아키텍처를 바라보기 시작했습니다.

Pagelyze는 웹사이트 감사(audit) 도구입니다. 단순한 연습용 앱이 아닙니다. 감사 보고서, 점수 산정 로직, 대시보드 등을 처리합니다. 이 때문에 저는 한 가지 질문에 답해야 했습니다.

제품이 성장해도 이 코드가 깔끔하게 유지될 수 있을까?

useState나 useEffect 같은 Hook은 중요합니다. 하지만 그것이 전부가 아닙니다. 최신 문법을 사용하더라도 유지보수하기 힘든 엉망인 코드가 될 수 있습니다. 문제는 대개 '책임(responsibility)'에 있습니다.

잘못된 구조에서는 파일 하나가 데이터 로딩부터 결과 표시까지 모든 것을 처리합니다. 규모가 커지면 이런 방식은 한계에 부딪힙니다.

더 나은 방법은 목적에 따라 컴포넌트를 나누는 것입니다.

각 요소는 하나의 역할만 수행합니다. 데이터 로직을 망가뜨리지 않고도 카드 디자인을 변경할 수 있습니다.

Redux를 쓸지 Context를 쓸지 고민하는 것을 멈추세요. 대신 '누가 이 상태(state)를 필요로 하는가?'를 물으세요.

커스텀 Hook은 동작(behavior)을 나타내야 합니다. 단순히 지저분한 코드를 다른 파일로 옮기는 용도가 되어서는 안 됩니다. 좋은 Hook은 데이터를 가져오는 역할을 수행하여, 페이지 컴포넌트는 화면을 조정(coordinate)하는 역할만 하도록 해야 합니다.

폴더 구조는 기능(feature) 단위로 구성하세요.

라우팅은 단순한 URL 그 이상입니다. 그것은 사용자의 여정(user journey)입니다. 사용자는 랜딩 페이지에서 무료 감사로, 그다음 보고서로, 마지막으로 서비스 문의로 이동합니다. 좋은 라우팅은 사용자를 다음 단계로 자연스럽게 안내합니다.

명확하게 구축하세요. 병목 지점을 찾으세요. 그리고 그 특정 부분만 수정하세요.

React의 베스트 프랙티스는 결국 '결정'에 관한 것입니다. 컴포넌트가 무엇을 소유할지, 상태가 어디에 존재할지, 라우트가 사용자에게 도움이 될지를 직접 결정하는 것입니다.

Pagelyze는 저의 시험대입니다. 저는 화면을 만들 수 있는지를 테스트하는 것이 아닙니다. 제품이 성장함에 따라 깔끔한 상태를 유지할 수 있는지를 테스트하고 있습니다.

Continue reading