• 회사 내에 프론트엔드 구성원이 많지 않은 환경에서 일하고 있는 상태라 다른 회사에서는 어떤식으로 코드를 구현하고 있고, 어떤 점을 집중해서 구현하는지 궁금했었습니다.
• 그런데 링크드인을 통해 Frontend Fundamental의 X 계정에서 선착순 50명으로 실제 토스 프론트엔드 과제를 공개하여 풀어보고, 리뷰까지 해준다는 글을 봤고, 오픈 당일 글이 올라오기를 열심히 기다렸다가 지원했습니다. 14시가 되는 순간 바로 지원했습니다.

기출문제 풀기

• 금요일 저녁에 실제 기출문제가 올라오고, 일요일 오후까지 제출해야 했습니다.

• 유지보수성, 장기적 확장성, 추상화 를 고려한 구현을 해야 한다는 것이 주된 키워드로 들어가 있었습니다.

• 또한 화려한 방법보다 익숙한 방법을 사용해달라는 요구사항이 있었기도해서 최대한 기존에 업무 시 진행하는 방식을 따라 진행하기로 했습니다.

• 구현 순서는 아래와 같이 진행했습니다.

    1. 요구사항 파악
    2. 동작 플로우 파악
    3. 데이터 레이어, 컴포넌트 레이어 설계, 동작 설계
    4. 필요한 라이브러리, 유틸 정리
    5. 파일 및 폴더 구조 정리
    6. TODO 작성
    7. LLM을 통해 단계별 진행하면서 체크
    8. QA

• 구현 중 고민했던 포인트 중 일부를 공유드립니다.

  • zustand vs context api

    • 적금 계산기를 하나의 도메인으로 보고, 이 레벨에서 공통으로 State를 다뤄야 한다는 점을 고정한 상태로 진행했습니다.
    • zustand를 사용할 때 장점 : domain root 레벨에서 zustand store 파일을 추가할 때, 원하는 데이터의 interface를 미리 만들어두고, state에는 필요한 상태에 대한 레이어, set함수 목록에는 컴포넌트에서 진행 시 필요한 action들을 모두 정의해 놓으면, 한 파일 내에서 state와 state흐름을 볼 수 있다는 점에서 고려 대상이 되었습니다.
    • zustand를 사용할 때 단점 : 전역 store를 사용하기 때문에 해당 도메인 페이지를 벗어나는 경우 클린업 동작을 직접 지정해줘야 하며, 도메인 범위의 상태를 전역 레벨에서 가지고 있으면, 상태 레이어 위치가 페이지와 일치하지 않는 점, 메모리 이슈등을 가져올 수 있다고 생각했습니다.
    • context api를 사용할 때 장점 : 공통 도메인 페이지의 상단에 provider를 감싸는 것만으로도 이 컴포넌트가 특정 도메인의 상태 레이어에 속해 있다는 점을 바로 알 수 있다는 장점이 있고, provider가 언마운트되면 상태도 사라지기 때문에 깔끔하게 정리가 가능하다고 생각했습니다.
    • context api를 사용할 때 단점 : 상태 변경 시 provider 하위 컴포넌트가 전부 리랜더링될 수 있으므로 주의해야 함, 업데이트 로직이 위 방법에 비해 상대적으로 복잡하고 코드량도 많아짐
    • 이런 관점에서 zustand를 사용한 store를 통해 상태를 구현했습니다.

• Suspense + errorBoundary vs Tanstack Query의 loading, error 처리

  • 사실 현재 실무에서 suspense를 제대로 사용하지 않고 있어서 기존 사용하던 방식대로 loading, error 처리를 할 것인지 고민하였으나, Suspense로 감쌀 수 있는 포인트가 몇 가지 보여 특정 부분에 적용했습니다.
  • 예를들면 상품 목록 컴포넌트와 필터링 적용 상품 목록 컴포넌트 클라이언트 단에서 필터링 적용을 하는 부분이라서 같은 API에서 가져오는 데이터였습니다.
  • 흐름을 API - Tanstack Query Fetch - Zustand domain state layer update (mapped) - View로 가져갔기 때문에
  • domain state layer와 view 사이에 filter만 추가되는 상황이라 두 컴포넌트 상단에 Suspense, ErrorBoundary를 넣어 선언적으로 처리할 수 있었기 때문에 사용하기로 했습니다.

라이브 해설

• 라이브 리뷰 및 해설을 들으면서 정리한 내용은 아래와 같습니다.

  • 요구사항을 먼저 보고 코드를 떠올린다.
  • UI형태와 코드가 1:1로 있도록 작성한다. (코드가 지도라고 생각하고 축적에 맞춰 작성한다.)
  • 재사용성을 미리 준비하지 않고, 책임 단위로 추상화하면 재사용성은 따라온다.

• 또한 여러 팁들을 많이 알아갈 수 있어서 좋았습니다.

  •  useState를 바로 쓰지 말고 커스텀 훅으로 래핑해 두면 나중에 다른 상태 관리 방식으로 변경하기 용이함
  • 추상화하더라도 UI에서 보이는 Text등을 추상화 바깥으로 꺼내두면 추상화 바깥 컴포넌트 레벨에서도 쉽게 이해할 수 있음 (ex: label, title)
  • 컴포넌트에 프로퍼티를 하나 추가해서 UI를 할당하는 방법 (ex: ProductList.isLoading)
  • ts-pattern을 사용한 필터링
  • 의존성 역전을 활용하여 추상화를 진행하면 위에서부터 밑으로 내려오면서 읽으며 이해할 수 있는 코드를 작성할 수 있음
  • FSD, DDD는 방법론일 뿐, 비슷한 도메인끼리 응집도가 높으면 폴더 구조는 그 다음 문제임

느낀점

• 기본에 충실한 게 중요하다.라는 점을 느꼈습니다.

  • 컴포넌트 위계 정의, 데이터 레이어 설계 등 여러 부분을 고민하면서 작업하지만, FSD, Atomic 등 여러 아키텍처를 공부하고 적용하려고 했던 부분은 더 읽기 쉽고, 유지보수하기 쉬운 코드를 작성하기 위함이었는데, 이런 것보다 한 코드를 작성하더라도 얼마나 더 깊이 고민하고, 작성하는지가 유지보수 및 가독성에는 훨씬 좋다고 느꼈습니다.

• 추상화 레벨을 잘 정리하면서도 가독성이 높은 코드를 작성하기 위해서는 많은 연습이 필요하다는 점을 느꼈습니다.

  • 이건 해설을 듣는 시점은 아니었고, 실무에서 리뷰 때 들었던 내용을 적용해보면서 느꼈습니다.
  • 이전까지는 깔끔한 코드, 의미에 따라 잘 분리되어 있는 코드가 더 읽기 쉽고 깔끔하다고 생각을 했는데, 라이브 해설은 그런 생각을 깨뜨리는 내용이었습니다.
  • 저도 특정 내용을 파악하기 위해 여러 파일을 이동하며 컨텍스트 파악이 어려웠던 점이 있었는데, 오히려 잘 응집되어 있으면서도 적절하게 추상화되어 있고, 내용도 쉽게 이해할 수 있는 코드를 작성하기 위해서 계속 연습하고 있으며, 성장이 정체되어 있다고 생각하던 시점에서 좋은 자극을 주셔서 감사했습니다.

• 코드리뷰를 더 열심히 해야겠다는 생각이 들었습니다.

  • 이번 모의고사를 진행하면서 정말 많은 분들이 논의점과 리뷰를 github에 올려주셨는데요.
  • 하나하나 읽다보니 저런 논의과정에서 생각이 깊이가 깊어지겠구나라는 점을 느꼈습니다.
  • 회사에서는 2~3명 밖에 없는 팀이고 업무가 많아서 리뷰를 꼼꼼하게 볼 수 있는 시간이 많지는 않지만, 지금부터라도 많은 논의를 하기 위해서 열린 질문을 많이 던지려고 노력하고 있습니다.

• 토스에서 이런 좋은 기회를 열어 주셔서 배운점, 느낀점이 아주 많았습니다.
• 앞으로도 이런 기회가 또 생긴다면 주저없이 참여할 것이며, 다른 분들에게도 적극 추천드릴 수 있는 행사였습니다.