🎓 [토스 Frontend Fundamentals 모의고사 1회 후기] 확장성을 고려한 설계

토스가 중요하게 생각하는 것은 무엇일까?
토스가 중요하게 생각하는 것이 왜 중요할까?

직접 과제를 풀고 해설 라이브를 보면서 확장성을 위해 토스는 어떻게 설계하는지 살펴볼 수 있는 기회를 가졌습니다!

안녕하세요! 토스 모의고사 1회에 참여하여 회고 및 후기를 작성합니다.

처음에 참여 신청했을 때 굉장히 기쁘기도 했지만 한편 의아했습니다.

💭 왜 고맙게 이런 걸 열어주지? 바쁘실텐데..? 역시 토스는 외부와 소통을 중요하게 여기는 구나! FE 개발 생태계의 발전을 도모하는구나! (그치만 모의고사 ..?)

이 숨길 수 없는 의문들을 애써 뒤로한 채 설레는 마음으로 주말동안 열심히 고민하여 과제를 제출하고 화요일에 해설 라이브를 들었습니다.

라이브 시작하자마자 이 의문을 해결해 주셨는데 토스 과제에 대한 루머 때문에 사설(?) 말고 출제 평가위원의 출제 의도를 직접 밝히겠다는 의도였다고 합니다! 👍

📍 과제: 꼭 신경써주세요 ☝️

---

• 서비스의 유지보수나 장기적인 확장성을 고려한 설계, 추상화 관점에 집중해서 기능을 구현해주세요.
• 사용자 경험을 개선하고 싶은 지점이 있다면 구현에 포함시키거나 README 등에 문서로 남겨주세요.
• 의문점이 있다면 스스로 합리적인 가설을 세우고 진행해주세요.

인상 깊은 부분 중 하나였습니다.

구현 요구사항 전 아주 큰 글씨로 확장성을 고려한 설계와 추상화 관점에 집중해서 기능을 구현하라는 요구사항을 보고 프로젝트 구조 부터 고민이 들기 시작했습니다.

📍 나의 접근 🤓

---

과제를 시작하고 1~2시간 동안 제가 이용해 본 모든 AI를 총 출동해서 토론을 했습니다.

💭 프로젝트 구조는 어떻게 잡을까? 확장성있는 구조라면 역시 FSD 일까?
💭 상황과 프로젝트 규모에 맞게 설계해야 하는데 요구사항 자체가 확장성있게 설계하라고 하네?
💭 어떻게 하지? 토스는 뭘 원하는 거지? 어떻게 접근하는 게 맞는 거지?

AI들과 토론 끝에 저는 다음과 같은 전략을 취했습니다.

1. 기능 구현 우선
2. 섣부른 추상화와 최적화 지양
3. 같은 관심사는 가깝게 위치
4. 하지만 관심사 분리는 필수적 진행
5. 구현 이후 리팩토링 하면서 유지보수와 확장성을 고려한 추상화 진행

초기에는 YAGNI(You Aren't Gonna Need It) 원칙에 따라 과도한 설계를 지양하고 구현에 집중한 뒤, 장기적인 확장성을 확보하기 위해 리팩토링을 진행하기로 결정했습니다.

... 저는 처음부터 확장성이라는 의미를 오인해 함정에 빠졌을 지도 모릅니다.

해설 라이브를 보고나니 구조나 방법론 자체는 중요하지 않다는 것을 깨달았습니다.
제일 중요한 것은 예측 가능하고 읽기 쉬운 코드를 작성하는 것이 었습니다.

일단 저의 접근 방법에 대해서 먼저 설명해보지만 별로 중요하지 않습니다.

1. 구현 먼저 🙆 . 섣부른 추상화는 지양 🙅

1) 처음에는 페이지 집중형 (Colocation) 아키텍처 선택했습니다.

src/
├── utils/
│   └── format.ts                        # 전역: 숫자 포맷팅
└── pages/
    └── SavingsCalculatorPage/           # 적금 계산 전용 페이지
        ├── index.tsx                    # export
        ├── SavingsCalculatorPage.tsx    # 메인 페이지
        ├── types.ts                     # 타입 정의
        ├── hooks/
        │   ├── useSavingsFormState.ts    # 입력 상태
        │   ├── useSavingsProductData.ts  # 데이터 조회
        │   ├── useProductSelection.ts    # 상품 선택
        │   ├── useSavingsResult.ts       # 계산 결과
        │   └── useRecommendedProducts.ts # 추천 상품
        └── components/
            ├── SavingsForm.tsx
            ├── ProductList.tsx
            ├── CalculationResult.tsx
            └── RecommendedProducts.tsx

2) 컴포넌트는 컨텐츠와 역할 기준으로 구분했었습니다.

return (
  <>
    <PageHeader title="적금 계산기" />

    {/* 계산 입력 */}
    <section>
      <Spacing size={16} />
      <SavingForm value={inputs} onChange={handleInputChange} />
      <Spacing size={16} />
    </section>

    <Divider borderHeight={16} spacingHeight={8} />

    {/* 사용자 선택 탭 */}
    <Tab onChange={value => setActiveTab(value as 'products' | 'results')}>
      <Tab.Item value="products" selected={activeTab === 'products'}>
        적금 상품
      </Tab.Item>
      <Tab.Item value="results" selected={activeTab === 'results'}>
        계산 결과
      </Tab.Item>
    </Tab>

    {activeTab === 'products' && (
      <ProductList products={products} selectedProductId={selectedProductId} onSelect={handleProductSelect} />
    )}

    {activeTab === 'results' && (
      <>
        {/* 계산 결과 */}
        <CalculationResult />

        <Divider borderHeight={16} spacingHeight={8} />

        {/* 추천 상품 */}
        <RecommendedProducts />
      </>
    )}

    <Spacing size={40} />
  </>
);

3) 훅은 관심사 별 분리하고 반환하는 데이터 흐름을 페이지에서 명시적으로 확인할 수 있도록 수정했습니다.

처음에는 훅은 담당하는 상태 관리 역할 기준으로 관심사를 분리하고, 그 훅들을 한 곳에서 모아두는 훅을 만들어 페이지에서 한번에 반환하도록 하다가... 상태와 그 상태를 업데이트하는 메서드간의 관계를 한번에 파악하기 어렵고 ☠️ 어떤 값이 네트워크 요청의 페이로드로 전달되는지 파악이 어려워서 ☠️ 중앙 집중형 훅을 제거했습니다.

const { inputs, handleInputChange } = useSavingsFormState();
const { products } = useSavingsProductData(inputs); // 🤔 ...
const { selectedProductId, selectedProduct, handleProductSelect } = useProductSelection(products);
const { savingResult } = useSavingsResult(inputs, selectedProduct);
const { recommendedProducts } = useRecommendedProducts(products); // 🤔 ...

2. 구현 끝. 좋아 이제 확장성 챙겨! ☠️

🧐 확장성을 고려하기 위해 리팩토링을 하겠다고 생각하자마자 보인 건 탭이었습니다. 탭 상태 관리와 도메인과는 관계가 없으니 분리해야 될거 같은데?

const [activeTab, setActiveTab] = useState<'products' | 'results'>('products');

{/* 사용자 선택 탭 */}
<Tab onChange={value => setActiveTab(value as 'products' | 'results')}>
  <Tab.Item value="products" selected={activeTab === 'products'}>
    적금 상품
  </Tab.Item>
  <Tab.Item value="results" selected={activeTab === 'results'}>
    계산 결과
  </Tab.Item>
</Tab>

{activeTab === 'products' && (
  <ProductList products={products} selectedProductId={selectedProductId} onSelect={handleProductSelect} />
)}

{activeTab === 'results' && (
  <>
    {/* 계산 결과 */}
    <CalculationResult result={savingResult} />

    <Divider borderHeight={16} spacingHeight={8} />

    {/* 추천 상품 */}
    <RecommendedProducts
      products={recommendedProducts}
      selectedProductId={selectedProductId}
      onSelect={handleProductSelect}
      />
    </>
)}

➡️ 재사용 가능하도록 탭 개수만 확장해서 사용가능하게 하자! Tabs.Panel props로 탭 이름과 식별자를 보내고 보여줄 주 내용은 children으로 전달했습니다.

1개든 2개든 4개든 감당 가능! 이런게 확장성 이겠지? 라고 생각했습니다. 하지만 출제 의도가 아니였습니다.

import { Tabs } from 'components/common';

<Tabs defaultValue="products">
  <Tabs.Panel label="적금 상품" value="products">
    {/* 상품 목록 */}
    <ProductList products={products} selectedProductId={selectedProductId} onSelect={handleProductSelect} />
  </Tabs.Panel>

  <Tabs.Panel label="계산 결과" value="results">
    {/* 계산 결과 */}
    <CalculationResult result={savingResult} />
    <Divider borderHeight={16} spacingHeight={8} />
    {/* 추천 상품 */}
    <RecommendedProducts
      products={recommendedProducts}
      selectedProductId={selectedProductId}
      onSelect={handleProductSelect}
      />
  </Tabs.Panel>
</Tabs>

🧐 api는 공통으로 관리해야겠지? DTO 타입이랑 실제 도메인 타입이랑 계층 분리해야겠지? 그리고 이러쿵 저러쿵 해야겠지? 그리고... 아.. 확장성이라면 해당 도메인 말고 다른 도메인도 있을 텐데 결국 feature 별로 나눠야겠지?

➡️ 최종 디렉토리 구조가 처음과 많이 달라졌습니다.

src/
├── apis/                                # API 레이어
│   ├── savingsApi.ts                    # API 호출
│   └── index.ts
├── types/                               # 타입 레이어 (대칭 구조)
│   ├── apis/
│   │   ├── savingsApiTypes.ts           # API 응답 타입 (DTO)
│   │   └── index.ts
│   └── index.ts
├── utils/                               # 전역 유틸리티
│   └── format.ts                        
├── components/                          # 공통 컴포넌트
│   └── common/
│       ├── Tabs.tsx                     # Compound Component Pattern
│       ├── PageHeader.tsx
│       ├── Divider.tsx
│       └── index.ts
├── pages/                                # 라우팅 진입점 (Top Layer)
│   └── SavingsCalculatorPage.ts          # features/savings를 불러와서 렌더링 (Thin Layer)
│
└── features/                             # (Middle Layer)
    └── savings/                          # 도메인
        ├── types.ts                      # 도메인 모델 타입
        ├── constants.ts                  
        ├── pages/                        # 실제 페이지 관리
        │   └── SavingsCalculatorPage.tsx # 라우팅 진입점 (Hook 조립)
        ├── hooks/                        # [Internal] Hook Composition Pattern
        │   ├── useSavingsFormState.ts    
        │   ├── useSavingsProductData.ts  
        │   ├── useProductSelection.ts    
        │   ├── useSavingsResult.ts       
        │   ├── useRecommendedProducts.ts 
        │   └── index.ts
        └── components/                   # [Internal] UI Components
            ├── SavingsForm.tsx
            ├── ProductList.tsx           # Inversion of Control
            ├── FilteredProducts.tsx
            ├── CalculationResult.tsx
            └── RecommendedProducts.tsx

📍 모의고사 해설 라이브 이후

---

0. 구현 따로, 리팩토링 따로 ? 🤔

저는 구현에 집중한 뒤에 리팩토링을 하는 것으로 단계를 쪼개서 진행하려 했습니다.

물론 물과 기름처럼 리팩토링을 딱 분리해서 하지는 않지만 굳이 단계를 둘로 쪼개서 진행하겠다는 방향 설정은 좋은 전략이 아니였던 것 같습니다.

앞서 말씀드렸다시피 토스에서 얘기한 유지보수를 위한 확장성 있는 설계는 예측 가능하고 읽기 쉬운 코드를 작성하는 것이 주된 포인트였습니다.

나머지 구조나 방법론은 상황에 맞게 선택하는 것이 였고, 모의고사에서 요구한 확장성있는 설계가 과제의 한 페이지를 구현하지만 언젠가 대규모로 확장될 것을 대비해서 설계하란 뜻이 아니였습니다.

글로 쓰고나니 당연한 얘기 같지만 막상 요구사항으로 주어졌을 때는 굉장히 많은 고민이 들게 했었습니다.
출제 의도를 잘 파악하지 못했기 때문이겠죠.

⚠️ 아래 내용의 코드는 정답이 아니며 해설 라이브 내용을 들은 뒤에 제 코드를 기반으로 작성해 본 것 뿐입니다.

1. 요구사항 문서를 보고 '이상적인 인터페이스' 설계 먼저

가장 먼저 이상적인 인터페이스를 설계하자!
의사 코드를 작성하는 것과 같았습니다.

한 페이지를 기준으로 제가 생각하는 이상적인 인터페이스를 설계해 보겠습니다.

export default function SavingsCalculatorPage() {

  return (
    <main>
      <h1>적금 계산기</h1>

      <section>
        <h2 className="sr-only">적금 계산을 위한 설정</h2>
        <SavingsForm inputs={inputs} onChange={handleFormStates} />
      </section>
      
      <Divider />
      
      <Tabs>
        <Tab.Panel>
          <section>
            <h2>적금 상품</h2>
            <SavingsProductList {...props} />
          </section>
        </Tab.Panel>
        
        <Tab.Panel>
          <section>
            <h2>계산 결과</h2>
            <CalculationResult selected={selected} inputs={inputs} />
          </section>
          
          <Divider />
          
          <section>
            <h2>추천 상품 목록</h2>
            <RecommendProductList {...props} />
          </section>
        </Tab.Panel>
      </Tabs>        
    </main>
  );
}

제가 라이브 해설을 듣기 전이라면 페이지의 개요와 전체적인 UI 구조가 한번에 파악이 되는 이 간결한 코드가 꽤 마음에 들어 했을 것 같습니다.

하지만 SavingsForm 컴포넌트는 사용자에게 어떤 입력 값들을 필요로 하는지 전혀 예측할 수 없습니다. 각 섹션마다 엄청 많은 컴포넌트가 있다면 모르겠지만 가독성을 해칠만큼 컴포넌트가 많지 않습니다.

그리고 컴포넌트마다 데이터의 흐름이 연결되어 있기 때문에 굳이 숨기지 않는 것이 좋겠습니다.

<form onSubmit={e => e.preventDefault()}>
  <Input
    label="목표 금액" 
    placeholder="목표 금액을 입력하세요" 
    value={value.목표금액} 
    onChange={handleFormStates} 
    />
  <Input 
    label="월 납입액" 
    placeholder="희망 월 납입액을 입력하세요" 
    value={value.월납입액} 
    onChange={handleFormStates} 
    />
  <Select label="저축 기간" value={12} onChange={handleFormStates}>
    <Option>6</Option>
    <Option>12</Option>
    <Option>24</Option>
  </Select>
</form>

주어진 코드에서 사용자의 입력이 필요한 부분에 초기 코드는 목표 금액과 월 납입액을 입력하는 TextInput 컴포넌트 2개와 개월 수 옵션을 선택하는 SelectBottomSheet 1개만 있었습니다.

// 수정 전 코드들

<NavigationBar title="적금 계산기" />

<Spacing size={16} />

<TextField label="목표 금액" placeholder="목표 금액을 입력하세요" suffix="원" />
<Spacing size={16} />
<TextField label="월 납입액" placeholder="희망 월 납입액을 입력하세요" suffix="원" />
<Spacing size={16} />
<SelectBottomSheet label="저축 기간" title="저축 기간을 선택해주세요" value={12} onChange={() => {}}>
  <SelectBottomSheet.Option value={6}>6개월</SelectBottomSheet.Option>
  <SelectBottomSheet.Option value={12}>12개월</SelectBottomSheet.Option>
  <SelectBottomSheet.Option value={24}>24개월</SelectBottomSheet.Option>
</SelectBottomSheet>

<Spacing size={24} />

// ... 생략

바로 form 요소나 onSubmit 을 사용하지 않았고 입력 시에 바로 입력값에 의해 상품 목록이 필터링 되기 때문에 굳이 form 요소를 사용할 필요는 없어 보입니다.
하지만 저는 여러 개의 사용자의 입력을 받아야 한다면 form 요소로 그룹화 하는 것이 HTML5 표준이라고 생각하기 때문에 사용했습니다.

가장 먼저 이상적인 인터페이스를 설계하는 것을 추천하셨고 저는 제 기준 이상적인 인터페이스를 설계하는 중 입니다.

주어진 SelectBottomSheet 컴포넌트 경우 옵션을 선택하는 데 BottomSheet를 사용하는 것은 그렇게 중요하지 않다고 합니다.

내부 구성 요소는 select 요소로 바뀔 수도 있고 UI 형태가 모달 로 바뀔 수도 있습니다.

기본적으로 HTML에서 제공하는 기본 인터페이스를 기준으로 일반적인 상황에서 모두가 예측 가능한 코드를 작성하는 것을 추천하셨고, 특히 창의력을 발휘하지 말자! 이 한마디가 마음 속 깊이 박혔습니다.

라이브를 들으면서 UI 또는 내부 구조가 바뀔지 모르는 상황에서 본질에 집중해 수정에 유연한 인터페이스를 만드는 초석이구나 라고 생각했습니다.

이렇게 제 기준 이상적인 인터페이스를 설계해봤습니다.

export default function SavingsCalculatorPage() {

  return (
    <main>
      <h1>적금 계산기&</h1>
      
      <section>
        <h2 className="sr-only">적금 계산을 위한 설정</h2>
        
        <form onSubmit={e => e.preventDefault()}>
          <Input 
            label="목표 금액" 
            placeholder="목표 금액을 입력하세요" 
            value={value.목표금액} 
            onChange={handleFormStates} 
          />
          <Input 
            label="월 납입액" 
            placeholder="희망 월 납입액을 입력하세요" 
            value={value.월납입액} 
            onChange={handleFormStates} 
          />
          <Select label="저축 기간" value={12} onChange={handleFormStates}>
            <Option>6</Option>
            <Option>12</Option>
            <Option>24</Option>
          </Select>
        </form>
      </section>
      
      <Divider />
      
      <Tabs>
        <Tab.Panel>
          <section>
            <h2>적금 상품</h2>
            <SavingsProductList {...props} />
          </section>
        </Tab.Panel>
        
        <Tab.Panel>
          <section>
            <h2>계산 결과</h2>
            <CalculationResult selected={selected} inputs={inputs} />
          </section>
          
          <Divider />
          
          <section>
            <h2>추천 상품 목록</h2>
            <RecommendProductList {...props} />
          </section>
        </Tab.Panel>
      </Tabs>        
    </main>
  );
}

⚠️ 이 글에 작성한 코드는 토스 모의고사 해설 라이브에서 제시한 정답이 아니며, 들었던 내용을 복기하면서 제 기준에서 작성해 본 코드입니다.

2. UI 형태와 코드 형태가 1:1 매핑되면 유지보수가 쉽다

이상적이라고 생각한 인터페이스 설계를 하나씩 제공해준 컴포넌트로 적용해 봅니다.

<NavigationBar title="적금 계산기" />
<Spacing size={16} />

<TextField 
  label="목표 금액" 
  placeholder="목표 금액을 입력하세요" 
  suffix="원"
/>

<Spacing size={16} />

<TextField 
  label="월 납입액" 
  placeholder="희망 월 납입액을 입력하세요" 
  suffix="원" 
/>

<Spacing size={16} />

<SelectBottomSheet 
  label="저축 기간" 
  title="저축 기간을 선택해주세요" 
  value={12} 
  onChange={() => {}}
>
  <SelectBottomSheet.Option value={6}>6개월</SelectBottomSheet.Option>
  <SelectBottomSheet.Option value={12}>12개월</SelectBottomSheet.Option>
  <SelectBottomSheet.Option value={24}>24개월</SelectBottomSheet.Option>
</SelectBottomSheet>
<Spacing size={24} />

위의 주어진 코드를 적용하면

<PageHeader title="적금 계산기" />
      
<section>
  <Spacing size={16} />
  <h2 className="sr-only">적금 계산을 위한 설정</h2>
  
   <form onSubmit={(e: React.FormEvent<HTMLFormElement>) => e.preventDefault()}>
    <TextField 
      label="목표 금액" 
      placeholder="목표 금액을 입력하세요" 
      value={value.목표금액}
      suffix="원"
      onChange={handleFormStates} 
      />

    <Spacing size={16} />

    <Input 
      label="월 납입액" 
      placeholder="희망 월 납입액을 입력하세요" 
      value={value.월납입액}
      suffix="원"
      onChange={handleFormStates} 
      />

    <Spacing size={16} />

    <SelectBottomSheet 
      label="저축 기간" 
      title="저축 기간을 선택해주세요" 
      value={12} 
      onChange={handleFormStates}
    >
      <SelectBottomSheet.Option value={6}>6개월</SelectBottomSheet.Option>
      <SelectBottomSheet.Option value={12}>12개월</SelectBottomSheet.Option>
      <SelectBottomSheet.Option value={24}>24개월</SelectBottomSheet.Option>
    </SelectBottomSheet>
  </form>
  
  <Spacing size={24} />
</section>

시멘틱 요소를 사용하거나 상태 관리를 위한 props가 추가한 것 외엔 딱히 원래 주어진 코드와 별 차이가 없어 보입니다.

만약 제가 처음에 생각했던 대로 별도의 Form 컴포넌트를 생성해서 분리한다면 더 나을까요?

<PageHeader title="적금 계산기" />
      
<section>
  <h2 className="sr-only">적금 계산을 위한 설정</h2>
  
  <Spacing size={16} />
  
  <SavingsForm inputs={inputs} onChange={handleFormStates} />
  
  <Spacing size={24} />
</section>

보이는 화면의 코드 수는 줄어들어 깔끔해 보이지만 실제 코드 수는 그대로입니다.

이런 상황을 "추상화가 아닌 추출" 이라고 합니다. 정확한 예시로는 몬스터 훅(하나의 훅에 모든 비즈니스 로직을 몰빵한 훅)을 사용한 안티 패턴의 예시에서 언급하셨습니다.

이 글(좋은 코드란 무엇일까 🧚)을 읽어 보시면 추출과 추상화 차이에 대해 자세히 알 수 있습니다.

그리고 아까 언급했듯이 어떤 사용자의 입력을 받는지 바로 예측이 어렵기 때문에 가독성을 오히려 해치게 됩니다.

💭 하지만 너무 많은 컴포넌트를 포함하고 있는 경우는? 복잡하고 많은 UI 로직과 컴포넌트들 한 페이지에 모두 보여주게 되면 더 읽기 어려운 코드가 되는 것이 아닐까?

실제로 비슷한 내용의 질문을 누군가 하셨는 데 답변으로 축척에 맞춰서 설계하라고 하신 게 기억에 남습니다.
축척(縮尺)은 지도를 만들 때 실제 거리를 얼마나 줄여서 표현하는지를 나타내는 비율입니다.

비유로 페이지가 세계지도라면 한국, 일본 등 나라를 파악할 수 있는 레벨의 컴포넌트들로 구성되어 있는데 갑자기 강남구, 테헤란로 142 컴포넌트가 나오면 안된다고 하셨던 거 같아요. (비슷하게 말씀하신 거 같은데 정확한 표현은 틀릴 수 있습니다. 😅)

지금 모의고사의 경우는 나라는 커녕 몇 동, 몇 호 또는 누구 사물함 위치 정도의 레벨인 거 같습니다.

그리고 좀 더 많은 내용을 정리하고 싶지만 리팩토링 할 수 있는 기간이 생겨서 그 이후에 이 포스트에 추가로 업데이트 하겠습니다.

3. 재사용은 따라오는 것. 책임 단위로 추상화를 할 뿐 🙏

이 내용도 인상 깊었습니다. 라이브 마지막 쯤 "재사용할 거 같으니 따로 뺄까요?" 라는 류의 말을 언급 안한 이유에 대해 설명하셨는데요.

책임 단위로 추상화를 하면 재사용은 따라온다. 이 한 문장으로 정리했습니다.

저는 구현 당시 프로젝트 구조에 대해 고민하느라 많은 시간을 소비했습니다.

한 페이지만 구현하는 분량에서 얼마나 재사용을 고려해서 설계를 해야할지 제 상상이나 기존 경험에 의존해야 했기 때문입니다. 하지만 제 경험이 기준이 될 수 있는 지도 확신이 없었기 떄문에 처음에는 해당 페이지 하위에서 최대한 가까운 구조를 가져 갔었고 확장성 위한 설계를 언젠가 대규모를 대비한 설계로 오인하여 FSD에 가까운 구조로 변경하게 됐습니다. 실제로 해당 페이지말곤 재사용하지 않는 자원들을 shared 위치로 설정하면서 말이죠.

📍 회고

라이브를 통해 들었던 모든 내용을 정리하고 싶었지만 자세한 내용은 리팩토링을 진행하면서 정리할 수 있을 거 같습니다.

토스 기술 과제의 해설을 들을 수 있는 아주 특별한 경험을 하게 돼서 좋은 시간이었고 너무나 유익했습니다. 확장성, 추상화 사실 쉽지 않았기에 실제로 구현 시 토스는 어떤 관점으로, 어떻게 추상화 하는지 자세히 알 수 있어 많은 도움이 된 시간이었습니다. 감사합니다!

📍 같이 보면 좋은 자료 🧚

• 토스ㅣSLASH 22 - Effective Component 지속 가능한 성장과 컴포넌트
• Frontend Fundamentals - 좋은 코드를 위한 4가지 기준
• 좋은 코드란 무엇일까

📍 (추가) 리팩토링한 내용

• https://github.com/toss-fe-interview/frontend-fundamentals-mock-exam-1/pull/73