[서평/리뷰 #3] <대규모 리액트 웹 앱 개발> 서평

안녕하세요 dev_writer입니다. 오늘은 [대규모 리액트 웹 앱 개발] 책에 대한 리뷰를 작성하겠습니다.

 

책의 목차는 다음과 같이 이루어져 있습니다.

1. 시작하며
2. 소프트웨어 복잡성 관리하기
3. 모듈성
4. 성능
5. 디자인 시스템
6. 데이터 가져오기
7. 상태 관리
8. 국제화
9. 코드 조직화하기
10. 개인화와 A/B 테스팅
11. 확장 가능한 웹 아키텍처
12. 테스팅
13. 툴링
14. 기술적 마이그레이션
15. 타입스크립트
16. 라우팅
17. 사용자 중심 API 디자인
18. 리액트의 미래
19. 맺음말

 

대규모 웹 애플리케이션의 정의

가장 먼저, "대규모 웹 애플리케이션"이라는 용어의 올바른 정의가 무엇일까요?

 

책에서는 시작하면서부터 대규모 웹 애플리케이션을 정의하고 있습니다.

우리는 대규모 웹 애플리케이션을 정의하는 가장 쉬운 방법이 다음과 같다고 생각한다. 수십 명 혹은 그 이상의 엔지니어로 구성된 대규모 팀에 의해 개발되었거나, 소규모 팀에 의해 개발되었지만 시간이 지남에 따라 계속 진화하는 웹 애플리케이션, 혹은 이 두 가지 성격을 모두 가진 애플리케이션을 대규모 애플리케이션이라 정의한다. 즉, 대규모 웹 애플리케이션은 유지보수에 개발자의 상당한 노력을 요구하는, 사소하지 않은 (non-trival) 애플리케이션이라 할 수 있겠다.

 

이 말을 듣고, 상당한 노력과 사소하지 않은 애플리케이션이란 무엇일지 추가로 고민해 보았습니다. 그러다가 책을 읽으면서 책의 목차로부터 힌트를 얻을 수 있었는데, 제가 내린 대규모 웹 애플리케이션의 정의는 아래와 같습니다.

대규모 웹 애플리케이션이란
차원이 다른 수준의 유지보수를 꾸준히 해야 하는, 계속 진화되는 애플리케이션이다.

 

책에서는 모듈화, 성능 최적화, 테스트와 같은 코드 수준에서의 개선 말고도 국제화, 개인화 및 A/B 테스팅 등 비즈니스와 관련된 기법들도 소개하고 있습니다. 이러한 기법들을 모두 적용해야 할 애플리케이션이라면, 그것이 곧 차원이 다른 수준의 유지보수를 하고 있는 애플리케이션이라 생각합니다. 단순히 코드만 수정하는 게 아니라 사용자 경험과 비즈니스 전략까지 영향을 미칠 수 있기 때문입니다.

 

처음에 제목만 들었을 때에는 대규모 웹 애플리케이션이란 "MAU가 높은 애플리케이션"일 줄만 알았었는데 (백엔드에서의 "대규모 트래픽"처럼..), 보다 명확히 정의할 수 있어 시작부터 좋은 고민을 할 수 있었습니다.

 

기술은 문제를 해결하기 위해 등장한 "도구"이다.

요즘 들어 각종 기술/기법들을 이용할 때마다 "왜" 써야 하는지 고민을 많이 했었는데, 본 책에서는 각 기술들을 소개할 때마다 탄생한 배경, 고려 요소 등을 함께 제공하고 있어 좋은 근거를 얻을 수 있었습니다.

 

또한, 기술을 선택할 때 단순히 그 기술에 익숙하다는 이유로 충분한 고민 없이 기술을 채택하는 행위는 좋은 접근법이 아님을 알려주었습니다.

 

히키는 도구와 (프로그래밍) 언어를 선택할 때 주로 고려해야 할 사항은 도구나 언어의 사용 편의성이 아니라 우리가 해당 도구와 언어를 사용해서 구축한 시스템이 갖는 복잡성이어야 한다고 말한다. 사용하기 쉬운 도구를 선호하는 것은 자연스러운 것이지만, 쉬운 시스템 변경이나 유지보수에 미치는 장기적인 영향에 관해서도 고려해야 한다. 사용하기 쉬운 도구가 항상 복잡성을 야기하지는 않겠지만 쉬운 사용성을 다른 모든 것보다 우선해서는 안 된다. 대신, 만들어지는 시스템의 전반적인 단순성에 초점을 두어야 한다.

 

아래는 책의 내용을 통해 기술의 등장 배경 및 사용 시 주의사항에 대해 정리해 본 내용입니다.

 

리액트 컴포넌트화의 고려 요소

보통 리액트를 공부해 보신 분들은 컴포넌트화를 하는 게 재사용성과 유지보수성을 높여준다는 것을 잘 알고 계실 겁니다.

 

그러나 한편으로는, 만약 극단적으로 컴포넌트를 잘게 쪼갠다고 가정했을 때에도 위 장점이 유지될까라고 한다면, 아닐 것입니다.

 

책에서는 리액트에서 컴포넌트화를 할 때에도 몇 가지 고려 사항을 제안하고 있습니다.

 

모든 것을 컴포넌트로 만들고 싶을 수도 있겠지만 균형이 중요하다. 너무 잘게 나누면 결국 그 코드베이스를 탐색하기 어렵게 될 것이다. 너무 성기게 나누면 앞에서 설명한 이익의 혜택을 누리지 못할 것이다. 컴포넌트로 나누는 것을 결정할 때는 여러 요소들을 고려해야 한다.

• 재사용성: 특정한 UI 요소 혹은 기능을 애플리케이션의 여러 부분에서 반복하기 원하는가? 그렇다면 자체적인 컴포넌트로 만들 수 있는 좋은 후보이다.
• 단순성과 가독성: 컴포넌트 코드의 가독성은 어떤가? 컴포넌트를 작은 하위 컴포넌트로 나누고 각각의 책임에 집중하도록 만들면 코드를 보다 쉽게 읽고 이해할 수 있게 되는가?
• 개선된 테스트 가능성: 컴포넌트가 더 작고 집중된 책임을 갖는다면 이 컴포넌트를 보다 효과적으로 테스트할 수 있는가? 작은 컴포넌트들은 일반적으로 적은 내부 상태와 적은 사이드 이펙트를 가지므로 테스트에서 격리하기 쉽고 기능의 각 조직이 의도한 대로 작동함을 보장한다.
• 성능 고려 사항: 컴포넌트를 나눔으로써 렌더링을 최적화하거나 불필요한 조직을 줄일 수 있는가? 리액트 같은 라이브러리에서는 종종 작은 컴포넌트가 보다 적은 수의 재렌더링을 하며 컴포넌트와 계산을 메모화한다. 이는 때때로 앱의 전반적인 성능을 개선할 수 있다.

 

리액트 쿼리의 탄생 계기

리액트 쿼리는 리액트 환경에서의 비동기 쿼리 과정을 도와주는 라이브러리로써, 기본적으로 사용할 수 있는 Fetch API와 또 다른 라이브러리인 Axios보다 더 뛰어난 기능들을 제공하고 있습니다.

 

이전에 Axios 인터셉터에 대해 조사했을 때 Fetch API는 기본적으로 내장된 API라 사용이 간단하지만 JSON 파싱 과정이 별도로 존재한다는 단점이 있었고, Axios는 별도로 설치해야 하는 라이브러리이지만 인터셉터 제공, JSON 파싱 지원 등 기능이 더 있는 기술로 파악했습니다.

 

이에 비해, 리액트 쿼리는 Fetch/Axios가 지원하는 기술 이외에도 캐싱, 재시도 메커니즘 등 애플리케이션이 커지고 요구사항이 복잡해지면서 발생한 문제를 해결하기 위해 등장하였습니다.

 

반면 리액트 쿼리를 이용하더라도 캐싱이 필요하지 않은 상황, 또는 기존의 설치된 axios만으로도 충분한 상황 등이라면 오히려 리액트 쿼리를 도입하는 게 적절하지 않을 수 있겠다는 접근도 해볼 수 있었습니다.

 

자세한 것은 레퍼런스로 찾아본 서비스에 React-query를 도입하며 마주한 문제들 글을 참고해 보면 좋습니다.

 

리액트 단위 테스트 해 보기 (feat. AAA 패턴)

리액트를 공부한 지 얼마 지나지 않은 저로서는 해당 섹션도 너무 좋은 영역 중 하나였습니다.

 

리액트 컴포넌트를 만들었다고 했을 때, 어떻게 테스트할 수 있을까요? 자바나 코틀린을 이용한 스프링 등 백엔드 단에서의 테스트는 많이 접해봐서 익숙했으나, 리액트 컴포넌트를 테스트하는 방법은 익숙하지 않아 어려운 영역으로만 생각했었습니다.

 

이것은 책에서 소개한 간단한 Counter 컴포넌트 (버튼 누르면 숫자 증감되는 컴포넌트) 테스트 코드를 공유드리며 말씀드리겠습니다.

 

Counter 컴포넌트

import React, { useState } from 'react';

const Counter = () => {
  const [count, setCount] = useState(0);
  
  const increment = () => {
    setCount(count + 1);
  };
  
  const decrement = () => {
    setCount(count - 1);
  };
  
  return (
    <div>
      <button onClick={decrement}>-</button>
      <span>{count}</span>
      <button onClick={increment}+</button>
    </div>
  );
};

export default Counter;

 

책에서는 리액트 컴포넌트 테스트를 할 때 AAA 패턴 (Arrange, Act, Assert - 정리, 동작, 확인 패턴)을 적용하여 알려주고 있습니다.

import React from 'react';
import {
  render,
  fireEvent
} from '@testing-library/react';
import Counter from './Counter';

describe('Counter component', () => {
  it('renders with initial count of 0', () => {
    // 정리 (Arrange)
    const { getByText } = render(<Counter />);
    
    /*
    동작 (Act) - 초기 렌더링을 테스트하므로 아무런 동작이 필요하지 않다.
    */
    
    // 확인 (Assert)
    expect(getByText('0')).not.toBeNull();
  });
  
  it('increases count on "+" button click', () => {
    // 정리 (Arrange)
    const { getByText } = render(<Counter />);
    const incrementButton = getByText('+');
    
    // 동작 (Act)
    fireEvent.click(incrementButton);
    
    // 확인 (Assert)
    expect(getByText('1')).not.toBeNull();
  });
  
  it('decreases count on "-" button click', () => {
    // 정리 (Arrange)
    const { getByText } = render(<Counter />);
    const decrementButton = getByText('-');
    
    // 동작 (Act)
    fireEvent.click(decrementButton);
    
    // 확인 (Assert)
    expect(getByText('-1')).not.toBeNull();
  });
});

 

총평

책을 다 읽고 나서야 저자 분에 대한 설명을 봤는데, 구글 크롬 엔지니어링 리더를 맡고 계신 분 (Addy Osmani)이었습니다. 구글 크롬이라면 책의 제목처럼 대규모 웹 애플리케이션이라 할 수 있겠다는 생각이 들었습니다. 다만 리액트에 완전히 종속적으로 알려주는 책이기보다는, 대규모 웹 애플리케이션을 구축할 때 어떤 문제를 접할 수 있고 그에 대한 해결책을 어떻게 적용하고 있는지에 대해 다루는 책이라 할 수 있습니다.

 

그래서 "대규모 웹 애플리케이션을 리액트로 구축하는 방법"에 대해 알고 싶으신 분들보다는, "대규모 웹 애플리케이션을 구축하기 위해 접근할 수 있는 해결책들이 무엇이 있는지"를 알고 싶으신 분들에게 잘 맞는 책입니다. (다르게 말하면, 부담 없이 쉽게 읽을 수 있는 책이기도 합니다!)

 

더 나은 프런트엔드 개발자가 되기 위해 시도해 볼 수 있는 접근법이 무엇이 있는지 궁금하신 분들께 이 책을 추천합니다.

 

 

본 글은 제이펍 출판사로부터 도서를 지원받아 작성되었습니다.