중요한 건 꺾이지 않는 민우

[좋았던 점] - 팀원들이랑 프로젝트를 진행하기 전에 한번 만나서 소통이 원활했던 점이 좋았습니다. - 협업에 있어서 소통하는 법 자체를 몰랐는데 하면서 많은 것 을 배우고 또 부족한점을 깨달은거 같아 더욱 더 열심히 공부해 나가야 할 거 같습니다. - 팀장님 주도 하에 만나는 시간을 정해서 그시간에 만나 소통했던게 도움이 많이 됐던것 같습니다! - "팀 내에서 소통하는 과정에서 가장 좋았던 점은 팀 모두가 참여도가 높았다는 점입니다. 매일 아침마다 회의를 진행했는데 지각/결석도 한 번도 없었고 어느 누구도 요령 피우지 않고 성실했습니다. - 제 의견을 잘 따라줘서 편했습니다. 중간에 너무 제 의견만 반영되는 것 같아 걱정했지만, 팀원들이 모두 이해해주어서 너무 고마웠습니다. - 팀원분들이 다 잘돕고 서로 소통하고 즐겁게 잘했습니다 ㅎㅎ [어려웠던 점(?)] - 가장 어려웠던 점은 모두가 긍정적이다 보니 우리의 생각이 최선이 맞을까? 하는 고민이 들었다는 점입니다. 물론 덕분에 진행하기는 편했습니다... ㅎㅎ"

[중요한 건 꺾이지 않는 민우팀을 향한 칭찬] - 사이트 속도가 가장 빠릅니다. - S3정적 웹호스팅 기능 쓴점 좋습니다. - 구현이 깔끔합니다. - 기술을 선택한 이유가 있는 점이 좋습니다. - 속도 개선을 위해 엔지니어링 적으로 고민하고 문제해결을 잘 한점이 좋았습니다. - 백엔드 개발자에게 꼭 필요한 퍼포먼스에 대한 고민이 좋았습니다. - 안정성 고려한점도 좋았습니다. - 테스트 코드에 대한 고려까지 좋았습니다. - 상당히 최적화 및 리소스 절약에 관한 고민을 많이 하신 팀으로 보입니다. - 또한 요청 유효성 검사 등을 사용하셨다고 소개한 유일한 팀인 것으로 보이고 Jacoco와 같은 커버리지 체크도 진행한 것이 좋네요. - 백엔드 커리큘럼으로서 뛰어난 프로젝트라 생각되네요. - 스케줄링과 batch의 방식으로 랭킹을 구현하신 것도 잘하신 겉 같습니다. - 실제로 배포된 사이트를 확인해보면 https까지 잘 적용되어 있고 속도가 굉장히 빠릅니다. ms 수준까지 api 호출, 응답 속도를 고려했다는 것이 보이네요. - 요청 유효성 체크 및 테스트도 잘 수행하신 것으로 보입니다. 기능의 볼륨을 좀 더 늘리시면 프로덕션 환경까지 고려해볼 수 있겠네요. - 기획한 기능은 적었으나 여러가지 기술적 고민을 깊게 한 점이 좋았습니다. 또한 이를 잘 적용하여 구현까지 해낸 것과 외부 API를 호출하나 반응 속도가 빠른 점이 인상 깊습니다. - BE현업자의 토이프로젝트같이 기술적인 고찰을 잘 해주었고 API 호출부분에서 어떻게 하면 최적화를 할 수 있을지 많이 고민한 흔적이 보여서 좋았음. 관련 사항 블로그 등으로 문서화 잘 해놓는다면 꼭 찾아서 보겠음! - WebFlux 도입 이유가 분명해서 좋았습니다. 다른 조원 분들도 백엔드 개발자라면 퍼포먼스 향상을 위해 어떠한 점을 고려해야 하는지 알 수 있는 소중한 경험이 되었을거라 생각합니다. - 랭킹 데일리 백엔드 처리.. 이런것 매우 좋음.. 실시간성이 불필요한 서비스에 굳이 시간과 자원을 낭비할 필요 없음.. (매우 좋은 판단임) - 재미있고 유익한 주제로 커리큘럼에서 학습한 다양한 기술을 적절히 잘 사용하여 적당한 범위 내에서 개발을 잘 진행한 것 같습니다. [중요한 건 꺾이지 않는 민우팀에게 드리는 피드백] - 필요성에 따라 랭킹 기능을 ZSet을 사용했다면 더욱 빠르게 실시간 랭킹까지 구현할 수 있었을 것이란 아쉬움이 있네요. - 좀 더 속도를 높이고 싶으시면 캐시와 prefetch와 같은 것도 고려해보시면 좋을 것 같습니다. - 동시성 문제를 해결하지 못했다고 하는데 Transaction만 잘 사용해도 동시성을 해결할 수 있는 정도의 기능이라 생각이 됩니다. - 기능 볼륨이 좀 작아 완성도를 좀 더 높이면 좋겠습니다. - 한 가지 말씀드리고 싶은 점은 신기술은 정말 좋지만 그렇다고 레거시(코드,시스템)를 미워하지말고 존중해야한다는거 알아두시면 좋을 것 같습니다! - webflux 통해 api 동시 3개 호출한 것도 좋지만, 그래도 300ms 가 느리고 오래 걸리면 답답할텐데, 어떻게 할 것인가? 이런 고민해보면 좋음.. 장기적으로는 prefetch 방식을 통해 예측을 기반으로 미리 요청.. 이전 페이지에서 요청.. 이걸 기반으로 캐싱.. - 구현한 서비스에 대한 데모가 좀 더 잘 되었다면 좋았을텐데 하는 아쉬움이 남고, 백엔드의 기술적으로는 매우 높게 평가 하였음.. - [기획] 특별히 지금 기획된 서비스에 부족한 부분은 없어 보이고 향후 이 프로젝트를 지속 발전시킬 계획이 있다면 아래 피드백을 참고하면 좋을 것 같습니다. 1. 책에 대한 리뷰가 모이는 공간은 작가가 독자들과 소통을 할 수 있는 좋은 공간이기도 합니다. 향후 이 부분을 더 고려하여 작가와의 소통 공간이나 나만의 서재 개념을 추가로 구현해 보는 것도 좋을 것 같습니다. 2. 내가 선호하는 책에 대한 데이터가 많이 쌓이다 보면 1000명 중 1명의 확률로 나와 취향이 비슷한 사람을 한 명 또는 최소 그룹의 형태로 발견하게 되는 순간이 오는데 이 부분을 모티브로 삼아 서비스를 사업화 하려는 시도도 종종 발견됩니다. 참고하면 좋을 것 같습니다. 3. 다각형/레이더 차트가 고객을 어떤 측면에서 돕는지가 현재 프로젝트에서는 잘 드러나지 않습니다. 참고하면 좋을 것 같습니다. 4. 메인 페이지를 성능 이슈 때문에 비워두고 검색 UI만 표시하고 있는 것 같은데 더 좋은 서비스를 위해서는 신간과 베스트셀러 위주의 북리뷰가 작은 갤러리 형태로 제공되는 것도 고려해보면 좋을 것 같습니다. - [개발] 개발과 관련해서는 다음과 같은 피드백을 드립니다. 1. 도서 리뷰 작성 기능에 더해 "챌린지 " 기능까지 구현한 부분이 긍정적으로 보입니다. 다만 챌린지 기능은 실제 사용하기에는 아직 기능의 완성도가 높아보이지 않습니다. 2. 프론트엔드 개발도 제법 많이 해서 전체적으로는 프로젝트의 완성도가 높아 보입니다. 3. 여러 서버를 대상으로 하는 API 호출 시 지연이나 성능저하 문제를 해결하기 위해 WebFlux 등을 사용한 시도는 긍정적입니다. 다만 실제 이 서비스는 운영을 하면 할수록 API 호출 보다 내부 DB에 저장되는 데이터의 양이 더 많을 것으로 예측되기도 합니다. 4. Swagger랑 Jacoco 등의 다양한 개발 환경과 개발 도구를 사용해 보는 경험은 긍정적입니다. 5. 효율적인 랭킹 업데이트를 위해 스케쥴러를 사용한 점이나 동시성 문제를 해결하기 위해 고민을 많이 한 부분 역시 긍정적입니다. (실제 필드에는 해결되지 않는 동시성 문제나 UX로 해결하는 것이 더 나은 경우도 가끔 있습니다) 6. 테스트 코드를 작성한 시도를 포함하여 많은 좋은(?) 것들을 시도하고 또 그 과정에서 많이 배운 것 같아 역시 긍정적입니다. - 다음은 모든 팀에 공통으로 적용되는 피드백입니다. [발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다. [개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등) [WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다.