- 저희가 기획한 PICBOY는 릴레이로 이어 그린다는 재미에 착안점을 두고 개발 되었습니다.
- 한사람이 의미없이 그린 그림에 누군가 다음 과정을 예측,상상하여 이어 그려나가 말도안되는 상황 풀이나, 절묘하게 잘 맞아 떨어지는 연계에서 오는 재미를 느낄수 있습니다!
📍FRONT GIT 바로가기
📍BACK GIT 바로가기
📍TEAM NOTION 바로가기
📍API 바로가기
📍QA 바로가기
- 2022.08.26 ~ 2022.10.06
| 이동건 | 신선호 | 장창균 | 정용욱 | 조다솜 | 정민희 | 우종훈 | 김나영 |
 |
 |
 |
 |
 |
 |
 |
 |
| (L)Backend | Backend | Backend | Backend | (VL)FrontEnd | FrontEnd | FrontEnd | Design |
🎮 내가, 혹은 다른 누군가 그린 그림에 상상력을 발휘하여 다음 그림을 그려봅시다!
| 그림 작성 | 이어 그리기 | 완성 |
|---|---|---|
 |
 |
 |
default.webm
| 사용기술 | 설명 |
|---|---|
| CDN | AWS 의 CloudFront 를 사용하였습니다. 메모리 캐싱을 이용하여 웹 로딩속도를 크게 개선할 수 있었습니다. 이미지를 다루는 서비스 이다 보니 여러 이미지들을 렌더링 할때 해당 기술이 로딩 속도에 핵심이 되었습니다. |
| MySQL | 각 유저에게 해당하는 자신이 직접 만든 게시물이나 다른 사람의 게시물에 참여한 그림이 포함되는 등 관계에 대한 효율 적인 서버관리를 위하여 관계형 DB를 선택하였습니다. |
| Web Socket | 실시간으로 알람을 준다는 점에 착안하여 웹소켓의 스톰프를 사용하게 되었습니다. 추후, 공지사항과 같은 내용을 전달하기 위해 SSE가 아닌 웹소켓을 사용하게 되었습니다. |
| Github Action | 협업 과정에서 변경 내용을 적용할 때 서버를 자동배포 함으로써 협업 절차를 좀 더 편하게 할 수 있어 사용되었습니다. |
| Https | DDos 등 서버 공격에 대한 보안을 위해서 프론트와 백 서버 모두 SSL 인증서를 통한 Https 를 적용하였습니다. |
휴대폰 인증
- 문제점 :
부적절한 게시 글을 지속적으로 올리는 불량 유저를 막아야 했습니다. 계정 자체를 삭제하는 방법을 생각해봤는데 결국은 다시 회원 가입을 하면 그만 이었습니다. 그래서 선택한 것이 유저 테이블에 상태 값을 줘서, 불량 유저의 경우에는 해당하는 상태값을 적용함으로써 서비스를 이용하지 못하게 막는 것 이었습니다. 하지만 이 방법도 결국에는 다른 계정으로 회원 가입 해버리면 그만 이었습니다.
- 가정 :
따라서 계정에 유니크한 값을 주는 쪽으로 생각을 했는데, 첫 번째로 이메일 인증, 두 번째로 휴대폰 인증 이었습니다. 적용하기 쉬운 이메일 인증을 생각했으나, 유저 입장에서 회원 가입 할 때 입력한 메일에 들어가서 인증 번호를 받아오는 번거로움이 있으면 접근하기 귀찮을 것이라는 판단과 멘토님의 멘토링을 참고하여 휴대폰 인증을 적용하기로 했습니다.
- 결과 :
사실 휴대폰 인증도 결국엔 휴대폰으로 오는 인증번호를 다시 입력해야하는 절차가 있어서 귀찮은 것은 마찬가지 였습니다. 그래도 이메일보다도 휴대폰이 좀 더 접근하기 편했고 해당 휴대폰 번호로는 더 이상 새로운 계정을 만들 수 없기 때문에 부적절한 행위를 하는 계정을 통제하기도 매우 쉬워졌습니다.
Query
-
문제점 : JPA 기본 쿼리를 사용했었습니다. 간단한 조회를 할 때에는 분명 편리했는데 서비스 기능들을 구현하는 과정에서 JPA 기본 제공 쿼리 만으로는 구현하기 까다로운 문제에 봉착했습니다. 성능 개선을 위해서 DB 조회 방식도 지금처럼 해서는 안되며 조회 방식에도 구현하고자 하는 기능을 구현하기에는 한계가 있다고 판단했습니다.
-
가정 : 조회 방식을 직접 쿼리문을 작성하여 가져오게 되면 DB 에서 꺼내올 때도 전부 불러와서 필터링 할 때 보다도 성능 개선이 있으며 무엇보다도 JPA 기본 쿼리로는 구현하기 까다로운 조건의 조회도 입맛대로 골라서 구현할 수 있어서 QueryDSL 을 사용하게 되었습니다.
-
결과 : 우선 예상 외로 코드 리팩토링이 되었습니다. 기본 조회 부분은 카테고리 따위의 필터로 조건 조회를 걸게 되어서 JPA 기본 쿼리도 조건마다 하나씩 들어감으로써 중복되는 코드들이 반복적으로 나타났었는데 QueryDSL 을 사용하여 직접 쿼리문을 작성하게 되니까 기존에 조회를 담당하던 Service 클래스를 쓰지 않아도 될 정도로 압축 되었습니다. 페이지네이션을 활용한 무한 스크롤을 적용하였기 때문에 한번에 데이터를 보내줄 때 리스트의 량이 작은 단위로 나눠져 있기 때문에 애초에 성능 개선이 눈에 띄게 올라가지는 않았지만 사용자가 많아져서 트래픽이 증가하게 될 경우에는 이 작은 성능 개선 만으로도 서비스 전반적으로 큰 차이를 보일 것이라고 판단했습니다. 마지막으로 주요 논점 이었던 복잡한 조건의 조회를 깔끔하게 해결할 수 있었습니다.
Transactional
- 문제점 :
6 프레임이 설정된 게시물에 현재 5개의 그림만 그려져 있을 때, 마지막 6번째 그림을 그려서 이어 그리기 참여를 누르게 될 때 문제가 발생했습니다. 참여 버튼을 여러 번 누르게 되면 DB에 여러 장의 사진이 들어가게 되었습니다.
- 가정 :
첫 번째로는 처음 버튼을 누르게 되면 버튼을 잠가서 다시 버튼을 누르지 못하게 하는 방법을 생각했습니다. 두 번째로는 애초에 DB 를 잠구는 방법을 생각했습니다.
- 결과 :
프론트 수준에서 버튼을 잠갔을 때는 문제점이, 여러 사람이 마지막 그림을 동시에 클릭하게 되면 어쨌든 DB에 동시에 들어가는 것은 막을 수 없었습니다. 그래서 테이블의 해당 열을 잠구는 식으로 해결 했습니다. 다만 이 경우에도 여러 번 클릭을 했을때 DB에는 하나만 들어가지만 유저가 받는 알림 메세지가 중복 해서 나오는 것은 막을 수 없었습니다. 해당 이슈는 프론트 에서 중복 알림을 막아 주는 것으로 해결했습니다.
음향 볼륨 조절
- 피드백
볼륨 조절이 필요할 것 같다.
볼륨이 너무 크다.
- 개선사항
- 효과음 파일이 별로 없어서 파일 자체 데시벨을 낮추었다.
설명 추가
- 피드백
메인 페이지 접속 했을때 무슨 사이트인지 모르겠다.
사용방법, 각 페이지별 설명 부족했다.
- 개선사항
- 사용방법을 좀 더 구체적으로 작성, 각 페이지 설명란 추가, 메인 페이지 마우스 커서 추가
스크롤바 추가
- 피드백
스크롤 바가 없어서 컨텐츠가 어디까지 있는지 구별이 불가능 했다.
컨텐츠 구별 불가
- 개선사항
- 스크롤바 추가