당신의 여행을 Yeogi(여기)에

나의 첫 번째 프로젝트 : Yeogi

모비 내부에서 외부 인력을 구해 진행한 Yeogi를 통해 처음으로 실제 각 파트의 담당자들과 함께 협업할 수 있었던 프로젝트였습니다.

같이 공부를 하며 이미 친분이 있던 동료들(모비 2기)과 하던 이전 프로젝트들과 달리 프로젝트 제작을 위해 모인 분들과 진행한 첫 프로젝트라 첫 번째 프로젝트라고 명명했습니다. 👀

Yeogi?

기획 의도

아래는 지극히 개인적인 경험에 의한 생각입니다 😮

개인적으로 여행을 좋아하기 때문에 자연스럽게 주제를 공유할 때 여행과 관련된 사항들을 떠올리게 되었습니다.

다양한 나라를 방문하게 될 경우, 나라마다 정보를 얻는 루트가 조금씩 달라집니다.

한국인들이 많이 방문하는 여행지의 경우에는 정말 다양한 플랫폼을 통해서 정보를 얻을 수 있지만, 그렇지 않은 경우에는 대부분 네이버 카페를 통해 얻어야 하는 경우가 많습니다.

카페를 통해 정보를 얻는 과정에서 제가 느꼈던 불편함은 크게 아래와 같았습니다 :

1️⃣ 정보를 얻거나 댓글을 달기 위해선 등급을 유지하기 위한 조건을 주기적으로 체크해야 한다.

2️⃣ 다른 나라를 방문하는 경우, 카페를 여러 군데 가입해야 한다.

또한 개인 블로그, 인스타그램, 유튜브 등 다양한 플랫폼을 참고할수록 내용이 방대해지게 되고 덩달아 계획을 세우는 시간도 늘어나게 되는 부분이 번거롭다고 느껴졌습니다.

나아가 여행의 일정을 관리하는 사이트도 있었고, 예약을 관리해주는 사이트도 있었지만 각국의 모든 정보를 얻는 사이트는 찾기 어려웠습니다.

보통 여행과 관련된 내용을 기록하는 사람들은 여행이 취미인 경우가 대부분일 거라 생각되었고 이들을 한 군데에 모을 수 있다면 정보를 교환하는데 좀 더 편리하지 않을까 하는 생각이 들었습니다.

Yeogi, 여기에 여행을 기록하세요

서비스 소개

'내'가 여행을 추억하기 위해 작성한 게시글이 다른 사람들에겐 여행 정보가 됩니다. Yeogi(여기)는 여행을 좋아하는 사람들의 추억이 모여 곧 정보가 되는 웹 사이트입니다.

🔗 Yeogi(여기) 기획서에서 더 자세한 내용 살펴보기

🗓️ 개발 기간

모비 내에서 약 두 달동안 프로젝트를 진행했습니다.
매주 정해진 기획과 관련된 서류들을 제출하느라 스파게티 코드처럼 지저분하게 짜여진 코드들이 많아 프로젝트가 끝난 후 2주동안 급하게 쓴 코드들을 리팩터링하는 시간 및 휴식 시간을 가졌습니다.
8월부터 다시 프로젝트 마무리를 위해 계속 진행될 예정입니다.

detail terms

모비 내 프로젝트 전체 진행 기간

전체 기간 : 2024.05.25 ~ 2024.09.01

07/21 최종 발표 및 회식

refactoring 및 re-fresh 기간

2024.07.21 ~ 2024.07.31

추가 진행

2024.08.01 ~ ing

👥 Yeogi Crew

Yeogi(여기)는 총 7명의 인원이 참여한 프로젝트입니다.
고정 회의는 한 주에 최소 세 번 가졌습니다.

1️⃣ 주에 한 번, 팀별 회의를 진행해 서로의 진행 상황을 공유합니다.

2️⃣ 주에 한 번, 해당 팀마다 대표 한 명이 스테이크 홀더(👑)로써 스테이크 회의를 진행합니다.

3️⃣ 주에 한 번, 전체 회의를 통해 차주의 sprint를 정합니다.

배포 주소는 여기

Designer

👑 Jayden

화면 설계서	디자인

피그마로 된 디자인을 보려면 여기

FE team

Amy, 👑 Gang, Wendy

FE gitHub는 여기

BE team

DK, Jun, 👑 Louis

BE gitHub는 여기

FE team Part

프론트엔드 팀에서 가져가고자 했던 점은 NextJS의 장점을 살리는 프로젝트를 만드는 것이었습니다. 또한 사용자 경험과 성능 향상을 위해 skeleton UI 사용 및 layout shift 해결에 신경을 썼습니다.

NextJS 적극 활용

1️⃣ RSC & SSR query fetching

NextJS는 RSC와 SSR을 통해 뛰어난 성능과 사용자 경험을 제공합니다. 이는 순수 리액트에서는 제공하기 어려운 몇 가지 핵심 기능들을 가능하게 합니다.

이러한 기능들을 통해 저희는 빠르고 효율적인 웹 애플리케이션 구축과 더불어 최적화된 사용자 경험을 제공하고자 했습니다.

RSC (React Server Components)

• 서버에서 렌더링되고 실행되는 컴포넌트
• 초기 로딩 속도 개선 가능
• 서버의 리소스 활용 가능
• 데이터베이스나 파일 시스템에 직접 접근 → API 호출 없이 데이터 패칭 가능

순수 리액트 환경에서는 클라이언트에서 데이터 패칭을 위해 반드시 API 호출이 필요한 반면 NextJS의 RSC를 활용하면 서버 리소스를 직접 활용이 가능하다는 장점이 있습니다.

SSR (Server-Side Rendering)

• 서버에서 페이지의 초기 HTML을 생성하는 기술
• 초기 로딩 시간을 단축
• SEO를 개선 가능
• 동적 콘텐츠를 포함한 전체 페이지를 서버에서 렌더링 클라이언트로 전송

순수 리액트에서는 CSR을 기본으로 하기 때문에 초기 로딩 시 JS가 모두 로드(load)되고 실행될 때까지 빈 화면이 표시되거나 SEO 최적화가 어렵다는 단점이 있습니다. 그러나 NextJS에서는 SSR을 통해 동적 콘텐츠를 포함한 전체 페이지를 서버에서 렌더링하여 사용자에게 즉시 제공함으로써 위의 단점을 해결할 수 있습니다.

관련 PR 확인은 여기

2️⃣ dynamic metadata

다이나믹 메타 데이터를 적용했을 때 웹 사이트가 얻을 수 있는 이점은 크게 세 가지가 될 것 같습니다.

1️⃣ SEO 최적화
각 페이지마다 고유한 메타 데이터를 설정하게 될 경우 검색 엔진 최적화(SEO)에 도움이 된다는 장점이 있습니다.
메타 데이터가 각 페이지에 맞게 설정돼 있다면 검색 엔진에서 해당 페이지를 더 잘 인식할 수 있기 때문에 검색 결과에 더 잘 반영될 수 있습니다.

2️⃣ 소셜 미디어 공유 최적화
소셜 미디어에서 콘텐츠를 공유할 때도 다이나믹 메타데이터가 중요한 역할을 합니다.

페이지마다 고유한 Open Graph(OG) 메타 태그를 설정할 경우 사용자가 해당 페이지를 공유할 때 미리보기 이미지, 제목, 설명이 적절하게 나타나도록 할 수 있습니다.

3️⃣ 향상된 사용자 경험
사용자에게 현재 보고 있는 페이지와 일치하는 정보를 제공함으로써 페이지의 내용과 일관성을 유지할 수 있습니다.

관련 PR은 여기

관련 벨로그는 여기

3️⃣ NextAuth

NextAuth를 사용하면 일반 리액트 프로젝트에서 OAuth 관련 로직을 구현할 때보다 훨씬 효율적이고 간편하게 인증 관리를 할 수 있습니다.

또한, NextJS에서는 OAuth 인증을 서버 관리로 변경하면 CORS 문제를 줄일 수 있을 뿐만 아니라 클라이언트가 직접 OAuth API에 접근하지 않기 때문에 브라우저의 CORS 정책 회피도 가능하다는 장점이 있습니다.

관련 PR은 여기

관련 벨로그는 여기

UX 최적화

layout shift

NextJS UI에서 제공하는 skeleton으로 로딩(loading) 시 발생하는 layout shift현상을 해결했습니다.
또한 main의 landing 페이지에서 용량이 큰 두 개의 이미지의 확장자를 svg에서 webp로 변경해 로딩되는 시간을 단축시켰습니다.

이미지가 많았던 메인 페이지의 처참했던 performance 점수도 40점대에서 75점으로 올랐습니다.

SVG ? WEBP ?

SVG (Scalable Vector Graphics)

• 벡터 이미지 형식
• 무한히 확대해도 품질이 손상되지 않는 특성
• 로고, 아이콘 및 그래픽 디자인에 적합

WebP (Web Picture)

• 구글이 개발한 이미지 포맷
• 픽셀 기반의 사진 및 복잡한 이미지를 위한 형식
• 손실 압축과 무손실 압축을 모두 지원
• 파일 크기를 줄이면서도 높은 품질을 유지 가능

기존에는 이미지의 품질을 위해 이미지의 확장자를 svg로 가져갔지만 성능 문제로 인해 용량이 큰 이미지를 webP로 변경했습니다.

WebP의 높은 이미지 압축률은 동일한 품질의 이미지를 더 작은 파일 크기로 저장할 수 있도록 해줍니다. 따라서 webP 확장자의 이미지를 사용하면 전체적인 페이지 로딩 시간을 단축시켜 사용자 경험을 향상시킵니다.

그 외에도 아래와 같은 장점이 있다고 합니다 :

1️⃣ 다양한 이미지 유형 지원
WebP는 손실(lossy) 및 무손실(lossless) 압축을 모두 지원하므로
JPEG, PNG 대안으로 사용 가능

2️⃣ 투명도 지원 → PNG와 같은 무손실 포맷의 대안으로 사용 가능

3️⃣ 애니메이션 지원 → gif 대체 가능

4️⃣ 광범위한 브라우저 지원
최근 웹 브라우저들은 대부분 WebP를 지원하므로 호환성 문제를 최소화 가능
나아가 다양한 사용자 환경에서 일관된 경험 제공 가능

5️⃣ 효율적인 네트워크 사용
파일 크기가 작아지면 네트워크 대역폭 사용이 줄어들게 되므로 모바일 데이터 사용량을 절약 가능

관련 PR은 여기

debounce

FE 팀과 디자인 팀은 사용자 경험이 저하될 것 같은 부분은 바로 의견을 나누며 해결책을 찾아나가려 노력했습니다.

(중략) (중략)

관련 PR은 여기

devTools 및 미사용 font 관리

배포된 페이지에서 React의 devTools가 의도치 않게 로드되는 문제가 있었습니다.
이를 방지하고 사용자에게 불필요한 파일이 로드되지 않도록 조치했습니다.

또한, 사용되지 않는 폰트를 변수로 설정하여 폰트 로딩을 최적화하였습니다.
이를 통해 Next.js의 내장 폰트 최적화 기능을 활용해, 필요한 경우에만 폰트 파일이 로드되도록 설정하였습니다.
Nanum_Myeongjo와 Pretendard 폰트를 CSS 변수로 정의하여 전역적으로 사용 가능하게 하였고, Tailwind CSS 설정을 통해 효율적인 폰트 관리를 구현했습니다.

관련 PR은 여기

LCP 점수 올리기

그 외에도 LCP 점수를 올림으로써 사용자가 빠르게 웹 페이지의 화면을 볼 수 있도록 최적화에 힘쓰고 있습니다.

관련 PR은 여기

관련 게시글은 <사용자를 생각한 한 걸음, LCP>

My Part

제가 메인으로 맡은 파트는 게시글 관련 쪽과 회원 정보 부분이었습니다.

post CRUD

여기(Yeogi)에서 사용한 게시글 에디터는 react-quill입니다.

관련 PR은 여기

UX 최적화

Intersection Observer를 사용한 비디오 재생 최적화

MainSurveyRecommend 컴포넌트에서는 Intersection Observer API를 사용하여 비디오 재생을 최적화했습니다.

관찰 대상 요소가 화면에 50% 이상 보일 때만 비디오를 재생시키도록 하는 handleIntersection 함수를 만들었습니다.

결과적으로 해당 함수로 인해 비디오가 사용자 화면에 보일 때만 재생되게 함으로써 불필요한 자원 소모를 줄일 수 있도록 신경썼습니다.

또한 비디오가 보이지 않을 때는 재생이 중단되기 때문에 다른 중요한 작업에 더 많은 리소스를 할당해 전체 페이지의 성능을 향상을 도모했습니다.

관련 PR은 여기

Memoirs 💭

common KPT

Yeogi Crew는 21일 최종 발표 후 그 주 토요일에 함께 회고하는 시간을 가졌습니다. 전원 모두 8월에도 이어서 프로젝트를 진행하기로 했기 때문에 회고 방식은 KPT로 가져갔습니다.

KPT memoirs
KPT 회고는 애자일(Agile) 방법론에서 사용되는 회고 기법 중 하나로, 팀의 작업 과정과 결과를 개선하기 위해 사용됩니다.

KPT는 세 가지 질문을 중심으로 진행

• Keep
  잘 되었던 점이나 효과적이었던 부분을 계속 유지하기 위해 무엇을 해야 하는지를 논의
• Problem
  문제가 있었던 점이나 개선이 필요한 부분을 분석하고 그 원인 모색
• Try
  문제를 해결하고 더 나은 성과를 내기 위해 시도해볼 새로운 방법이나 아이디어를 제안

Personal Memoirs

1️⃣ grey한 기획

초반에 제대로 잡고 가지 못한 기획에 대한 중요성을 모두 뼈저리게 느꼈습니다.
뒤늦게 프로젝트 진행 기간 후반에 기획을 잡고 가느라 시간은 많이 소모했지만 그 기간을 기회로 전원이 다시 한 번 더 프로젝트의 방향성을 다잡고 갈 수 있었다 생각합니다.

2️⃣ FE와 BE의 소통 문제

초반에 스테이크 홀더 간의 회의 시간에 이슈를 공유하고자 하여 문제에 대한 즉각적인 대응이 어려웠습니다. 이는 각자 맡은 파트에서 문제 발생 시 각 팀의 스테이크 홀더를 통해 상대 팀에게 전달되는 방식으로 결과적으로 해당 문제를 해결하기까지의 과정에 지연이 생길 수 밖에 없는 구조였습니다.

프로젝트 중반부터 문제 발생 시 담당자에게 즉각적으로 연락을 취하는 방식으로 변경 후 전보다 빠른 대응이 가능해졌습니다. 하지만 급한 건이라는 이유로 Jira나 Slack을 통하지 않고 개인적인 메신저를 통해 연락을 취하게 되었고 시간 동안 들쭉날쭉했습니다.

BE 팀의 경우, 전원이 재직 중이었기 때문에 문제 대응 시간이 한정적이었던 반면
FE 팀의 경우, 전원이 취업 준비 중이었기 때문에 24시간 문제를 바라보고 있었습니다.

이와 같은 연락 방식은 서로에게 곤란할 수 밖에 없다고 판단해 8월부터는 함께 정한 코어 시간을 활용해 문제를 공유하고, 불가피할 경우 Jira를 통하기로 했습니다.

3️⃣ BE끼리의 소통 문제

병목 현상 방지를 위한 즉각적인 문제를 공유한 FE 팀과는 달리 BE 팀은 RNR을 명확히 가져갔습니다. 따라서 바로 해결해야 하는 문제를 BE 담당자가 해결할 수 없는 상황일 경우, 해당 파트 전체가 지연되는 문제가 있었습니다.
또한 서로의 PR에 리뷰를 달지 않았기 때문에 다른 팀원이 문제를 해결하는 데에도 어려움이 있었습니다.

따라서 최종 발표 이후 BE 팀은 서로의 코드 공유를 원활히 하기 위해 8월 전까지 전체적인 코드 리팩터링 및 트랙킹 후 8월부터 서로의 PR에 전보다 열심히 리뷰하기로 했습니다.

4️⃣ grey한 agenda

모비 내에서 진행하고자 했던 방법은 매주 모든 팀원이 하나의 큰 파트를 바라보고 진행하는 거였습니다.

저희는 가져가고자 했던 기능 외적으로도 "그래도 사이트라면..." 하는 생각에 부가적인 기능도 동시에 진행시켰습니다. (예를 들면 로그인 기능이라거나...?)
그래서 모든 인원이 다 다른 파트를 동시다발적으로 진행하게 됨과 동시에 모든 파트에서 생기는 다양한 문제들을 함께 회의에 공유하려니 회의 자체도 길어지고 집중력도 분산되는 문제가 있었습니다.

8월 이후부터는 모두 공통된 하나의 맥락을 공유하며 진행시켜보면 좋을 것 같습니다.

🧐 프로젝트를 돌아보며...

얻어가고자 했던 부분이 있다면?

협업과 소통

처음으로 프로젝트만을 위해 모인 사람들과 진행한 프로젝트였던만큼 다른 파트 담당자들, 나아가 초면인 프론트엔드 개발자들과의 협업과 소통이 기대됨과 동시에 긴장되었습니다.

각 팀마다 집중하는 부분이 다를 것이라 생각했고 모든 니즈(needs)를 충족할 수 있을지, 분쟁 발생 시 잘 해결할 수 있을지에 대한 걱정과 더불어 모두가 만족할 프로젝트 완성을 이뤄내고 싶었습니다.

NextJS Project

또한 NextJS로 프로젝트를 진행하는 만큼, React에서는 구현할 수 없었던 Next 만의 강점을 살릴 수 있는 프로젝트를 완성하고 싶었습니다.

얻어갔는가?

협업과 소통

팀 간 소통 시 최대한 오해의 여지가 없도록 시각 자료를 첨부해 전달하고자 했습니다.
같은 의견을 공유하는 팀/팀원이 어떤 부분을 문제로 인식하고 있는지와 그에 대한 해결 방안을 제안하고자 했습니다.

기능을 구현하면서 발생하는 문제들로 인한 백엔드 개발자와의 1:1 소통은 여태까지 개인 메신저로 진행한 부분이 조금 아쉬웠습니다.

8월 이후부터 Jira를 통한 이슈 공유를 기대하고 있습니다.

NextJS에서 만든 React 프로젝트

NextJS에서 제공하는 수많은 기능들을 많이 활용하지 못한 것 같아 아쉬움이 남습니다. 시간에 쫓기다 보니 구현 자체에 목을 메게 되면서 항상 아쉬움을 남기게 되는 것 같아요.

그래도 현재 NextJS에서 제공하는 기능들을 적극 활용하기 위해 검색해가며 리팩터링을 진행하고 있기 때문에 어느 정도 해소가 되지 않을까 기대하고 있습니다.

---

다른 팀원의 회고가 궁금하다면?

• Gang의 회고가 궁금하다면 여기
• Wendy의 회고가 궁금하다면 여기