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

들어가며 ✍️

토스 Frontend Fundamentals 모의고사 2회차에 1회차에 이어 참여했어요.

• 진행 · 오종택님
• 1부 · 한재엽님
• 2부 · 문동욱님

주어진 회의실 예약 시스템 코드를 리팩토링하는 게 이번 과제였어요. 코드를 직접 개선하고, 서로의 PR을 리뷰하면서 "좋은 코드란 무엇인가"에 대해 깊이 고민할 수 있는 시간이었어요. 이번 글에서는 세션에서 인상 깊었던 내용과 제가 직접 고민했던 것들을 함께 정리해봤어요.

---

우리의 코드는 읽는 것이 아니라 예측한다

모의고사 리뷰에서 가장 기억에 남는 말이었어요.

"뇌는 모든 것을 입력받고 해석하는 게 아니라, 어느 정도는 예측한다."

코드를 볼 때 한 줄 한 줄 읽기보다는, 함수명이나 구조를 보고 "이 다음엔 이렇게 되겠지" 하고 예측하면서 읽잖아요. 그 예측이 맞아떨어질수록 읽기 편하고, 빗나가면 "어?" 하고 멈추게 되고요.

---

그래서 예측하기 힘든 코드가 뭔데?

PR 리뷰에서는 여러 코드 중 몇 가지 패턴을 뽑아서 같이 이야기했어요. "아 이런 게 예측이 안 되는 거구나" 싶었던 것들이에요.

🔍 setMessage — 사용처와 멀어질수록 이름의 부담이 커진다

그중 하나가 message 상태였는데, 흥미로웠던 건 이름보다도 전달 방식이었어요. 메시지를 실제로 사용하는 컴포넌트 가까이에 둬도 됐을 텐데, setMessage가 props로 계속 내려받는 형태였거든요.

const [message, setMessage] = useState<{ type: 'success' | 'error'; text: string } | null>(null);

const handleCancel = async (id: string) => {
  try {
    await cancelMutation.mutateAsync(id);
    setMessage({ type: 'success', text: '예약이 취소되었습니다.' });
  } catch {
    setMessage({ type: 'error', text: '취소에 실패했습니다.' });
  }
};

setMessage라는 이름만 봐서는 어떤 맥락의 메시지인지 — 채팅인지, 알림인지, 피드백인지 — 선언부까지 올라가서 type: 'success' | 'error' 구조를 확인해야만 알 수 있어요. 사용처에서 멀어질수록 이름이 져야 하는 부담이 커지는 거예요.

데이터를 쓰는 곳 가까이에 두는 것만으로도, 이름이 주는 부담이 자연스럽게 줄어들 수 있겠다 싶었어요.

🔍 setDate — props는 내부만 바라봐야 한다

또 다른 패턴은 DatePicker에 date, setDate를 직접 넘기는 형태였어요.

// 호출하는 쪽의 맥락이 그대로 노출된다
<div>
  <Text as="label">날짜</Text>
  <input
    type="date"
    value={date}
    onChange={e => setDate(e.target.value)}
    min={formatDate(new Date())}
  />
</div>

세션에서 이런 이야기가 나왔어요.

"함수가 자신이 호출되는 쪽의 맥락을 가지는 순간 재사용성이 떨어진다."

setDate라는 이름은 "부모에 date라는 state가 있고 그걸 set한다"는 맥락을 그대로 드러내요. DatePicker 입장에서는 "값이 바뀌었다"는 것만 알면 되는데, 호출하는 쪽의 사정까지 알고 있는 거죠.

value와 onChange라는 일반적인 인터페이스를 따르면 훨씬 자연스러워요. label은 DatePicker의 관심사가 아니니까 바깥에서 쓰는 쪽이 챙기면 되고, DatePicker는 날짜 입력 그 자체에만 집중하면 돼요.

// ✅ DatePicker는 날짜 입력만 책임진다
interface DatePickerProps {
  value?: string;
  defaultValue?: string;
  min?: string;
  onChange?: (e: ChangeEvent<HTMLInputElement>) => void;
  onBlur?: (e: FocusEvent<HTMLInputElement>) => void;
  name?: string;
}

export const DatePicker = forwardRef<HTMLInputElement, DatePickerProps>(
  ({ value, defaultValue, min, onChange, onBlur, name }, ref) => {
    const inputProps = value !== undefined ? { value } : { defaultValue };
    return (
      <input ref={ref} type="date" {...inputProps} min={min}
             onChange={onChange} onBlur={onBlur} css={inputStyle} />
    );
  }
);

onDateChange처럼 굳이 중복된 맥락을 넣을 필요도 없어요. 이미 DatePicker라는 컴포넌트 이름이 맥락을 충분히 설명하고 있으니까요.

🔍 navigate('/', { state: { message } }) — 숨겨진 데이터 전달

이것도 같이 이야기했던 패턴이에요.

navigate('/', { state: { message: '예약이 완료되었습니다!' } });

navigate의 state로 메시지를 넘기면 "홈으로 이동한다"까지는 예측되는데, "그러면서 성공 메시지를 전달한다"는 숨겨져 있어요. 받는 쪽에서는 location.state를 꺼내서 확인하고, history.replaceState로 수동 정리까지 해야 해요.

// 받는 쪽: 숨겨진 로직이 필요하다
const locationState = location.state as { message?: string } | null;
const [message, setMessage] = useState(
  locationState?.message ? { type: 'success', text: locationState.message } : null
);

useEffect(() => {
  if (locationState?.message) {
    window.history.replaceState({}, '');  // state 수동 정리까지 필요
  }
}, [locationState]);

state는 브라우저 히스토리에 묻혀버리는 데이터라 디버깅도 어렵고, 받는 쪽에도 숨겨진 로직이 필요해져요.

결국 이름이 역할을 숨기거나, 데이터가 보이지 않는 경로로 전달되면 읽는 사람 입장에서 예측이 깨진다는 거였어요.

---

PR 리뷰하면서 나온 이야기들

컴포넌트의 박스모델: 관심사를 어디서 끊을 것인가

추상화를 할 때 "어디까지 계층을 정할 거냐, 어디까지 의도를 담아서 보여줄 거냐"가 중요하다는 이야기가 나왔어요. 결국 내가 설계하는 컴포넌트가 어디까지를 자기 관심사로 볼 것인가를 정하는 거더라고요.

RoomBookingPage (조율자)
├── BookingFilterSection (필터 입력)
│   ├── DatePicker
│   ├── TimeSelect
│   ├── AttendeesInput
│   ├── FloorSelectField
│   └── EquipmentSelector
├── AvailableRoomList (결과 표시 + 데이터 페칭)
└── SubmitButton (제출)

각자 자기 박스 안의 일만 책임지면, 나중에 필터 UI가 사이드바로 바뀌어도, 목록이 카드형으로 바뀌어도 서로 영향을 안 줘요.

filterPanel: 숨기는 게 목적이 되면 안 된다

filterPanel도 코드 리뷰에서 나왔던 이야기예요. 여러 필터들을 하나의 panel로 묶은 구조였는데, 바깥에서 보면 필터 영역이라는 건 알겠는데 안에 어떤 정보가 있는지는 가늠이 잘 안 됐어요.

그러면서 오히려 "굳이 숨길 필요가 있었나?"라는 생각이 들었어요. 추상화 계층이 하나 더 생기면 바깥에서 예측이 쉬워져야 하는데, 안이 안 보이는 채로 묶이기만 했다면 비용 대비 얻는 게 있는지 따져봐야 하는 거니까요.

숨기는 게 목적이 아니라, 읽는 사람의 예측을 돕는 게 목적이라는 게 이 대목에서도 맞닿아 있었어요.

presentational vs 내부 페칭 — 뭐가 맞아요?

코드 리뷰 시간에 나온 질문이에요. 항상 presentational 컴포넌트로 만들어야 할지, 아니면 내부에서 페칭하도록 해야 할지 고민된다는 이야기였어요.

결국 presentational이냐 내부 페칭이냐보다, 이 컴포넌트의 핵심 관심사가 뭔지를 먼저 따지는 게 맞는 것 같아요. 도메인 맥락을 쥐고 있어야 하는 컴포넌트라면 내부에서 직접 가져오는 게 더 자연스럽고, 순수하게 UI만 책임지는 컴포넌트라면 props로 받는 게 맞고요. 어느 쪽이 항상 옳다기보다, 컴포넌트가 무엇을 알아야 하는지에 따라 달라지는 거예요.

전역 상태에는 정말 전역인 것만 담자

jotai나 zustand 같은 전역 상태 라이브러리를 쓰면 편하니까 자꾸 여기에 상태를 넣고 싶은 유혹이 생기잖아요. 근데 한번 물어봐야 해요. "이 상태, 진짜 다른 페이지에서도 쓰나?"

대부분은 아니에요. 회의실 예약 페이지의 필터 값은 그 페이지에서만 의미가 있지, 홈 화면이나 예약 현황 페이지에서 알 필요가 없거든요. 그런 상태까지 전역 store에 넣으면 "이 atom이 어디서 쓰이는 거지?" 하고 추적해야 하는 비용이 생겨요.

전역 상태에 담기 적합한 건 이런 것들이에요.

• 인증 정보 — 어떤 페이지에서든 로그인 여부를 알아야 하니까
• 테마/언어 설정 — 앱 전체에 영향을 주니까
• 알림 카운트 — 헤더에서 항상 보여줘야 하니까

반대로 특정 페이지의 폼 값, 필터 조건, 모달 열림 상태 같은 건 그 페이지 안에서 해결하는 게 맞아요. URL searchParams든, 지역 state든, 사용처에서 가까운 곳에 두는 거죠.

---

정답은 없다, 근거가 있을 뿐

마지막으로 가장 와닿았던 이야기예요.

"코드를 작성한 사람으로서 근거를 제출할 수 있으면 된다."
"정답이 아니니까. 주장이 중요하다. 정답이라고 믿고 따라가면 안 된다."

개발하다 보면 "이게 맞는 건가?" 싶을 때가 많잖아요. 근데 중요한 건 정답을 찾는 게 아니라, 내가 왜 이렇게 했는지 설명할 수 있느냐라는 거예요.

---

내 코드에서 고민했던 것들

1. 페이지는 안내 표지판이면 된다

처음 RoomBookingPage는 402줄짜리 단일 파일이었어요. 상태 선언, URL 동기화, API 호출, 필터 검증, 필터링 로직, 렌더링이 전부 한 곳에 있었거든요.

// ❌ Before: 원본 RoomBookingPage (402줄)
export function RoomBookingPage() {
  const [date, setDate] = useState(searchParams.get('date') || formatDate(new Date()));
  const [startTime, setStartTime] = useState(searchParams.get('startTime') || '');
  // ... 상태 8개

  useEffect(() => {
    // 6개 상태를 URL과 일일이 동기화
    setSearchParams(params, { replace: true });
  }, [date, startTime, endTime, attendees, equipment, preferredFloor]);

  // 필터링 로직, 충돌 검사까지 전부 인라인으로...

  return (
    <div css={css`background: ${colors.white}; padding-bottom: 40px;`}>
      {/* 300줄 이상의 JSX */}
    </div>
  );
}

세션에서 "기능에 대한 정보가 아니라면 안내 표지판처럼 외부에서 안내하고, 세부 정보는 아래에 남긴다"는 이야기가 나왔는데, 딱 페이지 컴포넌트한테 해당되는 말이라고 느꼈어요.

리팩토링하면서 페이지 컴포넌트를 흐름만 보여주는 안내판으로 만들었어요.

// ✅ After: 위에서 아래로 읽히는 선언적 구조 
export function RoomBookingPage() {
  const navigate = useNavigate();
  const queryClient = useQueryClient();

  const {
    isFilterValid, errorMessage, isPendingBooking,
    selectedRoomId, handleRoomSelect, handleFilterChange, handleSubmit,
  } = useBookingForm();

  return (
    <div css={pageStyle}>
      <button onClick={() => navigate(ROUTES.HOME)}>← 예약 현황으로</button>
      <Top.Top03>예약하기</Top.Top03>

      {errorMessage && <Text color={colors.red500}>{errorMessage}</Text>}

      <BookingFilterSection onFilterChange={handleFilterChange} />

      {!isFilterValid ? (
        <Text>{'예약 조건을 먼저 선택해 주세요.'}</Text>
      ) : (
        <ErrorBoundary onReset={() => queryClient.resetQueries({ queryKey: ['availableRooms'] })}>
          <Suspense fallback={<AvailableRoomList.Loading />}>
            <AvailableRoomList selectedRoomId={selectedRoomId} onSelectRoom={handleRoomSelect} />
          </Suspense>
        </ErrorBoundary>
      )}

      <Button onClick={handleSubmit} disabled={!isFilterValid || isPendingBooking}>
        {isPendingBooking ? '예약 중...' : '확정'}
      </Button>
    </div>
  );
}

파일 열었을 때 "필터 선택하고 → 목록 보고 → 확정하는 페이지구나"가 바로 보여요. 세부 구현이 궁금하면 타고 들어가면 되고요.

다만 지금 코드를 다시 보면 아쉬운 부분도 있어요. AvailableRoomList 안에 "예약 가능 회의실 N개" 같은 타이틀이나 빈 상태 메시지처럼 이 페이지의 맥락을 나타내는 내용이 컴포넌트 내부에 들어가 있거든요. 다시 작성한다면 그런 부분은 페이지에서 직접 담당하고, 컴포넌트는 정말 목록 렌더링에만 집중하도록 더 좁혔을 것 같아요.

2. URL searchParams를 상태로: 상태의 출처는 하나여야 한다

이 부분은 코드를 짜면서 저도 꽤 고민했던 지점이에요.

처음엔 react-hook-form으로 폼 상태를 관리했는데, 이 페이지에서는 필터 조건이 URL에도 반영돼야 했어요. 뒤로가기도 되어야 하고, 링크로 공유도 가능해야 하니까요.

문제는 react-hook-form이 관리하는 상태와 URL searchParams를 동기화하는 useEffect가 따로 필요했다는 거예요. 상태가 두 군데에 있으니까 자꾸 싱크가 어긋나는 느낌이었어요.

// ❌ useState 8개 + useEffect로 URL 동기화 = 이중 관리
const [date, setDate] = useState(searchParams.get('date') || formatDate(new Date()));
const [startTime, setStartTime] = useState(searchParams.get('startTime') || '');
// ... 6개 더

useEffect(() => {
  const params: Record<string, string> = {};
  if (date) params.date = date;
  if (startTime) params.startTime = startTime;
  // ...
  setSearchParams(params, { replace: true });
}, [date, startTime, endTime, attendees, equipment, preferredFloor, setSearchParams]);

그래서 아예 URL searchParams 자체를 상태로 쓰기로 했어요.

// ✅ URL searchParams가 곧 상태 (useBookingParams.ts)
export function useBookingParams() {
  const [searchParams] = useSearchParams();
  return {
    date: searchParams.get('date') ?? dayjs().format('YYYY-MM-DD'),
    start: searchParams.get('start') ?? '',
    end: searchParams.get('end') ?? '',
    attendees: Number(searchParams.get('attendees')) || 1,
    equipment: searchParams.get('equipment')?.split(',').filter(Boolean) ?? [],
    preferredFloor: searchParams.get('floor') ? Number(searchParams.get('floor')) : null,
  };
}

// ✅ 값 변경도 한 곳에서 (useUpdateBookingParam.ts)
export function useUpdateBookingParam() {
  const [, setSearchParams] = useSearchParams();
  return (partial: Record<string, unknown>) => {
    setSearchParams(prev => {
      // partial의 값들을 searchParams에 반영
    }, { replace: true });
  };
}

출처를 하나로 좁히니까 동기화 신경 쓸 게 없어졌어요. useState 8개 + useEffect 동기화가 통째로 사라진 셈이에요.

이렇게 하면서 스스로 내린 근거는 "URL이 single source of truth니까 이중 관리를 없애자"였어요. 필터 변경 → URL 변경 → 쿼리 리페치라는 단방향 흐름이 더 예측 가능하다고 느꼈고요.

그런데 세션 이후에 useBookingForm의 인터페이스에 대한 추가 피드백을 받으며 더 고민해보게 됐어요.

const {
  isFilterValid, errorMessage, isPendingBooking,
  selectedRoomId, handleRoomSelect, handleFilterChange, handleSubmit,
} = useBookingForm();

form이 이름에 들어가는 순간 세부 구현을 보지 않아도 react-hook-form의 useForm처럼 동작할 거라는 기대를 심어주게 된다는 거였어요. 실제 인터페이스와 어긋나다 보니 예측을 깨는 이름이 된 것 같기도 하고요.

생각해보니 useBookingForm이 필터 조건(searchParams 값들)과 예약 액션(룸 선택, 제출, 에러 처리)을 한꺼번에 쥐고 있다는 게 문제인 것 같아요. useBookingFilter와 useRoomBooking처럼 관심사별로 분리한다면 각 hook이 무엇을 반환하는지 이름만으로도 더 명확하게 예측할 수 있을 것 같아요. 아직 구체적인 형태는 고민 중이지만, 분리하는 방향으로 개선해보고 싶어요.

---

마무리 🙌

이번 모의고사를 한 줄로 요약하면, "왜 이렇게 짰어?"에 대답할 수 있는 코드를 쓰자인 것 같아요.

예측 가능한 이름, 상태의 출처를 하나로, 데이터는 쓰는 곳 가까이에, 전역 상태는 진짜 전역인 것만. 다 결국 "읽는 사람이 예측할 수 있게"라는 하나의 원칙에서 나오는 이야기였어요.

앞으로도 코드 짤 때 "이거 다른 사람이 보면 예측 가능한가?" 한번 더 생각해보게 될 것 같아요.
이름 하나, 데이터 위치 하나가 읽는 사람의 흐름을 끊기도 하고 자연스럽게 이어주기도 하니까요.
그 질문 하나를 앞으로도 습관처럼 가져가고 싶어요.

같은 코드를 작성하고 서로의 선택에 대해 "왜?"를 묻고 답하는 시간이 밀도있는 의미 있는 시간이었습니다..!

3회차도 기대되네요!! 🙌