제로베이스 프론트엔드 스쿨 10기 1차 HTML/CSS 과제 후기

조경석·2023년 1월 5일
0
post-thumbnail

썸네일 출처 : https://9gag.com/gag/adKwALB

제로베이스 프론트엔드 스쿨

웹 프론트엔드 개발 공부를 시작하고, 독학으로 가능한 범위 내에서 공부를 하다보니 학습 수준에 대한 증명이 될 수 있는 부트캠프 수료가 필요하다는 생각이 들었다.
수많은 부트캠프 중 개인 포트폴리오 작업과 병행할 수 있는 온라인 강의 위주인 제로베이스를 선택했고,
이하는 학습 커리큘럼의 첫번째 과제인 HTML/CSS 클론코딩 과제의 작업~제출까지의 기간동안 느낀 부분을 정리한 내용이다.

HTML/CSS를 공부하면서 느낀점

UI 디자이너로 재직하던 시절에도 가이드 작성을 위해 HTML과 CSS는 간단하게 배워두었고, 필요할때는 내가 직접 마크업과 스타일시트를 작성해 제공한 경험도 많아 새롭게 배우는 내용은 아니었다.
하지만 타인이 작성한 디자인 작업파일과 가이드, 요청문서를 보고 작업해본것은 이번 과제가 처음이었다.
전에도 팀원이 작업한 디자인 자료를 사용한적은 있지만, 가이드 작성시 주의할 부분이나 양식은 대부분 내가 정해둔 상황이라 내 방식과 크게 차이가 없어 새로울 것이 없었기 때문이다.

모든 디자인이 그렇지만, 구현에 대한 이해가 있어야 정확한 디자인이 나오고, 구현 담당자와의 의사소통 역시 불필요한 차질 없이 매끄럽게 이루어질 수 있다.
그런 부분에서 이번 과제 작업은 오히려 '디자이너라면 어떻게 가이드를 작성해야 개발자에게 혼란을 주지 않을 수 있는가'에 대해 다시 한번 고민하게 되는 기회였다.
다르게 말하면, 아래 항목들은 '프론트엔드 담당자가 디자이너에게 요구해야 하는 부분'이라고도 할 수 있겠다.

변수, 컴포넌트 이름짓기는 생각보다 귀찮은 일이다.

출처 : https://medium.com/swlh/naming-conventions-101-for-developers-8997bb96fd60

이게 무슨 뻔뻔한 소린가 싶을 수 있지만, 테스트용 코드에서 쓸데없이 변수 이름을 두고 몇 초간 멍때리거나, 괜히 번역기를 켜본 경험은 누구나 있을 것이다.
하물며 실무에서도 아무리 네이밍 컨벤션을 명확히 하고 클래스명 패턴을 정해놨더라도, 단위 컴포넌트 일부로서 가이드에 명시되지 않은 이 div의 이름은 무엇인가를 고민하는 일은 명백한 시간낭비다.

더 강하게 말하자면 이는 개발자가 할 일이 아니다.
사용자 경험을 고민하며 컴포넌트를 디자인하는 디자이너가 이름짓기에 더 유리하다는 인문학적인 설명도 가능하지만, 일단 디자이너는 요소를 배치하는 과정에서 각 영역, 각 도형의 역할을 충분히 고려하면서 작업한다.
게다가 미리 설계된 패턴에서 요소들을 가져와 배치하는 UI 디자인의 특성상, 단위 그룹의 역할(이름)을 고려하지 않고 작업한다는것은 오히려 불가능하다.
그렇기 때문에 디자이너가 단위 요소의 역할에 대해서는 더욱 심도깊은 고민과 결정을 거쳐 이름을 결정하게 되며, 개발자가 이에 대해서 추가적인 고민을 더할 필요가 없다는 뜻이다.
개발자는 디자이너가 작업해둔 그룹 계층에서 개별 단위 요소의 이름을 차용하고, 향후 구현 한계로 인한 디자인 사양 변경이 필요한 경우에도 해당 이름을 기준으로 소통하면 혼란 없이 소통이 가능하니 일석이조라고 할 수 있겠다.

만약 디자이너가 작업 파일에서 이름을 지정해두지 않아 가이드 상에서도 그룹 1, 사각형 1 등으로 나오거나, 동일한 단위 요소인데도 이름이 다르다면 그냥 그 디자이너가 대충 작업한게 맞다. 정확한 가이드 제공을 요청하자.

여백 개념은 디자이너의 직관을 따라라.

출처 : https://www.meme-arsenal.com/create/meme/5362275

padding과 margin의 구분은 디자인이나 CSS 작성을 해보면 관념적으로 깨우치게 된다고들 하지만, 역으로 개인적인 해석에 따라 달라질 수도 있는 주관적인 부분이기도 하다.

심지어 유명한 padding과 margin의 구분 뿐 아니라,
고정 너비의 가운데 정렬 or 내부 요소와 여백으로 인한 계산된(computed) 너비값,
동일 간격인데 일부 요소에 추가 여백 or 모든 요소의 간격이 별도로 설정,
기타등등 가이드상의 수치만으로는 판단이 불가능한 여백, 간격이 많다.

이에 대한 직관은 모든 디자이너가 이미 가지고 있으며, 모든 디자이너는 해당 패턴을 머리속에 정리한 채로 그 규칙을 따라 배치한다.
이 규칙 없이 배치된 요소는 애초에 미려할 수가 없고, 완성된 디자인이라고 말할 수 없는 예술작품에 불과하다.
짧게 말하면 디자이너에게 물어보는게 가장 정확하다는 뜻이다.

현재의 디자인 툴들은 도형 그룹 설정에서 여백, 간격, 정렬 설정을 제공하는 경우가 많으며, 이를 사용하면 가이드에도 적용될 수 있도록 기능을 제공하는 추세다.
아직은 기능에 한계가 많아 이 기능만으로 모든 디자인 사양을 제공할수는 없지만, 해당 기능으로 구현이 힘든 부분에만 추가적인 가이드를 더하면 그만이다.

HTML/CSS 공부하면서 어려웠던 개념과 이유

과제 요구사항에 맞춰 구현하면서 가장 고민되었던 개념은 역시 접근성이었다.
디자이너로서 가독성, 가시성에 대한 부분은 당연히 신경쓰는 부분이고, 차별 없는 사용자 경험을 위한 상호작용 요소의 배치는 항상 고민거리였다.
하지만 스크린리더로 대표되는 시각장애인을 위한 텍스트 접근성은 처음 구현해보는 부분이라, 생각보다 난해한 부분도 많고, 현실에서는 아직 멀었다 싶은 아쉬운 부분도 많았다.

'접근성을 고려하여'의 허무함

출처 : https://sheribyrnehaber.medium.com/accessibility-memes-2183f7fd24a5

공공기관, 기업, 개인을 막론하고 대부분의 웹 구현 요구사항에서 꼭 빠지지 않는 부분이 '접근성을 고려하여 구현하라'이다.
개인적인 경험으로는 공공기관에서 구현 요구사항에 대한 고민없이 기존 버전을 그대로 적용하여, GIS, 차트를 포함하는 시각화 서비스에 대한 시각장애인에 대한 접근성을 요구하는 경우도 있었다.
당연히 되면 좋겠지만, 캔버스 API를 사용하여 시각화를 구성하는 현재의 대부분의 차트 라이브러리는 이름과 역할만 알려줄 수 있는 초보적인 수준의 접근성 요소밖에 제공하지 않는다.

접근성의 개념을 정확히 이해하지 못한 요구사항들 뿐 아니라,
아직 접근성을 위한 요소의 구현방법 역시 한계가 많은 상황이다.

aria-disabled="true"를 적용하는 '스크린리더에서 읽어질 필요가 없는 장식, 보조용 요소' 처럼,
'스크린리더에서 보조적인 설명 문구가 필요한 구조'라는건 생각보다 많은 경우에 쓰인다.
하지만 정작, 그런 요소를 위한 표준 마크업이라는건 존재하지 않는다.

스크린리더에서만 읽을 수 있도록 '보이지 않는 텍스트'를 구현하려는 경우,
'보이지 않는 요소'를 읽지 않으려는 스크린리더의 특성상, 스타일 요소 중 '크기'에 관련된 요소 중 하나라도 0인 경우(width, font-size 등) 해당 요소는 아예 읽지 않는다.
그렇기 때문에 1px 사이즈의 컨테이너를 만들고 억지로 clip-path를 적용해 자르거나,
배경 이미지 등 컨테이너 영역을 채울 시각적 요소가 있다면 요소 안에 텍스트를 포함시키고 억지로 padding과 overflow:hidden을 조합해 밀어내는 등 보기에만 그럴듯한 방법을 사용한다.
당연히 스크린리더에서도 해당 요소를 억지로 숨겨둔 텍스트로 읽지만, 시각장애인으로서는 이게 대체 텍스트인지, 아님 영역 내에서 보이는 무언가를 읽은 것인지 구분할 방법은 없다.

기존의 aria-label 특성 역시 '텍스트 레이블이 보이지 않는' 텍스트 요소에만 사용해야 한다는 조건이 있어, 보조적이거나 추가적인 텍스트 용도로 사용하는것은 맞지 않다.
결국 접근성 구현 담당자는 편법을 사용하거나, 편법이 아닌 방법을 사용하기 위해 접근성 요소를 오용할 수밖에 없는 상황이니 아쉬울 따름이었다.

표준 없는 스크린리더

출처 : https://twitter.com/overflow_meme/status/1245944764421361665

이번 과제를 진행하면서 처음으로 스크린리더를 설치해보았고, 건방지겠지만 시각장애인들의 불편을 단편으로나마 경험해보는 기회가 된 것 같다.

테스트에 사용한건 응용 프로그램으로서 설치되는 NVDA와 크롬 공식 플러그인 Screen Reader 두가지였다.
운영체제 수준에서 제공하는 Windows Narrator가 있지만 비장애인이 테스트 용도로 사용하기에는 적합하지 못해 제외했다.

스크린리더를 선택하면서 가장 먼저 느꼈던 점은 "대중적이고 일반적인 스크린리더"라는게 존재하지 않는다는 것이었다.
사용자의 절대적 다수가 비장애인인 웹 검색 환경에서 시각장애인을 위한 도구를 찾는다는게 당연히 쉬운 일은 아니겠지만, 생각보다도 택도 없이 선택지가 적었다.
많지 않은 기여자들에 의해 구축되는 오픈 소스 프로젝트인 NVDA는 NVIDIA(NASDAQ: NVDA)에 밀려 검색되지도 않는 수준이고,
그럴싸한 유료 솔루션은 JAWS정도가 있으나 각 언어별 환경은 국가별 봉사단체에 의해 개선되는 상황이었다.

게다가 가장 놀라운 부분은 스크린리더별로 읽는 형식에 차이가 있었다.
크롬 개발자 도구의 Accessibility 툴팁은 그저 요소 텍스트나 aria-label을 그대로 보여줄 뿐, 실제로 스크린리더에서 읽는 내용과는 천차만별이었다.
Screen Reader 플러그인은 웹 브라우저 플러그인이어서인지 마크업 요소와 시멘틱 요소를 중점적으로 읽었고,
NVDA는 웹 요소, 응용 프로그램 요소 상관없이 공평하게 읽어주어야 하는 스크린리더로서 "모든" 읽을 수 있는 요소를 읽는 것으로 느껴졌다.
'스크린리더에서 읽을 수 있도록'이라는 말이 참 허탈할 수밖에 없었다.
도데체 '어떤' 스크린리더에서, '어떻게' 읽어주길 바란단 말인가.

NVDA, Screen Reader 둘 모두 당연히 개발자의 테스트 환경을 상정한 물건은 아니지만, 스크린리더 테스트 환경은 더더욱 끔찍했다.
둘 모두 스크린 읽어주기 일시정지 기능은 동작하지 않았고, 검색해보니 나와 똑같이 개발자로서 접근성 테스트 중 해당 증상을 질문한 포럼 글밖에 나오지 않았다.(게다가 고질적인 버그라고 한다. 참 답이 없다.)
결국 매번 스크린리더 자체를 활성화/비활성화하면서 테스트할수밖에 없었는데, 이러면 당연히 시각장애인을 위해 컨텐츠를 읽어줘야 하니 페이지(혹은 화면) 전체를 읽기 시작하고, 결국 시각에 의존해 읽기 원하는 요소를 포커스해야 한다.

작업할수록 이게 뭐하는 짓인가 싶고, 내가 시각장애인이라면 이 페이지를 사용할 수 있겠는가는 더더욱 확신이 사라지는 과정이었다.

제로베이스 온라인 강의 중 가장 도움이 되었던 강의와 이유

약간 과제 내용과는 동떨어지는 내용이지만, 현시점에서 가장 도움이 되는 커리큘럼은 매주 진행하는 CS퀴즈였다.
특별히 퀴즈 득점이 평가에 반영되는지는 확실하지 않지만,
프론트엔드 개발 공부에서는 무시되기 쉬운 CS지식에 대해 반강제적이라도 찾아볼 기회를 제공하는게 아주 좋은 의도라고 생각된다.
시험 내용 자체도 키워드 위주의 객관식으로,
시험을 진행하면서 지문과 선택지의 키워드를 검색해보는것만으로도 초급적이고 단편적인 지식이라도 습득할 수 있게 해주는것이 좋았다.
대부분 예전 자격증 시험때 공부했던 내용이라 기억에 남아있을거라고 생각했는데, 꽤 많은 부분을 새로 정리하게 되는 나를 발견하기도 했다.

나만의 공부팁

웹 프론트엔드 범위 중 HTML과 CSS에 대해서라면 확실히 마크업 달달이 외우기 수백번보다 한번 구현해보는게 백배 도움이 된다.
개발자 선배들이 가장 많이 하는 이야기가 '필요할때마다 문서를 읽어봐라'인데, 누구라도 구현과정을 경험해봤다면 백번이고 옳은 소리라고 생각할수밖에 없다.
그렇다고 수업을 듣는것도 중요한 것이, 방대한 양과 필수적인 요소와 보조적이고 실험적인 요소가 산재되어 있는 공식문서는 무턱대고 읽기에는 확실히 무리가 있다.
당연히 자주 사용되는 마크업이나 CSS요소에 대해서는 경험이 풍부한 사람의 정리와 조언이 필요하다.
단적으로 아무리 자바스크립트 반복문 수백번 써봐야 for밖에 모른다면 공부해봐야 소용이 없기 때문이다.
그렇기 때문에 일단은 교육자료를 속독하고,
자기가 구현하고 싶은 형태를 구현해본 뒤에,
이걸 교육자료에서 본거 같은데 아예 모른다면 다시 한번 교육자료를,
아는 내용인데 적용이 어렵다면 문서를 읽어보는 순서로 공부하는게 가장 확실한 습득방법이라고 생각한다.
실제로 내가 독학기간 중 사용했던 방법이고, 사용에 문제가 없는 개념이었더라도 문서를 읽어보면 새롭고 정확하게 깨우치게 되었다.

마무리

어째 프론트엔드라기보다는 디자이너가 신경써야 할 부분과 접근성 담당자가 고민할 내용이 주가 되었지만,
이번 과제를 진행하면서 가장 절절하게 느꼈고, 이론이 아닌 구현 수준의 HTML/CSS 작업에서 중요한 부분이라고 생각해 이렇게 정리하게 되었다.
결론적으로는 내가 실무자가 된다면, 이런 부분을 신경써야겠다 싶은 내용들이니 좋은 경험이 된 과제였다고 생각한다.
조금 아쉬웠던 부분은 과제 내용에 대한 질의응답이 불가능하다고 명시되어 있어, 구현 요구사항에 오해가 생길법한 부분이나 가이드가 잘못 작성된 부분에 대한 수정이나 의견을 요청할 수 없다는 것이었다.
향후 짧지 않은 기간동안 진행할 부트캠프의 첫 과제였으므로, 피드백이 어떻게 오게 될지 기대가 된다.

0개의 댓글