팀 프로젝트를 시작했다. 감사하게도 프론트앤드 개발하시는 분이 한분 합류해주셨다. 아쉽게도 백앤드 팀원을 구하지 못해서 해야 할 일이 배로 늘게 되었지만 어차피 지금까지 배웠던 것을 복습한다고 생각하고 처음부터 진행하기로 했다. 백앤드 개발자는 구해지는 대로 협의를 하여서 맡기기로 했다.
프로젝트 세팅하기
프로젝트 세팅은 생각보다 시간이 많이 걸렸다. 약 10시간정도의 시간을 가지고 프로젝트를 세팅했다 처음 세팅하는 것이기 때문에 구글에서 이것 저것 찾아보면서 세팅을 했다.
설계
Figma를 사용해서 기본 틀을 그렸다. 구성은 로그인화면 관리자 화면, 고객 화면, 상품 관리 화면, 크루 화면으로 나눴다. 피자 배달을 하면서 불편했던 점을 반영하려고 했다. 피그마를 사용하면서 component 단위로 설계할 수 있어서 정말 편했다. 복잡한 디자인이 아니라면 프론트 앤드 개발자라면 쉽게 사용할 수 있었다.
Git
git을 세팅하는 문제는 처음하는 것이기 때문에 구글에서 팀 프로젝트시 깃헙을 세팅하는 방법을 찾아보았다. 그 중에서 가장 이해하기 쉽게 설명한 것을 참고했다.
왜 개인 프로젝트라도 이렇게 진행하지 않았을까. 지금 진행하고 있던 개인 프로젝트를 이슈와 프로젝트 탭을 사용해서 관리할 수 있도록 변경했다. 스스로 문제를 이슈에 남기고 다시 이슈에 해결했던 방법을 코멘트로 남길 수 있게 되었다.
commit 메시지를 지금까지 작성하면서 그래도 나름 최대한 누구나 이해할 수 있는 메시지를 작성하기 위해 노력했다. 하지만 이번 팀 프로젝트를 진행하면서 commit message를 통일해야할 필요가 있었다. 위의 글에서는 Udacity Git Commit Message Style Guid를 알려주었다. 읽어보니 적용하기 간편해서 이번 팀 프로젝트에 적용하기로 했다.
git commit을 터미널에 입력하면 vi 편집기가 자동으로 열리는데 vscode로 기본 사용 되도록 변경할 수 있다. 방법은 아래 아티클을 참고해서 세팅하면 된다.
front, back 세팅하기
Front는 create-react-app을 사용해서 typescript 환경에서 개발 할 수 있도록 세팅하였다. Back은 expressjs를 사용하기로 했다. 문제는 프로젝트 폴더 구조를 어떻게 해야할지 감이 잡히지 않았다. 물론 지금 진행하고 있는 개인 프로젝트 처럼 프론트와 백을 따로 두어서 cors로 해결하면 동작은 한다. 하지만 프로젝트를 실재 사용할 수 있도록 하게 하면 보안이나 기타를 해결할 자신이 없어서 망설여지는 부분이 있었다.
첫 미팅
원격으로 진행되는 프로젝트이기 때문에 구글 밋업을 사용해서 미팅을 하였다. 팀 원 A에게 지금까지 세팅한 프로젝트를 설명했다. 패키지는 recoil과 styled-components, beautiful-dnd를 사용하기로 했다. react-router-dom은 기본 세팅에 포함시켰다. 둘 다 팀 프로젝트가 처음이었다. 아직 특별히 서로 질문을 하거나 프로젝트를 진행하는데 있어서 어떤 식으로 진행할지 교환한 사항은 없었다.
A에게 들었던 의외의 그리고 배우고 싶었던 부분이 있었다. 아직 사용해본적 없는 패키지를 듣더니 '도큐멘트'를 읽어보겠다고 했다. 사실 나는 어떤 패키지를 사용해야한다고 하면 Youtube에서 실재 구현되는 모습을 먼저 찾아본다. 그 이후에 실재로 사용하면서 도큐멘트를 읽어본다. 하지만 A는 도큐멘트를 먼저 읽어보겠다고 했다.
무언가를 이해하는 방법의 차이라고 생각할 수도 있지만 어쩌면 설계자의 말을 먼저 경청하는 습관일 수도 있다. 그래서 이번 프로젝트를 진행하면서 사용하게될 패키지나 기타 API 문서를 읽어보기로 했다.
미팅 시간은 매주 두 번에서 세 번으로 정했다. A가 직장인이기 때문에 나처럼 시간이 많지 않았다. 중간 미팅은 회고와 방향 잡기였고 주차 마지막 미팅은 구현한 것을 서로 눈으로 보면서 발생하는 버그, 수정 사항을 교환하고 다시 프로젝트를 시작하는 식으로 약속을 했다.
기능 요구 사항 작성하기
미팅 후에 github issue에 기능 요구 사항을 작성했다. 생각보다 요구사항이 많았다. 조금 걱정도 되지만 요구 사항을 보고 구현하는 것은 이번이 처음이 아니기 때문에 기능 요구사항을 작성하는데 많은 도움이 되었다. 다행이 그간 구직 활동을 하면서 3번 정도 기능 요구사항에 맞춰서 어플리케이션을 구현했던 경험이 많은 도움이 되었다.
백앤드는 기능 요구 사항을 어떻게 정리해야 할 지 조금 난감하다. 아직 작성은 못했지만 그동안 했던 경험을 바탕으로 오류, 모델 설계, rest api 설계, 보안 등을 정리해야할 것 같다. 그리고 추가되는 사항은 다시 이슈로 만들어서 기능을 보완하면 될 것 같다. 일단 머리속으로 너무 많은 생각을 하다보면 손가락이 잘 움직여지지 않는다. 하지만 일단 대략적인 것을 글로 옮겨 적고 글을 다시 읽고 수정하다보면 '어떻게하지'라는 생각이 '하... 어떻게 하지'에서 '어떻게 구현할 수 있을까'로 전환된다. 하지만 두 어떻게 하지가 약간 비슷한 느낌이라 조금 어지럽다.
최종 세팅
미팅이 끝나고 서로 이야기 했던 것을 반영했다. 백앤드와 프론트를 따로 나누어 동작하기로 했다. 나중에 히로쿠에 배포할 때, 문제가 될지 안 될지 알 수는 없지만 문제가 되면 나중에 분리하기로 했다. 프론트와 백앤드를 따로 분리해서 히로쿠에 디폴로잉하니까 React는 따로 build 툴이 필요했다. 지금 프로젝트는 디폴로잉 하면서 생각해보기로 했다.
마무리
이제 시작이다. 시작은 반이라고 누가 그랬다.(선조가 그랬나?) 하지만 반만 하고 끝 날수도 있다. 시작을 했기 때문에 끝으로 갈 수 있다는 말이기도 한 것 같다. 취업을 위해 시작한 프로젝트이지만 사실 누군가에게 도움이 되기를 바라는 마음에 누구나 키오스크를 프로젝트 주제로 선정했다.
피자 배달을 할 때, 키오스크가 필요한 경험이 있었다. 통신사 할인 판매 기간동안 정말 지옥처럼 밀려드는 사람을 보면서 그걸 다 버텨낸 내가 참 대단하다는 생각도 든다. 배달을 하다가 고객을 응대하다가 다시 배달을 다녀오다가 박스도 접고 밥도 먹고 담배도 피우고 후발 주자들도 챙기고 밀려드는 수많은 요구 사항에 도망가고 싶을 정도로 힘들기도 했지만 하면 할 수록 팀원들과 어떻게 해결할지 입을 맞추고 제도를 개선했던 경험이 있다. 하지만 기술적으로 풀어내지 못했던 것이 아쉬움으로 남아있다. 엑셀로 나름 키오스크를 만들었지만 엑셀이 모든 사람에게 공유되지 않았다. 동시성이 없었기 때문에 고객에게 피자를 주고 나서 기업에서 사용하고 있는 주문 프로그램과 엑셀을 둘 다 조작해야해서 불편함이 여러가지로 배가 되었다. 뭐 이건 사실 깊게 들어가면 구조적인 문제라 여러 이야기를 하지 않는 편이 좋겠다.
어쨌든 해당 경험을 바탕으로 자영업자, 대학교 축제 등에서 사용하기 편리한 키오스크를 만들어 보고 싶었다. 키오스크 설치 비용이 생각보다 꽤 들어간다. 요즘은 누구나 다 핸드폰을 가지고 있기 때문에 큐알코드로 메뉴를 주문하고 받을 수 있도록 하면 어느 누구나 다 편리하게 주문을 관리할 수 있을 것 같다.(네이버에서 이미 하고 있다는 건 함정이다.)
걱정되는 부분은 결재 모듈을 실재 구현이 가능한지 여부다. 결재 대행사에서 모든 사람들에게 테스트 서버를 열어주지 않을 것이다. 결재를 어떻게 진행할 수 있을지 고민이 된다. 카드를 직접 결재 하는 것은 무리가 있다. 현대에는 스마트폰으로 결재할 수 있는 수단이 다양하기 때문에 범용으로 처리할 수 있는 것이 필요하기도 하다. 하지만 프러덕션 레벨에서 개발하는 프로그램이 아니기 때문에 결재 모듈을 붙이는데 자유도가 떨어지는 것도 사실이다. 프로젝트를 진행하면서 고민해볼 문제인 것 같다. 하지만 가벼움을 추구하는 프로젝트이기 때문에 그 부분에 맞춰 테스트 서비스를 할 정도까지 구현해보려고 한다. 앞으로 나가는건 그 다음에 해도 좋을 것 같다.