[NestJS/오세유] 멘토링 회고

멘토님 Q&A

개발 관련

• 프론트에서 권한 없는 요청이나 잘못된 요청을 받았을 경우 백엔드에서 강제적으로 처리하는 것이 좋은가? 아니면 프론트에서 처리하는 것이 좋은가?
  • mvp라면 묵과해도 되는부분! → 북마크 기능은 after mvp
  • user - login, logout, 구직 flow
  • 농가 - 구인 flow
  • 결제 기능 → 사업/수익성 고려하는 경우 필수적으로 들어가야 하는 기능.
    • 과정, 개발에 더 집중하는 경우는 x
    • 완성도 있는 prod → 정산, 결제 처리 싸이클 경험해보는건 좋을 것 같다.
    • payment → 구독 서비스 (사업성 고려시 무조건! 봐야하는 부분)
• Auth → 카카오톡 소셜 로그인
  • 인증: 현업에서도 매우 어려운 토픽. “인하우스” !
  • 반대로 소셜 로그인부터 시작하는건 어떤가?
  • 실제로 현업에서도 오래 걸리는 인증 부분
• api문서(swagger)같은 프론트에게 전달할 때 이것 만큼은 꼭 넣어야한다.?
  • postman도 좋은 tool
  • mvp 모델 하나하나마다 문서 필요
• 프론트나 백엔드에서 할 수 있는 보안 이나 최적화 팁 또는 서로 간의 의견이 다를때 합의점을 찾는 방법
  • 보안쪽은 mvp에서 크게 고려해야할 정도는 아니다. 최소
  • 보안은 끝이 없고 mvp에서 우선순위를 낮춰도 된다.
  • 지향점 셋업하기 의사결정에 큰 도움.
  • 원하는 바가 있을 때는 좀 더 치열하게!
  • 작은 성공들을 해보는 것.
  • 매우 작은 스프린트(2주 단위 끊기)로 나누기
    • 한 가지 주제를 정하기.
    • 예) 비인가된 유저가 로그인 되는 서비스 → 달성할 목표들을 리스트업해보기
• 디자인 패턴대로 만들는것이 좋은가? 아니면 일단 만들고 패턴을 적용시키는 것이 좋은가?
  • 후순위가 될 가능성이 높다. 팀 안에서 특정 디자인 패턴을 능숙하게 쓸 수 있으면 쓰면 좋다!
  • 스파게티 코드도 경험해보는게 좋다..! 디자인 패턴을 적용해보고 안해보는것 둘다 경험!?
• 개인적인 질문(프론트에서 데이터를 수집할때 어디까지 수집할 수 있는가 ex ip주소등)
  • 보안, 정책
  • ip block하는 경우 :
• 프론트엔드 디버깅 팁, 테스팅도 규모가 작을때도 하는것이 좋은가?(jest)
  • 테스팅 : 컴포넌트 단위로 테스팅. 어ㄸ허게든 커버리지 100까지 할 수는 있다! 하지만 의미 X.
  • 크리티컬패스(실제 서비스가 워킹하는데에 있어 꼭 필요한 플로우)에 대한 end to end.
  • 백엔드 → 카카오톡 로그인이라고 하면, 테스트 계정을 가지고
  • 디버깅 → 구글 insepctor
• 프론트와 백에서 데이터를 어떤식으로 주고받는게 좋은가?
  • API를 통해서.
  • messaging
  • RCP
• 추천서비스관련
  • 외부 API 끌어쓰다가 비용측면에서 문제때문에 인하우스로 넘어갈것같다.
  • 당장은 지도 API를 통해서 구현하는게 도움이 될 것 같다.
  • 실질적으로 low Data를 가지고 ML시켜서 product에 유의미한 영향을 주는 정도까지 하는게 좋지만 당장에는 API까지만.
  • 농가를 만족시킬 수 있는! 우선 고객부터..시도해보기
  • 도메인이 많다..!
  • 어려운 서비스다.
• 이정도 규모에서의 상태관리는 어떤식으로 진행하는게 좋은가?(context API, redux, recoil)
  • context API를 활용!
• 정합성 테스트 → db에 잘 들어가는지? 지워지는지? 조회, 수정 등
  • 테스팅 코드
  • CRUD 테스팅 → 테스팅 커버리지로.
• MVP에서는 우선순위 낮을수도
  • postman도 많이 쓰이는 툴임!
• district enum 필드의 경우
  • 시 → 군 → 면, 읍 등등 나뉘어질 것
  • 주소 체계가 필드로 들어가야 함
  • 현업에선 잘 쓰이지 않는 구조..
  • 국가, 지역 CODE 값 (매핑되어있는 주소 체계)
  • mapping로직 : 클라이언트에서 table이 필요한 경우가 생김
  • 주소 API 활용하기.

Front-back

• communication: API를 통해 데이터를 교환한다!

추천 기능

• 비즈니스적인 요구사항이 필요.
• 주소체계 → 수익을? : 자체적으로 추천 서비스(추천 데이터시스템)
  • 초반엔 api를 사용. 비용을 줄이기 위해 in-house 시스템 개발을 하게 됨
• 지도 api
  • 실제로는 raw 데이터를 가지고 머신러닝
    • product에 도움될만한 인사이트를 뽑아냄..
    • 지금 mvp로는 그냥 api 사용

도메인

• 유저, 농가, 숙박, 교통!!
• 고객부터…

비즈니스 모델

• wanted, 숨고와 모델이 비슷. 고려 👍🏻
• 실제 현업에서는 우선 고객 유치를 한 후에 발전해나감
• 정책들!

오세유의 모델

• 구인글 하나 올릴 때마다 비용 받는것 → 허점이 있음 !
• 매칭이 한 번 이뤄진 후에는 더이상 서비스를 이용할 필요가 없음…
• “플랫폼을 앞으로 이용할 것인가?” → 숨고 참고해보자..
• 농업진흥청과의 collaboration
• abusing → 고객이 서비스를 오용? 하는 경우도 고려해야 함

“number”

• 얼마나 많은 고객, 배너 등 단가.. “수익”이 추가되면 더 나은 사업계획서가 될듯

프로젝트 진행 관련

• Front와 Back이 협업 할 때 지속적으로 주고받아야 할 사안들은 무엇이 있을까요?

런칭

• 실제 서비스를 런치해보는 경험을 해봐라!!!
• 농업진흥청과의 콜라보 → 농가에서 일하고 싶은 사람, 외국인 노동자
  • 페르소나 (고객층) 가 매우 중요함 → 서비스의 방향