참여하게 된 계기
토스 과제를 직접 풀어볼 수 있는 모의고사 이벤트가 있다고 지인분께서 공유해 주셔서 알게 되었다.
원래 코드 퀄리티에 대해 토론하는 것을 좋아했고, 직접 토스 과제를 풀어보고 해설까지 들을 수 있는 기회는 흔치 않기 때문에 바로 신청했던 것 같다.
모의고사 진행
모의고사 과제는 2시간 내에 적금 계산기 기능을 구현해서 PR을 제출하는 방식이었다.
여러 요구사항이 있었지만 이번 과제에서는 다음과 같은 핵심 요구사항이 있었다.
서비스의 유지 보수나 장기적인 확장성을 고려한 설계, 추상화 관점에 집중해서 기능을 구현해 주세요.
기능 구현 자체는 어렵지 않았지만 유지 보수성을 고려한 인터페이스를 설계하는 게 어려웠던 것 같다.
- 계산기 입력 필드가 늘어난다면 어떻게 변경 지점을 최소화할 수 있을까?
- 금액을 보여줄 때 달러나 엔화도 보여줘야한다면?
- 추천 적금 상품 목록이 사라진다면?
이런 가설들을 세우면서 변경 사항에 유연하고 수정할 때 여러 파일을 수정하지 않을 수 있게 응집도 있는 코드를 작성하려고 노력했던 것 같다.
컴포넌트가 갖는 책임과 역할을 나누고 결합도를 낮추려면 어떤 도전들을 해볼 수 있을지 고민하는 시간이 재밌었던 것 같다.
최근에는 인프라 작업들만 진행해서 코드를 작성 안 한지 2개월 정도 지났었는데 오랜만에 코드를 작성하고 깊게 고민해 볼 수 있어서 너무 유익했던 것 같다.
코드 리뷰 & 디스커션
과제를 제출한 후에는 코드 리뷰와 디스커션에서 토론을 할 수 있는 시간이 주어졌다.
개인적인 사정으로 인해 시간이 없어서 지인분의 코드 리뷰만 진행하게 되어서 아쉽지만, 이 코드 리뷰 과정에서 내가 작성한 코드와 비교해 보고 어느 부분이 다른지, 왜 이렇게 구현하셨을지 구현 의도를 유추해 보면서 많이 배울 수 있었고 내 코드를 다시 돌아볼 수 있어서 좋았던 것 같다.
- 내가 제출 한 PR
- 혹시 읽어보고 의견주실 부분이 있다면 언제든 코멘트 주셔도 좋습니다🙃
- 내가 코드 리뷰 한 PR
디스커션에도 얘기해 보면 좋을 주제들이 많이 올라와서 직접 의견도 남겨보고 다른 분들이 작성한 코멘트를 보면서 많이 배울 수 있었던 것 같다.
모의고사의 취지
해설 방송에서는 모의고사를 진행하시게 된 취지에 대해서도 말씀해 주셨다.
토스 과제가 어렵다, 과제의 채점 기준에 대한 잘못된 정보(README 작성, 테스트 코드 작성 등)가 퍼지는 일이 있어서 과제에서는 어떤 부분이 중요한지, 출제 의도는 무엇인지 설명하기 위해 모의고사 이벤트를 기획하게 되었다고 해주셨다.
배운점
추상화 레벨
해설 강의에서 페이지 컴포넌트에서 추상화를 많이 하지 않고 정보를 드러내셨을 때, 나는 아래와 같은 의문이 들었던 것 같다.
- 다루는 상태나 컴포넌트가 많아지면 페이지 컴포넌트가 너무 복잡하지 않을까?
- 사용하는 상태와 UI 코드가 멀어져서 응집도가 떨어지지 않을까?
하지만 강의를 계속 듣다 보니깐 웹에 비해 모바일에서는 생각보다 한 페이지에서 다루는 컴포넌트가 많지 않고, 만약 많은 컴포넌트를 다룬다면 그때 책임에 맞게 추상화를 할 수 있을 것 같다는 생각이 들게 되었다.
너무 과한 추상화는 오히려 코드를 복잡하게 만들고 중요한 정보를 내부에 숨길 수 있기 때문에 재사용성과 같은 기준으로 추상화를 고려하기보다는 컴포넌트의 책임에 맞게 분리한다면 재사용성은 따라오는 것이라는 점을 깨달을 수 있었다.
이상적인 인터페이스
코드를 작성하기 전에 화면에 맞게 이상적인 인터페이스를 먼저 그려보고 그에 맞게 코드를 작성하는 방법도 배웠다.
이렇게 인터페이스를 설계한다면 UI와 코드를 자연스럽게 매칭하여 직관적으로 요구사항에 대응할 수 있다는 장점이 있다.
구체적인 구현 방식은 나중에 고민해도 되며, 인터페이스는 특정 구현에 의존하지 않는 추상적인 형태여야 한다.
➔ 즉 사용자의 멘탈 모델을 그대로 코드에 반영하는 것과 같다.
또한, props 네이밍은 일반적이고 범용적인 이름을 사용하여, 특정 라이브러리나 도메인에 대한 결합도를 낮추면 컴포넌트의 재사용성과 유지보수성을 높일 수 있다는 이점이 있다.
Props Drilling / 전역 상태
단순히 Props Drilling 문제를 해소하려고 전역 상태를 무분별하게 도입하는 것은 권장되지 않는다.
이런 경우에는 합성 컴포넌트, render prop 등 컴포지션 기법을 활용해 결합도를 낮추고 상태 흐름을 명확히 하는 것이 더 적합하다.
전역 상태는 여러 컴포넌트에서 공유해야 하는 상태가 많고 이를 개별 props 전달이나 컴포지션만으로 관리하기 어려울 때 고려하는게 좋다.
➔ 애플리케이션의 여러 부분에서 직접 접근하고 업데이트해야 하는 상태가 충분히 많고 복잡할 때 도입하고, 그렇지 않은 경우에는 로컬 상태 관리 및 컴포지션 패턴으로 문제를 해결하는 것이 좋다.
후기
과제를 진행하면서 고민했던 부분들을 다른 참가자 분들과 얘기 나눠볼 수 있어서 새로운 관점에서의 얘기들을 많이 들을 수 있었고 여러 인사이트들을 얻을 수 있어서 재밌었다.
또한 해설 강의를 들으면서 내가 너무 과한 추상화를 진행한 것 같아 내 코드를 다시 되돌아볼 수 있는 시간도 가질 수 있었다.
이러한 과정들을 통해 적절한 추상화에 대한 감이 어느정도 잡힐 수 있었던 것 같아서 굉장히 유익했던 시간이였다.
공유해주셨던 자료들
좋은 글 감사합니다!