본문 바로가기

UX ⁄ UI

UI 특강 1탄 - 궁금한 점 답변드립니다.

이 글은 박재선 님의 2021년 7월 13일 <UI 개발 특강> 강의를 요약한 글입니다.
강의는 사전 질문에 대해 답변해주시는 식으로 진행되었습니다.

 

 

 

UI 개발자는 무슨 일을 하나요?

프로젝트는 기획, 디자인, 개발 (UI / FE / BE) 로 나눌 수 있다. 이 중 UI 개발자는 기획 단계를 거쳐 디자인 결과물을 토대로 화면에 보이는 콘텐츠의 대부분을 담당한다. 

한 마디로 말하자면, 기획 및 디자인 산출물을 받아서 페이지의 '뼈대를 만드는' 역할이다.

UI 개발자는 기획문서를 보지 않는다는 오해가 있는데, 무조건 디자인 가이드만 보는 것이 아니라 상황에 따라 기획 문서도 본다. 디자인 작업에 직접적인 관여는 하지 않는다.

클릭했을 때 어떤 이벤트를 일으키는 비교적 단순한 이벤트부터, Parallax 같은 원페이지를 구현도 하는 일에 포함된다. 요즘에는 자동화 툴이 많이 발달이 되어 있어서 UI 에도 자동화 도구를 많이 사용한다. Gulp Grunt 등 UI 작업 편의를 위한 Task 구현도 한다. 화면에 드러나지 않지만 모든 사람들에게 동일한 접근성을 제공할 수 있도록 하는 작업도 한다.

참고로, 'UI 개발자', '퍼블리셔', '마크업 디벨로퍼'는 각자 속해있는 집단에서 불리는 명칭으로 이름만 다를 뿐, 하는 일은 거의 같다고 볼 수 있다. 웹을 출판한다는 의미의 '퍼블리셔'는 '코더'라는 명칭보다 더 전문성을 담는 용어로 사용하게 되었다.

💡 관련 글: 프론트엔드 엔지니어와 웹 퍼블리셔 - 신현석 님

 

 

웹 표준은 왜 지켜야 하나요?

웹 표준이란 말 그대로 웹에서 통용되는 표준 기술 규격이다. 웹 표준을 지켜야 하는 이유는 안정적인 성능과 개발 효율성을 증대하기 위함이다.

과거 IE와 넷스케이프가 존재했던 시절, 개발자들에게 암흑기였다는 풍문도 있다. 표준화된 규격으로 어느 브라우저에서나 동일한 콘텐츠를 제공할 수 있다. 실제로 완전히 같은 화면이 렌더 되지는 않지만 어느 정도의 뼈대는 표준화를 통해 동일한 화면을 보여줄 수 있다. W3C에서 웹 접근성에 대한 표준화 지침을 제정하여 정상적인 웹을 이용하는 데에 있어 어려움을 겪는 분들에게도 도움을 줄 수 있다.

모든 태그들은 자신만의 의미가 있다. 의미에 맞는 태그를 사용해야 한다. 예를 들어, 모든 태그를 div 태그로 작성하거나, span 태그에 전부 onclick을 남발하거나 클릭한다고 해서 모두 a 태그로 만드는 식으로 작업하는 것은 지양해야 한다.

anchor : 링크(페이지를 이동하거나 같은 페이지 내 아이디 값을 가진 해당 영역으로 이동)
button : 단순 이벤트 처리(클릭하면 레이어 팝업이 뜨는)

 

 

접근성은 왜 지켜야 하나요?

상품 상세 이미지를 텍스트 없이 이미지로만 올려놓는다면 시각장애인이 서비스 이용에 큰 불편함을 느낄 수 있다. 우리 사회는 장애인에 대한 인식과 배려가 부족하고, 우리가 만드는 웹 서비스도 그러할 수 있다. 시각장애 외에도 청각장애, 손 운동장애, 중증 장애를 가지고 계신 분들이 불편함 없이 서비스를 사용하실 수 있도록 고려해야 한다.

기사 - 국내 쇼핑몰, 상품에 대한 음성 설명 미지원

💡 관련기사: "장애인은 대충 사라?"… 소비자 권리마저 사각지대 (2021.04.20/뉴스데스크/MBC)

 

이미지를 넣을 때는 풀어서 어떤 이미지인지 파악할 수 있도록 값을 넣어주는 것이 중요하다. focus 이동을 표시하는 효과를 완전히 제거하는 방식도 지양해야 한다. 텍스트와 콘텐츠의 명도 대비는 4.5대 1 이상이어야 한다. 스크린 리더는 보통 NVDA 를사용한다.

<!-- 잘못된 예 -->

<img alt=""> <!-- alt 값이 없음 -->
<img alt="이미지"> <!-- 스크린 리더가 '이미지 이미지'라고 읽어 중복된 정보 제공 -->
<img alt=""> <!-- 해당 이미지가 어떠한 형태, 상태인지에 대한 설명이 없음 -->

<!-- 올바른 예 -->
<img alt="담배를 피우는 브라운">

 

그렇다고 웹 접근성이 장애인 분들의 경우만 고려한 개념은 아니다. 접근성의 범위는 사실 매우 넓다. 접근성은 '모두'를 위한 것이다. 모두가 서비스를 사용하는데 불편함을 느끼지 않도록 서비스를 제공하는 것이 중요하다. 기획, 디자인, 개발 모든 직군 모두 접근성을 제공하는데 노력해야 한다. 

💡 참고자료: 접근성 지원 != 시각장애인 대응,   접근성 지원, 개발자의 빠른 성장을 도와줍니다.

 

 

반응형 웹 구현은 어떻게 하나요?

반응형 웹 구현은 작업자들마다 스타일이 다른다. 정형화된 방식은 없다. 

디자인 가이드가 나오면 UI 설계(마크업)를 하고 CSS 적용(PC, Mobile, Tablet 등 나눠서) 한 후, 화면을 확인하고 수정이 필요한 부분이나 불필요한 중복 스타일 선언한 부분 있나 확인하는 식으로 진행하는 방법이 있다.

'Mobile First' 는 꽤 오래전에 나온 개념이다. 말 그대로 모바일 환경을 먼저 작업을 하고 태블릿 화면으로 확장한 후, PC 화면까지 확장하는 형태로 작업한다. UI 개발자들은 실제로 해본 적이 많지는 않다. 오히려 PC 환경을 우선적으로 작업하는 방식이 일반적이다. PC 환경에서는 기본적으로 많은 정보를 담고 있기 때문에 초반부터 마크업 설계에 신경을 써야 한다.

디바이스 별 breakpoint

 

 

rem / em 은 언제 사용하나요?

우선 CSS에는 px, em, vw, vh, % 등의 여러 단위가 있다.

일반적으로 고정된 절대적인 단위의 px을 가장 많이 사용한다. 디자인 가이드를 모두 px로 받는다. 제플린 디자인 가이드에도 다른 단위를 써서 가이드를 받은 적은 없다. 국외의 부트스트랩이나 워드프레스에서는 em, rem을 사용한다. 

em 은상위 요소의 값을 바꿔주면 하위 요소의 사이즈를 별도로 지정해줄 필요가 없어 편하게 사용할 수 있다.

/* em: 부모 요소의 값을 상속받음 */

.parent { font-size: 10px; }
.parent .child { font-size: 1em; } // 10px;
.parent .child { font-size: 1.2em; } // 12px;

/* rem: <html>의 값을 상속받음 */

html { font-size: 10px; }
body { font-size: 20px; }
.elem { font-size: 1rem; } // 10px;

💡 참고자료: em? rem?

 

 

확장 가능한 마크업은 어떻게 만드나요?

확장 가능하고 재사용성이 높은 마크업을 만들기 위해서는 별도 산출물 관리를 위한 페이지를 제작하여 관리한다. 다른 개발자분들이 세팅해놓은 Storybook 환경에 UI 개발자가 컴포넌트를 등록하는 방식으로도 작업한다.

컴포넌트 재활용의 좋은 점은 필요할 때마다 컴포넌트를 붙이는 식으로 공통화해서 효율성을 높일 수 있다는 것이다. 하지만 공통화를 시켜둔 탓에 다른 곳에서 해당 컴포넌트를 붙여쓰기 위해 스타일을 계속 재선언해야할 수 있고, 그렇게 되면 레거시 코드가 늘어나게 된다. 담당자가 바뀌거나 해당 프로젝트에 익숙하지 않은 경우, 공통화된 부분으로 인해 의도하지 않은 사이드 이펙트가 발생할 수도 있다.

 

 

UI 개발자 간에는 어떻게 협업하나요?

같이 일하는 UI 개발자와 서로 쉽게 이해할 수 있는 규칙을 정하고 문서화하는 것이 중요하다. 서로 간의 규칙을 사전에 정한다. 예를 들어 마크업 방식을 구조를 간결하게 작성할 것인지, 여러 케이스에 대응하기 위해 방어적으로 작성할 것인지 방향을 정한다. 클래스 네이밍 또한 클래스 이름만으로도 어떠한 형태인지 쉽게 파악할 수 있도록 규칙을 정한다. CSS 작성 시 lint로 통일된 규칙을 적용하여 효율성을 높이기도 한다. (SASS lint)

유지보수를 고려해서 만드는 것도 중요하다. 이러한 규칙이 정해져 있지 않은 상황에서 유지보수를 하게 되면 사이드이펙트가 발생하고 업무 효율이 저하된다. 

UI 개발에 정답이 없기 때문에 코드리뷰하는 것이 어렵다. 서로에게 상처뿐인 리뷰는 자제하고 상대방의 의견을 존중하는 코드리뷰 문화를 만드는 것이 좋다.

 

꼼꼼한 Q&A 답변까지 감사합니다 :)