본문 바로가기

개발/개발일지

지역 중고거래 및 정보교류 커뮤니티 프로젝트 마이그레이션 후기(1차)

원티드의 프론트엔드 코스를 마무리하고나서, 협업에는 익숙해졌기에 내가 혼자서 코드를 구현하고 구조를 고민하고 만드는 것에 대한 갈증을 느꼈다. 동시에 협업을 하면서 사용했던 vite의 성능 측정을 하고 싶었고, 잘 모르던 상태에서 했던 기존 코드를 개선해보는 경험이 있다면 기존 서비스를 유지 개선하는 역할을 맡게 되더라도 더 자신있게 맡을 수 있을 것 같았다. 그래서 당근마켓 디자인을 기반으로 클론했던 지역 중고거래 및 정보교류 커뮤니티 프로젝트를 개선해보고자 했다. 

 

github repo link: https://github.com/jong6598/daangn_FE_refactoring

 

GitHub - jong6598/daangn_FE_refactoring: 지역 중고거래 및 정보교류 커뮤니티 프로젝트

지역 중고거래 및 정보교류 커뮤니티 프로젝트. Contribute to jong6598/daangn_FE_refactoring development by creating an account on GitHub.

github.com

 

프로젝트를 진행하면서 우선 순위에 두었던 점은 다음과 같다.

 

1. 관심사 분리를 통해 유연성을 높이고, 책임을 명확하게 나누자.

2. 유저 행동을 측정할 수는 없지만 예측해서 경험 개선을 위한 기능들을 추가하자.

3. 문서화를 통해 다른 사람이 보아도 이해할 수 있는 레포지토리를 만들자.

 

이정도를 우선순위에 두고 작업했다. 


팀으로 하는 프로젝트가 아닌 개인으로 하는 리펙토링이었기 때문에

자유도가 높고, 폴더구조나 프론트단에서 컨트롤 할 수 있는 기능들에 대해서 고민하고 추가할 수 있다는 점이 좋았다. 

하지만 변수명이나 코드의 직관성 등에 대해 고민할때 같이 물어볼 수 있는 동료의 부재를 크게 느꼈던 것 같다. 그래서 최대한 내가 참고한 레퍼런스들을 공유하고, 나의 코드들을 공유하기 위해 기존 활동하던 커뮤니티나 블로그에 공유를 했다. 


(+ 커리어리라는 플랫폼 QnA에서 지식공유를 하기 위해 노력하고 있다. 지식공유를 할 수 있는 개발자로 성장하기 위한 몸풀기로 생각하면서 내가 아는 부분들에 대해 더 고민해볼 수 있는 좋은 기회인 것 같다)

 

실제 유저를 모으고 서비스를 하지 않아서 아쉬웠던 점은 다음과 같았다.

 

- 에러바운더리 처리에서 사용할, 에러 상황에 대해 데이터가 많이 없다보니 세분화가 덜 되어서 아쉽다. 
- skeleton UI 적용시 빠른 환경에서는 화면 깜빡임 현상처럼 보일 수도 있을 것 같은데, 이걸 유저 데이터가 있으면 대부분의 유저의 평균 로딩시간을 파악하고, 이를 기준으로 skeleton의 적용 시간을 분기할 수도 있을 것 같다 (데이터와 함께 한 UX 개선을 너무 하고싶다..) => 방법이 생각나서 적용중(블로그링크 첨부예정)

 

기획면으로 고민했던 점

사실상 백엔드 배포를 부탁하고, 서버 단 에러가 발생할 때 직접 코드를 보거나 레퍼런스를 찾아가면서 변경될 코드를 작성하고 부탁하여서 진행한 리펙토링인 만큼, 새로운 기능을 추가하기에 난관이 있었다(물론 기존 기능중에 아직 구현하지 못한 것들도 있다.. 더 나은 방법이 있을까 고민중)

당근마켓이라는 서비스의 "동네 이웃간의 연결을 도와, 따뜻하고 활발한 교류가 있는 지역사회를 만드는 것” 이라는 목표를 고려했을때, 두가지 확장 방향이 떠올랐고 하나는 직접 구현해 보기도 했다.

 

1. 실종자 배너 추가 

 커뮤니티에서 실종이나 유기견 등의 문제가 발생했을때 인스타그램이나 트위터 같은 서비스 외에 당근마켓에도 정보를 올린다는 이야기를 듣고 실종배너가 중고거래 리스트 상단에 있으면 좋을 것 같다는 생각을 했다. 지역 기반의 서비스인 만큼, 동네에서나 인근에서 이런 목격자들을 좀 더 쉽게 발견할 수 있지 않을까라는 생각을 했다. 사실 코드적으로는 많은 것이 필요한 건 아니었지만, back-end를 거치지 않고 배너를 on-off 할 수 있게 구현하기 위해 localStorage를 사용하고, 버튼에 애니메이션을 준다거나, 배너 유무에 따른 view 포트 사이즈 조절 등 고민할 것들이 많았던 것 같다.

 

기존 서비스

 알고보니 기존의 서비스에서는 동네생활에서 분실/실종센터에 접속해서 볼 수 있게 이미 구현이 되어있었다. 하지만 직접 찾아서 들어가지 않으면 볼 수 없는 구조는, '정보를 등록하는 사람 외에는 자주 들어올까?' 라는 생각을 하게 했다. (활성화의 문제점? 실제로 분실/실종센터 탭이 많이 활성화된 것 같지 않았다. 좋아요 갯수나 댓글 수, 몇개의 게시물을 들어갔을때 제보보다는 글에 대한 공감하는 내용들이 주를 이뤘다.)

 

 확장방향

배너로 사용해서 노출도를 증가시키고 (대신 데이터나 이런것들을 통해 노출기준을 마련하는 것이 좋을 것 같다),  실종자 정보를 등록했을때, 범위 설정을 통해 반경이나 인접한 지역을 기준으로는 배너를 모두 띄워주는 방식으로 구현된다면, 좀 더 효과적인 방향으로 사용될 것 같다. (+ 기업 이미지 제고)

 

README로 확인하기: https://github.com/jong6598/daangn_FE_refactoring/blob/main/README.md

 

2. 채용서비스 제공 (아이디어 구상중)

 당근은 현재 동네가게, 동네홍보 등을 통해 유저와 유저가 직접 채용을 할 수 있는 서비스를 제공하고 있는 것처럼 보인다. 이걸 좀 더 확장 할 수 없을까 라는 생각을 했다. 

 

 확장방향

 기존 매너온도 등을 채용기업에 제공하거나, 기업의 경우 타 플랫폼의 평점처럼 매너온도를 사용하여 실제 근무자들이나 고용주들이 평소 서비스 이용 매너를 통해 상대를 판단할 수 있는 기준을 주는 것도 가능할 것 같다. 물론 이렇게 되면, 좀 더 매너있게 당근을 사용하려는 사람들도 늘어서 긍정적인 시너지 효과를 낼 수 있지 않을까? 라는 생각이 든다. 조금 더 구체화시켜서 정리해보고 적용하고 싶다.


이외의 주절주절한 느낀점..

 

이게 내가 짰던 코드가 맞나...? 웅장하게 마이그레이션을 해야겠다! 했지만 기존의 코드를 알아보는데 또 시간을 써야하는 불상사가 생겼었지...(내가 짠것도 다시 분석을 하고 있으면 다른 사람 코드는 어떻게 마이그레이션 하겠냐구요...) 이러면서 가장 생각을 했던 부분은 아..이래서 기록..기록하는구나 였다. 마이그레이션 이전 프로젝트에 대해 README라도 남겨뒀다면 얼마나 좋았을까하는 후회가 들었다. 하지만 후회는 후회를 낳을뿐! 현재는 PR과 ISSUE, README를 컨벤션을 정해두고 잘 정리하는 좋은 습관이 생겼으니 되었다!

 

 

아직 못한게 많다. 기존에 있었던 채팅도 못했고,,, 새로운 줄 알았던 실종정보 배너는 알고보니 동네정보에서 활성화 할 수 있는 탭이 있었다..역시 똑똑한 사람들이 모인 회사는 나보다 한발자국 빠르다. 그치만 이렇게 고민해보면서 아이디어를 내다가 보면 앞으로 갈 회사에서 좋은 아이디어를 낼 수 있지 않을까? 라는 생각으로 기록들을 하나씩 남겨두려고 한다. 중.꺾.마.

출시를 목표로 한 프로젝트에 투입되어서 GraphQL과 Next.js를 사용하게 되었다. typeScript를 좀 더 배우기 위해 <이펙티브 타입스크립트> 책을 읽고 있다. 프로젝트가 마무리되고 타입스크립트에 대한 인사이트가 더 추가되면 기존의 이 당근마켓 프로젝트 또한 계속해서 리펙토링하면서 완성도를 높이고 싶다.


함께 읽어볼만한 글

이 글은 서비스 전반적으로 생각한 것들을 위주로 다루고 있기에, 회고를 읽다가 혹시나 흥미가 생겨서 더 알아보고 싶다면 아래 글들을 읽어보는걸 추천한다! (동일한 필자의 글로, 짧은 분량은 아니지만 재밌다. 앞광고 맞다!)
https://jong6598.tistory.com/34

 

Optimistic UI(낙관적 UI)

Optimistic UI(이하 옵티미스틱 UI) 에 대해 알아보자! 기존의 버튼 인터랙션 1. 사용자가 버튼을 클릭 2. 버튼이 비활성화 상태로 바뀜 3. 서버에 신호가 전달되고 4. 서버에서 다시 페이지로 응답을

jong6598.tistory.com

https://jong6598.tistory.com/35

 

ErrorBoundary 심층 적용기

기존의 에러바운더리 적용 방식은 Global ErrorBoundary 라고 명명할 수 있을 것처럼 전체를 감싸는 에러바운더리를 작성해서, 잘못된 페이지를 접속했거나, 요청이 잘못되었을 때 등 발생하는 에러

jong6598.tistory.com