SR(Software Requirement)는 시스템이 목표 달성을 위해 갖춰야하는 기능, 또 그러한 기능을 정리한 문서를 뜻한다.
첫 프로젝트, 첫 SR을 앞둔 나는 우선 주어진 가이드를 훑어봤다. 팀원들과의 모임 전에 준비할 수 있는 건 아이디어 기획 뿐이었다. 나는 (1)그동안 배운 스펙을 복습할 수 있으면서 (2)비교적 쉽게 구현할 수 있어 깃을 이용한 협업을 익히는데 무리가 없을 거라 생각되는 아이디어를 몇 개 정리했다. 이때 제일 곤란했던 건 '이 세상에 나만 생각해낸 아이디어는 없다'는 점이었다. 평소에도 배운 것을 현실과 연결시키는 데 고민이 많았던 내게는 상대적으로 막막하게 느껴지는 것이 기획이기도 했다. 그냥 아이디어를 내는 일에도 부담을 느끼는데다 기능 구현까지 신경을 쓰니 당연한 일이다.
1. 프로젝트 선정
다행히 우리 팀은 5분도 되지 않아 곧장 프로젝트 아이디어를 정할 수 있었다. 첫번째 프로젝트에서는 '무엇을 하느냐'보다 '어떻게 하느냐'를 익히는 게 중요하다는 매니저의 조언이 있기도 했고, 다른 팀원이 준비해온 아이디어가 만장일치로 긍정적인 답을 얻었기 때문이었다.
2. 팀장, 팀명, 프로젝트명 정하기
팀명을 프로젝트명에서 힌트를 얻어(사실 거의 똑같이) 정했다. 팀장은 시간적 여유와 본인의 의지, 그리고 백엔드와 프론트엔드를 두루 볼 수 있는 코딩 능력을 감안하여 뽑았다.
3. 팀원별 role 설정
프론트엔드의 ㅍ만 봐도 머리가 아픈 나는(...) 곧장 백엔드를 맡기로 했지만, 아마 이번 프로젝트가 아니면 프론트엔드를 경험해볼 일이 거의 없을텐데 한 번만 더 경험하고 정리해볼 걸 그랬나... 하는 아쉬움도 조금 있었다. 아주 조금.
4. 프로젝트 기획 및 범위 설정
아이디어를 기획했던 팀원이 피그마로 대략적인 와이어 프레임과 기능 플로우를 짜온 덕분에, 이를 참고하면서 기능 리스트업을 시작했다. 첫 프로젝트라 기능을 정리하는 일이 약간 막막했는데 시각적 자료가 있으니 훨씬 수월했다.
1) Bare Minimum
- 로그인 권한 기능(로그인한 사용자에게만 보이는 화면 구성)
- 특정 아이콘을 클릭했을 때 관련 정보만 화면에 보이는 기능
- 로그아웃 후 페이지 이동
- 아이디/비밀번호 찾기(사용자의 이메일로 정보 발송)
- 회원 탈퇴/리뷰 카드 삭제
- 개인정보 수정/작성리뷰 수정
- 회원가입/로그인 유효성 검사(이메일, 비밀번호 유효성 검사)
- 소셜로그인
- 쿠키/토큰 설정
- 패스워드 입력시 *표시
2) Advanced
- 후기에 검색어 필터링 기능
- 검색기능(if문으로 검색어들을 점검)
- 후기 작성 모달창으로
- 다크모드
- 페이지 넘기기 기능
- 비밀번호 특정 글자수 이상만 허용(유효성)
별점, 그래프 등 시각화개별 카드를 종합한 최종 평가 통합페이지
3) Nightmare
- 비밀번호 찾기 한 후, 암호화된 랜덤한 비번으로 사용자에게 전송
매니저와의 미팅 끝에 최종결정된 우리 팀의 기능 목록이다. 다들 열정과 욕심이 너무 넘쳐서 Bare Minimum아닌 Bare Minimum이었는데... 사실 추려낸 것들도 버리지 않고 모두 Advanced로 넘겼다...
줄이 그어진 기능은 삭제하기로 한 것, 굴게 표시된 기능은 시간이 된다면 꼭 해보고싶다고 의견을 모은 것이다.
참, Bare Minimum은 공통 요구사항(페이지 구성 및 기능, Auth, CRUD, DB 설계, 배포, 프로젝트 개발 환경 구축)을 바탕으로 기획했다!
5. 시스템 아키텍처 설계
피그마를 이용해 와이어 프레임을 만들고, 사용자의 입장에서 프레임을 차례대로 넘겨가며 기능 플로우를 채워넣었다. 더 직관적이고 사용하기 쉬운 툴이 있는지 찾아봐야겠다.
6. 컴포넌트 구성
우리는 구글 미트로 프로젝트를 진행 중이었기 때문에 다같이 화면을 공유할 수 있는 구글 docs로 의견을 정리하고 있었다. 그래서 컴포넌트도 구글 프레젠테이션을 이용해 만들었다. 이 또한 다른 툴이 있다면 이용해보고 싶다.
7. 데이터베이스 스키마 작성
스키마는 dbdiagram으로 그렸다. 이전에 스프린트를 진행하며 한 두번 만져본 것이 다라 처음엔 상당히 불편하다고 느껴졌는데, 테이블이 보기 좋게 정리되고 완성된 스키마는 이미지 파일로 추출할 수 있다는 점이 좋았다.
이 단계에서는 요구조건인 다대다 테이블 구성을 위해 고민했고, 필요한 컬럼을 따지고 이름을 설정하느라 수정을 거쳐야 했다. 기획과 구현 기능에 아주 약간의 수정이라도 생기면 와이어 프레임, 컴포넌트, 스키마를 모두 수정해야 한다는 사실을 몸소 체험할 수 있었다. :)
8. API 문서 작성
API 문서 작성을 위해 gitbook이라는 프로그램을 처음 사용해봤다. 마치 한땀한땀 수를 놓듯 정성들여 사용해야 하는 프로그램이었다...
가끔은 GET인지 POST인지 헷갈릴 때도 있었지만 요청과 경로, req, res를 직접 작성해보는 경험은 전체 아키텍처를 이해하는 데 큰 도움이 됐다. 개인적으로 복습이 꼭 필요하다고 생각하는 과정이다.
9. 프로젝트 태스크 카드 작성 & 분배
먼저 (각 팀원이 하루에 쓸 수 있는 시간 * 전체 인원)으로 프로젝트의 가용시간을 계산한다. 그리고 각 API를 기준으로 예상시간이 적힌 태스크 카드를 작성한다.
우리는 깃허브의 이슈 템플릿을 활용해 태스크 카드를 만들었다. 아직 깃의 여러 기능들이 익숙하지 않아서, 이슈를 비롯한 여러 사용법을 계속 익혀가야겠다(이 프로젝트에서는 이슈 뿐만 아니라 칸반보드, 위키, 마일스톤 등을 활용한다). 태스크 카드는 첫 배포 후 분배할 예정이다!
10. 팀 룰 작성
처음엔 팀 룰로 정할 게 뭐가 있지? 라고 생각했는데 그건 정말 작고 귀여운 착각이었다. commit message, PR, 코딩스타일, 변수이름, 파일 이름, branch 이름 등 이름 작성법을 정리하는 게 8할이었고, 실제 룰에 따라 PR을 날릴 때는 이슈 번호 체크하랴 대소문자 구분하랴 엔터 두 번치랴... 혼란의 연속이었다. 팀 룰은 가장 작성하기 쉽고 알아보기 쉬운 방식으로 계속 수정될 것 같다.
하지만 이보다 더 혼란스러운 건 버전관리다. 특히 우리 팀은 Eslint 사용에서 좀 애를 먹었는데, 아직 또렷하게 머릿속에 정리가 되질 않아 이 부분은 따로 포스팅하려고 한다. 늘 혼자 기본세팅을 하거나, 이미 세팅된 레파지토리를 클론하여 코딩하던 내게는 꼭 필요하면서도 어려운 개념이다.
다음에는
- SR 전에도 다양한 준비가 가능하다. 아이디어 선정 여부에 상관없이 기획에 따른 아키텍쳐 그리기, 그 과정에서 다양한 프로그램과 툴 활용해보기 등. 때로는 효용성에 상관 없이 많은 준비(라 쓰고 경험이자 공부라 읽는)가 필요하다.
- 프로젝트 SR에 필요한 각종 툴을 '직접' 사용해보자.
- 아이디어는 더 도전적으로! 자기검열 하지 말기.
- 기획은 자유롭고 재미있게 하되, 시스템 아키텍처는 아주 꼼꼼하게 따져보자.
- 이 모든 과정을 혼자 다시 해보자.
➤계속 공부하고 있습니다. 더 나은 의견과 질문이 있으시다면 언제든, 어떤 경로로든 이야기해주세요.
