토스 프론트엔드 모의고사 후기
참여하게 된 이유
최근에 사이드 프로젝트 리팩토링을 AI의 도움을 받아 가면서 진행하고 있는데, AI의 답변을 보면서도 스스로 의문점이 들었고 이게 과연 맞는 방법일지 어려움을 겪다가 우연히 카카오톡 채팅방에서 토스 프론트엔드 모의고사에 참여할 수 있는 링크를 보게 됐다. 이게 실제 채용에서 이루어진 과제라고 언급했고, 토스 과제를 풀어보는 게 흔치 않은 기회라서 바로 신청했고 어렵지 않게(?) 참여할 수 있게 되었다.
진행
과제 노션에서 가장 인상 깊었던 문구는 ‘서비스의 유지 보수나 장기적인 확장성을 고려한 설계, 추상화 관점에 집중’ 이었다. 과제를 진행하면서 했던 고민이 몇 가지 있었다.
컴포넌트는 어느 정도 길어졌을 때 분리해야 하는지?
그 외에 분리하는 기준이 또 있을지?
커스텀 훅은 어떤 상황일 때 커스텀 훅으로 분리하는 게 적절한지?
컴포넌트가 가지는 props는 몇 개가 적절한지?
커스텀 훅의 경우에는 특정 로직이 여러 파일에 존재하고 있을 때, 적용하는 걸로 알고 있는데, 사이드 프로젝트 리팩토링을 하면서 커서가 무조건 커스텀 훅으로 빼길래 아예 rule로 반복되는 로직이 존재할 경우에만 적용해달라고 넣었는데, 지금 생각해 보면 서비스가 커지거나 기획이 달라질 때 분명 같은 로직을 쓰게 되는 경우가 발생할 수 있을 것 같다고 생각했다.
컴포넌트는 몇 개의 prop을 가져야 가장 적절할까? 또 어떤 걸 prop으로 가지고 있어야 할까? 사실 내 개인적인 기준으로는 2~3개가 가장 적절하다고 생각한다. 그래야 추후에 리팩토링할 때 편하지 않을까…? 사실 한 개로 가져가는 게 베스트라고 생각하지만, 현실적으로 그게 쉬운 작업이 될까 싶다.
그리고 나는 이벤트 핸들러를 prop으로 넘기는 걸 별로 좋아하지는 않는다. 부모 - 자식 관계의 컴포넌트에서 자식 컴포넌트 자체가 이벤트 핸들러를 컨트롤 할 수 있게 하면 되지 않을까? 사실 이 부분은 설계를 많이 해보면서 얻는 경험치라고 생각하기 때문에 앞서 생각했던 것도 언젠가는 바뀔 수도 있을 것 같다.
배운 내용
개인 일정 때문에 라이브 스트리밍을 모두 듣지는 못했지만 봤었던 부분까지에 대해서만 작성해 보려고 한다.
기획 꼼꼼히 읽어보기
기획서가 나왔다고 해서 바로 코드 작성에 돌입하는 게 아니라 기획서를 자세하게 읽어보고 코드를 어떻게 작성할지 상상하는 게 좋다고 하셨다.
지금 하고 있는 개인프로젝트도 기획서가 따로 있는데 남은 기능에 대해서는 요구사항을 꼼꼼히 읽어보고 어떻게 로직이나 컴포넌트를 설계할지 잘 생각해 봐야겠다.
화면과 코드를 맞추자
라이브 코딩 방식으로 진행을 하셨는데, 마크업을 보시면서 화면과 코드를 1:1 매칭시키는게 정말 신기했었다..물론 경험치가 달라서 그렇겠지만..아무튼 화면과 코드가 일치할 정도로 구현된게 가장 이상적인 인터페이스이고, 그래야 변경되는 요구사항에 대응하기 쉽다.
불필요한 추상화 금물
최근에 불필요하게 UI를 추상화하다가 디버깅하는데 시간을 꽤 잡아먹은 기억이 있는데, 좀만 길어지면 ‘아 바로 분리해야지!’라고 추상화해 버리는 나쁜(?) 버릇이 생긴 것 같다. 필요할 땐 데이터에 대한 정보를 직접 드러내는 게 오히려 좋다.
컴포넌트 코드를 분리하면서 해당 컴포넌트 네이밍을 고민할 바에 차라리 직접 정보를 노출하는 게 개발 생산성에 있어서는 더 나을 것 같다.
props drilling의 원인
라이브에서 언급하셨던 두 가지 원인은 다음과 같다.
하나의 컴포넌트가 너무 많은 역할을 하고 있음
상태가 제대로 역할에 반영되지 않음
이를 해결하기 위한 용도로 합성 컴포넌트라고 말씀하셨는데 이 부분에 대해서 말은 많이 들어봤지만 이번 기회를 통해 더 공부해 보고, 지금 하고 있는 프로젝트에도 한 번 반영해 보고 싶다.
마무리
이번 과제를 하면서 어떻게 컴포넌트를 나누고 어떻게 UI를 보여줄지에 대한 부분만 고민했었는데, 다른 분들이 올리신 PR을 보니, 내가 올린 PR과는 차원이 달라도 한참 달랐다. 기획이 달라지거나 서비스가 커질 경우를 대비해서 몇 수 앞을 내다보고 코드를 작성하신 것 같다.
내 코드만 신경쓸 게 아니라 다른 분들이 작성한 코드도 보면서 비교해 보는 것 또한 좋은 공부라고 생각한다.
