해커톤 프로덕트 보기
결과물 제출 링크: 
BES 2기 해커톤 발표 자료 및 시연 영상 제출(응답)4.92 KB
결과물 제출 시간: ~2월 16일 13시까지
금일 진행되는 해커톤 발표 및 상단의 제출물 링크를 참고하셔서 평가시트를 2월 17일 13시전까지 전달을 부탁드립니다. 
BES 2기 해커톤 발표 자료 및 시연 영상 제출(응답)4.92 KB
결과물 제출 시간: ~2월 16일 13시까지
금일 진행되는 해커톤 발표 및 상단의 제출물 링크를 참고하셔서 평가시트를 2월 17일 13시전까지 전달을 부탁드립니다. 안녕하세요 심사위원 여러분 :)
금일 해커톤 평가를 위해 모여주셔서 감사하다는 말씀 전합니다.
본 해커톤 발표물들은 총 5주의 기간 동안 5-6명의 수강생이 함께 구현한 작품입니다.
가지각색의 멋진 아이디어들이 모인 해커톤 발표를 들으면서 평가를 해당 페이지에서 진행해주시길 바랍니다.
제출하신 모든 팀들의 구현물을 꼼꼼히 살펴보고, 리뷰 작성 및 평가를 부탁드립니다.
특히 본 교육과정은 백엔드스쿨이기에 프론트엔드 요소가 다소 부족할 수 있다는 점 미리 양해 부탁드리며,
디자인 요소가 아닌 백엔드 기술적인 요소들을 위주로 평가를 부탁드립니다.
또한, 작성해주신 피드백은 취합 후 정리해서 각 팀에 전달드릴 예정입니다.
이 피드백은 각 프로젝트에 대한 평가가 아닌, 개선 및 성장 방향성에 초점을 맞춘 피드백이라는 점 참고 부탁드립니다.
최대한 성의있게, 정돈된 문장으로 리뷰를 받게 될 훈련생분에게 도움이 되는 내용을 작성해 주시면 감사드리겠습니다
여러분들의 피드백이 모여 훈련생들의 향후 백엔드 개발자가 되기 위한 여정에 있어 많은 힘이 될 것 같습니다.
다시 한 번 이 자리를 빛내주신 점 감사드리며 즐거운 마음으로 해커톤 발표를 들어주세요.
감사합니다.
-백엔드스쿨 운영진 드림-
감사합니다.
-백엔드스쿨 운영진 드림- 평가시트 (각 항목에 점수를 기입해주시면 됩니다.)
번호 | 팀명 | 혁신성 및 기술 활용도 (20점) | 목표 달성도 및 구현 능력 (70점) | 발표 전달력 (10점) | 피드백 |
1조 | poco a poco | 17 | 68 | 6 | 5주만에 완벽하게 개발하기엔 프로젝트의 크기가 다소 크다는 생각이 듭니다만 대부분의 기능을 어떻게든 구현했다는 점에서 개발 범위와 목표가 적절했는지에 대한 우려를 불식시킨 팀이 아니었나 생각합니다.
[기획] 기획 관점에서 향후 보완이나 추가가 필요하다고 판단되는 부분은 아래와 같습니다.
1. 메인 페이지에서 동일한 컨텐츠가 반복해서 보이지 않도록 하는 전략 (예: 특정 모임에 직접 "관심없음 "으로 표시하기, 다양한 개인화 전략 등)
2. "워너플레이 "나 "운동끼리 " 등의 유사 서비스가 이미 있는 상황에서 서비스 차별화를 조금 더 고민해봐도 좋을 것 같습니다.
3. 실시간 외에도 계획성 있는 운동을 돕는 기능에도 조금 더 기획관점에서의 투자를 해봐도 좋았을 것 같습니다.
4. 회원가입 시 불필요한 정보를 가입 시점에 요구하는 것은 피하는 것이 좋습니다.
5. 모임의 종류를 표현하는 UX의 개선 (현재는 너무 많은 버튼의 나열 형식)
[개발] 다양한 기술들을 적용하면서 동시에 아래와 같은 심화 기능을 개발한 것에 대해 긍정적으로 평가합니다.
1. 알림 메시지에 대한 읽음/안읽음 구분
2. "실시간 매칭 " 기능
3. 전반적으로 백엔드 영역에서의 높은 완성도
[개발] 다음과 같은 부분은 개발 관점에서 아쉬웠습니다.
1. "실시간 매칭 " 기능 선택 시 매칭 옵션의 디테일 부족
2. 매너점수 UI 역시 디테일이 부족합니다.
3. 백엔드의 완성도는 높으나 그와 대비적으로 프론트엔드의 완성도가 다소 낮습니다.
[기타] 기타 아래와 같은 피드백을 드립니다.
1. 발표자의 선정, 발표 페이스(속도)의 체크, 발표자료에 포함된 컨텐츠의 디테일 등은 조금 더 신경을 쓰면 좋을 것 같습니다.
2. "test123 ", "asdf " 와 같은 dummy text는 발표자료에 나오지 않는게 좋습니다.
3, WBS 작성에 신경을 조금 더 쓰면 좋을 것 같습니다. 상대적으로 WBS 작성이 잘 된 팀의 WBS를 반드시 참고하기 바랍니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
2조 | 댕냥 ffㅗ짝 | 18 | 64 | 7 | 유용하고 재미있는 주제를 선정한 팀입니다.
개발을 잘 하고도 개발한 내용물을 잘 포장해서 설명하지 못하면 우리가 얼마나 열심히 했고 얼마나 많은 일을 했는지 전달하기 어렵습니다. 다양한 기술과 다양한 툴을 통해 재미있는 서비스를 만들었다는 것이 발표 자료에서는 충분히 느껴지고, 기술 스택이나 개발 과정에 대한 자세한 설명 대비 프로젝트나 서비스에 대한 설명 부분이 조금 부족하지 않았나 싶습니다.
[기획] 기획 관점에서 향후 보완이나 추가가 필요하다고 판단되는 부분은 아래와 같습니다.
1. 반려견 "주치의 " 개념을 도입해보거나 기타 동물병원과의 연계를 통한 수익 창출 방안을 추가로 모색해보는 것도 좋을 듯 합니다. 충분히 확장성이 있는 서비스입니다.
2. UX가 다소 복잡해서 다이어리나 기타 정보를 생성하고 교환하는 사용자의 경험이 "즐거운 것 "이 아닌 "일 "처럼 느껴지는 부분이 조금 아쉽습니다. 정보를 생성하고 교환하는 사용자의 경험을 조금만 더 개선시킬 수 있다면 충분히 좋은 사업 아이템이라고 생각됩니다.
[개발] 다음과 같은 부분은 개발 관점에서 아쉬웠습니다.
1. 전체적인 서비스 UX로 선택한 캘린더뷰가 사용성 측면에서는 기존 우리에게 익숙한 다른 서비스 UX에 비해 조금 불편해보입니다. 일반적인 타임라인 뷰 형식을 띤 스토리 형식이었더라도 좋았을 것 같습니다.
2. 알림과 일정은 왠만하면 별도로 개발하기 보다는 MVP 차원에서 기존 사용자 플랫폼 이용하는 것도 MVP 관점에서는 어땠을까 하는 아쉬움이 있습니다.
3. 서비스 안정성
4. 낮은 완성도 (동작하지 않거나 완성도가 낮은 feature들이 사이트에 제법 보입니다)
[개발] 다양한 기술들을 적용하면서 동시에 아래와 같은 시도를 한 것에 대해 긍정적으로 평가합니다.
1. 무중단 배포
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
3조 | 냉삼조 | 16 | 69 | 5 | 의미있고 또 재미도 있는 주제를 선정한 팀입니다.
Business Model이 없어도 지금 당장 사이트를 운영할 수 있을 정도로 완성도가 높아 보입니다.
(향후 모바일 앱 프론트엔드로 이어지면) 무명 아티스트의 곡을 나만의 알람 음악이나 벨소리 등으로 이용하는 응용에 더해 작지만 충성도 높은 팬들에 기반한 무명 아티스트들을 위한 커뮤니티 앱 플랫폼으로도 포지셔닝 가능해 보입니다.
[기획] 기획 관점에서 향후 보완이나 추가가 필요하다고 판단되는 부분은 아래와 같습니다.
1. 내가 미는 컨텐츠가 사용자의 "마이페이지 "에 안보이는 것 같아 그 부분은 아쉽습니다.
2. "팬덤"이라는 관점에서 서비스의 색깔을 조금만 더 살렸으면 당장 상용화를 해도 될 것 같습니다.
[개발] 개발과 관련해서는 아래와 같은 피드백을 드립니다.
1. 짧은 시간 내에 많은 다양한 기능을 구현한 것으로 보이고 개별 기능에 detail이 있습니다.
2. 크롤러의 사용과 관련해서는 개발 기간을 줄이고 MVP 관점에서 빠르게 결과물을 도출하기 위해서라도 크롤러를 사용해서 초기 사용자 경험을 제공하는 것 보다 on-demand 방식의 API 호출 후 DB에 저장하는 방식도 고려가 되었다면 더 좋았을 것 같습니다만 크롤러를 사용했다는 것 그 자체, 그리고 그 취지에도 충분히 공감합니다.
3. 순위 차트를 보여줄 때 음악 장르별 구분이 향후에는 필요해보입니다.
4. 백엔드뿐만 아니라 전반적으로 깔끔한 프론트엔드 UX를 개발했습니다.
[기타] 기타 의견은 아래와 같습니다.
1. WBS를 제일 잘 작성한 팀입니다.
2. 발표 자료(문서)도 조금 더 신경을 쓸 수 있으면 좋겠습니다. (서비스에 대한 설명이나 기술 스택, 응용 등에 대한 내용이 조금 부족해보입니다)
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
4조 | 계획이 없나영 | 19 | 61 | 8 | 유사한 서비스가 많음에도 불구하고 충분히 보편적이면서 동시에 재미있는 주제를 선정한 팀입니다. 다만 서비스의 핵심(main) 진행 방식이 채팅을 통해 이루어지는 부분은 많이 아쉽습니다.
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. 재미있는 주제입니다. 여전히 불모지인 영역이기도 해서 서비스의 완성도만 높다면 사업성이 높은 영역입니다.
2. 실현 가능한 사업(수익) 모델
3. 사용자 interaction과 서비스의 핵심 flow가 채팅 서비스에 의해 진행되는 부분은 많이 아쉽습니다.
4. 유저 컨텐츠가 없는 부분이 많이 아쉽습니다. "플랜 "의 데이터 모델을 표준화시켜 더 디테일한 플랜을 서로 공유하고 평가하고 자산화(수익화) 하는 것들로 확장하는 것이 사업화에 더 도움이 되는 방향이 아닐까 싶습니다.
[개발] 다양한 기술들을 적용하면서 동시에 아래와 같은 심화 기능을 개발한 것에 대해 긍정적으로 평가합니다.
1. 채팅 서비스의 구현
2. 결재 서비스 연동
[개발] 다음과 같은 부분은 개발 관점에서 아쉬웠습니다.
1. 위의 기획 부분에서도 언급했듯이 플래너의 여행계획이 만들어지고 업로드 되는 형태를 표준화 하고 그것을 서비스 내에서 직접 데이터로 다룰 수 있었다면 더 좋았을 것 같습니다. (데이터 모델이나 UI 등)
2. 프론트엔드도 조금만 더 신경을 썼으면 좋았을 것 같습니다.
3. 포트폴리오 조회 화면에서 플래너 점수나 등급이 표시되지 않는 부분은 아쉽습니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
5조 | 개발의민족 | 16 | 65 | 8 | 짧은 시간 동안 굉장히 많은 양의 개발을 진행한 것 같아 커리큘럽 상의 백엔드 기술 사용 여부나 그 정도를 떠나 일단 긍정적으로 평가합니다.
[기획] 기획 관점에서 향후 보완이나 추가가 필요하다고 판단되는 부분은 아래와 같습니다.
1. 코인 시세 데이터 및 차트, 그리고 기본적인 매매를 위한 UI 등 다양한 기능들을 구현한 것은 긍정적이나 이 프로젝트의 근본 취지인 투자 습관 개선이나 정보 공유, 투자 스킬 향상 등과 관련된 feature는 잘 드러나지 않는 것 같아 아쉬운 면이 있습니다.
2. 발표 자료에 제시된 기대효과의 세가지 항목이 모두 "전략 "이나 "How "가 잘 보이지 않는 부분이 아쉽습니다.특히, 투자 습관 개선을 위해 제공된 매매일지 기능이 어떤 점에서 투자를 더 잘 할 수 있도록 사용자를 가이드 하는지 더 강조할 필요가 있어 보입니다. 단순히 매매일지를 작성하는 것만으로 어떻게 주식 실력이 늘지는 않습니다.
[개발] 다음과 같은 부분은 개발 관점에서 아쉬웠습니다.
1. 프로젝트의 사이즈가 커리큘럽 상의 백엔드 기술 사용의 관점에서는 다소 커보입니다. 그래서인지 프론트엔드에서의 API 연동과 외부 서버에서 제공되는 데이터의 양이 많은 반면 자체 서버에서의 비즈니스 로직을 보여주는 부분이 다소 부족해보입니다.
2. 실제 매매가 MVP 차원에서 꼭 필요했을까? (매매일지만으로 컨셉 검증은 가능하지 않을까?)
3. 매매일지를 모두 자동으로 생성하고 그것을 평가하는 부분을 더 보강하는 것을 어땠을까 하는 의견도 드립니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
6조 | 인규와 아이들 | 15 | 69 | 10 | 적절한 주제를 선정하여 백엔드 기술을 잘 응용/개발한 팀입니다. 보편적인 주제를 선정하고 다소 "넓은 " 영역을 목표로 한 것 같긴 하지만 꼭 있어야 하는 보편적인 기능을 구현하고 심플한 UX를 통해 서비스를 제공한 부분을 긍정적으로 평가합니다.
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. 짧은 시간 안에 게시판, 학생관리, 강좌관리, 수강신청, 결제관리, 마이페이지 등 굉장히 많은 feature를 구현한 부분은 긍정적입니다.
2. 사용자 painpoint가 그리 크지 않은 B2B 영역의 서비스라 그런지 주제 선정과 사업 확장성면에서 유연성과 독창성을 발휘하기 어려웠을 것 같습니다.
[개발] 다양한 기술들을 적용하면서 동시에 아래와 같은 심화 기능을 개발한 것에 대해 긍정적으로 평가합니다.
1. Swagger, Jacoco, 소나큐브 등 다양한 개발 환경과 도구를 적절히 잘 사용한 것 같습니다. 지금 수준에서는 이런 툴들을 왜 쓰는지 잘 이해가 안가는 부분도 많겠지만 규모가 큰 기업은 대부분 사용하고 있는 개발 환경의 일부인만큼 좋은 경험이었기를 바랍니다.
2. "신청 취소 "나 "대기신청 "과 같은 고도화 기능의 구현
[개발] 다음과 같은 부분은 개발 관점에서 아쉬웠습니다.
1. 기본 데이터베이스 기반 서비스 외에 정보 공유와 커뮤니케이션이 중요한 서비스인만큼 이벤트 기반 알림 서비스와 같은 기능도 구현을 해볼 수 있었다면 더 좋았을 것 같습니다.
2. ERD를 조금만 더 구조화해서 설계 및 표현 해줄 수 있으면 좋겠습니다.
[기타] WBS 작성 시 개발 항목을 detail하게 기술하고 구간별 테스팅을 실시한 부분은 긍정적입니다. 향후 WBS 작성 시에는 담당자도 함께 표시할 수 있으면 좋을 것 같습니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
7조 | 태조왕건우와
백성들 | 13 | 59 | 8 | 적절한 규모와 적절한 주제로 커리큘럼에서 학습한 다양한 기술을 적절히 잘 사용하여 무난한 개발을 진행한 팀입니다.
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. 함께 할 수 있는 활동의 범위가 상당히 넓은데 UX/UI를 적절한 수준에서 타협하여 개별 활동을 위한 UX를 강조하지 않으면서 전반적인 서비스를 제공하는 사이트를 잘 구축한 것 같습니다.
2. "Right now " 항목들에 "time bomb "이 있으면 조금 더 재미있는 서비스가 될 수도 있을 것 같습니다.
3. 사용자를 기술하는 방법으로 '당도' 외에 더 다양한 요소로 '사람'을 설명할 수 있으면 좋을 것 같습니다.
4. "꾸준히 ", "당장히 "와 같은 이름에서 구성원들의 창의성이 느껴집니다.
5. "블랙리스트 "나 "신고 " 기능까지 구현한 부분은 긍정적입니다. 다만 MVP 관점에서는 더 중요한 부분에 시간을 더 쓰고 덜 중요한 부분은 일부 컨셉만 구현하는 전략을 취했다면 어땠을까 하는 아쉬움이 있습니다.
[개발] "채팅 "이나 "결재 " 서비스까지 구현하려고 노력한 부분은 긍정적입니다만 다음과 같은 부분은 개발 관점에서 아쉬웠습니다.
1. WBS 작성을 조금 더 신경써서 하면 좋을 것 같습니다. 모범 사례로 평가되는 다른 팀의 WBS를 꼭 참조하기를 권고합니다.
2. 회원가입 할 때 입력 받은 전화번호를 인증번호 받을 때 기본적으로 보여주면 더 좋았을 것 같습니다.
3. 메인 화면에 열거된 다양한 활동들이 어떤 기준으로 보여지고 있는지 열거 기준을 좀 더 명확하게 보여줄 수 있으면 좋았을 것 같습니다.
4. "활동 " 페이지 내에 "참여하기 "와 "탈퇴하기 "가 함께 존재하는 부분은 조금 아쉽습니다. (항상 둘 중 하나만 존재하는 UI)
5. ERD를 조금만 더 구조화해서 설계 및 표현 해줄 수 있으면 좋겠습니다.
[기타] 발표자료(문서)에 서비스 내용이나 기술 스택, 기술 응용, 개발 이슈 등 더 디테일한 내용을 담을 수 있으면 좋겠습니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
8조 | 아이다섯이둘[I5E2] | 14 | 58 | 7 | 재미있는 주제고 사용자에게 유용하며 시장에 여전히 dominant한 서비스가 없어서 적절한 주제로 보여집니다.(운영 중인 서비스는 있습니다)
다만 못난이 농산물 문제는 기획과 개발 이슈 보다는 "유통업 "의 본질에서 해법을 찾고 있는 경우가 많아 이 프로젝트의 결과물이 사용자(특히 농민)의 painpoint를 얼마나 적절히 해결할 수 있는지에 대해서는 조금 회의적입니다. (제 심사 경험에 비추어 보면 매년 한 팀 정도는 정확히 이 주제로 프로젝트를 진행하고 있는 것 같습니다)
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. 대부분 필요한 기능은 다 구현이 되어 있는 것 같아서 특별히 피드백을 드릴 것이 없습니다. 다만 현재 구현된 프로젝트에서 계약 부분이 강조된 만큼 농민의 UX는 강조되지 못한 부분이 없지 않아 있는 것 같아 그 부분은 향후 더 고민을 해볼 수 있으면 좋을 것 같습니다. (농민이 얼마나 편리하게 경매 아이템을 업로드 할 수 있게 할 것인가?)
[개발] 개발과 관련해서는 다음과 같은 피드백을 드립니다.
1. 발표 내용 중에 백엔드 내용도 물론 많았지만 계약서 작성 기능과 관련해서 프론트엔드나 단순 API 연동 부분을 구현한 내용도 꽤 커보입니다. 커리큘럼에서 학습한 다양한 기술을 적절히 잘 사용하여 개발이 진행되었는지는 살펴봐야 할 것 같습니다.
2. 개발 완성도 부분에서 아쉬운 점이 다소 있는 것 같습니다. 많은 부분을 개발하는 것만큼 중요한 것은 단 하나라도 동작하는 서비스를 보여주는 것입니다. 그래서 큰 회사들은 개발 초기부터 동작하는 기본 서비스를 만들어 MVP라는 이름으로 수정을 거듭해가며 개발을 하는 방식을 많이들 채택하고 있다는 점을 참고하면 좋겠습니다. 하나라도 제대로 동작하는 것을 보여주는 것은 실력의 문제가 아니라 "계획 "의 문제가 아닐까 생각됩니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
9조 | web | 17 | 65 | 8 | 재미있는 주제로 적절한 개발 범위 내에서 무난히 개발을 진행한 것 같습니다. "에어 플래닝 " 팀(4조)과 구조적으로 서비스가 유사해 보이나 백엔드 커리큘럼 특성상 비슷한 프로젝트처럼 보이는 부분이 많은 것 역시 인지하고 있습니다.
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. 메인 페이지에서 버킷 리스트 항목 보여줄 때 개인화가 안되어 있는 점은 조금 아쉽습니다. 메인 화면에는 결국 내가 관심있는 카테고리의 항목들만 보이는 것이 조금 더 바람직한 기획이 아닐까 생각합니다. (로그인하지 않았거나 개인화를 위한 데이터가 수집이 덜 된 상태라면 지금처럼 보여지는 것이 맞습니다)
[개발] 개발과 관련해서는 다음과 같은 피드백을 드립니다.
1. 짧은 시간 내에 많은 걸 구현하려고 노력한 부분이 엿보입니다. 긍정적으로 평가합니다.
2. 개별 서비스 구현을 위해 많은 시도와 시행착오를 겪은 부분을 기술한 내용도 매우 긍정적으로 평가합니다.
3. Swagger 외에도 조금 더 다양한 개발 지원 도구들을 사용해볼 수 있었으면 더 좋았을 것 같습니다.
4. 채팅 메시지를 비동기 저장한다고 했는데 사용자의 다양한 통신 환경을 고려했을 때 절대적 시간을 중심으로 하는 "엄격한 " DB 저장 보다는 백엔드 로직의 복잡도나 서버 로드 관점에서 더 다양한 솔루션들을 살펴보는 것도 권해봅니다.
5. API를 문서화 하는 것 자체도 중요하지만 내가 어떤 목적으로 API를 문서화 하는지, 어디까지 공유하는지도 함께 고려하면서 문서화 도구를 사용하면 더 좋을 것 같습니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
10조 | 우아한 남매들 | 14 | 67 | 7 | 어떻게 보면 일반적인 구매/주문 서비스처럼 보이지만 "레시피 "에 기반한 독창적인 시나리오를 모티브로 커리큘럼에서 학습한 다양한 기술을 적절히 잘 사용하여 적당한 범위 내에서 개발을 진행한 것 같습니다.
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. 레시피로부터 필요한 식재료만 편리하게 구매할 수 있는 아이디어는 긍정적입니다.
2-1. 실제 레시피에 사용되는 양과 실제 주문 가능한 식재료의 양은 차이가 큰데 그 부분에 대한 해법을 고민하는 것은 프로젝트 범위를 벗어나는 일 같습니다. (향후 "소량 구매 ", "다른 사람과 함께 구매하기 " 등의 방법도 고려해 볼 수 있겠으나 차라리 시간을 길게 두고 장바구니에 넣어뒀다가 동일 재료가 필요한 다른 레시피를 체크아웃했을 때 사용자에게 알려주는 정도의 구현으로도 충분할지 모릅니다)
2-2. 그런 측면에서 장바구니에 어떤 식재료가 담겼을 때 이 식재료가 어떤 레시피에서 온 것인지를 추가로 알려줄 필요가 있어 보입니다. (내가 어떤 식재료를 사지 않기로 결정했을 때 어떤 레시피가 영향을 받는지 제대로 알기 어려움)
3. "상품등록 "은 이 프로젝트의 범위를 약간 벗어나는 기능 같아 보이기도 합니다.
[개발] 개발과 관련해서는 다음과 같은 피드백을 드립니다.
1. 당연한 것이지만 로그인 전에도 서비스를 볼 수 있는 점은 긍정적입니다.
2. 다양한 사용자 "권한 "을 소개하고 구현한 부분은 긍정적입니다. (그런 주제를 생각해본다는 것 자체가 긍정적)
3. 실제로 관리자 모드까지 구현한 부분도 긍정적입니다.
4. 레시피 내용이 텍스트로만 되어 있는 부분은 조금 아쉽습니다. 실제로 레시피는 복잡한 구조적 데이터입니다만 이 부분을 제대로 구현하는 것 역시 프로젝트의 개발 범위를 벗어나는 것일지도 모르겠습니다.
5. 재료 등록 화면에서 처음부터 모든 재료를 수동으로 등록하는 것 보다는 레시피 내용으로부터 추출한 재료들을 먼저 보여주는 것도 향후에는 고려해보면 좋겠습니다.
[기타] 기타 피드백입니다.
1. WBS를 잘 작성했습니다. 다만 한 기능이 몇일에 걸쳐 오래 개발되는건 피하는 것이 좋습니다.
2. 발표자료(문서)는 깔끔하게 잘 디자인/작성 되었습니다만 서비스 내용이나 기술 스택, 기술 응용, 개발 이슈 등 더 디테일한 내용이 부족한 점은 아쉽습니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
11조 | 중요한 건 꺾이지 않는 민우 | 17 | 67 | 9 | 재미있고 유익한 주제로 커리큘럼에서 학습한 다양한 기술을 적절히 잘 사용하여 적당한 범위 내에서 개발을 잘 진행한 것 같습니다.
[기획] 특별히 지금 기획된 서비스에 부족한 부분은 없어 보이고 향후 이 프로젝트를 지속 발전시킬 계획이 있다면 아래 피드백을 참고하면 좋을 것 같습니다.
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를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
13조 | 한사랑코딩회 | 13 | 61 | 9 | 재미있고 개발자에게 유익하기도 한 주제로 커리큘럼에서 학습한 다양한 기술을 적절히 잘 사용하여 적당한 범위 내에서 개발을 잘 진행한 것 같습니다. 특히 팀원이 많지 않은 점을 감안하면 프로젝트의 완성도가 높은 편입니다.
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. (개발 관련 이슈일 수도 있으나) 인증을 스크린샷으로 하는 부분은 많이 아쉽습니다. 특별히 난이도가 높은 작업도 아니었을 것 같은데 프로젝트 전체 구현 중 제일 아쉬운 부분입니다.
2. 동시에, 기획적인 시각에서는 굳이 코딩 관련 챌린지로 이 프로젝트가 국한될 필요는 없어 보입니다. (적어도 스크린샷 기반이라면)
3. 많은 사람들이 다양한 주제로 이 서비스를 사용하게 된다면 각각의 사용자들은 다른 사람이 새롭게 생성한 챌린지를 관찰하는 것만으로도 새로운 기술이나 트렌드에 간접적으로 노출되는 효과도 기대할 수 있을 것 같습니다.
4. 단순히 인증이나 체크인을 온/오프로만 판단하는 것에 더해 "빈도 "도 파악할 수 있으면 조금 더 깊이 있는 서비스를 제공할 수 있을 것 같습니다.
[개발] 개발과 관련해서는 다음과 같은 피드백을 드립니다.
1. 알림 서비스가 구현되어 있지 않은 점은 좀 아쉽습니다.
2. 어떤 멤버가 좋은 사람이다 안좋은 사람이다가 필요한 순간에 적절한 위치에서 표시되지 않고 사용자의 추가 action을 통해서 얻어질 수 있는 정보라는 점은 수정이 필요해 보입니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
14조 | 잠은죽어서자조 | 17 | 67 | 9 | 전시 경험 공유라는 독특한 주제로 커리큘럼에서 학습한 다양한 기술을 적절히 잘 사용하여 적당한 범위 내에서 개발을 잘 진행한 것 같습니다. 특히 이 프로젝트는 프론트엔드와 백엔드 모두 완성도가 높아 보입니다.
[기획] 기획과 관련한 피드백은 아래와 같습니다.
1. 이 서비스의 핵심 고객(target customer)가 데모 시나리오나 발표자료 상에 선명하게 드러나지 않는 부분은 아쉬운 부분입니다. 모든 사람에게 필요하고 유용한 서비스이기도 하지만 "전시를 왜 다른 사람과 함께 가야 가는가? "에 대한 자연스러운 해답을 줄 수 있는 use case를 기반으로 개발을 진행했으면 더 좋았을 것 같습니다.
2. 핵심 서비스가 정해지고 핵심 사용자가 정해지고 나면 그 후에는 전시회 참관 기록이 중요한 증거나 기록으로 쓰일 수 있으려면 어떤 형태로 보여지면 좋을까에 대한 고민을 더 해보면 좋을 것 같습니다.
[개발] 개발과 관련해서는 특별한 피드백이 없습니다. (칭찬입니다)
DB 모델링이나 기술 스택, 개발도구의 사용 등과 관련해서도 특별히 이슈가 없어 보이고, 처리하는 데이터 용량이 많아 보이긴 하지만 그 또한 서비스 특성이고 서비스 성능에도 영향을 미치고 있지 않아 보여서 아래 몇 가지 작은 이슈 외에는 특별히 개발 관련 피드백이 없습니다.
1. 회원 가입 시 굳이 너무 많은 데이터를 요구할 필요는 없습니다. 필요한 정보는 그 정보가 필요해질 때 천천히 획득하는 전략이 멤버십 유지에 더 유리합니다.
2. "북마크 "나 "함께봐요 " 기능을 선택했을 때 GUI의 상태 변화는 필요해 보입니다. 현재는 팝업 메시지만 표시되고 있습니다.
3. 로그인이 안되어 있는 상태에서 마이페이지를 선택했을 때 마이페이지 웹 컨텐츠가 로드되고 난 이후에 로그인 페이지로 redirect 되는 부분
[기타] 기타 아래와 같은 피드백을 드립니다.
1. WBS 작성에 신경을 조금 더 쓰면 좋을 것 같습니다. 상대적으로 WBS 작성이 잘 된 팀의 WBS를 반드시 참고하기 바랍니다.
다음은 모든 팀에 공통으로 적용되는 피드백입니다.
[발표자료] 주요 기능을 설명할 때 기능(function) 위주의 설명 보다 사용자 시나리오(user scenario) 위주의 발표 자료 작성이 더 효과적입니다.
[개발] 해커톤 프로젝트는 핵심 기능이 아니라면 가능하면 기존 서비스를 최대한 이용하는 것이 MVP 관점에서도 유리합니다. (캘린더, SNS 등)
[WBS] WBS를 제대로 작성하는 것은 매우 중요합니다. 빅테크에서 개발팀의 개발 기간이 크게 변경되지 않는 주요 이유 중 하나가 상세하게 작성된 개발 계획 때문입니다. |
