mini.log

Frontend Fundamentals 모의고사 2회차 후기

Sun, 29 Mar 2026 12:42:11 GMT

Frontend Fundamentals 모의고사 2회차에 참여했다. 저번 1회차에 운좋게 참여하게 되어 유익한 시간을 보내고, 이번에도 이어서 참여하게 되었다.

1회차 후기

이번에는 개인적인 사유로 많은 시간을 할애하지는 못해서 아쉬움이 있었지만 1회차 때 배웠던 것들을 바탕으로 빠르게 한 번 진행해보았다. 1회차와는 다르게 구현 과제가 아닌 리팩토링 과제여서 조금 더 수월하게 진행할 수 있었고, 컴포넌트 추상화에만 조금 더 집중할 수 있는 시간이었다.

느낀점 3줄 요약

이전에 배웠던 UI가 드러나게 추상화하기를 잘 해낸 것 같았다.
라이브 해설강의를 듣고난 후, 추출과 추상화를 여전히 잘 구분짓지 못하고 있었다는 걸 깨달았다.
1회차에는 다른 참가자들 코드도 많이 뜯어보고 리뷰도 남겼었는데, 그런 시간을 가지지 못해서 아쉬움이 크게 남았다.

과제 진행

1. UI만 보고 임시 코드 작성하기

1회차 때 배운대로 기존 코드를 보지 않고 UI만 보고 페이지 컴포넌트의 대략적인 형태를 임시 코드로 작성했다. 그리고 추상화 하기로 한 컴포넌트들의 인터페이스를 정해보았다. 여기서 집중했던 것은 UI가 드러나도록 하는 것이었는데, 내가 생각하기에 중요했던 부분은 섹션들마다 있는 타이틀, 레이아웃을 위한 spacing 컴포넌트 들이었다. 이것들을 페이지 컴포넌트에 드러내야 페이지 컴포넌트를 보았을 때 UI와 바로바로 매칭이 될 거라고 생각했다.

2. 현재 구현 확인하기

주어진 코드는 모든 페이지의 로직과 jsx가 하나의 컴포넌트에 들어가있는 방식이었다. 일단은 많은 로직들이 있었지만 이걸 기준으로 추상화하지는 않고 UI기준으로 내가 작성한 컴포넌트들로 추상화하고 나면 로직들이 책임에 맞는 컴포넌트로 위치하게 될거라고 생각하고 현재 구현에서 jsx 부분을 위주로 추상화하겠다고 계획을 세웠다.

3. 리팩토링 시작

정말 눈에 보이는 UI대로 컴포넌트화를 진행했다. 여기서 나는 추출과 추상화에 대해서 조금 더 고민이 필요했다고 생각한다.

내가 기존에 생각했던 인터페이스대로 리펙토링이 가능한지를 codex를 이용해서 빠르게 검증해보고 인터페이스만 가지고 이래저래 고민해보았다. 대부분의 컴포넌트들은 section이라는 단위로 분리를 하면 해당 section에서 필요한 상태값과 변환 함수, 그리고 제목이 props로 드러나기 때문에 적절해보였다.

한가지 고민했던 부분은 회의실의 예약 현황을 보여주는 section이었는데 단순히 추출만 하고 props를 구성하면 다음과 같은 인터페이스를 가지게 된다.

하지만 이 컴포넌트의 실제 UI를 보면 섹션 title안에 회의실 별 타임 테이블리스트가 있고 그 타임 테이블은 header와 timelinelist로 이루어져 있다. 그래서 title을 제외한 다른 것들은 사실 타임 테이블 리스트를 위한 것이다. 그래서 이런 UI적 요소들을 드러내고 왜 이런 props들이 필요한지 더 잘 나타내기 위해 합성컴포넌트로 나타내보았다.

      }
        timeline={
          
        }
      />

4. 해설강의를 듣고..

짧은 시간이었지만 나름 잘 해냈다라고 생각했는데 조금 더 추상화에 대해서 생각해보았어야한다는 것을 해설강의를 통해 느꼈다. 오히려 긴 시간 고민했던 1회차때의 코드가 조금 더 나았나? 싶기도 할 정도로 이번에는 거의 추출에 가깝게 리팩토링을 했다는 것을 해설 강의를 진행하는 내내 느꼈다.

먼저 섹션 컴포넌트를 추출할 때 title까지 추출할 필요가 있었을까 싶다. title을 제외한 내용이 들어있는 부분을 컴포넌트화 하겠다고 생각했다면 오히려 추상화에 집중할 수 있었을 것 같다. 가장 오래 고민했던 ReservationTimelineSection의 경우를 예로 들자면, title부분은 페이지 컴포넌트에 그냥 드러내고 타임 테이블 부분만 추상화하겠다고 하면 자연스럽게 예약 현황이라는 도메인 지식을 컴포넌트에서 분리했을거다. rooms, reservations가 아닌 rows, timeRange 등의 props를 받도록 설계했다면 그냥 타임 테이블을 나타내는 컴포넌트로 추상화 할 수 있었다. 그러면 타임테이블을 나타내는 컴포넌트를 페이지컴포넌트에서 가져다썼고, 그안에 들어가는게 회의실과 예약이라는 것이 props로 표현되었을 것이다.

5. 배운점

잘못된 코드 의심하는 방법 하나가 기억에 남는다.

이 props들을 보면 rooms에 rooms를 넘겨준다. 이러면 의심해볼만 하다. 이건 추상화가 맞나? 추출아닌가? 잘 추상화 되었다면 아래와 같을거다. (물론 props 이름은 더 고민이 필요하다.)

이렇게 2회차를 마무리 했는데, 리팩토링을 하면서 조금 더 고민과 연습을 해봐야겠다.

Frontend Fundamentals 모의고사 후기

Tue, 25 Nov 2025 16:18:36 GMT

Frontend Fundamentals 모의고사란?

Frontend-fundamentals

Frontend Fundamentals 모의고사는 토스에서 실제로 출제되었던 과제에 참여하면서 토론하고 해설을 들을 수 있는 프로그램이다. 링크드인에서 이런 프로그램을 진행한다는 것을 보고 선착순 50명 안에 들기 위해 알람을 맞춰놓고 기다렸다.

올해 초, Frontend Fundamentals 문서를 읽고 회사에서도 개인 프로젝트에서도 어떤 코드가 더 좋을까에 대해서 많이 고민하고 개선할 수 있었다. 이번 기회로 토스에서 코드를 작성할 때 중요하게 생각하는 부분이 어떤 것인지 더 많이 배우기를 기대하며 모의고사에 참여했다.

느낀점 3줄 요약

먼저 간략하게 느낀점부터 적어보자면,

과제를 풀면서 평소에 고민하던 부분들을 많이 마주할 수 있어서 좋았다.
제출 후에는 다른 참여자들의 코드를 보면서 좋은 구현 아이디어도 얻어가고, 다른 분들은 어떤 걸 중요하게 생각하며 코드를 작성하는지도 엿볼 수 있었다.
라이브 해설강의가 수능 모의고사 풀이 강의를 떠오르게 했는데, 무릎을 탁치게하는 깨달음도 얻고 나도 나름 Frontend-fundamentals에서 배운 점들을 잘 써먹고 있구나 싶은 자신감도 생겼다.

과제 풀어보기

처음 과제를 받았을 때, 요구사항의 기능 구현 난이도가 높지는 않아보였고 확장성을 고려한 설계와 추상화 관점에 집중해달라는 문구가 있었다. 그래서 익숙한 기술들을 사용해서 기능은 빠르게 구현하고, 설계에 고민을 많이 해보자는 마음으로 시작했다.

고민했던 부분

폼 상태 관리, 필터링 로직 가독성 고민 같은 부분도 있었지만 추상화가 주요 고민이었다. 여러 입력 필드들, 탭 전환, 리스트 등 별 생각 없이 구현하다보면 그냥 관성적으로 컴포넌트로 분리할까? 싶은 부분들이 있었다. 하지만 이번 만큼은 이유 없이 추상화 하지 않겠다고 다짐하며 고민 끝에 나름의 기준을 세울 수 있었다. 고민을 하며 세운 정말 나름의 기준이고 정답은 아니다.

단순히 의미상으로 비슷한 것끼리 묶는 컴포넌트를 만들지 말자.
UI 라이브러리에서 제공하는 컴포넌트 가공하여 재사용 위한 컴포넌트로 만들지말자.
레이아웃은 페이지에서 책임지고 하위 컴포넌트에 숨기지 말자.
로직을 책임 단위로 보고 컴포넌트를 추상화 하자.

입력 필드를 form으로?

여러 입력 필드들이 있고, 이 입력 필드들은 연관된 상태를 가지기 때문에 하나의 form state로 다루는 상황이었다. 이 필드들을 form이라는 컴포넌트로 추상화할지 고민되었다. 그래서 일단 컴포넌트를 만들어보니 몇가지 문제점이 눈에 보였다.

으로 필드사이 간격을 조정하고 있었는데, 하나의 form으로 묶어보니 페이지 컴포넌트에서 레이아웃이 전혀 보이지 않았다.
그리고 formContext로 상태를 주입받다보니 props도 없어서 정말 어떤 역할을 하는 컴포넌트인지 전혀 알 수 없었다.
form 안에 여러 필드 입력을 위한 로직들이 전부 혼재한다.

이 3가지 문제점을 보고 필드별로 추상화하기로 결정했다. 여기서 추상화를 안 할순 없었냐하면, 그럴수도 있었지만 입력 필드 로직, 스타일 등이 모두 페이지 컴포넌트에 존재했기 때문에 이 입력 필드 하나만을 위한 코드들은 숨기는게 좋다고 생각해서 추상화는 꼭 필요하다고 생각했다.

탭 전환 기능을 공통화?

탭 전환을 위한 UI 컴포넌트를 탭 내용을 렌더링 하는 기능까지 갖춘 컴포넌트로 추상화할지가 다음 고민이었다. 하지만 이를 추상화 해서 얻는 점은 탭 렌더링 로직을 숨긴다 정도인데 탭 UI는 있으니 상태만 관리하고 조건부 렌더링을 하면 되는 건데 이걸 숨겨야할까? 싶었다. 그리고 UI 컴포넌트의 인터페이스를 변경하지 않고 최대한 활용하는게 일관성 있게 쓸 수 있을 거라 생각하여 페이지 컴포넌트에 탭 렌더링 로직을 드러냈다.

토론

제가 올린 PR에도 언제든 편하게 의견 주시면 좋아요~

모든 분의 PR을 다 보고 싶었지만 게으름 이슈로 다 보지는 못했다. 점심시간에 잠깐 짬을 내서 코드 리뷰도 달아보고 여러 아이디어를 얻어보았다. 기억에 남는 아이디어는 nummeric input을 다루는 hook을 통해 포메팅과 상태 로직을 추상화 한 것이었는데, 그냥 util로 만들어서 상태 변경 때마다 포메팅 하는 것보다 훨씬 좋다고 생각했다.

그리고 "단일 책임" 경계에 대한 discussion도 아주 재미있었다.

해설을 듣고 난 뒤

라이브코딩으로 진행해주신 해설을 통해 요구사항을 분석하고 접근하는 법부터 설계의 관점을 배울 수 있었다. 해설을 통해 배운점, 잘 해왔던 점을 정리해본다.

배운점

추출과 추상화는 다르다. (좋은 코드란?)
요구사항을 보고 인터페이스 위주로 pseudo code를 작성하면 구현하며 흐름을 잃지 않을 수 있다.
UI가 드러나게 페이지 컴포넌트를 구성하다보면 추상화할 것과 아닌 것이 명확하게 드러난다.
Suspense fallback에 들어가는 컴포넌트를 합성 컴포넌트로 만들어서 의존성이 드러나게 할 수도 있다.
추상화를 할 때에는 엣지케이스를 내부에서 처리하고 내부 컴포넌트의 인터페이스를 유지하자.
책임 단위로 추상화를 하면 재사용성은 따라온다.
컴포넌트 인터페이스를 설계할 때 일반적인 props를 사용하자.

useState는 구현의 영역이다. 이것만으로 추상화할 가치가 있다. useState가 아닌 다른 방식으로 구현하게 될 수도 있으니.

// 이렇게 단순한 상태만 관리하는 훅이지만 
// 이 내부 구현이 전역 상태가 될지, storage를 사용할지, reducer를 사용할지, setQueryState를 사용할지 등
// 구현 방식의 선택사항일 뿐, 단순하니 추상화할 가치가 없다고 생각하지말자. 
function useView(...) {
const [view, setView] = useState<"view1" | "view2>(...)

return [view, setView] as const
}

잘한점

페이지 컴포넌트에서 UI가 드러나게끔 추상화를 했다. 해설을 통해 기준을 더 명확하게 할 수 있었다.
대부분의 컴포넌트 인터페이스에서 의도가 드러나게 해서 사용하는 곳에서 예측이 되도록 했다. 이건 좀 더 연습이 필요하다.

끝으로..

오늘을 계기로 코드를 보는 시각이 달라질 것 같다. 많은 고민과 연습이 필요하겠지만 좋은 코드의 기준들이 체화되도록 노력해야겠다.

좋은 시간 만들어주신 토스 프론트엔드 개발자 분들께 감사드립니다!

함수형 프로그래밍으로 검색 기능 만들기

Tue, 19 Aug 2025 16:17:04 GMT

검색 기능을 구현하면서 점진적으로 함수형 프로그래밍 스타일로 개선해나간 과정을 기록해보려고 한다. 코드가 적힌 순서대로 실행되어 로직이 잘 읽히도록 노력했다.

최초 코드

처음엔 그냥 기본적인 자바스크립트 방식으로 검색을 구현했다. 띄어쓰기를 고려해서 replace로 공백을 제거하는 방식을 썼다.

// 함수형 프로그래밍을 위해 FxTS 라이브러리를 사용했다.
import { filter, pipe, toArray, isUndefined, unless } from '@fxts/core' 

...

  // 기존 카테고리 필터 로직에 검색 로직을 추가했다.
  const search = Route.useSearch()

  const { data: policies } = useSuspenseQuery({
    ...getPoliciesQueryOptions(),
    select: ({ data: policies }) => {
      pipe(
        policies,
        unless(
          () => isUndefined(search.category),
          filter((policy) => policy.category === search.category!)
        ),
        // 여기 부터 개선하게 될 코드
        unless(
          () => isUndefined(search.keyword),
          filter(
            (policy) =>
              policy.title
                .toLowerCase()
                .replace(/\s+/g, '')
                .includes(search.keyword!.toLowerCase().replace(/\s+/g, '')) ||
              policy.description
                .toLowerCase()
                .replace(/\s+/g, '')
                .includes(search.keyword!.toLowerCase().replace(/\s+/g, ''))
          )
        ),
        toArray
      )
    },
  })

동작은 하지만 코드가 잘 읽히지 않고 저 || 비교연산자를 기준으로 딱봐도 같은 코드가 반복되고 있다. 이 두가지 부분을 어떻게든 개선해 보고 싶었다.

Step 1: 공통 로직 분리

가장 먼저 텍스트 정규화 로직을 함수로 분리했다. 일단 중복을 제거해보려는 시도였다.

// 텍스트 정규화 함수 분리
const normalizeText = (text: string) => text.toLowerCase().replace(/\s+/g, '')

filter((policy) => {
  const normalizedKeyword = normalizeText(search.keyword!)
  return (
    normalizeText(policy.title).includes(normalizedKeyword) ||
    normalizeText(policy.description).includes(normalizedKeyword)
  )
})

이제 normalizeText라는 함수명으로 의도가 명확해졌고, 키워드도 한 번만 정규화 하니까 조금 나아보였다. 그런데 return 이후의 조금 극단적이지만 코드를 순서 그대로 읽어보면 이렇게 된다.

정규화 하는 함수에 title을 넘기고 그 결과에 정규화된 키워드가 포함되거나 정규화 하는 함수에 description을 넘기고 그 결과에 정규화된 키워드가 포함되는 policy를 필터링한다.

Step 2: 체이닝 방식으로 복귀

Step 1에서의 함수 분리는 좋았지만, 읽기가 어려웠고 여전히 || 연산자를 기준으로 같은 코드가 반복된다. 차라리 체이닝 방식이 읽는 순서대로 실행되기 때문에 더 낫다고 생각했다.

filter(
  (policy) =>
    policy.title
      .toLowerCase()
      .replace(/\s+/g, '')
      .includes(search.keyword!.toLowerCase().replace(/\s+/g, '')) ||
    policy.description
      .toLowerCase()
      .replace(/\s+/g, '')
      .includes(search.keyword!.toLowerCase().replace(/\s+/g, ''))
)

Step 3: pipe로 공통로직 순서대로 실행하기

텍스트 정규화 로직을 함수화 한건 좋은 시도였고, 문제는 함수의 실행순서라고 생각했다. 그래서 반복되고 있던 search.keyword 부터 일단 pipe의 첫 번째 인자로 넣어보기로 했다.

filter((policy) =>
  pipe(
    search.keyword!,
    normalizeText,
    (normalizedKeyword) =>
      some((field) => normalizeText(field).includes(normalizedKeyword), [
        policy.title,
        policy.description,
      ])
  )
)

이제 키워드는 한 번만 정규화되고, 로직의 흐름도 더 명확해졌다. 키워드를 정규화한 다음, 그 결과를 가지고 필드들과 비교하는 구조가 되었다.

Step 4: 필드 배열을 기준으로 pipe 실행

그런데 some 함수를 보다보니 괜히 함수로 감싸야하고, 비교 대상 필드 배열도 두번째 인자로 위치시켜야했다. 다시 생각해보니 비교 대상 필드 배열을 pipe의 첫번째 인자로 하는게 자연스러울 것 같았다.

filter((policy) =>
  pipe(
    [policy.title, policy.description],
    map(normalizeText),
    some((field) => field.includes(normalizeText(search.keyword!)))
  )
)

이제 로직이 정말 읽는 순서대로 진행된다

비교 대상 필드들을 배열로 만들어
모든 배열 원소를 정규화하고
정규화된 키워드가 포함된 필드가 있는지 확인한다

하지만 여전히 some안의 콜백 함수 로직이 눈에 거슬렸다. 간단하니까 읽어지는 것 같지만 함수가 중첩되어 순서에 맞지 않다.

Step 5: 한번 더 pipe 실행하기

이쯤 되니 함수 실행 순서가 반대일 때는 pipe를 사용하면 되는구나라는 생각이 저절로 들었다. some 안의 콜백도 pipe를 이용해 순서대로 읽게 했다.

filter((policy) =>
  pipe(
    [policy.title, policy.description],
    map(normalizeText),
    some((field) => pipe(
      search.keyword!, 
      normalizeText, 
      (keyword) => field.includes(keyword)
    ))
  )
)

이제 모든 부분이 순서대로 실행되어 데이터가 어떻게 변화되는지 잘 읽을 수 있게 되었다. 키워드를 2번 정규화하게 되지만, 성능에 영향을 미치지는 않을거라 가독성을 높이는게 더 좋다고 생각했다.

최종 결과

const { data: policies } = useSuspenseQuery({
  ...getPoliciesQueryOptions(),
  select: ({ data: policies }) =>
    pipe(
      policies,
      unless(
        () => isUndefined(search.category),
        filter((policy) => policy.category === search.category!)
      ),
      unless(
        () => isUndefined(search.keyword),
        filter((policy) =>
          pipe(
            [policy.title, policy.description],
            map(normalizeText),
            some((field) => pipe(
              search.keyword!, 
              normalizeText, 
              (keyword) => field.includes(keyword)
            )
           )
          )
        )
      ),
      toArray
    ),
})

마지막으로..

 some((field) => pipe(
   search.keyword!, 
   normalizeText, 
   field.includes // 화살표 함수가 아닌 메서드를 pipe에 넘기면?
 )

마지막 화살표 함수를 쓴 부분을 꼭 저렇게 써야하나 라는 생각이 들어 메서드를 넘겨보았다. 하지만 동작을 하지 않았는데, 이유는 this 바인딩 때문이었다. 공부할 때 정말 많이 봤던 내용이라 알고 있다고 생각했는데 전혀 아니었다. this 바인딩에 대해서는 다시 잘 정리해서 다음 글로 써야겠다.

느낀점

함수형으로 로직을 작성하면 코드를 읽는 순서와 실행 순서를 일치시킬 수 있다.
새로운 비교 대상 필드가 생겨도 배열에 넣으면 되니 확장성도 좋다.
카테고리 필터링에 검색 필터링을 쉽게 추가한 것도 pipe의 힘이라고 생각한다.
의도적으로라도 pipe와 map, filter, some 같은 함수들로 표현하다보니 다양한 로직들을 함수형으로 작성할 수 있겠다는 자신감이 생겼다.

오늘 작성한 코드들은 모두 FxTS라는 라이브러리를 사용했다. 오늘 내가 사용한 함수들 외에도 아주 많은 API를 제공하는데, 함수형 프로그래밍에 대한 두려움의 장벽을 많이 허물어 준 라이브러리다. 사용법이 정말 간단하면서 타입추론도 잘 되고, 일관성 있게 코드를 작성할 수 있게 도와준다. 유인동님의 도서 멀티패러다임 프로그래밍의 리뷰어로 참여하면서 함수형 프로그래밍과 FxTS에 대해 알게 되었는데 돌아보니 정말 감사한 경험이었다.

Prettify 타입으로 복잡한 타입 쉽게 보기

Sun, 17 Aug 2025 14:17:29 GMT

복잡한 제네릭 타입들을 중첩해서 쓰다 보면 결과 타입이 뭔지 도저히 알 수가 없다.

Omit & OtherType, 'c'>

IDE에서 보면 이런 식으로 나와서 매번 최종 타입까지 찾아가서 봐야한다.

그러던 중에 유튜브 영상에서 이런 헬퍼 타입을 만들어서 사용하는 방법을 보게 되었다.


/**

 * @description 복잡한 교차/중첩 타입을 펼쳐서 읽기 쉽게 표시하는 헬퍼 타입

 * 타입의 의미는 그대로 유지하면서, IDE에서 보기 좋은 형태로 변환한다.

 */

export type Prettify = {

  [K in keyof T]: T[K]

} & {}

사용 예시


// Before: 복잡한 타입

type Complex = Omit<{ a: string; b: number; c: boolean }, 'c'> & { d: Date }

// IDE에서 "Omit<{...}, 'c'> & { d: Date }" 로 표시됨



// After: Prettify 적용

type Clean = Prettify

// IDE에서 "{ a: string; b: number; d: Date }" 로 깔끔하게 표시됨



// 유니온 타입도 잘 동작함

type PolicyCategories = Prettify | '전체'>

// IDE에서 "일자리" | "주거" | "금융" | "교육" | "전체" 로 깔끔하게 표시됨

동작 원리

타입을 "예쁘게" 만들어주는 마법 같은 느낌이어서 원리를 찾아봤다.

1. Mapped Type으로 재구성


{ [K in keyof T]: T[K] }

이 부분이 TypeScript에게 "T의 모든 키를 순회하면서 새로운 객체 타입을 만들어라"라고 지시한다. 교차 타입이나 복잡한 조건부 타입을 단일 객체 리터럴로 재구성하는 역할이다.

2. 빈 교차 타입으로 강제 평가


& {}

이게 핵심이다. 빈 교차 타입을 추가하면:

TypeScript 컴파일러가 타입을 즉시 평가하도록 강제함
지연 계산을 방지하고 타입 캐시를 무효화함
내부 표현을 사용자가 읽기 쉬운 형태로 정규화함

왜 타입스크립트는 알아서 이렇게 안해줄까?

AI의 답변은 다음과 같다.

TypeScript는 성능을 위해 복잡한 타입 계산을 가능한 한 미루려고 한다. 그래서 IDE에서 보면 Omit, '...'> & {...} 같은 내부 표현 그대로 보여준다.

Prettify는 이런 지연 계산을 강제로 실행시켜서 최종 결과를 보여주는 방식이다.

언제 사용하면 좋을까?

여러 제네릭 타입을 조합해서 만든 복잡한 타입
유니온 타입이 복잡하게 중첩된 경우
라이브러리 타입들을 조합해서 만든 커스텀 타입
동료들이 타입을 이해하기 쉽게 만들고 싶을 때

타입을 볼 때 타입 선언부까지 가지 않고 확인할 수 있어서 좋은 것 같다. 이렇게 타입 계산을 강제로 시키는 방식이 IDE에서 성능을 실제로 떨어뜨리는지는 확인해볼 필요가 있다.

참고

https://youtu.be/q5DFpyIN5Xs?si=qhd1vV67EOa4w5MI&t=241

TanStack Router 파일 라우팅 깔끔하게 관리하기 (feat. Private folder)

Sun, 17 Aug 2025 14:00:06 GMT

요즘 TanStack Router를 아주 잘 사용하고 있는데 이걸 선택한 이유는 크게 두가지다.

Type Safe하게 router 기능을 사용할 수 있다. (React Router를 쓰면서 가장 불편했던 점..)
파일 기반 라우팅이 가능하다.

나는 NextJS를 많이 사용해보지 않아서 파일 기반 라우팅을 할 때에는 디렉토리 구조를 어떻게 구성해야할지 고민이 되었다.

"특정 라우트에서만 사용하는 컴포넌트나 훅은 어디 둬야 하지..?"

/policies 경로에서만 쓰는 policy-card 컴포넌트가 있다면, /policies/components/policy-card 이런 식으로 route 하위의 components 디렉토리를 만들고 싶었다. 하지만 이렇게 할 경우 components를 sub route로 인식해서 routeTree에 포함이 된다.

🤔 routeFileIgnorePrefix vs routeFileIgnorePattern

NextJS에서는 Private folder를 이용해서 _components와 같이 route로 인식하지 않게 하는 방법이 있었다. 그래서 이와 같은 기능이 있을 거라고 생각하고 문서를 찾아보니 명시적으로 라우팅에서 특정 파일/폴더를 무시하는 두 가지 옵션을 찾을 수 있었다.

routeFileIgnorePrefix: 파일/폴더 이름 앞에 특정 접두사(기본값: -)가 붙으면 무시하는 방식.
routeFileIgnorePattern: 정규식 패턴에 맞는 파일/폴더를 무시하는 방식.

처음엔 routeFileIgnorePattern을 사용하려고 했다. (components|hooks|utils) 이런 식으로 정규식을 설정 파일에 한 번만 등록해두면, 폴더 이름을 - 없이 깔끔하게 쓸 수 있기 때문이었다.

// Pattern 방식
src/routes/
└── policies/
    ├── components/ 
    │   └── policy-card.tsx
    ├── hooks/
    │   └── use-policy-filter.ts
    └── index.tsx

👍 Prefix 방식 선택 이유

하지만 나는 routeFileIgnorePrefix를 쓰기로 했고 기본값인 -를 prefix로 쓰기로 했다.

1. 명확성

폴더 이름에 -가 붙어있으면 누가 봐도, 언제 봐도 "아, 이건 라우트가 아니구나" 라고 바로 알 수 있다.

// Prefix 방식
src/routes/
└── policies/
    ├── -components/ 
    │   └── policy-card.tsx
    ├── -hooks/
    │   └── use-policy-filter.ts
    └── index.tsx

routeFileIgnorePattern 방식은 디렉토리 구조만 봐서는 얘가 라우트인지 아닌지 알 수가 없다. 항상 vite.config.ts 같은 설정 파일을 열어서 정규식을 확인해야만 한다.

2. 설정 파일 변경 최소화

routeFileIgnorePrefix 방식은 그냥 규칙에 따라 디렉토리를 만들면 된다. prefix를 바꾸지 않는다면 설정 파일을 건드릴 필요가 전혀 없다. (prefix를 _로 바꾸려고 했지만 _는 TanStack Router에서 레이아웃 파일명으로 쓰이고 있기 때문에 기본값을 선택했다.)

하지만 routeFileIgnorePattern은 나중에 utils 디렉토리가 필요해지면? constants 디렉토리가 필요해지면? 그때마다 설정 파일 열어서 정규식에 |utils, |constants를 추가해줘야 한다. 관리 포인트가 늘어나는 걸 피하고 싶었다.

결론

routeFileIgnorePattern: 설정에 의존해야 하고 관리 포인트가 늘어난다.
routeFileIgnorePrefix: 단순하고, 명확하며, 확장성이 좋다.

vscode로 디버깅하기

Mon, 08 Jul 2024 08:03:37 GMT

웹 브라우저에서와 같이 vscode에서도 디버거를 사용할 수 있다.

break point 설정

메뉴 알아보기

variables

local
global

watch

변수 추적
문장도 입력 가능

call stack

함수 실행순서를 확인할 수 있다.

loading script

현재 로드된 모든 스크립트(소스 파일)를 보여준다.

break point 확인

break point중 지금 사용하지 않을 것을 일시 비활성화 할 수 있다.

디버거 조작하기

continue

클릭하면 다음 브레이크 포인트로 실행

step over

코드 한줄씩 실행하는데, 다른함수를 호출할 때 건너뛰면서 실행됨

step into

함수 안으로 들어가고 싶을때

step out

함수 밖으로 빠져나옴

활용팁

variable 동적으로 조작
edit break point로 특정 시점에 멈추게 하기
콜스택에서 몇번째줄에서 호출되었는지 확인하기

[Error log] Failed to fetch dynamically imported module

Mon, 20 May 2024 04:33:41 GMT

사이드 프로젝트를 하는 와중에 storybook을 실행했을 때 위와 같은 에러가 발생했다.

절대 경로로 import 한 파일을 찾을 수 없다는 에러여서 vite와 관련되어 있을 거라고 생각하고 찾아보았다.

builder-vite

공식문서의 vite설정 부분을 찾아보니 아래와 같이 패키지 설치가 필요했다.

core: {
    builder: '@storybook/builder-vite',
  },

vite.config

패키지 설치를 마쳤는데도 안되길래 vite 경로를 조금 더 찾아보았다. tsconfig에서 paths 설정을 해주었고 import도 잘 되어서 몰랐는데 vite에서도 기본 path 설정이 필요했다.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";
import path from "path";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
   resolve: {
    alias: {
      "~/atoms": path.resolve(__dirname, "./src/components/atoms"),
      "~/molecures": path.resolve(__dirname, "./src/components/molecules"),
      "~/organics": path.resolve(__dirname, "./src/components/organisms"),
      "~/templates": path.resolve(__dirname, "./src/components/templates"),
      "~/pages": path.resolve(__dirname, "./src/pages"),
      "~/style": path.resolve(__dirname, "./src/style"),
      "~": path.resolve(__dirname, "./src"),
    },
  },
});

위와 같이 설정하고 나니 정상적으로 작동한다.

vite-tsconfig-paths

예전 프로젝트에 따로 alias 설정이 없길래 괜찮은 줄 알았는데 잘 보니 그때는 패키지를 사용한거였다.

import { defineConfig } from "vite";
import tsConfigPaths from "vite-tsconfig-paths";

import react from "@vitejs/plugin-react-swc";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react(), tsConfigPaths()],
});

위의 alias 설정으로 잘 되기 때문에 이번에는 따로 패키지 설치없이 진행했다.

Supabase로 프로젝트 살리기

Thu, 16 May 2024 08:54:01 GMT

항상 팀 프로젝트를 하고 나서 디벨롭을 하려하면 "서버비용 때문에 서비스를 중지합니다" 라는 말을 듣게 된다. 이런 프로젝트를 살리기 위해 Supabase를 사용해보았다.

선택 이유

Supabase의 문서를 들어가자 마자 Firebase의 대안인 오픈소스라는 소개가 있다. 이처럼 Firebase라는 선택지도 있었지만 Supabase를 사용한 이유는 Postgres 기반의 관계형 DB를 사용할 수 있다는 점이었다.

기존 프로젝트를 살려서 디벨롭하는게 목적이기 때문에 이전의 API 자원을 그대로 사용하기를 원했는데, Supabase의 관계형 DB 덕분에 ERD를 참고해서 빠르게 DB를 구축할 수 있었다.

그리고 추가로 Edge Functions, Storage, Auth 같은 기능을 제공하는 것도 Supabase의 장점인데 Auth는 일단 사용하지 않을 것이기 때문에 이것 빼고 설명해보겠다.

프로젝트 만들기

프로젝트를 만드는 것이 Supabase의 시작인데 아주 간단하다. 아래와 같이 이름과 Organization을 지정하고 새 프로젝트를 생성하면 된다.

📚 Database

Database를 만드는 것도 아주 직관적인데, Table Editor로 가서 new Table만 누르면 아래와 같이 명령어 하나 없이 테이블을 만들 수 있다. 또는 SQL Editor에서 SQL문으로 여러 작업들을 할 수 있는데 이것도 정말 편한게 AI Assistant가 있어서 SQL문을 잘 몰라도 사용할 수 있다.

RLS

RLS는 깊게 알지는 못하지만 DB에 접근할 수 있는 사용자를 지정하는 역할을 한다고 알고 있다. 나중에 Edge functions로 API를 만들다가 알게되었는데 아무리 요청을 해도 data가 빈값으로 오길래 찾아보니 RLS를 지정하지 않아서였다.

RLS는 테이블에서 policy를 선택하면 나오는데 이것도 아래와 같이 템플릿을 제공하기 때문에 아주 편하게 사용할 수 있다.

🔨 Edge Functions

사용하면서 정말 좋다고 생각한 것이 Edge Functions인데 DB만 있다면 이를 호출할 때 SQL문 비슷하게 접근해서 필요한 데이터를 요청하거나 삽입해야한다.

Edge Functions은 서버리스 함수 기능 중 하나로, 전 세계의 엣지 네트워크에 분산되어 사용자에게 빠른 서비스를 제공한다. 이를 활용하여 기존과 동일하게 API 통신을 할 수 있는 백엔드 서비스를 구축할 수 있다.

Edge Functions은 Deno 환경에서 개발할 수 있는데 개발 환경을 세팅하고 사용하는 건 Supabase Youtube와 공식문서를 보면 너무 잘 알려주기 때문에 사용법은 생략하겠다.

Deno를 통해 함수를 작성하고 배포하고 요청을 보내봤다.

📦 Storage

Storage는 사진 같은 파일을 저장할 수 있는 저장소이고 이미지 url을 생성해주기 때문에 이것도 정말 쉽게 이용해서 API를 만들 수 있었다.

🧐 회고

예전에 프로젝트에 사용을 고려했던 적이 있었는데 DB에 대한 이해도가 부족해서 설계부터 막히다보니 그만뒀었다. 하지만 DB나 API 함수에 대한 이해도가 생기고 나니 정말 쉽게 백엔드를 구축할 수 있게 해주는 서비스라는 걸 느낄 수 있었다. supabase로 지하철 SNS 서비스의 백엔드를 아주 간단한 것부터 살려보았다. 그리고 공식문서가 너무 잘 되어 있어서 끝난 프로젝트를 살리는데에 쓰기 정말 좋은 것 같다.

참고

supabase 공식문서 생활코딩 유튜브

Vite를 알아보자

Thu, 18 Apr 2024 10:37:22 GMT

🥲 개요

면접관: Vite를 사용한 이유가 있나요? 나: ESM 방식을 사용하기 때문에 빌드속도가 빨라서 선택했습니다. 면접관: 음.. 배포환경에서는 Rollup을 사용하고 개발환경에서만 esbuild를 사용하지 않나요? 나: 아.. 그 부분까지는 잘 몰랐습니다.

사실 첫번째 답변에서 “ESM 방식을 사용하기 때문에 개발 서버 구동이 빠릅니다.” 라는 말을 하고 싶었던 거였다. Vite와 빌드에 대해 제대로 알고 있지 않아서 답을 잘못했었던 것 같다. 그래서 Vite를 조금 더 이해하기 위해 정리해보려 한다.

📦 번들링

모듈화 되어있는 여러 자바스크립트 파일을 브라우저에서 실행할 수 있는 파일로 합치는 과정

Webpack, Rollup 그리고 Parcel과 같은 번들링 도구들이 있다.

번들링 vs 빌드 번들링은 빌드의 한 부분이다. 번들링, 압축, 난독화, 트랜스파일링 등의 과정을 빌드라고 한다. 현대의 번들링 도구들은 빌드 과정까지 함께 지원하기 때문에 헷갈렸다.

문제

프론트엔드 애플리케이션이 발전함에 따라 JS 모듈의 개수도 많아지다 보니 번들링 작업 후 개발 서버를 가동하는데에 너무 오래걸리고, HMR을 사용하더라도 변경 사항이 적용되는 데에 수 초 이상 걸리는 문제가 있었다. Vite는 ESM을 활용해서 개발 서버 구동 시간을 줄이고 이런 문제를 해결한다.

⚡️Vite

개발환경

서버구동

Vite는 모듈을 Dependencies와 Source code로 나누어 위의 문제점을 개선했다.

Dependencies 개발 할 때 바뀌지 않는 부분
esbuild를 이용한 사전 번들링을 제공해서 기존 번들러보다 빠른 속도를 제공한다.

Source code JSX, CSS 같이 컴파일링이 필요하고 수정이 잦은 것들 Native ESM을 이용해서 브라우저를 번들러로 사용한다.

소스 코드 갱신

Webpack 소스 코드를 갱신하면 기존의 경우 번들링 과정을 다시 거쳐야했고 이에 대한 대안으로 나온게 Webpack의 HMR(Hot Module Replacement)이다. 이는 모듈 전체를 다시 로드하지 않고 변경된 부분만 업데이트 하는 방식이다. 하지만 Webpack의 경우 소스코드가 하나의 파일로 번들링 되어 있기 때문에, 모듈의 의존성을 파악하기 위해 모든 파일을 해석해야했다.
그래서 프로젝트 규모가 커지면 HMR 시간이 길어지는 문제가 있었다.
Vite ESM을 이용한 HMR을 구현해서 변경된 모듈과 직접적으로 관련된 부분만 업데이트 해서 기존의 HMR을 개선했다. 이렇게 해서 프로젝트 규모가 커져도 HMR로 업데이트 하는 시간에는 영향이 없도록 했다.

이렇게 Vite도 HMR을 사용한다는걸 확인할 수 있다.

배포환경

ESM이 대부분의 브라우저에서 지원되지만 배포 시에는 Rollup으로 번들링한다.

ESM을 배포환경에서 사용하면 각 모듈 파일을 별도의 HTTP 요청을 통해 가져와야하기 때문에 네트워크 지연이 될 수 있다. 그리고 트리 셰이킹이나 코드 압축, 난독화, 청크파일 분할을 이용해서 번들링하는게 좋기 때문에 배포환경에서는 번들링을 한다.

번들링에 esbuild를 사용하지 않는 이유는 Rollup의 플러그인을 이용하기 위해서라고 한다. esbuild는 주로 성능 최적화에 초점을 두고 있기 때문에 Rollup만큼 다양한 기능을 제공하지 않는다고 한다.

특징

index.html 이 public이 아닌 프로젝트 루트에 위치한다.

이건 추가적인 번들링 과정 없이 index.html이 앱의 진입점이 되게끔 하기 위함이라고 한다.

```
// index.js
var globalVar = "global";

console.log(window);
```
이렇게 전역 변수를 선언하고 html을 만들어서 javascript를 브라우저에서 실행시키면 window 객체를 확인할 수 있다. 아주 많은 값들 중에 이상한 게 하나 껴있다. 전역 변수로 선언했던 값이다. 이처럼 전역 변수를 만들면 window 객체 안에 변수가 만들어지고 window.globalVar로 접근도 가능하다.

🍄 전역 변수의 문제점

스코프 분리 안됨

window 객체에서 전역 변수에 접근할 수 있다는 것이 큰 문제가 될 수 있다. index2.js라는 다른 파일을 하나 더 만들고 window.globalVar에 접근해보자.
```
...
  
    
    
  
```
```
// index2.js
console.log("index2", window.globalVar);
```
이처럼 파일을 나눠도 전역공간에 선언한 변수를 참조할 수 있다. 즉, 스코프가 나뉘지 않는다. 이 말은 파일이 여러 개가 되면 변수를 중복 선언하게 될 수도 있다는 뜻이다.

전역 공간 오염

전역 변수는 window 객체 안에 만들어진다는 것을 위에서 보았다. 그러면 window 객체 안에 있는 global method와 같은 이름으로 선언하면 어떻게 될까?
```
var setTimeout = "global";

console.log(window);
```
setTimeout 변수를 선언해보니 메서드가 없어지고 "global"로 할당되어 있는 것을 볼 수 있다. 이처럼 전역 변수를 잘못 사용하면 메서드를 사용할 수 없게 된다.

😷 전역 공간 사용 최소화
- 전역에서는 IIFE(즉시실행함수) 사용하기
- 전역 공간에 함수가 선언되는 것을 방지한다.
- Module 사용하기
- 모듈 파일에서 함수 밖에 선언된 변수는 전역 스코프가 아닌 모듈 스코프에 등록된다.
- var 대신 const, let 사용하기
- var는 block scope가 아니라서 for문 등에 사용하면 전역 공간을 오염시킬 수 있다.
- closure 사용하기

grid 뿌수기

Mon, 01 Jan 2024 12:57:50 GMT

flexbox에 이어서 grid를 정리해본다. 기본 개념부터 반응형 웹에서 사용할 수 있는 grid 속성까지 공부해보자.

🍊 grid 개념

flex가 main-axis를 기준으로 1차원에서 요소를 정렬했다면 grid는 column과 row로 2차원에서 요소를 정렬한다.

.container {
    display: grid;
}

flex와 마찬가지로 부모요소에서 grid를 적용하고 cell의 형태를 정의한다. 하지만 flex와 다르게 자식 요소에 적용하는 속성이 많다

🛠 속성

🔨 부모요소에 적용하는 속성

grid-template-columns, grid-template-rows

columns: 열의 너비, 개수 rows: 행의 높이, 개수

.father {
    grid-template-columns: 100px 100px;
    grid-template-rows: 200px 100px;

}

gap

flex와 마찬가지로 gap을 사용할 수 있다. 이때 가로와 세로의 gap을 다르게 하고 싶다면 column-gap과 row-gap을 사용한다.

.father {
    row-gap: 10px;
      column-gap: 20px;
}

inspector chrome inspector를 활용하면 grid의 형태를 쉽게 알아볼 수 있다.

line number

grid에는 line number가 있는데 맨 앞 가장자리 부터 1, 맨 뒤 가장자리 부터 -1이 된다. line에다가 이름을 지정해 줄 수도 있다.

  grid-template-columns: [first] 100px [second] 200px [third] 50px [last];
  grid-template-rows: [korea] 200px [japan] 100px [usa];

🔧 자식요소에 적용하는 속성

grid-column, grid-row

자식 요소가 그리드 셀의 몇번째 라인에서 시작해서 몇번째 라인에서 끝날지를 정할 수 있다. line number또는 line name을 사용한다.

.child:last-child {
  background-color: tomato;
  /* grid-column-start: 2;
  grid-column-end: -1; */
  grid-column: second / last; /*shortcut*/
}

.child:first-child {
  /* grid-row-start: 1;
  grid-row-end: -1; */
  grid-row: korea / usa; /*shortcut*/
}

🪓 Advanced

fr

grid-cell의 크기를 정의할 때 사용하는 단위인데 상대적인 크기를 나타낸다

.father {
    grid-template-columns: 1fr 1fr 1fr 2fr; /*1 : 1 : 1 : 2*/
}

repeat

grid-cell의 크기를 반복적으로 쓸 때 유용하게 사용할 수 있다.

.father {
    grid-template-columns: repeat(3, 1fr) 2fr; /*1 : 1 : 1 : 2*/
}

grid-templete-areas, grid-templete

위의 기본 속성들로 표현하기가 까다로울 경우 grid-templete-areas라는 속성을 사용할 수 있다. 직접 grid-cell의 구역을 지정해준다. grid-templete으로 줄여 쓸 수 있다.

body {
  display: grid;
  height: 100vh;

  /* grid-template-columns: 1fr 1fr 1fr 1fr;
    grid-template-rows: 1fr 2fr 1fr;
    grid-template-areas:
      "a a a a"
      "b b b c"
      "d d d d"; */

  /*shortcut*/
  grid-template:
    "a a a a" 1fr
    "b b b c" 2fr
    "d d d d" 1fr / 1fr 1fr 1fr 1fr;
}

header {
  background-color: blue;
  grid-area: a;
}

section {
  background-color: coral;
  grid-area: b;
}

aside {
  background-color: forestgreen;
  grid-area: c;
}

footer {
  background-color: deeppink;
  grid-area: d;
}

span keyword

자식 요소가 grid-cell을 몇 개 차지할 건지를 나타내는 속성이다.

.child {
    grid-column: 1 / span 2; /*1번 라인부터 시작해서 2개의 grid-cell을 차지함*/
}

grid-auto-column, row, flow

지정해둔 grid-cell의 개수보다 많은 자식 요소들이 생길 경우 새로운 자식 요소를 배치하는 속성들이다.

4개의 자식요소들을 template으로 조정해주고 나머지는 auto로 정한다

.father {
    grid-template-columns: repeat(2, 1fr);
      grid-template-rows: repeat(2, 1fr);
      grid-auto-rows: 1fr; /*새로운 요소의 높이*/
      grid-auto-columns: 1fr; /*새로운 요소의 너비*/
      grid-auto-flow: column; /*grid 요소들을 배치할 때 column을 먼저 채운다*/
}

justify-items, align-items, place-items, place-self

셀 내부 아이템 정렬할 때 사용하는 속성들 px 쓸 때만 유효하다.

child의 크기는 column의 크기가 아니다.

.father {
  ...
  align-items: end;
  justify-items: center;
  place-items: end center; /*shortcut*/
}

.child {
  ...
  width: 50px;
  height: 50px;
}

.child:nth-child(6) {
  ...
  /* align-self: center;
  justify-self: center; */
  place-self: center center; /*shortcut*/
  grid-column: span 2;
}

justify-content, align-content, place-content

셀 자체를 그룹 정렬할 때 사용하는 속성들

.father {
  ...
  /*align-content: start;
      justify-content: end;*/
  place-content: start end;
}

min-content, max-content

width에 주는 것처럼 grid-template-columns에도 사용할 수 있다.

.father {
  grid-template-columns: 1fr max-content, 1fr;
}

minmax()

최소값보다 크고 최대값보다 작은 크기 범위를 정의한다.

.father {
  grid-template-columns: repeat(3, minmax(300px, 350px));
  /*minmax(min-content,max-content)*/
}

반응형 ui

auto-fill

빈 공간이 있을때 지정한 크기(min)의 열을 최대한 많이 만듬, 그 열이 비어있어도 만듬

grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));

auto-fit

빈 공간이 있을때 지정한 크기(min)의 열을 최대한 많이 만듬, 자식 요소의 개수만큼이 최대

grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));

🎮 연습하기

grid-garden