참여 계기
최근 "확장성 있는 프론트엔드 구조", "응집성과 모듈성", "관심사 분리", "추상화" 등 실제 코드에 적용하기 어려운 주제들에 대해 고민하던 중, LinkedIn을 통해 토스 Frontend Fundamentals 모의고사를 알게 되었다. 토스 과제를 직접 풀어보고 해설까지 들을 수 있는 흔치 않은 기회라고 생각해 바로 신청했다.
토스 측에서는 과제전형에 대한 잘못된 정보(README 작성, 테스트 코드 작성 필수 등)가 퍼지는 것을 바로잡고, 과제의 출제 의도와 평가 기준을 명확히 알리기 위해 이 모의고사를 기획했다고 한다.
진행 절차
모의고사는 다음과 같은 순서로 진행되었다.
- 모의고사 관련 안내 받기
- 과제 진행/Pull Request를 통한 제출
- 깃허브 디스커션에서 토론
- 모의고사 해설 강의 듣기 (라이브 스트리밍)
모의고사의 핵심 요구사항은 "서비스의 유지 보수나 장기적인 확장성을 고려한 설계, 추상화 관점에 집중"하는 것이었다.
초반에는 폴더구조나, 컴포넌트 분리 측면에서 고민하다가 기능을 구현할 시간이 부족해져서 유지보수와 추상화 관점에서 고려를 하지 못 해 아쉬운 부분이 있었다.
배운 내용
인터페이스 우선 설계
해설에서는 코드를 작성하기 전에 이상적인 인터페이스를 먼저 그려보는 방법을 보여주었다. 화면 요구사항을 보고 UI와 1:1로 매핑되는 코드 구조를 상상한 후, 실제 구현된 코드와 비교하며 간격을 파악하는 방식이었다.
이렇게 설계하면 UI와 코드가 자연스럽게 매칭되어 요구사항 변경 시 수정 지점을 쉽게 찾을 수 있다. 먼저 구현을 하려고 하다보면, 코드에서 구현되지 않은 부분들을 채워넣고 싶다는 생각이 들 것이고, 중요하지 않은 부분에서 시간을 쓰게 될 확률이 높아진다.
→ 인터페이스를 나중에 변경하는데 드는 시간이 더 크다.
추상화 레벨의 적절성
페이지 컴포넌트에서 적절히 정보를 드러내는 것이 오히려 가독성을 높일 수 있다. 컴포넌트가 많아지면 그때 적절히 책임에 맞게 추상화하면 된다.
너무 과한 추상화는 오히려 코드를 복잡하게 만들고 중요한 정보를 내부에 숨길 수 있다. 데이터나 상태가 어떻게 존재하는지를 중심으로 논리적인 단위로 컴포넌트를 자연스럽게 분리하는 것이 중요하다.
전역 상태 관리의 기준
기존에는 Props Drilling이 어느정도 발생하면 문제 해결을 위해 전역 상태 사용해왔다. 하지만 이번에 Props Drilling만을 해결하기 위해 전역 상태를 도입하는 것은 권장되지 않는다는 점을 배웠다. Props Drilling은 합성 컴포넌트, render prop 등 컴포지션 기법으로 해결하고, 컴포넌트의 위계 관계를 조정하는 것이 우선이다.
→ 전역 상태는 애플리케이션의 여러 부분에서 직접 접근하고 업데이트해야 하는 상태가 충분히 많고 복잡할 때 도입해야 한다.
마무리
짧은 시간이었지만 내가 놓치고 있었던 문제점들을 명확하게 이해할 수 있었던 시간이었다. 앞으로는 다음 기준들을 염두에 두고 개발하려 한다.
- 기능 개발에 앞서 인터페이스 설계
- 무조건 추상화하거나, 무조건 드러내는것을 지양
- 특정 방법론보다 "내 코드가 UI와 잘 매칭되는가?", "유지보수하기 쉬운가?"를 기준
폴더 구조나 특정 패턴보다 코드의 흐름과 읽힘이 더 중요하다는 메시지를 다시 한 번 깊이 새기게 되었다. 결국 단순히 잘게 나누는 것보다 읽기 쉽고 유지보수하기 쉬운 코드가 훨씬 더 가치 있다.
이번 모의고사를 통해 이러한 인사이트를 얻을 수 있는 기회를 제공해준 토스 측에 감사하며 배운 개념들을 바탕으로, 시간이 날 때 과제를 다시 풀어보며 적용해보는 시간을 가져봐야겠다.
