배포 url - HTTPS 일단 작동되긴함
https://citefred.store
지금이 11시
발표 등 통일 키워드
•
가게→카페
•
유저,사용자→일반회원
•
사업자,가게주인→ 사업자회원
3시~4시쯤 발제 1시간 좀 작업안될것같음
회고발표자료만들기+회고멘트 (3시간) 11시~3시
목차
1분 30초: 프로젝트 소개 + 시연
•
회원가입, 로그인 등의 기능이 있다면, 그런 과정은 뛰어넘어주셔도 됩니다. 계정을 생성한 상태로 주요 기능만 간단하게 시연해주세요!
•
프로젝트 소개
◦
커피 및 차, 그리고 디저트와 같은 카페 메뉴를 전문적으로 주문을 받고 배달하는 웹 서비스를 구현 했습니다.
◦
이를 통해 초기 프로젝트 기획부터, DB설계, 개발과 배포까지 전체적인 프로젝트 개발 과정을 익히기 위한 첫 프로젝트입니다.
•
시연 시나리오
◦
프론트로 보여줄 부분
▪
회원가입 폼만살짝보여줬다가 뒤로가서
▪
이미 가입된걸로 로그인해버리기
▪
이러면 가게리스트 쭉나와야하고,
▪
검색으로 가게하나 찾고
▪
메뉴 등록 폼만보여줘
▪
등록하면, 아래 쭉이렇게 나옵니다.
▪
리뷰도 이렇게 폼에작성하면
▪
리스트 쭉나옵니다.
◦
포스트맨으로 보여줄 부분
▪
들어가서 주문은 POSTMAN을 켜
▪
주문 등록하고 조회해
•
2분 30초 : 개발을 진행하면서 어려웠던 점, 해결한 내용 (트러블슈팅) / 새로 도전한 기술이 있다면?
◦
프론트 이해도의 부족과 해결
▪
개발한 서버 API로 request가 전송되고 서버로부터 클라이언트로 response가 응답하는 부분인 DispatcherServlet 디스패처 서블릿에 대한 충분한 이해도가 부족했습니다.
▪
특히 요청의 첫 시작점인 클라이언트에서 어떤 방식으로 요청하는지에 대해 JavaScript와 구현하는 어려움에서 시간을 많이 소모하게 되었습니다. 최대한 팀원들 모두 각자 구현해보면서 이 부분의 이해도를 조금 높일수 있었고 앞으로 프론트와의 협업이나 스스로 기능을 구현하는데 큰 도움이 될 것 같습니다.
◦
DB설계 변경과 관련된 내용
▪
◦
배포에 대한 도전
▪
배포과정을 팀 전체적으로 경험이 부족했는데, 제가 직접 공부하고 배포해보면서 이 과정을 팀원들과 공유하면서 부분적으로 이해 할 수 있게 되었습니다.
▪
하지만 SSL 인증서를 추가하여 HTTPS로 변경하는 것에는 조금 복잡한 부분들과 많은 설정 부분이 있어서 아직 충분한 이해가 부족한 상태라고 생각합니다. 이 부분을 함께 스터디해서 보완해 나가고자 합니다.
•
1분 : 앞으로 시간이 더 있었다면 어떤 것을 더 할 수 있었을지
◦
개발 과정 중에 저희가 작성한 메소드의 작동 방식, 결과를 확인 하고자 테스트코드 작성해보기도했습니다.
▪
하지만 단위 테스트 코드를 처음 작성해보면서 부족한 점이 있는것 같습니다.
▪
단위 테스트 코드를 보완해보고, 통합 테스트 코드까지 모두 완성해보고 싶습니다.
◦
아마존에서 제공하는 EC2, ACM, ROUTE 등 클라우드 서비스를 기반으로 배포하는 것을 목표로 했습니다.
▪
이 부분을 해결하기 위해서는 기초적인 OS와 관련된 CS지식과, 네트워크, 데이터 통신, 인프라에 대한 이해 등 다양한 CS 지식이 필요한 것을 느꼈습니다.
▪
현재 배포되는 과정들에 미흡한 부분들을 보완하면서, 필요한 지식들을 계속해서 쌓아가고 싶습니다.
예상 QnA
•
기존 배달앱과의 차이점을 둔 것은 없습니까? 아니면 초기의 이 서비스에대한 목표
◦
현재 단계에서는 기본적인 배달 앱과 큰 차이점은 없지만, 초기에 아이디어가 시작된 부분에서는 최근 서비스되고 있는 배달의 민족과 같이 다양한 음식 카테고리를 다루는 서비스와 달리 저희는 카페 카테고리로 한정하고 싶었습니다. 그 이유는 개인 카페와 같이 특색있는 카페들의 모습들을 보다 자세히 보여주고 싶었습니다. 이번 짧은 2주간의 주특기 프로젝트 기간에는 이를 위해서는 기본적인 배달앱과 같은 프로젝트를 먼저 다룰줄 알고 커스터마이즈가 가능한 실력을 갖춰야 한다고 생각했습니다.
◦
대용량 데이터 처리나, 대량 트래픽과 관련된 문제도 해결해보고 싶었지만 이 또한 기본적인 배달앱과 같은 프로젝트를 전체적으로 구현하는데 집중해보았습니다.
◦
•
커뮤니케이션에 대한 어려움과 극복
◦
다들 처음 팀프로젝트를 진행하는 것이지만 팀원 개개인의 특장점을 빠르게 파악하지 못했다. 그래서 시간이 소모되기도했다.
◦
이런 문제를 해결하고자 자주 회의를 개최하고, 서로 진행 상황을 공유하며, 또한 프로젝트 병합시마다 코드리뷰를 통해 부족한 부분들을 서로 코치해주는 방식으로 속도를 맞출 수 있었다.
◦
•
프로젝트 진행에 대한 어려움과 극복
◦
하고자했으나 성능 개선 등에 집중하고 싶었으나,
◦
프론트엔드 개발과 연결해야 하는 점에서 개발 일정을 정확히 예측 하기 어려웠습니다. 따라서 가장 기본적인 백엔드 구성 부터 테스트코드까지 작성해보는 것을 가장 높은 우선순위로 진행하게 되었습니다.
•
이프로젝트에서 로그인은 어떤방식으로 구현되어있나요?
◦
현재는 JWT 토큰을 활용해서, 로그인을 하면 JWT토큰을 생성하고 있습니다.
기존에는 쿠키에 담아서 요청하던 것을 헤더에 담아서 요청하는 방식으로 변경했습니다.
왜? 일단은 브라우저에서 쿠키를 못 읽는다. 그 이유는 cors정책을 따로 수정해야 되서.
CORS 관련 헤더를 설정하지 않으면, 프론트엔드 JavaScript 코드에서 응답의 쿠키를 직접 읽거나 수정할 수 없다.
cors정책=다른도메인에서 오는 요청을 어떻게 처리할지 결정하는 것 , 기본 정책은 다른 출처에서 오는 응답의 헤더에
접근할 수 없기 때문에 기본적으로는 쿠키를 못 읽는다.
•
이프로젝트에서 CRUD는 어떤방식으로 구현되어있나요?
◦
기본적인 배달의 CRUD 를 구현했습니다.
로그인&회원가입 / 유저 / 가게CRUD / 메뉴CRUD / 리뷰CRUD / 검색
1.
회원가입 & 로그인: 사용자는 회원가입을 통해 서비스에 가입할 수 있습니다. 사업자와 일반 사용자를 구분하지 않고, 가게를 등록하는 사용자만 사업자 번호를 입력하도록 하여 시스템을 간소화했습니다.
2.
가게 및 메뉴 관리: 가게를 소유한 사용자(사업자)는 자신의 가게에 대한 정보와 메뉴를 생성, 수정, 삭제할 수 있습니다. 일반 사용자는 이러한 정보를 조회할 수 있습니다.
3.
리뷰 작성 및 관리: 모든 사용자는 방문한 가게에 대하여 리뷰를 작성하고, 자신이 작성한 리뷰는 수정 및 삭제할 수 있습니다.
4.
주문 및 배달 관리: 모든 사용자는 원하는 메뉴를 주문할 수 있으며, 사장님은 주문 받은 메뉴의 상태 확인과 배달 완료 상태 변경이 가능합니다. 또한 주문이 이루어질 때마다 유저의 잔고 포인트 차감과 사장님의 잔고 포인트 증가가 발생합니다.
5.
검색 기능: 키워드에 따라 원하는 가게나 메뉴를 검색하여 찾아볼 수 있는 기능을 제공합니다.
이 프로젝트에서 우리는 서비스 내에서 발생하는 다양한 상황에 대응하기 위해 유연하면서도 간결한 시스템 설계 방식을 채택했습니다.
•
테스트코드는 무엇을 테스트하고있나요?
◦
컨트롤러 레포지토리는 제외하고 서비스로직의 기능 구현이 잘 작동하나에 대해 테스트하고 있습니다.
예) 유저 회원가입, 가게 등록, 수정 같은 기본 CRUD
•
시간이 남는다면 어떤것을 더 구현하고 싶나요?
◦
리프레시 토큰에 대한 내용
우리의 프로젝트에서는 사용자 인증을 위해 JWT를 활용하였습니다. 하지만 JWT는 짧은 유효기간을 가지므로, 만료되면 사용자가 다시 로그인해야 하는 문제가 있습니다. 이러한 문제를 해결하기 위해 리프레시 토큰이라는 개념을 도입하고 싶습니다.
리프레시 토큰의 주요 개념으로는 안전한 관리를 위해서 사용하는 'Redis'와 같은 in-memory 데이터베이스 시스템의 도입이 필요하고, 빠른 데이터 처리 속도와 TTL(Time To Live) 기능 등으로 세션 정보나 임시 데이터 저장에 적합하며, 리프레쉬 토큰 관리에도 자주 사용되는 개념으로 파악했습니다.
추후에, 보완점을 개선하여 리프레쉬 토근과 Redis를 도입하여 사용자 경험을 더욱 개선할 계획입니다.
•
레디스 개념에 관한 질문 in-memory , 데이터 처리 속도 , TTL, 임시 데이터 저장
1.
In-Memory 시스템: 일반적으로 데이터베이스는 디스크에 데이터를 저장합니다. 그러나 In-Memory 시스템은 메모리에 데이터를 저장합니다. 이렇게 메모리에 직접 접근하면, 디스크에서 데이터를 읽어오는 것보다 훨씬 빠르게 정보를 가져올 수 있습니다.
2.
빠른 데이터 처리 속도: 메모리에서 직접 데이터를 읽고 쓰기 때문에, 처리 속도가 매우 빠릅니다. 마치 답을 찾기 위해 전체 도서관의 책들을 훑어보는 것보다, 바로 자신의 책상 위의 책을 확인하는 것이 더 빠른 것과 같습니다.
3.
TTL(Time To Live): TTL은 '생명 시간'이라고 생각하면 됩니다. Redis에서는 각각의 데이터에 대해 얼마나 오랫동안 저장할지를 설정할 수 있습니다. 설정된 시간이 지나면, 그 데이터는 자동으로 삭제됩니다.
4.
임시 데이터 저장: 임시적인 정보, 예를 들어 방문자의 세션 정보나 임시 비밀번호 등을 저장하는데 유용합니다. 이런 정보들은 일정 시간 후에 필요 없어지므로, TTL 기능을 활용하여 자동 삭제되도록 할 수 있습니다.
따라서 Redis와 같은 In-Memory 시스템은 리프레시 토큰 같은 임시적이지만 빠르게 접근해야 하는 정보를 관리하는데 아주 유용합니다.
리프레시 토큰의 작동 예시
JWT와 리프레시 토큰, 그리고 Redis를 이용한 인증 과정은 다음과 같습니다.
1.
로그인 시: 사용자가 로그인을 하면, 서버는 액세스 토큰과 리프레쉬 토큰 두 가지를 생성합니다. 액세스 토큰은 짧은 유효기간을 가지며, 사용자가 서비스를 이용할 때마다 자신이 누구인지 증명하는 역할을 합니다. 반면에 리프레쉬 토큰은 보다 긴 유효기간을 가집니다.
2.
Redis에 저장: 생성된 리프레쉬 토큰은 Redis와 같은 in-memory 데이터베이스에 저장됩니다. 이때, 각 리프레쉬 토큰에는 TTL(Time To Live)이 설정되어, 그 기간 동안만 유효하게 됩니다.
3.
액세스 토큰 만료: 액세스 토큰의 유효기간이 만료되면, 사용자는 서비스를 이용할 수 없게 됩니다.
4.
리프레시 & 새로운 액세스 토근 발급: 이때 사용자(혹은 클라이언트)는 서버에게 보관하고 있던 리프레쉬 토근을 전달합니다. 서버는 Redis에서 해당 리프레쉬 토근의 유무와 유효성을 확인하고, 문제가 없다면 새로운 액세스 토근을 발급해줍니다.
따라서 사용자는 다시 로그인하지 않아도 계속해서 서비스를 이용할 수 있게 되며, 이것이 바로 "리프레시" 과정입니다.
null 값에 대한 답변 :
간략히. - 밑에는 상세 설명
"null" 값을 가진 중요한 필드(예: 사업자번호)는 데이터의 무결성을 손상시키는데, 이는 고유 식별자가 누락되어 데이터의 일관성과 정확성이 보장되지 않기 때문입니다. 이로 인해 정보 조회나 연산에 오류가 발생하거나, 외래 키 관계 설정에 문제를 일으킬 수 있습니다. 따라서 null을 피하고 초기값이나 기본값을 설정하여 사용해야 합니다.
ex)
예를 들어, 사업자번호 필드가 유저를 구분하는 중요한 식별자라고 가정해봅시다. 만약 특정 유저의 사업자번호가 "null"이라면, 이 유저는 다른 유저들과 동일한 방식으로 식별되지 않습니다. 즉, 사업자번호가 'null'인 한 유저와 'null'인 또 다른 유저를 구분할 수 있는 방법이 없습니다.
또한, 외래 키로 사용되는 필드에 'null' 값이 있을 경우에도 문제가 발생할 수 있습니다. 외래 키는 한 테이블에서 다른 테이블로의 연결을 나타내므로, 이 필드에 'null' 값이 있다면 해당 연결 자체가 불완전해집니다.
따라서 중요한 필드에서 'null' 값을 가지게 되면 데이터의 일관성과 정확성 보장에 문제가 생기며, 이러한 문제들은 전반적인 데이터 무결성을 해치게 됩니다.
•
null 값에 대한 문제 → 필드에 null값 유무
사업자번호 필드가 중요한 역할을 하는 경우, 이 필드에 null 값이 항상 있다면 다음과 같은 문제들이 발생할 수 있습니다:
1.
데이터 무결성 문제: 사업자번호는 각각의 유저를 구분하는 중요한 식별자일 수 있습니다. 이런 경우, 사업자번호 필드에 null 값이 들어있다면 유저를 올바르게 식별하는 것이 불가능해질 수 있습니다.
2.
조회 오류: 사업자번호로 유저 정보를 조회하거나 정렬하려 할 때, 해당 필드에 null 값이 있다면 예상치 못한 결과나 오류가 발생할 수 있습니다.
3.
연산 오류: 만약 사업자번호를 사용하여 어떤 계산을 하려고 한다면, null 값을 가진 필드 때문에 계산 결과도 null이 되거나 오류가 발생할 가능성이 있습니다.
4.
외래 키 제약 조건 위반: 만약 사업자번호 필드가 다른 테이블과의 관계(외래키)를 설정하는 데 사용된다면, null 값을 가진 경우 외래키 제약 조건을 위반하게 됩니다.
따라서 중요한 역할을 하는 필드에서 항상 null 값을 가지는 것은 좋지 않으며, 가능하다면 초기값 혹은 기본값을 설정해주거나 입력 시 반드시 값을 받도록 하는 등의 방법으로 데이터 무결성을 확보해야 합니다.
데이터베이스에서 무결성(integrity)은 데이터의 정확성, 일관성, 유효성을 보장하는 규칙이나 제약 조건을 의미합니다. 즉, 데이터가 특정 기준이나 규칙을 준수하여 올바르게 유지되는 상태를 말합니다. 무결성에는 크게 네 가지 종류가 있습니다.
1.
엔티티 무결성(Entity Integrity): 각 행(row)은 고유하고 고유한 식별자(primary key)에 의해 식별됩니다. 즉, 모든 테이블에서 기본 키는 null이 아니어야 하며 중복될 수 없습니다.
2.
참조 무결성(Referential Integrity): 외래 키(foreign key) 값은 반드시 참조하는 테이블의 기본 키 값 중 하나거나 null 이어야 합니다. 이 규칙은 관계된 데이터 간의 일관성을 보장합니다.
3.
도메인 무결성(Domain Integrity): 모든 열(column)은 선언된 도메인(즉, 해당 열에 저장될 수 있는 값의 집합 및 형식 등)에 대한 값을 가져야 합니다.
4.
사용자 정의 무결성(User-Defined Integrity): 비즈니스 규칙에 따라 정의된 사용자 지정 규칙입니다. 예를 들어 "고객 나이는 18세 이상"과 같은 조건을 설정할 수 있습니다.
시연영상+기능소개멘트
촬영+편집+youtube배포 (3시간)
17시 완료라치면,
회고발표시작 17시시작
우리팀회고발표 18:20