개요
- 여러 종류의 웹 서비스 중, 기본적인 비즈니스 웹 서비스인 상품을 판매하는 웹 서비스를 제작.
- 모두 백엔드로 이루어진 팀.
서비스
- 커피원두를 판매하는 웹 서비스
정리 내용
- 넋두리
- 최종 구현 결과
- 트러블 이슈
- 성장 내용
넋두리
포스팅이 많이 늦었다. 스스로 변명을 하자면, 개발을 시작하고 협업하는 첫 프로젝트였기 때문에 모든 것이 낯설고 어려웠다. 마지막 며칠은 벼락치기처럼 작업하고 소통하느라 하루가 어떻게 지나가는지도 모를 정도였다.
끝과 동시에 2차 프로젝트를 진행하다보니 정신이 없었다.
확실히 많이 엉성했고, 도로보다 풀숲을 헤매는 시간이 길었지만, 완성하고 나니 여러 가지 인사이트를 얻을 수 있었다. 나는 이번 프로젝트에서 시큐리티, 즉 회원가입과 로그인 기능을 맡아 진행했고, 그 결과는 다음과 같다.
최종 구현 결과
무려... 첫 도메인 화면이다. 프론트의 중요성을 절실히 느낀다.
전공에 빗대어 말하자면, 골조와 기초공사가 튼튼한 집을 지어도 인테리어와 외부 디자인이 엉망이면 구매자를 설득하기 어렵다.
하지만 지금은 기능을 구현하고 실행할 수 있다는 것만으로도 기뻐하고 싶다.
적어도 한 걸음 앞으로 나아갔으니, 그것만으로도 일단 만족한다.
로그인 버튼을 누르면 로그인화면으로 연결된다.
로그인을 하면 토큰값이 제공되고, 로그인한 사용자에게만 보이는 페이지로 이동된다.
원하는 주문을 담기를 통해 장바구니로 옮기고 장바구니 안에서 수량을 입력하면 밑에 총 금액이 표기된다.
결제하기를 누르면 특정 유저가 주문한 값이 서버에 저장된다.
주문 내역을 들어가면 최근에 주문한 내역이 표기된다.
주문완료 상태에서는 주문 삭제가 가능하다.
어드민 즉, 관리자계정으로 로그인하면 상품 추가 버튼이 생성되고 클릭하면 상품을 등록하는 페이지가 열린다.
로그아웃상태에서는 주문하기 버튼이 없으며, 로그인을 해달라는 메세지가 표기된다.
정말 기능만을 구현한 프로젝트였다. 이번 프로젝트는 총 7일 동안 진행되었으며, 개발과 함께 PPT 자료 및 기본적인 명세서도 제작했다.
명세서를 만드는 것도, 협업도, PPT를 제외한 거의 모든 것이 처음이었다. 처음에는 도대체 어디서부터 시작해야 할지 막막하고 답답했다. 하지만 혼자 멍하니 있는다고 해결되는 것은 아니니, 팀원들을 붙잡고 끊임없이 질문했다.
질문의 질을 높이기 위해 먼저 사고하고, 정리한 후 질문을 던졌다.
단순히 "뭐 해야 돼요?" "이거 왜 안 돼요?" 같은 질문은 듣는 사람 입장에서 "그냥 해줘" 라는 말처럼 들릴 수 있다고 생각했다. 그래서 질문할 때는 다음과 같은 형식을 유지하려 했다.
- 이슈 내용
- 직접 시도해본 해결 방법
- 문제점과 이해가 안 되는 부분
다행히 팀원들도 함께 고민해주며 "배우면서 하는 거니까 부담 없이 질문하라" 고 말해줬다.
역시 어디서든 좋은 사람들과 함께 일하는 것만큼 큰 복은 없는 것 같다.
트러블 이슈
1. Git 레포지토리
협업을 위해 깃 레포지토리를 생성하는 과정에서부터 이슈가 발생했다.
팀원 중 누구도 브랜치 전략을 경험해본 적이 없었기 때문이다. 다행히 한 분이 포크(Fork) 방식을 사용해본 경험이 있어, 그 방식을 공유하며 진행했다.
포크 방식은 메인(Main) 레포지토리를 각자의 계정으로 그대로 복사하여 작업하는 방식이다.
PR 과정이 비교적 간단하다는 장점이 있지만, 최신 상태를 유지하려면 매번 동기화해야 하는 번거로움이 있다.
또한, 사소한 변경 사항도 업데이트와 PR을 통해 반영해야 하는 부담이 있었다.
2. 프로세스 이슈
첫 협업이다 보니 작업 프로세스가 뒤죽박죽이었다.
보통의 협업 프로젝트는 다음과 같은 절차를 따른다.
- 프로젝트 주제 및 필요한 기능 공유
- 요구사항 명세서 작성
- 엔터티(Entity) 설계
- API 명세서 작성
- 내용을 토대로 프로젝트 파일 생성
- Git 레포지토리 생성 및 팀원 초대
- 커밋, PR 규칙 공유 및 브랜치 설정
하지만 우리는 이러한 과정 없이, 각자의 IDE에서 자신의 파트를 먼저 개발하는 방식으로 진행했다.
그 결과, 후반부에 코드를 병합하는 과정에서 수많은 오류가 발생했고,
각각의 코드 조각을 일일이 맞춰 연결하는 데 많은 시간을 소모해야 했다.
3. 프론트를 만만히 봤다
백엔드 설계가 끝나면, 프론트엔드는 쉽게 해결될 것이라 막연하게 생각했다.
하지만 현실은 달랐다.
프론트엔드 설계뿐만 아니라, 백엔드와의 연동 과정에서도 예상보다 많은 시간이 소요되었다.
결국, "절대 밤새지 않겠다"는 다짐을 지키지 못하고 밤을 새며 작업해야 했다.
결론적으로 프론트는 이미지없이 텍스트로 너무 단순하고 무식했지만, 수 많은 오류를 직접 경험하고 해결하며 단기간에 많은 인사이트를 얻고 성장했다고 자부한다.
성장 내용
- 프로세스의 중요성
어떤 일이든 큰 스케치작업을 해놓고 세부 내용을 쪼개고 일정을 잡고 일하는 방식이 중요하다. 개발을 배우면서 개발의 프로세스를 직접 경험해 본적이 없어서 서툴렀지만, 이번 프로젝트를 통해 개발 프로세스를 많이 깨달았다.
- 시큐리티의 이해
기존 학습에서 스프링 시큐리티를 불러와 회원가입을 통해 로그인 로그아웃 방식을 경험했다. 하지만 이는 단순한 방식으로 토큰값을 이용해 일반 이용자와 관리자를 나누는 방식이 있다는 사실을 알게됬고, 웹서비스 이용자에서 웹서비스 개발자로 시큐리티와 가까워지고있다.
