
얼마 전 링크드인에서 토스 Frontend Fundamentals 모의고사를 모집한다는 글을 보게 되었습니다. 평소 프론트엔드 설계나 구조에 대한 고민이 많았던 터라 망설임 없이 신청했습니다.
기획서를 받고 자신 있게 구현을 시작했습니다. 기능 자체는 어렵지 않았지만, 문제는 습관에서 발생했습니다. 요구사항을 충분히 구조화하지 않은 채, 평소처럼 IDE부터 열고 코드 먼저 살펴보고 구현하기 바빳습니다.
구현 중간쯤 다다르자 구조가 어색하게 꼬이기 시작했습니다. 어떤 컴포넌트가 어떤 책임을 가져야 하는지 경계가 모호해졌고, 결국 구현을 멈추고 인터페이스를 다시 정리해야 했습니다. 그제야 전체 흐름이 명확해졌지만, 이 과정에서 꽤 많은 시간을 허비해야 했습니다.
이후 해설 강의를 들으며 가장 뼈저리게 느낀 점은 "인터페이스부터 떠올려라"는 조언이었습니다. 코드를 작성하기 전, 요구사항 문서와 구현예시 UI를 보고 이상적인 형태가 무엇인지 머릿속으로 먼저 그려보고 인터페이스 먼저 구현해보는것이 핵심이었습니다.
특히 UI 형태와 코드 구조가 1:1로 대응되는 것의 중요성을 다시금 깨달았습니다. 텍스트까지 전부 상수로 분리하던 제 습관이 사실은 코드의 이정표를 스스로 가리고 있었다는 점도 알게 되었습니다.
커스텀 훅에 대한 설명도 인상적이었습니다.
value와 setter가 있다면 useState처럼 생겨야 한다는 것, 즉 훅은 새로운 패턴을 창조하는 곳이 아니라 구현을 숨기는(추상화) 용도여야 한다는 것입니다. 상태 관리나 동기화 로직은 훅 내부로 숨기고, 사용하는 쪽에서는 view와 setView만 알면 되는 구조가 이상적인 추상화라는 설명이었습니다.
Prop Drilling과 Suspense에 대한 관점도 명쾌하게 정리되었습니다. Props가 깊어진다고 무조건 전역 상태를 도입할 것이 아니라, 컴포넌트의 위계를 조정하거나 Children Composition을 활용해 해결해야 한다는 점, 그리고 Suspense는 단순한 로딩 처리가 아니라 성공 케이스만 다루게 해주는 깔끔한 경계라는 점이 크게 와닿았습니다. useSuspenseQuery를 통해 컴포넌트가 isLoading, isError 같은 분기 없이 온전히 준비된 데이터만 다루게 하는 것이 핵심이었습니다.
인터페이스를 먼저 그릴 것.
UI와 코드를 1:1로 대응시킬 것.
미리 재사용할 것 같아서 성급하게 추상화하지 말 것.
책임 단위로 적절히 추상화하면 재사용성은 자연스럽게 따라온다
등등 너무 많은 인사이트가 있어서 행복한 하루였습니다. 너무 재밌었어요.
이렇게 공짜로 많은 걸 얻어가도 되나싶습니다.
항상 최전선에서 많은 정보들을 나눠주시는 Toss FE Chapter여러분들께 감사의 인사를 올립니다.
감사합니다.. 덕분에 많이 성장해요