멘토링 1주차

멘토링 준비 자료 (질문드릴 사항)

1. 메뉴 데이터 획득 방안

검색 시 메뉴 자체를 키워드로 사용하려고 했으나 Open API 에서는 상호명, 음식의 카테고리 만을 제공.

• 방안 1

  포털 사이트(네이버, 다음 등)에서 각 음식점의 메뉴 정보를 크롤링

  • 법적 이슈 존재
  • 모든 정보를 크롤링하여 DB에 적재 시 비용적 측면이 감당될까

• 방안 2

  라벨링 하듯 메뉴 데이터를 직접 샘플로 입력

  프랜차이즈와 같이 메뉴가 동일한 점포에 대해서 일괄적으로 데이터 입력 적용

• 방안 3

  사용자로 하여금 직접 메뉴를 입력하도록 설계

2. 기술 스택

Nest.js + TypeScript를 적용하기로.

3. 브랜치 전략

• 방안 1
  • 기능별 브랜치 분화
  • 프론트엔드, 백엔드로 역할 분리를 하지 않았기 때문에 브랜치 병합 시 더욱 직관적임
  • feature/#issue
• 방안 2
  • 최상위에서 FE, BE로 분리 후 기능별 분화
  • 따로 분리 시 작업 내용이 명확하고 충돌 위험이 적음?
  • feature/be/login , feature/fe/#1

4. 기타 질문

• 음식점 데이터를 어떻게 가지고 있어야할까. Open API 를 통해 얻은, 혹은 크롤링한 데이터를 우리 서비스 DB 에 갖고 있어도 되는가.
• 멘토님과 상황 공유가 잘 이루어지지 않고 있다. 어떤 식으로 공유 해드리는 것이 좋을까.

멘토님 답변

1. 기술 스택

Nest.js + TypeScript 적용키로

Nest.js의 굉장히 높은 러닝커브를 고려해야한다. 다만 팀 내 Java Spring 을 사용해본 팀원이 있기 때문에 주도적으로 구현해 볼 수도 있을 것 같다.

추가적으로 기술적 챌린지의 일환으로 Next.js 도 고려해보면 좋을 것 같다. 물론 현재 서비스 로직에는 Next.js 가 적절하지 않기는 하다. (실질적으로 구현해야하는 페이지가 단 2개이기 때문에, SPA 방식이 적절)

• 여담: Naver 는 모든 페이지마다 각각의 Next.js 서버를 두고 개발

2. 브랜치 전략

기능별 Branch 분화 vs BE, FE 별 Branch 분화

개인적으로는 전자의 방식이 좋다고 생각한다. 왜냐하면 서로 BE, FE 구분을 하지 않은 상태에서 각각의 소스코드가 서로 다른 Branch 에 존재하면 테스트하기 굉장히 어려워질 수 있다.

3. 음식점 데이터의 저장 및 활용

음식점 데이터를 어떻게 가지고 있어야할까. Open API 를 통해 얻은, 혹은 크롤링한 데이터를 우리 서비스 DB 에 갖고 있어도 되는가.

크롤링 한 데이터를 DB 에 저장하고 이를 상업적인 용도로 이용하게 되면 법적으로 문제가 되는 것으로 안다. 다만 우리는 단순 개인 프로젝트(?)라서 괜찮지 않을까. Open API 의 정책도 잘 확인해보아야 한다.

4. 멘토님과의 상황 공유

멘토님과 상황 공유가 잘 이루어지지 않고 있다. 어떤 식으로 공유 해드리는 것이 좋을까.

멘토링 전에 공유할 링크, 안건을 미리 공유해주시면 어느정도 내용에 대한 이해를 한 상태로 멘토링에 참여할 수 있을 것 같다.

5. 기술적 도전

slido 같은 ui 구현 등을 기술적 도전이라 볼 수 있을까

볼 수 있다. 기존에 몰랐던 기술들로 진행하는 것은 전부 일종의 기술적 도전으로 볼 수 있다. 가장 최악은 알던 기술로만 프로젝트를 진행하는 것.

ETC

1. 풀스택 개발

• 멘토님 - 권장하고 싶다. 다만 이를 가지고 기업 지원문서를 작성한다면, 그 때는 크게 도움이 안될 수도 있다. 그럼에도 불구하고 권장하고 싶다.

2. 모바일 웹 구현과 기술적 도전

• 멘토님 - 모바일 웹을 구현하는 것은 당연하게도 기술적 도전이다. 기존에 써보지 못한 이벤트 핸들러 등, 데스크탑으로 한정 했을 때보다 완전히 다른 개발 환경에 어지러울 수 있다.

3. 로그인 및 회원가입

• 멘토님 - 로그인 기능은 현재 단계에서는 필요 없더라도 구현을 권장하고 싶다. 우선 해당 기능을 쓰지 않는 기술이 거의 없을 뿐 더러 이후 리뷰와 같은 기능이나 창이 닫혀도 세션을 유지하기 위해서는 로그인을 도입해야한다.

4. 채팅 기능

• 멘토님 - 어차피 해당 서비스는 음식점 선택에만 영향을 미치고, 나머지 소통은 다른 어플리케이션(ex. 카카오톡)을 통할 것 같은데 굳이 채팅을 구현할 필요가 있을까? 이를 위해서 소켓 통신을 유지하는 것은 일종의 낭비라고 생각한다.
• 멘토님 - 추가적으로, 채팅 기능 보단 음식점 리뷰와 같은 기능을 고려해보는 것은 어떨까.