웹 퍼블리셔는 무슨 일을 하는가? Part 1 - The Tracks of mulder21c

2021-05-09 22:10:12

2년 전에 썼던 "웹 퍼블리셔는 무슨 일을 하는가?" 포스트를 이제야 좀 더 구체화 해본다.

웹 페이지는 캔버스가 아니다.

가장 먼저 해야 할 이야기는 이것일듯 하다. 웹 퍼블리셔를 준비하고 있거나 웹 퍼블리셔로 일하고 있는 이들 중에서도 그렇고, 많은 웹 기획자들도 그렇고, 웹 디자이너들도 그렇고, 웹 페이지를 무슨 캔버스처럼 생각하는 경향이 매우 큰 듯하다.

결론을 먼저 말해두지만, 웹 페이지는 그림을 그리는 캔버스가 아니다.

HTML의 목적은 "구조화"와 "정보 전달"에 있다.

HTML is the language for describing the structure of Web pages.

What is HTML?W3C standards HTML & CSS

웹 페이지를 구성하는 가장 기본이 되는 언어는 HTML이다. 그리고 W3C에서는 HTML에 대해 웹 페이지의 구조를 기술하는 언어라고 설명하고 있다.

그리고 웹 페이지의 구조를 기술하는 이 HTML을 구성하는 각 요소(element)들은 특정한 의미를 전달한다.

HTML에서 요소(element), 속성(attribute), 속성 값(attribute value)은 정의 된 (이 명세에 의해) 특정한 의미(semantic)을 가집니다.

3.2.1. 의미론(semantic)HTML 5.1 Specification

다시 말해, 웹 페이지를 만들기 위해 태그를 작성하는 행위는 이 문서를 읽는 주체로 하여금 문서가 가진 정보가 무엇인지를 인식할 수 있도록 하기 위함이다.

즉,

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <title>문서 1</title>
</head>
<body>
  <h1>제목</h1>
  <p>문단 1</p>
  <img src="/images/rose.gif" alt="장미꽃" />
</body>
</html>

는

HTML 5 문서이고
문서의 주 언어는 한글이며
문서에 사용된 문자 인코딩은 UTF-8 이며
문서의 제목(title)은 "문서 1"이고
문서의 콘텐츠의 대제목은 "제목"이며
이후 "문단 1" 이라는 문단과 "장미꽃"이라는 이미지가 있다.

의 구조를 가지는 문서가 된다.

문서의 소비자는 정상 시력을 가진 사람만이 아니다.

HTML 문서는 눈이 아주 잘 보이는 사람 뿐 아니라, 앞을 보지 못하는 사람, 난독증을 앓고 있는 사람 등, 게다가 사람이 아닌 검색 엔진, 장애인들을 위한 보조기기들 같은 소프트웨어나 컴퓨터 역시도 해당 문서를 인식 할 수 있어야 한다.

때문에 '웹 접근성'이 자꾸 튀어나오는 것이고, 'SEO'가 자꾸 튀어 나오는 것이다.

많은 웹 기획자가 웹 브라우저에 표현되기 원하는 형상만을 생각한채 와이어 프레임을 '그려내고', 많은 웹 퍼블리셔들디 디자이너의 시안이 웹 브라우저에서 잘 시각화 되도록 태그를 '나열하는' 경우가 많다. (물론 그렇지 않은 기획자나 웹 퍼블리셔도 있겠지만, 상대적으로 봤을 때 그렇지 않은 경우가 허다하다.)

하지만, 실제로 HTML을 통해 만들어진 문서 구조를 인식하는 것은, 앞서 언급한 바와 같이 시각 매체를 통하지 않고 인식하는 경우 역시 많다.

문서 자체는 의미 전달이 목적이지 표현(presentation)이 목적이 아니다.

일부 웹 퍼블리셔들의 경우 이건 시안이 표 모양이니까 <table>로 마크업 하면 돼, 이건 한 줄에 나와야 하니까 <p>로 감싸면 돼 라는 식으로 마크업 하는 것들을 종종 보게 된다.

여기서 시각적 요인을 제외해 보면, 사실 시각적으로는 표 모양으로 그려졌지만 "표"가 아닌 콘텐츠인 경우가 있고, 한 줄을 차지한다 하더라도 단독으로 문단이 되지 않는 경우가 있다.

하지만 대다수의 이들이 전달해야 하는 의미와 상관 없이, 콘텐츠 정보가 아닌 자신의 눈을 통해 보여지는 시각적 정보를 전달하는 마크업을 만들어내는 것을 쉽게 목격하게 된다.

웹 기획자나 웹 디자이너 역시 마찬가지로, 와이어 프레임이나 시안을 그리는데 열중해 있고, 실제로 웹 문서를 통해 전달받아야 할 textual 정보에는 관심을 두지 않는 경우가 얼마나 많은지.

특히나 웹 기획자가 문서를 통해 전달되어야 할 textual 정보에 관심이 없다는 것은, 사실상 웹 기획을 하면서 웹을 이해하지 못하고 있다는 반증이나 다름없다고 본다. 마찬가지로, 웹 퍼블리셔가 자신이 작성하고 있는 웹 문서가 전달하는 textual 정보가 무엇인지조차 파악하지 못하거나 관심이 없다는 것도 웹을 이해하지 않은 채 웹 분야에서 일을 하고 있다라는 것이라 보아야 할것이다.

마크업을 잘하는 것은 글을 잘쓰는 것과 같다.

"마크업을 잘한다"라는 것은 빠른 시간 안에 시안과 동일한 모습을 웹 브라우저에 표현시키는 것이 아니다. "마크업을 잘한다"라는 것은 마크업의 목적에 부합하게 작성되었을 때 그 마크업을 두고 잘 마크업 되어 있다라고 할 수 있을 것이다.

즉, 문서의 구조를 잘 담아내고 콘텐츠의 의미를 올바르게 전달할 수 있도록 마크업되어 있는 문서를 두고 "마크업이 잘 되었다" 혹은 그 작업자를 두고 "마크업을 잘한다"라고 할 수 있다.

사실 마크업을 잘 하는 것은 글을 잘 쓰는 것과 같다.
글을 잘 쓴다라고 하는 것은 글 쓰는 목적이 분명하고, 단일한 주제와 명확한 결론이 있고, 개요가 잘 짜여져있고 바른 어휘, 바른 문장, 바른 단락으로 구성되어 있을 때, 글을 잘 쓴다라고 한다.

웹 문서라고 해서 다를 바가 없다.
웹 문서의 목적이 분명하고, 개요가 잘 짜여져 있고, 적절한 요소(element)로 구성되어 있으며, 마크업 자체가 정보를 제대로 전달하고 있어야 한다.
인쇄물과 웹 문서의 차이라면 단지 인쇄물은 종이에 발행된 것이고 웹 문서는 디지털에 발생된 것이라는 것과, 웹 문서는 사용자와의 인터랙션이 가능하고 좀 더 다양한 디지털 콘텐츠를 포함시킬 수 있다라는 것이다.

텍스트와 비텍스트 콘텐츠를 아름답게 보여지게 하는 것은 나중의 일이다.
인쇄물에서도 원고를 더 보기 아름답게 만드는 것은 "편집 디자인"의 몫이지 글 자체의 몫이 아니다.

웹 퍼블리셔는 문서를 해석할 줄 알아야 한다.

때문에 웹 퍼블리셔에게 필요한 역량 중 하나는 기획안과 시안으로부터 문서를 해석해 내는 일이다.
다시 말해, 웹 퍼블리셔는 기획안과 시안으로부터 문서의 구조, 개요를 잡아 낼 수 있어야 하고, 콘텐츠를 적절하게 (적당하게가 아니라 "적절"하게) 섹션을 나눌 수 있어야 하며, 콘텐츠의 각 구성 요소들의 용도를 파악할 수 있어야 한다.

물론, 모든 것을 다 혼자 파악할 수 없기 때문에 때로는 명확한 기획자의 의도를 알기 위해 기획자의 도움을 구해야 하기도 한다. (하지만 가끔은 기획자 스스로도 콘텐츠의 용도나 의도도 파악하지 못한 채 그냥 '그림'을 그리고 있는 경우도 많기는 하다... )

이것이 선행되어야, 짜임새 있는 웹 문서가 나오게 되고, 시맨틱한 마크업이 이루어지며, 웹 접근성과 검색엔진최적화가 이루어 질 수 있는 바탕이 된다.

HTML은 대강 눈에 잘 보이면 그만인 언어가 아니며, 마냥 쉬운 언어가 아니다.

대다수 HTML에 대해 진입 장벽이 낮다라고 이야기 한다. 맞는 말이다. HTML은 배우기 매우 쉽고 웹 웹 브라우저에 의해 즉각적으로 확인이 가능하니 HTML을 다루기 위한 진입은 다른 언어들에 비해 상당히 쉬운 편이다.

하지만, 진입 장벽이 낮다라고 해서 HTML로 무언가 만드는 것이 쉽다라는 것으로 오해해서는 안된다.
진입 장벽이 낮음을 다루기 쉽다라고 해서 이를 이용해 만드는 것도 쉽다라고 하는 것은 마치 치킨집을 차리는데 진입 장벽이 낮으니 치킨집을 차려서 수익을 창출해 내는 것도 쉽다라고 말하는 것과 별반 다를 바가 없다. (치킨을 맛있게 튀겨내는 것도 어렵지만, 수익을 내는 건 얼마나 더 어려운 것인지!)

웹 퍼블리셔는 단순히 tag를 나열하는 업무를 하는 것이 아니다.
앞서 말한 것들과 같이 문서의 구조를 잡고, 문서가 가진 정보들을 적절하게 분류하고 골격을 세우는 일이 웹 퍼블리셔가 해야 할 일들이다.

부디 제발 문서가 전달해야 하는 정보에는 관련짓지 않고 생각 없이 눈에 보이는 그림을 웹 브라우저에 그려내는 행위를 멈추어 주기를 바란다. 마크업은 그보다 더 깊이가 있고 논리적이며 복잡한 작업이다.

HTML을 다룬다와 html 파일을 작성한다는 다르다

아주 많은 웹 퍼블리셔들이 오인하는 것 중 하나가 HTML을 다루는 것을 html 파일 작성으로만 생각한다는 거다.

아니, 웹 퍼블리셔가 HTML을 다룬다는 것은 html 파일을 다룬다는 것이 아니라 최종 렌더링 된 결과 HTML — 즉 어떤 과정을 거쳐 최종적으로 사용자의 브라우저에 노출되는 HTML을 책임 진다는 거다. 그리고 너무 당연하게 이 어떤 처리를 거치기 전의 파일 확장자가 html이라는 보장은 어디에도 없다.

나는 십여년전부터 웹 퍼블리셔가 간단한 수준의 서버 언어 — 텍스트 출력, 단순한 분기문, 반복문 정도는 읽거나 사용할 수 있어야 한다고 이야기해왔고, 그 때마다 돌아오는 반응은 개발자가 하는 걸 왜 퍼블리셔가 해야 하느냐라는 거였다.

과거 CSS Tricks의 필진인 Chris Coyier는 웹 퍼블리셔에 해당하는 해외 포지션의 설명에 light backend를 포함시키고 있었다 (현재도 front-end에 여전히 light backend가 포함되어 있다). 개인적으로 light backend를 포함시켜둔 이유를 바로 위에서 언급한 그 이유 때문이라고 생각한다.

최근에는 종종 템플릿 엔진(pug, ejs 등)을 이용해서 HTML을 렌더링하는 개발 환경을 가진 경우조차도 (개발 환경 설정을 해야 하는 것이니) 개발자가 해야 하는 것이지 퍼블리셔가 왜 이걸 다루어야 하느냐고 반문하는 경우도 있었다.

내가 처음 HTML을 만져본게 1998년이었고, 업으로 삼기 시작한게 2010년이었는데, 그 이후로 십여년이 지나는 동안 기술은 많은 부분 발전하고 변경되어 왔는데, 유독 웹 퍼블리셔들 만큼은 십여년 전의 기술에서 단 한 발자국도 떠나지 않으려는 듯 하다.

십여년 전에야 디자이너에서 넘어온 퍼블리셔가 많았기 때문에 HTML 파일을 생성하고 다음 차례의 서버 사이드 개발자에게 전달하는 형태가 어쩌면 불가피한 상황이었을 수 있으나, 이 기조를 지금까지 가지고 오는 것에는 분명히 문제가 있다.

제발 서버 언어 붙으면 그건 이제 (서버 사이드) 개발자가 건드려야죠, Node 환경이기만 하면 그건 프론트엔드 개발자가 건드려야죠 하는 식으로 나는 "HTML 파일만" 건드립니다라는 되도 않는 고집은 좀 버렸으면 좋겠다.
내부 개발 환경이 handlbars·pug 등의 템플릿 엔진으로 되어 있으면 이를 통해 HTML을 책임 질 수 있어야 하는 것이고, 필요하다면 PHP, JSP 등의 코드가 얹어져 있는 코드도 일부 수준에서는 수정 하여 처리 후 최종 렌더링 될 HTML을 책임질 수 있어야 하는 거다.

tags:

웹 퍼블리셔 HTML markup