Toss Frontend Fundamentals 모의고사 회고
지난 주말, Toss에서 주최한 Frontend Fundamentals 모의고사에 참여했다.
이 모의고사는 Toss의 프론트엔드 개발자 채용에서 실제로 사용했던 과제를 풀어보는 서비스인데, 단순히 문제만 푸는 것이 아니라 다른 사람들의 코드를 보고 토론할 수 있으며, 라이브 해설 강의까지 제공된다니 참여하지 않을 이유가 없었다.
과제 제출
요구사항을 훑어보던 중, 가장 강조된 문구가 눈에 들어왔다.
서비스의 유지보수나 장기적인 확장성을 고려한 설계, 추상화 관점에 집중해서 기능을 구현해주세요.
이 문장을 보자마자 생각이 많아지기 시작했는데, 결과적으로 이것이 패착이었다.
- 컴포넌트와 함수의 네이밍은 어떻게 명확하게 할까?
- 컴포넌트 분리는 어느 수준까지 해야 할까?
- 상태를 부모 컴포넌트에서 관리해서 내려줄까, 아니면 전역 상태 도구를 도입할까?
- 폴더 구조를 어떻게 하지? 응집성을 위해 pages 내부에서 분리를 할까? 아니면 FSD 이론을 어느 정도 적용해서 관심사를 분리할까?
- 라이브러리는 어떻게 사용을 해야 할까?
- README 작성까지... 시간이 될까?
지금 다시 생각해도 고민거리가 많은데, 과제를 풀 당시에는 훨씬 더 복잡한 생각들이 머릿속을 채웠던 것 같다. 차라리 침착하게 요구사항을 먼저 분석하고, 기본적인 구현을 마친 뒤에 설계를 다듬었으면 훨씬 나았을 것이라는 아쉬움이 든다.
라이브 세션
라이브 해설에는 평소 블로그 글을 인상 깊게 읽었던 재엽님과, 원티드 프리온보딩을 재밌게 강의해주셨던 종택님이 나오셔서 혼자 반가운 마음이 들었다.
세션은 실시간 코딩, PR 및 Discussion 리뷰, Q&A로 구성되었는데, 보는 내내 고개를 끄덕이고 감탄하느라 바빴다. 새삼 공부 더 해야겠다는 자극을 강하게 받은 유익한 시간이었다.
배운 점
라이브를 통해 배운점들을 정리해봤다.
useState는 '구현'
const [view, setView] = useState();
단순히
view를 관리하는 상태처럼 보이지만, 이는 전역 상태, 브라우저 스토리지, URL 등 다양한 방식으로 구현될 수 있다. 이것 또한 추상화의 영역이다. (useState만이 아니라 다른 부분에서도 ‘구현’이라는 말을 많이 하셨다. 이건 그냥 예시..)
- 인터페이스는 표준을 따르자
컴포넌트 인터페이스 설계 시 불필요한 창의력보다는 일반적인 인터페이스를 따르는 것이 좋다. (Input은 Input답게!)
- Props Drilling
Props Drilling을 해결하기 위해 무조건 전역 상태를 도입하는 것은 좋지 않다. Drilling은 주로 역할 분리가 제대로 되지 않았거나, 하나의 컴포넌트가 너무 많은 책임을 질 때 발생한다. 구조적인 역할 분리를 통해 해결하는 것이 우선이다.
-
이상적인 형태를 먼저 떠올리자
코드를 작성하기 전, 요구사항 문서를 보고 이상적인 구조를 먼저 상상하는 습관을 들이자. -
UI와 코드는 1:1 매핑
UI를 지나치게 쪼개려 하지 말고, 시각적인 UI 구조와 코드의 형태가 매핑되도록 작성하면 유지보수하기 좋다.
- 추상화와 재사용성
책임 단위로 올바르게 추상화를 하면 재사용성은 자연스럽게 따라온다.
마치며
비록 요구사항 충족에 급급해 생각만큼 구현을 다 마치지는 못했지만, 모의고사라는 프로세스를 경험해 본 것 자체가 좋았다. 다른 분들의 코드를 보며 배운 점도 많았고, 깃허브 디스커션에서의 수준 높은 토론들을 보며 생각의 폭을 넓힐 수 있었다.
사람은 생각하는 동물이다. 앞으로도 구현에만 매몰되지 말고, 끊임없이 생각하고 고민하는 개발자가 되어야겠다.
