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

0. 웹 프론트엔드 모의고사?

돌이켜보면 학창시절 때 정말 많은 모의고사를 풀었었다. 더 많은 모의고사, 다양한 문제를 접할수록 수능을 잘 볼거라 믿어 의심치 않던 시절이었다. 익숙하지 않은 유형의 문제를 틀리고 해설을 보며 외우는 과정의 반복. 이 반복된 행동을 괴로워하면서도 꽤나 즐겼던 것 같다. 이렇게 계속하다보면 수능에서 무슨 문제가 나와도 당황하지 않겠지라고 생각하며, 모의고사를 풀 때만큼은 잠시 불안에서 벗어날 수 있었다.

 

그리고 몇년이 지나, 모의고사와는 연을 끊은지 오래된 나에게 우연히 웹 프론트엔드 모의고사가 실시된다는 소식을 들었다. 웹 프론트엔드도 모의고사가 있다고? 트윗을 살펴보니 토스 프론트엔드 채용에서 실제로 사용했던 과제를 모의고사로 출제한다고 써져있었다. 토스에 지원해본적이 없어서 과연 어떤 과제가 나올 지 궁금했다. 또 웹 프론트엔드 일을 하며 거의 매일 코딩을 하지만 내가 과연 올바른 코딩을 하고 있는지 스스로를 의심할 때가 종종 있는데, 이번 기회를 통해 의심에 대한 답변을 할 수 있을까하는 기대도 있었기에 모의고사에 응모하기로 다짐했다.

 

 

글을 자세히 읽어보니 모두가 모의고사를 볼 수 있는게 아니라 선착순 50명만 모의고사를 볼 수 있다고 써져있었다. 수강신청만 했다하면 번번히 망했던 내게 좋은 소식은 아니었다. 그래도 한 번 시도는 해봐야지 생각하며, 2시가 되자마자 트위터를 계속 새로고침하다가 뜬 초대 링크를 클릭했다. 이번에는 다행히 선착순에 성공할 수 있었고, 주말에 시간을 내어 2시간 동안 모의고사에 응시할 수 있었다.

---

1. 얼마만에 듣는 해설강의인지

해설강의는 화요일 8시에 라이브로 진행되었다. 6평이나 9평이 끝나면 인강 사이트에 접속해서 시험지를 펼치고 인강 선생님들의 해설강의를 듣고는 했었다. 나한테는 많이 어려웠는데 선생님들은 모든 걸 안다는 듯이 척척 풀곤해서 현타가 꽤 많이 왔었던 기억이 난다. 아무튼 8시가 되어 폰을 키고 해설강의 링크에 접속했다. 과연 주말에 내가 열심히 만든 코드는 퀄리티가 괜찮았을까. 과연 토스 개발자들은 어떻게 코드를 짜셨을까. 호기심을 가지고 개발자님의 설명에 집중하기 시작했다.

 

먼저, 개발자분들께서 이번 모의고사를 출제한 이유에 대해서 설명해주셨다. 지금까지 진행되었던 토스 과제에 대한 잘못된 정보가 퍼져서 그 부분을 정정하고 싶으셨다고. README.md를 안썼거나, 테스트 코드를 짜지 않아서 떨어졌다는 소문이 퍼졌다고 하는데, 사실 그런 부분이 중요한 건 아니라고 하셨다. 그렇다면 과제를 구현할 때 중요한 점은 과연 무엇일까? 바로 ‘코드를 어떻게 설계하는지’에 대한 것이었다.

---

2. 코드 구조와 UI 구조를 1대1 매칭하기

개발자분께서는 먼저 코드를 읽기 전에, 파일을 새로 생성하시고 제공된 UI를 보며 어떻게 구조를 짤까, 이상적인 인터페이스는 무엇일까 고민하시면서 마크업을 구성하셨다. 개발자분께서 작성한 코드는 어떤 UI를 나타내는지 바로 알 수 있을 정도로 직관적이었다. 왜냐하면 코드의 구조와 UI의 구조가 1:1로 매핑이 되어있었기 때문이다. 특히 title과 같은 텍스트가 해당 코드가 어느 부분인지 알려주는 역할을 해주었다.

 

파일을 분리하는데에만 집중하지 말 것. 열심히 쪼갠다고 능사는 아니며, 불분명한 컴포넌트명은 오히려 혼란을 가중시킨다는 점을 알게 되었다. 컴포넌트로 쪼갠다고 할 때, 해당 컴포넌트가 무슨 역할을 하는지 선명하게 드러내는 것이 중요하다.

---

3. 컴포넌트를 만들 때 일반적인 표준을 따르자 → 코드의 사회성

Input이라는 접미사가 붙은 컴포넌트를 만든다고 가정하자. 그렇다면 그 컴포넌트는 일반적인 Input과 유사한 구조를 가지고 있어야 다른 사람들이 이해하기 쉽다.

 

해설강의 후반부에 다른 응시자분이 작성하신 ‘EmptyResultBoundary’라는 이름의 컴포넌트 코드를 보여주시면서, 이 코드를 왜 우리한테 보여주는지를 질문해주셨다.

→ 보통 ‘Boundary’라는 이름이 들어가게 되면 ErrorBoundary를 떠올리게 되고, 그러면 Error나 Promise가 던져지는걸 예상하게 되는데 이 코드에서는 그렇지 않았다는 점이 아쉬웠다는 설명을 해주셨다.

 

이런 관점에 대해서는 아예 생각해보지 못했어서 더욱 신선하게 다가왔다. 옛날에 국어 시간에 배운 ‘언어의 사회성’처럼 ‘코드의 사회성’을 지킬 수록 우리의 소통은 더욱 간편해진다. 이를 지키기 위해서, 더 많은 코드를 보면서 패턴에 익숙해질 필요가 있다는 사실을 알게 되었다.

---

4. 추상화 !== 추출 → Monster Hook의 출현을 막아라

2번에서 언급했듯이, 우리는 파일을 깔끔하게 분리하는 것에만 집중하면 안된다. 이번에 해설을 진행해주신 재엽님의 블로그에는 추상화와 추출의 차이점이 작성되어있다.

 

https://jbee.io/articles/etc/%EC%A2%8B%EC%9D%80%20%EC%BD%94%EB%93%9C%EB%9E%80%20%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

좋은 코드란 무엇일까

 

 

추출은 특별한 기준없이 단순히 밖으로 끌어내는 것이고,

추상화는 어떤 대상의 중요한 요점들을 재해석하여 정리하는 것이다.

 

단순히 깔끔하게 보이기 위한 분리는 재사용하기 어렵고, 역할을 파악하기 힘든 괴물을 만들 뿐이다.

예를 들어 이번 모의고사에서 깔끔하게 보이기 위해 내가 만든 훅을 보자.

const {
    isLoading,
    errorMessage,
    goalAmount,
    monthlyAmount,
    term,
    setGoalAmount,
    setMonthlyAmount,
    setTerm,
    selectedProductId,
    handleSelectProduct,
    selectedProduct,
    finalAmount,
    diffFromGoal,
    recommendedMonthly,
    recommendedProducts,
    filteredProducts,
  } = useSavingsCalculator();

무려 16개의 반환값이 있는 기괴한 훅을 만들었다. 이런 훅을 Monster Hook이라고 하는데, 계산을 하는데 사용되는 사실만 알뿐 그 안에서 무슨 일이 일어나는지 개발자는 이 훅만 보고 파악을 할 수 없게 된다.

 

단순히 분리만 한 훅은 아무런 의미가 없다. 우리는 책임 단위를 기준으로 직관적이게 분리를 해야한다.

 

같은 의미로 개발자분들께서는 FSD와 같이 어떻게 폴더를 쪼개야되는지를 설명해주는 방법론에 대해서 회의적인 시각을 가지고 계셨다. FSD가 유명해진 이유는 코드의 라인수가 줄어들면 깔끔해보이는데, 코드의 라인수를 줄이게 하기위해 끄집어내고 집어넣는 방법을 FSD가 알려주기 때문이지 않을까하는 견해를 밝혀 주셨다. 오히려 코드들은 물리적으로 가까이 있는 것이 직관적이고 좋지 않을까하는 생각을 말씀해주셨다. 즉, 폴더 구조에 너무 집착하지 말자!

 

---

5. 결론은 직관적인 코드

위에 적은 내용 외에도,

Global State를 쓰는 이유가 props drilling이어서는 안된다,

isLoading 같은 우리의 관심사가 아닌 요소에 시선을 빼앗기기 위해 useSuspenseQuery를 사용하면 좋다,

와 같은 유용한 팁들을 알려주셨다.

 

 

그리고 마지막으로 아래와 같이 3줄 요약을 해주셨다.

1. 코드를 보기 전에 요구사항 문서를 보고 먼저 이상적인 형태를 떠올려보자.
2. UI 형태와 코드 형태가 1:1로 매칭되면 유지보수가 쉽다.
3. 책임 단위로 추상화를 하면 재사용성은 따라오는 것.

해설강의를 통해 알려주신 내용들은 결국 누구나 알아보기 쉬운 직관적인 코드를 만들기 위한 방법이었다. 지금까지 내가 어떻게 구조를 짜왔고 코딩을 해왔는지 되돌아보았다. 그저 깔끔해보이기 위한 의미없는 분리의 반복. 내가 만든 컴포넌트가 무슨 역할을 하기 위한 것인지 확인하기 위해 주석을 달고 drilling을 해왔던 것을 떠올려봤을 때, 나의 코드는 분명 직관적이지 않았다.

 

이번 과제 레포의 discussion 탭에서 다양한 토론이 이루어졌는데 글을 읽어보며 접근성이나 구조 설계 등 여러 주제에 대한 정보를 익힐 수 있었다. 이뿐만 아니라 이번에 모의고사를 주최한 Frontend Fundamentals 홈 페이지에서 코드퀄리티, 번들링 등에 대한 내용들이 상세하게 적혀있어 앞으로 자주 접속하려고 한다. (사실 최근에 홈페이지 최적화를 할 때 이 페이지의 번들링 탭을 자주 참고했었다!)

 

정말 오랜만의 모의고사와 해설강의. 옛날로 돌아간 기분과 함께 얻어가는 게 많았던 귀중한 시간이었다. 이런 모의고사를 위해 고생해주신 Frontend Fundamentals 개발자분들께 감사드리며, 다음에 이런 기회가 또 생긴다면 참여해야겠다는 다짐을 하게 되었다.