밈글밈글

https://memegle.xyz
우리 밈글밈글 프로젝트는 신조어와 밈을 작성할 수 있는 오픈백과 사전이다. 각종 밈 퀴즈도 풀어볼 수 있다.
뭘 했는지 소개하는게 좋을 것 같아서 미리 해본다.
실전 프로젝트의 최종 발표는 참여하지 않는 협력사를 위해 9분간의 발표 영상 자료를 만들어 제출하고, 참여한 협력사들을 상대로는 5분의 라이브 발표를 시행한다.
이 내용을 제출하기 위해 하루종일 내용을 구성하고, PPT를 디자인하고 만드는 과정을 수행했다. 일주일동안 내내 이 작업을 했다. 보다 잘 만들기 위해서, 우리의 6주간의 성과를 보여주기 위해서.
고민을 많이 했다. 우리의 무엇을 보여줘야 할 지.
프로젝트엔 사실 어떤 기술이 들어간게 없다. API 조금 가져다 쓴 것과 캐싱 조금 한 걸 제외하면 CRUD들로만 구성되어 있다.

CRUD만 있다보니, PPT로 어떤 점을 말할까 하는 고민이 들었다. 고민은 점점 깊어졌다. 그러던 중, 문득 생각이 들었다.
프로젝트에 우리가 그동안 했던 고민을 담아보면 어떨까 하는 생각이 들었다. 우리는 우리가 현재 만들어놓은 구조 속에서 발생할 수 있는 어떤 한계점이나 그런 부분들을 최대한 극복하고, 우리 구조이기에 할 수 있는 어떤 개선사항을 만들고자 열심히 노력했다. 물론 대부분의 시도는 허사였지만, 그 와중에도 유효타는 가끔 있었기에, 이 부분을 담아낼 수 있다면 나름 어필할 수 있는 포인트가 되겠다는 생각이 들었다. 이 생각을 기반으로 PPT를 만들었다.
Presentation
PPT는 다음의 포인트를 중점으로 잡고 제작했다.
1. 뻔한 성능 개선같은건 말 할 가치도 없다 - N+1 문제 같은 것 말이다. 이걸 해결 못 한 조가 있었을까?
2. 충분히 고민한 흔적을 남길 것 - 인터넷에서 기능을 찾아서 가져다 붙이고 자랑하는 것이 아니라 이 문제는 어떻게 발견하게 되었고, 그래서 어떻게 고민하게 되었고, 어떻게 해결하게 되었는지를 말하고자 했다. '이거 대단하죠?'가 아닌 '이걸 만든 우리가 대단하죠?'를 어필하고자 했다.
아쉬웠던 점은 시간이었다. 9분, 그 중에서도 백엔드에게 주어진 시간인 3분 30초는 우리의 고민을 담아내기엔 터무니없이 짧은 시간이었다. 최대한 거두절미 했음에도 그랬다. 우리의 고민과 그 해결을 위한 노력을 충분하지 어필하지 못 한 점이 정말 아쉬웠다.
여기에서나 적는거지만, 우리의 챌린지는 다음과 같았다.
1. 스칼라 서브쿼리의 적용, 하지만 풀테이블스캔에서의 성능저하 발생
-> 풀테이블 스캔을 하는 영역에서는 분리해 HashMap에 저장하여 관리.
-> 개선 이전 테스트 환경에서 평균 1100ms의 속도 -> 스칼라 서브쿼리 적용후 450ms -> 분리한 뒤 150ms
[SpringBoot] FetchJoin 없이 N+1 문제 제거하기
성능 개선 22. 1. 24. 추가) 폐기 안 된 방법입니다. 상황에 따라 못 짠(스칼라 서브쿼리가 많은) 한 방 쿼리보다 빠르다. 일단 SQL 짜는 능력이 부족한 지금은 이 방법을 적용하는 것이 나아 보인다.
dazbee.tistory.com

2. Youtube Data Api v3의 적용, 하지만 기능의 검색 신뢰도가 낮은 문제 발생
-> Levenshtein Distance Algorithm 적용, 문장의 유사도를 비교하여 신뢰도 향상
[Java] 문자열의 유사도 구하기 : 거리 알고리즘
Levenshtein Distance Algorithm 실전 프로젝트 중, 유튜브 영상을 검색해 관련성 있는 영상을 가져오는 기능을 구현하던 중 문제가 발생했다. 유튜브 영상의 검색결과가 생각보다 그렇게 관련성이 높은
dazbee.tistory.com

3. 알림 요청 기능이 매 페이지마다 발생하는 문제
-> 사용자의 상태에 알람 확인 여부를 넣은 뒤, 변화가 없을 경우 Redis, 변화가 발생했을 경우 DB에서 데이터를 가져오도록 만들어 해결.

4. 오픈사전의 동시 수정 제한
-> 사전에 플래그를 넣어 플래그가 존재할 경우 다른 사람의 수정을 제한, 존재하지 않을 경우 수정 가능하도록 하여 구현.

5. 각종 캐싱 전략
- 메인페이지 / 퀴즈페이지 / 통계페이지 / 베스트 데이터 관련(사전, 짤방 페이지) 정적인 데이터의 캐싱
- 알람, 동시 수정 제한과 같은 데이터의 캐싱
이 것들을 모두 열심히 말하면서 나는 초보자이지만 열심히 했어요, 많은 고민을 했어요. 그런 것을 알리고 싶었지만 그러지 못 한 점이 너무 아쉬웠다.










































후기
이번 실전프로젝트 기간은 나에게 있어 많은 고뇌과 그만큼의 성장을 가져다 주었다.
등 떠밀려 팀장이 된 사람과 함께하고싶지 않은 마음에 직접 팀장을 지원했고,
이 정도의 마음가짐으로는 팀장의 업무를 수행하기엔 준비가 많이 부족했다는 점과,
팀장이라는 포지션이 가지는 책임감과,
중간 발표에서의 힘듦,
내부적인 어려움,
최종 발표를 준비하는 어려움까지..
물론 이 사이사이에도 번민과 고통이 있었다. 중간에 항해99를 드랍할까 하는 마음까지 들었다.
하지만 정말 뛰어난 팀원분들이 노력하는 모습을 보면서 내가 지금 나가면 얼마나 부끄러울까 하는 생각이 들어 그러지 못 했고, 결국 끝까지 해낼 수 있었다. 정말 뛰어난 팀원분들이 함께 해주셨다. 이 점에 너무 감사했다. 나는 운이 정말 좋았다.
스스로에게 기특한 점은, 하루에 6시간을 안 자면 큰일이 나는 내가 5시간씩 자면서 작업을 했다는 점이었다. 앞으론 이러지 말아야지.
힘든 일도 많았지만 그만큼 재미 있었다! 이력서 쓰러가야지!
'내가 발표한 것들' 카테고리의 다른 글
항해99 1/8(토) 발표 - 실전프로젝트 (0) | 2022.01.08 |
---|---|
항해99 12/9(목) 발표 - DB Index? 뭐가 좋고 뭐가 안 좋은데요? (0) | 2021.12.09 |
항해99 4기 11/18(목) 발표 - OSI 7계층 : 이게 뭘까요? (0) | 2021.11.18 |
항해99 4기 11/12(금) 발표 - 알고리즘 : 칼을 뽑는 법, 무라도 써는 법 (0) | 2021.11.18 |
댓글