Q. 전반적인 프로젝트 기획 및 MVC 목표에 대해서 평가해주십시오.
A. 멘토님답변정리!
프로젝트 주제 자체는 이전에 다른 조에서 봐왔던 프로젝트와는 다르게 참신하고 좋은 것 같습니다만, 내부적으로 구현할만한 요소들(데이터 관점에서 회원, 설문, 응답 3개로 구성)이 부족하고 기술적 트러블 슈팅이 크게 없는 주제인 것 같아 기획적인 측면에서도 살을 좀 더 붙이는게 좋을 것 같습니다.
API 설계는 Restful하게 잘 구성해주셨는데, Servey가 아니라 Survey로 수정해주셔야 될 것 같고,() 한 가지 체크해주시면 좋을만한 부분은 뒤에 대상 ID가 나오는 경우는 보통 대상을 복수로 잡아둡니다. 예를 들어, 질문지 선택 조회 API의 경우 GET /api/surveys/{surveyId} 이런식으로 구성이 될 수 있습니다. path 부분만 조금 더 가다듬으면 될 것 같습니다.()
ERD는 전부 양방향 매핑으로 설계해두셨는데, 그렇게 한 이유가 있을까요? 설문지나 응답지를 기준으로 회원을 조회하는 기능이 있다면 의미가 있겠지만, 실제로 서비스 내에서 어떤 것을 메인(주)으로 잡고 조회하는지에 따라 매핑 관계를 지정하는 것이 좋습니다. 단/양방향 매핑 관계에 대해 좀 더 학습해보시고 제대로 적용되었는지 한번 더 체크해보시면 좋을 것 같습니다.
) 한 가지 체크해주시면 좋을만한 부분은 뒤에 대상 ID가 나오는 경우는 보통 대상을 복수로 잡아둡니다. 예를 들어, 질문지 선택 조회 API의 경우 GET /api/surveys/{surveyId} 이런식으로 구성이 될 수 있습니다. path 부분만 조금 더 가다듬으면 될 것 같습니다.()
ERD는 전부 양방향 매핑으로 설계해두셨는데, 그렇게 한 이유가 있을까요? 설문지나 응답지를 기준으로 회원을 조회하는 기능이 있다면 의미가 있겠지만, 실제로 서비스 내에서 어떤 것을 메인(주)으로 잡고 조회하는지에 따라 매핑 관계를 지정하는 것이 좋습니다. 단/양방향 매핑 관계에 대해 좀 더 학습해보시고 제대로 적용되었는지 한번 더 체크해보시면 좋을 것 같습니다. → 회원:설문지를 양방향으로 한 이유
설문지(survey에선 userId, username를 확인하기 위하여 → 그 설문지의 작성자를 표시해주려는 목적 → 예로, “건강보험공단”님의 설문입니다.)
→ 회원:응답지를 양방향으로 한 이유
응답지(answer에서도 userId를 확인하기 위하여 → 그 응답지의 userId를 확인 → 중복 응답을 체크하기 위하여 → 회원:응답 → 1:N에서 중복되는 userId를 체크하기 위해)MVP 스펙 및 목표는 맨 처음 프로젝트 주제 언급할 때 말씀드렸다시피 다소 작게 잡으신 것 같습니다. 서비스 기능들을 좀 더 추가하시거나, 인프라적인 차원에서 scalablity를 좀 더 챙길 수 있는 과제를 도입해보는 것도 괜찮을 것 같습니다.
→ 기능의 디벨롭 기본적으로 설문지 자체의 테이블을 좀 더 복잡하게 구성하는것
→ 추가적인 기능은 - 채팅 서비스, 결과보기(+즐겨찾기,좋아요,추천,비추천 등으로 인기 설문보여주기 및 알림서비스) 등의 서비스 추가해보는 아이디어 → AWS 인프라 안에서도 여러 기능들을 시나리오에 따라 개선안으로 추가 할 수 있다.
중요한것은 그 시나리오 설정이 중요하고, 문제 발생→인식→기술 선택→개선 이런 방향으로 가야 한다.아래는 AWS 서비스들을 사용하여 스케일러빌리티를 향상시킬 수 있는 몇 가지 아이디어
Q. 함축적인 MVP 구현하면서도 놓치지 말아야 할 기본적인 부분, 신경써야 하는 부분이 궁금합니다. 특히 성능 개선 챌린지과제에 영향이 있을만한 부분은 꼭 잘 구성하고 넘어가야 할 것 같아서 궁금합니다.
A. 멘토님답변정리!
MVP scope에서 달성하고자 하는 목표를 충분히 달성하는 코드를 작성해주시면 됩니다. 되도록 unit test code도 충실히 잘 작성해주시면 더 좋을 것 같습니다.
Q. 팀 회의를 통해 MVP에 적용할 기술 스택의 우선순위를 선정했는데 맞는지 궁금합니다.
챌린지 과제를 고민하는 중에 많은 성능 개선에 필요한 전략 중 "캐싱, 데이터베이스 최적화, 비동기" 라는 키워드에 주목했습니다. 선정 기준은 채용공고에서 자주 노출되는 키워드이면서, 트래픽 상황에 대응한다고 알려진 기술을 적용해보고자합니다.
A. 멘토님답변정리!
채용공고에 자주 노출되는 키워드를 중심으로 준비하는건 올바른 기술 선택 방식이 절대 아닙니다. 회사를 가시게 되면 지금 계획대로 구성했을 경우, 다음과 같은 질문을 받을겁니다. "Mysql -> PostgreSql로 넘어가는건 별도의 이유가 있는건가요?" "elasticsearch를 도입하신 기술적 이유는 뭔가요?" 단순히 채용공고에서 있을법한 기술셋들을 사용해보고 싶은 목적으로 선택하신다면, 나중에 설령 해당 회사들의 면접을 가신다고 하더라도 기술적 도입 근거가 없어서 크게 도움이 되지 않을 겁니다.
예를 들어, Mysql을 선택한다면 "transaction 관리가 용이한 rdbms이고, 가장 범용적으로 쓰이는 DB로 문제가 생겼을 때 참고할 수 있는 eco system이 잘되어 있다." 수준의 답변은 할 수 있어야합니다. 참고로 이것 말고도 mysql이 갖는 기술적 장점들은 많습니다. 중요한 점은 채용 공고에 주안점을 맞추고 기술셋을 선택하지 말라는 것이고, 어떤 문제를 해결하고 싶은데 그 문제를 해결하기 위한 방법의 관점에서 기술셋을 선택하셔야 합니다.
캐싱, 데이터베이스 최적화, 비동기 모두 좋은 주제입니다. 캐싱은 우선 redis라는 인메모리 저장소로, 데이터베이스 최적화는 index를 도입하거나 데이터 정규화정도가 될 수 있을 것 같고, 비동기는 어떤 것을 비동기로 처리하고 싶느냐에 따라 결정될 것 같습니다.
Q. 2번과 이어지는 궁금증입니다. 저희가 진행할 우선순위 리스트에서 현실적으로 몇개의 기술정도 까지 학습과 적용하면서 결과를 얻어 낼 수 있을지 궁금합니다.
아직 위 기술을 본격적으로 학습 해보지 않아서 실제로 기술의 학습 및 적용, 충분한 테스트 소요시간이 얼마나 걸릴지 파악하기가 어려워 프로젝트 기간 내 스케쥴을 조율하는데 불확실한 부분이 있습니다.
A. 멘토님답변정리!
죄송합니다만, 저도 정확히 모릅니다. 사람마다 하기 나름입니다. 특정 기술셋을 어느 수준으로 파느냐에 따라 1년이 걸릴 수도 있고, 사용하고 적당한 트러블 슈팅만 해보는 수준이라면 1-2개월이면 충분할 수도 있습니다. 우선 기존에 익숙해져있는 기술셋(Java, Spring, ...)들이 있을것으로 기대되지만, 그것들을 정말 잘 이해하고 쓰고 있는지 점검도 해봐야될 것 같습니다. 중요한 것은 많은 기술셋을 다 다뤄보는게 아니라, 하나를 다루더라도 깊이 있게 제대로 다뤄보시는게 중요합니다. redis나 elasticache, aws에서 제공되는 Paas를 쓰고 이를 면접에서 어필하고 싶다면, 단순히 사용해봤다는 수준은 크게 도움이 되지 않습니다. 기술셋 학습과 적용 관련한 스케쥴 조율이 힘드시다면, 프로젝트를 진행하는데 가장 필수적인 기술셋들을 중심으로 먼저 하나하나 정복해나가시고, 추후 도입 예정 기술셋들을 선정해두고 시간이 허용되면 진행해보시면 어떨까 싶습니다.