✒️ 기획자, 디자이너와 함께 하는 첫 사이드 프로젝트
처음 시작은 정말 간단한 웹프로젝트라고 해서 시작하게 되었다.
백엔드도 거의 없어도 될거라고, 프론트 혼자서 충분히 개발 가능할 것 같다고.
이미 PM으로 일하고 계신 분이 이 프로젝트를 생각하게 된 계기, 디자인, 작업 계획 등을 세세하게 말씀해주시며 함께 플젝을 해보자고 말씀하셨고, 나도 마침 할 일이 딱히 없었던 지라 흔쾌히 수락했다.
무엇보다 2학년 때 디자인과 수업을 들을 정도로 디자인에도 관심이 많았고, 프론트엔드 개발자로서 UX에 대해 이론적으로 좀 더 알 수도 있겠다는 생각이 들어 재밌어보였다.
특히, 디자이너나 기획자와 함께 프로젝트를 해본 것은 회사나 대외 활동에서 강제적으로(?) 묶여있을 때 뿐이었어서, 자발적으로 사이드 프로젝트를 함께 해보면 내가 보지 못했던 시야에서도 볼 수 있어 좋은 경험도 될 것이라 생각했고, 무엇보다 너무 재미있을 것 같았다.
실제로 PM 분이 처음 이야기하기로는 정말 간단한 단계였고, 백엔드도 필요 없을 것이라 이야기하셨기에 나 혼자 해도 큰 어려움이 없을 것 같았다. (물론 이제는 확실히 안다… PM과 디자이너 입장에서의 간단함과…. 개발자의 간단함은……. 너무 다르다……..)
🙌🏻 프로젝트 소개
그리고 아래는 PM 분이 링크드인에 작성하신 우리 서비스에 대한 소개이다.
(실제로 프로젝트 같이 하자며 이 얘기를 하셔서... 재밌을 것 같아 풀스택으로 혼자 개발하자는 꼬임에 넘어갔다...하하하....)
배포된 서비스 링크는 https://uxpirates.xyz/ ⬅️ 여기이다.
사용한 기술 스택을 간단하게만 분류해서 작성해보자면 아래와 같이 정리할 수 있을 것 같다.
FE : react + typescript
BE : nodejs + express
DB : JSON
Cloud : Docker, Docker-compose, ec2
UX 해적단은 UX 원칙에 기반해 실제 프로덕트를 분석하는 UX 스터디입니다.
단순히 인터넷에 정리된 UX 원칙을 읽고 정리하는 것을 넘어, 이 원칙들을 실제 사례에 적용하며 UX 개념을 더 깊이 이해하는 방식으로 학습합니다.
제가 만든 UX 해적단 스터디는 UX 관련 자료를 한국어로 체계적으로 공유하는 데 의미를 두었습니다.
좋은 아티클을 찾으려면 늘 영어 자료를 번역해야 했고, 그 과정에서 많은 디자이너들이 (저 역시도) 원문을 온전히 이해하기 어렵거나,
한국어로 쓰인 질 높은 분석글을 접하기 힘들다는 점이 아쉬웠습니다.
이러한 문제를 해결하고자, 한국의 디자이너 혹은 디자이너를 꿈꾸는 분들이 더 정제된 UX 사례를 쉽게 찾을 수 있도록 돕고자 시작한 개인 프로젝트였습니다.
그런데 예상보다 많은 분들이 관심을 가져 주셨고, 생각보다 더 큰 프로젝트로 성장할 수 있었습니다.
지난 8개월간,
✅ 26명의 스터디원이
✅ 300개 이상의 UX 분석글을 직접 작성했습니다.
그리고 이 과정에서 스터디가 누군가에게 미약하게나마 도움이 되고 있다는 것을 실감했습니다.
그래서 더 많은 분들에게도 이 방대한 스터디 결과물을 더 잘 정리하고 공유하기 위해 UX 해적단 홈페이지를 만들었습니다.
📌 UX 해적단 홈페이지에서 확인할 수 있는 내용
✔ UX 키워드 분석 아티클
✔ 키워드별 / 프로덕트별 UX 분석 자료
✔ 스터디 참여 링크
🎨 확실히 디자이너들은 달랐다…
가장 처음에 1차 디자인이 완성되고 1차 완성된 부분 먼저 개발에 들어가게 되었다.
처음 피그마를 받아보았을 때… 많이 놀랐다.
나도 꽤 피그마를 다룰 줄 안다고 생각했는데, 정말 오만이었다.
우선 페이지도 체계적으로 나뉘어져있었고, User flow나 Lo-fi도 정말 세세하게 작성해두셨다.
사실 페이지도 그렇게 많지 않은데 이렇게 꼼꼼하게 작성해두신 것을 보고, ‘난 정말 디자이너는 못하겠다.’는 생각을 수천수만번 했던 것 같다.
아래 이미지들이 1차로 받았던 피그마였고,
아래 이미지는 최종적으로 작업하게 된 페이지 중 일부인데,
피그마에서 prototype으로 모든 인터렉션을 확인할 수 있도록 연결시켜두셨다.
예를 들어 어떤 버튼을 클릭하면 이 화면으로 넘어가고, 어떤 버튼 위에 호버하면 어떻게 되고 등등…
개발자인 나로서는 “도대체 이걸 하나하나 언제 다 연결하고 있는 거지?” 자동화도 없이 그냥 하나하나 연결해나가는 것이 너무 신기하고 대단해보였다.
다시 한 번 난 절대 PM이나 디자이너는 못하겠다고 생각했다. ㅎ
이렇게 꼼꼼하게 모든 경우의 수를 작성해 둘 자신이 없다.
🛠 겪었던 시행착오들
분명 처음 시작할 때에는 백엔드 개발자도 필요 없을 정도로 간단한 프로젝트다, 페이지 하나만 할거다 하셔서 정말 간단한 토이 프로젝트 정도로 생각했었지만 생각보다 (많이) 복잡했다.
기획자와 디자이너 입장에선 간단하다고 생각하는 것들이 많았다…
예를 들자면 모달을 페이지처럼 띄우는 것…. 필터링 기능 등등…
정말 많은 시행착오가 있었지만, 간단하게나마 작성해보려고 한다.
다만 매번 에러를 쳐내고 다른 프로젝트 (네부캠)를 하느라 해결하고 본업(?)으로 바로바로 돌아가느라 따로 작성해두거나 기록해둔 것이 없었고,,,
주고받은 연락을 토대로 기억나는 것을 이제서야 적어보게 되었다. 그래서 분명 구체적이지 않을 수도 있다.
😭 잦은 기획,디자인 변경
처음부터 기획이나 디자인이 최종이었다면 좋았겠지만, 진행하면서 기획과 디자인이 계속 바뀌었다.
특히 데이터 구조가 여러 번 바뀌었는데, 예를 들자면 처음에는 아티클을 pattern, category, ui component라는 태그로 분류했었다.
사실 데이터 구조가 바뀐 건 개발자(나)만 아는 것이고, 그냥 이 태그를 안 쓰기로 했다고 하면 키워드를 사용하고 있던 DB 구조를 바꿔야 하는 것이었다. 사실 디자인에서의 변경은 UI를 바꿔야 한다는 것이 확실히 눈에 보이지만 기획에서의 변경은 그저 나(개발자)만 아는 것이었을 뿐이라,,,,ㅎ
(실제로 처음엔 이렇게 필터링 디자인도 달랐고, 검색 기능도 있었다)
(그리고…. 이미지 보면 알겠지만 구현도 다 해뒀었다 ㅋㅋㅋㅋㅋㅋ큐ㅠㅠ)
그런데 어느 날 갑자기 "이런 분류 체계와 검색 기능이 지금 단계에서는 필요 없을 것 같다"고 하면서 기존 구조를 날려버리게 되었다…..
덕분에 DB 전체를 수정해야 했고, API도 싹 바꿔야 했다. 사실 DB 구조나 디자인을 정말 많이 바꿨어서, 처음 화면과 기능을 보면 지금과 완전 다르다는 것을 알 수 있다.
기획이 바뀌면서 이미 만들어놓은 컴포넌트들 중 일부는 폐기되었고, "이거 필요할 것 같아요!"라고 해서 만들었던 기능들은 몇 주 뒤 "이거 안 쓰는게 맞는 것 같아요!"라는 말과 함께 사라지곤 했다.
그래도 난 기획자와 디자이너가 잘 할 수 있는 영역과, 개발자가 잘 할 수 있는 영역이 따로 있다고 생각하고, 서로 의견을 낼 수는 있지만 그 의견을 수용할지 수용하지 않을지는 각자가 선택하는 것이라고 생각한다. 각자가 잘하는 분야이고, 적어도 그 분야에서는 나보다 더 많이 배운 사람이라 생각하기 때문에 서로의 요청을 반영하는 것 또한 그 역할의 의무라고 생각한다.
그래서 수정을 요청하실 때마다 열심히 반영했다.
대신 사용자 입장에서 부정적인 경험을 갖게 될 것 같은 요소라면 의견 정도는 제안했었다.
예를 들자면 지금은 아예 없어진 기능이지만 검색 기능을 구현할 때 검색 결과 UI가 직관적이지 않아 좀 더 검색의 느낌이 강하도록 제안했던 것…?
이렇게 피그마 디자인 대로 구현했지만 이상할 때 미리 의견을 묻는 것 정도…?
그리고 이런 식으로 기획에서 생각 못 했던 정말 사소한 예외 상황들을 가정하는 것…?
이외에도 정말 여러 이야기를 나누고 의견을 제안했었다. 물론 “오 그건 생각 못했는데 생각해보니 UX를 해칠 것 같네요. 오히려 디자이너가 생각 못한 부분을 생각하시네요” 하며 반영된 부분도 있었고, “그것도 맞는 이야기긴 한데 디자이너 입장에서는 UX적으로 이게 맞다고 배워서, 디자이너들이 사용할 페이지이기도 하니까 이렇게 하는게 맞을 것 같아요” 하며 그대로 진행된 부분도 있었다.
확실히 정답이 없는 분야이다 보니 정말 근거를 포함해서 “의견을 제시하는 것”까지만 했었다.
어쨌든 디자인이나 기획이 변경될 때마다 db를 새로 설계해야 하거나 api를 새로 설계해야 하거나, 만들어둔 컴포넌트를 사용하지 못하게 되어 프론트 구조 설계도 다시 해야 할 때가 많아 힘들었지만,
디자인이 변경될 때나 기능이 추가/삭제 될 때 마다 변경해야 하는 이유가 모두 납득 가능했고, 내가 납득하지 못하더라도 어떤 결정이든 기획/디자인 관점에서 사용자를 위한 결정이었기 때문에, 적어도 그렇다고 믿었기 때문에 힘들기는 해도 오히려 즐겁게 개발할 수 있었던 것 같다.
🔎 확장성을 고려한 설계
이 프로젝트는 정말 ‘완성’이라는 개념이 없고, 계속해서 사용자 반응을 보고 키워갈 여지가 엄청 많은 프로젝트였기 때문에, 확장성을 고려해서 구현해야 했다.
그리고 어느 기능까지 1차 배포용으로 사용하고, 어느 기능은 다음 배포로 미룰지조차 정해지지 않았기 때문에, 최대한 어떤 기능이든 가장 쉽게 추가할 수 있도록 구현해야 했다.
확장성을 고려한 부분이 많았지만, 지금 생각나는 예시로는 이 프로젝트가 나중에는 외국어도 지원했으면 좋겠다고 말씀하셨기 때문에 처음 db 설계 할 때 영어로도 변수명을 저장해두어야겠다고 생각했고, 데이터를 처음 저장할 때부터 최대한 필요해보이는 정보라면 모두 넣어두려고 하였다.
그 외에도 설계 단계에서 엄청 공을 많이 들였는데, 특히 백엔드와 DB는 최대한 손대지 않고 싶어서 (개인적으로 백엔드와 DB는 제대로 안 해두면 갈아 엎기 훨씬 빡세다고 생각한다…) 엄청 꼼꼼하게 설계하려고 했던 것 같다.
🚧 서버 비용을 최소화하기 위한 노력
그리고 이 프로젝트의 또 한가지 특징이라고 한다면, 서버 비용을 정말 최소한으로 하려고 했다는 것이다. 물론 프론트는 vercel 같은 호스팅을 이용해도 되지만, 어차피 백엔드는 무조건 올려야 하기 때문에 (무조건 하나는 서버를 써야 하기 때문에) 서버 비용을 최소화 할 수 있는 여러가지 방법을 생각해보았었다.
서버를 어차피 하나는 올릴 거라면, 프론트도 내 힘으로 배포하고 싶다는 생각이 많이 들었고, 처음부터 끝까지 혼자 힘으로 docker와 docker-compose를 사용해서 배포하고 싶다는 욕심이 있었다. 그래서 굳이 vercel을 사용하지 않았고, 그럼에도 서버는 하나로만 돌리고 싶었기에 프론트와 백엔드를 하나의 서버에 함께 올리게 되었다.
지금 생각하면 무모하고, 어쩌면 어리석기도 한 아이디어인 것 같지만, 실제 돈을 벌기 위한 서비스가 아니기 때문에 오히려 서버를 2개씩 올리는 것은 더 무모하고 오버스펙이라고 판단했다.
어쨌든 그렇게 프론트와 백엔드를 하나의 서버에 올리기로 결정하였는데…
가장 걱정이고 결정하기 어려웠던 것은 DB였다.
PM분이 DB를 쓰지 않았으면 좋겠다고 처음부터 말씀하셨고, DB를 쓸 정도로 무거운 프로젝트가 아니기 때문에 DB가 없었으면 좋겠다고 했었다.
사실 개발자로서 DB를 쓰지 않을 수 있는 프로젝트가 있다면 정말 화면만 노출시키는 정도의 프로젝트라고 생각하는데, 기획자의 관점에서는 DB를 쓴다는 것이 무겁다는 인식을 가지고 있었던 것 같다.
만약 백엔드 개발자와 협업하는 프로젝트였다면 무조건 DB를 썼을 것이고 (백엔드 개발자가 있었다면) 아마 누구든 무조건 쓰자고 밀어붙였을 것이다) 그게 맞았겠지만, 나 혼자 이 모든 서비스를 개발해야 했기 때문에 (나는 FE 분야의 실력을 늘리고 싶은 마음이 강했기 때문에) DB를 쓰지 않는 것이 나쁘지 않은 선택이라는 생각이 들었다.
보안이 중요한 프로젝트도 아니고, “글 쓰기”와 “써져있는 글 보기”가 중점인 프로젝트이기에 큰 문제가 없을 것이라고 판단했었다.
결국 이 서버에 만약 PostgreSQL이든 NoSQL이든 데이터베이스를 올리게 되면
- PM 관점에서 프로젝트가 너무 무거워진다.
- 풀스택으로 참여한 FE 개발자의 관점에서, DB까지 다루고 싶지 않다.
내가 이 사이드 프로젝트를 통해 실력을 쌓고 싶은 분야는 FE, Cloud + 약간의 BE 정도였다. 이 BE에 DB까지 끼워 넣을 여력은 되지 않았고, DB만큼은 최소한으로 가져가자는 것이 내 판단이었다.
그래서 결국 데이터베이스를 사용하지 않고 그냥 json으로 관리하기로 하였고, 이 선택은 엄청난 후폭풍을 몰고 오게 된다.
🤯 그럼 이미지는 어떻게 저장하지…?
사실 json으로 관리하기로 결정할 때, 가장 걱정했던 것은 이미지였다. 이미지 파일이 글마다 들어가야하는, 오히려 트위터 같이 글을 보는 서비스가 아니라 인스타그램 같이 사진을 보는 서비스에 가까운데, 사진을 DB나 별도의 서버/스토리지를 쓰지 않고 어떻게 저장할지가 관건이었다.
서버의 비용을 절대 더 늘릴 수는 없었기에, 이미지까지 저장하면 정말 비용이 너무 많이 들 것 같았다.
그래서 선택한 방법은, 호스팅 사이트를 이용하는 것이었다.
어차피 글을 쓰는 사람은 이 프로젝트에 참여한 3명 중 한명이기 때문에, 굳이 이미지를 파일로 올리지 않아도 글을 작성하는 방식을 알 수 있는 사람들이었다. 그래서 이미지를 호스팅 사이트에 업로드해서 그 업로드 된 url을 db에 저장하게 하고, 글을 가져올 때 db의 해당 url을 읽어서 이미지로 노출시키는 방법을 생각해냈다.
사실 일반적인 방법이라고 할 수 있을지 정말 모르겠다. 누군가에게는 신박하고 충격적인 (멍청한..?) 방법일 수도 있을 거라는 생각도 들었지만, 비용을 최소화 할 수 있는 최선이었다고 생각한다.
어쨌든 글을 새로 작성할 때, 호스팅 사이트에 업로드 해서 추출한 url을 아래와 같이 관리자 페이지의 이미지 url input에다가 넣어주면, 그 이미지 url을 json 파일 (데이터 저장 공간)에 글의 정보와 함께 추가해주게 되는 것이다.
실제로 이렇게 포스팅하며 초반 테스트를 해보았을 때는 아무 문제가 없었고, 오히려 서버 비용을 아꼈다고 생각해서 신이 났다.
하지만… 밑에서 이야기하겠지만 이렇게 호스팅 사이트를 이용하니 글을 많이 추가해서 이미지가 훨씬 많아졌을 때 이미지를 불러오는 속도가 너무 느려졌고, 사이트를 사용할 수 없는 정도의 수준에 이르게 된다…
🐳 Docker, Docker-compose로 배포하기 위한 노력
위에서 언급했듯 이 프로젝트를 하면서 FE 뿐만 아니라 cloud에 대한 이해도 확실하게 잡고 싶었다.
저번 학기에 들은 수업에서 docker와 k8s, jenkins 등을 배우며 ‘이런 게 있군’ 정도를 알았고, 재작년 인턴을 하며 실제로 jenkins 파이프라인까지 사용해보며 흥미를 가지게 되었다. 프론트엔드는 내가 개발한 것이 눈에 보여서 흥미로웠다면, 클라우드는 반대로 보이지 않아서 흥미를 갖게 된 것 같다.
어쨌든 이 프로젝트에서 꼭 docker를 직접 사용해서 프론트와 백엔드를 모두 배포해보고 싶었기 때문에 구현을 다 하고나서 docker로 감싸는 작업을 하게 되었다.
그런데 꼭 항상 문제는 nginx에서 터지는 것 같다. 백엔드는 docker로 감싸는데 큰 어려움이 없었지만, 프론트 쪽은 nginx도 사용해서 묶어주어야 했기 때문에 많이 어려웠다. ‘welcome to nginx!’ 페이지만 몇 번을 본 건지 모르겠다.
프론트엔드와 백엔드를 모노레포로 관리하면서 각각을 docker로 띄우고, 이 둘을 docker-compose로 함께 띄우는 것을 정말 여러번 시도했고 공부했다. 겪었던 일부 문제는 블로그에 이미 작성해두었기 때문에 굳이 어떤 문제가 있었는지 여기에서 자세하게 적지는 않을 것이다.
많이 힘들고 가장 오래 걸린 작업이긴 했지만, 덕분에 docker-compose에 대해 더 많이 공부해 볼 수 있었고, 특히 volumes 같은 개념을 진심으로 이해할 수 있게 되었다.
💬 기획자/디자이너와 개발자의 소통 오류..
사이트를 보면 알겠지만, 왼쪽 사이드바에서 필터링을 걸 수 있는 기능이 있었다. 이 필터링을 어떤 기준으로 거는지에 대해서 회의 때 여쭤봤었는데, PM 분이 and 조건으로 걸어달라고 하셨었다.
나는 아무 생각 없이 일반인의 관점이 아니라 개발자의 관점에서 and로 처리하였고, 그 말은 당연히 공통으로 들어가는 요소들만 출력되게 하는 것이었다.
그러니까 밴다이어그램으로 이야기를 해보자면, Toss와 Coupang을 둘 다 체크하면 프로덕트가 Toss이면서 Coupang인 아티클을 보여주게 했다는 것이다.
그런데 알고보니 PM 분은 그 반대를 의미하신 거였고, Toss와 Coupang을 둘 다 체크하면 Toss에 해당하는 아티클 + Coupang에 해당하는 아티클을 모두 보여주게 해야했던 것이다.
(심지어… 서로 “당연히” 각자가 이해한 대로 생각하고 있다가, QA 진행할 때 작성해주셔서 서로 이해에 차이가 있었다는 것을 알게 되었다…)
OR로 걸어달라는 이야기임을 깨닫고 수정했는데, 선택할 수 있는 대분류가 크게 ‘UX 평가, 프로덕트, 키워드’ 세 개가 있었고, 세 분류도 OR로 걸게 되면 그냥 모든 아티클이 나오게 되는 경우도 발생했다.
예를 들자면 Good UX와 Bad UX, Coupang 세개를 선택하면 모든 아티클이 노출되게 되는 것이다.
(나도 지금 쓰면서 맞게 쓰고 있는 것인지 헷갈린다..;;)
결국 이런 경우를 말씀드리니 이것까지는 생각하지 못했다고 해서, 이 세 분류끼리는 AND 조건으로 걸고 같은 분류 내에서는 OR 조건으로 거는 것을 제안드렸고, 이렇게 진행하기로 결정하였다.
🥶 역시 가장 힘들었던 QA
인턴을 하면서 개인적으로 QA가 가장 힘들었기 때문에, 당연히 힘들 것이라고 예상은 하고 있었다.
그런데 아무리 예상을 해도… 힘든 건 언제나 마찬가지인 것 같다. 사실 모두가 그렇겠지만 어렵다기보다는 귀찮다?에 가까운 것 같다.ㅎㅎ
어쨌든 아래에서 볼 수 있듯 엄청난 QA가 진행되었고…
확실히 디자이너가 보는 눈은 다르다는 것을 뼈저리게 체감할 수 있었다.
그런데 원래는 모바일 디자인이 따로 없었고, (그렇게까지 큰 프로젝트가 아니니까 모바일은 절대 안 만들거라고 하셨었다) 데스크탑 버전을 그대로 사용하기에는 무리가 있을 것 같아 내가 임의로 모바일인 경우 한 화면에 보이도록 비율만 조정하는 정도로 만들었었다.
그런데 디자이너와 PM분 모두 QA하면서 실제 배포된 것을 사용해보니 데스크탑 버전을 그대로 사용할 수는 없겠다고 판단하셨다.
그래서 정말 미안하지만 모바일도 만들어야겠다고 하셨고, 결국 QA만 하면 끝날 줄 알았지만 새로 모바일 버전을 개발하게 되었다…
(원래 회의를 미리 잡거나 정규적으로 정해두고 했는데, 갑자기 전화가 오길래 엄청 놀래고 심장 떨어질 뻔 하기도 했었다…ㅎㅎ….^^ 전화까지 왔다는 건 … 내가 크리티컬한 문제를 만들었다거나… 정말 큰 일이 났을 때일테니까…. 그치만 오히려 이렇게까지 겁먹어서인지 모바일버전 만들어야 할 것 같다는 내용인 걸 듣고 오히려 안심했다 ㅎㅎㅎㅎ^^)
모바일 버전에서는 디자인이나 기능도 달라졌기 때문에 (예를들어 필터링 하는 사이드바가 모달처럼 열고 닫을 수 있는 메뉴로 바뀌었다) 컴포넌트를 아예 새로 만들어야 했다. 그 외에도 모바일만을 위한 컴포넌트를 만들어야 할 부분이 많았다….ㅎ
어쨌든 ㅎㅎ 모바일도 급하게 구현한 뒤 모바일 버전까지 QA를 수차례 진행했고, 수정하는 작업을 거쳤다.
정말 최소한의 기능으로만 만들었던 관리자 페이지도… 아티클 추가를 조금이라도 편하게 하기 위해 기능 추가 요청이 꽤 있었다.
아티클을 추가할 때 이미지의 크기가 같지 않은 경우에 대한 대응도 필요했고, (물론 이건 개발 쪽에서 할 수 있는 것은 없었다) 수없이 많은 개선과 수정 작업을 거쳤다.
😭 아직 많이 부족한 개발자라.....
쓰다보니 위에서 계속 개발에 새로운 요청사항만 언급해서 기획이나 디자인이 부실했나? 싶게 보일 것 같다는 생각이 문득 드는데,
전혀.
오히려 내가 바쁘다는 핑계로 덜렁덜렁 작업해서 api가 제대로 실행되지 않는 경우도 있었고,
(심지어 이건 배포했다고 해서 터지는 문제도 아니고 그냥 동작 제대로 되는지 기본적인 테스트도 안 거치고 배포해버린 엄청난 나의 귀차니즘 때문이었다. 그냥 정말,,, 미친거지)
내가 한번에 제대로 구현하지 못해서 (정말 기본적인 것인데도…) 계속 반복해서 QA 주고 테스트하셔서 그냥 미안하고 죄송할 따름이었다….
그리고 모달 창이 단순히 state가 변경되는 것이 아니라 화면만 모달이고 페이지의 개념으로 사용되는 거라
페이지를 바꿨을 때 새로고침 되면서 스크롤이 가장 위로 올라가버리는 문제가 발생했다.
아래와 같이 모달창이 띄워지면 스크롤이 올라가버리는 문제였는데,
이 문제는 다른 포스팅에서 따로 작성할 예정이기 때문에 자세하게 적지는 않겠다.
🐢 모바일에서 이미지 로딩이 너무 느리잖아요 …..
QA를 모두 해결하고나서, 이제는 정말 사용자를 받기 전, 아티클을 추가하는 단계가 되었다.
그런데 아티클이 100개 정도 되니 너~무 느려지는 현상이 발생했다.
캐시를 모두 지우고 새로고침을 할 때면, 이미지를 가져오는 데 거의 5초 이상은 걸렸다.
5초까지는 정말 양보해서 그렇다고 칠 수 있는데, 문제는 모바일에서 발생했다. 모바일에서는 캐시를 지우고 접속하면 거의 20초는 넘게 걸렸고, 심지어는 시간이 너무 오래 걸려서 이미지를 끝까지 가져오지 못하는 문제도 있었다.
이렇게는 도저히 사용자를 받을 수 없었기 때문에 어떻게든 해결을 했어야 했는데,
가장 먼저 생각해낸 문제의 원인은 바로 호스팅 사이트였다.
위에서 언급했듯 서버 비용을 줄이기 위해 외부 호스팅 사이트를 이용해서 이미지를 가져오고 있었고,
가장 먼저 생각났던 것은 ‘호스팅 사이트의 서버에 의존하기 때문이 아닐까?’ 하는 의문이었다.
그런데 조금 더 생각해보니 “아무리 우리 서버나 스토리지를 따로 쓴다고 해도, 최대한 가장 저렴한 비용의 서버를 사용할텐데 과연 호스팅 사이트보다 얼마나 더 빠를 수 있지?” 하는 의문이 들었다.
따로 DB를 둔다고 해서 이 현상이 극단적으로 좋아질 것 같지는 않다는 생각이 들었고, 프론트 쪽에서 로딩 시간을 줄일 수 있을 방법을 찾기 시작했다.
우선 가장 먼저 UX를 개선해야겠다고 생각했고, suspense 로딩바를 채우면 괜찮지 않을까 하는 생각이 들었다.
지금은 이미지가 있는지조차 알 수 없었기 때문에, 사용자 입장에서는 메인 화면에서부터 이탈율이 꽤 많을 것이라는 생각이 들었기 때문이었다.
그렇게 UX를 개선해놓고, 속도가 느린 본질적인 이유를 찾아야 했다.
아티클이 적을 때에는 문제가 되지 않다가 많아지니 문제가 생겼다는 점에 집중해서 생각해보았다.
그러다 계속 테스트를 하다보니 페이지에 접속하면 모든 이미지들이 동시에 불러와진다는 것을 발견했고,
당연히 페이징 등의 처리가 전혀 되어있지 않기 때문에 모든 아티클들의 이미지를 한번에 다 불러오고 있다는 것을 알게 되었다.
이런 식으로 정말… 너무 느리게 불러오고 있었고,
(진짜 너무 느리니까 gif 볼 필요도 없다;;;)
이를 해결하기 위해서 여러 방법들을 시도해보았다.
해결하기 위해 시도한 방법들과, 해결한 방식에 대한 기록도 따로 포스팅을 해 둘 예정이니 어떻게 해결했는지는 여기서 언급하지 않겠다.
어쨌든 여러 시도 끝에 로딩 시간을 엄청나게 단축시킬 수 있었고, 사용자에게 서비스 할 수 있는 정도의 속도까지 개선할 수 있었다.
해결하느라 정신이 없어서 개선 전에는 lighthouse 분석을 해보지 않아 어떻게 나왔을지 잘 모르겠는데, 모바일로 접속했을 때 위의 gif에서 볼 수 있듯 20초 넘게 걸렸기 때문에 분명 이 분석 결과도 빨간색이 잔뜩 뜨지 않았었을까… 하는 생각이 든다.
아래는 해결한 후의 (데스크탑에서) lighthouse 모습이다.
어쨌든 이렇게 기획자 분도 만족할 정도의 개선 결과를 도출해낼 수 있었고, 무사히 배포할 수 있게 되었다.
📭 드디어… 서비스 오픈하고 첫 배포….
이렇게 떨려하면서 서비스 오픈하고 첫 배포 했는데,,,
바보같이 빌드 테스트 안해보고 올려서 올렸더니 바로 빌드 오류나버렸다…..
오히려 너무 떨려서 진짜 기본적인 빌드를… 까먹어버렸다….^^
정말 내가 생각해도 너무 황당하고 어이가 없어서;;;
빌드 오류 나서 gate way 뜨는 거 보고….. 진짜 처음 배포부터 망했구나 … 하며 해탈했다^^
하면서 급하게 오류난 부분 수정해서 바로 배포했다… 다행히 별 문제 아니라서 (그냥 eslint 문제였다…) 바로 대응했지만, 오류 잡는데 오래 걸리는 문제였다면…………. 생각만해도 아찔…..^^
도대체 왜 신중하지 않았니…..
대신 호되게 당한 덕분에 그 이후로 업데이트 할 때에는 항상 신중하고 신중하게 빌드도 해가면서 하고 있다…
또 개선사항이 생겨서 조만간 또 다시 이 프로젝트 개발을 해야 할 것 같지만
개인적으로 정말 재미있기도 하고 의미있기도 한 프로젝트였다고 생각한다.
처음으로 풀스택으로 혼자 모든 개발을 맡아서 실사용자까지 받아본 서비스였기 때문에,
힘들기도 하고 어렵기도 하고 감당해야할 부분도 많았고, 설계 등 해결 방안의 조언을 구하거나 토의를 할 사람도 없었지만, 다양한 문제 상황을 경험하고 해결해 본 소중한 경험이 되었다고 생각한다.
무엇보다 회사나 동아리가 아닌 개인적으로, 디자이너와 기획자와 함께한 첫 프로젝트였기 때문에 더 많이 배우고 성장할 수 있는 기회가 되었다고 생각한다.
또 네부캠 하면서, 지금도 인턴을 하면서 진행해왔던 프로젝트라 100프로 몰입하지 못한 환경이었기에 아쉬움도 남고, 한편으로는 뿌듯함도 큰 서비스이다. 아쉬움이 남는다는 건 그만큼 애정이 간다는 뜻이겠지. 회사 다니면서 리팩토링하고 추가 기능 개발할 생각을 하면 벌써 힘이 들지만, 그래도 재밌을 것 같아 기대는 된다.
아자아자 파이팅….!
+이 서비스 접속자수가 10만을 돌파했다......... 너무 놀랍고 당황스럽지만 로그 확인을 위해 고군분투(?)한 기록도 추가해둔다......
