1.
서비스 와이어프레임, API 명세서, ERD 등이 잘 구성되어 있습니다. 기능적인 측면에서도 단순히 CRUD 기능만 있는게 아니라, 채팅 기능까지 요구사항에 추가하셨다는 점에서 여태까지 해왔던 프로젝트와 차별화 포인트가 존재한다고 생각합니다. 다만 웹 소켓 관련해선 서버 설정과 클라이언트에서 추가되어야 할 의존성(stomp.js 등)들이 있습니다. 이 부분도 처음 구현하신다면, 미리 예제 코드를 따라서 설정해보시길 권해드립니다.
2.
또 지금과 같은 커뮤니티 서비스를 구현하시면, 향후 기업에서 일하실 때(백오피스나 어드민 서비스 등등) 연관된 주제 구현 시 도움이 많이 될 수 있어, 주제를 잘 선택하셨다고 생각합니다.
3.
다만 여행 정보, 코스, 도시, 유저 간 채팅 및 팔로우 기능 등 구현해야 할 기능들이 많은 상황이라, 구현의 우선순위를 정하고 우선순위 대로 구현하는 것이 중요할 것 같습니다.
4.
카테고리별 여행 정보에서 여러 조건으로 조회 가능하도록 구현하는 것이 구현에 시간이 오래 걸리고 어려울 수 있습니다. QueryDSL을 사용하실 것인지 JPQL을 사용하실 것인지, QueryDSL을 사용하신다면 QueryDSL 설정 방법과 조회 방법에 대해서 미리 충분히 익혀두시고 기능 개발을 시작하시길 권해드립니다. 충분히 학습하지 않으면, 오랜 시간이 소요될 수 있기 때문입니다.
5.
또 프론트엔드와 배포까지 하려면 3주라는 시간이 꽤 빠듯할 것 같습니다. 해당 내용들이 어렵진 않으나, 익숙하지 않으면 시간이 오래 소요될 수 있어 미리 프론트엔드 설정을 해보실 것을 권해드립니다. 또 되도록이면 React보다는 vue나 Thymeleaf를 사용하는 걸 추천드리는데요. React를 사용하면 별도의 프론트엔드 서버를 구성(당연히 배포까지)해야 해서 시간이 오래 걸릴 수 있습니다. 가장 시간이 적게 드는 Thymeleaf + Bootstrap 조합을 사용하실 것을 권해드립니다.
6.
팔로우, 팔로워 기능을 구현하기 위한 ERD 테이블에서 followingId와 followerId 대신, follower_userid, following_userid 로 대체 되어야 할 것 같습니다. 팔로잉 ID와 팔로워 ID로는 유저 정보를 조회할 수 없기 때문입니다. → 이건 해결함, 근데 다른 문제 질문
7.
추가적으로 서비스 아키텍처도 그려보시면 좋을 것 같습니다. 배포는 어떻게 할 것인지, 프론트엔드 기술은 무엇을 쓸 것인지 등등을 아키텍처 다이어그램을 그리시면서 미리 정리해보실 것을 권해드립니다. → 해결
8.
기능적인 요구사항을 보면, 기능을 구현하는 측면에서는 흠 잡을 것 없어 보입니다. 여기서 한 단계 더 좋은 어플리케이션이 되려면, 시스템 요구사항을 고려해보시는 것이 좋습니다. 가령 확장성 있는 어플리케이션을 만든다면, 로드밸런서를 추가하고 여러 대의 서버 요청을 분산해서 처리하는 구조로 변경할 수 있습니다. 또 실제 배포까지 하신다면 모니터링 시스템을 도입해볼 수 있습니다. 그라파나와 프로메테우스를 사용하신다면, 서버 메모리 사용량, 활성 세션 수 등의 정보를 대쉬보드에서 쉽게 확인하실 수 있습니다.
9.
현재 어플리케이션에서는 채팅 정보를 RDB에 저장하고 계십니다. 제가 면접관이라면 Redis, NoSQL, ElasticSearch 등 유저 간 채팅을 저장하기 위한 NoSQL 서비스가 존재하는데, 다른 여러가지 고려사항 중 왜 RDB를 사용하셨는지 여쭤볼 것 같습니다. 채팅 과정에서 DB I/O 작업을 거치며, 어플리케이션의 실시간성이 저해될 수 있을 것 같습니다. 이 부분에 대해서 기술적으로 합당한 의사결정인지 뒷받침될 근거가 필요해보입니다.
