데이터 기반의 근거있는 성능 개선 - boostcampwm-2022/web17-waglewagle GitHub Wiki
🧑🔬 대단한 것을 만들고 싶지만, 오버엔지니어링을 경계합니다.
대단한 것을 만들고 싶습니다.
처음 팀원을 모을 때, 팀원이 모여서 다 같이 의견을 나눌 때도 6주는 길지도 짧지도 않은 기간이기에 비전이 필요하다는 생각을 했습니다.
다 같이 즐길 수 있는 것, 그리고 도전적이어서 성취감도 있을만한 주제를 고르고 싶었습니다.
또한 완성도를 신경쓰고 싶었습니다. 이전까지 만들었던 것보다 성장한 모습을 보여줄 수 있는 프로젝트가 되길 바랬습니다.
오버엔지니어링을 경계합니다.
그런 와중에 다들 ‘근거 없이 대단한 것’을 만들고 싶지는 않아했습니다.
모두가 합의가 가능한 대단한 것이어야하며, 단순하더라도 근거가 있기를 바랬습니다.
회의를 진행함에 있어서 ‘우리는 A라고 기획하고, 핵심기능을 B라고 정했는데 정말 지금 거기까지 고려해야할까?’ 라는 내용으로 회의의 흐름을 잡을 수 있게 되었습니다.
📽️ 데모를 꼭 합시다.
실제와 설계는 항상 달랐습니다.
근거를 위해서 데모 배포를 꼭 하자는 이야기가 논의되었습니다.
결국 팀 내에서 논의하고 멋있게 만들어도 유저 반응은 다를 수 있다는 것이었습니다.
프로젝트가 끝나기 전, 꼭 배포를 하고 개선하는 경험이 있기를 희망했습니다.
📐 근거있는 성능 개선을 합시다.
근거있는 성능 개선을 합시다.
단순히 트렌드를 따라가는 것이 아니라, 실제 사용자의 경험을 수집하고 팀 내에서 스스로 문제에 대해서 분석하고 판단하여 성능을 개선하길 바랬습니다.
숫자로 이야기합시다.
Bad smell도 중요한 지표이지만, 판단하고 공유하기 좋은 것은 숫자라고 생각했습니다.
단순히 ‘좋아졌다’라는 것이 아니라, 수치로 나눌 수 있기를 희망했습니다.
도구를 사용합시다.
프론트엔드는 크롬 개발자 도구, 라이트하우스, React devtools, Tanstack Query devtools 등 도구를 통해서 문제를 분석하고 성능을 개선합니다.
백엔드는 테스트 코드, mockito, artillery 등을 통해 테스트 하고, 수치를 통해 문제를 분석해서 성능을 개선합니다.
수치화는 생각보다 어려웠습니다.
무엇을 수치로 정해야할지도 모르는 때가 많았습니다. 기준을 정해야하는데, 생겨난 이슈를 해결했다는 지표가 무엇이 되어야하는지 혼란스러웠습니다.
무엇이 이슈가 되는지도 어려웠습니다. 자칫하면 오버엔지니어링이 될 수 있다는 부분이 문제였습니다.
🧘 돌아보며 : 프로젝트가 끝나고
1. 웹소켓 쫑파티
Websocket을 통해서 실시간성을 보장하던 것이, 오버엔지니어링이었을 수 있었겠다는 생각이 들었습니다.
이후 발생할 서버 비용과, 확장의 어려움을 생각해서 short polling으로 변경하였습니다.
2. 키워드는 몇 개까지 보여주면 될까요?
처음 물리엔진을 만들 때, 극단적인 상황까지 고려해야한다며 버블을 500개까지 띄워서 성능을 맞추려고 했었습니다. 헌데 50 ~ 300명의 중규모 커뮤니티를 고려하여서 만든 서비스에 키워드 버블 500개를 만드는 것은 초기의 목표가 아니라는 생각이 들었습니다.
따라서 500개의 연산이 가능하도록 만드는 것 대신, 사용될 에너지를 줄여서 SEO나 접근성에 더 투자할 수 있었습니다.
3. 데모 진행 (2022.12.11)
데모를 진행하고, 많은 반응을 얻을 수 있었습니다.
다들 피곤하다는 상황을 고려하여 캠프 기간 동안 부스트캠프 내에서 가입 유저 30명과 50개의 키워드, 키워드 총 가입자 수 100명을 목표로 데모 배포를 진행했고, 배포 첫 날 47명의 유저와 81개의 키워드, 키워드 총 가입자 수 219명으로 많은 자료를 얻을 수 있었습니다.
이를 토대로 기능을 개선하고 병목현상을 예상해볼 수 있었습니다.
4. 어플리케이션 성능 분석 도구 : Jennifer Front
프론트엔드에 성능 분석 도구를 심어서 Backend와 Frontend의 성능을 모두 분석하였습니다.
이를 통해서 클라이언트의 페이지 로드 시간과 백엔드의 API 요청 시간, 에러율을 확인하여 더 나은 서비스로 개선할 수 있었습니다.
