whale_dream.log

[WIL] 항해 플러스 프론트엔드 6기 1,2,3주차 회고

Mon, 28 Jul 2025 04:06:54 GMT

항해 플러스 프론트엔드 6기 코스를 시작한지 어느새 3주가 지나 첫번째 챕터 JS & React 딥다이브 챕터가 마무리되었습니다. 3주간을 되돌아보면 제 일상의 대부분이 항해 플러스였습니다. 매주 난도 높은 과제를 수행하는 것이 저에겐 쉽진 않았지만 그만큼 많은 것을 얻고 느끼고 배운 3주였습니다. 사실 매주 회고를 작성하려고 했지만… 헤헤 실패! 그래도 첫번째 챕터가 끝난 기념으로 첫번째 회고를 작성해보겠습니다.

항해 플러스 신청 계기

내가 항해 플러스를 신청한데에는 사실 아주 많은 이유가 있다. 아마 한 20가지 정도는 작성할 수 있을것 같은데ㅋㅋㅋ

몇가지만 적어보자면…

작년 한해동안 회사에서 잘하는 동료분에게 많은 도움을 받으면서 나도 실력을 향상시켜서 동료분들에게, 회사에 그렇게 도움이 되는 사람이 되고 싶었고
한번 더 크게 성장할 원동력이 필요했고
3년차가 되면서 회사 업무와 코드에 익숙해졌는데, 다른 회사의 개발자분들은 어떻게 개발을 하고 있는지 궁금해서 회사 밖의 많은 프론트엔드 개발자분들을 만나고 싶었고
기본기를 다져서 내 실력에 스스로 자신감을 얻고 싶었다.

그 밖의 수십가지 이유로 항해플러스에 오게 됐는데,, 3주차가 지난 지금 항해 플러스 하길 정말 잘했다는 생각이 든다. 이미 이 중 상당 부분을 달성하고 있기 때문이다!

KPT 회고

🐳 Keep

현실과 타협을 잘 했다!

3주를 지나고 보니 가장 잘했다고 생각하는 점이다.

처음에는 과제와 관련된 모든 개념들을 완벽하게 이해하고 차근차근 모든걸 다 이해하면서 AI 도움을 거의 받지 않고 과제를 수행하고 싶었는데….. 내 실력에는 불가능한 일이었다는걸 1주차에 바로 깨달았다.

어떻게 해서라도, 내 코드가 내 마음에 전혀 들지 않더라도 과제를 일단 통과하기 vs 최대한 스스로 학습하고 완벽하게 구현하되 과제의 통과 유무는 신경쓰지 말기

이 두가지 중에서 많은 고민을 하다 결국 그래도 과제 기간은 어떻게든 맞추고 이후에 시간을 내서 다시 한번 과제를 수행하자는 마음으로 첫번째를 택했고, 결과적으로 돌아보니 이렇게라도 과제 전체를 한 것이 항해 플러스의 진도를 따라가며 코치님께서 전달하고자 하셨던 내용들을 흡수하는데 더 도움이 되었던 것 같다.

한주 한주 지날수록 나아졌다!

1주차는 좌절과 절망의 연속이었다. 그냥 매일매일이 형편없는 나 견디기 챌린지..🥹 2주차는 그래도 1주차보단 SPA에 대한 이해나, AI 사용 등등 모든 면에서 더 나은 과제 수행을 했다. 3주차는 각각의 개념을 확실하게 이해하고자 노력했고, 나름 만족스럽게 과제 수행을 했다.

사실 이게 난이도 차이도 있겠지만, 1주차의 고생들이 2,3,주차를 과제를 조금 더 수월하게 수행할 수 있게 만들었다고 생각한다. 아직도 난 많이 부족하지만 어제보다 나아지고 있음을 생각하며 더 열심히 해야겠다.

🦐 Problem

부족했던 부분들을 못 메꿨다!

일단 시간내에 과제를 수행하고 과제를 복습하면서 부족한 부분을 메꾸자 ← 이게 내 다짐이었는데.. 그냥 과제를 시간내에 수행하기만 한 사람이 된 것 같기도 하다. 과제 끝나면 찾아보기로 한 궁금한 점들이 많았는데 그중 한 절반정도만 찾아보고 나머지는 귀찮음에 날려버렸다.다음주부턴 귀찮음을 이기고 꼭 궁금했던 부분 다 해결하기 도전..

다양한 의견 교류를 하지 못했다!

늘 과제 진도가 다른분들에 비해 한박자 느려서.. 아는 게 많지 않아 말할만한 의견이 별로 없었다.. 그래도 클린코드 주에는 평소에 생각했던 내가 선호하는 코드 작성 방향들이 있으니 이야기 할 만한 부분이 있을 것 같다..! (말할 용기만 생긴다면…)

🔥 Try

조금 더 적극적으로 코드리뷰 참여하기!

예전에 한번 코드리뷰를 받은적은 있지만, 코드리뷰를 내가 한 건 항해가 처음이었다. 나는 아는게 없는데 내가 코드리뷰를…? 이라는 마음에 처음엔 조금 어색하고 두려웠는데, 팀원분들과 가벼운 내용부터 코드리뷰를 해 보니 생각보다 어려운 일이 아니었다..! 그리고 무엇보다 다른 분들의 코드나 다른분들께서 해주신 코드리뷰를 보고 “아 나도 이런식으로 해봐야겠다~ 이런걸 신경써야 겠다~” 를 느낄 수 있어서 좋았다. 4주차 부터는 조금 더 적극적으로 의견 공유를 하고 코드 리뷰에 참여해야겠다.

깊게 공부하기!

1,2,3 주차를 하면서 느낀건 여태껏 내가 정말 겉핥기식 공부만 하고 있었다는 것이다. 3주간 프레임워크 없이 SPA 만들기를 진행하면서 SPA 프레임워크의 동작 원리를 어느정도 알고있다고 생각했는데 알고있기는 커녕 나는 여태껏 궁금해 한 적 조차 없었다는 사실을 깨달았다. SPA 프레임워크, 가상돔, 리액트 훅들과 전역 상태 관리를 직접 구현해보니, 과거의 내가 위의 개념들이 무엇인지 이해하기 위해 했던 공부와 이런 것들을 직접 구현하기 위해 무엇이 필요한지 고민했던 3주간의 공부의 깊이가 얼마나 차이나는지 느낄 수 있었다.

어떻게 해야 깊게 공부할 수 있는지 조금은 느낄 수 있었고, 나도 앞으로 이렇게 깊게 파고드는 공부를 하기 위해 노력해야 겠다는 다짐을 했다.

회고를 마치며

체력적으로나 정신적으로 꽤 힘들긴 했지만, 많은 걸 배우고 느낀 후회 없는 3주였습니다. 어느정도냐면.. 이제 겨우 3주 끝냈으면서 벌써부터 항해 끝나면 일상이 정말 허전하겠다…라는 생각이 종종 든답니다.. 3주간 SPA부터 가상돔, 리액트 훅들과 전역상태관리를 직접 구현해보니 각각 어떤 문제를 해결하고자 했는지를 확실히 이해할 수 있었습니다.

그리고 이를 바탕으로 실무에서 특정 이슈에 대해 다른 분이 제시한 해결 방안이 SPA가 추구하는 방향과 맞지 않다는 주장도 할 수 있게 되었다는 점이 개인적으로는 꽤 뿌듯합니다.(나도 이제 자신있게 주장할 수 있다아아아~!!!!)

이렇게 성장할 수 있게 도와주신 준일 코치님께 진심으로 감사드립니다.

그리고 무엇보다 회고에서 가장 하고싶었던 말은…

이렇게 3주를 버틸 수 있었던 건 우리 4팀분들 덕분입니다아🫶 최고의 학메님과 최고의 팀장님과 최고의 팀원들 뿐인 4팀에 속해서 행복합니다🐳 북끄러워서 표현은 잘 못하지만 4팀 모두들 내가 진짜 많이 조아해에에~~!!

그리고 앞으로 함께할 7팀분들도 잘 부탁드립니다!

useTitle 적용 가이드

Wed, 25 Jun 2025 04:38:09 GMT

개요

요약

각 목록 페이지의 title과 description을 백엔드 api를 통해 받은 메뉴 데이터 값으로 출력하도록 하는 useTitle 컴포저블을 작성하여 host 모듈에서 expose 해두었습니다.

기존 문제점

*** 에서는 메뉴 관리를 통해 메뉴명을 바꿀 수 있으며, 매 버전마다 메뉴명이 조금씩 달라집니다. 기존에는 각 목록 페이지의 title과 description 출력에 프론트의 정적인 값을 사용했기 때문에, 메뉴 관리로 LNB의 메뉴명을 변경했을 때 프론트엔드 소스를 수정하여 재배포하지 않으면 목록의 title과 LNB 메뉴명이 일치하지 않는 이슈가 있었습니다. 이를 프론트 소스 변경 없이 해결하기 위해 [메뉴 관리]에서 설정한 메뉴 데이터의 title과 description을 반환하는 훅을 작성했습니다.

구현 방식

저희 솔루션에서는 route의 path가 달라질 때마다 현재 path(url)가 속한 LNB를 백엔드에서 받은 메뉴 데이터에서 찾고, 찾은 정보를 host의 useMenuStore에 저장해둡니다. useTitle 훅에서는 이 정보들 중 title(현재 path가 속한 LNB 이름)과 description을 반환합니다.

useTitle.ts

// 목록 페이지 title, description을 newMenuStore의 현재 선택된 메뉴 데이터에서 가져오는 훅
import { computed } from 'vue';
import { useMenuStore } from '@/stores/menu/useMenuStore';
export const useTitle = () => {
  const store = useMenuStore();
  const pageTitle = computed(() => store.currentMenuInfo?.lnbMenuName ?? '');
  const pageDescription = computed(
    () => store.currentMenuInfo?.description ?? ''
  );
  return {
    pageTitle,
    pageDescription,
  };
};

적용 가이드

remote 레포지토리 shims-vue.d.ts 파일에 host useTitle 컴포저블 타입 정의를 추가합니다.

// shims-vue.d.ts파일
declare module 'host*****/hooks/useTitle' {
import { Ref } from 'vue';
export const useTitle: () => {
 pageTitle: Ref;
 pageDescription: Ref;
};
}

Title 및 description 적용이 필요한 곳에서 useTitle 컴포저블을 import 하여 사용합니다.


# remote 모듈 적용 예시
remote에서는 목록 페이지에 공통으로 ListLayout 컴포넌트를 적용하고 있습니다.


ListLayout 에서는 기본적으로 useTitle의 pageTitle과 pageDescription을 출력합니다.

## Edge case
1. LNB 데이터에 존재하지 않는 목록 페이지 (ex. 마이페이지)

마이페이지처럼 LNB 데이터에 존재하지 않는 목록 페이지는 menuStore에 현재 메뉴에 대한 정보가 없습니다. 
따라서 useTitle의 pageTitle, pageDescription은 빈문자열('')을 반환하며, falsy 값으로 평가되어 fallbackTitle과 fallbackDescription이 출력됩니다.



2. 메뉴 데이터의 LNB명이 아닌 프론트에서 별도로 정의해둔 title/description을 출력해야 하는 경우

프론트에서 별도로 정의해둔 title/description을 출력해야 하는 경우에는 해당 목록 컴포넌트에서 ListLayout을 호출 할 때 isStatic props를 true로 전달해주시면 됩니다. isStatic이 true일 경우, props로 함께 받은 title, description, 혹은 route.meta에 정의된 값이 출력됩니다.

모듈페더레이션 환경에서 Vue Error Boundary 구현하기

Wed, 19 Mar 2025 16:33:05 GMT

0. 배경

현재 개발하고 있는 솔루션은 화면에서 Error가 발생하면, 해당 Error 발생 시점부터 사용자가 새로고침을 하기 전까지 애플리케이션 전체가 정상적으로 동작하지 않는 이슈가 있습니다. 이로 인해 사용자 입력이 반영되지 않거나 화면이 다시 렌더링 되지 않는 등의 현상이 나타납니다. 이를 해결하기 위한 방법인 Error Boundary에 대해 리서치 하고 테스트 한 결과를 정리했습니다.

1. Error Boundary란?

Error Boundary의 역할

UI의 일부분에 존재하는 자바스크립트 에러가 전체 애플리케이션을 중단시키면 안 됩니다. Error boundary 컴포넌트는 하위 컴포넌트에서 발생한 에러가 상위 컴포넌트로 전파되는 것을 막고, 깨진 컴포넌트 트리 대신 Fallback UI를 보여줍니다. 즉, 상위 컴포넌트는 하위 컴포넌트의 에러를 모른 채 정상적으로 계속 작동 할 수 있습니다.

또한, 에러 종류에 따라 적절한 화면을 정의하여 보여줌으로써, 애플리케이션 전반에서 에러와 관련된 일관성 있는 사용자 경험을 제공할 수 있습니다.

핵심 동작 원리

ErrorBoundary 컴포넌트의 onErrorCaptured() 훅에서 false를 반환하면 에러가 더이상 상위 컴포넌트로 전파되지 않습니다. hasError 속성이 true이면 Fallback UI를 렌더링합니다.

hasError 속성이 true 일 때 errorStatus 값에 따라 서로 다른 UI를 렌더링합니다.

Axios Error와 화면 자바스크립트 Error 처리 분리

Vue의 onErrorCaptured() 훅은 에러, 에러를 트리거한 컴포넌트 인스턴스, 에러 소스 유형을 지정하는 정보 문자열, 총 세 개의 인자를 받습니다.

onErrorCaptured(
  (err: unknown, instance: ComponentPublicInstance | null, info: string) => {
})

첫번째 인자인 err에는 모든 타입의 Error가 들어올 수 있기 때문에 기본적으로 unknown 타입을 갖습니다.

따라서 이 err를 에러의 종류(Axios Error / 그 밖의 Error)에 따라 분기하여 처리하려면 각 err의 속성에 안전하게 접근하기 위한 타입 가드가 필요합니다.

타입스크립트 instanceof 연산자를 이용해 타입가드를 설정하려고 했으나, 403, 500과 같은 Error response가 AxiosError 타입으로 판단되지 않는 이슈가 있습니다. 원인을 아직 명확히 알 수 없으나, tanstack-query로 response가 한번 더 감싸지면서 AxiosError 타입으로 추론되지 않는 것으로 짐작하고 있습니다. (추후 명확한 원인 파악 후 개선되어야 할 부분입니다.)

우선은 FetchError 타입인지 판단할 수 있는 사용자 정의 타입 가드 함수를 정의하여 캡쳐한 err가 Axios Error인 경우 에러 코드를 errorStatus로 설정하는 로직을 구현했습니다. 그 외의 JS, 혹은 렌더링 및 라이프사이클 오류의 경우 errorStatus를 0으로 설정했습니다.

// 함수가 true를 반환하면 함수가 호출된 블록 스코프에서 타입이 FetchError로 추론
function isFetchError(error: any): error is FetchError {
  return (
    typeof error === 'object' &&
    error !== null &&
    error.headers &&
    error.headers.constructor?.name === 'AxiosHeaders'
  );
}
onErrorCaptured(
  (err: unknown, instance: ComponentPublicInstance | null, info: string) => {
    hasError.value = true;
    if (isFetchError(err)) {
      errorStatus.value = err.status;
    } else {
      errorStatus.value = 0;
      console.error(
        'Error captured in ErrorBoundary Component: \n',
        err,
        '\n in Component: ',
        instance?.$?.type
      );
    }
    // 에러가 상위 컴포넌트로 전파되지 않도록 막음
    return false;
  }
);

hasError 속성 초기화

Fallback UI를 보여줄것인지를 판단하는 hasError 속성은 기본적으로 애플리케이션이 처음 mount 되었을 때, ErrorBoundary 컴포넌트가 새로고침 등의 이유로 unMount되었다가 다시 mount 되었을 때, route.path가 이동했을 때 초기화 되도록 구현하였습니다.

구현 과정에서의 고민과 결론

#1 에러 바운더리를 host, remote 중 어디에 둘 것인지

Error Boundary 컴포넌트는 솔루션 전체에서 일관성 있게 적용 되어야 하기 때문에, host에 두고 관리하는 것이 좋을 것 같습니다. host에서 Error Boundary 컴포넌트를 작성해서 expose 하고, 해당 컴포넌트를 remote에서 import해서 사용하는 방식으로 구현했고, 테스트 완료 했습니다.

host-app vue.config 파일

exposes: {
     ...
    './components/ErrorBoundary': './src/views/error/ErrorBoundary',
     ...
 },

각 remote-app의 App.vue