06.26. 최종 프로젝트 / 중간발표

1. 프로젝트 정보

서비스 기획 의도: 팀 ‘길벗’ 은 한국의 아름다움과 역사적 가치를 보다 가까이에서 편리하게 즐기실 수 있는 서비스를 기획하고자 하였습니다. 궐나드리는 궁궐에서 진행되는 다양한 행사와 관련 정보들을 소개하고, 관람 예약을 도와드립니다. 또한 주변 한복점과 연계한 한복 예약 서비스도 진행합니다. 한국의 문화와 전통, 공연 및 체험 프로그램 등 궁궐의 다채로운 행사들이 여러분을 기다리고 있습니다. 지금 길벗과 함께 궐나드리 떠나볼까요?

2. 프로젝트 한 줄 설명 : 

궁궐 관람 예약 및 관람 정보 큐레이션, 한복 대여 서비스까지!

3. 프로젝트 시연영상 : 

궐나드리 시연영상

 

 

4. 발표 주요 자료 : 

목표 서비스 아키텍쳐

목표 추가 구현사항

 

최종 프로젝트 발표 대본을 짜고 준비를 열심히 하여 무사히 발표를 완료하였다.

중간발표는 무사히 마친 듯 하지만.. 최종발표를 정말 열심히 준비해야겠다.

 

 

1. 기술적 의사결정 & 트러블슈팅 기록

프로젝트를 진행하면서 직면한 문제를 어떤 과정으로 해결 하셨는지, 스택별로 기록 해 주세요

기술적 의사결정을 기본으로, 트러블슈팅도 있다면 기록해둡시다.

• 태서경
  1. 프리티어로 배포를 하기 때문에 DB 용량에 신경을 써야 한다.
     • 크롤링 이미지들은 따로 저장하지 않고 charfield url을 저장한다.
  2. 해결 방안

---

• 이세희
  • 문제 상황 : 결제완료 처리를 위해 결제고유번호를 url파라미터로 넘겨주어야하는데 redirect 주소에서 파라미터 값을 받아오지 못함. 결제 완료 요청이 들어온 해당 데이터의 고유값을 찾아올 방법이 필요
    • 해결 방안 결제고유번호는 1. 보안이 필요한 데이터가 아님 , 2. 일정 시간이 지나면 자동으로 결제 요청을 했던 통신이 막힘. 이라는 특징이 있기 때문에 결제 요청 단계에서 쿠키에 저장한 뒤 결제 완료 페이지 쿠키에서 GET, 결제완료 처리해 줄 해당 특정 데이터를 바로 찾아올 수 있게 됨.
  • 문제 상황 : 결제기록 테이블을 행사, 한복 예약이 같이 사용했기 때문에 상품의 PK값을 저장한다면 값이 겹침. PK 없이 결제한 특정상품을 찾을 수 있는 방법이 필요
    • 해결방안
      1. 결제일자와 상품번호, 유저 아이디 등 데이터 고유값을 특정 식으로 계산해 암호화해서 주문번호를 만들어내기
      2. 특정 필드의 특정한 위치에 상품 PK를 포함시켜 상품의 정보가 필요한 곳에서 split을 이용해 상품 PK를 GET하기 V
         • 장점 : 복잡한 식이 필요없음, 간단한 방법으로 고유한 번호를 가지고 올 수 있음
         • 단점 : PK를 가지고 오는 방식이 불확실함

---

• 나지수
  • 문제 상황 : 후기 작성할 때 받은 별점을 상점별로 평균내어 상점 메인 페이지에 노출
    • 해결 방안 한복점 리스트를 만드는 시리얼라이저에 평균 별점 필드를 추가해 표기 후기 등록할때마다 db에 평균 별점을 다시 작성 하지 않아도 됨
  도입 이유 사용자의 편의성을 고려하여 한복점의 위치를 제공, 시각적으로 표시해주어 접근성을 높여주기 위함

  문제 상황	지도에 위치를 표시해 노출해주기 위해서는 위도와 경도의 정확한 좌표값이 필요함
  해결 방안	주소로 위치 좌표를 출력해주는 API, 출력한 위치 좌표를 활용해 위치를 그려주는 API를 사용
  의견 조율	사용자가 상점 페이지를 방문할 때 좌표출력 API와 지도 출력 API가 두 번 호출되는 비효율점
  의견 결정	위치 좌표를 출력하는 API는 상점 등록 시 서버에서 한 번만 실행, 좌표값을 serializer에 추가해 API 요청 횟수를 줄임

---

• 정찬호
  • 문제 상황 : 티켓 구현 방식
    • 해결책-공연이 생성될 때, 해당 공연의 티켓을 자동적으로 생성되게 하자(x)
      1. 장점: 관리자가 티켓을 생성해 주지 않아도 되는 점, 자동화가 이루어진다는 점에서 관리의 편리함 제공
      2. 단점: 하나의 공연일 경우 큰 무리가 없지만, 공연의 수가 늘어날 수 록 생성되는 티켓의 수가 너무 많아져 현재 프로젝트에서 그 수를 감당할 수 있을지, 기술적인 어려움
      -관리자가 직접 해당 공연의 티켓을 생성 단, 하루 단위로 나누어 공연일 몇 일전에 예약이 가능하다는 사실을 명시 후 범위 안 날짜의 티켓만 생성
      1. 장점: db에 부담을 줄여줌, 기술적으로 구현이 쉬워짐
      2. 단점: 관리자가 매일 티켓을 생성해 주어야 하는 번거러움 발생, 휴먼 에러 발생가능성이 높아짐
      [결정]단, 티켓을 공연날짜 단위로 구분하여 생성한다는 점에서 의논이 필요하다고 생각됨 현재 시스템에서는 관리자가 직접, 해당 공연의 모든 티켓을 생성해야 함 자동적 생산을 채택하지 않은 이유가, db부담이 예상되어서인데, 이 문제를 지금 채택한 방법에서도 여전히 가지고 있음
    • 물론 기술적인 어려움 때문에 구현을 하지 못한 이유도 있지만, 지금의 방식은 번거러움과 db부담의 문제를 둘 다 가지고 있어 의논 후 변경점을 찾아야 한다 생각됨
    • 관리자가 직접 티켓을 생성해주는 방법을 채택, 휴먼 에러는 serializer에서 validate를 통해 최대한 방지
    • [시도]
  도입 이유 사용자에게 인원 제한이 정해져있는 행사의 결제 서비스를 제공

  문제 상황	결제와 행사 예약 구현의 역할을 분배하였기 때문에 행사 예약을 결제 기능에 연결하기 위한 구동 방식 수정 필요
  해결 방안	1안) 결제 기능을 그대로 사용
  2안) 예약 과정에서 결제에 필요한 데이터를 받아 넘겨주는 형태로 수정
  의견 조율	1안) 현재 구현되어 있는 결제 시스템에 맞춰 예약 시스템의 전반적인 수정이 필요함
  2안) 결제에 필요한 데이터(수량, 회원명, 가격)는 약간의 수정으로 데이터를 공유할 수 있음
  의견 결정	두 기능을 모두 활용하여 예약 과정에서 결제에 필요한 데이터를 넘겨주는 방식을 선정

---

• 김민경
  • 문제 상황 : 나중에 db에 용량을 많이 잡아먹을까봐 프로필 이미지 URL (vs. ImageField)으로 받아오기로 선택했으나 파일을 받아와서 URL저장되는것이 에러가남.
    • 해결책 : ImageField받아오기로 바꿈.
      1. 장점: db에 반영이됨
      2. 단점: 회원가입 시 이미지 업로드 문제가 발생, 추후에 용량관리 문제 발생 가능.
  • 문제 상황 : 회원가입 때 프로필 이미지 업로드를 할 시 데이터베이스에 저장이 안됨.
    • 해결책: 회원가입때는 디폴트 이미지를 받아오고, 추후에 수정하게 함.
      1. 장점: 빠르게 해결이 됐음.
      2. 단점: 프로젝트에 의도한 바가 벗어남.

2. 중간발표 피드백 기록

월요일에 대면 피드백을 꼼꼼히 기록해두고, 개선이 필요한 사항에 적용해봅시다.

---

• [ ] webapp 모바일 환경 고려하기
• [ ] 테스트코드 작성
• [ ] 변수, 클래스 네이밍 - 어떤 역할 하는지 알게끔
• [ ] ex) custom permission --> is admin or readonly permission
• [ ] 테스트할때 사용했던 프린트물 삭제
• [ ] 특정 스토어, 로그인한 사용자껀지 확인할 때 object_filter owner.request, store_id (한번에 처리하기, 두번 리퀘스트 할 필요 없음)
• [ ] 코멘트 지울때 댓글 아이디만 받아오기
• [ ] 처음부터 request.user쓰면 비교할 필요없음 - 점검하기
• [ ] 유저 아이디 받아와서 리퀘스트 유저랑 비교하기 코드 많음.
• [ ] Read me 작성

3. 중간 발표 후 회고

1) 미구현 된 MVP 기능

• 소셜로그인: 백엔드 했으나 다시 수정필요, 프론트 연결
• 비밀번호 바꾸기 : 백엔드 수정
• 비밀번호 찾기 / 이메일 인증 : 백엔드에서 구현하기
• 끝난 행사 비활성화 처리 : 백엔드에서 구현하기
• taggit 사용으로 궁궐 별로 주변 한복점 출력하기 : 백엔드에서 구현하기
• taggit 행사 : 백엔드 구현

2**) 추가/개선 할 기능과 그 이유**

• (개선) 행사 게시물의 범위 확장 : 현재는 예약이 가능한 행사만 어드민이 게시가 가능하도록 구현이 되어있음. 사용자에게 더욱 폭 넓은 정보제공을 위해 예약이 불가한 행사도 게시 가능하도록 변경하기
• (개선) 크롤링 시스템 자동화 : 현재 자동화 시스템이 구축되어 있지 않아 python 파일을 실행해주어야 크롤링이 실행됨. 일정한 주기마다 데이터를 수집, 교체해주는 방식으로 큐레이션과 각종 행사 정보 게시하기
• (개선) 크롤링의 범위 확대 : 큐레이션 & 포토스팟 등
• (추가) 예약 확정 문자 발송 : 사용자의 편의성을 위해 상품 예약구매 시 사용일시와 장소, 구매 확정 여부를 문자나 카카오톡으로 발송해주는 시스템

3**) 추가/개선할 기능을 어떻게 구현 할 것인지**

• ex) 사용할 라이브러리와 그 이유

4. 앞으로의 계획 및 우선순위

• 예시순위 구분 앞으로의 계획 (구체적으로) 마감예정일자

  1	MVP	- 소셜로그인(카카오), 유저앱 프론트까지 구현	06.27
  2	MVP	- 기한 지난 행사 비활성화 처리	06.28
  3	MVP	- taggit 행사 / 한복점	06.28
  4	MVP	- 비밀번호 찾기 / 이메일 인증	06.29
  5	개선	- 결제 코드 리펙토링	06.27
  6	개선	- 크롤링 시스템 자동화, 범위 확대	06.28
  7	추가	- 예약 확정 문자 발송	06.28
  8	개선	- 프론트 CSS 개선	06.30

5. 이번주까지 해야할 일

• 팀 전체 (리더와 부리더님께서 필두로 정리해 주세요.)
  • [ ] 백엔드 앱 기능 완성 및 안정화
  • [ ] 코드 리펙토링 - 개인별
  • [ ] Read me 작성
• 팀원 개인별로 작성해 주세요.
  • 태서경
    • [x] 서비스 전 프론트 css 반응형, 디자인 정리, js 수정
    • [ ] 홍보지 제작 및 더미데이터 준비
    • [ ] 크롤링 시스템 자동화
    • [ ] 크롤링 범위 확대
    • [ ] 테스트코드 작성
  • 이세희
    • [x] 결제 코드 리펙토링
    • [ ] 예약 확정 문자 발송
    • [ ] 프론트 CSS 개선
  • 나지수
    • [x] 한복점 taggit 추가
    • [ ] store 코드 리펙토링
  • 정찬호
    • [ ] 기한 지난 행사 비활성 자동화 처리
    • [ ] 행사 taggit 추가
  • 김민경
    • [x] 소셜로그인
    • [x] 유저앱 정리
    • [ ] 비번바꾸기 활성화
    • [ ] 아이디찾기
    • [ ] 비번찾기
      • [ ] 하려면 이메일인증도 해야됨