HTML

글자만 담긴 파일을 주고받던 시절에는 그 안에서 무엇이 제목이고 무엇이 목록인지 아는 쪽이 사람뿐이었습니다. 사람은 줄 간격을 보고 짐작하지만 기계는 짐작하지 못합니다. 그래서 파일을 다른 기계로 옮기면 모양이 흐트러졌고, 서식 규칙이 제각각이라 같은 문서가 열 곳에서 열 가지로 보였습니다.

더 불편한 것은 문서끼리 잇는 방법이 없다는 점이었습니다. 어떤 글이 다른 글을 가리키려면 "자료실 문서 번호 147 을 참고하라" 고 적는 수밖에 없었고, 읽는 쪽은 일어나 그 번호를 찾아와야 했습니다. 가리키는 곳이 열 군데면 열 번을 찾아다녔습니다.

HTML 은 이 둘을 한꺼번에 풀려고 만든 표기법입니다. 문서 안의 덩어리마다 이것이 제목이라거나 이것이 문단이라는 표시를 붙여 기계가 알아볼 수 있게 하고, 다른 문서를 가리키는 일도 같은 방식의 표시 하나로 처리해 누르면 바로 열리게 했습니다. 하이퍼텍스트라는 이름이 그 두 번째 성질에서 왔습니다.

HTML 은 화면에 놓인 것들이 각각 무엇인지를 기계가 알아보게 만드는 문제를 풀어 줍니다. 방법은 내용을 태그로 감싸는 것 하나입니다. <h1>가격 정책</h1> 처럼 여는 표시와 닫는 표시 사이에 글을 넣으면 그 글자가 가장 큰 제목이라는 뜻이 됩니다.

이렇게 표시해 두면 세 가지가 따라옵니다.

1. 브라우저가 기본 동작을 대신 해 줍니다. 누르는 자리를 <button> 으로 적어 두면 키보드 탭 키로 그 자리까지 이동하고 엔터로 눌립니다. 같은 모양을 뜻 없는 상자로 만들어 놓고 눌리는 동작만 따로 붙이면 이 전부를 손으로 짜야 합니다.
2. 화면을 보지 않는 독자가 읽어 갑니다. 시각장애인이 쓰는 스크린 리더는 태그를 따라 "제목 1, 가격 정책" 하고 읽어 주고, 제목만 건너뛰며 훑는 기능도 태그를 근거로 움직입니다. 장애나 상황에 관계없이 쓸 수 있게 만드는 접근성 작업이 여기서 시작합니다. 검색 결과 위쪽에 놓이도록 사이트를 다듬는 검색 엔진 최적화 도 같은 표시를 재료로 씁니다.
3. 문서끼리 이어집니다. <a href="/pricing"> 은 누르면 저 주소로 간다는 표시이고, 남의 사이트든 같은 사이트의 다른 장이든 똑같이 가리킵니다.

그래서 HTML 이 맡는 것은 모양이 아니라 정체입니다. 글자를 크고 굵게 만드는 일은 화면의 표현을 지정하는 스타일 언어인 CSS 가 하고, 눌렀을 때 무엇이 열리게 하는 일은 브라우저에서 동작을 만드는 언어인 자바스크립트 가 합니다. 셋이 같은 화면에 함께 올라가되 맡는 질문이 다릅니다. 무엇이 있는가, 어떻게 보이는가, 무엇을 하는가입니다.

웹 화면을 만드는 데 HTML 을 빼고 가는 길이 몇 가지 있지만, 어느 쪽이든 HTML 이 그냥 주던 것을 하나씩 내놓게 됩니다.

첫째는 화면을 그림처럼 직접 그리는 방식입니다. 브라우저에는 빈 칸 하나를 받아 선과 글자를 픽셀 단위로 찍는 방법이 있고, 디자인 도구나 지도처럼 자유롭게 그려야 하는 제품이 이 길을 씁니다. 대신 그렇게 찍은 글자는 복사가 되지 않고 스크린 리더가 읽지 못하며 검색에도 걸리지 않습니다. 화면 위의 모든 것이 기계에게는 색 덩어리이기 때문입니다.

둘째는 설치하는 앱으로 가는 방식입니다. iOS 와 안드로이드는 각자의 화면 정의 방식이 있어 HTML 없이 앱을 만듭니다. 그 대신 주소 하나로 아무에게나 열어 보이는 일이 안 되고, 고칠 때마다 심사를 거치며, 같은 화면을 두 벌 만들게 됩니다.

셋째는 더 간단한 표기법을 쓰는 방식입니다. 기호 몇 개로 제목과 목록을 적는 마크다운이 대표적입니다. 쓰기는 편하지만 표현할 수 있는 종류가 적고, 브라우저가 마크다운을 직접 읽지 못해 화면에 띄우려면 결국 HTML 로 바꿔 줘야 합니다.

요즘 프론트엔드 코드에서 태그를 직접 적는 일이 줄어든 것을 네 번째 대안으로 오해하기 쉽습니다. 화면 조각을 만드는 함수를 불러 쓰면 손으로 적은 태그가 한 줄도 안 보이지만, 브라우저에 도착하는 것은 여전히 HTML 입니다. 적는 자리가 옮겨졌을 뿐입니다.

"이거 div 말고 button 태그로 바꿔 주세요. 키보드로 눌리지를 않아요."

모양만 버튼이고 뜻 없는 상자로 만들어 둬서 브라우저가 버튼 대접을 안 해 준다는 지적입니다.

"마크업이 전부 div 라 스크린 리더가 제목을 하나도 못 짚어요."

화면은 멀쩡해 보이는데 구조 표시가 빠져 있어 눈으로 보지 않는 사람에게는 줄글 한 덩어리로 들린다는 뜻입니다.

"검색이 이 페이지를 못 줍는 건 본문이 HTML 에 없어서예요."

첫 응답에는 빈 껍데기만 오고 내용을 나중에 채우는 구조라, 그때 읽고 가는 검색 로봇 눈에는 빈 페이지로 보인다는 말입니다.

페이지덱에서도 이 말이 돌아온 적이 있습니다. 민서가 요금제 화면을 접근성 기준으로 훑다가 플랜 선택 버튼 네 개가 전부 상자로 만들어져 있는 것을 찾아냅니다. 마우스로는 문제가 없어 여섯 달 동안 아무도 몰랐고, 키보드만 쓰는 고객이 문의를 넣고서야 드러났습니다. 태오가 태그를 바꾸자 따로 짜 뒀던 눌림 처리 코드가 필요 없어졌습니다.

같은 주에 현우가 새 소개 페이지는 왜 검색에 안 잡히냐고 들고 온 것도 같은 자리였습니다. 제목이 제목 태그가 아니라 큰 글자로만 되어 있어 로봇이 주제를 짚을 근거가 없었습니다. 두 사람이 고친 것은 보이는 모양이 아니라 그 아래에 적힌 표시뿐입니다.

HTML 을 프로그래밍 언어로 아는 경우가 가장 많습니다. 꺾쇠와 영어 단어가 줄줄이 붙은 생김새가 코드와 비슷하고 개발자가 다루니 자연스러운 오해입니다. 하지만 HTML 에는 조건을 따지거나 같은 일을 반복하거나 값을 계산하는 문법이 없습니다. 무엇이 어디에 있다고 적는 일만 합니다. 그래서 학습 계획을 짜며 HTML 을 뗐으니 절반은 왔다고 여겼다가, 실제 난도가 나오는 자바스크립트 앞에서 멈추는 일이 생깁니다.

쉬우니 대충 적어도 된다는 생각도 자주 봅니다. 문법이 관대해서 닫는 표시를 빠뜨려도 화면은 그럭저럭 그려지니 틀렸다는 신호가 오지 않습니다. 브라우저가 눈감아 준 것을 스크린 리더와 검색 로봇은 눈감아 주지 않습니다. 드러나는 시점도 늦습니다. 출시 몇 달 뒤 접근성 점검을 받거나 검색 유입을 파고들 때 한꺼번에 나오고, 그때는 화면 수십 개를 되짚어야 합니다.