기존의 배달의 민족 앱 서비스가 피씨에서 사용할 수 없다는 면이 사용자 접근성에서 좋지 않다고 판단했고 이에 배달의 민족 웹 서비스를 만들고자 했다. 웹 접근성 준수가 주요 목적으로 HTML5, CSS3, Javascript를 사용하여 1주간의 프로젝트를 진행했다.
스타트업을 근무하면서 협업의 기회가 많이 없었기에 다인원의 협업이 긴장되었지만 개발에 대해 논의할 생각에 설레기도 했다. 5명의 사람들과 프로젝트 기획부터 개발까지 진행하면서 문제를 어떻게 상의하고 진행 상황을 파악할 수 있을까? 라는 생각이 들었다. 그 전까지는 혼자서만 레포지토리를 사용하다보니 협업할 때 깃의 사용법에 대해 모르는 점도 많았기 때문이다. 그래서 팀원들과 이야기한 결과 아래와 같은 규칙과 협업툴을 사용하기로 했다.
진행 상황을 파악할 수 있는 협업툴
위와 같은 규칙으로 1주동안 개발을 진행한 결과, 협업툴의 편리함과 프로젝트의 진행 상황들을 알 수 있다는 이점을 알았다. 아래처럼 보다시피 개개인의 파트 진행 상황을 파악할 수 있어 도움이 필요한 파트에 붙어서 같이 작업할 수 있었다. 원래 나의 파트는 쇼핑 라이브와 비디오 페이지였다. 주어진 페이지를 끝내고 시간안에 작업을 마무리하기 위해 남아있던 주문 상세 페이지를 구현하였다.
git convention의 중요성
git convention의 경우 적응하는데 시간이 걸렸었다. 항상 git comment를 페이지단위로 상세 설명으로만 입력을 하고 타입까지 붙여서 쓴 적은 없었기 때문이다. 그러다보니 왜 쓰는 거지?라는 의문이 들었고 프로젝트가 끝나고나서야 git convention의 중요성을 느꼈다. git commit을 살펴보는데 타입을 가장 먼저 명시를 해놔서 이 commit이 새로운 기능을 추가한 건지, 리팩토링이 된 것인지를 바로 알 수 있었고 찾고자 하는 부분도 해당 타입을 검색하여 금방 찾을 수 있었다.
모르면 바로 물어보고 같이 해결하기
댓글 mock data를 만들어서 실시간 채팅이 일어나는 애니메이션을 구현하려고 했다. 객체 데이터와 for ...of문을 사용하여 데이터를 하나씩 가져와서 출력하려 했다. 하지만 무엇이 문제였는지 10개의 데이터가 6개만 출력되는 오류가 발생했다. 맨 처음에는 for ...of문이 잘못된 줄 알았었다. 하지만 객체이기 때문에 for ...of문을 써야되는데 하고 고민하다가 결국 팀원에게 SOS를 요청했다. 팀원과 같이 객체 데이터부터 살펴보면서 논의하다가 mock data 객체 안에 같은 키를 여러번 선언한 게 문제였다. 이에 팀원과 이중 배열로 데이터 구조를 바꾸었고 이를 해결할 수 있었다. 혼자 해결할 때는 제대로 파악하기 어려웠는데 부족한 부분을 팀원이 메꾸어주고 내가 무엇을 모르고 어떤 부분을 알아가야하는지 이정표의 역할을 해주었다. 이게 바로 협업을 하는 이유가 아닐까 싶다.
웹 접근성
웹이나 앱을 사용하다보면 시각적인 부분이 강하기도 하고 마우스나 터치 패드로만 사용을 많이 하다보니 키보드를 이용하는 사용자에 한해서만 더 신경을 쓰면 된다고 생각했었다. 하지만 웹 접근성을 배우며 공부를 해보니 전자 누름식같은 입력 보조 장치, 스크린 리더기 등을 사용하여 컨텐츠를 제공받는 경우들이 있다는 것을 알게 되었다.
Markup
이전에는 UI에 따라 마크업 구조를 고민하면서 시멘틱 마크업을 준수하려고 했었다. 하지만 웹 접근성에 대해 알고 스크린 리더기를 통해 컨텐츠를 사용해보면서 하나의 문서처럼 사용자에게 어떤 컨텐츠이고 어떤 구성인지를 미리 알려줄 수 있는 태그와 마크업 구조를 적용해야한다는 것을 배웠다. 예를 들어 스크린 화면상 로그인, 회원가입이 있고 그 다음에 로고가 보여지는 서비스가 있다. 이때 로고보다 다른 컨텐츠를 먼저 마크업하게되면 스크린리더 사용자는 어떤 서비스의 로그인, 회원가입인지 모르게 될 것이다. 고로 이런 부분을 염두하여 모든 사용자들이 환경과 관계없이 같은 컨텐츠를 이용할 수 있는 서비스를 만들어야겠다.
WAI-ARIA
WAI-ARIA 처음 접한 것은 온라인 강의를 들으며 aria-hidden
속성이였다. 이 속성을 쓰면 시각적으로 내용이 보인다고 알려주었지만 사실 그때는 이게 왜 필요한 건지 와닿지 않았다. 하지만 프로젝트에 들어가고 스크린 리더기를 사용해 들으면서 그 필요성을 깨닫게 되었다. 디자인에 맞게 마크업을 하면 '|'과 같은 알 필요없는 정보들이 많았고 aria-hidden
을 설정하지 않으면 스크린 리더기는 이 의미없는 정보를 사용자에게 전달하고 있었던 것이다.
또한 개인 파트인 video관련 WAI-ARIA를 찾아보면서 관련된 속성들이 꽤 있었서 놀랬었다. 사실 비디오같은 부분은 모든 사용자에게 똑같이 제공하는 게 어려워서 넘어가는 부분일꺼라 생각했다. 나의 안일한 생각에 반성하며 웹 접근성을 준수하기 위해 생각의 관점을 바꿔서 접근하야되겠다라는 것을 느꼈다.
webp, webm
이미지나 비디오는 트래픽을 많이 잡아먹고 다운로드가 늦게 되면 UX적으로도 좋지 않기에 최적화를 해야했다. 이 해결책으로 구글에서 만든 이미지 및 미디어 포맷 webp, webm를 알게 되었고 이는 JPG와 PNG, GIF 등보다 적은 용량을 차지한다. 단점이라면 IE에서 지원을 하지 않는 다는 것이지만 IE가 서비스 지원이 종료됨에 따라 서비스에 적극적으로 적용할 필요가 있다고 생각했다.
1주 짧게 한 프로젝트였지만 배웠던 웹 접근성을 적용해보며 어떻게 활용되는지를 이해하게 된 프로젝트였다. 그리고 실무 경험이 있다는 게 프로젝트 기능을 어떻게 구현해야 한다던가 시간 안에 빠르게 구현할 수 있다는 것은 좋은 장점이 되었다. 하지만 늘상 개념이 부족하다고 생각했었는데 이번에 확실하게 느끼게 되었다. 이제 다가오는 자바스크립트 딥다이브 수업을 통해서 확실하게 개념을 이해하고 좋은 코드를 구현할 수 있는 개발자가 되도록 선구안을 가져야겠다. 부족한 부분을 부끄러워하지말고 해결하려고 노력하자!