기획
탄생 배경
1.
문제 인식 :
•
인터넷에 있는 매력적인 레시피를 보고 따라 해보고 싶어도, 필요한 재료를 일일이 구매하는 과정이 번거롭다.
2.
해결 방안
•
딸깍! 레시피: 사용자가 레시피에 나와 있는 모든 재료를 한 번의 클릭으로 구매할 수 있는 플랫폼
3.
기능
•
레시피 검색 및 선택 : 다양한 레시피를 검색하고 선택할 수 있는 기능
•
재료 자동 목록화 : 선택된 레시피에 필요한 재료를 자동으로 목록화하여 보여줌
•
원클릭 재료 구매 : 목록된 재료를 한 번의 클릭으로 모두 구매할 수 있는 기능
방향성
•
차별화 요소
◦
사용 편의성 : 레시피에 필요한 모든 재료를 쉽고 빠르게 구매할 수 있는 편리함 제공
◦
시간 절약 : 재료 구매 및 준비 시간을 대폭 줄여줌
◦
다양한 레시피 지원 : 다양한 종류의 레시피를 제공하여 사용자의 선택의 폭을 넓힘
아키텍처
•
프론트
◦
Svelte
▪
Svelte Material UI : Svelte UI 라이브러리
▪
Svelte-Store: 전역 상태 관리자
◦
Netlify로 프론트 서버 및 CI/CD 구축
•
백엔드
◦
EC2: 백엔드 서버
▪
Springboot 2개
•
무중단 배포용
▪
Nginx
•
로드 밸런싱용
◦
S3: 정적 파일 저장소
◦
RDS: 관계형 데이터베이스
▪
PostgreSQL에서 MySQL로 변경
◦
ElastiCache
▪
인메모리 DB 용도로 사용
▪
RefreshToken이나 이메일 인증 시, 데이터 임시 저장용으로 사용(TTL을 통해)
◦
CI/CD
▪
Gradle, Github Actions, Docker를 통해 무중단 배포 환경 구축
•
Gradle: 빌드 툴
•
Github Actions: 레포 관리용으로 사용되는 Github 서버
•
Docker: 일관된 환경에서 배포하기 위한 컨테이너 기술
MVP 주요 작업물
•
재료 구매 버튼 클릭 → 주문 → 결제
기술적 의사 결정
식재료 데이터 활용 방안
•
도입 이유: 딸깍! 레시피 서비스에서, 식재료 데이터를 관리해줄 필요가 존재
•
문제 상황
1.
레시피를 만들 때, 식재료에 없는 데이터를 입력하면 어떻게 처리할 것인가?
2.
식재료에 대한 재고가 존재하는 경우, 이를 어떻게 처리할 것인가?
3.
식재료에 대한 가격과 단위는 어떻게 처리할 것인가?
•
해결 방안
1.
식재료 테이블에 존재하는 데이터로만 레시피를 등록할 수 있게 설정
2.
식재료에 대한 재고량은 무한대로 있다고 가정
3.
식재료마다 단위와 단위당 가격 필드를 설정
•
의견 조율
◦
해당 서비스는 버튼 클릭 하나만으로 레시피에 사용되는 식재료를 구매할 수 있는 것이 주된 목표
◦
쇼핑몰 사이트를 만드는 것이 아니기에, 재고량에 대해서는 크게 관여하지 않도록 결정
•
의견 결정
◦
도출된 해결 방안으로 진행
버튼 클릭 시, 장바구니에 식재료를 담는 방식
•
도입 이유: 클릭 하나만으로 장바구니에 식재료 데이터를 담아줄 필요가 존재
•
문제 상황
1.
장바구니에 담긴 데이터를 어떻게 처리할 것인가?
2.
장바구니에 이미 식재료가 담겨있다면 어떻게 처리할 것인가?
•
해결 방안
◦
결제가 진행되면, 현재 장바구니에 담긴 데이터를 통해 상태가 WAITING인 주문을 생성
◦
재료 구매 버튼을 클릭할때마다 장바구니를 비우도록 설정
•
의견 조율
◦
재료 구매 버튼을 클릭 시, 장바구니에 관련된 API 호출을 한 번에 처리할 것인지, 여러 번 호출해서 처리할 것인지 결정할 필요가 존재
•
의견 결정
◦
하나의 API에 여러 책임을 두지 않기 위해, 최대한 RESTful하게 API를 작성하는 것으로 목표 ⇒ 여러 번 API 호출을 통해 해결
◦
프론트에선 백엔드로 API 콜을 여러 번 날리는 비용이 들겠지만, 서버의 유지보수 측면에선 유리한 상황이기에 이러한 방식을 채택
추후 개발 및 기술적인 도전 계획
•
공공 데이터 API와 Spring Batch를 통한 주기적인 식재료 데이터 업데이트
•
날씨별, 계절별, 상황별, 등등… 레시피 추천 서비스
튜터님 질문 2가지 답변
1.
카카오페이 결제 모듈은 진짜 띄우실건가요? 생각보다 심사나 승인 절차가 복잡할텐데 어디까지 알아보시고 어디까지 구현 예정이신지 궁금합니다. 아직은 기획 초기이기 때문에 드리는 질문입니다! 심사 승인 절차를 따져봤을 때 우리가 해당 요구사항을 맞춰서 테스트키를 발급받고 실제 api를 사용 할 수 있을 것 같다면 확정적으로 가져가시고, 아니라면 폐기하는게 현실적으로 나을 수 있을 것 같습니다. 생각보다 알아보고 구현하는게 시간이 소요되고, 해당 심사 과정에서 예상되는 부분을 개발하는게 공수가 클 것 같아서요 (개인적으로는 붙이는데 성공하면 큰 매력요소가 될 것 같습니다)
•
테스트 모드가 따로 있기에, 서비스가 상용화되기 전까지는 테스트 모드만 사용할 계획
•
사용화 된다면, 카카오측과 제휴를 맺어서 실제 결제가 되도록 진행
2.
스벨트를 사용하려고 하신 이유와 과정에서 겪은 시행착오에 대해서 자세하게 설명해주세요. 일반적으로 레퍼런스가 정말 많은 리액트를 사용하지 않으신것 대비 얻으신 특별한 경험이나 기술적인 장점이 궁금합니다.
•
이유
◦
기본적인 프론트 문법만 알고 있을 때, 직관성이 높고 거의 바닐라 자바스크립트를 사용하는 듯한 느낌을 주는 스벨트에 대해 학습하는 시간이 적을 것이라는 생각이 듦
◦
리엑트나 뷰를 사용할 계획도 세웠으나, 학습하는데에 시간이 오래 걸릴 것 같음
◦
스밸트를 조사해본 바, 프론트에 대한 기본 지식과 js 프로그래밍 실력만 있다면 누구나 쉽게 접근할 수 있어보였음
•
장점
◦
높은 직관성
◦
쉬운 난이도
◦
잘 정리된 공식 문서
•
단점
◦
상대적으로 적은 자료
