(스톱워치 시작)

1

안녕하세요, 중급 프로젝트 7팀, 럭키위키의 팀장 겸 발표를 맡은 김민찬입니다. 그럼 시간 관계 상, 바로 발표를 시작해보도록 하겠습니다.

#2 먼저 목차입니다. 발표 순서는 보시는 바와 같은 순서로 진행됩니다. 프로젝트 개요 설명 이후에 시연 영상을 보시고 나서, 저희 프로젝트만의 차별점과 트러블 슈팅 과정으로 이어지게 될 것 입니다.

#3 첫번째로 프로젝트 개요입니다.

#4 구체적인 설명에 앞서 간단하게 저희 팀의 구성 및 역할부터 말씀드리도록 하겠습니다. 저희 팀은 팀장인 저와, 정현님 그리고 주은님 이렇게 총 3명으로 이루어진 팀입니다. 각자 맡은 역할로는, 제가 팀장 겸 발표 그리고 유저 기능과 랜딩 및 메인페이지와 계정 설정 페이지, 그리고 알림 기능을 맡았구요. 정현님께서는 저희 프로젝트의 주력 컨텐츠인 위키 편집 기능과 새로운 로고 및 랜딩 이미지 디자인을 담당해주셨고, 주은님 역시 주력 컨텐츠인 나의 위키 조회와 검색 기능을 담당해주셨습니다.

#5 다음은 구체적인 프로젝트 설명입니다. 먼저, 저희가 선택한 주제는 위키드인데요, ’친구가 직접 작성해주는 나만의 위키’ 라는 컨셉이 흥미를 가지게 만들었고, 여러 아이디어로 새로운 기능을 추가하거나, 우리 팀만의 디자인들을 추가해 개성을 더해 가는 것도 재미있을 것이라 생각했기 때문입니다. 그리고 저희는 위키드의 요구사항인 자유게시판 기능을 구현하지 않았는데요, 아무래도 저희가 인원이 3명이다보니, 선택과 집중을 해야했다는 게 가장 큰 이유구요, 또 저희가 우연히 위키드의 레퍼런스격으로 보이는 코드잇 직원분들이 사이드 프로젝트로 개발하신 위키드 페이지를 알게 되었는데, 해당 페이지에도 자유게시판 기능이 없었습니다. 아마 프로젝트가 중급 프로젝트로 편입되면서 추가된 기능이라 생각하여, 자유 게시판 기능을 제외하고, 기존 요구 사항에 없던 메인 페이지 추가, Polling 방식을 활용한 알림 기능 제작, 검색 페이지 무한 스크롤 등을 추가하여 ‘위키’ 서비스에 좀더 집중하는 것으로 결정하였습니다.

#6 시연 영상을 보여드리기 전에 저희 프로젝트의 목표를 말씀드리겠습니다. 저희 프로젝트의 목표는, UI나 기능적인 부분은 외부 라이브러리에 의존하더라도, 상태 관리만큼은 외부에 의존하지 않고, Nextjs라는 프레임워크와 기본적인 리액트의 렌더링 방식에 익숙해지고자 하는 것이 목표였습니다. 그리하여, 저희는 프레임워크로는 Nextjs의 페이지 라우터를, 스타일 관리는 SCSS를 사용하였고, 클라이언트와 서버 상태 관리 라이브러리는 일절 사용하지 않았습니다. 최대한 기본 Nextjs가 제공하는 것을 활용하여, 로그인 상태에 따른 리다이렉트 라우팅은 middleware를, 데이터 패칭은 axios가 아닌 기본 fetch 함수를, 상태 관리도 기본 리액트 훅을 활용하여 프로젝트를 만들어보고자 하였습니다.

#7 이러한 목표를 잡은 이유는, 심화 프로젝트에서는 포트폴리오 스택 관리를 위해, 반드시 zustand와 tanstack-query 같은 상태 관리 라이브러리를 사용해야 할 텐데, 중급 프로젝트에서마저 React 내부적으로 상태를 어떻게 관리하는 지도 완벽하게 이해되지 않은 상황에서, 내외부적인 상태 관리를 라이브러리에 의존하게 되면 리액트 자체의 상태 관리에 대한 제대로된 이해를 해볼 기회를 가지기가 어렵다고 생각했기 때문입니다.

#8 다음은 개괄적인 프로젝트 수행 절차입니다. 자 그럼, 저희가 자유 게시판을 제외한 기존 요구사항은 모두 구현한 후, 그 외에 추가적으로 구현한 부분들이 많기 때문에 시연 영상 먼저 보시고, 프로젝트 기능 구현과 트러블슈팅에 관한 설명으로 이어나가도록 하겠습니다.

#9 저희 럭키위키 프로젝트 시연영상입니다.

(시연영상)

#10 시연영상을 보고 오셨으니, 저희 프로젝트에서 요구사항 외에 추가적으로 구현한 부분들만 간단하게 짚고 넘어가도록 하겠습니다.

#11 첫번째로, 기능은 아니지만, 기존 위키드와 뭔가 다른 프로젝트라는 것을 가장 눈에 띄게 알려주는 것이 바로 이 신규 로고라고 생각하는데요, 럭키위키라는 이름은 제가 아이디어를 냈고, 정현님께서 직접 손수 새로운 로고를 디자인하고 포토샵으로 만들어주셨습니다.

#12 다음은 메인 페이지입니다. 랜딩 페이지만 있고 정작 메인페이지가 없는 게 아쉬워서, 제가 핀터레스트 돌아다니면서 디자인 레퍼런스를 찾아서 직접 설계하여 구현을 해보았습니다. middleware를 활용하여, 로그인이 되지 않은 상태라면 최초 진입 페이지는 랜딩 페이지가 되구요, 로그인이 된 상태라면 랜딩 페이지가 없이 메인 페이지로 진입하게 됩니다.

#13 다음은 Polling을 사용한 위키 변동 사항 알림 기능입니다. 원래는 SSE(server-sent-event)로 구현하여 실시간으로 서버의 변동 사항을 받아오고 싶었습니다. 그래서 api route와 event-source api로 구현을 해보려했으나, 한 번 응답이 오면 서버와의 연결이 끊겨버리는 문제가 있었습니다. 알고보니 서버 측에서 SSE를 상정한 API 구현을 해놓지 않으면 클라이언트 측만으로 구현이 되지 않는 부분이라고 하여, Polling 방식으로 구현하여 3초 주기로 서버에 재요청을 하고, 요청이 실패하면 서버 과부하의 문제일 수 있으니, 딜레이를 2배로 늘려가는 방식으로 알림 기능을 구현하였습니다. 3초라는 주기는 우연히 모각코에 들르신 주강사님께 도움을 받았습니다. 이 자리를 빌려 감사의 말씀을 드립니다!

#14 다음은 위키 인증 퀴즈 변경 기능입니다. 이 기능도 기존에는 없던 기능이었고 전용 API도 없었습니다. 하지만 서비스 상에서 인증 퀴즈는 내가 인가한 사람 또는 내가 내는 문제를 맞춘 사람만 나의 위키를 수정할 수 있어, 비즈니스 로직 상, 아주 중요한 기능이라고 생각했기 때문에 질문 변경 기능은 꼭 필요하다고 생각했습니다. 다행히 위키 편집 API에서 인증 질문도 변경할 수 있다는 것을 알게되어, 해당 API를 활용하여 인증 퀴즈를 변경할 수 있도록 하였습니다.

#15 다음은 인증 퀴즈 이메일 전송 기능입니다. 해당 기능은 멘토님께서 보시고 진짜 서비스 같다며 놀라워 하신 부분이었는데요. 앞서 말씀드렸던 것 처럼, 인증 퀴즈가 매우 중요한 기능이라고 생각했지만, 제공된 API 어디에서도 인증 퀴즈 답변을 조회할 수 있는 방법은 없었습니다. 그 말은 즉, 한 번 답변을 잊어버리면 아무도 위키를 수정할 수 없는 치명적인 문제가 발생하게 된다는 것입니다. 이를 방지하기 위해, 프로필을 생성하거나, 위키 퀴즈를 변경할 때에 이메일로 질문과 답변을 보내주는 기능을 개발하게 되었습니다.

#16 다음은 최근 검색어 기능입니다. 주은님께서 아이디어를 내시고 직접 개발하신 기능인데요, 검색창에 검색어를 입력하면 로컬 스토리지에 저장하여 최근 검색한 이력을 볼 수 있도록 하였습니다.

#17 마지막으로 오픈 그래프 공유 기능입니다. 정현님께서 구현해주셨고, 보시는 바와 같이 카카오톡에서 공유했을 때, 오픈 그래프가 잘 나타나고, 클릭 시 vercel과 git action으로 배포된 럭키위키 사이트로 이동하게 됩니다.

#18 자, 이제 마지막으로 팀에서 기능 구현을 하며 맞닥뜨린 트러블슈팅에 대해서 말씀드리겠습니다.

#19 첫번째는 무한 스크롤 구현 도중 발생한 에러입니다. 이는 무한 스크롤로 데이터를 순차적으로 패칭할 때, 코드 로직상 별다른 원인 없이, 데이터가 2번씩 불러와져, 같은 컴포넌트들이 2번씩 렌더링되면서 키값이 중복되었다고 뜨는 에러였습니다. 문제의 원인은 React Strict Mode가 데이터를 fetch하는 useEffect를 2번 실행시키고 있어 발생하는 에러였고, 이를 끄자 해결이 되었습니다.