brunch

You can make anything
by writing

C.S.Lewis

by 유어슈 디자인팀 Sep 07. 2023

요즘 학생들의 프로젝트 하는 법

대딩들의 프로젝트 진행 방법을 알려드려요

대학교 생활을 4년을 겪고 나서 느낀 것이 있다. 바로,,, ‘왜 중간고사 망하고도 잘본다고 다짐해 놓고 기말고사 기간엔 그 다짐을 까먹는 걸까?!’였다. 분명 중간고사 시험 결과 보고서는 열정이 가득했는데 기말기간만 되면 왜 열정이 사그라드는 걸까. 그래서 아이디어를 냈다. ‘중간고사 다짐을 기말고사에 전해주면 어떨까?’

프로젝트를 하고 싶은데 처음으로 프로젝트/팀플을 하는 사람들은 다른 사람들은 어떻게 하는지 궁금할 수도 있다는 생각에 이렇게 기록을 남기기로 했다.

1단계. 아아디어 들고가서 구인

아는 개발자나 디자이너가 동아리 사람밖에 없어서, 유어슈에서 사람을 모집했다. 앞서 말한 아이디어를 기반으로 대략적인 스펙 정도를 가지고 동아리에서 사람들을 구인했다.

2단계. 프로젝트 진행 방식과 일정 조율

아이디어 특성상 기말고사 시작 전 한 달이라는 시간을 두고 릴리즈 해야했기 때문에 시간이 넉넉하지 못하고 데드라인이 명확한 프로젝트였다. 따라서 스프린트1과 스프린트2로 나누어 MVP기능을 만들고 이후 테스트와 검증을 걸쳐 남은 시간동안 우선순위에 맞추어 수정 및 추가 개발을 진행하는 방식으로 진행했다.

3단계. 스프린트

시간이 없기 때문에 스프린트1에서는 가능한 최소 기능만 구현하는 것에 초점을 두고 진행을 했다.

3.1 아이데이션

프로덕트를 만드는 건 모두의 몫이기에 아이디어 같은 경우는 개발자와 디자이너와 기획자 PM 모두 모여서 점점 아이디어에 살을 붙였다.

3.2 기획

만나서 대면으로 소통하면서 빠르게 완성해나갔다. 예상 타겟층, 기능명세서, 와이어프레임 같은 산출물을 만들어냈다. 빠르게 진행하기 위해 스토리보드는 생략하고 와이어프레임 옆에 기능에 대한 구체적 설명이나 정책을 추가로 작성하는 식으로 진행했다.

3.3 디자인

디자이너가 여러 명이어서 먼저 디자인 컨셉 시안을 들고 오기로 했다. 디자인 컨셉을 정하고 본격적으로 UI를 만들기 시작했다.

3.4 개발

서면으로 계속 상황공유 스크럼을 하면서 체크했다. 시간이 한정적이었기 때문에 우선 최소기능만 개발하는 것에 집중했다.

3.5 QA

QA는 기획, 디자인, 개발자 모두가 함께 진행했다.

3.6 리걸

서비스에 필요한 법적인 검토와 이용약관 같은 문서 작성을 요청드렸다.

3.7 회고

일단 1차 MVP를 완성했기 때문에 축하도 하고 좋았던 점, 아쉬웠던 점을 나누고 KTP 회고를 썼다.

3.8 사용자조사

1차 MVP는 외부에 공개하지 않고 타겟으로 설정한 사람들을 대상으로 UT를 진행하고 인터뷰도 했다. 각자 조사를 해보고 인사이트를 정리해 기획에 이후 반영하기로 했다.

4단계. 두번째 스프린트 진행

일단 MVP기능은 구현 해두었으니 안심하고 추가 기능을 하나 둘 씩 붙였다. 사용자조사를 바탕으로 기획이 약간 수정되었는데 모든 걸 무조건 수정하지 않고 수정사항을 리스트로 정리하고, 우선순위를 나누어 우선순위대로 기획, 디자인, 개발이 들어갔다.

5단계. 배포 및 홍보

최종 릴리즈를 하고 직접 홍보를 열심히 했다. 당시 학교 봄축제 부스에서 홍보를 하기로 했다.

6단계. 최종 회고

최종 회고를 하고 프로젝트를 마무리했다.

한 달이라는 짧은 시간동안 하나의 웹 프로덕트를 만들었다. 정말 재밌었다. 아이디어가 구체화되면서 서비스가 되는 것도, 멋진 사람들과 다같이 열심히 하나의 목표를 향해 가는 것도, 조금씩 개선하며 점점 프로덕트를 개선시키는 것도, 부족한 부분을 찾아가며 수정하고 개선하는 것도 너무 즐거웠다.

결과물을 공유해드리자면,,,

미래의 나에게 편지를 써보세요! 다만 결심을 곁들인...

�https://i-got-it.soomsil.de/

+ 웹프론트엔드 한나님의 후기

사용한 기술 스택

React, Typescript, Axios, React-Query, Recoil, Radix-ui

구조

api, components, css, hooks, images, pages, services, state, styles, types 폴더로 나누어 개발

아쉬운 점

React-Query 문들을 모두 훅으로 만들어 사용했었는데, 프로젝트 규모가 커질수록 파일이 너무 많아질 것 같다. 반복되는 쿼리만 훅으로 만들고, 반복되지 않는 쿼리 문은 사용처에서 바로 작성하여 사용했다면 더 좋은 구조를 갖출 수 있었을 것 같다.

Dialog 종류가 많았는데, 공통 요소들을 좀 더 잘 정리해서 만들었다면 더 좋았을 것 같다. 예를 들어 버튼의 개수와 같은 구조적인 부분이 다른 컴포넌트만 나누는 것이다. Title, Description, Image와 같은 요소들은 선택적으로 둔 뒤 내부 아이템의 크기에 따라 Dialog 크기를 유동적으로 만들었다면 반복되는 코드가 줄어들고, 좀 더 좋은 구조가 되었을 것 같다.

SCSS를 써보자! 해서 도입했지만, 확장자만 SCSS일 뿐, CSS처럼 사용했다. 다음 프로젝트에서는 SCSS를 좀 더 공부해서 제대로 작성해보고 싶다.

배운 점

BASE_URL과 headers를 한 번만 작성하고, 가져다 쓸 수 있도록 api.ts라는 공통 파일을 만들어서 사용했는데, 이 파일에서 토큰을 넣어버리자 api 호출 시 토큰이 제대로 들어가지 않는 문제를 발견했다. api.ts 파일은 처음 한 번 실행된 후 다시 실행되지 않는다는 것을 파악하지 못한 것이 원인이었다. 결국, 토큰은 모든 api 호출 문에서 각각 헤더로 넣어주어야 한다는 것을 깨달았고, 토큰을 관리하는 TokenService.ts 파일을 싱글톤 형식으로 만들어 내부에 get, set, logout, get headers 함수를 만들었다. 이렇게 함으로써 api 호출 단에서는 TokenService.headers 형식으로 토큰을 넣어줄 수 있었다.

작업 중간에 Github 내에서 대소문자가 꼬이는 현상이 발생했다. Github에서는 대소문자를 변경 사항으로 인식하지 않아 발생한 문제였다. 협업을 시작하기 전 폴더명과 파일명에 대한 규칙을 정할 때 대소문자 규칙까지 정립하고 작업에 들어가는 것이 중요하다는 것을 깨달았다.