사실 이 이야기는, 꽤 진지한 태도로 본질적인 것에서부터 차근차근 거론해야 맞는 것이다만, 머리 나쁘고 깊게 생각하기 싫어하고 대충대충 살자 주의자이다보니 그런 거 다 귀찮아서 그냥 내가 생각하는 방식대로 이야기하려고 한다. 이 글의 주제나 마찬가지일 <웹표준>에 대해서 진지하게 접근하려는 사람들이라면 이 글을 읽고 거품깨나 물며 달려들테지만.
1. 테이블… 속도의 문제
1997년 당시 홈페이지를 만들면서, 어디 학원을 다니거나 과외를 받은 것도 없이 그냥 인터넷 디벼서 찾아낸 HWP 문서 달랑 하나 (이거 지금도 하드 어딘가에 저장되어 있다) 참고삼아서 HTML 작업을 했었다. (당근 메모장으로) 그때까지만 해도 아직 386 PC에 도스 5.0/윈도우 3.1을 쓰고 있었던 나는, (그 당시 주류는 펜티엄에 윈도우95) 넷스케이프 내비게이터도 버벅거리는 탓에 <오페라>라는 브라우저를 설치해 HTML 파일을 확인해가며 작업을 하고 있었다.
따로 배운 것이 워낙 없다보니 내가 HTML 문서를 만드는 작업은 아래한글에서 워드 작업하던 것과 별반 다르지 않았다. 그냥 텍스트 나열식이 아니라 약간 레이아웃이 필요한 부분이 나오면, 아래한글에서 <표> 불러와 작업하듯 당연히 <테이블>을 써서 레이아웃을 만들었었다. 그러던 어느날, 건담 메카닉 페이지를 만들어서 오페라에서 확인해보려는데 이게 브라우저에 뜨는데만 한참 걸리는게 아닌가. 워낙 컴 상태가 안좋은 탓에 웹에 올려놓은 것도 아닌 내 하드디스크에 있는 파일을 브라우저에 띄우는데도 참을 수 없을 정도였다. 근데 다른 문서파일들과 비교해보니 (테이블이 없는) 다른 페이지들은 브라우저가 내용을 읽어오는대로 조금씩 보여주기 때문에 기다리는데 별 불편함이 없는데 반해, 테이블로 내용을 둘러싸버린 페이지는 테이블 안의 내용을 다 읽어들인 다음에 한꺼번에 브라우저에 보여주기 때문에 건담 메카닉 페이지처럼 이미지까지 여러 장 들어있는 경우 브라우저가 그거 다 읽어들일 동안 사용자는 허연 페이지만 한참을 쳐다보고 있어야 했던 거다. 이것이 내가 처음 접했던 테이블 레이아웃의 문제점이었다.
(기억하는 사람은 없겠지만, 초창기 제타건담의 메카닉 소개 페이지가 둘로 나눠져 있었던 이유가 바로 저것이다. 한 페이지에 다 넣었더니 로딩시간이 너무 오래 걸려서…)
그후로 가급적이면 테이블을 레이아웃에 넣는 방식을 지양하면서, 텍스트에 좌우여백이 필요한 경우 BLOCKQUOTE를 쓴다거나 하는 식으로 속도와의 전쟁을 벌이게 되었다. 그러다가 아시다시피 우리나라의 인터넷 환경이 무섭게 빨라지고, 나도 컴퓨터를 펜티엄급으로 바꾸고 윈도우 95도 깔고 하면서 점점, 그놈의 속도에 무신경해지기 시작했다. 같은 회사의 웹디자이너가 테이블로 도배하다시피한 메인페이지를 들고 나타났을 때도, 아니 이러면 속도가 느려지는데가 아니라 오 테이블을 쓰니까 이렇게도 레이아웃이 나오는군하고 감탄하기만 했을 정도로 말이다.
2. 넷스케이프… 크로스 브라우징
내가 처음 홈페이지를 만들 때만 해도, 웹브라우저는 넷스케이프 내비게이터가 완전 대세였다. 학교 전산실에 가면 누구나 넷스케이프를 썼지, 조잡한 아이콘 배열로 유명했던 MS 익스플로러를 쓰는 사람은 없었다. 당연히 나도, 넷스케이프에 맞춰서 홈페이지를 만들려고 했다.
하지만 앞서 말했듯 집에 있는 PC에 넷스케이프를 깔 수 없는 지경이다 보니, 어쩔 수 없이 집에서는 <오페라>, 학교에서는 <넷스케이프>를 사용하는 이중생활이 시작되고 말았다. 거의 차이가 없긴 했지만 두 브라우저간의 호환성 문제도 조금 있었기 때문에 소위 크로스 브라우징도 깨나 고민했었던 것 같다.
그러다가 점점, MS의 끼워팔기전략 성공 및 넷스케이프 6.0의 실패 등으로 인해 내 홈페이지도 어느덧 익스플로러 전용으로 탈바꿈하기 시작했다. 예전엔 넷스케이프에서만 되는 태그, 익스플로러에서만 되는 태그 구분해서 쓰고 양쪽에서 고르게 잘 보이도록 신경깨나 썼는데 어느새 귀찮아진 거다. 이 시각 현재 내 홈페이지를 방문하고 있는 사람들의 99%가 익스플로러나 MSN브라우저로 들어오고 있는데, 익스플로러 점유율도 문제겠지만 내가 타 브라우저 이용자들의 편의를 전혀 고려하지 않고 있다는 것도 큰 이유일 거다. (파이어폭스에서 영화음악이 잘 안나온다는 사실도 최근에야 알았다)
3.블로그화… 구조에 대한 고민
약 3년 전부터 홈페이지를 블로그 형태로 뜯어고쳐야겠다고 맘먹은 이후, 여태 다른 글에서 주절거렸던 것처럼 지금까지 나름 성공적으로(?) 진행해오고 있는 중이다. 그런데 그냥 방문하는 사람들은 알 수 없고 상관도 없지만, 블로그형 프로그램을 새로 짜면서 작업해야하는 내 입장에서는 영 실마리가 안풀리는 문제가 하나 있었으니, DB만으로는 홈페이지를 구조적으로 표현하기 힘들다는 거였다.
무슨 이야기인고 하니, 지금 내 홈페이지는 컨텐츠를 거의 전부 DB로 만들어 저장하고, 페이지에서 필요한 부분만 쏙쏙 뽑아내서 약간만 재가공하여 브라우저에 표시하게 되어있는데, (여기까지 읽고 이해 안가면 차라리 패스!!) 테이블 투성이에 그때그때 눈에 보이는 것만 수정하며 만들어놓은 레이아웃이라 이 “재가공” 단계가 장난이 아닌 거였다. 다시 말하면 예전에는 홈페이지 디자인을 바꾼다, 할 때 페이지가 100개면 100개의 페이지를 전부 (조금씩이라도) 작업해야했다면, 컨텐츠를 DB로 바꾼 이후에는 최소 1개의 페이지만 바꾸면 모든 페이지가 다 바뀐 효과가 나는 수준, 이걸 기대하고 있었는데 그게 잘 안되고 여전히 (100개까지는 아니지만) 20~30개의 페이지를 손질해야만 하는 현실이 문제였던 거다.
예를 들면 내가 예전에 쓴 글의 본문에서 특정한 문장만 폰트컬러를 지정했다고 하면, 나중에 홈페이지의 배경색을 바꿔버렸을 때 여기에 지정한 폰트컬러와 배경이 안맞아 다시 색을 고쳐야 하는 문제 같은 것들이 도처에 도사리고 있었던 거다. 이거는 홈페이지를 말그대로 완전히 구조적으로 뜯어고친 다음 원래 작업한 본문들까지 전부 CSS 기반으로 뜯어고치지 않고서는 해결할 수 없는 문제들이었다.
4. 해답은 웹표준
여기까지 그동안 내가 홈페이지를 작업하면서 끙끙 안고 왔던 문제들 – (실상 우리나라의 인터넷 환경에서는 크게 문제될 것이 없지만) 테이블의 남발로 인한 속도 문제, 타 브라우저와의 호환문제, 홈페이지를 보다 구조적으로 관리하는 문제 – 에 대한 유일한 해답은, 사실 웹표준에 따라 사이트 디자인을 변경하기만 하면 되는 거였다. 알면서도 지금껏 미적미적 미뤄왔던 이유는 앞서 말한 것처럼 일단 그렇게 바꾸기 위해서 해야할 작업이 만만치 않다는 거, (한번 해놓으면 그 다음은 쭈~욱 편하다) 어느새 테이블에 익숙해져서 CSS로 레이아웃 짜기 어렵다는 거, (익숙해지면 CSS가 더 편하다고 한다) 뭐 그런 것들이었다. (쉽게 귀찮아서, 라고 요약할 수 있다) 그러다가 결정적으로 바꾸기로 결심한 것이 잠깐 언급했지만 얼마전에 파이어폭스 브라우저에서는 영화음악이 잘 나오지 않는다는 사실을 알고나서였다. 안그래도 영화음악 사이트쪽을 전면 개편하려고 이것저것 준비하던 중이었는데, 걸린 김에 크로스 브라우징, 하는 김에 웹표준화, 뭐 이렇게 되어버렸던 거다.
지금 올라가있는 상태가 나름대로 웹표준한답시고 여기저기서 문서 받아 고쳐본 모습이다. 아직은, 아직은 진짜 웹표준화하려면 멀었다. 현재 정리된 문서들도 일단 일일이 보고 다시 고쳐야 하고, 하는 김에 그동안 테이블 남발로 엉망이 된 HTML 코드들도 정리해야한다. 그게 언제 끝날진 아직 모르지만 일단 겉보기는 다 했다. 에고에고.
