진행 상황 공유

• 프로젝트 진행도

• 기능 구현 진행도

• 질의응답

  • 전 반에서도 바쁜 시기여서 질문이 없었음

• ucc 공유

  • 부끄러워 하심

• ucc 15초 뒷부분 검은색 처리 프론트엔드 질문

  • dim 처리
  • 바디에만 dim처리를 한 이유
    • 고민을 많이 하셨음
    • 수령장소를 하는 데 자기가 선택한 수령 장소를 확실하게 표현을 해주기 위함
    • ui,ux 부분에 고민을 많이 해줘야 함
  • 왜 그렇게 만들었는지 계속해서 고민해야 함
  • radius 깎는 것도 padding이랑 함께 고민하면서 깎아야함
    • padding과 radius 비율도 같이 생각하면서 깎아야 함
  • 기술은 계속 해서 바뀌지만 ui, ux는 계속해서 쌓아가는 것이기 때문에 계속해서 고민해야 함
  • 프론트 jwt 인증 인가 해서 던지는 것도 중요하지만 ui, ux도 중요하다.
  • 프론트는 변수 처리도 같이 고민하는 것이 좋음
    • 어디까지 변수 처리를 해야 하는지
    • 실무에서는 백엔드를 admin과 db를 연결시키기 때문에 바꿔지면 프론트에 나와야 해서 같이 변수처리에 고민을 해야 함

• 백엔드

  • 서비스 나눠서 연결해보는 중
  • 클라우드 스톤은 msa로 넘어가는 단계
  • 처음에 msa를 하지 않은 이유
    • 처음부터 하기에는 어려움
    • 어떤 서비스가 어떻게 될지 모름
    • 포인트나 쿠폰 이런 것들이 예측이 되지 않아서(독립db를 가져가도 되는지)
  • 각각의 장점이 분명히 있음
  • unicon 회사들도 조금씩 바꿔나가고 있음
  • db가 엮어있는 것이 너무 많아서 확장성을 고민하고 있음
  • 실제로 속도가 그렇게 나지 않음

Q. 접근에 대한 조건을 달아서 msa를 도입해야 하는지

A. db를 영향이 없는 것부터 뜯어서 msa로 도입하려고 생각 중. 엮여있는게 많으면 동기화가 중요한데 엄청 작은 단위부터 엮여있지 않는 것을 먼저 뜯으려고 고민중

• db를 하나로 두면 db가 엄청 커짐
• 현업에서는 무결성도 중요하지만 관리 감독을 하는 것도 중요함
• 테이블에 컬럼 하나만 추가해도 어디서 문제가 생겼는지 모를 수도 있음
• 서비스적인 차원에서 더 고민해야 함
• 데이터에 내가 로그가 차 있으면 마이그레이션도 고민해야 함

뜯은 db는 성능을 어느정도로 쓸까가 비용 문제에 연관이 되어 있기 때문에 고민 해야함

• redis가 좋다는 것은 앎, cache로 빠르게 가져옴

  • redis를 달면 db가 터지지 않으니까 좋음
  • redis가 잘 유지가 되려면 kafka나 raddit mq도 달아야한다고 생각함
  • over engineering이 되어버림

• 프로젝트는 이것 저것 해 볼 수 있어서 좋음