🎓 [토스 Frontend Fundamentals 모의고사 2회 후기] 예측가능한 코드

📍 소감

이번 토스 모의고사 2회차에 참여하면서 유지보수와 확장성있는 설계를 위해 예측가능한 코드를 작성하는 기준, 적절한 추상화 수준으로 조정하는 법에 대해서 정리할 수 있었습니다.

그리고 구현이든, 리팩토링이든 이상적인 인터페이스를 설계하는 것이 가장 중요하고 선행 되어야하는 점을 느꼈습니다.

📍 2회차 모의고사 과제 내용

과제 설명

“회의실 예약” 화면을 구현해주세요. 날짜를 선택해 회의실 예약 현황을 확인하고, 원하는 시간/인원/장비 조건으로 예약을 시도합니다.

꼭 신경써주세요 ☝️

서비스의 유지보수나 장기적인 확장성을 고려한 설계, 추상화 관점에 집중해서 기능을 구현해주세요.

📍 나의 접근

이전 1회차와 다른 점은 처음부터 구현하는 것이 아닌 이미 구현되어 있는 레거시 코드를 개선해야 하는 것 입니다.

1회차와 동일한 점은 유지보수와 장기적인 확장성을 고려한 설계와 추상화를 고려해야 했습니다.

처음에는 이 확장성을 고려한 설계에 대해 기준을 정의하는데 아주 많은 시간을 들였고 확실한 기준이 없었지만 토스 모의고사 1회차에 배운 것을 가지고 명확하게 정의할 수 있었습니다.

1. 확장성을 고려한 설계와 추상화의 기준 정리

읽기 쉬운 코드

• 화면 페이지의 UI와 코드가 1:1 대칭이 되어야한다.
• 텍스트는 이정표 역할을 해주어야 하므로 페이지 컴포넌트 단위에서 드러내야 한다.
• 재사용되는 리스트 UI의 인터페이스는 필터링이나 정렬 조건은 순수함수 활용해 드러내고 책임을 분리한다.

코드의 응집도를 높이되 의존성 역전으로 컴포넌트의 레벨을 조정

• 관련된 것은 모아 코드의 응집도를 높이자
• 컴포넌트 컴파운드 패턴 활용해 페이지 컴포넌트에서 바로 UI 구성을 알 수 있게 하자.
• 재사용은 따라 오는 것 미리 빼거나 추상화 하지 않는다.

2. 지저분한 코드를 읽어서 하나 하나 판단할 바엔 AI를 잘 학습 시키자

• 이상적인 인터페이스를 먼저 설계해야 하지만 이미 구현되어 있는 코드... 🤔
• 개인적으로 충분하지 않은 시간을 확보한 상황에서 어떤 전략을 취할지 고민
• 1회차 모의고사에서 후기 작성한 나의 블로그 글과 추천하신 글, 유튜브 영상 내용을 AI한테 학습하여 문서 작성 → 반복적으로 검토, 검증

📍 해설 라이브를 통해 배운 점

라이브는 총 2부로 진행됐고 1부는 재엽님께서 인터페이스, 모듈 책임, 조합에 대해 설명하셨고 동욱님은 예측하기 좋은 코드와 질의 응답 위주로 진행했습니다.

1. 어김없이 이상적인 인터페이스를 먼저 설계하자

토스 모의고사 1회차를 통해 유지보수가 쉽고 확장가능한 설계의 핵심은 '예측 가능하고 읽기 쉬운 코드를 작성하는 것'이라는 것을 이해하고 이것을 가능하게 하는 방법에 대해 정리했었습니다.

1. 요구사항 문서를 보고 '이상적인 인터페이스' 설계 먼저
2. UI 형태와 코드 형태가 1:1 맵핑되면 유지보수가 쉽다
3. 재사용은 따라오는 것. 책임 단위로 추상화를 할 뿐

👉 토스 모의고사 1회 핵심 내용 정리

이번에는 처음부터 구현이 아닌 리팩토링이기 때문에 이상적인 인터페이스의 기준을 문서로 정리해서 AI한테 학습시키는 것이 효율적일 것이라고 판단했지만 제가 원하는 결과물이 나오지 않았습니다.

라이브 해설에서 재엽님이 기존 코드를 무시하고 새롭게 이상적인 인터페이스를 의사코드로 작성하신 뒤에 AI 한테 전달하는 모습을 보고 ... 나는 왜 이 생각을 못했지...? 😱 저의 좁은 식견에 한탄했습니다.

제가 생각하는 이상적인 인터페이스를 설계하는 과정은 하단에 위치한 리팩토링 과정에 작성했습니다.

2. 예측하기 쉬운 코드는 왜 중요할까?

추상화를 할 때 창의력을 발휘하지마라 라는 말을 토스 모의고사 1회차 때 들은 기억이 납니다.
예측하기 쉬운 코드를 작성해야하는 맥락이랑 같습니다.

창의력을 발휘하지 말라는 의미는 일반적인 표현, 누구나 알고 있는 인터페이스나 형태에 가깝게 표현하라는 의미입니다.

컴포넌트명을 네이티브 HTML 요소 이름과 비슷하게, props 명을 그 요소의 속성과 가깝게 표현하면 각 전달되는 값들이 어떤 역할로 UI에 표현될 수 있는지 자연스럽게 예측할 수 있습니다.

예측하기 어려운 코드 예시

<DateSelect 
  date={date} 
  setDate={setDate} 
  minDate={minDate} 
/>

컴포넌트 이름을 보면 '날짜를 선택하는 컴포넌트' 임을 예상할 수 있습니다.

컴포넌트 이름에 Select가 들어가 있습니다.

Date 데이터는 서버에서 제공하는 특정 날짜에 대한 정보들 일수도 있고 단순히 Data 객체나 input 요소의 date 타입을 이용해 클라이언트에서 정의할 수 있는 데이터 일수도 있습니다.

선택하는 기능의 UI를 구현하는 방법도 많습니다. HTML의 select 요소 처럼 드롭다운 형태거나 radio, checkbox 형태일 수도 있고, BottomSheet 형태가 될 수 있습니다.

디자인 요구 사항에 따라 얼마든지 달라질 수 있을 거 같습니다. 내부 구현을 어떻게 할지 예측하게끔 표현하는 것은 코드를 수정하는 관점에서 봤을 때 매칭되게 사용할 필요는 없을 거 같습니다. 오히려 수정 범위가 늘어 날지도 모릅니다.

하지만 props 명과 값의 이름이 동일해서 전달되는 값이 어떻게 쓰일지 예측하기 어렵습니다.

const [date, setDate] = useState();

코드가 길지 않고 컴포넌트와 useState가 선언된 위치가 가깝다면 date는 클라이언트에서 관리하고 있는 상태 값이고 setDate 는 업데이트 함수를 props로 전달하고 있으니 상태 끌어올리기로 date가 다른 컴포넌트에 공유되고 있는 값이라고 예측할 수 있겠지만 상태가 업데이트 되는 트리거가 무엇인지는 예측하기 어렵습니다.

그리고 상황에 따라 코드 위치가 멀어진다면 DateSelect 컴포넌트의 props에 전달되는 값과 맥락을 읽기 위해 추적하고 맥락을 기억하고 있어야합니다.

사람의 뇌는 중요하다고 여기지 않은 것은 거의 스킵하거나 저장하지 않기 때문에 모든 맥락과 변수이름을 외우기 어렵습니다.

그렇기 때문에 예측 가능한 코드가 읽히기 쉽습니다.

예측하기 쉬운 코드 예시

<DatePicker 
  value={selectedDate} 
  onChange={setSelectedDate} 
  min={formatDate(new Date())} 
/>

DatePicker 는 Native HTML 요소는 아니지만 표준에 차용될 만큼 자주 사용했던 제이쿼리 라이브러리의 날짜를 선택하는 용도의 위젯 이름입니다. 날짜를 선택하는 라이브러리의 이름은 대부분 DatePicker를 많이 씁니다.

이 DatePicker의 내부 구현도 value와 onChange, min 속성 이름들로 내부 구현을 들여다 보지 않아도 어느정도 예상할 수 있습니다.

<input
  type="date"
  value={value}
  min={min}
  onChange={(e) => onChange(e.target.value)}
/>

그리고 날짜 캘린더를 선택하는 역할의 인터페이스는 거의 고정적으로 쓰여서 내부 구현의 수정으로 인터페이스나 컴포넌트명이 수정될 고려사항도 거의 없어보입니다.

3. 적절한 추상화 수준

화면 UI 구성과 페이지 컴포넌트 내 코드들이 1:1 대응이 되는 것이 좋지만 얼마나 표현해줘야 할지 고민이 드는 순간들이 있습니다.

원하는 층의 예약할 수 있는 회의실을 찾기 위해 층을 선택해야하는 Select를 구현해봅니다.

<FloorSelect>
  <FloorSelect.Option>1</FloorSelect.Option>
  <FloorSelect.Option>2</FloorSelect.Option>
  <FloorSelect.Option>3</FloorSelect.Option>
  <FloorSelect.Option>4</FloorSelect.Option>
</FloorSelect>

실제 선택가능한 옵션이 2~4개가 아닌 10개 이상이 되고 여러곳에서 사용된다면 사용하기 불편하고 코드만 길어집니다. 게다가 서버 데이터를 받아서 표현해야할 경우도 있습니다. 맵핑하는 구현부를 보여줄 필요가 없게 됩니다.

라이브 해설에서 페이지 컴포넌트에서 굳이 알지 않아도 되는 정보를 표현할 때 "코드가 배 밖으로 나왔다", "내장이 쏟아졌다" 라고 재밌게 표현하셨는데 지금 생각해도 웃음이 납니다. 🤣

말자체도 웃기지만 사실 제가 1회차 때 후기로 이상적인 인터페이스로 이렇게 표현했습니다. 그때 클라이언트에서 정의하고 3개밖에 없어서 1:1로 보여줘야한다는 말에 매몰돼서 그렇게 정의했었던 기억이 나네요. 😂

4. 컴파운드 컴포넌트 패턴의 오남용

컴파운드 컴포넌트 패턴을 잘 못 사용하면 오히려 코드가 복잡해질 수 있습니다.

이 경우는 네임스페이스 관점에서만 접근해서 적절한 추상화를 하지 않고 모든 책임을 한 모듈안에 몰빵해서 생기는 문제입니다.

컴파운드 컴포넌트 패턴을 오남용할 경우, 재사용하는 곳이 많아질 경우 매번 조립해서 사용해야하는 불편함과 사용처에서 내부 구현부의 맥락을 읽어야하는 상황이 생길 수 있습니다. 내부에서 children props로 context를 공유하는 경우 파악하기 더 어려워집니다.

잘 사용한 예시

<FilterPanel.Loading>
  
<FilterPanel.Error>

오남용 예시

<BookingFilter onFilterChange={handleFilterChange}>
  <BookingFilter.Title>예약 조건</BookingFilter.Title>

  <BookingFilter.DateInput label="날짜" />

  <BookingFilter.TimeRange startLabel="시작 시간" endLabel="종료 시간" />

  <div css={css`display: flex; gap: 12px;`}>
    <BookingFilter.Attendees label="참석 인원" />
    <BookingFilter.FloorSelect label="선호 층" />
  </div>

  <BookingFilter.Equipment label="필요 장비" />

  <BookingFilter.ValidationError />
</BookingFilter>

5. 논리적으로, 비판적으로 사고하는 것이 중요한 이유 (feat. AI)

AI의 발전으로 생산성이 늘었다고 말하지만, 생산성의 정의는 무엇인가요? 생산성의 정의가 되어 있지 않은데 어떻게 늘었다고 말 할 수 있나요? 라는 동욱님의 말씀을 들은 순간 머리가 띵해졌습니다.

과제에 관련된 코드 리뷰나 리팩토링할 관점에 대해서 다른 분들과 얘기를 나누다가 이 부분에 대해서도 관점을 나눴습니다. 실제로 AI 덕분에 구현은 빨리 끝나서 PR은 몇 십개가 쌓이지만 아직도 모든 인원이 코드리뷰를 해야하는 규칙 때문에 쌓여져있는 PR을 처리하지 못하고 있다는 사례를 들었습니다.

AI를 통해 구현에 대한 생산성은 늘었다고는 분명하게 말할 수 있겠습니다만.. 제품에 대한 생산성이 늘었는지는 아직 잘 모르겠습니다.

제품의 완성 기준에 따라 다를 수도 있지만 배포를 한 이후에 기존 레거시 코드를 AI가 명확하게 서술하지 않은 문서 파일로 인해 마음대로 바꿔버려서 사전에 사람이 찾아내지 못해 승인했다면 이슈를 급하게 처리해야하는 비용이 들것이고 이런 상황을 차단하기 위해서 겹겹이 사람이 QA를 진행한다면 마찬가지로 병목이 여전히 생길 것 입니다.

전체 제품 생산의 파이프라인 과정마다 구현만큼 AI가 투입되어서 병목을 해결할 수 있다고 해도 아직까지 믿을 수 없다면 전체 생산성은 똑같지 않을까요?

📍 리팩토링 과정

1. 이상적인 인터페이스 설계하기

다시 처음부터 과제에 접근한다는 마음으로 제가 생각하는 페이지 화면과 코드가 1:1 대응된 이상적인 인터페이스를 설계해 봤습니다.

⚠️ 아래 내용과 기준은 제 생각일 뿐 라이브에서 제시한 해답이 아닙니다.

// 예약 현황 페이지

<h1>회의실 예약</h1>

<section>
  <h2>날짜 선택</h2>
  
  <DatePicker value={선택한날짜} onChange={선택한날짜_업데이트함수} min={오늘날짜}  />
</section>

<section>
  <h2>예약 현황</h2>	
  
  <Suspense fallback={<Timeline.Loading />}>
    <Timeline date={선택한날짜} />
  </Suspense>
</section>

<section>
  <h2>내 예약</h2>
  
  <Suspense fallback={<MyReservations.Loading />}>
    <MyReservations />
  </Suspense>
</section>

<CtaButton>예약하기</CtaButton>

저번에 리팩토링을 하면서 개선했던 것이 떠올라 data fetch 때문에 suspense를 사용하는 것을 상정하고 인터페이스를 설계했습니다.

(에러 바운더리는 suspense 기준으로 감싸면되니 설계 단계에서는 무시합니다.)

예약 현황의 Timeline의 컴포넌트와 내 예약의 MyReservations 컴포넌트가 추출과 다름없을 정도로 숨겨지게 되었습니다.

읽기 쉽고 예측가능한 코드를 위해 화면 UI와 코드를 1:1 대응하도록 설계했다고 하기 좀 무색해 보입니다.

Timeline의 경우

  <h2>예약 현황</h2>	
  
  <Suspense fallback={<Timeline.Loading />}>
    <Timeline date={선택한날짜} />
  </Suspense>

이 Timeline의 컴포넌트를 보고 어떤 것을 기대할 수 있을까요?

사용자가 선택한 날짜 데이터를 받고 회의실 예약 내역을 조회하는 것, 그 UI의 형태가 타임라인인 것을 코드를 위에서 부터 읽어온 맥락으로 유추해 볼 수 있을 거 같습니다.

이 정도 수준은 추상화일까 추출일까 고민이 되지만 좀 더 UI 화면과 1:1 대응이 되는 정보를 보여주면 더 친절할 거 같습니다.

회의실과 시간대 등 기준이 드러나면 좋겠다고 생각했지만 서버로 부터 받아온 data를 활용하기에 밖에서 전달하려면 suspense를 걷어내야 합니다.

MyReservations의 경우

<h2>내 예약</h2>

<Suspense fallback={<MyReservations.Loading />}>
  <MyReservations />
</Suspense>

마찬가지로 이 MyReservations 컴포넌트를 보고 어떤 것을 기대할 수 있을까요?

내 예약 텍스트와 Suspense로 감싸져 있는 것을 보니 내가 예약한 회의실 예약 건들을 조회해 줄 것 같습니다.

그 이상의 정보는 타고 들어가봐야 알 수 있습니다.

리스트의 구조라던가 내가 예약한 데이터이기 때문에 인터랙션을 통해 변경 가능성도 있을 수 있겠지만 지금 코드로는 전혀 예측할 수 없습니다.

토스 모의고사 1회차 때는 어떻게 했더라?

1회차의 경우 동일한 UI의 리스트가 재사용되어서 filter와 sort 등의 조건을 순수함수로 props로 전달해 차별되는 정보와 기준을 드러나게 했지만 여전히 리스트의 UI 구조는 알 수 없었습니다.

<section>
  <h2>적금 상품 목록</h2>

  <ErrorBoundary
    onReset={reset}
    fallbackRender={({ resetErrorBoundary }) => (
      <ProductList.Error message="추천 상품을 불러오는 데 실패했습니다." onRetry={resetErrorBoundary} />
    )}
    >
    <Suspense fallback={<ProductList.Loading text={'상품을 불러오는 중...'} />}>
      <ProductList
        filters={[
          product => filterByMonthlyAmount(product, savingsStates.monthlyAmount),
          product => filterByTerm(product, savingsStates.term),
        ]}
        fallback={'조건에 맞는 상품이 없습니다.'}
        />
    </Suspense>
  </ErrorBoundary>
</section>

<section>
  <h2>추천 상품 목록</h2>
  
  <ErrorBoundary
    onReset={reset}
    fallbackRender={({ resetErrorBoundary }) => (
      <ProductList.Error message="추천 상품을 불러오는 데 실패했습니다." onRetry={resetErrorBoundary} />
    )}
    >
    <Suspense fallback={<ProductList.Loading text={'추천 상품을 불러오는 중...'} />}>
      <ProductList
        filters={[
          product => filterByMonthlyAmount(product, savingsStates.monthlyAmount),
          product => filterByTerm(product, savingsStates.term),
        ]}
        sortBy={sortByAnnualRateDesc}
        limit={2}
        fallback={'추천 상품이 없습니다.'}
        />
    </Suspense>
  </ErrorBoundary>
</section>

하지만 꼭 화면의 코드와 UI의 내용이 1:1 대응되도록 자세히 표현할 필요는 느끼지 않았습니다.

<ProductList
  filters={[
    product => filterByMonthlyAmount(product, savingsStates.monthlyAmount),
    product => filterByTerm(product, savingsStates.term),
  ]}
  sortBy={sortByAnnualRateDesc}
  limit={2}
  fallback={'추천 상품이 없습니다.'}
/>

읽기 전용의 필터 조건에 해당되는 내역을 조회하고 다른 곳에서 재사용 될 때 filter, sort, limit 조건을 props로 열어서 필요한 수준의 정보를 드러내고 적절한 수준으로 추상화를 했기 때문입니다.

2회차의 경우 예약 현황 페이지의 내 예약 리스트와 다른 페이지인 예약하기 페이지에서 예약 가능한 리스트 는 내 예약의 경우에만 취소 버튼이 있기도 하고 디자인이 다릅니다. 하지만 묘하게 닮은 부분이 있습니다.

추상화 수준을 어떻게 잡으면 좋을까요?

2. 이상적인 인터페이스는 성공 케이스에 대해서만 다룬다!

재엽님께서 말씀하신 성공 케이스에서만 다루는 것에 관점을 맞춰서 로딩 상태를 고려한 suspense를 무시해 봤습니다.

⚠️ 아래 코드는 라이브에서 제시한 해답이 아닙니다. 라이브 이후 제가 생각하는 이상적인 인터페이스의 기준입니다.

// 예약 현황 페이지

<h1>회의실 예약</h1>

<section>
  <h2>날짜 선택</h2>
  
  <DatePicker 
    value={선택한날짜} 
    onChange={선택한날짜_업데이트함수} 
    min={오늘날짜}
  />
</section>

<section>
  <h2>예약 현황</h2>
  
  <Timeline 
    selected={선택한날짜} 
    rowField={시간대} 
    colField={회의실이름} 
  />
</section>

<section>
  <h2>내 예약</h2>
  
  <ul>
    {reservations.map((reservation) => (
      <li key={reservation.id}>
        <Card 
          top={reservation.회의실이름} 
          bottom={reservation.회의실스펙} 
          right={<Card.CancelButton />} 
         />
      </li>
    ))}
  </ul>
</section>

<CtaButton>예약하기</CtaButton>

Timeline의 경우

<Timeline 
  selected={선택한날짜} 
  rowField={시간대} 
  colField={회의실이름} 
/>

• 타임라인 UI의 행과 열에 해당하는 데이터가 무엇인지 알 수 있습니다.
• 컴포넌트 내부에서 회의실이라는 도메인과 분리되고 데이터를 주입받게 되면서 Timeline 컴포넌트의 재사용이 가능한 수준이 됐습니다.

MyReservations의 경우

<ul>
  {reservations.map((reservation) => (
    <li key={reservation.id}>
      <Card 
        top={reservation.회의실이름} 
        bottom={reservation.회의실스펙} 
        right={<Card.CancelButton />} 
        />
    </li>
  ))}
</ul>

• 리스트의 UI 구조와 예약 취소 기능을 예측할 수 있습니다.
• Card 컴포넌트의 UI는 어떻게 주입할 수 있을지는 리팩토링하면서 더 고민해봐야할 거 같습니다.

3. 이상적인 인터페이스를 구현하기 위한 선택

suspense와 에러 바운더리를 사용하려면 결국 query 결과를 반환하는 컴포넌트를 감싸야하는데 어떻게 제가 생각하는 이상적인 인터페이스 기준으로 페이지 컴포넌트 코드 레벨에서 드러나게 할 수 있을까요?

suspensive 라이브러리를 선택한 이유

Suspensive 라이브러리는 기존 React와 다른 서버 상태 관리 및 전역 상태 관리 도구들로부터 해결할 수 없던 문제들을 해결하기 위해 나온 라이브러리 입니다.

React의 Suspense는 자식 컴포넌트가 던지는 Promise 객체를 catch하는 형태로서 동작하기 때문에 query와 suspense를 동일한 코드 레벨에 위치하기 어렵습니다.

제가 생각하는 이상적인 인터페이스 설계에서 query의 결과 값을 사용하는 컴포넌트 구조가 드러나길 원했기 때문에 Suspensive 라이브러리가 제공하는 SuspenseQuery API를 사용했습니다.

// https://suspensive.org/ko/docs/react-query/SuspenseQuery
// 공식문서의 코드 중 일부 발췌

<Suspense fallback={'loading...'}>
  <SuspenseQuery {...userQueryOptions(userId)}>
    {({ data: user }) => <UserProfile key={user.id} {...user} />}
  </SuspenseQuery>
</Suspense>

SuspenseQuery가 문제를 해결하는 방법

Suspensive 라이브러리에서 제공하는 Suspense는 자식 컴포넌트로 SuspenseQuery를 사용할 수 있습니다.

SuspenseQuery 컴포넌트 내부에서 render props 패턴으로 외부에서 전달받은 queryOptions를 가지고 useSuspenseQuery를 실행합니다.

 import { SuspenseQuery } from '@suspensive/react-query'

 // You can use QueryOptions as props.
 <SuspenseQuery {...queryOptions()}>
   {({ data, isLoading }) => {
     return <></>
   }
 </SuspenseQuery>

SuspenseQuery 컴포넌트의 children은 jsx로 반환되는 컴포넌트가 아닌 함수의 형태로 받기 때문에 children prop으로 전달된 함수의 인자로 useSuspenseQuery 결과 값을 받아 컴포넌트가 반환되어 렌더링합니다.

export const SuspenseQuery = <
  TQueryFnData = unknown,
  TError = unknown,
  TData = TQueryFnData,
  TQueryKey extends QueryKey = QueryKey,
>({
  children,
  ...options
}: UseSuspenseQueryOptions<TQueryFnData, TError, TData, TQueryKey> & {
  children: (queryResult: UseSuspenseQueryResult<TData, TError>) => ReactNode
}) => <>{children(useSuspenseQuery(options))}</>

이렇게 니즈를 바로 충족시킬 수 있는 적절한 라이브러리가 있었다니 !!

바로 토스에서 만들었습니다. 👏👏

조금 더 빨리 알게 됐으면 좋았을 텐데 이번에 제대로 알게 돼서 잘 사용할 수 있을 거 같습니다.

📍 마치며

이번에도 모의고사에 참여하길 정말 잘했다고 느꼈습니다. 도움주신 종택님, 재엽님, 동욱님 감사합니다! 🙇‍♀️

아쉬운 점은 시간을 많이 투자하지 못했고 조급하게 접근해서 고민을 깊게 하지 못한 점들이 많이 아쉬웠습니다.

라이브 이후에 회고를 갖는 시간을 두 차례 겪으면서 고려할 사항들과 해결 방안들을 비교해 보면서 더 많이 얻어갔습니다.

앞으로 리팩토링을 진행하면서 나오는 고민 포인트와 선택, 그 이유에 대해서도 내용 추가해보겠습니다. 감사합니다!