프로젝트 소개

감사한 사람들에게 편지를 영상으로 만들어 공유하는 서비스, Thanks Clip!

역할

프론트 4명 (백엔드X)

기능별로 분담하여 작업

프로젝트 개발 기간

1.2~1.16 기획 및 개발

1.17~ 프로젝트 발표(중간 회고) 진행, 배포 및 테스트를 통한 이슈 확인 -ing

Idea 🍉

기획 단계, 아이디어 선정!

연초를 맞아 gdsc frontend 스터디팀의 마지막 활동으로 계획했던 gdsc-final-project를 진행하였다.

가장 먼저 figjam으로 비대면 라이브 소통을 하면서 각자가 생각해 온 아이디어를 모았다. 아이디어는 빠른 이해를 위해 서비스 대상, 한 줄 소개, 서비스 효과 세 파트로 나누어서 피그잼에 적을 수 있도록 하였다.

나의 경우 주접/축하 짤 생성기와 개발자 밈 테스트를 아이디어로 가져왔는데, 초반에는 내 아이디어가 꽤 긍정적인 반응을 얻었으나 전자의 경우 에디터 구현이 매우 어려울 것이라는 판단과 후자의 경우 기획만 하다 기간이 끝날 것 같다는 결론이 내려졌다 😵 

아쉽지만 팀원들의 의견은 모두 일리 있는 말이었고, 우리는 2주라는 짧은 시간동안 배포까지 끝내야하는 현실적인 목표를 갖고 있었기에 최종적으로 감사하는 마음을 담아 편지를 보내는 서비스를 구현해보기로 했다. (일상님의 아이디어가 채택되었다👍🏻)

아이디어 구체화

아이디어 구체화를 위해, 우리 서비스에서 전달하고자 하는 핵심 가치나 키워드가 무엇일지 생각해보았다. 다양한 의견이 나왔는데 그 중 영상을 통해 감사를 표현해보면 어떨까 라는 생각을 하게 되었고, 결론적으로 편지를 영상으로 재해석하는 기능이 우리 서비스의 핵심 기능이 되었다. 지금 생각해도 꽤 참신한 아이디어라고 생각한다.

아이디어가 거의 다 잡혀갈 때 쯔음 서비스명도 정했다. 운좋게 내가 제시한 ThanksClip이 서비스명이 되어 괜히 뿌듯했기도 한 순간이었다.

아이디어 흐름 잡기 - 컴포넌트 기반 스토리보드 짜기

먼저 아이디어 구체화를 위해 회의를 진행했다. 회의는 피그잼이라는 툴을 사용했는데, 섹션별로 나누어 포스트잇으로 간단히 자신의 생각을 적어내는 ui가 참 직관적이고 보기 편했고 모두의 참여도를 이끌어내기에 탁월했던 것 같다. 노션의 경우 줄글로 적어야해서 뭔가 잘 정제된 문장을 한 땀 한 땀 써내려 가야할 것 같은 느낌이 있는데 피그잼의 ui는 여러 사람 의견을 공유하고 브레인스토밍하는데 딱 제격인 것 같다는 느낌을 받았다. 😯

아무튼 다시 돌아가서, 우리의 아이디어가 잘 전달되기 위해 어떤 흐름으로 진행되어야 할 지 논의했다. UI 구체화 전에 빠르게 스토리 보드를 만들었는데 우리는 즉각적으로 개발에 착수 할 수 있게 하기 위해서 ui 컴포넌트 단위로 사고하려고 노력하였다. 결국 우리가 기획한 것들이 개발 단계로 넘어갔을 때 어떻게 컴포넌트 단위로 흘러가는지에 대해 처음부터 많은 고민을 했던 것 같다.

개발 목록 구체화 및 와이어프레임 디자인

앞서 말했다시피, 우리는 개발 사고로 확장이 용이하도록 스토리보드를 제작했기 때문에 스토리보드를 보고도 1차적으로 개발 목록을 리스트업할 수 있었다. 그래서 크게 모든 페이지에서 공통으로 사용되는 공통 컴포넌트와 페이지 내에서만 사용되는 페이지 컴포넌트를 나누어서 개발 업무를 분류했다.

또한 UI 구체화를 위해 하연님께서 피그마로 와이어프레임 디자인을 해주셨다. 디자인 컨셉은 다같이 정했지만 페이지 하나하나 디자인 하는것이 쉽지 않은데 흔쾌히 제작해주신 하연님께 이 자리를 빌어 다시 한 번 감사의 말씀을 드린다… (그리고 역시나 디자인 전공자는 다름을 느꼈다 ✨)

그리고 이 와이어프레임을 토대로 개발 업무도 조정되었다

Develop 🛠🔨

개발 단계, rule 정하기

이제 기획 단계가 마무리될 시점이었기에 남은 건 개발 뿐(이라고 생각했지만 사실 프로젝트 마무리 시점까지 기획회의를 자잘하게 계-속 해나아갔다. 이게 애자일이지 😅😤)이었다.

그래서 개발 전 팀원끼리 맞춰나가야할 사항들을 정리했다.

첫째로, 뽑아낸 개발 목록을 각자 실력 및 선호도에 따라 분담했고, 개발 칸반보드를 이용해서 개발 업무를 배치했다.

둘째로, PR룰과 커밋룰을 정했다. PR의 경우 리뷰어를 지정하고 PR의 성격을 나타내는 라벨을 꼭 붙여서 생성하도록 정했다. 기능단위로 feature브랜치를 팠기에 보통 기능 하나를 완료하면 PR을 날리는 형식으로 진행되었다. 또한 원활한 코드리뷰를 위해 최대한 PR에 어떤 구조로 설계해서 최종적으로 어떤 결과를 도출했는지 이해하기 쉽게 글을 작성했다. 글만으로 부족하다면 직접 테스트한 영상이나 사진도 첨부하였다.

실제로 날렸던 PR이다.

개발 환경 셋팅 및 스택 정하기

개발 core stack의 경우 처음에는 vite.js+react 조합이었지만, 서버 사이드 렌더링이 필요해진 시점 이후에는 nextjs+react로 마이그레이션 하였다.

역할	종류
(SSR)Framework	Next.js
UI library	React
Styling	tailwind
State Management	Jotai
Programming Laguage	JavaScript
Data Fetching	x (serverLess)
Formatting	Eslint, Prettier, husky, lint-staged
Package Manager	pnpm
Version Control	Git, github

공통 컴포넌트

우리 서비스는 step별로 편지를 완성해가는 페이지가 이어지는 흐름이다. 그래서 각 step페이지마다 공통되는 부분이 많았고, 사진과 같이 파란색으로 박스친 부분을 공통 UI 컴포넌트로 정의하여 재사용성을 높었다.

페이지별 기능 소개 (컴포넌트 기반 설명)

차례대로 메인 화면 -> step1 화면(1) -> step1 화면(2) -> step2 화면이다.

메인 화면 서비스 타이틀 및 화면 소개 문구가 보이고, 시작버튼을 통해 서비스를 진행할 수 있다.

step1 화면 받는 사람과 보내는 사람 입력 폼을 작성하고, 계속하기 버튼을 누르면 감사편지 입력 폼이 등장한다.

step2 화면 받는 사람에게 어울리는 감사 키워드를 선택하는 폼이 등장하며, 2-5개 선택할 수 있다.

차례대로 step3 화면 -> 모달창(step3→step4) -> step4 화면 -> 다운로드(받는 사람용) 화면입니다.

step3 화면 + 모달창 편지지를 꾸밀수 있는 편집기가 등장한다. 편집기 옵션은 편지지 형태, 배경색, 글씨체, 스티커 총 4가지가 있다. 영상으로 만들어지기 전에 모달창을 띄워 최종적으로 만들어진 편지를 검토 및 수정할 수 있다.

step4 화면 + 다운로드 화면 제출된 편지를 바탕으로 remotion 라이브러리를 통해 영상을 제작하고, 영상을 플레이어 기능을 통해 재생가능하도록 하였다. 영상은 키워드 - 받는 사람 이름 - 편지내용이 다양한 애니메이션이 적용된 상태로 보여진다. 또한 아래 카카오톡 공유 버튼을 통해 받는 사람에게 영상을 다운로드할 수 있는 페이지로 연결시킬 수 있다.

---

KPT 방식으로 다시 회고해보기

Keep

프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분

• 기술 스택에서의 비약적 성장
  • 기존에 reactJS만 알고있었는데 이번 프로젝트를 통해 NextJS, tailwindCSS, Jotai를 처음 사용하게 되었다. 정말 아예 모르는 상태에서 공식문서에 의존해가며 정말 조금씩 적용해본게 다지만 프로젝트에 바로바로 적용해가며 학습하다보니 매우 빠르게 이해할 수 있었다. 분명 스터디용으로 처음부터 한 스텝씩 차근히 밟아갔으면 얼마 못 가 마무리도 못짓고 흐지부지 되었을게 뻔했을 것이다. 그렇기에 2주 동안 많은 것을 얻을 수 있던 것 같아 좋은 경험이었다.
• 2주라는 기간동안 기획에서부터 배포까지 마무리해 본 경험
  • 2주라는 기간동안 무에서 완전한 유를 만들었다. 스프린트 기간이 보통 2주단위인데, 스프린트 한 주기가 돌 동안 프로젝트 하나가 완성되었으니 꽤 타이트하게 진행되었다. 그만큼 회의도 매일 3-4시간씩 진행하고, 모두가 프로젝트에 열정적이었기에 가능했던 결과라고 생각한다.
• 오직 프론트엔드 개발자끼리의 협업
  • 백-프론트와의 협업만 해봤었는데, 오직 프론트 4명이서만 협업을 해 본 경험은 이번이 처음이었다. 프론트 개발 환경을 통합하고 규칙을 하나 하나 설계해 나아가다 보니, 체계적인 협업 프로세스를 경험할 수 있었다. 보통 데드라인에 쫓기다보면 마무리가 다소 아쉬워지는 상황이 종종 오곤 하는데, 이번 프로젝트는 협업 진행 방식에서도 얻을 게 참 많았던 것 같다
• PR과 코드 리뷰
  • 인생 처음 PR을 열심히 작성했고 팀원들로부터 코드리뷰를 받았다. 너무 새롭고 신기한 경험이었다. 일단 누군가에 의해 내 코드를 봤을 때 직관적이고 이해하기 쉬워야한다는 약간의 기분좋은 압박감 + 긴장감(?) 이 있었기에 나름대로 깔끔히 코드를 작성하려고 노력했다. 원래 같으면 변수명도 맘대로 짓곤 하는데, 리뷰어 입장에서 ‘이 변수가 무엇을 의미하는지 한 번에 알아채지 못할 것 같은데?’ 라는 생각이 조금이라도 들면 바로바로 수정했다. 이 과정에서 다양한 시각으로 한 번 더 코드를 곱씹고 넘어갈 수 있어서 너무 좋았다.
• 내 파트가 아니더라도 다양한 이슈에 대해 함께 고민했던 점
  • 아무래도 핵심기능인 편지 콘텐츠를 영상으로 변환하는 과정에서 매우 많은 이슈가 있었다. 그래서 계속해서 문제 상황에 대한 대처(해결)방안이 필요했는데, 이를 회의시간이나 슬랙에서 함께 고민하고 공유했다. 사실 본인은 어떤 이슈인건지 이해하려 드는것에 불과했고 솔루션을 내는 위치까진 가지 못했지만 ㅎ 함께 이슈를 확인하고 고민하면서 다른 팀원들이 어떤 업무를 진행하고 있는지 확실하게 파악할 수 있어서 좋았다. 지속적으로 소통하고 적극적으로 피드백을 공유하고자 했던 준성님께 이자리를 빌어 감사의 말씀을 드린다✨
• 배포 이후 서비스 운영 계획
  • 배포 이후에도 꾸준히 다양한 모바일 환경에서 테스트 시도 후 이슈를 발행하여 UI 개선 등 후작업을 진행중이다. 나에게 프로젝트 마무리는 항상 성공적인 배포였는데, 이번 프로젝트를 진행하다보니 배포 후 서비스를 운영해보는 것도 개발 시야를 넓히는데 매우 큰 도움이 될 것이라고 생각되었다. 그래서 앞으로도 쭉 ! 서비스를 내리지 않고 운영 및 유지보수를 이어나가고 싶은 개인적인 바람이다.🥸 🤓

Problem

프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점

• 개발 환경 설정 / 개발 스택 / 아키텍처를 정할 때 본인 의견을 피력하지 못함
  • 프론트 프로젝트 경험이 많지 않아 익숙한 기술스택이랄게 없었고 다양한 기술스택을 사용 경험이 없어 우리의 서비스 규모나 특징에 가장 알맞은 스택을 선정하는 기준이나 센스가 없었기 때문이다. 그래서 상대적으로 개발경험이 많은 다른 팀원들의 의견에 맞추어 스택이 결정되었다. 다음 프로젝트 때엔 이번 경험을 바탕으로 의견을 적극적으로 피력하여 잘 수렴되길 기대해본다
• 일정 관리의 아쉬움
  • 원래는 10일을 잡고 진행하고자 했던 프로젝트였는데, 계속 기획도 수정되고 그에 따라 개발 테스크도 조정되다 보니 10일이란 시간은 턱없이 부족했다. 팀원 모두가 24시간 내내 이 프로젝트를 할 수 있는 상황이 아니었고, 보통 오전~오후에 개인 일정을 보내고 밤에 사이드 프로젝트 느낌으로 시간을 쏟았기 때문에 10일동안 배포까지 완성시키자는 목표는 정말 빠듯했던 목표였던 것 같다
  • 나 또한 마찬가지로 개인 일정이 있었고 무엇보다 아직 실력이 부족해 구글링을 해가며 기능을 만지다보니 구현한 기능들의 예상 개발 기간보다 항-상 오버되었다. 난 분명 이틀 안에 끝내겠다고 말했는데 자꾸만 하루 이틀 오버해서 PR을 날리는 내 자신이 너무 조금 답답했다. 잘하고 싶었는데 조금 더 잘 알고 진행했더라면 내가 이 프로젝트에 관여할 수 있는 범위 & 도움을 줄 수 있는 부분이 지금보다 더 많지 않았을까.
• 칸반보드와 PR의 활용도
  • 칸반보드는 팀원 작업 상태를 실시간으로 확인할 수 있고 업무 진행에서 발생하는 혼란을 줄이며 프로젝트에 존재하는 병목을 확인하고 관리할 수 있다는 점에서 필수적이라고 생각한다.
  • 하지만 칸반보드 내에 데드라인이 직접적으로 존재하지 않기 때문에, 초반에는 본인의 현재 작업상황에 맞추어 칸반보드를 잘 관리하였지만 막바지에 다다를 수록 칸반보드 관리가 미흡해졌다. 이번 프로젝트의 경우 거의 매일 매일 회의를 하고 open된 PR도 실시간으로 확인할 수 있는 환경이었기에 칸반보드를 보지 않아도 각자가 무슨 일을 하고 있는지 어느정도 파악이 되었긴했지만, 다음 프로젝트에서 칸반모드의 미흡한 관리는 치명적일 수도 있겠다는 생각을 했다.
  • Pull Request 기반의 개발은 결국 다른 사람의 커밋 내용을 보고 자연스럽게 코드리뷰 & 논의 하는데까지 의의가 있는데 나의 경우 후반부에 접어들수록 PR명만 보고 팀원의 작업 상황을 체크하는 정도로만 활용했던 것 같아 개인적인 아쉬움이 남는다.

Try

Problem에 대한 해결 방식으로 "다음 프로젝트"에서 시도해볼 점

전반적인 회고라 Try부분이 다소 추상적인 것 같다. 🥲 problem에 대한 해결방법이라기보다는 keep부분에서 나열했던 것들을 더 견고하게 하여 다음 프로젝트에 시도해보고싶다는 일종의 다짐 같은 느낌으로 해석하면 더 좋을 듯 하다

• 다양한 기술 스택들에 능숙해지기

  • React
  • Next.js 공식문서 읽는 것에 익숙해지기
  • jotai 외에도 다양한 상태관리 패턴 사용 경험 넓혀보기
  • tailwind와 styled-component 사용법 익숙해지기

• 기술 스택 선정을 위한 시야 넓히기

  • 프론트엔드 아키텍처 의사결정 항목들이 무엇이 있는지 유형별로 파악해보고 정리하기

• 처음부터 끝까지 본인의 힘으로 배포해보기

  • aws ec2, lambda, s3, route53
  • vercel
  • ci/cd

• 배포 후 에도 지속적으로 테스트해보기

  • 다양한 모바일 환경에서 테스트해보고, 보이는 버그 잡기
  • 리팩토링/픽스 이슈 많이 남기기
  • 프로젝트가 끝나더라도 내가 만든 서비스에 애정을 갖기 😝

• 스스로 challenging한 영역을 만들어내서 그 속에 뛰어들어보기🌟🌟

  • 새로운 라이브러리를 활용해보고 그 안에서의 이슈 해결해보기 등

• PR 규칙 강화해보기

  • PR 템플릿 사용하기
  • 이전 코드와 개선된 코드에서 바뀐 점&효과 등을 잘 정리하기
  • 예시
    • 최소 1명의 리뷰어 approve
    • 빌드 success
  • 근데 백엔드 팀원이 내 PR을 보고 코드리뷰를 해줄 수가 있나..? 만약 프론트가 1명이라면 누가 review하고 approve하는 것일까

• 하나의 프로젝트에 대한 코딩컨벤션 규칙 만들어보기 (개인 작업이더라도)

• 칸반보드 사용

  • trello나 jira, github project 등 다른 칸반보드 플랫폼 활용해보기
  • 위에서 언급했던 칸반보드의 단점을 해결할 수 있는 궁극적인 방법 고민해보기