함수형 프론트엔드에서 의존성 제어하기

안녕하세요. 프롬 프론트엔드 팀에서 테스트와 이것저것 전도하는 프론트엔드 개발자 김태희입니다.

제가 4월에 들어왔는데. 이제 2023년이 끝나고 2024년이 다가오고 있습니다. 제가 과거에 짰던 코드는 레거시가 되어가고요. 하나 둘 추가했던 기능은 복잡하고 거대한 로직이 되기도 했습니다. 서버/브라우저/webview 같은 다양한 환경과, react와 qwik 같이 여러 프레임워크 등을 지원하려 하면서, 의존성에 대해 여러모로 고민을 하게 되었습니다.

이번에는 모던 리액트처럼 함수형을 지향하는 프론트엔드 프레임워크에서, 어떻게 의존성을 제어할지에 대해 이야기해보려 합니다. 의존성은 지속 가능한 소프트웨어 프로젝트를 위해 정말 중요한 주제인데요. class 기반 객체지향을 하는 백엔드 생태계와 달리, 프론트엔드에서는 어려워하는 분들이 많습니다.

그러면 어떻게 하면 의존성을 더 잘 제어해서 더 이해하기 쉽고, 변경하기 쉬우며, 안전한 코드를 만들 수 있을지 같이 고민해보시죠.

의존성에 대하여

코칭을 하고 팀원 분들과 이야기를 하다보면 의존성에 대해 다들 다른 생각을 가지고 계십니다. 명확하지 않고 이것저것 생각이 혼재된 경우도 많고요. 저는 이미 개인 블로그에 프런트엔드에서 의존성을 제어하는 법이라는 글을 쓴 적이 있습니다만.

잠시 그때 했던 이야기를 정리해보고, 의존성의 개념을 잡고 시작해보려 합니다.

일단 의존성이라 하면 js개발자에게는 package.json에서 dependencies라 부르는 외부 패키지들이 떠오르실 겁니다. 예를 들자면 react나 next부터 jotai나 react-query 같은 상태관리 라이브러리나, styled-component나 tailwind 같은 스타일링 라이브러리 등이 있겠습니다. 이런 외부 의존성은 직접 바퀴를 재발명할 필요 없이, 빠르게 새 기능을 개발하게 도와주기 때문에 많이들 사용합니다.

외부 의존성이 전부는 아니지만, 일단 외부 의존성에 집중해보죠. 먼저 공개 인터페이스와 내부 구현이 무엇인지 살펴봅시다.

인터페이스 vs 내부 구현, 제공자 vs 사용자

이런 의존성 제공자들은 사용자들이 사용할 수 있는 api를 제공합니다. api라 하면 http 서버와 통신하는 것만 생각하시는 경우도 있는데요. 더 넓게 생각하면 이런 것도 다 공개 인터페이스입니다. java 같은 언어에서는 public 접근 제어자로, golang 같은 언어에서는 첫 글자를 대문자로 설정하기도 하는데요. javascript 모듈에서는 export 한 것들이 공개 인터페이스입니다. 이를 의존성 사용자들은 import해서 사용합니다.

예를 들어 다음 코드에서는 jotai가 제공하는 atom으로 cartAtom을 만들고요. useAtomValue로 atom에 해당하는 상태를 store에서 꺼내서 사용하고 있습니다.

// atom/cart.ts
import { atom } from 'jotai';

import { CartVo } from 'vo/shared/Cart.vo';

const cartAtom = atom<CartVo | undefined>(undefined);

export { cartAtom }

// pages/index.tsx
import { useAtomValue } from 'jotai';

import { cartAtom } from 'atom/cart';

function Page(){
    const cart = useAtomValue(cartAtom)
    // ...
}

이렇게 생각하면 저희가 직접 만든 의존성도 비슷하게 생각할 수 있습니다. 예를 들어 atom/cart.ts 모듈은 외부에 cartAtom을 공개하고 있습니다. pages/index.tsx 모듈에서는 이런 cartAtom을 가져다가, jotai의 useAtomValue와 함께 사용하고 있죠.

리팩터링 vs 파괴적 변경

인터페이스와 동작을 유지하면서 내부 구현만 바꾸면 리팩터링이라 합니다. 구현을 바꾸면서 인터페이스가 바뀌거나, 겉보기 동작이 깨지면 파괴적 변경이라 합니다.

예를 들어 리액트 쿼리를 이용한 다음 코드를 봐주시죠. 브랜드의 경로를 받아서, 해당하는 브랜드의 정보를 가져오는 로직인데요. react query v3에서는 cache key와 데이터를 가져오는 비동기 함수, options를 3개의 인자로 받게 했습니다.

import { getBrand } from 'api/brand';
import useOnApiError from 'hooks/useOnApiError';
import { useSuspendedQuery } from 'hooks/useQuery';

const useGetBrand = (brandPath: string) => {
    const onApiError = useOnApiError();

    return useQuery(
        ['getBrand', brandPath], // key
        (signal) => getBrand(brandPath, signal), // data를 가져오는 비동기 함수
        { onError: onApiError } // options
    );
};

export default useGetBrand;

semantic version을 준수하는 의존성 제공자들은 minor 버전 업데이트에서는 보통 인터페이스 하위 호환을 지키려 노력합니다. 예를 들어 3.1에서 3.2로 올라가면서 성능 최적화를 위해 여러 내부 구현을 개선했다고 해봅시다. 그래서 인터페이스는 변한 게 없기 때문에, 의존성을 사용하는 프로젝트에서는 버전을 올려도 아무 것도 깨지지 않아야 합니다. (물론 성능은 좋아지겠죠.)

이렇게 외부 인터페이스를 유지하면서, 내부 구현을 개선하는 것만 리팩터링이라 합니다. 코드 구조를 갈아 엎으면 다 리팩터링이라고 잘못 쓰이는 경우가 많지만요.

의존성 제공자들은 메이저 버전을 올릴 때 파괴적 변경을 도입하기도 합니다. 예를 들어 react-query를 쓰다보면 useQuery 말고도 prefetch나 다양한 기능에 key, 비동기 함수, options를 복붙하게 될 때가 많은데요. 그래서 react-query v5에서는 저 세 가지 인자를 하나의 객체로 받도록 수정했습니다. 물론 약간 더 장황해지긴 했지만, query 객체를 하나 만들어두면 이곳저곳 공유해서 쓸 수 있어서 편리해졌죠.

하지만 이는 파괴적 변경입니다! version 5로 올라가려면 새로운 인터페이스에 맞춰서, 기존 인터페이스를 사용하는 모든 레거시 코드를 뜯어고쳐야 합니다. 이런 곳이 28곳이라면? 100곳이라면? 1000곳이라면?

그리고 변수명이나 매개변수 모양이 바뀌는 정도가 아니라 패러다임이 바뀌는 수준의 큰 파괴적 변경도 있습니다.

• react가 class component와 life cycle에서 hook으로 갈아타면서 모든 생태계가 뒤집혔습니다
• react에 server component가 도입되면서 styled나 emotion 등의 기존 css in js 라이브러리가 동작하지 않게 되었습니다
• react-query는 v5부터 useQuery에 onSuccess나 onError 등의 handler를 제공하지 않기로 했습니다

실행 환경과 표준, 어댑터, 폴리필

저희는 다양한 실행 환경(runtime)에서 코드를 돌립니다. 자바스크립트는 원래 과거 Netscape 브라우저에서 돌아가기 위해 만들어진 언어였습니다. 인터넷 익스플로러가 세상을 지배하고 자바스크립트를 베껴서 JScript를 만들기도 하고요. 그 후에 나온 크롬이나 파이어폭스 등 다양한 브라우저들도 자바스크립트를 지원했습니다만. 표준이 있어도 마이크로소프트가 무시했고 이런저런 복잡한 역사가 있었습니다.

여러 의존성들이 각자의 인터페이스를 만들어서 난립하게 되면, 의존성 사용자들은 고통 받게 됩니다. 마치 C 타입 충전기를 쓰지 않는 애플 마냥. 의존성 사용자들은 다양한 환경과 다양한 의존성의 인터페이스를 지원하기 위해서 머리를 싸매게 됩니다. 이는 지금도 현재 진행형이라 크롬에서는 잘 돌아가는데 사파리에서는 안 돌아간다는 사용자 문의를 받을 때마다, 개발자들은 눈물을 흘리죠. 새로 나온 css 기능을 쓰기 전에는 매번 can i use 같은 사이트에 브라우저 지원 범위를 검색해보고요.

이런 실행 환경들은 개발자가 코드를 한 줄도 고치지 않아도 알아서 변화합니다. 사파리 16에서는 잘 돌던 코드가 사파리 17에서는 보안이 강화되면서 깨지기도 하고요. 사파리 17에 나온 기능을 써보려 해도 사파리 14를 쓰는 사용자들을 지원할 수 없어서 포기하기도 합니다. 안드로이드나 ios도 새로 버전업을 하고, js도 계속해서 ES6, ES2023, ES2024가 나옵니다.

그래서 어떤 의존성의 인터페이스를 다른 의존성의 인터페이스로 변환해주는 어댑터들이 나옵니다. Java는 똑같은 코드가 window, linux, mac에서 모두 돌아갈 수 있게 해줬죠. JQuery는 비일관적인 브라우저 js 사이에서 일관된 방식으로 dom을 조작할 수 있는 인터페이스를 제공했습니다.

한편 신 버전의 인터페이스를 구 버전의 기능만으로 비슷하게 구현해주는 폴리필도 많이들 사용합니다. 예를 들어 core-js와 babel/preset-env는 browserlist의 정보를 이용해서 알아서 구버전의 js로 변환해주거나, 지원하지 않는 브라우저 api는 비슷하게 만들어서 넣어줍니다. 모던 css를 옛 브라우저에서 돌아가게 해주는 postcss-preset-env 같은 것도 있습니다.

지금까지 정리한 개념들을 한 번 되짚어 보시죠. 내가 코딩을 하면서 겪었던 사례도 떠올려보신 뒤에 계속 읽어나가시면 좋겠습니다.

의존성의 파괴적 변경에 대처하기

앞서 이야기한 것처럼 외부 의존성의 인터페이스를 곳곳에서 직접 import해서 사용하면, 파괴적 변경이 일어났을 때 고칠 부분이 많아집니다. 너무 많은 사용자가 이 인터페이스에 의존하고 있기 때문이죠. 외부 의존성이라면 버전을 올리지 않고 버틸 수도 있습니다. 우리가 직접 만든 의존성이라면 하위 호환을 유지하려 할 수도 있고요.

하지만 생태계와 런타임이 발전하는 건 막을 수 없습니다. 제가 아는 어떤 프로젝트는 파이썬 버전을 올리지 않고 버티다가, 포매터나 린트 같은 모든 툴까지 지원이 끊기면서 버전을 올릴 수 밖에 없게 되었습니다. react class component로 된 레거시들도 비슷한 신세에 처해 있죠.

그러면 어떻게 하면 좋을까요?

외부 인터페이스를 감싸기

먼저 외부 의존성을 한 번 중간 계층을 두어서 감싸는(wrap) 방법이 있습니다. 그리고 프로덕트 코드에서는 외부 의존성을 직접 import할 수 없게 막으면 됩니다. 그래서 객체지향 쪽 책을 보시면 그래서 외부 의존성에 직접 의존하지 말라고 합니다. 우리가 소유한 인터페이스로 한 번 감싸두고, 외부 의존성을 이용해서 내부만 구현하는 것이죠. 이를 “추상화에 의존하고 구현에 의존하지 않는다”고도 하고요. 유식한? 말로는 제어의 역전이라고도 부릅니다.

이는 특히 의존성이 변경될 가능성이 높거나, 많은 곳에서 사용할 예정이라면, 혹은 다양한 구현체로 빌드할 필요가 있을 때에는 꼭 지키시면 좋습니다.

의존성 주입에 대해 검색해보면 세상에 자바의 생성자 주입과 setter 주입만 있는 것처럼 설명하고, 생성자 주입이 더 좋다는 설명만 복사 붙여넣기 된 것을 볼 수 있습니다. 아니면 @데코레이터를 남발한 스프링 식 의존성 주입 방법만 많이 나오는데요.

하지만 react나 프론트엔드에서는 class나 interface를 쓰지 않는 경우가 많습니다. 함수에서는 어떻게 하면 좋을까요?

리액트에서는 보통 커스텀 훅이나 컴포넌트를 이용합니다. 예를 들어 위에서 본 cartAtom은 다음처럼 useCart로 감쌀 수 있습니다.

// atom/cart.ts
import { atom, useAtom } from 'jotai';

import { CartVo } from 'vo/shared/Cart.vo';

const cartAtom = atom<CartVo | undefined>(undefined);

function useCart(){
    return useAtom(cartAtom)
}

export { cartAtom, useCart }

// pages/index.tsx
import { useCart } from 'atom/cart';

function Page(){
    const [cart] = useCart()
    // ...
}

이렇게 하면 atom/cart만 jotai에 의존하고요, pages/index.tsx 는 jotai의 존재를 모르게 됩니다. 혹시나 jotai 말고 react-query나 다른 라이브러리로 갈아타게 되더라도 useCart의 구현만 수정해주면 됩니다.

한편 기존에 useQuery를 useQueryRequest라는 이름으로 이미 감싸서 사용하고 있었습니다. 앞서 말한 불편함도 있고, cacheKey에 언어나 통화 같은 자주 겹치는 요소를 매번 넣어주기가 번거로워서 만든 것이었는데요. 이번에 react-query v5로 올라가면서 파괴적 변경이 상당했지만, useQueryRequest는 이미 객체 하나만 받도록 해두어서 내부 구현만 고쳐주면 되었습니다.

외부 의존성을 유연하게 migration하기

의존성을 사용하다보면 우리가 지원해야하는 환경에서는 동작하지 않아서, 이사(migration)를 가야할 때가 있습니다.

저희는 실제로 jotai의 SSR 동작이 저희가 기대하는 것과 달라서 currencyAtom을 cookie와 useSyncExtenralStore로 migration 한 적이 있었는데요. 슬프게도 useAtom(currencyAtom)을 곳곳에서 쓰고 있어서, 모든 코드를 수정해야 했습니다.

또 다른 예시로 tailwind나 styled component 같은 라이브러리는 디자인 시스템이나 공용 컴포넌트로 한 번 감싸두면 좋습니다. 이러면 사용하기에도 편리하고요. styled-component 등을 사용할 수 없는 server-component 등으로 migration을 할 때 공용 컴포넌트의 스타일만 똑같이 만들어주면 되거든요. 프로젝트 전반에 복사 붙여넣기한 스타일이 퍼져있다면, 한 스타일에서 다른 스타일로 바꾸기가 매우 어려울 겁니다.

비슷하게 react-router-dom을 사용하던 분들은 next/router로 갈아타면서 여러가지 고통을 겪게 되실 겁니다. Link나 useRouter 같은 걸 한 번 감싸두었다면… <Link to="..." 가 <Link href="..." 로 바뀌는 식의 사소한 차이에 더 쉽게 대응할 수 있을 겁니다. storybook이나 test 환경처럼 Next router를 사용할 수 없는 환경에서도 next의 내부 구현과 씨름할 필요 없이, 구현체만 바꾸면 되지요.

이런 인터페이스를 만들 때에는 표준에 대해 깊이 생각해보시면 좋습니다. 예를 들어 router를 추상화하려면 ‘react-router-dom’, ‘next’, ‘stackflow’ 등, 우리가 migration할 가능성이 높은 구현체들을 살펴보시고 공통점은 무엇이고 차이점은 무엇인지 고민해보시면 좋습니다.

의존성을 명시적으로 드러내고 주입하자

다음으로 외부 의존성이 없는 순수 함수를 분리하고, 외부 의존성을 명시적으로 매개변수로 넘기는 방법이 있습니다. component에서는 prop으로 넘기는 것이 여기에 해당하고요. class 기반 객체지향에서는 생성자 주입 방식도 이와 유사합니다. 이는 특히 다양한 환경을 지원하는 코드를 만들거나, 복잡하고 중요한 핵심 로직을 만들 때 유용합니다.

예를 들어 다음 useFormatPrice 훅은 사용자가 설정한 currency와 lang을 context에서 암시적으로 가져오고 있습니다. 그래서 현재 사용자가 설정한 통화와 언어로 가격을 렌더해주는 역할을 합니다.

export const useFormatPrice = () => {
    const { lang } = useTranslation('common');
    const currency = useCurrencyValue();

    const formatPrice = useCallback(
        (price: number | null, lang: LanguageCodeT, currencyCode = currency.code) => {
            const formattedPrice = addCommaToNumber(price ?? 0);

            if (currencyCode === 'KRW') {
                return lang === 'ko' ? `${formattedPrice}원` : `₩${formattedPrice}`;
            }
            // currentCode === 'USD'
            return `$${formattedPrice}`;
        },
        [currency.code, lang]
    );
    return { formatPrice };
};


const { formatPrice } = useFormatPrice()

// 사용자가 KRW, ko로 설정한 경우
formatPrice(1000) // 1000원

// 사용자가 KRW, en으로 설정한 경우
formatPrice(1000) // ₩1000

// 사용자가 USD로 설정한 경우
formatPrice(1000) // $1000

흔히들 만드는 훅이고 당장은 편리해보이지만 여러 문제가 있습니다.

먼저 react hook에 의존하기 때문에 server component에서 사용할 수 없습니다. 이 hook을 이용하는 컴포넌트도 마찬가지고요. 저희는 언어나 통화는 서버에서 url과 cookie로 알 수 있는데, 사용을 못하게 됩니다.

다음으로 사용자가 설정한 통화와 다르게 렌더하고 싶은 경우에는 사용할 수가 없습니다. 예를 들어 어떤 한국인 사용자가 61000원에 앨범을 샀다고 해봅시다. 미국에 사는 친구에게도 앨범을 사주려고 USD로 설정한 뒤에, 주문 내역에 들어가면 다음처럼 이상한 에러가 발생합니다.

61,000원이 아니라, 현재 설정된 달러로 가격이 다르게 표기되는 것이죠! 외부에서 formatPrice를 제어할 방법도 없습니다. formatPrice는 사용자가 설정한 언어와 통화는 물론이고 react hook과 강결합되어 있어서 유연하지 못한 코드가 되었습니다.

그러면 어떻게 하면 좋을까요? formatPrice를 순수 함수로 분리하고, 매개변수로 context를 넘기면 됩니다.

function formatPrice(price: number | null, currencyCode: CurrencyCodeT, lang: LanguageCodeT){
    const formattedPrice = addCommaToNumber(price ?? 0);

    if (currencyCode === 'KRW') {
        return lang === 'ko' ? `${formattedPrice}원` : `₩${formattedPrice}`;
    }
    // currentCode === 'USD'
    return `$${formattedPrice}`;
}

// 사용자가 KRW, ko로 설정한 경우
formatPrice(1000, 'KRW', 'ko') // 1000원

// 사용자가 KRW, en으로 설정한 경우
formatPrice(1000, 'KRW', 'en') // ₩1000

// 사용자가 USD로 설정한 경우
formatPrice(1000, 'USD', 'ko') // $1000

이러한 의존성은 renderHook이나 Provider 로 감싸주는 것처럼 리액트에 특수한 로직 없이 손 쉽게 테스트할 수 있습니다. qwik 같은 다른 프레임워크에서도 사용할 수 있고요.

하지만 이러면 매번 매개변수로 3개씩 넘겨야 하니 번거롭습니다. 그래서 context의 의존성을 주입해준 custom hook을 만들 수 있습니다.

export const useFormatPrice = () => {
    const { lang } = useTranslation('common');
    const currency = useCurrencyValue();

    return {
        formatPrice: (price: number | null, currencyCode = currency.code, lang = lang) => formatPrice(price, currencyCode, lang)
    };
};

const { formatPrice } = useFormatPrice();

formatPrice(1000) // 1000원
formatPrice(1000, 'USD') // $1000

이렇게 특정 매개변수를 채워둔 새로운 함수를 만드는 기법을 함수형에서는 부분 적용 혹은 커링이라고도 부릅니다.

의존성이 없는 순수 함수는 서버에서도 브라우저에서도 잘 돌아갑니다. 이는 여러 라이브러리들도 비슷한 전략을 쓰고 있으니 참고해보시면 좋습니다.

component에 prop을 명시적으로 주입하기

비슷하게 컴포넌트도 순수 함수로 만들고 props를 이용해 명시적으로 의존성을 넘기는 방법이 있습니다. props도 함수의 매개변수일 뿐이니까요. (class 객체지향에서는 생성자 주입이라고도 부릅니다.) 과거에는 props를 이용해 의존성을 주입하는 게 당연한 방법이었습니다. 그 당시에는 고차 컴포넌트를 이용해서 컴포넌트에 특정 props를 부분 적용했지요. 위에서 말한 부분 적용과 다르지 않습니다. 지금도 next-translate 같은 라이브러리는 hook을 이용한 방법과 고차 컴포넌트를 이용한 방법을 둘 다 지원하고 있습니다.

import React from 'react'
import withTranslation from 'next-translate/withTranslation'

class ErrorBoundary extends React.Component {
  render() {
    const { t, lang } = this.props.i18n

    return <p>{t('common:error-title')}</p> // <p>에러가 발생했습니다!</p>
  }
}

export default withTranslation(ErrorBoundary)

그런데 hook이 나오고 나서는 props의 타입을 정의하고, 고차 컴포넌트를 만드는 게 번거롭기도 하고요. hook은 import만 하면 쉽게 가져다 쓰고 합성할 수 있으니, 점점 props를 이용한 주입 방식이 잊혀져 가고 있었습니다만…

server side rendering이 나오면서 이야기가 좀 달라지기 시작했습니다. nextjs의 pages 라우터를 사용해보신 분들은 아시겠지만, getServerSideProps를 이용해서 Page에 서버에서 가져온 데이터를 주입합니다. 서버 컴포넌트에서도 클라이언트 컴포넌트에 props을 이용해서 명시적으로 데이터를 넘겨주고요. 만약에 props를 받지 않고, 특정 상태 라이브러리에서 hook으로 데이터를 가져올 거라고 가정했다면 이런 변화에 적응하기가 어려울 겁니다.

그러니 hook을 쓰지 말자는 것은 아닙니다만. (저도 props를 이용한 주입은 자제하는 편입니다.) props를 이용한 주입 방식이 번거로워보일지라도, 좋은 대안 중 하나라는 걸 기억해주시면 좋겠습니다.

필요한 곳에만 의존하기 aka 인터페이스 격리의 원칙

매개변수는 필요한 것만 받고, 서로 다른 로직의 인터페이스는 분리하는 게 좋습니다.

함수나 커스텀 훅을 만들다보면 거대한 타입을 만들고, 타입 의존성을 이곳저곳에 퍼트리고는 합니다. 이러면 결합도도 높아지고, 테스트도, 사용도 어려워집니다.

예를 들어 저희 팀에는 상품의 상태를 판정하는 코드가 있는데요. 상품의 딱 필요한 데이터 4개에만 의존을 하게 되어 있습니다.

import type { GoodsStatusT } from 'Types';

export type ComputedGoodsStatusT = 'ready' | 'soldout' | 'quit' | 'comingsoon';

export function computeGoodsStatus(
    {
        startDate,
        endDate,
        status
    }: {
        startDate?: number; // 판매 시작 시각
        endDate?: number; // 판매 종료 시각
        status?: GoodsStatusT; // 서버에서 지정한 상품 상태
    },
    now: number
): ComputedGoodsStatusT {
    // 이하 로직
}

그런데 코드리뷰를 하다보면, api에서 가져온 데이터를 Type 정의에 다 집어 넣는 경우를 보고는 합니다. 당장은 편리하고 간결해보입니다.

import type { GoodsStatusT } from 'Types';
import type { GetGoodsResponse } from '@knowmerce/store-api-goods';

export type ComputedGoodsStatusT = 'ready' | 'soldout' | 'quit' | 'comingsoon';

export function computeGoodsStatus(
    {
        startDate,
        endDate,
        status
    }: GetGoodsResponse, // <- api에서 가져온 타입을 그대로 넣었습니다.
    now: number
): ComputedGoodsStatusT {
    // ... 이하 생략
}

하지만 이러면 computeGoodsStatus는 GetGoodsReponse에만 사용할 수 있게 됩니다. 예를 들어 저희는 상품을 선택하게 도와주는 Bundle이라는 게 있는데요. Bundle에도 startDate, endDate, status가 다 있고 로직도 똑같습니다. (똑같아야 합니다) 그런데 이러면 bundle을 위한 로직은 새로 복사 붙여넣기해서 만들어야 하죠.

테스트도 어려워집니다. 원래 이 순수 함수는 매개 변수가 몇 개 되지 않으니, 다음처럼 쉽게 테스트할 수 있었습니다.

const 시작전 = unixDate(2019, 12, 31, 23, 59);
const startDate = unixDate(2020, 1, 1);

test('startDate 이전이면, comingsoon 이다', () => {
    expect(computeGoodsStatus({ status: 'ready', startDate }, 시작전)).toBe('comingsoon');
});

하지만 이제는 객체를 통째로 만들어서 넘겨줘야 합니다. 상품이 판매 중인지를 판단하는 것과 무관한 상품 이름이랑 설명, 이미지 등등을 전부 가짜로 만들어야 하죠. 만약에 api에 새로운 필드가 추가되거나, 백엔드에서 필드명을 바꾸게 된다면 로직도 테스트도 고쳐야할 것입니다.

test('startDate 이전이면, comingsoon 이다', () => {
    expect(computeGoodsStatus({
        status: 'ready',
        startDate,
        id: 333,
        name: '드림캐쳐 (Dreamcatcher) 8th Mini Album [Apocalypse : From us] [W ver.] (한정반)',
        description: '...상품 설명...',
        body: '매우 긴 상품 상세 설명',
        image: 'https://my-awesome-domain/images/333/f0ca6dc0-2494-406b-8250-8c4bd03d76f2_1683775448296',
        // ... 이하 생략
    }, 시작전)).toBe('comingsoon');
});

왜 이렇게 되었을까요? 이 함수를 사용하는 사용자에게 너무 많은 걸 요구했습니다. 우리가 통제할 수 없는 서버의 타입에 강결합되었고요. 우리의 관심사와 무관한 인터페이스를 뒤섞었기 때문입니다.

문제의 해결책은 간단합니다. 인터페이스 사용자에게 최소한만 요구하고, 서로 다른 인터페이스를 뒤섞지 않으면 됩니다. 귀찮더라도 인터페이스를 분리하시고 작은 타입을 여러 개 만드시는 게 좋습니다.

context를 이용한 의존성 주입

마지막으로 context와 모듈에 대한 이야기를 해보겠습니다.

많은 분들이 react의 context api를 리덕스 같은 상태 관리 도구로만 오해하시고는 하는데요. 그렇다고 하면 좀 이상한 게 많습니다. 다들 이야기하지만 리렌더도 최적화되지 않고요. redux나 jotai 같은 라이브러리를 같이 써야 합니다.

jotai 같은 라이브러리는 Provider가 필요 없는 Provider less 모드를 지원하기도 하고요. 전역 singleton 객체를 이용해서 비슷한 기능을 지원하는 경우도 많습니다.

context api가 정말 상태를 관리하나 생각해보면 꼭 그럴 필요는 없습니다. 대부분은 거의 변하지 않는 정적인 것들만 구독합니다.

특히 props을 이용한 의존성 주입이 번거롭고, 컴포넌트 계층을 넘나들면서 의존성을 주입해야 할 때 편리한 도구지요. 앞서 이야기한 것처럼 props을 이용해서 의존성 주입을 하다보면 번거로우실 때가 많을텐데요. 그런 props 내리기 문제는 사실 객체지향이나 백엔드에서도 늘 있는 일이고, 다들 의존성 주입 문제라고 생각합니다. (생성자에 생성자에 생성자…)

다른 프레임워크를 써보신 분은 아시겠지만, context api는 의존성 주입 도구로 많이 쓰입니다. context api와 유사한 기능을 vue에서는 provide / inject라 부릅니다. svelte는 getContext와 setContext라고 하고요. 서버 프레임워크들에서는 context가 db connection이나 로그인한 정보 같은 외부 의존성을 들고 있습니다.

vue에서 쓰는 용어가 특히 주의를 기울일만 합니다. inject? 클래스 객체지향 언어에서 의존성 주입(Dependency Injection)을 해보신 분은 아시겠지만, 의존성을 ‘주입’한다는 말입니다.

react에서도 context api는 보통 의존성을 주입하는 용도로 씁니다. redux나 jotai 같은 상태 라이브러리는 store를 context api로 주입하고 사용합니다. react-router-dom은 Provider를 이용해 구현체를 갈아 끼울 수 있었습니다. (MemoryRouter, HashRouter 같은) tanstack-query는 QueryClient를 context로 주입합니다. 그래서 test를 위해 가짜 의존성을 주입할 때에도 이런 Provider를 사용하죠.

context API는 열등한 리덕스가 아닙니다. context는 자주 변하는 상태보다는, 사용자 설정이나 테마, 위에서 말한 것처럼 자주 변하지 않는 의존성인 경우가 더 많습니다.

예를 들어서 위의 예시에서 저는 currency나 lang을 component의 props로 받지 않고, useCurrencyValue나 useTranslation 같은 훅을 이용해서 받았는데요. 이 역시 일종의 context를 주입 받았다고 할 수 있겠습니다.

// props로 주입
function Component({ currency, lang }: { currency: CurrencyCodeT, lang: LanguageCodeT })

// Context로 주입
function Component()
    const { lang } = useTranslation('common');
    const currency = useCurrencyValue();

context 주입은 쉽게 합성할 수 있고, 매번 타입을 작성할 필요도 없어서 편리합니다만. react 환경에서만 쓸 수 있어, qwik 같은 다른 프레임워크나 getServerSideProps처럼 다른 환경과 로직을 공유하진 못합니다. 그래서 저는 보통 순수한 로직을 만들고, react 환경에 특수한 의존성을 context로 주입 받는 hook을 만들어 사용하는 편입니다.

module alias와 importmap을 이용한 의존성 주입

그런데 리액트 팀의 Sebastian은 Context를 이용한 런타임 의존성 주입보다는 정적인 module alias를 더 선호한다고 합니다. 심지어 Runtime dependency injection is the worst thing ever라고 강도 높게 비판할 정도인데요. 특히 subtree마다 다른 의존성을 주입해주는 게 아니라, 앱 전체의 전역 의존성을 주입하는 경우에는 특히 그렇다고 합니다.

그 이유는 이해가 갑니다. 런타임 의존성 주입은 성능상으로 느리고요. 앱 초기화에 시간이 오래 걸리게 합니다. 스프링이나 네스트로 백엔드 개발을 해보신 분은 공감하시지 않을까 싶네요 ^^ 변경되지 않는 의존성이라면 특히 정적으로 링크하는 게 좋고, 동적으로 주입하는 건 더욱 비효율적입니다.

그렇다면 sebastian이 제시하는 대안인 정적인 module alias는 무엇일까요? webpack이나 vite 같은 번들러의 module alias 기능을 이용하면 특정 모듈을 import하는 코드를 쉽게 바꿔치기 할 수 있습니다. 보통은 js에서 절대 경로 import를 구현하기 위해 쓰이고는 합니다.

예를 들어 next로 개발하다보면, vitest나 storybook 같은 테스트 환경에서 next/link나 next/image 등이 작동하지 않고는 했습니다. 그러면 보통 이러한 환경을 mocking하려고 고생하게 되는데요. laddle이라는 스토리북 대체 프레임워크의 문서에서는 더 단순한 방법을 제안합니다. 테스트를 위한 가짜 구현체로 next에서 import하는 모듈을 바꿔치기하는 것이죠.

import path from "path";
import { defineConfig } from "vite";

export default defineConfig({
  resolve: {
    alias: {
      "next/image": path.resolve(__dirname, "./.ladle/UnoptimizedImage.tsx"),
      "next/link": path.resolve(__dirname, "./.ladle/UnoptimizedLink.tsx"),
    },
  },
});

const UnoptimizedLink = (props: any) => {
  return <a {...props} />;
};
export default UnoptimizedLink;

const UnoptimizedImage = (props: any) => {
  return <img {...props} />;
};
export default UnoptimizedImage;

이 방법은 테스트를 위해서도 유용하지만, 다양한 환경을 지원해야 하는 프로젝트를 만들 때에도 유용합니다. 예를 들어 저는 하나의 코드베이스로 웹과 데스크탑 앱(tauri), 모바일 앱(capacitor)을 모두 지원하는 프로젝트를 만든 적 있는데요. vite.config를 3개 만들어서 각 환경마다 다른 의존성을 주입해서 빌드하도록 했었습니다.

앞서 말한 것 같은 기술스택을 migration 하는 상황에도 유용합니다. 기존의 의존성과 인터페이스가 호환되는 어댑터를 만드신 다음, module alias로 처리하시면 기존 코드를 건드리지 않고도 새 기술스택으로 프로젝트 전체를 마이그레이션할 수 있습니다.

예를 들어 react의 더 가벼운 구현체인 preact가 있는데요. preact 문서에서는 preact/compat이라는 호환 모듈로 alias해서 기존 react 프로젝트를 통째로 migration하는 법을 알려줍니다. 다양한 번들러에서 module alias를 하는 방법을 친절히 설명해주고 있으니, webpack이나 vite 가 아닌 번들러를 쓰시는 팀에서는 참고해보시면 좋겠습니다.

const config = {
   //...snip
  "resolve": {
    "alias": {
      "react": "preact/compat",
      "react-dom/test-utils": "preact/test-utils",
      "react-dom": "preact/compat",     // Must be below test-utils
      "react/jsx-runtime": "preact/jsx-runtime"
    },
  }
}

그러면 이런 module alias는 번들러를 사용해야만 쓸 수 있을까요? 새로 나온 importmap은 브라우저가 module을 resolve하는 방법을 지정하는 표준입니다. 번들러를 사용하지 않는 프로젝트에서도 쉽게 module alias를 설정하고, 여러 라이브러리들을 쉽게 import할 수 있습니다. js 백엔드 생태계에서는 deno 같은 런타임들도 잘 지원해주고 있습니다.

하지만 module alias는 한계가 있는 방법이기도 합니다. react로 server side rendering을 하다보면, 사용자나 request마다 상태나 의존성을 공유하면 안 되는 경우도 생기고요. 사용자 설정처럼 런타임에 바뀌는 상태 의존성도 경우도 있기 때문입니다. (자주 바뀌지는 않겠습니다만)

예를 들어 한 페이지는 KRW로 렌더되더라도, 다른 페이지는 USD로 렌더하고 싶을 수 있는데요. react-query나 jotai 등의 문서를 보시면 보통 런타임에 QueryClient나 store를 request마다 동적으로 만들어서 해결합니다.

import { Hydrate, QueryClient, QueryClientProvider } from 'react-query'

// query client를 정적으로 생성하면 모든 사용자가 query를 공유하게 됩니다 X
// const queryClient = new QueryClient()

export default function MyApp({ Component, pageProps }) {
  // 런타임에 동적으로 생성하면 렌더마다 격리됩니다 O
  const [queryClient] = React.useState(() => new QueryClient())

  return (
    <QueryClientProvider client={queryClient}>
      <Hydrate state={pageProps.dehydratedState}>
        <Component {...pageProps} />
      </Hydrate>
    </QueryClientProvider>
  )
}

저희는 실제로 이 처리를 까먹어서, 프로덕션에서 이슈로 이어진 적도 있습니다. 위에서도 언급했던 $61000 이슈인데요. KRW에서 USD로 통화 설정을 바꾸어도 계속 KRW로 렌더되어서 사용자 분들이 불편을 겪으셨죠…

이 기법은 테스트에서 상태를 격리할 때에도 흔하게 사용됩니다. 런타임 의존성 주입을 한 코드는 매 테스트마다 상태를 만들어서 쉽게 주입하고, 다른 테스트와는 격리할 수 있죠. 덕분에 여러 테스트를 동시(concurrent)에 병렬(parallel)로 돌려서 테스트를 빠르게 만들 수도 있고요. 테스트 러너의 값비싼 isolation이나 global 정리에 의존하지 않을수 있습니다.

예를 들어 저희의 vitest는 isolate 옵션을 끄면 2배 빨라졌고요. isolation을 지원하지 않는 bun test를 쓰면 157개의 typescript unit test를 실행하는데 0.1초 밖에 걸리지 않습니다. 정적인 의존성 주입으로 전역 상태를 공유하게 했다면 불가능했겠죠.

그리고 최근 JIT 컴파일이 자주 쓰는 코드는 inline 최적화 등을 통해 동적인 의존성 주입의 비용을 줄여주고 있습니다. 저는 js 뿐만 아니라 python이나 lua 등의 언어에서 다양하게 실험을 해보고 있는데요. 평범한 인터프리터와 달리 JIT compile을 하는 구현체에서는 초기화 이후에는 큰 차이가 없어서 신기하게 생각했던 기억이 있습니다.

모든 의존성 주입 방법은 각자 장점과 한계가 있으니, 어떤 의존성을 어떻게 관리할지 고민해보시면 좋겠습니다. 항상 정적인 의존성 주입만 쓰거나, 항상 동적인 의존성 주입만 쓸 수는 없기 때문입니다. 내가 특정 이슈나 문제로 크게 고통 받았다고 해서, 그 방법론 자체가 the worst thing ever라고 단정지어서는 안 되겠습니다. 물론 현명한 사람도 그런 실수를 할 때가 있지만요.

결론

아직 하고 싶은 이야기가 많지만, 아쉽게도 이미 이야기가 많이 길어져서 이만 줄여야할 것 같습니다. 지금까지 한 이야기를 추상적으로 요약해볼테니, 구체적 예시들을 떠올려보시면서 천천히 읽어보시죠.

저희는 의존성을 제공하기도 하고 사용하기도 합니다. 의존성은 공개 인터페이스를 열어두고 호환성을 약속하며 내부 구현을 리팩터링을 해나갑니다. 하지만 슬프게도 인터페이스의 한계를 만나면 파괴적 변경을 만들면서 메이저 버전을 올리기도 합니다.

파괴적 변경이 일어나면 사용자들은 코드를 대량으로 수정해야 하기 때문에 고통스러워집니다. 그래서 보통은 우리가 소유한 인터페이스를 정의해서 추상에 의존하지, 특정 구현에 의존하지 않도록 제어의 역전을 해서 사용합니다. 외부 의존성을 감싸는 어댑터를 만들어서 우리의 인터페이스에 맞추도록 하곤 합니다.

class 기반 객체지향 생태계와 달리, 함수 생태계에서는 주로 순수 함수를 이용합니다. 의존성이 없고 예측 가능한 순수 함수에 명시적으로 의존성을 넘기면, 서버나 브라우저 같이 다양한 환경을 쉽게 지원할 수 있습니다. 테스트하기도 물론 쉬워지고요. 하지만 매개변수가 너무 많으면 번거롭기 때문에, 보통은 의존성을 미리 부분 적용한 함수를 만들어서 사용합니다. props를 통해 컴포넌트에 의존성을 주입하는 것도 매개변수를 이용한 주입과 똑같고, class에서는 생성자 주입과 유사하게 생각할 수 있습니다.

의존성의 인터페이스를 설계할 때에는 사용자에게 필요한 최소한만 요구하는 게 좋습니다. 여러 관심사가 인터페이스에 뒤섞이면 다양한 환경에서 사용하기 어렵고, 테스트하기 어려운 코드가 됩니다. 이를 인터페이스 격리의 원칙이라고도 부릅니다.

react의 context API는 주로 상태 관리보다는 의존성 주입 도구로 더 널리 쓰입니다. vue나 svelte 같은 다른 프레임워크도 유사한 방법을 지원합니다. 매개변수를 받고 넘기고를 반복할 필요 없이, 컴포넌트 tree를 뛰어 넘어서 쉽게 context를 주입할 수 있습니다.

하지만 런타임 의존성 주입은 번거롭고, 성능 이슈가 있을 때도 있습니다. 번들러는 정적으로 module alias를 통해 빌드시에 설정한 의존성과 연결해줍니다. 이는 강력한 방법이지만, 런타임에 request나 test마다 상태가 격리되어야 하는 경우에는 사용하기 어렵습니다. 상황에 따라 어떤 방법이 좋은지는 개인의 경험이나 안 좋은 기억이 아니라, 실험과 벤치마크, 프로젝트의 맥락을 자세히 살피고 결정해야 합니다.

세상에 의존성을 관리하는 방법은 이 외에도 매우 많고 다양합니다. 의존성의 의존성을 초기화하는 의존성 그래프라거나, 의존성 scope, 직접 의존성을 판단해서 선택하는 의존성 선택, event나 message를 이용해서 느슨한 결합으로 의존성을 격리하는 법도 있고요. pandacss나 tailwind가 CSS라는 표준을 정적 컴파일러와 결합해서 다양한 프레임워크를 지원하는 것도 흥미롭습니다. 최근에 SSR이 도입되고 서버와 클라이언트라는 두 개의 환경을 지원하게 되었다거나. 저희처럼 다양한 프레임워크를 쓰는 팀에서 공통 로직을 관리하면서 생각해볼 점도 점점 많아지고 있지 않나 싶습니다. 언젠가 남은 이야기도 할 수 있는 시간이 생기길 바랍니다.

긴 글 읽어주셔서 감사합니다. 여러분이 프론트엔드 의존성에 덜 휘둘리고, 더 통제권을 가지실 수 있기를 바랍니다. 앞으로도 더 다양한 이야기를 들고 오겠습니다. 또 뵙죠.