프로젝트 주제 자체가 뻔한 어플리케이션이 아니여서 좋은 것 같습니다.
이러한 프로그램일수록 요구사항과 기능구현에 대한 자세한 회의가 필요할 것 같네요.
다만 어플리케이션이 뻔한 어플리케이션이 아니여서 기획회의에 시간이 너무 오래걸린다면 차라리 뻔한 주제를 사용해서 기획에 시간을 줄이고 그 어플리케이션을 어떻게 구현할 것인지, 대용량 처리는 어떻게 할 것인지,
사용자가 늘수록 어떠한식으로 데이터 처리를 할것인지에 대해 깊게 고민해보는 것이 오히려 취업/면접에 도움이 될 수도 있습니다.
이미 기획회의가 끝나셨다면 해당 요구사항들에 대해 어떠한식으로 구현하고 어떻게 트래픽처리를 할 것인지에 대해 고민하는 과정이 취업/면접에 유리합니다.
기술스택 적절해보입니다.
아쉬운 점은 해당 기술스택을 어떤 곳에 사용할지가 명확하게 명시되어있으면 좋을 것 같습니다. 예를들어 레디스를 이용해 읽기 캐시를 사용한다던가 세션캐시 아니면 토큰 저장용으로 사용한다던지 등 어떠한 기능에 이 기술을 사용할지를 명시해주시면 좋겠네요
카프카, 레디스, CQRS패턴 모두 보편적으로 많이 사용하는 기술입니다. 하지만 명확하게 이 기술을 어떠한 곳에 사용하고 해당 기술에 대해 블로그 검색등을 통해 기본개념을 이해하고 사용하시면 더 좋을 것 같습니다. 곧 면접을 보게 되실텐데 명확하게 이해하고 쓰지 않은 기술은 차라리 안쓰는것보다 좋지 않을 수 있습니다. 왜냐하면 프로젝트에 사용했던 기술에 대해 면접에서 꼬리질문을 통해 질문받을 확률이 거의 100%여서 명확하게 대답을 하지 못한다면 오히려 독이 될 수 있습니다.
서비스 구상에서도 여러 회의를 거쳐서 고른 과정이 있는 것 같네요. 협업하면서 정하신 것 같아서 좋습니다.
use case도 지금까지 작성하신 것은 명확하게 요구사항을 적어놓으셔서 좋습니다. 다른 기능들에 대해서도 이와같이 작성해놓으시면 나중에 구현할때 오히려 더 편합니다. 지금처럼 문서화를 먼저해두시고 코딩하는 습관을 기르시는 게 좋습니다.
와이어프레임도 잘 작성해주셨네요. 해당 와이어프레임 화면을 가져올땐 어떤 API를 사용하고 "구매하기"등 버튼을 눌렀을때는 어떤 API를 사용할지 명확하게 정리되어있어야 합니다. API 명세에 이것을 적든 와이어프레임 밑에 적든 어떤화면에서 어떤 API를 사용할 것인지 팀 내부적으로 명확하게 정리하는 것이 중요합니다. (이 과정을 말로 다 설명할 수 있다면 프론트는 구현하지 않더라도 충분합니다)
github rules도 적절합니다.
아직 ERD나 API 명세가 나오질 않은걸 보니 완벽히 정리된 것은 아닌가보네요. 저녁때 확인해보고 피드백 더 남겨놓겠습니다.
by 이성국 튜터