시나리오 관련

1. 지금부터 규모가 큰 프로젝트를 진행하려고 한다면 시나리오가 매우 구체적이어야 할 필요가 있을 것 같습니다.
2. api 명세 정도로 정리해보시는걸 추천드립니다.
3. 지금까지 해왔던 것처럼 도메인으로 나누고 업무를 분담하는 방식으로는 진행이 어려울 것이라고 생각합니다.
4. 구체적으로 시나리오를 작성하고 -> 그 시나리오를 기반으로 이슈를 생성하고 -> 그 이슈를 기반으로 업무를 분담하면 순차적으로 진행되어야 하는 순서가 꼬이지 않고 개발을 진행 할 수 있습니다.
5. erd와 api 명세도 그 시나리오를 기반으로 다시 정리 할 수 있기 때문에 지금이라도 시간을 써보셔도 좋을 것 같습니다. 나중에 소요될 시간을 더 아낄 수 있거든요

API 명세 관련

1. 아마 시간이 부족해서 추가 못하셨겠지만, 모든 요청에 상태코드와 응답값을 추가하시는게 좋을 것 같습니다
2. 인증 칼럼을 두는 것 보다 차라리 api 헤더정보를 정리해보시면 좋을 것 같네요
3. 유저 팔로우와 취소에서 팔로워 아이디를 받을 이유가 있는지 궁금합니다.
4. 모집글 조회는 하나의 api에 파라미터로 전체 신청 좋아요 등을 구분해서 내려주도록 수정해도 좋을 것 같네요
5. 댓글 api에서 저장이 되어있는 유저정보를 같이 보내는 이유도 궁금합니다.
6. 그 외에 api는 깔끔하고 좋은 것 같습니다.

ERD 관련

1. 시나리오와 기능 정의가 아직 구체적이지는 않아서 정확히 파악은 안되지만, 모집글과 기술스택은 고민이 필요해 보이네요, 별도의 테이블로 분리해서 오히려 중복 데이터가 많아지지 않을까 하는 걱정이 됩니다
2. 유저와 기술스택도 마찬가지 입니다, 1번 2번 둘 다 배열 형태의 칼럼으로 저장해도 괜찮을 것 같네요
   • 로직에서 반복문으로 처리
     • java,spring,javascript
       • split(”,”) 사용
     • 중간에 스택 하나를 제거하고 싶다면?
       • ex) a,b,c,d,e,f,g, N=7
         • b,d,f을 제거 M=3
         • 제거하려는 기술스택을 찾는 시간: O(N*M)
         • 배열에서 제거하는 시간: O(N)
   • DB에서 기술스택 갯수만큼 조회
3. 직군별 모집인원도 아직 추측이지만 테이블 분리하지않거나 아예 히스토리성 테이블을 만들고 조회를 잘 하면 필요가 없을 것 같습니다.

전반적인 프로젝트 관련

1. 소켓 여는건 백엔드 작업보다는 프론트쪽에서 생각할게 상대적으로 많습니다. 시간이 많이 소요될 수 있고 처음 진행해보시는 만큼 채팅쪽을 빨리 구현하실 생각으로 진행하시면 좋을 것 같습니다.