토스 Frontend Fundamentals 2회 모의고사

Woody·2026년 3월 29일

2회 모의고사를 풀게 된 계기

최근 회사에서 다양한 업무를 하고 있지만, 실제로 코드를 짜는 경험을 할 일이 없었다. 프로젝트가 일부 마무리되고 팀장 + PL 역할에 충실하고 있던 상황이었고, 코딩의 경우 오류 수정이나 탐색, 자동화에 집중하다 보니 거의 아이디어 수준에서 끝나는 정도였다.

이러다 보면 내가 배웠던 좋은 원칙들을 잊어버릴 것 같았고, 시험이라는 틀 안에서 — 조금 부끄럽지만 — AI 없이 오랜만에 열심히 풀어보자고 생각했다.

난이도와 소요 시간

사실 난이도는 사람마다 정말 달랐을 것 같다. 이번에는 저번 모의고사와 달리 기능 구현이 아닌, 이미 구현되어 있는 상태에서의 리팩토링에 중점이 되어 있었기 때문이다. 실제로 구현에는 더 이상 손을 댈 필요가 거의 없었고, 어떻게 하면 이 코드의 추상화가 더 잘 될지, 또 어떻게 하면 예측 가능한 코드가 될 수 있을지를 고민하는 시간이었다.

소요 시간은 저번과 같이 2시간을 생각하고 시작했는데, 생각해 보니 딱히 시간 제한이 없었다(...). 뭔가 2시간 안에 해결해야지 하고 딱 멈췄었는데, 그 때문인지 알고 있던 것도 많이 놓쳤던 것 같다. 한 시간 정도 추가해서 총 3시간 정도 풀었다.

기존 코드를 보고 느낀 문제점

코드를 처음 봤을 때 굉장히 정리되지 않은 코드라고 느꼈다. 얽힘이 느껴졌고, 코드에서 어떤 부분이 어떤 역할을 하는지 파악하기가 쉽지 않았다. 기본적으로 분리를 하고 싶었고, 그 분리를 통해서 기능별로 정리하고 싶다고 생각했다. 예측 가능성이 떨어져 있었고, 기능끼리의 결합도가 너무 높아 보였다.

내가 집중한 것과 시도한 패턴들

내가 집중한 건 코드의 예측 가능성을 높이는 것이었다. 일반해를 통해 누가 봐도 어떤 기능을 할지 예측이 가능하고, 문제가 생긴 부분을 빠르게 찾아서 해결할 수 있도록 하는 것. 또한 결합도를 낮추어서 각자 단위 테스트가 가능하고, 기능끼리의 연결이 과도하지 않게 하는 게 목적이었다.

최초로 시작한 건 요구사항 보기.
맨 처음 요구사항을 보고 순차적으로 이상적인 구조를 그려본 다음, 그 구조에 어긋나는 부분들을 먼저 정리해 보았다. 이상적인 구조로 코드를 먼저 분리하고, 얽혀 있는 부분들을 어떻게 할지 고민한 것 같다.
date와 같은 필터 값은 URL 파라미터로 처리하는 게 좋다고 느꼈고, 이를 통해 예측 가능한 인터페이스를 줄 수 있다고 생각했다.

또한 일반해의 원칙을 지키면서 타당한 props를 사용하고자 했다. XP 프로그래밍에서 배웠듯, TDD 원칙을 고려하며 단위 테스트가 가능하지 않다는 것은 기본적으로 기능이 얽혀 있다는 신호라고 생각했고, 그 얽힘을 해소하고자 했다.

1회차와 비교해서 달라진 점

오히려 이번엔 1회차보다 못했다는 생각을 했다. 1회차에는 엑셀레이터 3기가 끝나고 얼마 되지 않았기 때문일까, 나름대로의 철학이 있었고 그걸 적용하고자 했는데. 지금은 몇 가지 키워드를 기반으로 정리하다 보니 무언가 놓치고 있다는 생각이 들었다.

아쉬웠던 점

일반해의 원칙, YAGNI 원칙, TDD, 예측 가능성, 얽힘 — 이런 부분들을 알고 있으면서도 여전히 실수하고 있다고 느꼈다. 사실 추상화된 단어를 아는 것도 중요하지만, 그걸 체화하여 코드에서 바로 코드 스멜을 느끼고 처리하는 것도 중요한데, 아직 그 연습이 덜 된 것 같다.

<MyReservations setMessage={setMessage} />
right={<CancelButton id={reservation.id} setMessage={setMessage} />}

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

문제의 setMessage. 예측 가능한 props가 아니며, 어떤 기능을 할지도 애매한 상황이다. 실제 사용처에서도 props가 한 번 더 내려가서, 결국 캔슬 버튼까지 너무 먼 거리를 이동한다.

사실 꽤나 특징적으로 드러나기 때문에 바로 코드 스멜을 느낄 만도 했는데, 내 코드를 계속 보다 보니 오히려 느끼지 못한 것 같다. 이런 부분에서 아직 체화되지 않은 개념들이 있다고 느꼈다.

마무리

모두가 그럴지도 모르겠지만, 항상 나의 코드는 부끄러운 것 같다. 내 코드를 보여주고, 내 실력을 보여주고. 내가 코드를 잘 짜고 있는가라고 생각하면, 동작은 하지만 정말 최선일까? 라는 생각이 항상 든다.

이러한 결핍을 느껴야 성장할 수 있고, 개선하고 싶은 의지가 들 것이라 생각한다. 이번에 오랜만에 코드를 아예 손코딩으로 하면서 많이 느꼈고, 아직도 잘 체화하고 있지 못하는구나 라는 생각을 많이 했다.

3회가 언제일지는 모르겠지만, 그때도 결국 무언가 아쉬운 게 생기겠지. 그래도 최선을 다했다고 이야기할 수 있는 사람이 되고 싶다.

profile
프론트엔드 개발자로 살아가기

0개의 댓글