배스킨라빈스 웹 사이트를 개선해보았다. (feat. 웹 접근성)

💛 nalsae·2023년 3월 25일
3

💭 프로젝트 회고

목록 보기
3/7
post-thumbnail

 작년에 부트캠프에 참여하면서 HTML과 CSS 학습이 끝나갈 무렵, 미니 프로젝트를 하나 참여하게 되었다. HTML과 CSS만으로 (JS는 살짝 곁들여서) 정적 웹 사이트를 하나 만들어보는 프로젝트였는데, 선택지는 2가지가 있었다. 첫째로 새로운 웹 사이트를 간단하게 제작하는 것, 둘째로 기존 웹 사이트를 분석하여 개선해보는 것. 나와 팀원들은 고민 끝에 후자를 선택했다. 그 이유에는 프로젝트 진행 기간이 1주밖에 되지 않는다는 점이 큰 영향을 미쳤다. 1주면 아무리 간단한 웹 사이트라고 하더라도 기획, 디자인, 개발을 모두 진행하기에는 무리가 있으리라 판단한 것이다.

 팀원들과 상의하여 기존 웹 사이트를 개선하는 방향으로 갈피를 잡은 후, 어떤 웹 사이트를 개선할지에 대한 고민이 생겼다. 그래서 생각나는 브랜드의 사이트에 무작정 들어가서 개발자 도구를 켜고, 개선점이 있는지 뜯어보기 시작했다. 영 마땅한 웹 사이트가 없어서 괴로워하던 찰나에, 문득 팀원 중 한 명이 아이스크림이 먹고 싶다는 이야기를 했고 의식의 흐름대로 배스킨라빈스 홈페이지에 들어가보게 되었다. 그런데 이게 웬걸, 페이지 로딩까지 약 1분 가까이 되는 시간이 소요되는 것이었다. 개개인의 인터넷 상태나 컴퓨터 사양에 따른 차이를 감안하고서라도 느려도 너무 느렸다. 그때 나를 포함한 팀원들은 모두 느꼈다. 이거다!

 그렇게 짧지만 빡센 1주간의 여정을 시작하게 되었고, 그 과정과 결과에 대해 기억을 되살려 이번 글에서 정리해보고자 한다. 사실 개인 Notion과 GitHub Wiki에 한참 전에 정리를 해놓은 내용들이지만, 추억 회상과 복습의 차원에서 제대로 된 글로 남기고 싶은 마음이 크다. 그럼 본격적으로 시작!


📌 프로젝트 요약

  • 진행 인원
    : 4명

  • 진행 기간
    : 22.07.30 ~ 22.08.05(약 1주)

  • 기획 의도
    : 한국 배스킨라빈스 웹 사이트의 메인 페이지, 아이스크림 메뉴 페이지 개선

  • 기술 스택


📑 기획 단계

 먼저 기획 단계에서는 전체적인 프로젝트의 방향성과 작업 일정, 문제점 분석과 개선 방안, 협업 방식과 컨벤션에 대해 논의했다. 이를 요약하면 다음과 같다.

  • 방향성
    : 기존 배스킨라빈스 웹 사이트의 클론 코딩
    : 추가적으로 성능 최적화 및 UX를 개선할 수 있는 UI 수정

  • 작업 일정
    : 7/30 ~ 7/31까지 디자인 시안 제작 및 마크업, 코드 리뷰
    : 8/1 ~ 8/3까지 스타일링 작업, 간단한 JS 기능 구현
    : 8/3까지 대략적인 작업 완료 후 8/4부터는 발표 준비

  • 문제점 분석 & 개선 방안
  1. 렌더링 시간 이슈
    : 처음 사이트 접속 시 아이스크림 메뉴 페이지 렌더링 시간이 약 40초 정도로 굉장히 많이 소요됨
    👉 picture 태그 사용하여 다양한 포맷과 사이즈의 이미지 제공
    👉 Image Sprite 방식 이용하여 이미지 소스 다운로드 속도 개선
    👉 Lazy Loading 기법을 활용하여 필요한 이미지만 먼저 보일 수 있도록 개선
    👉 렌더링 시간에 대한 UX 개선 위해 Skeleton UI와 로딩 표시기 제공

  2. 접근성 이슈
    : 헤딩 태그의 오용
    👉 시맨틱한 마크업 구조 적용
    : 키보드 포커스 위치 식별 불가
    👉 식별이 용이한 키보드 포커스 제공

  3. 보안 이슈
    : 보안에 취약한 http 프로토콜 사용
    👉 암호화가 추가된 https 프로토콜로 변경하여 배포

  4. 기능 추가 관련
    : 카테고리별 메뉴 추천 기능의 필요성
    👉 작업 일정의 여유가 있다면 UI 및 기능 구현 시도

  • 협업 방식과 컨벤션
    : Git & GitHub
    : commit, branch, PR 컨벤션 논의
    : merge 전 최소 2명의 코드 리뷰가 필요하다는 규칙 수립

🎨 디자인 단계

 기획 회의를 마치고 별다른 디자인 시안 없이 바로 마크업과 스타일링에 착수할 수도 있었지만, UX를 고려하여 UI를 개선할 계획이 있었기 때문에 최대한 유사하게 Figma로 디자인 시안을 제작하기로 했다. 결과적으로는 UI 개선도 개선이지만, 디자인 시안 덕분에 작업하는 팀원들 입장에서 편하다는 이야기를 들어서 뿌듯했다. 실제로 개발에 대한 지식이 있는 상태에서 디자인 시안을 제작하려고 하니 중요하게 생각해야 할 점이 무엇인지 더 체감할 수 있었다.

 위의 사진처럼 지금 보면 디자인 시스템이라고 할 수도 없는 초단순한 컬러 차트도 제작했었다. 그 당시에는 나름 뿌듯했지만 글을 작성하는 현재로서는 부끄러울 따름이다. 하지만 시간이 촉박했으니 뭐.. 나름 최선의 선택이었다고 변명하고 싶다 ㅎㅎ;

 짜잔! 이렇게 몇 시간만에 휘뚜루마뚜루 디자인 시안이 탄생하게 되었다. 위의 시안이 데스크탑 버전 UI, 아래의 시안이 모바일 버전 UI다. 구체적으로 기존에 비해 어떤 부분이 변경되었는지는 프로젝트 결과 부분에서 다루고자 한다.


🔨 개발 단계

 개발은 나를 포함한 총 4명의 팀원이 각각 분담하여 마크업, 스타일링, JS 기능을 구현했다. 구체적으로는 메인 페이지의 캐러셀, 메인 페이지의 전체 레이아웃, 메뉴 페이지, 헤더와 푸터로 구분하여 작업했다.

 개발 단계에서 가장 중요하게 생각한 부분은 아무래도 시맨틱한 마크업과 이미지 최적화다. 시맨틱하게 마크업을 작성하기 위해 적절한 헤딩 태그와 상황에 맞는 시맨틱 태그를 사용하고자 했다. 또한 이미지 최적화를 위해 전반적인 이미지 사이즈를 축소하고 포맷을 webp로 변경했다. 가장 핵심이 되는 부분은 Image Sprite 방식을 이용하여 이미지를 렌더링하는 것이다. 렌더링 이슈의 개선 방안으로 논의했던 다양한 방법 중에 Image Sprite 방식을 선정한 이유는 이번 프로젝트의 진행 기간이 1주밖에 되지 않을 뿐더러, JS를 거의 사용하지 않았기 때문이다. 순수 HTML과 CSS만으로 Lazy Loading 기법이나 Skeleton UI, 로딩 표시기를 구현하는 것은 불가능에 가깝다고 판단했기 때문에 Image Sprite 방식을 사용하여 렌더링 이슈를 개선하고자 했다.

 여기서 잠깐 Image Sprite에 대해 설명하자면, 쉽게 말해 사용할 이미지들을 하나의 이미지로 합쳐놓고 CSS로 이미지의 position을 조절하여 적용하는 방식이다. 여러 개의 이미지를 사용될 때마다 렌더링하면 깜빡이는 현상이나 렌더링 시간이 오래 걸리는 문제가 발생할 수 있지만, 하나의 이미지로 합쳐놓으면 웹 페이지가 처음 로딩될 때 이미지를 한 번만 다운로드하기 때문에 이러한 문제를 개선할 수 있다. 그 외에 이미지의 모듈화가 가능하다는 장점도 있지만, 이번 프로젝트에서는 렌더링 이슈를 개선하는 데 초점을 맞춰 Image Sprite 방식을 채택했다.


🎉 프로젝트 결과

 그렇게 치열했던 일주일이 지나고, 우리 팀은 나름 성공적인 결과를 도출할 수 있었다. 지금부터 그 결과를 이미지 최적화, 접근성, UX와 UI, 최종적인 Lighthouse 성능 지표의 관점에서 각각 소개해보겠다.

🔶 이미지 최적화

 이것이 바로 직접 제작한 Image Sprite 방식의 이미지이다. Image Sprite 방식을 사용한 결과 수치적으로는 다음과 같은 쾌거를 이룰 수 있었다.


🔶 접근성

🔹 헤딩 태그의 오용

 HeadingsMap이라는 크롬 확장 프로그램을 이용하여 기존 웹 사이트의 헤딩 태그를 보면 위와 같다. 헤딩 태그가 1 > 3 > 4로 순차적인 구조가 아닐 뿐더러 각각의 헤딩 태그가 무엇을 의미하는지 정확히 알 수 없다. 웹 페이지의 목차를 담당하는 헤딩 태그는 자고로 구조적으로 논리적이어야 한다. 책을 펼쳤을 때 목차가 제대로 구성되어 있지 않거나 잘못되었다면 독자 입장에서 굉장한 불편함을 느끼게 될 것이다. 웹 페이지도 마찬가지다. 헤딩 태그를 적재적소에 사용해야 사용자 입장에서 긍정적인 UX를 경험하기 마련이다.

 따라서 우리는 위와 같이 헤딩 태그를 개선했다. 기존 헤딩 태그보다 훨씬 가독성이 좋고, 각각의 헤딩 태그가 담당하는 내용과 하위 섹션을 인식하기 용이하다.

🔹 키보드 포커스 이슈

 다음으로 키보드 포커스 관련 이슈를 해결하고자 했다. 위의 이미지에서 키보드 포커스를 찾아볼 수 있는가? 전혀 아니다. 정지된 이미지라고 생각할 수 있지만, 이미지의 우측 하단 확대한 부분을 보면 아닌 것을 알 수 있다. 즉 영상을 녹화하는 동안 계속 키보드의 탭 키를 눌러서 키보드 포커스가 정상적으로 이동은 하지만, 사용자에게 가시적으로 키보드 포커스가 전혀 보이지 않는 실정이다. 극단적으로 말하면 마우스를 이용할 수 없는 환경의 사용자는 키보드 포커스만으로 이 사이트를 이용할 수 없는 것이다.

 따라서 위와 같이 키보드 포커스 관련 이슈를 해결했다. 키를 누를 때마다 정상적으로 파란색 테두리의 키보드 포커스가 가시적으로 보이는 모습이다.


🔶 UX와 UI

 기획 회의를 하면서 논의했었던 UI 수정사항을 몇 군데 반영했는데, 이 부분을 기존과 비교하면서 소개해보겠다. 다만 기존 웹 사이트의 디자인은 22년 7월 경, 프로젝트를 진행했을 당시의 모습이라는 점을 참고해주셨으면 한다.

🔹 헤더와 내비게이션 바

 먼저 내비게이션 바의 각 메뉴 이름을 한국어로 바꾸기로 했다. 별 건 아니지만 '영양 성분 및 알레르기'만 한국어인 게 거슬려서 이왕이면 한국 웹 사이트니까 한국어로 통일하고 싶었다. 또한 Header의 전반적인 폰트 크기를 크게, 색을 더 뚜렷하게 수정하여 가독성을 개선하고자 했다.

🔹 캐러셀

 다음으로는 메인 페이지의 캐러셀 디자인을 수정했다. 위가 변경 전, 아래가 변경 후의 캐러셀 디자인이다. 사실 변경된 디자인이 썩 마음에 들진 않지만, 접근성을 최대한 준수하는 차원에서 아래와 같이 변경했다. 기존에서는 캐러셀을 사용자가 정지할 수 있는 버튼이 없었는데 이를 추가했고, 이전/다음 버튼이나 캐러셀 하단의 페이지네이션 버튼의 가시성도 향상시켰다.

🔹 메인 페이지 - 레이아웃

 또한 메인 페이지의 레이아웃 순서를 변경했는데, 기존에는 이벤트 > 메뉴 순서였다면, 메뉴 > 주문 순서로 변경했다. 후술하겠지만 일단 기존 이벤트 영역에 문제가 많다고 판단하여 아예 주문 섹션으로 변경했고, 이에 따라 메뉴 섹션의 우선순위가 더 높다고 판단하여 상단에 배치하게 되었다.

🔹 메인 페이지 - 이벤트 섹션

 개선점을 논의하면서 가장 큰 문제라고 생각했던 이벤트 섹션이다. 각 배너를 클릭하면 각각 관련된 주문 사이트로 이동할 것 같지만 전혀 아니다. 주문 방법을 안내하는 배스킨라빈스 웹 사이트 내의 공통된 페이지로 이동한다. 이는 배너 존재 의의에 의구심을 가지게 만드는 유저 시나리오라고 판단했다. 따라서 각각의 배너를 클릭했을 때 관련된 사이트로 이동하도록 수정했다. 이뿐만 아니라 섹션의 이름을 'BR EVENT'에서 각 배너와 관련 있는 '간편 주문'으로 변경했고, 가독성을 향상시켰다.

🔹 메뉴 페이지 - 가독성

 아이스크림 메뉴 페이지에서는 전체적으로 가독성을 향상시켰고, 기존에는 스크롤이 표시되지 않았던 부분을 스크롤이 표시되게끔 변경했다. 이는 사용자가 현재 어떤 콘텐츠를 보고 있고, 콘텐츠가 얼마나 남았는지 인식이 용이하게끔 하기 위함이다. 또한 데스크탑 버전에서는 1위부터 8위까지 한눈에 볼 수 있도록 변경했다.

 상술한 맥락과 동일하게 가독성을 향상시키기 위해 개별 아이스크림에 대한 정보를 간소화하고, 폰트 크기나 색을 수정했다.

🔹 반응형 디자인

 마지막으로 반응형 디자인에 대한 부분이다. 기존 웹 사이트는 적응형 디자인으로, 데스크탑과 모바일로 접속했을 때 각각 다른 URL의 웹 페이지를 렌더링하는 방식을 채택했다. 그래서인지 데스크탑에서 메뉴 페이지의 뷰포트를 축소했을 때 위와 같이 좀 어색하게 동작하는 모습을 볼 수 있다.

 따라서 기존의 어색했던 부분을 개선하여 데스크탑에서도 정상적으로 반응형 디자인이 적용되도록 했다.


🔶 Lighthouse 성능 지표

 드디어 하이라이트다! 지금까지 개선한 점들을 토대로 기존 웹 사이트와 개선한 웹 사이트의 Lighthouse 성능 지표를 비교해보았다.

 먼저 기존 웹 사이트의 Lighthouse 성능 지표는 위와 같다. 위에서부터 순서대로 메인 페이지와 메뉴 페이지이다. 자 그러면 개선된 결과는 과연?!

 짜잔! 마찬가지로 위에서부터 메인 페이지와 메뉴 페이지이다. 사실 배포 과정이나 서버 상태 등 아주 정확한 비교 환경이라고는 할 수 없지만, 기존에 비해 수치적으로도 확실히 개선된 부분이 보여서 뿌듯했다.


💕 좋았던 점

 사실 가장 좋았던 점은 아무래도 팀 프로젝트 경험을 할 수 있었다는 것이 아닐까 싶다. 먼저 팀 분위기가 말할 것도 없이 화목했다. 또한 다른 사람의 코드는 어떤지, 또 내 코드를 다른 사람이 봤을 때는 어떤지 서로 PR을 리뷰하는 과정을 통해 많이 배울 수 있었다. 그리고 짧은 기간이었지만 기획부터 디자인, 개발까지 포괄적으로 경험할 수 있었다는 점도 기억에 남는다. 개발자의 입장에서 좋은 기획과 좋은 디자인이 무엇인지 좀 더 생각해보게 된 것 같다. 이러한 경험이 쌓이고 쌓이면 타 부서 동료들과의 협업 과정이 원활해질 것이라 생각한다.

💔 아쉬운 점

 프로젝트 결과가 성공적이었기 때문에 크게 아쉬운 점은 없지만, 아무래도 기간이 짧아서 원래 구현하려고 했던 아이스크림 메뉴의 필터 기능을 구현하지 못한 것이 아쉬웠다. 또한 프로젝트의 기술 스택으로 TailwindCSS를 채택했는데, 간단한 스타일링은 편리했지만 배경 이미지나 가상 요소를 스타일링할 때는 불편함이 너무 컸다. 특히 Image Sprite 방식을 채택하면서 background 관련 스타일링을 구현해야 하는 일이 많았는데, 기존 CSS와는 다르게 구현하지 못하는 스타일링이 있어서 참 난감했다. 이러한 문제를 해결하려다 보니 @apply로 작성한 mixin 코드가 점점 길어지게 되었다. 어느 순간에는 배보다 배꼽이 더 큰 게 아닌가 하는 생각이 들었다 ㅎㅎ.. 앞으로 프로젝트를 진행할 때 기술 스택을 선정하는 과정에서 숲을 내다보는 안목이 필요함을 뼈저리게 느끼는 순간이었다.

profile
𝙸'𝚖 𝚊 𝚍𝚎𝚟𝚎𝚕𝚘𝚙𝚎𝚛 𝚝𝚛𝚢𝚒𝚗𝚐 𝚝𝚘 𝚜𝚝𝚞𝚍𝚢 𝚊𝚕𝚠𝚊𝚢𝚜. 🤔

0개의 댓글