Queosk는 식당 웨이팅과 주문 과정에서 발생하는 시간을 단축시켜 사용자의 식당 이용을 편리하게 만들고,
식당 점주에게는 웨이팅 관리, 결제, 정산 등을 효율적으로 관리할 수 있는 기능을 제공하는 앱입니다.
이 앱은 키오스크 전자 주문 시스템과 웨이팅 서비스를 통합하여, 사용자가 식당을 방문하지 않고도 웨이팅을 등록하고,
본인의 차례가 되면 스마트폰을 사용하여 주문할 수 있도록 지원합니다.
이를 통해 사용자는 보다 편리하게 식당을 이용할 수 있고, 식당 점주는 여러 관리 기능을 하나의 앱으로 효율적으로 관리할 수 있습니다.
 |
 |
 |
 |
 |
 |
|---|---|---|---|---|---|
| Front-End | Front-End | Front-End | Back-End | Back-End | Back-End |
| 심상훈 | 박석한 | 박수빈 | 최병호 | 조동현 | 조현수 |
| 🚀 소셜 로그인(카카오) | 🔍 위치기반 근처 식당 찾기 |
|---|---|
| 💵 웨이팅 신청 | 📝 리뷰 작성 / 수정 |
|---|---|
| 🔖 결제 | 🔔 알림 |
|---|---|
| 🧑🏻💻 판매자 회원가입 | 🚀 판매자 일반 로그인 |
|---|---|
| 🏋🏿 메뉴,테이블 등록 / 수정 | ✅ 조리/웨이팅 현황 |
|---|---|
- AWS의 이미지 서버인 S3를 잘 불러오지 못하고 에러가 나는 문제.
- GitHub에서의 서브 모듈이 적용되지 않는 문제.
- GitHub Repository의 conflict 해결에 관한 문제.
- application.yml의 구성 문제.
- GitHub에서의 서브 모듈이 적용되지 않는 문제에 대해선 이유를 찾지 못함.
- 팀장의 GitHub 사용 미숙.
- application.yml을 수정하였음.
- 서브 모듈 적용을 계속 시도 하였으나, 불가능하여 application.yml을 레포지토리에 올림.
- 임시 방편으로 IntelliJ에서 Confict를 처리하고 스쿼시 머지가 아닌 직접 머지를 위해 리포지토리 설정을 계속 토글함.
- 3주차 전까지 Amazon Web Service에 대한 지식을 더 학습 할 필요가 있음.
- 스쿼시 머지 및 PR시의 Confict 처리 방법, 서브 모듈 적용 방법 등, GitHub에 대한 자세한 공부를 할 필요가 있음.
- 나는 단순한 CRUD만 할줄 알았구나! 하는 생각이 머리를 스치고 있다. 더 겸손하고 더 배워야 한다.
- 테스트 코드에 대해 동료의 테스트 코드를 참조하여 작성하고 있다. 스스로 작성할 수 있도록 공부 할 예정이다.
- API EndPoint 어떻게 해야 Restful 하게 작성해야 하는지에 대한 고민
- dev Branch에 어플리케이션이 제대로 정상 동작을 하지 않는 코드가 머지되어 나머지 작업 진행이 힘들었음
- Restful에 대한 이해도와 익숙하지 않아서 생겼던 문제였음.
- 서로가 제대로 확인을 하지 않고 pr을 날리고 approve를 해서 생긴 문제였음.
- 공식문서와 블로그를 참고하여 최대한 Restful하게 작성해보려 노력했음
- pr에 대한 리뷰를 모두 받아야 머지가 되게 했고, 본인도 pr 올리기전에 어플리케이션을 실행하여 테스트 해보기로 했음
프로젝트 전에 미리 컨벤션을 확실히 정하고, 진행해야 된다고 느꼇고, 테스트코드 작성을 했는데 되짚어보니 빼놓은 테스트코드도 있었고, 좀 더 세심하고 꼼꼼하게 진행해야 될 것 같다.
- Jwt토큰을 통한 토큰 검증 시 Bearer prefix를 붙인 토큰 검증에 실패하는문제
- 이메일 인증완료 페이지 구성에 관한 문제.
- "Bearer" 토큰은 JWT 토큰과 같은 인증 토큰을 사용할 때 사용되는 표준적인 방식 중 하나.
이 토큰은 클라이언트가 보낸 요청에 대해 서버에서 인증과 권한 부여를 처리할 때 사용됨.
UserDetails인터페이스는 스프링 시큐리티에서 인증 및 권한 부여에 사용되는 인터페이스. 스프링 시큐리티는 사용자의 인증 정보를UserDetails객체로 관리하며, 이 객체를 통해 사용자의 권한과 인증 상태를 확인하고 처리. - 프로젝트의 웹앱에서 이루어지는 api 호출이 아닌 이메일을 받은 유저가 링크를 클릭함으로써 호출되는 api이므로 frontend가 아닌 backend에서의 화면처리 필요.
- 역할과 권한을 커스텀User테이블에 넣고, UserDetailsService를 구현하는 Service를 생성하여 SpringSecurity에서 제공하는 User(UserDetails, CredentialsContainer구현)에 커스텀User의 정보를 저장
- resources/static 에 각각 다른 응답을 보여주는 세 개의 정적 html 화면을 만들어 각 응답에 맞추어 반환.
- 인증페이지만을 위해 Thymeleaf 템플릿 엔진을 사용해 1개의 동적페이지만을 사용하는 방법
- Spring Security와 Jwt 토큰 그리고 그 인증과정에 대한 이해도가 조금 높아진 것 같다.
- 좌표를 받아 법정 동을 구하며 그 동네의 매장을 찾을 때 JPA로는 매장을 정렬할 방법을 찾지 못함.
- 원래는 이번 주 안에 배포를 하였어야 했음.
- JPA의 기능으로는 해당 기능을 구현하는데 한계가 있음.
- QureyDSL을 사용하려 했으나, 불안정 이슈와 실력 미달로 인해 실패
- 대안으로 네이티브 쿼리를 사용하려 하였고, 쿼리를 작성 후 돌렸으나 왠지 모르게 실패
- DB의 테이블을 쌍따옴표로 감싸니 성공
- 배포에 대해선 프론트와의 논의를 거쳐 다음주에 배포 시작.
- 해당 기능을 이용해 자신으로 부터 일정 거리 이하로 떨어진 매장도 구할 수 있을것으로 보임
- JPA에 너무 의존하지 말자. 이거 CURD 할때는 좋은데 기능이 좀 모자라다. 혹은 내가 기능을 확실히 모르거나.
- SQL문을 어떻게든 짜야한다는걸 다시 한번 느꼈다. 프로젝트 후에 공부해야지.
- 다음 프로젝트에선 QureyDSL도 다시 한번 도전 해볼 생각이다.
- 배포를 두려워 하지 말자! ✊
- IntelliJ에서 경로가 수정된 클래스를 Import 하지 못하는 현상 발생 (can not resolve symbol….)
- 구글링 결과 캐시 또는 인텔리제이 내부 오류로 프로젝트 코드/의존성 라이브러리를 불러오지 못하여 발생한다고 한다.
- IDE 재실행 → 해결 X
- Build > Rebuild Project → 해결 X
- 캐쉬 삭제 후 재시작 → 해결 X
- .idea 삭제 후 재시작 → 해결 O
- File > Project Settings > Project & SDKs 에서 JVM 설정 다시하기 로 해결되는 경우도 있다고 한다.
- 이번 주에는 외부 api연동 및 User service 리팩토링 , Menu 서비스 개발을 진행했다. 깃 사용법이 드디어 조금 익숙해졌고 외부 api연동하는 부분도 조금씩 익숙해진것 같다.
- 정산 API 구현 함에 있어 스프링 배치를 사용해야 할지, 아니면 단순히 쿼리를 이용한 조회연산을 할지 고민이 있었음
- 스프링배치는 일괄대용량 데이터처리를 할 수 있다는 장점이 있지만, 가게마다 마감시간이 다른데 일괄처리 되기 전에 가게가 매출을 알고싶어 했을 때 일괄처리 전이라면 매출정보를 알 수 없다는 단점이 있다고 생각함
- 단순쿼리를 이용한 연산을 사용할 때는 가게가 매출을 알고 싶어할 때 즉각적으로 보여줄 수 있는 장점이 있지만, 가게가 요청을 할 때마다 매번 조회할 때마다 다시 연산을 실행해야 한다는 단점이 있음.
- 일단 queryDSL을 통한 일별 매출과 기간별 매출을 구현했음
- (지금은 프론트와 협의하여 제거한 기능입니다.) 클라이언트↔ 서버 간 WebSocket 통신은 성공했으나 서버에서 전달하는 값이 업데이트되지 않는 현상
- WebSocket은 데이터를 문자열이나 바이트 형태로 주고받기때문에. 객체를 WebSocket을 통해 전송하려면 업데이트하고자하는 데이터의 직렬화가 필요했다.
- 데이터를 JSON 형태로 직렬화하여 전송하였고 성공했다.
- 직렬화 라이브러리를 사용하여 바이트 형태로 전송할 수 있다고 한다.
- 제거된 기능이긴 하지만 웹소켓을 연동해보며 웹소켓의 동작원리와 구조에 대해 조금 알게되었다. 기회가 된다면 다른 프로젝트에서도 활용해보고 싶다.
- 정산 API 구현 함에 있어 스프링 배치를 사용해야 할지, 아니면 단순히 쿼리를 이용한 조회연산을 할지 고민이 있었음
- 스프링배치는 일괄대용량 데이터처리를 할 수 있다는 장점이 있지만, 가게마다 마감시간이 다른데 일괄처리 되기 전에 가게가 매출을 알고싶어 했을 때 일괄처리 전이라면 매출정보를 알 수 없다는 단점이 있다고 생각함
- 단순쿼리를 이용한 연산을 사용할 때는 가게가 매출을 알고 싶어할 때 즉각적으로 보여줄 수 있는 장점이 있지만, 가게가 요청을 할 때마다 매번 조회할 때마다 다시 연산을 실행해야 한다는 단점이 있음.
- 일단 queryDSL을 통한 일별 매출과 기간별 매출을 구현했음
담당한 부분이 아니기도하고 Devops 업무에 가까운 업무이긴 하지만 프로젝트 배포 일정이 다가옴에따라 이와 관련한 몇가지 특징을 공부해보았다.
큐오스크 프로젝트는 EC2, Docker 그리고 Jenkins를 사용하여 CI/CD 를 통한 배포를 진행한다.
- 확장성: AWS EC2를 사용하면 필요한 만큼의 컴퓨팅 리소스를 확장/축소 유리.
- 효율성: Docker 컨테이너는 가상화 기술을 사용하여 애플리케이션을 격리하고 가볍게 실행할 수 있어 리소스를 효율적으로 관리가능
- 자동화: Jenkins를 사용하면 빌드, 배포 및 테스트 프로세스를 자동화할 수 있으며 CI/CD 파이프라인 구축 용이
- 탄력성: AWS EC2를 사용하면 인스턴스를 동적으로 조정하여 트래픽 변동에 대응할 수 있음
- 비용: AWS 사용시 금전적인 비용 발생
- 관리 복잡성: 여러 컴포넌트를 함께 사용하는 경우, 인프라스트럭처 및 설정 관리가 복잡해질 수도 있음
- 보안: 보안 설정이 부족하거나 실수로 설정을 잘못 구성할 경우 보안 취약점 발생가능성 있음
**CI/CD (Continuous Integration, Continuous Deployment)CI/CD는 소프트웨어 개발 및 배포 프로세스를 개선하고 자동화하기 위한 개발 방법론 및 접근 방식
- axios 에서의 토큰 저장방식 및 저장해야할 토큰 에 대한 고민
- React에서의 새로고침시 로그인을 유지하기 위해서는 저장소를 사용해야하는데 이 방식이 여러가지라 고민을 했습니다.
- 로컬 스토리지에 accessToken과 refreshToken을 저장하고 axios interceptor를 통해서 해결하는 방법으로 해결 했습니다.
- msw 공부 및 패턴 자료 탐색
- axios interceptor에 대해 좀더 자세히 알게 되었습니다.
- 웨이팅 등록 페이지에서 인원수를 체크하고 다음 웨이팅 확정 컴포넌트로 넘어갔다가 인원수를 다시 체크하기 위해서 웨이팅 등록 컴포넌트로 되돌아갔을 시 인원이 초기화 되는 문제 발생.
- 웨이팅 현황 페이지에서 현재 시간을 보여주는 항목이 next.js 서버 시간과 오차가 발생해 오류 발생.
- 웨이팅 등록 컴포넌트를 다시 불러오면서 인원수를 나타내는 [count] state가 다시 초기화되는 문제.
- next.js 서버 시간과 클라이언트 시간이 달라서 렌더링된 HTML 내용이 달라서 발생하는 문제.
- 문제를 해결하기 위해서는 local에 count 값을 저장하거나 상태 관리를 통해서 count 값이 유지되어야 할 것 같음.
- 문제 해결을 위해 상태관리에 대한 정보를 찾아 보는 중.
- next.js 의 서버 시간을 받아와서 new Date() 괄호 안에 넣어주면 시간이 동기화되며 해결될 것으로 예상.
- 웨이팅 현황 페이지에서 현재 시간을 보여주는 항목이 next.js 서버 시간과 오차가 발생해 오류 발생.
- 레이아웃 및 디자인 통일성이 필요할 거 같다는 멘토님의 의견에 따라 레이아웃 및 디자인 통일이 필요.
- next.js 서버 시간과 클라이언트 시간이 달라서 렌더링된 HTML 내용이 달라서 발생하는 문제.
- 프론트엔드 팀이 각각 작업을 하면서 맡은 컴포넌트의 컨테이너만 규격이 정해져있고 나머지는 각자의 디자인을 하다보니 통일성이 사라짐.
- next.js 의 시간을 받아오는 것이 아직 해결되지 않음, 문제의 해결책을 좀 더 찾아보고 해결하거나 또는 해결하지 못했을 시에도 멘토님에게 알려드리기로 함.
- 기능 구현 후 프톤트엔드 팀원끼리 모여서 디자인 통일성에 대해서 한번 논의가 필요.
- 팀원 한분의 막바지 이탈로 작업해야할게 갑자기 늘어나게 됨
- axios 요청을 통한 redirect 가 진행되지 않음
- msw를 사용시 작업중인 컴퓨터의 사양에 따라 서로 다른 속도로 Msw가 마운트 되는 현상 발견 ( 수빈님의 제보 )
- axios의 경우 기본적으로 status code 3xx 번 코드를 자동으로 redirect가 아닌 get요청을 보내는 사항을 발견
- axios 관련
- msw 코드를 300 ~ 307 까지 다 수정해도 자동으로 get 요청을 보냄
- header의 location은 잘 인식하나 이를 get요청을 보내서 페이지로 요청이 안됨
- fetch로 했을때는 작동을 하나 이 방법은 좋은 방법이 아님 ( Proxy 설정이 무시됨 )
- msw 관련
- msw의 마운트 전에 모든 컴포넌트를 로딩 안되게 해야 겠다고 생각하고 이를 기반으로 MSWWrapper component를 작성했습니다
- 세부 로직으로는 msw가 마운트 될경우 children을 포함하여 출력하고 아닌경우 “MSW 로딩중…”이라는 텍스트를 출력하게 했습니다.
- 해당 컴포넌트의 경우 실 프로덕트 상황에서 MSW 환경변수가 enabled가 아닌경우 사용자에서 표시되지 않고 넘어갑니다.
- msw의 마운트 전에 모든 컴포넌트를 로딩 안되게 해야 겠다고 생각하고 이를 기반으로 MSWWrapper component를 작성했습니다