MySurpin 프로젝트 회고

My Surpin 🏄🏻‍♀️🏄🏼‍♂️

---

팀원이 결정되고 아이디어를 정할 때만해도 2주면 넉넉한 시간이니 여러 도전들을 해볼 수 있겠구나 하고 생각했는데 그냥 정말 훅 지나가버렸다. 이번 프로젝트 때 나는 팀장 역할을 맡게 되었고, 프론트엔드 쪽에 집중했다. 페어 프로그래밍은 많이 경험해봤지만, 4명이 함께하는 프로젝트는 처음이었다. 그래서인지 각자 작성했던 클라이언트, 서버 코드를 연결시켰는데 정상적으로 작동했을 때, 그리고 배포 후 팀원들과 우리의 도메인에서 만났을 때 뭔가 당연한 일지만 더 기쁘고 신기하게 와닿았던 것 같다. 팀원들 모두 어려운 점이 생기면 바로 공유하는 분위기이고, 배우려는 의지가 강한 분들로 구성되어 다행이었다. 덕분에 문제가 생겨도 빠르게 해결할 수 있었고, 서로 알려주고 배우면서 다들 많은 걸 배워갈 수 있기도 했다. 무엇보다도 가장 크게 얻은건 이제 혼자가 아니라 여러명이 하나의 서비스를 만들기 위해서는 어떤식으로 협업을 해야하는 지에 대한 전반적인 그림을 그릴 수 있게 된 것 같다. 이제 2주 동안 4명의 팀원이 만든 MySurpin이라는 서비스를 소개해보고자 한다.

 

My Surpin이 무슨 말이야..?

🏄‍♂️ 당신만의 북마크 모음집을 만들어보세요! 🏄‍♀️

인터넷에는 수많은 웹사이트, 서비스들이 있는데 보통 자주 방문하는 유용한 사이트들을 북마크해두고 편리하게 그 페이지로 이동할 수 있도록 한다. 그리고 북마크들이 잔뜩 쌓이는 경우, 보통 폴더로 나눠서 관리를 하는 걸 많이 봤다.

 

또는 Github 레파지토리에 그런 유용한 사이트들을 모아두는 것도 볼 수 있었는데, 굉장히 많은 사람들이 나중에 보기위해 fork를 해가고 있었다. 유튜브 재생목록이나, melon의 멜론DJ 도 자기만의 폴더, 리스트를 다른 사람들과 공유한다는 점에서 비슷한 역할을 하는 것 같아 니즈가 있을 거라는 생각에 아이디어를 제안하게 되었다.

 

이러한 아이디어를 기반으로 정해진 팀원들과 이야기를 나누다보니 다양한 사람들의 북마크 모음을 한곳에서 모아서 볼 수 있다면 유용한 사이트가 될 것 같고, 그런 북마크 모음을 작은 미니홈피 형태로 구경할 수 있도록 만든다면 재밌지 않을까 하는 의견으로 좀 더 구체화되어갔다.

 

북마크들을 폴더별로 관리중인 크롬 상단바

 

My Surpin =My + Surfing + Pin

My Surpin은 My + Surfing + Pin 이 합쳐진 단어이다. 'Surpin'은 웹 서핑의 Surfing🏄‍♂️과 무언가를 고정하는 용도의 Pin📌이 합쳐진 합성어이다. 웹서핑을 하다가 맘에 드는 장소를 발견하면 핀을 꽂아두라는 의미이다. 서핑을 취미로 하시는 팀원분이 계셔서 그 팀원분이 웹 서핑이라는 단어와 연관 지어보는게 어떻겠다는 의견을 주셨다. 다른 팀원분이 그에 더해 핀과 합쳐 서핀이라는 이름을 제안하셨는데, 모두의 맘에 딱 드는 이름이라 바로 결정되었다. 

 

Surpin ?!

---

서핀은 한 마디로 각자의 관심사가 반영된 웹사이트 URL 모음집이다. 위의 북마크 폴더 대신 이렇게 URL 목록들을 관리하고, 공유도할 수 있고, 다른 사람들의 서핀을 구경할 수도 있다 👏🏻 더 이상 브라우저 상단에 꾸깃꾸깃하게 북마크들을 보관하지 말자,,!

 

(왼) 서핀들이 쭉 늘어져있는 모습 / (오) 서핀 클릭시 보이는 url 관리 모달창

 

My Surpin은 어떤 기술로 만들어졌을까..?! 🧐

---

전반적으로는 위와 같은 스택을 사용해 만들었다. 각 스택을 사용한 이유에 대해 간단히 소개하자면 다음과 같다.

 

React

• 컴포넌트의 재사용성 (특히..모달창)
• Class형에 비해 Life Cycle 관리가 쉬움
• 화면을 구성하는 부분들을 컴포넌트 라는 역할, 기능에 따라 쪼개어 독립적으로 관리할 수 있음

Redux

• 상태의 중앙화로 전체 상태 관리 용이
• props를 하나하나 내려주지 않아도 어디서나 다른 컴포넌트 상태에 접근 가능
• 모든 데이터를 스토리지에 저장하기 때문에, 브라우저 종료 후에도 동일 시점부터 재진행 가능 (Redux Persist)

Sass

• 상위 Selector을 참조하므로 클래스명을 여러번 반복해 적는 등의 코드 중복 방지 가능
• 변수사용으로 유지보수 용이
• 높은 가독성

 

My Surpin 본격 구경하기  🌊

---

1. 메인페이지

메인페이지는 서핑의 이미지에 걸맞게 동적으로 작동한다. 리액트의 useRef()로 컴포넌트 DOM의 위치에 접근하게 함으로서 버튼을 눌렀을 때, 해당하는 Section 위치로 이동하도록 했다. 차트 부분은 특정 위치에 도달했을 때 데이터 값을 변화시킴으로써 그래프가 상승하는 듯한 효과를 내도록 구현했다. Navbar 에는 사용자가 언제든지 검색이 가능하도록 고정적인 검색창을 추가해 편의성을 높였다.

 

 

 

2. 제목, 설명, 태그, URL 목록, 썸네일 등을 지정해 나만의 서핀 만들기

2-1. 썸네일 이미지 업로드

Node.js의 Javsscript용 AWS SDK를 활용했다. 정적파일인 썸네일 이미지를 <input>태그로 사용자로부터 입력받아, S3 버킷으로 전달하도록 했다. 전달 후 응답으로 받아온 S3 url을 서버에 다시 전달해 DB에 저장시키고, 이후에는 DB에 저장된 url을 서버로부터 받아와 썸네일을 보여주도록 구현했다.

 

2-1. URL만 입력하면 자동으로 페이지의 Title이 이름으로 입력됨

URL 을 입력하면 해당 URL html의 <title> 부분을 가져오는 함수를 작성했다. 우선 서버 컨트롤러 부분에 axios로 해당 url의 html을 긁어온 후 title 부분만 매칭시키는 정규식을 적용해두었고, 클라이언트에서는 사용자가 url 이름을 입력하지 않으면 자동으로 요청을 보내 title을 가져오도록 했다. 

 

 

2-2. Drag & drop으로 간편하게 url 목록 순서 조정 가능

beautiful dnd 라이브러리를 이용해 url 리스트 순서를 드래그로 간편하게 수정할 수 있도록 해 간편성을 높였다. 추가로, 각 url은 클릭하게되면 해당 웹사이트로 이동시켜준다. 다시 서핀창으로 돌아오기 편하도록 새창을 열어 띄워주도록 했다.

 

 

 

3. 태그 기반으로 서핀 검색

이 부분도 useRef()를 이용해, 페이지의 가장 아래 부분에 스크롤 위치가 도달했을 때 새로운 리스트를 달라고 서버에 요청하도록 했다. 무한스크롤 형태라 모든 리스트가 렌더링 되었음에도 요청이 가는걸 방지하기 위해, 총 검색결과 개수를 미리 서버로부터 받아와 한번에 로딩시키는 개수로 나누어 요청 가능 횟수를 제한하는 조건문을 추가했다.

 

 

 

4. 다른 사람이 만든 서핀 퍼오기

다른 사람들이 만든 서핀을 구경하다가 맘에 드는 서핀을 발견하면, 퍼올수도 있다. 물론 목적에 맞게 수정도 가능하다. 퍼오는 경우에는, DB에서 서핀id를 기준으로 따로 카운트하고 있는 원본 서핀의 인기도가 올라가고, 태그를 기반으로 검색했을 때 이 값을 기반으로 인기있는 서핀 부분의 상단에 올라가게 된다.

 

 

 

5. 클립보드 복사 한번으로 간단하게 공유

나만 알기 아까운 서핀은 간단한 클릭한번으로 친구에게 공유할 수 있다. select() 메서드 와 execCommand를 이용해 가상의 input 태그에 담아둔 값을 복사해오도록 했다.

 

 

6. 현재 트렌드, 새로 생성된 서핀들 확인 가능

현재 가장 인기있는 검색어를 마이서핀의 trend now 를 통해 확인할 수 있다. 그래프는 Chart.js(라이브러리)로 기본적인 차트를 작성했고, gradient 효과를 주기 위해 canvas API를 이용했다. 검색 랭킹이 뜨는 부분은 '서핑'이라는 컨셉에 맞게 파도가 치는 느낌을 추가했다. 이 부분은 CSS의 keyframe을 활용했다.

 

 

 

 

Flow Chart

---

DB 스키마

---

API 개요

---

 

잘한 점, 개선해야할 점 

---

다같이 정해둔 팀 규칙

 

 

잘한 점 

 

1. 도전 정신, 새로운것에 대해 겁먹기보다 시도부터 하는 태도
2. 매일 아침에는 회의시간, 저녁에는 회고시간을 가진 것
3. 팀원들이 (하루종일..) zoom으로 지속적으로 소통한 것
4. 어려운 점이 생기면 바로 공유하는 분위기
5. 유연한 규칙 적용

개인적으로 잘했다고 생각하고, 다음 프로젝트 때도 유지해야 한다고 생각하는 사항들이다. 역시 빠르게 진행되는 프로젝트에서 어떤 일을 했는지, 배운건 무엇인지 기억하기 위해서는 무조건 기록을 해야한다. 그런 면에서 매일 회고시간을 가지고 모든 팀원들이 회고록을 작성했던 건 신의 한수였다고 생각한다. 그리고 팀원들이 직접 만나지는 못했지만 하루종일 줌을 틀고 지속적으로 소통을 한 점도 잘했다고 생각한다. 작업을 하다가 어려운 부분이 생기면 공유하고, 각자 태스크를 유동적으로 분배할 수 있어서 좀 더 빠르게 진행할 수 있지 않았나 생각이 든다.

 

개선할 점

 

1. 각자 작성한 코드를 공유하는 시간 부족
2. commit 규칙, PR, 이슈카드 템플릿을 점점 지키지 않은 것
3. branch 관리를 좀 더 세분화할 필요성
4. 태스크 분배 방식각자 작성한 코드를 공유하는 시간 부족
5. 체력관리! 시간관리! 필요
6. 디자인이나 사용자 경험(UX) 에 대해 좀 더 깊은 고민이 필요

개인적으로 아쉬움을 느끼거나 다음 프로젝트 때는 개선해야할 필요가 있다고 생각하는 사항들이다. 일단 시간이 촉박하다고 느껴지다보니 코드리뷰를 할 시간이 많이 부족해서 뒤로 갈수록 각자 작성한 코드를 바로 merge 하는 식이 되었다. 오히려 충돌을 일으키는 부분도 있고 다른 사람이 작성한 코드를 이해하지 못하고 넘어가기도 했어서 이부분은 꼭 개선해야 할 것 같다. 그리고 기능구현도 물론 중요하지만, 사용자가 사용하기 편하고, 기능을 알아보기 쉬운 사이트를 구현하는 것도 중요하다는 생각이 들었다. 

 

느낀점 ✍🏻

---

프로젝트를 하면서 생각대로 작동하지 않던 Github과 React Hooks, Redux 때문에 고생을 했었는데, 이제는 좀 친해진 느낌이다. 특히 React나 Redux 는 써보기는 했지만 어떤 역할을 하고, 어떤 점에서 편하구나 하는 정도로 넘어갔었는데 이렇게 직접 이용해서 뭔가를 만들어보니까 이제서야 어떤 메서드를 언제 써야하는지 구분할 수 있게 되고, 왜 쓰는지, 장점이 뭔지 몸소 깨닫게 될 수 있던 것 같다. 역시 삽질을 해야 많이 배운다..! 그리고 사용자 경험(UX) 측면에서 어떻게 구현해야 서비스를 좀 더 자연스럽게 사용할까? 하는 고민도 나름대로 했는데, 너무 사소해서 하나의 기능이라고 인식하지 못할 정도의 페이지 전환, 스무스한 스크롤.. 등 편리한 사용자 경험을 제공하기 위해선 생각보다도 훨씬 더 많은 정성이 필요하고, 그런 서비스를 제공하는 웹사이트에는 개발자들의 노력이 담겨져있다는 것도 깨달았다.

 

이 외에도 두번째 배포 테스트를 하고 확인해보는데, 내 환경이랑은 다르게 나타나는 부분들이 있어서 다른 초기 환경에서 반드시 테스트를 해봐야겠다는 다짐도 했고, 내가 대충 넘어가는 부분이 다른 팀원들한테 피해를 끼칠 수 있기 때문에 merge를 하기 전에 코드를 좀 더 꼼꼼하게 확인을 해야겠다는 생각도 들었다. 물론 아쉬운 점도 있기는 하지만, 그보다도 너무 많은것들을 배웠다고 생각한다. 이번 프로젝트를 발판삼아 한달 프로젝트 때는 훨씬 더 체계적으로 진행해야겠다.

 

팀원들과 2주 동안 열심히 달려서 신체적으로는 굉장히 지친 상태지만, 여전히 코딩하는건 재밌고, 알아가고 배워갈수록 도전해보고 싶은 것들은 더 많아져서 하루만 푹 자고 얼른 다음 프로젝트를 시작하고싶다..! 🙌🏻