90년대 웹 개발자만이 기억하는 것 (2014)

 (zachholman.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1990년대 개인 웹은 표준화된 레이아웃 도구가 부족해 <blink>, <marquee>, 1x1.gif, &nbsp;, DHTML 같은 기법으로 배치와 효과를 억지로 만들던 시절이었음
  • CSS 레이아웃이 자리 잡기 전에는 1x1.gif와 반복된 &nbsp;가 요소 위치를 밀어내는 핵심 배치 도구처럼 쓰였고, 글은 이를 과장된 향수로 풍자함
  • 초기 CSS는 링크 밑줄 제거와 a:hover 스타일 변경처럼 작은 시각 효과에 집중됐고, 그 결과 링크와 일반 텍스트의 구분이 흐려졌음
  • DHTML은 CSS와 JavaScript를 섞어 로딩 alert(), 눈송이, 아코디언 메뉴, 커스텀 <marquee> 같은 효과를 만들던 복사-붙여넣기 문화와 맞닿아 있었음
  • 픽셀 폰트, 88x31 버튼, Internet Explorer 4.0, GeoCities, FrontPage ’98은 당시 개인 웹사이트가 기술 선택과 정체성을 과시하던 방식으로 등장함

<blink>와 <marquee>가 애니메이션이던 시절

  • <blink>를 <marquee> 안에 넣는 조합은 1990년대 웹에서 대단한 컴퓨터 애니메이션처럼 농담 섞여 다뤄짐
  • 1990년대 웹 개발자는 오늘날의 jQuery나 비관계형 데이터베이스보다 더 중요한 이야기를 갖고 있었다는 식의 과장된 자부심이 깔려 있음

1x1.gif로 페이지를 밀어내던 레이아웃

  • 1x1.gif, spacer.gif, transparent.gif는 모두 1픽셀×1픽셀 투명 GIF를 가리킴
  • HTML 이미지의 WIDTH와 HEIGHT 속성을 크게 지정해 보이지 않는 공간을 만들고, 페이지 요소를 원하는 위치로 밀어낼 수 있었음
  • 예시 코드는 <TABLE>, <TR>, <TD>, <FONT>, <MARQUEE>, 웹 카운터 CGI를 함께 써서 구조와 장식을 한꺼번에 처리함
  • 1x1.gif가 요소를 페이지 어디든 배치하게 해줬고, 오늘날까지도 세로 중앙 정렬의 유일한 방법이라는 식의 풍자가 이어짐

&nbsp;로 맞추던 수동 간격

  • 이미지 태그를 쓰기 어렵다면 &nbsp;를 반복해 간격을 맞추는 방법도 있었음
  • PLEASE SIGN과 MY GUESTBOOK BELOW: 사이에 여러 개의 &nbsp;를 넣어 게스트북 문구를 배치하는 예시가 나옴
  • 1990년대에 &nbsp;를 쓴 횟수만큼 니켈을 받았다면 AOL 월간 초과 요금을 낼 돈이 충분했을 것이라는 농담으로 이어짐

초기 CSS는 링크 밑줄부터 지웠음

  • CSS는 HTML의 황금기 말에 등장해 콘텐츠와 스타일 분리를 약속한 기술로 소개됨
  • 당시 CSS로 가장 먼저 한 일은 링크의 밑줄 제거였음
  • 링크가 텍스트처럼 보이고 텍스트가 링크처럼 보이면서 어디를 클릭해야 할지 알기 어려워졌음
  • 마우스 커서 뒤에 불꽃 흔적이 남는 효과도 함께 거론됨
  • 2000년의 index.shtml 파일 예시에는 인라인 CSS로 a:hover {text-decoration: none; color: #000000}만 들어 있음
    • 호버 시 밑줄을 제거하고 색을 검은색으로 바꾸는 코드임
    • SSI를 쓰는 index.shtml 파일이라는 점도 농담처럼 강조됨

DHTML과 코드 복사 문화

  • CSS로 링크 밑줄을 없앤 뒤 JavaScript로 페이지 로드 시 alert("Welcome to my website!")를 띄우는 흐름이 이어짐
  • CSS와 JavaScript의 결합은 DHTML이라는 “공포의 기술”로 풍자됨
  • DHTML 효과에는 페이지 위에서 떨어지는 눈송이, 아코디언 메뉴 애니메이션 이미지맵, <div>를 사용한 커스텀 <marquee> 등이 포함됨
  • Dynamic Drive 같은 사이트 덕분에 문제를 직접 풀기보다 50줄 코드 블록을 복사해 붙여넣으면 해결되는 것처럼 다뤄짐
  • DHTML은 당시의 Twitter Bootstrap에 비유됨

픽셀 폰트와 낮은 해상도의 미학

  • 당시 컴퓨터 화면은 CRT라 물리적으로는 컸지만 해상도는 높지 않았음
  • 제한된 픽셀을 효율적으로 쓰기 위해 6포인트 수준의 작은 글꼴을 쓰는 분위기가 있었음
  • 단순한 픽셀 기반 서체를 본 웹 개발자들이 일러스트레이터가 되려 했고, 스플래시 화면에 아이소메트릭 픽셀 일러스트를 넣는 시도도 있었음
  • 그 시간과 돈을 Photoshop 설치보다 닷컴 IPO 투자에 쓰는 편이 나았을 수 있다는 농담도 붙음

Internet Explorer 4.0과 88x31 버튼

  • 오늘날 사람들이 Internet Explorer를 싫어하는 이유는 Internet Explorer 4.0의 “순수한 형태”에서 멀어졌기 때문이라는 식으로 풍자됨
  • Internet Explorer 4.0은 Active Desktop과 Channels를 갖춘 완벽한 브라우저처럼 과장됨
  • 당시 웹사이트에는 방문자가 어떤 브라우저를 써야 하는지, 어떤 도구와 서비스를 쓰는지 알리는 88x31 픽셀 버튼이 많이 붙어 있었음
  • 버튼은 군복의 훈장처럼 사이트 운영자의 선택과 소속을 보여주는 장치로 비유됨
    • 에디터 예시는 FrontPage ’98
    • 웹 서버 예시는 GeoCities
    • 웹 링은 사이트를 가장 높게 올려주는 곳을 원했지만 실제로는 없었다는 농담이 붙음

오늘날 웹을 향한 농담

  • 오늘날 웹은 JavaScript 위에 여러 추상화가 쌓인 상태로 표현됨
  • JavaScript가 수학도 제대로 계산하지 못한다는 농담과 함께, 오늘날의 웹에 도달한 일이 놀랍다는 식으로 마무리됨
  • 다음 pull request에 많은 &nbsp;를 붙여 팀을 장난스럽게 괴롭히라는 제안으로 끝남

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 서버 사이드 이미지 맵 얘기가 정말 남 일 같지 않음
    웹 프로그래머라기보다 가끔 웹 기반 도구를 만드는 시스템 관리자라 웹 실력은 2000년대 초반에 멈춰 있고, JavaScript에도 묘한 거부감이 있음. 최근 도구에서 이미지 위의 점을 다루는 기본 동작이 필요했는데 JavaScript 5줄이면 됐을 일을 2023년에 서버 사이드 이미지 맵으로 처리함
    결국 JavaScript 5줄 대신 상태를 관리하는 Python 50줄과 이상한 프래그먼트 문법을 처리하는 요청 핸들러 특수 케이스가 생겼고, 좀 민망하지만 그래도 돌아가게 만든 건 묘하게 뿌듯함

    • 서버 사이드 이미지 맵의 최악은 아카이빙을 완전히 깨뜨린다는 점임
      archive.org Wayback Machine에서 오래된 사이트를 찾았는데 홈페이지 전체가 서버 사이드 이미지 맵이면, 원래 서버 없이는 나머지 사이트의 목적지 URL을 알아낼 방법이 없어 완전히 막다른 길이 됨
    • 2015년에 Chromium의 서버 사이드 이미지 맵 지원을 고친 적이 있음
      당시에는 거의 망가져 있어서 확대/축소가 100%가 아니거나 padding이 0이 아니면 좌표가 틀어졌고, 비슷한 문제가 여럿 있었음. 아무도 눈치채지 못한 건 이미지 맵 자체가 거의 안 쓰이고 서버 사이드 이미지 맵은 더더욱 안 쓰였기 때문임
      나도 JavaScript 없이 쉽게 빠져나가고 싶어서 90년대 HTML을 떠올렸지만, 결국 Chromium 버그를 고친 뒤 서버 사이드 이미지 맵이 별로라는 결론을 내리고 JavaScript를 썼고, JavaScript 버전이 더 나았음
    • “이 지옥 같은 것 전체에서 JavaScript 딱 5줄뿐이라도 내 프로그램에는 안 넣겠다”는 감각에 완전히 공감함
      HTMX는 정말 구원 같고, Tailwind UI를 사면 누구나 프런트엔드에서 꽤 위험한 사람이 될 수 있음. 그래도 JavaScript가 왜 찝찝한지 다른 관점도 궁금함. 개인적으로는 문법의 일관성 부족이 크고, TypeScript 쪽은 node_modules 폴더만 봐도 속이 울렁거림
      전체적으로 무슨 일이 벌어지는지 통제할 수 없다는 느낌 때문에 오랫동안 프런트엔드에서 멀어졌음
    • 2019년 말 집에서 회사에 있는 장치 GUI를 조작해야 했는데 원격 데스크톱은 없고, 스크린샷 도구와 클릭을 주입하는 명령줄 도구만 있었음
      Lisp 몇십 줄로 화면의 이미지 맵을 제공하는 웹 서버를 만들고, 이미지 맵 요청이 오면 클릭을 삽입하게 했음. 출근 왕복을 아끼려 만든 작은 일회성 도구였는데, 이후 COVID가 터지면서 너무 많은 사람이 쓰게 됐고 지금도 누군가 쓰고 있을지 모름

  • “지금도 요소를 세로 가운데 정렬하는 유일한 방법”은 더 이상 사실이 아니지만, 지난 30년간 div 안에서 그냥 vertical-align: middle;을 못 쓴 생산성 비용은 수십억 달러였을 것 같음
    IE4나 IE6 시절쯤 링크 :hover에 overline 스타일을 주던 유행도 기억남. 테이블로 둥근 모서리 div와 버튼을 만들기도 했고, 2000년대에도 Photoshop에서 잘라 테이블 셀에 넣는 고통이 계속됐음

    • 그때도 테이블 셀 안에서는 VALIGN=MIDDLE 이 있었음
      90년대에도 가능했는지는 모르겠지만 2000년대에는 확실히 존재했음
    • 요즘은 그런 CSS를 ChatGPT에게 쓰게 하는데, 웃기게도 최소 열두 가지 해법을 내놓는 듯함
      다만 규칙 2~3개면 충분한데 5개 이상을 붙이는 식의 중복 규칙도 자주 섞임. 정말 우스울 정도로 멍청함
    • 테이블로 둥근 모서리를 만들던 시절이 정말 유행이었음
      그놈의 모서리 때문에 얼마나 많은 시간을 썼는지 모름
    • 지금도 세로 정렬은 여전히 큰 골칫거리이고, 미묘한 이해가 많이 필요함
      Tailwind CSS에서도 단순하지 않아서 요소가 블록인지, 텍스트인지, 부모 레이아웃이 무엇인지 등을 계속 따져야 함
    • 좋아하는 CSS 해킹 중 하나는 div { display: table-cell; vertical-align: middle; }임
      모든 상황에서 통하진 않지만, 처음엔 더럽게 느껴져도 관심사의 분리는 여전히 유지되고 딱히 다른 단점은 보이지 않음

  • 이 문맥의 DHTML은 Distributed HTML이 아니라 Dynamic HTML이었고, 그래서 Dynamic Drive의 Dynamic이기도 함

    • “DHTML은 당연히 distributed HTML이다”는 농담이었는데 잘못 인용한 것 같음
      다른 사람들도 똑같이 잘못 인용한 걸 보면, 글쓴이가 최근에 장난스럽게 수정했을 가능성도 있어 보임
    • 그래도 “Technology of Terror”라는 묘사는 반박 없이 여전히 유효함
    • 아래쪽의 “그냥 복사해서 붙여넣을 수 있었다”는 부분을 암시하려던 건가 싶었고, 어쩌면 DCOM을 비튼 것일 수도 있음
    • 아래 스레드에서 논의됐음: https://news.ycombinator.com/item?id=39127528
      결론은 농담이긴 한데 좋은 농담은 아니라는 쪽이었음
    • 여기서 정말 재미 금지파를 찾아낸 듯함

  • 프레임도 빼놓을 수 없음. 모든 페이지의 내비게이션 바를 수정해야 하는 문제에 대한 원래의 “해결책”이었음
    문제는 검색 엔진이 각 프레임 페이지를 따로 색인할 수 있어서 누군가 프레임 페이지에 직접 들어오면 어떻게 할지 처리해야 했다는 점임. 섹션 사이의 절단선도 항상 뚜렷해서 어색하고 불편했음

    • 진짜 고수들은 서버 사이드 인클루드를 썼음
      HTML 안에 특수한 주석을 넣어두면 Apache가 클라이언트로 보내기 전에 다른 파일의 내용으로 치환해 줬음
    • 다른 웹사이트가 내 페이지를 프레임에 넣으면 frame-buster 스크립트를 배포했고, 내 프레임 없이 페이지가 고아가 되면 frame-joiner 스크립트를 소환했음
    • 프레임은 지금도 기반 마이크로프런트엔드 기술로 의외로 잘 쓰이고 있음
      이론은 https://martinfowler.com/articles/micro-frontends.html#Run-t...에 있고, 구현은 https://luigi-project.io에서 볼 수 있음
    • JavaScript의 “AJAX”식 사용 중 우스울 정도로 큰 비율은 프레임으로도 처리할 수 있었고, 프레임이 정체되지 않고 조금만 발전했다면 성능도 더 나았을 가능성이 큼
      여기에 HTML 테이블이 기본 기능을 갖추고, 데이터 소스 기반 테이블과 목록 뷰가 2000년대 중반에 제공됐다면 어마어마한 시간과 돈을 아낄 수 있었을 것임
      웹이 결제 표준을 받아들여 브라우저 자체가 결제 입력을 처리했다면 얼마나 많은 돈을 아꼈을지도 말하기 시작하면 끝이 없음
    • 섹션 간 경계가 브라우저마다 정확히 같지도 않았음
      얘들아, 모두가 같은 브라우저를 쓰지 않던 시절이 있었음

  • 1996년, Microsoft 홈페이지에는 마우스를 올리면 펼쳐지는 메뉴 바가 있었고, 그게 어떻게 동작하는지 알아내겠다고 마음먹었음
    당시 IE에는 “소스 보기” 버튼이 있었지만 플랫폼 감각이 부족해서 Notepad 문서로 열렸고, 서버는 Unix라 줄바꿈이 \n인데 Windows는 \r을 기대하니 HTML 소스가 한 줄짜리 긴 문서로 보였음
    소스를 샅샅이 봐도 HTML 태그는 다 아는 것들이고 내용도 페이지에 보이는 텍스트뿐이었음. 유일하게 낯선 건 HTML 엔티티였고, 움직이는 메뉴가 있는 사이트마다 보였으니 분명 관련 있다고 믿었음
    6개월 동안 DHTML 효과가 알고 보니 HTML 엔티티였던 것들의 마법 주문으로 구현된다고 믿었고, 나중에 WebMonkey 튜토리얼을 찾으면서 그게 커리어 전체로 이어졌음

    • 소스 보기가 내 출발점이었음
      최소화 도구와 컴파일러는 훌륭하지만, 잘 설계된 사이트의 정돈되고 관리된 소스를 읽던 시절이 정말 그리움
      운영 코드에서도 원래 소스 형식을 보존하고, 전 세계의 다른 사람들이 우리 코드를 읽을 거라는 기대를 유지할 수 있는 압축 방식으로 갔으면 좋았겠다는 생각이 듦. 초기 웹이 빠르게 발전한 데에도 이런 문화가 큰 역할을 했고, 내 업계 입문사에서도 분명 큰 부분이었음
    • 당시 실제로 무엇이 움직이는 메뉴를 만들었는지 궁금함. 그때 코딩을 하던 세대가 아니라서 아마도 어떤 태그나 스크립트가 원인이었을 것 같음
    • 마우스를 올렸을 때 이미지를 바꾸고 싶어서 비슷한 경험을 했음
      Barnes & Noble에서 JavaScript Bible을 사서 주말 동안 읽었고, 그 뒤로 계속 배우게 됨
    • WebMonkey라니, 추억이 확 살아남

  • 테이블이 둥근 모서리에도 쓰였다는 걸 잊으면 안 됨
    3×3 테이블을 만들고 가운데 셀을 제외한 셀에 이미지를 넣어 둥근 모서리를 가진 웹사이트 요소를 만들었는데, 그게 인간 표현력의 정점처럼 느껴졌음
    HTML 이메일도 유행이었고 이메일 클라이언트는 브라우저보다 훨씬 느리게 갱신됐기 때문에, 제대로 표시되길 원하면 이 기법이 2010년대까지도 쓰였음

    • 3×3 테이블용 tl.gif, tr.gif, bl.gif 같은 이미지 묶음을 만들던 걸 절대 잊지 못함
      당시 브라우저는 빈 셀의 배경 이미지를 렌더링하지 않았기 때문에 좌우 셀 배경을 보이게 하려면 글에서 말한 1x1.gif 도 필요했음. 좋은 시절이었음
    • border-radius를 얻자마자 디자인 유행이 바뀌어서 아무도 둥근 모서리를 원하지 않게 됨
    • 글의 여러 항목은 90년대보다는 2000년대 초반에 가까운 것 같음
      테이블로 둥근 모서리를 만들기 전에는 Trillian이라는 멀티 채팅 앱을 스킨 꾸미듯 만졌던 기억이 있음. Yahoo Chat, ICQ 등을 처리했고, 둥근 모서리 다루듯 위쪽과 옆쪽 셀에 반복 이미지를 넣어 창 크기 조절이 잘 되게 했음
    • https://www.folklore.org/Round_Rects_Are_Everywhere.html
      위대하고 전능한 Oz의 최고 업적임. 뭐, iPhone이 더 컸을 수도 있음
    • 테이블은 그림자에도 쓰였음

  • 90년대/00년대 웹사이트라면 “800×600 해상도에 최적화” 버튼이 빠질 수 없었음
    조금 더 멋을 내고 싶다면 “Valid HTML 4.01”도 붙였음
    그때 광고는 요즘의 복잡한 JavaScript 묶음과 동영상 광고가 아니라 단순한 표준 크기 배너였음. Norton Internet Security 2003이 방문한 페이지의 HTML을 조용히 다시 쓰면서 표준 광고 크기 배너만 제거하고 나머지는 놔두는 걸 보고 충격받았던 기억이 있음. 광고 차단기가 보안 솔루션이라는 20년 된 확인이기도 함

  • 글 전체에 webmaster라는 단어가 한 번도 안 나온다니, Zach가 정말 90년대에 있었던 게 맞나 싶음

    • 90년대 말에 만든 “Webmaster” 명함을 아직 갖고 있음
      그 당시 그 직함이 얼마나 “멋졌는지”는 아무도 이해 못 할 것임. 지금 보면 나조차도 오글거리지만 좋은 기억이 정말 많음
    • 공식적으로 자신을 “webmistress”라고 부르던 여성과 일한 적이 있음
      농담이 아니었음

  • 90년대 웹을 직접 체험하고 싶다면 The Geocities Gallery https://geocities.restorativland.org/를 추천함
    이런 개인 웹페이지들에는 아름다운 무언가가 있음. 각 페이지는 저마다 뚜렷한 외형을 갖고 있고, 그것만으로도 작성자의 성격을 많이 보여줌
    보통 자기소개, 무작위 개인 사진 몇 장, 짧은 설명이 붙은 추천 링크 목록, 취미에 대한 느슨한 글 등이 있어 매우 개인적이고 차분함. 모든 프로필 페이지가 똑같이 밋밋하고 지루해 보이고, 끝없이 늘어나는 콘텐츠와 특정한 삶의 이미지를 유지해야 한다는 압박이 있는 오늘날 소셜 미디어와는 선명하게 대비됨

    • 덕분에 토끼굴에 빠졌음
      Area51 아래 어느 디렉터리에 있었는지 기억나지 않고 어쩌면 아카이브되지 않았을 수도 있는 예전 내 사이트를 찾느라, 또 그냥 그 시절을 되살리느라 한참을 보냈음
      기억은 이상함. Geocities를 보니 옛 인터넷의 냄새까지 떠올랐는데, 아마 컴퓨터가 있던 가족실 냄새였을 것임
    • 90년대 중반에 Windows의 벽돌 배경과 투명 GIF 그래피티를 조합해서 꽤 멋진 효과를 만들었던 기억이 있음
      ACID, ICE, FIRE 같은 BBS 아트 그룹의 초기 작업도 당시에는 정말 멋졌음
      IE5/6 지배 이전에 더 고급스러운 것은 대체로 Flash로 밀려났음. 2000년대 초반에는 E4X 기반으로 React와 비슷한 프레임워크를 만들었고, ActionScript/Flash/Flex, Mozilla/Netscape가 이를 지원했으며 VB.Net의 XML 리터럴 표기와도 비슷했음
      Microsoft와 Google이 채택하지 않았고, 결국 JSON이 왕이 됨

  • 90년대에는 웹 레이아웃 질문의 답이 거의 항상 테이블이었음
    텍스트 정렬이 어긋났나? 테이블. 멋진 메뉴가 필요한가? 테이블. 전체 사이트를 만드는가? 중첩 테이블. 행과 셀로 디자인을 해킹할 수 있는데 CSS가 왜 필요했겠음

    • 2024년에도 이메일 레이아웃에서는 여전히 사실임
    • 그리고 모든 셀마다 font 태그를 넣어야 했다는 것도 잊으면 안 됨
    • 그때는 전부 TDD였음. TD-Driven Design이었음
    • 아직도 테이블을 좋아함
      동적 디자인에 정말 훌륭하고, 열/행 병합, 정렬, 가중치도 지원함. CSS는 여전히 옛날 테이블보다 훨씬 복잡함
    • 이제는 그걸 할 수 있는 좀 더 의미론적으로 올바른 방식을 얻게 됨
답변달기