본문 바로가기

프로그램/PHP

[펌] css-웹표준 고생기.


웹표준을 실무에 적용하다

HTML만큼 대중화된 프로그래밍 언어는 없을 게다. 초등학생도 HTML 태그로 다음까페 대문을 화려하게 구성할 정도니 말 다했다. 자바스크립트는 벅찬지 복사해서 붙여 쓰지만 HTML은 전문가도 아닌 초등학생이 하드코딩하니 이보다 쉬운 언어는 아마 앞으로도 나오기 힘들 듯하다. 이러한 HTML이 웹2.0을 만나면서 상황이 아주 묘해졌다. 2.0 추종자들이 내용과 표현의 분리를 거의 협박조로 강조하면서부터(이 바닥이 얼마나 분위기를 잘 타는지 아는 사람을 알 게다) 태그와 속성을 한데 붙여 쓰던 위지윅(WYSIWYG, What You See Is What You Get)이 졸지에 니지윅(NYSIWYG, Nothing You See Is What You Get)이 되었다. 내용과 표현을 분리하라고 제시된 것이 웹표준이고 그 방법론이 CSS 사용인데. 태그엔 아이디나 클래스를 속성으로 넣고 이 걸 이용해서 스타일에서 별도로 처리하는 식이다. 그러니 BODY 부분만 보면 대체 이게 어떻게 보이는 지 알 수 없다(그저 밑으로 길게 늘어질 뿐이다. 기획자가 내놓은 스토리보드 PPT 파일보다 보기 어렵다). 그러니 니지윅이라고 할 수밖에. 이런 CSS를 사전에서 찾아보니 이렇다.

 

기존의 HTML은 웹 문서를 다양하게 설계하고 수시로 변경하는데 많은 제약이 따르는데, 이를 보완하기 위해 만들어진 것이 스타일 시트이고 스타일 시트의 표준안이 바로 CSS 이다. 간단히 스타일시트라고도 한다.

HTML을 이용해서 웹 페이지를 제작할 경우 전반적인 틀에서 세세한 글꼴 하나 하나를 일일이 지정해주어야 하지만, 웹 페이지의 스타일(작성형식)을 미리 저장해 두면 웹 페이지의 한 가지 요소만 변경해도 관련되는 전체 페이지의 내용이 한꺼번에 변경되므로, 문서 전체의 일관성을 유지할 수 있고 작업 시간도 단축된다.

따라서 웹 개발자들은 보다 풍부한 디자인으로 웹을 설계할 수 있고, 글자의 크기, 글자체, 줄간격, 배경 색상, 배열위치 등을 자유롭게 선택하거나 변경할 수 있으며 유지·보수도 간편하게 할 수 있다.

각기 다른 사용자 환경에서 동일한 형태의 문서를 제공한다는 이점도 있다. CSS로 만들어진 문서는 사용자들의 브라우저 환경에 따라 홈페이지가 다르게 나타나는 일이 없고 어느 환경에서나 제작자가 의도한대로 그 효과가 전달된다. (네이버 사전 중에서)

 

필자가 장담컨대 단 한번도 위의 말처럼 된 적이 없었다. 일단은 오해를 막기 위해 먼저 이 말을 해야 한다. CSS가 문제는 아니다. 당연히 웹표준도 문제가 아니다. CSS와 웹표준은 널리 권장하고 공부해야 한다. 다만 실무에서 막상 CSS로 웹표준을 구현할 때는 권해준 만큼 제대로 되지 않는다는 말이다. 그 이유도 사람마다 틀리겠지만 필자의 경험으로 보건대 첫째, HTML코더를 천하게 여겼던 이 바닥의 인사 시스템, 둘째, 웹표준을 언제 어떻게 구현해야 되는지에 대한 경험 부족, 셋째, 디자이너나 기획자와의 커뮤니케이션 오류, 넷째, 기본 업무 툴 자체의 비표준 사용이다.

 

HTML코더, 신분상승의

우선 개발자나 혹은 디자이너가 CSS를 왜 제대로 사용 못할까? 여기에 대해 계속되는 야근, 자기 발전의 미비, CSS 교육의 미흡 등 흔히 정부 정책에 대해 토 다는 게 습관처럼 돼 버린 사람처럼 얘기하고 싶지는 않다. 실무에서 필자가(필자뿐 아니라 실무에 있는 사람의 블로그를 봐도 그렇다) 결론 내린 것은 단 하나다. 직업의 귀천 때문이다. 흔히 웹과 관련된 개발은 그 영역에 따라 직종도 구별된다. 서버프로그래머(닷넷 프로그래머, 자바 프로그래머, PHP 프로그래머 등),  DB개발자(MS-SQL 관리자, 아파치 관리자 등), 어플리케이션개발자(C++개발자, 윈도우 개발자 등), HTML코더 등이 그렇다. 이 중에서 가장 비싼 개발자가 서버개발자고 가장 싼(?) 개발자가 HTML코더다. 다른 직종은 전부 개발자나 프로그래머, 혹은 관리자 명함을 갖는데 HTML코더는 그야말로 CODER로 취급된다. 심지어 HTML코더를 아르바이트생이나  디자이너가 대신하는 경우도 많다. 잡코리아 등에 구인 정보를 보면 웹디자이너를 뽑을 때 우대 사항으로 항상 들어가는 것이 HTML 코딩 가능자 우대. 보통 HTML코더가 자바스크립트도 같이 하는데, 자바스크립트야 말로 아무나 하는 언어로 취급당한다.

 

이러니 누가 HTML이나 자바스크립트나 CSS를 제대로 공부하겠는가? 웹사이트의 핵심은 서버도 아니고 DB도 아니다. 사용자의 브라우저에서 보이는 게 핵심이고 그게 전부다. 그런데 브라우저에 보이는 것의 90% HTML과 자바스크립트와 CSS로만 이루어져 있다. 데이터를 MS-SQL에서 받아오든 MY-SQL에서 받아오든 사용자 입장에선 아무 상관 없다. C++로 만들든 비주얼베이직으로 만들든 JAVA로 만들든 그게 사용자에게 무슨 이익인가. 닷넷이든 ASP JSP PHP든 그저 보이기만 하면 된다. 실제로는 HTML코더가 닷컴의 핵심인데 불구하고 가장 천대받았다. 아주 큰 회사가 아니고서는 HTML코더가 따로 있지 않았고 웹프로그래머가 사실상 웹클라이언트를 도맡아 했다. 이들 또한 스스로를 닷넷프로그래머, ASP프로그래머, 자바프로그래머로 인정받길 원했지 HTML코더가 되고 싶은 생각은 꿈에도 없었다. 그저 귀찮은 일이지만 할 사람이 없으니 한번 준 셈이었다. 이러니 대부분의 웹페이지가 서버프로그램과 HTML이 뒤섞여 있었고, 서버프로그램이 우선이고 HTML은 그저 보여주기 위해 끼어 있는 식이었다.

 

2.0이 웹표준과 CSS를 강조하면서부터 HTML코더에 대한 수요가 늘어났지만 워낙 이 바닥이 HTML코더를 천대했던 터라 그 수요를 따라잡을 수가 없었다. HTML와 자바스크립트, CSS를 능숙하게 다루는 사람을 구하기가 하늘의 별따기가 되었다. 그럼 적어도 몸값이라도 비싸 저야 될 텐데 이게 또 다르다. 그건 아무나 할 수 있지 않아요?라는 생각이 아직도 지배적이고, 정 없으면 개발자 시키지하는 상황이니 누가 HTML전문가로 나섰겠는가. 그래서 만능 가제트, 서버프로그래머가 또 나섰다. 허나 평소에도 잘 안 쓰고 천대하던 것을 막상 직접 하려니 잘 될 리가 있나. 예전 같으면 서버프로그램에서 테이블 만들어서 한번에 루핑 돌리면 끝날 일을 갖고, XML 만들고 AJAX로 연결하고 자바스크립트로 파싱하고, CSS로 모양을 만드려니 여간 귀찮지 않다. 그나마도 서버프로그램은 워낙에 디버깅 기술이 발전해서 디버거만 쓰면 다 잡아내는데 자바스크립트와 CSS는 코드를 헤까닥 뒤집어도 못 찾는다. 필자도 로그 이미지와 메뉴, 그리고 배경 이미지로 구성된 GNB 영역을 DIV로 구성하느라고 서버프로그래머와 디자이너와 붙어 하루 종일 애쓴 적 있다. 중간 중간에 테이블의 유혹(TABLE 태그로 만들면 10분도 안 걸린다. 2.0 TABLE을 쓰지 말라고 잘못 전달됐기 때문에 이런 고생 한 사람 많을 게다)을 수십 번 떨쳐내고서야 저녁 즈음에 성공했다. 그나마도 웹표준은 아니다. 그저 테이블 안 쓰고 해냈다는 데서 오는 자신감만 얻었을 뿐.

 

그 이후로는 좀 쉬워졌다. 회사 자체적으로 CSS 스터디도 하고, 관련 문서도 서로 공유했다. 몇 번의 고생 끝에 FLOAT(좌측, 가운데, 혹은 우측으로 붙이는 스타일) POSITION(위치를 절대적으로 혹은 상대적으로 변경시키는 스타일) 개념도 터득했고, WIDTH PADDING(DIV 등의 박스 안쪽에 여백을 주는 스타일) 혹은 MARGIN(PADDING과 반대로 박스 바깥쪽에 여백을 주는 스타일)의 관계(WIDTH를 고정하면서 PADDING이나 MARGIN을 쓰면 실제 폭은 WIDTH+PADDING(혹은 MARGIN)이 된다. 레이아웃을 가로로 나눌 때 우측 단(영역)이 밑으로 빠져나간다면 대부분은 이 문제다)도 이해됐다. 그래도 다시 써보라 그러면 필자는 그냥 테이블을 사용할 거다. 어쨌든 필자더러 CSS 천재라고 서버프로그래머가 한마디 CSS 천재가 어디서 밥 벌어 먹고 살 수 있을까? 여전히 서버프로그래머는 닷컴 어딜 가도 서버프로그래밍 능력으로 대우받고, 디자이너는 디자인 실력으로 선택된다. 서버프로그래머가 HTML/자바스크립트/CSS를 잘하는 건 아무도 신경 안 쓰는 우대 사항일 뿐이고, 디자이너가 HTML을 잘 다루는 건 디자인을 잘한다고 인정될 때 지나가며 한 마디 하는 커뮤니케이션 잘 할 수 있겠네요일 뿐이다. 하물며 기획자가 HTML 잘 알아서 멀 어쩌겠는가.

 

비록 HTML코더가 몸값은 안 올랐지만 웹 퍼블리셔라는 직종도 생겨나는 듯하고, 최근 구글 등의 구인 광고에서 예전과 달리 웹개발자의 필수 기술로 CSS/HTML/AJAX/자바스크립트가 최상단에 올라오는 걸 보면 바야흐로 HTML코더의 시대가 도래하기는 하지 않을까? 사실 구글 캘린더를 봐도 그렇고, 노트를 봐도 그렇다. 요즘 뜨는 구글 스프레드쉬트나 구글문서를 봐도 그렇다. 어디 이뿐이냐. 2.0 사이트의 대부분이 CSS/HTML/AJAX/자바스크립트를 제대로 사용한 것이다. 두드리면 열린다고 최근 들어 오픈소스 진영이나 포털에서 앞다퉈 자바스크립트 모듈이나 UI 가이드를 제공하고 나섰다. 필자의 회사에서도 야후 UI  jQuery 덕을 많이 봤다. 네이버에서도 2006년말에 NHN UI 개발 가이드(html.nhndesign.com)를 오픈했다. 이 외에도 파이어폭스의 파이어버그가 자바스크립트나 AJAX 오류를 잡아내는데 용이하다. 개발자들이 하도 답답했던지 바캠프(www.barcamp.org/BarCampSeoul)를 직접 열어 이런 정보도 공유하니 각자가 적절하게 선택해서 사용하면 되겠다.

 

CSS 쓰는 것도 타이밍

다음 문제는 CSS의 이득이 실무에선 잘 나타나지 않는다는 것이다. 어느 사이트든 일단 오픈하면 리뉴얼하기 전까지는 현재의 레이아웃이나 디자인을 그대로 유지한다. 리뉴얼은 새로운 사이트를 개발하는 수준의 큰 프로젝트여서 어차피 다 바꾼다는 심정으로 작업에 임한다. 그러니 기존의 파일을 수정하는 것보다는 아예 새로 만드는 것이 나을 때가 많다. 기존에 만들어놓은 소스를 폐기하고 다시 만드는 데 대해 아깝다는 얘기는 종종 하지만 그래도 실무는 다르다. 직접 개발하고 직접 리뉴얼을 담당하는 개발자라 할지라도 다시 만드는 게 쉽고 속도도 빠를 때가 많다. 예전 소스를 분석하는 게 오히려 시간을 더 잡아먹기 때문인데, 자기가 만든 것도 이럴 정도니 남이 만든 소스 가져다가 수정하는 거야 두말 하면 잔소리다. 그래서 애써 CSS로 잘 구성해 놓고 아무나 와도 쉽게 수정하고 변경할 수 있다고 해도 막상 쓸모가 없을 때가 많다. 이와는 달리 개발 과정에서는 처음 기획서대로 개발한 뒤에 내부 테스트를 거쳐서 수정하는 경우가 많은데 이 때는 CSS로 작업하면 확실히 능률적이다. 그렇다고 이것이 CSS와 실무를 벌려놓은 원인은 아니고, 실제로는 기획과 테스트, 수정을 반복할 때 애초의 규칙이 깨지는 경우 다반사기 때문이다. 이것을 예를 들어 얘기하자.

 

블로그 화면의 왼쪽, 혹은 오른쪽에 펼치지는 각종 박스를 보자. 보통 이 박스에는 카테고리, 댓글, 최근글, 트랙백, 달력 등이 있다. 이들의 제목을 CSS로 사용하면 보통 다음과 같이 코딩한다.

 

<style>

.box_title {font-size:12px; font-weight:bold;}

</style>

<div class=”box_title”>카테고리</div>

<div class=”box_title”>댓글</div>

<div class=”box_title”>최근글</div>

<div class=”box_title”>달력</div>

 

박스의 제목에 클래스로 box_title을 주고, CSS에서 box_title의 스타일을 14px로 굵게 처리한 것이다. 즉 어떤 규칙이 있는 박스 제목에 하나의 클래스를 부여하여 동일한 표현 방식을 사용하는 셈이다. 따라서 테스트후에 박스 제목이 너무 작아서 안 보입니다. 글자를 조금 더 키우고 색깔을 붉은 색으로 바꾸죠라는 의견이 나오면 CSS 부분만 아래처럼 바꾸면 된다.

 

<style>

.box_title {font-size:14px; font-weight:bold; color:red;}

</style>

 

이런 식으로 개발 과정에서 테스트 후의 수정이 매우 쉽기 때문에 CSS를 적극 사용할 만하다. 그런데 만약 테스트 과정에서 이런 의견이 나오면 어떻게 될까? 카테고리는 눈에 잘 뛰어야 하니까 파란색으로 바꾸고, 댓글과 최근글은 카테고리보다는 작았으면 좋겠어요. 달력은 배경색깔을 gray(회색)로 바꿨으면 합니다. 이쯤 되면 개발자는 CSS를 포기해야 된다. 만약 굳이 CSS를 쓰겠다면 아래처럼 코딩하면 된다.

 

<style>

.box_title {font-size:12px; font-weight:bold;}

.blue {color:blue;}

.10px {font-size:10px;}

.bg_gray {background-color:gray;}

</style>

<div class=”box_title blue”>카테고리</div>

<div class=”box_title 10px”>댓글</div>

<div class=”box_title 10px”>최근글</div>

<div class=”box_title bg_gray”>달력</div>

 

그런데 이렇게 보면 CSS를 쓰면 더 좋을 것 같지만 실제 파일의 코드 줄이 수백 줄이 넘어가는 상황에서 CSS와 클래스를 서로 찾아가며 바꾸다 보면 장난 아니게 복잡해진다. 또 이런 저런 요구로 클래스명을 남발하면 기존의 아이디나 네임과 뒤섞여서 개발자 스스로도 혼동하게 된다. 그렇다고 처음부터 규칙대로 만들 수도 없다. 어떤 요구가 어떻게 들어올지 모르는 상황에서 어떤 규칙으로 만들 수 있을까? 그래서 평소에 하던 대로 코딩하는 게 더 쉽다. 아래와 같다.

 

<div style=”font-weight:bold; font-size:12px; color:blue”>카테고리</div>

<div style=”font-weight:bold; font-size:10px;”>댓글</div>

<div style=”font-weight:bold; font-size:10px;”>최근글</div>

<div style=”font-weight:bold; font-size:12px; background-color:gray;”>달력</div>

 

이 문제를 참 엉뚱하게 해결했다. 필자가 있던 팀에 두 명의 개발자가 있었는데 한 명은 처음부터 클래스 이름을 부여해 CSS를 떼어놓고 작업했다. 다른 한 명은 바로 위의 코드처럼 HTML 태그 안에 직접 스타일을 삽입하면서 작업했다. 각각이 장단점이 있었는데, CSS를 사용한 경우는 BODY 이하의 내용을 확인하거나 이해하기가 쉬운 반면 바로 바로 수정하기가 힘들었다. 어떤 클래스 이름을 사용했는지 일일이 찾아야 하므로 화면을 위 아래로 정신 없이 움직여 가면서 다른 클래스와 충돌되는지도 확인해야 했다. 이에 비해서 태그를 직접 스타일에 삽입한 경우는 아무 때나 상관없이 즉석에서 스타일 수정이 가능했다. 클래스 찾을 일도 없었고 잘못 들어갈까 봐 고민할 것도 없었다. 대신 BODY 이하 문서가 도대체 뭔지 확인할 수 없었고, 전체적으로 코드가 난잡해졌으며 파일 용량이 커졌다. 그래서 결론을 내렸다. 개발 과정에서는 태그에 직접 스타일을 사용하고, 기획이나 디자인 수정이 거의 완료되었을 때는 CSS로 정리한다. 요컨대 CSS 쓰는 것도 타이밍이 중요하다. 비록 이 책을 읽는 독자 중에 직접 CSS를 건드리는 사람이 몇 명이겠냐만은 그래도 개발자 옆에서 앉아 굼벵이 코딩 보면서 언제 완성돼요? 언제 완성돼요? 언제 완성돼요 답답해하며 가슴을 턱턱 친 경험이 있다면 그들에게 이 책을 권해보자.

 

코딩은 2.0, 디자인은 1.0

개발자 옆에서 갑갑한 기획자 못지 않게 개발자도 하도 진력나서 죽 쑨 인상 쓸 때가 몇 번 있다. 한참 코딩하고 있는데 느닷없이 기획자가 옆에 와서 기획이 조금 수정됐어요할 때(조금이란 단어는 기획자 입에서 나올 때는 대략 10~20%고 개발자 귀에 들어갈 때는 80~90%), 막판에 바빠 죽겠는데 여기 글자 틀렸어요. 여기도 띄어쓰기 해 주세요하며 문법 선생님처럼 굴 때(문법에 관한 한 기획자 왈 아무리 개발자라도 기본적인 문법은 알아야 되지 않나?, 개발자 왈 스토리보드에 있는 대로 똑같이 만들면 꼭 저런다), 그리고 디자이너가 영 엉뚱하게 이미지 잘라줄 때다.

 

개발자와 디자이너가 이미지 커팅 갖고 니가 잘못 잘랐네, 니가 잘못 넣었네 하는 일이야 어제 오늘 새삼스러울 게 없지만 그래도 한솥밥 먹은 지 제법 되다 보니 서로 눈치가 생겨서 대강 여기는 어떻게 넣겠다 하고 잘라주면 대충 맞았다. 필자가 프리챌에 있을 때도 디자인팀과 개발팀 중간에서 그다지 고생한 것 같지는 않았는데 최근 회사에서 이게 문제가 되었다. 개발자가 웹표준을 적용하면서 서로 눈치를 다시 맞춰야 하는 일이 종종 생겼기 때문이다. 예를 들면 네 모서리가 둥근 모양의 박스를 표현할 때 생기는 문제다. 이 박스는 국내의 웬만한 사이트는 거의 표준처럼 돼서 네이버나 다음의 초기화면을 잘 보면 정 사각형 박스와 함께 반반 정도 사용된다. 예전의 경우는 아래처럼 코딩했다.

 

<table width=”200px”>

<tr>

<td><img src=”top.gif” width=”200px” height=”3px”></td>

       </tr>

       <tr>

<td style=”background-image:url(center.gif)”>내용…</td>

       </tr>

       <tr>

<td><img src=”bottom.gif” width=”200px” height=”3px”></td>

</tr>

</table>

 


그림
01 top.gif

사용자 삽입 이미지

그림 02 center.gif

사용자 삽입 이미지

 

그림 03 bottom.gif

사용자 삽입 이미지


테이블을 만들어서 맨 위의 행(TR : Table Row) td(Table Data cell)에 양쪽 상단이 둥근 모서리를 가진, 폭이 200px인 이미지 top.gif[그림 01]를 붙인다. 가운데 행의 td에는 내용을 적는 대신 양쪽만 테두리선을 가진 이미지인 center.gif[그림 02]를 반복시키고, 마지막으로 맨 밑의 td에 양쪽 하단이 두근 모서리를 가진 bottom.gif[그림 03]를 붙인다. 이렇게 하면 가운데 td에서 내용이 늘어나서 세로로 죽 길어져도 박스가 깨지는 일이 없다. 이걸 1.0 방식의 CSS로 표현하면 아래와 같다.

 

<style>

             .box {width:200px;}

             .box_t {background-image:url(top.gif); height:10px;}

.box_c {background-image:url(center.gif);}

.box_b {background-image:url(bottom.gif); height:10px;}

</style>

 

<table class=”box”>

<tr>

<td class=”box_t”></td>

       </tr>

       <tr>

<td class=”box_c”>내용…</td>

       </tr>

       <tr>

<td class=”box_b”></td>

</tr>

</table>

 

테이블에 클래스를 box로 주고 스타일에서 폭을 200px로 고정시켰다. 이와 같은 방식으로 3개의 td에 모두 클래스를 별도로 주고 스타일에서 배경이미지를 삽입한 뒤 높이를 적절히 조절하는 방식이다. 2007 7월 현재 네이버 첫화면이 이런 식으로 둥근 모서리 박스를 처기하고 있다.

 

위의 두 예는 이미지 커팅에서 차이가 나지 않는다. 둘 다 폭이 200px로 고정된 3개의 이미지를 사용한다. 지금도 대부분의 웹에이전시가 이렇게 이미지를 커팅하고 코드를 짠다. 그럼 이걸 웹2.0 방식으로 처리하면 어떻게 될까? 2.0에 대해서 개발적으로 비교적 발빠르게 움직인 포탈답게 다음(daum.net)은 아주 웹2.0스럽게 코딩했는데 이를 보기 좋게 옮기면(말 그대로 보기 좋을 뿐이지 이해가 쉬운 건 아니니 양해바란다) 아래와 같다.

 

<style>

       .box {border:1px solid blue; width:198px;}

       .boxDiv {background-image:url(round.gif); width:6px; height:6px; position:absolute; font-size:1px}

       .top_left {top:-3px; left:-3px;}

.top_right {top:-3px; right:-3px;}

.bottom_left {bottom:-3px; left:-3px;}

.bottom_right {bottom:-3px; right:-3px;}

</style>

 

<div class=”box”>

       <div>내용…</div>

       <div class=”boxDiv top_left”></div>

<div class=”boxDiv top_right”></div>

<div class=”boxDiv bottom_left”></div>

<div class=”boxDiv bottom_right”></div>

</div>

 

그림 04 round.gif

사용자 삽입 이미지

 

위의 코드에서 핵심은 round.gif[그림 04]. 이 이미지는 ¯와 같이 생긴 1px의 푸른색 테두리를 가진 정사각형이다(테두리가 안으로 오목하게 들어가야 한다. 실제로는 매우 작아서 원으로 보이기 때문에 round.gif라 표현한다). 이 이미지 하나를 가지고 포지션을 다양하게 조절하여 네 모서리에 위치시킨다. 이미지를 가운뎃점을 기준으로 수평과 수직으로 나누었을 경우, 이미지의 1/4분면을 박스의 우측하단에, 2/4분면을 좌측하단에, 3/4분면을 우측상단에, 4/4분면을 좌측상단에 배치시키면 된다. 따라서 원래의 이미지는 가로 세로 6px인데, 스타일 속성 중 top, left, right, bottom을 위치에 따라 -3px씩 사용하여 이미지의 분면을 나눈 셈이다. 만약 이미지가 가로 세로 8px이면 -4px로 맞춰야 될 것이다.

 

이까지 읽었다면 재미없는 코드를 끊기 있게 참아준 점에 감사 드린다. 이 책이 장미가족의 태그교실도 아니고 CSS Cookbook도 아닌데 이렇게 자세히 설명하는 데는 이유가 있다. 우선 위에서부터 첫 번째와 두 번째 예는 코딩이 비교적 쉬우면서 직관적으로 이해가 된다. 대신 가로 폭이 유동적일 경우(예컨대 200px 250px로 수정되거나 혹은 100%로 바뀔 경우) 3개의 이미지를 다시 제작해야 된다. 이에 비해 마지막 예는 다소 복잡해 보이긴 해도 이미지를 1개만 사용하고 가로 폭의 변동과 상관없이 표현할 수 있다. 당연히 수시로 변경하거나 유지보수할 때 간편하다. 그런데 웹표준을 지키든 말든 간에 일단은 이미지 커팅이 처음부터 제대로 되어야 한다. 개발자는 웹표준에 따라 마지막 예처럼 코딩했든데 디자이너는 처음 두 예처럼 이미지 3개를 던져버리면 서로가 허탈해진다. 개발자는 개발자 나름대로 웹2.0 정신을 무장해서 웹표준대로 만들어 보려 하는데 디자이너가 안 받쳐준다며 투덜거리고, 디자이너는 디자이너대로 진작에 어떻게 어떻게 원하는지 말해줘야 해주지!하며 맞선다. 이 와중에 기획자는 뭐가 문젠지도 모르고 이미지 자르는 게 뭐가 이렇게 어려워?"하면서 속도가 느리다고 혀를 찬다. 하나의 팀에 웹1.0도 있고 웹2.0도 있고 이 둘 사이를 배회하는 사람도 있다.

 

이 문제를 해결하기 위해 필자의 회사에선 기획자, 개발자, 디자이너가 모두 모여서 CSS를 스터디한 적이 있다. 그런데 이게 쉽지 않다. 우선 우리나라에 기획자는 대부분 인문계 출신이고 HTML의 기본 정도만 알고 있다. 개발자도 적용하기 어려운 CSS를 기획자들이 무슨 수로 이해하겠는가. 게다가 기획자가 CSS로 먹고 살 것도 아니고 누가 물어보는 것도 아닌데 굳이 공부 의욕이 생길 리 만무하다. 디자이너도 마찬가지다. 디자이너에게 HTML은 옵션일 뿐이다. HTML을 잘 다루는 디자이너는 그저 회식 자리에서 노래 잘 부르는 회사원과 같다. 지나가면서 한 마디 칭찬하지만 그저 지나가는 말일 뿐이다. 디자이너는 창조력으로 먹고 살아야 한다. 그러니 원래가 예능계인 디자이너가 숫자와 기호로 가득한 코드와 씨름하고 있자면 크리에이티브가 사라지는 데에 불안해진다. 그래서 이내 포기한다.

 

대기업을 빼고는 이미지 컷팅 가이드란 게 있을 리 없다. 일반적으로 디자이너가 개발자에게 주는 디자인 스타일 가이드가 있는데 이 것처럼 개발자도 디자이너에게 이미지 커팅 가이드를 줘야 한다. 디자이너는 첫화면에서 레이어로 뜨는 모든 박스는 모서리를 둥글게 처리하자고 하면 개발자는 모서리가 둥근 박스는 둥근 모서리 이미지를 1개의 이미지로 붙이고 테두리의 폭과 컬러값을 주시오라고 하면 된다. 요컨대 CSS를 적극적으로 사용해서 웹표준을 구현하려 할 때 개발자 혼자 열심히 뛰어봤자 제 풀이 지치기 마련이다. 디자이너와 기획자와 사전에 자체 표준을 미리 만들어놓고 작업해야 후회가 없다.

 

여기서 잠깐! 둥근 모서리가 있는 박스를 만들 때 아주 예전에는 이미지를 7개나 사용한 적이 있다. 좌상단, 우상단, 좌하단, 우하단, 상단 배경, 가운데 배경, 하단 배경해서 7개다. 어찌보면 웹2.0을 웹1.0을 이미지수로 비교할 수도 있겠다. 1.0에서는 과도하게 많은 이미지를 사용한 반면 웹2.0은 이미지를 최대한 적게 사용하는 식으로 말이다. 그러던 것이 최근에 아예 이미지를 사용하지 않고도 둥근 모서리 박스를 만들 수 있게 되었다. 아마도 디자이너를 상대하기조차 몹시 싫어한(?) 개발자들의 분투가 아닐까 싶다. 다양한 소스가 있으니 마음에 드는 걸 쓰면 되는데 그 중 하나를 소개하면 아래와 같다(잠깐 설명하자면 이렇다. 위에서부터 높이가 1픽쉘인 블록을 차례대로 출력하면서 좌우에 테두리를 준다. 대신 좌우 여백을 줘서 모서리 부근에는 테두리가 안쪽으로 들어가게 만든다. 아래 예에서는 5px에서 시작해서 3px, 1px로 줄어든 것이다. 그 다음엔 내용을 적고 그 밑의 테두리는 위에 했던 것을 거꾸로 반복하면 된다. 이걸 응용하면 못 만들 게 없다).

 

<style type="text/css">

.box b {display:block; height:1px; overflow:hidden; border:blue;}

.box .r1 {background:blue; margin:0px 5px 0px 5px;}

.box .r2 {border-left:2px solid; border-right:2px solid; margin:0px 3px 0px 3px;} 

.box .r3 {border-left:1px solid; border-right:1px solid; margin:0px 2px 0px 2px;} 

.box .r4 {border-left:1px solid; border-right:1px solid; margin:0px 1px 0px 1px;}

.box .content{border-left:1px blue solid; border-right:1px blue solid;}

</style>

 

<div class="box">

<b class="r1"></b>

<b class="r2"></b>

<b class="r3"></b>

<b class="r4"></b>

<div class="content">내용</div>

<b class="r4"></b>

<b class="r3"></b>

<b class="r2"></b>

<b class="r1"></b>

</div>

 

웹은 표준, 워드는 비표준

2.0으로 먹고 사는 사람이 있듯 웹표준으로 먹고 사는 사람도 있다. 그런데 웹표준을 주창하는 사람이 쓴 워드 문서를 보면 전혀 표준스럽지 않을 때가 많다. 하물며 우리네야 어디 문서 작성할 때 스타일이란 걸 한번 제대로 써본 적이나 있는가. 필자도 MS-오피스를 사용한 지 7년만에 올해 초 처음 써봤으니 말이다. 이렇게 평소에도 하루에 몇 번씩이나 열어서 작업하는 오피스에도 스타일을 사용하지 않고 툴바 단추를 이래저래 눌러가며 모든 페이지의 글자와 문단을 일일이 고치고 꾸미고 하는 버릇이 들었으니 어찌 웹표준이 제대로 업무에 녹아 들겠는가. 모름지기 몸이 깨우치기 전까진 아무리 머리 굴려봐야 소용 없는 법이다.

 

2006년 말에 필자도 웹표준과 CSS를 접하면서 워드에도 이런 기능이 있을까 싶어 찾아보니 아니나 다를까 메뉴에 [서식]이 턱 하니 한자리 차지하고 있는 게 아닌가. 평소에 [서식] 메뉴에서 [글꼴]이나 [단락]만 만질 줄 알았지 그 밑에 [스타일 및 서식]은 눌러볼 생각도 못했다. 이런 편리한 기능이 있는 줄 모르고 그간 얼마나 시간을 허비했나 싶어 아찔하기까지 했다. 한 이틀 인터넷 검색하며 써보니 그다지 어렵지도 않았다. 해서 팀원들을 모아놓고 간단하게나마 워드 스타일 강의도 하고 실례도 보여주었다. 그래도 웹표준만큼 자주 재촉 안 해서일까? 몇몇은 금방 원래 자기 방식대로 돌아갔다. 이럴 때면 역시 정치를 잘해야 국민이 행복하다는 생각이 든다. CEO부터 적극적으로 문서 표준을 따르고, 이를 전 사원에게 전파시켜야 하는데 이게 괜한 헛짓 같아서 망설이기 십상이다. 따지고 보면 요즘 닷컴에서 6~7년차 넘어가면 맨바닥부터 땅 파면서 배워온 사람들인데 이런 경험과 노하우를 후배들에게 잘 가르쳐서 똑 같은 오류를 범하지 않도록 해야 된 텐데, 요즘은 후배 가르치기도 어렵고, 가르칠 수도 없고, 가끔은 무섭기도 하다. 겨우 2~3년차 된 사원도 나름대로 인터넷 키드(그 밑으로 디지털 키드는 더 심하다)다 보니 자기도 모르는 것 없다는 거다. 반대로 후배 입장에서도 선배의 주먹구구식 교훈은 들으나마나 해 보일 것이다. 이 바닥이 하도 빨리 변하다 보니 어제의 교훈이 오늘은 타파해야 할 관습이 될 정도니 누구 잘못이라 할 것도 없다.

 

어쨌든 필자가 워드 스타일을 써보니 편리하고, 평소에도 이런 식으로 스타일을 즐겨 사용했다면 CSS로 이렇게까지 고생 안 했을 것도 같고, 또 문서와 관련해서 생기는 여러 잡스러운 일이 한꺼번에 사라지는 것 같아서 지면을 빌려 설명하고자 한다. 이미 스타일과 서식을 사용해서 문서를 작성하고 있는 독자라도 섣불리 다음 페이지를 넘기지 말고 이 페이지 그대로 주변에 보여주자. 본인만 아는 것보다 주변의 동료에게 적극 문서 표준을 퍼뜨리면 확실히 여러 모로 도움된다. 문서를 여러 명이 돌려 가며 자신의 문서에 참조하거나 혹은 다른 사람의 문서를 받아서 하나로 정리할 때는 정말 편하다. 요컨대 이 글 맨 앞에 인용한 대로 스타일과 서식을 쓰면 문서 전체의 일관성을 유지할 수 있고 작업 시간도 단축되며 글자의 크기, 글자체, 배열위치 등을 자유롭게 선택하거나 변경할 수 있으며 유지와 보수도 간편하다.

 

그럼 오피스에서 스타일과 서식을 어떻게 사용할까? 일단은 오피스마다 특성이 조금 다르니 워드만 대상으로 하자(MS-WORD 2003을 기준으로 얘기하겠지만 앞뒤 버전이라고 해서 특별히 다르지 않다). 앞서 얘기했든 스타일을 사용하려면 2가지 방법이 있다. 하나는 툴바의 펼침목록에서 스타일명을 선택하는 것인데, 이 경우는 커서가 위치한 문단이 바로 해당 스타일로 적용된다. 다른 하나는 [서식] 메뉴에서 [스타일 및 서식]을 클릭하면 우측에 작업창이 생긴다. 우선 워드 문서에 아무것도 없는 상태라면 기본 스타일이 보일 텐데, 일반적으로 표준, 제목1, 제목2, 제목3, 하이퍼링크로 되어 있다. 맨 밑에는 사용 가능한 서식을 볼 수 있는 옵션이 있으므로 [모든 스타일]을 선택해서 한번씩 눌러보자. 이것만 해도 스타일을 어떻게 사용하는지 금방 알 수 있다.

 

그 다음은 새 스타일을 만드는 과정인데, 우선은 [새 스타일]을 클릭해서 이름을 입력하고 필요한 서식을 결정한다. 예컨대 인용문이라고 이름 짓고 글꼴을 이탤릭체로 하면 [인용문]이라는 새 스타일이 생긴다. 이제 이 스타일을 적용하고 싶은 문단에 커서를 위치시켜 놓고 [인용문]을 선택하면 그 문단이 이탤릭체로 바뀐다.

 

사실 스타일 사용은 이게 다다. CSS와 똑 같은 것이다. 내용의 특정 문단에 스타일명을 적용하고(CSS CLASS), 스타일 수정(CSS의 경우는 <style>태그 안에 들어가는 스타일 속성 지정 영역)에서 글꼴이나 문단 모양을 바꾸는 것이다. 이후부터는 스타일만 수정하면 된다. 만약 2개의 문서에서 똑 같이 이태릭체로 보이는 인용물을 서로 다른 스타일명으로 지정했더라도 상관은 없다. 복사해서 붙여넣으면 스타일도 같이 따라오므로 하나의 스타일을 선택해서(스타일의 [같은 서식 선택]을 클릭하면 해당 스타일이 적용된 모든 문단이 다중 선택된다) 다른 스타일로 바꾼다. 간혹 블로그 글이나 다른 오피스 문서(엑셀 등)를 워드에 붙여 넣을 때가 곤란을 겪을 때가 있는데 이 때 전체 선택한 뒤에 스타일을 [표준]으로 바꾸면 된다. 그 다음에 적절한 문단을 다중 선택해서 스타일을 입힌다.

 

이 정도는 사실 기초고 실제 업무에서는 수준을 잘 이용하면 좋다. 방법은 절말 쉽다. 원래 제공되는 스타일을 그대로 이용하면 된다. 제목1, 제목2, 제목3은 이미 수준이 1, 2, 3으로 정해져 있기 때문에 가능하면 이걸 그대로 사용한다. HTML 태그에 있는 <H1>, <H2>, <H3> 태그가 이와 똑 같은 것이다. 웹표준에서도 가급적이면 HTML의 기본 태그를 사용하라고 하듯이 워드 표준에서도 굳이 소제목들을 마우스로 긁어가면서 글꼴 키우고 굵게 만들 필요는 없다. 수준을 잘 이용하면 파워포인트의 장표로 바로 적용되기도 하니 괜히 파워포인트에서 장표 만들고 글자나 위치 맞추느라 진땀 빼는 시간도 줄어든다.

 

닷컴에 취직하려면 가장 기본으로 갖춰야 할 것이 검색 능력 오피스 활용 능력이다. 그런데 기획자나 운영자를 뽑을 때는 종종 이런 걸 확인하는데, 개발자나 디자이너는 전혀 상관을 안 한다. 그래서 개발자나 디자이너가 만든 문서를 보면 참으로 한심할 때가 많다. 이걸 공돌이네 그림쟁이네 하며 남 몰라라 할 때가 아니다. 2.0 시대엔 기획자도 따로 없고 개발자도 따로 없고 디자이너도 따로 없다. 하물며 마케터라고 나 몰라라 할 수 없다. 서로 다른 분야의 사람이 한 팀을 이뤄서 프로젝트를 진행하는 방식이 많은 요즘에 문서를 통한 커뮤니케이션이 더욱 중요해지고 있지 않은가. CEO에게 고하건대 복지랍시고 영어 공부시킬 게 아니라 오피스 교육부터 먼저 시켜야 된다.

 

1.5 최적

모름지기 체하지 않으려면 천천히 꼭꼭 씹어 먹으면 된다. 업무 방식은 1.0이고 요구하는 것은 2.0이니 1.5 정도에서 시작하고 만족하면 된다. 섣불리 앞서려고도 하지 말고 뒤늦게 쫓으려고도 하지 말자. 똑게똑부 멍게멍부라 했다. 누가 뭐래도 똑똑하고 게으른 사람이, 멍청하고 부지런한 사람보다 난 법이다.

 

-김철수 인터넷 연구소