Structure Story for Makers
1960년대 MIT 지하에선 “각주 맞추다 밤 샌다”는 탄식이 새어 나왔고, IBM 연구소에서는 “제목 한 줄 바꾸면 보고서가 다 무너져요”라는 푸념이 쌓였습니다. RUNOFF와 GML은 그런 밤샘을 줄이기 위해 태그와 지시어를 붙잡았고, ISO 회의장에서는 “같은 구조인데 서로 못 읽는다”는 외침이 SGML을 낳았습니다.
CERN 연구원이 “연구 노트를 서로 바로 열고 싶다”며 HTML을 제안했고, 브라우저 엔지니어는 DOM과 HTML5로 “문서를 데이터처럼 다뤄보자”고 맞장구쳤습니다. 요즘 회의실에서는 디자인 시스템 팀이 “랜딩 페이지마다 구조와 랜드마크를 통일하자”며 커스텀 엘리먼트를 배포합니다.
연도 버튼을 눌러 “어떤 문제가 있었길래 이런 태그가 생겼을까?”를 들어보세요. 생소한 용어가 나오면 바로 옆에서 풀어 드리고, 사람들의 대화와 선택이 구조를 어떻게 바꿨는지 이야기로 안내합니다.
연도 버튼을 누르면 같은 화면에서 자세한 이야기를 읽을 수 있는 대화 상자가 열립니다.
1960s
“각주 맞추다 눈이 쑤신다”는 하소연이 나오자 연구원들은 메인프레임에게 제목과 문단을 맡기려 RUNOFF와 GML 같은 지시어를 붙였습니다.
1970s
학회와 정부 기관이 한자리에 모여 “이식 가능한 언어와 DTD가 필요하다”며 SGML 초안을 굽고 다듬었습니다.
1980s
SGML이 공식화되자 “이제 가벼운 응용을 만들어보자”는 말이 나왔고, CERN 연구원은 하이퍼텍스트 링크를 심은 HTML 메모를 돌렸습니다.
1990s
IETF와 W3C가 HTML 2.0과 DOM을 만들며 “브라우저마다 다르게 보이면 곤란해요”라는 요구를 코드와 API로 맞췄습니다.
2000s
브라우저 팀이 WHATWG를 세워 “폼과 인터랙션을 더하자”고 외쳤고, 커뮤니티는 마이크로포맷으로 일정과 연락처를 태그로 꺼냈습니다.
2010s
HTML5 권고안과 WAI-ARIA 패턴이 “랜드마크를 분명히, 역할을 정확히”라는 원칙을 정착시키며 구조와 접근성을 함께 묶었습니다.
2020s
“랜딩마다 다시 짜지 말자”는 요구에 커스텀 엘리먼트와 퍼블릭 가이드가 응답하며 구조 관리를 코드와 문서로 나눠 가졌습니다.
SGML, HTML, 접근성 패턴을 다룬 대표 레퍼런스를 모았습니다. 원문 사양을 넘나들며 구조의 변화를 추적해 보세요.
1967
대학원생 제리는 “각주를 손으로 맞추다 밤을 새요.”라며 프로그램으로 문서 구조를 제어하기 시작했습니다.
MIT 지하 기계실에서 제리는 펀치카드 더미를 안고 RUNOFF 프로그램을 돌렸습니다. 한 장씩 뽑힌 용지에는 제목과 본문이 정렬된 상태로 나타났고, 옆자리 연구원 수잔은 “명령 몇 줄만 적어도 각주 위치가 딱 맞네요!”라며 놀랐습니다.
팀은 문단, 제목, 목록을 제어하는 키워드를 메모에 적어 공유했습니다. 사용자가 `#CENTER` 같은 지시어를 쓰면 문단이 중앙에 맞춰지는 모습에, 지도교수는 “보고서가 훨씬 읽기 쉬워졌군요.”라고 감탄했습니다.
RUNOFF는 텍스트에 제어 명령을 삽입해 조판 결과를 자동으로 맞추는 초기 포맷터였습니다. 문단과 제목을 기호로 표현하면, 기계가 줄바꿈과 여백을 계산해 사람이 구조를 바르게 읽을 수 있다는 사실이 확인되었고, 이는 나중에 태그 기반 문서 언어가 탄생하는 배경이 되었습니다.
1969
IBM 연구진은 대형 문서를 반복 편집하느라 지친 동료들을 위해, 의미를 설명하는 태그 언어를 만들었습니다.
IBM 요크타운 연구소에서 찰스 골드파브와 동료들은 “제목을 바꾸면 페이지가 다 틀어져요.”라는 불만을 들었습니다. 세 사람은 회의실 칠판에 각종 문서 구조를 적고, `:<TITLE>`과 같은 태그를 만들어 실험했습니다.
시범 문서가 프린터에서 나오자 품질 관리 담당자는 “태그만 고치면 문서 전체가 다시 조판되네요.”라며 환호했습니다. GML 시연을 지켜본 고객사 담당자는 즉시 라이선스 도입을 검토했습니다.
GML은 Generalized Markup Language의 약자로, 문서를 구조적 요소로 나누자는 발상을 담았습니다. 내용과 표현을 분리하면 재사용과 자동 조판이 쉬워진다는 사실이 확인되었고, 이 아이디어는 이후 SGML 표준과 HTML 태그 체계의 직접적인 기반이 되었습니다.
1973
카네기멜런의 브라이언 리드가 “컴퓨터가 달라도 같은 보고서를 받으면 좋겠다.”며 이식 가능한 문서 언어를 만들었습니다.
연구실 학생들은 타 기종에서 문서를 열 때마다 글꼴이 무너지자 좌절했습니다. 리드는 `@Heading`, `@Begin(Body)` 같은 키워드를 정의해 기계에 구애받지 않는 문서 언어를 작성했고, 동료 마가렛은 다른 학교 메인프레임에서 문서를 받아 “같은 구조가 그대로 살아 있네요.”라며 고개를 끄덕였습니다.
Scribe는 빠르게 퍼져 나가 학회 논문 양식으로 채택됐고, 연구실 문서 관리 담당자는 “이제 출력 장치가 달라도 제목과 본문이 엉키지 않습니다.”라는 보고서를 제출했습니다.
Scribe는 선언형 마크업과 스타일 템플릿 개념을 제시했습니다. 문서 구조 정의와 스타일 정의를 분리해, 같은 구조를 여러 장치에서 재활용할 수 있다는 점을 보여 주었고 이는 SGML과 HTML에 참고 사례로 남았습니다.
1978
유럽 표준 회의에서 “살짝 다른 태그 때문에 문서가 깨져요.”라는 문제를 해결하려고 SGML 초안이 공개됐습니다.
제네바 회의실에서 ISO 위원들은 각자 가져온 문서 예제를 펼쳤습니다. 영국 대표는 항공 매뉴얼을, 프랑스 대표는 법령 문서를 내놓고 “같은 구조인데 태그가 달라 서로 읽을 수가 없어요.”라고 말했습니다.
위원회는 문서 타입 정의(DTD) 개념을 포함한 SGML 초안을 공개하고, 각국 기관에 시험 사용을 요청했습니다. 공공 기록 보관소 담당자는 “이제 문서 구조를 선언한 뒤 교환할 수 있겠네요.”라며 안도했습니다.
SGML 초안은 태그 집합을 명시하는 DTD와, 내용을 계층 구조로 기술하는 규칙을 포함했습니다. 구조 정의를 공유하면 다른 조직도 같은 문서를 파싱할 수 있다는 원리가 받아들여졌고, 이는 1986년 정식 표준화의 출발점이 되었습니다.
1986
SGML 표준이 승인되자 기술 문서 업계는 “이제 기계가 문서를 읽을 수 있다.”며 환호했습니다.
ISO 총회에서 표준 승인 소식이 전해지자, 항공 매뉴얼을 관리하던 앤은 즉시 문서 관리 시스템을 업데이트했습니다. 그녀는 “태그와 DTD를 표준으로 등록하면 부품 카탈로그가 자동으로 조립돼요.”라고 동료에게 설명했습니다.
전문 출판사는 SGML 파서를 채택해, 수백 페이지 매뉴얼을 장치별로 변환하는 시범을 진행했습니다. 고객은 “같은 내용을 인쇄물과 데이터베이스에서 동시에 받을 수 있군요.”라고 말했습니다.
ISO 8879:1986은 마크업 선언 방식과 파서 행동을 명확히 정의해, 구조화된 문서 교환을 가능하게 했습니다. 이후 HTML은 SGML 응용으로 탄생했고, 구조를 명시하면 프로그램이 의미를 추론할 수 있다는 믿음이 확고해졌습니다.
1989
팀 버너스-리가 “연구 문서를 연결하려면 가벼운 SGML 응용이 필요하다.”며 HTML을 제안했습니다.
CERN의 한 사무실에서 버너스-리는 SGML 문서를 줄이고 하이퍼텍스트 링크를 추가한 초안을 동료에게 보여줬습니다. 동료 니콜라스는 “이 태그라면 누구나 쉽게 문서를 만들 수 있겠네요.”라고 말했습니다.
연구자들은 즉시 HTML 태그 리스트를 실험하며, `` 요소가 문서를 잇는 모습을 확인했습니다. “SGML의 좋은 부분만 남겼군요.”라는 평가가 이어졌습니다.
HTML은 SGML을 간소화하고 하이퍼텍스트 링크를 핵심으로 삼았습니다. 구조적 요소와 링크 모델을 정의해, 브라우저가 문서를 해석하고 네비게이션을 제공할 수 있게 했으며, 이후 모든 웹 문서 구조 논의의 출발점이 되었습니다.
1995
IETF가 첫 공식 HTML RFC를 발행하자, 브라우저 개발사들은 “같은 문서를 다같이 해석할 수 있게 됐다.”고 안도했습니다.
IETF 회의에서 HTML 워킹그룹은 폼과 이미지, 앵커 요소를 정리한 문서를 배포했습니다. 넷스케이프 엔지니어 브렌다는 “이제 폼 제출과 테이블 구조가 표준화되네요.”라고 말했고, 마이크로소프트 팀도 신속히 구현 계획을 세웠습니다.
RFC 1866이 공개되자 ISP 기술지원팀은 “브라우저마다 결과가 다른” 문의가 줄기 시작했다고 보고했습니다.
HTML 2.0 RFC는 문서 구조, 폼, 엔티티 처리 규칙을 명문화했습니다. 태그 의미가 합의되면서 웹 문서를 자동화 도구가 읽을 수 있게 되었고, 이후 버전에서 시맨틱 확장이 가능해졌습니다.
1997
W3C가 XML 1.0을 승인하자 개발자들은 “같은 태그 구조로 문서와 데이터를 모두 주고받자.”며 구조 실험을 가속했습니다.
1997년 12월, W3C 기술 브리핑에서 팀 브레이는 슬라이드를 넘기며 말했습니다. “SGML은 무겁지만 XML은 가볍습니다. 서버와 브라우저, 심지어 PDA까지 같은 트리를 이해하게 만들 수 있죠.” 참가자 미셸은 노트북에서 주문 데이터를 XML로 변환해 보여 주며 “API 없이도 구조를 공유할 수 있어요.”라고 감탄했습니다.
신문사는 기사 피드를 XML로 배포하기 시작했고, ERP 업체는 회사 간 통합을 위해 DTD와 네임스페이스를 작성했습니다. “문서처럼 읽고 데이터처럼 파싱한다”는 접근이 현실이 되었습니다.
XML 1.0은 태그, 속성, 네임스페이스를 엄격히 정의해 다양한 시스템에서 같은 구조를 이해하도록 했습니다. 프론트엔드는 XML 기반 SVG, RSS를 읽으며 시맨틱을 확장했고, 백엔드는 SOAP, B2B 연동 등에서 XML 스키마를 활용했습니다. 이후 JSON이 등장해도 “데이터와 문서를 구조로 정의한다”는 사고방식은 계속 이어졌습니다.
1998
브라우저 공급사는 “스크립트로 문서 구조를 건드릴 표준이 필요하다.”며 DOM Level 1을 채택했습니다.
W3C 회의에서 브라우저 엔지니어들은 노드 탐색과 속성 조작 API를 정의했습니다. 넷스케이프와 IE 대표는 `document.getElementById` 사용법을 공유하며, 서로 호환되는 구현을 약속했습니다.
웹 개발자 라셸은 첫 테스트에서 버튼 클릭으로 문단을 생성하는 코드를 작성하고 “이제 문서를 데이터처럼 다룰 수 있어요.”라고 블로그에 후기 게시물을 올렸습니다.
DOM Level 1은 문서를 트리 구조로 표현하고, 노드를 생성·삭제하는 표준 메서드를 정의했습니다. 이를 통해 HTML 구조를 런타임에 조작하며 동적 애플리케이션을 만들 수 있게 되었고, 구조와 스크립트의 연결 고리가 마련됐습니다.
2004
애플, 모질라, 오페라는 “폼과 인터랙션을 강화한 HTML이 필요해요.”라며 WHATWG를 결성했습니다.
산호세에서 열린 브라우저 벤더 회의에서 이안 힉슨은 HTML5 초안의 방향성을 발표했습니다. 그는 `canvas`, `input type="email"` 같은 요소를 소개하며 “웹 문서가 앱처럼 일해야 합니다.”라고 강조했습니다.
회의 후 게시판에는 개발자들의 요청이 쏟아졌고, WHATWG 메일링 리스트는 하루에도 수십 통의 피드백으로 가득 찼습니다.
WHATWG는 기존 HTML을 확장해 애플리케이션에 필요한 시맨틱과 API를 포함했습니다. 사양이 공개 협업 형태로 작성되면서, 구조와 의미를 코드로 정의하는 문화가 더욱 활발해졌습니다.
2005
웹 커뮤니티는 “기존 HTML만으로 일정과 연락처를 노출할 수 없을까?”라며 클래스 기반 구조 약속을 만들었습니다.
BarCamp 행사에서 개발자들은 명함 교환을 자동화하고 싶다며 `hCard` 예제를 돌려봤습니다. 참석자 리암은 블로그에 `class="fn org"`를 붙이고 나서 “주소록 앱이 자동으로 데이터를 읽어가요.”라고 자랑했습니다.
microformats.org에는 사례가 쌓였고, 검색 엔진 팀이 “이 구조라면 일정과 리뷰를 추출할 수 있다.”며 실험을 시작했습니다.
마이크로포맷은 기존 HTML 요소에 클래스 이름을 붙여 의미를 표현하자는 약속이었습니다. 구조화된 데이터를 공유하면 검색과 일정 통합이 쉬워진다는 사실이 드러났고, 이는 나중에 schema.org와 같은 시맨틱 웹 표준으로 이어졌습니다.
2011
구글·빙·야후가 “같은 마크업이면 서로 이해하자.”며 schema.org를 발표하자, 제작자들은 구조화 데이터를 본격 채택했습니다.
2011년 SMX 컨퍼런스에서 구글의 리치어와 빙 엔지니어가 함께 무대에 섰습니다. “이제 itemscope와 itemprop만 맞추면 검색 결과에 리뷰 별점과 행사 일정이 바로 뜹니다.” 발표 후 마케팅 팀장 수지는 “우리 레시피에도 별점이 나오게 할래요!”라며 개발자에게 구조화 마크업을 요청했습니다.
이듬해 전자상거래 사이트가 상품, 가격, 재고 정보를 schema.org 어휘로 노출하면서, 크롬과 파이어폭스 개발자 도구에는 구조화 데이터 점검 기능이 추가됐습니다. “구조가 곧 검색 트래픽”이라는 말이 현실이 되었습니다.
schema.org는 검색엔진이 공동으로 유지하는 어휘집입니다. HTML과 JSON-LD 어디에서든 사용할 수 있어 구조를 표시하는 방식이 통일되었고, 접근성 도구와 음성 비서가 같은 구조를 재사용할 수 있게 했습니다. 프론트엔드는 구조화된 정보를 시각적으로 드러내고, 백엔드는 정해진 스키마에 따라 데이터를 제공하며 협업 범위를 넓혔습니다.
2014
W3C가 HTML5 권고를 발표하자 팀 리더는 “div 대신 main으로 갈아타자”라며 템플릿을 갈아엎고 시맨틱 요소를 받아들였습니다.
웹팀 리더 하나는 문서 템플릿에서 `
블로거들은 `section`과 `aside` 사용법을 공유하며, 디자인 시스템에 시맨틱 규칙을 추가했습니다.
HTML5는 시맨틱 요소와 문서 구조 알고리즘을 제공해, 레이아웃이 아닌 의미 중심 마크업을 권장했습니다. 표준이 확정되면서 접근성 도구와 검색 엔진이 구조를 활용하기 쉬워졌습니다.
2017
W3C는 WAI-ARIA 1.1 패턴을 공개하며 “구성요소마다 역할과 상태를 명확히 알려 주세요.”라고 권장했습니다.
캘리포니아의 한 뮤지엄 웹팀은 탭 컴포넌트를 테스트하면서 ARIA 역할을 적용했습니다. 스크린 리더 사용자 테스터가 “이제 탭 제목과 현재 위치를 정확히 들을 수 있어요.”라고 피드백했습니다.
패턴 가이드는 열린 상태, 키보드 포커스 이동 순서를 표로 정리해, 프론트엔드 팀이 구조를 설계할 때 참고서가 되었습니다.
ARIA 1.1은 역할, 상태, 속성을 통해 문서 구조가 보조기술에 전달되도록 보완했습니다. 시맨틱 태그만으로 표현하기 어려운 패턴을 보완해, 구조 정보를 더 정밀하게 전할 수 있게 했습니다.
2020
브라우저 지원이 안정되자 디자인 시스템 팀은 “`
한 공공기관 팀은 `
접근성 엔지니어는 커스텀 엘리먼트 내부에 시맨틱 요소를 유지하도록 리뷰했고, 배포 후 사용자 설문에서는 “페이지마다 같은 패턴을 쉽게 인식할 수 있다.”는 응답이 늘었습니다.
Custom Elements v1은 표준 클래스 확장을 통해 재사용 가능한 구조를 만들 수 있게 했습니다. 컴포넌트가 자신만의 템플릿과 접근성 속성을 포함하면, 디자인 시스템이 구조를 자동으로 보급할 수 있다는 사실이 확인되었습니다.
2022
대규모 서비스는 “디자인뿐 아니라 문서 구조 규칙도 손에 잡히게 정리하자.”며 퍼블릭 가이드를 발행했습니다.
정부 UX 센터는 디자인 시스템 웹사이트에 구조 템플릿을 공개했습니다. 콘텐츠 팀원은 “견본을 복사하면 제목 계층과 랜드마크가 이미 잡혀 있어요.”라고 소감을 남겼습니다.
회사 내부 오피스 아워에서는 개발자와 디자이너가 함께 구조 규칙을 검토하며, 문서 구조를 테스트하는 자동화 스크립트를 공유했습니다.
디자인 시스템은 구성요소뿐 아니라 문서 구조, 접근성 체크리스트를 포함하기 시작했습니다. 구조 규칙을 문서화하면 새 페이지도 같은 의미 체계를 따르게 되고, 콘텐츠 품질이 일정하게 유지된다는 장점이 확인되었습니다.
2023
W3C Design Tokens 초안이 “색과 컴포넌트 속성을 한 구조에 담자.”고 제안하자, 제품팀은 구조와 스타일 자산을 한 번에 배포하기 시작했습니다.
2023년 W3C 커뮤니티 그룹은 Design Tokens Working Draft를 공개하며 `"color.background.surface"` 같은 키 구조를 소개했습니다. 피그마 디자이너 안나는 “이제 변수 이름만 공유하면 앱과 웹이 동시에 업데이트돼요.”라고 말했고, 프론트엔드 리드는 토큰 JSON을 라이브러리에 가져와 즉시 테마를 교체했습니다.
컨퍼런스에서는 “토큰이 곧 구조다”라는 말이 따라붙었습니다. 토큰 파일에 역할, 계층, 접근성 대비 정보까지 적어 두며 구조와 스타일 정의가 하나의 출처에서 관리되기 시작했습니다.
Design Tokens 규격은 색상, 간격, 타입 스케일 같은 시각 속성을 키-값 구조로 정의하고, 플랫폼별 빌더가 이를 변환하도록 합니다. 프론트엔드는 토큰을 읽어 컴포넌트 구조를 일관되게 렌더링하고, 백엔드는 같은 토큰을 이메일, PDF 템플릿에도 적용하면서 “구조와 스타일의 단일 진실”을 유지할 수 있게 되었습니다.
