세미나 과제
과제 제출 레포지토리: https://github.com/37-dive-sopt-web/YujinJung
매주 세미나가 끝난 후 과제가 주어졌는데, 기초적인 html&css&js부터 React까지 웹 개발 전반에 대한 구현을 경험해볼 수 있어서 각 단계를 깊게 공부해볼 수 있는 좋은 기회였다.
각 주차별 과제 구현 방법 및 구현 정도는 상단 레포지토리를 통해 확인할 수 있다.
또한 단순히 구현에만 그치는 것이 아니라, 솝트에서 처음으로 구현 과정 및 각 구현을 하면서 내렸던 결정들을 pr에 녹여서 자세히 작성해보면서 구현할 때 이외에 추가적으로 다시 한 번 공부가 된다고 느낄 수 있었다.
pr뿐 아니라 솝트 내 정착되어 있는 코드리뷰 문화도 너무 좋았다. 부끄러운 말이지만 솝트에 들어오기 전까지는 코드리뷰를 직접 달거나 경험해 본 경험이 전무했는데 처음으로 다른 사람들에 대한 코드들을 보며 똑같은 결과를 위해서 정말 많은 구현 방법이 있다는 것을 느낄 수 있었고, 다른 사람들의 코드들이나 결정 과정들을 보며 새로운 기술이나 구현 방법도 많이 알 수 있어서 너무 도움되는 과정들이었다.
과제를 제출 후 파트장님이 매주 그 주의 과제왕을 선별해주시는데, 너무 감사하게도 2주차 코드리뷰 우수조와 4주차 과제왕에 선발되는 결과도 얻을 수 있었다.
스터디
솝트에서는 공부하고자 하는 스터디에 들어가 웹 개발에 대해 더 깊이 공부할 수 있는데, 나는 '리엑트 심화 스터디'와 '성능 최적화 스터디'에 들어가 관련 내용을 깊이 있게 공부하고, 공부한 내용을 바탕으로 아티클을 작성하며 스터디원들과 서로 공부했던 내용을 공유할 수 있었다.
리엑트 심화 스터디 내용 중에는 평소에 제대로 알지 못하고 가져다 쓰기만 하던 기술들을 깊이 있게 원리와 사용 방법 등을 공부해보고, 이를 직접 실습과도 연결지어볼 수 있어서 좋았다.
또한 성능최적화 스터디를 들어갔던 이유가 평소 '성능최적화'라는 단어만 접해봤지, 실제로 구현에 적용해보거나 공부해본적이 없었는데 이를 경험해보고 싶어서였다. 웹 성능최적화에는 정말 다양한 방법이 존재하고, 스터디에 들어가서 성능최적화에 대해 공부해본 덕분에 합동 세미나와 솝트 밖에서 했던 프로젝트에도 직접 공부한 내용을 적용해볼 수 있는 값진 경험을 얻을 수 있었다. 앞으로 앱잼에서 구현했던 서비스에도 스프린트 기간에 성능최적화에 대해 조금 더 깊게 공부한 후 이를 차차 적용해보고자 한다.
리액트 스터디 커리큘럼
성능최적화 스터디 커리큘럼
공부한 성능최적화를 적용해본 pr: https://github.com/DdingSroom/dding-sroom-frontend/pull/229
합동 세미나 - 티켓베이
합동 세미나에서는 타 파트인 서버, 디자인, 기획과 직접적으로 소통하며 협업의 형태를 갖춘 채로 서비스 하나를 만들어보는 값진 경험을 해볼 수 있었다.
나는 '티켓베이'라는 티켓 중개 거래 표 거래 플랫폼을 리디자인 및 리기획한 서비스를 개발하게 되었는데, 그 중에서도 '티켓 상세 페이지'를 담당하게 되었다. 티켓 상세 페이지의 ui 퍼블리싱부터 api 연동까지 하나의 서비스의 웹 개발 전반에 대한 경험을 얻을 수 있어서 좋았고, 겨울에 있을 앱잼을 대비할 수 있어서 좋았다.
노션에 각자 맡은 작업의 작업 상태를 실시간으로 체크하면서 구현을 진행했는데, 나는 초기 세팅 중 icon svgr, axios, 절대 경로를 담당하게 되었다. 공통 컴포넌트로는 버튼 컴포넌트와 Tabbar 컴포넌트를 담당하게 되었다. 또 티켓 상세 페이지에 있는 티켓 상세 조회 api 연동을 담당했다.
아무래도 혼자서 과제를 해내는 것이 아니라 같은 파트 내에서도 4명이 힘을 합쳐 하나의 결과물을 만들어내야 하는 과정이었기에, 같은 파트내에서도 서로의 코드를 보고 리뷰를 달며 새로 배울 수 있는 것도 많았고 협업의 형태를 갖춰서 서비스를 만들어낼 수 있어서 뿌듯했다.
특히 전에는 서비스를 개발할 때 단순히 api 연동까지만 진행하고, 후의 과정인 리팩토링을 제대로 진행해본 적이 없었는데, '티켓 상세 페이지'에 진입했을 때 지도 이미지가 바로 불러와지지 않아 ux적으로 불편함을 초래해 이를 '스켈레톤 적용'이라는 리팩토링으로 해결해볼 수 있어서 좋은 경험이었다.
합동 세미나 레포지토리: https://github.com/SOPT-all/37-COLLABORATION-WEB-TICKETBAY
앱잼 - 컴핏
앱잼에서는 약 5주 간의 시간 동안 실제 출시를 위한 서비스를 만들게 되었는데, 나는 '컴핏'이라는 '지원자의 경험과 기업을 연결해주는 자소서 추천 서비스'를 개발하게 되었다. 앞전의 3주 간의 시간 동안에는 서비스 기획과 디자인으로 인해 본격적인 개발을 들어가진 못했고, 그동안 웹 파트에서는 초기세팅을 진행했다. 나는 zustand와 storybook, tanstack query 초기세팅을 진행하게 되었고, 세가지 초기세팅 모두 이번 앱잼에서 처음 담당해보는 것이었기에 진행하면서 각 초기세팅의 필요성과 서비스 내에서 어떤 역할을 하는지 공부해볼 수 있어서 좋았다. 각 초기세팅에 대한 작성했던 기술 블로그도 아래에 첨부하겠다.
storybook 기술 블로그: https://same-cricket-7d1.notion.site/2-Storybook-2dd70a834882800da24cfd0d732e5735?source=copy_link
zustand 기술 블로그: https://same-cricket-7d1.notion.site/1-Zustand-2d870a834882803ba6afc3249368674b?source=copy_link
공통 컴포넌트 중에는 alert 컴포넌트와 input 컴포넌트, input 자동완성 컴포넌트를 담당하게 되었고, api 연동은 경험 등록 페이지 내 아래와 같은 5개 api 를 담당하였다.
이번 앱잼에서 특히 기억에 남는건 웹 파트원들과 함께 React 내에서 FSD 폴더 구조를 채택한 점이었는데, 처음 팀원들과 폴더 구조를 잡을 때 어디까지 FSD 구조를 가져와서 사용할 지 많이 고민했던 기억이 난다.
우리 '컴핏'서비스의 규모를 고려하여 최종적으로는 아래와 같이 FSD 구조를 가져가기로 결정했다.
src
┣ app // 프로젝트 초기화, 라우팅 설정 등
┃ ┣ layout
┃ ┣ providers
┃ ┣ routes
┃ ┣ styles
┃ ┣ App.tsx
┃ ┗ main.tsx
┣ features // 도메인 단위로 컴포넌트 관리
┃ ┣ bookmark
┃ ┣ company-analyze
┃ ┣ experience
┃ ┣ home
┃ ┣ login
┃ ┣ my-page
┃ ┣ onboarding
┃ ┗ register
┣ pages // 도메인 단위로 페이지 관리
┣ shared // 공유되는 항목들
┃ ┣ assets
┃ ┃ ┣ icons
┃ ┃ ┣ icons
┃ ┃ ┗ images
┃ ┣ config
┃ ┣ lib
┃ ┣ model
┃ ┣ stories
┃ ┣ styles
┃ ┃ ┣ tokens
┃ ┣ types
┃ ┗ ui
┗ widgets // 의미적으로 구분되는 컴포넌트(header, company-card 등)이 과정에서 구조는 “이론적으로 좋은 것”이 아니라 “팀 규모와 서비스 복잡도에 적합한 것”이어야 한다는 점과 디렉토리 구조는 곧 관심사의 분리 전략이라는 점, 초기에 기준을 명확히 잡아두면 이후 기능 확장에서 혼란이 줄어든다는 점을 배울 수 있었다.
FSD 구조 뿐 아니라 css library는 vanilla-extract을 사용하기로 했는데, 둘 다 합동 세미나 때 잠깐 경험해본 것이 다였기에, 이번 경험을 통해 더 깊게 사용해볼 수 있어서 좋은 시간이었다.
합숙을 하는 약 2주 간의 시간 동안 기획, 디자인, 서버 파트와 끊임없이 소통하며 서비스를 최종적으로 완성할 수 있었다.
컴핏 FE 레포지토리: https://github.com/TEAM-COMFIT/COMFIT-CLIENT
컴핏 서비스 링크: https://www.comfit.co.kr/
하나의 서비스를 기획, 디자인, 서버, 웹 파트가 협업하여 QA까지 진행해본 적이 나는 처음이었기에 목적 기업의 전반적인 개발 플로우를 경험해볼 수 있어서 좋은 경험이었다고 생각한다.
또한 개인적으로는 아직 기술적으로 많이 부족하다는 생각을 하게 되어 앞으로 끊임없이 깊이 있는 웹 공부를 해야 겠다고 다짐한 시간이었다.
앱잼에서 어떤 기술을 어떤 근거로 선택했고, 그에 대한 구현 과정 및 방법은 별도의 글로 정리해보도록 하겠다.
행복앱잼이어따 🩷
웨비톡
웹 파트 마지막 세미나 시간에 '웨비톡'이라고 각자 공부한 기술에 대해 발표 형식으로 소개하는 시간이 있었다. 나는 'TanStack Query로 실시간 데이터를 다루는 방법'라는 주제로 웨비톡을 진행하게 되었다.
WebSocket + useState 방식이 왜 규모가 커질수록 취약해지는지 설명하고, 문제의 원인이 WebSocket이 아니라 서버 상태를 로컬 상태로 관리하는 구조에 있음을 짚었다.
이후 실시간 데이터도 결국 Server State라는 관점으로 재정의하고,
그 기준점은 Query Cache, 프론트엔드는 관리가 아니라 동기화, WebSocket은 데이터 전달이 아니라 invalidate 신호 역할이라는 구조로 정리했다.
결론적으로, 실시간은 기술 선택의 문제가 아니라 서버 상태 동기화 설계의 문제라는 메시지를 전달했다.
웨비톡 발표를 통해 TanStack Query를 단순한 패칭 도구가 아니라, 서버 상태 관리 전략으로 이해하게 되었다.
웨비톡 발표 영상: https://www.youtube.com/watch?v=7zQyLfhrzu8&list=PLKpZBRN3fDmPuCP3WBgxTh4M6iv6V5kav&index=2
번개 & 뒷풀이 ⚡️
솝트에 들어오기 정말 잘했다고 생각한 이유 중에 최고는 기술적인 발전, 협업 경험 획득 등도 아닌 당연 '좋은 사람'들을 많이 만난 것일 것이다.
원래는 갑작스러운 약속은 잘 안나가는 내가, 솝트 사람들이라면 가리지 않고 나갈 수 있으면 거의 모든 번개와 뒷풀이에 참여했던 것 같다.
같이 즐겁게 놀고, 또 필요할 때는 진지하게 기술, 개발 이야기를 하며 반 년동안 솝트 사람들 덕분에 인격적으로도, 기술적으로도 충분히 성장할 수 있었던 감사한 시간이라고 생각한다.
37기가 끝난 현 시점, 내가 다시 한 번 38기 ob로의 도전을 하려는 이유도 아마 '좋은 사람'들을 만날 수 있게 해준 솝트의 매력에 푹 빠져서일 것이다.
37기 YB로써 받았던 감사함과 좋은 영향력을 38기에는 내가 OB로써 다른 사람들에게 또 한 번 베풀어 줄 수 있는 좋은 기회가 있으면 좋을 것 같다.
웹계인들 사랑해 👽🛸🖤
