토스 프론트엔드 모의고사 해설
포인트 요약 🌟
- 화면과 코드 구조는 가능한 1:1로 대응되게 설계하면, 코드를 봐도 UI가 자연스럽게 떠오른다.
- 구현 전에 “이상적인 인터페이스”를 먼저 정의하면, 내부 구현은 교체 가능한 세부사항이 된다.
- 재사용성은 목표가 아니라 결과물이다. 책임 단위로 적절히 추상화하면 자연스럽게 따라온다.
1. 이상적인 인터페이스: 화면과 코드가 1:1로 읽히게
해설 강의에서 강조되었던 부분은 “코드를 치기 전에 먼저 이상적인 인터페이스를 상상하라”는 메시지였다.
UI를 보면서
- 화면과 코드가 어떻게 대응될지,
- 이 컴포넌트를 사용할 때 어떤 형태로 쓰이면 좋을지,
- 어떤 단위로 나누는 게 자연스러운지
를 먼저 그려보면 전체 구조가 빠르게 정리된다.
예를 들어 Input은 “Input처럼 보이고 Input처럼 쓰이는 인터페이스”를 가지면 내부 구현을 보지 않더라도 역할이 바로 떠오른다.
예측 가능한 인터페이스가 가장 좋은 인터페이스라는 것을 다시 느꼈다.
2. 구현은 추상화하고, 표준화된 인터페이스를 따르자
- 상태 관리 도구에 인터페이스를 종속시키지 말자
- 인터페이스는 표준으로, 내부 구현은 추상화하자
예를 들어 view 상태를 관리하고자 할 때,
상태 관리 도구(useState, 전역 상태, URL, localStorage…)는 언제든 바뀔 수 있는 구현 세부사항이다.
그렇기 때문에 인터페이스 자체를 상태 도구에 종속시키지 않는 것이 중요하다.
const [view, setView] = useView(); // 겉으로는 useState와 거의 동일한 인터페이스
인터페이스를 일관적이고 표준적인 형태로 유지하면, 내부 구현을 변경해도 사용하는 쪽은 달라지지 않는다.
3. UI 컴포넌트와 도메인 로직의 분리
컴포넌트 안에서 화면 구조, 스타일, 도메인 로직(필터링, 계산 등) 이 모두 섞여 있으면 읽기 부담이 커진다.
이걸 고급적이게 말하면, “컴포넌트의 추상화 레벨이 너무 낮다”라는 신호다.
강의에서는 필터링 로직 같은 도메인 부분을 따로 모듈로 뺀 뒤
UI 컴포넌트는 화면 구조에 집중하고 도메인 로직은 데이터를 어떻게 만들고 가공할지에 집중하게 하는 구조를 보여주셨다.
이렇게 하면 화면만 수정하고 싶을 때 도메인 로직을 건드릴 일이 줄어들고 도메인 로직을 변경해도 UI는 최소한만 영향을 받는다.
4. 재사용성은 책임 단위로 분리하면 따라오는 것
ProductList를 재사용 가능한 형태로 만들지 고민이 많았었다..
해설에선 재사용성의 기준을 다음과 같이 제시해주셨다.
- 재사용을 먼저 생각하지 말고,
- 책임 단위로 추상화하면 재사용성은 자연스럽게 따라온다
<ProductList filters={...} orderBy="rate" limit={10} />
- ProductList는 리스트를 렌더링하는 컴포넌트
- filters, orderBy, limit은 외부에서 주는 옵션
역할만 명확하게 분리해도 여러 상황에서 막힘 없이 사용할 수 있다.
억지로 재사용을 목표로 쪼개는 건 오히려 코드를 복잡하게 한다는 점을 다시 느꼈다.
후기
이번 해설 강의는 과제를 풀어가는 과정에서 어떤 기준으로 판단하고 결정하는지를 설명해주셔서 정말 유익했습니다.
인터페이스 설계나 좋은 코드에 대한 기준도 새롭게 배울 수 있었고, 앞으로 직접 적용해보면서 더 익혀보고 싶다는 생각이 들었어요.
이런 귀한 경험을 나눠주신 토스 재엽님, 종택님께 감사드립니다! 😁
