토스 Frontend Fundamentals 모의고사 2회 후기

이번 과제는 이미 동작하고 있는 회의실 예약 서비스를 리팩토링하는 문제였다. 새로운 기능을 추가하는 것이 아니라, 기존 코드를 더 읽기 쉬운 구조로 바꾸는 것이 핵심이었다. 먼저 나름대로 리팩토링을 진행해 PR을 올렸고, 이후 해설 강의를 들으면서, 인상 깊었던 문장들을 정리해 보았다.

1. 우리는 코드를 읽는 게 아니라 예측한다.

해설 강의에서 가장 인상 깊었던 문장이 있었는데, 코드를 한 줄씩 꼼꼼히 해석하며 읽는 것이 아니라 지금까지의 경험을 기반으로 패턴을 인식하고 "이다음엔 이런 코드가 나오겠지?"라고 예측하면서 읽는다는 것이었다. 예측이 맞으면 빠르게 이해하고 넘어가고, 반대로 예측이 틀리는 순간 흐름이 끊기고 다시 코드를 되짚게 된다. 그래서 중요한 건 코드를 짤 때 내가 의도한 대로 예측 가능하게 만드는 것이라는 생각이 들었다. 사실 “좋은 코드는 예측 가능한 코드입니다” 같은 문장은 여태 수없이 들어왔는데, 이번에 리팩토링 과제와 함께 설명을 들으니 좀 더 깊게 와닿았다. 결국 읽는 사람이 내가 의도한 흐름대로 자연스럽게 다음 동작을 예상할 수 있어야 하고, 그 기대를 깨지 않는 구조여야 한다.

2. 인터페이스를 먼저 정의하지 않으면 props는 계속 늘어난다.

<BookingFilterPanel
  filter={filter}
  onChange={handleFilterChange}
  floors={floors}
  validationError={validationError}
/>

당시에는 전혀 어색하지 않았는데, 왜냐면 필터 UI를 구성하는 데 필요한 값들을 넘긴 것뿐이라고 생각했기 때문이다. 하지만 다시 보면 해당 인터페이스에는 서로 다른 성격의 정보가 섞여 있다.

• floors: 데이터
• validationError: 폼 상태

필터 컴포넌트임에도 불구하고 점점 다른 역할까지 함께 떠안는 구조가 된 것이다. 해설 강의에서는 이런 상황을 구현을 따라가며 인터페이스가 점점 넓어지는 구조라고 설명하였는데, 필요한 값을 계속 추가하다 보면 "이 컴포넌트가 무엇을 하는지"보다 "외부에서 무엇을 넘겨줘야 하는지"가 먼저 보이게 된다는 것이다.

이 기준으로 다시 보니, 막연히 "쪼개면 더 깔끔할 것 같다"가 아니라 왜 더 세부적으로 기능 단위로 나눌 수 있는지에 대한 근거가 생겼다. 원래 BookingFilterPanel 안에 감춰져 있던 DateSelector, TimeSelect, FloorSelect 같은 컴포넌트들을 바깥으로 드러내고, 각자 자기 역할만 갖도록 구성하는 쪽이 더 자연스럽게 느껴졌다.

• DateSelector
• TimeSelect
• FloorSelect

이렇게 나누면 각 컴포넌트가 자기 관심사만 가지게 되고, 적어도 인터페이스만 봐도 역할이 더 또렷하게 보인다.

3. 컴포넌트는 얼마나 스스로 설명되는가? 를 기준으로 하자.

<MyReservationList
  reservations={myReservationList}
  rooms={rooms}
  onCancelSuccess={() => setMessage(...)}
  onCancelError={() => setMessage(...)}
/>

필요한 데이터와 핸들러를 부모에서 내려주는 전형적인 구조이지만, 해설 강의에서는 이런 구조의 한계를 짚었다. 컴포넌트가 외부에 의존하는 정보가 많아질수록 이 컴포넌트를 사용하기 위해 알아야 할 맥락도 함께 늘어난다는 것이다. 즉, 분리는 되어 있지만 사용하는 쪽에서 알아야 할 정보는 많아지는 구조다. 핵심은 "단순히 나눴는가"가 아니라, 이 컴포넌트는 스스로 설명 가능한가 라는 기준이었다.

결국 컴포넌트가 따로 존재한다는 사실보다 중요한 건, 그 컴포넌트를 사용하는 사람이 별도 설명 없이도 역할을 어느 정도 이해할 수 있느냐는 것이었다. 분리 자체가 목표가 아니라, 읽는 사람이 덜 헷갈리게 만드는 것이 목표라는 점을 다시 보게 되었다.

4. 이름은 외부 맥락이 아니라 내부 의미를 드러내야 한다.

이전에는 setData, handleChange처럼 상태를 바꾸는 행위를 기준으로 이름을 짓는 경우가 많았는데, 다시 보니 이런 방식은 컴포넌트의 내부보다는 외부 맥락에 더 가까운 이름이라는 생각이 들었다.

예를 들어 이런 코드가 있다고 하면,

<DateSelector
  date={date}
  setDate={setDate}
/>

이 인터페이스는 얼핏 보면 자연스러워 보이지만, setDate라는 이름은 이 컴포넌트가 호출되는 바깥의 맥락에 의존하고 있다. 만약 날짜가 바뀌었을 때 콘솔을 찍거나, API를 호출하거나, 다른 상태를 업데이트해야 하는 상황이 온다면 setDate라는 이름은 더 이상 적절하지 않게 된다. 즉, 컴포넌트가 “바깥에서 무엇을 할지”까지 알고 있는 구조가 되어버린다. 이런 경우에는 HTML 인터페이스와 비슷한 패턴으로 바꾸는 것이 더 자연스럽다.

<DateSelector
  value={date}
  onChange={(nextDate) => setDate(nextDate)}
/>

이렇게 바꾸면 DateSelector는 단순히 "값이 바뀌었다"는 사실만 전달하고, 그 이후에 무엇을 할지는 사용하는 쪽에서 결정하게 된다. 컴포넌트는 자신의 역할에만 집중하고, 외부 맥락과는 분리되는 구조다.

++

마진에 대한 얘기도 기억에 남았는데, margin은 컴포넌트 바깥의 영역이기 때문에, 컴포넌트가 바깥 간격까지 결정하려 들면 재사용할 때마다 보정 코드가 붙기 쉽다. 그래서 컴포넌트는 padding만 책임지고, margin은 사용하는 쪽에서 제어해야 한다는 원칙이 인상 깊었다. 사실 디자인 시스템이나 공통 컴포넌트를 구현할 때를 제외하면 마진을 크게 의식하지 않고 사용해 왔던 것 같은데, CSS적인 부분도 결국 컴포넌트의 관심사와 연결된다는 점이 인상 깊었다.

// 컴포넌트 내부에서 margin을 결정
<Card style={{ marginTop: 16 }} />

// 사용하는 쪽에서 간격을 제어
<Wrapper>
  <Card />
</Wrapper>

비슷한 맥락으로 라벨도 동일하다.

// 컴포넌트 내부에 라벨 포함
<DateSelector />

// 내부
<label>날짜 선택</label>
<input ... />

위의 구조는 컴포넌트가 "어떤 문맥에서 사용되는지" 까지 알고 있는 상태다. 반대로 라벨을 분리하면 컴포넌트의 역할이 더 명확해진다.

<label>날짜 선택</label>
<DateSelector value={date} onChange={...} />

이렇게 되면 DateSelector는 "날짜를 선택한다" 는 역할에만 집중하고, 어떤 텍스트를 보여줄지는 사용하는 쪽에서 결정할 수 있다.

결국 컴포넌트를 설계할 때는 항상

• 이건 컴포넌트 내부의 책임인가?
• 아니면 사용하는 쪽의 책임인가?

를 나눠서 보는 것이 중요하다는 생각이 들었다. 예전에는 이런 부분을 깊게 생각해 본 적이 없었는데, 이번에는 컴포넌트의 경계를 나누는 기준으로 다시 볼 수 있게 되었다.

느낀 점

요즘 AI가 실질적으로 업무 안으로 들어오고, 빠른 생산성이 더 중요하게 여겨지는 분위기 속에서 프론트엔드의 설계나 구조에 대한 고민이 예전보다 덜 중요하게 받아들여지는 순간들이 있는 것 같다. AI가 작성해 준 결과물도 화면만 잘 동작하면 충분하다는 식의 평가를 계속 듣다 보니, 나 역시 점점 힘이 빠졌고 그 기준에 익숙해지고 있었던 것 같다. 그런 흐름 자체를 부정하고 싶은 건 아니지만, 그런 장면들이 반복되다 보니 나도 모르게 원래라면 한 번 더 고민했을 부분을 그냥 넘기게 되고, 어느 순간부터는 "그래, 이 정도면 되겠지" 하는 마음으로 구현하고 있었던 것 같다. 물론 나름대로 기준을 정리해 두고 AI와 함께 활용하려고는 하고 있지만, 그 과정 자체가 예전만큼 즐겁게 느껴지지 않았던 것도 사실이다.

이번 과제를 하면서 오랜만에 코드 자체를 다시 생각해 보게 되었다. 어떻게 나눌지, 어떤 이름이 더 예측 가능한지, 인터페이스가 어떤 역할을 드러내는지 같은 이야기들이 내가 원래 중요하게 생각했던 기준들을 다시 떠올리게 해 주었다.

이번 과제는 리팩토링 기준을 배우는 것을 넘어, 내가 코드를 어떤 마음으로 대하고 있었는지를 다시 돌아보게 만든 시간이었다.