RSS Feed of choi2021 DevLog

2025년 11월 회고

Sat, 06 Dec 2025 00:00:00 GMT

11월은 coverage growth silo에서 새로운 사업자 대상의 체크리스트 제품을 만들고, 숨은 환급액 찾기의 웹진출을 위한 백업 작업과 다음 세목 추가를 위한 작업들을 먼저 진행했다. 그리고 드디어 프론트에서도 개인 클러스터를 도입했다. 11월 한달간 작업들을 정리해보려 한다.

새로운 제품, 사업자 체크리스트와 새로운 세목을 위한 준비

사업자 체크리스트는 새로운 사업자 대상의 제품이 나가기 전, 현재 사업자 분들이 사업을 진행하면서 혜택을 받을 수 있는 부분들에 대해 잘 알고 있는지 파악하고, 정보를 전달하기 위한 제품이다. 제품 출시 후 아직 많이 사용되고 있지는 못한 상태지만, 우리 부모님은 잘 알고 계실까하는 궁금한 내용도 있어 앞으로 좀 더 디벨롭해가면 좋겠다는 생각이 들었고, 이후 확장할 세목 제품들에도 시너지를 낼 수 있기를 기대하고 있다.

이후에는 숨은 환급액 찾기와 함께 새로운 세목을 추가하기 위한 준비 작업을 하고 있다. 같은 제품 내 함께 녹이기 때문에 같은 제품 영역에 두가지 사일로 작업이 있다보니, 디자인이나 실험에 있어서 병목이 있을 거란 우려가 생겼다. 다행히 먼저 이부분에 대해 이슈 레이징 했을 때 컨버젼 사일로 분들께서 잘 공감해주셔서 먼저 새로운 세목이 추가되는 버전을 먼저 내보내 충돌없이 독립적으로 각각 작업할 수 있었다. 현재 준비중인 새로운 세목이 12월를 타겟팅하고 있기 때문에, 12월 회고에 조금 더 작성해 보려한다.

숨은 환급액 찾기 웹버전 백업과 이어지는 고민

컨버전 사일로의 노력으로 최근 숨은 환급액 찾기 서비스가 웹으로 출시되게 되었다. 팀이동을 하면서 직접 작업을 하지 않았지만, 이전 히스토리를 아는 사람으로서 새로 오신 두분의 백업을 맡아 조금씩 함께 이슈를 처리하며 백업을 진행했다. 백업을 진행하면서 웹쪽 코드를 보면서, 웹과 모바일 두가지 플랫폼에서 플랫폼 차이로 발생하는 관리의 어려움을 느낄 수 있었고, 앞으로 두가지 모두를 잘 관리하기 위해 여러가지 방법과 기술적인 고민도 필요하겠다는 생각이 들었다.

예를 들어 모바일과 웹 모두에서 똑같이 제보된 이슈를 수정할 때나, 단순 문구를 수정할 때도 항상 두가지 플랫폼 모두를 신경써서 작업해야한다는 점에서 앞으로 리소스가 2배 이상 쓰일 수 있는 작업들을 어떻게 하면 공통화할지, 또 다른 부분은 어떻게 처리할지에 대한 다양한 논의가 필요할 것 같다.

이런 고민들과 함께 새롭게 웹을 위한 인프라 세팅을 하면서 동료분이 어려움을 이야기 해주셨고, 인컴에서 인프라 관련 작업을 할 때의 어려움이 블랙박스로 남아 계속해서 어렵게 한다는 생각이 들었다. 내가 관심있는 분야이기도 하고, 현재 팀이 겪고 있는 문제이기도 하기 때문에 해당 세팅을 어떻게 하면 간편하게 할 수 있을지 등 고민해보려 한다.

프론트 개발 생산성을 위한 개인클러스터 도입

프론트 개발자가 2명에서 5명으로 늘어나면서, 기존 알파 환경을 사용하는 방식에 대해 문제가 커졌다. 2명에서는 기존에 바텀싯 형식으로 특정 개발자 이름으로 들어가면 해당 개발자의 결과물을 볼 수 있도록 별도 도메인과 서버를 연결해 해결하고 있었다. 여기에는 세가지 문제점이 존재하게 된다.

먼저 한명이 하나의 결과물만 알파 환경에서 테스트할 수 있다. 기존의 구현방식은 개발자 마다 하나의 도메인과 하나의 서버를 연결해 테스트할 수 있게 되어있었다. 이때 한명이 여러개의 작업에 대한 빌드 결과물을 보고 싶을 때는 기존 걸 revert한 후에 새로 올리거나 이전 작업이 main에 병합되어야 알파 환경과 연결된 브랜치에 연결해서 볼 수 있는 문제가 있었다.

두 번째로는 알파 환경 구현 방식으로 인한 테스트의 어려움이다. 라이브와 달리 알파는 develop 기준 도메인에 진입해 바텀싯을 띄우고나서, 선택한 도메인으로 진입하는 방식이기 때문에 테스트환경이 다르다. 이로 인한 사이드 이펙트로, 진입 시점에 실행되는 로직을 테스트할 때 이동 전에 먼저 실행되거나, 결과물이 develop에서 없는 페이지인 경우 404가 발생하는 이슈가 있었다. 또한 두번 웹뷰를 띄우면서 발생하는 사이드 이펙트로 인해 앱브릿지의 에러로 타팀에서 수정요청이 들어오기도 했다.

세 번째로는 인프라와 개발과정의 복잡성이다. 개발자가 한명 추가될 때마다 매번 별도의 파이프라인을 만들어, 새로운 브랜치와 바텀싯에 이름 추가, 새로운 도메인을 인식하기 위한 devops 팀의 작업이 필요했다. 또한 별도의 파이프라인으로 인해, 각각의 변경점을 감지하기 위해 타겟팅하는 dev/a, dev/b 등의 브랜치들이 만들고, 이러한 커스텀 git flow 전략으로 develop을 개인마다 가지고 것처럼 배포하다 보니, 계속 브랜치를 최신화하기 위한 관리가 더 많이 필요해지고, merge 커밋은 어떻게 할지 등 다양한 고민이 필요했다.

이러한 문제점을 한번에 해결하기 위해 개인 클러스터를 도입하게 되었다.

개인 클러스터는 먼저 개발자별 서버를 고정적으로 사용하는 게 아니라, 작업별 서버를 만들는 방식으로 같은 요청이 들어와도 특정 헤더 를 감지해, 해당 서버로 꺾어주는 gateway를 중앙에 두는 방식을 의미한다.

기존 이미지와 비교해 보면 아래와 같다

간단하게 생각해보면 바텀싯으로 웹에서 진행하던 부분을 게이트웨이에서 웹뷰를 띄울때 request header에 있는 헤더값을 감지해 필요한 서버로 라우팅을 하고, 해당 서버의 빌드 결과물을 가져오는 방식이다.

첫 번째 문제점이었던 개발자별 하나의 작업만 테스트 환경에 올릴 수 있는 문제가, 작업별 서버를 띄우고 해당 서버에 대한 설정을 헤더로 설정하는 작업을 하면 됨으로 해결되게 된다. 테스트를 할때는 헤더 설정을 앱내에서 수정하면 다른 작업으로 바로 진입할 수 있게 된다.

두번째 문제였던 테스트의 어려움 문제는 더이상 두번 웹뷰를 띄우지 않고 미리 설정한 헤더 값을 읽고 웹뷰를 띄워 alpha/tax-refunds로 한번만 진입하기 때문에 해결되게 된다.

세번째 문제였던 인프라와 개발과정의 복잡성은 파이프라인은 하나로 유지한 체로, 게이트웨이에 설정과 서버만 띄우면되기 때문에 devops팀 분들의 도움 없이도 알파환경 구성이 가능하다. git 전략은 이제 main을 기준으로 바로 작업 브랜치를 따고 개별 작업 서버를 띄우면 되기 때문에 TBD를 이용해 간단하게 운영이 가능하다.

1~2달 정도 devops 분들과 함께 이야기하고 요청드린 후에 어떻게 사용할지를 고민하고, 테스트한 후에 적용하게 되었다. 사용하는 프론트 개발자분들과 테스트하시는 사일로원분들, QA분들의 의견을 자주 들어 더 자주 배포하고, 더 빠르게 배포하는데 기여하는 좋은 개발 문화를 만들어가보려 한다.

돌아보는 11월의 액션아이템과 12월 액션아이템

11월의 목표는 아래와 같았다.

도커와 쿠버네티스 공부해보기
프론트 개인 클러스터 도입

현재 도커는 공부하고 있지만 아직 쿠버네티스까지 가지는 못했다. 대신 도커에 대한 이해도를 바탕으로 인컴 내 다양한 서비스의 인프라에 대한 이해도를 조금씩 올려가고 있다. 앞으로 다양한 서비스를 서빙해야하는 것에 대한 니즈가 있기 때문에 나만의 뾰족함을 만들어가기에도 좋을 것 같아서 계속해서 해보려 한다.

프론트 개인클러스터는 무사히 잘 도입했고 이후에는 더 잘 사용할 수 있게 사용성을 개선하기 위한 다양한 방식을 고민하고 적용하려 한다.

그래서 12월의 목표는 아래로 잡아보려 한다.

도커와 쿠버네티스 공부해보기
인컴 내 인프라 구조 정리하기
개인클러스터 사용성 개선하기

12월의 목표는 11월과 유사하지만 조금 더 인프라를 챕터내 자산으로 만들기 위한 문서화와, 관리 편리성을 위한 관리 방식 통일화에 대해 고민해볼 예정이다. 그와 함께 도커와 쿠버네티스를 계속해서 공부하고, 개인 클러스터가 아직 낯선 분들을 위해 조금 더 편하게 사용할 수 있게 사용성을 더 높여보려 한다.

매달 느끼지만 한달 한달 똑같은 걸 그냥 했다는 없는게 신기하다. 더 많은 걸 배우고 적용해보자.

2025년 10월 회고

Sun, 09 Nov 2025 00:00:00 GMT

10월은 1년 가까이 함께 했던 conversion boost silo에서 새로운 coverage growth silo로 이동을 결정하고, 새로운 제품을 위한 준비를 하는 시간을 가졌다. 준비하는 동안에 새롭게 내부 제품인 어드민 관련 작업을 담당하고, 드디어 5명이 된 프론트엔드 챕터의 새로오신 동료분들의 온보딩을 도와드리고 함께 협업을 위한 토대를 다지는 시간을 가졌다.

1년간의 토스와 팀 이동

글을 쓰는 오늘 11월 9일 기준으로 2024년 11월 4일 토스 코어에 입사 후, 1년동안 숨은 환급액 찾기 서비스를 만들어왔다. 숨은 환급액 찾기를 만들면서 개발자로서, 많이 성장했던 것 같다. react native를 이용한 앱 개발에서 프론트 개발을 해보고 싶다는 생각으로 지원해, 토스의 프론트엔드 멘토링 프로그램에 참여하고 토스에 입사하기까지 많은 작업들을 해왔다.

연말정산 미리보기와 같은 인플로우 이벤트 작업부터 스크래핑, 공제, 결제, 신고까지 전반의 복잡한 퍼널까지 기술적인 부분이나 더 잘 만들기 위한 노력과 도메인에 대한 이해도를 높이는 시간이었던 감사한 시간이었고, 부끄럽지만 도메인을 가장 잘 아는 사람 중 하나라고 여겨지는 것 같다.

그러면서 한편으로 컴포트존에 있다는 느낌을 받았다. 당연하게도 시간이 흐르면서 익숙해진 부분들이 생기고, 반복되는 작업 속에서 개발자로서 성장할 수 있는 부분들에 대한 고민이 깊어져 같다. 코어에서 인컴으로 전적을 결정했던 순간처럼, 팀을 옮기는 결정을 통해서 조금 더 새롭게 부딪히기를 바랬고, 내가 회사 밖에서도 무언가를 만들 수 있는 사람이 되기를 바랬다.

회사에서는 큰 문제를 푸는 법을 배우고, 언젠가 회사 밖에서 살아가기 위한 무기를 많이 배워나가는 시간이 되어야 하지 않을까라는 생각이 커져가면서, 단순히 프론트 개발자인 것을 넘어서 개발자로서 조금 더 큰 시야에서 시스템을 이해하고 싶었다. 처음부터 무언가를 만드는 경험을 해보고 싶었고, coverage growth 사일로로 옮기기로 결정했다.

기존의 숨은 환급액 찾기와 함께 더 시너지를 낼 수 있게 다양한 신규 제품을 고민하고 더 성장할 수 있는 0 to 1을 더 고민하는 팀으로, 조금 더 새로운 도전을 하면서도, 숨은 환급액 찾기에 대한 이해도를 바탕으로 제품과 다양한 사일로의 작업을 서포트하기에도 좋은 곳이라 생각했다. 새로운 곳에서 다시 신뢰를 쌓아 나가며, 새로운 무언가를 만들면서 내가 목표로 하는 모습을 이뤄가기를 바라본다.

공제 퍼널 개편

새롭게 월세공제를 제공하게 되면서, 공제 퍼널이 길어지게 되었고 그에 따른 유저경험 개선이 필요하다는 생각이 커졌다. 평소 고민하고 있던 구간이었기 때문에, 짬짬히 어떻게 개선하면 좋을까 정리해두었고 정리해둔 내용을 바탕으로 현재 공제 구간을 개선할 수 있었다.

숨은 환급액 찾기 내 공제구간은 유저의 환급액을 계산하기 위해 수정할 수 있는 공제들이 있다. 예를 들면, 부양가족, 신용카드 공제 등이 있고 현재의 문제는 해당 구간들을 항상 모두 거쳐야 한다는 점이었다. 예를 들어 유저 A는 부양가족, 신용카드, 의료비 공제만 있는 상태라면 해당하는 공제 뿐 아니라 다른 공제들 예를 들어 이번에 추가한 월세공제, 중소기업 취업 감면 등의 페이지를 모두 진입한 후에 해당하는지 체크해, 다음으로 넘어가는 로직으로 구현되어 있었다.

function 의료비Step() {
    const [의료비공제_해당, set의료비공제_해당] = useState(false);

    useEffect(() => {
        const 의료비공제_해당 = await 의료비공제해당확인();
        set의료비공제_해당(의료비공제_해당);

        if (!의료비공제_해당) {
            다음_공제로_이동();
        } else {
            set의료비공제_해당(true);
        }
    }, []);

    if (!의료비공제_해당) {
        return <로딩 />;
    }

    return <의료비공제_화면 />;
}

function 공제퍼널() {
    // ...
    return (
        <Funnel.Render
            의료비={() => (
                <의료비공제Step
                    onNext={() => history.push("다음스텝")}
                />
            )}
            <!-- ... -->
            마지막공제={() => (
                <마지막공제Step
                    onNext={async () => await 공제입력완료()}
                />
            )}
        />
    );
}

위와 같이 구성되면 각 스텝에서 판단을 담당하기 때문에 코드적으로는 명확한 장점을 가지지만, 불필요한 공제 스텝 화면들에 들어가면서 불필요한 계산을 하는 동안 로딩 화면이 오래 노출되는 문제가 있다.

이를 개선하기 위해 유저별로 항상 받아야 하는 공제 내용을 체크하고 동적으로 다음 스텝을 결정하도록 수정하고, 공제 내부의 입력 가능한지 판단하는 로직은 덜어내 유저경험을 개선했다.

function 의료비Step({ onNext }) {
    return <의료비공제_화면 onNext={onNext} />;
}

function 공제퍼널() {
    const 다음스텝_계산 = async (현재공제) => {
        const 입력대상_공제목록 = await get입력대상_공제목록();
        const 현재공제_index = 입력대상_공제목록.findIndex(
            공제 => 공제.id === 현재공제.id
        );
        const 다음공제_index = 현재공제_index + 1;

        if (다음공제_index >= 입력대상_공제목록.length) {
            return null; // 마지막 공제
        }

        return 입력대상_공제목록[다음공제_index];
    };

    const 다음스텝으로_이동 = async (현재공제) => {
        const 다음공제 = await 다음스텝_계산(현재공제);
        if (다음공제) {
            history.push(다음공제.id);
        } else {
            공제입력완료();
        }
    };

    return (
        <Funnel.Render
            의료비={() => (
                <의료비Step
                    onNext={() => 다음스텝으로_이동({ id: '의료비' })}
                />
            )}
            <!-- ... -->
            마지막공제={() => (
                <마지막공제Step
                    onNext={async () => await 공제입력완료()}
                />
            )}
        />
    );
}

간단히 리팩토링한 코드를 보면 기존과 달리 공제 스텝별 판단 로직을 상위로 옮김으로써, 공제 스텝은 렌더링만 담당하도록 보다 간단해졌고 퍼널의 흐름을 담당하는 공제 퍼널 화면에는 다음 스텝이 어떤 스텝인지 계산하는 로직을 담당해, 불필요한 화면 이동 없이 필요한 화면만 보여주도록 개선할 수 있었다.

해당 개선으로 QA 팀분들의 도움을 받아, 전체적인 유저 플로우를 자동화로 돌려보았을 때 기존 8초 정도 걸리던 공제 퍼널을 1.5초~3초로 개선해 최대 약 40%의 로딩 시간을 단축할 수 있었다.

당시 무조건 모든 공제를 거치게 되어있었던 이유는 서버의 계산 방식과 서버분들도 완전히 이해하기 어려웠던 레거시 로직들이 점점 가시화되고, 함께 리팩토링 작업을 하면서 알려주신 엔진 계산 로직에 대한 이해도가 늘어가면서, API 호출 순서 등 환급액 계산을 위해 필요한 부분이 어떤 건지 알게 되었고, 이를 바탕으로 이번 개선을 주도적으로 진행할 수 있었다. 앞으로도 단순히 내가 맡은 프론트 뿐만이 아니라 제품 전반에 좀 더 관심을 가져야겠다는 생각이 들었던 작업이었다.

2명에서 5명으로 일하기와 온보딩의 온보딩

프론트 개발자가 2명에서 5명으로 늘어나면서, 2명에서 일하는 법이 아닌 5명에서 일하는 방식을 만들어 가는 시간이 필요했다. 기존 2명에서는 당연했던 방식이 적절하지 않게 되면서 새롭게 문제로 떠오르게 되거나, 기존에 문제라고 느끼지 못했던 부분이 문제가 되는 점들이 있었다. 예를 들면 알고보니 각자의 스타일로 만들고 있었던 폴더, 파일 컨벤션으로 인해 어떤 걸 기준으로 만들면 좋을지에 대한 질문에서 시작해, 폴더, api 등 제품 전반에 대한 컨벤션을 함께 정하고 있다.

또한 필요한 부분들에 대해 적극적으로 의견을 주시거나, 직접 작업해주시면서 든든함을 느낄 수도 있었는데, cspell과 같은 툴을 알려주시기도 하고 코드 리뷰가 전보다 활성화되어 다양하게 의견을 들으면 더 좋은 제품을 만드는 감정을 느꼈다.

특히 팀을 옮기면서 새로오신 두분이 conversion boost silo로 오시게 되어, 온보딩을 두 분과 함께 진행하게 되었다. 누군가에게 배우기만 하던 내가 누군가에게 전달하는 경험은 처음이었다. 말그대로 온보딩의 온보딩을 진행하게 된것이다.

"내가 설명을 잘하고 있는 걸까?", "내가 하는 방식이 정답이 아닌데 무조건 받아들이시면 안되는데" 등 다양한 고민을 하면서, 온보딩 과정이 괜찮은가 자주 물어보고 좀 더 좋은 방법이 없을까 고민해보기도 했다. 고민하며 선택한 방식은 함께 스펙을 보고 내가 작업한다면 생각하며 todo를 직접 짜고, 먼저 작업을 해보는 것이었다. 조금 과했던 것 같기는 하지만 전달드리기 위해서는 내가 먼저 이해해야한다고 생각하다보니 사실상 pr만 안올렸지 작업을 먼저 한번씩 해보고 todo로 만들어 전달하는 시간을 가졌다.

다행히 두분 모두 이야기해보았을 때, todo로 만들어 함께 필요한 부분들을 하나씩 전달드리는 방식이 좋았다는 피드백을 받기도 했다. 토스라는 큰 팀에는 워낙 히스토리가 많다보니 필요한 부분을 잘 정리해 드리는게 좋았다고 의견을 주셨다.

내가 무언가를 해야 속이 편하고, 내가 하는 무언가에 대해 고민이 많았던 나에게, 새로운 분들을 도와드리면서 오히려 함께 만드는 것의 기쁨을 더 배우는 시간이 되었다. 이와 함께 기존에 가지고 있던 혼자 다 해야한다는 부담감들을 점점 내려놓을 수 있었고, 드디어 "여유"라는 게 생길 수 있었다.

팀의 생산성을 위한 부분들에 대해, 제품 개발에 조금 더 시간을 집중할 수 있게 도와드릴 수 있는 방법을 더 고민하고 있고 기존 개발 테스트 방식과 배포 방식의 문제점을 해결하기 위한 개인클러스터를 도입해보려고 인프라팀과 함께 이야기하고 개인적으로 인프라를 더 공부해보고도 있다.

돌아보는 10월의 액션아이템과 11월 액션아이템

10월의 목표는 아래와 같았다.

히스토리 문서화 하기
인프라와 모노레포 구조 공부해보기

드디어 숨은 환급액 찾기 전체에 대한 히스토리 문서 작성 완료했다. 꽤나 오래 걸렸지만, 그래도 새로 입사하신 분들 뿐 아니라, QA분들까지 봐주시고 계신 것 같아 뿌듯했다. 이와 함께 추석에 모노레포에 대해 공부해보았고, 미뤄뒀던 aws 관련 책을 읽으면서 어떻게 인프라가 구성되어 있는지 이해도를 높이고 있다. 생각보다 재밌어서 더 공부해보고 프론트 인프라 부분들과 개발 환경 개선을 위한 작업도 진행해보면 좋을 것 같다는 생각이 들었다.

11월의 목표는 아래로 잡아보려 한다.

도커와 쿠버네티스 공부해보기
프론트 개인 클러스터 도입

aws 뿐 아니라 도커나 쿠버네티스와 같은 devops 관련 지식들도 공부해보려 한다. 최근 웹 서비스를 준비하면서 신규 배포가 필요한데 다양한 인프라 문제를 겪으시는 것을 보면서 내가 조금 더 잘 알고 있다면, 도움을 드렸을 텐데 아쉬움을 느꼈다.

개인 클러스터를 통해서 보다 다양한 작업을 진행해 프론트 개발자별로 n개의 개별 결과물을 테스트할 수 있게 개선해 팀 전체 생산성도 높여보려 한다. 1년을 다녀도 매번 새로운 토스 생활, 또 다시 성장하는 한달로 만들어보자.

모노레포 이해해보기

Sun, 12 Oct 2025 00:00:00 GMT

모노레포란?

모노레포(Monorepo)는 여러 프로젝트를 하나의 저장소에서 관리하는 개발 전략이다. 현재 내가 일하고 있는 토스에서도 다양한 글과 발표를 했을 정도로, 여러 프로젝트를 동시에 운영해야할 때 문제점을 해소하기 위해 채택하고 있다.

그러면 멀티 레포 방식의 어떤 문제를 해결하기 위해 모노레포를 선택하는 것일까?

멀티 레포의 문제점

공통 로직을 shared 패키지로 분리하고, 이를 여러 서비스(a, b)에서 사용하는 상황을 가정해보자. 패키지 매니저는 npm인 상황이다.

프로젝트 구조
├── shared/          (공통 로직)
├── service-a/       (서비스 A)
└── service-b/       (서비스 B)

1. 패키지 배포 및 버전 관리의 복잡성

shared를 import하려면 별도 패키지로 npm에 배포하고, 각 서비스에서 해당 버전을 명시해야 한다.

// service-a/package.json
{
  "dependencies": {
    "shared": "^1.0.0" // npm에 배포된 버전
  }
}

이때 Atomic 변경이 불가능하다는 치명적인 문제가 있다:

shared 수정 → npm 배포 → service-a, service-b의 버전 업데이트
shared에서 에러 발생 시, 모든 의존 서비스를 롤백해야 함

shared를 의존하는 서비스가 늘어날 수록 총 N+1개의 PR, N+1개의 리뷰, N+1번의 배포가 필요하다보니 개발 비용이 크게 늘어나는 상황이 된다.

2. 중복된 node_modules로 인한 리소스 낭비

모노레포와는 조금 다른 npm 패키지 매니저의 문제이지만 여러 서비스를 npm으로 운영했을 때의 문제점으로, 각 서비스가 독립된 node_modules를 가지면서 동일한 패키지가 중복 저장된다.

monorepo/
├── shared/
│   └── node_modules/              # 약 50MB
│       ├── lodash@4.17.21/        (500KB)
│       ├── axios@1.6.0/           (1.2MB)
│       └── typescript@5.3.0/      (30MB)
│
├── service-a/
│   └── node_modules/              # 약 250MB
│       ├── lodash@4.17.21/        (500KB) ← 중복!
│       ├── axios@1.6.0/           (1.2MB) ← 중복!
│       └── typescript@5.3.0/      (30MB) ← 중복!
│
└── service-b/
    └── node_modules/              # 약 280MB
        ├── lodash@4.17.21/        (500KB) ← 또 중복!
        ├── axios@1.6.0/           (1.2MB) ← 또 중복!
        └── typescript@5.3.0/      (30MB) ← 또 중복!

총 디스크 사용량: 580MB
실제 고유 패키지: 약 250MB
중복: 330MB (57% 낭비!)

3. 코드 검색의 어려움

저장소 경계로 인해 전체 코드베이스를 대상으로 검색하거나 리팩토링하기 어렵다. 특정 함수가 어디서 사용되는지 추적하려면 여러 저장소를 오가며 확인해야 한다.

4. 팀 협업 비용 증가

3개 저장소의 컨텍스트를 모두 이해해야 함
의존성 변경 시 여러 저장소에 걸친 코드 리뷰 필요
로컬 개발 환경 설정 복잡성 증가

모노레포로 해결하기

모노레포는 위 문제들을 근본적으로 해결한다:

✅ 단일 커밋으로 Atomic 변경: shared와 서비스를 동시에 수정하고 하나의 PR로 배포
✅ 패키지 중복 제거: 공유 캐시를 통해 디스크 사용량 최소화
✅ 통합 검색 및 리팩토링: 전체 코드베이스를 대상으로 작업 가능
✅ 간소화된 협업: 하나의 저장소에서 모든 것을 관리

여러가지 모노레포 구성 방식이 있지만, 간단히 토스에서 현재 사용하고 있는 Yarn PnP에 workspace를 더한 방식으로 구현해보려 한다.

Yarn PnP + Workspace

Yarn Berry의 Plug'n'Play(PnP)와 Workspace 기능을 조합하면 강력한 모노레포를 구축할 수 있다.

Yarn PnP의 장점

1. Minimal install footprint

node_modules 폴더를 생성하는 대신 .pnp.cjs 파일 하나만 생성한다.

# 기존 방식
yarn install
→ node_modules/ (수백 MB ~ 수 GB)

# PnP 방식
yarn install
→ .pnp.cjs (수백 KB)

2. Shared installs across disks

글로벌 캐시 디렉토리(~/.yarn/berry/cache/)에 패키지를 저장하고, 모든 프로젝트가 이를 공유한다. pnpm의 경우 hard link로 같은 패키지더라도 개별로 관리해 메모리 사용량이 큰 반면, yarn pnp는 globalCache를 이용할 수 있어 같은 패키지면 같이 사용한다.

# enableGlobalCache: false (기본)
project-1/.yarn/cache/  (800MB)  ← 독립 캐시
project-2/.yarn/cache/  (600MB)  ← 독립 캐시
project-3/.yarn/cache/  (500MB)  ← 독립 캐시
총 사용량: 1.9GB

# enableGlobalCache: true
~/.yarn/berry/cache/    (900MB)  ← 공유 캐시
총 사용량: 900MB (52% 절약!)

3. Ghost dependencies protection

package.json에 명시하지 않은 의존성에 접근하면 에러를 발생시킨다. 호이스팅으로 인한 암묵적 의존성 문제를 방지한다.

// package.json에 lodash가 없는데 사용하면
import _ from "lodash"
// ❌ Error: lodash is not listed in your dependencies

4. Semantic erroring

import 에러 발생 시 더 상세한 정보를 제공한다.

❌ 기존: Module not found
✅ PnP: Package "react" is not listed in dependencies.
       Did you mean "@types/react"?

실제 구현 예시

프로젝트 구조

monorepo/
├── package.json           # 루트 설정
├── .yarnrc.yml            # Yarn 설정
├── .pnp.cjs               # PnP 매니페스트
├── shared/
│   └── package.json
├── service-a/
│   └── package.json
└── service-b/
    └── package.json

1. 루트 package.json

{
  "name": "monorepo",
  "version": "1.0.0",
  "workspaces": ["shared", "service-a", "service-b"],
  "scripts": {
    "start:a": "yarn workspace service-a start",
    "start:b": "yarn workspace service-b start"
  },
  "packageManager": "yarn@4.1.0"
}

위 루트 요소에서 주요 속성에 대해 정리해보자.

주요 속성:

private: true: npm 배포 방지
workspaces: 각 패키지 경로 지정
packageManager: Corepack이 사용할 Yarn 버전

여기서 Corepack은 Node.js에 내장된 패키지 매니저로 corepack을 사용하면 팀원 모두가 동일한 Yarn 버전을 사용할 수 있게 된다.

// package.json
{
  "packageManager": "yarn@4.1.0"
}

# 1. corepack 활성화
corepack enable

# 2. yarn 명령어 실행
yarn install
# → corepack이 yarn@4.1.0 자동 다운로드 및 실행

2. .yarnrc.yml

nodeLinker: pnp

enableGlobalCache: true

npmRegistryServer: "https://registry.yarnpkg.com"

주요 설정:

nodeLinker: pnp: PnP 모드 활성화
enableGlobalCache: true: 글로벌 캐시 사용
npmRegistryServer: npm 레지스트리 URL

3. 워크스페이스 패키지 설정

// shared/package.json
{
  "name": "shared",
  "version": "1.0.0",
  "main": "index.js"
}

// service-a/package.json
{
  "name": "service-a",
  "version": "1.0.0",
  "dependencies": {
    "shared": "workspace:*"
  }
}

workspace:* 프로토콜:

로컬 워크스페이스의 최신 코드를 항상 참조
버전 관리 불필요
변경 사항 즉시 반영

4. 워크스페이스 확인 및 실행

# 워크스페이스 목록 확인
yarn workspaces list
# shared
# service-a
# service-b

# 워크스페이스 정보 조회
yarn workspace service-a info
# ├─ service-a@workspace:service-a
# │  └─ Dependencies
# │     └─ shared@workspace:* → workspace:shared

마치며

내게 모노레포는 이미 세팅이 되어있다보니, 블랙박스와 같은 부분이었다. 인컴 서비스 규모가 커짐에 따라 서비스가 늘어나는 것이 예상되는 상황에서 어떻게 프로젝트들의 의존관계를 관리하면 좋을까 고민이되었고, 이번에 정리할 수 있었다.

이번 글에는 단순한 예제였지만, 여기에 배포 파이프라인과 인프라가 더해지면 더욱 복잡해지는데, 다음은 실제 Next 서비스를 여러개 있고, 배포하는 상황을 가정해서 배포 파이프라인을 구성하는 법을 고민해보고 정리해봐야겠다.

참고 자료

무중단 배포를 위한 Next.js Static 파일 관리 전략

Thu, 09 Oct 2025 00:00:00 GMT

2025 9월 회고에서 이야기했던 배포할 때마다 발생하던 에러를 디버깅하면서 알게 된 Next.js 빌드 결과물의 구조와 올바른 배포 전략을 정리해보려 한다.

문제 상황

배포 시점마다 ChunkLoadError가 센트리에 급증하고, 잠시 후 다시 사라지는 패턴이 반복되고 있었다. 빈도가 높지 않아 우선순위를 뒤로 미뤘지만, 특정 시점에 트래픽이 급감한다는 노드 개발자분의 제보로 이것이 실제 사용자에게 영향을 주는 문제임을 인지하게 되었다.

Next.js 빌드 결과물 이해하기

문제를 해결하기 위해서는 먼저 Next.js가 빌드 시 어떤 결과물을 만들고, 브라우저가 어떻게 이를 사용하는지 이해해야 해보자.

프로젝트 구조

간단한 Next.js 15 App Router 프로젝트를 예시로 살펴보자.

app/
├── about/
│   └── page.tsx
├── layout.tsx
└── page.tsx

빌드 결과물

next build 실행 시 .next 폴더에 다음과 같은 구조가 생성된다.

이 중 핵심적으로 봐야 할 부분은 세 가지다:

app-build-manifest.json - 페이지별 필요한 번들 매핑
static/ - 브라우저에서 다운로드하는 JS/CSS
server/ - Node.js 프론트 서버에서 실행되는 코드

1. app-build-manifest.json

app-build-manifest.json는 각 페이지가 필요로 하는 번들 파일들의 위치를 정의한다.

{
  "pages": {
    "/about/page": [
      "static/chunks/webpack-05cc406d6a87b1a9.js",
      "static/chunks/4bd1b696-692f10ba759dfb60.js",
      "static/chunks/517-7ba66467149c8b06.js",
      "static/chunks/main-app-0368da5f48dd66a2.js",
      "static/chunks/app/about/page-f21e94017376511e.js"
    ]
  }
}

파일 종류는 아래와 같이 정리할 수 있다.

공통 번들: webpack-xxx.js, framework-xxx.js (모든 페이지 공유)
페이지 번들: app/about/page-xxx.js (해당 페이지만 사용)
Dynamic import: 85-xxx.js (코드 스플리팅된 청크)

파일명의 해시:

page-f21e94017376511e.js
     └──────┬──────────┘
      콘텐츠 해시

파일 내용이 변경되면 해시도 변경되어 새로운 파일명이 생성된다. 파일 변경이 되지 않으면 새롭게 만들어지지 않아 불필요한 파일 생성을 막고 캐싱을 적극적으로 사용할 수 있다.

2. Static 폴더

브라우저가 다운로드하여 실행하는 JavaScript와 CSS 파일들이 위치한다.

이 폴더 내 파일들은 /_next/static/ 경로로 서빙되며, 페이지 방문 시 아래와 같이 HTML에 삽입된다:

<script src="/_next/static/chunks/webpack-05cc406d6a87b1a9.js"></script>
<script src="/_next/static/chunks/main-app-0368da5f48dd66a2.js"></script>
<script src="/_next/static/chunks/app/about/page-f21e94017376511e.js"></script>

각 <script> 태그는 app-build-manifest.json에 정의된 번들 목록을 기반으로 자동 생성된다. 해당 태그가 생성되는 과정은 아래 Server 폴더 내용과 함께 알아보자.

3. Server 폴더

Node.js 서버에서 실행되는 코드들이 들어있다.

빌드 타입에 따라 다른 결과물이 생성된다:

SSG (Static Site Generation)

.next/server/app/
└── _not-found.html  ← 빌드 시점에 완성된 HTML

빌드 시점에 HTML이 완성되어 저장되며, 요청 시 이 파일을 그대로 제공한다. HTML 내부에는 manifest에 정의된 script 태그들이 이미 삽입되어 있다:

<!DOCTYPE html>
<html>
  <head>
    <script src="/_next/static/chunks/webpack-xxx.js" async></script>
    <script src="/_next/static/chunks/main-app-xxx.js" async></script>
    <script src="/_next/static/chunks/app/page-xxx.js" async></script>
  </head>
  <body>
    <div id="__next">
      <!-- 서버에서 렌더링된 HTML -->
    </div>
  </body>
</html>

SSR (Server Side Rendering)

.next/server/app/about/
└── page.js  ← HTML 생성 함수

요청마다 page.js를 실행하여 HTML을 동적으로 생성한다. 이때 app-build-manifest.json을 참조하여 필요한 <script> 태그를 삽입한다. 잠시 해당 script 태그가 삽입되는 과정을 next 패키지에서 알아보자.

Next.js 서버에서 HTML을 만드는 과정:

//next/src/server/get-page-files.ts
export function getPageFiles(
  buildManifest: BuildManifest,
  page: string
): readonly string[] {
  const normalizedPage = denormalizePagePath(normalizePagePath(page))
  let files = buildManifest.pages[normalizedPage]

  if (!files) {
    console.warn(
      `Could not find files for ${normalizedPage} in .next/build-manifest.json`
    )
    return []
  }

  return files
}

// next/pages/_document

function getDocumentFiles(
  buildManifest: BuildManifest,
  pathname: string,
  inAmpMode: boolean
): DocumentFiles {
  const sharedFiles: readonly string[] = getPageFiles(buildManifest, "/_app")
  const pageFiles: readonly string[] = inAmpMode
    ? []
    : getPageFiles(buildManifest, pathname)

  return {
    sharedFiles,
    pageFiles,
    allFiles: [...new Set([...sharedFiles, ...pageFiles])],
  }
}

function getScripts(
  context: HtmlProps,
  props: OriginProps,
  files: DocumentFiles
) {
  const { assetPrefix, buildManifest, assetQueryString } = context

  const normalScripts = files.allFiles.filter(file => file.endsWith(".js"))
  const lowPriorityScripts = buildManifest.lowPriorityFiles?.filter(file =>
    file.endsWith(".js")
  )

  return [...normalScripts, ...lowPriorityScripts].map(file => {
    return (
      <script
        key={file}
        src={`${assetPrefix}/_next/${encodeURIPath(file)}${assetQueryString}`}
        nonce={props.nonce}
        async={!isDevelopment && disableOptimizedLoading}
        defer={!disableOptimizedLoading}
        crossOrigin={props.crossOrigin || crossOrigin}
      />
    )
  })
}

export class Head extends React.Component<HeadProps> {
  getScripts(files: DocumentFiles) {
    return getScripts(this.context, this.props, files)
  }

  render() {
    // 생략
    const files: DocumentFiles = getDocumentFiles(
      this.context.buildManifest,
      this.context.__NEXT_DATA__.page,
      process.env.NEXT_RUNTIME !== "edge" && inAmpMode
    )

    return (
      <head {...getHeadHTMLProps(this.props)}>
        {/* 기본 meta, link 태그들 */}
        {head}
        {children}
        {/* 생략 */}
        {/* Main Scripts */}
        {!disableOptimizedLoading &&
          !disableRuntimeJS &&
          this.getScripts(files)}
      </head>
    )
  }
}

핵심 흐름:

사용자 요청 (/about)
  ↓
Next.js 서버
  ↓
1. app-build-manifest.json 읽기
   → "/about/page": ["static/chunks/...", "static/chunks/app/about/page-xxx.js"]
  ↓
2. .next/server/app/about/page.js 실행
   → React 컴포넌트를 HTML 문자열로 변환
  ↓
3. manifest에서 가져온 번들 파일들을 <script> 태그로 생성
  ↓
4. HTML + script 태그 조합
  ↓
브라우저로 전송

지금까지 페이지 진입시 Next 빌드 결과물이 서로 어떻게 연결되어서 서빙되는지 알아보았다. 이제 실제 ChunkLoadError 에러가 어떻게 발생하게 되었는지 어떻게 해결했는지 알아보자.

문제 발생 시나리오

재현 환경

클라이언트 컴포넌트가 포함된 SSR 페이지:

// app/about/page.tsx
export const dynamic = "force-dynamic"
import LikeButton from "./LikeButton"

export default async function AboutPage() {
  const data = await fetch("...").then(r => r.json())
  return (
    <div>
      <h1>About Page</h1>
      <pre>{JSON.stringify(data)}</pre>
      <LikeButton /> {/* 클라이언트 컴포넌트 */}
    </div>
  )
}

타임라인 다이어그램

┌─────────────────────────────────────────────────────────┐
│ T=0: 구버전 서비스 운영 중                               │
└─────────────────────────────────────────────────────────┘

블루 서버 (v1)                    S3/CDN
├─ manifest                       ├─ page-OLD_HASH.js ✅
│  └─ page-OLD_HASH.js 참조       └─ (구버전 청크)
└─ 사용자 요청 처리 중

사용자 A → /about 접속
  ↓
블루 서버 SSR 실행
  ↓
HTML: <script src="...page-OLD_HASH.js">
  ↓
브라우저: page-OLD_HASH.js 다운로드 ✅


┌─────────────────────────────────────────────────────────┐
│ T=1: 새 버전 배포 시작 (--delete 옵션 사용)              │
└─────────────────────────────────────────────────────────┘

블루 서버 (v1) 계속 실행          S3/CDN 업데이트
├─ manifest                       ├─ page-OLD_HASH.js ❌ 삭제!
│  └─ page-OLD_HASH.js 참조       └─ page-NEW_HASH.js ✅ 업로드
└─ 여전히 트래픽 받는 중

그린 서버 (v2) 시작
├─ manifest
│  └─ page-NEW_HASH.js 참조
└─ 헬스체크 대기 중


┌─────────────────────────────────────────────────────────┐
│ T=2: 문제 발생! (블루-그린 전환 전)                      │
└─────────────────────────────────────────────────────────┘

사용자 B → /about 접속
  ↓
로드밸런서 → 블루 서버(v1)로 라우팅
  ↓
블루 서버 SSR 실행
  ↓
HTML: <script src="...page-OLD_HASH.js">
  ↓
브라우저: page-OLD_HASH.js 요청
  ↓
S3/CDN: ❌ 404 Not Found (이미 삭제됨)
  ↓
ChunkLoadError 발생!


┌─────────────────────────────────────────────────────────┐
│ T=3: 블루-그린 전환 완료                                 │
└─────────────────────────────────────────────────────────┘

블루 서버 (v1) 종료               S3/CDN
                                  └─ page-NEW_HASH.js ✅
그린 서버 (v2) 활성화
├─ manifest
│  └─ page-NEW_HASH.js 참조
└─ 모든 트래픽 수신

사용자 C → /about 접속
  ↓
그린 서버 SSR 실행
  ↓
HTML: <script src="...page-NEW_HASH.js">
  ↓
브라우저: page-NEW_HASH.js 다운로드 ✅
  ↓
정상 동작 ✅

실제 재현 결과

개발 환경에서 재현하기 위해 빌드 후 특정 청크를 삭제했다:

# 빌드
npm run build

rm .next/static/chunks/app/about/page-817d6baba2395b08.js

# 서버 시작
npm run start

브라우저에서 /about 접속 시:

해결 방법

해결방법은 새로운 버전의 결과물을 배포할 때에도 이전 버전의 static 결과물을 서빙가능하도록 해주는 것이다.

그러기 위해서 static 결과물은 따로 CDN에서 서빙하도록 수정했고, 해당 CDN 주소는 BUILD_ID를 기반으로 구분된 폴더로 서빙해서 독립적으로 관리할 수 있도록 했다. 사실 코어에서는 이미 해당방법을 사용하고 있어서 아주 간단하게 CLI 옵션을 키고 CDN의 동작을 수정하면 되는 상황이었다.

기존 CSR 서비스에서 SSR 기반 서비스로 전환하면서 해당 CLI 옵션과 동작 설정이 누락되면서 발생했던 것 같다.

정리

해당 이슈를 수정하면서 프론트 서버에 대한 이해도를 조금 더 높여야겠다는 생각이 들었다. 노드 개발자분이 제보하지 않으셨다면 지속적으로 트래픽이 떨어지는 구간이 발생했을 것이란 생각에 아찔했다.

한편으로는 해당 이슈를 디버깅하면서 그냥 사용하고 있던 Next Build 결과물에 대한 이해와 배포 프로세스, 인프라 세팅에 대한 이해도가 한층 높아져 많이 배울 수 있었다.

2025년 9월 회고

Thu, 02 Oct 2025 00:00:00 GMT

9월은 드디어 조금 무난한 한달이었던 것 같다. 매달 새로운(?) 토스 생활이지만 그래도 조금은 안정화되어 가는 느낌을 받았다. 그리고 드디어 새로운 동료 분이 오셨다. 돌아보니 굉장히 다양한 작업을 한 것 같지만 그래도 적응해가는지 무난했던 한달간의 생활을 돌아보자.

TDS V2 업데이트

TDS는 토스 개발자라면 매일 마주하는 제품으로 토스 디자인 시스템을 의미한다. TDS는 데우스라는 디자인 툴과 함께 사용하는데 인컴은 이전 버전의 다소 오래된 패키지를 사용하다보니, 8월 회고 마지막에 이야기했던 부분처럼 Breaking Change가 있는 상태로 코드젠이 제공되면서 지속적으로 일일이 싱크를 맞춰야하고, 코드 젠에 되어있는 대로 코드를 작성했지만, 실제로는 보이지 않는 디자인 QA 티켓이 지속적으로 발생해 팀의 리소스가 사용되는 이슈가 있었다. 이러한 부분을 해소하기 위해서 디자인 시스템 버전 업데이트를 제안하고 진행하게 되었다.

작업을 진행하면서 가장 고민했던 부분은 어떻게 하면 달리는 차의 바퀴를 갈아 끼울 수 있을까였다. 왜냐하면 디자인 시스템은 정말 매일 개발을 하면서 사용되다보니 작업하는 순간에도 동료의 작업에 마이그레이션 해주어야할 부분이 생길 수 있기 때문이었다. 내가 작업한 브랜치가 최대한 따라가려고 해도 작업범위가 늘어나고 어디서 놓쳤는지 알기 어렵기 때문에, 해당 부분이 디자인 이슈로 이어질 수 있었다.

예를 들면 Text 컴포넌트의 title1이라는 요소가 titleTop이라는 요소로 바뀌는 breaking change가 생겼다고 하면, 이전 버전을 사용하면서 title1으로 작성된 부분은 컴포넌트 props이기 때문에 따로 에러가 발생하지 않아 놓칠 수 밖에 없고, IDE로 찾아서 전부 교체를 한다해도 병합 순서에 따라 남는 부분이 생기고 해당 요소가 안보이는 이슈가 발생할 수 있다. 이러한 부분을 감지하기 위해 아래와 같은 커스텀 린트 룰을 추가했다.

"rules": {
    "no-restricted-syntax": [
      "error",
      {
        "selector": "JSXElement[openingElement.name.name='Text'] JSXAttribute[name.name='title1']",
        "message": "Text 컴포넌트에서 title1 속성은 더 이상 사용되지 않습니다. titleTop을 사용해주세요."
      }
    ]
  }

내 작업 스타일 탓일까 디자인 시스템 팀에서 CLI를 제공해주시긴 했지만, 모든 게 한번에 바뀌면 변경점이 커서 오히려 감지 못하는 이슈가 많아지지 않을까 걱정이 되어, 한번에 변경하는 CLI 대신 필요한 부분들에 대한 변경점에 대한 린트룰을 추가하는 방식으로 작업해보았다. 약간 TDD 비슷하게 에러 상황 -> 코드 수정 -> 테스트 통과 방식으로 진행하는게 내 스타일에 더 잘 맞았고, 다행히 안정적이고 빠르게 마이그레이션 작업을 완료할 수 있었다. 다음에도 비슷한 마이그레이션 과정에서 사용할 수 있는 전략으로 생각되어 해당 전략을 챕터 위클리에 소개하기도 했다.

토스폼 내재화

토스에는 다양한 내부 제품들이 있다. 다양한 실험을 위한 튜바, 디자이너/개발자 모두의 편의를 위한 데우스, 운영을 위한 어드민 제품 등 조직 내부의 문제를 해결하기 위해, 생산성 향상을 위한 다양한 제품들이 있다. 현재 인컴은 이러한 제품들을 인컴 환경에 맞게 제공하기 위해 내재화하는 작업을 많이 진행중에 있다. 그중 이번달에는 토스폼으로 유저에게 설문조사를 위한 폼을 보내고 받은 응답을 어드민을 통해 볼 수 있게 해주는 서비스를 내재화하는 작업을 진행했다.

작업 자체는 토스폼을 담당해주시는 팀과 함께 협업하는 형식이어서 크게 어렵지는 않았지만, 코어와는 다른 회원 체계 등 인컴에 맞게 내재화를 위한 작업이 필요했다. 이 과정에서 데스크탑 제품이었던 홈페이지 작업과는 다르게 처음으로 모바일 제품으로서 신규 서비스 구현이 필요했다. 그래서 숨은 환급액 찾기 서비스에서 자주 사용하고 있는 유틸, 컴포넌트, 패키지들이 똑같이 필요하다는 점을 알게 되었고, 해당 유틸들을 공통 워크 스페이스로 정리해두면 앞으로 더 다양한 서비스들을 제공할 떄의 큰 효율을 만들 수 있겠다는 생각이 들었다.

이러한 개발 효율화에 대한 니즈는 자연스럽게 모노레포에 대해 관심이 생기게 되었고, 코어 프로젝트의 100개가 넘는 서비스를 서빙하기 위해 모노레포가 어떠한 구조를 이용하고 있는지, 그와 함께 이전에 간단하게 살펴봤던 패키지 매니저들의 역할은 어떻게 되는지 글을 작성하는 추석 연휴동안 공부해보고 정리해보려 한다.

표동모 v2 마이그레이션

표동모는 표준동의모듈의 줄임말로 토스폼과 같이 토스의 내부 제품 중 하나다. 토스에서 수집하는 다양한 동의문들에 대해 규격화한 제품으로 인컴 내 제품에도 새로운 패키지를 구현해서 적용해야 하는 순간이 왔다. 기존에는 오래된 레거시 패키지를 사용하고 있었지만 이번에 새로운 요구사항 (커스텀 로그, 새로운 버전의 UI) 대응을 위해 전체적으로 v2로 마이그레이션 작업을 진행했다.

작업 자체는 어렵지는 않지만 동료분께서 만들어주신 인컴 전용 표동모 패키지를 분석하고, 핵심 부분에 해당하는 코어 패키지들을 보면서 어떻게 적용하면 될지 파악하는 등 패키지간의 의존관계도 공부하고, 모노 레포로 구성된 패키지 구조에서 개발 환경에서 어떻게 패키지를 업데이트하고 해당 패키지를 반영될 때, 패키지 캐시가 남아 적용안되는 문제도 겪으면서 배움이 많았던 작업이었다.

아직 구버전 패키지 의존성이 남아있어서 완전히 정리하는 작업까지 10월중에 진행해보려 한다.

배포시 에러 급증 문제 해결하기

프론트 개발을 하면서 조금 이상한 에러가 찍히는 경우가 지속적으로 발생했다. unexpected token '<' 에러로 이상하게 배포하는 시점에 정말 많은 에러가 찍혀 센트리 error peak 알림으로 제보되고 있었다가 조금 시간이 지나면 급격하게 줄어들었다. 해당 이슈가 있다는 것을 인지한건 4개월 정도 되었지만, 배포시점에만 발생하는 이슈라 파악하기가 어려웠고, 자주 발생하는 이슈가 아니라는 점, 금세 에러가 줄어들기 때문에 우선순위를 뒤로해두었다.

하지만 노드 개발자분께서 특정시점에 트래픽이 쭉 빠지는 시점이 있는데 어떤 문제가 있는지 같이 봐줄 수 있는지 물어보셨고, 시점이 프론트 배포 시점이었다. 내가 생각했던 것보다 유저에게도 영향을 줄 수 있는 문제라는 점을 인지하게 된 순간이었다.

해당 문제를 파악하기 위해서는 먼저 인프라 구조와 Next의 빌드, 배포 과정을 이해해야 했다.

우리가 제공하는 웹 서비스는 결국 사용자의 브라우저에 다운로드 되는 HTML, CSS, JS 파일이다. 배포라는건 해당 파일들을 새롭게 만들어서 저장소에 업로드하는 작업이고 유저는 페이지를 이동하면서 필요한 파일들을 해당 저장소에 요청을 보내고 응답으로 받아서 보게 된다.

이때 중요한건 새롭게 배포될 빌드 결과물은 별도의 build id를 가진 이전 결과물과 다른 결과물이 된다는 점이다.

예를 들어 intro 페이지를 빌드한 결과물이 intro-1.js로 빌드가 되어서 배포된 상태에서, 새롭게 배포할때는 intro 페이지는 intro-2.js라는 다른 파일을 빌드과정에서 만들어서 배포되게 된다.

이러한 구조에서 유저가 이전 버전의 결과물을 보고 있다가 서비스를 이용하는 와중에 새로운 배포 결과물로 덮어씌워지는 상태가 된다면 어떻게 될까? 이전 빌드 결과물인 intro-1.js를 찾고 싶어도 intro-2.js로 바뀌어 있기 때문에 찾을 수 없어 404 에러가 발생하게 된다.

여기서 더 이상했던 점은 404가 에러가 아니라 unexpected token '<' 에러가 발생했던 점인데 해당 에러는 js을 요청했는데 HTML이 응답으로 받아지면서 발생했다는 것을 발견했다. 바뀐 서빙 주소에 요청을 보냈을 때 404 에러가 발생했지만 CloudFront에서 해당 404를 커스텀 에러 페이지와 함께 200으로 응답하게 되면서 발생했던 에러였다.

근본적인 문제는 이전 빌드 결과물이 덮어 씌워지면서 발생하는 에러였고, 해당 에러를 해결하기 위해서 정적 asset들은 CDN에 이전 빌드와 현재 빌드 모두 서빙하는 방식을 적용해 해결할 수 있었다. 커스텀 에러 페이지는 서비스 내에서 직접 구현하는게 맞다고 생각해 제거하게 되었다.

해당 이슈를 해결하면서 작게 봤던 이슈가 작지 않은 영향을 주고 있었던 점과 디버깅 과정에서 next build과정으로 만들어진 결과물을 서빙하는 인프라 구조 + 블루 그린 배포 전략에 따른 배포 방식 등을 이해할 수 있었는데 조금 더 자세한 내용은 별도 글로 정리해보려 한다.

어떻게 결제와 신고를 편하게 하도록 해줄 수 있을까

사일로 작업은 주로 결제 전환과 신고 전환율을 높이기 위한 작업들을 진행하고 있다. 이전에는 최대한 많은 맥락을 줌으로서 유저가 잘 이해하도록 돕는다면 요즘은 필요한 맥락만 남기고 최대한 퍼널을 정리하는 방향으로 작업이 진행되고 있다. 이러한 방향성이 개인적으로 세금이라는 어려운 맥락에 필요한 부분만 전달할 수 있게 정리함으로서 조금 더 유효하지 않을까라는 생각이 있다.

이에 따라 기존 결제 퍼널과 신고 퍼널간의 길었던 구간을 합쳐서 결제 직후 바로 신고가 되게 하거나, 순서를 바꾸는 등 기존과 달리 큰 퍼널의 변경 실험들을 진행하고 있다. 이에 따라 고려할 점은 많아지고 있지만 퍼널간 연결관계나 네비게이션 스택 관리 등 다양한 부분들을 고려하는 새로운 요구사항들을 고민해보는 기회가 되었다.

특히 주민번호 스크래핑을 추가해서 유저가 부양가족들의 정보를 보다 쉽게 가져올 수 있게 하는 실험과, 결제 구간내 공제 요약과 결제 요약을 합치는 실험은 기대가 되고 있다.

새로운 동료가 생겼어요

드디어 6개월 만에 새로운 동료분이 들어오셨다. 메이트는 다른 동료분께서 담당해주셨지만 같이 잘 적응하실 수 있게 도와드리고 싶었다. 새로운 분이 오신 게 처음이라서 그런지 많이... 어려움을 겪으시는 것 같았다. 최근 어떤 점이 어려운지 여쭤봤을 때 제품을 이해하기 어렵다는 피드백을 주셨다. 구체적으로는 어떤 페이지가 데우스의 어떤 화면에 해당하는지 등을 찾는데 많은 시간을 쓰고 계신다고 알려주셨다. 참고해서 구현할 만한 부분은 어디일지, 어떤 패키지들이 있는지 등 토스 개발 생태계 자체를 이해하는데 많은 어려움이 있으셨던 것 같다.

추석 직후에 또 다른 동료 두 분이 합류하시기로 되면서 갑자기 기존 2명에서 5명이 될 예정인 상태로 인해 걱정이 많다. 좋은 동료가 많아지는 건 너무 좋은데 우리는 그분들이 잘 적응하실 수 있게 준비가 되어 있는지 걱정이 되었다. 좀 더 제품 맥락을 많이 알고 있는 내가 문서화에 더 기여하기 위해 노력이 필요한데 아직 담당 업무를 하는 것에 많은 시간을 쏟고 있어서 챙기지 못하는 것 같다는 생각이 든다. 조금씩이라도 제품 한판 정리를 매일 작성해서 챕터 전체의 이해도를 높이기 위한 노력을 기울여보려 한다.

돌아보는 9월의 액션아이템과 10월 액션아이템

9월의 목표는 아래와 같았다.

디자인 시스템 최신화
인프라와 모노레포 구조 공부해보기

두가지 중에서 디자인 시스템 최신화 작업은 완료했지만, 인프라와 모노레포 구조는 문제를 해결하면서 조금씩 문제 해결을 위한 부분만 이해하고 깊이 있게 이해하지는 못했다. 앞으로 해당 부분의 중요성과 담당 업무가 조금씩 생기는 걸 고려했을 때 10월에 똑같이 가져가보려 한다. 추가로 7월부터 지속적으로 하겠다했지만 못했던 히스토리 문서화 작업이 정말 필요해졌다. 새로운 동료분이 더 좋은 퍼포먼스를 내실 수 있도록 책임감을 가지고 진행해보려 한다.

히스토리 문서화 하기
인프라와 모노레포 구조 공부해보기

9월은 내재화나 내부 제품들을 챙기는데 많은 작업을 진행했던 것 같다. 8월 회고에 작성했던 부분 처럼 단순 사일로 작업 뿐 아니라 점점 내가 할 수 있는 역량을 늘려가는 것 같다. 인프라도 모노레포도 기술적 성장도 조금씩 챙겨가고 있고, 사람적으로도 기술적으로도 새로운 부분들을 조금씩 맡고 도전할 때 내가 더 성장한다는 것을 느끼는 것 같다. 나는 익숙한 곳에 있는 것을, 컴포트 존에 있는 것을 싫어하는 건 아닐까란 생각이 많이 드는 요즘, 다음 달은 또 어떤 걸 해볼지 기대해본다.

2025년 8월 회고

Mon, 08 Sep 2025 00:00:00 GMT

8월은 예비군으로 한주가 날라가버려서 7월과 비슷하게 굉장히 빠르게 흘러갔던 것 같다. 이와 더불어 1학기에 대한 얼라인먼트 시즌이 돌아와, 토스에서 다양한 문제를 푸는 여러 팀들의 레슨런을 들을 수 있었다.이번에는 특별하게 인컴에서 자체적으로 미니 얼라를 진행했고, 프론트엔드 챕터 대표로 발표를 진행하기도 했다.

숨은 환급액 찾기 리팩토링 프로젝트를 마무리하며 성과와 과정 내 발견한 내용들에 대해서도 전사 위클리에서 발표하는 등 다양한 행사에 참여하고 직접 기획한 작업도 마무리한 알찬 8월에 대해 회고해보려한다.

토스 생활: 인컴의 Mini Alignment

한학기가 끝나고 토스의 얼라이먼트 시즌이 돌아왔다. 지난번과는 다르게 tax silo가 아니라 토스 인컴으로 발표를 PO분들이 진행해주셨다. 뿐만 아니라 이번에 조금 더 특별했던 건 인컴 자체적인 미니 얼라인먼트 시간을 가졌다. 인컴 구성원 분들이 발표를 하기 때문에, 프론트엔드 챕터(라기엔 동료분이 휴가였기 때문에)를 대표해 한학기 동안 어떤 작업을 했고, 2학기에는 어떤 문제를 해결하려 하는지 담아 발표 담당해 준비하고 진행했다.

1학기에는 5월이 있었기 때문에 상당히 강렬했던 5월과 프론트 개발과정에서 마주했던 다양한 어려움들을 실사례들을 담았고, 해당 문제들을 하나씩 해결해나간 과정을 담아서 발표했다.

예를 들어, 하나의 서비스를 개발하는 과정에서 두가지 레포에서 개발해야하는 어려움, 1학기 동안 진행 만든 22개의 모바일 제품과 2개의 데스크탑 제품, 41번의 실험을 해왔더 그과정에서 하나의 개발 환경을 3명의 개발자가 함께 사용하면서 생기는 병목 문제 등을 담았다.

여기에 5월의 프론트 관점에서 어떤 어려움이 있었는지, 2학기에는 이러한 과정에서 1학기에 쌓인 기술부채를 정리하는 숨은 환급액 찾기 리팩토링 작업과 로딩 개선 작업을 하려는 개인적인 목표도 이야기를 담았다.

무아지경으로 발표해서 어떻게 발표했는지 기억이 나지는 않지만, 나중에 이야기를 들어보니 5월에 새벽까지 일하면서 먹었던 맥모닝만 강렬하게 기억에 남은 것 같다...

개인적으로 앞에서 오랜만에 발표하려니 부담도 되고, 어떤 걸 담아야할까 고민이 많이 되었지만 나름 재밌었던 경험이었고, 내가 한 것 이상으로 좋았던 점은 동료분들의 발표를 듣는 거였다.

함께 일을 하는 동료지만 직접적으로 협업하지 않으면, 어떤 일을 하고 있고 어떤 어려움이 있었는지 알기 어려움이 있다. 각자의 다양한 어려움을 풀어나가는 모습이 멋있고 대단하게 느껴졌다. 서로에 대한 리스펙이 쌓일 수 있었고, 2학기도 더 잘해보고 싶은 마음이 생긴 소중한 경험이었다.

숨은 환급액 찾기 리팩토링 (aka 숨환찾 다이어트 프로젝트) 마무리

숨은 환급액 찾기 7월부터 진행해온 숨환찾 다이어트 프로젝트를 마무리했다. 어떤 작업들을 했는지 하나씩 정리해보자.

1. 이어하기 개선

작업의 60% 이상을 투자한 지점으로 7월 회고 때 작성했던 신고 진행상태에 따라 유저가 랜딩해야하는 곳을 결정하는 이어하기에 많은 시간을 쏟았다.

이어하기를 개선해야겠다고 생각했던 이유는, 5월 당시 체감상 CS의 60~70% 정도가 이어하기에서 발생했었다. 5월 한달동안 CX 팀의 25%를 숨은 환급액 찾기에서 발생했던 걸 감안하면, 상당히 많은 리소스가 사용했고, 하루의 대부분을 cs를 대응하는데 사용했다. 추가로 독립적인 13개의 API의 14개의 필드를 조합해 유저의 상태를 정해서 특정 구간으로 넘겨주어야하기 때문에 히스토리를 모르면, 이해하기 어려운 지점이라 나에 대한 버스팩터가 가장 높은 지점이라는 생각이 들었다.

이어한 문제점을 개선하기 위해 7월 회고에 작성했던 것 처럼 하나의 API로 통합하는 작업을 진행했고, 그결과 굉장히 명확하게 유저상태로 랜딩될 수 있게 정리될 수 있었다.

도메인 이어하기를 통해 호출한 결과에 어떤 도메인으로 갈지를 결정하면 되었고, 해당 도메인 내에서의 세부적인 스텝별 이어하기가 필요하다면 해당 도메인 브릿지 페이지에서 하위 도메인 이어하기를 추가해, 트리구조로 복잡했던 이어하기 설계를 풀어냈다.

도메인 트리

덕분에 이제 새로운 도메인이 추가되거나, 하위 도메인이 추가되더라도 빠르게 대응할 수 있는 확장성 있는 구조가 되었고 프론트 입장에서는 단순히 최대 2개의 API의 상태만 조합해서 보면 됨으로 CS 대응하는 시간이 굉장히 줄어들었고 직접 체감하고 있다.

뜻 밖의 수확: 코드에서 숨은 돈 찾기

신고 이어하기를 마이그레이션하는 과정에서 기존 구조의 문제를 발견하게 되었다. 이어하기를 판단하는 기준이 제품 플로우 순서와 반대로 되어 있다는 점이었다.

제품 플로우: 스크래핑 -> 공제 -> 결제 -> 신고
이어하기: 스크래핑 -> 신고 -> 공제 -> 결제

신고를 먼저하고 있었기 때문에 처음 신고할 때는 문제가 없지만, 이러한 구조는 신고이력이 있고, 다음 신고를 할 수 있는 경우에 신고결과로 먼저 랜딩되기 때문에 신고를 하지 못하는 상황이 될 수 있는 상황이었다. 서버분과 함께 해당 케이스로 인해 신고를 못하는 사람들의 환급액이 최대 8억 규모라는 것을 파악해, 구조적 문제를 팀에 공유드리고, 전체적인 플로우를 고치는 작업을 함께 진행했다.

추가적으로는 환급액에 대한 기준이 다르게 보여주는 지점들이 있어, 환급액 있다고 안내받아 앱내 진입했지만 실제로는 보이지 않는 문제도 해결해 유저경험도 개선할 수 있었다.

리팩토링이라는 작업으로도 전체적인 구조와 제품 이해도가 올라갈 수 있었고, 우리가 놓치고 있던 매출에 대한 부분을 발견할 수 있다는 선례를 만드는 좋은 포인트가 되었다.

2. 부녀자 공제 프론트에서 서버로

부녀자 공제는 조건이 굉장히 까다로운 공제로 기존에 프론트에서 서버로 부터 대상 정보를 받아서 특정 조건을 조합해서 공제 해당 여부를 판단하고 있어, 대응이 어려운 문제가 지속적으로 있었다. 이러한 로직을 서버로 위임해 명확히 책임을 분리할 수 있었다. 덕분에 기존에 비해 에러가 굉장히 줄었고, 대응이 굉장히 간단해질 수 있었다.

3. 파이썬 서버 도메인 제거

일부 남아있던 파이썬 서버를 직접 호출하고 있던 부분들을 모두 코틀린 기반의 서버 API로 변경하는 작업을 진행했다. 파이썬 서버 의존성을 줄이는 작업을 진행하고 있기 떄문에 프론트 의존성을 줄이는데 기여할 수 있었다.

이러한 3가지 작업 뿐 아니라 세세하게는 스크래핑에 붙어있던 추가수집 퍼널 분리 작업 등 다양한 개선 작업을 했다. 우리의 목표였던 서버와 프론트의 책임이 혼재되어 있어 발생하는 어려움들을 해결할 수 있었다. 계획 로드맵 내 작업 중 일부는 보류되기도 했지만 계획했던 90% 이상의 작업들을 수행했고, 기간내에 마무리를 해 제품 개발과 장기적인 기술적 개선 작업이 병행될 수 있다는 것을 보여주는 팀의 좋은 선례로 남기를 기대하고 있다.

내가 잘 안했던 작업들 해보기

기능 개발과 퍼널 개발에 많은 시간을 사용했었다면, 요즘에 인컴 공통 패키지에 대한 작업 비중도 조금씩 늘려가는 것 같다. 그이유는 로깅이나 디자인 시스템의 최신화에 대한 요구사항이 추가되는 점도 있지만, 조금 내가 외면하고 내가 맡은 일만 해야지라는 생각을 벗어내고 싶기도 했다. 동료분께서 해당 작업을 잘 챙겨주시고 계셔서, 나보다 잘하는 분께 맡기는 게 더 효율적이지 않을까 생각했던 것도 있었다.

1학기에 대한 연봉조정을 하면서 어떤 부분에 대해 초점을 맞춰서 성장하면 좋을지 고민이 되었고, 비즈니스가 커지면서 생기는 다양한 문제들이나 챕터내 다양한 문제에 대해 더 관심을 가지고 기여해보자라는 목표를 세우게 된 것 같다.

그래서 이번 달에 한 작업은 아주 간단하지만 놓치기 쉬운 바텀시트 관련 로깅을 로깅 패키지에 추가 구현해보았다. 그렇게 공수가 큰 작업은 아니었지만 단순히 만들어진 패키지를 사용하는 것을 넘어 분석하고 패키지에 직접 기여하는 작업으로 앞으로 계속해서 늘려가보려 한다.

돌아보는 8월의 액션아이템과 9월 액션아이템

8월에 해보기로 한 작업은 아래 두가지 였다. 이중에 숨환찾 다이어트 프로젝트는 다행히 잘 마무리했다. 하지만 두번째 AI를 통해 프로젝트 구조 히스토리 문서화하는 작업은 하지 못했다. 한달간 중점을 맞췄던 건 프로젝트 전체적인 구조화와 불필요한 부분 덜어내기에 초점을 맞췄던 것 같다. 중복코드나 사용하지 않는 파일들을 정리하는 작업을 진행했다. 정리 후에 이후에 해당 문서화 작업을 진행해 온보딩 준비에도 기여해보려 한다.

숨은 환급액 찾기 다이어트 프로젝트 완료하기
AI를 통한 히스토리 문서화 해보기

9월에는 아래와 같은 목표를 가져보려 한다.

디자인 시스템 최신화
인프라와 모노레포 구조 공부해보기

디자인 시스템은 다소 오래된 패키지를 사용하면서 breaking change가 있는 부분에 병목이 되고 있어, 이를 해소해보려한다. 인프라와 모노레포는 신규 서비스들에 대한 전사 목표가 있어보여, 그에 대한 기술적 준비를 위해 공부하고 적용해보려 한다.

요즘 들어 드는 생각은 비즈니스가 커지면 자연스럽게 기술적 어려움이 생기고, 그것을 해결하기 위해 내가 성장해야하는 상황이 다가온다는 점인 것 같다. 기술적으로 내가 뒤쳐지고 있는 것 아닐까라는 생각에 불안하고, 걱정이 많았지만 새로운 요구사항과 새로운 방향이 보이다 보니 내가 현재 집중해야할 게 무엇인지 조금 더 느끼는 것 같다.

추가로 숨환찾 다이어트 프로젝트를 하면서, 내가 조금 더 멀리 보고 장기적인 개선에 대한 관심이 많은 사람이구나라는 점도 느낄 수 있었다. 9월에는 조금 더 새로운 목표와 작업들로 기여할 수 있기를 기대해 본다.

2025년 7월 회고

Sun, 24 Aug 2025 00:00:00 GMT

7월 회고를 굉장히 늦게 작성하게 되었다... 팀원분들과 함께 해외 워크샵을 다녀오면서 다양한 경험을 하기도 했고, AI를 어떻게 쓰면 좋을지, 주말에 이것 저것 사용해보는 등 기존과 다른 고민들을 하다보니 7월에 대한 정리가 늦었다. 한달간의 고민과 작업들을 돌아보고 이미 다가버린 8월, 다가올 9월은 어떻게 보내볼지도 적어보려한다.

시작된 숨은 환급액 찾기 다이어트 프로젝트

6월 말 부터 계획했던 작업을 본격적으로 시작했다. 6월 회고에서 작성했던 것 처럼 제품 전체에 대한 구조화, 모듈화를 기반으로 제품을 모듈 단위로 구분했다. 그에 따라 정리된 스텝은 이어하기, 스크래핑, 추가 수집, 공제, 결제, 신고 6가지로 분류를 했고, 각 도메인을 구분한 단위 내의 세부적인 작업들을 정의하고 일정을 정리했다.

7월은 사실상 이어하기가 거의 메인 작업이었다. 신고 상태에 따라 다음 스텝을 진행하게 하는 것은 리텐션과 유저 경험에 아주 중요한 요소였고 고객의 상태가 어디인지 판단하기 위해 13개의 API가 필요한 상황이었기 때문에 각 스텝에 맞게 이동할 수 있는 하나의 API를 백엔드 개발자분과 정의해 점진적으로 마이그레이션을 진행했다.

//before
const [{ a1, a2, a3 }, { b1, b2 }] = await Promise.all([fetchA(), fetchB()])

if (a1 || b1) {
  return "스크래핑"
}

if (a2 && !a3 && b2) {
  return "추가수집"
}

//after
const { userStatus } = await 통합_이어하기_API()
if (userStatus === "스크래핑") {
  return "스크래핑"
}

점진적 마이그레이션을 위해서 우선 기존의 13가지와 전환할 하나의 API 총 14가지 API를 호출한 다음, 각 상태를 판단하는 필드들의 유저 상태와 하나로 정리한 API가 1대1로 잘 매칭되는지 보고 다를 경우 로그를 남겨서 안정적으로 마이그레이션을 진행할 수 있었다. 백엔드 개발자분의 좋은 아이디어 덕분에 상당히 안정적으로 옮길 수 있었고, 매주 미팅 시간에 센트리로 로그를 같이 분석하면서 세밀한 유저 케이스들을 보고 수정해갈 수 있었다.

const [{ a1, a2, a3 }, { b1, b2 }, { userStatus }] = await Promise.all([
  fetchA(),
  fetchB(),
  통합_이어하기_API(),
])

if (a1 || b1) {
  if (!userStatus === "스크래핑") {
    Log("스크래핑이 아님")
  }
  return "스크래핑"
}

if (a2 && !a3 && b2) {
  if (!userStatus === "추가수집") {
    Log("추가수집이 아님")
  }
  return "추가수집"
}

7월까지는 스크래핑과 추가수집 퍼널에 대한 이어하기 마이그레이션을 완료했고, 세부적으로는 스크래핑 내부에 있던 추가수집 퍼널을 분리하는 작업도 진행했다. 해당 과정에서 아직 브릿지에만 적용되어 있는 SSR을 전체적으로 적용할 경우 브릿지 화면들이 생겼을 때 보다 빠르게 전환이 가능하게 개선이 가능하겠다는 생각도 들었다.

현재까지 일정대로 잘 진행되고 있는 상황이고, 8월까지 잘 마무리한 후에 전체적인 소회를 담은 회고도 9월에 작성해보려 한다.

인컴 홈페이지 배포 파이프 라인 구축

7월에는 새롭게 인컴 홈페이지를 오픈하게 되었다. 해당 구현 작업은 다른 프론트 개발자분께서 진행해주시고, 인프라 세팅작업을 담당해서 함께 진행하게 되었다. 사실 인프라, AWS에 대한 경험이 너무 없었기 때문에 많이 걱정했지만 열심히 인프런 강의와 자료들을 보면서 CSR로 된 프로젝트를 배포할 때 파이프라인 구성을 완료할 수 있었다.

간단하게 구현과정을 적어보면 CSR의 경우 빌드된 결과물을 S3에 올리는데 이때 CloudFront로 CDN을 구현해 캐싱을 진행하게 된다. 여기서 조금 더 고민해야할 부분은 바로 어느 버전의 빌드 결과물을 보여줘야할 지에 대한 부분이다. 만약 새롭게 배포한 결과만 올린다면 큰 문제는 없지만, 배포 후 장애로 롤백이 필요하거나, 다양한 버전에 대한 테스트 환경을 구성해야할 때가 필요할 수 있다. 이러한 버전 관리를 위해 CDN과 S3 사이에 어떤 버전으로 랜딩할지를 결정할 수 있는 서버리스 서비스인 Lambda가 필요하게 된다.

이렇게 구현된 인프라를 바탕으로 깃허브에 배포될 때마다 빌드 결과물을 새롭게 S3에 올리고 새로운 버전이 올라왔으므로 CDN의 캐시무효화를 하는 깃허브 액션을 구성하게 되면 간단한 CSR 배포 파이프라인이 완성되게 된다.

인컴홈페이지

잘 모르는 분야라 굉장히 두렵기도 했고 일정에 대한 압박감도 있었지만, 다행히 여러 자료들이 있었고 claude code와 티키타카를 하며 열심히 배워서 적용할 수 있었다.

이렇게 한번 인프라와 플랫폼 업무에 대한 경험을 쌓고 나니 많은게 달라보였다. 흔히 보던 "www.google.com"을 검색했을 때 생기는 일이라는 면접 문제가 조금 더 잘 이해가 될 수 있었고 인프라간의 연결관계, 인프라를 코드로 관리하기 위한 테라폼 등 다양한 새로운 지식들에 대해서 알게 되었다.

이후 실질적인 문제로 토스 앱 내에서 타팀과 함께 작업해야하는 부분에서 스킴이 잘못되어 리다이렉션이 필요할 때 인프라 람다 설정을 변경해 장애를 빠르게 해결하기도 했다. 만약 경험이 없었다면 담당 사일로에 전달드리고 마냥 기다릴 수 밖에 없었을텐데, 직접 빠르게 대처할 수 있는 좋은 기회가 되었다.

아직 부족하지만 조금씩 역할을 확장하고, 조금 더 다양한 작업을 할 수 있도록 계속해서 인프라 쪽도 관심을 가지고 공부해보려 한다.

돌아보는 7월의 액션아이템과 8월 액션아이템

7월에 해보려 했던 작업은 아래와 같았다.

AI를 통해 히스토리 문서화 해보기
CSR페이지 SSR 마이그레이션을 위한 인증 공유 체계 구축

인증 공유 체계는 구현했지만 현재 전체적인 인증 관련 작업이 마이그레이션을 앞두고 있어서 해당 작업은 조금 더 추가 작업이 필요해 9월에 마이그레이션이 끝난 후 본격적으로 작업해보려한다. AI를 통해 히스토리 문서화는 간단히 진행할 수는 있지만, 까먹어서... 진행하지 못했다.

8월은 아래와 같은 액션 아이템을 진행해보려 한다.

숨은 환급액 찾기 다이어트 프로젝트 완료하기
AI를 통한 히스토리 문서화 해보기

8월이 얼마 남지 않은 상황에 액션아이템을 만들다 보니 조금 머쓱하지만 우선 숨은 환급액 찾기 다이어트 프로젝트를 잘 완수하는 것을 목표로 하려 한다. 계획했던 것을 잘 수행하고, 그안에서의 가치를 잘 전달하는 것까지를 목표로 9월에 전사 위클리에서 발표까지 해보려 한다.

AI를 통해 히스토리 문서화는 작업과정에서 필요한 내용들을 정리하고 그것을 다시 학습시키면서 좋은 선순환을 만들기 위한 초안을 제시해보려한다. CLAUDE.MD나 .cursorrule과 같은 설정을 조금 더 관심가지고 업데이트 해보려한다.

늦었지만 작성한 7월 회고, 얼마남지 않은 8월이지만 다음 회고는 조금 더 풍부하게 작성할 수 있을 것 같다. 글을 쓰면서 요즘 기술에 대한 글에 대한 작성이 뜸해졌다는 것을 느낀다. 새로운 AI기술이 너무 많이 나오고, 한편으로는 내가 지금 공부하는게 크게 의미 있을까? 회의감이 들기도 했다. AI가 나보다 잘할텐데 라는 생각에서 시작된 무기력함이었지만 사용하면 사용할 수록 내가 모르면 요청을 할 수 없다는 것, 내가 똑똑해야 AI를 잘 쓸 수 있겠다는 생각이 정리되었다. 내가 요즘 겪는 문제가 뭔지, 조금 더 효율화할 수 있는게 뭔지 계속해서 나에게 관심을 갖고, 내 일상에 관심을 가지고 해결하며, 나누는 것을 목표로 해보려 한다. 8월에는 그런 요소들도 같이 간단하게 작성하거나 만든 후기도 담아보면 좋을 것 같다.

2025년 6월 회고

Sat, 12 Jul 2025 00:00:00 GMT

6월은 5월을 지나고 조금은 팀적으로 제품적으로 정리하는 시간을 가지게 되었다. 엄청나게 뛰었던 여파였을까 건강은 괜찮지만, 회사에 앉아서 일을 하려해도 멍한 기분이 지속되었다. 한편 업무적으로는 5월을 겪으면서 내년 5월에 똑같은 어려움을 겪지 않기 위해 어떻게 하면 좋을까하는 고민이 시작되었다. 이러한 고민을 해결하기 위해 어떤 점이 필요하다 이야기하기 시작했던 6월에 대해 정리해보고자 한다.

숨은 환금액 찾기 리팩토링 프로젝트

5월의 어려움들을 정리해보면 먼저 CS를 대응하는데 너무 많은 시간을 들여야했다는 점이었다. CS의 주된 문제는 유저가 다양한 신고가 되지 않는 사유가 있었지만, 그것을 봐야하는 개발자가 프론트인지, 서버인지, 노드인지 명확하지 않아 대부분 모든 문제에 태그를 당하고 로그를 분석하고 정리하는데 시간을 많이 사용했다. 그럴수 밖에 없었던 것이 서버 입장에서도 어떤 페이지에 어떤 API가 사용되고 있는지 모르고 CS를 대응해주시는 입장에서는 화면에서 잘못나오는 부분이다보니 프론트가 거의 항상 동원되어야 하는 상황이었다.

두번째로 개발 팀내의 문제로는 6월에 신규로 합류하시는 개발자 분들이 많아지고, 기존에 계시던 개발자분들을 팀을 옮기거나 떠나시는 상황이었다. 코어에서 파견으로 도와주시던 서버개발자 두분과 인컴소속으로 함께 일하시던 개발자 한분께서 이직하게 되시면서 기존 히스토리를 아는 서버 개발자가 적어지는 상황에서 많은 분들이 한번에 들어오시면서 온보딩을 어떻게 해야할지 기존의 복잡한 구조는 어떻게 해야할지에 대한 문제가 제기되었다. 프론트 챕터에는 채용이 아직 되지 않은 상황이지만, 동일하게 맥락을 아는 사람이 특정 사람에게 치중되어있는 문제를 느끼고 있었고, 서로가 백업하기 어려운 현재 상황을 타개할 필요가 있다고 느꼈다.

위 두가지 메인 문제점을 해결하기 위해 인컴 대표님과 PO분들께 현재의 개발자분들이 느끼는 문제점들에 대해 공유를 드리고, 나와 동일하게 문제의식을 가지고 계셨던 서버개발자분과 함께 길드식으로 숨은 환급액 찾기 리팩토링 프로젝트가 시작되게 되었다.

가장 먼저 진행한건 문제점을 뾰족하게 만들기 위해 현황파악에 시간을 많이 들였다. 첫번째 문제를 해결하기 위해서는, 프론트와 서버의 책임을 명확하게 하는 것이 필요하다고 생각했다. 그래서 가장 먼저 API를 기록할때 특별한 인컴만의 헤더를 추가해 어떤 페이지에서 해당 API를 호출하는지 기록할 수 있게 했다. 덕분에 전체적으로 url별로 호출하고 있는 API들을 한판 정리할 수 있었고, 어느 구간에서 과하게 API를 사용되고 있는지 알 수 있었다.

이를 기반으로 조사해보니 제품을 전체적으로 도메인을 기준으로 구조화, 모듈화해서 볼 수 있었다. 각 도메인별로 구간을 나누고 해당 구간내에서 개선해야할 문제점들을 도출하고 정리작업들에 대해 세워나갔다. 특히 유저가 신고 과정중 이탈했을 경우, 어디로 랜딩해야할지 결정하는 이어하기 구간의 경우 총 13개의 API가 사용되고 있어, 어려움이 있었는데 이를 하나의 API로 판단가능하게 수정되고 각 구간별 이어하기의 경우도 내부적인 이어하기 API로 판단하도록 전체적인 제품 설계를 수정하도록 개선방향을 잡아나갔다. 서로 엉켜있던 구조에서 트리 구조와 같은 위계가 생기게 되어 다른 개발자 분들의 이해도를 높이는데도 기여할 수 있을 것 같다는 기대가 되었다.

로드맵을 완성한 후에 PO분께서 문제점, 로드맵, 효과 등에 대해 정리해서 발표해주면 좋겠다는 의견을 주셔서 전사 위클리 시간에 발표를 진행해, 팀원분들의 공감대도 만들 수 있었다. 7,8월 두달 동안 집중해서 진행할 예정으로 이후에 많은 개발자분들이 좋아하고 제품적으로도 더 안정적일 수 있기를 기대하고 있다.

프로젝트 정리 작업

리팩토링 프로젝트는 서버와 프론트가 소통하는 영역에서의 문제를 해결한다면 프론트 자체적으로 해결해야할 문제점들도 있었다. 5월중 앱이벤트가 누락되거나 잘못찍히면서 생겨 전사 데이터에 영향을 준 적도 있었고, 이전 통합결제 기능 배포과정에서 생긴 v2 폴더들로 인해 복잡해진 프로젝트 폴더 구조로 찾기 어려운 문제도 있어 폴더 정리도 필요해 보였다.

로그의 경우 DOM, DA분들과 함께 보다 개발자 친화적이고 자동으로 잘 기록될 수 있도록 버전을 올린 버전으로 새롭게 정의하는 작업을 진행해 마이그레이션을 진행했다. 그과정에서 누락되거나 잘못 남기고 있던 부분들을 수정할 수 있었다.

폴더 정리나 미뤄져왔던 세이브잇 시절 코드 정리작업을 하나 둘 진행하면서 불필요한 복잡도를 조금씩 낮출 수 있었다.

돌아보는 6월의 액션아이템과 7월 액션아이템

5월에 세웠던 6월의 액션아이템을 돌아보면 두가지 다 진행했다. 프론트 코드 정리작업은 프론트와 서버가 함께 해결해야하는 문제와 내부적으로 정리해야하는 문제들을 챙길 수 있었다. 조금 아쉬운 부분은 히스토리 문서화로 AI를 이용해 전체 프로젝트에 대해 분석시키고 더 히스토리화 하는 법을 배워야겠다는 생각이 든다. CSR 페이지를 SSR로 마이그레이션을 일부 진행했지만 아직 더디게 느껴진다. 그 이유는 SSR 페이지간 인증 공유를 위한 부분에 대해 작업이 필요하기 떄문으로 7월중에 체계를 잡아 조금 더 편하게 마이그레이션이 가능하게 만들어보려한다.

프론트 코드 정리 및 히스토리 문서화하기
CSR페이지 SSR로 마이그레이션하기

7월의 액션 아이템은 아래와 같다.

AI를 통해 히스토리 문서화 해보기
CSR페이지 SSR 마이그레이션을 위한 인증 공유 체계 구축

매번 다양한 문제들을 만나는 토스생활이지만, 그래도 내가 느끼는 문제를 함께 공감해줄 수 있는 동료가 있고 같이 해결해보자하는 분들이 많다는 점인 것 같다. 7월에는 워크샵이 있어 조금 더 짧게 느껴지겠지만 로드맵에 따라 잘 완수해 제품의 안정성도 높이고, 팀 전체의 신뢰를 높일 수 있는 좋은 계기가 되기를 바라본다.

2025년 5월 회고

Tue, 03 Jun 2025 00:00:00 GMT

드디어 가장 바쁜 25년 정기신고 기간이 끝나게 되었다. 정말 감정적으로 체력적으로 다양한 오르내림이 있었던 한달로 글을 작성하는 6월 3일 아침 마무리되었다. 다이나믹했던 5월에 정리해보자.

😂 길고 길었던 5월의 작업들

5월의 작업량을 보면 가히 평월의 2배~3배로 진행되었던 것 같다. 작업양은 깃헙 잔디만 봐도 느껴질 수 있었는데 4월 말부터 5월의 하루 커밋양을 보면 하루 최대 60개에 달할 정도의 작업이 있었다.

매일매일 회의를 통해 액션아이템을 결정하고 그에 따라 팀의 작업방향이 수시로 바뀌기도 했고, 5월에만 가능한 정기신고이다보니 미리 준비는 했지만 놓쳤던 부분을 보완하거나 24년을 위해 특별히 추가된 공제를 지원하는 등의 작업이 필요했다.

특히 결혼공제의 경우 유저의 오입력을 막기 위해서 수정을 4차까지 진행해 사일로에서 진행했던 여타 실험보다 더 빠르게 결정하고 수정하는 작업을 진행했다. 유저의 입력을 직접 받을 수 밖에 없는 공제 내용이었고 24년 혼인신고를 한 경우에만 공제를 받을 수 있다보니 24년에 결혼을 했는지, 24년에 결혼한 상태인지로 잘못 인지하고 예로 답할 경우 공제금액이 달라지기 때문에 정말 빠르게 대응이 필요했다.

이외에도 5월에 새롭게 진행된 작업들로 선정산/후결제, 납부 지원 작업 등 다양한 기능도 빠르게 개발이 필요했다. 매일 몰려오는 CS들과 큰 작업들로 인해 5월 초반과 중반 그리고 후반의 업무 집중도와 텐션이 점점 고갈되어감을 느꼈고 혼자 책임감으로 끙끙 앓다가 업무 중 감정적으로 대하는 모습들을 팀원들에게 보이기도 했다.

팀원분들은 "흑화했다"라고 귀엽게(?) 표현해주셨지만 해당 경험을 통해서 혼자서 감당이 안되면 팀원분들께 더 적극적으로 도움을 요청하는 것의 중요성을 크게 느끼게 되었다. 혼자서 고민하기보다 일정을 조율하거나 작업 방식을 변경하는 등의 다양한 방식이 있었을텐데, 주어진 걸 기한 내에 마무리 해야한다는 것에 너무 많은 책임감을 느꼈던 걸까, 못한다고 말하면 나의 부족함을 보이는 것이라 생각해서였을까 오히려 좋지 않은 의사소통 방식으로 진행하게 되었던 것 같다.

정말 일이 많고 힘들 때 나의 모습이 어떤지 보게 되었고 더 좋은 의사소통에 대해 고민하게 된 시간들이었다. 개인적인 우여곡절이 많았지만 정말 다행히도 팀 전체가 열심히 달려온 5월, 정말 기쁘게 전사 목표를 달성할 수 있었다.

SSR 적용과 개별 도메인 지원을 통한 개발 생산성 향상시키기

4월부터 준비해온 SSR 도입 작업을 5월 중순에 드디어 라이브에 적용하게 되었다. 해당 작업을 시작하면서 목표는 LCP 개선과 SSR 배포 파이프라인을 세팅하면서 지원가능하게된 작업자별 개별 개발 도메인 지원이었다.

SSR 작업은 기존 서비스는 유지하면서 렌더링 방식을 변경하기 위해서 모노레포 구조로 진행되어 CSR용 폴더를 스캐폴딩해 SSR 폴더로 옮긴다음에 SSR을 적용하는 방식으로 진행하게 되었다.

이과정에서 코어 환경에서 이미 잘 구축되어있는 SSR 관련 코드들을 전체적으로 분석하고 인컴 환경에 맞게 수정해 전체적인 SSR에 대한 지식을 높일 수 있었다. 특히 잃어버린 유저의 시간을 찾아서 : 100년을 아껴준 SSR 이야기 영상과 마이그레이션 가이드 문서를 보면서 많은 것을 배울 수 있었던 시간이었다.

현재 적용한 화면은 가장 초기화면인 index화면이지만 해당 화면에 SSR을 적용하기 위해서 어떻게 인증과정을 수정할지, react query와의 의존성은 어떻게 관리할지, 디자인 시스템인 TDS와의 연동은 어떻게 할지, 중간에 로그가 누락되는 문제는 어떻게 해결할지 등 정말 다양한 이슈와 고민들을 거쳐서 1차본을 완성해 적용하게 되었다.

아직 전체 페이지에 편하게 적용할 수 있는 상황이라 조금 더 개선이 필요해 6월부터 확장해나가려한다.

작업 과정에서 CSR과 SSR 두가지 폴더에 쪼개져있다보니 하나의 기능을 위해 각각에 작업해야하는 프론트 개발자의 비용과 두배로 테스트해야했던 QA팀의 배려가 있었고 덕분에 안전하게 배포될 수 있었다.

5월이라는 큰 이벤트가 있는 시기에 SSR이라는 큰 기술적 변화를 하는데에 많은 압박감이 있었지만 팀이 필요하다고 공감 해주셨던 문제점은 단순히 로딩시간 개선보다는 팀의 생산성 개선에 있었다.

SSR으로 마이그레이션 전까지 개발과정은 여러명의 개발자가 하나의 개발 도메인을 사용하고 테스트를 하고 있어 QA를 위해서 점유가 필요한 상황이었다. 이과정에서 라이브 액티비티와 같은 네이티브 기능이 필요한 경우에 실기기에서 봐야하기 때문에 큰 병목이 되고 있었고, QA 과정에서 자동으로 다른 분의 작업이 병합되면서 github 액션이 돌경우 갑자기 이전에 했던 QA 이슈들이 되살아나서 혼란스러운 상황이 계속해서 있어왔다.

SSR 덕분에 해결된 것은 아니지만 SSR을 도입하면서 배포 파이프라인을 새롭게 구축하게 되었고 이과정에 플랫폼 개발자분의 지원을 통해 개발자별 개별 도메인을 개발 환경에서 사용할 수 있게 변경되어 기존의 개발과정에서의 문제점을 해결해 개발 생산성을 크게 끌어올릴 수 있었다. 개발자는 편하게 실기기에서도 테스트를 할 수 있는 환경이, QA분들도 해당 개발작업만 보실 수 있는 큰 장점으로 인플로우와 퍼널 작업 크고 작은 실험이 빠르게 배포되는데 크게 기여할 수 있었다.

과정에서 아쉬웠던 점은 제품 개선 측면에 대한 분석이 어려웠던 점이다. 팀의 비용을 고려해 하루에 점진 배포로 100프로까지 올려버려 SSR 도입을 통해 유저 전환율과 같은 제품 기여도에 대해 측정하지 못했다. 이후 SSR을 확장할 때는 실험을 통해 실제 유저에게 로딩속도가 얼마나 중요한지 볼 수 있게 준비해보려 한다.

5월 이후 남은 과제들

5월에 다양한 작업들을 빠르게 진행하면서 정리되지 못하고 남아있는 코드들과 맥락들이 많아지게 되었다. 이와함께 혼자 고맥락의 제품을 개발하면서 높아진 버스지수에 대한 고민이 이어지게 되었다. 서로가 백업을 해줄 수 있고 인컴 프론트 개발자 모두가 심리적 안정감을 갖고 일할 수 있게 하기 위한 시간이 필요하다고 생각이 자연스레 들었다.

이를 위해서 6월에는 꼭 코드 정리와 함께 맥락 다운로드 등을 위한 작업들이 필요하다고 생각해 대표이신 일용님과 팀에 건의드렸고 팀에서도 공감을 받을 수 있었다. 또한 나뿐 아니라 서버 개발자분들도, QA 팀에서도 필요성을 느끼고 있어 함께 정비하는 시간을 갖기로 정해지게 되었다.

6월은 현재 프로젝트 코드 구조나 설계 방식 등 나만 알고 있는 맥락을 최대한 다운로드 드리고, 기존 서비스 내 문제점들을 발굴하고 수정해 나가려 한다.

돌아보는 5월의 액션아이템

4월회고에 작성했던 5월의 액션아이템들은 모두 수행했다.

5월에 빠르게 팀 업무 지원하기
5월을 겪으며 개선해야할 부분 정리하고 챙기기
SSR로 라이브 성공하기

6월은 액션아이템으로 2학기를 위해 더 빠르게 성장하기 위한 준비할 예정이라 아래와 같이 액션아이템을 세워보려 한다.

프론트 코드 정리 및 히스토리 문서화하기
CSR페이지 SSR로 마이그레이션하기

정말 다사다난했던 5월을 보내며 6월은 2학기와 내년 5월을 더 잘 준비하기 위한 기반을 잘 갖추고, 이번 5월의 경험을 통해 더 좋은 개발자, 더 좋은 동료가 되길 바라본다.

2025년 4월 회고

Mon, 19 May 2025 00:00:00 GMT

4월 회고를 5월 중순에야 작성하기 시작하게 되었다. 소문으로만 듣던 인컴의 5월이 오면서 정말 많은 작업들을 하고 실시간으로 대응하다 드디어 시간이 조금 나 작성해보려 한다. 정신없이 흘러간 4월을 다시 꺼내 정리해보며 남은 5월 동안의 액션 아이템도 챙겨가보려 한다.

드디어 오픈한 오픈소스 react-simplikit

작년 12월부터 참여한 오픈소스 프로젝트 react-simplikit가 오픈했다.

12월 토스 오프 위크일 때 토스 프론트엔드 온보딩 겸 기존 여러 유틸들과 훅들을 분석하기 시작해 라이브러리에 오픈 직전 목표로 했던 26개의 훅/유틸/컴포넌트들 중에서 45%인 12개의 구현을 담당했다. 사내 프로젝트들에 적용하기 위해서 변경된 인터페이스가 있으면 codemod를 만들어서 cli로 간편하게 마이그레이션을 돕는 등의 작업들과 문서화 작업 등 다양한 작업에 참여할 수 있었다.

react-simplikit pr들

목표로 했던 구현체를 완성하는데 까지는 생각보다 빠르게 완료되었지만 기존에 유사한 컨셉의 리액트 유틸 라이브러리인 react-use와 같은 라이브러리들이 있었고 홍보전략과 우리만의 강점을 찾아나가는데 많은 시간이 필요했다.

그중 가장 신경썼던 부분으로 토스의 노하우를 담으면서도 리액트 외의 의존성이 없고 테스트 커버리지를 100프로라는 점을 우리의 강점으로 내세웠다.

테크니컬 라이터분의 도움을 받아 문서를 정리하고, 그래픽 디자이너분께서 로고를 만들어주시는 등 많은 분들의 도움을 받아 완성할 수 있었고 토스 공식 링크드인 등 다양한 홍보도 진행했다.

내가 올린 linkedin 홍보 글

이미 경쟁 라이브러리들의 스타나 기여받는 수가 많은 상태라 잘 될 수 있을까라는 걱정이 많았지만, 다행히 사람들이 관심을 가져주었고 그결과 현재 5월 19일 기준 총 233개의 스타를 가지고 있고 계속해서 이슈와 pr이 올라오는 중이다.

react-simplikit pr들

하나의 라이브러리가 만들어지는데 얼마나 많은 노력이 필요한지 배울 수 있었고, 왜 우리 라이브러리를 사용해야 하는지를 고민하면서 하나의 제품을 판다는 느낌을 받을 수 있었다.

현재 5월까지 사일로 업무가 많은 상황이라 참여를 못하고 있지만, 6월부터 계속해서 관리하면서 조금 더 유용한 훅들을 추가하고 다양한 의견도 주고 받을 수 있게 기여를 조금 더 해보려한다.

5월을 위한 다양한 작업들: 라이브 액티비티, 24년 세법 반영

4월 중순부터는 우리팀의 가장 큰 대목인 5월을 준비하기 위한 작업을 바쁘게 진행했다. 갑자기 많은 사람들이 몰렸을 때를 위한 대기열 기능을 추가하고 더 자주 유저가 들어올 수 있도록 Live Activity를 추가하는 등 다양한 작업을 담당하고 진행하게 되었다. 대기열 기능을 원래는 숨은 환급액 찾기 서비스에만 적용하는게 팀의 목표였지만, 인플로우 제품들에도 필요할 것 같다고 판단해 extra mile로 작업을 해두었다. 4월 말에 갑자기 증권과의 협업으로 인플로우에 트래픽이 몰리면서 서비스 장애를 맞을 뻔했지만 이때 미리 작업해둔 덕분에 성공적으로 서비스를 할 수 있었다.

24년 새로운 공제 항목인 24년에 혼인신고한 부부를 위한 결혼 공제가 퍼널로 추가되었다. 4월 작업 당시에는 충분히 해당 UI로 인지하고 혼인신고 내용에 답을 하겠다는 생각을 했지만, 5월 초에 가장 괴롭히는 퍼널이 될줄은 몰랐다. 그내용은 5월에 작성해보려 한다.

주체적으로 진행해본 SSR 작업

기존 CSR로 되어있던 제품을 SSR로 전환해 초기 로딩속도를 개선해보려 했다. AWS에 단순히 빌드 결과를 올리고 다운받아 화면을 보여주는 것과는 다르게 서버를 띄우고, 특정 도메인으로 진입시에 해당 서버 주소로 연결시키는 등 생각보다 많은 작업이 필요하다는 것을 플랫폼 개발자분께 배울 수 있었다. 인프라적인 부분들은 많이 도와주셔서 서비스 코드를 SSR로 전환하는데에만 집중할 수 있었고, 가장 많은 트래픽이 모이는 index 페이지를 전환에 성공하게 되었다.

기존 서비스와 비교했을 때 진입시 7초에서 4초정도로 3초로 57% 이상 초기 랜딩 속도가 줄어드는 효과를 보여주었다.

시간이 타이트하지만 라이브에 내보낼 수 있도록 더 꼼꼼히 테스트해보고 있고, 여러명이 동시에 작업할 수 있도록 각자의 도메인에 각자의 빌드 결과물을 올릴 수 있는 개발 환경 개선도 작업중에 있다.

작업만 하다보니 작업 내용을 정리하지 못해 소그룹에 내용을 공유하지 못하고 있고 아직 많은 페이지가 CSR로 동작하고 있다. 5월이 끝난 후에는 같이 이야기할 수 있도록 잘 정리해서 인컴만의 SSR 적용방식을 소개해보려 한다.

돌아보는 4월의 액션아이템

4월의 액션 아이템은 아래와 같았다.

Tanstack Query 문서 정리하고 소그룹 내 발표하기
개인 클러스터 지원 작업 진행해보기
세금 도메인 관련 서적 읽고 정리하기
사내 라이브러리 기여하기

첫번째 tanstack query를 next와 함께 사용하는 방식을 정리해서 공유해보려했는데 SSR을 어떻게 적용할 지 고민하다가 발표까지 하지 못했고, 세금 도메인 관련 서적을 읽고 정리하는 건... 기술적인 내용을 공부하는 것에 우선순위에 미뤄져 하지 못했다.

대신 개인 클러스터와 같이 개발환경 개선작업과 사내 라이브러리 기여 및 오픈까지 성공적으로 완수한 한달이었다.

5월의 액션 아이템은 아래와 같이 정리해보려 한다.

5월에 빠르게 팀 업무 지원하기
5월을 겪으며 개선해야할 부분 정리하고 챙기기
SSR로 라이브 성공하기

5월은 팀의 의사결정이 실시간으로 이루어지고 굉장히 많은 트래픽이 몰리는 시기이기 때문에 더 기술적인 문제들보다 팀의 문제에 많이 집중해보려 한다. 이미 5월을 겪고 있는 상황에서 굉장히 힘들지만 그안에서 느끼는 여러 감정과 일을 어떻게 할지, 어떻게 대할지에 대한 생각을 다음달 회고에 작성해보려 한다.

2025년 3월 회고

Sun, 30 Mar 2025 00:00:00 GMT

2025년 3월도 빠르게 흘러갔다. 우리 팀의 큰 대목인 5월이 다가오면서 갈수록 더 분주하게 준비해나가는 것 같다. 세금 시장에 대한 다양한 실험 작업과 기술적고민과 커리어에 대한 고민 등을 했던 3월에 대해 기록해보려 한다.

세금이란 도메인에 대해 더 알고 싶어

처음 토스 코어에 합류하고 현재 5개월 가량이 되었다. 5개월 간의 시간동안 숨은 환급액 찾기라는 하나의 서비스에 대해서 다양한 시도와 실험을 진행해왔다.

11월 오자마자 일주일만에 만들었던 환급액 2배 이벤트부터 유저들의 많은 관심을 받았던 연말정산 미리보기, 25년 현재까지 conversion boost silo의 한명의 프론트 개발자로서 환급 과정에 필요한 스크래핑, 공제, 결제, 신고라는 서비스 전반적인 작업들에 대한 실험과 개선 작업들을 담당하고 있다.

좋은 동료들과 좋은 결과들을 만들어가면서 내 안에 앞으로의 토스 생활을 어떻게 가져갈지, 인컴과 코어중 어디서 커리어를 이어나갈지에 대한 고민이 시작되게 되었다.

1년 반정도의 모바일 개발, 6개월 정도의 프론트엔드 개발을 하면서 클라이언트 개발은 다양한 분야와 접해져 있고 상대적으로 넓지만 얇게 많이 알아야한다고 느껴졌다. 그과정에서 아쉬웠던 점은 서버 개발자분들에 비해 도메인을 코드로 표현하는 경우가 많지 않았다. 어떤 서비스별로 만드는데 있어서 중요한 특징들에 대해 경험하지 못하고 잘 이해하지 못하고 개발하고 있다는 갈증이 있었다.

이러한 고민을 갖고 있던 나에게 숨은 환급액 찾기라는 서비스는 조금 달랐다. 세금이라는 어려운 도메인을 보다 쉽게 풀어내기 위해서 애쓰는 동료들과 있다보니, 모르면 코드를 작성하지 못하는 경험도 하게 되고, 이 일을 왜 해야하는지 납득하기 위해서 공부할 수 밖에 없었다. 토스에 왔는데 금융 맥락의 제품을 꼭 경험하고 싶던 나에게 정말 운좋게 찾아온 기회같이 느껴졌다.

그래서 큰 결심(?)으로 토스 인컴으로 4월 1일부터 전적하기로 결정했다. 코어에는 90명이나 되는 뛰어난 프론트엔드 개발자분들이 계시고, 각 분야에서 잘하시는 분들이 많이 계셔서 더 가까이 배울수 있는 장점과 코어 내의 100개가 넘는 정말 많은 서비스들이 있다보니 다양한 도메인에서의 성장 기회를 놓치는 건 아닐까 많이 고민했다.

하지만 인컴에서 파견으로 근무하는 과정에서도 여전히 끊기지 않고 계속해서 좋은 코드를 토론하고, 함께 오픈소스를 만들고, 업무 협력을 많이 하고 있고, 현재 서비스를 5개월만으로 "나는 이 서비스를 정말 잘 이해하고 있어", "나는 이 서비스를 만들기 위해 정말 노력했어"라고 하기에는 아직 하고 싶은게 많았다.

코어라는 든든한 울타리, 깔끔하게 포장된 고속도로를 달리는 대신 아직 많이 개선하고 부딪히면서 배워나가야하는 오프로드에서 직접 자갈도 치우고 길을 만들면서 성장하고 싶다는 생각에 선택하게 되었다.

그렇게 선택하고 나니 서비스에 의견을 내는데 왠지 모르게 적극적이게(?) 되었다. 어디서 전환율이 떨어지는지, 어떻게 팀 목표를 이룰 수 있을지 주어진 일만 하는게 아니라 아이디어들도 조금씩 더 내보고 있다.

그리고 추가로 2월에 목표로 했던 세금 도메인 관련 서적 읽기을 액션 아이템을 실행했다. 이번 달 읽은 책은 물어보기 부끄러워 묻지 못한 전국민 세금상식으로 가벼운 책이었지만 상속세, 부가세, 취득세 등 우리 생활에 곳곳에 숨어있는 세금 영역에 대해 알게 되었고 우리 팀이 목표로 할 다양한 시장들에 대해 알 수 있었다.

토스 인컴을 선택하면서 내가 가진 기대감들과 함께, "불편함을 느낄 때 사람은 행동하고, 행동할 때 성장한다"고 생각하는 나에게 새로운 도전의 기회를 만들어 나가길, 그리고 그 기회를 잡아 더욱 성장하는 개발자가 되기를 바라본다.

스크래핑 퍼널 개선

3월에는 신고 내역 개선, 결제 화면 실험 등 다양한 작업들을 진행했지만 그중 가장 개인적으로 하고 싶었고, 고민을 많이 했던 것은 스크래핑 퍼널 개선 작업이었다.

스크래핑은 특정 서비스를 진행하기 위해서 필요한 인증이나 특정 절차를 앱내에서 할 수 있도록 구현하는 과정으로 숨은 환급액 찾기 서비스에서는 유저별 환급액을 계산하는 기준이 되는 여러가지 데이터를 가져오는 서비스의 시작점이라고 볼 수 있다.

기존에는 2개 또는 3개의 스텝만 거치면 되기 때문에 하나의 페이지에서 퍼널이 구현되어 있던 상황이었지만, 현재 조건에 따라 2개에서 5개까지 늘어난 상황이다보니 여러가지 문제점이 발생하게 되었다.

먼저 유저 경험적으로 길어진 퍼널 스텝만큼 이탈율이 증가할 수 있게 되었고, 내부적으로 스크래핑에 걸리는 시간이 길어질 수록 이탈율이 급격하게 증가하는 데이터가 있어 이를 근거로 작업을 진행할 수 있었다.

두 번째로는 하나의 화면에 여러 서비스를 대응하는 방식으로 구현되어 있기 때문에, 각각의 서비스 특성을 살린 코드를 작성하기 어려웠다. 단순 문구를 변경하는 것에도 여러 depth를 거쳐서 수정해야했고 이로 인해 컴포넌트 별 내부는 서비스 분기문이 늘어나 한번에 읽기 어려운 코드들이 작성되고 있었다.

세 번째로 엔진의 개선으로 불필요해진 스텝과 로딩 시간이 줄어들었다. 엔진을 개발하시는 개발자분들의 노력으로 특정 유저들의 환급액 계산에 필요했던 스텝이 엔진의 개선으로 불필요해짐에 따라 제거가 가능해졌고, 스크래핑에 걸리는 시간이 줄어들어 로딩화면도 그에 맞게 단축된 버전으로 만들 필요가 생겼다.

이러한 제품적 필요성과 함께 평소에 개선하면 좋겠다 싶었던 다소 모호했던 API 인터페이스를 서버 개발자분들과 다시 정의하고 적용하는 작업을 했고, 구간별 성능 개선작업도 함께 진행했다.

작업을 진행하면서 특히 신경썼던 부분은 도메인에 서비스별 스크래핑 분기를 최대한 상위에서 사용처와 함께 두고, 하위 컴포넌트들은 도메인 맥락없이 단순히 조합할 수 있는 구조를 가져가려했다.

예를 들어, 인증 스텝을 구현할 때 공통되는 컴포넌트를 만들고, 공통되는 컴포넌트 필요한 요소를 prop으로 전달해 만든 컴포넌트를 사용처에서 사용하는 형식으로 코드 중복은 줄이면서도 최대한 사용처에서 명확하게 사용할 수 있게 하려했다.

function BaseAuthStep(props:AuthStepProps){
    // 공통로직
}

export const AuthStep={
    숨은환급액찾기: (props:AuthStepProps)=> <BaseAuthStep title={"숨은 환급액 찾기"} {...props}>
    연말정산미리보기:(props:AuthStepProps)=> <BaseAuthStep title={"연말정산 미리보기"} {...props}>
}

function 숨은환급액찾기Funnel(){
    return(
        <Funnel.Render
            AuthStep={()=> <AuthStep.숨은환급액찾기 >}
            //...
        />
    )
}

function 연말정산미리보기Funnel(){
    return(
        <Funnel.Render
            AuthStep={()=> <AuthStep.연말정산미리보기 >}
            // ...
        />
    )
}

열심히 개선 작업을 하고 동료분들의 좋은 피드백도 받았지만, 개선으로 인해 새로운 문제도 발생하게 되었다. 예를 들면, N개의 서비스에 따른 N개의 퍼널 페이지가 만들어지다 보니 로깅과 같이 명령적으로 작성되는 코드들에서 누락되는 문제가 있었다.

기존 하나의 페이지에서 공통화 되어있던 부분들이 쪼개지는 과정에서 서비스마다 다른 부분, 공통으로 관리해야할 부분 등에서 놓치는 부분이 생겼던 부분이었다.

그래도 작업을 진행하면서 퍼널 개선 작업의 원래 범위는 숨은 환급액 찾기만이었지만 extra mile로 인플로우 팀의 다양한 제품들도 모두 개선된 스크래핑 퍼널을 이용할 수 있게 추가작업을 진행해 전체 제품에서의 개선을 이끌어내기도 해 적극적으로 작업해본 성공적인 첫 시도였다.

배포를 이번주에 나가 아직 퍼널 전환율 등 데이터를 보지 못했지만 좋은 영향이 있기를 기대하고 있다.

조금 더 과감해지자

3월에는 동료분께서 인트로 화면 진입시간의 문제점을 제기하고 SSR도입 작업에 대해 팀에 적극적으로 공유하고 공감대를 만들어 내 4초에서 5초까지 걸리던 구간을 0.5초로 단축하는 큰 성과를 만들어냈다.

동료분의 일하는 모습을 보면서 토스가 일하는 방식에 대해 생각을 다시 한번 이해하게 되었다.

나 또한 인트로 화면에서 오래걸리고 있다는 문제가 있다는 것을 알고 있었다. 당시 그것보다는 팀의 다른 작업을 하는 게 더 중요하다고 생각한 것도 있지만 나는 로딩 시간이 오래걸리는 게 큰 문제라고 나에게 시간을 주면 해결해보겠다고 말할 용기가, 팀원들을 설득할 용기가 없었던 것 같다.

동료분의 문제 제기를 하고 공감대를 만드시는 과정을 보면서 행동하지 못했던 나의 부족함을 느꼈고, CSR과 RN만 경험했던 나와 달리 SSR을 도입했을 때 명확한 효과가 있을 것이라는 것에 물음표를 던졌던 나와달리 다른 개발자 분들과 치열하게 의논하고 플랫폼팀의 도움을 받아 작업하시는 모습에서 방법을 찾고 문제를 해결하는 방향에서도 적극적으로 도움을 구해야한다는 것을 배울 수 있었다.

문제를 문제라고 생각한다면 조금 더 과감하게 말하는 것, 그리고 그 문제를 풀기 위해 다양한 리소스를 구하고 책임지고 해결하는 것 내가 배울 부분이라 느껴졌다.

너무 고민만 하기보다 행동으로 시도해보는 것, 3월에 배운 토스에서 일 잘하는 동료의 모습이었다.

3월의 액션아이템과 다음 달을 위한 액션 아이템 정리

3월 회고에서 작성했던 액션아이템은 아래와 같다.

퍼널 개선 작업 진행하기
더 일을 잘하기 위해 일감을 쌓고 함께 진행하기
세금 도메인 관련 서적 읽고 정리하기
사내 라이브러리 기여하기
HMR 관련 글 작성하기

2월에 비해 많은 부분을 진행했던 달이었다. 앞서 작성했던 대로 퍼널개선 작업과 세금 도메인 관련 서적을 읽었다.

더 일을 잘하기 위해 일감을 쌓고 함께 진행하기 위한 작업은 리스트업을 했을 때 가장 필요한 작업으로 개인 클러스터 작업이 떠올랐다. 두명이 하나의 서비스에서 작업하다보니 테스트 환경을 점유하는 형식으로 테스트가 진행되거나, 서로 버전이 달라 덮어써져 QA에서 해결된 문제가 다시 발생하는 등 여러가지 이슈가 있어 왔다. 4월에는 이를 위한 작업을 진행하고, AWS에 대해서도 공부해보고자 한다.

HMR 관련 글도 드디어 작성했다. 사실 목표는 fast-refresh 동작방식까지 보고 싶었지만 너무 방대하기도 했고, webpack을 잘모르는 상황이었다 보니 webpack-dev-server과 webpack에서의 HMR 동작방식을 먼저 알아보았다.

사내 라이브러리 작업은 아직 정체기에 있다. 길드에서 호기롭게 추가할 작업목록을 작성해보겠다 했지만 아직... 하지 못했다. 메인 업무와 함께 길드 작업을 하는 건 생각보다 많이 빠듯하긴 하지만, 오픈 소스가 제대로 오픈되고 많은 관심을 받을 수 있게, 조금 더 내가 반복적으로 코드를 작성하는 부분들에 대해 관심을 갖고 동료분들의 코드를 보면서 같이 포함되면 좋을 부분을 정리하려 한다.

4월의 액션아이템

다음 달을 위한 액션아이템은 아래와 같다.

Tanstack Query 문서 정리하고 소그룹 내 발표하기
개인 클러스터 지원 작업 진행해보기
세금 도메인 관련 서적 읽고 정리하기
사내 라이브러리 기여하기

3월과 동일하게 가져가는 두가지 액션아이템과 함께 새롭게 개인 클러스터 관련 작업과 Tanstack Query 문서 정리하고 소그룹 내 발표하기는 새롭게 진행해보려 한다.

인트로 뿐 아니라 서비스 전반적으로 SSR을 도입하려는 상황에서 토스의 SSR에서 데이터 패칭 방식을 이해가 필요해졌다. 이에 대해 정리하고 소그룹 내에 발표도 하면서 조금 적극적으로 학습을 해보려 한다.

글로 정리하다 보니 정말 다양한 고민과 결정을 했던 한달이었던 것 같다. 다가오는 5월을 대비해 아마 막판 스퍼트를 하게될 4월에 더 많은 기여와 성장을 기대해본다.

HMR, webpack-dev-server 알아보기

Sun, 16 Mar 2025 00:00:00 GMT

HMR은 개발과정에서 full reload 없이 파일 변경에 따른 모듈의 변화, 추가, 삭제를 감지하고 즉시 반영해 개발 속도를 높이는 기능이다. 보통은 프레임워크나 라이브러리에서 제공하는 기능으로 React에서는 React-refresh 패키지를 이용해 제공하고 있고, Next에서는 Fast Refresh로 제공하고 있다. 최근 Next로 서비스를 개발하면서 발생한 Fast Refresh 이슈를 해결하고 프론트엔드 챕터 내 해결방안을 공유하게 되었다. 그과정에서 평소에 깊이 있게 이해하지 않았던 내용들이 있어 정리해보고자 한다.

HMR (Hot Module Replacement)

HMR은 webpack에서 잘 설명되어있어 webpack 공식 문서를 참고해 정리해보려한다. HMR은 webpack의 설명을 보면 어플리케이션이 동작하는 동안 full reload 없이 모듈의 변화, 추가, 삭제를 감지하고 이를 적용해 개발 속도를 높이는 기능으로 소개하고 있다.

full reload를 하게 되면서 자바스크립트를 새롭게 받아와 실행하기 때문에 작업 과정에서 만들어진 기존 상태와 데이터 등을 모두 잃어버리게 되기 되는데 이를 방지하고, 필요한 모듈만 업데이트해 개발시간을 단축할 수 있다.

HMR 동작방식

HMR이 동작하는 과정을 webpack 공식 문서에서는 각 요소별로 역할을 설명하고 있다.

Application

Application은 브라우저에서 실행되는 JavaScript 코드를 의미하며, HMR의 클라이언트 부분을 담당한다.

HMR 런타임을 통해 업데이트 확인 요청
업데이트된 모듈을 비동기적으로 다운로드
런타임에 업데이트 적용
애플리케이션의 상태를 유지하면서 새로운 코드를 적용

Compiler

컴파일러는 코드가 변경됨에 따라 새로운 변경된 코드를 만들어낸다. 이때 변경된 파일에는 새롭게 컴파일된 해시가 담겨있는 manifest와 chunk가 포함되어있다.

Module

코드 변경이 일어날 모듈에는 변경되었다는 것을 알려줄 수 있도록 HMR 코드가 작성될 수 있다. 모든 파일에 작성될 필요는 없으며, 업데이트는 버블링 되어 적용된다. webpack에서는 module.hot 객체를 통해 제공된다.

Runtime

파일 변경이 일어나면 각 파일별로 실행할 콜백함수를 지정할 수 있다. webpack에서 이때 두가지 API가 제공되는데 check, apply가 있다.

check: 변경된 모듈이 존재하는지 확인
apply: 변경된 모듈을 적용

공식 문서의 내용을 정리해보면 HMR 기능을 위해서 총 5가지 과정이 필요하다.

개발 서버
파일 변경 정보를 주고 받을 웹소켓 서버와 클라이언트
파일 변경 감지에 따른 이벤트 수신/발신
변경된 모듈 파일에 대한 재컴파일 및 파일 전송
변경된 모듈을 받아 애플리케이션에서 변경사항 적용

webpack-dev-server을 이용해 HMR 구현해보기

이제 webpack을 이용해서 HMR기능을 간단히 구현해보자. 이또한 가이드 문서에 자세히 나와있어 해당 예시로 구현해보았다.

webpack-dev-server는 webpack에서 제공하는 개발 서버로 버전 4.0.0부터 default로 HMR 기능을 제공한다.

npm install --save-dev webpack-dev-server

// package.json
"scripts": {
  "start": "webpack serve --open"
}

// webpack.config.js
module.exports = {
  // ...
  devServer: {
    hot: true, // default: true
  },
}

여기에 css와 같은 스타일의 변화는 style-loader를 추가하면 된다. style-loader 내부에는 module.hot으로 변경된 스타일을 적용할 수 있게 구현되어 있다.

// webpack.config.js
module.exports = {
  // ...
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },

생각보다 너무 간단하게 구현되었는데 webpack-dev-server 패키지와 webpack 자체적으로 많은 로직을 캡슐화하고 처리하기 때문이다.

그러면 조금 더 내부에 어떻게 구현되어있는지 알아보자. 아래 설명할 때는 위 5가지 기능에 좀 더 초점을 맞춰서 순서대로 분석해보려한다.

Webpack과 webpack-dev-server 파헤쳐보기

먼저 webpack-dev-server 패키지 정보를 살펴보자.

// https://github.com/webpack/webpack-dev-server/blob/master/package.json
{
  "dependencies": {
    "ansi-html-community": "^0.0.8",
    "bonjour-service": "^1.2.1",
    "chokidar": "^3.6.0",
    "colorette": "^2.0.10",
    "compression": "^1.7.4",
    "connect-history-api-fallback": "^2.0.0",
    "express": "^4.21.2",
    "graceful-fs": "^4.2.6",
    "http-proxy-middleware": "^2.0.7",
    "ipaddr.js": "^2.1.0",
    "launch-editor": "^2.6.1",
    "open": "^10.0.3",
    "p-retry": "^6.2.0",
    "schema-utils": "^4.2.0",
    "selfsigned": "^2.4.1",
    "serve-index": "^1.9.1",
    "sockjs": "^0.3.24",
    "spdy": "^4.0.2",
    "webpack-dev-middleware": "^7.4.2",
    "ws": "^8.18.0"
  }
}

중요하게 사용되는 패키지들을 정리해보면 아래와 같은 기능을 구현하기 위해 각 패키지가 사용되고 있다.

chokidar: 파일 변경 감지
express: 개발서버 구현
sockjs,ws: 웹소켓 통신
webpack-dev-middleware: 미들웨어 구현

폴더 구조를 보면 크게 두가지로 서버와 클라이언트로 나눠져 있다.

webpack-dev-server-folder-structure

개발 서버와 웹소켓 서버

그러면 먼저 서버를 살펴보자. 서버에는 TCP, proxy 등 webpack에서 제공하는 다양한 옵션들이 제공되고 있기 때문에 최대한 HMR에 필요한 기능만 정리해서 자체적으로 만든 코드와 함께 비교하며 정리해보려한다.

HMR을 위해서 첫번째로 개발서버가 필요하다. 간단한 예제에서는 express를 이용해 http 서버를 개발서버로 구현했다.

constructor에 서버를 구현하는데 필요한 주요한 내용들이 있다.

compiler: webpack 컴파일러
options: webpack-config.js에서 설정한 옵션들
currentHash: 모듈 해시
app: express 애플리케이션
server: http 서버

  constructor(compiler: webpack.Compiler, options: any) {
    this.compiler = compiler;
    this.options = options;
    this.currentHash = undefined;

    const app = express();
    this.server = http.createServer(app);
  }

실제 코드에서는 조금 더 복잡한 로직들이 담겨있다.

// https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L271
const getExpress = memoize(() => require("express"));

//https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L1853
  async setupApp() {
    /** @type {A | undefined}*/
  this.app =
    typeof this.options.app === "function"
      ? await this.options.app()
      : getExpress()();
  }
//https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L2546

 async createServer() {
    const { type, options } =
      /** @type {ServerConfiguration<A, S>} */
      (this.options.server);

    if (typeof type === "function") {
      /** @type {S | undefined}*/
      this.server = await type(
        /** @type {ServerOptions} */
        (options),
        /** @type {A} */
        (this.app),
      );
    } else {
      // eslint-disable-next-line import/no-dynamic-require
      const serverType = require(/** @type {string} */ (type));

      /** @type {S | undefined}*/
      this.server =
        type === "http2"
          ? serverType.createSecureServer(
              { ...options, allowHTTP1: true },
              this.app,
            )
          : serverType.createServer(options, this.app);
    }

    this.isTlsServer =
      typeof (
        /** @type {import("tls").Server} */ (this.server).setSecureContext
      ) !== "undefined";

    /** @type {S} */
    (this.server).on(
      "connection",
      /**
       * @param {Socket} socket
       */
      (socket) => {
        // Add socket to list
        this.sockets.push(socket);

        socket.once("close", () => {
          // Remove socket from list
          this.sockets.splice(this.sockets.indexOf(socket), 1);
        });
      },
    );

    /** @type {S} */
    (this.server).on(
      "error",
      /**
       * @param {Error} error
       */
      (error) => {
        throw error;
      },
    );
  }

두번째로 웹소켓 서버를 구현하려 한다. 간단 예제에서는 ws를 이용해 웹소켓 서버를 구현했다.

  private webSocketClients: WebSocket[] = [];
  private webSocketServer: WebSocket.Server | null = null;

  constructor(compiler: webpack.Compiler, options: any) {
    // ...
    this.createWebSocketServer();
  }

 createWebSocketServer() {
    if (!this.webSocketServer) {
      this.webSocketServer = new WebSocket.Server({ server: this.server });

      this.webSocketServer.on("connection", (ws) => {
        this.webSocketClients.push(ws as WebSocket);
        //  ...
        // 클라이언트와 연결 종료 시 정리
        ws.on("close", () => {
          const index = this.webSocketClients.indexOf(ws as WebSocket);
          if (index !== -1) {
            this.webSocketClients.splice(index, 1);
          }
        });
      });
    }
  }

websocket으로 연결 후 클라이언트에게 현재 상태를 전송하고 연결 종료 시 정리하는 로직이다.

간단 예제에서는 ws로만 선택해서 구현했지만 실제 코드에서는 지원할 수 있는 websocket type에 따라 sockjs, ws를 선택해서 구현하고 있다.

// https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L1621
getServerTransport() {
    let implementation;
    let implementationFound = true;

    switch (
      typeof (
        /** @type {WebSocketServerConfiguration} */
        (this.options.webSocketServer).type
      )
    ) {
      case "string":
        if (
          /** @type {WebSocketServerConfiguration} */ (
            this.options.webSocketServer
          ).type === "sockjs"
        ) {
          implementation = require("./servers/SockJSServer");
        } else if (
          /** @type {WebSocketServerConfiguration} */ (
            this.options.webSocketServer
          ).type === "ws"
        ) {
          implementation = require("./servers/WebsocketServer");
        }
        // ...
      default:
        implementationFound = false;
    }

    return implementation;
  }

이제 연결된 서버에 데이터를 전송하는 로직을 추가해보자. 예제 코드에서도 동일하게 사용해도 될정도로 sendMessage 함수는 간단하다. websocket client 상태가 OPEN이면 타입, 데이터, 파라미터를 담아 JSON 형식으로 전달해주는 역할을 한다.

sendMessage(clients: WebSocket[], type: string, data?: any, params?: any) {
    for (const client of clients) {
      if (client.readyState === WebSocket.OPEN) {
        client.send(JSON.stringify({ type, data, params }));
      }
    }
  }

그러면 어떤 데이터를 넘겨주는지 살펴보자. websocket 서버 연결시 stats 데이터를 넘겨주는데 이 데이터는 컴파일러에서 제공하는 데이터로 웹팩이 번들링하는 과정에서 생성되는 메타 데이터를 담고 있는 데이터이다.

// stats 예시
{ "hash": "33a462b5ab0e8f48a065", "errors": [], "warnings": [] }

이 데이터를 통해 현재 빌드가 변경되었는지 등의 상태를 확인할 수 있고 이를 통해 변경사항을 확인할 수 있다.

예제 코드에서는 createWebSocketServer로 클라이언트를 등록하고 연결된 클라이언트에게 현재 상태를 전송하고, webpack.config.js에서 설정한 hot 옵션을 확인해 type이 hot인 sendMessage 전송한다.

const DEFAULT_STATS = {
  all: false,
  hash: true,
  warnings: true,
  errors: true,
  errorDetails: false,
};

// ...
  getStats(statsObj: Stats | MultiStats) {
    const stats = DEFAULT_STATS;
    return statsObj.toJson(stats);
  }

  sendStats(clients: WebSocket[], stats: StatsCompilation, force?: boolean): void {

   const shouldEmit =
      !force &&
      stats &&
      (!stats.errors || stats.errors.length === 0) &&
      (!stats.warnings || stats.warnings.length === 0) &&
      this.currentHash === stats.hash;

    if (shouldEmit) {
      this.sendMessage(clients, "still-ok");
      return;
    }

    // 현재 해시 저장
    this.currentHash = stats.hash;
    this.sendMessage(clients, "hash", stats.hash);

    const errors = stats.errors as NonNullable<StatsCompilation["errors"]>;
    const warnings = stats.warnings as NonNullable<
      StatsCompilation["warnings"]
    >;
    // 변경사항 전송 로직
    if (errors.length > 0 || warnings.length > 0) {
      const hasErrors = errors.length > 0;

      if (warnings.length > 0) {
        let params;

        if (hasErrors) {
          params = { preventReloading: true };
        }

        this.sendMessage(clients, "warnings", warnings, params);
      }

      if (errors.length > 0) {
        this.sendMessage(clients, "errors", errors);
      }
    } else {
      this.sendMessage(clients, "ok");
    }
  }

  createWebSocketServer() {
      this.webSocketServer = new WebSocket.Server({ server: this.server });

      this.webSocketServer.on("connection", (ws) => {
        this.webSocketClients.push(ws as WebSocket);

         if (this.options.hot === true || this.options.hot === "only") {
          this.sendMessage([ws as WebSocket], "hot");
        }

        if (!this.stats) {
          return;
        }

        // 연결된 클라이언트에게 현재 상태 전송
        this.sendStats([ws as WebSocket], this.getStats(this.stats));
      });
  }

그러면 이제 websocket 클라이언트를 연결하고 메시지를 받는 로직을 살펴보자.

dev-server 예시에서 websocket 설정이나 따로 코드를 작성하지 않았지만 자동으로 연결되었다. 그이유는 아래 코드에서 클라이언트 엔트리 파일 경로를 반환하는 addAdditionalEntries 함수를 통해 클라이언트 엔트리 파일 경로를 반환하고 이를 통해 클라이언트 엔트리 파일을 동적으로 추가해 연결하기 때문이다.

예제에서는 최대한 간략하게 만들었지만 실제는 webpack.config.js에서 설정한 옵션들을 이용해 host, port, pathname, hot 등을 추가해 연결할 수 있다.

여기서 중요한 부분은 clientHotEntry는 웹팩 자체 패키지의 dev-server 파일을 가져오고 있다는 점과 additionalEntries에 클라이언트 엔트리 파일 경로를 추가하고 있다는 점이다.

  // ...
  constructor() {
    // ...
  this.addAdditionalEntries(compiler);
  }

 private getClientEntry(): string {
    // 클라이언트 엔트리 파일 경로 반환
    return require.resolve("./client/index.js");
  }

  private getClientHotEntry(): string {
    return require.resolve("webpack/hot/dev-server.js");
  }

  //https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L623

  addAdditionalEntries(compiler: webpack.Compiler) {
    const additionalEntries = [];

    let webSocketURLStr = "";

    const searchParams = new URLSearchParams();

    const protocol = "ws:";

    searchParams.set("protocol", protocol);
    const port = this.options.port ?? "0";

    searchParams.set("port", String(port));

    const pathname = "";

    searchParams.set("pathname", pathname);

    searchParams.set("hot", String(this.options.hot));

    webSocketURLStr = searchParams.toString();

    additionalEntries.push(`${this.getClientEntry()}?${webSocketURLStr}`);

    const clientHotEntry = this.getClientHotEntry();
    if (clientHotEntry) {
      additionalEntries.push(clientHotEntry);
    }

    for (const additionalEntry of additionalEntries) {
      new webpack.EntryPlugin(compiler.context, additionalEntry, {
        name: undefined,
      }).apply(compiler);
    }
  }

그러면 이렇게 searchParam으로 연결한 값들은 어떻게 사용되는지 client 파일에서 살펴보자.

앞서 설정한 searchParam을 파싱한 후에 옵션을 활성화한다.

var parsedResourceQuery = parseURL(__resourceQuery)
var enabledFeatures = {
  "Hot Module Replacement": false,
  "Live Reloading": false,
  Progress: false,
  Overlay: false,
}

var options = {
  hot: false,
  liveReload: false,
  progress: false,
  overlay: false,
}

if (parsedResourceQuery.hot === "true") {
  options.hot = true
  enabledFeatures["Hot Module Replacement"] = true
}
if (parsedResourceQuery["live-reload"] === "true") {
  options.liveReload = true
  enabledFeatures["Live Reloading"] = true
}
if (parsedResourceQuery.progress === "true") {
  options.progress = true
  enabledFeatures.Progress = true
}

이렇게 켜진 옵션에 대해서는 실제 콘솔에 출력되는 로그를 통해 확인할 수 있다.

websocket-client-log

이제 서버에서 sendMessage를 통해 메시지를 전송했을 때 처리하는 로직을 보자.

sendMsg로 웹소켓 서버에서 받은 메시지를 또다시 어디론가 보내는 것을 볼 수 있다.

// https://github.com/webpack/webpack-dev-server/blob/master/client-src/utils/sendMessage.js
function sendMsg(type, data) {
  if (
    typeof self !== "undefined" &&
    (typeof WorkerGlobalScope === "undefined" ||
      !(self instanceof WorkerGlobalScope))
  ) {
    self.postMessage(
      {
        type: "webpack".concat(type),
        data: data,
      },
      "*"
    )
  }
}

var onSocketMessage = {
  hot: function hot() {
    if (parsedResourceQuery.hot === "false") {
      return
    }
    options.hot = true
  },
  invalid: function invalid() {
    log.info("App updated. Recompiling...")
    sendMessage("Invalid")
  },
  hash: function hash(_hash) {
    status.previousHash = status.currentHash
    status.currentHash = _hash
  },

  "still-ok": function stillOk() {
    sendMessage("StillOk")
  },
  ok: function ok() {
    sendMessage("Ok")
    reloadApp(options, status)
  },
  // ...
}

현재까지 우리는 개발서버, 웹소켓 서버와 클라이언트를 연결하는 과정을 알아보았다. 서버에서 클라이언트로 메시지를 보냈는데 또다시 websocket의 클라이언트는 어디론가 메시지를 보내는 것 까지 확인했다.

Webpack과 연결하기

그러면 웹소켓 클라이언트가 보낸 메시지는 어디로 어떻게 처리되는걸까? 이것을 이해하기 위해서는 앞서 개념에서 설명했던 HMR의 런타임과 컴파일러가 어떻게 동작하는지 이해해야한다.

다시 서버 코드로 돌아가 initialize 메소드 내부를 보면 setupHooks 메소드와 함께 webpack의 HotModuleReplacementPlugin을 추가하는 로직을 볼 수 있다.

setupHooks는 컴파일 결과에 따라 콜백함수를 추가하는 역할로 파일변경으로 컴파일이 새롭게 진행될 때 socket을 통해 컴파일 결과를 전달하는 역할을 담당한다.

HotModuleReplacementPlugin은 webpack 내장 플러그인으로, 컴파일 과정에서 변경된 자바스크립트 모듈 코드를 평가하고 모듈 그래프를 만들어 변경된 모듈에 따라 어디까지 적용할지 결정하는 역할을 담당한다.

  constructor(compiler: webpack.Compiler, options: any) {
    // ...
    this.setupHooks();

    new webpack.HotModuleReplacementPlugin().apply(this.compiler);

    app.use(webpackDevMiddleware(this.compiler));
  }


  setupHooks(): void {
    this.compiler.hooks.invalid.tap("webpack-dev-server", () => {
      if (this.webSocketServer) {
        this.sendMessage(this.webSocketClients, "invalid");
      }
    });
    this.compiler.hooks.done.tap(
      "webpack-dev-server",

      (stats) => {
        if (this.webSocketServer) {
          this.sendStats(this.webSocketClients, this.getStats(stats));
        }
        this.stats = stats;
      }
    );
  }

실제 코드는 아래와 같다.

// https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L1744
async initialize() {
    // ...
    if (this.options.webSocketServer) {
      const compilers =
        /** @type {MultiCompiler} */
        (this.compiler).compilers || [this.compiler];

      for (const compiler of compilers) {
        if (compiler.options.devServer === false) {
          // eslint-disable-next-line no-continue
          continue;
        }

        this.addAdditionalEntries(compiler);

        if (this.options.hot) {
          const HMRPluginExists = compiler.options.plugins.find(
            (p) => p && p.constructor === webpack.HotModuleReplacementPlugin,
          );

          if (HMRPluginExists) {
            this.logger.warn(
              `"hot: true" automatically applies HMR plugin, you don't have to add it manually to your webpack configuration.`,
            );
          } else {
            // Apply the HMR plugin
            const plugin = new webpack.HotModuleReplacementPlugin();

            plugin.apply(compiler);
          }
        }
      }
    }


// https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L1883
setupHooks() {
    this.compiler.hooks.invalid.tap("webpack-dev-server", () => {
      if (this.webSocketServer) {
        this.sendMessage(this.webSocketServer.clients, "invalid");
      }
    });
    this.compiler.hooks.done.tap(
      "webpack-dev-server",
      /**
       * @param {Stats | MultiStats} stats
       */
      (stats) => {
        if (this.webSocketServer) {
          this.sendStats(this.webSocketServer.clients, this.getStats(stats));
        }

        /**
         * @private
         * @type {Stats | MultiStats}
         */
        this.stats = stats;
      },
    );
  }

그러면 HotModuleReplacementPlugin 플러그인이 어떻게 동작하는지 살펴보자. 생각보다 코드가 복잡하고, 실제로 CommonJS, ESM 등 다양한 자바스크립트 환경을 지원하도록 구현되어 있기 때문에 기본적인 module.hot만 지원하는 부분만 간단히 살펴보려 한다.

파일 변경으로 변경된 모듈을 변경한다는 것은 생각보다 복잡한 일이다. 먼저 변경된 파일이 영향을 미치는 모듈들을 찾아야하고, 변경된 모듈에 따라 어디까지 적용할지 결정해야한다.

상당히 복잡하지만 코드를 살펴보면 chunk, module에 대해 해시 계산을 하고 이전 빌드의 해시 값과 비교하여 다른 경우 변경된 모듈로 마킹하고 변경 사항이 있으면 hotIndex 증가시킨다.

compiler.hooks.compilation.tap(
  PLUGIN_NAME,
  (compilation, { normalModuleFactory }) => {
    // This applies the HMR plugin only to the targeted compiler
    // It should not affect child compilations
    if (compilation.compiler !== compiler) return

    // #region module.hot.* API
    compilation.dependencyFactories.set(
      ModuleHotAcceptDependency,
      normalModuleFactory
    )
    compilation.dependencyTemplates.set(
      ModuleHotAcceptDependency,
      new ModuleHotAcceptDependency.Template()
    )

    let hotIndex = 0
    /** @type {Record<string, string>} */
    const fullHashChunkModuleHashes = {}
    /** @type {Record<string, string>} */
    const chunkModuleHashes = {}

    compilation.hooks.record.tap(PLUGIN_NAME, (compilation, records) => {
      if (records.hash === compilation.hash) return
      const chunkGraph = compilation.chunkGraph
      records.hash = compilation.hash
      records.hotIndex = hotIndex
      records.fullHashChunkModuleHashes = fullHashChunkModuleHashes
      records.chunkModuleHashes = chunkModuleHashes
      records.chunkHashes = {}
      records.chunkRuntime = {}
      for (const chunk of compilation.chunks) {
        const chunkId = /** @type {ChunkId} */ (chunk.id)
        records.chunkHashes[chunkId] = chunk.hash
        records.chunkRuntime[chunkId] = getRuntimeKey(chunk.runtime)
      }
      records.chunkModuleIds = {}
      for (const chunk of compilation.chunks) {
        records.chunkModuleIds[/** @type {ChunkId} */ (chunk.id)] = Array.from(
          chunkGraph.getOrderedChunkModulesIterable(
            chunk,
            compareModulesById(chunkGraph)
          ),
          m => chunkGraph.getModuleId(m)
        )
      }
    })
    /** @type {TupleSet<[Module, Chunk]>} */
    const updatedModules = new TupleSet()
    /** @type {TupleSet<[Module, Chunk]>} */
    const fullHashModules = new TupleSet()
    /** @type {TupleSet<[Module, RuntimeSpec]>} */
    const nonCodeGeneratedModules = new TupleSet()
    compilation.hooks.fullHash.tap(PLUGIN_NAME, hash => {
      const chunkGraph = compilation.chunkGraph
      const records = /** @type {Records} */ (compilation.records)
      for (const chunk of compilation.chunks) {
        /**
         * @param {Module} module module
         * @returns {string} module hash
         */
        const getModuleHash = module => {
          if (compilation.codeGenerationResults.has(module, chunk.runtime)) {
            return compilation.codeGenerationResults.getHash(
              module,
              chunk.runtime
            )
          }
          nonCodeGeneratedModules.add(module, chunk.runtime)
          return chunkGraph.getModuleHash(module, chunk.runtime)
        }
        const fullHashModulesInThisChunk =
          chunkGraph.getChunkFullHashModulesSet(chunk)
        if (fullHashModulesInThisChunk !== undefined) {
          for (const module of fullHashModulesInThisChunk) {
            fullHashModules.add(module, chunk)
          }
        }
        const modules = chunkGraph.getChunkModulesIterable(chunk)
        if (modules !== undefined) {
          if (records.chunkModuleHashes) {
            if (fullHashModulesInThisChunk !== undefined) {
              for (const module of modules) {
                const key = `${chunk.id}|${module.identifier()}`
                const hash = getModuleHash(module)
                if (
                  fullHashModulesInThisChunk.has(
                    /** @type {RuntimeModule} */ (module)
                  )
                ) {
                  if (records.fullHashChunkModuleHashes[key] !== hash) {
                    updatedModules.add(module, chunk)
                  }
                  fullHashChunkModuleHashes[key] = hash
                } else {
                  if (records.chunkModuleHashes[key] !== hash) {
                    updatedModules.add(module, chunk)
                  }
                  chunkModuleHashes[key] = hash
                }
              }
            } else {
              for (const module of modules) {
                const key = `${chunk.id}|${module.identifier()}`
                const hash = getModuleHash(module)
                if (records.chunkModuleHashes[key] !== hash) {
                  updatedModules.add(module, chunk)
                }
                chunkModuleHashes[key] = hash
              }
            }
          } else if (fullHashModulesInThisChunk !== undefined) {
            for (const module of modules) {
              const key = `${chunk.id}|${module.identifier()}`
              const hash = getModuleHash(module)
              if (
                fullHashModulesInThisChunk.has(
                  /** @type {RuntimeModule} */ (module)
                )
              ) {
                fullHashChunkModuleHashes[key] = hash
              } else {
                chunkModuleHashes[key] = hash
              }
            }
          } else {
            for (const module of modules) {
              const key = `${chunk.id}|${module.identifier()}`
              const hash = getModuleHash(module)
              chunkModuleHashes[key] = hash
            }
          }
        }
      }

      hotIndex = records.hotIndex || 0
      if (updatedModules.size > 0) hotIndex++

      hash.update(`${hotIndex}`)
    })
  }
)

변경된 모듈을 파악했으면 해당 모듈을 교체해야 한다. 그러기 위해서 해당 모듈에 대한 정보를 Manifest.json와 HotupdateChunk를 만든다.

if ((newModules && newModules.length > 0) || (newRuntimeModules && newRuntimeModules.length > 0)) {
  const hotUpdateChunk = new HotUpdateChunk();
  hotUpdateChunk.id = chunkId;
  // 모듈 및 런타임 모듈 연결
  chunkGraph.attachModules(hotUpdateChunk, newModules || []);
  chunkGraph.attachRuntimeModules(hotUpdateChunk, newRuntimeModules || []);

  const renderManifest = compilation.getRenderManifest({ ... })
  for (const entry of renderManifest) {
    compilation.emitAsset(filename, source, {
      hotModuleReplacement: true,
      ...assetInfo
    })
  }
}

for (const [
  filename,
  { removedChunkIds, removedModules, updatedChunkIds, assetInfo },
] of hotUpdateMainContentByFilename) {
  const hotUpdateMainJson = {
		c: Array.from(updatedChunkIds),
		r: Array.from(removedChunkIds),
		m:
			removedModules.size === 0
				? completelyRemovedModulesArray
				: completelyRemovedModulesArray.concat(
						Array.from(removedModules, m => chunkGraph.getModuleId(m))
				)
    }

  const source = new RawSource(JSON.stringify(hotUpdateMainJson))
    compilation.emitAsset(filename, source, {
      hotModuleReplacement: true,
      ...assetInfo,
    })
  }
}

이렇게 만든 Manifest.json과 HotupdateChunk를 클라이언트에게 전달하고 클라이언트는 이를 받아 변경된 모듈을 교체한다.

compilation.hooks.additionalTreeRuntimeRequirements.tap(
  PLUGIN_NAME,
  (chunk, runtimeRequirements) => {
    runtimeRequirements.add(RuntimeGlobals.hmrDownloadManifest)
    runtimeRequirements.add(RuntimeGlobals.hmrDownloadUpdateHandlers)
    // ...
    compilation.addRuntimeModule(chunk, new HotModuleReplacementRuntimeModule())
  }
)

실제로 예제에서 파일변경시 네트워크 탭을 보면 아래와 같이 chunk와 manifest가 네트워크 요청으로 전달되는 것을 확인할 수 있다.

hot-update-chunk

그리고 hot-update.js을 자세히 보면 다음과 같은 코드가 담겨있다.

"use strict"
self["webpackHotUpdatesimple_webpack_dev_server"]("main", {
  /***/ "./src/example/counter.js":
    /*!********************************!*\
  !*** ./src/example/counter.js ***!
  \********************************/
    /***/ function (
      __unused_webpack_module,
      __webpack_exports__,
      __webpack_require__
    ) {
      // ...바뀐 모듈 내용
    },
})

앞서 websocket 클라이언트의 sendMsg함수에서 보내는 형식과 동일하다는 것을 볼 수 있다.

// sendMsg.js
self["webpackHotUpdatesimple_webpack_dev_server"]("main", {
  // ...
})

정리해보면 webpack으로 컴파일하는 과정에서 런타임에서 모듈 변경시 실행할 이벤트 리스너를 콜백으로 전달하게 되고, 파일별로 설정할 수 있게 제공하는 API를 module.hot으로 볼 수 있다. 그리고 websocket 서버에서 파일변경으로 변경된 모듈 정보를 넘기면 websocket 클라이언트에서는 해당 정보를 받아 교체하고, 런타임에 등록된 이벤트 리스너를 실행해 미리 정의한 로직을 실행할 수 있게 된다.

아래는 변경된 파일이 아니라 초기 번들에 담긴 런타임 코드이다.

webpack-runtime

파일 변경 이벤트 전달

이제 마지막으로 간단한 파일 변경 이벤트 처리 부분이다. 처음에는 chokidar를 사용하여 파일 변경을 감지하고, websocket 이벤트로 전달할 줄 알았지만 webpack-dev-middleware에서 처리되고 있었다.

chokidar은 static file을 감지할 때 사용되고 있다.

 watchFiles(watchPath, watchOptions) {
    const chokidar = require("chokidar");
    const watcher = chokidar.watch(watchPath, watchOptions);

    // disabling refreshing on changing the content
    if (this.options.liveReload) {
      watcher.on("change", (item) => {
        if (this.webSocketServer) {
          this.sendMessage(
            this.webSocketServer.clients,
            "static-changed",
            item,
          );
        }
      });
    }

    this.staticWatchers.push(watcher);
  }

정리

정리해보면 아래와 같이 그림으로 나타낼 수 있다.

webpack-overview-diagram

예시로 작성했던 코드는 여기에 올려두었다.

평소 당연하게 생각하는 기능 안에 얼마나 많은 고민이 담겨있는지 느낄 수 있었다. 원래는 Fast Refresh까지 보려했지만 이미 너무 방대한 내용이 담겨있는 것 같아 webpack에서의 HMR 동작방식만 먼저 알아보았다.

다음에는 Next.js에서의 HMR 동작방식을 알아보고, 마지막으로 Fast Refresh 동작방식을 알아보려 한다.

참고

https://www.javascriptstuff.com/understanding-hmr/

2025년 2월 회고

Thu, 27 Feb 2025 00:00:00 GMT

2025년 2월은 토스 인컴 오피스로 이사하고 일하는 첫 달이었다. 넓어진 새로운 공간에 쾌적하게 일하며 다양한 고민을 했던 2월이었다. 2월했던 작업들을 돌아보고 1월에 하기로 했지만 못했던 것, 새롭게 시작하게 된 것 등을 정리해보고자 한다.

세금 도메인 이해도 높이기

1월에 도메인에 대한 지식이 떨어져 업무 주도성이 떨어짐을 느꼈었다. 그 이후에 다행히(?)도 도메인 지식으로 인해 작업 자체가 어렵거나 한 경우는 적었지만 목표했던 공부는 하지 못했다...😞

그래도 다행히 점은 1월에 도메인 지식이 필요하다고 느끼게 만들어준(?) 부녀자 공제 관련 문제를 조금 더 수월하게 이해하고 해결작업을 진행했다. 처음에는 부녀자 공제라는 단어 자체가 낯설고, 유저가 세대주/ 세대원인지 그리고 여기에 기본공제 대상자인지 아닌지 등 굉장히 많은 조건들이 얽혀있다보니 이해하는데 많은 시간이 걸렸다.

국세상담센터에 작성되어 있는 부녀자 공제 관련 조건

분명 앞으로도 이렇게 도메인에 대해 이해하고 작업이 필요한 경우가 있을 것이고, 퇴근하고 공부하는게 어렵지만 진짜 3월부터는 매일 조금씩 해보기로 목표로 해보려 한다.

토스 입사 후 첫 발표: Fast Refresh 고치기

토스 입사 후 처음으로 프론트엔드 미팅시간에 발표를 진행하게 되었다. 주제는 Fast Refresh 고치기로 Next의 Fast Refresh가 동작하지 않는 상황을 해결해 나간 해결 과정에 대해 발표를 진행했다. 소그룹에서 먼저 발표를 진행했던 내용을 소그룹 리더분께서 모바일 트랙 미팅에도 같은 내용으로 발표해주면 좋겠다고 제안해주셨고 감사한 기회로 발표하게 되었다.

Fast Refresh는 Next에서 사용하는 HMR 기능으로 개발 중인 페이지에 변경사항이 생기면 변경사항을 바로 반영해주는 기능이다. 하지만 이 기능이 동작하지 않는 상황이었기 때문에 단순 문구 수정이나 스타일 수정에도 매번 full reload가 필요했다.

해결방법은 패키지 업그레이드라는 아주 간단한 방법이었지만, 어떻게 패키지 업그레이드를 하면 되는지 해결방법을 도출하고, 실제 어떤 변경사항이 해당 버전에 적용되어 수정되었는지를 담은 내용으로 발표를 준비했다.

하지만 발표하는 과정에서 방송사고(?)가 발생했다. 발표가 목요일이라 수요일 밤에 퇴근 후 2시간동안 열심히 영상도 만들어서 준비했건만, 사내 자료라 생각되어 영상을 유튜브에 올리고 비공개로 해두어 발표 자료 계정에서 아무것도 재생이 안되었다...

너무 당황스러웠지만 사진과 글로만 우선 전달드리고 나중에 전체 공개로 변경한 자료를 다시 올려드렸지만 첫 발표가 이렇게 되어 아쉬움이 많이 남았다.

그래도 발표가 끝나고 똑같이 겪고 있었던 이슈였다고 감사하다는 챕터원분이 직접 현장에서 말씀해주셨고, 나를 추천해주셨던 멘토분께서도 벌써 발표를 하는게 대단하다는 말씀도 해주셔서 아예 무의미하지는 않았구나라는 생각과 함께 조금은 위안이 되었다.

다음에 또 언제 발표하게 될지는 모르겠지만 그때는 조금 더 발표자료를 열심히 체크하고 더 의미있는 작업을 공유해보고자 한다.

2월의 액션아이템과 다음 달을 위한 액션 아이템 정리

1월 회고에서 작성했던 2월의 액션아이템은 아래와 같다.

숨은 환급액 찾기 제품 내 퍼널 개선 필요 지점 제안하고 개선하기
세금 관련 공제 내용 정리하기
사내 라이브러리 기여하기
데이터 패칭 관련 라이브러리 분석하기

종합적으로는 계획했던 부분을 많이 진행하지 못한 2월이었다.

퍼널 개선이 필요한 점을 제시하기는 했지만, 아직 작업을 진행하지는 못했다. 팀의 우선순위에 따라 3월에는 퍼널 개선 작업을 진행해보고자 한다.

세금 관련 공제 내용은 체크하기는 애매하지만 그래도 부녀자 공제 이슈를 수정하면서 한발짝 나아갔다고 생각했다. 3월에는 세금 관련 서적을 읽고 더 자세히 정리해보고자 한다.

사내라이브러리 작업은 약간 정체하게 되었다. 이미 외부에서 많이 사용하고 있는 라이브러리가 있어 우리 길드의 라이브러리를 조금 더 가다듬기 위한 목표와 방향성을 잡는데 더 많은 시간을 사용했다. 3월부터는 새롭게 잡은 목표로 적극적으로 기여를 해 프로젝트가 성공적으로 오픈될 수 있도록 해보려고한다.

Tanstack query를 분석해보려했지만, Fast Refresh 이슈를 수정하고 발표자료를 준비하면서 HMR에 대해 더 자세히 공부하고 정리해보고 있다. 평소 잘 몰랐던 분야이다보니 조금 더 시간이 걸릴 것 같지만 정리하는 글도 작성해보려 한다.

3월의 액션아이템

3월의 액션 아이템은 아래와 같다.

퍼널 개선 작업 진행하기
더 일을 잘하기 위해 일감을 쌓고 함께 진행하기
세금 도메인 관련 서적 읽고 정리하기
사내 라이브러리 기여하기
HMR 관련 글 작성하기

3월에는 내가 성장하는 것 뿐 아니라 팀이 편해지고 함께 성장할 수 있는 주제들도 진행해보려 한다. 한달에 한번씩 인컴 내 프론트엔드 회의시간을 갖고 있고 팀원분께서 좋은 아이디어를 많이 제시해주고 계시기 때문에, 나도 조금 더 효율적으로 잘 일할 수 있도록 다양한 주제들을 제안하고 작업을 진행해 보고 싶다.

또한 2월에 하지 못했던 액션 아이템들을 조금 더 진행해보고, 공부하고 있던 HMR 관련 글을 작성해보려 한다.

성장에 대해 고민하는 2월

이번 달은 여러 일을 했지만 성장에 대해 많이 고민했던 한달이었다. 개인적으로 내가 욕심이 너무 많다는 생각이 들었다. 다 잘하는 개발자가 되고 싶지만, 시간이 한정적이다 보니 빠르게 해결하지 못하고 일은 쌓여가는 걸 보다보니 늘 부채감이 쌓이는 것 같았다. 이런 이야기를 팀원분들께 드렸을 때 모든 걸 잘하는 개발자가 되는 것을 포기해라고 말씀해주셨다. 시간은 한정적이니까 혼자서 다 처리하는 게 아니라 적극적으로 동료에게 지금 해야하는 일들에 대해 우선순위를 세워달라고 공유하는 게 중요하다는 말씀을 해주셨다.

내가 생각하는 좋은 개발자는 모든 문제를 척척하는 개발자, 실무가 아주 뛰어난 사람이라고 생각했구나 생각이 들었고, 팀으로 일하는 것이 어떤 것인지 조금 더 고민하는 시간이었다. 내가 못하는 걸 잡고 시간을 많이 쏟는 게 잘하는 게 아니라 가장 잘하는 분께 적절하게 위임하는 게 중요하다는 것을 느꼈다.

슈퍼 개발자보다 팀플레이어 개발자를 목표로 조금 더 성장하는 3월이 되기를 바란다.

2025년 1월 회고

Mon, 27 Jan 2025 00:00:00 GMT

2025년이 시작되고, 새로운 업무와 새로운 환경이 시작되었다. 토스에 11월에 입사하면서 이제 3개월이 되는 달로, 바쁘게 일했던 11월, 12월을 지나 1월은 상대적으로 이번 한해를 준비하는 작업들을 진행하는 달이었다.

12월 말의 off-week 기간과 글을 쓰는 현재 설날의 긴 연휴로 인해 3개월이란 시간이 상대적으로 더 빠르게 느껴졌지만, 한달간의 업무를 정리해보고 12월에 세웠던 목표를 이루었는지 다음달에는 어떤 목표로 나아갈 지 생각해보려 한다.

새롭게 담당하게 된 퍼널 개선 업무

1월이 되면서 조직 개편이 있었고, 기존 토스 코어내 세금 사일로에서 토스 인컴의 퍼널 개선 사일로로 이동하게 되었다. 이에 따라 일하는 사무실도 변경되었고, 담당하는 업무도 변경되게 되었다.

기존 메이트분이 담당하시던 퍼널 관련 업무들을 이제 내가 담당하게 되어 현재 진행중인, 앞으로 내가 할 업무들에 대해 다운로드받게 되었다.

메이트 분께서 다운로드를 해주시는 내용을 들으면서, 부분부분 코드나 기술적인 건 이해가 되지만, 큰 흐름과 도메인과 관련된 부분을 이해하는데 많은 어려움이 있었다. 세금이란 도메인에 어려운 용어들이 혼재되어 있고, 관련 법률사항들이 예외케이스들이 하나하나 코드에 녹아들어있다보니 완전히 이해하는데 오랜시간이 걸렸다. 나는 내 담당 제품에 대해 너무 모르고 일해왔구나 체감하게 되었다.

이러한 부족한 도메인 지식은 문제가 있을때 어떻게 풀어나갈 지에 대해 어려움으로 이어졌다. 예를 들어 특정 공제 내용이 잘못 적용되어 신고되는 케이스가 있다는 내용을 전달받아도 해당 공제 관련 구현에서 각 변수들의 의미는 뭔지부터 시작해 어떤게 기존에 문제가 되는지 파악도 어려웠다.

팀원분들이 내가 어려워하는 것을 이해해주셔서 디자이너분과 백엔드 개발자분이 필요한 업무에 대해 정리해주시고 문제를 뾰족하게 만들어주셨지만 이대로는 안되겠다는 생각이 많이 들었다.

메이트 분께서 다운로드를 해주시면서 담당했던 제품중에서 가장 길고 복잡한 퍼널 제품중 하나라고 말씀해주신 만큼, 퍼널을 다루는 것에 있어서 깊이가 필요하다고 생각해 자주 사용하는 새로운 useFunnel 라이브러리 버전으로 정리를 하면서 내부구현을 이해하고 활용해보려 했다.

두번째로 내가 모르는 도메인 관련 지식을 모르는 상태로 계속해서 두게 되면, 그때 계속해서 물어서만 일하게 되면 팀원분들의 추가적인 리소스가 드는 것 뿐 아니라 내 자신의 업무주도성이 떨어지겠다는 걱정이 많이 들었다.

2월부터는 이러한 도메인 내용들 또한 마주할 때마다 관련 법률과 용어들을 정리하고 이해하는 시간을 가지면서 업무를 진행해나가려 한다. 그리고 이러한 도메인 내용을 바탕으로 내가 기여할 수 있는 부분을 제안하는 것을 액션아이템으로 삼아보려 한다.

토스 생활: alignment week

토스에는 한해를 시작하면서 alignment week라는 이름의 행사가 있다. 이 행사는 토스 내 모든 팀들이 과거 한해를 돌아보고, 새로운 한해를 시작하면서 목표를 세우고 이를 이루기 위해 모두 모여 이야기하는 시간을 가지는 행사다.

2023년 토스 얼라이먼트 위크

다른 팀의 발표를 듣고, 우리 팀의 PM분이 발표하는 시간에 응원도 하면서 정말 많은 팀에서 다양한 문제를 풀기위해 애쓰고 있고, 토스에는 일에 열정이 가득한 사람들이 많다는 것과, 앞으로가 더 기대됨을 느낄 수 있었다.

올해 더 큰 성과를 통해 우리팀이 한번 더 발표할 수 있도록 기여해보고 싶다.

새로운 환경과 사람들

팀의 소속이 변경되면서 인컴분들과 함께 사무실을 사용하게 되었고, 새로운 사람들과 함께하게 되었다.

기존 사일로분들이 메이트분을 제외하고 함께 옮겨지게 되었고, 간간히 함께 일했던 분들이 계셨지만 새롭게 합류한 분들이 많았다.

새롭게 합류하신 분 중에는 프론트엔드 개발자분도 계셔서 오시기전, 노션으로 기존 개발 환경, 진행중인 업무 등에 대해 정리한 문서를 작성했다. 이후에 합류 이후에 해당 문서를 전달드리고 그것을 바탕으로 함께 팀내 프론트엔드 온보딩 문서로 발전시키기도 했다. 코어에서 2년 넘게 일하셨던 분이다 보니 정리를 굉장히 잘하시고, 프로젝트의 필요한 부분을 히스토리로 남겨두는 것을 잘하셨다.

기존 메이트분의 장점은 반복업무에 대해서 굉장히 효율화 잘하시는 분이셨다. Raycast나 Shell Script, snippet을 자체적으로 만드셔서 반복된 업무에 대해 템플릿을 만들어 사용하는 것을 많이 배울 수 있었는데, 이분의 장점을 또 찾고 배워나가는 것을 기대하고 있다.

뿐만 아니라 새로운 동료분들과 이야기하면서 각자 새로운 환경에 대한 목표가 있는게 좋았고, 이분들의 장점을 찾아보고 배워나가는 것을 기대하고 있다. 함께 더 좋은 제품, 더 좋은 팀을 만들어나가기를 바래본다.

사내 라이브러리 개발

사내 라이브러리를 1월 중순까지 거의 10개 정도의 PR을 올렸고 길드 내 첫 마일스톤으로 잡았던 작업량을 달성할 수 있었다.

현재 남겨두고 있는 부분은 해당 라이브러리를 오픈소스로 공개하기 전 문서 작업들과 사내에서 마이그레이션 진행시 편리하게 옮길 수 있도록 codemod를 만드는 작업이 남았다. 나는 이중 codemod를 만드는 작업을 담당하게 되었고 설 연휴 동안 작업을 진행해볼 예정이다.

12월 말부터 거의 하루에 한개정도 작업을 했던 게 실제로 오픈하기 까지 얼마 남지 않은 것 같아 기대도 되고, 뿌듯하기도 했다. 계속해서 관심을 가지고 사용하시는 분들과 소통도 하면서 적극적으로 계속해서 기여해나가는 것을 목표로 하려한다.

이전 한달과 다음 한달의 목표

이전 한달의 목표들은 아래와 같았다.

[] 숨은 환급액 찾기 제품 내 개선할 부분 제시하고 작업해보기 (제시까지는 못함)
토스 프론트엔드 라이브러리 분석하기
사내 라이브러리에 기여하기

숨은 환급액 찾기 제품 내 개선할 부분 제시하고 작업해보기

숨은 환급액 찾기 서비스를 이용하면서 진입시 로딩시간이 길다는 생각이 들어 실제 유저가 겪고 있는 시간이 얼마나 되는지 측정작업을 먼저 진행했다. 기존에 코어 서비스들은 측정이 되고 있었지만 인컴 제품은 계열사가 달라 따로 데이터를 쌓기위한 작업이 필요했다.

별도 작업을 하더라도 아직 데이터 인프라가 완성되지 않아 세부 데이터까지 수집해서 보기 어려운 상황이었다.

그러면 포기해야하나 할때 백엔드 엔지니어분께서 아이디어를 주셔서 간단하게 추세를 보는 방법에 대해 제안해주셨다. 제시해주신 형식에 맞게 데이터를 쌓고 그라파나라는 툴을 이용해서 대시보드를 간략하게 만드는 것까지 현재 진행할 수 있었다.

2월에는 어떤 퍼널에서 오랜시간이 걸리고 있고, 이탈을 하고 있는지 확인하며 퍼널간 전환율 개선 작업으로 진행할 수 있도록 제안해보려 한다.

토스 프론트엔드 라이브러리 분석하기와 사내 라이브러리 기여하기

토스 프론트엔드 라이브러리 분석하기를 위해 개발하는 과정에서 마주하는 다양한 유틸들의 내부 구조들을 분석하고 정리해보고 있다.

이번달은 사내 라이브러리에 기여하면서 리액트 관련 기존 구현들을 분석하고 테스트 케이스, 문서를 보완하는 작업을 진행했다.

추가로 퍼널 개선 업무를 맡으면서 기존의 작성했던 이전 버전 useFunnel에 이어 새로운 버전의 useFunnel 라이브러리를 분석하고 정리하게 되었다.

코드들을 분석하면서 얼마나 많은 고민이 담긴 패키지인지 느낄 수 있었고, 퍼널 담당 업무를 할때 조금 더 기술적으로 이해도를 높인 상태에서 진행할 수 있겠다는 자신감도 얻을 수 있었다.

new useFunnel 분석해보기

다음 한달은 개발과정에서 많이 사용하는 react-query 라이브러리를 분석하고 정리해보려 한다.

다음 한달의 목표

다음 한달의 목표는 이전 한달의 목표 달성 현황과 작업을 하면서 느꼈던 느낀점을 바탕으로 4가지로 정해보았다.

숨은 환급액 찾기 제품 내 퍼널 개선 필요 지점 제안하고 개선하기
세금 관련 공제 내용 정리하기
사내 라이브러리 기여하기
데이터 패칭 관련 라이브러리 분석하기

욕심이 많아 다 잘하고 싶어 계속 늘어가는 것 같지만, 더 좋은 개발자, 더 좋은 동료가 되기 위해 계속해서 발전해나가는 것을 목표로 하려 한다.

블로그를 작성하는 것을 팀원분들께 들킨(?) 이후로 한달 회고가 언제 올라오는지 놀림반, 관심반을 받고 있다.

내가 작성한 글을 누군가 읽고 있으니 더 책임감을 가지고 액션 아이템들을 이루어나가기를 바라본다.

new useFunnel 분석해보기

Sun, 19 Jan 2025 00:00:00 GMT

useFunnel 라이브러리는 2023 토스 Slash의 퍼널: 쏟아지는 페이지 한 방에 관리하기 발표에서 복잡한 퍼널간 상태관리를 위한 라이브러리 useFunnel을 소개되었고, 토스 프론트엔드 액셀러레이터 과정의 2주차 주제였던 퍼널간 상태 관리하기라는 주제를 진행하고 분석하는 글을 작성했다.

작성했던 이전글

개인적으로 새롭게 정리하게 된 이유는 기존 패키지과 달리 다양한 장점을 가지고 있고, 훨씬 다양한 유즈케이스를 관리하기 위해 새롭게 만들어져 오픈소스로 공개되어 분석해보고 싶었고, 1월부터 굉장히 복잡한 퍼널을 관리가 필요한 제품을 담당하게 되면서 퍼널에 대한 이해도를 높일 필요가 있다고 느꼈다.

그러면 새로운 useFunnel 패키지에 대해 알아보고 분석해보자.

새로운 useFunnel은 어떤 문제를 해결하기 위한걸까?

기존 패키지가 있지만 새롭게 만들게 된 이유는 무엇일까? 새로운 패키지를 만들어주신 선영님과 민우님께서 사내 블로그에 올려주신 글을 통해 알아보자.

먼저 기존 라이브러리의 문제점

당시 선영님께서 담당하게 되신 서비스인 주택 담보 대출 비교 서비스는 굉장히 복잡한 퍼널 관리가 필요했고, 기존 사용중인 두가지 퍼널 관리 방식을 통해 구현되어 있었다.

첫번째는 기존 use-funnel 패키지로 직관적이고 익숙하지만 퍼널과정에서 수집하게 되는 데이터 관리를 별도로 해야하는 문제점이 있었다.

interface FormState {
  purpose: Purpose;
  address: string;
  income: number;
}

function Funnel() {
  const [formState, setFormState] = useState<Partial<FormState>>({});
  const [Funnel, setStep] = useFunnel([FunnelName.대출목적선택, FunnelName.담보물선택, FunnelName.연소득입력], {
    initialStep: FunnelName.대출목적선택,
    stepQueryKey: 'mortgage-loan-funnel',
  });

  return (
    <Funnel>
      <Funnel.Step name={FunnelName.대출목적선택}>
        <대출목적선택
          onNext={purpose =>
            setFormState(prev => ({ ...prev, purpose }));
          }}
        />
      </Funnel.Step>
      <Funnel.Step name={FunnelName.담보물선택}>
        <담보물선택
          onNext={(address) => {
            setFormState(prev => ({ ...prev, address }));
          }}
        />
      </Funnel.Step>
      <Funnel.Step name={FunnelName.연소득입력}>
        <연소득입력
          onNext={(income) => {
            setFormState(prev => ({ ...prev, income }));
          }}
        />
      </Funnel.Step>
    </Funnel>
  );
};

두번째로는 XState 상태관리 도구를 이용하는 방식으로 퍼널과 상태를 함께 관리하지만 복잡하면서도 상태관리와 렌더링하는 컴포넌트 코드가 분리되어 있는 문제점이 있었다.

function createFunnelMachine() {
  return (
    createMachine<Partial<Context>, Event, StateType>({
		  id: "mortgage-loan-funnel",
		  initial: "대출목적선택",
		  states: {
				대출목적선택: {
					entry: [assign(context => 대출목적선택State검증(context))],
					on: {
						대출목적선택완료: [
						  {
						    target: "담보물선택",
						    actions: [assign()],
						  }
						]
					}
				},
				담보물선택: {
					entry: [assign(context => 담보물선택State검증(context))],
					on: {
						담보물선택완료: [
						  {
						    target: "연소득입력",
						    actions: [assign()],
						  }
						]
					}
				},
				연소득입력: {
					entry: [assign(context => 연소득입력State검증(context))],
					on: {
						연소득입력완료: [
						  {
						    target: "입력완료",
						    actions: [assign()],
						  }
						]
					}
				},
				입력완료: {
				  entry: [assign(context => 입력완료State검증(context))],
				}
		  }
    })
  );
}

function Funnel() {
  const [funnelMachine] = useState(() => createFunnelMachine());
  // useMachineRouter는 dispatch 시점에 적절한 다음 퍼널로 라우트시켜주는 기능을 구현한 hook이에요
  // 내부적으로 XState의 useMachine을 사용해요
  const [render, state] = useMachineRouter(funnelMachine);

  return (
    <>
      {render({
        대출목적선택: ({ dispatch }) => (
          <대출목적선택
	          onNext={purpose =>
	            dispatch({ type: "대출목적선택완료", payload: { purpose }})
	          }}
	        />
        ),
        담보물선택: ({ dispatch }) => (
          <담보물선택
	          onNext={address =>
	            dispatch({ type: "담보물선택완료", payload: { address }})
	          }}
	        />
        ),
        연소득입력: ({ dispatch }) => (
          <연소득입력
	          onNext={income =>
	            dispatch({ type: "연소득입력완료", payload: { income }})
	          }}
	        />
        ),
        입력완료: ({ context }) => (
          <입력완료 context={context} />
        )
      })}
    </>
  );
}

둘다 공통적으로 뒤로가기와 앞으로 가기를 할 때, 수집한 데이터를 관리하는데 어려움이 존재하게 된다. 예를 들어 A->B->C 에서 B로 돌아가게 되면 A에서 수집한 데이터 외의 B에서 이미 수집한 데이터가 존재하게 된다.

뒤로가기 데이터 관리 문제

이부분을 읽으면서 이미 선택한 데이터를 다시 선택하지 않아도 되게 해줄 수 있기 위해 이미 선택한 정보는 뒤로가기시에도 보관하는 게 좋지 않을까 생각이 들었지만 아래와 같은 상황이라면 달라진다.

복잡한 퍼널에서의 뒤로가기 데이터 관리 문제

위 사진처럼 A → B → C → B(뒤로가기) → A(뒤로가기) → D → E로 이동한다면 했을때 선택한적 없어야하는 B의 값을 D, E 퍼널에서 갖게 되면서 별도로 원하는 데이터를 정제하는 과정이 필요하게 된다.

이렇게 퍼널이 복잡해질수록 각 스텝에서 보유해야하는 데이터를 한정시켜주는게 데이터의 흐름을 이해하는데 조금 더 직관적이고 좋을 것 같다는 생각이 들었고 문제상황을 공감할 수 있었다.

기존 useFunnel의 또다른 문제점

기존의 useFunnel 패키지의 또다른 문제점은 Next와의 강한 결합이었다. 다른 라우팅 라이브러리와 환경(React Router DOM, react native 환경) 에서는 각자 자체적으로 구현해야 한다는 점이 있었고, 퍼널에서 수집한 데이터의 타입이 자동적으로 추론이 되지 않기 때문에 A퍼널에서 필수적으로 받아야하는 데이터가 B 퍼널에서 여전히 optional로 추론되기도 해 타입을 좁히는 코드가 별도로 필요했다.

이 두가지 문제점을 추가로 개선한 버전이 바로 새로운 useFunnel 패키지였다. 그러면 이제 실제 코드를 보면서 분석해보자.

코드 분석

use-funnel 패키지를 다운받아서 내부 구조를 보게 되면 아래와 같은 구조를 확인할 수 있다.

use-funnel 패키지 구조

위와 같은 프로젝트 구조를 통해 core 폴더는 라이브러리, 프레임워크와 상관없이 동일하게 적용되는 핵심로직을 가지고 있고, 라우팅 라이브러리/프레임워크 폴더들은 각각의 사용방법에 맞게 구체적인 구현이 되어있을 것으로 예상할 수 있다.

이렇게 공통 코어 로직과 구체적인 구현을 분리하는 구조를 통해 특정 라우팅 라이브러리/프레임워크와의 강결합을 끊고 라이브러리의 유연성을 가지게 되었다.

그러면 이제 핵심적이고 중요한 코어 폴더의 코드를 살펴보자.

Core 패키지

코어 패키지는 모든 패키지에서 공통적으로 사용되는 핵심 로직이 구현되어 있는 패키지이다.

core 폴더 구조

코어 패키지의 index.ts 파일을 살펴보면 다음과 같은 코드를 확인할 수 있다.

// index.ts
export { AnyFunnelState } from "./core.js"
export * from "./stepBuilder.js"
export { CreateFunnelStepType } from "./typeUtil.js"
export * from "./useFunnel.js"

stepBuilder 등 추가적인 기능들을 제공하고 있지만, 이중 개인적으로 중요하다고 생각하는 핵심 useFunnel.tsx 파일을 살펴보면서 필요한 타입, 유틸 함수들을 하나씩 분석해보려 한다.

처음 코드를 봤을 때 굉장히 복잡한 타입 정의에 압도를 당하는 느낌이어서 부분 부분 따라가며 이해하는 것이 좋다고 생각이 들어 쪼개서 분석해보았다.

UseFunnelOptions

UseFunnelOptions 타입은 퍼널의 옵션을 정의하는 타입이다.

// core.ts
export interface FunnelState<TName extends string, TContext = never> {
  step: TName
  context: TContext
}

export type AnyContext = Record<string, any>
export type AnyStepContextMap = Record<string, AnyContext>

export type FunnelStateByContextMap<TStepContextMap extends AnyStepContextMap> =
  {
    [key in keyof TStepContextMap & string]: FunnelState<
      key,
      TStepContextMap[key]
    >
  }[keyof TStepContextMap & string]

// useFunnel.tsx
export interface UseFunnelOptions<TStepContextMap extends AnyStepContextMap> {
  id: string
  initial: FunnelStateByContextMap<TStepContextMap>
  steps?: {
    [TStepName in keyof TStepContextMap]: FunnelStepOption<
      TStepContextMap[TStepName]
    >
  }
}

UseFunnelOptions 타입은 라우팅 패키지별로 사용할 createUseFunnel 함수에 전달할 옵션을 정의하는 타입이다. initial 옵션을 정의할 때 FunnelStateByContextMap 타입을 사용하고 있는데, 사용처에서 정의한 context 구조를 통해 스텝별 퍼널의 상태를 타입으로 정의하고 있다.

// core.ts
export interface FunnelState<TName extends string, TContext = never> {
  step: TName
  context: TContext
}

funnelState는 퍼널의 상태를 정의하는 타입이다. 퍼널의 상태는 퍼널의 스텝과 퍼널에서 사용할 데이터를 정의하는 context로 구성되어 있다.

// core.ts
export type FunnelStateByContextMap<TStepContextMap extends AnyStepContextMap> =
  {
    [key in keyof TStepContextMap & string]: FunnelState<
      key,
      TStepContextMap[key]
    >
  }[keyof TStepContextMap & string]

FunnelStateByContextMap 타입은 스텝별 퍼널 상태를 정의하는 타입으로 키는 문자열로 좁혀져 있는데 퍼널의 퍼널의 스텝은 브라우저 히스토리와 관련이 깊다보니 key가 될 수 있는 string | number | symbol 타입에서 string으로 좁히도록 되어있지 않을까 생각해볼 수 있었다.

실제로 사용하는 코드를 보면 아래와 같다.

type EmailInput = {}

type PasswordInput = {
  email: string
}

type OtherInput = {
  email: string
  password: string
}

const funnel = useFunnel<{
  이메일입력: EmailInput
  비밀번호입력: PasswordInput
  그외정보입력: OtherInput
}>({
  id: "my-funnel-app",
  initial: {
    step: "이메일입력",
    context: {},
  },
})

그러면 위 예제에서 전달될 타입들을 살펴보면 다음과 같다.

type TStepContextMap = {
  이메일입력: EmailInput
  비밀번호입력: PasswordInput
  그외정보입력: OtherInput
}

type FunnelStateByContextMap = {
  이메일입력: FunnelState<"이메일입력", EmailInput>
  비밀번호입력: FunnelState<"비밀번호입력", PasswordInput>
  그외정보입력: FunnelState<"그외정보입력", OtherInput>
}

type UseFunnelOptions = {
  id: string
  initial: {
    step: keyof TStepContextMap
    context: TStepContextMap[keyof TStepContextMap]
  }
  steps?: {
    [TStepName in keyof TStepContextMap]: FunnelStepOption<
      TStepContextMap[TStepName]
    >
  }
}

기본적인 옵션 외에 steps는 퍼널의 타입을 커스텀하게 정의할 수 있는 옵션으로 옵셔널한 옵션이다. 이때 step별로 조금 더 세부적인 타입이나 런타임 에러를 체크할 수 있는 옵션을 정의할 수 있다.

// stepBuilder.ts
export type FunnelStepGuardOption<TContext> = {
  guard: (data: unknown) => data is TContext
}

export type FunnelStepParseOption<TContext> = {
  parse: (data: unknown) => TContext
}

export type FunnelStepOption<TContext> =
  | FunnelStepGuardOption<TContext>
  | FunnelStepParseOption<TContext>

FunnelStepGuardOption은 전달 받은 데이터가 특정 타입인지 검증하는 옵션이고, FunnelStepParseOption은 전달 받은 데이터를 특정 타입으로 변환하는 옵션이다.

FunnelStepOption은 두 옵션을 합치는 union 타입으로 정의되어 있는데 steps 옵션으로 두가지 방식을 다 사용할 수 있게 제공하고 있다.

그러면 실제 사용 예제를 살펴보자.

import { useFunnel } from "@use-funnel/next"

type FormState = {
  email?: string
  password?: string
  other?: unknown
}

function 이메일입력_guard(data: unknown): data is FormState {
  return true
}

function 비밀번호입력_parse(data: unknown): FormState & { email: string } {
  if (
    !(
      data != null &&
      typeof data === "object" &&
      "email" in data &&
      typeof data["email"] === "string"
    )
  ) {
    throw new Error("비밀번호입력 데이터가 아닙니다.")
  }
  return { ...data, email: data.email }
}

function 그외정보입력_parse(
  data: unknown
): FormState & { email: string; password: string; other: unknown } {
  const parseData = 비밀번호입력_parse(data)
  if (!("password" in parseData && typeof parseData.password === "string")) {
    throw new Error("비밀번호가 없습니다")
  }
  return { ...parseData, password: parseData.password, other: parseData.other }
}

function MyFunnelApp() {
  const funnel = useFunnel({
    id: "step-by-step",
    initial: {
      step: "이메일입력",
      context: {},
    },
    steps: {
      이메일입력: { guard: 이메일입력_guard },
      비밀번호입력: { parse: 비밀번호입력_parse },
      그외정보입력: { parse: 그외정보입력_parse },
    },
  })

  funnel.step === "이메일입력" && typeof funnel.context.email // "string" | "undefined"
  funnel.step === "비밀번호입력" && typeof funnel.context.email // "string"

  funnel.step === "비밀번호입력" && typeof funnel.context.password // "string" | "undefined"
  funnel.step === "그외정보입력" && typeof funnel.context.password // "string"
  // ...
}

위 코드는 공식 문서의 예제를 이용한 것으로 steps에 실제 런타임 에러를 체크할 수 있는 옵션을 정의하고 타입이 안전하게 추론되는 것을 확인할 수 있다.

UseFunnelResults

타입적으로 가장 복잡한 UseFunnelResults는 createUseFunnel 함수의 반환 타입이다. 해당 타입을 이해하기 위해 위와 같이 구성하는 타입들을 하나하나씩 살펴보며 이해해보자.

// core.ts
export type AnyStepContextMap = Record<string, AnyContext>

export type RouteOption = Partial<Record<string, any>>

export interface FunnelState<TName extends string, TContext = never> {
  step: TName
  context: TContext
}

export type AnyFunnelState = FunnelState<string, AnyContext>

export type GetFunnelStateByName<
  TFunnelState extends AnyFunnelState,
  TName extends TFunnelState["step"]
> = Extract<TFunnelState, { step: TName }>

AnyStepContextMap은 퍼널의 스텝별 데이터를 정의하는 타입이고, RouteOption은 퍼널의 라우트 옵션을 정의하는 타입으로 key를 문자열로 가지는 객체이다.

FunnelState 타입은 퍼널의 상태를 정의하는 타입으로 퍼널의 상태는 퍼널의 스텝과 퍼널에서 사용할 데이터를 정의하는 context로 구성되어 있다.

GetFunnelStateByName 타입은 FunnelState 타입에서 특정 스텝의 이름을 이용해 특정 퍼널의 상태를 추출하는 타입이다.

예로 퍼널의 상태가 다음과 같이 정의되어 있다고 가정해보자.

type StepContextMap = {
  이메일입력: {
    email?: string
  }
  비밀번호입력: {
    email: string
    password?: string
  }
}

여기에 특정 스텝의 상태를 추출하면 다음과 같은 타입이 된다.

type 이메일입력State = GetFunnelStateByName<StepContextMap, "이메일입력">
// {
//   step: '이메일입력';
//   context: { email?: string; }
// }

이제 다음으로 히스토리 관리 메소드들, 트랜지션 함수를 정의하는 타입들을 살펴보자.

// router.ts
export interface FunnelRouterTransitionOption {
  renderComponent?: {
    overlay: boolean
  }
}

type TransitionFnArguments<
  TName extends PropertyKey,
  TContext,
  TRouteOption extends RouteOption
> = Partial<TContext> extends TContext
  ? [
      target: TName,
      context?: TContext,
      option?: FunnelRouterTransitionOption & TRouteOption
    ]
  : [
      target: TName,
      context: TContext,
      option?: FunnelRouterTransitionOption & TRouteOption
    ]

FunnelRouterTransitionOption 타입은 퍼널의 라우트 옵션을 정의하는 타입으로 Overlay 형식의 컴포넌트도 퍼널의 스텝으로 관리하기 위해 정의되어 있다.

TransitionFnArguments 타입은 트랜지션 함수의 인자를 정의하는 타입으로 트랜지션 함수의 인자는 특정 스텝의 이름, 스텝의 데이터, 라우트 옵션으로 구성되어 있다.

다음으로 step별로 required, optional 속성을 정의하는 util 타입을 살펴보자.

// typeUtils.ts

export type Prettify<T> = Omit<T, never>

export type RequiredCompareKeys<TBase, TResult> =
  | keyof TResult
  | keyof TBase extends infer K
  ? K extends keyof TResult
    ? K extends keyof TBase
      ? TBase[K] extends TResult[K]
        ? never
        : K
      : undefined extends TResult[K]
      ? never
      : K
    : never
  : never

export type OptionalCompareKeys<TBase, TResult> =
  | keyof TBase
  | keyof TResult extends infer K
  ? K extends keyof TResult
    ? K extends keyof TBase
      ? TBase[K] extends TResult[K]
        ? K
        : never
      : undefined extends TResult[K]
      ? K
      : never
    : K extends keyof TBase
    ? K
    : never
  : never

Prettify 타입은 객체의 속성으로 never인 타입을 제외해 타입을 읽기 쉽게 만들어주는 타입이다.

RequiredCompareKeys 타입은 두가지 타입의 속성 중 필수 속성으로 변경/추가된 속성을 배열로 반환하고,OptionalCompareKeys 타입은 두가지 타입의 속성 중 선택 속성으로 변경된 속성과 공통으로 가지고 있는 속성을 배열로 반환한다.

예시로 step별로 아래와 같은 타입이 있다고 가정해보자.

type StepContextMap = {
  이메일입력: {
    email?: string
  }
  비밀번호입력: {
    email: string
    password?: string
  }
}

그러면 이제 두가지 타입의 속성을 합치면 RequiredCompareKeys와 OptionalCompareKeys 타입을 사용해 필수 속성과 선택 속성을 추출할 수 있다.

// 비밀번호입력 스텝에서:
type Required = RequiredCompareKeys<
  StepContextMap["이메일입력"],
  StepContextMap["비밀번호입력"]
> // "email"

type Optional = OptionalCompareKeys<
  StepContextMap["이메일입력"],
  StepContextMap["비밀번호입력"]
> // "password"

TransitionFn에서는 두가지 타입의 속성을 합치는 타입을 사용해 트랜지션 함수의 인자를 정의하고 있다.

// typeUtils.ts

export type CompareMergeContext<TBase, TResult> = Prettify<
  {
    [K in RequiredCompareKeys<TBase, TResult>]: K extends keyof TResult
      ? TResult[K]
      : K extends keyof TBase
      ? TBase[K]
      : never
  } & {
    [K in OptionalCompareKeys<TBase, TResult>]?: K extends keyof TBase
      ? TBase[K]
      : K extends keyof TResult
      ? TResult[K]
      : never
  }
>

//FunnelRender.tsx

type TransitionFn<
  TState extends AnyFunnelState,
  TNextState extends AnyFunnelState,
  TRouteOption extends RouteOption
> = <TName extends TNextState["step"]>(
  ...args:
    | TransitionFnArguments<
        TName,
        CompareMergeContext<
          TState["context"],
          GetFunnelStateByName<TNextState, TName>["context"]
        >,
        TRouteOption
      >
    | [
        target: TName,
        callback: (
          prev: TState["context"]
        ) => GetFunnelStateByName<TNextState, TName>["context"],
        option?: FunnelRouterTransitionOption & TRouteOption
      ]
) => Promise<GetFunnelStateByName<TNextState, TName>>

CompareMergeContext 타입은 두가지 타입의 속성을 합치는 타입으로 필수 속성으로 변경된 값과 기존에 있거나 새롭게 추가된 선택 속성을 추출해 합치는 타입이다.

TransitionFn 타입은 트랜지션 함수를 정의하는 타입으로 인자는 두가지 인터페이스를 사용해 정의하고 있고 반환 타입은 특정 스텝의 상태를 Promise로 반환하는 타입이다. 제네릭을 보면 현재 TState와 TNextState는 트랜지션 함수의 현재 상태와 다음 상태를 정의하고 있고 TRouteOption는 트랜지션 함수의 라우트 옵션을 전달받는다.

인자의 첫번째 방식은 TransitionFnArguments 타입을 사용해 특정 스텝의 이름, 스텝의 context, 라우트 옵션으로 구성된다. Context를 전달할 때 타입적으로 다음 스텝으로 퍼널 전환할 때 타입적으로 안전하게 context를 전달하게 하기 위해 CompareMergeContext 타입을 사용해 정의하고 있다. 비교대상은 TState[context] 타입와 GetFunnelStateByName 타입을 사용한 다음 스텝의 context로 정의된다.

두번째 방식은 특정 스텝의 이름, 콜백 함수, 라우트 옵션으로 구성된다. 콜백 함수는 이전 스텝의 context를 받아 다음 스텝의 context를 반환하는 함수이다.

이제 히스토리 타입을 보자.

export type FunnelTransition<
  TStepContextMap extends AnyStepContextMap,
  TStepKey extends keyof TStepContextMap & string,
  TRouteOption extends RouteOption
> = TransitionFn<
  FunnelState<TStepKey, TStepContextMap[TStepKey]>,
  {
    [NextStepKey in keyof TStepContextMap & string]: FunnelState<
      NextStepKey,
      TStepContextMap[NextStepKey]
    >
  }[keyof TStepContextMap & string],
  TRouteOption
>

export interface FunnelHistory<
  TStepContextMap extends AnyStepContextMap,
  TStepKey extends keyof TStepContextMap & string,
  TRouteOption extends RouteOption
> {
  push: FunnelTransition<TStepContextMap, TStepKey, TRouteOption>
  replace: FunnelTransition<TStepContextMap, TStepKey, TRouteOption>
  go: (index: number) => void | Promise<void>
  back: () => void | Promise<void>
}

FunnelTransition 타입은 퍼널의 전환 함수(트랜지션 함수)를 정의하는 타입으로 퍼널의 전환 함수는 퍼널의 상태, 다음 상태, 라우트 옵션으로 구성된다.

FunnelHistory 타입은 퍼널의 히스토리를 정의하는 타입으로 퍼널의 히스토리는 퍼널의 상태, 다음 상태, 라우트 옵션을 전달받아 트랜지션 함수를 정의하고 있다. 우리가 자주보던 window.history API와 유사하게 push, replace, go, back 메소드를 정의하고 있다. 각 메소드는 FunnelTransition 타입을 통해 정의되어 있다.

공식문서의 예시로 보면 다음과 같다.

declare function 이메일입력(props: {
  onNext: (email: string) => void
}): JSX.Element
declare function 비밀번호입력(props: {
  email: string
  onNext: (password: string) => void
}): JSX.Element

switch (funnel.step) {
  case "이메일입력":
    return (
      <이메일입력
        onNext={email => funnel.history.push("비밀번호입력", { email })}
      />
    )
  case "비밀번호입력":
    return (
      <비밀번호입력
        email={funnel.context.email} // optional -> required
        onNext={password =>
          funnel.history.push("그외정보입력", prev => ({ ...prev, password }))
        }
      />
    )
}

이메일입력에서 onNext를 보게되면 email 데이터는 필수값으로 전달되고, 비밀번호 입력에서 context.email은 이메일입력에서 입력한 값이 있기 때문에 필수값으로 전달된다.

다음으로 FunnelStep 타입을 보자.

// FunnelRender.tsx

export type FunnelStep<
  TStepContextMap,  // 전체 스텝 컨텍스트 맵
  TStepKey,        // 현재 스텝 키
  TRouteOption     // 라우팅 옵션
> = {
  step: TStepKey;                              // 현재 스텝 이름
  context: TStepContextMap[TStepKey];          // 현재 스텝의 컨텍스트
  history:FunnelHistory<TStepContextMap, TStepKey, TRouteOption>         // 히스토리 조작 메서드들
  index: number;                               // 현재 스텝의 인덱스
  historySteps: FunnelState<...>[];           // 전체 히스토리 스텝들
};

export type FunnelStepByContextMap<TStepContextMap extends AnyStepContextMap, TRouteOption extends RouteOption> = {
  [TStepKey in keyof TStepContextMap & string]: FunnelStep<TStepContextMap, TStepKey, TRouteOption>;
}[keyof TStepContextMap & string];

export type FunnelRenderReady<
  TStepContextMap extends AnyStepContextMap,
  TRouteOption extends RouteOption,
> = FunnelStepByContextMap<TStepContextMap, TRouteOption>;

FunnelStep은 앞서 정리해온 타입들을 이용해 퍼널 스텝을 정의하는 타입이다. 퍼널 스텝은 step, context, history, index, historySteps로 구성된다.

FunnelStepByContextMap 타입은 contextMap의 키값들을 키로, 값은 퍼널 스텝으로 가지는 객체에서 각 스텝별 FunnelStep 타입을 생성하는 유틸리티 타입을 반환하는 util 타입이다.

FunnelRenderReady 타입은 퍼널의 스텝을 정의하는 타입으로 퍼널의 스텝은 퍼널의 상태, 라우트 옵션을 전달받아 퍼널의 스텝을 정의하고 있다.

// FunnelRender.tsx
export type FunnelRenderOverlayHandler = {
  close: () => void
}

export type RenderResult<
  TStepContextMap extends AnyStepContextMap,
  TStepKey extends keyof TStepContextMap & string,
  TRouteOption extends RouteOption
> =
  | {
      type: "render"
      render: (
        step: FunnelStep<TStepContextMap, TStepKey, TRouteOption>
      ) => React.ReactNode
    }
  | {
      type: "overlay"
      render: (
        step: FunnelStep<TStepContextMap, TStepKey, TRouteOption> &
          FunnelRenderOverlayHandler
      ) => React.ReactNode
    }

export interface FunnelRenderComponentProps<
  TStepContextMap extends AnyStepContextMap,
  TRouteOption extends RouteOption
> {
  funnel: FunnelRenderReady<TStepContextMap, TRouteOption>
  steps: {
    [TStepKey in keyof TStepContextMap & string]:
      | RenderResult<TStepContextMap, TStepKey, TRouteOption>
      | ((
          step: FunnelStep<TStepContextMap, TStepKey, TRouteOption>
        ) => React.ReactNode)
  }
}

FunnelRenderOverlayHandler는 overlay 형식의 컴포넌트를 렌더링할때 사용하는 타입으로 오버레이가 닫힐 때를 위해 close 메소드를 정의하고 있다.

RenderResult 타입은 퍼널 타입별로 렌더링함수의 타입을 정의하는 것으로 render, overlay 두가지 타입을 정의함으로서 이후에 퍼널 타입별로 렌더링함수를 정의할 때 타입적으로 안전하게 정의할 수 있다.

FunnelRenderComponentProps 타입은 RenderComponent의 prop을 정의하는 타입으로 퍼널의 렌더 컴포넌트는 퍼널의 스텝을 전달받아 렌더 함수를 정의하고 있다.

// useFunnel.tsx
export type UseFunnelResults<
  TStepContextMap extends AnyStepContextMap,
  TRouteOption extends RouteOption
> = {
  Render: ((
    props: FunnelRenderComponentProps<TStepContextMap, TRouteOption>["steps"]
  ) => JSX.Element) & {
    with: typeof renderWith
    overlay: typeof overlayRenderWith
  }
} & FunnelStepByContextMap<TStepContextMap, TRouteOption>

UseFunnelResults 타입은 앞서 소개한 타입들을 이용해 훅으로 반환되는 타입으로 Render 메소드는 FunnelRenderComponentProps 타입으로 prop을 전달받아 컴포넌트를 반환하고, FunnelStepByContextMap 타입으로 퍼널의 스텝을 반환하게 된다.

실제 useFunnel훅을 사용하는 예제를 보면 다음과 같다.

declare function 이메일입력(props: {
  onNext: (email: string) => void
}): JSX.Element

declare function 비밀번호입력(props: {
  email: string
  onNext: (password: string) => void
}): JSX.Element

declare function 그외정보입력(): JSX.Element

type SignupFunnel = {
  이메일입력: 이메일입력
  비밀번호입력: 비밀번호입력
  그외정보입력: 그외정보입력
}

// switch문을 사용한 구현
function MyFunnelApp() {
  const funnel = useFunnel<SignupFunnel>({
    id: "my-funnel-app",
    initial: {
      step: "이메일입력",
      context: {},
    },
  })

  switch (funnel.step) {
    case "이메일입력":
      return (
        <이메일입력
          onNext={email => funnel.history.push("비밀번호입력", { email })}
        />
      )

    case "비밀번호입력":
      return (
        <비밀번호입력
          email={funnel.context.email}
          onNext={password => funnel.history.push("그외정보입력", { password })}
        />
      )

    case "그외정보입력":
      return <그외정보입력 />
  }
}

// Render 컴포넌트를 사용한 구현
function MyFunnelApp() {
  const funnel = useFunnel<SignupFunnel>({
    id: "my-funnel-app",
    initial: {
      step: "이메일입력",
      context: {},
    },
  })

  return (
    <funnel.Render
      이메일입력={({ history }) => (
        <이메일입력 onNext={email => history.push("비밀번호입력", { email })} />
      )}
      비밀번호입력={({ context, history }) => (
        <비밀번호입력
          email={context.email}
          onNext={password => history.push("그외정보입력", { password })}
        />
      )}
      그외정보입력={() => <그외정보입력 />}
    />
  )
}

예제를 보면 퍼널 컴포넌트를 만들때 Switch문을 이용해서 각 스텝별로 컴포넌트를 렌더링할 수 있게 할 수 있고, Render 컴포넌트를 이용해서 각 스텝별로 컴포넌트를 렌더링할 수 있게 할 수 있다.

그러면 이제 드디어 열심히 정리한 타입들을 이용해 이제 UseFunnel 타입을 만들 수 있다.

export interface UseFunnel<TRouteOption extends RouteOption> {
  <
    _TStepContextMap extends AnyStepContextMap,
    TStepKeys extends keyof _TStepContextMap = keyof _TStepContextMap,
    TStepContext extends _TStepContextMap[TStepKeys] = _TStepContextMap[TStepKeys],
    TStepContextMap extends string extends keyof _TStepContextMap
      ? Record<TStepKeys, TStepContext>
      : _TStepContextMap = string extends keyof _TStepContextMap
      ? Record<TStepKeys, TStepContext>
      : _TStepContextMap
  >(
    options: UseFunnelOptions<TStepContextMap>
  ): UseFunnelResults<TStepContextMap, TRouteOption>
}

대부분의 타입에 대한 분석은 끝났으니 실 구현부를 보자.

FunnelRender

funnelRender는 Render컴포넌트에 해당되는 컴포넌트에 해당하게 된다.

export function useUpdatableRef<T>(value: T) {
  const ref = useRef(value)
  ref.current = value
  return ref
}

function useOverwriteFunnelHistoryTransitionArgument<
  TStepContextMap extends AnyStepContextMap,
  TStepKey extends keyof TStepContextMap & string,
  TRouteOption extends RouteOption
>(
  history: FunnelHistory<TStepContextMap, TStepKey, TRouteOption>,
  callback: (
    step: TStepKey,
    context?: TStepContextMap[TStepKey],
    option?: FunnelRouterTransitionOption
  ) => FunnelRouterTransitionOption
): FunnelHistory<TStepContextMap, TStepKey, TRouteOption> {
  const callbackRef = useUpdatableRef(callback)

  return useMemo(() => {
    return {
      ...history,
      push(...args) {
        const [step, context, option] = args
        const newOption = callbackRef.current(
          step as unknown as TStepKey,
          context as TStepContextMap[TStepKey],
          option
        )
        return (history.push as any)(step, context, newOption)
      },
      replace(...args) {
        const [step, context, option] = args
        const newOption = callbackRef.current(
          step as unknown as TStepKey,
          context as TStepContextMap[TStepKey],
          option
        )
        return (history.replace as any)(step, context, newOption)
      },
    }
  }, [history])
}

export function FunnelRender<
  TStepContextMap extends AnyStepContextMap,
  TRouteOption extends RouteOption
>(props: FunnelRenderComponentProps<TStepContextMap, TRouteOption>) {
  //...
  const funnelRenderHistory = useOverwriteFunnelHistoryTransitionArgument(
    funnel.history,
    (step, _, transitionOption) => {
      const targetStep = steps[step]
      const isOverlay =
        typeof targetStep === "object" && targetStep.type === "overlay"
      const newTransitionOption: FunnelRouterTransitionOption = {
        ...transitionOption,
        renderComponent: {
          overlay: isOverlay,
        },
      }
      return newTransitionOption
    }
  )
  //...
}

useUpdatableRef 훅은 컴포넌트가 리렌더링됨에 따라 최신 값을 유지하기 위해 사용되는 훅이다.

useOverwriteFunnelHistoryTransitionArgument는 overlay 타입의 스텝을 관리하기 위해 사용되는 훅으로 ovelay 타입인지 체크하고 새로운 트랜지션 옵션을 반환하는 훅이다.

const { funnel, steps } = props
const render = steps[funnel.step]
let renderEntires: Array<[keyof TStepContextMap, React.ReactNode]> = []

const funnelRenderHistory = useOverwriteFunnelHistoryTransitionArgument(
  funnel.history,
  (step, _, transitionOption) => {
    const targetStep = steps[step]
    const isOverlay =
      typeof targetStep === "object" && targetStep.type === "overlay"
    const newTransitionOption: FunnelRouterTransitionOption = {
      ...transitionOption,
      renderComponent: {
        overlay: isOverlay,
      },
    }
    return newTransitionOption
  }
)

props로 전달받은 steps를 통해 전체 퍼널 스텝 객체를 받고, 현재 스텝을 funnel.step으로 받아 현재 스텝에 해당하는 컴포넌트를 받는다. funnelRenderHistory는 overlay 타입인지 체크하고 새로운 트랜지션 옵션을 반환한다.

renderEntires는 현재 스텝과 현재 스텝의 컴포넌트를 배열로 저장하는 변수다.

const funnelRenderStep = useMemo(() => {
  return {
    ...funnel,
    history: funnelRenderHistory,
  }
}, [funnel, funnelRenderHistory])

if (typeof render === "function") {
  renderEntires.push([funnelRenderStep.step, render(funnelRenderStep)])
} else if (render.type === "render") {
  renderEntires.push([funnelRenderStep.step, render.render(funnelRenderStep)])
} else if (render.type === "overlay") {
  const beforeSteps = funnelRenderStep.historySteps.slice(
    0,
    funnelRenderStep.index
  )
  for (const step of beforeSteps.slice().reverse()) {
    const stepRender = steps[step.step]
    // NOTE: cannot use history in overlay render before steps
    if (typeof stepRender === "function") {
      renderEntires.push([
        step.step,
        stepRender({
          ...funnelRenderStep,
          ...step,
          history: overlayBeforeHistory,
        }),
      ])
      break
    } else {
      renderEntires.push([
        step.step,
        stepRender.render({
          ...funnelRenderStep,
          ...step,
          history: overlayBeforeHistory,
          close: neverUseHistory,
        }),
      ])
      if (stepRender.type === "render") {
        break
      }
    }
  }
  renderEntires = renderEntires.slice().reverse()
  renderEntires.push([
    funnelRenderStep.step,
    render.render({
      ...funnelRenderStep,
      close: funnelRenderHistory.back,
    }),
  ])
}

funnelRenderStep은 현재 스텝과 현재 스텝의 히스토리를 합쳐서 반환하는 객체다. renderEntires에 현재 스텝과 현재 스텝의 컴포넌트를 배열로 저장하는데 이때 render의 타입에 따라 다르게 저장한다.

((step: FunnelStep<TStepContextMap, TStepKey, TRouteOption>) => React.ReactNode) render의 타입이 함수일 경우로 render에 현재 스텝을 전달해 현재 스텝의 컴포넌트를 함께 저장한다.
RenderResult의 타입이 render인 경우 render.render(funnelRenderStep)을 호출해 현재 스텝의 컴포넌트를 저장한다.
RenderResult의 타입이 overlay인 경우 overlay인 경우에는 백그라운드에 이전 스텝의 컴포넌트가 함께 렌더링되어야 하기때문에 조금 복잡한 로직을 통해 이전 스텝의 컴포넌트를 함께 저장한다. 아래에서 조금 더 자세히 보자.

function neverUseHistory(): never {
  throw new Error("Cannot use history in overlay render before steps.")
}

const overlayBeforeHistory: FunnelHistory<any, any, any> = {
  push: neverUseHistory,
  replace: neverUseHistory,
  go: neverUseHistory,
  back: neverUseHistory,
}

const beforeSteps = funnelRenderStep.historySteps.slice(
  0,
  funnelRenderStep.index
)

for (const step of beforeSteps.slice().reverse()) {
  const stepRender = steps[step.step]

  if (typeof stepRender === "function") {
    renderEntires.push([
      step.step,
      stepRender({
        ...funnelRenderStep,
        ...step,
        history: overlayBeforeHistory,
      }),
    ])
    break
  } else {
    renderEntires.push([
      step.step,
      stepRender.render({
        ...funnelRenderStep,
        ...step,
        history: overlayBeforeHistory,
        close: neverUseHistory,
      }),
    ])

    if (stepRender.type === "render") {
      break
    }
  }
}

renderEntires = renderEntires.slice().reverse()

renderEntires.push([
  funnelRenderStep.step,
  render.render({
    ...funnelRenderStep,
    close: funnelRenderHistory.back,
  }),
])

type이 overlay인 경우 overlayBeforeHistory를 정의해 이전 스텝의 잘못된 history 변경을 방지한다. overlay가 직전 스텝인 경우에는 다시 이전 스텝이 필요하기 때문에, render일때만 break한다. 마지막에 현재의 overlay스텝을 entries에 추가하고, overlay close 메소드를 통해 뒤로가기 메소드를 전달한다.

return (
  <Fragment>
    {renderEntires.map(([step, element]) => (
      <Fragment key={step.toString()}>{element}</Fragment>
    ))}
  </Fragment>
)

마지막으로 renderEntires를 이용해 정의된 요소들을 렌더링해 반환한다.

// 전체 코드

function neverUseHistory(): never {
  throw new Error("Cannot use history in overlay render before steps.")
}

const overlayBeforeHistory: FunnelHistory<any, any, any> = {
  push: neverUseHistory,
  replace: neverUseHistory,
  go: neverUseHistory,
  back: neverUseHistory,
}

export function FunnelRender<
  TStepContextMap extends AnyStepContextMap,
  TRouteOption extends RouteOption
>(props: FunnelRenderComponentProps<TStepContextMap, TRouteOption>) {
  const { funnel, steps } = props
  const render = steps[funnel.step]
  let renderEntires: Array<[keyof TStepContextMap, React.ReactNode]> = []

  const funnelRenderHistory = useOverwriteFunnelHistoryTransitionArgument(
    funnel.history,
    (step, _, transitionOption) => {
      const targetStep = steps[step]
      const isOverlay =
        typeof targetStep === "object" && targetStep.type === "overlay"
      const newTransitionOption: FunnelRouterTransitionOption = {
        ...transitionOption,
        renderComponent: {
          overlay: isOverlay,
        },
      }
      return newTransitionOption
    }
  )

  const funnelRenderStep = useMemo(() => {
    return {
      ...funnel,
      history: funnelRenderHistory,
    }
  }, [funnel, funnelRenderHistory])

  if (typeof render === "function") {
    renderEntires.push([funnelRenderStep.step, render(funnelRenderStep)])
  } else if (render.type === "render") {
    renderEntires.push([funnelRenderStep.step, render.render(funnelRenderStep)])
  } else if (render.type === "overlay") {
    const beforeSteps = funnelRenderStep.historySteps.slice(
      0,
      funnelRenderStep.index
    )
    for (const step of beforeSteps.slice().reverse()) {
      const stepRender = steps[step.step]
      // NOTE: cannot use history in overlay render before steps
      if (typeof stepRender === "function") {
        renderEntires.push([
          step.step,
          stepRender({
            ...funnelRenderStep,
            ...step,
            history: overlayBeforeHistory,
          }),
        ])
        break
      } else {
        renderEntires.push([
          step.step,
          stepRender.render({
            ...funnelRenderStep,
            ...step,
            history: overlayBeforeHistory,
            close: neverUseHistory,
          }),
        ])
        if (stepRender.type === "render") {
          break
        }
      }
    }
    renderEntires = renderEntires.slice().reverse()
    renderEntires.push([
      funnelRenderStep.step,
      render.render({
        ...funnelRenderStep,
        close: funnelRenderHistory.back,
      }),
    ])
  }

  return (
    <Fragment>
      {renderEntires.map(([step, element]) => (
        <Fragment key={step.toString()}>{element}</Fragment>
      ))}
    </Fragment>
  )
}

function useOverwriteFunnelHistoryTransitionArgument<
  TStepContextMap extends AnyStepContextMap,
  TStepKey extends keyof TStepContextMap & string,
  TRouteOption extends RouteOption
>(
  history: FunnelHistory<TStepContextMap, TStepKey, TRouteOption>,
  callback: (
    step: TStepKey,
    context?: TStepContextMap[TStepKey],
    option?: FunnelRouterTransitionOption
  ) => FunnelRouterTransitionOption
): FunnelHistory<TStepContextMap, TStepKey, TRouteOption> {
  const callbackRef = useUpdatableRef(callback)

  return useMemo(() => {
    return {
      ...history,
      push(...args) {
        const [step, context, option] = args
        const newOption = callbackRef.current(
          step as unknown as TStepKey,
          context as TStepContextMap[TStepKey],
          option
        )
        return (history.push as any)(step, context, newOption)
      },
      replace(...args) {
        const [step, context, option] = args
        const newOption = callbackRef.current(
          step as unknown as TStepKey,
          context as TStepContextMap[TStepKey],
          option
        )
        return (history.replace as any)(step, context, newOption)
      },
    }
  }, [history])
}

createUseFunnel

이제 코어 패키지의 찐 본채인 createUseFunnel을 분석해보자.

export interface FunnelRouterOption<TState extends AnyFunnelState> {
  id: string;
  initialState: TState;
}

export interface FunnelRouterTransitionOption {
  renderComponent?: {
    overlay: boolean;
  };
}

export interface FunnelRouterResult<TRouteOption extends RouteOption> {
  history: AnyFunnelState[];
  currentIndex: number;
  push: (state: AnyFunnelState, option?: FunnelRouterTransitionOption & TRouteOption) => void | Promise<void>;
  replace: (state: AnyFunnelState, option?: FunnelRouterTransitionOption & TRouteOption) => void | Promise<void>;
  go: (index: number) => void | Promise<void>;
  cleanup: () => void;
}

export interface FunnelRouter<TRouteOption extends RouteOption> {
  (option: FunnelRouterOption<AnyFunnelState>): FunnelRouterResult<TRouteOption>;
}

export function createUseFunnel<TRouteOption extends RouteOption>(
  useFunnelRouter: FunnelRouter<TRouteOption>
): UseFunnel<TRouteOption> {

useFunnelRouter는 패키지별로 전달할 Router로 FunnelRouterOption을 전달받아 FunnelRouterResult를 반환하는 함수다. Core 패키지로 전달되는 Routing 패키지들의 인터페이스가 된다.

FunnelRouterOption에는 앞서 사용예시에서 전달하던 id와 initialState가 있고, FunnelRouterResult에는 history, currentIndex, push, replace, go, cleanup 있다.

createUseFunnel은 한마디로 말하면 라우팅 패키지들(useFunnelRouter)을 전달받아 현재 상태를 관리하고, UseFunnelResult를 반환하는 함수다.

 return function useFunnel<
    _TStepContextMap extends AnyStepContextMap,
    TStepKeys extends keyof _TStepContextMap = keyof _TStepContextMap,
    TStepContext extends _TStepContextMap[TStepKeys] = _TStepContextMap[TStepKeys],
    TStepContextMap extends string extends keyof _TStepContextMap
    ? Record<TStepKeys, TStepContext>
    : _TStepContextMap = string extends keyof _TStepContextMap ? Record<TStepKeys, TStepContext> : _TStepContextMap,
  >(options: UseFunnelOptions<TStepContextMap>): UseFunnelResults<TStepContextMap, TRouteOption> {
    const optionsRef = useUpdatableRef(options);
    const router = useFunnelRouter({
      id: optionsRef.current.id,
      initialState: optionsRef.current.initial,
    });
    const currentState = (router.history[router.currentIndex] ??
      options.initial) as FunnelStateByContextMap<TStepContextMap>;
    const currentStateRef = useUpdatableRef(currentState);

createUseFunnel은 useFunnel함수를 반환하는데 이때 앞서 전달했던 타입들이 제네릭으로 정의되게 된다.

optionsRef는 최신 옵션값을 참조하게 되고, router에 해당 옵션을 전달해 라우팅 패키지들을 통해 퍼널 상태를 관리하게 된다.

currentState는 현재상태를, 비어있다면 옵션의 initialState를 참조하게 되고, currentStateRef는 이러한 현재 상태를 참조해 항상 최신 상태를 참조하게 된다.

const cleanUpRef = useUpdatableRef(router.cleanup)

useEffect(() => {
  return () => {
    cleanUpRef.current()
  }
}, [])

cleanUpRef는 패키지별로 정의된 cleanup 메소드를 가져와서 unmount시 실행한다.

const parseStepContext = useCallback(
  <TStep extends keyof TStepContextMap>(
    step: TStep,
    context: unknown
  ): TStepContextMap[TStep] | null => {
    const stepOption = optionsRef.current.steps?.[step]
    if (stepOption == null) {
      return context as TStepContextMap[TStep]
    }
    // 1. check parse function
    if (funnelStepOptionIsParse(stepOption)) {
      return stepOption.parse(context)
    }
    // 2. check guard function
    if (funnelStepOptionIsGuard(stepOption)) {
      return stepOption.guard(context) ? context : null
    }
    return null
  },
  [optionsRef]
)

parseStepContext는 steps 옵션의 guard, parse 함수를 통해 현재 상태를 파싱하는 함수다.

const history: FunnelHistory<
  TStepContextMap,
  keyof TStepContextMap & string,
  TRouteOption
> = useMemo(() => {
  const transition = (
    step: keyof TStepContextMap,
    assignContext?: object | ((prev: object) => object)
  ) => {
    const newContext =
      typeof assignContext === "function"
        ? assignContext(currentStateRef.current.context)
        : {
            ...currentStateRef.current.context,
            ...assignContext,
          }
    const context = parseStepContext(step, newContext)
    return context == null
      ? optionsRef.current.initial
      : ({
          step,
          context,
        } as FunnelStateByContextMap<TStepContextMap>)
  }
  return {
    push: async (...args) => {
      const [step, assignContext, transitionOption] = args
      const nextState = transition(step, assignContext)
      await router.push(nextState, transitionOption)
      return nextState as never
    },
    replace: async (...args) => {
      const [step, assignContext, transitionOption] = args
      const nextState = transition(step, assignContext)
      await router.replace(nextState, transitionOption)
      return nextState as never
    },
    go: router.go,
    back: () => router.go(-1),
  }
}, [router.replace, router.push, router.go, optionsRef, parseStepContext])

history는 현재 상태를 파싱하고, 현재 상태를 전달해 다음 상태를 만들어 라우팅 패키지별로 정의된 transition 메소드에 정의한다.

currentStateRef를 통해 최신 현재 상태를 참조하게 한 이유로 비동기로 호출되더라도 최신값을 조회할 수 있게 된다.

transition 메소드에서는 parseStepContext를 통해 현재 상태를 파싱하게 된다.

const step: FunnelStep<
  TStepContextMap,
  keyof TStepContextMap & string,
  TRouteOption
> = useMemo(() => {
  const validContext = parseStepContext(currentState.step, currentState.context)
  return {
    ...(validContext == null
      ? optionsRef.current.initial
      : {
          step: currentState.step,
          context: validContext,
        }),
    history,
    index: router.currentIndex,
    historySteps: router.history as FunnelStateByContextMap<TStepContextMap>[],
  }
}, [
  currentState,
  history,
  router.history,
  router.currentIndex,
  parseStepContext,
])

step은 현재 상태에 대한 context가 유효한지 확인하고, 유효하다면 현재 상태를 전달해 UseFunnelResult의 step, context, history, index, historySteps를 전달하는 변수다.

export function useStateSubscriberStore<T>(state: T) {
  const stateRef = useUpdatableRef(state);

  const stateStoreRef = useRef<Store<T>>({
    listeners: [],
    subscribe(listeners) {
      this.listeners.push(listeners);
      return () => {
        this.listeners = this.listeners.filter((fn) => fn !== listeners);
      };
    },
    getSnapshot() {
      return stateRef.current;
    },
  });

  useEffect(() => {
    for (const listener of stateStoreRef.current.listeners) {
      listener();
    }
  }, [state]);

  return stateStoreRef;
}

export function useStateStore<T>(subscriberRef: MutableRefObject<Store<T>>) {
  const [state, setState] = useState(() => subscriberRef.current.getSnapshot());

  useEffect(() => {
    return subscriberRef.current.subscribe(() => {
      setState(subscriberRef.current.getSnapshot());
    });
  }, [subscriberRef]);

  return state;
}


const currentStepStoreRef = useStateSubscriberStore(step);

const Render = useMemo(() => {
  return Object.assign(
    (props: FunnelRenderComponentProps<TStepContextMap, TRouteOption>['steps']) => {
      const currentStep = useStateStore(currentStepStoreRef)
      return <FunnelRender funnel={currentStep} steps={props} />
      },
      {
        with: renderWith,
        overlay: overlayRenderWith,
      }
    )
  }, [currentStepStoreRef])

  return {
    ...step,
    Render,
  }
}

useStateSubscriberStore는 useSyncExternalStore와 동일하게 state를 참조하고, 변경될때마다 리스너를 호출하는 함수다.

Render는 현재 상태를 참조하고, 현재 상태를 전달해 FunnelRender 컴포넌트를 렌더링하는 함수다. 이때 Object.assign을 통해 FunnelRender 컴포넌트에 with와 overlay 옵션을 할당하게 된다.

// 전체 코드
export function createUseFunnel<TRouteOption extends RouteOption>(
  useFunnelRouter: FunnelRouter<TRouteOption>
): UseFunnel<TRouteOption> {
  return function useFunnel<
    _TStepContextMap extends AnyStepContextMap,
    TStepKeys extends keyof _TStepContextMap = keyof _TStepContextMap,
    TStepContext extends _TStepContextMap[TStepKeys] = _TStepContextMap[TStepKeys],
    TStepContextMap extends string extends keyof _TStepContextMap
      ? Record<TStepKeys, TStepContext>
      : _TStepContextMap = string extends keyof _TStepContextMap
      ? Record<TStepKeys, TStepContext>
      : _TStepContextMap
  >(
    options: UseFunnelOptions<TStepContextMap>
  ): UseFunnelResults<TStepContextMap, TRouteOption> {
    const optionsRef = useUpdatableRef(options)
    const router = useFunnelRouter({
      id: optionsRef.current.id,
      initialState: optionsRef.current.initial,
    })
    const currentState = (router.history[router.currentIndex] ??
      options.initial) as FunnelStateByContextMap<TStepContextMap>
    const currentStateRef = useUpdatableRef(currentState)

    const cleanUpRef = useUpdatableRef(router.cleanup)

    useEffect(() => {
      return () => {
        cleanUpRef.current()
      }
    }, [])

    const parseStepContext = useCallback(
      <TStep extends keyof TStepContextMap>(
        step: TStep,
        context: unknown
      ): TStepContextMap[TStep] | null => {
        const stepOption = optionsRef.current.steps?.[step]
        if (stepOption == null) {
          return context as TStepContextMap[TStep]
        }
        // 1. check parse function
        if (funnelStepOptionIsParse(stepOption)) {
          return stepOption.parse(context)
        }
        // 2. check guard function
        if (funnelStepOptionIsGuard(stepOption)) {
          return stepOption.guard(context) ? context : null
        }
        return null
      },
      [optionsRef]
    )

    const history: FunnelHistory<
      TStepContextMap,
      keyof TStepContextMap & string,
      TRouteOption
    > = useMemo(() => {
      const transition = (
        step: keyof TStepContextMap,
        assignContext?: object | ((prev: object) => object)
      ) => {
        const newContext =
          typeof assignContext === "function"
            ? assignContext(currentStateRef.current.context)
            : {
                ...currentStateRef.current.context,
                ...assignContext,
              }
        const context = parseStepContext(step, newContext)
        return context == null
          ? optionsRef.current.initial
          : ({
              step,
              context,
            } as FunnelStateByContextMap<TStepContextMap>)
      }
      return {
        push: async (...args) => {
          const [step, assignContext, transitionOption] = args
          const nextState = transition(step, assignContext)
          await router.push(nextState, transitionOption)
          return nextState as never
        },
        replace: async (...args) => {
          const [step, assignContext, transitionOption] = args
          const nextState = transition(step, assignContext)
          await router.replace(nextState, transitionOption)
          return nextState as never
        },
        go: router.go,
        back: () => router.go(-1),
      }
    }, [router.replace, router.push, router.go, optionsRef, parseStepContext])

    const step: FunnelStep<
      TStepContextMap,
      keyof TStepContextMap & string,
      TRouteOption
    > = useMemo(() => {
      const validContext = parseStepContext(
        currentState.step,
        currentState.context
      )
      return {
        ...(validContext == null
          ? optionsRef.current.initial
          : {
              step: currentState.step,
              context: validContext,
            }),
        history,
        index: router.currentIndex,
        historySteps:
          router.history as FunnelStateByContextMap<TStepContextMap>[],
      }
    }, [
      currentState,
      history,
      router.history,
      router.currentIndex,
      parseStepContext,
    ])

    const currentStepStoreRef = useStateSubscriberStore(step)

    const Render = useMemo(() => {
      return Object.assign(
        (
          props: FunnelRenderComponentProps<
            TStepContextMap,
            TRouteOption
          >["steps"]
        ) => {
          const currentStep = useStateStore(currentStepStoreRef)
          return <FunnelRender funnel={currentStep} steps={props} />
        },
        {
          with: renderWith,
          overlay: overlayRenderWith,
        }
      )
    }, [currentStepStoreRef])

    return {
      ...step,
      Render,
    }
  }
}

분석을 하면서 실 구현부 보다 타입정의가 복잡하게 느껴졌다. 코어 라이브러리의 핵심은 현재 스텝, 옵션의 최신 상태를 참조하고, 다음 상태를 만들어 라우팅 패키지별로 정의된 transition 메소드에 전달하는 것으로 정리할 수 있다.

그러면 마지막으로 라우팅 패키지로 많이 사용하는 next 패키지를 분석해보려 한다.

next 패키지 분석하기

next는 현재 15버전 기준 App router를 지원한다. 분석하려는 패키지는 Page router를 기준으로 작성하려 하고, 공식문서를 보면 App Router는 Browser 패키지를 이용할 것을 권장하고 있다.

설치하기의 app router 관련 안내

const QS_KEY = "funnel."

const STEP_KEY = ".step"
const CONTEXT_KEY = ".context"
const HISTORY_KEY = ".histories"

const checkIsHistoryKey = (key: string) =>
  key.startsWith(QS_KEY) && key.endsWith(HISTORY_KEY)

먼저 상단의 변수들을 보면 퍼널의 QueryString으로 사용될 키들이 정의되어 있다. checkIsHistoryKey는 해당 키가 히스토리 키인지 확인하는 함수다. 왜 별도로 히스토리 키를 체크하는 유틸함수가 있는지는 아래에서 설명하려 한다.

export const TestPagesRouterFunnel = () => {
  const funnel = useFunnel<FunnelState>({
    id: FUNNEL_ID,
    initial: { step: "start", context: {} },
  })

  return (
    <funnel.Render
      start={({ history }) => (
        <div>
          <p>start</p>

          <button onClick={() => history.push("middle", { a: "1" })}>
            next
          </button>
        </div>
      )}
      middle={({ history }) => (
        <div>
          <p>middle</p>
          <button onClick={() => history.push("end", { a: "1", b: "2" })}>
            next
          </button>
        </div>
      )}
      end={() => (
        <div>
          <p>end</p>
        </div>
      )}
    />
  )
}

위 예제를 실행해보면 http://localhost:3101?funnel.test.step=end&funnel.test.context=%7B%22a%22%3A%221%22%2C%22b%22%3A%222%22%7D 와 같은 형태로 생성되는 것을 확인할 수 있다.

interface NextPageRouteOption {
  shallow?: boolean
  locale?: string | false
  scroll?: boolean
}

export const useFunnel = createUseFunnel<NextPageRouteOption>(({ id, initialState }) => {

NextPageRouteOption은 Next.js의 페이지 옵션 타입으로 shallow, locale, scroll 옵션을 전달받는다.

useFunnel은 앞서 코어 패키지를 분석하면서 보았던 createUseFunnel에 next page router에 맞춰 생성된 함수를 전달한다. FunnelRouter<TRouteOption> 타입으로 전달되는데 앞서 코어 패키지를 분석하면서 FunnelRouterOption을 파라미터로 FunnelRouterResult를 반환한다.

전달된 타입을 작성해보면 다음과 같다.

interface NextPageRouteOption {
  shallow?: boolean
  locale?: string | false
  scroll?: boolean
}

interface FunnelRouterResult<NextPageRouteOption> {
  history: AnyFunnelState[]
  currentIndex: number
  push: (
    state: AnyFunnelState,
    option?: FunnelRouterTransitionOption & NextPageRouteOption
  ) => void | Promise<void>
  replace: (
    state: AnyFunnelState,
    option?: FunnelRouterTransitionOption & NextPageRouteOption
  ) => void | Promise<void>
  go: (index: number) => void | Promise<void>
  cleanup: () => void
}

export interface FunnelRouter<NextPageRouteOption> {
  (
    option: FunnelRouterOption<AnyFunnelState>
  ): FunnelRouterResult<NextPageRouteOption>
}

export function createUseFunnel<NextPageRouteOption>(
  useFunnelRouter: FunnelRouter<NextPageRouteOption>
): UseFunnel<NextPageRouteOption>

다른 라이브러리들에도 마찬가지로 RouterOption을 전달받을 것으로 예상할 수 있다.

const router = useRouter()

const currentContext = useMemo(() => {
    try {
      const currentStep = router.query?.[`${QS_KEY}${id}${STEP_KEY}`] as
        | string
        | undefined
      const currentContext = router.query?.[`${QS_KEY}${id}${CONTEXT_KEY}`] as
        | string
        | undefined
      return currentStep == null || currentContext == null
        ? initialState
        : { step: currentStep, context: JSON.parse(currentContext) }
    } catch {
      return initialState
    }
  }, [router.query, initialState])

  const _beforeHistories = router.query?.[`${QS_KEY}${id}${HISTORY_KEY}`]
  const beforeHistories = useMemo<(typeof initialState)[]>(() => {
    try {
      return _beforeHistories == null
        ? []
        : JSON.parse(_beforeHistories as string)
    } catch {
      return []
    }
    }, [_beforeHistories])

  const currentIndex = beforeHistories.length
}

router는 Next.js의 useRouter 훅을 통해 현재 라우터 객체를 참조하게 된다.

currentContext는 앞서 정의한 queryString 키들을 통해 현재 상태를 참조하고, beforeHistories를 이용해 histories 상태들을 참조하게 된다.

currentIndex는 현재 스텝의 인덱스를 의미한다.

return useMemo(
  () => ({
    history: [...beforeHistories, currentContext],
    currentIndex,
    async push(state, { scroll, locale, shallow = true } = {}) {
      const { pathname, query } = makePath(router)
      const queryContext = {
        [`${QS_KEY}${id}${STEP_KEY}`]: state.step,
        [`${QS_KEY}${id}${CONTEXT_KEY}`]: JSON.stringify(state.context),
      }

      await router.push(
        {
          pathname,
          query: {
            ...query,
            [`${QS_KEY}${id}${HISTORY_KEY}`]: JSON.stringify([
              ...beforeHistories,
              currentContext,
            ]),
            ...queryContext,
          },
        },
        {
          pathname,
          query: { ...removeKeys(query, [checkIsHistoryKey]), ...queryContext },
        },
        {
          shallow,
          locale,
          scroll,
        }
      )
    },
    async replace(state, { scroll, locale, shallow = true } = {}) {
      const { pathname, query } = makePath(router)
      const queryContext = {
        [`${QS_KEY}${id}${STEP_KEY}`]: state.step,
        [`${QS_KEY}${id}${CONTEXT_KEY}`]: JSON.stringify(state.context),
      }

      await router.replace(
        {
          pathname,
          query: {
            ...query,
            ...queryContext,
          },
        },
        {
          pathname,
          query: { ...removeKeys(query, [checkIsHistoryKey]), ...queryContext },
        },
        {
          shallow,
          locale,
          scroll,
        }
      )
    },
    go: index => window.history.go(index),
    async cleanup() {
      const { pathname, query } = makePath(router)
      const queryContext = {
        [`${QS_KEY}${id}${STEP_KEY}`]: undefined,
        [`${QS_KEY}${id}${CONTEXT_KEY}`]: undefined,
      }

      await router.replace(
        {
          pathname,
          query: {
            ...query,
            ...queryContext,
          },
        },
        {
          pathname,
          query: { ...removeKeys(query, [checkIsHistoryKey]), ...queryContext },
        },
        {
          shallow: true,
        }
      )
    },
  }),
  [id, router, currentIndex, beforeHistories, currentContext]
)

각 메소드를 보게되면 FunnelRouterResult의 메소드에 맞춰 작성되어 있다.

//utils.ts
export const removeKeys = (_value: Record<string, any>, conditions: (string | ((key: string) => boolean))[]) => {
  const value = { ..._value };
  const valueKeys = Object.keys(value);

  conditions.forEach((condition) => {
    if (typeof condition === 'string') {
      delete value[condition];
    } else {
      valueKeys.forEach((key) => {
        if (condition(key)) {
          delete value[key];
        }
      });
    }
  });

  return value;
};

export const makePath = (router: Pick<NextRouter, 'asPath' | 'pathname' | 'query'>) => {
  const { asPath, query: _query } = router;
  const query = { ..._query };

  const pathname = asPath.split('?')[0];

  const pathVariables = [...router.pathname.matchAll(/\[(.+?)\]/g)].map((match) => match[1]); // 동적 라우트 변수를 추출

  pathVariables.forEach((variable) => {
    delete query[variable];
  });

  return { pathname, query };
};

// ...
async push(state, { scroll, locale, shallow = true } = {}) {
      const { pathname, query } = makePath(router)
      const queryContext = {
        [`${QS_KEY}${id}${STEP_KEY}`]: state.step,
        [`${QS_KEY}${id}${CONTEXT_KEY}`]: JSON.stringify(state.context),
      }

      await router.push(
        {
          pathname,
          query: {
            ...query,
            [`${QS_KEY}${id}${HISTORY_KEY}`]: JSON.stringify([
              ...beforeHistories,
              currentContext,
            ]),
            ...queryContext,
          },
        },
        {
          pathname,
          query: { ...removeKeys(query, [checkIsHistoryKey]), ...queryContext },
        },
        {
          shallow,
          locale,
          scroll,
        }
      )
    },
    async replace(state, { scroll, locale, shallow = true } = {}) {
      const { pathname, query } = makePath(router)
      const queryContext = {
        [`${QS_KEY}${id}${STEP_KEY}`]: state.step,
        [`${QS_KEY}${id}${CONTEXT_KEY}`]: JSON.stringify(state.context),
      }

      await router.replace(
        {
          pathname,
          query: {
            ...query,
            ...queryContext,
          },
        },
        {
          pathname,
          query: { ...removeKeys(query, [checkIsHistoryKey]), ...queryContext },
        },
        {
          shallow,
          locale,
          scroll,
        }
      )
    },

makePath는 현재 라우터의 pathname과 query를 참조하고, removeKeys는 특정 조건에 따라 쿼리스트링에서 키를 제거하는 함수다.

makePath를 통해 query를 추출할때 동적 라우트 변수가 있는 경우 해당 변수를 제거해, 보다 명확하게 funnel 관련 query만 관리하기 위한 것으로 보였다.

push, replace를 보게되면 context를 JSON.stringify를 통해 문자열로 변환해 쿼리스트링에 전달하는 것을 확인할 수 있다.

next router push interface

이때 push와 replace의 두번째 파라미터에는 as로 실제 path와 다르게 보여질 수 있게 할 수 있다. 예시로 가져왔던 http://localhost:3101?funnel.test.step=end&funnel.test.context=%7B%22a%22%3A%221%22%2C%22b%22%3A%222%22%7D로 query상태를 조회하면 history가 감춰져 있는 것을 볼 수 있다.

query state

removeKeys를 통해 history 키를 제거하는 것을 확인할 수 있다.

push는 현재 상태에 새로운 step과 context를 전달하고, replace는 현재 상태에 히스토리 변화없이 새로운 step과 context를 전달한다.

{
  // 브라우저 히스토리 이동
  go: (index) => window.history.go(index),

  // 퍼널 상태 초기화
  async cleanup() {
    // 현재 경로 정보 가져오기
    const { pathname, query } = makePath(router);

    // 퍼널 관련 쿼리 파라미터 제거
    const queryContext = {
      [`${QS_KEY}${id}${STEP_KEY}`]: undefined,
      [`${QS_KEY}${id}${CONTEXT_KEY}`]: undefined,
    };

    // 라우터 상태 업데이트
    await router.replace(
      {
        pathname,
        query: {
          ...query,
          ...queryContext,
        },
      },
      {
        pathname,
        query: {
          ...removeKeys(query, [checkIsHistoryKey]),
          ...queryContext,
        },
      },
      {
        shallow: true,
      }
    );
  },
}

go는 window.history.go(index)를 통해 히스토리를 이동하고, cleanup은 퍼널 관련 쿼리 파라미터를 제거하고 히스토리를 초기화한다. 코어 로직에서 봤듯이 해당 컴포넌트가 unmount될때 호출되는 것을 확인할 수 있다.

이렇게 별도의 패키지로 분리해 두었기 때문에 이후에 다른 라우팅 라이브러리가 나오더라도 쉽게 구현할 수 있는 확장성을 가지고 있다.

정리

useFunnel은 퍼널 상태를 관리하는 훅으로, 퍼널 상태를 초기화하고 히스토리를 이동하는 기능을 제공한다. 구버전 useFunnel은 퍼널과 데이터를 따로 관리해야하는 점과 타입적으로 정확하게 추론하기 어려웠던 점이 있었고, next와 강한 결합으로 react-native, react-router-dom과 같은 라우터에서 사용할 수 없었다.

이러한 문제점을 해결하기 위해 새로운 useFunnel이 등장하게 되었다. 보다 정확한 타입 추론과 여러가지 라우터를 지원할 수 있도록 개선되었고, 오버레이를 하나의 퍼널스텝으로도 사용할 수 있는 등 다양한 기능을 제공한다.

내부 코드를 보면서 엄청난 타입 정의에 대해 놀랐다. 덕분에 타입스크립트도 함께 공부할 수 있었고, 앞으로 퍼널을 구현할 때 더 자신감을 가지고 사용할 수 있을 것 같다.

위 예제는 next의 page router에 대한 구현만 작성했지만 이후에 React Native 환경, Next App router에 대해서 작업을 하면서 정리해가려 한다.

2024년 12월 회고, bye bye 2024

Fri, 27 Dec 2024 00:00:00 GMT

2024년 12월은 토스에서 2번째 달로, 글을 작성하는 현재 off-week 기간으로 조금 빠르게 회고를 작성하고 있다.

다른 달보다 근무 일수는 적었지만, 처음 동료평가를 받아보고, 사업자 환급금 서비스, 연말정산 미리보기 서비스 등을 개발하며 많은 것을 배웠던 한달이었다. 12월을 정리하며 토스 적응기 2달차에 대해 기록해보려 한다.

12월은 연말정산의 달

환급액 두배 이벤트 이후로 새롭게 진행한 서비스로 연말정산 미리보기 서비스를 개발해 빠르게 런칭하게 되었다.

연말에 직장인과 사업자 모두가 궁금해하는 시즌성 서비스였기 때문에 기존의 기능들을 최대한 살려서 빠르게 런칭하는 것이 중요했고, 그과정에서 세금 도메인과 프로젝트 구조를 더 이해하게 되었다.

코드를 보면서 사용자는 굉장히 편하게 느끼지만, 그 편안함을 위해 개발자들은 얼마나 많은 노력을 했는지 알 수 있었다. 다양한 유저별 상황과 조건에 맞게 제품을 만들고, 그안에서 속도를 내기 위해 노력한 흔적을 보며 많이 배울 수 있었다.

제품을 만들면서 숨이 차오른다(?)는 느낌을 받았지만, 그러다 보니 하면 좋은 일들과 중요한 일들의 위계를 세우는 것이 중요하다는 것, 왜 토스에서 Focus on Impact라는 문화를 가지고 있는지 느낄 수 있었다.

필수 기능들에 대해 빠르게 개발하고, 서비스를 런칭한 후에 추가 개선점들을 개선하는 빠른 이터레이션을 진행해 더 좋은 제품을 만들 수 있었다.

이렇게 런칭한 제품은 뉴스 기사로 소개되었고 현재까지도 좋은 반응을 이끌어내고 있다.

연말정산 미리보기 기사

첫달에 했던 환급액 두배 이벤트는 잘될 줄 알았지만 생각보다 반응이 미적지근했고, 반면 연말정산 미리보기는 개인적으로 이미 유사한 서비스들이 토스 내에도 있었기 때문에 큰 기대는 없었지만 좋은 반응을 받게 되면서, 두 달안에 토스 내의 성공과 실패(?)를 모두 경험하는 좋은 기회를 얻을 수 있었다.

다음 달은 또 어떤 일들이 있을지 더 많은 것을 배워나갈 수 있기를 바라본다.

토스에서의 첫 피드백

토스로 이직 후 처음으로 동료평가를 받아보게 되었다. 토스의 회사 문화중 솔직한 피드백을 중요시한다고 알고 있었기 때문에, 살짝 두려움이 있었지만 매일같이 함께 일하는 사일로 팀원분들의 솔직한 피드백을 받아보며 좋은 경험을 할 수 있었다.

토스의 문화

토스의 피드백은 문화를 근거로 이야기하게 되는데 여기서 가장 많이 공통적으로 받았던 부분은 Move with Urgency와 Learn proactively였다.

공통적인 설명은 한달 반이라는 기간 내에 빠르게 적응하고 제품을 만들어 팀에 기여했다는 점과 팀과 회사의 적응을 위한 점들을 먼저 물어보고 배워나갔던 점에 대해서 좋은 평가를 해주셨다.

입사를 하고 적응을 하면서 현재 팀의 내 자리는 특수성이 있었다고 느껴졌다. 매출을 내고 있는 팀이기 때문에 기대를 받는 팀이라는 점, 세금이라는 다소 어려운 맥락을 가진 제품이라는 점 등 다른 팀에 대해 잘 모르지만 주변의 이야기를 들으면서 어느정도 차이가 있다고 느껴졌다.

그렇기 때문에 적응기간을 줄이고 빠르게 팀에 기여하는 것이 중요하다고 느껴서 최대한 제품을 이해하기 위해 노력했고, 모르는 것이나 중간 중간 1대 1로 밥을 먹거나하면서 어떻게 하면 잘 적응할 수 있을지, 내가 더 잘하기 위해서 어떤 점을 신경쓰면 좋을지 등 질문을 적극적으로 했던 부분들이 긍정적으로 평가되었던 것 같다.

앞으로 더 잘할 수 있으면 좋을 부분들은 내가 가진 판단을 통해 팀과 조직에 영향력이 있다면 적극적으로 제안하는 것과 주도적으로 의견을 내는 부분이었다.

그래서 1월부터의 액션아이템으로 현재 우리 서비스에서 보완되면 좋겠다고 느끼는 점들을 적극적으로 제안해보려 한다.

두려웠지만 잘 적응하고 좋은 팀과 좋은 제품을 만들어가고 있다는 것, 한명의 토스 사람으로서 좋은 팀원이 되고 있다는 것을 느낄 수 있었다.

사업자 환급금 서비스

토스는 플랫폼으로서 많은 회사들과 협업하는 경우가 많다. 예를 들어 금융상품에서는 한국투자증권 등의 금융회사들도 있고, 토스 인슈런스는 보험사들과도 긴밀하게 협력하는 등 다양한 회사들과 협업하게 된다.

사업자 환급금은 내가 처음 맡은 제휴사 협력 서비스였다. 제휴사와 협업하면서 다른 회사의 제품을 어떻게 연결할지 우리가 해줘야할 부분과 제휴사에 요청해야할 부분 등 다양한 부분을 고려해 서비스를 만들어야 했다.

서로 개발해온 방식과 테스트 환경 등이 다르다보니 생각보다 의사소통에 많은 시간이 소요되었고, 이런 부분들을 해결하며 서비스를 만들어나가는 것이 중요하다는 것을 느낄 수 있었다.

또한, 사업자 환급 서비스는 긴 퍼널은 아니었지만, 누군가가 만들어둔 서비스를 기반으로 개발하는 게 아니라, 처음부터 개발하는 경험을 할 수 있었다.

기존 개발 환경과 달리 SSR로 개발하면서 SSR에서 주의해야할 점들 (서버에서 실행 시 window가 없다는 점 등) 등을 배울 수 있었고, 이전 slash 영상과 다른 SSR로 개발된 서비스 코드들을 분석하면서 SSR에서의 데이터 패칭 방식등을 배울 수 있었다.

SSR로 개발하면서 특히 좋았던 점은 서버에서 redirection 로직을 처리할 수 있다. CSR이었다면 유저에게 화면을 보여주고 리다이렉션이 이루어야 하기 때문에 잠시의 깜빡임과 로딩 시간이 필수적이지만, 서버에서 응답에 따라 바로 리다이렉션을 해주다보니 굉장한 장점으로 느껴졌다.

SSR의 단점은 아니지만 내가 길러야 할 새로운 역량으로 서버를 모니터링하고 디버깅 능력이 필요해졌다.

토스의 프론트 개발자로서 조금씩 더 성장해갈 수 있었던 시간으로 좋은 경험을 할 수 있었다.

다음 한달의 목표

이전 한달의 목표들은 아래와 같았다.

숨은 환급액 찾기 제품 내 개선할 부분 제시하고 작업해보기
토스 프론트엔드 라이브러리 분석하기
사내 라이브러리에 기여하기

이중 첫번째 부분은 아직 직접 작업에 대해 제시하고 작업해보지 못했다. off-week동안 조금 더 좋은 서비스가 되기 위해 필요한 부분들에 고민해보고 1월에는 꼭 직접 작업해보고 피드백을 받아보고 싶다.

두번째, 세번째 목표는 함께 진행중에 있다. 사내 라이브러리 작업에 contributor로 참여하게 되어 진행하고 있고, 이과정에서 다양한 라이브러리 코드에 대해 분석이 필요해 자연스럽게 진행할 수 있었다.

아직 진행하지 못했거나 진행중이기 때문에 다음 한달의 목표도 이전 한달과 동일하게 잡아보려 한다.

숨은 환급액 찾기 제품 내 개선할 부분 제시하고 작업해보기
사내 라이브러리 적극적으로 기여하기

이중 숨은 환급액 찾기 제품 내 개선할 부분 제시하고 작업해보기의 작업할 부분으로 성능 분석과 에러 모니터링 등 운영상 제품의 안정성에 기여할 수 있을 만한 부분들을 고려하고 있다.

생각만 하기보다 행동을 하는 한달이 되기를 다음 달에는 더 많은 것을 배워나갈 수 있기를 바란다.

2024년 11월 회고, welcome to 토스

Sun, 01 Dec 2024 00:00:00 GMT

11월은 토스로 이직한 지 첫 달이었고, 새로운 사람들, 새로운 문화, 새로운 코드 등 모든 게 새로웠던 한달이었다.

아직 적응 중이지만 한달간 겪었던, 토스의 모습과 내가 배웠던 것들을 기록해보려 한다.

내가 경험한 토스 사람들

팀에 처음 배치되었을 때 놀랐던 부분은 팀원들이 굉장히 적극적으로 도와주려 하는 모습이었다.

메이트 분은 거의 매일같이 30분씩 어려움이 없는지 기술적, 문화적 어려움을 같이 해결해주시려 해주셨고, 팀원 분들 모두가 온보딩 과정에서 필요하거나 질문이 있을 때 빠르게 도와주시는 모습을 보며 감사했다.

그와 함께 팀원 모두 자신이 하는 일에 대해 굉장히 몰입되어 있고, 왜 이일을 하는지 또는 진행하고 있는 일의 목적이 무엇인지에 대해 근본적인 질문을 누구에게 물어도 PM, 디자이너, 개발자 상관없이 명확하게 답해주는 모습을 보며 놀랐다.

이전 회사에서 개발자로서 일하면서 '주어진 것을 잘 만드는 것'에 조금 더 많이 고민을 하며 일을 했지만, 토스는 일을 하면서 왜 이일을 하는지 또는 진행하고 있는 일의 목적이 무엇인지에 대해 근본적인 질문에 대해 서로를 설득할 수 있어야하고, 확실한 목적을 가지고 일을 하는 것 같았다.

동시에 이러한 납득이 되고 난 후에는 빠르게 제품의 이터레이션을 돌리며, 유저의 피드백을 받아 제품을 발전시키는 문화를 경험할 수 있었다.

그리고 팀의 빠른 속도를 위해서 서로가 병목이 되지 않게 필요한 부분에 대해서는 서스럼없이 도움을 요청하거나 의견을 묻다보니 일을 하면서 답답함이 없다는 점이 좋았다.

이러한 속도를 보면서 아직 미숙한 내가 팀의 속도를 더디게 하지 않을까 걱정되기도 했지만, 다행히 팀원 분들이 나에게 많은 도움을 주시며 적응하는 데 도움을 주셨다.

점점 더 팀의 속도에 기여할 수 있기를, 또한 토스팀의 중요한 문화인 DRI를 발휘해서 내가 생각하는 지금 제품에 필요한 부분에 대해 의견을 제시하고 책임지고 결정해보는 것을 다음 한달의 목표로 잡으려 한다.

첫 서비스 개발 - 환급액 2배 이벤트

내가 맡게된 서비스는 토스의 '숨은 환급액 찾기' 서비스로, 유저가 납부한 세금에 대해서 돌려받을 수 있는 환급액을 찾아주는 서비스이다.

해당 서비스의 디자인들을 보고 제품을 분석하면서 놀랐던 부분은 압도당할 만큼 복잡한 퍼널이었다.

토스ㅣSLASH 23 - 퍼널: 쏟아지는 페이지 한 방에 관리하기 영상 내용중 일부

입사전에 slash 발표 영상을 봤을 때 발표자분이 엄청나게 복잡한 제품을 만드셔서 이렇게 디자인이 나왔구나 모두 이렇게 복잡하지는 않겠지 했지만, 내가 담당한 숨은 환급액 찾기 서비스 또한 만만치 않게 복잡한 퍼널이었다.

세금이라는 복잡한 개념에 대해 유저들이 이해할 수 있도록 논리적으로 퍼널들이 나열되어있었고, 시간이 꽤 필요했지만 실제 사용해보면서 디자인과 전체 플로우에 대한 이해도를 높일 수 있었다.

해당 제품에 가장 먼저 담당한 기능은 '환급액 2배 이벤트'였다. 게임 형식으로 뽑기를 진행하고 당첨시 2배 환급을 진행하는 이벤트로, 유저들의 인플로우를 늘리는 이벤트였다. 백엔드 개발자분께서 말씀해주신 것에 따르면 팀 내에서 진행했던 이벤트 중에서 가장 복잡했던 이벤트였다고 한다.

작업을 하면서 혹시 나로 인해서 기간이 많이 미뤄지지 않을까, 놓친 요구사항들로 인해서 장애가 나지 않을까 걱정했지만 다행히도 메이트분의 도움으로 계속해서 제품 이해도와 코드베이스를 높여갔고, 팀원 모두가 함께 QA를 해주시면서 다행히 안정적으로 배포될 수 있었다.

해당 이벤트가 배포되고 난 후에 또 놀랐던 점은 내가 작업한 이벤트가 뉴스 기사로 나오게 되었다는 점이었다.

환급액 2배 이벤트 기사

이전 회사에서는 팀이 열심히 작업한 기능을 유저가 모르고 사용하지 않아, 데이터적으로 분석하거나 더 나은 제품을 만드는 데 피드백을 받기 어려웠는데 토스는 굉장히 적극적으로 유저들에게 제품을 알리고 피드백을 받아 제품을 발전시키는 문화를 가지고 있구나 생각이 들었다.

토스는 정말 안타나 번트를 대는게 아니라 모두가 홈런을 치게 밀어준다는 문화를 경험할 수 있었다.

프론트엔드 코드 베이스에 익숙해지기

토스 프론트엔드 개발자로서 새로운 코드 베이스에 익숙해지기 위해서 우선 제품의 여러 코드를 보고 분석했다.

다행히 토스의 디자인 시스템은 프론트엔드 멘토링 과정을 통해서 한달간 사용하다 보니 조금 더 자연스럽게 사용할 수 있었고, 다양한 라이브러리 를 사용하는데 어려움이 있으면 여러 채널을 통해 질문할 수 있었다.

특히 사내 문서가 잘 되어 있었고, 최근 토스 기술 블로그에 소개된 박씨라는 봇이 있기 때문에 24시간 편하게 질문할 수 있어 좋았다.

토스 프론트엔드 개발자들이 더 이상 문서를 찾지 않는 이유중 일부

또한 추가적인 노력으로 사내 문서의 히스토리를 보면서 어떤 주제들을 중요하게 생각하는지 찾아 이번 달은 패키지 매니저에 대해 공부하고 정리하며 글을 작성했고, 사내 오픈소스인 overlay kit에 대해 분석하는 글을 작성했다.

앞으로도 하나씩 조금씩 더 깊이 있게 코드 베이스에 익숙해져 이후에는 기여하는 것까지를 목표로 하고 있다.

다음 한달의 목표

이번 한달은 사람, 문화, 건물 모든 것에 새롭게 적응해야 했지만, 다음 한달은 조금 더 여유를 갖고 제품에 대해 더 깊이 있게 이해하고 기여할 수 있기를 바라며 다음 한달의 목표를 정해보았다.

숨은 환급액 찾기 제품 내 개선할 부분 제시하고 작업해보기
토스 프론트엔드 라이브러리 분석하기
사내 라이브러리에 기여하기

현재 사일로 내에서 개선할 부분에 대해서 제시하고 직접 작업하고 유저에게 기술적 문제를 해결했을 때 어떤 피드백을 받을 수 있는지 경험해보고 싶고, 토스 프론트엔드 라이브러리를 분석하고 기여해보며 토스 프론트엔드 개발자로서 동료로서 성장할 수 있기를 바란다.

Overlay Kit 분석

Sun, 24 Nov 2024 00:00:00 GMT

overlay-kit은 토스의 오픈소스 프로젝트로 모바일 제품을 만들면서 자주 사용하는 바텀시트, 다이얼로그 컴포넌트를 선언적으로 관리할 수 있도록 도와주는 패키지이다.

해당 패키지의 사용법과 내부 구현을 분석해보면서 어떤 문제를 해결하고자 만들어졌는지 알아보자.

Overlay Kit이 해결하고 싶은 문제

모바일 제품을 만들면서 한정적인 화면 크기로 인해 추가 정보를 받거나, 보여주기 위해 바텀시트와 다이얼로그와 같은 overlay 컴포넌트를 자주 사용하게 된다.

이러한 overlay 컴포넌트를 사용하고 만드는 방법으로 가장 일반적인 방법은 상태를 직접 관리하는 방식으로 isOpen에 따라 컴포넌트를 보여주고 보여주지 않게 변경해 구현할 수 있다.

// 패키지 데모의 state를 이용한 예시
function DemoWithState() {
  const [isOpen, setIsOpen] = useState(false)

  return (
    <div>
      <p>Demo with useState</p>
      <button onClick={() => setIsOpen(true)}>open modal</button>
      <Modal isOpen={isOpen}>
        <div
          style={{
            display: "flex",
            flexDirection: "column",
            alignItems: "center",
            justifyContent: "center",
          }}
        >
          <p>MODAL CONTENT</p>
          <button onClick={() => setIsOpen(false)}>close modal</button>
        </div>
      </Modal>
    </div>
  )
}

문제 없이 잘 동작하는 코드이지만, 다음과 같은 문제점이 있다.

overlay 컴포넌트가 늘어남에 따라 isOpen 상태에 대한 보일러 플레이트 코드가 많아진다.
isOpen 상태의 선언(useState), 변경(onClick), 사용하는 곳(Modal)이 흩어져 있어 코드 가독성이 떨어져보인다.

이러한 부분은 더 많은 overlay 컴포넌트를 관리해야할 때 더욱 문제가 되게 된다.

overlay kit은 해당 문제들을 열고닫는 동작을 선언적으로 관리함으로서 해결한다. 아래는 overlay kit을 이용해 같은 요구사항을 구현한 예시이다.

function DemoWithEsOverlay() {
  return (
    <div>
      <p>Demo with overlay-kit</p>
      <button
        onClick={() => {
          overlay.open(({ isOpen, close, unmount }) => {
            return (
              <Modal isOpen={isOpen} onExit={unmount}>
                <div
                  style={{
                    display: "flex",
                    flexDirection: "column",
                    alignItems: "center",
                    justifyContent: "center",
                  }}
                >
                  <p>MODAL CONTENT</p>
                  <button onClick={close}>close modal</button>
                </div>
              </Modal>
            )
          })
        }}
      >
        open modal
      </button>
    </div>
  )
}

앞선 예제와는 다르게 상태를 별도로 선언하지 않아도 되고, 상태의 선언과, 변경, 사용하는 곳이 하나로 관리되기 때문에 코드 가독성이 좋아진다.

이제 해당 패키지의 내부 구현을 살펴보면서 어떻게 이러한 기능을 구현되어있는지 알아보자.

패키지 분석하기

overlay kit 패키지를 다운받아서 내부 구조를 보게 되면 아래와 같은 구조를 확인할 수 있다.

overlay kit 패키지 구조

생각보다 굉장히 간단하게 구성되어있는 것을 볼 수 있는데 하나하나 한번 살펴보자.

package.json

가장 먼저 package.json보면 다음과 같은 내용이 있다.

{
  // ...
  "dependencies": {
    "use-sync-external-store": "^1.2.2"
  },
  // ...
  "peerDependencies": {
    "react": "^16.8.0 || ^17.0.0 || ^18.0.0",
    "react-dom": "^16.8.0 || ^17.0.0 || ^18.0.0"
  }
}

공식문서를 보면 react 16.8 버전부터 지원하고 있으며, 18버전부터 추가된 useSyncExternalStore를 지원하기 위해서 별도의 dependency로 추가하고 있는 것으로 볼 수 있다.

overlay kit 지원버전

useSyncExternalStore는 react 18에서 추가된 hook으로 javascript로 구현된 외부 상태를 구독할 수 있도록 도와주는 hook으로 제품을 개발할 때 사용하기 보다 JS 변수의 변화를 리액트의 렌더링으로 연결할 때, 특히 상태관리 라이브러리에서 내부적으로 사용되고 있다.

// zustand의 useStore 구현부
export function useStore<TState, StateSlice>(
  api: ReadonlyStoreApi<TState>,
  selector: (state: TState) => StateSlice = identity as any,
) {
  const slice = React.useSyncExternalStore(
    api.subscribe,
    () => selector(api.getState()),
    () => selector(api.getInitialState()),
  )
  return slice
}

useSyncExternalStore의 내부 구현을 살펴보면 다음과 같다.

// useSyncExternalStore 내부 구현
import * as React from "react"
import is from "shared/objectIs"

const { useState, useEffect, useLayoutEffect } = React

export function useSyncExternalStore<T>(
  subscribe: (() => void) => () => void,
  getSnapshot: () => T,
  getServerSnapshot?: () => T
): T {
  const value = getSnapshot()
  const [{ inst }, forceUpdate] = useState({ inst: { value, getSnapshot } })

  useLayoutEffect(() => {
    inst.value = value
    inst.getSnapshot = getSnapshot

    if (checkIfSnapshotChanged(inst)) {
      forceUpdate({ inst })
    }
  }, [subscribe, value, getSnapshot])

  useEffect(() => {
    if (checkIfSnapshotChanged(inst)) {
      forceUpdate({ inst })
    }
    const handleStoreChange = () => {
      if (checkIfSnapshotChanged(inst)) {
        forceUpdate({ inst })
      }
    }
    return subscribe(handleStoreChange)
  }, [subscribe])

  return value
}

function checkIfSnapshotChanged<T>(inst: {
  value: T,
  getSnapshot: () => T,
}): boolean {
  const latestGetSnapshot = inst.getSnapshot
  const prevValue = inst.value
  try {
    const nextValue = latestGetSnapshot()
    return !is(prevValue, nextValue)
  } catch (error) {
    return true
  }
}

useSyncExternalStore의 내부 구현을 분석해보면 getSnapshot 함수를 통해 외부 상태의 현재 값을 읽어오고 subscribe 함수를 통해 외부 상태의 변경을 구독하며, 외부 상태가 변경될 때마다 getSnapshot의 반환값을 이전 값과 비교하여 값이 변경되었다면 컴포넌트를 리렌더링하는 방식으로 동작한다.

리액트에서 리렌더링을 발생시키기 위해서는 상태가 변경되어야 하기 때문에, 외부 상태의 변경을 구독하여 외부 상태가 변경될 때마다 컴포넌트를 리렌더링하는 방식으로 리액트와 javascript 상태가 연결되는 것을 알 수 있다.

그러면 overlay kit에서는 어떻게 사용되고 있는지 살펴보자.

store.ts

store.ts 파일을 살펴보면 다음과 같은 내용이 있다.

import { type OverlayControllerComponent } from "./provider"
import { type OverlayReducerAction, overlayReducer } from "./reducer"

type OverlayId = string

export type OverlayItem = {
  id: OverlayId
  isOpen: boolean
  controller: OverlayControllerComponent
}

export type OverlayData = {
  current: OverlayId | null
  overlayOrderList: OverlayId[]
  overlayData: Record<OverlayId, OverlayItem>
}

let overlays: OverlayData = {
  current: null,
  overlayOrderList: [],
  overlayData: {},
}

let listeners: Array<() => void> = []

function emitChangeListener() {
  for (const listener of listeners) {
    listener()
  }
}

export function dispatchOverlay(action: OverlayReducerAction) {
  overlays = overlayReducer(overlays, action)
  emitChangeListener()
}

export const registerOverlaysStore = {
  subscribe(listener: () => void) {
    listeners = [...listeners, listener]

    return () => {
      listeners = listeners.filter(l => l !== listener)
    }
  },
  getSnapshot() {
    return overlays
  },
}

OverlayItem과 OverlayData 인터페이스

type OverlayId = string

export type OverlayItem = {
  id: OverlayId
  isOpen: boolean
  controller: OverlayControllerComponent
}

export type OverlayData = {
  current: OverlayId | null
  overlayOrderList: OverlayId[]
  overlayData: Record<OverlayId, OverlayItem>
}

OverlayItem은 id, isOpen, controller로 구성된다.

id: overlay 식별자
isOpen: overlay 열림/닫힘 상태
controller: overlay로 보여줄 컴포넌트

OverlayData는 current, overlayOrderList, overlayData로 구성된다.

current: 현재 상위 노출되는 overlay id
overlayOrderList: 현재 메모리에 등록된 오버레이 목록
overlayData: id를 키로 사용하는 각 오버레이의 상세 데이터

이러한 데이터 구조를 통해 오버레이 상태를 관리하고 있는 것을 알 수 있다.

overlay 상태관리

사용처에서 노출되지 않던 overlay 상태관리는 아래와 같이 구현되어있다.

let overlays: OverlayData = {
  current: null,
  overlayOrderList: [],
  overlayData: {},
}
let listeners: Array<() => void> = []

function emitChangeListener() {
  for (const listener of listeners) {
    listener()
  }
}

export function dispatchOverlay(action: OverlayReducerAction) {
  overlays = overlayReducer(overlays, action)
  emitChangeListener()
}

export const registerOverlaysStore = {
  subscribe(listener: () => void) {
    listeners = [...listeners, listener]

    return () => {
      listeners = listeners.filter(l => l !== listener)
    }
  },
  getSnapshot() {
    return overlays
  },
}

상태는 overlays 변수를 통해 관리되고 있고, 변수의 변경사항의 현재 값을 반환하는 getSnapshot 함수를 통해 현재 상태를 조회하고 달라질 때마다 useSyncExternalStore를 통해 리렌더링이 일어나게 된다.

listeners 변수에는 상태가 변경될 때마다 실행할 콜백 함수를 보관하는 배열로, 앞서 설명한 useSyncExternalStore 내부 구현의 useEffect에서 forceUpdate를 통해 리렌더링시키는 함수가 해당 배열에 추가된다.

이후에 dispatchOverlay를 통해 등록된 콜백함수가 실행되면서 reducer를 통해 overlays 변수의 값이 변경되면(checkIfSnapshotChanged가 true) 이에 따라 리렌더링이 발생하게 된다.

// useSyncExternalStore 내부 구현의 useEffect 일부
useEffect(() => {
  if (checkIfSnapshotChanged(inst)) {
    forceUpdate({ inst })
  }
  const handleStoreChange = () => {
    if (checkIfSnapshotChanged(inst)) {
      forceUpdate({ inst })
    }
  }
  return subscribe(handleStoreChange)
}, [subscribe])

useSyncOverlayStore와 OverlayProvider

이제 위에서 정의한 registerOverlaysStore를 통해 오버레이 상태를 관리하는 useSyncOverlayStore와 오버레이 컴포넌트를 렌더링하는 OverlayProvider를 살펴보자.

// useSyncOverlayStore
import { useSyncExternalStore } from "use-sync-external-store/shim/index.js"
import { registerOverlaysStore } from "./store"

export function useSyncOverlayStore() {
  const { subscribe, getSnapshot } = registerOverlaysStore
  return useSyncExternalStore(subscribe, getSnapshot, getSnapshot)
}

// OverlayProvider
import { type FC, useEffect, useRef, type PropsWithChildren } from "react"
import { OverlayContextProvider } from "./context"
import { dispatchOverlay } from "./store"
import { useSyncOverlayStore } from "./use-sync-overlay-store"
import { overlay } from "../event"

export function OverlayProvider({ children }: PropsWithChildren) {
  const overlayState = useSyncOverlayStore()

  useEffect(() => {
    return () => {
      dispatchOverlay({ type: "REMOVE_ALL" })
    }
  }, [])

  return (
    <OverlayContextProvider value={overlayState}>
      {children}
      {overlayState.overlayOrderList.map(item => {
        const {
          id: currentOverlayId,
          isOpen,
          controller: currentController,
        } = overlayState.overlayData[item]

        return (
          <ContentOverlayController
            key={currentOverlayId}
            isOpen={isOpen}
            current={overlayState.current}
            overlayId={currentOverlayId}
            onMounted={() => {
              requestAnimationFrame(() => {
                dispatchOverlay({ type: "OPEN", overlayId: currentOverlayId })
              })
            }}
            onCloseModal={() => overlay.close(currentOverlayId)}
            onExitModal={() => overlay.unmount(currentOverlayId)}
            controller={currentController}
          />
        )
      })}
    </OverlayContextProvider>
  )
}

type OverlayControllerProps = {
  overlayId: string
  isOpen: boolean
  close: () => void
  unmount: () => void
}

type OverlayAsyncControllerProps<T> = Omit<OverlayControllerProps, "close"> & {
  close: (param: T) => void
}

export type OverlayControllerComponent = FC<OverlayControllerProps>
export type OverlayAsyncControllerComponent<T> = FC<
  OverlayAsyncControllerProps<T>
>

type ContentOverlayControllerProps = {
  isOpen: boolean
  current: string | null
  overlayId: string
  onMounted: () => void
  onCloseModal: () => void
  onExitModal: () => void
  controller: OverlayControllerComponent
}

function ContentOverlayController({
  isOpen,
  current,
  overlayId,
  onMounted,
  onCloseModal,
  onExitModal,
  controller: Controller,
}: ContentOverlayControllerProps) {
  const prevCurrent = useRef(current)
  const onMountedRef = useRef(onMounted)

  /**
   * @description Executes when closing and reopening an overlay without unmounting.
   */
  if (prevCurrent.current !== current) {
    prevCurrent.current = current

    if (current === overlayId) {
      onMountedRef.current()
    }
  }

  useEffect(() => {
    onMountedRef.current()
  }, [])

  return (
    <Controller
      overlayId={overlayId}
      isOpen={isOpen}
      close={onCloseModal}
      unmount={onExitModal}
    />
  )
}

useSyncOverlayStore는 registerOverlaysStore를 구독하고 현재 상태를 반환하는 함수로, 이를 통해 오버레이 상태를 구독할 수 있다.

import { useSyncExternalStore } from "use-sync-external-store/shim/index.js"
import { registerOverlaysStore } from "./store"

export function useSyncOverlayStore() {
  const { subscribe, getSnapshot } = registerOverlaysStore
  return useSyncExternalStore(subscribe, getSnapshot, getSnapshot)
}

이렇게 만들어진 useSyncOverlayStore는 OverlayProvider에서 사용되어 오버레이 상태를 구독하고 있는 것을 볼 수 있다.

OverlayProvider는 오버레이 상태를 구독하고 있는 useSyncOverlayStore를 통해 현재 상태를 읽어와 오버레이 컴포넌트를 렌더링하는 역할을 한다. 내부 코드를 보면 unMount 또는 리렌더링이 일어날때 기존 오버레이들을 닫는 action을 발생시키고, 오버레이 목록을 순회하며 오버레이 컴포넌트를 렌더링하는데 children으로 전달받은 컴포넌트 밑에 렌더링함으로서 기존 페이지 컴포넌트 상위에 그려질 수 있게 한다.

export function OverlayProvider({ children }: PropsWithChildren) {
  const overlayState = useSyncOverlayStore()

  useEffect(() => {
    return () => {
      dispatchOverlay({ type: "REMOVE_ALL" })
    }
  }, [])

  return (
    <OverlayContextProvider value={overlayState}>
      {children}
      {overlayState.overlayOrderList.map(item => {
        const {
          id: currentOverlayId,
          isOpen,
          controller: currentController,
        } = overlayState.overlayData[item]

        return (
          <ContentOverlayController
            key={currentOverlayId}
            isOpen={isOpen}
            current={overlayState.current}
            overlayId={currentOverlayId}
            onMounted={() => {
              requestAnimationFrame(() => {
                dispatchOverlay({ type: "OPEN", overlayId: currentOverlayId })
              })
            }}
            onCloseModal={() => overlay.close(currentOverlayId)}
            onExitModal={() => overlay.unmount(currentOverlayId)}
            controller={currentController}
          />
        )
      })}
    </OverlayContextProvider>
  )
}

ContentOverlayController는 overlay 상태에 있는 오버레이 컴포넌트를 주입받아 렌더링하는데 오버레이 컴포넌트로 정의된 인터페이스의 isOpen, close, unmount를 overlayState에서 prop으로 전달받아 사용하게 된다.

내부적으로 onMounted, onCloseModal, onExitModal로 정의된 이벤트 액션을 오버레이 컴포넌트에 전달하는 것을 볼 수 있다.

이때 onMounted에는 requestAnimationFrame을 open 이벤트를 발생시키는데, 컴포넌트 내부에서는 ref를 활용해 불필요한 렌더링을 방지하면서 해당 이벤트를 처리하고 있다. requestAnimationFrame을 이용하기 때문에 브라우저의 렌더링 타이밍에 맞춰 최적화된 시점에 실행되게 구현되어 있다.

추가적으로 OverlayAsyncControllerProps를 정의해 비동기로 처리할 수 있도록 하고 있다.

type OverlayControllerProps = {
  overlayId: string
  isOpen: boolean
  close: () => void
  unmount: () => void
}

type OverlayAsyncControllerProps<T> = Omit<OverlayControllerProps, "close"> & {
  close: (param: T) => void
}

export type OverlayControllerComponent = FC<OverlayControllerProps>
export type OverlayAsyncControllerComponent<T> = FC<
  OverlayAsyncControllerProps<T>
>

type ContentOverlayControllerProps = {
  isOpen: boolean
  current: string | null
  overlayId: string
  onMounted: () => void
  onCloseModal: () => void
  onExitModal: () => void
  controller: OverlayControllerComponent
}

function ContentOverlayController({
  isOpen,
  current,
  overlayId,
  onMounted,
  onCloseModal,
  onExitModal,
  controller: Controller,
}: ContentOverlayControllerProps) {
  const prevCurrent = useRef(current)
  const onMountedRef = useRef(onMounted)

  /**
   * @description Executes when closing and reopening an overlay without unmounting.
   */
  if (prevCurrent.current !== current) {
    prevCurrent.current = current

    if (current === overlayId) {
      onMountedRef.current()
    }
  }

  useEffect(() => {
    onMountedRef.current()
  }, [])

  return (
    <Controller
      overlayId={overlayId}
      isOpen={isOpen}
      close={onCloseModal}
      unmount={onExitModal}
    />
  )
}

그러면 ContentOverlayController에 전달하는 이벤트들과 액션들에 대해 알아보자.

Reducer와 Event

위 섹션에서 정리한 ContentOverlayController에 전달하던 액션들은 event.ts에 정의되어있다.

앞서 useSyncStore로 연결한 이벤트를 모두 실행시키는 dispatchOverlay 함수를 통해서 open, close, unmount, closeAll, unmountAll, openAsync 함수들이 정의되어있다.

dispatchOverlay 함수 내부에는 현재상태인 overlays와 액션을 받아 reducer를 통해 overlays 변수의 값을 변경하고, 변경된 값을 반환하고 변경된 상태를 구독하는 리스너들에게 알리는 emitChangeListener 함수를 호출하는 것을 볼 수 있다.

export function dispatchOverlay(action: OverlayReducerAction) {
  overlays = overlayReducer(overlays, action)
  emitChangeListener()
}

Reducer.ts

reducer를 보게되면 전달받은 상태와 액션에 따라 상태를 변경해 반환하는 것을 볼 수 있다. 이러한 패턴은 Redux에서 자주보는 Flux 패턴을 따르고 있는 것을 볼 수 있다.

import { type OverlayData, type OverlayItem } from './store';

export type OverlayReducerAction =
  | { type: 'ADD'; overlay: OverlayItem }
  | { type: 'OPEN'; overlayId: string }
  | { type: 'CLOSE'; overlayId: string }
  | { type: 'REMOVE'; overlayId: string }
  | { type: 'CLOSE_ALL' }
  | { type: 'REMOVE_ALL' };

export function overlayReducer(state: OverlayData, action: OverlayReducerAction): OverlayData {
  switch (action.type) {
    case 'ADD': {
      const isExisted = state.overlayOrderList.includes(action.overlay.id);

      if (isExisted && state.overlayData[action.overlay.id].isOpen === true) {
        throw new Error("You can't open the multiple overlays with the same overlayId. Please set a different id.");
      }

      return {
        current: action.overlay.id,
        overlayOrderList: [...state.overlayOrderList.filter((item) => item !== action.overlay.id), action.overlay.id],
        overlayData: isExisted
          ? state.overlayData
          : {
              ...state.overlayData,
              [action.overlay.id]: action.overlay,
            },
      };
    }
    case 'OPEN': {
      return {
        ...state,
        overlayData: {
          ...state.overlayData,
          [action.overlayId]: {
            ...state.overlayData[action.overlayId],
            isOpen: true,
          },
        },
      };
    }
    case 'CLOSE': {
      const openedOverlayOrderList = state.overlayOrderList.filter(
        (orderedOverlayId) => state.overlayData[orderedOverlayId].isOpen === true
      );
      const targetIndexInOpenedList = openedOverlayOrderList.findIndex((item) => item === action.overlayId);

      const currentOverlayId =
        targetIndexInOpenedList === openedOverlayOrderList.length - 1
          ? openedOverlayOrderList[targetIndexInOpenedList - 1] ?? null
          : openedOverlayOrderList.at(-1) ?? null;

      return {
        ...state,
        current: currentOverlayId,
        overlayData: {
          ...state.overlayData,
          [action.overlayId]: {
            ...state.overlayData[action.overlayId],
            isOpen: false,
          },
        },
      };
    }
    case 'REMOVE': {
      const remainingOverlays = state.overlayOrderList.filter((item) => item !== action.overlayId);
      if (state.overlayOrderList.length === remainingOverlays.length) {
        return state;
      }

      const copiedOverlayData = { ...state.overlayData };
      delete copiedOverlayData[action.overlayId];

      const current = state.current
        ? remainingOverlays.includes(state.current)
          ? state.current
          : null

      return {
        current,
        overlayOrderList: remainingOverlays,
        overlayData: copiedOverlayData,
      };
    }
    case 'CLOSE_ALL': {
      return {
        ...state,
        overlayData: Object.keys(state.overlayData).reduce(
          (prev, curr) => ({
            ...prev,
            [curr]: {
              ...state.overlayData[curr],
              isOpen: false,
            } satisfies OverlayItem,
          }),
          {} satisfies Record<string, OverlayItem>
        ),
      };
    }
    case 'REMOVE_ALL': {
      return { current: null, overlayOrderList: [], overlayData: {} };
    }
  }
}

Event.ts

reducer에 전달한 action들을 직접 전달하는 이벤트 함수들은 event.ts에 정의되어있다. 내부적으로 dispatchOverlay를 통해 reducer에 전달하는 것을 볼 수 있다.

import { type OverlayAsyncControllerComponent, type OverlayControllerComponent } from './context/provider';
import { dispatchOverlay } from './context/store';
import { randomId } from './utils';

type OpenOverlayOptions = {
  overlayId?: string;
};

function open(controller: OverlayControllerComponent, options?: OpenOverlayOptions) {
  const overlayId = options?.overlayId ?? randomId();

  dispatchOverlay({
    type: 'ADD',
    overlay: {
      id: overlayId,
      isOpen: false,
      controller: controller,
    },
  });

  return overlayId;
}

async function openAsync<T>(controller: OverlayAsyncControllerComponent<T>, options?: OpenOverlayOptions) {
  return new Promise<T>((resolve) => {
    open((overlayProps, ...deprecatedLegacyContext) => {
      /**
       * @description close the overlay with resolve
       */
      const close = (param: T) => {
        resolve(param as T);
        overlayProps.close();
      };
      /**
       * @description Passing overridden methods
       */
      const props = { ...overlayProps, close };
      return controller(props, ...deprecatedLegacyContext);
    }, options);
  });
}

function close(overlayId: string) {
  dispatchOverlay({ type: 'CLOSE', overlayId });
}
function unmount(overlayId: string) {
  dispatchOverlay({ type: 'REMOVE', overlayId });
}
function closeAll() {
  dispatchOverlay({ type: 'CLOSE_ALL' });
}
function unmountAll() {
  dispatchOverlay({ type: 'REMOVE_ALL' });
}

export const overlay = { open, close, unmount, closeAll, unmountAll, openAsync }

더 알아보기 섹션 이해해보기

공식문서의 더 알아보기 섹션에는 4가지 추가 사용법을 제공하고 있다. 각각에 대해 앞서 봤던 동작원리를 이용해서 이해해보자.

1. React 바깥에서 열기

Overlay kit은 react 외부에서도 overlay를 열 수 있다.

import ky from "ky"
import { overlay } from "overlay-kit"

const api = ky.extend({
  hooks: {
    afterResponse: [
      (_, __, response) => {
        if (response.status >= 400) {
          overlay.open(({ isOpen, close }) => (
            <ErrorDialog open={isOpen} onClose={close} />
          ))
        }
      },
    ],
  },
})

이러한 구조가 가능한 이유는 overlay.open 메소드는 내부적으로 dispatchOverlay를 통해 reducer에 렌더링할 컴포넌트와 함께 액션으로 전달하고 있기 때문이다.

function open(
  controller: OverlayControllerComponent,
  options?: OpenOverlayOptions
) {
  const overlayId = options?.overlayId ?? randomId()

  dispatchOverlay({
    type: "ADD",
    overlay: {
      id: overlayId,
      isOpen: false,
      controller: controller,
    },
  })

  return overlayId
}

이후에 렌더링 되는 곳은 OverlayProvider 내부에서 정의된 controller에 전달되기 때문에 react 외부에서도 동일하게 사용할 수 있다.

export function OverlayProvider({ children }: PropsWithChildren) {
  const overlayState = useSyncOverlayStore()

  useEffect(() => {
    return () => {
      dispatchOverlay({ type: "REMOVE_ALL" })
    }
  }, [])

  return (
    <OverlayContextProvider value={overlayState}>
      {children}
      {overlayState.overlayOrderList.map(item => {
        // 오버레이 컴포넌트 렌더링
      })}
    </OverlayContextProvider>
  )
}

2. Custom ID 지정하기

overlayId를 직접 지정해서 전달할 수 있다.

function Demo() {
  const openDialog = () => {
    overlay.open(
      ({ isOpen, close, unmount }) => {
        return <Dialog open={isOpen} onClose={close} onExit={unmount} />
      },
      { overlayId: "customId" }
    )
  }

  return <Button onClick={openDialog}>Open dialog</Button>
}

직접 id를 지정할 수 있는 것은 open 메소드에 전달하는 옵션에 있는 overlayId 속성을 전달하고 있고 없을 경우에는 randomId 함수를 통해 랜덤한 id를 생성하고 있다.

const overlayId = options?.overlayId ?? randomId()

이렇게 정해진 id는 reducer에서 처리되는 OPEN 액션에 전달되어 오버레이 데이터에 저장된다.

//...
case 'OPEN': {
      return {
        ...state,
        overlayData: {
          ...state.overlayData,
          [action.overlayId]: {
            ...state.overlayData[action.overlayId],
            isOpen: true,
          },
        },
      };
    }

3. Promise와 함께 사용하기

overlay kit은 비동기 처리를 위해 promise와 함께 사용할 수 있다.

const result = await new Promise<boolean>(resolve => {
  overlay.open(({ isOpen, close }) => {
    return (
      <Dialog open={isOpen} onClose={() => close(false)}>
        <DialogTitle>계속 진행하시겠어요?</DialogTitle>
        <DialogActions>
          <Button
            onClick={() => {
              resolve(true)
              close()
            }}
          >
            네
          </Button>
          <Button
            onClick={() => {
              resolve(false)
              close()
            }}
          >
            아니요
          </Button>
        </DialogActions>
      </Dialog>
    )
  })
})

if (result) {
  // 사용자가 "네"를 눌렀을 때의 처리
} else {
  // 사용자가 "아니요"를 눌렀을 때의 처리
}

그이유도 1번과 동일하게 open 메소드가 실행되면서 데이터가 저장되고, 이후에 렌더링 되는 곳은 OverlayProvider 내부에서 정의된 controller에 전달되기 때문이다.

promise를 사용할 때 주의할점은 꼭 resolve를 해줘야한다는 점인데, resolve를 하지 않으면 await에서 무한정 대기하게 되어 다음 코드로 진행할 수 없다. 추가로 promise가 메모리에서 해제되지 않아 메모리 누수가 발생할 수 있다.

직접 promise에서 감싸는 방식 대신 openAsync 메소드를 사용하는 방법도 있다.

const result = await overlay.openAsync<boolean>(({ isOpen, close }) => {
  const agree = () => close(true)
  const cancel = () => close(false)

  return (
    <Dialog open={isOpen} onClose={cancel}>
      <DialogTitle>계속 진행하시겠어요?</DialogTitle>
      <DialogActions>
        <Button onClick={agree}>네</Button>
        <Button onClick={cancel}>아니요</Button>
      </DialogActions>
    </Dialog>
  )
})

if (result) {
  // 사용자가 "네"를 눌렀을 때의 처리
} else {
  // 사용자가 "아니요"를 눌렀을 때의 처리
}

openAsync 메소드는 자체적으로 close 메소드 내부에서 resolve를 호출하기 때문에 따로 resolve를 호출해줄 필요가 없어 실수를 줄일 수 있다.

async function openAsync<T>(
  controller: OverlayAsyncControllerComponent<T>,
  options?: OpenOverlayOptions
) {
  return new Promise<T>((resolve) => {
    open((overlayProps, ...deprecatedLegacyContext) => {
      /**
       * @description close the overlay with resolve
       */
      const close = (param: T) => {
        resolve(param as T);
        overlayProps.close();
      };
      /**
       * @description Passing overridden methods
       */
      const props = { ...overlayProps, close };
      return controller(props, ...deprecatedLegacyContext);
    }, options);
  });
}

4. 오버레이 애니메이션과 Unmount 처리

overlay kit에서 close는 오버레이의 애니메이션을 위해서 메모리에서 완전히 제거하지 않고 렌더링만 제외시키는 역할을 한다. 이러한 이유로 오버레이 컴포넌트에서 unmount 메소드를 이용해야 메모리에서 완전히 제거할 수 있다.

function Demo() {
  const openDialog = () => {
    overlay.open(({ isOpen, close, unmount }) => (
      <Dialog open={isOpen} onClose={close} onExit={unmount} />
    ))
  }
}

실제 reducer와 이벤트 함수들을 보면 실제로 해당 데이터를 지우는 것은 REMOVE 액션이다.

// event.ts
function close(overlayId: string) {
  dispatchOverlay({ type: "CLOSE", overlayId })
}
function unmount(overlayId: string) {
  dispatchOverlay({ type: "REMOVE", overlayId })
}

// reducer.ts
//...
    case 'CLOSE': {
      const openedOverlayOrderList = state.overlayOrderList.filter(
        (orderedOverlayId) => state.overlayData[orderedOverlayId].isOpen === true
      );
      const targetIndexInOpenedList = openedOverlayOrderList.findIndex((item) => item === action.overlayId);

      const currentOverlayId =
        targetIndexInOpenedList === openedOverlayOrderList.length - 1
          ? openedOverlayOrderList[targetIndexInOpenedList - 1] ?? null
          : openedOverlayOrderList.at(-1) ?? null;

      return {
        ...state,
        current: currentOverlayId,
        overlayData: {
          ...state.overlayData,
          [action.overlayId]: {
            ...state.overlayData[action.overlayId],
            isOpen: false,
          },
        },
      };
    }
    case 'REMOVE': {
      const remainingOverlays = state.overlayOrderList.filter((item) => item !== action.overlayId);
      if (state.overlayOrderList.length === remainingOverlays.length) {
        return state;
      }

      const copiedOverlayData = { ...state.overlayData };
      delete copiedOverlayData[action.overlayId];

      const current = state.current
        ? remainingOverlays.includes(state.current)
          ? state.current
          : remainingOverlays.at(-1) ?? null
        : null;

      return {
        current,
        overlayOrderList: remainingOverlays,
        overlayData: copiedOverlayData,
      };
    }

마치며

선언적으로 관리하는 overlay kit의 장점과 내부 구조를 살펴보았다.

이 과정을 통해서 react와 javascript가 어떻게 연결될 수 있는지 살펴볼 수 있었고, 선언적으로 관리하기 위해서 어떠한 방식으로 코드가 작성되어있는지 이해할 수 있었다.

코드를 볼 수록 토스 팀의 노력과 생각을 이해할 수 있었고, 단순히 이용하는 것이 아니라 앞으로 동료로서 더 발전시키는데 기여하고 싶다는 생각이 들었다.

패키지 매니저 비교해보기

Mon, 18 Nov 2024 00:00:00 GMT

토스에 입사한 후 프론트엔드의 다양한 기술 주제에 대해 새롭게 알게 되면서 하나씩 정리해보고자 한다.

이번 주제는 패키지 매니저로 평소 잘 몰랐던 주제라 흥미롭게 생각해 각각의 특징과 장단점 등에 대해 정리해보려한다.

이미 토스 블로그와 다른 블로그들에 잘 정리된 글이 있기 때문에 해당 글들을 참고하여 작성하였다.

node_modules로부터 우리를 구원해 줄 Yarn Berry

패키지 매니저의 과거, 토스의 선택, 그리고 미래

패키지 매니저란?

패키지 매니저는 NPM, YARN과 같이 외부 모듈을 관리할 때 사용하는 도구로 의존성을 관리하고, 패키지를 설치, 업데이트, 제거하기 위한 도구이다.

만약 패키지 매니저가 없이 외부 모듈을 사용하려면 어떻게 해야할지 생각해보자.

패키지 매니저가 없다면 내가 원하는 라이브러리 코드를 프로젝트에서 사용하기 위해서, 특정 폴더에 해당 코드를 직접 복사해서 붙여넣어야 한다.
그리고 붙여넣은 위치에 맞게 라이브러리를 가져올 수 있게 경로를 관리해야 한다.
그리고 어느 시점의 라이브러리를 다운받냐에 따라 사용하고 있는지에 따라 코드가 달라지니까 어떤 버전의 라이브러리를 복사 붙여넣기 했는지 기록해야할 것 같다.
마지막으로 패키지 자체가 안전한지 확인하는 과정도 필요할 것 같다.

방금 말한 패키지 매니저가 없을 때 해야할 과정 4가지 과정은 결국 우리를 위해 패키지 매니저가 담당해주고 있는 일로 볼 수 있다.

결국 한마디로는 패키지 매니저는 외부 모듈을 프로젝트에 쉽게 설치하고 관리할 수 있게 도와주는 도구라고 할 수 있다.

패키지 매니저가 동작하는 방식

패키지가 동작하는 방식을 알아보면 세가지 스텝으로 진행된다.

Resolution
Fetching
Linking

각 스텝에 대해 알아보자.

Resolution

Resolution은 package.json에 기록된 의존성 정보를 읽고 해당하는 버전 범위를 체크하는 과정이다.

예를 들어 package.json에 react 패키지가 ^18.0.0 버전으로 기록되어 있다면, Resolution 과정에서는 react 패키지의 버전이 18.0.0 이상이면서 최대한 최신 버전인 18.99.99 버전을 이용할 수 있구나하고 사용가능한 버전을 체크하는 과정이다.

이때 의존성의 의존성의 버전도 체크하는 과정을 거쳐서 각 의존성들의 버전을 고정시켜서 최종적으로 사용할 수 있는 버전을 찾는 과정이다.

Fetching

Fetching은 체크된 버전의 패키지를 다운받는 과정으로 로컬 캐시가 있는지 확인하고 없다면 원격 저장소에서 패키지를 다운받는 과정이다.

Linking

Linking은 다운받은 패키지를 프로젝트에 연결하는 과정으로 패키지를 사용할 수 있도록 프로젝트에 연결하는 과정이다. npm과 yarn은 node_modules 폴더에 패키지를 설치하고 각 매니저별로 최적화된 방식으로 패키지를 연결한다.

패키지 매니저 비교하기

패키지 매니저의 역할을 알아보았으니 이제 각 패키지 매니저에 대해 알아보자. 알아볼 패키지매니저는 NPM, Yarn, Pnpm, Yarn Berry이다.

NPM

NPM은 Node Package Manager의 약자로, 가장 역사가 오래된 Node.js 패키지 매니저다.

편한 CLI 명령어를 제공하고 NPM 공식사이트를 통해서 패키지를 검색할 수 있다.

npm

위에서 소개된 Linking 과정에서 NPM은 정해진 의존성 트리를 기반으로 node_modules 폴더에 패키지를 설치하고 연결하는 과정을 거친다.

npm-project/
└─ node_modules/
| ├─ a/
| |
| └─ b/
|    └─ node_modules/
|        └─ c
|
└─ src
└─ index.ts

node_modules...

이렇게 거대해진 node_modules 폴더는 프로젝트 크기가 커질수록 CI/CD 과정에서 오래걸리게 되고 시간 뿐 아니라, 큰 용량을 차지하게 된다.

Ghost Dependencies

이렇게 커진 node_modules 폴더를 최적화하기 위해서 hoisting이라는 기법을 이용하지만, 이러한 최적화 방식은 오히려 사용하려고 하지 않았던 패키지를 설치하거나 삭제될 수 있는 Ghost Dependencies 문제가 발생하게 된다.

Ghost Dependencies

Ghost Dependencies를 이해하기 위해 간단한 예제를 만들어 보았다.

먼저 간단히 가장 기본이 되는 패키지 @choi2021/ghost-dep-test-package-a를 만들어보았다. 해당 패키지는 정말 간단한 sum이라는 함수를 반환한다.

function sum(a, b) {
  return a + b
}

module.exports = {
  sum,
}

이제 두번째 패키지 @choi2021/ghost-dep-test-package-b를 만들어보자. 해당 패키지는 앞서 만든 @choi2021/ghost-dep-test-package-a를 의존성으로 가지고 있다.

// package.json
{
  "name": "@choi2021/ghost-dep-test-package-a",
  "version": "1.0.0",
  "main": "index.js"
}

// index.js
const { sum } = require("@choi2021/ghost-dep-test-package-a")

function sumAndMultiply(a, b, c) {
  return sum(a, b) * c
}

module.exports = {
  sumAndMultiply,
}

이제는 실제로 npm-example이라는 프로젝트에 @choi2021/ghost-dep-test-package-b를 설치해보자.

{
  "name": "npm-example",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "description": "",
  "type": "module",
  "dependencies": {
    "@choi2021/ghost-dep-test-package-b": "*"
  }
}

해당 프로젝트에 npm install을 진행하면 아래와 같이 node_modules 폴더에 패키지가 설치된다.

npm-example

node_modules 폴더를 살펴보면 @choi2021/ghost-dep-test-package-b만 의존성을 가지고 있지만 @choi2021/ghost-dep-test-package-a 패키지가 설치되어 있는 것을 확인할 수 있다.

그리고 의존성 트리가 앞서 설명한 호이스팅과정을 통해서 최상위 레벨에 위치하게 된다.

여기서 문제가 되는 Ghost Dependency가 발생하게 되는데 해당 패키지가 가지는 의존성은 @choi2021/ghost-dep-test-package-b이지만, 프로젝트 내부에서 @choi2021/ghost-dep-test-package-a를 직접 사용할 수 있다.

import { sum } from "@choi2021/ghost-dep-test-package-a"

console.log(sum(1, 2))

npm-ghost-dep

이렇게 직접 의존하지 않은 패키지에 접근할 수 있게 되는 현상을 Ghost Dependency라고 하며, 이는 실제 프로젝트에서 다음과 같은 문제를 일으킬 수 있다.

의도치 않은 패키지 사용으로 인한 보안 취약점 발생
패키지 업데이트 시 예상치 못한 오류 발생
프로젝트의 의존성 관리가 불명확해짐

npm은 가장 오래된 패키지 매니저이라 커뮤니티가 크지만, 프로젝트의 규모가 커질 수록 용량을 많이 차지하고, CI/CD 과정에서 오래걸리는 단점을 가지고 있다. 이러한 단점을 극복하기 위해 Yarn이 등장하게 되었다.

Yarn

Yarn은 페이스북에서 만든 패키지 매니저로 2016년도에 작성된 페이스북 Yarn 소개 글을 보면 Yarn의 배경에 대해 알 수 있다.

당시 페이스북은 팀과 프로젝트가 커지면서 일관되지 않는 의존성, 안정성, 성능적인 이슈를 겪게 되었고 새로운 npm client로 Yarn을 만들게 되었다.

어떻게 Yarn은 이러한 문제들을 해결한걸까? 하나씩 알아보자.

일관된 의존성

NPM을 이용해 만든 node_modules 폴더는 파일 시스템 기반이다보니 여러 패키지가 얽히다 보면 일관되지 않은 트리를 만들게 되고, "내 컴퓨터에서는 되는데"라는 문제점이 발생하게 된다.

이를 개선하기 위해 Yarn은 yarn.lock 파일을 도입했다. 이 파일은 모든 패키지의 정확한 버전과 의존성 정보를 저장하여, 어느 환경에서나 동일한 버전의 패키지가 설치되도록 보장한다.

# yarn.lock 예시
react@^16.0.0:
  version "16.14.0"
  resolved "https://registry.yarnpkg.com/react/-/react-16.14.0.tgz"
  integrity sha512-...
  dependencies:
    loose-envify "^1.1.0"
    object-assign "^4.1.1"

성능

npm은 순차적인 방식으로 설치하는 반면에 Yarn은 병렬적인 방식으로 설치하기 때문에 성능적인 측면에서 더 빠르다.

명령어

명령어도 조금 더 npm에 비해 간결해져 사용하기 편하다.

npm	yarn
npm install	yarn install
npm uninstall package	yarn remove package

하지만 NPM에 비해 일부 호환성 문제가 있다는 단점이 있고, 자체 최적화 알고리즘을 진행해 node_modules를 이용하는 방식은 여전히 Ghost Dependency 문제가 발생하게 된다.

같은 예제를 Yarn 프로젝트에서 실행했을 때 상황이다.

// package.json
{
  "name": "yarn-example",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "@choi2021/ghost-dep-test-package-b": "*"
  },
  "type": "module"
}

// index.js
import { sum } from "@choi2021/ghost-dep-test-package-a"

console.log(sum(1, 2))

yarn-example

직접 의존성이 없는 패키지에 아직 접근할 수 있는 것을 확인할 수 있다.

Pnpm

pnpm(performant npm) 또한 npm의 문제점을 해결하기 위해 만들어진 패키지 매니저로 Yarn과는 다른 방식으로 해결한다.

pnpm의 공식문서의 motivation 부분을 살펴보면 기존 문제를 어떻게 해결하는지 알 수 있다.

적은 용량

npm으로 백개의 프로젝트에서 하나의 의존성을 설치해야 하는 경우 100개의 복사본이 생기게 된다. 하지만 pnpm에서는 content-addressable store라는 개념을 도입해 하나의 의존성에 대해서 하나의 복사본만 존재하게 된다.

만약 버전이 다른 의존성이 설치되어야 한다면 다른 버전만 store에 설치하게 되고 모든 파일들은 한 곳에 설치되어 hard-link 방식으로 연결되게 된다.

hard-link는 주소를 alias처럼 동일한 파일을 여러 위치에서 참조할 수 있게 하는 방식이다. 실제 파일은 하나만 존재하고, 여러 위치에서 이 파일을 직접 가리키는 참조를 만들기 때문에 용량이 적게 차지하게 된다.

pnpm-disk

빠른 설치 속도

pnpm의 설치 과정은 세가지 과정을 거친다고 한다.

Resolution: 필요한 의존성을 파악하고 스토어에 설치한다.
Directory structure calculation: npm과 동일하게 node_modules 폴더 구조를 계산한다.
Linking: 정리된 의존성들을 다운받고 스토어와 node_modules를 hard-link로 연결한다

Non-flat node_modules와 Ghost Dependencies

npm과 yarn은 모두 hoist로 인해 flat한 구조를 가지고 Ghost Dependencies 문제가 발생하지만, pnpm은 이러한 문제를 해결하기 위해 바로가기 폴더를 만드는 것과 같은 symlink 방식으로 문제를 해결한다.

pnpm-node-modules

앞선 예제를 pnpm 프로젝트에서 설치했을 때 모습이다.

pnpm-example

node_modules에는 직접 의존하는 ghost-dep-test-package-b만 존재하고, 실제로 코드에서 실행해보면 에러가 발생하는 것을 볼 수 있다.

// package.json
{
  "name": "pnpm-example",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@choi2021/ghost-dep-test-package-b": "*"
  },
  "type": "module",
}


// index.js
import { sum } from "@choi2021/ghost-dep-test-package-a"

console.log(sum(1, 2))

pnpm-error

이렇게 직접 의존하지 않은 패키지에 접근할 수 없게 되어 Ghost Dependencies 문제를 해결할 수 있게 되었다.

pnpm도 단점이 존재하는데 적은 용량과 빠른 설치 속도를 위해 추가된 store를 만드는 과정과 symlink, hard link의 오버헤드로 최초에 store를 만드는 시간이 조금 더 걸리지만 이후에는 매우 빠른 속도로 설치할 수 있다.

Yarn Berry

마지막으로 Yarn Berry에 대해 알아보자.

Yarn Berry는 yarn classic(v1)에서 조금 더 개선된 버전으로 앞서 소개한 패키지 매니저들과는 다르게 Plug'n'Play(pnp) 방식을 이용한다.

그러면 동일하게 앞서 만든 패키지를 의존하는 예제를 만들어서 어떤 점이 달라졌는지 살펴보자

적은 용량

yarn berry 세팅하기 위해서는 yarn set version berry 명령어를 먼저 실행해야 한다. 이후에는 기존 yarn 명령어를 그대로 사용할 수 있다.

yarn set version berry
yarn install

pnp방식의 큰 특징은 많은 용량을 차지하던 node_modules 폴더가 없고 대신에 .yarn/cache 폴더 내부에 패키지들이 설치되는 것이다.

yarn-pnp-example

그리고 이러한 패키지들은 각 패키지별로 하나의 zip만 가지기 때문에 훨씬 적은 용량을 차지하게 된다.

빠른 설치 속도

먼저 여러 파일을 다운받아서 복잡한 구조를 만들던 node_modules 대신 yarn.lock을 기반으로 .pnp.cjs 파일 하나만 만들면 되기 때문에 기존 패키지들에서 많은 시간을 소요하던 I/O 작업에서 많은 시간이 단축 된다.

패키지를 찾을 때도 javascript map을 이용해서 패키지의 직접 참조 주소로 바로 접근하기 때문에 훨씬 빠르게 패키지를 찾을 수 있다.

아래는 .pnp.cjs 파일의 일부를 가져온 것으로 packageRegistryData에 각 패키지 별로 어디에 위치해 있는지, 어떤 패키지에 의존하는지 등의 정보를 기록하고 있다.

패키지 관리와 Ghost Dependencies

pnp는 .pnp.cjs 파일을 이용해서 패키지를 관리하기 때문에 아래와 같은 형태로 패키지들의 위치와 의존성을 기록하고 있다.

// .pnp.cjs

const RAW_RUNTIME_STATE =
  '{\
  "packageRegistryData": [\
    [null, [\
      [null, {\
        "packageLocation": "./",\
        "packageDependencies": [\
          ["@choi2021/ghost-dep-test-package-b", "npm:1.0.0"]\
        ],\
        "linkType": "SOFT"\
      }]\
    ]],\
    ["@choi2021/ghost-dep-test-package-a", [\
      ["npm:1.0.0", {\
        "packageLocation": "./.yarn/cache/@choi2021-ghost-dep-test-package-a-npm-1.0.0-baec42f21a-2fac373eba.zip/node_modules/@choi2021/ghost-dep-test-package-a/",\
        "packageDependencies": [\
          ["@choi2021/ghost-dep-test-package-a", "npm:1.0.0"]\
        ],\
        "linkType": "HARD"\
      }]\
    ]],\
    ["@choi2021/ghost-dep-test-package-b", [\
      ["npm:1.0.0", {\
        "packageLocation": "./.yarn/cache/@choi2021-ghost-dep-test-package-b-npm-1.0.0-d8c30a1a6f-caf57e1dd9.zip/node_modules/@choi2021/ghost-dep-test-package-b/",\
        "packageDependencies": [\
          ["@choi2021/ghost-dep-test-package-b", "npm:1.0.0"],\
          ["@choi2021/ghost-dep-test-package-a", "npm:1.0.0"]\
        ],\
        "linkType": "HARD"\
      }]\
    ]],\
    ["yarn-pnp-example", [\
      ["workspace:.", {\
        "packageLocation": "./",\
        "packageDependencies": [\
          ["yarn-pnp-example", "workspace:."],\
          ["@choi2021/ghost-dep-test-package-b", "npm:1.0.0"]\
        ],\
        "linkType": "SOFT"\
      }]\
    ]]\
  ]\
}'

정확하게 어떤 패키지를 직접 의존하는지 확인할 수 있고, 이를 통해 Ghost Dependencies 문제를 해결할 수 있다. 실제로 앞서 만든 예제를 yarn berry에서 실행했을 때 모습이다.

// package.json
{
  "name": "yarn-pnp-example",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "@choi2021/ghost-dep-test-package-b": "*"
  },
  "type": "module",
  "packageManager": "yarn@4.5.1"
}

// index.js

import { sum } from "@choi2021/ghost-dep-test-package-a";

console.log(sum(1, 2));

yarn-pnp-ghost-dep

pnp 패키지 매니저에서 패키지를 찾을 수 없다는 에러를 볼 수 있다.

정리해보면 yarn berry는 PnP 방식을 이용해 기존과 달리 node_modules 폴더 없이 패키지를 관리하고, 빠른 설치 속도와 적은 용량을 가지며, 또한 Ghost Dependencies 문제를 해결할 수 있는 장점을 가지고 있다.

하지만 기존의 node_modules 기반의 패키지 매니저와 호환성 문제가 있다.

yarn berry에서는 이렇게 적은 용량으로 패키지를 관리할 수 있다보니 패키지 자체를 git의 버전 관리 대상에 포함시키는 zero-install으로도 이용하는 경우도 많다.

git clone 과정에서 모든 패키지가 함께 설치되다보니 별도의 Install 과정이 필요 없어 새로 프로젝트를 다운받을 때나, CI과정에서 시간을 아껴줄 수 있는 장점이 있다.

토스는 기존에 이러한 장점으로 zero-install을 도입했지만, 현재는 PnP를 이용하더라도 레포 크기가 커져서 zero install을 끈 상태라고 한다.

마치며

RN 개발자에서 프론트엔드 개발자로 전향하면서 보다 javascript 생태계에 대해 조금 더 관심을 갖고 바라보고 있게 되었다. 그중에서 패키지 매니저는 크게 신경쓰지 않았던 부분이었지만 토스에 합류해 메이트 분과 이야기를 나누면서 이전 회사에서는 어떤 패키지 매니저 환경에서 작업을 했는지 질문을 받게 되었다.

토스 기술 블로그들에도 몇번 본적이 있었고, 프론트엔드 개발자로서 이런부분을 알면 좋겠다는 생각이 들어 작성하게 되었다.

이제는 조금은 더 이해할 수 있게된 패키지 매니저를 통해 단순히 CLI만 사용하지 않고 의존성들이 각각 어떻게 관리되는지 어떤 장단점이 있는지 이해하고 사용할 수 있을 것 같다.

10월 회고, 숨고를 떠나며

Fri, 25 Oct 2024 00:00:00 GMT

👋 숨고를 떠나며

23년 2월에 입사해 24년 10월 18일을 마지막으로 숨고라는 제품을 만든지 1년 8개월이 지났다. 2년을 채우고 떠났으면 좋았겠지만, 좋은 기회가 오게 되어 떠나게 되었고 10월은 대부분 함께 일했던 동료분들과 함께 이야기하고 고마움을 표현하며 보내는 시간을 주로 가졌다.

9월회고에 작성했던 MMKV작업과 React Query작업은 현재까지 진행된 내용들에 대한 문서만 인수인계를 위해 작성했고, 실제 적용한 결과를 보지는 못했다.

개발자로서 첫 직장이었던 숨고를 떠나며 기억에 남는 순간들과 배웠던 부분들을 정리해보려 한다.

1. 사람은 실수한다

이직을 준비하고 내가 했던 작업들을 정리하면서, 내가 했던 실수들, 그리고 그것을 보완하기 위해서 어떤 노력을 해왔는지 돌아보았다.

숨고에서 가장 가슴을 쓸어내렸던 순간은 단연코, 작년 5월에 있었던 요청 견적서 작업이었다. 제품의 메인 비즈니스 도메인인 견적서 작성 퍼널에 딥링크를 이용해 진입했을 때 견적 발송이 되지 않는 장애가 발생했다. 당시 입사한지 3개월이 되었던 시점에 아직 모바일 플랫폼에 대한 이해도 부족해 발생했던 이슈였다.

당시 23년 5월 회고로 작성했던 글의 일부

매출에 직접적인 장애를 만들면서, 사후 회고도 진행하면서 자존감이 많이 떨어졌던 순간이었다. 개발자는 제품을 직접 만드는 사람이다보니, 제품에 대해 많은 기여를 할 수 있지만, 그만큼의 책임감을 가져야한다는 것을 깨달았던 순간이었다.

그리고 제품의 안정성에 대해 크게 관심을 가지게 되었던 계기가 되었다. 다시는 장애를 만들고 싶지 않아 '어떻게 하면 다시 이런 장애를 만들지 않을 수 있을까' 혼자 엄청나게 고민하게 되었다. 하지만 의도적으로 장애를 만드는 사람이 없듯이, 경험을 통해서 점점 설계와 좋은 코드에 대해 배우면서 놓치는 부분들이 줄여져 가겠지만 여전히 사람이라면 예상하지 못한 곳에서 발생할 수 밖에 없다고 생각이 정리 되었다.

한마디로 빈도는 줄일 수 있어도 사람은 실수할 수밖에 없다라고 정리가 되었다. 그러면 내가 해야할 노력해야할 행동은 예측하는 게 아니라 빠르게 대응하는 것이라고 생각했다.

개인적으로 공부를 해서 냄새나는 코드를 빠르게 찾는 노력은 당연히 시간을 들여서 하지만, 지금 내가 할 수 있는 노력은 빠르게 대응하기 위한 작업을 담당해 보자는 생각이 들었다.

그렇게 시작한 작업이 바로 에러 모니터링 강화, 에러바운더리 도입이었다.

당시 에러 모니터링은 필요한 부분, 중요 도메인에 한해서 로깅용도로 사용되고 있었고, 여러 에러들이 위계없이 슬랙으로 제보되면서 중요한 에러를 구분하기 어려워 빠른 대처가 어려웠다.

이를 해결하기 위해서 에러 로깅에 위계를 설정하고, 불필요한 에러 로그와 필요한 로그를 구분하고, 비어있는 catch문으로 전파되지 않는 에러가 없게 eslint 룰을 추가하는 로딩 개선 작업과 화이트스크린 에러가 발생한 상황에서도 앱을 계속해서 사용할 수 있도록 에러바운더리를 스크린 단위로 제품 전체에 적용했다.

사고 치기 싫어서(?) 진행했던 작업이었지만 제품 안정성에 대한 고민을 해볼 수 있게 되었고, 챕터 내에서 자연스럽게 담당하게 된 영역 중 하나가 되어 이후, 에러 모니터링 과정에서 어려움이 있을 때, 나에게 물어보시기도 하고 에러 모니터링 툴을 변경하는 작업에서도 POC를 담당해서 진행하는 등 긍정적인 방향으로 이어졌다.

작업을 하면서도 쉽지는 않았다. 모호할 수 있는 기준을 처음부터 세우고, 에러 바운더리라는 기술이 해결할 수 있는 문제들을 소개하고 어떤 장단점이 있는지 설명했을 때를 떠올려보면, 일이 이만큼 커질 줄은 몰랐다. 혼자서 제품 전체에 적용하면서 길어지는 작업 과정에서 지치기도 하고, 동료분들이 공감할 수 있는 작업을 하고 있는 건지 중간중간 힘들기도 했다.

레몬베이스로 받았던 동료 피드백중 일부

다행히 중간 중간 작업 과정을 계속해서 공유드렸던 것의 효과였을까, 작업에 대해 주기적으로 피드백과 좋은 방향을 함께 제시 해주셨고, 덕분에 잘 마무리할 수 있었다. 장기적인 일을 할 때 일의 범위를 적당한 단위로 끊어가는 것의 중요성도 덤으로 배워갔다.

앞으로도 아마 실수하고 싶지 않지만, 장애를 만들 수 있다. 중요한 건 일어난 일을 잘 마무리 한 후에 더 좋은 제품을 만드는 기회로 바꿔서, 더 나은 시스템과 코드를 함께 만들어 가기 위해 노력해 나가는 것이라 생각한다. 실수를 성장의 기회로 만들어 준 좋은 동료들에게 감사한 마음을 가지고 더 좋은 제품을 만들어 나가야겠다.

2. 나중에 리팩토링할 시간은 없다

작업을 하다보면 늘 시간과 퀄리티는 늘 고민하게 되는, 함께 가기 어려운 트레이드 오프인 것 같다. 현실의 문제는 늘 시간과 싸우기 때문에 시간 내 빠르게 동작하는 코드를 만들게 되는 경우가 많았고, 쌓여진 동작만 하는 코드들은, 서로 엉켜 더 이상 다음 기능을 붙일 수 없게 되고 결국 대공사가 필요해졌다.

그래 날면 된거야...

그렇다면 이전으로 돌아가서 어떻게 하면 더 좋은 결과물을 만들 수 있을까?

시간을 많이 들이면 제품의 퀄리티가 올라갈 수 있지만, 시간은 한정되어 있는 이러한 현실의 문제를 해결하기 위해 내가 선택한 방법은 틈틈이, 짬짬히 리팩토링하는 것이었다.

당시 시간이 없어서 퀄리티가 떨어졌고, 이만큼의 기능을 담당하게 될 줄 몰랐던 코드라면, 지금의 내가 계속해서 과거의 내 작업을 돌아보는 것이 맞겠다는 생각이 들었다.

그러면 지금의 작업은 늦춰지는 건 아닐까 라는 생각이 들지만, 그때보다 도메인에 적응하고, 코드베이스에 익숙해지면서 대체로 어제보다 오늘 더 좋은 코드를 작성하게 되었던 것 같다. 그리고 익숙해진 부분이 많아진 상태에서 다시 요구사항들을 바라보면 그때보다 훨씬 간단히 해결할 때도 많았다.

그리고 하드스킬을 키우기 위한 노력을 지속해 같은 기능을 만들 때 시간을 줄여 더 좋은 코드로 작성하기 위해 노력해왔다. 조금 더 좋은 패턴, 좋은 설계방법들을 보고 배우며, 나와 유사한 문제를 풀어오신 선배 개발자분들의 흔적을 열심히 쫓아갔던 것 같다.

이러한 노력들이 티나지 않는 내 나름의 양심적인 노력이라 생각하고 틈틈히 챕터업무로 진행해왔다. 하지만 동료분들은 그런 모습을 보면서 격려와 계속했으면 하는 점으로, 내가 가진 장점으로 봐주시기도 했다.

리팩토링관련 피드백 일부

앞으로도 개발자로서 좋은 코드를 만들기 위해 틈틈히, 짬짬히 리팩토링을 진행해가며 역량을 늘려 더 좋은 코드를 만들어 나가야겠다.

3. 질문하는 개발자

현업에서 일하기 전, 내가 생각했던 잘하는 개발자는 주어진 요구사항을 척척 해결하는 개인의 퍼포먼스를 잘 내는 사람이라고 생각했다. 그리고 입사 초기 "내가 얼마나 잘하는 사람인지 보여줘야 해"라는 생각에 혼자서 압박감에 시달리고 힘들어 했었고, 1년을 일할 때까지도 나보다 잘하는 동료들의 모습을 보면 "내가 다른 사람들보다 잘한다고 할 수 있는 무기가 뭘까" 고민하고 내 부족함을 부끄러워했다. 질문을 할 때 나를 판단하지 않는 동료들이였지만 혼자서 너무 부족한 질문은 아닐까 걱정하기도 했다.

내가 만든 무거운 짐들은 다행히 시간이 흐르면서 관점을 내가 아니라 잘하는 동료의 모습을 조사해보기로 바꾸면서 줄어들게 되었다.

좋은 동료분들의 모습들을 정리해보았을 때 다 달랐다. 어떤 분은 히스토리를 잘 기억하셔서 팀이 정책적으로 힘들어할 때 결정을 잘 내릴 수 있게 돕기도하고, 어떤 분은 비개발자 분들과 소통할 때 기술적인 내용을 잘 풀어서 설명해주시도 했다. 어떤 분은 자동화에 진심이어서 팀의 비효율을 개선하려 노력하셨고, 어떤 분은 설계에 관심이 많아서 잘짜여진 구조를 만드는 일을 잘하셨다.

나라는 한사람이 이 모든것을 다 잘하면 좋겠지만 현실적으로 할 수 없다는 사실을 자연스럽게 받아드리기로 했다. 대신 작업을 진행하면서 나에게 부족한 부분들이 동료가 잘하는 부분이라면 가서 적극적으로 물어보고 배우기로 했다. 모르는 것을 받아드리고, 질문하는 것이 더 빠르게 성장할 수 있는 방법이라고 생각하게 되었다.

질문하는 과정에서 자연스럽게 동료의 잘하는 부분을 나의 것으로 조금씩 만들어나갈 수 있었고, 더 좋은 제품을 위한 토론을 하면서 우리 팀에서 반복적으로 겪는 문제를 알게 되고, 당장은 중요하지 않을 수 있지만 장기적으로 필요로 하는 부분들에 대해서 제안하고 담당하며 나만의 뾰족함도 만들어 나갈 수 있었다.

현재 내가 되고 싶은 사람, 내가 생각하는 좋은 개발자는 질문하는 개발자인 것 같다. 기존 방식을 당연하지 않게 바라보고 조금 더 효율적이고 쉬운방법을 고민하고 질문을 던지는 사람, 코드리뷰 속에서 당연하게 생각했던 부분에 던져진 하나의 물음을 통해 동료가 더 깊이 고민하고 더 좋은 방법을 찾아낼 수 있게 하는 사람이다.

앞으로도 이렇게 질문하며, 계속해서 더 성장해나가길, 그리고 좋은 질문을 던지는 사람이 되어가길 바래본다.

4. 코딩은 사회적 활동이다

코딩은 컴퓨터에게 명령을 하고 원하는 결과물을 얻어나가는 과정이라고 개인과 컴퓨터간의 상호작용이라고 생각하기 쉽지만, 혼자서 작업을 진행하는 것이 아니라 동료와 함께 작업을 진행하는 사회적 활동이라는 점을 많이 배웠다.

사람은 모두 다르다. 좋아하는 것도, 잘하는 것도, 중요하게 생각하는 것도 다르다. 그리고 그러한 관심사들이 코드를 작성하는 개발자 한명, 한명에게 묻어난다.

나는 선언적인 비동기 처리에 관심이 많았고, 에러바운더리, suspense를 통해서 선언적으로 비동기 상태를 관리하는 방식을 제품에 녹여내고 싶었다.

에러 바운더리는 작업 전에 어떤 장단점이 있는지, 우리가 얻을 수 있는 건 어떤건지, 그리고 얼마나 제품의 복잡도가 올라가게 될지 등 다양하게 설명하는 시간을 가질 수 있었다. 발표를 통해 동료분들과 함께 고민하는 시간을 가지고, 혼자서 오래 고민하던 문제를 더 좋은 방향으로 작업을 진행해 잘 마무리할 수 있었다.

하지만 전역로딩 경험 개선 작업을 진행하면서는 충분한 시간을 가지지 못했다. Tanstack Query와 Suspense를 이용해 로딩상태를 분리하는 작업을 모두 다 진행하고 난 뒤에 사후에 작업 결과를 정리하는 시간을 가졌다. 그때 동료분께서 해주신 피드백은 작업이 풀고자하는 문제보다 복잡하게 되었다는 점이었다.

코드리뷰를 하면서 일부 동료분들은 어떻게 작업이 진행되고 있는지 접할 수 있었지만, 랜덤으로 배정되다보니 피드백 시간에 처음보시는 분도 계셨기 때문에 어렵게 느껴지셨던 것 같다.

나에게 당연하다고 느끼는 것이 누군가에게 당연하지 않다는, 어쩌면 당연한 사실을 다시금 깨달았다. 이러한 과정을 겪으면서 단순히 내가 생각하는 좋은 것이 제품에 적용되는 게 중요한 게 아니라, 함께 코드를 작성하는 동료분들이 어떻게 생각하는지 들어보고 함께 고민하는 시간이 중요하다는 것을 깊이 깨달을 수 있었다. 제품 내 반영되게 되면 나만 관리하면 되는게 아니라 동료들이 함께 가꾸어야 하는 팀의 자산이 된다는 것을 놓쳤던 것 같다.

이직을 하게 되면서 실제로 더이상 내가 관리할 수 없게 되었고, 마음의 빚이 된 작업으로 남게 되었다. "먼저 어떤 문제를 어떻게 풀지 설명했더라면, 조금 더 설득력있고 복잡도를 낮추는 방향으로 미리 작업 방향을 바꿨을텐데"하는 아쉬움이 아직도 많이 든다.

앞으로는 시간이 더 걸리고, 이해를 맞춰가는데 어려울 수 있지만 코드를 작성하는 동료분들과 더 좋은 방향으로 작업을 진행해 나가야겠다.

📝 마무리

숨고는 나에게 너무 감사한 곳이다. 배울 수 있는 부분이 너무 많았고, 부족한 나에게 많은 기회를 주고, 개발자라는 직업에 대해 더 깊이 이해하게 해준 곳이었다. 그리고 앞으로 어떤 개발자가 되고 싶은지, 어떤 사람이 되고 싶은지 옆의 동료들을 보며 많이 느끼고 배울 수 있는 곳이었다.

이제는 다음 회사로 떠나지만, 숨고에서 배운 것들을 기억하며 더 성장해 더 많은 것을 나누어줄 수 있는 개발자가 되고 싶다.

바이바이 숨고

9️⃣ 2024년 9월 회고

Tue, 01 Oct 2024 00:00:00 GMT

9월은 스쿼드 업무로 신규 비즈니스 모델에 대한 마지막 실험을 진행해보고, 3분기 동안 진행했던 프로젝트를 마무리하는 시간이었다. 로딩경험 개선 작업에 대해 글을 작성했고, 토스 FE 멘토링 accelerator에 참여하면서 분석했던 useFunnel에 대한 글도 작성했다. 3개월의 업무를 정리했던 9월에 대해 회고하고 10월의 계획을 세워보려 한다.

9월의 액션아이템

9월의 액션아이템은 아래 3가지로 설정했었다.

React Query를 이용한 로딩 경험 개선 작업 정리하기
useFunnel 라이브러리 분석 후 오픈소스 분석 과정 공유하기
MMKV 데이터 스토리지 라이브러리 적용 작업 정리하기

이중 위 2가지는 진행했지만 마지막 MMKV 데이터 스토리지 라이브러리 적용 작업 정리하기는 하지 못했다.

React Query를 이용한 로딩 경험 개선 작업 정리하기

로딩 경험 개선을 위해 React Query와 Suspense를 제품 내 도입하면서 이를 적용한 결과를 정리해 글로 작성했다. 해당 글을 작성하면서 다시 돌아보니 Suspense와 React Query를 이용해 적용한 방법이 어려웠을 수 있겠다는 생각이 들었다.

처음 작업을 보았을 때 Suspense, Query의 생소한 개념들에 대해 이해하는데 어려웠을 것 같았다. 챕터에서 진행하는 일들은 보통 제품 전역에 영향을 주거나, 새로운 표준이 될 수 있는 작업이 되는 것 같다.

그래서 더더욱 안정적으로 잘 정리와 공유시간이 필요했는데, 현실적인 시간이 없었던 부분과 코드리뷰로도 충분했겠지라는 나만의 생각으로 인해 작업이 온전히 공유되지 못했던 것 같다.

코딩은 사회적 활동이라는 말의 의미를, 이번 작업을 통해 다시 한번 느낄 수 있었던 것 같다.

useFunnel 라이브러리 분석 후 오픈소스 분석 과정 공유하기

토스 FE Accelerator 멘토링 과정을 진행하면서 분석했던 useFunnel 라이브러리에 대한 글을 작성했다. 발표자료에 워낙 잘 정리되어 있었기 때문에 풀고자 하는 문제와 해결방법을 따라 만들면서 많이 배울 수 있었고, 이러한 과정을 글로 정리해 녹여내보고 싶었다.

현재는 해당 라이브러리에 대한 새로운 버전이 나와있어 추후에 해당 라이브러리도 조금 더 공부해보면 좋을 것 같다.

처음부터 큰 라이브러리들을 분석하는 것은 쉽지 않지만, 내가 사용하고 있는 라이브러리에 대해 분석하고 공유하는 것은 좋은 방법이 될 수 있겠다는 생각이 들었다. 앞으로도 이러한 작업을 지속적으로 해보면 좋을 것 같다.

MMKV 데이터 스토리지 라이브러리 적용 작업 정리하기

MMKV 데이터 스토리지 라이브러리 적용 작업은 Native Module에서 token을 어떻게 가져올지에 대한 문제로 인해, 보류되고 있다. 실제 적용 후에 적용 과정과 성능에 대한 결과를 정리해보고 싶었지만, 아직 적용을 못한 상태이다.

다음 달에 배포 후에 해당 작업에 대한 결과를 정리해보려 한다.

10월의 액션아이템

React Query 도입 가이드 작성하기
토스 오픈소스 라이브러리 분석해보기

10월의 액션아이템으로 위 두가지로 정한 이유는, 토스로 이직을 준비하고 있기 때문이다.

현재 3분기 로딩경험 개선을 위해 적용한 React Query를 현재까지 적용해온 기준과 가이드를 작성하고, 토스에서 잘 적응하기 위해 토스의 오픈소스 라이브러리를 분석해보려 한다.

이직을 결심하게 된 건, 토스 FE Accelerator 멘토링 과정을 진행하면서 Native 쪽 보다는 웹에 대한 업무를 더 많이 하고 싶다는 생각에 시작하게 되었다.

부족하지만 멘토링 과정 이후에 멘토님의 추천을 받을 수 있었고, 11월 4일을 입사일로 정해지게 되었다.

10월에는 아마 현재 진행 중인 프로젝트를 마무리하는 시간을 가지게 될 것 같다. 숨고에서 너무 많이 배웠고, 아직도 배울게 많지만 조금 더 주도적으로 일할 수 있고, 내가 채우고 싶은 전문성을 더 깊이있게 고민하고 있는 동료들이 있는 환경에 가고 싶었다.

현재의 안정적인 환경보다 새롭게 도전하며 나를 밀어 붙여서 성장하고 싶다는 생각에 이직을 결심했다.

10월에는 내가 맡았던 업무들을 잘 마무리할 수 있기를 바라고, 새로운 환경에서 잘 적응할 수 있을 준비를 하려 한다.

⏳ 로딩 경험 개선

Wed, 25 Sep 2024 00:00:00 GMT

❓로딩 경험 개선은 왜 필요할까

일전에 동료분께서 공유해주신 글로 카카오 페이지의 무조건 스켈레톤 화면을 보여주는게 사용자 경험에 도움이 될까요?라는 글을 읽게 되었다. 글의 내용을 요약하면 무조건 스켈레톤 UI와 같은 로딩 상태를 위한 UI를 보여주는 것이 사용자 경험에 도움이 되지 않는다는 내용이었다.

예시 100ms	예시 300ms

아티클의 예시로 나왔던 이미지 둘을 보면, 100ms는 300ms 응답보다 유저에게 빠르게 와서 더 좋은 상황임에도 불구하고, 로딩 상태로 인해 깜빡임이 발생하는 것처럼 보여 사용자에게 불편함을 줄 수 있다.

이러한 상황은 당시 우리 제품에서도 발생하고 있는 상황이었다.

위 예시처럼 dim처리가 있는 전역 로딩을 사용하는 화면들에서 많이 느껴지던 불편함이었고, 진입시 전역로딩을 사용하는 화면들을 작업범위로 정하고 작업을 시작했다.

❗️로딩 경험 개선을 위한 두가지 접근법

그러면 어떻게 로딩 상태에 대해 개선할 수 있을까? 여기에 대해서는 두가지 접근 방법이 있었다. 각각을 지연 로딩 시간 설정과 최소 로딩 시간 설정이라고 부르려한다.

1. 최소 로딩 시간 설정: 임의로 최소 로딩시간을 주기

최소 로딩 시간 설정 방식은 응답 속도와 무관하게 일정시간을 로딩UI를 노출한 후에 성공/실패 화면을 보여주는 방식으로, 로딩 시간이 깜빡임으로 느껴지지 않을 만큼 충분히 길게 노출시키는 방식이다.

해당 방식의 장점은 응답속도와 무관하게 적용되기 때문에, 전체 유저에게 일정한 유저 경험을 보장할 수 있다. 하지만 응답이 빠르게 왔지만, 특정 시간만큼 기다려야 하기 때문에 유저 입장에서 불편함을 느낄 수 있다.

2. 지연 로딩 시간 설정: 특정 시간만큼의 Delay를 준 후에 노출시키기

지연 로딩 시간 설정 방식은 로딩 UI 노출을 특정시간만큼 지난 후에 노출시키는 방식으로 빠른 응답이 오는 경우에 로딩 UI가 노출되지 않고 성공/실패 화면으로 넘어갈 수 있기 때문에 깜빡임을 방지할 수 있다.

해당 방식의 장점은 응답속도에 따라 로딩 UI를 노출시키기 때문에, 빠른 응답속도를 보장하면서 깜빡임을 방지할 수 있다. 하지만 해당 시간 이후로 걸릴 경우 일부 사람에게는 여전히 깜빡임이 발생할 수 있기 때문에, 기준이 될 시간에 대한 고려가 필요했다.

예를 들어 200ms를 기준으로 지연 로딩 시간을 설정하면, 200ms 이내에 응답이 오면 로딩 UI를 노출하지 않고, 200ms 이후에 응답이 오면 로딩 UI를 노출하는 방식이다. 하지만 250ms가 걸린 경우에는 200ms 이후에 로딩 UI가 노출되기 때문에, 50ms동안 로딩 UI가 보였다 사라지기 때문에 여전히 깜빡임이 발생할 수 있다.

각각 장단점이 있는 방식이기 때문에 고민이 필요해 동료분들의 의견을 여쭤보았고 최소 로딩 시간 설정 방식으로 진행했을 때 로딩 시간을 임의로 늘리는 것이기 때문에, 유저에게 안좋을 것 같다는 동료분들의 의견이 있어 지연 로딩 시간 설정을 적용하기로 했다.

🚀 지연 로딩 시간 설정 적용

전역로딩을 이용하는 화면들에 지연 로딩 시간을 설정하기 위해서는 생각보다 간단했다.

Redux 전역 로딩상태를 구독하고 있는 최상위 컴포넌트에 정의되어 있는 FullScreenLoading 컴포넌트에 지역 상태를 추가한 후에 전역상태가 변경되면 지연시간을 주고 로딩 UI를 노출하도록 구현했다.

export const FullScreenLoading: React.FC = () => {
  const globalLoading = useSelector(state => state.globalLoading)
  const [show, setShow] = useState(false)

  useEffect(() => {
    const timeout = setTimeout(() => {
      setShow(visible)
    }, 200)
    return () => {
      clearTimeout(timeout)
    }
  }, [globalLoading])

  return show ? <Loading loading={globalLoading} /> : null
}

하지만 두가지 포인트에 대한 고려가 필요했다.

먼저 전역로딩의 용도가 다양했다. POST 요청 과정에서 여러번 호출되지 않게 막을 때, 발송 과정에서 안드로이드 백버튼과 같이 뒤로가기를 하지 못하게 막는 역할을 함께 하고 있다보니, 진입시에 필요한 지연 로딩을 전체적으로 적용하는 것이 적절하지 않아 보였다.

두 번째로는 지연 로딩 시간 설정의 단점인 특정 시간 이상 걸리는 유저에게는 여전히 깜빡임이 발생할 수 있다는 점을 고려해, 페이지별 지연시간 설정이 가능하게 구현하는 게 필요하다고 생각했다. Redux에 추가적인 속성을 정의해서 해결할 수 있지만, Redux 사용을 지양하는 팀내 컨벤션을 생각해 Redux 의존성을 줄이는 방향으로 구현하려 했다.

Redux 없이 구현하는 방식으로 개인적으로 관심이 많던 Tanstack Query와 Suspense를 이용해, 로딩 상태를 선언적으로 분리한 후에 지연시간을 설정하는 방식을 적용하기로 했다.

Suspense로 로딩 상태 선언적으로 분리하기

Suspense는 React에서 비동기 상태를 선언적으로 처리하는 방식으로, 에러바운더리는 에러를 suspense는 로딩 상태를 분리할 수 있다.

예를 들어 아래 코드와 같이 컴포넌트 내에서 데이터 조회에 대한 성공/실패/로딩 세가지 경우에 대한 상태가 함께 존재했을 때 분기문이 길어져 코드 가독성이 떨어지고, 일일이 상태를 manual하게 관리하면서 실수가 발생할 수 있다.

function MyComponent() {
  const [data, setData] = useState()
  const [isLoading, setIsLoading] = useState(true)
  const [isError, setIsError] = useState(false)

  useEffect(() => {
    async function fetchData() {
      try {
        setIsLoading(true)
        const data = await fetchData()
        setData(data)
        setIsLoading(false)
      } catch (error) {
        setIsError(true)
        setIsLoading(false)
      }
    }
    fetchData()
  }, [])

  if (isLoading) return <div>Loading data...</div>

  if (isError)
    return (
      <div>
        Oops failed to fetch data! <a href="/home">Home page</a>
      </div>
    )

  return (
    <ul>
      {data.map(({ id, name }) => {
        return <li key={id}>{name}</li>
      })}
    </ul>
  )
}

위 코드를 개선해 에러는 에러바운더리, 로딩은 Suspense로 분리하면 우리가 관심을 가지고 있는 성공 상태에 대해서만 신경쓰면 되어 코드 가독성이 향상되고, 선언적인 방식으로 상태를 관리해 개발자의 실수를 줄일 수 있다.

function MyComponentContent() {
  const data = useFetchData() // 임의의 suspense 사용가능한 훅
  return (
    <ul>
      {data.map(({ id, name }) => {
        return <li key={id}>{name}</li>
      })}
    </ul>
  )
}
function MyComponent() {
  return (
    <ErrorBoundary>
      <Suspense fallback={<div>Loading data...</div>}>
        <DataLoader />
      </Suspense>
    </ErrorBoundary>
  )
}

이제 여기에 지연로딩을 위해 전역 로딩 컴포넌트에 적용하는 방식과 유사하게 지연시간을 주고 로딩 UI를 노출하도록 구현해보자.

지연 로딩을 위한 Delay 컴포넌트 구현하기

지연 로딩을 위한 컴포넌트를 카카오 페이지 글에서는 DeferredComponent라고 명명했지만, 토스의 Suspensive 라이브러리 내의 Delay 컴포넌트를 참고해 조금 더 직관적인 Delay로 정하게 되었다. 아래는 Delay 컴포넌트 구현 코드이다.

export const Delay: React.FC<{ ms?: number }> = ({ ms = 200, children }) => {
  const [show, setShow] = useState(false)

  useEffect(() => {
    const timeout = setTimeout(() => {
      setShow(true)
    }, ms)
    return () => {
      clearTimeout(timeout)
    }
  }, [ms])

  return show ? <>{children}</> : null
}

// Delay 컴포넌트 사용 예시
function MyComponentContent() {
  const data = useFetchData() // 임의의 suspense 사용가능한 훅
  return (
    <ul>
      {data.map(({ id, name }) => {
        return <li key={id}>{name}</li>
      })}
    </ul>
  )
}
function MyComponent() {
  return (
    <ErrorBoundary>
      <Suspense
        fallback={
          <Delay>
            <div>Loading data...</div>
          </Delay>
        }
      >
        <DataLoader />
      </Suspense>
    </ErrorBoundary>
  )
}

Delay 컴포넌트는 기존 전역 상태를 이용하는 방식과 유사하게 지연시간을 주고 로딩 UI를 노출하도록 구현했다. Props으로 ms를 받아 지연시간을 설정할 수 있고, 기본값은 카카오 페이지 글을 참고해 200ms로 설정했다.

하지만, Suspense 자체적으로 아직 Next JS와 같은 프레임워크나, 특정 인터페이스로 데이터를 가져오는 경우가 아니면 사용할 수 없는 한계점이 존재했다.

공식문서 suspense에 대한 Note

Suspense를 지원하는 라이브러리들은 Recoil, Relay, Tanstack Query 등이 있고, 다행히 우리 프로젝트에서 아주 일부 사용하고 있던 Tanstack Query가 V5 기준으로 안정적으로 지원하고 있었기 때문에 Tanstack Query를 이용해 적용해보기로 했다.

Tanstack Query migrate to v5 섹션의 suspense에 대한 노트

Tanstack Query의 SuspenseQuery를 이용한 Suspense 적용

Tanstack Query V5버전에서 suspense를 이용하기 위해서는 새롭게 추가된 useSuspenseQuery,useSuspenseQueries,useSuspenseInfiniteQuery 세가지 훅을 이용해야 한다.

각각에 대한 적용방법을 알아보자.

1. useSuspenseQuery를 이용한 적용

useSuspenseQuery는 단일 쿼리에 대해 suspense를 적용할 때 사용한다. 아래 코드는 useSuspenseQuery를 이용해 데이터를 가져오는 코드이다.

function MyComponentContent() {
  const { data } = useSuspenseQuery({
    queryKey: "data",
    queryFn: fetchData,
  })

  return (
    <ul>
      {data.map(({ id, name }) => {
        return <li key={id}>{name}</li>
      })}
    </ul>
  )
}
function MyComponent() {
  return (
    <ErrorBoundary>
      <Suspense
        fallback={
          <Delay>
            <div>Loading data...</div>
          </Delay>
        }
      >
        <DataLoader />
      </Suspense>
    </ErrorBoundary>
  )
}

2. useSuspenseQueries를 이용한 적용

여러 쿼리에 대해 Suspense를 적용할 때는 각각을 SuspenseQuery로 함께 작성하게 되면 Promise를 순서대로 던지면서 컴포넌트 렌더링이 suspend되게 되기 때문에, 병렬로 처리되지 못하게 된다.

이러한 길어지는 요청시간을 개선하기 위해서는 하위 컴포넌트에서 각각 useSuspenseQuery로 호출하게 하거나, useSuspenseQueries로 병렬로 호출할 수 있다.

공식문서 parallel queries 섹션의 suspense 사용시 주의점 노트

import { useSuspenseQueries } from "@tanstack/react-query"
import { fetchProjects } from "../queries"

export default function Projects() {
  const [{ data }] = useSuspenseQueries({
    queries: [
      {
        queryKey: ["projects"],
        queryFn: () => fetchProjects(1),
      },
      {
        queryKey: ["projects2"],
        queryFn: () => fetchProjects(2),
      },
    ],
  })

  return (
    <div>
      <h1>TanStack Repositories</h1>
      {data.map(project => (
        <p key={project.full_name}>{project.name}</p>
      ))}
    </div>
  )
}

이렇게 적용하게 되면 앞선 요청이 끝나고 다음 요청을 하는게 아니라 병렬로 처리되기 때문에, 각각의 요청시간이 더해지지 않고 병렬로 처리되어 더욱 빠른 응답속도를 보장할 수 있다.

3. useSuspenseInfiniteQuery를 이용한 적용

useSuspenseInfiniteQuery는 무한 스크롤/ 페이지네이션이 필요한 목록 화면에 대한 Suspense를 적용할 때 사용한다. 아래 코드는 useSuspenseInfiniteQuery를 이용해 데이터를 가져오는 코드이다.

export default function PaginatedProjects() {
  const { data, fetchNextPage, isFetching } = useSuspenseInfiniteQuery<
    Data,
    Error,
    InfiniteData<Data>,
    QueryKey,
    number | undefined
  >({
    queryKey: ["projects"],
    queryFn: ({ pageParam }) => {
      return fetchProjects({ pageParam })
    },
    initialPageParam: 1,
    getNextPageParam: (lastPage, pages) => {
      return lastPage.length === 10 ? pages.length + 1 : undefined
    },
  })

  const list = data.pages.flat()

  return (
    <div>
      <h1>TanStack Repositories</h1>
      <button onClick={() => fetchNextPage()}>불러오기</button>
      {list.map(project => (
        <p key={project.full_name}>{project.name}</p>
      ))}
      {isFetching ? <p>불러오는중...</p> : null}
    </div>
  )
}

SuspenseQuery 훅들을 적용했을 때 부수적인 장점으로 코드적으로 뿐만 아니라, 타입적으로도 성공했을 때에 대한 타입을 명확하게 지정시켜준다. 덕분에 라이브러리 내의 초기값으로 정의된 undefined과 구분되어 별도로 undefined을 좁혀주는 Validation 없이 적용이 가능했다.

useQuery 타입 정의

useSuspenseQuery 타입 정의

AsyncBoundary 구현

SuspenseQuery를 이용해 Suspense를 적용하게 되면 Query가 실패했을 때 에러를 던지기 때문에 에러바운더리가 필요하다.

이때 중요했던 것은 기존 처럼 단순히 ErrorBoundary를 이용하는 게 아니라 tanstack Query의 QueryErrorResetBoundary를 한번 더 감싸서, reset할 수 있게 구현해야 했다.

import { QueryErrorResetBoundary } from "@tanstack/react-query"
import { ErrorBoundary } from "react-error-boundary"

function MyComponent() {
  return (
    <QueryErrorResetBoundary>
      {({ reset }) => (
        <ErrorBoundary
          onReset={reset}
          fallbackRender={({ resetErrorBoundary }) => (
            <div>
              There was an error!
              <Button onClick={() => resetErrorBoundary()}>Try again</Button>
            </div>
          )}
        >
          <Suspense
            fallback={
              <Delay>
                <div>Loading data...</div>
              </Delay>
            }
          >
            <DataLoader />
          </Suspense>
        </ErrorBoundary>
      )}
    </QueryErrorResetBoundary>
  )
}

상대적으로 길어진 코드길이와 매번 SuspenseQuery를 사용할 때마다 많은 코드를 작성해야하기 떄문에 이를 추상화하고 재사용할 수 있게 AsyncBoundary라는 컴포넌트를 구현해 사용했다.

import { ReactElement, Suspense } from "react"
import { ErrorBoundary } from "react-error-boundary"
import { QueryErrorResetBoundary } from "@tanstack/react-query"

type AsyncBoundaryProps = {
  pendingFallback: ReactElement
  rejectFallback: ReactElement
  children: ReactElement
}

export function AsyncBoundary({
  pendingFallback,
  rejectFallback,
  children,
}: AsyncBoundaryProps) {
  return (
    <QueryErrorResetBoundary>
      {({ reset }) => (
        <ErrorBoundary onReset={reset} fallback={rejectFallback}>
          <Suspense fallback={pendingFallback}>{children}</Suspense>
        </ErrorBoundary>
      )}
    </QueryErrorResetBoundary>
  )
}

function MyComponent() {
  return (
    <AsyncBoundary
      pendingFallback={
        <Delay>
          <div>Loading data...</div>
        </Delay>
      }
      rejectFallback={<div>There was an error!</div>}
    >
      <DataLoader />
    </AsyncBoundary>
  )
}

로딩 UI 개선

지연 로딩 방식은 200ms 이상 걸릴 경우 깜빡임이 발생할 수 있기 때문에, 로딩 UI 자체를 개선하는 작업도 필요하다 생각했다.

기존 전역 로딩 UI는 dim 처리가 되어있어 기본 바탕색이 되는 흰색과 차이가 커서 더 깜빡임이 느껴지는 것 같아 로딩 UI를 흰바탕의 ActivityIndicator를 이용한 UI로 교체해 개선했다.

기존 전역 로딩 UI	개선된 전역 로딩 UI

기존 전역 로딩 UI	개선된 전역 로딩 UI

상대적으로 덜하긴 하지만, 깜빡임이 느껴질 수 있을 만한 시간을 체크해서 세부적인 조정도 진행하는 작업을 진행하면 이후에 더 좋은 유저경험을 기대할 수 있을 것 같다.

지연 로딩 시간 설정 적용 후 결과와 느낀 점

아래는 앞서 제품내 전역로딩으로 인해 깜빡임이 발생하던 알림 목록화면에 적용한 결과다.

200ms 이하로 걸릴 때	200ms 이상으로 걸릴 때

200ms 이하로 걸릴 때는 로딩 UI가 노출되지 않고, 200ms 이상으로 걸릴 때는 로딩 UI가 노출되는 것을 확인할 수 있다.

깜빡임이 심하게 느껴지던 전역로딩을 진입시 로딩 UI로 사용하는 화면들에 대해서만 작업을 했지만, 작업과정에서 Tanstack Query와 Suspense를 이용해 선언적으로 비동기 상태를 관리하는 방법을 고민하고 적용해, 평소 비동기 상태 관리에 관심을 제품에 녹일 수 있는 좋은 경험이었다.

하지만 개인적으로 아쉬웠던 건 적용과정에서 페이지별 소요되는 시간들을 이용해 세밀하게 지연 로딩 시간을 적용하지 못했고, 배포 후 결과를 공유하며 구현 방식이 복잡했다는 피드백을 받기도 했다.

나의 기준에서는 제품 내 선언적인 비동기 상태 관리와 Tanstack Query의 적극적 도입이 필요하다고 생각하고 작업 방향을 잡았지만, 팀내에서는 필요성에 대한 공감이 부족한 채로, 밀어붙였던 것 같다.

이러한 작업을 진행할 때에는 팀원들과 충분한 커뮤니케이션이 필요하다는 것을 느꼈다. 다음에는 조금 더 사전 공유와 의견을 듣는 시간을 만들어서 작업을 진행하는 게 좋을 것 같다는 생각이 들었다.

📚 useFunnel 분석하고 따라 만들어 보기

Tue, 17 Sep 2024 00:00:00 GMT

2023 토스 Slash의 퍼널: 쏟아지는 페이지 한 방에 관리하기 발표에서 복잡한 퍼널간 상태관리를 위한 라이브러리 useFunnel을 소개했다.

[퍼널: 쏟아지는 페이지 한 방에 관리하기 인트로 ]

useFunnel Slash 발표

프론트엔드 개발자라면 여러 스텝에 거쳐서 사용자의 입력을 받고, 해당 정보를 제출하는 폼 정보를 다루는 경험을 한번쯤은 하게된다. 그리고 페이지나 스텝이 많아지면 많아질수록 복잡도는 올라가고, 디버깅의 어려움을 겪기도 한다.

현업에서 자주 마주치는 이 문제를 우아하게 풀어낸 토스의 useFunnel 라이브러리를 언젠가 분석하고 적용해봐야겠다고 생각했지만 당시에는 미래의 나에게 맡겨두고(?) 미뤄두었다.

토스의 프론트엔드 accelerator 멘토링 과정의 2주차 주제였던 퍼널간 상태 관리하기라는 주제로 과제를 개선하게 되었고, 더이상 미루지말자라는 마음으로 useFunnel 라이브러리를 분석하고 적용해보는 과정을 진행했다.

이제는 useFunnel을 분석하고 적용해보자

useFunnel 라이브러리는 당시 Next JS에 의존도를 가지고 있었지만 현재는 타입적으로 강화되었고, Next JS 뿐 아니라 React Router와 같은 다양한 Routing 라이브러리들을 지원할 수 있게 개선된 버전도 만들어졌다.

개선된 useFunnel

이번 글은 구 useFunnel 라이브러리 발표와 라이브러리를 분석하고, 이를 적용해보는 과정을 공유하려 한다.

useFunnel이 풀고 싶은 문제

Funnel이란?

Funnel이란 용어는 현재 재직중인 회사에서도 많이 사용하는 용어로, 원래는 마케팅에서 많이 사용하는 용어로 알려져있다.

Funnel의 의미는 깔때기로 번역되며 초기 단계에 많은 사용자가 들어오다가, 중간 단계에서는 일부 사용자가 빠져나가고, 마지막 단계에서는 일부 사용자만 남게되는 형태를 의미한다.

funnel 이미지

그러면 이러한 Funnel 형태로 구성되는 디자인을 알아보자.

디자인 요구사항 탐방

발표 자료는 휴대폰 가입에 대한 예제로, 각 스텝별로 가입방식, 주민번호, 집주소를 입력한 후에 제출하는 방식을 취하고 있다.

디자인 요구사항

이를 해결하는 방법, useFunnel을 사용하기 전 후로 나눠서 살펴보자.

useFunnel 전 해결 방법과 예제

useFunnel을 사용하기 전에는 전역상태를 사용하여 데이터를 관리하고, 각 스텝을 페이지로 별로 관리하고, 제출 API를 호출할 때 모아온 데이터를 담아 발송하는 방식으로 구현할 수 있다.

전역상태를 이용한 해결방법

발표보다 조금 더 간단히 이동 버튼을 누르면 전역 상태를 업데이트 하고 마지막 집 주소 스텝에서는 alert를 보여주고 제출 완료 화면에서 작성된 내용을 출력하는 예제를 작성해 보았다.

예제 폴더 구조

export default function PhoneNumberPage() {
  const setForm = useFormStore(state => state.setForm)
  const router = useRouter()

  const handleClick = () => {
    setForm({ phoneNumber: "010-1234-5678" })
    router.push("/form/citizenNumber")
  }

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <h1>휴대전화 입력</h1>
        <button className={styles.primary} onClick={handleClick}>
          주민번호 입력 스텝으로 이동
        </button>
      </main>
    </div>
  )
}

export default function CitizenNumberPage() {
  const setForm = useFormStore(state => state.setForm)
  const phoneNumber = useFormStore(state => state.form.phoneNumber)
  const router = useRouter()

  const handleClick = () => {
    setForm({ citizenNumber: "123456789" })
    router.push("/form/address")
  }
  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <h1>주민번호 입력</h1>
        <p>{`입력된 휴대번호: ${phoneNumber}`}</p>
        <button className={styles.primary} onClick={handleClick}>
          주소입력 스텝으로 이동
        </button>
      </main>
    </div>
  )
}

// 전역 스토어

const initialForm: Form = {
  phoneNumber: "",
  address: "",
  citizenNumber: "",
}

export const useFormStore = create<StoreType>(set => ({
  form: initialForm,
  setForm: (form: Partial<Form>) =>
    set(state => {
      return {
        ...state,
        form: {
          ...state.form,
          ...form,
        },
      }
    }),
  resetForm: () => set({ form: initialForm }),
}))

요구사항을 모두 충족하면서 정석적인 방법이지만, 두가지 유지보수의 어려움이 존재하게 된다.

스텝별로 어떤 데이터/ 어떤 스텝으로 이동하는지 페이지를 들어가야 알 수 있다
상태를 수집하는 곳과 사용하는 곳이 달라 수정할 때 전체 흐름을 추적해야한다

위 두가지 문제를 어떻게 해결한 useFunnel 훅에 대해 알아보자.

useFunnel을 이용한 해결 방법

위 문제를 해결하기 위해서 우선 여러개의 페이지로 구성된 스텝을 하나의 페이지에서 관리하고 각 스텝들은 조건부 렌더링을 이용해 하위 컴포넌트로 변경해 스텝별 UI 흐름을 한눈에 추적하기 쉽게 개선할 수 있다.

그리고 기존 전역상태로 관리하던 폼 데이터는 지역상태로 둠으로써 스텝과 데이터가 한곳에서 관리하게 되고, 사용하는 곳과 업데이트 하는 곳 모두 하나의 파일내 작성해 응집도를 높이는 이점을 가질 수 있다.

useFunnel을 이용한 해결 방법

그러면 이에 맞게 이전 예제를 리팩토링해보자.

적용 후 프로젝트 구조

export type Form = {
  phoneNumber: string
  address: string
  citizenNumber: string
}

const initialForm: Form = {
  phoneNumber: "",
  address: "",
  citizenNumber: "",
}

export default function FormPage() {
  const [form, setForm] = useState<Form>(initialForm)
  const [step, setStep] = useState<
    "주민번호" | "주소" | "핸드폰번호" | "제출완료"
  >("핸드폰번호")

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        {step === "핸드폰번호" && (
          <PhoneNumberStep
            onNext={(phoneNumber: Form["phoneNumber"]) => {
              setForm(prev => ({ ...prev, phoneNumber }))
              setStep("주민번호")
            }}
          />
        )}
        {step === "주민번호" && (
          <CitizenNumberStep
            phoneNumber={form.phoneNumber}
            onNext={(citizenNumber: Form["citizenNumber"]) => {
              setForm(prev => ({ ...prev, citizenNumber }))
              setStep("주소")
            }}
          />
        )}
        {step === "주소" && (
          <AddressStep
            phoneNumber={form.phoneNumber}
            citizenNumber={form.citizenNumber}
            onNext={async (address: Form["address"]) => {
              try {
                // 제출 로직
                await new Promise(resolve => {
                  setTimeout(resolve, 1000)
                })
                setForm(prev => ({ ...prev, address }))
                setStep("제출완료")
              } catch (error: unknown) {
                alert(`제출 실패: ${error}`)
                return
              }
            }}
          />
        )}

        {step === "제출완료" && <CompleteStep form={form} />}
      </main>
    </div>
  )
}

// 주민번호 스텝 컴포넌트
;("use client")

import styles from "@/app/page.module.css"
import { Form } from "@/app/registerForm/page"

type CitizenNumberPageProps = {
  phoneNumber: Form["phoneNumber"]
  onNext: (citizenNumber: Form["citizenNumber"]) => void
}

export function CitizenNumberStep({
  phoneNumber,
  onNext,
}: CitizenNumberPageProps) {
  const handleClick = () => {
    onNext("123456789")
  }
  return (
    <>
      <h1>주민번호 입력</h1>
      <p>{`입력된 휴대번호: ${phoneNumber}`}</p>
      <button className={styles.primary} onClick={handleClick}>
        주소입력 스텝으로 이동
      </button>
    </>
  )
}

위 리팩토링한 예제 코드를 통해 보면 발표처럼 여러 페이지가 아니라 하나의 페이지로, 전역상태로 폼 데이터를 관리하는 것이 아니라 지역상태로 관리하고, 각 스텝별로 조건부 렌더링을 통해 UI를 관리하는 것을 확인할 수 있다.

동작도 기존과 동일하게 작동하며, 새로운 스텝이 생겨도 조건부 렌더링 조건을 추가하면 되고, 제출을 다른 스텝에서 진행해야 하더라도 prop만 변경하면 되어, 코드의 가독성과 유지보수성이 향상되었다.

useFunnel 라이브러리 따라 만들어가기

그러면 이제 useFunnel 라이브러리를 따라 만들어가보자. 발표에서 순차적으로 추상화 과정이 잘 설명되어있어서 그대로 순차적으로 만들어가보려 한다.

1. 조건부 렌더링 추상화

먼저 조건부 렌더링 부분을 Step이라는 컴포넌트로 추상화할 수 있다. 조건이 맞을 때에만 보여줄 수 있게 하는 컴포넌트로 발표에서는 if라는 property로, 예제에서는 show라는 property로 적용해보았다.

조건부 렌더링 추상화

export default function FormPage() {
  const [form, setForm] = useState<Form>(initialForm)
  const [step, setStep] = useState<
    "주민번호" | "주소" | "핸드폰번호" | "제출완료"
  >("핸드폰번호")

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <Step show={step === "핸드폰번호"}>
          <PhoneNumberStep
            onNext={(phoneNumber: Form["phoneNumber"]) => {
              setForm(prev => ({ ...prev, phoneNumber }))
              setStep("주민번호")
            }}
          />
        </Step>
        <Step show={step === "주민번호"}>
          <CitizenNumberStep
            phoneNumber={form.phoneNumber}
            onNext={(citizenNumber: Form["citizenNumber"]) => {
              setForm(prev => ({ ...prev, citizenNumber }))
              setStep("주소")
            }}
          />
        </Step>
        <Step show={step === "주소"}>
          <AddressStep
            phoneNumber={form.phoneNumber}
            citizenNumber={form.citizenNumber}
            onNext={async (address: Form["address"]) => {
              try {
                // 제출 로직
                await new Promise(resolve => {
                  setTimeout(resolve, 1000)
                })
                setForm(prev => ({ ...prev, address }))
                setStep("제출완료")
              } catch (error: unknown) {
                alert(`제출 실패: ${error}`)
                return
              }
            }}
          />
        </Step>

        <Step show={step === "제출완료"}>
          <CompleteStep form={form} />
        </Step>
      </main>
    </div>
  )
}

// Step 컴포넌트
export function Step({ show, children }: PropsWithChildren<{ show: boolean }>) {
  if (!show) {
    return null
  }
  return <>{children}</>
}

2. 반복되는 조건문과 Step 상태 추상화

step에 조건문을 반복하지 않고, 단순히 어떤 스텝인지만 넘겨주면, 현재 step과 비교하여 조건부 렌더링을 할 수 있게 추상화해보자.

반복되는 조건문과 Step 상태 추상화한 인터페이스

이를 위해서 드디어 오늘 주제인 useFunnel 훅이 나오게 된다. 현재 스텝을 Step 컴포넌트가 알기 위해서는 이를 관리하는 Funnel이라는 컴포넌트로 children으로 전달되는 Step들중 현재와 일치하는 step만 렌더링하게 할 수 있다.

useFunnel

예제 코드에 적용해보자.

export default function FormPage() {
  const [form, setForm] = useState<Form>(initialForm)
  const [Funnel, setStep] = useFunnel()

  return (
    <Funnel>
      <Funnel.Step name={"핸드폰번호"}>
        <PhoneNumberStep
          onNext={(phoneNumber: Form["phoneNumber"]) => {
            setForm(prev => ({ ...prev, phoneNumber }))
            setStep("주민번호")
          }}
        />
      </Funnel.Step>
      <Funnel.Step name={"주민번호"}>
        <CitizenNumberStep
          phoneNumber={form.phoneNumber}
          onNext={(citizenNumber: Form["citizenNumber"]) => {
            setForm(prev => ({ ...prev, citizenNumber }))
            setStep("주소")
          }}
        />
      </Funnel.Step>
      <Funnel.Step name={"주소"}>
        <AddressStep
          phoneNumber={form.phoneNumber}
          citizenNumber={form.citizenNumber}
          onNext={async (address: Form["address"]) => {
            try {
              // 제출 로직
              await new Promise(resolve => {
                setTimeout(resolve, 1000)
              })
              setForm(prev => ({ ...prev, address }))
              setStep("제출완료")
            } catch (error: unknown) {
              alert(`제출 실패: ${error}`)
              return
            }
          }}
        />
      </Funnel.Step>
      <Funnel.Step name={"제출완료"}>
        <CompleteStep form={form} />
      </Funnel.Step>
    </Funnel>
  )
}

// useFunnel 훅
type StepProps = {
  children: React.ReactNode
}

function Step({ children }: StepProps) {
  return <>{children}</>
}

type FunnelProps = {
  children: React.ReactNode
  step: "주민번호" | "주소" | "핸드폰번호" | "제출완료"
}

export function useFunnel() {
  const [step, setStep] = useState<
    "주민번호" | "주소" | "핸드폰번호" | "제출완료"
  >("핸드폰번호")
  const FunnelComponent = ({ children }: FunnelProps) => {
    const validSteps = Children.toArray(children).filter(isValidElement)
    const targetStep = validSteps.find(
      (
        children: React.ReactElement<{
          name: "주민번호" | "주소" | "핸드폰번호" | "제출완료"
        }>
      ) => children.props.name === step
    )

    if (targetStep == undefined) {
      throw new Error(`${step} 스텝 컴포넌트를 찾지 못했습니다.`)
    }

    return targetStep
  }

  return [Object.assign(FunnelComponent, { Step }), setStep] as const
}

발표 자료의 코드는 짧은 시간내의 이해도를 위해 조금 더 간소화 버전을 소개해주셨지만 useFunnel 오픈 소스를 보면 예제 코드처럼 유효한 children만 필터링하여 현재 step과 일치하는 step만 렌더링하는 방식으로 구현되어있다.

실제 Funnel 컴포넌트

여기서 또한 볼 수 있는 것은 외부에 노출할 필요가 없는 Step 컴포넌트를 useFunnel 내부에 숨기고, 외부에 노출할 Funnel 컴포넌트만 노출하는 Compound 패턴으로 컴포넌트 간 관계를 잘 보여주고 있다.

3. Steps 타입 추상화

발표내용에는 없지만 예제 코드에 구현한 훅은 현재 타입이 내부에서 하드코딩되어있어, 이를 추상화하여 외부에서 타입을 지정할 수 있게 만들어보려 한다. 이 작업은 오픈소스 코드에서 어떻게 타입을 관리하고 있는지를 참고해 구현해보았다.

export default function FormPage(){
    const [form, setForm] = useState<Form>(initialForm);
    const [Funnel,setStep]=useFunnel({
        steps:['핸드폰번호','주민번호','주소','제출완료'] as const
    });

    return (
        // ...
    );
};


// useFunnel 훅

type NonEmptyArray<T> = readonly [T, ...T[]];
type StepsType = NonEmptyArray<string>;

type StepProps<Steps extends StepsType> = {
    name: Steps[number];
    children: ReactNode;
};

function Step<Steps extends StepsType>({ children }: StepProps<Steps>) {
    return <>{children}</>;
}

type FunnelProps<Steps extends StepsType> = {
    children: Array<ReactElement<StepProps<Steps>>>;
    steps: Steps;
    step: Steps[number];
};

function Funnel<Steps extends StepsType>({children, step, steps}: FunnelProps<Steps>) {
    const validSteps = Children.toArray(children)
        .filter(isValidElement)
        .filter((child) => {
            return steps.includes(
                (child.props as Partial<StepProps<Steps>>).name ?? ""
            );
        }) as Array<ReactElement<StepProps<Steps>>>;

    const targetStep = validSteps.find(
        (children) => children.props.name === step
    );

    if (targetStep == undefined) {
        throw new Error(`${step} 스텝 컴포넌트를 찾지 못했습니다.`);
    }

    return targetStep;
}

type RouteFunnelProps<Steps extends StepsType> = Omit<
    FunnelProps<Steps>,
    "steps" | "step"
>;

type FunnelComponent<Steps extends StepsType> = ((
    props: RouteFunnelProps<Steps>
) => ReactElement) & {
    Step: (props: StepProps<Steps>) => ReactElement;
};

export function useFunnel<Steps extends StepsType>(steps: Steps) {
    const [step, setStep] = useState<Steps[number]>(steps[0]);
    const FunnelComponent: FunnelComponent<Steps> = useMemo(
        () =>
            Object.assign(
                function RouteFunnel(props: RouteFunnelProps<Steps>) {
                    return (
                        <Funnel<Steps> steps={steps} step={step}>
                            {props.children}
                        </Funnel>
                    );
                },
                { Step }
            ),
        // eslint-disable-next-line react-hooks/exhaustive-deps
        []
    );

    return [FunnelComponent, setStep] as const;
}

위 코드는 useFunnel 오픈소스 코드를 거의 그대로 가져온 코드로 추상화된 훅을 사용하면서 외부에서 타입을 지정할 수 있게 만들어보았다. 각 코드들을 조금씩 뜯어보면서 왜 각각이 필요한지 정리해보자.

StepsType

type NonEmptyArray<T> = readonly [T, ...T[]]
type StepsType = NonEmptyArray<string>

StepsType은 빈배열이 아님을 타입적으로 보장하고, 전달하는 스텝 배열에 따라 리터럴로 타입을 좁혀주기 위해, readonly로 되어 있다. Generic으로 받은 Steps 타입은 StepProps와 FunnelProps에서 사용되어, 각각의 컴포넌트에서 사용할 수 있게 되었다.

StepProps

type StepProps<Steps extends StepsType> = {
  name: Steps[number]
  children: ReactNode
}

function Step<Steps extends StepsType>({ children }: StepProps<Steps>) {
  return <>{children}</>
}

StepProps는 Step 컴포넌트에서 사용할 타입을 정의한 것으로, name은 전달된 Steps 배열의 요소중 하나로 타입을 좁힌다.

FunnelProps

type FunnelProps<Steps extends StepsType> = {
  children: Array<ReactElement<StepProps<Steps>>>
  steps: Steps
  step: Steps[number]
}

function Funnel<Steps extends StepsType>({
  children,
  step,
  steps,
}: FunnelProps<Steps>) {
  const validSteps = Children.toArray(children)
    .filter(isValidElement)
    .filter(child => {
      return steps.includes(
        (child.props as Partial<StepProps<Steps>>).name ?? ""
      )
    }) as Array<ReactElement<StepProps<Steps>>>

  const targetStep = validSteps.find(children => children.props.name === step)

  if (targetStep == undefined) {
    throw new Error(`${step} 스텝 컴포넌트를 찾지 못했습니다.`)
  }

  return targetStep
}

FunnelProps는 Funnel 컴포넌트의 Prop을 지정한 부분이고 Funnel 내부에 유효한 children으로 필터링하는 과정에서 타입 단언으로 작성되어 있다. 타입 단언으로 작성된 이유가 뭘까하고 제거해보았을 때, 아래 children.props.name에서 name이 정의되어 있지 않다는 에러가 발생하기 때문에 타입 단언을 사용한 것으로 보인다.

FunnelComponent

type RouteFunnelProps<Steps extends StepsType> = Omit<
  FunnelProps<Steps>,
  "steps" | "step"
>

type FunnelComponent<Steps extends StepsType> = ((
  props: RouteFunnelProps<Steps>
) => ReactElement) & {
  Step: (props: StepProps<Steps>) => ReactElement
}

export function useFunnel<Steps extends StepsType>(steps: Steps) {
  const [step, setStep] = useState<Steps[number]>(steps[0])
  const FunnelComponent: FunnelComponent<Steps> = useMemo(
    () =>
      Object.assign(
        function RouteFunnel(props: RouteFunnelProps<Steps>) {
          return (
            <Funnel<Steps> steps={steps} step={step}>
              {props.children}
            </Funnel>
          )
        },
        { Step }
      ),
    // eslint-disable-next-line react-hooks/exhaustive-deps
    []
  )

  return [FunnelComponent, setStep] as const
}

RouteFunnel은 Funnel 컴포넌트를 분리하는 대신 바로 작성해도 동작에는 문제가 없지만 코드 가독성을 위해 분리시키신 것으로 보였다. FunnelComponent 타입 Step 컴포넌트의 타입을 지정해줌으로서 Step의 name이 전달받은 Steps 배열의 요소중 하나임을 보장할 수 있게된다.

해당 타입 없이도 StepsType을 사용하면서 자동으로 좁혀지지 않을까 했지만, 타입 지정전에는 단순 컴포넌트로 암묵적으로 추론되면서 name에 지정된 값이 아닌 다른값을 넣거나, Steps로 빈배열을 넣어도 타입에러가 안나게 된다.

타입 지정 전

타입 지정 후

4. 히스토리 관리

하나의 페이지로 관리하게 되면서 가독성은 올라가게 되었지만 뒤로가기를 했을 때 스텝별 히스토리가 유지되지 못하게 되었다.

해당 문제를 해결하기 위해 발표 내용을 참고해보면 step을 상태가 아니라 QueryParam으로 관리하는 방식으로 해결했다.

히스토리 관리

위 방법과 같이 예제코드에 적용해보자.

// QS
function createQueryString(params: Record<string, any>) {
  const queryString = createSearchParamString(params)

  if (queryString === "") {
    return ""
  }

  return `?${queryString}`
}

function createSearchParamString(params: Record<string, any>) {
  return new URLSearchParams(
    Object.entries(params)
      .filter(([, value]) => value != null)
      .map(([key, value]) => {
        if (Array.isArray(value)) {
          return value.map(x => [key, x])
        }
        return [[key, value]]
      })
      .flat()
  )
    .toString()
    .replace(/\+/g, "%20")
}

export const QS = {
  create: createQueryString,
}

// useFunnel 훅
interface SetStepOptions {
  stepChangeType?: "push" | "replace"
}

const STEP_QUERY_KEY = "funnel-step"

export function useFunnel<Steps extends StepsType>(
  steps: Steps,
  initialStep: Steps[number]
) {
  const router = useRouter()
  const setStep = useCallback(
    (step: Steps[number], setStepOptions?: SetStepOptions) => {
      const url = `${QS.create({
        [STEP_QUERY_KEY]: step,
      })}`

      switch (setStepOptions?.stepChangeType) {
        case "replace":
          router.replace(url)
          return
        case "push":
        default:
          router.push(url)
          return
      }
    },
    [router]
  )

  const FunnelComponent: FunnelComponent<Steps> = useMemo(
    () =>
      Object.assign(
        function RouteFunnel(props: RouteFunnelProps<Steps>) {
          const step = useQueryParam(STEP_QUERY_KEY) ?? initialStep
          return (
            <Funnel<Steps> steps={steps} step={step}>
              {props.children}
            </Funnel>
          )
        },
        { Step }
      ),
    []
  )

  return [FunnelComponent, setStep] as const
}

QueryParam으로 Step을 관리하게 되면서 더이상 step 지역상태는 불필요하게 되었고, setStep의 옵션으로 push와 replace에 따라 히스토리를 관리할 수 있게 되었다.

히스토리 관리 전 뒤로가기	히스토리 관리 후 뒤로가기

5. 폼 데이터 관리

발표는 히스토리 관리까지를 라이브러리 작업에 대한 소개로 마무리했지만, 오픈 소스 코드를 보면 폼 데이터 관리에 대한 부분도 있어서 추가해보았다.

코드 중에는 데이터 스토리지를 이용해 이전 작성한 값들을 저장하고 불러오는 로직도 있었지만, 현재 예제에서는 생략하였다.

export type Form = {
  phoneNumber?: string
  address?: string
  citizenNumber?: string
}

export default function FormPage() {
  const [Funnel, state, setState] = useFunnel([
    "핸드폰번호",
    "주민번호",
    "주소",
    "제출완료",
  ] as const).WithState<Form>({})

  return (
    <div className={styles.page}>
      <main className={styles.main}>
        <Funnel>
          <Funnel.Step name={"핸드폰번호"}>
            <PhoneNumberStep
              onNext={(phoneNumber: Form["phoneNumber"]) => {
                setState(prev => ({
                  ...prev,
                  step: "주민번호",
                  phoneNumber,
                }))
              }}
            />
          </Funnel.Step>
          <Funnel.Step name={"주민번호"}>
            <CitizenNumberStep
              phoneNumber={state.phoneNumber}
              onNext={(citizenNumber: Form["citizenNumber"]) => {
                setState(prev => ({
                  ...prev,
                  step: "주소",
                  citizenNumber,
                }))
              }}
            />
          </Funnel.Step>
          <Funnel.Step name={"주소"}>
            <AddressStep
              phoneNumber={state.phoneNumber}
              citizenNumber={state.citizenNumber}
              onNext={async (address: Form["address"]) => {
                try {
                  // 제출 로직
                  await new Promise(resolve => {
                    setTimeout(resolve, 1000)
                  })
                  setState(prev => ({
                    ...prev,
                    step: "제출완료",
                    address,
                  }))
                } catch (error: unknown) {
                  alert(`제출 실패: ${error}`)
                  return
                }
              }}
            />
          </Funnel.Step>
          <Funnel.Step name={"제출완료"}>
            <CompleteStep form={state} />
          </Funnel.Step>
        </Funnel>
      </main>
    </div>
  )
}

// useFunnel 훅

export function useFunnel<Steps extends StepsType>(
  steps: Steps,
  initialStep?: Steps[number]
) {
  const router = useRouter()
  const _initialStep = initialStep ?? steps[0]
  const setStep = useCallback(
    (step: Steps[number], setStepOptions?: SetStepOptions) => {
      const url = `${QS.create({
        [STEP_QUERY_KEY]: step,
      })}`

      switch (setStepOptions?.stepChangeType) {
        case "replace":
          router.replace(url)
          return
        case "push":
        default:
          router.push(url)
          return
      }
    },
    [router]
  )

  const FunnelComponent: FunnelComponent<Steps> = useMemo(
    () =>
      Object.assign(
        function RouteFunnel(props: RouteFunnelProps<Steps>) {
          const step = useQueryParam(STEP_QUERY_KEY) ?? _initialStep
          return (
            <Funnel<Steps> steps={steps} step={step}>
              {props.children}
            </Funnel>
          )
        },
        { Step }
      ),
    // eslint-disable-next-line react-hooks/exhaustive-deps
    []
  )

  type S = Record<string, unknown>
  type Step = Steps[number]
  type NextState = S & { step?: Step }

  const nextPendingStepRef = useRef<Step | null>(null)
  const nextStateRef = useRef<Partial<S> | null>(null)

  const WithState = <State extends S>(initialState: State) => {
    const [state, _setState] = useState<S>(initialState)
    const setState = useCallback(
      (
        next: Partial<NextState> | ((next: Partial<NextState>) => NextState)
      ) => {
        let nextStepValue: Partial<NextState>
        if (typeof next === "function") {
          nextStepValue = next(state)
        } else {
          nextStepValue = next
        }

        console.log(nextStepValue)

        if (nextStepValue.step != null) {
          nextPendingStepRef.current = nextStepValue.step
        }
        nextStateRef.current = nextStepValue

        _setState(next)
      },
      [_setState, state]
    )

    useEffect(() => {
      if (nextPendingStepRef.current == null) {
        return
      }
      if (deepEqual(nextStateRef.current, state)) {
        setStep(nextPendingStepRef.current)
        nextPendingStepRef.current = null
      }
    }, [state])

    return [FunnelComponent, state, setState] as const
  }

  return Object.assign([FunnelComponent, setStep] as const, {
    WithState,
  }) as readonly [
    FunnelComponent<Steps>,
    (step: Steps[number], options?: SetStepOptions) => void
  ] & {
    WithState: <StateExcludeStep extends Record<string, unknown>>(
      initialState: StateExcludeStep
    ) => [
      FunnelComponent<Steps>,
      StateExcludeStep,
      (
        next:
          | Partial<StateExcludeStep & { step: Steps[number] }>
          | ((
              next: Partial<StateExcludeStep & { step: Steps[number] }>
            ) => StateExcludeStep & { step: Steps[number] })
      ) => void
    ]
  }
}

setState로 폼 데이터를 업데이트시킨 후에 다음 step으로 이동시키기 위해 nextPendingStepRef와 nextStateRef와 useEffect를 사용한 것으로 보인다. 마지막 타입 단언을 하지 않았을 때 state의 타입이 주입한 타입이 아니라 Record<string, unknown>로 추론되기 때문에 타입 단언을 사용한 것으로 보인다.

이렇게 step과 폼 데이터를 함께 관리하게 되면서, 보다 응집도를 높인 훅을 완성할 수 있었다.

마치며

useFunnel이란 훅을 너무 좋은 방법이다 생각하다 드디어 직접 분석해보았다. 요구사항들과 해결방법을 코드와 함께 히스토리를 분석해보는 과정에서 더 깊이 있게 공부할 수 있게 되었고, 앞으로도 틈틈히 오픈소스를 분석해보며 더 많은 것을 배워나가야겠다.

🥳 2024년 8월회고

Sun, 15 Sep 2024 00:00:00 GMT

정신없이 9월을 보내다 보니 8월이 끝나고도 벌써 15일이나 지나버렸다. 조금 늦었지만 8월을 회고하고 9월의 계획을 세워보려 한다.

8월의 액션아이템

7월에 계획했던 8월의 액션아이템은 아래 4가지이다. 이중 앞선 2가지는 완료했지만, useFunnel 라이브러리 분석 후 오픈소스 분석 과정 공유하기와 컴포넌트 설계 추가 작업 진행하기는 하지 못했다.

MMKV 데이터 스토리지 라이브러리 적용 후 성능 개선 결과 정리하기
React Query를 이용한 비동기 상태 개선 방향 공유하기
useFunnel 라이브러리 분석 후 오픈소스 분석 과정 공유하기
컴포넌트 설계 추가 작업 진행하기

MMKV 데이터 스토리지 라이브러리 적용 후 성능 개선 결과 정리하기

지난 달에 벤치마크 지표들을 공유하면서 기존 사용하던 Async Storage에서 마이그레이션할 라이브러리를 MMKV로 정했고, 이번 달에는 실제 마이그레이션을 진행했다.

이전 발표에서 앱시작과정에서 API 호출과 함께 데이터를 가져오는 시간을 측정했던 부분이 API 의존성을 제거했을 때 수치를 보면 더 좋을 것 같다는 의견을 주셨고, 개발 환경에서 앱을 빌드하고 비교해 보았을 때 MMKV는 150ms에서 65ms로 50%이상 개선된 결과를 보였다.

하지만 로컬 DB자체를 제품내에서 사용하는 경우가 많지 않아 엄청나게 큰 개선을 가져오지는 못할 것으로 보이지만, Async Storage에서 간혹 200ms까지 걸리는 조회 시간이 있었기 때문에, 이를 개선하는 건 의미있다고 생각이 들었다.

작업 내용

마이그레이션 작업은 이전 마이그레이션 작업들에 비해 상대적으로 간단했지만, 테스트나 기존 코드들이 Async Storage 자체에 의존하고 있어서 이를 수정하는 작업이 조금 까다로웠다. 이를 해결하기 위해서 기존 아키텍처에서 AsyncStorage 자체에 의존하기 보다 인터페이스를 의존하게 해 이후 다른 라이브러리로 전환하더라도 최소한의 수정으로 가능하도록 설계를 변경하는 작업이 필요했다.

// 기존 예시

class KeyValueStorage {
  async setItem(key, value) {
    await AsyncStorage.setItem(key, value)
  }
  async getItem(key) {
    return AsyncStorage.getItem(key)
  }
}

class Repository {
  constructor() {
    this.storage = new KeyValueStorage()
  }

  async getLocalData(key) {
    return this.storage.getItem(key)
  }
}

// 이후

interface Storage {
  getItem: (key: string) => Promise<string | null>
  setItem: (key: string, value: string) => Promise<void>
}
const storage: Storage = new MMKVStorage()

class MMKVStorage implements Storage {
  async setItem(key, value) {
    await storage.set(key, value)
  }
  async getItem(key) {
    // 기존과 호환을 위해 JSON.parse를 사용
    const value = storage.getString(key)
    return value ? JSON.parse(value) : null
  }

  async setItem(key, value) {
    storage.set(key, JSON.stringify(value))
  }
}

class Repository {
  constructor(storage: Storage) {
    this.storage = storage
  }

  async getLocalData(key) {
    return this.storage.getItem(key)
  }
}

const repository = new Repository(storage)

조금 아쉬웠던 부분은 MMKV 라이브러리 자체가 AsyncStorage와는 다르게 기본 자료형들을 바로 가져올 수 있게 지원하지만, 기존 AsyncStorage와의 호환성을 위해 JSON.Stringinfy가 필요하고, 기존 인터페이스를 맞추기 위해 불필요한 promise를 반환해야 했다.

추가로 유틸들의 테스트가 AsyncStorage에 의존하고 있는 경우에 storage를 주입하는 방식으로 수정하다보니, 오히려 사용처 코드들이 복잡해보이기도 했다. 테스트가 필요한 게 맞는지 조금 더 고민해봐야 할 것 같다.

이후 작업 자체는 모두 완료했지만 아직 Native Module에서 어떻게 토큰을 가져오고 할지에 대해 논의가 진행되면서 배포는 보류되게 되었다. 배포 이후 성능을 측정하고 결과를 정리해보는 작업을 9월 또는 10월에 진행해보려 한다.

React Query를 이용한 로딩경험 개선 작업 공유하기

React Query를 이용해 Suspense로 비동기 상태를 분리하고, 전역 로딩경험을 개선하는 작업을 완료했다. 작업 자체는 완료했지만, 다양한 도메인에서 작업이 진행된 만큼 QA가 각각 진행이 필요하다보니 완전히 배포를 하지는 못했다.

작업 과정에서 중간중간에 공유하려 했지만, 발표를 하기에 다른 분들의 발표 일정이 겹쳤고, 예비군도 다녀오다 보니 작업과정이 아니라 결과를 공유하는 방식이 되어버렸다. 코드리뷰의 리뷰어로 배정되신 분들은 작업과정에 대해 이해하실 수 있었지만, 다른 분들은 결과만을 보게 된 것 같아 아쉬웠고, 문제의 크기에 비해 너무 어렵게 작업이 된 것 같다는 피드백을 받기도 했다.

해당 피드백을 받으면서 문제를 해결하기 위해서, 필요한 기술을 사용했는데 어떤 부분이 문제였는지 온전히 이해하는데에는 시간이 필요했다. 조금 더 일찍 공유했다면 괜찮았을까 아쉬움이 남아 한동안 괴로워하기도 했다.

기술적 문제를 해결하는 것도 중요하지만, 그 과정에서 다른 분들과 소통하는 것도 중요하다는 것을 다시 한번 느낄 수 있었다. 나름의 성장통을 겪었던 작업이었고, 해당 발표내용을 정리해 9월중으로 해당 작업에 대한 글을 작성해보려 한다.

하지 못한 액션아이템

useFunnel 라이브러리 분석 후 오픈소스 분석 과정 공유하기와 컴포넌트 설계 추가 작업 진행하기는 진행하지 못했다.

8월 동안 아직 프론트엔드엔드 accelarator 멘토링 과정 중이었기 때문에 둘째주까지 매주 다른 주제로 과제를 개선시켜나가면서 시간이 부족했다.

9월에는 꼭 이 두가지에 대해 진행해보려 한다.

새롭게 진행했던 활동들

7월과 동일하게 프론트엔드엔드 accelarator 멘토링 과정의 3주차, 4주차 과정을 진행해 마무리하게 되었다. 3주차 주제는 우아한 비동기 처리, 4주차는 UX 개선에 대한 주제로 진행되었다. 각 주차별 주제에 대한 내용을 정리해보자.

3주차 - 우아한 비동기 상태관리

3주차 주제의 우아한 비동기에는 Promise, async/await, Generator, Observable 등 비동기 처리를 어떻게 하면 더 우아하게 할 수 있을지에 대해 이야기했다.

비동기 상태는 사실 React에서 가장 어려운 부분 중 하나라고 생각한다. 하나의 요청에 대해서는 로딩/성공/실패가 발생하고 n개의 요청에 대해서는 3^n개의 상태가 발생할 수 있기 때문이다.

참고자료: 프론트엔드 웹 서비스에서 우아하게 비동기 처리하기

요청에 따른 비동기 상태의 경우의수.png

"에이, 왠만하면 다 성공하잖아" 라고 생각할 수 있지만, 개발자의 실수, 서버의 장애, 네트워크의 문제 등 다양한 이유로 실패할 수 있기 때문에 이러한 상태를 고려해야 한다.

그리고 이러한 고려를 일일이 manual하게 관리하기에는 코드가 너무 복잡해지거나 특정 로직가 빠지는 경우가 발생할 수 있기 때문에, 선언적인 방식으로 처리했을 때 각 상태에 대한 처리를 놓치지 않을 수 있다.

// 명령적인 방식
function Profile(){
	const foo=useAsyncValue(()=>{
		return fetchFoo()
	});

	const bar=useAsyncValue(()=>{
		if(foo.error||!foo.data){
			return undefined
		}
		return fetchBar(foo.data);
	});

	if(foo.error||bar.error) return <div> 로딩 실패.. </div>
	if(!foo.data||!bar.data) return <div> 로딩중... </div>
	return <div>{foo.data.name}님 {bar} 환영합니다. </div>
}

// 선언적인 방식

function FooBar(){
    const foo= useAsyncValue(()=> fetchFoo());
    const bar=useAsyncValue(()=>fetchBar(foo));
    return <div>{foo}{bar}</div>
}

function App(){
    return (
        <ErrorBoundary fallback={<MyErrorPage/>}>
            <Suspenese fallback={<Loader/>}>
                <FooBar/>
            </Suspense>
        </ErrorBoundary>
    )
}

이렇게 선언적으로 작성했을 때 기존과 달리 각 상태에 대한 처리를 놓치지 않을 수 있고, 로딩/성공/실패라는 각 비동기 상태에 따른 관심사 분리가 되어 코드가 더욱 깔끔해진다.

이렇게 선언적인 비동기 상태 관리에 대해 의논하고 알아가면서, 3분기 작업중 진행하고 있는 로딩 경험개선 작업을 진행하면서 Suspense를 이용해 선언적으로 비동기 상태를 분리하는 방법을 적용하게 되었다.

추가로 나는 놓쳤던 부분이지만 함께 진행하는 분은 작성된 폼 정보를 여러번 요청할 수 있는 경우를 고려해 Post 요청에 대한 추가 로딩 상태를 구현하는 디테일을 보여주시기도 해서, 내가 놓쳤던 디테일에 대한 부분들을 배울 수 있었다.

function Form() {
  const [name, setName] = useState("")
  const [email, setEmail] = useState("")
  const { mutate, isPending } = useMutation({
    mutationFn: submitForm,
    onSuccess: () => {
      navigate("/success")
    },
  })

  return (
    <form
      onSubmit={e => {
        e.preventDefault()
        mutate({ name, email })
      }}
    >
      <input value={name} onChange={e => setName(e.target.value)} />
      <input value={email} onChange={e => setEmail(e.target.value)} />
      <button type="submit" disabled={isPending}>
        제출
      </button>
    </form>
  )
}

4주차 - UX 개선

UX를 개선하는 방법으로 FCP/LCP 개선 방법과 스켈레톤 UI를 이용한 사용자 체감 로딩 속도를 줄이는 내용에 대해 이야기했다.

FCP/LCP를 개선하는 방법으로 나는 번들의 크기를 줄여서 초기로딩 시간을 개선할 수 있지 않을까 생각하고 작업하게 되었다. 이를 위한 방법으로 코드스플릿팅과 CRA 대신 vite로 마이그레이션하는 방식을 적용해보았다.

하지만 아쉽게도 과제 자체의 페이지 수가 많지 않고 CRA의 webpack에서 vite의 esbuild와 rollup으로 변경해 본 결과 번들 크기는 차이가 났지만, FCP에 큰 영향을 주지 못했다.

이러한 접근은 사실 데이터적으로 접근하는데 너무 많은 시간을 투자했고, 결과적으로는 큰 성과를 보지 못했던 것 같다.

다른 분들은 스켈레톤 UI와 화면 전환 애니메이션을 구현하고, 화면 이탈시에 이탈 방지 모달을 노출하는 등 보다 유저가 느낄 수 있는 실질적인 UX 개선을 진행하셨다. 이걸 보면서 유저에게 유의미한 개선은 무엇일지, 어떤 방식으로 개선할 수 있을지에 대해 다시 한번 생각해보고 배울 수 있는 순간이었다.

이렇게 하나의 과제에 대해 다양한 주제로 진행하면서 내가 놓치고 있던 점, 다른 분들께서 중요하게 생각하는 점들을 배울 수 있었던 정말 소중한 시간이었다. 그리고 마음 한켠에 이제 왠만한 건 다 만들 수 있고, 잘하고 있다는 생각에 빠져있던 모습을 느꼈고, 다시 한번 겸손해지고 더욱 더 배우고 싶다는 생각이 들었다.

React Native를 이용한 작업도 좋지만 웹개발에 대한 지식을 더욱 더 깊게 배우고 싶다는 생각이 들었다.

9월의 액션아이템

글을 작성하는 시점에 9월 중순이 지나가고 있지만, 9월의 액션아이템을 정리해보려한다.

MMKV 데이터 스토리지 라이브러리 적용 작업 정리하기
React Query를 이용한 로딩 경험 개선 작업 정리하기
useFunnel 라이브러리 분석 후 오픈소스 분석 과정 공유하기

이번 달에는 8월에 못했던 작업들과 함께 완료한 작업들에 대해서는 성과와 트러블 슈팅들에 대한 글을 작성해보려한다. 추가로 useFunnel 라이브러리 분석 후 오픈소스 분석 과정을 공유해보려 한다.

8월 한달 동안 다양한 활동을 하면서 새로운 경험을 많이 했고, 이를 토대로 9월에는 더욱 더 성장하고 싶다는 의욕이 생기는 한편, 내가 어디로 가고 싶은지, 어떤 개발자가 되고 싶은지에 대해 다시 한번 고민이 깊어지는 시기를 보내고 있는 것 같다.

앞으로도 더욱 더 성장하고 싶다는 의지를 가지고 9월을 보내보려 한다.

👏 2024년 7월회고

Sat, 03 Aug 2024 00:00:00 GMT

7월은 새롭게 한분기를 시작하는 달로, 챕터 내에서는 하고 싶었던 MMKV 데이터 스토리지 마이그레이션과 로딩 경험 개선 두가지 일감을 담당해 진행했고, 스쿼드에서는 새롭게 요청서 기반이 아닌 새로운 비즈니스 모델 실험에 맞는 퍼널 화면을 구현하는 등 새로운 작업들을 사내에서 담당해서 진행하게 되었다.

외부 활동으로는 오픈 소스 라이브러리에 처음으로 contribution을 해보고, 토스 FE Accelerator에도 합격해 멘토링 과정을 시작했다.

다양한 새로운 활동을 진행한 7월을 정리하고, 8월의 액션아이템들을 정리해보려 한다.

7월의 액션아이템

6월 회고를 작성하면서 7월의 액션아이템으로 아래와 같이 선정했었다.

Native Stack 적용 글 작성하기
Async Storage 대체할 라이브러리 검토 및 마이그레이션하기
제품 내 로딩 상태 개선하기
컴포넌트 설계 추가 작업 진행하기
페이지간 데이터 공유 문제 고민하고 논의하기

Native Stack 적용기 글 작성하기

2분기 OKR로 화면 전환간 성능 개선 작업을 담당하면서 적용한 Native Stack Navigation 적용과정에 대한 글을 작성했다. Native Stack Navigation을 적용하면서 메모리 사용량과 CPU 사용량을 감소시켜 화면 전환간 버벅임을 개선 과정과, 작업간 어려웠던 점, 트러블 슈팅을 정리할 수 있었고 이후 시도하면 좋을 작업들에 대해서도 정리할 수 있었다.

후작업으로 생각했던 일감 중 하나였던 검색 화면 진입시 버벅이는 이슈에 대한 작업을 추가적으로 진행했다.

해당 이슈는 react native screens에 등록되어 있던 이슈로 전환되는 화면의 TextInput이 AutoFocus가 true로 되어있을 경우 AutoFocus로 인한 키보드 노출 이벤트와 화면 전환 이벤트가 함께 처리되면서 버벅임이 발생하는 것으로 보였다.

[Repo에 등록된 이슈의 재현 영상]

UI 스레드의 부하를 줄이기 위해서 AutoFocus를 true로 설정하는 것 대신, 화면전환 완료 이후에 manual하게 TextInput ref에 focus를 동작시키는 방식으로 해결할 수 있었다.

해당 이슈에 공유한 해결방법

후작업을 통해 담당했던 일감에 대한 완성도를 높일 수 있어 뿌듯했던 순간이었다.

Async Storage 대체할 라이브러리 선정하기

Async Storage를 이용하면서 큰 문제는 없지만, 조금 더 빠르면서도 사용성이 좋은 데이터 스토리지 라이브러리를 찾고 적용하는 작업을 시작하게 되었다.

후보군으로는 WatermelonDB, MMKV, OP-SQLite로 총 3가지 라이브러리를 선정하게 되었는데 MMKV만을 사실 첫 목표로 작업을 기획했었지만, 챕터원 분들의 추천으로 다른 라이브러리들도 함께 비교해보면 좋을 것 같다고 알려주신 라이브러리들을 함께 비교해보기로 했다.

해당 라이브러리들을 비교하기 위해 MMKV 레포에 소개되어있는 Bench Mark 레포를 참고했고, 새롭게 레포를 만들어 비교를 진행하고 결과를 정리해보았다.

아래는 각 라이브러리별로 성능을 비교한 결과로 key: 'k', value: 'hello' 저장을 1000번 반복한 후에 시간을 측정한 결과로, MMKV가 가장 빠르게 처리되었음을 확인할 수 있었다.

벤치마크 비교 데이터

속도도 중요하지만 개발자 경험, 커뮤니티 지원, 실제 제품에 적용이 가능한지 등 여러가지 비교가 필요했고 결론적으로 MMKV를 선정하게 되었다.

[데이터 스토리지 라이브러리 별 npm 트렌드 비교]

정리한 내용들을 통해 챕터원분들께 발표를 진행했고, MMKV를 실제 제품에 적용했을 때 기대되는 성능적인 이점도 공유했다.

공유한 내용중에 시간 측정에 API 응답시간도 함께 포함되어있던 결과를 보고, 조금 더 정확한 측정을 위해 추가적인 작업이 필요하다는 피드백을 받았고, 이에 대한 추가적인 작업을 진행한 후에 정확하게 얼마나 성능적인 이점을 기대할 수 있을지 다시 측정하는 작업을 진행하기도 했다.

MMKV가 왜 빠른지, 또 제품에 적용하면서 고려했던 점 등에 대한 내용은 8월에 제품에 반영한 후에 블로그에 정리해보려 한다.

제품 내 로딩 상태 개선하기

제품 내 비동기 상태를 관리를 고도화하기 위해 로딩 상태 개선 작업을 발제하고 진헹하게 되었다. 에러바운더리 작업을 하면서, 전체 제품의 화면들을 보게 되면서 로딩화면이 필요한데 없는 경우, 로딩화면이 있는데 불필요하게 깜빡이는 경우들을 보게 되었다.

로딩화면이 필요한데 없는 경우는 웹뷰 진입시 화면, 목록 화면에서 탭을 눌렀을 때 새로운 데이터를 가져오는동안 로딩 상태가 없어 반응이 없는 것 처럼 보이는 등 사용성 개선을 위한 로딩처리가 필요한 부분들이 있어보였다. 해당 케이스는 각각에 맞는 로딩 상태를 추가해서 해결해나가고 있다.

로딩화면이 있는데 깜빡인다고 느껴지는 경우는 화면 조회를 위한 API 응답속도가 너무 빠를 때 오히려 로딩 상태 화면이 나왔다 사라지는 속도가 빨라서 깜빡이는 것처럼 느끼게된다. 이에 대한 개선 방법으로 두가지 방법이 있었는데 하나는 로딩 화면을 보여주는 최소시간 설정 방법과 다른 하나는 카카오 페이지의 무조건 스켈레톤 화면을 보여주는게 사용자 경험에 도움이 될까요? 글에서 소개된 일정 시간 내 응답이 오면 로딩화면을 보여주지 않는 방법이 있었다.

두가지 방법에 대해서는 장단점이 존재한다.

첫번째 방법의 장점은 유저가 아무리 빨라도 최소시간 설정이 있으니까 통일화된 로딩 경험을 할 수있지만, 단점으로 빠른 응답을 받았음에도 불구하고 로딩화면이 더 오래 보여지는 것처럼 느껴질 수 있다.

두번째 방법의 장점은 빠른 응답을 받았을 때 로딩화면을 보여주지 않아 사용자 경험이 더 좋아질 수 있지만, 단점으로 해당 시간 이상의 시간이 걸리면서 얼마 차이가 나지 않는 경우 깜빡이는 효과를 또다시 느낄 수 밖에 없다는 점이다. (기준 200ms 이내는 보여주지 않는다면 300ms 응답이 왔을 때 로딩은 100ms동안 보이면서 깜빡임을 여전히 느낄 수 있다.)

해당 장단점을 비교하고 일감 목표를 고민했을 때 최소 시간 설정을 생각하고 있었지만 카카오 페이지의 글과, 챕터원 분들께 방향을 공유드리면서 이미 빠른데 일부로 느리게 보여주는 것이 더 제품에 안좋을 것 같다는 피드백을 듣고, 두번째 방법을 선택했다. 이제 두번째 방법을 정하면서 로딩화면을 보여주지 않는 시간을 어떻게 설정할지, 어떤 화면에 적용할지 등 다양한 고민을 하면서 적용작업을 진행하고 있다.

추가적으로 로딩 경험 개선을 위해 React Query를 이용해 비동기 상태를 개선하는 방법으로 적용해가고 있다. 그중 가장 많이 공부하고 적용해보려 하는 방식은 로딩 상태를 선언적으로 관리할 수 있는 suspense의 도입인데, suspense가 왜 좋은지, 어떤 문제를 풀기 위한 방법인지 등을 8월 중에 발표해보고 챕터 내 비동기 코드를 개선하는데 기여해보고자 한다.

하지 못한 액션아이템

하지 못했던 액션아이템들로는 컴포넌트 설계 작업 공유와 페이지간 데이터 공유 해결해보기가 있었다.

페이지간 데이터 공유 문제는 챕터 동료 분께서 Zustand를 도입 작업을 해주시면서 도메인 간 공유할 수 있는 방법을 통해 해결해주셔서, 다음 달에는 남아있는 컴포넌트 설계부분을 더 고민하고 해결해보려 한다.

새롭게 진행했던 활동들

오픈 소스 라이브러리에 contribution하기

7월에는 특별한 경험들을 많이 할 수 있었는데, 먼저 토스의 es-toolkit 라이브러리에 contribution을 했다. 챕터원분께서 해당 라이브러리에 대해 소개해주시면서 오픈소스에 기여하는 경험을 해보면 좋겠다며 슬랙에 공유해주셨다.

평소 오픈소스에 기여를 하고 싶지만, 어디서부터 어떻게 해야하는지 알지 못해, 늘 분석만 하고 있다가 좋은 기회라 생각해 해당 라이브러리 코드들을 보게되었다.

잘 설명된 문서들과 제품에서 자주 사용하던 lodash를 최신 ECMAScript에 맞게, 성능과 번들 사이즈를 향상시킨 라이브러리다 보니 상대적으로 어떤 패키지보다 나에게 허들이 낮아 보였다.

작업이 필요한 이슈들과 이미 완료된 PR, 해당 라이브러리에 필요한 작업이 어떤 것인지 파악하고, 이미 병합된 PR들을 분석해보면서 어떤 점들을 고민하면 좋을지 라이브러리에 대한 이해도가 높여갔다.

총 7개의 PR을 올렸고, 그중 3개는 수정이 필요하거나, 불필요할 것 같다는 논의 끝에 close하게 되었고, 4개의 PR은 merge되게 되었다.

[내가 올렸던 PR]

es-toolkit-내가 올렸던 PR

이렇게 연초부터 개인적으로 목표로 잡고 있었던 오픈소스 기여를 할 수 있어서 뿌듯했고, 이제는 어떻게 하는지 알았으니 앞으로도 계속해서 관심있게 보고 내가 자주 사용하는 라이브러리들의 문제들을 찾아서 기여해보고 싶다.

토스 FE Accelerator 멘토링

우연히 링크드인에서 보게된 토스 FE Accelerator 프로그램에 6월 말에 지원해 테스트, 면접과정을 거쳐 7월부터 멘토링 과정을 시작하게 되었다.

링크드인 모집 글

토스 slash 개발자 컨퍼런스를 열심히 듣던 애청자로서 토스는 어떻게 일하고 있는지, 회사 밖의 다른 개발자 분들의 고민과 좋은 코드는 어떤 것이라 생각하는지 궁금했던 나에게 너무 좋은 기회가 되었다.

함께 조로 배정된 다른 회사의 FE 개발자분들과 토스 리드분과 함께 매주차 오프라인 코드 리뷰를 하면서 서로 같은 과제를 두고 왜 이렇게 코드를 작성했는지, 더 좋은 방법은 없을지 등을 함께 이야기 하면서 매주차 하나의 주제에 대한 깊이를 더해가는 시간을 가지고 있다.

회사에서 일하다보면 서로 다른 도메인을 담당하고 일을 하게 되고, 코드리뷰를 하더라도 더 깊이 고민하고 작업하신 작업자 분의 말씀을 더 존중하고 나보다 배경에 대해 더 잘 알고 계시니까라고 생각하면서 어느 정도 믿고 진행하는 경우도 많았던 것 같다.

하지만 멘토링 과정을 진행하면서 매주 진행하는 과제는 모두가 같다보니, 배경이 동일한 상황에서 이것 저것 물어보다 보니, 매주 내가 고려하지 못했던 부분, 내가 놓친 부분들을 다시 한번 생각해보게 되는 시간이 되고 있다.

7월에 진행한 주제들

7월은 2가지 주제, 관심사 분리와 퍼널간 상태관리를 주제로 한주씩 진행했다. 3월 회고 때부터 언급했던 퍼널간 상태관리를 고민하던 나에게 자연스럽게, 퍼널간 상태관리라는 관심사를 어떻게 우아하게 해결할 수 있을지 고민하게 되었다.

해당 문제를 해결하기 위해 첫번째로 Routing 페이지에 필요한 정보를 지역상태로 선언해 각 페이지에 필요한 정보를 주입하는 방식으로 작성하고 이를 공유했지만, 해당 방식은 Routing과 퍼널 스텝 관리 관심사가 혼재해 분리되면 좋을 것 같다는 피드백을 받을 수 있었다.

첫주차 멘토링 시간이 끝나고 리팩토링을 하면서 우선 관심사 분리에 초점을 맞춰서 퍼널간 상태 관리를 위해 정석적인 Zustand를 이용한 전역스토어를 만드는 방법을 이용해 해결할 수 있었다.

과제의 테스트 코드들도 다 통과했고, 기존 피드백에 따라 잘 수정한 것 같지만, 오랫동안 고민했던 주제였고 이번에 공부하지 않으면 이후에도 계속해서 마음 한켠에 남아있을 것 같아 useFunnel 코드를 분석하고, 이를 적용해보는 과정을 진행했다.

useFunnel 문서

useFunnel 코드를 여러번 보고, 발표내용을 여러번 들으면서, 어떤 문제를 해결하려하는 훅인지, 왜 코드가 이렇게 작성되었는지 한땀 한땀 이해하는 과정을 거칠 수 있었다. 처음에는 과한가 싶었지만 분석하고 직접 적용해보면서 너무 좋은 경험이었다는 것을 깨닫게 되었다.

2주차 멘토링 시간에 비록 완벽하게 구현한 건 아니지만 현재 과제에 맞게 어느정도 구현한 결과물을 가져갔고, 함께 공유했을 때 좋은 피드백을 받을 수 있었고, 실제 사내 제품에도 적용하면 좋겠다는 생각도 들었다.

useFunnel을 조금 더 완벽하게 분석한 후에 오픈소스 분석과정을 공유하는 글을 작성해도 좋을 것 같다.

벌써 2주나 흘렀지만 앞으로 남은 과정들을 진행하면서, 단순히 내가 알고있는 바운더리 내에서 최선이 아니라, 조금은 과하게 고민하고, 다른 사람들과 함께 공유하면서 더 좋은 방법을 찾아가는 과정을 더 많이 경험해보고 싶다.

8월의 액션아이템

7월의 다양한 새로운 활동과 함께 아래와 같이 8월의 액션아이템을 선정했다.

MMKV 데이터 스토리지 라이브러리 적용 후 성능 개선 결과 정리하기
React Query를 이용한 비동기 상태 개선 방향 공유하기
useFunnel 라이브러리 분석 후 오픈소스 분석 과정 공유하기
컴포넌트 설계 추가 작업 진행하기

하던 걸 꾸준히 잘하는 것도 중요하지만, 더 잘하기 위해 지금 보다 extra mile을 고민하는 게 지금 시점에 필요하다고 생각이 들었다.

새로운 시야와 다양한 경험을 통해 더 좋은 개발자가 되기 위해 8월에도 노력해보려 한다.

🖥️ Native Stack 적용하기

Sat, 06 Jul 2024 00:00:00 GMT

2분기 TechOKR 작업으로 선정된 화면전환간 성능 개선 작업을 담당하면서 Native Stack Navigator을 제품에 도입하게 되었다. 해당 작업을 진행하게된 배경, 적용과정에 대해 정리하면서 새롭게 알게된 내용, 시행착오를 기록해보려 한다.

🚀 Native Stack Navigator 작업 배경

Native Stack이란

Native Stack Navigator는 react navigation에서 지원하는 Navigator 형태 중 하나로, stack navigator의 인터페이스와 유사하게 제공하면서, stack navigator와 다르게 iOS는 UINavigationController, Android는 Fragment로 Native 요소를 이용해 화면을 구현하게 된다.

Native 요소를 이용해 화면을 구현하면서 Native가 가지고 있는 성능과 특징들을 이용할 수 있는 장점을 가지지만, stackNavigator와 다르게 커스텀이 어려운 단점을 가진다.

왜 Native Stack을 도입하게 되었나

Native Stack은 이전 1분기에 startup-time 개선 작업을 진행하면서 고려했던 방법중에 있었던 작업으로, 당시에는 화면전환간 속도가 앱 시작 시간을 최적화하는데 큰 영향이 없을 것 같아 보류해 두었다.

당시 기획해두었던 아이디어들

이후에 일감으로 발전시켰던 이유로 기존 제품에 stackNavigator를 이용하면서 화면 전환간 버벅임이 발생하는 경우가 간헐적으로 있었고, React Native 공식문서의 Navigation 예제가 NativeStack을 이용하는 방식으로 소개되는 것으로 수정되었고 (커뮤니티에서 성능을 위해 권장하는 방법), 화면전환 애니메이션을 Native 스레드에서 진행하게 되면 JS 스레드가 바쁘게 진행될 때에도 안정적으로 화면 전환 애니메이션을 보장할 수 있을 것을 기대하며 작업을 시작하게 되었다.

[react native 공식문서의 Navigating between screens]

react native 공식문서의 Navigating between screens

[React Navigation v2의 소개된 메모리 사용량 비교 데이터]

React Navigation v2의 소개된 메모리 사용량 비교 데이터

추가로 현재 React Native는 Expo를 공식적인 프레임워크로 추천하고 있는 흐름 속에 expo에서 사용하는 routing 시스템인 Expo router도 동일하게 React Native Screens를 이용해 file-based routing 방식으로 지원하고 있다.

expo-router 인트로 섹션

🛠 Native Stack Navigator 제품에 적용해보기

기존 제품은 Stack Navigator를 사용하고 있었기 때문에 Native Stack Navigator로 마이그레이션하기 위해서는 Stack Navigator의 Navigation Option을 Native Stack Navigator에 맞게 변경하는 작업이 가장 중요하게 진행되었다.

이러한 옵션중 가장 중요했던 부분은 presentation 옵션으로, presentation을 어떻게 정하느냐에 따라 화면전환 애니메이션, 화면 렌더링 스타일이 달라지게 된다.

Stack Navigator의 presentation 옵션

stack navigator에서는 card, modal, transparent modal 3가지 옵션을 사용할 수 있다.

card: 기본 화면전환 방식으로, iOS와 Android에서 default OS animation으로 화면전환이 진행된다.
modal: 화면이 모달로 뜨는 방식으로, iOS와 android 모두 화면이 아래에서 위로 올라오는 방식으로 화면이 뜨게 된다.
transparent modal: 모달로 뜨는 화면이지만, 배경이 투명하게 되어있어 이전 화면이 보이게 된다.

[iOS Presentation별 화면전환 애니메이션]

Card	Modal	Transparent Modal

[Android Presentation별 화면전환 애니메이션]

Card	Modal	Transparent Modal

또한, stack Navigator의 경우 일반 View로 구현되는 화면이기 때문에 Card <-> Modal 화면간 이동이 자유로워 Card 위에 Modal화면이 쌓이고, Modal화면에 Card 화면이 다시 쌓일 수 있다.

[Card -> Modal -> Card2 -> TransparentModal 화면전환]

Native Stack Navigator의 presentation 옵션

Native Stack Navigator에서는 card, modal, transparent modal, contained modal, contained transparent modal, full screen modal, form sheet 7가지로 구분되어 있다.

iOS에서 사용하는 모달 스타일을 조금 더 세부적으로 설정할 수 있게 지원하고 있고, android에서는 모두 modal 또는 transparentModal로 fallback되어 처리된다.

card: 기본 화면전환 방식으로, iOS는 오른쪽에서 왼쪽으로 화면이 전환되고, Android는 OS 버전에 따라 다르게 화면전환 애니메이션이 진행된다.
modal: iOS는 네이티브 모달처럼 화면이 입체적으로 올라오는 형태의 모달을 가지고 아래에서 위로 화면이 나타나게 되지만, Android는 card와 동일한 애니메이션으로 화면이 전환된다. (관련 이슈)
transparent modal: 이전화면이 보이는 백그라운드로 보이는 모달형태의 화면이다.
contained modal: iOS는 UIModalPresentationCurrentContext 모달 스타일을 이용해 부모 크기에 따라 차지하게 되며, Android는 modal과 동일하게 처리된다.
contained transparent modal: iOS는 UIModalPresentationOverCurrentContext 모달 스타일을 이용해 부모 크기에 따라 차지하게 되며, Android는 transparent modal과 동일하게 처리된다.
fullScreenModal: iOS는 UIModalPresentationFullScreen 모달 스타일을 이용해 전체 화면을 차지하게 되고, 제스처로 제거되지 않는 특징을 가진다. Android는 modal과 동일하게 처리된다.
formSheet: iOS는 UIModalPresentationFormSheet 모달 스타일을 이용하고 Android는 modal과 동일하게 처리된다.

[iOS Presentation]

card	modal

transparent modal	contained modal

contained transparent modal	fullScreen modal

formSheet

[android Presentation (Android 14, API Level 34)]

card	modal

transparent modal	contained modal

contained transparent modal	fullScreen modal

formSheet

stack Navigator와 다르게 Native 요소들을 이용해 화면을 구현하기 때문에 모달은 항상 Navigation History의 마지막에 와야하는 조건이 있다. 이 조건을 지키지 않으면 Card 화면이 Modal 화면 뒤에 쌓여 보이지 않는 현상이 발생한다.

[Card -> Modal -> Card2 화면전환 ]

위 예시를 보면 Modal 이후 Card2로 화면전환을 진행하게 되면, Card2가 Modal 화면 뒤에 쌓이게 되어 보이지 않는 현상이 발생한다. navigation pop을 클릭하게 되면, Card2가 먼저 제거되고, 이후 Modal 화면이 제거되는 현상을 확인할 수 있다.

React Navigation의 가이드에 따르면 모달 화면은 항상 Navigation History의 마지막에 와야한다고 되어있는데, 이는 Native Stack Navigator의 특징으로 보여진다.

React Navigation의 가이드

제품 내 Navigator presentation 반영하기

그러면 이제 Native Stack Navigator의 presentation 옵션을 제품에 적용해보자.

Card

Stack Navigator와 동일하게 iOS와 Android 모두 동일하게 Card에 default Animation을 적용하기로 했다. iOS는 완전히 동일하게 동작해서 큰 고민이 없었지만 Android는 별도의 애니메이션을 주어야할 지 고민이 되었다. 그이유는 Android에서는 OS 버전에 따라 다른 화면전환 애니메이션이 진행되게 되고 기존과 다른 유저 경험에 대한 우려가 있었기 때문이다.

[Stack Navigator에 정의된 Transition Preset, Android 버전별 애니메이션 옵션]

/**
 * Standard Android navigation transition when opening or closing an Activity on Android < 9 (Oreo).
 */
export const FadeFromBottomAndroid: TransitionPreset = {
  gestureDirection: "vertical",
  transitionSpec: {
    open: FadeInFromBottomAndroidSpec,
    close: FadeOutToBottomAndroidSpec,
  },
  cardStyleInterpolator: forFadeFromBottomAndroid,
  headerStyleInterpolator: forFade,
}

/**
 * Standard Android navigation transition when opening or closing an Activity on Android 9 (Pie).
 */
export const RevealFromBottomAndroid: TransitionPreset = {
  gestureDirection: "vertical",
  transitionSpec: {
    open: RevealFromBottomAndroidSpec,
    close: RevealFromBottomAndroidSpec,
  },
  cardStyleInterpolator: forRevealFromBottomAndroid,
  headerStyleInterpolator: forFade,
}

/**
 * Standard Android navigation transition when opening or closing an Activity on Android 10 (Q).
 */
export const ScaleFromCenterAndroid: TransitionPreset = {
  gestureDirection: "horizontal",
  transitionSpec: {
    open: ScaleFromCenterAndroidSpec,
    close: ScaleFromCenterAndroidSpec,
  },
  cardStyleInterpolator: forScaleFromCenterAndroid,
  headerStyleInterpolator: forFade,
}

아래 GIF에서 기존은 가운데에서 퍼져나가는 형식(ScaleFromCenterAndroid)으로 화면이 전환된다면, Native Stack에서는 오른쪽에서 왼쪽으로 화면이 전환되는 것을 확인할 수 있다.

기존 안드로이드 화면전환	Native Stack 화면 전환

기존 ScaleFromCenterAndroid와 최대한 유사한 애니메이션으로 Fade 애니메이션을 처음 고민해봤지만, 여전히 기존과 다른게 느껴지는 것 같다는 동료분의 피드백을 받았고, 버전에 맞게 표준 애니메이션을 적용하는 default 옵션이 이후 유지보수 측면에서 좋을 것 같다는 좋은 조언을 해주셔서, Card 옵션을 그대로 적용하기로 했다.

Modal

작업 중 가장 이슈가 많았고, OS별로 기본적으로 제공하는 부분이 달라 고민이 많았던 작업 영역이었다.

OS별로 모달 옵션들을 정리해보면 iOS에서는 modal, contained modal, fullscreen modal, formsheet 4가지가 있고, android는 modal 한가지 옵션만 제공하지만 이슈가 있어서 추가적으로 애니메이션 옵션을 적용해야하는 상황이었다.

여기에 추가적으로 모달이 항상 Navigation History의 마지막에 와야하는 조건이 있어서, 이를 지키지 않으면 기존 제품과 다르게 화면이 보이지 않는 이슈가 발생해, card와 modal간 화면 전환의 자유도도 고민해야 했다.

결론적으로는 위에서 언급한 옵션들이 아닌 iOS와 Android 모두 Card 옵션에 slide_from_bottom 애니메이션을 적용한 형태로 적용하기로 했다.

왜 뜬금없이 Card냐는 의문이 들 수 있겠지만, android에 이슈로 인해 추가적인 애니메이션이 필수적으로 필요한 상황인 점과 기존 제품 내 Navigation History 관리 방식을 유지해 작업범위와 컨벤션을 지키는 것이 더 좋겠다는 점을 고려해 선택하게 되었다.

그러면 각 옵션들을 적용했을 때 발생했던 이슈들을 정리해보자.

Modal와 FormSheet

iOS에서는 modal와 formsheet 옵션을 적용했을 때, 기존 제품내 모달과 다르게 화면 전체를 차지하는게 아니라 일정 영역만 차지하고 위로 떠있는 형태를 가지게 되고, android는 card와 동일하게 화면 전환이 이루어지는 이슈가 있어 사용하지 못했다.

[제품내 모달과 Modal 옵션]

기존 제품내 모달 화면	modal iOS	modal android

[제품내 모달과 formsheet 옵션]

기존 제품내 모달 화면	formsheet iOS	formsheet android

Contained Modal과 FullScreen Modal

android는 card와 동일하게 화면 전환이 이루어지는 이슈가 동일하게 있지만, iOS에서는 contained modal과 fullscreen modal 옵션을 적용했을 때, 기존과 같이 화면이 전체를 차지하는 형태로 화면이 나타낼 수 있어 사용하려 했던 옵션이었다.

하지만 각 옵션은 적용에 있어 문제점들이 각각 존재했다. contained Modal의 경우에는 Navigation History의 마지막에 와야하는 조건을 위해 별도의 Nested Navigator로 모달들을 관리하는 비용이 컸다는 점으로 인해 사용하지 못했다.

fullscreen Modal 옵션은 card,modal간 화면 전환 이슈와 더불어, alert 모달을 상위에 띄워줄 수 없는 이슈가 있어 사용하지 못했다. 아래는 해당 상황을 위한 mimic 코드이다.

[fullscreen modal에서 Modal로 구현한 alert가 뜨지 않는 이슈를 위한 mimic 코드]

// zustand로 구현한 전역 모달 노출 코드
import { create } from "zustand"

export const useAlertModal = create(set => ({
  visible: false,
  show: () => set({ visible: true }),
  hide: () => set({ visible: false }),
}))

const App = () => {
  const visible = useAlertModal(state => state.visible)
  const close = useAlertModal(state => state.hide)
  const onPressClose = () => {
    close()
  }

  return (
    <SafeAreaView style={{ flex: 1 }}>
      {visible && (
        <Modal
          visible={visible}
          animationType={"fade"}
          transparent={true}
          onRequestClose={onPressClose}
        >
          <View
            style={{
              justifyContent: "center",
              alignItems: "center",
              backgroundColor: "white",
              flex: 1,
            }}
          >
            <Text>Modal이에요</Text>
            <Button title="닫기" onPress={onPressClose} />
          </View>
        </Modal>
      )}
      <NavigationContainer>
        <NativeStack />
      </NavigationContainer>
    </SafeAreaView>
  )
}

const FullscreenModal = ({ navigation }) => {
  const handlePress = () => {
    navigation.pop()
  }

  const show = useAlertModal(state => state.show)
  const showAlert = () => {
    show()
  }

  return (
    <SafeAreaView style={{ flex: 1 }}>
      <Button title="뒤로가기" onPress={handlePress} />
      <Button title="alert 띄우기" onPress={showAlert} />
    </SafeAreaView>
  )
}

Modal로 구현한 alert 컴포넌트가 상위에 뜨지 않는 이슈

이러한 이슈들로 인해 iOS와 Android 모두 Card 옵션에 slide_from_bottom 애니메이션을 적용한 형태로 적용하기로 했다.

slidefrombottom 속도 이슈 해결하기

이제 더이상 이슈가 없을 것이라 생각했지만 Card 옵션에 slide_from_bottom 옵션을 적용하는 방식에도 이슈가 있었다.

바로 모달이 뜨는 애니메이션 속도 이슈로 iOS에서는 duration을 옵션으로 정할 수 있게 제공하지만, android에서는 커스텀할 수 없어 기존과 체감이 될정도로 느리게 화면이 전환되는 이슈가 있었다.

animationDuration 공식문서

Android Stack Navigator Modal	Android Native Stack Card (slide_from_bottom)

눈에 띄게 느리다는 느낌이 들어 해당 부분을 해결하기 위해 React Navigation 내부 코드를 하나하나 분석하게 되었다.

먼저 NativeStackNavigator를 만들기 위한 createNativeStackNavigator를 보면 createNavigatorFactory 팩토리 함수에 NativeStackNavigator를 인자로 넘겨주는 방식으로 NativeStackNavigator를 만들고 있다.

//[참조 코드](https://github.com/react-navigation/react-navigation/blob/main/packages/native-stack/src/navigators/createNativeStackNavigator.tsx)
function NativeStackNavigator({...rest }: NativeStackNavigatorProps) {
    ...

    return (
        <NavigationContent>
            <NativeStackView
                {...rest}
                state={state}
                navigation={navigation}
                descriptors={descriptors}
            />
        </NavigationContent>
    );
}

export function createNativeStackNavigator<
    ParamList extends ParamListBase,
    NavigatorID extends string | undefined = undefined,
    TypeBag extends NavigatorTypeBagBase = {
        ParamList: ParamList;
        NavigatorID: NavigatorID;
        State: StackNavigationState<ParamList>;
        ScreenOptions: NativeStackNavigationOptions;
        EventMap: NativeStackNavigationEventMap;
        NavigationList: {
            [RouteName in keyof ParamList]: NativeStackNavigationProp<
                ParamList,
                RouteName,
                NavigatorID
            >;
        };
        Navigator: typeof NativeStackNavigator;
    },
    Config extends StaticConfig<TypeBag> | undefined =
            | StaticConfig<TypeBag>
        | undefined,
>(config?: Config): TypedNavigator<TypeBag, Config> {
    return createNavigatorFactory(NativeStackNavigator)(config);
}

내가 궁금한건 스크린이 어떻게 만들어지냐니까 이제 NativeStackView 코드 내부를 보게 되면 React Native Screens에서 Screen, ScreenStack 컴포넌트를 받아서 prop을 전달하는 방식으로 wrapping하고 있다는 것을 알 수 있었다.

//[참조 코드](https://github.com/react-navigation/react-navigation/blob/main/packages/native-stack/src/views/NativeStackView.native.tsx):`react-navigation/packages/native-stack/src/views/NativeStackView.native.tsx`)
//...
import {
    Screen,
    type ScreenProps,
    ScreenStack,
    type StackPresentationTypes,
} from 'react-native-screens';
//...


const MaybeNestedStack = (props) => {
    //...
    if (isHeaderInModal) {
        return (
            <ScreenStack style={styles.container}>
                <Screen
                    enabled
                    isNativeStack
                    hasLargeHeader={options.headerLargeTitle ?? false}
                    style={StyleSheet.absoluteFill}
                >
                    {content}
                    <HeaderConfig
                        {...options}
                        route={route}
                        headerHeight={headerHeight}
                        headerTopInsetEnabled={headerTopInsetEnabled}
                        canGoBack
                    />
                </Screen>
            </ScreenStack>
        );
    }

    return content;
};

const SceneView = (props) => {
    //...
    return (
        <Screen
            key={route.key}
            enabled
            isNativeStack
            style={StyleSheet.absoluteFill}
            hasLargeHeader={options.headerLargeTitle ?? false}
            customAnimationOnSwipe={animationMatchesGesture}
            fullScreenSwipeEnabled={fullScreenGestureEnabled}
            // ... 기타 props
        >{...}</Screen>
    );
};

type Props = {
    state: StackNavigationState<ParamListBase>;
    navigation: NativeStackNavigationHelpers;
    descriptors: NativeStackDescriptorMap;
};

export function NativeStackView({ state, navigation, descriptors }: Props) {
    ...
    return (
        <SafeAreaProviderCompat style={{ backgroundColor: colors.background }}>
            <ScreenStack style={styles.container}>
                {state.routes.map((route, index) => {
                    //...
                    return (
                        <SceneView
                            key={route.key}
                            index={index}
                            focused={isFocused}
                            descriptor={descriptor}
                            previousDescriptor={previousDescriptor}
                            nextDescriptor={nextDescriptor}
                            isPresentationModal={isModal}
                            // 기타 props
                        />
                    );
                })}
            </ScreenStack>
        </SafeAreaProviderCompat>
    );
}

실제 애니메이션 속도를 변경하기 위해서는 React Navigation 코드가 아니라 React Native Screens 패키지 내부 코드를 수정해야하는 것을 알게 되었다. 그래서 React Navigation에서 Native Stack의 이슈는 React Native Screens 레포에 올려달라했구나 이해가 되었다.

React Native Screens로 안내하는 React Navigation 공식문서

이어서 React Native Screens 패키지 내부 코드를 분석하게 되었고, 아래와 같이 Screen 코드를 간단하게 나타낼 수 있고, Screen 컴포넌트는 ScreenNativeComponent를 만들어지는 것을 볼 수 있다.

//[참조 코드](react-native-screens/src/components/Screen.tsx)
// ...
import ScreenNativeComponent from "../fabric/ScreenNativeComponent"
import ModalScreenNativeComponent from "../fabric/ModalScreenNativeComponent"

export const NativeScreen: React.ComponentType<ScreenProps> =
  ScreenNativeComponent as React.ComponentType<ScreenProps>
const AnimatedNativeScreen = Animated.createAnimatedComponent(NativeScreen)

// ...

const Screen: React.FC<ScreenProps> = props => {
  // ...
  return <AnimatedNativeScreen {...props} />
}

export default Screen

그리고 ScreenNativeComponent 코드를 보게 되면, Screen 컴포넌트를 만들어주는 코드를 찾을 수 있었다. 아래 코드는 codegen을 이용해 Screen 컴포넌트를 iOS와 Android를 빌드할 때 자동으로 생성하기 위한 인터페이스들이 정의되어 있는 코드이다. 이제 codegen을 통해 만들어진 해당 코드 부분을 찾아가면 드디어 내가 원하는 안드로이드 애니메이션 속도를 변경할 수 있을 것이라고 생각할 수 있었다.

//[참조코드](react-native-screens/src/fabric/ScreenNativeComponent.ts)
import codegenNativeComponent from "react-native/Libraries/Utilities/codegenNativeComponent"
// ...

type StackPresentation =
  | "push"
  | "modal"
  | "transparentModal"
  | "fullScreenModal"
  | "formSheet"
  | "containedModal"
  | "containedTransparentModal"

type StackAnimation =
  | "default"
  | "flip"
  | "simple_push"
  | "none"
  | "fade"
  | "slide_from_right"
  | "slide_from_left"
  | "slide_from_bottom"
  | "fade_from_bottom"
  | "ios"

// ...
export default codegenNativeComponent<NativeProps>("RNSScreen", {
  interfaceOnly: true,
})

드디어 rnscreens 내부의 ScreenStack 코드에서 애니메이션 설정 코드를 발견할 수 있었다. 그중 내가 찾던 slide_from_bottom애니메이션은 R.anim.rns_slide_in_from_bottom, R.anim.rns_no_animation_medium으로 정의되어 있었다.

[참고 코드](react-native-screens/android/src/main/java/com/swmansion/rnscreens/ScreenStack.kt)
class ScreenStack(context: Context?) : ScreenContainer(context) {
    ...
    override fun onUpdate() {
        ...
        createTransaction().let {
            // animation logic start
            if (stackAnimation != null) {
                if (shouldUseOpenAnimation) {
                    when (stackAnimation) {
                        StackAnimation.DEFAULT -> it.setCustomAnimations(R.anim.rns_default_enter_in, R.anim.rns_default_enter_out)
                        StackAnimation.NONE -> it.setCustomAnimations(R.anim.rns_no_animation_20, R.anim.rns_no_animation_20)
                        StackAnimation.FADE -> it.setCustomAnimations(R.anim.rns_fade_in, R.anim.rns_fade_out)
                        StackAnimation.SLIDE_FROM_RIGHT -> it.setCustomAnimations(R.anim.rns_slide_in_from_right, R.anim.rns_slide_out_to_left)
                        StackAnimation.SLIDE_FROM_LEFT -> it.setCustomAnimations(R.anim.rns_slide_in_from_left, R.anim.rns_slide_out_to_right)
                        StackAnimation.SLIDE_FROM_BOTTOM -> it.setCustomAnimations(
                            R.anim.rns_slide_in_from_bottom, R.anim.rns_no_animation_medium
                        )
                        StackAnimation.FADE_FROM_BOTTOM -> it.setCustomAnimations(R.anim.rns_fade_from_bottom, R.anim.rns_no_animation_350)
                        StackAnimation.IOS -> it.setCustomAnimations(R.anim.rns_slide_in_from_right_ios, R.anim.rns_slide_out_to_left_ios)
                    }
                } else {
                    when (stackAnimation) {
                        StackAnimation.DEFAULT -> it.setCustomAnimations(R.anim.rns_default_exit_in, R.anim.rns_default_exit_out)
                        StackAnimation.NONE -> it.setCustomAnimations(R.anim.rns_no_animation_20, R.anim.rns_no_animation_20)
                        StackAnimation.FADE -> it.setCustomAnimations(R.anim.rns_fade_in, R.anim.rns_fade_out)
                        StackAnimation.SLIDE_FROM_RIGHT -> it.setCustomAnimations(R.anim.rns_slide_in_from_left, R.anim.rns_slide_out_to_right)
                        StackAnimation.SLIDE_FROM_LEFT -> it.setCustomAnimations(R.anim.rns_slide_in_from_right, R.anim.rns_slide_out_to_left)
                        StackAnimation.SLIDE_FROM_BOTTOM -> it.setCustomAnimations(
                            R.anim.rns_no_animation_medium, R.anim.rns_slide_out_to_bottom
                        )
                        StackAnimation.FADE_FROM_BOTTOM -> it.setCustomAnimations(R.anim.rns_no_animation_250, R.anim.rns_fade_to_bottom)
                        StackAnimation.IOS -> it.setCustomAnimations(R.anim.rns_slide_in_from_left_ios, R.anim.rns_slide_out_to_right_ios)
                    }
                }
            }

            ...
        }
    }
}

이제 진짜 마지막으로 해당 xml 파일을 찾아 duration부분을 수정하고 patch package를 진행해 애니메이션 속도를 변경할 수 있었다. 기존 duration은 config_mediumAnimTime으로 설정되어 있었고, 해당 부분을 수정하면 커스텀하게 수정이 가능하게 되었다.

animation duration은 react-native-screens에서 20,250,350을 기본 값으로 설정해두고 있는 것으로 보여, 250으로 변경해 적용하게 되었다.

<!--[참고 코드](react-native-screens/android/src/main/res/base/anim/rns_slide_in_from_bottom.xml)-->
<?xml version="1.0" encoding="utf-8"?>
<translate xmlns:android="http://schemas.android.com/apk/res/android"
    android:fromYDelta="100%"
    android:toYDelta="0%"
    android:duration="@android:integer/config_mediumAnimTime" /> <!--250으로 변경 -->

<!--[참고 코드](react-native-screens/android/src/main/res/base/anim/rns_slide_out_to_bottom.xml)-->
<?xml version="1.0" encoding="utf-8"?>
<translate xmlns:android="http://schemas.android.com/apk/res/android"
    android:fromYDelta="100%"
    android:toYDelta="0%"
    android:duration="@android:integer/config_mediumAnimTime" /> <!--250으로 변경 -->

<!--[참고 코드] (react-native-screens/android/src/main/res/base/anim/rns_no_animation_medium.xml)-->
<?xml version="1.0" encoding="utf-8"?>
<alpha xmlns:android="http://schemas.android.com/apk/res/android"
    android:fromAlpha="1.0"
    android:toAlpha="1.0"
    android:duration="@android:integer/config_mediumAnimTime"/> <!--250으로 변경 -->

개선 전 Android Native Stack Card (slide_from_bottom)	개선 후 Android Native Stack Card (slide_from_bottom)

시간상 하지 못했지만, 조금 더 모달 애니메이션을 개선하면 좋았을 것 같다는 아쉬운 생각이 들었다. 기존에는 끝에 점점 천천히 도착하는 듯한 효과가 있었지만 지금은 linear하게 한번에 뜨고 닫히는 것 같아 어색함이 남아있어보였다. 이후에 더 native스러운 느낌을 줄 수 있게 후작업으로 개선 작업도 진행해보려 한다.

TransparentModal

기존 일부 화면에서 사용되고 있던 transparent modal 옵션을 containedTransparentModal을 이용해 최대한 사용하려 했지만, 다음 화면이 card인 경우에 애니메이션이 버벅이는 듯한 이슈가 발생하게 되었다. 이를 해결하기 위해서 transparent modal 옵션 대신 기존 화면을 바텀시트 컴포넌트를 이용해 구현하는 방식으로 수정하게 되었다.

이렇게 수정했을 때 기존은 모달이지만 서서히 fade in/fade out으로 화면전환이 되었지만, 바텀시트로 변경하면서 overlay가 보이는 모달 느낌이 더 들 수 있어 좋은 선택이라 생각이 들었다.

제품 내 모든 transparent modal 옵션을 사용하던 화면들을 다 바꾸지는 못했고, 이슈가 있었던 화면만 수정하게 되었지만, 다음화면에 따라 화면전환 애니메이션에 이슈가 있을 수 있어 후작업을 진행해야할 것 같다.

이슈가 되었던 transparent modal	BottomSheet으로 전환한 transparent modal

기타 이슈: gesture handler로 사진 끌어당겨 닫기 이슈

해당 이슈는 첫번째 배포 때 롤백하게 된 가장 컸던 이슈로 이미지 슬라이더를 보고 끌어당겨 해당 화면을 pop한 후에, 제품 내 메인 퍼널 중 하나인 요청서 작성화면에 진입한 경우에 질문이 10개만 렌더링되는 이슈가 발생했다.

이미지를 끌어당겨 종류할 수 있게 하기 위해 PanResponder를 이용해 구현했는데, PanResponder로 끌어당겨 navigation.pop을 진행하게 하는 동작에서 문제가 발생하는 것으로 보였다.

해당 이슈를 해결하는 과정에서 FlatList로 구현된 요청서 작성화면의 요소가 Flatlist의 initialNumToRender prop의 default 값처럼 딱 10개만 항상 렌더링되는 것을 근거로 FlatList 내부 코드를 확인해보게 되었다.

Flatlist는 VirtualizedList를 상속받아 구현되어 있고, VirtualizedList는 다음 목록을 가져오기 위해서 Batchinator를 이용해 다음 목록을 받아오게된다. 이때 Batchinator는 InteractionManager의 runAfterInteractions 메소드를 이용해 다음 목록을 받아오게 구현되어 있었다.

[ Batchinator 코드]

class Batchinator {
  _callback: () => void;
  _delay: number;
  _taskHandle: ?{cancel: () => void, ...};
  constructor(callback: () => void, delayMS: number) {
    this._delay = delayMS;
    this._callback = callback;
  }
  /*
   * Cleanup any pending tasks.
   *
   * By default, if there is a pending task the callback is run immediately. Set the option abort to
   * true to not call the callback if it was pending.
   */
  dispose(options: {abort: boolean, ...} = {abort: false}) {
    if (this._taskHandle) {
      this._taskHandle.cancel();
      if (!options.abort) {
        this._callback();
      }
      this._taskHandle = null;
    }
  }
  schedule() {
    if (this._taskHandle) {
      return;
    }
    const timeoutHandle = setTimeout(() => {
      this._taskHandle = InteractionManager.runAfterInteractions(() => {
        // Note that we clear the handle before invoking the callback so that if the callback calls
        // schedule again, it will actually schedule another task.
        this._taskHandle = null;
        this._callback();
      });
    }, this._delay);
    this._taskHandle = {cancel: () => clearTimeout(timeoutHandle)};
  }
}

module.exports = Batchinator;

이미지를 끌어당겨 종료하기 위해 사용되는 PanResponder 또한 내부 적으로 InteractionManager를 이용하는데 이때 gesture 방해를 막기위해 JS 이벤트를 blocking하게 구현되어 있다.

pan responder 주석

이를 근거로 자세한 동작과 충돌 과정은 파악하지 못했지만 이미지를 끌어당겨 종료하는 이벤트를 처리하는 과정에서 Interaction Manager가 blocking되어 FlatList의 InteractionManager가 동작하지 못하게 막아서 발생하는 이슈로 추측할 수 있었다.

해당 이슈를 해결하게 위해서 Pan Responder의 interaction 도중에 navigation.pop이 진행되게 하는게 아니라 Interaction이 모두 끝난 후에 진행되게 해 문제를 해결할 수 있었다.

    const panResponder = useRef(
        PanResponder.create({
            ...,
            onPanResponderGrant: () => {
                // PanGesture가 완료되고 난 이후에 화면 이동을 동작시켜 InteractionManager간 충돌을 막습니다.
                InteractionManager.runAfterInteractions(() => {
                        navigation.goBack();
                });
            },
        }),
    ).current;

⭐️ 적용 후 성능 분석

이제 적용 후 성능 분석을 진행한 내용을 정리해보려 한다. 화면 전환간 성능을 개선한다는 목표를 가지고 작업을 진행했다 보니 지표적으로 명확하게 보여줄 방법이 크게 없어 어려움을 느꼈다.

고민 끝에 정했던 방법은 총 3가지로, 먼저 간단하게 실제 제품 내 메인 퍼널들에 대한 영상을 찍어서 전/후 비교를 진행했고, 다음으로 직접적이지는 않지만 애니메이션 처리 과정에 필요한 CPU 사용량과 memory 사용량을 보기 위해 android에서 웹의 light house처럼 성능측정을 할 수 있는 flash light을 이용해 메인 퍼널들에 대한 지표를 측정해보았다. 그리고 추가적으로 화면 stack이 최대 100개가 되었을 때도 정상적으로 애니메이션을 처리할 수 있을지 보기 위해 stress 테스트를 진행해보았다.

영상을 통한 전/후 비교

영상을 통한 전/후 비교는 가장 직관적으로 보여줄 수 있는 방법이라고 생각했다. 영상을 찍어서 전/후 비교를 진행했고, 이를 통해 애니메이션의 자연스러움과 끊김이 있는지, 또한 화면 전환 속도가 빨라졌는지 확인할 수 있었다.

아래는 메인 퍼널 중 하나인 고객홈 -> 메인 카테고리 까지 넘어가는 과정을 Android (Galaxy22)에서 찍은 영상이다.

AS-IS	TO-BE

영상을 비교해보았을 때 이전보다 조금 더 부드럽게 전환되고 화면전환 이벤트 처리가 빨라진 것을 느낄 수 있었다.

FlashLight를 이용한 성능 측정

영상을 찍는데에서 끝내지 않고 최대한 숫자로, 지표로 분석해보면 조금 더 좋지 않을까 생각해 flash light를 이용해 성능 측정을 진행해보았다. flash light와 maestro e2e 자동화 코드를 이용해 측정해보았고, 앱을 시작해서 위에서 영상으로 찍었던 메인 퍼널 시나리오에 대해 각각 30번 진행했을 때 성능 지표를 측정했다.

홈 -> 메인 카테고리 전/후
modal
받은 요청 목록 -> 받은 요청 상세 전/후
modal
받은 견적 목록 -> 받은 견적 상세 -> 견적서 상세 전/후
modal
채팅방 목록 -> 채팅방 AS-IS
modal

성능 지표를 분석해보았을 때 퍼널 별로 오르락 내리락 하는 부분들이 있지만, CPU 사용량과 Memory 사용량이 대부분 감소했고 이는 애니메이션 처리 과정에서 더 효율적으로 처리되고 있다는 것을 의미한다고 볼 수 있었다.

그리고 추가적으로 분석해보았을 때 받은견적 목록 -> 받은 견적 상세 -> 견적서 상세 전환에서 다른 퍼널과 다르게 전체적인 지표 모두 좋아진 것을 볼 수 있었다. 퍼널간 차이점을 보았을 때 측정했던 퍼널 중 가장 긴 퍼널이었다는 점을 고려해 Navigation stack이 쌓일수록 더 효율적으로 처리하고 있다는 것을 알 수 있었다.

이러한 특징을 눈으로 더 명확하게 확인해보기 위해서 Navigation stack이 100개가 되었을 때도 성능이 좋아지는지 확인해보는 건 어떨까라는 호기심이 생겨 stress 테스트를 이어서 진행해보았다.

Stress 테스트를 통한 성능 확인

stress 테스트는 10개, 30개, 50개, 75개, 100개 까지 stack에 화면이 쌓였을 때 어떻게 화면전환이 되는지를 촬영해보았고, 영상 상단에 navigation stack의 길이를 표시해 현재 몇개 stack이 쌓였는지 확인할 수 있게 했다. 아래 영상은 Android Galaxy22 기기에서 측정한 결과다.

Stack Navigator 10개	Stack Navigator 50개	Stack Navigator 100개

Native Stack Navigator 10개	Native Stack Navigator 50개	Native Stack Navigator 100개

Stack Navigator는 stack이 쌓일수록 화면전환 속도가 느려지는 것을 확인할 수 있었고, Native Stack Navigator는 stack이 쌓여도 유사한 속도로 화면전환이 진행되는 것을 볼 수 있었다.

촬영과정에서 기기에서 느껴지는 발열도 Native Stack Navigator가 더 낮은 것을 느낄 수 있었고, 이는 CPU 사용량과 Memory 사용량이 줄어들어 성능이 향상되었다는 것을 체감할 수 있었다.

📚 배운점

여태까지 진행했던 프로젝트 중에서 가장 이슈가 많았던 작업이었고, 다행히 잘 해결해서 현재 잘 제품에 반영되어 있어 뿌듯했다.

단순 Javascript 런타임만 고민하는게 아니라 모바일 플랫폼에 특화된 성능 개선을 적용할 수 있어 좋았고, 잘 만들어진 오픈 소스 라이브러리들을 내부구조도 파헤치는 좋은 경험이 되어 이후에 React Navigation에도 기여하고 싶은 마음도 생겼다.

적용하면서 성능이 개선되었는지 확인하기 위해 다양한 방법을 사용해보았는데, 영상을 찍어 전/후 비교를 하는 것이 가장 직관적이었다. 나름 숫자로 표현하기 위해 노력해보았지만 어느정도 한계가 있었다. 하지만, 메모리나 CPU 사용량과 같이 이전에 관심을 두지 않았던 하드웨어 스펙에 대해서도 관심을 가지게 되었고, 이를 통해 성능을 개선하는데 도움이 되었다.

물론 여전히 남겨진 일들이 있지만, 하나의 또 큰 일감을 잘 마무리하고 사용자 경험과 성능 모두 개선할 수 있었던 좋은 작업이었다고 생각되었다.

🤭 2024년 6월회고

Sun, 30 Jun 2024 00:00:00 GMT

2분기를 마무리하면서 6월 한달 간 진행했던 스쿼드 업무, 챕터 업무 및 5월달의 action item들을 정리해보고 다음 분기를 위해 어떤 부분들을 더 공부하면 좋을지 개선하면 좋을지 정리해보려 한다.

5월 회고 돌아보기

5월에 삼았던 action item들을 정리해보면 아래와 같다.

화면전환 간 성능 개선을 위해 Native Stack 도입 및 성능 분석방법 찾아보기
에러 바운더리를 조금 더 챕터원들이 쉽게 적용하는 방법 고민해보기
컴포넌트 설계 정리
못했던 작업 진행해보기: 리액트 내부 코드 분석, UI 패턴별 최적화 정리해보기
3분기 일감 발제하기: 선언적으로 인증/인가 관리하기, Async Storage 대체하기

이중 리액트 내부 코드 분석은 Native Stack 적용을 위해 React Navigation과 React Native Screens 패키지를 분석하는데 시간을 쏟다보니 하지못했다. 3분기 일감으로 생각했던 선언적으로 인증/인가 관리하기는 이보다 Native Stack을 적용하면서 여러 퍼널들을 겪으면서 화면전환간 로딩을 개선하는게 조금 더 유저경험에 도움이 될 것 같아 미루게 되었다. 대신 Async Storage를 mmkv로 대체하는 일감은 챕터업무로 발탁되어 3분기에 담당자로 진행하게 되었다.

이제 5월의 action item들을 진행했던 6월의 작업들을 정리해보자.

6월의 작업들

🚀 Native Stack 적용하기

React Navigation의 Stack Navigator에서 Native Stack Navigator를 적용해 화면전환간 성능을 개선하는 작업으로 6월 26일 배포되면서 마무리하게 되었다. 원래 배포는 6월 12일로 예정되어 있었지만, QA과정에서 애니메이션이 끊기는 이슈와 gesture handler로 사진을 끌어당겨 닫은 이후에, 요청서 화면에서 10개의 질문만 렌더링되는 이슈가 있어 롤백하게 되었는데 해당 이슈를 해결하고 다시 배포하게 되었다. 해당 이슈들에 대해 간단하게 정리해보려 한다.

애니메이션 끊김 이슈

애니메이션이 끊겼던 이슈는 overlay가 있는 회원가입 안내 모달 화면에서 발생하게 되었다. 해당 화면은 transparent modal로 되어있었는데 Card로 된 다음 화면으로 전환할 때 애니메이션이 끊기는 듯한 현상이 나타났다.

이를 해결하기 위해서 transparent modal 대신 바텀 시트를 사용해 화면을 구현하는 방식으로 수정했고, 해당 이슈를 통해 Native Stack에서 transparent modal의 경우 다음 화면이 어떤 것인지에 따라 애니메이션이 끊겨보일 수 있어, bottomTab이 있는 홈 화면이 아니면 바텀시트로 구현하는 것이 좋다는 것을 알게 되었다.

gesture handler로 사진 끌어당겨 닫기 이슈

이미지를 보고 끌어당겨 종료한 후에, 제품 내 메인 퍼널 중 하나인 요청서 작성화면에서 질문이 10개만 렌더링되는 이슈가 발생했다. 해당 이슈는 롤백을 하게 되는 가장 큰 이유가 된 이슈로, React Native의 Interaction Manager와 관련된 이슈였다.

이미지를 끌어당겨 종류할 수 있게 하기 위해 PanResponder로 구현했는데, PanResponder로 끌어당김 이벤트가 종료되는 시점에 navigation.pop을 진행하면서 StackNavigator에서는 발생하지 않았던 이슈가 Native Stack에서 발생했다. 해당 이슈를 해결하는 과정에서 FlatList로 구현된 요청서 작성화면의 요소가 Flatlist의 initialNumToRender prop의 default 값처럼 딱 10개만 항상 렌더링되는 것을 근거로 삼아 내부 코드를 확인해보게 되었다.

Flatlist는 VirtualizedList를 상속받아 구현되어 있고, VirtualizedList는 다음 목록을 가져오기 위해서 Batchinator를 이용해 다음 목록을 받아오게된다. 이때 Batchinator는 InteractionManager를 이용해 InteractionManager.runAfterInteractions를 이용해 다음 목록을 받아오게 되는 것을 알게 되었다.

[ Batchinator 코드]

class Batchinator {
  _callback: () => void;
  _delay: number;
  _taskHandle: ?{cancel: () => void, ...};
  constructor(callback: () => void, delayMS: number) {
    this._delay = delayMS;
    this._callback = callback;
  }
  /*
   * Cleanup any pending tasks.
   *
   * By default, if there is a pending task the callback is run immediately. Set the option abort to
   * true to not call the callback if it was pending.
   */
  dispose(options: {abort: boolean, ...} = {abort: false}) {
    if (this._taskHandle) {
      this._taskHandle.cancel();
      if (!options.abort) {
        this._callback();
      }
      this._taskHandle = null;
    }
  }
  schedule() {
    if (this._taskHandle) {
      return;
    }
    const timeoutHandle = setTimeout(() => {
      this._taskHandle = InteractionManager.runAfterInteractions(() => {
        // Note that we clear the handle before invoking the callback so that if the callback calls
        // schedule again, it will actually schedule another task.
        this._taskHandle = null;
        this._callback();
      });
    }, this._delay);
    this._taskHandle = {cancel: () => clearTimeout(timeoutHandle)};
  }
}

module.exports = Batchinator;

pan responder 주석

이를 근거로 자세한 동작과 충돌 과정은 파악하지 못했지만 이미지를 끌어당겨 종료하는 이벤트가 발생 후 Interaction Manager가 blocking되어 FlatList의 InteractionManager가 동작하지 못하게 막아서 발생하는 이슈로 추측할 수 있었다. 그래서 Pan responder의 interaction 도중에 navigation.pop이 진행되게 하는게 아니라 Interaction이 모두 끝난 후에 진행되게 해 문제를 해결할 수 있었다.

    const panResponder = useRef(
        PanResponder.create({
            ...,
            onPanResponderGrant: () => {
                // PanGesture가 완료되고 난 이후에 화면 이동을 동작시켜 InteractionManager간 충돌을 막습니다.
                InteractionManager.runAfterInteractions(() => {
                        navigation.goBack();
                });
            },
        }),
    ).current;

이렇게 두가지 추가 이슈를 모두 마친 이후에 6월 26일 배포를 진행하게 되었다.

성능 분석하기

일감의 목표가 화면전환간 성능개선이었다보니, 어떻게 측정 기준을 잡아야할 지 막막함이 있었다. 왜냐하면 대부분의 상황에서는 JS 스레드에서 애니메이션을 진행하든 UI 스레드에서 애니메이션을 진행하든 큰 차이가 보이지 않을 것으로 예상되었기 때문이다. 어떻게 하면 수치적으로 나타낼 수 있을까 고민끝에 화면전환과 직접적으로 관련된 것은 아니지만 CPU와 메모리 사용량을 비교해보기로 했다.

측정방법은 FlashLight와 maestro를 이용한 e2e 테스트를 사용했다.FlashLight는 현재 안드로이드만 지원하고 있어 안드로이드를 기준으로, 제품 내 고객, 고수 분들이 가장 많이 사용하는 퍼널들을 사용했다. 총 30회 반복 측정을 진행했고, 아래는 측정한 받은 견적 목록 도메인의 화면 전환간 성능을 측정한 결과이다.

받은 견적 화면전환 성능 측정 결과

사진은 측정한 퍼널 중 하나의 퍼널 데이터이지만, 총 4가지 퍼널을 측정했을 때 CPU 사용량과 RAM 사용량은 전반적으로 감소되었다.

결과를 분석하다보니 짧은 퍼널일 때보다 퍼널이 길어질 수록 차이가 더 심해지는 것을 알게되어, 페이지가 많아져 메모리 사용량이 많아졌을 때 애니메이션이 정상적을 동작하는지 보기 위해 Stress 테스트도 추가로 진행했다.

측정 방법은 stack에 최대 100개까지 화면이 쌓여있는 경우에 101번째 화면으로 진입할 때 애니메이션을 영상으로 찍어보았다. 영상 상단의 숫자는 Navigator에 쌓여있는 페이지 숫자를 의미한다.

[페이지가 stack에 10개/100개가 쌓였을 때 화면 전환 애니메이션]

Stack Navigator	Native Stack Navigator

stack Navigator의 경우 100개가 되었을 때 클릭 이벤트처리부터 화면전환까지 10개 때와 비교해 눈에 띄게 느려진 것을 볼 수 있었고, 그에 반해 Native Stack Navigator의 경우 큰 차이 없이 자연스럽게 처리되는 것을 볼 수 있었다.

추가로 테스트를 진행하면서 기기의 발열감을 느낄 수 있었는데 이는 stack Navigator의 경우 화면이 많아질수록 메모리 사용량이 늘어나고, 메모리 사용량이 늘어나면서 CPU 사용량이 늘어나게 되어 발열이 느껴지는 것으로 추측된다. 더 자세한 데이터는 Native Stack을 주제로 글을 작성하며 함께 공유할 예정이다.

Native Stack을 적용을 마치고 결과를 챕터원 분들께 공유드렸을 때, 받았던 질문이 몇가지 있었다.

React Navigation에서 React-native-screens가 사용되는 방식
실제 Native 요소가 사용되는 것과 RN의 View로 화면을 만들었을 때 차이점

당시 답변을 드리지 못했고, 개인적으로도 궁금한 부분이기 떄문에 이에 대한 답변들을 계속해서 찾으며 공부해보고 있고, Native Module에 대한 공부를 추가적으로 진행해서 간단한 패키지를 mimic해서 만들어 글과 함께 정리해볼 예정이다.

2분기 챕터 OKR이었던 Native Stack 적용을 잘 마무리해서 기쁘고, 잘 마무리할 수 있었던 이유는 첫 배포 당시 이슈 파악을 위해 많은 챕터원분들께서 함께 도와주셔서 이후에 두번째 배포때는 문제없이 안정적으로 배포될 수 있었다. 개인적으로 React Navigation에 대해 많이 공부할 수 있었고, Native 코드도 많이 보고 동작을 이해하는 계기가 되었다.

조금 아쉬웠던 부분은 개선된 결과를 숫자로 표현하기 어려움이 있었다는 점이었다. 애니메이션과 메모리/CPU사용량에 대한 관계를 더 잘 공유하고, 이를 측정하는 작업들을 선행했다면 성과분석에 더 좋았을 것이라는 아쉬움도 남았다.

에러 바운더리 적용작업 마무리

드디어 에러바운더리 적용작업도 완료했다. 5월에 고민했던 새로운 화면들이 추가되었을 때 어떻게 적용할 수 있을지 고민했던 부분을 위한 작업들도 추가로 진행했다. 현재 적용된 화면과 적용되지 않은 화면들을 파악할 수 있는 script를 추가했고, 새로운 화면을 생성할 때 자동으로 에러바운더리가 적용되도록 하는 작업을 진행했다. 자세한 시행착오들을 에러바운더리 도입하기에 작성해보았다.

하나의 화면에 적용하는 작업은 간단하지만 제품 전체에 적용하면서 다양한 케이스들을 고민하고 적용하는 것은 생각보다 어려운 작업이었다. 그리고 동료의 학습비용을 줄이기 위한 고민들을 하면서, 지속적인 공유가 필요한 이유를 느낄 수 있었다.

그래도 3분기에 거쳐 해온 에러/예외처리 고도화 작업을 마무리하면서 긴 호흡의 하나의 작업을 완료했다는 점에 뿌듯함을 느낄 수 있었다.

컴포넌트 설계

5월에 작업했던 composition 컴포넌트 설계 공부를 하고 적용한 고수 프로필 컴포넌트를 동료분들께 어떻게 변경되었고 어떤 점을 고려해서 리팩토링했는지 전달드리려 했지만, Native Stack과 에러바운더리 적용작업에 많은 시간을 쓰다보니, 자연스럽게 후순위로 밀리게 되었다.

다행히 스쿼드 작업을 진행하면서 작업한 컴포넌트를 내가 직접 사용하게 되었다. 수정 당시에는 이렇게 사용되면 좋겠다 하며 설계했던 부분이 기존에 없던 요구사항을 적용하면서 어려움을 만들기도 했다. 1차로는 완료했지만 아직 개선해야할 부분들이 많아 조금 더 공부하고 적용해서 8월 내로 꼭 전달해보려 한다.

UI 패턴별 최적화 정리하기

스쿼드 작업을 진행하면서 신규 폼 화면을 구현하게 되었다. 여러가지 스텝을 통해 데이터를 모으고 마지막에 전달하는 설문조사 패턴으로 앞서 토스 슬래시 발표를 보면서 공부했던 내용을 적용해려 했다. 하지만 기존 챕터 내 컨벤션은 전역 상태와 화면들간의 결합도를 낮추기 위해서 최대한 스크린 단위로 데이터를 관리하는 방식으로 이루어져 있기 때문에 설문조사 패턴을 적용하기는 어려웠다.

그래서 우선은 각 스텝별 화면에서 데이터를 param으로 전달하는 기존 방식대로 구현을 했고, 3분기에 기존 파편화되어있던 화면간의 데이터 공유 문제를 해결하기 위한 작업들이 예정되어 있기 때문에 조금씩 의견들을 제시해보고 다시 적용해보려한다.

추가적으로는 input 컴포넌트들을 사용하면서 키보드에 따라 어떻게 스크롤을 관리할지, 각종 에러 상황, 로딩상황 등 다양한 유즈케이스들을 정리하면서 유저경험을 개선하기 위한 많은 고민들을 해보려 했다.

Async Storage 대체하기

3분기 챕터 업무를 기획하면서 5월에 고민했던 Async Storage를 mmkv로 적용하는 작업을 발제했다. mmkv를 적용했을 때 두가지 장점을 기대하고 작업을 발제했다.

Async Storage 보다 빠른 속도 (유저 경험 향상)
Async Storage 사용시 필요했던 비동기 코드를 동기적 코드로 변경해 데이터 흐름을 쉽게 이해할 수 있다 (개발자 경험 향상)

위 두가지 장점을 기대하며 7월부터 작업을 진행할 예정이고, 챕터원분들의 피드백으로 mmkv대신 다른 op-sqlite와 같은 다른 스토리지 라이브러리들도 같이 고민하면 좋겠다고 말씀해주셔서, 먼저 조사 후에 기대하는 효과들을 모두 만족하는 라이브러리를 선택해서 작업을 진행해보려 한다.

7월의 action item 정리

6월도 역시 목표했던 만큼 다 완료하지는 못해 아쉽지만, 우선순위에 따라, Native Stack 적용과 에러 바운더리 작업들을 마무리했고 이어서 다음 일감으로 기획했던 작업도 담당하게 되어 2분기를 잘 마무리 할 수 있었다.

7월의 목표는 아래와 같다.

Native Stack 적용 글 작성하기
컴포넌트 설계 추가 작업 진행하기
페이지간 데이터 공유 문제 고민하고 논의하기
Async Storage 대체할 라이브러리 검토 및 마이그레이션하기
제품 내 로딩 상태 개선하기

마지막 로딩 상태 개선은 에러 바운더리 적용 이후에, 고민한 작업으로 너무 빠르게 로딩이 진행될 경우 오히려 깜빡임처럼 느끼게 해, 유저경험을 해치고 있다고 느끼게 되어 3분기 일감으로 발제하게 되었다. 현재 작업 방식은 일정한 기준 시간을 정해서 로딩을 진행하는 방식을 고민하고 있지만, 어떻게 진행될지는 조금 더 고민을 해보려 한다.

우선 이렇게 5가지로 action item을 정했고, 7월에 다시 한번 회고를 통해 어떤 부분을 개선하면 좋을지, 어떤 부분을 더 공부하면 좋을지 정리해보려 한다.

✅ 에러바운더리 도입하기

Sun, 02 Jun 2024 00:00:00 GMT

에러바운더리 작업을 작년 2023년 11월에 챕터 주간미팅에서 발표한 후에,24년 1월부터 5월까지 총 5개월동안 작업을 담당하고 제품 내 전체 스크린에 적용을 완료했다.

해당 일감의 목표는 런타임 에러로 인한 화이트스크린 에러를 방지하는데 있었다. 이를 위해 스크린 단위로 런타임 에러를 감지하고 fallback UI를 노출할 수 있게 에러바운더리를 적용했다. 에러바운더리가 무엇인지, 어떤 장점과 한계점이 있는지, 그리고 적용과정에서 어떤 점들을 고려했는지 정리해보려 한다.

🤔 에러바운더리란

에러바운더리는 react 16에 도입된 개념으로 UI 렌더링 과정에서 발생한 자식 컴포넌트 트리에 에러를 발생했을 때, 상위로 에러를 던지지지 않고 fallback UI를 보여주는 컴포넌트다. 에러 상태를 담당해주는 Context로 이해할 수 있다.

[에러 바운더리를 시각화한 그림 (참조. Logrocket 에러바운더리 글)]

에러바운더리

에러바운더리는 기본적으로 클래스 컴포넌트로 작성되며 아래 코드를 통해 4가지 정보에 대해 알 수 있다.

[에러 바운더리 컴포넌트]

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props)
    this.state = { hasError: false }
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true }
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    console.log(error, errorInfo)
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return <h1>Something went wrong.</h1>
    }

    return this.props.children
  }
}

// Usage in a component
class App extends React.Component {
  render() {
    return (
      <ErrorBoundary>
        <MyComponent />
      </ErrorBoundary>
    )
  }
}

this.state: 에러상태를 가지는 컴포넌트
getDerivedStateFromError: 렌더링 에러가 발생했을 때, 에러상태를 변경해 fallback UI가 보이도록 업데이트
componentDidCatch: 에러가 발생했을 때, 버그 리포팅하는 등 수행할 callback을 등록
render: 에러발생시 조건부 렌더링을 이용해 미리 정의한 fallback UI가 노출

사용할 때는 예시 코드의 App 컴포넌트 처럼 우리가 원하는 컴포넌트를 감싸주면 된다.

에러바운더리의 장점과 한계

그러면 에러바운더리가 가지는 장점은 아래의 두가지로 정리할 수 있다.

사용자 경험의 향상 (UX👆): 자식 컴포넌트 렌더링 에러가 최상위로 올라가 화이트스크린으로 이어지지 않게 막아준다.
개발자 경험의 향상 (DX👆): 에러상태를 위임해 에러를 선언적으로 핸들링 할 수 있다.

이러한 장점을 가진 에러바운더리지만 아쉽게도 다음과 같은 에러들은 감지할 수 없다.

[리액트 공식문서에서 작성된 에러바운더리의 한계점]

내가 만들었던 에러

에러바운더리는 위와 같은 한계점을 가지고 있고 런타임에러나 렌더링 에러가 얼마나 자주 발생하겠어?라는 생각이 들 수 있다. 실제로 개발을 하면서 제품내 발생했던 런타임 에러에 대한 해당 예제로 런타임 에러가 발생할 수 있는 상황에 대해 알아보자.

예시 요구사항은 회원가입 과정에 대한 개선 작업으로, 총 4개의 화면을 3개로 줄이는 작업을 진행하려한다.이때 작성된 데이터들은 임시로 저장하고 저장된 데이터가 있다면 재진입시 불러올 수 있어야 하고 기존 진행했던 step(pageIndex)에 따라 데이터를 불러온다.

새롭게 줄인 화면에서는 임시저장된 데이터를 가져올 때 3번째 화면을 마지막으로 생각하면 되기때문에 이전 데이터를 가져올 때, index가 3을 넘어가면 에러를 던지도록 작성해두었다.

const 실험전_마지막페이지 = 4
const 실험후_마지막페이지 = 3

let AsyncStorage의_마지막페이지 = 실험전_마지막페이지 // 예시로 AsyncStorage를 let으로 작성했다.

const getDataFrom = (index: number) => {
  switch (index) {
    case 1:
      return { title: "페이지1", content: "페이지1의 내용" }
    case 2:
      return { title: "페이지2", content: "페이지2의 내용" }
    case 3:
      return { title: "페이지3", content: "페이지3의 내용" }
    default:
      throw new Error("없는 페이지입니다.") // 실험 후 마지막 페이지는 3이니까 3보다 큰값은 안 들어올거야
  }
}

function ScreenThrowingError() {
  const [index, setIndex] = React.useState(1)
  const pageData = getDataFrom(index)

  const handlePress = () => {
    if (실험후_마지막페이지 === index) {
      return
    }
    setIndex(index + 1)
  }

  useEffect(() => {
    const AsyncStorage의_데이터불러오기 = true
    if (AsyncStorage의_데이터불러오기) {
      setIndex(AsyncStorage의_마지막페이지)
    }
  }, [])

  return (
    <View style={{ flex: 1, justifyContent: "center", alignItems: "center" }}>
      <View>
        <PagerView data={pageData} />
      </View>
      <TouchableOpacity
        style={{ position: "absolute", bottom: 12 }}
        onPress={handlePress}
      >
        <Text style={{ fontSize: 32, color: "teal" }}>{`다음페이지`}</Text>
      </TouchableOpacity>
    </View>
  )
}

위와 같은 상황의 코드를 시뮬레이터에서 동작시켜보면 다음과 같이 화이트 스크린 에러가 발생하게 된다. 원인은 이전에 최대 index를 4로 설정해두었는데, 이후 3으로 줄인 상황에서 4번째 페이지 데이터를 불러와야 하기 때문이다.

이렇게 화이트 스크린이 발생하는 상황에서 앞서 작성한 에러바운더리를 적용하면 다음과 같이 코드를 작성할 수 있다.

export class ErrorBoundary extends React.Component<{ hasError: boolean }> {
  constructor(props: { children: ReactNode }) {
    super(props)
    this.state = { hasError: false }
  }

  static getDerivedStateFromError() {
    return { hasError: true }
  }

  componentDidCatch(error: Error) {
    // bugsnag.notify(error);
    console.log(error)
  }

  render() {
    if (this.state.hasError) {
      return (
        <View
          style={{ justifyContent: "center", alignItems: "center", rowGap: 12 }}
        >
          <Text style={{ fontSize: 32 }}>에러 발생 ☠️</Text>
          <TouchableOpacity
            style={{
              borderColor: "red",
              borderWidth: 1,
              padding: 10,
              borderRadius: 10,
            }}
            onPress={() => {
              AsyncStorage의_마지막페이지 = 실험후_마지막페이지
              this.setState({ hasError: false })
            }}
          >
            <Text style={{ fontSize: 30, color: "red" }}>재시도 하기</Text>
          </TouchableOpacity>
        </View>
      )
    }

    return this.props.children
  }
}

function App() {
  return (
    <SafeAreaView
      style={{
        justifyContent: "center",
        alignItems: "center",
        flex: 1,
        rowGap: 12,
      }}
    >
      <ErrorBoundary>
        <ScreenThrowingError />
      </ErrorBoundary>
    </SafeAreaView>
  )
}

결과는 동일하게 런타임 에러가 발생하지만 화이트 스크린은 발생하지 않고, 이전 페이지로 돌아가는 것을 볼 수 있다.

위 예제를 통해 에러가 발생했을 때 에러 상황 자체를 해결해 줄 수는 없지만, 앱을 종료하고 다시 실행해야하는 유저의 불편함을 줄여줄 수 있는 에러바운더리의 장점을 잘 보여준다.

🚀 에러바운더리 적용하기

먼저 에러 바운더리를 적용하는 작업범위는 스크린 단위로 결정했고, 이를 위해 Route 컴포넌트에 있는 ScreenKey들을 조사했다. 조사결과 24년 2분기 기준 246개의 스크린이 존재했고, 불필요하거나, 중복된 screenkey들을 제외하고 100% 적용을 목표로 작업을 진행했다.

작업 방식

에러 바운더리의 동작방식은 1) 에러가 발생했을 때, 2) 에러를 잡아 fallback UI로 대신 보여준다. 동작방식을 고려한 적용규칙을 아래와 같이 세웠다.

1. 스크린 최상단에 에러바운더리 적용하기

에러 바운더리의 영향범위를 최대한으로 넓히기 위해 화면의 최상단에 두는 것을 제 1원칙으로 삼았다.

제품 내 코드를 분석해보면 스크린 컴포넌트에서는 데이터 패칭, 공통 상태 관리, 이벤트 버스 구독 등 다양한 로직을 담고 있었다. 이러한 상황에서 기존 스크린 컴포넌트에 그대로 에러바운더리를 적용하게 되면, 에러 경계 자체에서 발생하는 에러들이 발생했을 때 에러바운더리가 커버해 줄 수 없어 보였다.

이를 해결하기 위해서는 두가지 방법이 존재한다. 첫번째로 최상위에 에러바운더리로 감싸는 컴포넌트를 추가하거나, 두번째로 기존 컴포넌트를 유지하되 HOC로 에러바운더리를 적용하는 방법이 있었다.

// AS-IS
function AScreen() {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetchData().then(data => setData(data))
  }, [])

  return (
    <Layout>
      <Header />
      {data ? <AScreenContent data={data} /> : <Loading />}
    </Layout>
  )
}

// TO-BE 1. 컴포넌트로 감싸주기

function AScreen() {
  return (
    <ErrorBoundary>
      <AScreenContainer />
    </ErrorBoundary>
  )
}

function AScreenContainer() {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetchData().then(data => setData(data))
  }, [])

  return (
    <Layout>
      <Header />
      {data ? <AScreenContent data={data} /> : <Loading />}
    </Layout>
  )
}

// TO-BE 2. HOC로 감싸주기
function AScreen() {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetchData().then(data => setData(data))
  }, [])

  return (
    <Layout>
      <Header />
      {data ? <AScreenContent data={data} /> : <Loading />}
    </Layout>
  )
}

export default withErrorBoundary(AScreen)

두가지 방법 중에서 내가 선택한 방법은 첫번째 최상위에 에러바운더리를 적용한 컴포넌트를 추가하는 방법을 이었다.

최상위에 적용하게 되면 depth가 더 많아지지만, 선언적으로 코드를 작성하기 때문에 조금 더 읽기 편하다고 생각해 결정하게 되었다. 그리고 변경된 스크린 컴포넌트의 구현방식이 챕터원분들께 허들로 느껴지지 않게, 코드리뷰를 통해 자세히 설명하려 했고, 주간 미팅때 업무 진행 과정을 지속적으로 공유하면서 큰 문제없이 적용을 완료할 수 있었다.

2. Fallback UI 디자인하기

에러 바운더리의 큰 장점 중 하나는 에러가 발생했을 때 미리 정해놓은 fallback UI를 보여줄 수 있다는 것이다. fallback UI를 구현할 때 가장 많이 고민했던 부분은 화면의 레이아웃 변화 최소화하면서 해당 화면을 벗어날 수 있게 해주는 방법이었다. 에러가 발생한 것 자체가 유저 입장에서 당황스러운 상황에서 화면이 많이 변경되거나, 화면을 벗어날 수 없다면 더욱 당황스러울 것이라고 생각했다.

이러한 디자인을 기획할 때 모바일 특성을 고려해 헤더를 어떻게 처리할지에 대해 많이 고민했다. 제품 내 화면을 이동하는 방식은 tab, 바텀 버튼, 헤더가 있지만, 그중 대부분의 화면들이 헤더를 통해 화면을 이동하고 있기 때문에 헤더의 뒤로가기 버튼 또는 닫기 버튼을 통해 화면을 벗어날 수 있게 해주는 것이 중요했다.

이를 위해서 아래와 같은 prop 구성으로 에러바운더리 컴포넌트를 구현했다. 에러바운더리는 react-error-boundary 라이브러리를 이용해 적용했다.

screen: 에러가 발생한 스크린에 대한 정보를 에러 리포팅에 전달하기 위한 prop
fallbackHeader: 공통 헤더를 적용할 수 없을 때, 스크린별로 커스텀 헤더를 적용하기 위한 prop
style: 적용하는 스크린이 overlay가 있어 흰색이 아니거나 할 경우, 커스텀할 수 있는 prop

type Props = {
  screen: "AScreen" | "BScreen" | "CScreen" | "DScreen"
  fallbackHeader?: React.FunctionComponentElement<ScreenHeaderPropsInterface>
  style?: StyleProp<ViewStyle>
}
export const RuntimeErrorBoundary: React.FC<PropsWithChildren<Props>> = ({
  children,
  screen,
  style,
  fallbackHeader,
}) => {
  const handleError = useCallback(
    (error: Error, info: React.ErrorInfo) => {
      errorLogging.sendError({
        error: new Error("화이트 스크린 에러발생"),
        originalError: error,
        tag: ErrorTag.WhiteScreen,
      })
    },
    [screen]
  )

  const fallbackRender = useCallback(() => {
    return (
      <View style={[styles.container, style]}>
        {isNotNil(fallbackHeader) && fallbackHeader}
        <ErrorContent
          title={"오류가 발생했습니다"}
          content={"잠시 후 다시 시도해주세요"}
        />
      </View>
    )
  }, [fallbackHeader, style])
  return (
    <ErrorBoundary fallbackRender={fallbackRender} onError={handleError}>
      {children}
    </ErrorBoundary>
  )
}
const styles = StyleSheet.create({
  container: {
    flex: 1,
  },
})

위 코드에서 ErrorContent 컴포넌트의 공통 UI는 화이트 스크린 에러는 재시도를 하더라도 해결되지 않기 때문에 잠시 후 다시 시도해주세요와 같은 안내 문구만 노출하게 구성했다.

바로 에러 상황을 해결해줄 수 없지만 에러 상황을 빠르게 제보받고 대처하기 위해 에러 리포팅 유틸을 onError 콜백함수로 연결해 슬랙채널을 통해 빠르게 제보받을 수 있게 했다.

이렇게 구현한 에러바운더리를 스크린에 적용할 때는 헤더에 단순 navigation 로직이 담긴 경우, 헤더를 함께 최상위로 분리했고, 헤더에 회원가입 스텝이 변경되거나, 검색 text input이 있는 등 추가적인 로직이 담겨있는 경우에는 fallbackHeader를 적용해 별도로 적용할 수 있게 했다.

// 공통 헤더를 사용하는 경우
function AScreen() {
  return (
    <Layout>
      <Header />
      <RuntimeErrorBoundary screen={"AScreen"}>
        <AScreenContainer />
      </RuntimeErrorBoundary>
    </Layout>
  )
}

function AScreenContainer() {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetchData().then(data => setData(data))
  }, [])

  if (!data) {
    return <Loading />
  }

  return <AScreenContent data={data} />
}

// 공통 헤더를 사용할 수 없는 경우
function BScreen() {
  return (
    <Layout>
      <RuntimeErrorBoundary
        screen={"BScreen"}
        fallbackHeader={<Header />}
        style={{ backgroundColor: "black" }}
      >
        <BScreenContainer />
      </RuntimeErrorBoundary>
    </Layout>
  )
}

function BScreenContainer() {
  const [data, setData] = useState(null)
  useEffect(() => {
    fetchData().then(data => setData(data))
  }, [])

  return (
    <>
      <BHeader />
      {data ? <BScreenContent data={data} /> : <Loading />}
    </>
  )
}

최대한 공통 헤더를 이용하려 했지만, 제품의 복잡도가 놀라갈 수록, 헤더의 로직이 복잡해져서 fallbackHeader를 사용하는 경우가 더 많아졌다.

적용하면서 부수 효과로 비동기 처리에 따른 로딩/에러/성공 UI들을 간단하게 정리하기도 했다. 이에 더 나아가 Suspense와 useErrorBoundary 훅을 이용해 선언적으로 비동기 분기문들을 처리하는 작업들도 함께 진행하고 싶었지만, 작업 목표가 전체 제품에 적용하는 것이기 때문에, 우선적으로 에러바운더리 적용에 집중했다.

적용한 후에 실제로, 제품 내 화이트스크린 에러가 발생했을 때, 에러바운더리 덕분에 정확한 스크린 단위로 제보를 받아 빠르게 대응할 수 있었고, 해당 이슈를 재현해보면 화이트 스크린을 보지 않고 해당 화면을 벗어날 수 있게 해 유저 편의성을 개선할 수 있었다.

🙌 변화하는 제품 따라가기

24년 1분기에 작업을 시작하면서 작년 4분기에 에러 로그 분류작업을 정리했던 화면 데이터를 토대로 진행했다. 당연하게도 시간이 흐르면서 기능 개발 방향에 따라 새롭게 화면이 생기고, 필요없어진 화면은 제거되었다.

1분기 때 작업을 완료하는 시점에는 작년 4분기 데이터 바탕으로 전체 262개의 화면중 63개 화면 (24%)를 남겨두고 마무리되었다. 당시 나는 “다음 분기에 63개만 마저하면 되겠지”라고 생각했지만 2분기 작업 시작전에 다시 조사해보니 전체 화면은 262개에서 246개 화면으로 줄었고, 적용되지 않은 화면이 63개에서 108개 화면으로 늘어난 것을 알게 되었다.

1분기 작업 시작 기준이 작년 4분기 때 조사한 화면 기준이다보니 시간이 6개월 정도 시간이 지나면서 이러한 차이가 발생했지만, 앞으로도 제품의 방향에 따라 새로운 도메인, 새로운 화면들이 계속해서 추가되고, 또 필요없어진 화면들은 제거됨에 따라 적용되지 않은 부분들이 늘어나게 될 것이 예상되는 상황이었다.

이러한 문제를 해결하기 위해서 두가지 방법을 생각하고 적용해보았다.

1. 적용된 화면과 적용되지 않은 화면을 알기 위한 자동화 스크립트

작업을 마무리하면서 적용된 화면과 적용되지 않은 화면을 알기 위해 자동화 스크립트를 작성했다. 이 스크립트는 제품 내 모든 화면을 조사하고, 적용된 화면과 적용되지 않은 화면을 구분해주는 스크립트로 작업을 하면서 세웠던 규칙을 토대로 작성했다.

전체 화면의 기준은 React Navigation을 사용하면서 적용할 때의 규칙인 ScreenKey(key)와 Screen 컴포넌트(value) 구조를 이용해, 전체 ScreenKey를 기준점으로 이용했고, 각 화면들은 1) 적용된 화면, 2) 중복된 화면, 3) 보류 화면, 4) 불필요한 화면으로 분류했다.

중복된 화면 (DuplicatedScreenKeys) : 같은 Screen에 modal/card 형식에 따라 두가지의 ScreenKey를 가지는 화면
보류 화면 (DelayedScreenKeys) : 제거가 예정되어 있거나, 사용 파악이 어려웠던 화면
불필요한 화면 (NotRequiredScreenKeys) : 개발 환경을 위한 화면이거나, 에러바운더리를 적용해도 큰 효용이 없어보이는 화면

각 분류에 대한 예를 들어 중복된 화면의 경우,프로필 상세화면의 경우 모달형식이냐 카드형식이냐에 따라 ProfileDetail과 ProfileDetailModal ScreenKey가 같이 사용되기 때문에 하나를 제외했다.

보류화면은 스쿼드 작업으로 인해 실험결과에 따라 제거 예정인 화면이거나, 특정 이벤트 화면의 경우 현재 사용되지 않지만 코드로만 남아있는 경우 보류화면으로 분류했다.

불필요한 화면은 개발 환경을 위한 화면이거나, Start 화면과 같이 에러가 발생했을 때 해당 화면을 벗어날 수 없고, 최상위 에러바운더리가 있기 때문에 불필요한 화면으로 분류했다.

이렇게 분류한 기준을 적용한 스크립트 코드는 아래와 같다.

// src/screens/index.tsx 내부 스크린 설정
type RootStackParamList = {
  Start: undefined
  Home: undefined
  Login: undefined
  Signup: undefined
  Profile: { userId: string }
  ProfileModal: { userId: string }
  Feed: { feedId: string; userId: string }
  FeedModal: { feedId: string; userId: string }
  InviteEvent: { eventId: string }
  NotFound: undefined
  OldRequest: { requestId: string }
}

enum ScreenKeyEnum {
  Start = "Start",
  Home = "Home",
  Login = "Login",
  Signup = "Signup",
  Profile = "Profile",
  ProfileModal = "ProfileModal",
  Feed = "Feed",
  FeedModal = "FeedModal",
  InviteEvent = "InviteEvent",
  NotFound = "NotFound",
  OldRequest = "OldRequest",
}

// tsconfig.json 설정으로 프로젝트 생성
const project = new Project({
  tsConfigFilePath: "tsconfig.json",
})

type ScreenKey = `${ScreenKeyEnum}`

// 파일 경로
const SCREEN_KEY_ENUM_PATH = "src/screens/index.tsx"
const SCREENS_DIR = "src/screens"

const checkIsScreenKey = (screenKey: string): screenKey is ScreenKey => {
  const screenKeyEnumValues: ScreenKey[] = Object.values(ScreenKeyEnum)
  return screenKeyEnumValues.includes(screenKey as ScreenKey)
}

const filterScreenKeys = (keys: string[]): ScreenKey[] => {
  return keys.filter(checkIsScreenKey)
}

// RuntimeErrorBoundary 컴포넌트를 사용하는 파일을 찾기 위한 함수
const findFilesUsingRuntimeErrorBoundary = (dirPath: string): ScreenKey[] => {
  const screenKeys: string[] = []
  const items = fs.readdirSync(dirPath, { withFileTypes: true })

  items.forEach(item => {
    const itemPath = path.join(dirPath, item.name)
    if (item.isDirectory()) {
      screenKeys.push(...findFilesUsingRuntimeErrorBoundary(itemPath))
    } else if (item.isFile() && item.name.endsWith(".tsx")) {
      const sourceFile = project.addSourceFileAtPath(itemPath)
      const fileText = sourceFile.getText()
      if (fileText.includes("<RuntimeErrorBoundary")) {
        // 정규식을 사용하여 스크린 내부 RuntimeErrorBoundary 컴포넌트의 screen prop의 ScreenKeyEnum 값을 추출
        const regex =
          /<RuntimeErrorBoundary[^>]*screen\s*=\s*\{(ScreenKeyEnum\.\w+)\}/
        const match = regex.exec(fileText)
        if (match != null) {
          const screenValue = match[1]
          const screenKeyRegex = /ScreenKeyEnum\.(\w+)/
          const screenKeyMatch = screenKeyRegex.exec(screenValue)
          if (screenKeyMatch != null) {
            screenKeys.push(screenKeyMatch[1])
          }
        }
      }
    }
  })

  return filterScreenKeys(screenKeys)
}

// ScreenKeyEnum enum의 key 값을 가져오는 함수
const getScreenKeyEnumKeys = (): ScreenKey[] => {
  const sourceFile = project.addSourceFileAtPath(SCREEN_KEY_ENUM_PATH)
  const keys: string[] = []

  sourceFile.forEachDescendant(node => {
    if (node.getKind() === SyntaxKind.EnumDeclaration) {
      if (node.getText().includes("ScreenKeyEnum")) {
        node.getChildrenOfKind(SyntaxKind.EnumMember).forEach(member => {
          keys.push(member.getName())
        })
      }
    }
  })

  return filterScreenKeys(keys)
}

const main = () => {
  const screenKeys = getScreenKeyEnumKeys()
  const screenKeysInScreenDir = findFilesUsingRuntimeErrorBoundary(SCREENS_DIR)
  const DuplicatedScreenKeys: ScreenKey[] = [
    ScreenKeyEnum.ProfileDetailModal, // ProfileDetail와 중복
    ScreenKeyEnum.FeedModal, // Feed와 중복
  ]
  const DelayedScreenKeys: ScreenKey[] = [
    ScreenKeyEnum.OldRequest,
    ScreenKeyEnum.ModalRequestReview,
  ]
  const NotRequiredScreenKeys: ScreenKey[] = [
    ScreenKeyEnum.Start,
    ScreenKeyEnum.NotFound,
  ]

  const DoneArr = new Set([
    ...screenKeysInScreenDir,
    ...screenKeysInComponentDir,
  ])

  const AlreadyCheckedArr = new Set([
    ...NotRequiredScreenKeys,
    ...DuplicatedScreenKeys,
    ...DelayedScreenKeys,
  ])

  const requiredScreenArr = screenKeys.filter(
    screenKey => !AlreadyCheckedArr.has(screenKey)
  )
  const missingArr = requiredScreenArr.filter(
    screenKey => !DoneArr.has(screenKey)
  )

  // 결과 출력
  console.debug("--------------------------------")
  console.debug("전체:", screenKeys.length)
  console.debug("불필요:", NotRequiredScreenKeys.length)
  console.debug("중복:", DuplicatedScreenKeys.length)
  console.debug("보류:", DelayedScreenKeys.length)
  console.debug("필요:", requiredScreenArr.length)
  console.debug("계산결과:", DoneArr.size)
  console.debug("누락된 스크린:", missingArr)
  console.debug("--------------------------------")
}

main()

이제 해당 script를 package.json의 script로 등록해두면, npm run check-screen 명령어로 전체 화면을 조사하고, 적용된 화면과 적용되지 않은 화면을 알 수 있게 된다.

스크립트 실행 결과

현재 script에 개선할 부분이 많이 있지만 우선 적용되지 않은 화면을 알 수 있게 되어, 이후 작업을 진행할 때 더욱 효율적으로 작업할 수 있게 되었다.

이후 github action으로 연결해 CI 과정과 연결해 master에 병합될 때마다 주기적으로 체크하는 작업도 진행할 수 있을 것 같다는 생각이 들었다.

2. 스크린 파일 생성 script에 에러바운더리 적용하기

챕터 동료분께서 주신 아이디어로 나는 몰랐지만 챕터내 많은 분들이 스크린 생성 스크립트를 이용해서 새로운 화면을 생성한다는 것을 알게 되었다. 새로운 화면을 만들기 위해서는 RootStack.Navigator안에 RootStack.Screen 컴포넌트를 추가하고 해당 컴포넌트에 대한 ScreenKey를 추가해야 한다.

이를 자동으로 추가해주는 script가 기존에 존재해 여기에 에러바운더리를 추가해보기로 했다. 직접 추가하는 경우에는 당연히 에러바운더리 코드를 작성해야 적용되겠지만 스크린 생성 script를 이용할 떄는 별다른 고민없이 적용될 수 있을 것 같다는 생각이 들었다. 기본 형식은 아래처럼 정하게 되었다.

import React from 'react';
import Screen from '@component/Screen';
import { Text, View } from 'react-native';
import { ScreenKeyEnum } from '@screen/index';
import ScreenHeader from '@component/ScreenHeader';
import { RuntimeErrorBoundary } from '@component/RuntimeErrorBoundary';
import Screen from '@component/Screen';


export function FooScreen() {
    return (
        <Layout>
            <ScreenHeader title={''} />
            <RuntimeErrorBoundary screen={ScreenKeyEnum.Foo}>
                <${screenName}Content />
            </RuntimeErrorBoundary>
        </Layout>
    );
}

function FooContent() {
    return (
        <View>
            <Text>bcg</Text>
        </View>
    );
};

역시 혼자 고민하기 보다 함께 고민할 때 더 좋은 해결책을 얻을 수 있다는 것을 알게 되었고, 앞으로 새롭게 스크린들이 추가될 때 편하게 적용할 방법에 대한 고민을 해결할 수 있었다.

📚 마치며

하나의 기술을 알게 되고 적용하는 것은 쉽지 않은 일이다. 단순히 하나의 컴포넌트를 만들고 기존 컴포넌트에 적용하는 작업이라 생각했지만 이과정에서 많은 고민과 시행착오가 있었다. 어떻게 하면 최대한 기존 코드 컨벤션을 깨뜨리지 않으면서 적용해 동료분들의 학습 곡선을 최소화할 수 있을지, 어떻게 하면 더 효율적으로 작업을 진행할 수 있을지 고민하고, 이를 해결하기 위해 다양한 방법을 시도해보았다.

횡단 관심사인 에러바운더리를 적용하면서 제품내 모든 화면들을 조사하게 되었고, 부수적으로 제품 전체에 대한 이해도가 높아질 수 있었고, 5개월간 하나의 주제의 일감을 혼자 처음부터 끝까지 진행하면서, 일을 지치지 않고 진행하기 위해서는 적절한 단위로 끊어서 진행하는 일하는 방식에 대해서도 배울 수 있었다.

또 좋은 제품을 만들기 위해서는 혼자서 일하는 게 아니라 동료와 함께 고민하고, 함께 공유하며, 함께 성장해야 한다는 것을 다시금 깨달았다. 이번 작업을 통해 앞으로도 함께 성장하며 좋은 제품을 만들어 나가고 싶다.

🙌 2024년 5월회고

Sat, 01 Jun 2024 00:00:00 GMT

5월은 미리 보는 주 4일제처럼 휴일이 많았고 개인적인 일정이 많았던 달이었다. 업무는 4월부터 담당했던 작업들을 마무리하고 성과분석 및 발표를 진행하기도 했다. 어떤 작업들을 했는지, 4월 회고 때 하기로 마음먹었지만 어떤 건 놓쳤는지 확인해보려 한다.

🤔 4월 회고 돌아보기

4월 회고때 정리한 action item들을 정리해보면 아래와 같다.

화면전환 간 성능 개선을 위해 Native Stack 도입 및 성능 분석방법 찾아보기
에러 바운더리를 조금 더 챕터원들이 쉽게 적용하는 방법 고민해보기
컴포넌트 설계에 관해 공부하고 정리해보기
UI 패턴별 최적화 정리해보기
React 내부 코드 분석해보기
선언적으로 인증/인가 관리하기

이중에서 실제로 진행하면서 발생했던 시행착오들과, 하지 못했던 것들을 정리해보려 한다.

1. 화면전환 간 성능 개선을 위해 Native Stack 도입 및 성능 분석방법 찾아보기

5월은 실제로 기존 StackNavigator에서 NativeStackNavigator로 변경하는 작업을 진행했다. 기존에 stackNavigator는 JS를 통해 만들어지는 반면 NativeStackNavigator는 직접 Native 요소들을 사용하게 구현되어 있기 떄문에 기존과 다른 인터페이스들을 갖게 되었다. 달라진 인터페이스와 함께 플랫폼별로 다르게 구현되는 부분들 때문에 최대한 기존과 유사한 유저 경험을 줄 수 있게 일일이 확인하고 적용했다.

이과정에서 다양한 이슈들이 존재했는데 예로, 기존에 card와 modal 간의 이동이 자유로워 card -> m해dal -> card로 화면 전환이 자유로웠던 반면, Native 요소를 이용하면서 Modal이 Navigation의 마지막으로 노출되어야 한다는 규칙에 따라, Modal 뒤에 쌓여 보이지 않는 이슈가 있었다. 두번째로 화면전환 애니메이션 자체가 달라지거나, 애니메이션 속도가 줄어드는 등 다양한 이슈를 확인하고 대처하는 작업을 진행했다.

이슈들을 해결하고 나서 성과 분석을 위해 적용 전 제품 내 핵심 퍼널들의 화면 전환들을 비교하보기 위해 영상촬영을 진행하고, 이후 반영된 버전으로 다시 촬영하여 비교해보는 작업을 진행했다. 추가로 안드로이드만 현재 지원되지만 maestro(e2e 테스트)를 이용한 FlashLight 성능 측정을 통해 화면전환간 성능을 측정했다. 앞서 촬영했던 메인퍼널들에 대한 e2e script를 작성하고 30회 정도 반복 측정을 통해 화면전환간 성능을 측정했다.

해당 결과는 아직 분석에 시간이 필요해 6월 동안 분석하고 결과를 공유할 예정이다. 6월에는 적용과정에서의 troubleShooting과 성능측정 결과에 대한 글을 작성해보려 한다.

2. 에러 바운더리를 조금 더 챕터원들이 쉽게 적용하는 방법 고민해보기

에러 바운더리 작업을 제품 내 전체 화면들에 대한 적용을 드디어 완료했다. 지난 회고 때 고민했던 새로운 화면들이 추가되었을 때 어떻게 적용할 수 있을지 고민했던 부분을 위한 작업들도 추가로 진행했다.

먼저 현재 적용된 화면들과 적용되지 않은 화면들을 알 수 있게 ts-morph를 이용한 script 코드를 작성해 지속해서 에러바운더리가 적용되지 않은 화면들에 대해 체크할 수 있게 했다.

두 번째로는 동료분께서 주신 아이디어로, 기존 스크린 파일 생성 시 사용하는 템플릿 생성 scrip 코드에 에러바운더리를 적용하는 코드를 추가해, 새로운 화면을 생성할 때 자동으로 에러바운더리가 적용되도록 하는 작업을 진행했다. 제안 받은 당시에 늘 직접 파일을 생성하고 Navigator에 일일이 추가했었기 때문에 템플릿 생성 script에 추가할 생각을 못했는데, 함께 고민해주신 덕분에 쉽게 적용할 수 있었다.

이렇게 현재를 기준으로 한 적용 작업 뿐 아니라, 이후 새롭게 추가될 화면들을 위한 작업들도 진행해 조금 더 완성도 있게 마무리할 수 있었다. 첫 번째 적용되지 않은 화면들을 찾아낼 수 있게 하는 script는 이후 github action을 이용한 CI에 연동해 주기적으로 체크할 수 있게 발전시켜볼 예정이다.

6월에는 작업 배경, 작업 방식, 결과에 대해 글을 작성해보려 한다.

3. 컴포넌트 설계에 관해 공부하고 정리해보기

4월에 컴포넌트 설계에 관한 공부가 필요하다 느꼈던 이유는, 스쿼드 기능개발 작업을 진행하면서 여러 도메인에서 공통으로 사용하는 컴포넌트를 다루게 되었기 때문이었다.

당시 해당 컴포넌트는 1200줄이 넘는 많은 코드들이 하나의 컴포넌트에 담겨있어 한눈에 이해하기가 어려웠고, 자체적으로 API 요청하고 있기 때문에 해당 컴포넌트 밖에서 해당 데이터가 필요할 때 중복 API를 호출해서 사용해야 하는 등의 이슈를 가지고 있었다.

이러한 이슈들을 해결하기 위해서 서로 다른 도메인과 화면에서 공통으로 사용될 때,제품의 요구사항이 달라졌을 때 유연하면서 확장성 있는 컴포넌트를 만들기 위해 컴포넌트 설계를 공부했고, 이를 적용해보려 했다.

스쿼드 작업의 여유가 있을 때, 또는 퇴근 후에 리액트 컴포넌트 설계에 대한 강의와 글을 읽으면서 직접 적용하면서 작업을 진행했다. 공부하면서 다양한 컴포넌트 설계 패턴이 있다는 것을 배울 수 있었고 그중에서 compound Pattern을 이용한 headless UI를 적용해보았다.

아직 개선할 부분이 많이 남아있지만 1차적으로 작업을 완료했을 때 컴포넌트 내부 코드가 300줄 이내로 줄어들게 되었고, 보다 유연하게 요구사항들을 반영할 수 있게 수정될 수 있었다. 이부분도 이후에 조금 더 개선 작업을 추가한 뒤에 글로 작성해보려 한다.

하지 못한 UI 패턴별 최적화 정리하기, React 내부 코드 분석하기와 선언적으로 인증/인가 관리하기

UI 패턴별 최적화 정리하기와, React 내부 코드 분석하기, 선언적으로 인증/인가 관리하기는 5월에 진행하지 못했다. 스쿼드 업무를 진행하면서 조금씩 정리해보려 했지만 컴포넌트 설계를 공부하고 접목하고 싶은 마음에 해당 일감에 집중하고 우선 미루기로 했다. 대신 컴포넌트 설계 과정에서 JSX가 실제로 createElement로 컴파일되어 사용된다는 점 등을 배울 수도 있었다.

5월에는 우선순위에서 밀렸지만, 진행중이던 일감들을 마치는 대로 6월의 action item들로 실행해보려 한다.

🚀 5월에 고민을 시작한 일감 및 공부

5월은 4월에 고민했던 일감들을 진행하면서 해당 일감들로부터 파생된 일감들을 더 진행하다보니 새로운 주제들을 많이 생각하지 못했다. 대신 6월이 되면서 다음 분기에 진행하면 좋을 일감들을 현재 챕터 내에서 작성하고 있다. 6월에 진행하지는 않겠지만 7월부터 담당해서 진행하고 싶은 일감들을 아래에 정리해보려 한다.

주기적 성능 측정을 위한 CI 구축

화면전환 간 성능 개선 작업을 하면서 FlashLight와 maestro를 함께 이용하면서 e2e 테스트를 통해 주요퍼널들에 대한 성능을 측정했다. 이를 CI에 연동해 주기적으로 성능을 측정하고 결과를 버전별로 관리할 수 있다면, 조금 더 의미있게 비교해볼 수 있지 않을까 생각이 들었다. 물론 e2e 테스트 코드들을 작성해야하는 점, 현재 FlashLight는 android 기기만을 기준으로 측정하는 점 등의 이슈들이 있지만, 기준이 되는 기기에 대해 주기적으로 앱의 성능을 측정한다면 개선할 부분들을 파악하거나, 문제점들을 조금 더 빠르게 파악해 제품의 안정성에 기여할 수 있겠다는 생각이 들었다.

선언적으로 인증/인가 관리하기

4월 회고 때 작성했던 부분이지만, 현재 제품 내에서 고객/고수의 경우에만 사용 가능한 화면에서 일일이 인증/인가를 체크하는 부분이 많이 존재한다. 이를 선언적으로 관리하는 방법을 찾아보고 적용해보고 싶다. 예로 react navigation의 가이드로 Authentication flow를 도입하는 방법 등을 적용해 보고 싶다.

AsyncStorage 대체하기

현재 제품 내에서 AsyncStorage를 이용해 데이터를 저장하고 있는데, AsyncStorage는 비동기로 동작하기 때문에 데이터를 조회/삭제/변경에 느린 성능이 가지고 있다. 이에 대한 대체재로 MMKV를 도입해 보고 싶다.

여기서 어떤 작업들을 담당해서 진행할 수 있을지 모르지만, 3분기에도 계속해서 제품에 다양한 기여해나가는 일들을 진행해보고 싶다.

마치며

5월은 4월에 이은 작업들이 많았고, 하겠다 선언한 action item들을 많이 진행하지 못했던 것 같다. 하고 싶은 건 많지만, 하나의 일을 제안, 실행, 마무리하는데 까지 시간이 많이 소요되었다. 6월에는 5월에 하지 못한 일들을 더 집중해서 진행하고, 7월부터는 3분기에 진행할 일들을 미리 정리해서 더욱 더 성장할 수 있도록 노력해보려 한다.

🙌 2024년 4월회고

Wed, 01 May 2024 00:00:00 GMT

4월은 바빴지만, 내안에 "어떤게 맞는걸까, 내가 잘하고 있는걸까" 하는 고민이 많았던 한 달이었다. 3월 달의 하기로 했던 것들 중 얼마나 했는지에 대해 정리해보고 4월에는 어떤 것들을 했는지 또 어떻게 하면 더 나은 개발자가 될 수 있을지 정리해보려 한다.

💪 3월 회고 돌아보기

3월 회고때 마음먹었던 것들은 아래와 같이 정리할 수 있다.

App Startup Time 줄이기 때 하지 못한 일감 후속 작업 진행하기
에러바운더리 적용하고 과정에 대한 글쓰기
스쿼드 내 소통할 때 적극적으로 소통하기, 기술 용어 대신 이해하기 쉬운 용어로 표현하기
컴포넌트 설계에 대한 공부하기
UI 패턴별 최적화하는 방법에 대해 정리하기

위 다섯가지에 대해 4월 한달동안 어떘는지 개인적으로 생각해보려 한다.

1. App Startup Time 줄이기 후속 작업

App Startup Time 개선 작업을 잘 마무리하고 당시 미뤄뒀던 후속작업들을 진행하겠다고 3월에 다짐했었다.

다행히 다음 챕터 업무로 화면 전환간 성능을 개선을 담당하게 되었다. 그 방법으로 Native Stack을 적용하는 작업을 메인으로 진행하고 있다. 우리 제품은 React Navigation을 이용해 라우팅, 화면전환을 구현하고 있는데, 성능 측정을 위한 자체 Custom Stack Navigation을 만들어서 적용하고 있다.

이를 제거하고 React Navigation의 Native Stack을 적용하면서 JS 스레드를 이용한 화면전환이 아니라 Native 스레드를 이용해 화면 전환간 성능을 개선할 수 있을 것이라고 생각했다. 이뿐 아니라 기존 화면 전환간 문제가 될 수 있을 만한 부분들을 찾아보고 아이디어를 떠올리고 있다.

조금 아쉬운건 화면전환 작업은 순간적으로 일어나는 부분이기 때문에 측정에 어려움이 있고, 동일 기기에서 직접 영상으로 비교해보려 하는데, 그것 또한 큰 의미가 있는 것인지 의미를 찾기 어려워 보인다.

만약 조금 더 측정을 해보려한다면 네트워크 의존이 적은 화면에 대한 E2E 테스트 코드를 작성하거나, 앱을 사용하는 흐름에서 화면전환되는 순간의 CPU, 메모리, FPS가 떨어지는 정도를 비교해보는 방법이 좋아 보여 우선 측정 방법을 계속해서 고민해보고 있다.

2. 에러바운더리 제안 및 적용하는 과정에 대한 글쓰기

3월에 이어 4월도 에러바운더리를 적용하는 작업을 진행하게 되었다. 3월까지는 작년 4분기 작업 전에 조사했던 화면들에 대한 기준으로 작업을 진행했고, 그사이에 새롭게 추가되고 수정된 화면들에 대한 반영이 되어 있지 않았기 때문에 4월에 작업을 시작하면서는 현재의 기준으로 조사가 먼저 필요했다.

ChatGPT 덕분에 기존 정리해둔 데이터에 새롭게 추가된 데이터를 합친 새로운 테이블을 만들 수 있는 Script를 작성해, 현재 기준 제품 내에는 총 256개 화면이 존재하고 그중 108개 화면(42%)에 대한 작업이 필요하다는 것을 알 수 있었다.

분명 3월에 정리했을 때는 작년 4분기 조사한 화면들 기준으로 262개중 84개(33%)의 화면이 남아있었는데 다시 정리하니 달라진 것이다. 이렇게 정리하고 나니 단순히 열심히만 해서는 영원히 끝나지 않을 작업이라는 생각이 들었다. 구멍난 독에 물붓기처럼 구멍을 손으로 막으면서 물을 부었을 때 어느정도 차긴 하겠지만, 새로운 화면들은 생기고, 필요없는 화면들은 제거되게 되면서 끝이 없는 작업이라는 것을 느꼈다.

이를 해결하기 위해서는 단순히 새롭게 추가하는 게 다가 아니라 챕터내 공유를 통해 다시 한 번 왜 필요한지, 어떤 효과가 있는지 공유해, 다같이 노력해야 해결할 수 있는 방법이란 생각이 들었다.

그리고 이렇게 챕터 구성원들이 함께 노력해주시기를 요청하는 동시에 조금 더 쉽게 적용할 수 있는 방법은 없을지 고민이 필요해 보였다. 최상위 컴포넌트인 Screen 컴포넌트 내부로 옮겨서 적용할지 등 기존 작업을 돌아보면서 최대한 쉬운 방법을 고민해보려 한다.

이러한 시행착오들을 잘 정리해서 6월정도에는 글을 써보려한다.

3. 스쿼드 내 소통 방식에 대한 노력

3월부터 합류한 스쿼드 내에서 다양한 작업을 진행하게 되었다. 신사업 담당 스쿼드이다 보니 다른 회사와의 협업을 하거나 빠르게 테스트하거나 중간에 다른 일들이 많이 들어오는 상황에서 의사소통이 좀 더 중요하게 느껴졌다.

이번달 주요 작업중 하나였던 쿠팡 광고 연결작업을 진행하면서 쿠팡 광고 상품 클릭시 앱이 설치되면 쿠팡 앱으로 진입 후 광고상품에 랜딩하게 되고, 앱이 설치되어 있지 않으면 모바일 웹을 통해 광고상품에 랜딩시키는 작업을 진행했다.

이때 iOS, Android에 따라 쿠팡 광고에 랜딩할 때 기존 기획과 다른 부분들이 있었고, 이런 기획과 다른 부분들을 정리해서 스쿼드에 공유하는 등, 실제 구현과정에서 예상과 다를 수 있는 부분들을 적극적으로 공유하려 노력했다.

또한 유저 데이터를 측정하기 위한 트래커의 경우에도 PO, Data 엔지니어분께서 설계해주셨을 떄 실제 적용할 때 어떤 요소가 있으면 좋을지, 더 좋은 방법은 없을지 적극적으로 소통하기도 했다.

여전히 기술적인 요소에 대해 설명할 때 어려움이 있는 것 같다. 단순히 된다/안된다 두가지로 나눠서 이야기하는 게 아니라 이해할 수 있게 잘 설명하는 방법들을 계속 연습해가야 겠다는 것을 느꼈던 한달이었다.

4. 컴포넌트 설계에 대한 공부하기

스쿼드 기능 개발을 하면서 컴포넌트 설계에 대해서 많이 고민하고 작업했다. 기존과 다른 요구사항이 생겼을 때 어떻게 하면 변화에 유연하게 개발할 수 있을지, 고민하는 과정은 시간이 더 많이 들었지만, 데이터와 UI와 분리한 뒤에 재사용하기 편한 인터페이스로 개선하는 작업을 진행하면서 하나씩 더 사용하기 좋은 컴포넌트에 대한 개념을 잡아가고 있다.

3월 회고 떄 말했던 UI 라이브러리들을 참고해서 조금 더 확장성있게 컴포넌트를 만드는 건 아직 적용하지 못했다. 대신 기능 개발 과정에서 병목이 되었던 컴포넌트 하나를 정해서 리팩토링 작업을 계획하고 컴포넌트 설계와 관련된 강의들을 참고해 적용해보려한다. 이과정을 정리해서 주간 미팅 시간에 팀원들과 함께 공유해도 좋을 것 같다.

5. UI 패턴별 최적화하는 방법에 대해 정리하기

UI 패턴별 최적화하는 방법에 대해 정리하기는 아직 시작하지는 못했다. 대신 4월 한달간 가장 많이 본 패턴을 정리해보면 목록 -> 상세로 연결되는 화면들로 이루어진 상점 패턴이었다.

React Native에는 ScrollView, FlatList, SectionList 등 다양한 리스트 컴포넌트들이 있고, 컴포넌트 자체 Prop이 지원하는 요소들을 공식문서를 기반으로 구현하려 노력했다.

예를 들어 목록의 특정 요소가 노출되었는지를 감지하는 방법인 FlatList의 onViewableItemsChanged를 이용하는 방법을 정리해 간단한 글을 작성했고, 우리 제품내에서도 처음 사용하게 된 prop이라 공유하면 좋을 것 같아 주간 미팅에서 발표를 하기도 했다.

아직 부족해 한번에 UI 패턴 별 최적화 방법을 정리하지 못했지만 하나하나 계속해서 정리해나가려 한다.

🚀 4월에 고민을 시작한 일감 및 공부

4월과 다르게 새롭게 고민을 시작한 일감들에 대해 정리하면서 5월에는 어떤 일을 진행할 지 계획해보려 한다.

선언적으로 로그인 필요화면 다루기

기능 개발을 하면서 로그인이 되어있는 유저만 진입가능한 화면들에 대한 작업하게 된다. 그경우 로그인을 했는지 안했는지를 스크린 내부에서 계속해서 고민하면서 개발해야하다 보니 분기문이 늘어나는 것을 느끼게 되었다. 만약 스크린 상위에서 HOC로 로그인이 되었는지 확인한 후에 하위에서는 무조건 로그인 되어있는 경우로 생각해서 작업할 수 있다면 조금 더 관심사를 잘 분리할 수 있지 않을까 생각이 들었다.

React의 Protected Route처럼 RN에서 구현할 수 있는 방법을 고민해보려 한다.

진입점에 대한 분기문 덜어내기

에러바운더리 작업을 진행하면서 해당 화면에 진입한 진입점에 따라 다른 결과를 실행시키는 코드를 간혹보게 되었다. 예를 들어 공통 휴대폰 인증화면이 있다고 하면 고객 홈에서 들어왔을 경우에는 인증 실패시 고객홈으로 돌아간다면, 커뮤니티에서 진입한 경우에는 토스트를 띄워줄 수 있다.

이렇게 진입점마다 달라지는 코드가 해당 화면에 존재하게 되었을 때 두가지 문제점이 있다고 생각이 들었다.

먼저 해당 진입점의 변화가 생겼을 때 대처가 어렵다. 만약 진입점의 이름이 바뀌거나 해당 화면이 제거되었을 때에도 분기문이 진입점 이름에 따라만 정의되고 있어서 해당 케이스가 제거/변경에 누락되는 케이스가 발생할 수 있다.

두번쨰로는 진입점에 따라 해당 화면 내부 코드가 분기문으로 인해 복잡해진다. 만약 앞선 예제처럼 인증 실패시에 대한 부분에 대한 정의가 필요하다면 해당 실패를 위한 callback을 전달하는 게 더 좋은 코드이지 않을까 생각이 들었다.

이부분도 정리해서 주간 미팅에 공유해보려 한다.

React 분석해보기

개인적으로 공부하고 있는 부분은 2월부터 계속해서 매일 리액트 공식문서의 한챕터씩 정리해보고 있다. 이제 거의 마무리되어서 다음 단계로 리액트 내부 코드들을 까보면서 각 요소가 직접 어떻게 동작하는지, 리액트의 특징이 어떻게 구현되어 있는지에 대해 공부해보려 한다.

리액트에 대해 더 잘 이해하게 되는 것도 좋지만, 정말 많은 사람들이 사용하는 라이브러리 코드를 보면서, 어떤 코드가 좋은 코드인지 이해하는 좋은 기회가 될 것 같다.

리액트 공식문서에 대한 정리

📚 마치며

이번 회고는 3월 회고때 했던 다짐들을 잘 지켰는지, 새로운 고민을 시작한 일감들에 대해서도 함께 정리해보았다. 말만 하고 실행하지 않는 것을 막기 위해 매달 회고를 이전 달의 다짐과 비교해보는 것도 좋은 방법이라고 생각이 들었다.

매달 쓰고 있지만 이렇게 정리하면서 다시 한번 내가 어떤 개발자가 되고 싶은지, 어떤 부분을 더 공부해야 하는지, 어떤 부분을 더 신경써야 하는지에 대해 다시 한번 생각해보는 시간이 되는 것 같다.

5월은 쉬는 날이 많다. 이것을 기회로 더 많이 개인공부를 많이 늘려서 회사에서 더 많은 것을 공유할 수 있는 개발자로 나아가는 한달이 되길 바라본다.

👀 onViewableItemsChanged 이해해보기

Sun, 21 Apr 2024 00:00:00 GMT

기능 개발을 하면서 목록의 특정 아이템이 50% 노출되었을 때 트래커가 발송시키는 요구사항을 받게 되었다. 이를 구현하는 과정에서 알게된 FlatList의 onViewableItemsChanged prop에 대해 정리해보려 한다.

🤔 onViewableItemsChanged란?

onViewableItemsChanged는 RN의 FlatList에 전달할 수 있는 prop으로 FlatList가 스크롤에 의해 보여지는 아이템들(viewableItems)이 변경됨에 따라 호출되는 함수로 현재 viewableItems는 어떤 것이고, 변경된 items는 어떤 것인지에 대한 정보를 제공한다.

[onViewableItemsChanged의 타입 정의]

onViewableItemsChanged?: ((
    info: {
        viewableItems: Array<ViewToken>;
        changed: Array<ViewToken>
    }) => void) | null | undefined;

interface ViewToken {
    item: any;
    key: string;
    index: number | null;
    isViewable: boolean;
    section?: any;
}

이때 자주 함께 사용되는 config로 viewabilityConfig를 통해 어떤 조건을 만족할 때 viewableItems로 설정할지에 대해 정할 수 있다. config의 요소는 아래 4가지가 있다.

minimumViewTime: onViewableItemsChanged를 호출하기 전에 viewableItem으로 간주되기 위한 최소 시간
viewAreaCoveragePercentThreshold: viewport에 얼마나 아이템이 차지해야 viewableItem으로 여길지에 대한 최소 노출 비율
waitForInteraction: 사용자의 interaction을 기다릴지 여부
itemVisiblePercentThreshold: viewport 기준이 아니라 item 기준으로 viewableItem으로 간주되기 위한 최소 노출 비율

위 4가지 속성에 대한 타입은 아래와 같다.

export interface ViewabilityConfig {
  minimumViewTime?: number | undefined
  viewAreaCoveragePercentThreshold?: number | undefined
  itemVisiblePercentThreshold?: number | undefined
  waitForInteraction?: boolean | undefined
}

viewabilityConfig를 전달하면 4가지 속성중에서 viewAreaCoveragePercentThreshold나 itemVisiblePercentThreshold는 필수값으로 설정되어야 한다. 해당 속성이 설정되지 않으면 아래와 같은 에러가 발생한다.

viewabilityConfig에서 필수값을 설정하지 않았을 때 발생하는 에러

🚀 onViewableItemsChanged 사용하기

그러면 이제 실제 onViewableItemsChanged를 사용하는 예시를 보자.

요구사항 1. 처음 3번째 요소가 70% 노출되었을 때 콘솔 찍기

요구사항으로 처음 3번쨰 요소의 70% 노출되었을 때 콘솔이 찍히게 하려한다.

[예시 코드 실행해보기]

import React, { useRef } from "react"
import {
  SafeAreaView,
  View,
  FlatList,
  StyleSheet,
  Text,
  StatusBar,
} from "react-native"

const data = Array.from({ length: 50 }, (item, index) => ({
  id: Math.random().toString(12).substring(0),
  title: `Item ${index + 1}`,
}))

type ItemProps = {
  title: string
}

const Item = ({ title }: ItemProps) => (
  <View style={styles.item}>
    <Text style={styles.title}>{title}</Text>
  </View>
)

const TARGET_INDEX = 2

const App = () => {
  const isShown = useRef(false)

  const handleViewableItemsChanged = ({
    viewableItems,
  }: {
    viewableItems: Array<ViewToken>
    changed: Array<ViewToken>
  }) => {
    if (isShown.current) {
      return
    }

    const isTargetInView = viewableItems.some(
      item => item.index === TARGET_INDEX
    )
    console.log(isTargetInView)
    if (isTargetInView) {
      console.log("타켓 노출") // Tracker 찍기
      isShown.current = true
    }
  }

  return (
    <SafeAreaView style={styles.container}>
      <FlatList
        initialNumToRender={4}
        renderItem={({ item }) => <Item title={item.title} />}
        keyExtractor={item => item.id}
        data={data}
        viewabilityConfig={{
          itemVisiblePercentThreshold: 70,
          waitForInteraction: true,
        }}
        onViewableItemsChanged={handleViewableItemsChanged}
      />
    </SafeAreaView>
  )
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    marginTop: StatusBar.currentHeight,
  },
  item: {
    backgroundColor: "#f9c2ff",
    height: 300,
    justifyContent: "center",
    marginVertical: 8,
    marginHorizontal: 16,
    padding: 20,
  },
  title: {
    fontSize: 32,
  },
})

export default App

[실행 영상]

요구사항 2. 3번째요소가 50% 노출되었을 때, 5번째 요소가 30% 노출되었을 때 콘솔 찍기

여기에 조금 더 복잡하게 여러 노출 조건이 요구사항으로 왔을 때는 viewabilityConfigCallbackPairs를 이용할 수 있다. viewabilityConfigCallbackPairs는 viewabilityConfig와 onViewableItemsChanged를 묶어서 전달할 수 있는 prop으로, 배열형식으로 전달할 수 있다.

[예시 코드 실행해보기]

import React, { useRef } from "react"
import {
  SafeAreaView,
  View,
  FlatList,
  StyleSheet,
  Text,
  StatusBar,
  ViewToken,
} from "react-native"

const data = Array.from({ length: 50 }, (item, index) => ({
  id: Math.random().toString(12).substring(0),
  title: `Item ${index + 1}`,
}))

type ItemProps = {
  title: string
}

const Item = ({ title }: ItemProps) => (
  <View style={styles.item}>
    <Text style={styles.title}>{title}</Text>
  </View>
)

const TARGET_70_INDEX = 2
const TARGET_30_INDEX = 4
const App = () => {
  const isShownTarget = useRef({
    [TARGET_70_INDEX]: false,
    [TARGET_30_INDEX]: false,
  })

  const handleViewableItemsChanged = (
    {
      viewableItems,
    }: {
      viewableItems: Array<ViewToken>
      changed: Array<ViewToken>
    },
    targetIndex: typeof TARGET_70_INDEX | typeof TARGET_30_INDEX
  ) => {
    if (isShownTarget.current[targetIndex]) {
      return
    }
    const isTargetInView = viewableItems.some(
      item => item.index === targetIndex
    )
    if (isTargetInView) {
      console.log(`${targetIndex} 타켓 노출`)
      isShownTarget.current[targetIndex] = true
    }
  }

  return (
    <SafeAreaView style={styles.container}>
      <FlatList
        initialNumToRender={4}
        renderItem={({ item }) => <Item title={item.title} />}
        keyExtractor={item => item.id}
        data={data}
        viewabilityConfig={{
          itemVisiblePercentThreshold: 70,
          waitForInteraction: true,
        }}
        viewabilityConfigCallbackPairs={[
          {
            viewabilityConfig: {
              itemVisiblePercentThreshold: 70,
              waitForInteraction: true,
            },
            onViewableItemsChanged: info => {
              handleViewableItemsChanged(info, TARGET_70_INDEX)
            },
          },
          {
            viewabilityConfig: {
              itemVisiblePercentThreshold: 30,
              waitForInteraction: true,
            },
            onViewableItemsChanged: info => {
              handleViewableItemsChanged(info, TARGET_30_INDEX)
            },
          },
        ]}
      />
    </SafeAreaView>
  )
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    marginTop: StatusBar.currentHeight,
  },
  item: {
    backgroundColor: "#f9c2ff",
    height: 300,
    justifyContent: "center",
    marginVertical: 8,
    marginHorizontal: 16,
    padding: 20,
  },
  title: {
    fontSize: 32,
  },
})

export default App

[실행 영상]

📚 마무리

만약에 onViewableItemsChanged를 이용하지 않고 특정 요소의 영역이 노출되었을 때를 확인하려면 Viewport높이, 요소의 위치, scroll offset 위치를 직접 계산해서 확인해야 한다. 다행히 RN에서는 내장된 prop으로 이를 자체적으로 계산해주기 때문에 편리하게 사용할 수 있다.

조금 더 자세한 under the hood 내용은 Understand onViewableItemsChanged in FlatList을 참고할 수 있다.

🙌 2024년 3월회고

Sun, 07 Apr 2024 00:00:00 GMT

3월에는 1분기동안 진행중이던 챕터업무들을 목표했던 만큼 완료했고, 새로운 스쿼드로 합류하게 되었다. 1분기를 마치며 배운점들과 시행착오들, 새로운 스쿼드에서 느낀 점들을 정리해보려 한다.

💪 챕터업무 마무리하기

3월은 1분기동안 챕터 업무로 기획하고 담당하고 있던 작업들을 마무리하는 시간들이었다. 1월부터 진행했던 App Start Time 줄이기 작업과 에러바운더리 적용 작업을 기획했던 범위만큼 모두 완료할 수 있었다.

🚀 App Start Time 줄이기

App Start Time 줄이기 일감을 하면서 고민하고 적용했던 작업들을 따로 회고로 작성했다. 3개월이라는 시간동안에 퇴근 후에도, 주말에도 계속해서 자료들을 찾아보고 적용해봤다. 정말 말그대로 자다가도 갑자기 생각나서 시도해보기도 할 정도로 최선을 다해서 작업했던 것 같다. 다행히 3월 내에 목표로 했던 7초에서 4초 이내로 줄여보자라는 OKR을 iOS/Android 두가지 플랫폼 모두 3.2초로 달성할 수 있어 뿌듯했다.

여기에 더불어 성능 개선 일감들을 담당하면서 몇초를 더 줄이고, 얼마나 더 빨라지는 것에 대한 성과가 항상 개발자들만 이해할 수 있는 성과로 남는 것은 아닐까하는 아쉬움이 있었다. 이러한 아쉬움은 이전 4분기에 진행했던 견적발송 로직 개선작업을 진행하면서 처음 느끼게 되었는데, 견적을 발송하는데 걸리던 시간을 줄였다는 것에 뿌듯했지만, 작업에 대해 회사 사내 세미나에서 발표를 진행하고 자료를 정리하는 과정에서 내가 한 작업이 실제 우리 제품을 사용하는 유저에게는 어떤 가치를 주었는지에 대해서 명확하게 알기 어려웠다.

성능 개선은 제품을 사용하는 유저가 분명히 빠르게 "원하는" 동작을 할 수 있게 도와주지만, 그게 유저가 정말 원했던 것인지, 답답함을 느끼고 있는 부분이었는지를 이해하는 건 다른 문제다보니 성능개선을 하더라도 비즈니스적인 관점에서 더 접근해보고 싶었고, 분석하는 작업도 같이 진행해보고 싶었다.

이번 일감에서는 개인적으로 가려웠던 부분을 해결할 수 있었는데, 앱 시작화면에서 홈화면으로 5초 이내로 랜딩하는 유저 데이터를 함께 봤을 때 5% 상승하는 결과를 볼 수 있었다. 이를 통해 조금 더 유저 중심적인 성능 개선을 할 수 있었던 것 같다.

이후에도 미뤄두었던 후순위 작업들을 하나씩 진행하면서 더 나은 제품들을 만드는데 계속해서 기여해보려 한다.

🚑 에러바운더리 적용

23년 4분기에 제안하고 일감화하게된 에러 바운더리 작업을 진행했다. 에러바운더리를 적용하기 위해서 Fallback UI에 어떻게 보여줄지 정하기 위해 UX 리서처분과 플랫폼 디자이너분께 의뢰드려 공통 Fallback UI에 대한 디자인을 전달받을 수 있었다. 작업은 우선 런타임 에러가 발생했을 때, 재시도를 해도 해결되지 않는 경우에 대한 Fallback UI를 만드는 작업을 먼저 진행한 이후에 각 스크린에 적용하게 되었고, 런타임 에러바운더리로 명명하게 되었다.

런타임 에러바운더리를 위한 공통 Fallback UI 컴포넌트를 만들면서 특히 신경썼던 부분은 에러 발생시 레이아웃과 스타일 변화가 최대한 없게 만들기 위해 노력했다. 그러기 위해서 헤더 부분이 중요했는데, 비록 유저가 이용중이던 화면은 이용할 수 없지만 앱을 껐다켜거나 하는 재시작 동작이 없어도, 다른 화면으로 진입하거나 계속해서 제품을 이용할 수 있게 하는 것을 중요하게 생각하고 작업했다. 기본 fallback UI에 헤더컴포넌트를 주입하는 방법 등을 고려해 작업했고, 약 70%의 화면들에 대한 작업을 완료할 수 있었다.

다음 분기에서 이어서 나머지 화면들에 대해 적용하고, 이후에는 런타임 뿐아니라 데이터 조회 API에서 발생하는 에러들을 다룰 때에도 분기문으로 되어있는 코드들을 에러바운더리를 적용해 선언적으로 작성할 수 있게 해보려 한다.

기존에는 화이트 스크린 에러가 발생했을 때, 최상단에서 잡히다 보니 정확한 흐름을 보기 위해서는 사용자 이용 패턴을 따라하는 방법에 많은 시간이 소요되었는데, 스크린 단위로 런타임 에러바운더리를 적용하고 나서는 정확히 어느 화면에서 유저들이 어떤 에러를 겪고 있는지 제보 받을 수 있어 더 좋았다. 이후에 에러바운더리를 제안하고, 적용했던 일감에 대해 정리해보려 한다.

🙌 새롭게 합류한 스쿼드

챕터업무를 마치고 3월 말부터는 새로운 스쿼드에 합류하게 되었다. 분명 작년에도 스쿼드에서 기능개발을 맡아서 진행해왔지만, 3개월 정도 챕터에서 작업을 하고 다시 돌아가고 나니 느낌이 새로웠다.

챕터업무는 하나의 OKR을 위해서 혼자서 고민하고, 혼자서 목표를 위한 일감들에 대한 계획을 짜고 진행했다면, 스쿼드는 OKR을 위해 혼자가 아니라 PO, PD, Data Analyst, QA, BackEnd Engineer, FrontEnd Engineer 다양한 동료들과 함께 의사소통해야 하다보니 완전히 다른 업무를 하게 되는 느낌이었다. 더불어 새롭게 합류한 스쿼드의 업무가 많아 나를 포함해 모바일 엔지니어가 두명인 상황으로 함께 하나의 스토리에 대해 일을 분배하고, 서로가 병목이 되지 않게 하는 것이 중요한 상황이 되었다.

달라진 업무환경에 적응하면서 서로간의 의사소통을 통해 정책 결정, 기술적인 결정 등을 진행해야하기에 조금 더 기술적인 용어대신 조금 더 이해하기 쉬운 용어로 표현하는 법에 대해 더 연습이 필요하겠다는 점을 느꼈고, 혼자 고민하기 보다 정책적인 결정을 위해 PO, PD분들과 이야기 하고, 기술적으로 고민이 될때 스쿼드 엔지니어 분들과 함께 고민할 수 있어서 혼자 일할 때보다 든든함을 느낄 수 있었다.

1년이 지난 지금, 기능개발에 있어서 이전과 조금 다른 시선을 갖게 된 것 같다. 1분기 동안 성능 개선 작업들과 여러 화면들에 대한 에러바운더리를 적용하면서 프로젝트 전반적인 코드들을 볼 수 있었다. 돌아보면서 내가 짠 코드였는데도 왜 이렇게 작성했는지 알 수 없고, 이후에 리팩토링할 수 있는 시간이 오면 해야지라 생각하며 미뤄뒀던 나의 TODO 주석들이 보이기도 했다.

내가 짠 코드들을 보면서 당시 아쉬운 코드를 작성할 수 밖에 없었던 변명같은 이유는 기한 내에 완성하기만을 목표로 작업했기 때문이었던 것 같다. "동작만하면 된거야"라는 생각과 적당히 덜어내고, 내가 모르는 도메인과 같이 사용하는 코드는 유지보수하기 어려우니까 그냥 하나 더 만들어버리는 등 시간에 쫓겨 기능을 개발하다 보니 부족한 부분이 많았던 것 같다.

부족했던 모습에서 더 성장하기 위해서는 기능개발의 가장 기본적인 컴포넌트 설계부터 좀 더 공부할 필요가 있어 보였다. 이를 위해서 이전에 봤던 컴포넌트 설계에 대한 자세한 예시와 인사이트가 잘 담겨있는 토스 slash 컨퍼런스의 Effective Component 지속 가능한 성장과 컴포넌트를 다시 보며 정리하기 시작했고, 2023 RN 리서치에 정리되어 있는 React Native UI 라이브러리들을 돌아보며 확장성과 변화에 유연한 컴포넌트 설계방법을 공부하고 적용해보려 한다.

2023 RN 리서치 UI 라이브러리 결과

두번째로는 UI 패턴별로 최적화하는 방법들에 대해 정리해보려 한다. 이부분도 토스 slash 컨퍼런스의 퍼널: 쏟아지는 페이지 한 방에 관리하기를 통해 인사이트를 얻을 수 있었다. 해당 발표에서 총 세가지 UI 패턴,상점, 단일 페이지, 설문조사으로 소개하고 있고, 실제로 우리 제품에서 구현되는 UI들의 대부분이 세가지 패턴에 포함된다는 점을 알 수 있었다.

상점(목록->상세)

단일 페이지

설문조사 패턴

이렇게 UI 패턴을 묶을 수 있다는 것은 도메인과 요구사항들과 상관없이 공통되게 적용할 수 있는 최적화 요소들이 있고 이러한 부분들을 정리해놓는다면, 내가 담당하는 도메인이 달라져도, 좋은 코드를 작성할 수 있게다는 생각이 들었다.

이렇게 정리한 두가지 액션아이템들에 대해서 잘 정리해서 팀내에도 공유하고 적용하며 더 resourceful한 엔지니어가 되기 위해 노력해보려 한다.

App StartUp time 개선

Wed, 03 Apr 2024 00:00:00 GMT

24년 1Q동안은 스쿼드가 아닌 모바일 챕터에 속해, App Start time 줄이기 업무를 담당했다. App Start Time을 줄이기 위해 시도하고 조사하며 겪었던 시행착오들을 기록해보려한다.

⚠️ App StartUp time이란?

앱 시작 시간 (StartUp time)은 앱을 실행하고 첫 화면이 랜딩되기까지의 시간을 의미한다. 시작시간을 줄이는 것에 대한 작업의 비즈니스적 가치는 앱을 이용하는 모든 유저가 필수적으로 거쳐야하는 퍼널을 빠르게 완료함으로서, 앱을 보다 빠르게 이용할 수 있게 해 사용자 경험을 개선하는 것에 있다.

그러면 이제 App Start time을 단축하기 위해 어떤 시도를 했는지 알아보자.

📌 App StartUp time 측정하기

성능을 비교하기 위해서는 항상 기준이 필요하다. 성능 비교를 위해 작년 4Q에 진행했던 견적발송 개선 작업과 동일하게 Firebase Performance를 이용해 측정했다. 다행이었던 부분은 이전에 측정을 시도했던 코드가 남아있어 참고해서 작업을 진행할 수 있었다.

기존의 기준은 가장 상위 파일인 App -> Start화면 -> 고객/고수 홈화면으로 이동하기까지의 시간이었다. 이미 기준이 잘잡혀 있어 동일한 기준으로 측정하게 되었다.

측정 유틸 개선하기

기준을 세운 이후에 데이터를 측정하는데에는 두가지 케이스에 대한 고려가 필요했다.

첫번쨰로 유저의 타입으로 앱을 이용하는 유저에 따라 Splash Screen에서 필요한 정보가 달라지기 떄문에 비회원/고객/고수 세가지에 맞게 정리하고 데이터를 필터링 할 수 있어야 했다.

두번째는 코드푸시를 이용한 필수 업데이트를 이용하는 경우다. 필수 업데이트를 진행하는 경우에 앱센터에 올라온 새로운 필수 버전이 있는지 체크하고 해당 번들을 설치하게 되는데 이때 설치하는데 추가적인 시간이 소요되기 때문에 이를 고려해야 했다.

위 두가지 케이스를 위해서 먼저 유저타입은 attribute로 trace에 추가하고, 필수업데이트의 경우는 데이터 측정에서 제외시켜 두가지 케이스를 고려해 측정을 진행했다.

측정 코드는 이전 견적발송시간 측정때 구현해둔 Firebase Performance util 모듈에 두가지 케이스를 모두 커버할 수 있게 attribute 추가 메소드와 skip 기능을 추가했다.

[Firebase Performance util]

export class PerformanceTracker {
  private constructor(
    private traceMap: Map<
      keyof typeof PerformanceKey,
      FirebasePerformanceTypes.Trace
    > = new Map(),
    private configMap: Map<
      keyof typeof PerformanceKey,
      { startTime: number; isSkipped: boolean; latestTime: number }
    > = new Map()
  ) {}

  async start(name: keyof typeof PerformanceKey) {
    const trace = perf().newTrace(name)
    const startTime = Date.now()
    this.configMap.set(name, {
      startTime,
      isSkipped: false,
      latestTime: startTime,
    })
    this.traceMap.set(name, trace)
    await trace.start()
  }

  async stop(name: keyof typeof PerformanceKey) {
    const trace = this.traceMap.get(name)
    const config = this.configMap.get(name)
    if (isNil(trace) || isNil(config)) {
      return
    }

    if (config.isSkipped) {
      this.traceMap.delete(name)
      return
    }

    await trace.stop()
    this.traceMap.delete(name)
  }

  addCheckPoint(name: keyof typeof PerformanceKey, metricName: string) {
    const trace = this.traceMap.get(name)
    const config = this.configMap.get(name)
    if (isNil(trace) || isNil(config)) {
      return
    }

    const checkPointTime = Date.now() - config.startTime
    const timeGap = Date.now() - config.latestTime
    trace.putMetric(metricName, checkPointTime)
    this.configMap.set(name, { ...config, latestTime: Date.now() })
  }

  skipTrace(name: keyof typeof PerformanceKey) {
    const config = this.configMap.get(name)
    if (isNil(config)) {
      return
    }
    this.configMap.set(name, { ...config, isSkipped: true })
  }

  addAttribute(name: keyof typeof PerformanceKey, key: string, value: string) {
    const trace = this.traceMap.get(name)
    if (isNil(trace)) {
      return
    }
    trace.putAttribute(key, value)
  }
}

세부 체크포인트 지점 추가하기

이제 구현한 측정 유틸과 전체적인 기준에 각 지점마다의 개선을 보기 위해 체크포인트들을 세웠다. 기준은 4가지로 아래와 같이 정했다.

App 화면 초기화: 최상위 App화면에서 전역적인 provider들과 전역상태, 이벤트리스너들을 준비하고 기기 내부 storage에서 정보들을 가져오는데 걸리는 시간
앱 업데이트 체크: 앱 버전과 코드푸시 업데이트를 체크하는 시간
로그인: 인증토큰을 이용해 로그인을 완료하고 일부 후처리 작업까지 걸리는 시간
홈화면 이동: 로그인 후 홈화면 이동까지 걸리는 시간

그리고 측정 데이터를 볼 때 고수를 기준으로 얼마나 개선되었는지를 보려 했다. 그 이유는 유저 타입별로 호출하는 API 수가 다르기 때문에 데이터의 유저 타입에 의해 결과가 달라지게 되었다. 이를 개선하기 위해서 가장 많은 API를 호출하는 고수로 데이터를 비교해보려 했다.

정의한 체크포인트에 따라 App Start time의 데이터를 정리해보면 개선 작업전 1월 24일부터 2월 14일간 90% 고수 유저 기준으로 OS별 데이터는 다음과 같이 정리할 수 있었다.

체크포인트	iOS	Android
App 화면 초기화	1.6초	1.8초
앱 업데이트 체크	3.3초 (+1,700ms)	2.8초 (+1000ms)
로그인	5.9초 (+2,600ms)	6.2초 (+3,400ms)
홈화면 이동	6.5초 (+600ms)	6.9초 (+700ms)

구간별 시간을 통해서 앱 업데이트부터 로그인 + 홈화면 이동 구간, 업데이트 체크, App화면 초기화 순으로 오래걸리는 구간을 우선순위를 높여 작업을 진행하게 되었다.

🚀 개선 작업

이제는 App Start time을 단축하기 위해 검토하고 시도해봤던 부분들에 대해 정리해보자.

🛜 네트워크 최적화

가장 먼저 실행한 부분은 네트워크 요청 최적화로 불필요한 중복 API를 호출하는 경우가 없는지 체크하고 순서와 상관이 없는 요청들은 동시성을 이용해 네트워크 시간을 최적화했다.

불필요한 요청 감지하기

불필요한 네트워크를 제거하는 작업은 두가지 효과를 기대할 수 있다.

먼저, 네트워크 응답 시간을 줄일 수 있다. 1초가 걸리는 요청을 N번 하고 동기적으로 응답을 기다린다면 N초를 기다려야만 한다.

두번째로, 서버의 부담을 줄여줄 수 있다. 요청이 많다는 것은 그만큼 서버에서 부담해야할 트래픽이 늘어난다는 것이고, 만약 요청이 몰리게 되면 서버에서 처리가 오래걸리게 되거나 타임아웃이 발생할 수 있다. 불필요한 요청을 제거함으로서 서버의 부담을 줄일 수 있다.

측정 시작부터 완료까지 과정에서 호출되는 중복 네트워크 요청들을 조사하기 위해서 Axios interceptor를 이용해 개발환경에서 특정 시간내의 중복 호출을 감지할 수 있는 모듈을 만들어 적용했다. 또한, Firebase Performance의 metric을 이용해 네트워크 응답 시간과 성공률에 대한 데이터를 쌓을 수 있었다.

[중복 API 호출 감지 interceptor ]

const requestMap = new Map<
  string,
  {
    lastTime: number
    count: number
    notify?: (count: number) => void
  }
>()

const requestCheckDuplicatedRequestInterceptor = async (
  config: InternalAxiosRequestConfig
) => {
  if (isProduction()) {
    return config
  }

  const { method, url, params, data } = config
  const requestKey = `${method?.toUpperCase()} ${url} ${JSON.stringify(
    params
  )} ${JSON.stringify(data)}`
  const request = requestMap.get(requestKey) ?? { lastTime: 0, count: 0 }

  const now = Date.now()
  if (request.lastTime === 0 || now - request.lastTime > 1000) {
    const notify = debounce((count: number) => {
      console.warn(`${method?.toUpperCase()} ${url} 반복 요청 ${count} times`)
    }, 1000)

    requestMap.set(requestKey, { lastTime: now, count: 1, notify })
  } else {
    requestMap.set(requestKey, {
      lastTime: now,
      count: request.count + 1,
      notify: request.notify,
    })
    request.notify?.(request.count + 1)
  }
  return config
}

[Firebase Performance network metric]

img.png

중복호출 감지 interceptor를 통해 개발 과정에서 중복 호출되고 있는 API들을 체크한 후에, 첫번쨰 호출받은 응답을 두번째에 이용하게 수정함으로서 중복 호출에 대한 최적화를 할 수 있었다. 네트워크 응답 시간이 오래걸리는 API들은 정리한 후에 백엔드 분들께 전달드려 최적화를 요청해 시간을 단축할 수 있었다.

로그인/로그인 후처리 구간 최적화하기

로그인 과정에서 순서가 중요한 작업들을 고려해 flow를 정리해보면 인증 토큰 가져오기 -> 인증토큰 유효성 검사 -> 로그인 -> 로그인 후처리 로 정리해볼 수 있다. API들을 스텝별로 재분류하고 나니 로그인 이후에는 로그인 후처리 작업간에는 순서가 상관없기 때문에 Promise.all 메소드를 이용해 처리할 수 있어보였다.

그리고 기존에 홈화면 이동 이후에 일부 후처리 작업들이 진행되고 있었지만 모두 완료하고 홈화면으로 랜딩하게 하는 것이 더 합당해보여서 순서를 수정하게 되었다. 아래는 개선한 코드의 일부를 가져와 정리해보았다.

[개선된 Splash 화면 초기화 flow]

// 유저타입별 초기화
const 유저타입별_초기화 = async (userType: UserType) => {
  await Promise.all([
    공통_초기화(),
    유저_초기화(userType),
    고수_초기화(userType),
  ])
}

const 초기화_실행 = async () => {
  try {
    const token = await 토큰가져오기()

    await 업데이트버전체크()

    const deepLink = await 딥링크_정보가져오기()

    const userType = await 로그인(token)
    performanceTracker.addCheckPoint("로그인")

    await 유저타입별_초기화(userType)

    await 홈_화면으로_이동(deepLink)
    await tracker.stopTrace("측정_완료")
  } catch (error) {
    에러핸들링_및_로깅()
  }
}

앱 업데이트 체크 최적화

두 번째로 네트워크 최적화를 진행한 부분은 업데이트 버전 체크부분으로 Codepush 버전과 앱 최소/권장 버전으로 두가지 버전에 대한 네트워크 요청이 순서대로 진행되고 있었다. 각각 요청하는 서버가 다르고 서로 다른 데이터이기 때문에 동시성을 이용해 적용했다.

아래 코드푸시 네트워크 응답 데이터를 보면 90% 유저를 기준으로 android는 1.35초, iOS는 1.69초가 걸리는 것을 볼 수 있다. 동시성을 이용하더라도 오래걸리는 응답에 의존하기 때문에, 큰 개선을 기대하기는 어려웠다.

iOS

Android

자체적으로 번들을 캐싱하는 방법도 고려해봤지만 생각보다 리소스가 클 것 같아 이후에 적용해보기로 계획하고 당시에는 넘어가게 되었다.

이후 챕터 동료 분의 작업으로 자체적인 코드푸시 시스템 구축으로 업데이트를 체크하는데 300ms 내외로 크게 줄어드는 성과가 있었다.

App화면 초기화 구간 최적화

App화면 초기화 구간은 AB테스트 정보와 피쳐플래그를 조회하는 작업과 함께 AppState, 네트워크 상태 등 외부 시스템과의 연결하는 작업이 진행된다.

코드를 보며 발견했던 문제점은 Socket 연결, FCM 연결 등 실시간으로 동작 여부를 체크하는 네트워크 요청이 불필요하게 여러번 호출되고 있었고, AB테스트 정보는 이후 로그인 구간 이후에 다시 조회되는 중복이 발생하고 있었다.

AppState의 경우, 기존 react-native-community의 useAppState 훅을 이용하는 방식에서 RN 내장 모듈 AppState 이벤트 리스너를 이용하는 방식으로 수정해 불필요한 재실행을 해결했다.

[RN AppState 이벤트 리스너 예제]

const appState = useRef(AppState.currentState)
const [appStateVisible, setAppStateVisible] = useState(appState.current)

useEffect(() => {
  const subscription = AppState.addEventListener("change", nextAppState => {
    if (
      appState.current.match(/inactive|background/) &&
      nextAppState === "active"
    ) {
      console.log("App has come to the foreground!")
    }

    appState.current = nextAppState
    setAppStateVisible(appState.current)
    console.log("AppState", appState.current)
  })

  return () => {
    subscription.remove()
  }
}, [])

네트워크 상태는 기존과 동일하게 react-native-netinfo를 이용하지만 불필요하게 리렌더링을 일으키는 useNetInfo를 이용하는 방식이 아니라 Appstate와 동일하게 이벤트 리스너를 이용하는 방식으로 변경했다.

[react-native-netinfo 이벤트 리스너 예제]

// Subscribe
const unsubscribe = NetInfo.addEventListener(state => {
  console.log("Connection type", state.type)
  console.log("Is connected?", state.isConnected)
})

// Unsubscribe
unsubscribe()

AB테스트 정보를 가져올 때는 로그인 전/후 전체 정보를 두번 가져오고 있었다. 이를 개선하기 위해서 기기별로 필요한 클라이언트 AB테스트 정보와 로그인 후에 유저별로 필요한 서버 AB테스트 정보를 조회 요청으로 분리함으로서 불필요한 요청을 줄일 수 있었다.

해당 구간은 Async Storage를 많이 이용해 값을 조회하기 떄문에 성능이 더 좋은 storage로 마이그레이션하는 방법도 고민했지만 챕터 내에서 시도했다가 이슈가 있어 적용하지 못했던 적이 있어 후순위로 진행해보기로 했다.

이외 작업으로는 기존에 네트워크 요청을 보낼 때 AsyncStorage에 있는 토큰을 매번 조회해서 보냈지만, 토큰을 전역상태로 저장한 후에 조회하는 방식으로 변경하는 작업을 진행하는 소소한 개선작업도 진행했다.

결과

이렇게 구간별로 나누어 네트워크 최적화 작업을 진행하고, 2월 14일부터 3월 6일까지 고수 유저의 결과를 보았을 때 os별로 다음과 같은 결과를 얻을 수 있었다.

체크포인트	iOS	Android
App화면 초기화	1.3초(기존 대비 -300ms)	1.3초(기존 대비 -500ms)
앱 업데이트 체크	2.1초 (+800ms, 기존 대비 -900ms)	2.7초 (+1,400ms, 기존 대비 -400ms)
로그인	3.5초 (+1,200ms, 기존 대비 -1400 ms)	3.7초 (+1000ms, 기존 대비 -2400ms)
홈화면 이동	6.3초 (+2800ms, 기존대비 +2000ms)	5.9초 (+2200ms, 기존대비 +1500ms)

결과의 홈화면 이동 이후에 초기화 작업이 진행되지 않기 때문에 이제 측정 완료와 홈화면 이동을 동일하게 볼 수 있다. 결과를 보면 로그인~홈화면이동 구간을 제외하고 각 구간에서 개선이 있었다. 로그인~홈화면이동 구간은 로그인 내부에서 진행하던 작업들을 분리해 후처리 작업을 함께 처리하게 수정했기 떄문에 이전 기록에 비해서 증가했다.

이전기록과 비교했을 때 전체적으로는 iOS에서 6.5초 -> 6.3초로 0.2초 (3%), android에서는 1초(14%) 의 개선이 있었다.

OS별로 개선된 정도가 달랐던 이유는 당시에는 몰랐지만 iOS에서만 FCM 메시지 수신과정에서 문제로 고수분들의 로그인이 풀려 다시 로그인하면서 시간이 조금 더 걸리는 이슈가 있었다. 이후에 해결했을 때, 두 OS 모두 유사한 시간으로 측정되었다.

🖥️ 렌더링 최적화

렌더링 최적화 작업은 불필요한 리렌더링을 막아, 복잡한 연산이 필요한 UI가 다시 그려지면서 시간이 소요되는 것을 방지할 수 있다. 또한 컴포넌트 내부에서 API를 호출하는 경우 불필요한 API 호출을 막아 성능을 개선할 수 있다. 이과정에서 몇가지 알게되었던 부분들을 정리해보려 한다.

전역상태 조회 최적화

스크린간 공유할 데이터 또는 전역적으로 사용되는 데이터를 관리하는 방법으로 전역상태를 이용한다. 우리 프로젝트에서는 Redux를 주로 이용하고 있는데 이때 참조하고 있는 값이 객체인지 primitive한 값인지에 따라 리렌더링이 일어날 수 있다.

예를 들어 아래에 UserProfile 컴포넌트는 userProfile이라는 전역상태를 참조하고 있다. 그리고 OtherComponent는 특정 경우에 userProfile의 일부 속성을 업데이트한다. 코드는 정상적으로 동작하고 문제가 없어보인다.

[UserProfile 컴포넌트]

const UserProfile: React.FC = () => {
  const userProfile = useSelector((state: RootState) => state.userProfile)

  return (
    <div>
      <h1>{userProfile.name}</h1>
      {/* 기타 사용자 프로필 정보를 표시 */}
    </div>
  )
}

const OtherComponent: React.FC = () => {
  const dispatch = useDispatch()

  const changeUserProfilePhoneNumber = () => {
    // `userProfile`의 `phoneNumber` 속성을 업데이트합니다.
    dispatch(updateUserProfile({ phoneNumber: "987-654-3210" }))
  }

  return (
    <button onClick={changeUserProfilePhoneNumber}>전화번호 업데이트</button>
  )
}

하지만 아래 action과 reducer를 보면 OtherComponent의 action에 의해, 불변성을 지키기 위해서 userProfile의 객체가 새롭게 할당되고, 새롭게 할당된 객체로 인해 UserProfile 컴포넌트에 리렌더링이 일어나게 된다.

[action/reducer 코드]

// actions/userProfileActions.ts

export const UPDATE_USER_PROFILE = "UPDATE_USER_PROFILE"

export const updateUserProfile = (updatedProfile: Partial<UserProfile>) => {
  return {
    type: UPDATE_USER_PROFILE,
    payload: updatedProfile,
  }
}

// reducers/userProfileReducer.ts

import { UPDATE_USER_PROFILE } from "../actions/userProfileActions"

const initialState: UserProfile = {
  name: "John Doe",
  phoneNumber: "123-456-7890",
}

const userProfileReducer = (state = initialState, action: any) => {
  switch (action.type) {
    case UPDATE_USER_PROFILE:
      return {
        ...state,
        ...action.payload,
      }
    default:
      return state
  }
}

export default userProfileReducer

이를 방지하기 위해서 전역상태를 참조할 때 객체가 아니라 필요한 값을 참조하게 수정했고, 추가적으로 불필요한 전역상태 조회는 제거하는 방식으로 불필요한 리렌더링을 방지할 수 있었다.

[UserProfile 컴포넌트 수정]

const UserProfile: React.FC = () => {
  const name = useSelector((state: RootState) => state.userProfile.name)

  return (
    <div>
      <h1>{name}</h1>
      {/* 기타 사용자 프로필 정보를 표시 */}
    </div>
  )
}

조건부 렌더링과 custom hook

조건부 렌더링은 특정 조건에서만 노출되어야하는 컴포넌트가 있을 때 자주 사용하게 된다. 하지만 이를 이용할 때도 불필요한 성능이나 API 호출이 일어날 수 있다.

예를 들어 아래는 업데이트 진행률을 표시하기위한 컴포넌트로 isProgressVisible를 prop으로 전달하고 내부에 isProgressVisible이 true일때만 해당 컴포넌트가 렌더링되도록 구현되어 있다.

const SplashScreen: React.FC = () => {
  const { data, loading } = useFetchData()
  const [isProgressVisible, setIsProgressVisible] = useState(false)

  return (
    <View>
      <UpdateProgress isVible={isProgressVisible} />
    </View>
  )
}

const UpdateProgress: React.FC<{ isProgressVisible: boolean }> = ({
  isProgressVisible,
}) => {
  const { progress } = useVersionInfo()

  if (!isProgessVisible) return null
  return (
    <View>
      <Text>{progress}%</Text>
    </View>
  )
}

const useVersionInfo = () => {
  const [progress, setProgress] = useState(0)

  useEffect(() => {
    const fetchProgress = async () => {
      const progress = await getVersionProgress()
      setProgress(progress)
    }

    const interval = setInterval(fetchProgress, 1000)

    return () => clearInterval(interval)
  }, [])

  return { progress }
}

하지만 위 컴포넌트는 문제점을 가지고 있다. UI는 우리가 원한대로 조건부로 보이게 되지만 custom hook은 이와 상관없이 동작하게 된다. 이는 useEffect가 동작하는 사이클과 관련되는데 컴포넌트가 null로 렌더링되더라도 렌더링이 마친것으로 보고 prop과 상관없이 API를 호출하게 된다. 이를 해결하는 것은 간단하다. 컴포넌트의 렌더링 주체를 컴포넌트 내부에서 하지 않고 부모 컴포넌트에서 관리하게 한다.

const SplashScreen: React.FC = () => {
  const { data, loading } = useFetchData()
  const [isProgressVisible, setIsProgressVisible] = useState(false)

  return <View>{isProgressVisible && <UpdateProgress />}</View>
}

const UpdateProgress: React.FC<{ isProgressVisible: boolean }> = ({
  isProgressVisible,
}) => {
  const { progress } = useVersionInfo()

  return (
    <View>
      <Text>{progress}%</Text>
    </View>
  )
}

이렇게 수정하게 되면 UpdateProgress 컴포넌트는 isProgressVisible이 true일때만 렌더링되기 때문에 불필요한 API 호출을 방지할 수 있고, 부모컴포넌트의 코드만 봐도 어떤 컴포넌트가 렌더링 될지를 예측할 수 있는 장점을 가진다.

이외에도 앞서 네트워크 최적화에서 설명했던 Appstate나 Network 상태에 따라 이벤트를 구독할 때 불필요하게 여러번 동작해 리렌더링을 일으키는 부분도 이벤트 리스너를 이용하는 방식으로 수정해 불필요한 리렌더링을 방지할 수 있었다.

결과

렌더링 최적화의 결과를 React Devtools를 이용해 측정해보았을 때 다음과 같은 결과를 얻을 수 있었다.

리렌더링 최적화 Before

리렌더링 최적화 After

동일한 측정기준에서 총 27번의 리렌더링에서 15번으로 줄일 수 있었다. 더 줄일 수도 있지만 개발 환경에서만 렌더링되는 요소도 있고, React navigation, modal 등 서드파티 라이브러리 자체에서 발생하는 리렌더링도 있다보니 여기서 마무리했다.

🛫 최종 결과

1Q 동안 네트워크 최적화와 렌더링 최적화를 주로 진행했고, 90% 유저를 기준으로 4월 3일 90일간 90프로 고수 유저 기준으로 다음과 같은 결과를 얻을 수 있었다.

iOS

Android

결과를 분석해보면 홈화면 이동을 기준으로 iOS는 6.5초에서 3.2초로 50% 개선되었고, Android는 6.9초에서 3.2초로 53% 개선되었다.

위 작업들 뿐만 아니라 챕터내에서 함께 애써주신 작업들 (android에서 적용된 proguard, 자체적인 코드푸시 시스템 구축으로 앱 업데이트 속도 개선) 덕분에 결과적으로 좋은 성과가 있었다.

비즈니스적으로는 실제 메인화면으로 진입하는 퍼널에서 5초 이내에 업데이트 완료 후에 메인으로 진입하는 진입률이 5% 증가하는 성과가 있었다. 전체적으로 Start time 완료 시간이 줄어들어 사용자 경험에 긍정적인 영향을 준 것으로 보인다.

🤔 시도하지 못했지만 이후 적용해볼만한 부분

1분기 동안은 네트워크와 렌더링 최적화에 중점을 맞추어 진행해 기간내에 실행하지 못했던 아이디어들이 있었다.

개선 아이디어

각 아이디어별로 간단하게 정리해보면 다음과 같다.

번들 최적화

번들 최적화 작업은 react native의 실행환경이자 번들러인 metro는 tree-shaking을 지원하지 않고 있다. 그렇기 때문에 번들링 과정에 사용하지 않는 코드들이나 모듈들이 있을 수 있고 JS는 모든 코드들이 준비된 다음에 동작하기 때문에 번들이 커질수록 초기 실행속도가 느려질 수 있다. 이를 위해서 프로젝트 내에서 사용중인 lodash나 moment와 같은 라이브러리를 개별적으로 사용하거나, 필요한 부분만 가져와 사용하는 방법을 적용해보려 했다.

toss에서 발표했던 번들러를 Metro에서 ESBuild로 전환했던 경험을 공유해주신 React Native, Metro를 넘어서를 보면서 적용하면 어떨까 생각도 했지만 아직 번들러에 익숙하지 않아 시간이 많이 필요해보여 미루게 되었다.

해당 일감은 1분기에 진행하지 못했지만 2분기 챕터 일감으로 기획되어 있어 일부 기여해보려 한다.

네이티브 모듈 최적화

우리가 작성하는 코드의 대부분이 JS이기 떄문에 먼저 JS적인 최적화를 진행했지만, Native 모듈들을 최적화하는 방법도 있다. JSI, Turbo module과 같은 new architecture를 도입해 bridge를 이용하지 않고 native 모듈을 사용하는 방법 등 네이티브 적인 개선도 할 수 있을 것 같아보였다.

하지만 Native에 대한 지식이 부족하다보니 조금 더 익숙하고 이해하기 쉬운 JS적인 최적화를 먼저 진행하고 이후에 시도하려고 후순위로 미루게 되었다. 이후에 Native 모듈을 연결하는 방법들을 공부하고 적용해보면 좋을 것 같다.

AsyncStorage 마이그레이션

앱 초기단계에서 AsyncStorage를 많이 이용하고 있는데, AsyncStorage는 비동기적으로 동작하기 때문에 성능에 영향을 줄 수 있다. 이를 해결하기 위해서는 성능이 좋은 storage로 마이그레이션하는 방법이 있어 보였다. 하지만 마이그레이션 자체에 대한 비용이 조금 더 많이 들게 되지 않을까 하는 생각이 들어서 후순위로 미루게 되었다.

2분기 일감으로 계획되어 있지는 않지만 mmkv나 op-sqlite와 같은 라이브러리를 이용해 AsyncStorage를 대체하는 방법도 고려해보려 한다.

Native Stack

우리 프로젝트는 React Navigation의 custom router를 이용해 사용하고 있다. Custom Router는 화면 전환시 JS에서 동작하기 때문에 화면전환간 JS 스레드를 blocking하고 성능이 떨어질 수 있다. 이를 개선하는 방법으로 Native Stack을 이용해 화면전환을 Native에서 처리하게 하여 JS 스레드를 blocking하지 않는 방법을 생각해 봤다.

성능은 개선되겠지만 Start Time 과정에서 화면 전환은 splash 화면에서 메인화면으로 한번밖에 없기 때문에 효과가 미미할 것 같아 후순위로 기획해둔 작업이었다.

2분기 일감으로 기획되어 있어 적용하고 화면 전환간 성능도 함께 알아볼 예정이다.

📚 마무리

하나의 큰 일감을 기획하고 3달동안 고민하고 자료조사를 하고 실제로 의미있었던 작업도 성과가 미미했던 작업도 있었다.

이과정에서 ReactNative 환경에서 어떻게 JS가 동작하는지, React의 렌더링 과정이 어떻게 동작하는지에 대한 이해가 더 깊어질 수 있었고, 성능 최적화에 대한 이해도가 높아진 것 같다.

개인적으로 모든 유저가 겪게되는 과정을 개선하는 일감이라 압박도 많았지만 좋은 결과로 마무리된 것 같아 뿌듯하다. 앞으로도 성능 최적화에 대한 고민과 개선을 지속적으로 진행해보려 한다.

이벤트 루프 in React/React native 1편

Sun, 17 Mar 2024 00:00:00 GMT

앞선 글을 통해 Promise.all는 자바스크립트의 동시성을 이용한 메소드임을 정리해보았다. 이어서 자바스크립트에서 비동기 처리를 가능하게 하는 기본원리인 이벤트 루프를 React와 React Native 예제 코드와 함께 정리해보려 한다.

🤔 이벤트 루프란?

이벤트 루프는 자바스크립트에서 코드를 실행하고 이벤트를 처리하는 역할을 하며, 단일 스레드로 동작하는 자바스크립트에서 비동기 처리를 가능하게 한다. 이벤트 루프의 동작을 코드로 같이 정리해보자.

⬇️ 동기 처리

const foo = () => console.log("First")
const bar = () => console.log("Second")
const baz = () => console.log("Third")

foo()
bar()
baz()

위 코드를 실행하면 First, Second, Third 순서로 출력이 된다. 이는 동기적으로 실행되는 코드로 자바스크립트는 기본적으로 코드를 위에서 아래로 순서대로 읽고 실행한다.

⏩ 비동기 처리

그러면 이제 비동기 함수들에 대해서 알아보자.

⏩ 비동기 처리: callback 함수

const foo = () => console.log("First")
const bar = () => setTimeout(() => console.log("Second"), 0)
const baz = () => console.log("Third")

foo()
bar()
baz()

// 결과
// First
// Third
// Second

이러한 결과를 이해하기 위해 아래 시각화된 gif를 통해 함께 이해해보자.

[참조: ✨♻️ JavaScript Visualized: Event Loop]

코드는 위에서 아래로 동일하게 위에서 아래로 순서대로 실행되지만,

foo()함수가 실행되고
bar()함수가 실행되면서 setTimeout가 실행된다. 이때 브라우저는 비동기적으로 실행되는 코드를 task queue에 넣는다.
baz()함수가 실행되고
이때 call stack이 비어있으면 이벤트 루프는 task queue에 있는 코드를 call stack으로 옮겨 실행한다.

이벤트 루프는 위와 같이 Network 요청, 이벤트 등과 같은 시간이 오래걸리는 작업을 진행할 때 오랜시간 스레드를 차지해 다음 작업을 처리하지 못하는 것을 방지해준다.

🅾️ 비동기 처리: Callback의 무한 loop

그러면 만약 callback 함수가 계속해서 쌓이게 되는 상황을 생각해보자. 이때 React와 React Native에서 이벤트 루프가 어떻게 동작할까?

React에서 콜백을 계속해서 만드는 예제로 두가지 상태를 이용한 예제 코드를 작성해봤다.

count: 버튼 클릭시 무한 루프로 콜백함수를 task queue에 쌓는 역할
value: input에 값을 입력해 리렌더링을 일으켜 JS 스레드 blocking을 확인하는 역할

[React 코드]

function App() {
  const [value, setValue] = useState<string>("")
  const [count, setCount] = useState<number>(1)

  const makeInfiniteCallback = () => {
    setTimeout(() => {
      setCount(prev => prev + 1)
      makeInfiniteCallback()
    }, 0)
  }
  const handlePress = () => {
    makeInfiniteCallback()
  }

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    console.log(e.target.value)
    setValue(e.target.value)
  }

  return (
    <div
      style={{
        justifyContent: "center",
        display: "flex",
        flexDirection: "column",
        alignItems: "center",
        gap: "10px",
      }}
    >
      <input value={value} onChange={handleChange} />
      <span>Count: {count}</span>
      <button onClick={handlePress}>Click</button>
    </div>
  )
}

export default App

React 코드 실행 영상 with JS thread

영상속 이벤트 루프가 동작하고 있는 순서를 정리해보자.

버튼 클릭시 makeInfiniteCallback 함수가 실행된다.
setTimeout이 실행되면서 task queue에 콜백함수가 쌓이게 된다.
이벤트 루프는 callstack이 비어있으면 queue되어 있는 콜백함수를 call stack으로 가져와 실행한다. (count 값이 1씩 증가)
이때 다시 callback 함수가 실행되면서 setTimeout이 실행되고 task queue에 쌓이게 된다.
(무한 루프)
이 사이에 input에 값을 입력하면 상태를 업데이트하게 되고 업데이트된 상태를 이용해 일정 시간마다 다시 DOM을 그리는 과정이 진행된다. (리액트의 렌더링 과정)
callStack에 쌓인 작업을 실행하면서 console을 찍고 화면을 리렌더링한다.
6번과정 이후 call stack이 비어있으면 다시 task queue에 있는 콜백함수를 call stack으로 옮겨 실행한다.
1~7까지의 과정을 반복한다.

이를 통해 확인할 수 있는 것은 이벤트루프는 task Queue에 다른 작업이 queue되어 있더라도 하나씩 callstack에 가져와서 처리하기 때문에 JS 스레드가 멈추지 않고 계속해서 작동하는 것을 확인할 수 있다.

추가적으로 RN에서도 확인해보면 리액트와 동일하게 작동하며 RN의 performance tool을 이용해 JS 스레드를 보았을 때도 멈추지않고 동작하고 있는 것을 볼 수 있다.

[RN 코드]

function App(): React.JSX.Element {
  const [value, setValue] = useState("")
  const [count, setCount] = useState(1)
  const makeInfiniteCallback = () => {
    setTimeout(() => {
      setCount(prev => prev + 1)
      makeInfiniteCallback()
    }, 0)
  }
  const handlePress = () => {
    makeInfiniteCallback()
  }

  const handleChange = (text: string) => {
    console.log(text)
    setValue(text)
  }

  return (
    <SafeAreaView
      style={{ flex: 1, justifyContent: "center", alignItems: "center" }}
    >
      <StatusBar barStyle={"dark-content"} />
      <Button title={"시작하기"} onPress={handlePress} />
      <TextInput
        style={{
          width: 200,
          height: 40,
          borderWidth: 1,
          borderColor: "black",
          margin: 10,
          textAlign: "center",
        }}
        value={value}
        onChangeText={handleChange}
      />
      <Text>{count}</Text>
    </SafeAreaView>
  )
}

export default App

RN 코드 실행 영상 with JS thread

⏩ 비동기 처리: Promise

Promise는 비동기 처리를 위한 객체로, 성공과 실패를 나타내는 상태와 성공시 결과값, 실패시 에러를 나타내는 값으로 이루어져 있다. 이러한 상태에는 총 세가지가 있다.

Pending: 초기 상태
Fulfilled: 성공 상태
Rejected: 실패 상태

Promise는 callback과 같이 비동기로 동작하지만 별도의 queue를 통해 동작한다. 이를 microtask queue라고 하며, 이벤트 루프는 task queue보다 먼저 실행된다.

이제 코드를 통해 Promise의 비동기 처리과정을 알아보자.

console.log("Start")

setTimeout(() => console.log("TimeOut!"), 0)

Promise.resolve("Promise!").then(res => console.log(res))

console.log("End")

// 결과
// Start
// End
// Promise!
// TimeOut!

위 코드는 앞서 정리했던 콜백함수와 함께 Promise 코드를 처리하는 예제다. 결과를 아래 gif와 함께 분석해보자.

[참조: ⭐️🎀 JavaScript Visualized: Promises & Async/Await]

1. Start 출력

이벤트 루프는 console.log('Start')를 call stack에 쌓고 JS 엔진이 읽어 start 로그가 찍힌다.

2. setTimeout 실행

이벤트 루프는 다음줄을 call stack에 쌓고 실행된다. setTimeout의 callback은 task queue에 쌓이게 된다.

3. Promise 실행

이벤트 루프는 Promise를 call stack에 쌓고 실행된다. Promise.resolve로 전달된 Promise!가 then 메소드로 전달된다. 이후 then의 callback은 microtask queue에 쌓이게 된다.

4. End 출력

이벤트 루프는 console.log('End')를 call stack에 쌓고 JS 엔진이 읽어 End 로그가 찍힌다.

5. Promise 출력

이벤트 루프는 call stack이 비어있는지 확인하고 queue된 작업을 call stack으로 가져와 실행한다. 이때 microtask Queue를 먼저 확인해 Promise의 then 메소드로 전달된 callback을 call stack으로 가져온다. 이후 콜백이 실행되면 Promise!가 출력된다.

6. setTimeout 출력

이벤트 루프는 다시 call stack이 비어있는지 확인하고 queue된 작업을 call stack으로 가져와 실행한다. 이때 microtask Queue가 완전히 비었는지 확인한다. micro task queue가 비었으므로 이제 task Queue를 확인해 setTimeout의 callback을 call stack으로 가져오고 실행한다.

이러한 과정을 통해서 이루어지기 때문에 결과가 Start -> End -> Promise! -> TimeOut! 순서로 promise가 callback보다 먼저 출력되게 되었다.

🅾️ 비동기 처리: Promise의 무한 loop

이제 실제 React와 React Native에서 Promise를 사용하는 예제를 통해 이벤트 루프가 동작하는 것을 확인해보자. 앞서 gif를 이용한 동작과정에 대해 알아보았을 때 Promise는 두가지 특징을 볼 수 있었다.

별개의 microtask queue를 통해 동작한다.
task queue보다 우선순위가 높다.

앞서 언급했지만 이벤트 루프가 Promise를 처리할 때 또다른 특징을 가진다. 이벤트 루프는 microtask queue에 쌓인 모든 promise를 처리한 후에 다시 돌기 시작한다. 이를 알아보기위해 무한 loop되는 상황을 만들어 확인해보자.

아래 코드는 위 callback 무한 루프와 동일한 예제로 callback을 Promise로만 바꾸어 동작시켜보려 한다.

[React 코드]

function App() {
  const [value, setValue] = useState<string>("")
  const [count, setCount] = useState<number>(1)

  const makeInfinitePromise = () => {
    Promise.resolve().then(() => {
      setCount(prev => prev + 1)
      makeInfinitePromise()
    })
  }
  const handlePress = () => {
    makeInfinitePromise()
  }

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    console.log(e.target.value)
    setValue(e.target.value)
  }

  return (
    <div
      style={{
        justifyContent: "center",
        display: "flex",
        flexDirection: "column",
        alignItems: "center",
        gap: "10px",
      }}
    >
      <input value={value} onChange={handleChange} />
      <span>Count: {count}</span>
      <button onClick={handlePress}>Click</button>
    </div>
  )
}

export default App

아래 영상을 보면 리액트 코드를 동작시켰을 때 다음과 같이 이벤트루프가 동작하게 된다.

버튼 클릭시 makeInfinitePromise 함수가 실행된다.
Promise.resolve().then()이 실행되면서 microtask queue에 then 내부 콜백함수가 쌓이게 된다.
이벤트 루프는 callstack이 비어있으면 microtask queue에 있는 함수를 call stack으로 가져와 실행한다.
이때 다시 callback 함수가 실행되면서 Promise.resolve().then()이 실행되고 microtask queue에 쌓이게 된다.
(무한 루프)
1번부터 4번까지의 과정이 반복된다.

React 코드 실행 영상 with JS thread

예제를 통해 microtask queue가 모두 비어질 때까지 계속해서 microtask queue의 작업을 하는 것을 알 수 있었다. 추가적으로 callback 때와 다르게 클릭 후 count가 올라가지 않는 모습을 보인다. 이는 then 콜백에 포함된 set함수가 동작하지 않는 것처럼 보인다.

이부분을 이해하려면 리액트의 렌더링 과정에 대해 이해할 필요가 있다. set함수는 promise를 통해 계속해서 호출되어 V-DOM에 변경사항이 계산된다(render phase, reconciliation). 하지만 실제 DOM을 다시 그리는 과정(Commit phase)은 이벤트 루프가 microtask queue에 갇히게 되어 UI업데이트가 불가능하기 때문에 계산한 DOM을 실제 DOM에 반영하지 못하게 된다. 이로인해 set함수가 동작하지 않는 것처럼 보이게 된다.

유사한 코드를 RN에서는 어떻게 동작하는지 알아보자.

[RN 코드]

function App(): React.JSX.Element {
  const [value, setValue] = useState("")
  const [count, setCount] = useState(1)
  const makeInfinitePromise = () => {
    Promise.resolve().then(() => {
      setCount(prev => prev + 1)
      makeInfinitePromise()
    })
  }
  const handlePress = () => {
    makeInfinitePromise()
  }

  const handleChange = (text: string) => {
    console.log(text)
    setValue(text)
  }

  return (
    <SafeAreaView
      style={{ flex: 1, justifyContent: "center", alignItems: "center" }}
    >
      <StatusBar barStyle={"dark-content"} />
      <Button title={"시작하기"} onPress={handlePress} />
      <TextInput
        style={{
          width: 200,
          height: 40,
          borderWidth: 1,
          borderColor: "black",
          margin: 10,
          textAlign: "center",
        }}
        value={value}
        onChangeText={handleChange}
      />
      <Text>{count}</Text>
    </SafeAreaView>
  )
}

export default App

RN 코드 실행 영상

React Native는 Main 스레드와 JS 스레드가 비동기적으로 소통하며 동작하기 때문에 JS 스레드가 무한루프에 빠져도 Main 스레드가 동작할 수 있어 TextInput에 값을 입력할 수 있었다. 하지만 JS 스레드는 동일하게 microtask queue에 머물러있기 때문에 JS 스레드의 프레임 측정이 불가능해지고 TouchableOpacity의 애니메이션도 돌아오지 않는 것을 볼 수 있다.

이를 통해 Promise는 callback과 다르게 microtask queue를 통해 동작하며, 이벤트 루프는 microtask queue에 쌓인 모든 작업을 처리한 후에 다시 돌기 시작한다는 것을 확인할 수 있다.

Promise.all의 동시성 이해하기

Sun, 03 Mar 2024 00:00:00 GMT

🙄 자바스크립트가 병렬처리?

아마 작년 말부터 2월까지 작업했던 작업 중 가장 많이 한 작업 중 하나가 순차적으로 진행되는 비동기 코드를 Promise.all()을 이용해 한번에 동작할 수 있게 최적화하는 작업이었다. 사람들에게 말할 때는 병렬처리라고 표현하곤 했지만 내안에 어색함이 느껴졌다. 자바스크립트는 싱글스레드 언어인데 어떻게 여러가지 일을 동시에 처리하는 걸까에 대한 질문을 찾아갔던 과정을 정리해보려 한다.

🤔 자바스크립트 엔진의 동작 파헤쳐보기

자바스크립트는 싱글 스레드 언어다. 이말의 의미는 한번에 하나의 일만 할 수 있게 설계되어 있는 언어로 이벤트 루프를 이용해 call stack으로 들어온 하나의 일만 한번에 처리할 수 있다. 그러면 어떻게 Promise.all([...]) 같은 코드를 통해 동시에 여러가지 일을 동시에 처리하는 것이 가능할까.

Sequence vs Parallel vs Concurrent

자바스크립트에서 여러가지 일을 동시에 처리하는 것에 대해 정확하게 이해하기 위해서는 Sequence, Parallel, Concurrent의 차이를 이해해야 한다.

Sequence: 순차적으로 실행되는 것을 의미한다. A -> B -> C 순서대로 실행되는 것을 의미한다.
Parallel: 말그대로 동시에 실행되는 것을 의미한다. A, B, C가 동시에 실행되는 것을 의미한다.
Concurrent: 병렬적으로 실행되는 것처럼 보이지만, 실제로는 동시에 실행되지 않는 것을 의미한다. A, B, C가 동시에 실행되는 것처럼 보이지만, 실제로는 A가 실행되고, B가 실행되고, C가 실행되는 것을 의미한다.

출처: [Does Promise.all Execute in Parallel? How Promise.all Works in JavaScript](https://javascript.plainenglish.io/does-promise-all-execute-in-parallel-how-promise-all-works-in-javascript-fffc2e8d455d)

따라서 위 정의에 따라 자바스크립트가 여러가지 일을 동시에 처리할 수 있다는 것의 의미가 parallel이라면 실제로 여러가지 일을 동시에 실행하는 것으로, concurrent하다면 순차적으로 진행하지만 빠르게 진행되기에 동시에 진행되는 것처럼 보인다고 할 수 있다. parallel과 concurrent 두가지 동작 중 어떤 게 맞는지 확인하기 위해 예를 들어, 코드와 함께 알아보자.

자바스크립트 스레드를 웨이터로 예를 든다면 다음과 같이 정리할 수 있다.

Sequence: 웨이터가 하나의 테이블에 대해 주문을 받고 음식이 나오면, 다음 테이블에 대해 주문을 받는 것을 의미한다.
Parallel: 여러 웨이터가 여러 테이블에 대해 동시에 주문을 받고 동시에 음식이 나오는 것을 의미한다.
Concurrent: 한명의 웨이터가 여러 테이블의 주문을 순서대로 받고 주문을 넣지만 빠르게 이 과정이 진행되다 보니 여러 테이블의 대한 음식이 거의 동시에 나오는 것을 의미한다.

그러면 예제 코드를 이용해 위 세가지 상황에 대해 확인해보자. 아래 코드는 orderAndServe라는 함수를 이용해 테이블에 대한 주문을 받고 음식을 서빙하는 코드이다.

function orderAndServe(startTime, ms, tableNumber) {
  console.log(`테이블 ${tableNumber} 도착 - ${new Date() - startTime}ms`)
  return new Promise(resolve => {
    console.log(`테이블 ${tableNumber} 주문 받음 - ${new Date() - startTime}ms`)
    return setTimeout(() => {
      resolve(tableNumber)
    }, ms)
  }).then(number => {
    console.log(
      `테이블 ${number} ${ms}ms 후 음식 나옴 - $${new Date() - startTime}ms`
    )
  })
}

async function sequenceRun(startTime) {
  await orderAndServe(startTime, 1000, 1)
  await orderAndServe(startTime, 1000, 2)
}

async function concurrentOrParallelRun(startTime) {
  await Promise.all([
    orderAndServe(startTime, 1000, 1),
    orderAndServe(startTime, 1000, 2),
  ])
}

만약 자바스크립트가 Parallel하게 동작하다면 두가지 가정을 해볼 수 있다.

실행할 때 마다 끝나는 테이블의 순서가 다를 수 있다. 독립적인 스레드에서 진행되기 때문에 결과의 순서가 보장되지 않을 수 있다.
각 테이블에 도착하는 시간, 주문을 받는 시간, 음식이 나오는 시간이 같다.

Sequential	Concurrent

위 사진은 두가지 테이블에 대해서 각 함수를 실행한 결과로, sequential처럼 항상 테이블1에서 테이블 2로 같은 순서로 진행되는 것을 볼 수 있다.

위 가정했던 두가지 중 parallel 하다는 가정의 첫번째가 어긋난 것을 볼 수 있다. 하지만 두 번째 가정이었던 테이블별 도착, 주문, 서빙 시간이 같다는 가정은 맞는 것을 볼 수 있다. 그러면 조금 더 많은 테이블을 서빙하게 해보자

function orderAndServe(startTime, ms, tableNumber) {
  console.log(`테이블 ${tableNumber} 도착 - ${new Date() - startTime}ms`)
  return new Promise(resolve => {
    console.log(`테이블 ${tableNumber} 주문 받음 - ${new Date() - startTime}ms`)
    return setTimeout(() => {
      resolve(tableNumber)
    }, ms)
  }).then(number => {
    console.log(
      `테이블 ${number} ${ms}ms 후 음식 나옴 - $${new Date() - startTime}ms`
    )
  })
}
const tables = Array.from({ length: 10 }, (_, i) => i + 1)

async function concurrentOrParallelRun(startTime) {
  await Promise.all(
    tables.map(tableNumber => orderAndServe(startTime, 1000, tableNumber))
  )
}
concurrentRun(new Date())

아래 사진은 위 10개의 테이블에 대한 코드를 실행한 결과다. 아래결과를 보면 테이블 1부터 10까지 순서가 유지되고, 테이블별 각 동작 완료시간의 차이가 나는 것을 볼 수 있다.

테이블이 10개일 때 결과

이를 통해 Promise.all()은 병렬적(parallelism)으로 처리하는 것이 아니라 자바스크립트의 동시성(concurrency)을 이용해 순차적으로 진행하지만 빠르게 진행함으로서 성능의 이점을 얻을 수 있는 메소드임을 알 수 있었다.

번외: 병렬을 지원하면 결과가 어떻게 달라질까

내가 했던 parallelism에 대한 두가지 가정이 실제 병렬 처리 지원하는 언어에서 유의미하게 동작하는지에 대해 알아보고자 ChatGPT를 이용해 Go언어로 유사한 코드를 작성해보았다.

package main

import (
	"fmt"
	"sync"
	"time"
)

func orderAndServe(startTime time.Time, ms time.Duration, tableNumber int, wg *sync.WaitGroup) {
	defer wg.Done() // 이 함수가 끝나면 WaitGroup의 카운터를 감소시킨다.

	fmt.Printf("테이블 %d 도착 - %vms\n", tableNumber, time.Since(startTime).Milliseconds())
	fmt.Printf("테이블 %d 주문 받음 - %vms\n", tableNumber, time.Since(startTime).Milliseconds())
	time.Sleep(ms)
	fmt.Printf("테이블 %d %vms 후 음식 나옴 - %vms\n", tableNumber, ms.Milliseconds(), time.Since(startTime).Milliseconds())
}

func main() {
	startTime := time.Now()
	var wg sync.WaitGroup

	// 10개의 테이블에 대해 병렬로 처리
	for i := 1; i <= 10; i++ {
		wg.Add(1) // WaitGroup의 카운터를 증가시킨다.
		go orderAndServe(startTime, 1000*time.Millisecond, i, &wg)
	}

	wg.Wait() // 모든 고루틴이 완료될 때까지 기다린다.
}

위 코드는 go언어로 작성한 코드로, sync.WaitGroup을 이용해 병렬로 함수를 진행시켰다. 아래는 위 코드를 실행한 결과다.

go언어로 작성한 코드 결과

결과를 보면 테이블 도착과 주문받음까지 진행 순서가 테이블 1부터 진행하지 않고 (첫번째 가정의 독립적인 스레드), 완료한 시간을 보면 동일하게 처리된 것 (두번째 가정의 같은 시간에 완료)을 볼 수 있었다. 이를 통해 앞선 두가지 가정이 병렬처리가 가능한 언어의 특징을 잘보여주는 가정이었고, Promise.all()은 병렬적으로 처리하는 것이 아니라 자바스크립트의 동시성을 이용하는 메소드임을 한번 더 확인할 수 있었다.

[참조]

🙊 2024년 2월회고

Fri, 01 Mar 2024 00:00:00 GMT

🙊 개발자로 일한지 1년이 되다니...

2월은 회사에 입사해 만 1년이 되는 달이었다. 벌써 1년이 되다니, 1년간의 시간 동안 내가 어떤 일을 했고, 어떤 성과를 만들었는지 나와 동료, 회사의 평가를 통해 되돌아 볼 수 있는 시간이었다.

1년간의 나를 되돌아보면서 나에 대해서 리브랜딩(?) 또한 필요하다고 생각이 들어, 블로그를 이전하고 이력서도 새롭게 작성했고, 이와 함께 더 다양한 시야를 갖기 위해 커뮤니티 활동에 참여하기도 했다. 1년 중 가장 짧은 달이지만 회사 내외적으로 나름 다사다난했던 2월을 되돌아 보려 한다.

😍 Gatsby로 블로그 이전하기

블로그 이전은 사실 오랜기간 고민해왔던 일이었다. 기존에 Jekyll로 만들어진 블로그의 디자인은 괜찮긴 했지만, ruby 언어로 작성되어 커스텀을 위해 학습비용이 크다는 점과 상대 경로를 제대로 이해하지 못하는 이슈 등이 있어 2024년에는 꼭 이전해야겠다는 목표를 세웠다.

세웠던 목표는 1년치 계획이었는데... 2월에 회사에 입사한지 1년이 된 겸, 깃허브 프로필에도 걸려있는 블로그가 내 얼굴과 같다는 생각이 들어 블로그 이전을 실행에 옮기게 되었다.

블로그 이전은 해야겠는데... 마땅한 플랫폼이 떠오르지 않았다. 내가 직접 만드는 방법도 좋은 경험이 되겠지만, 글을 작성하는 것 자체에 더 초점을 맞출 수 있게 플랫폼을 먼저 알아보자는 맘이 들어 이것저것 찾아보기 시작했다.

다행히 나처럼 고민하시는 분들이 많았는지 개발자 블로그 플랫폼에 대해 비교하는 다양한 글들을 볼 수 있었다. 티스토리, Velog, wordpress 등의 플랫폼들은 이전에 이미 작성해놓은 글들을 이전하는 작업에 많은 수고가 필요하다는 점과 내가 직접 커스텀할 수 없다는 단점이 크게 작용해 다른 방법은 없을까 고민하게 된다.

그러던 중 우연히 페이스북에서 만든 리액트를 이용한 문서화 서비스인 Docusaurus에 대한 글들을 접하게 되었다. Docusaurus는 리액트를 이용하다 보니 기존 내가 알고 있는 지식을 이용해 커스텀이 가능했고, 마크다운 형식으로 작성된 글을 그대로 복사/붙여넣기만 하면 해당 글을 분석해 페이지형식으로 만들어 줄 수 있었다. React Native 공식문서에도 쓰이고 있고, 실제 블로그 마이그레이션 후기 글들도 있어 공식문서를 읽으면서 작업을 시작하게 되었다.

Docusaurus로 블로그 이전하기

컨텐츠에만 집중하라니 너무 좋은데?

Docusaurus는 markdown으로 작성된 글을 커스텀 디자인, SSG(Static-Site generator)를 이용해 성능이 높은 페이지를 만들어 준다. Docusaurus 내부에는 총 두가지로 컨텐츠를 구분할 수 있는데, 하나는 Docs로 기술 문서를 작성하는 형식으로 버전별 문서관리가 필요하거나, 주제별 하위 컨텐츠 분류 등을 적용할 때 사용할 수 있어 보였고, 다른 하나는 Blog로 블로그 형식의 글을 작성할 수 있게 해준다.

나는 블로그용으로 사용하려 하기 때문에 Blog에 대한 세팅을 하고 프로젝트에 이전에 작성해둔 마크다운 파일들을 옮겨 이전을 하기 시작했다. 세팅을 하고 보니 Docusaurus 블로그 자체적인 아쉬운 점이 눈에 보이기 시작했다.

기술 블로그는 시리즈로 연속된 게시물들을 보여주는게 필요한데, Docusaurus는 해당 기능을 Blog에서 지원하지 않았고, 각 주제에 따라 몇개의 글이 작성되었는지를 알 수 없다는 점이 아쉬웠다. 블로그 이전을 참고했던 parkgang.log님 블로그에서는 회고와 같은 글을 Blog로, 기술적인 내용은 docs로 분류해 주제별 글을 정리해두셨지만, 똑같이 적용하기 전 "그래도 내맘에 쏙드는 다른 플랫폼은 없을까" 마지막으로 찾는 과정에서 Gatsby를 발견하게 된다.

Gatsby로 블로그 이전하기

Gatsby 메인화면

Gatsby 또한 Docusaurus와 같이 SSG를 이용해 정적 페이지를 만드는 데 최적화된 플렛폼으로 리액트로 작성되어있다. Docusaurus와 동일하게 마크다운 파일을 페이지로 만들어 주기 때문에 쉽게 이전이 가능하고, Docusaurus 블로그를 사용하시는 분들을 찾는 것보다 더 다양한 개발자분들이 사용하고 있는 점도 좋았다.

왜 많은 사람들이 Gasby를 블로그로 많이 사용할까?에 대해 생각해보았을 때, Gasby는 블로그 플러그인을 통해 마음에 드는 디자인과 구성을 템플릿으로 사용할 수 있게 제공하고 있었고, 원하는 기능들을 플러그인으로 연결할 수 있는 점이 좋아보였다. Jekyll 블로그 때와 같이 어떤 디자인으로 블로그를 만들면 좋을까 고민하다가 devHudi라는 분께서 만들어 두신 gatsby-starter-hoodie라는 플러그인이 마음에 들어 현재 블로그로 이전하게 되었다.

Gatsby로 이전하는 과정에서 블로그 글들을 다시 한번 읽으며 내가 이때는 이런 걸 어려워했구나라는 생각과 1년사이 많이 성장했구나라는 생각이 들었다. 한편 내가 블로그 관리를 소홀히 했구나를 여실히 느낄 수 있었는데, 참조로 한 글이나 이미지가 사라져서 보이지 않거나, 상대경로가 잘못되어있는 경우도 보였다... 상대주소와 Jekyll 때 깃허브에 올려서 정리했던 이미지 주소들을 로컬주소로 변경하는 등의 작업을 진행하고 GA(Google Analytics)와 utterance를 통한 댓글도 적용해보았다. 이후에 방명록, 방문자 수 등의 기능을 추가하고 계속해서 나의 성장과정을 잘 보여줄 수 있게 가꿔나가야겠다.

🤿 프론트엔드 다이빙 클럽

2월에는 회사 밖, 커뮤니티 활동에도 관심을 갖고 있었는데 링크드인 게시글을 보고 토스에서 운영하는 프론트엔드 커뮤니티인 프론트엔드 다이빙 클럽에 지원하게 되었다. 사실 이전에도 토스 블로그의 소개 글을 보면서 다양한 회사의 각자의 문제를 풀고 계시는 프론트엔드 개발자분들과 이야기를 나눠보고 싶고, 내가 가진 시야를 넓혀주는 좋은 기회가 되지 않을까라는 생각에 지원했지만 떨어졌었다. 이번엔 정말 운좋게 참여하는 기회를 얻어 개발환경 개선이라는 주제로 참여하게 되었다.

가서 어떤 이야기를 하게 될까, 아는 사람이 아무도 없을텐데... 별의 별 고민을 하면서 참여했지만 금새 적응해 편하게 이야기할 수 있었다. 조원분들은 내가 생각했던대로 다양한 회사에서 오셨고, 다양한 관심사를 가지고 계셨다. 신기했던 부분은 대부분 조원분들이 모노레포에 대한 관심을 많이 가지고 계셨던 점이었다 모노레포로 된 프로젝트 경험이 없던 나에게는 모노레포가 어떤 문제를 해결하기 위한 기술인지, 왜 좋은 건지 등 배경이 없다보니 같이 많은 이야기를 할 수는 없었지만 좋은 키워드를 얻어가는 시간이었다.

명찰과 굿즈

조원분들과 신나게 이야기하던 중에 세션시간이 시작되었는데 첫번째 주제는 모노레포 파이프라인 최적화에 대해, 두번째 주제는 생산성 높게 API 호출하는 방법에 대한 주제로 발표를 해주셨다.

첫번째 발표를 들으면서 처음 들었던 생각은 "패키지 관리에 사람들이 정말 많은 관심을 가지고 있구나"였다. 직전에 조원분들간의 이야기 주제도 발표주제도 모노레포로 서비스를 잘 운영하는 방법이다 보니 더 확 느껴졌다.

발표내용중 놀랐던 점은 yarn을 이용한 zero install을 사용할 경우 node_modules에 설치되는 패키지를 모두 함께 올려두게 된다는 점이었다. repository에 올라와있는 파일 자체가 엄청나게 크기 때문에 이를 clone하고 checkout하는 과정 자체의 시간이 오래걸릴 수 있다는 문제가 있었고, 이를 해결하기 위해 circle CI의 config등을 통해 병렬화 또는 배포시간 단축 등에 대해 이야기해주셨다. 패키지를 올리지않고 repo를 가져온 다음에 매번 패키지를 설치하는 게 당연했던 나에게 새로운 이야기였다.

프론트엔드에서 플랫폼적으로 문제를 해결해나가는 모습을 보며 CI/CD 과정에서도 기술적으로 해결하나가야할 재밌는 문제들이 많이 있구나를 느낄 수 있었고 우리 팀 프로젝트의 CI/CD중에서 내가 개선할 수 있는 부분은 없을까 고민하는 좋은 시간이 되었다.

두번째 발표는 기능을 구현하는 과정에서 겪을 수 있는 서버의 API와 프론트엔드 코드가 강결합이 되어 있을 때 발생할 수 있는 여러가지 문제를 예시로, 프론트엔드 자체적인 interface를 구현해 어떻게 일정에 맞게 또 안전하게 프론트엔드 코드를 지킬 수 있을지에 대한 내용이었다. 들으면서 우리 프로젝트의 아키텍처 구조에서 Repository 패턴이 동일한 역할을 하고 있고 덕분에 API가 나오지 않았을 때도 API 명세만 알면 병렬로 프론트엔드 코드를 작성할 수 있었던 점이 떠올랐다.

발표가 끝나고 나서는 뒷풀이에도 참여해 같은 조가 아니었던 분들과도 이야기하며 다양한 연차와 경험을 가지신 분들의 이야기를 들을 수 있었다. 만나는 분마다 느꼈던 점은 여기에 모이신 분들은 모두 금요일 저녁에 퇴근 후 모여서 개발얘기를 하고 싶을 만큼 개발을 너무 좋아하시는 분들이라는 것 그리고 더 많이 배우고 성장하고 싶어하시는 분들이라는 것을 느낄 수 있었다. 처음 참석한 커뮤니티 자리였지만 너무 좋은 영향과 열정을 느낄 수 있었던 시간이었다.

😆 마무리

블로그를 이전하면서 기술적인 주제에 대한 이야기와 회사 업무를 진행하면서 해결해간 기술적인 문제에 대한 이야기는 분리하는 게 좋지 않을까라는 생각이 들었다. 그래서 앞으로는 회고에는 한달간 공부한 내용들에 대해, 개인적인 이야기를 작성하고, 기술적인 내용은 다른 글로 분리해 조금 더 작성해보려 한다. 앞으로 회고에 쓸 내용이 없으면 어쩌나 고민도 되지만... 오히려 더 부지런하게 기술적 주제에 대한 글을 작성하고 요약하는 방식으로 작성하면 되지않을까 싶다. 그래서 2월동안 진행했던 에러바운더리 적용 작업과 App Start 시간 줄이기 작업에 대한 내용은 다음 글에서 작성해보려 한다.

2월 한달간도 다양한 경험이 가득한 알찬 시간, 내 자신에 대해 고민하고 다음 1년에 대해 고민하는 좋은 시간이었던 것 같다. 3월은 또 어떤 일이 기다리고 있을지 기대하며 더 열심히 달려보자.

🐥 2024년 1월회고

Wed, 07 Feb 2024 00:00:00 GMT

1월에는 스쿼드에서 챕터로 소속이 바뀌면서 업무가 기능개발에서, 성능을 최적화하고 안정성을 높이기 위한 업무들이 주를 이루게 되었다. 크게 집중해서 진행했던 업무는 App Start시간을 최적화와 에러바운더리 적용이었다. 두 가지 챕터 업무와 함께 불필요한 API 호출을 감지하는 방법에 대해 고민하고 해결방법을 찾아 적용해보았다.

1월 업무를 새롭게 배우게 된 점과 느꼈던 점들을 간단히 정리해보려 한다.

⚠️ 불필요한 API 호출을 감지해보자

불필요한 API를 줄이는 것은 서비스를 이용하는 고객의 사용성을 높이고, 서버의 부하를 줄일 수 있는 두 가지 장점이 있다. 그 중요성을 저번 견적 발송 시간을 줄이면서 느끼고 개발단계에서 아는 방법이 없을지 고민했고, 이것을 해결하는 방법으로 axios interceptor를 이용해보기로 했다.

axios interceptor

axios interceptor는 axios의 요청과 응답을 가로채는 기능이다. 이를 이용해 요청과 응답에 대한 로직을 추가할 수 있어 공통적인 요청과 응답에 대해 처리를 할 수 있다.

[axios interceptor 공식문서 예시 코드]

// Add a request interceptor
axios.interceptors.request.use(
  function (config) {
    // Do something before request is sent
    return config
  },
  function (error) {
    // Do something with request error
    return Promise.reject(error)
  }
)

// Add a response interceptor
axios.interceptors.response.use(
  function (response) {
    // Any status code that lie within the range of 2xx cause this function to trigger
    // Do something with response data
    return response
  },
  function (error) {
    // Any status codes that falls outside the range of 2xx cause this function to trigger
    // Do something with response error
    return Promise.reject(error)
  }
)

이러한 기능을 이용해 구현한 중복 API를 체크하기 위한 코드는 아래와 같다.

[axios interceptor를 이용한 중복 API 체크 interceptor]

const requestMap = new Map<string, { lastTime: number; count: number }>()

const 중복체크_request_interceptor = async (
  config: InternalAxiosRequestConfig
) => {
  const { method, url, params, data } = config
  const requestKey = `${method?.toUpperCase()} ${url} ${JSON.stringify(
    params
  )} ${JSON.stringify(data)}`

  const request = requestMap.get(requestKey) ?? { lastTime: 0, count: 0 }
  const now = Date.now()
  if (request.lastTime === 0 || now - request.lastTime > 1000) {
    requestMap.set(requestKey, { lastTime: now, count: 1 })
  } else {
    requestMap.set(requestKey, { lastTime: now, count: request.count + 1 })
    console.warn(
      `${method?.toUpperCase()} ${url} 반복 요청 ${request.count + 1} times`
    )
  }
  return config
}

위와 같이 interceptor를 통해 들어온 요청 정보를 key로 한 Map에 기록하고 중복 API라고 볼 수 있는 것의 기준은 우선 1초 정도로 정해보기로 했다. 이렇게 구현하고 나면 다음과 같이 warning이 찍히는 것을 볼 수 있다.

[warning으로 찍힌 중복호출 로그]

중복호출로그

구현하고 나니, 실제로 발생하고 있는 API들을 찾을 수 있었는데, 중복 API가 발생할 때마다 찍히다 보니 로그가 너무 많이 찍히는 문제가 있었다. 이를 해결하기 위해서 간단하게 debounce를 이용해 logging 코드를 감싸주었다.

[debounce를 적용한 중복 API 체크 interceptor]

const notify = debounce(({ method, url, count }) => {
  console.warn(`${method?.toUpperCase()} ${url} 반복 요청 ${count + 1} times`)
}, 1000)

const requestMap = new Map<string, { lastTime: number; count: number }>()

const 중복체크_request_interceptor = async (
  config: InternalAxiosRequestConfig
) => {
  const { method, url, params, data } = config
  const requestKey = `${method?.toUpperCase()} ${url} ${JSON.stringify(
    params
  )} ${JSON.stringify(data)}`

  const request = requestMap.get(requestKey) ?? { lastTime: 0, count: 0 }
  const now = Date.now()
  if (request.lastTime === 0 || now - request.lastTime > 1000) {
    requestMap.set(requestKey, { lastTime: now, count: 1 })
  } else {
    requestMap.set(requestKey, { lastTime: now, count: request.count + 1 })
    notify({ method, url, count: request.count })
  }
  return config
}

[하나만 찍히는 로그]

중복호출로그

구현 후, 개발과정에서 중복 호출되는 API들을 확인할 수 있었고, 이를 통해 실제로 어떤 화면에서 발생하고 있는지 알 수 있었다. 조금 아쉬운 점은 개발환경에서 인지하고 싶어서 추가한 코드이지만 우리 프로젝트 코드에 추가되기보다 debugger에 표기되는 게 더 좋아 보였다.

이후에 RN 디버거를 분석해보면서 해당 기능을 만들어보는 것도 좋을 것 같다.

🛫App Start 시간 줄이기

챕터로 소속이 변경되고 24년 1분기 모바일 챕터 목표로 App Start 시간 단축 일감을 담당하게 되었다. 기존에 측정하고 있던 기준은 최상위 파일인 App.tsx가 렌더링 된 이후 부터 Splash을 거쳐 홈화면에 진입하기까지였다.

측정 기준 잡기

가장 먼저 시도한 방법은 네트워크 적 병목이 있는지 체크함으로써 불필요한 API들은 제거하고 차례로 진행되고 있는 병목지점들을 병렬화함으로써 시간을 단축하려 했다.

홈화면에 들어가기 전에 주요하게 진행해야 할 프로세스는 세 가지로 다음과 같이 정리할 수 있다.

앱 버전 체크 및 업데이트
인증토큰을 이용한 로그인
로그인 후 초기화 작업

위 세 가지가 모두 완료되고 나서 홈 화면으로 이동할 수 있기 때문에 이 세 가지 프로세스가 모두 완료되는 데까지 걸리는 시간을 측정하기로 했다. 그리고 각 스텝의 완료지점에 checkpoint를 주어 얼마의 시간이 걸리는지 정보를 추가했다.

[중요 지점에 체크포인트를 반영된 Splash 화면 코드]

const 초기화_실행 = async () => {
  try {
    await 토큰가져오기()
    performanceTracker.addCheckPoint("인증토큰 가져오기")

    await 업데이트버전체크()

    const deepLink = await 딥링크_정보가져오기()
    performanceTracker.addCheckPoint("딥링크 정보 가져오기")

    await 로그인()
    performanceTracker.addCheckPoint("토큰 기반 로그인")

    await tracker.stopTrace("기존_trace_측정_완료")
    await 홈_화면으로_이동(deepLink)
    performanceTracker.addCheckPoint("홈 화면 이동")

    await 초기화작업1()
    // ...
    await 초기화작업N()
    await tracker.stopTrace("새로운 trece_측정_완료")
  } catch (error) {
    에러핸들링_및_로깅()
  }
}

위 코드에서 새로운 trace를 추가한 이유는 초기화가 모두 완료되는 데까지 시간을 알고 싶었다. 홈 화면으로 이동시키고, 이후에 일부 초기화 작업이 진행되고 있어, 화면전환이 응답속도보다 빠른 경우는 깜빡이거나 layout shift가 발생하고 있다는 점을 발견하게 되어 모두 완료하는 게 유저 경험에 더 좋을 것 같았다. 그래서 우선 전체 초기화를 완료하는 데 필요한 시간을 함께 보고자 했다.

현재 추가한 중간지점들의 데이터를 IOS 90% 유저 기준으로, 다음과 같이 데이터를 쌓아볼 수 있었다.

인증토큰 가져오기: 1.6초 (최상위 App.tsx를 렌더링한 후부터 Splash 화면에 진입한 후에 인증토큰을 가져오기까지)
딥링크 불러오기: 3초 (버전 체크, 딥링크 정보 불러오기까지)
토큰 기반 로그인: 5.8초 (로그인+ 일부 로그인 후 작업까지)
홈 화면 이동: 6.3초 (로그인 후 홈 화면으로 이동하기까지)

위 측정결과를 보고 먼저 딥링크 정보를 불러오고 나서 화면 이동까지의 시간을 단축해 보려 했다. 이를 위해서 유저 타입을 기준으로 초기화 작업을 진행할 수 있게 리팩토링했다.

유저타입을 중점으로 생각했던 이유는 두 가지로, 먼저 유저타입별로 초기화 작업을 위한 API 호출 횟수가 달랐다. 비회원/고객/고수 모두가 사용하는 공통 초기화 로직, 고객과 고수만을 위한 초기화 로직, 고수만을 위한 초기화 로직 총 세 가지로 구분할 수 있었고, 유저가 고수라면 세 가지 모두를 진행해야 해서 가장 시간이 오래 걸리는 유저 타입으로 예상되었다.

두번째로는 기존에는 로그인 함수 내부에 일부 초기화 작업이 포함되어있거나 초기화 작업 각각 내부에서 로그인 여부 또는 유저 타입을 체크해 실행하게 되어 있었던 것을 타입별로 묶어 병렬처리할 수 있어보였다.

유저타입별 초기화 리팩토링

설계를 마치고 나서는 필요하지 않은 API를 찾는 것과 필요한 API들의 순서 정하기는 개별 API를 분류하는 작업을 진행했다. 필요하지 않은 API를 찾는 작업에 앞서 구현한 중복 API 체크 유틸 덕분에 어떤 API가 중복되는지 알 수 있었고, 이를 통해 필요하지 않은 API를 찾아 제거하는 작업을 진행했다.

이어서 남은 필요한 API들은 서로의 논리적 전후 관계를 정리해 토큰 불러오기 - 로그인 -유저타입별 초기화 순으로 흐름이 진행될 수 있게 했다. 이렇게 세 가지로 분류된 흐름 속에서 유저 타입별 초기화 작업들을 병렬로 처리해 시간을 단축하려 했다.

[유저타입을 들어낼 수 있게 리팩토링한 초기화 코드]

// 유저타입별 초기화
const 유저타입별_초기화 = async (userType: UserType) => {
  await Promise.all([
    공통_초기화(),
    유저_초기화(userType),
    고수_초기화(userType),
  ])
}

const 초기화_실행 = async () => {
  try {
    await 토큰가져오기()

    await 업데이트버전체크()

    const deepLink = await 딥링크_정보가져오기()
    performanceTracker.addCheckPoint("딥링크 정보 가져오기")

    const userType = await 로그인()
    performanceTracker.addCheckPoint("토큰 기반 로그인")

    await 유저타입별_초기화(userType)

    await 홈_화면으로_이동(deepLink)
    performanceTracker.addCheckPoint("홈 화면 이동")

    await 로깅()
    await tracker.stopTrace("새로운_측정_완료")
  } catch (error) {
    에러핸들링_및_로깅()
  }
}

작업을 완료하고 개발환경과 Prod환경이 다르다 보니 얼마나 줄어들 수 있을지, 예상이 되지 않지만 앞서 초기화 작업이 화면이동보다 늦어져서 layout shift가 일어나는 문제는 해결할 수 있었고, 예외처리도 적용함으로서 보다 안정적으로 홈화면으로 진입할 수 있게 되었다. 현재 배포되지 않은 상황이라 결과가 어떻게 될지 걱정 반, 기대반으로 기다리고 있다.

그외 시간을 줄이기 위한 방법들

앞서 나눠두었던 세가지 측정지점에 따라 다음 방법들에 대해 고민하고 챕터내에서 논의를 진행했다. 먼저 업데이트 버전체크와 딥링크정보를 가져오는 지점을 개선할 수 있어 보였다. 여기서 가장 핵심이 되었던 부분은 앱버전 업데이트 체크로 코드푸시의 자체 메소드를 이용해서 App center의 올라와있는 버전과 현재 앱의 버전을 체크하고 있고, 체크하는데 90프로 유저 기준으로 1.6초가 소요되고 있었다.

단축하기 위한 방법으로 배포과정에서 해당 버전과 필수 업데이트 필요 여부등을 기록하는 자체 플래그를 만든다면 codepush 메소드를 사용하지 않고 사용이 가능해보였다. 하지만 진실의 원천이라 할 수 있는 App Center의 버전을 체크하지 않고 자체적으로 구현하는 것은 안정성에 대한 우려가 있고, 비용이 큰 작업이 될 것 같아 앞선 개선작업의 결과를 보고 작업해보기로 했다.

마지막 남은 방법으로는 인증 초기화 전까지의 단계, 앱 번들을 불러오고 실행할 때 병목지점을 찾는 것이었다. 이부분은 아직 정확한 지점을 찾지못해 네트워크적인 접근외에도 여러 React native 최적화와 관련된 글과 논의를 보면서 방법을 찾고있다.

Bundle Splitting, Hermes, JSI등에 대해 검토해 보았지만, 이미 우리 앱에서는 Hermes엔진을 사용하고 있고, 현재 우리가 측정기준에 맞춘 최적화가 아니기 때문에 JS 스레드 자체의 부담을 줄일 수 있는 방법에 대해 고민이 필요해 보였다.

가장 기본적인 불필요한 리렌더링을 줄이는 작업을 먼저 진행하고, 이후에 번들의 크기를 줄이는 등의 작업을 진행할 예정이다.

🚥 에러바운더리 적용

드디어 에러 바운더리를 적용 작업을 시작했다. 내가 계획한 적용방법은 가장 바깥쪽부터 안쪽으로 에러바운더리를 적용하는 것으로, 최상위 에러바운더리를 시작으로 스크린단위로 적용해 나갈 예정이었다.

필요한 에러바운더리를 최상위에 적용하기 위해 App.tsx를 수정했고, error를 감지할 수 있게 적용했다.

class App extends Component<{}, State> {
    state: State = {
        hasError: false,
    };

    constructor(props: Record<string, never>) {
        super(props);
    }

    componentDidCatch(error: Error, errorInfo: React.ErrorInfo) {
       에러로깅()
    }

    static getDerivedStateFromError() {
        return { hasError: true };
    }

    handleRestartApp = () => {
        CodePush.restartApp();
    };

    render(): ReactElement {
        const { hasError } = this.state;

        if (hasError) {
            return (
                <FallabckComponent retry={handleRestartApp} />
            );
        }
        return (
            //...
        );
    }
}

export default App;

최상위 에러바운더리에 에러가 도달했을 때에 앱을 재시작할 수 있게 도와주는 게 좋을 것 같아, Codepush를 이용한 restart 기능을 추가했다.

구현자체는 어렵지 않았지만, 조금 더 고민이 되었던 것은 어떻게 안내해주는 게 유저입장에서 도움이 될 수 있을까였다. 혼자 고민하다가 챕터원분들의 도움을 받아 다양한 시안을 만든 후에, UX writer 분과 플랫폼 디자이너분들의 도움을 받아 완성했다.

챕터내의 업무인데 다른 챕터분들께 일을 만들어 드리는 건 아닐까라는 고민이 되었지만 실제로 요청드렸을 때 너무 흔쾌히 도움을 주셨고, 오히려 현재 이번년도 분기 OKR과 연관된 작업이라 개발자분들께 에러 발생시 화면들에 대한 조사를 부탁드리려 했다는 이야기를 들어 함께 협업하는 좋은 계기가 되었다.

나보다 더 잘 아시고, 잘 하시는 분께 적절한 도움을 받는게 중요함을 또 다시 느낄 수 있었다.

📚그외에 배운점

App Start개선 작업들을 진행하면서 현재 React Native 아키텍쳐 자체에 대한 공부가 필요했다. 해당 내용들을 따로 정리하면서 블로그에 올려보고 new Architecture, JSI등 RN팀에서 많은 노력을 기울이고 있다는 점도 알 수 있었다. 또한 에러바운더리를 적용하면서 실제적으로 제안하고 적용하면서 앱의 안정성에도 기여할 수 있어 좋았던 한달이었다.

개인적으로 계속해서 자동화나 조금 더 일을 효율적으로 처리하기 위한 방법들도 고민하게 되는 것 같다. 중복 API호출 감지 유틸을 만들기도 하고, App Start 시간을 줄이는 작업을 하면서 JS Bundle 최적화를 위해 Lodash 패키지 전체를 직접 import하지 않게 스크립트를 작성하기도 했다. 유의미한 결과가 나타나게 되면 블로그에 글도 작성해볼 예정이다.

아직 너무너무 배울게 많다고 느껴 버겁게 느껴지기도 하지만, 더 좋은 방법에 대해 치열하게 고민했던 한달이었다. 큰 개선이 되지 않더라도, 치열하게 고민하는 것 자체가 내가 성장해가는 과정이길 바라면서 마쳐본다.

🌟 2023년 12월 회고

Sun, 31 Dec 2023 00:00:00 GMT

12월에는 제 1회 숨테크 사내 세미나에서 발표 연사로 참여했고, 내가 속해있던 스쿼드의 마지막 작업으로 바로견적 상세화면을 개선하는 작업을 진행했다. 그리고 마지막으로 새벽점검에 참여해 챕터원 중 가장 많은 새벽점검을 한 챕터원이 되었다. 연말이지만 나름 다사다난했던 12월을 회고해보려한다.

🙋‍♂️ 사내 세미나 발표하기

11월에 참여하겠다고 자신있게 자원했지만... 먼저 주제를 먼저 정하고 발표해보고 싶다고 자원한 게 아니었기 때문에, 내가 너무 성급하게 결정한 게 아닌가 생각이 들었다. 하지만 나는 신입이니까 뭘하든, 앞에서 실수를 많이 하더라도 나에게 도움이 되는 경험이 될 것이란 생각으로 준비해봤다.

주제에 대해 고민하면서 기술 세미나이기 때문에 기술적으로 깊이가 있는 주제를 정하면 좋겠다고 생각했지만, 숨고에 들어와 주요 도메인중 하나인 견적도메인에 대한 일감들을 진행해온 과정을 대해 정리해 모바일 엔지니어로서의 성장기를 주제로 발표해보고 싶었다.

그렇게 정한 주제는 숨고와 함께 모바일 엔지니어로 자라기로 1년간 시간 순으로 2Q의 스쿼드, 3Q의 챕터, 4Q의 테크 OKR 작업에 참여하면서 경험과 레슨런들을 정리해 발표했다.

[숨테크 포스터]

숨테크 포스터

2Q. 스쿼드에서 처음 만나게된 견적 도메인

2Q에는 스쿼드에서 요청견적서 실험을 진행하게 되었다. 5월 회고에서 작성했던 내용처럼 두가지 스크린을 통해 진행되는 견적작성 flow를 하나의 요청견적서 화면으로 합쳐, 요청서 내용을 보면서 견적서를 작성할 수 있게 사용성을 향상시키려한 일감으로, 5월 회고에 작성했던 실험과정에서 생긴 배포 이후 딥링크로 접근시 견적을 작성할 수 없었던 장애와 디버깅 과정을 담았다.

당시 처음 견적도메인에 대한 실험을 진행하다 보니 도메인에 대한 이해도가 낮아 leadId와 requestId로 요청서 Id를 다르게 호출하고 있던 이유를 몰랐고, 웹개발 경험만 있다보니 모바일 개발에서 중요한 딥링크에 대한 고려가 부족해 발생했던 장애였다.

[디버깅 결과를 정리한 코드]

디버깅 결과를 정리한 코드

이과정을 통해서 내가 얻었던 레슨런은 모바일 개발의 중요한 포인트인 딥링크에 대한 고려와 도메인에 대한 정확한 이해었다. 이어진 고민으로는 "이러한 장애를 만들지 않기 위해서 노력해도 사람이다 보니 실수를 할 수 있는데 실수가 발생해도 시스템적으로 빠르게 대응하기 위해서는 어떻게 할 수 있을까?", "어떻게 하면 시스템적으로 장애를 빠르게 감지할 수 있을까"로 이어지게 되었다.

3Q. 에러/예외처리 고도화

3Q에는 스쿼드 작업과 함께 챕터에서 에러/예외처리 고도화 작업을 시작했다. 블로그 회고로는 7월 회고부터 등장한 작업으로 발표에는 시간관계상 에러 분류기준을 새롭게 정하고 견적도메인에 적용한 과정을 담았다.

모바일 프로젝트는 에러 로깅 툴로 버그스낵을 사용하고 있는데, 당시 슬랙과 연동되어있는 로깅 알림 채널에 버그스낵으로 로깅되는 모든 에러가 채널에 제보되고 있었다. 에러가 발생했으니 제보받는 것은 맞지만, 에러 핸들링이된 로그들도 모두 찍히다 보니 중요한 에러가 발생해도 한번에 확인이 어려웠다.

이러한 문제점을 해결하기 위해서 분류 기준을 세분화하는 작업을 진행했고, 아래 사진과 같이 기준을 세워 기존 분류를 수정하는 작업과, 새롭게 필요한 부분에 대한 로그를 추가하는 작업을 진행했다.

[에러 분류 기준]

에러 분류 기준

기준을 세우고 먼저 적용한 도메인은 이전에 장애가 발생했던 견적도메인이었고 아래와 같이 분류를 세분화해 로깅하는 작업을 진행했다.

[에러 분류 기준을 적용한 견적도메인]

에러 분류 기준

이러한 분류작업을 하면서 자연스럽게 견적발송 과정에서 사용되는 API들에 대해 조사하게 되었고, 이과정에서 견적발송 가능여부를 체크하는 과정에서 같은 API를 여러번 호출하는 상황을 발견하게 되었다.

4Q. 테크 OKR 견적발송 퍼널 개선

4Q에는 Tech OKR 작업으로 견적발송 퍼널 개선작업에 참여하게 되었다. 10월 회고에 작성한 내용으로 기존 앞서 에러/예외처리 고도화작업을 진행하면서 발견한 중복 API를 줄이면 견적 발송시간을 크게 줄일 수 있지 않을까라는 가설을 가지고 작업을 진행했다.

내가 세운 가설을 검증하기 위해서는 기존 실제 우리 유저가 겪고 있는 견적발송 시간에 대한 데이터가 필요했고, 이를 위해 Firebase Performance를 적용해 견적발송 시간을 측정하는 작업을 먼저 진행했다. 측정 결과는 11월 9일부터 11월 23일간 90% 유저 기준으로 IOS는 견적발송 가능 여부를 체크하는데 5.6초, 견적발송 완료에는 총 7.59초, Android는 견적 발송 가능여부 체크에 6초 견적발송 완료에는 8.05초가 걸리고 있었다.

위 데이터를 두가지로 정리해 볼 수 있었는데 먼저, 중복 API가 발생하고 있는 견적발송 가능여부 체크에서 전체 시간의 70%이상이 걸리고 있고, 90% 유저 기준이지만 견적발송이 오래 걸리고 있다는 점이었다. 데이터를 통해서 중복 API를 줄임으로써 견적발송 시간을 줄일 수 있을 것이라는 가설에 대한 좀 더 높은 확신을 가지고 작업을 진행할 수 있었다.

개선작업은 두가지 step으로 진행되었는데, 기존 각각 useCase 함수 내부에서 가능여부를 체크하기 위해 별도로 호출하던 API들을 견적발송 전체 flow를 담당하는 상위함수에서 병렬 호출하게 했다. 다음은 응답 결과를 각각 useCase에 param으로 전달해주었다.

[개선 작업]

개선 작업

개선 작업 후 결과를 개선전과 같은 기간 비교해보았을 때 IOS에서 5.6초에서 0.73초로 87%정도 감소했고, 견적발송완료에는 7.59초에서 2.96초로 61프로가 감소했다. Android에서는 견적발송 가능여부 체크에 6초에서 0.89초로 85%정도 감소했고, 견적발송완료에는 8.05초에서 3.06초로 61%정도가 감소했다.

[견적발송 시간 개선 전/후 비교]

견적발송 시간 개선 전/후 비교

이러한 결과를 비즈니스적으로 조금 더 풀어보고자 50%, 75%, 85%, 90%, 95% 유저에 대한 두 OS의 데이터를 보았을 때 50%가 넘는 개선이 있었고 한마디로 유저가 견적을 한번 보낼 시간에 두번 보낼 수 있게 되었다고 정리해보았다.

작업을 하면서 얻었던 레슨런은 클라이언트에서 API를 어떻게 사용하는지가 유저경험에 어떤 영향을 줄 수 있는지에 느낄 수 있었다. 이어진 고민으로는 어떻게 우리 프로젝트 내부의 불필요한 API 호출을 감지할 수 있을지, 그리고 어떻게 하면 불필요한 API 호출을 줄일 수 있을지에 대해 고민하게 되었다.

발표하고 느낀점

위 내용들과 함께 간단하게 내년에 숨고에서 하고 싶은 일들에 대해서도 공유해보며 발표를 마쳤다. 발표 당일 3시부터 세미나가 시작되었는데 떨려서 그전까지 일이 잘 잡히지 않았다. 발표를 마치고 나서야 간식도 먹고 웃을 수 있었다 🤣 발표를 위해서 꽤 많이 연습했는데, 내 기준에서는 다행히 준비한 내용을 무사히 다 말할 수 있었고 (청중분들은 다르게 느끼셨을 수도...) 누군가 앞에 서서 말한다는 게 얼마나 힘든일인지, 또 얼마나 큰 경험인지도 같이 느낄 수 있었다. 내년에는 조금 더 기술적으로 성장해서 깊이 있는 주제로도 발표해보고 싶다는 마음과 함께 누군가에게 내 이야기를 전할 수 있는 개발자, 공유할 수 있는 게 많은 개발자가 되고 싶다는 목표가 생긴 정말 좋은 경험이었다.

[발표하는 모습]

발표하는 모습

‍🥲️ 스쿼드 마지막 작업, 바로견적 상세화면 개선 실험과 서버 점검

12월을 마지막으로 다음 달부터는 챕터으로 소속을 잠시 옮기게 되었다. 그전에 마지막으로 진행하게된 바로견적 상세화면과 새벽점검에 대해서 간단하게 정리해보려 한다.

바로견적 상세화면 개선 실험

바로견적은 고수분이 설정한 조건에 맞는 요청서가 작성되었을 때 미리 작성된 내용을 이용해 자동으로 견적서를 매칭시켜주는 기능이다. 고수분들의 일과 중에 늘 앱에 접속해 있으실 수 없기 때문에 자동으로 매칭시킴으로써 편의성을 개선할 수 있는 도메인이다. 이전 지역 개선 작업 이후에 두번째 개선 작업으로 바로견적 상세화면을 개선하게 되었다.

바로견적은 자동으로 견적을 매칭시키다 보니, 도중에 다양한 실패사유에 의해 멈추게 될 수 있었다. 기존에는 진행/정지/캐시부족 세가지 상태만 보여줬다면 정확히 어떤 사유로 멈추게 되었는지 좀 더 명확하게 보일 수 있게 했고, 로띠와 햅틱을 추가해 UX를 개선했다.

📳 햅틱이 뭐야?

로띠는 이전에도 사용해본 적이 있었지만 개선작업을 통해 햅틱에 대해 새롭게 알게되었다. 햅틱은 유저에게 진동 또는 모션을 적용해 터치하는 느낌을 줄 수 있는 기술로, 예시로 이번에 적용하려는 부분은 정지된 바로견적 캠페인을 다시 재개하게 되었을 때 유저가 진동을 느끼면서 바로견적이 다시 시작되었다는 것을 알 수 있게 하는 것이었다.

이를 구현하기 위해서 react-native-haptic-feedback 라이브러리를 사용했고, 사용법은 아래와 같다.

import HapticFeedback from "react-native-haptic-feedback"

const options = {
  enableVibrateFallback: true, // 햅틱을 적용할 수 없는 ios 10 이하에서 heavy로 진동하는 설정
  ignoreAndroidSystemSettings: false,
}

HapticFeedback.trigger("impactLight", options)

시각적인 요소(애니메이션) 뿐 아니라 진동을 통한 유저 인터랙션에 대해 새롭게 알고 경험할 수 있는 좋은 기회가 되었다.

🌘 새벽 서버 점검

세번째로 참여하게 된 새벽 서버 점검 작업으로 챕터원 중 가장 많이 새벽점검에 참여한 사람이 되었다 🤣

서버 점검이 자주 있는 작업이 아니다 보니, 서버점검에 참여했던 분이 안 계시면 물어볼 분이 없기 떄문에 기존 문서와 달랐진 점들과 내가 직접 겪었던 경험을 바탕으로 가이드라인을 꼭 문서화해야겠다 생각했다. 하지만 기존 문제점을 해결하기 위한 뚜렷한 아이디어가 떠오르지 않아 어떻게 하면 좋을지 고민하다가, 가이드라인을 작성하지 못했다.

서버점검을 위해서 내가 해야한 일은 한마디로 서버 점검을 우회하고 테스트 할 수 있는 빌드를 만들어서 전달드리는 것이다. 하지만 test 빌드인지 Prod 빌드인지에 따라 우회 키값이 달라지게 설정되어 있어 test 빌드에서는 Prod 서버를 우회하지 못하고, Prod 빌드는 점검 모달 확인 버튼 클릭시 앱을 종료를 시키기 때문에 test 빌드에 Prod 키값을 하드코딩된 별도의 버전을 전달드려야 하는 상황이었다.

별도의 빌드를 전달드리는 것은 큰일은 아니지만, 서버점검이 배포일자와 항상 유사하게 진행되다보니 QA엔지니어께서 기존 테스트를 하시고 계시던 작업들이 반영되어있는 버전에서 서버점검을 하시고 싶어하셨다.

모바일 엔지니어는 별도의 앱을 빌드하지 않아도 되고, QA엔지니어는 테스트중이던 앱 버전에서 확인할 수 있으니 모두의 효율을 높일 수 있을 것 같아 고민중에, 기존 우회 플래그를 켰을 때 설정도는 키값이 앱빌드가 test인지 Prod인지에 따라 달라지게 되어 있던 부분을, 타겟 서버에 따라 달라지게 하면 test 앱 빌드에서도 Prod 서버를 우회할 수 있을 것 같아 작업을 진행했다.

다행히 해당 작업을 통해 기존 QA 엔지니어께서 테스트 하시던 버전 그대로 테스트 점검과 본 점검 모두 성공적으로 우회할 수 있었고, 해당 작업을 통해 좀 더 간단해진 새벽점검 가이드라인도 작성할 수 있었다.

[컨플에 작성한 가이드 라인]

서버점검가이드

😆 모바일 엔지니어로 2023년을 보내며

12월의 마지막 날, 2023년을 돌아보니 2월에 입사해 많은 걸 배우려고, 어쩌면 내가 부족한 걸 드러내지 않으려고 애썼던 것 같다. "왜 나는 이걸 모르지"와 "이거 안해봤는데 어떡하지"의 연속이었던 날을 지나, 여전히 잘 모르는 게 많지만 이제는 질문을 어떻게 하면 좋을지, 어떻게 소통하면 좋을지를 알아가고 있는 것 같다.

내가 어떤 질문을 하더라도 "왜 저사람은 저런 질문을 하지"보다는 어떤 게 문제인지부터 같이 찾아주려하는 동료들이 있어서, 심리적 안정감을 갖고 모르니까 더 잘아시는 분께 도움을 요청하면서 배워가고 있다.

배울 게 많은 동료들과 일하면서, 왜 내가 "프로그래머, 열정을 말하다" 책에서 "가장 못하는 사람이 되라" (진짜 못하라는 게 아니라 나보다 뛰어난 사람들이 모인 집단에 가라는 뜻)라는 챕터가 가장 좋았는지 이해가 되었다.

아마 내년에도 모르는 게 많을 거고, 매일 새로운 문제를 풀어가겠지만 그럴수록 더 많은 것을 배우고 성장하는 과정이 될 거라 기대도 된다. 더 많이 채워서 나도 더 나눌 수 있는 한해가 되기를 바라면서 마쳐본다.

Typescript: Conditional Types

Tue, 19 Dec 2023 00:00:00 GMT

Conditional Types 🤩

타입스크립트에서 조건부 타입은 T extends U ? X : Y와 같은 형태로 사용된다. 이는 T가 U에 할당 가능한지에 따라서 X와 Y중 하나의 타입을 선택하게 된다.

이러한 모습은 기존 javascript의 삼항연산자와 유사하게 느껴진다. (condition ? trueExpression : falseExpression)

interface Animal {
  live(): void
}
interface Dog extends Animal {
  woof(): void
}

type Example1 = Dog extends Animal ? number : string // type Example1 = number

type Example2 = RegExp extends Animal ? number : string // type Example2 = string

Generic과 함께 사용하기

Generic과 함께 사용하면 더 유용하게 사용할 수 있다. 다음 예제를 보자.

// 예시 1
type MessageOf<T> = T extends { message: unknown } ? T["message"] : never

interface Email {
  message: string
}

interface Dog {
  bark(): void
}

type EmailMessageContents = MessageOf<Email> // string

type DogMessageContents = MessageOf<Dog> // never

// 예시 2
type Flatten<T> = T extends any[] ? T[number] : T

// Extracts out the element type.
type Str = Flatten<string[]> // type Str = string

// Leaves the type alone.
type Num = Flatten<number> // type Num = number

Infer와 함께 사용하기

infer는 타입스크립트에서 타입을 추론하는 키워드이다. infer를 사용하면 조건부 타입을 사용해 동적으로 타입을 추론할 때 유용하게 사용할 수 있다.

// 예시1
type Flatten<Type> = Type extends Array<infer Item> ? Item : Type

//예시2
type GetReturnType<Type> = Type extends (...args: never[]) => infer Return
  ? Return
  : never

type Num = GetReturnType<() => number> // number

type Str = GetReturnType<(x: string) => string> // string

type Bools = GetReturnType<(a: boolean, b: boolean) => boolean[]> // boolean[]

예시 2를 보면 함수의 반환타입을 동적으로 변경할 수 있게 infer를 이용해 추론한 예제다.

Distributive Conditional Types

Distributive Conditional Types는 조건부 타입이 사용될 때 전달되는 타입이 union으로 구성되어 있으면 각각의 타입에 조건부 타입을 적용한 후 union으로 다시 합쳐진다.

type ToArray<Type> = Type extends any ? Type[] : never

type StrArrOrNumArr = ToArray<string | number> // string[] | number[]

😃 2023년 11월 회고

Sat, 02 Dec 2023 00:00:00 GMT

11월은 스쿼드 일감과 함께 챕터업무를 진행한 한달이었다. 에러 예외처리 고도화 일감을 진행하면서 에러바운더리에 대해 공부하고 발표했고, 앞서 10월에 진행하면서 데이터 측정을 위해 구현했던 Firebase Performance util에 대해 소개하며 총 두번의 발표를 했다. 챕터 일감으로 새로운 에러 리포팅 툴인 로그로켓에 대해 검토하고 직접 미팅을 하기도 했다. 다양한 일감을 진행한 11월에 대해 대해 정리해보려한다.

비어있는 Catch문 막기 ✋

여러 도메인들의 코드들의 Catch문에 작성된 에러 핸들링 코드를 보면 다양한 고민의 흔적을 볼 수 있었다. 어떤 분은 TODO를 남겨두셨고, 어떤 분은 로그를 추가해주셨고, 어떤 분은 불필요해보여 따로 처리하시지 않은 부분도 있었다. 개인적으로 try-catch문을 사용하게 되면 에러가 전파되는 것을 막기 때문에, 해당 부분에서 반드시 핸들링 로직을 추가해주어야한다고 생각한다. 그렇기 때문에 비어있는 catch문이 작성되지 않게 제한할 필요가 있다고 생각이 들었고, 이러한 생각을 챕터에 공유드렸을 때 긍정적으로 받아드려주셔서 커스텀 Lint 룰을 만들어 적용하는 작업을 에러/예외 처리 작업으로 진행하게 되었다.

ESLint 이해해보기

ESLint는 프로젝트의 코드 스타일을 잘 통일해주는 좋은 도구라 생각만 했지, 직접 커스텀 룰을 만들어서 추가하게 될 줄 몰랐다. ESLint에 직접 커스텀 Lint 룰을 추가하기 위해서는 몇가지 개념을 이해할 필요가 있었다.

meta

meta는 말그대로 rule에 대한 metadata를 담는 부분이다.
- type은 problem, suggestion, layout으로 구분되어 실제로 문제가 될 수 있는지를 나타낼 수 있다.
- docs에는 해당 에러가 발생했을 때 어떻게 안내할 지를 담는 부분으로 추가된 룰에 대한 설명을 담을 수 있다.
- fixable은 --fix 옵션을 이용해서 고칠 수 있게 할지를 설정할 수 있다,
create

create는 실제로 우리가 작성된 코드에서 어떤 것을 report할 지를 정의하는 부분으로 인자로 context를 받을 수 있는데 context는 어떤 상황에 report할지 등을 담은 여러 메소드와 속성이 담긴 객체다.

[ESLint Custom Rule ]

meta 같은 경우는 아주 간단하게 어떻게 할지를 정의하면 되니까 쉽게 작성이 가능했지만, 내가 원하는 요구사항인 catch문에 대해 감지해서 비어있을 때 규칙을 어겼다고 보고하기 위해서는 ESLint가 우리 소스코드를 읽는 방법에 대해 이해가 필요했다.

AST (Abstract Syntax Tree)

AST는 ESLint에서 소스코드를 읽은 후 만드는 트리형태의 자료구조를 의미하는데, 자료들을 찾아보면서 토스에서 작성한 ESLint와 AST로 코드 퀄리티 높이기 글을 통해 도움을 받을 수 있었다.

console.log()를 https://astexplorer.net/의 acorn 파서를 이용해서 파싱했을 때 얻을 수 있는 AST를 보면 다음과 같다.

[console.log의 AST]

{
  "type": "Program",
  "start": 0,
  "end": 13,
  "body": [
    {
      "type": "ExpressionStatement",
      "start": 0,
      "end": 13,
      "expression": {
        "type": "CallExpression",
        "start": 0,
        "end": 13,
        "callee": {
          "type": "MemberExpression",
          "start": 0,
          "end": 11,
          "object": {
            "type": "Identifier",
            "start": 0,
            "end": 7,
            "name": "console"
          },
          "property": {
            "type": "Identifier",
            "start": 8,
            "end": 11,
            "name": "log"
          },
          "computed": false,
          "optional": false
        },
        "arguments": [],
        "optional": false
      }
    }
  ],
  "sourceType": "module"
}

변환된 구조를 보면 어떤 이름의 객체인지, 어떤 속성을 가지고 있는지 등이 트리구조로 변환된 것을 볼 수 있다.

그러면 이번에는 try-catch문을 AST로 변환되었을 때 어떻게 나타나게 되는지 알아보자.

[try-catch문의 AST]

{
  "type": "Program",
  "start": 0,
  "end": 12,
  "body": [
    {
      "type": "TryStatement",
      "start": 0,
      "end": 12,
      "block": {
        "type": "BlockStatement",
        "start": 3,
        "end": 5,
        "body": []
      },
      "handler": {
        "type": "CatchClause",
        "start": 5,
        "end": 12,
        "param": null,
        "body": {
          "type": "BlockStatement",
          "start": 10,
          "end": 12,
          "body": []
        }
      },
      "finalizer": null
    }
  ],
  "sourceType": "module"
}

여기서 내가 주요하게 봤던 부분은 scope 타입이 AST에서 특정되어 구분된다는 점이었다. 실제로 공식문서를 보았을 때 catch문은 CatchClause로 구분되어 적용할 수 있다.

scope

내가 만들려고 했던 부분중 첫번째 catch문을 만났을 때를 다음과 같이 구현이 가능했다.

[Catch문 감지를 위한 eslint rule]

module.exports = {
  meta: {
    /*...*/
  },
  create(context) {
    return {
      CatchClause(node) {
        // 이제 비어있는 것만 감지하자
      },
    }
  },
}

두번째로 비어있다는 것을 확인할 필요가 있었는데 이것은 catch문의 block 내부를 보면 되는데 앞선 예제에서 CatchClause의 body안의 body 속성 내부가 빈 배열로 작성되어있는 것을 볼 수 있다.

[비어있는 catch문에 대한 AST]

{
  "body": [
    {
      "handler": {
        "type": "CatchClause",
        "body": {
          "type": "BlockStatement",
          "body": []
        }
      }
    }
  ]
}

앞서 정리한 두가지 정보를 통해 다음과 같이 rule을 완성할 수 있다.

[완성된 Custom Rule]

module.exports = {
  "no-empty-catch-blocks": {
    meta: {
      /*...*/
    },
    create(context) {
      return {
        CatchClause(node) {
          if (node?.body.body.length === 0) {
            context.report({
              node: node.body,
              message: "비어있는 catch문 대신 에러 로그를 남겨주세요",
            })
          }
        },
      }
    },
  },
}

마지막으로 만들어진 rule을 .eslintrc.js에서 어떤 심각도로 설정할 지를 정함으로써 우리 프로젝트에 적용할 수 있었다. 간단한 lint 룰을 설정하는 작업이었지만 우리 프로젝트 전반에 추가되는 개발 환경에 새로운 규칙을 추가해 에러 핸들링에 대해 조금 더 관심도를 높이고 신경쓸 수 있게 기여하는 작업이었다.

우리 ErrorBoundary 써봐요 😃

에러 핸들링에 대해 관심을 가지고 챕터 업무로 진행하면서 자연스럽게 선언적으로 에러를 핸들링할 수 있는 에러 바운더리를 알 게 되었다. 어떻게 동작하는지 이해하기 위해 많은 발표 자료도 보고 직접 예제들을 만들어 사용하면서 어느정도를 이해를 높일 수 있었고, 우리 프로젝트에 적용하면 좋겠다는 생각이 들었다. 하지만 현재 우리 프로젝트에는 한 곳 정도에서 쓰이고 있었기 때문에 챕터원분들에게 어떤 점이 좋고, 어떻게 적용할 수 있는지, 한계점은 어떤 것인지 알려드리는 게 먼저 필요해 보였다. 기술논의 시간에 내가 직접 겪었던 에러 상황등을 담아 에러바운더리에 대해 발표를 진행했다.

에러 바운더리 코드 이해해보기

에러바운더리는 react 16에 도입된 개념으로 UI 렌더링 과정에서 발생한 자식 컴포넌트 트리의 에러를 발생했을 때, 상위로 에러를 던지지지 않고 fallback UI를 보여주는 컴포넌트다. 에러 상태를 담당해주는 Context로 이해할 수 있다.

[에러 바운더리를 시각화한 그림 (참조. Logrocket 에러바운더리 글)]

에러바운더리

이제 코드를 보며 알아보자. 에러바운더리는 클래스 컴포넌트로 코드를 통해 4가지 정보를 얻을 수 있다.

[에러 바운더리 컴포넌트]

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props)
    this.state = { hasError: false }
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true }
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    console.log(error, errorInfo)
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return <h1>Something went wrong.</h1>
    }

    return this.props.children
  }
}

// Usage in a component
class App extends React.Component {
  render() {
    return (
      <ErrorBoundary>
        <MyComponent />
      </ErrorBoundary>
    )
  }
}

this.state: 에러상태를 가지는 컴포넌트구나
getDerivedStateFromError: 렌더링 에러가 발생했을 때, hasError를 fallback UI가 보이도록 업데이트하구나
componentDidCatch: 에러가 발생했을 때, 버그 리포팅하는 등 수행할 callback을 등록할 수 있구나
render: 에러발생시 정의한 fallback UI가 노출되구나

사용할 때는 우리가 원하는 컴포넌트를 감싸서 에러가 발생했을 때 상위 컴포넌트로 전달되는 것을 받아주게 context를 설정해주면 된다.

발표자료를 준비하면서 우리 프로젝트에서도 일부 적용되어 있는 것을 볼 수 있었는데, App.tsx의 최상단에서 에러 발생시 화이트스크린 에러를 로깅을 할 수 있게 componentDidCatch가 작성되어 있는 것을 확인할 수 있었다.

에러바운더리의 장점과 한계

그러면 에러바운더리가 가지는 장점은 무엇일까? 내가 정리한 장점은 다음과 같았다.

하나의 컴포넌트 렌더링 에러가 화이트스크린으로 이어지지 않게 막아준다 = 사용자 경험의 향상 (UX👆)
반복적으로 사용되던 에러상태를 위임해 에러를 선언적으로 핸들링 할 수 있다 = 개발자 경험의 향상 (DX👆)

하지만 에러바운더리가 모든 에러를 처리해줄 수는 없는데 리액트 공식문서를 참조하면 다음과 같은 에러들은 감지할 수 없다.

[리액트 공식문서에서 작성된 에러바운더리의 한계점]

그렇기 때문에 렌더링 자체의 문제가 없는 에러들은 에러바운더리로 위임시킬 수 없다. 그러면 에러바운더리가 우리 프로젝트에서 필요한 걸까?

내가 만들었던 에러

우리가 코드를 작성하면서 런타임에러나 렌더링 에러가 얼마나 자주 발생하겠어?라는 생각이 들 수 있지만, 스쿼드에서 일감을 진행하면서 직접 만들었던 예제를 작성해보았다.

상황은 총 페이지가 4개였던 스크린을 3개로 줄이는 실험을 진행했다. 이때 기존 스크린에는 AsyncStorage를 통해 작성한 데이터들을 저장하는데 이때 pageIndex에 따라 데이터를 불러온다. 문제가 되는 시나리오는 새롭게 퍼널을 줄인 스크린에서는 이후 페이지의 마지막 페이지를 최대값이라 생각해 최대를 넘으면 에러가 발생하게 코드로 작성해둔 상태였다.

const 실험전_마지막페이지 = 4
const 실험후_마지막페이지 = 3

let AsyncStorage의_마지막페이지 = 실험전_마지막페이지 // 예시로 AsyncStorage를 let으로 작성했다.

const getDataFrom = (index: number) => {
  switch (index) {
    case 1:
      return { title: "페이지1", content: "페이지1의 내용" }
    case 2:
      return { title: "페이지2", content: "페이지2의 내용" }
    case 3:
      return { title: "페이지3", content: "페이지3의 내용" }
    default:
      throw new Error("없는 페이지입니다.") // 실험 후 마지막 페이지는 3이니까 3보다 큰값은 안 들어올거야
  }
}

function ScreenThrowingError() {
  const [index, setIndex] = React.useState(1)
  const pageData = getDataFrom(index)

  const handlePress = () => {
    if (실험후_마지막페이지 === index) {
      return
    }
    setIndex(index + 1)
  }

  useEffect(() => {
    const AsyncStorage의_데이터불러오기 = true
    if (AsyncStorage의_데이터불러오기) {
      setIndex(AsyncStorage의_마지막페이지)
    }
  }, [])

  return (
    <View style={{ flex: 1, justifyContent: "center", alignItems: "center" }}>
      <View>
        <PagerView data={pageData} />
      </View>
      <TouchableOpacity
        style={{ position: "absolute", bottom: 12 }}
        onPress={handlePress}
      >
        <Text style={{ fontSize: 32, color: "teal" }}>{`다음페이지`}</Text>
      </TouchableOpacity>
    </View>
  )
}

위와 같은 상황의 코드를 시뮬레이터에서 동작시켜보면 다음과 같이 화이트 스크린이 발생하게 된다.

기존 화이트 스크린이 발생하는 상황에서 앞서 작성한 에러바운더리를 적용해 다음과 같이 코드를 작성했다.

export class ErrorBoundary extends React.Component<{ hasError: boolean }> {
  constructor(props: { children: ReactNode }) {
    super(props)
    this.state = { hasError: false }
  }

  static getDerivedStateFromError() {
    return { hasError: true }
  }

  componentDidCatch(error: Error) {
    // bugsnag.notify(error);
    console.log(error)
  }

  render() {
    if (this.state.hasError) {
      return (
        <View
          style={{ justifyContent: "center", alignItems: "center", rowGap: 12 }}
        >
          <Text style={{ fontSize: 32 }}>에러 발생 ☠️</Text>
          <TouchableOpacity
            style={{
              borderColor: "red",
              borderWidth: 1,
              padding: 10,
              borderRadius: 10,
            }}
            onPress={() => {
              AsyncStorage의_마지막페이지 = 실험후_마지막페이지
              this.setState({ hasError: false })
            }}
          >
            <Text style={{ fontSize: 30, color: "red" }}>재시도 하기</Text>
          </TouchableOpacity>
        </View>
      )
    }

    return this.props.children
  }
}

function App() {
  return (
    <SafeAreaView
      style={{
        justifyContent: "center",
        alignItems: "center",
        flex: 1,
        rowGap: 12,
      }}
    >
      <ErrorBoundary>
        <ScreenThrowingError />
      </ErrorBoundary>
    </SafeAreaView>
  )
}

결과는 다음과 같이 동일하게 런타임 에러가 발생하지만 화이트 스크린은 발생하지 않고, 이전 페이지로 돌아가는 것을 볼 수 있다.

위 예제는 에러 상황 자체를 해결해 줄 수는 없지만, 앱을 종료하고 다시 진입해야하는 유저의 불편함을 크게 해줄 수 있는 에러바운더리의 장점을 잘 보여준다.

그러면 우리가 자주 사용하는 이벤트와 비동기에서 사용할 수 없을까 🤔

에러바운더리의 장점을 알고 적용하려고 보니 렌더링 에러만 감지할 수 있는 한계점이 있었다. 우리가 자주 사용하는 비동기와 이벤트 핸들러에서 발생한 에러에서도 적용하는 방법은 없을까라는 생각이 든다.React-Error-Boundary는 이러한 한계를 극복하기 위한 라이브러리로 다음과 같은 사용방법이 있다.

Fallback

에러바운더리로 에러가 전달되었을 때 어떤 컴포넌트를 보여줄지 직접 전달하는 방식이다.

function App() {
  return (
    <ErrorBoundary
      fallback={<Text style={{ fontSize: 32 }}>에러 발생 ☠️</Text>}
    >
      <MyComponentThatMayError />
    </ErrorBoundary>
  )
}

fallbackRender

fallback과 달리 컴포넌트 함수를 전달하는데, 이때 prop으로 error와 resetErrorboundary를 전달받아 어떤 에러인지에 대한 정보와 에러바운더리를 벗어날 수 있게 연결할 수 있다.

function FallBackComponent({ resetErrorBoundary }: Props) {
  return (
    <View style={{ rowGap: 12 }}>
      <Text style={{ fontSize: 32 }}>에러 발생 ☠️</Text>
      <TouchableOpacity
        style={{
          borderColor: "red",
          borderWidth: 1,
          padding: 10,
          borderRadius: 10,
        }}
        onPress={() => resetErrorBoundary()}
      >
        <Text style={{ fontSize: 32, color: "red", textAlign: "center" }}>
          재시도
        </Text>
      </TouchableOpacity>
    </View>
  )
}

function App() {
  return (
    <ErrorBoundary fallbackRender={FallBackComponent}>
      <MyComponentThatMayError />
    </ErrorBoundary>
  )
}

onReset, onError, resetKeys

onReset은 에러가 reset됐을 때 수행할 callback을, onError는 에러가 발생했을 때 수행할 callback을, resetKeys는 전달된 dependency가 달라졌을 때 fallback UI가 제거되게 할 수 있는 props이다.

<ErrorBoundary
  fallbackRender={FallbackComponent}
  onError={error => {
    // 에러 리포트
    console.log(error)
  }}
  onReset={() => {
    // state 초기화
  }}
  resetKeys={["API로 받아올 상태"]}
>
  <MyComponentThatMayError />
</ErrorBoundary>

useErrorBoundary

useErrorBoundary는 비동기, 이벤트 핸들러 함수에서 에러 발생했을 때 에러바운더리를 보여줄지, 또는 에러바운더리를 벗어나게할지를 조절할 수 있게 하는 훅으로, 앞선 errorboundary가 가지는 한계점을 해결할 수 있게 도와주는 함수다.

function MyComponentThatMayError() {
  const { resetBoundary, showBoundary } = useErrorBoundary()

  return (
    <View style={{ rowGap: 12, flex: 1, alignItems: "center" }}>
      <TouchableOpacity
        style={{
          borderColor: "teal",
          borderWidth: 1,
          padding: 10,
          borderRadius: 10,
        }}
        onPress={resetBoundary}
      >
        <Text style={{ fontSize: 30, color: "teal" }}>리스트 불러오기</Text>
      </TouchableOpacity>
      <TouchableOpacity
        style={{
          borderColor: "red",
          borderWidth: 1,
          padding: 10,
          borderRadius: 10,
        }}
        onPress={() => {
          showBoundary(true)
        }}
      >
        <Text style={{ fontSize: 30, color: "red" }}>에러발생버튼</Text>
      </TouchableOpacity>
    </View>
  )
}

비동기핸들링 예제 리팩토링해보기

소개한 여러가지 사용법을 이용해 간단한 비동기 코드를 리팩토링해보자. 우리 프로젝트의 많은 스크린에서 사용하고 있는 형식으로 에러 상태를 다루고, 에러 상태에 따라 보여줄 화면을 직접 정의해서 보여주고 있다. 로딩 상황, 에러상황에 따라 보여줄 화면에 대한 정의 함께 섞여있어 스크린 코드가 길게 작성되어 있다.

[에러 바운더리 적용 전 예제 코드]

function MyComponentThatMayError() {
  const [isLoading, setIsLoading] = React.useState(false)
  const [data, setData] = React.useState({ title: "", content: "" })
  const [error, setError] = React.useState(false)

  const fetchTask = useCallback(async () => {
    try {
      setIsLoading(true)
      const result = await new Promise<{ title: string; content: string }>(
        (resolve, reject) => {
          if (canGetResponse) {
            resolve({ title: "페이지1", content: "페이지1의 내용" })
          } else {
            reject(new Error("에러 발생"))
          }
        }
      )
      setData(result)
    } catch (e) {
      canGetResponse = true
      setError(true)
    } finally {
      setIsLoading(false)
    }
  }, [])

  useEffect(() => {
    fetchTask()
  }, [fetchTask])

  if (isLoading) {
    return <ActivityIndicator size={"large"} />
  }

  if (error) {
    // 에러상황 때 보여줄 화면을 분기문으로 정의
    return (
      <View style={{ rowGap: 12 }}>
        <Text style={{ fontSize: 32 }}>에러 발생 ☠️</Text>
        <TouchableOpacity
          style={{
            borderColor: "red",
            borderWidth: 1,
            padding: 10,
            borderRadius: 10,
          }}
          onPress={() => fetchTask()}
        >
          <Text style={{ fontSize: 32, color: "red", textAlign: "center" }}>
            재시도
          </Text>
        </TouchableOpacity>
      </View>
    )
  }

  return (
    <SafeAreaView
      style={{
        justifyContent: "center",
        alignItems: "center",
        flex: 1,
        rowGap: 12,
      }}
    >
      <Text style={{ fontSize: 32 }}>{data.title}</Text>
      <Text style={{ fontSize: 32 }}>{data.content}</Text>
    </SafeAreaView>
  )
}

위 코드를 이제 React-Error-Boundary를 이용해서 에러상태와 fallback UI를 에러바운더리에 위임해보자 😆

[에러 바운더리 적용 후 예제 코드]

type Props = {
  error: Error
  resetErrorBoundary: () => void
}

let canGetResponse = false

function MyComponentThatMayError() {
  const [isLoading, setIsLoading] = React.useState(false)
  const [data, setData] = React.useState({ title: "", content: "" })
  const { showBoundary } = useErrorBoundary()

  const fetchTask = useCallback(async () => {
    try {
      setIsLoading(true)
      const result = await new Promise<{ title: string; content: string }>(
        (resolve, reject) => {
          if (canGetResponse) {
            resolve({ title: "페이지1", content: "페이지1의 내용" })
          } else {
            reject(new Error("에러 발생"))
          }
        }
      )
      setData(result)
    } catch (e) {
      canGetResponse = true
      showBoundary(e)
    } finally {
      setIsLoading(false)
    }
  }, [showBoundary])

  useEffect(() => {
    fetchTask()
  }, [fetchTask])

  if (isLoading) {
    return <ActivityIndicator size={"large"} />
  }

  return (
    <SafeAreaView
      style={{
        justifyContent: "center",
        alignItems: "center",
        flex: 1,
        rowGap: 12,
      }}
    >
      <Text style={{ fontSize: 32 }}>{data.title}</Text>
      <Text style={{ fontSize: 32 }}>{data.content}</Text>
    </SafeAreaView>
  )
}

function FallBackComponent({ resetErrorBoundary }: Props) {
  return (
    <View style={{ rowGap: 12 }}>
      <Text style={{ fontSize: 32 }}>에러 발생 ☠️</Text>
      <TouchableOpacity
        style={{
          borderColor: "red",
          borderWidth: 1,
          padding: 10,
          borderRadius: 10,
        }}
        onPress={() => resetErrorBoundary()}
      >
        <Text style={{ fontSize: 32, color: "red", textAlign: "center" }}>
          재시도
        </Text>
      </TouchableOpacity>
    </View>
  )
}

function App() {
  return (
    <ErrorBoundary fallbackRender={FallBackComponent}>
      <MyComponentThatMayError />
    </ErrorBoundary>
  )
}

개선전 코드에 비해 에러바운더리로 에러상태와 fallback UI를 위임하고 나서, 컴포넌트 내부에 불필요한 분기문이 줄어들었고 성공과 로딩중일때만 작성되어 있어 보다 한번에 읽기 쉬워진 것을 볼 수 있다.

발표를 마치고

발표를 준비하면서 우리 앱의 수많은 스크린에 적용할 만하다, 비용(시간) 대비 큰 효과를 얻을 수 있는 작업인지에 대해서 긍정적으로 생각해주실까 고민이 들었다. 그래도 한달정도 관련 여러 자료들을 보고 내 나름 정리하고 발표하는 것만 해도 나에게는 큰 수확이다라고 생각했는데, 다행히 챕터원 분들이 모두 긍정적으로 생각해주셔서 라이브러리를 이용해 조금씩 도입하는 작업을 진행해보기로 정해졌다😊

그외의 작업들

기술적으로 정리할만큼의 큰 작업은 아니지만 11월달에 했던 그외 작업들도 정리해보았다.

버그스낵 custom Grouping 도입

기존 사용하고 있던 버그스낵을 좀더 잘 사용하기 위해서, 같은 에러지만 발생한 stackTrace에 따라 나뉘어서 찍히고 있던 문제를 해결하기 위해 Custom Grouping을 Group Hash를 도입해 해결했다.

로그로켓 도입 검토

기존 사용하던 버그스낵은 에러 발생상황을 알기 위해서는 하나하나 흐름을 직접 따라가고 확인해봐야, 디버깅 할 수 있기 때문에, 에러 발생 전후의 영상이 있으면 좋을 것 같다는 아쉬움이 있었다. 이러한 영상을 제공하는 툴로써 로그로켓을 검토하게 되었다. 로그로켓 공식문서를 봐도 잘 이해가 안되는 부분들 (소스맵, conditional recording)과 같은 부분들을 해결하기 위해서 직접 로그로켓측과 미팅을 가지고 물어보기도 했다. 결과적으로는 비용문제와 우리 챕터에서 세웠던 조건들을 만족하지 못해 도입은 보류되었다.

직접 영어로 미팅을 하다보니 내가 조금 더 다양하게 물어보지 못했고, 좀 더 잘 알아보지 못해서 우리팀의 좋은 툴을 놓치는 것은 아닌가 하는 생각이 들어 맘 한편이 아쉽기도 했다.

Firebase Performance에 대한 발표

이전 10월에 작업하면서 유틸을 추가했지만 어떻게 사용하면 좋을지 공유를 하지는 않았었다. 이후 챕터내의 성능 개선 작업을 위한 데이터를 쌓을 수 있게 유틸의 개발 과정과 코드들을 공유면서 코드별로 어떤 문제를 해결하기 위해서 작성되었는지 이후에 또 어떻게 개선하면 좋을지 등을 담아 발표를 진행했다.

12월 테크팀 세미나 발표 참여

12월에 테크팀 자체적인 세미나를 진행하게 되면서, 2023년 동안 어떤 일들을 진행했는지 정리하는 발표를 하면 좋겠다는 생각해 자원하여 참여하게 되었다. 챕터내 발표가 아닌 많은 분들 앞에서 처음으로 발표하는 자리라 잘 준비해서 12월에 잘 발표하고 후기도 남기려 한다.

11월을 돌아보니 생각보다 많은 일들을 동시에 진행했던 것 같다. 시간을 더 효율적으로 사용하는 법, 여러가지 일을 동시에 진행할 때 얼마나 시간을 각각 쓸지 고민하고 관리하면서, 일을 잘하는 방법에 대해서도 관심이 생겼다. 자연스럽게 애자일에 대한 관심도 조금씩 생겨 나중에 정리해보려한다. 더 다양한 관심사와 일감들과 함께 즐겁게 일하는 12월이 되기를 바라며 마쳐본다.

Typescript: Keyof, TypeOf, Indexed

Thu, 16 Nov 2023 00:00:00 GMT

Keyof

KeyOf는 객체 타입의 키값, 속성에 대한 타입으로 string 또는 numeric literal의 union으로 나타내진다.

type Point = { x: number; y: number }
type P = keyof Point // "x"|'y'

이때 string또는 number 인덱스 signature를 가지고 있다면 keyof는 해당 타입을 반환한다.

type Arrayish = { [n: number]: unknown }
type A = keyof Arrayish // number

type Mapish = { [k: string]: boolean }
type M = keyof Mapish // string

TypeOf

typeof 연산자는 자바스크립트 자체가 이미 가지고 있다. 표현식에서 사용가능하고 변수의 타입을 추론할 때 쓰일 수 있다.

console.log(typeof "Hello world") // string
let s = "hello"
let n: typeof s // string

typeof는 보다 복잡한 상황에서 자주사용되는데 값으로 사용되는지, 타입으로 사용되는지를 타입스크립트가 이해할 수 있게 전달해줄 때 사용된다.

type Predicate = (x: unknown) => boolean
type K = ReturnType<Predicate> // boolean

function f() {
  return { x: 10, y: 3 }
}
type P = ReturnType<typeof f>

그렇다고 항상 사용할 수 있는 것은 아니라 값으로 사용되는 변수나 속성에서만 쓰일 수 있어.

typeof

Indexed Access Type

객체의 key값에 접근하듯이 type 또한 key 명을 이용해 타입을 추론할 수 있다.

type Person = { age: number; name: string; alive: boolean }
type Age = Person["age"]

type I1 = Person["age" | "name"] // type I1 = string | number

type I2 = Person[keyof Person] // type I2 = string | number | boolean

type AliveOrName = "alive" | "name"
type I3 = Person[AliveOrName] // type I3 = string | boolean

배열은 특별하게 number를 전달하게 되면 아이템이 어떤 타입을 가지는 지 타입을 추론할 수 있다.

const MyArray = [
  { name: "Alice", age: 15 },
  { name: "Bob", age: 23 },
  { name: "Eve", age: 38 },
]

type Person = (typeof MyArray)[number]

type Person = {
  name: string
  age: number
}
type Age = (typeof MyArray)[number]["age"]

// Or
type Age2 = Person["age"]