Graphy, 프로젝트를 기록하다

개발자를 준비하다 보면, 좋은 프로젝트에 대한 고민이 많아진다.

하지만 처음부터 좋은 프로젝트를 개발하는 것은 어렵기에 대부분 프로젝트 레퍼런스를 참고하거나, 주변에 평가를 받아 개선하기도 한다.

Graphy는 이를 도와줄 수 있는 프로젝트 공유 플랫폼이다.

개발자로 취업 준비 중인 사용자를 타겟팅한 포트폴리오 기록 사이트로, 사람들이 보다 좋은 프로젝트를 개발할 수 있도록 도와주는 것을 목표로 하고 있다.

👀 Graphy 메인 페이지

👀 Graphy 프로젝트 공유글 작성 페이지

👀 Graphy 프로젝트 공유글 검색 및 상세 페이지

⚠️ Graphy가 겪은 이슈

❗️ 댓글 API 개선기 (Backend)

댓글은 계층형으로 구현하고 경우에 따라 삭제되더라도 “삭제된 댓글입니다.” 형태로 화면에 보이도록 했다.

초기에 설계했던 댓글 삭제의 비지니스 로직이다. 댓글의 경우 답글의 유무에 따라 삭제 처리가 달랐고, 반대로 답글의 경우 화면에서 바로 지우지만, 추가로 원댓글에 대한 삭제 로직이 존재했다.

해당 로직을 다중 IF문을 사용해 구현했었으나, 이 방법은 서버에 부담이 될 수 있고, 응답 속도 저하로 사용자의 부정적인 경험을 유발할 것이라고 예상해 두 가지의 개선안을 생각했다.

이전과 달리 댓글 답글 모두 삭제 처리, 조회 시 쿼리문을 이용한 삭제된 댓글 마스킹
서버에서 처리했던 로직은 최대한 쿼리문으로 처리

하지만, 또 다른 문제가 발생했다. 조회 시 모든 댓글과 답글을 불러오기 때문에 다수의 댓글이 저장된 경우 지연이 발생할 수 있었다.

이 문제는 유튜브 댓글 방식으로 해결했다.

유튜브는 답글의 개수만 보여주고, 클릭을 해야 조회가 이루어진다. 기존의 전체 조회가 아닌 이 방식을 적용해 성능을 개선했다.

🔅 성능 개선 결과

댓글 9,000개를 기준으로 각각 삭제에 있어 각각 44%, 75%의 개선 효과

❗️ QUILL 에디터 이미지 처리 (Frontend)

프로젝트를 작성하고 공유하는 저희 프로젝트 특성상 텍스트 에디터가 필요했기에 Desktop/Moblie 지원이 가능하고 한글 입력이 가능한 Quill 에디터를 선택하였다.

Quill 에디터를 활용하여 글 작성 기능을 개발하였고, 직접 사용해보면서 글을 작성하는 데 오랜 시간이 소요되는 것을 알게 되었다.

여러 시도를 해보면서 이미지를 넣은 글이 글만 있는 게시글보다 훨씬 작성 시간이 오래 걸린다는 것을 발견했다.

이 문제점에 대한 정보를 찾아보니 Quill 에디터는 기본적으로 이미지를 BASE64로 인코딩 해서 업로드 한다는 것을 알게 되었다. 기존의 이미지 처리방식은 프론트에서 이미지를 서버로 넘기고 그 이미지를 S3로 넘기는 방식인데, 8비트를 6비트로 표현하려는 Base64의 특성 때문에 33%의 용량 증가가 발생하며 이 증가한 용량과 긴 문자열을 다시 이미지로 표현할 때 걸리는 시간 때문에 로딩 시간이 결국 증가하게 된 것이다.

이를 해결하기 위해 프론트에서 S3로 바로 이미지를 업로드 시킨 뒤, 서버에 URL만 보내는 대안을 생각했다.

바꾼 이미지 처리 방식에서는 프론트에서 직접 S3로 이미지를 업로드 시키기 때문에 그 과정에서 서버를 경유하지 않아도 된다. 이미지 파일이 아닌 URL만 백엔드 서버로 전송하면서 용량 문제도 해결했다. 추가로 사용자가 이미지를 요청할 경우에도 서버에서 반환한 URL을 바로 사용해 이미지를 보여줄 수 있어, 로딩속도까지 감소하게 된다.