해커톤 프로덕트 보기
결과물 제출 링크: 
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 | 16 | 60 | 6 | - 평이하게 잘 만들었으나 프런트는 다소 아쉬움.
- 실시간 채팅, 모임후 피드백 등등 다양한 부분에 대한 고려가 잘 되어 있었음.
- 앞에 모든 기능을 스크린샷으로 소개를 하길래 구현을 통합해서 동작하게 다 못 한줄 알았는데, 발표 시간 한참 초과해서 데모가 시연된지라, 발표 시간 분배와 개발한 결과물의 표현 방법에 대한 고민은 더 필요함. |
2조 | 댕냥 ffㅗ짝 | 14 | 50 | 7 | - 프런트가 다소 많이 아쉬움. 반료동물 일지 작성도 구글캘린더 같은 형태라 아쉬움이 있고, 요즘 SNS처럼 인스타 형태가 가장 일반적인 실제 상용화 된 서비스의 형태인지라 (유사 서비스를 많이 찾아보고 벤치마킹 해볼 것)
- 사용자가 수동으로 입력해야 할 필드들이 너무 많아 사용성(UX적) 인 고려가 함께 되면 더 좋고, 요즘은 백엔드 개발자라도 서비스의 컨셉과 사용성까지 고려하며 개발 하는것이 이런 서비스 개발의 트랜드라 고민해볼 것.
- gitlab, jenkins, sonarqube 는 또 ec2에서 별도로 다 구동하고 있는데, 이런것을 다 gitlab 하나로 대체 할 수도 있는지라 통합 고려. 또한 push 알림 등도 aws에도 기능들이 있는데 굳이 firebase 를 사용해서 알림전달을 한다거나 과도하게 많은 서비스 컴포넌트를 통해 쉬운 서비스를 다소 어렵게 구현하였음. (nginx 리버스 프록시도 aws elb 로 대체 할 수도 있고, 아니면 전체를 도커 컨테이너로 배포 하거나, 여러가지 방안이 있음.)
- 서비스 개발 중 레디스 해킹 관련 언급이 있었는데, 일단 매우 좋은 경험이고, 해당 경험을 기반으로 보안성에도 꼭 신경을 쓰는 백엔드 개발자가 되길 바람.. (또한, 더 크게는 애초에 접근제어를 통한 설계단계에서부터 보안성을 고려해볼 것. 개발 이후가 아닌 개발 이전..) |
3조 | 냉삼조 | 14 | 65 | 10 | - 디테일에 매우 많은 신경을 쓴 것이 좋았음. 수정 가능 여부를 ux로 녹여 넣거나, 입력 글자수 라던지, 삭제시 주의를 요하는 부분, 포인트제도, faq와 검색 기능 등 매우 디테일하게 고려된 부분들은 good.
- wbs 사용이 아쉽다고 했는데, 전체 팀 중 가장 잘 한 팀 중 하나라 걱정 안해도 됨.
- 디자인 패턴 등 개발적으로 고려한 사안도 좋았고, 실제 서비스가 의미 있게 보이기 위해 초기 데이터를 크롤러를 통해 개발한 부분 등도 좋은 스타팅 포인트였음. |
4조 | 계획이 없나영 | 14 | 50 | 9 | - 플러너와 연결하는… 상용 서비스 중 마이리얼트립 과 유사해 보이는 서비스 형태이며, 서비스가 다소 넓은 범위다 보니 기획적으로 조금 더 고려해서 핵심 서비스에 집중 하였으면 더 좋았을 것 같음.
- 너무 식상하고 일반적인 회원가입 부분이라던지 이런 곳에 집중해서 설명하다보니 실제 서비스인 “여행 플래닝” 관련 부분은 너무 없고, 그냥 “게시판” 에 글을 쓰는것과 별 차이가 없었음. (국내 여행이냐 해외여행이냐, 개별 가이드냐 단체 가이드냐 등등부터 고려해야 할 핵심 피쳐들이 너무 많은데…)
- 데이터가 많아지면 서버에 부하가 될 수도 있는데, 그에대한 고려나 테스팅 기법 또한 필요 함. (MySQL - RDS 사용 안하고 로컬 설치형으로 한 것 같은데, 그 부분에 대한 고려도 필요하고…) |
5조 | 개발의민족 | 16 | 60 | 9 | - 실제 거래가 목적인가? 아니면 모의 투자가 목적인가? 실제 투자라면 그 안정성과 보안성과 트랜잭션 등 매우 많은 성능과 백엔드 코어 기술들에 대한 고려가 필요 함. (발표에 그런 부분들이 표현 되지는 못하였음)
- 기술적으로는 인증 기능들을 모두 하나하나 직접 구현 한 것 같은데, 현업에서는 사실 라이브러리 하나 잡아서 잘 사용하면 그런 기능들은 쉽게 처리가 되고, 보안적으로나 로직적으로나 더 잘 짜여져 있음. (학습 목적상 직접 구현해 본 것은 좋음)
- 빅데이터 처리 어떻게 할 것인지 고려 필요. 이런 서비스는 상당히 많은 데이터 및 비정형 데이터가 많이 생기게 될텐데, 따라서 mysql 보다는 nosql db들을 사용하게 될 확율이 매우 큼. (거래량이 엄청 많이 질 것이라… mongo db 및 ec2 설치형 보다는 RDS 기반의 서비스 고려해볼 것) |
6조 | 인규와 아이들 | 16 | 65 | 10 | - 멋사에서 외주주고 개발한 프로젝트라고 해도 손색이 없을 듯. 서비스 품질도 좋아 보이고, ERD 등에 대한 설계등도 잘 하였음. 다만 이제 학생 차원에서 서비스를 어떻게 보여주고, 어떻게 검색하고, 이런 부분들까지 고려가 되어 확장하면 좋을 것 같음.
- 발표 ppt 퀄리티도 좋음 (템플릿을 잘 고른 것 같고, 실제 컨텐츠의 배치나 줄바꿈 등의 디테일은 보완이 필요하기는 함). 시연 영상과 음성/자막처리까지 발표에 대한 디테일은 매우 잘 신경을 썼고, 로그인 기능의 다양한 형태는 동시에 3개를 비교해 주며 표현하는 부분까지 매우 잘 처리 하였음)
- 플랫폼 서비스에 대한 개발 항목이 매우 많은데, 이런것들을 적절히 고려하여 품질높게 개발하였음.. (정원초과, 대기신청 등의 디테일을 현실적으로 고려), 할인정책, 결제 등, toss api 활용 등까지 잘 개발 하였음..
- 리버스 프록시 분산처리, 도커 컴포즈 통한 배포, 스웨거를 통한 API 문서화 등 좋음.. (스웨거 기반에 자동 테스팅도 가능하니 그런 부분들 추후 확장 개발 시 참고)
- jacoco 코드 커버리지 유닛 테스트, sonarqube 통한 정적 분석과 코드 품질까지 고려한것 매우 좋음 |
7조 | 태조왕건우와
백성들 | 14 | 50 | 7 | - 기술적인 내용들 조금만 더 발표자료에 담아 주시면 좋음. (REST-API라던지, CICD 구성이라던지.. 개발적인 노력들.. 디자인 패턴이라던지.. 이런 부분들이 전혀 없음.)
- 사용자별 랭킹이라던지.. 활동량을 높이기 위한 기능들.. 확대하면 더 좋을 것 같음.
- 그 외 알림, 읽음/미읽음 등 디테일에 대한 구현이 좋았고, “당도” 평가 등의 컨셉도 좋았고, 나머지는 전반적으로 평이함.
- ERD 는 잘 표현되었음. |
8조 | 아이다섯이둘[I5E2] | 16 | 55 | 9 | - 발표 자료 좋고, 기획 의도 명확하게, 속 시원하게 표현되었음.. 요 서비스가 실제로 있고, 서비스가 있다는건 시장성이 있는 것임으로 기획 의도는 좋음..
- 웹 에디터로 문서 증적관리까지 고려한 부분들은 매우 좋음.. (물론 현실적으로는 문서 증적관리 서비스들 모두사인 등의 상용 서비스를 활용해서 하겠지만, 학습 차원에서 직접 다 만들어 본 부분들은 매우 기술적으로도 의미가 있었을 듯.) 거기에 더불어 결과 문서에 대한 메일 발송 등 잘 하였음.. API 연동도 많고 많은것 시도하였음..
- 개발 중 발생한 어려운 기술적인 문제와 해결 방안 등을 포함 한 부분들도 좋았음.. 근데 성공 사례보다 실패사례 위주로 설명된것은 또 살작 아쉬움..
- git stash 활용? 사실 잘 안써야 좋은데… 올바른 사용법 들 알아볼 것 (커밋, 브랜치, 등등) |
9조 | web | 16 | 60 | 8 | - 버킷리스트인데… 그냥 여행/트립 서비스 같음. 그래서 정체성이 살~짝 모호해짐..
- 반응성이나 전반적인 서비스 품질은 좋아 보임..
- 스웨거로 API 만든것.. 스크린샷에 내용은 적지만 설계적으로 매우 치명적인 실수들을 많이 하였음. URI를 잘 설계하는 기법 꼭 찾아볼것.. 단수형/복수형 경로명 등등.. 경로에 POST 등의 메소드가 안나와야 함.. (URI 컨벤션들이 너무 많이 틀림)
- 그 외에는 전반적으로 무난하게 적절한 기술들 다양하게 활용해서 잘 개발 하였음. |
10조 | 우아한 남매들 | 14 | 60 | 7 | - ERD 표현에 대한 고민 조금 더 해 볼 것.. 이걸 기반으로 백엔드 개발자가 실제로 개발을 해야 해서, 이해가 잘 가도록 보여져야 함..
- 회원가입에서 입력과 동시에 조건들 처리 되는것들 잘 하였음.. 근데 왜 굳이 "중복확인" 버튼을 두었는지? ㅎㅎ
- 전반적인 상품 선택과 서비스 개발된 부분들은 잘 하였음.. 근데, 주문 하면 어디에서 어떻게 주문됨?? ㅎㅎ
- 플랫폼 서비스의 기본 백엔드 기능들은 적절하게 준비되고 개발 되었음.. (관리자모드, 권한 등)
- 아키텍쳐 소개나, REST-API소개나 이런 부분들이 없는것이 다소 아쉬움
- 서비스를 실체화 할때 몇인분, 주문 가격과 변동성과 마트 연동 등에 대한 고민까지 해보면 좋을 것 같음… (다나와 등 플랫폼의 가격 변동 그래프 등 참고해볼것)
- 발표 컨텐츠가 많이 부실해서 아쉬웠음.. 컨텐츠 더 채울것.. |
11조 | 중요한 건 꺾이지 않는 민우 | 15 | 65 | 8 | - webflux 통해 api 동시 3개 호출한 것도 좋지만, 그래도 300ms 가 느리고 오래 걸리면 답답할텐데, 어떻게 할 것인가? 이런 고민해보면 좋음.. 장기적으로는 prefetch 방식을 통해 예측을 기반으로 미리 요청.. 이전 페이지에서 요청.. 이걸 기반으로 캐싱..
- 랭킹 데일리 백엔드 처리.. 이런것 매우 좋음.. 실시간성이 불필요한 서비스에 굳이 시간과 자원을 낭비할 필요 없음.. (매우 좋은 판단임)
- 구현한 서비스에 대한 데모가 좀 더 잘 되었다면 좋았을텐데 하는 아쉬움이 남고, 백엔드의 기술적으로는 매우 높게 평가 하였음.. |
13조 | 한사랑코딩회 | 14 | 55 | 7 | - gitlab을 사용한 CICD를 통한 배포 등은 매우 좋음.. 개발 코드를 도커 컨테이너화 시키고, 테스트를 하고, 오류가 없으면 배포를 하고, 이런 부분들 잘 습득해두길..
- 깃헙 커밋 이력 등은 사용자가 이미지로 캡쳐해서 올리는것 같은데, 클릭해서 줌인아웃 되는걸로보아, 서비스 API를 활용해서 보여주면 더 좋을 것 같음. (굳이 업로드 안해도 자동 측정도 가능 함.)
- 또 팔로우를 하기에는 이유가 있어야 해서… 뭔가 그 사람을 따라야 할 컨텐츠적인 측면 추가 고려..
- cicd 를 잘 활용하였고, 추가로 계속 다양한 플러그인들을 활용한 테스팅 자동화 까지 고려하면 매우 좋음. (소수의 인원으로 효율적으로 개발과 배포를 할 수 있음) |
14조 | 잠은죽어서자조 | 14 | 50 | 7 | - github 통해서 통합해서 github action 통해 ci/cd 배포까지 한것은 매우 좋음..
- 참고로, 회원가입 받을때 개인정보는 최소화가 좋음.. 주소는 굳이 왜… 만약 티켓 배송 등으로 필요하다면 OK 인데, 그런 내용을 사용자에게 고지해야 함.. 필수와 선택에 대한 고려 해야 함..
- 마이캘린더도 API 통해서 네이버캘린더나 구글캘린더로 보내주고 가져오기 등을 통해, 일정을 여러곳이 아닌 한곳에서 관리…
- ERD 에서 “전시” 데이터가 너무나 큼.. 정규화를 통한 분할이 좀 필요함.. (전후 사용자 통계 등은 분리해야..) |
