[Node.js_4기] 최종프로젝트 1일차 TIL_회의 (24/03/26)

목차

 

1. 문제

2. 시도

3. 결과

4. 배운점

 

1. 문제 

 

최종 프로젝트가 발제되었고, 어떤 서비스를 개발할 것인지 하루종일 회의하였습니다.

 

2. 시도 

 

1. 나무위키의 아성을 뛰어넘는 새로운 위키 <<< 나무위키의 위대함 앞에 fail

2. 공공데이터+AI << 최종 프로젝트로 할만한 볼륨은 아닌것 같아 fail

3. 주식 or 코인 + AI투자 << 수익을 내는 서비스가 되는건 불가능할것 같아 fail

4. PT (webRTC를 사용, 사진을 찍어 올리면 해당 식단을 ai에게 평가받고, 추가적으로 트레이너에게 코멘트도 받을 수 있는 서비스 + @)

5. 귀농 지원 (정보 , 커뮤니티 , 이미지 분석을 통한 작물 상태 확인 + @)

6.  다나와의 마이너 카피 (이미 다나와가 있다.)

 

팀원간의 회의로는 PT 또는 귀농지원 두가지로 좁혀졌습니다.

 

3. 결과 

 

해당 내용을 담당 튜터님께 상담받았고, 

상담 결과는 다음과 같습니다.

 

<대략 요약본>

1. 백엔드 책임: 데이터 처리, 프런트엔드의 요청 처리 및 대시보드

<< 해당 내용은 백엔드의 마음가짐에 대한 이야기 였습니다. 취업 전략, 프로젝트 목표를 대략적으로 설정하는데 도움이 될 내용이였습니다. >>
2. 고객 참여 유형: 잠재적인 대량 할당으로 인해 백엔드 할당을 권장하기가 어렵습니다.

3. 서비스: 사용자가 여러 명일수록 복잡성이 증가하므로 신중한 API 구성이 필요합니다. AI 분석이 추가될 가능성이 있으므로 프로세스 자동화가 중요합니다.

4. 플랫폼 생태계: webRTC를 사용하는 제품 관리, 대시보드, 모니터링 채널을 위한 관리자 페이지가 필요합니다.

<< 이어지는 내용으로, 서비스를 어떻게 구성하는지에 따라 난이도와 볼륨이 달라진다는 내용입니다.>>

<< 1과 연계되어, 백엔드 개발자의 경우 프런트 엔드와 외부 기획자, 마케터등을 주요 고객으로 삼기 떄문에 , 대시보드를 구성하여 서비스의 플로우등을 보여줄 수 있으면 좋다는것 같습니다..>>

5. 기술 권장 사항: 외국 지역의 경우 Azure, SNS(Simple 알림 서비스), SQS, 게시/구독 패턴과 같은 AWS 서비스를 고려하세요.
6. 백엔드 확장 영역: 보안, 데이터 분석, 데이터베이스 관리, 인프라 아키텍처 및 API 성능.
8. 메시지 대기열: 수십만 또는 수백만 개의 요청을 효율적으로 처리하는 것을 고려하여 SQS 대기열에 게시자-구독자 모델을 사용합니다.
9. 전반적으로 이 프로젝트는 여러 사용자에게 서비스를 제공하는 동적 웹 플랫폼을 지원하기 위한 복잡한 백엔드 작업을 포함하며 기술 및 확장성 문제를 모두 제기합니다.

 

4. 배운점 

 

결과적으로, 이번 최종 프로젝트를 통해 최대한 많은 기술을 사용해보고, 많이 깨지고 부서지면서 트랙을 마무리할 수 있었으면 좋겠습니다.