웹 사이트 물려받기: 웹 사이트를 유지보수 가능한 상태로 만들기지나친 부담감 없이 다른 누군가의 웹 사이트를 받아서 유지보수하는 방법  |
 |
|
난이도 : 중급 Brett McLaughlin, 저자 겸 편집자, O'Reilly Media Inc. 2008 년 5 월 20 일 완벽한 세상에서 여러분은 지금까지 할당된 모든 웹 사이트를 직접 유지보수하고, 개선하고, 새로 설계할 것입니다. 불행하게도 현실 세계에서는 여러분은 종종 누군가 다른 사람이 설계했거나 만든 사이트를 이어 받아야 할 경우가 생깁니다. 새로운 직업, 새 프로젝트, 새로운 책임감은 모두 위험을 안고 다가온다. 새로운 상사, 새 사무실, 새 동료를 맞이하는 동안, 이제 여러분이 보살피고 먹여살릴 웹 사이트를, 어떻게 서로 연결되어 있는지 아무런 힌트도 주지 않고 넘기는 행위보다 더 치명적인 위협은 없다. 종종 특히 경험이 부족한 웹 디자이너나, 더 나쁘게 단순히 내용을 "채워넣기에 급급한" 누군가가 만든 사이트를 넘겨 받으면 내용, 표현, 심지어 몇몇 활동이 뒤죽박죽된 유산을 상속받는 셈이다. 물론 페이지는 추하게 보인다. 다행스럽게도 이런 페이지를 깔끔하게 조율되고 쉽게 유지보수가 가능한 웹 사이트로 변신하게 만드는 논리적인 접근 방법이 존재한다. 2부로 나눈 이 글은 엉망진창이고 다루기 힘든 페이지를 제대로 구조화되고 조직화되고 유지보수 가능한 코드로 바꾸는 로드맵을 제공한다. 1부에서 사이트를 유지보수 가능하게 만드는 방법을 배운다. 2부에서 사이트 레이아웃을 조직화하고 효율을 높이고 통제하에 놓여있는지 확인할 것이다. 몇몇 유효성이 증명된 기법이 이런 복잡한 작업을 관리 가능하게 만들며, 성공을 넘어서 탁월한 위치에 이르게 만든다. 이런 기법은 또한 사이트를 연결하는 데 투입되는 시간을 최소로 줄이고, 개선하고, 유지하는 과정에 투입되는 시간을 최대로 높이도록 만든다. 이런 방식으로 만든 사이트를 나중에 새로 단장하거나 심지어 디자인을 새롭게 할 기회가 생기면, 뒤얽힌 스타일로 범벅된 HTML 대신에 잘 나눠진 HTML과 CSS에서 시작할 수 있다. 다른 사람 작업을 이어받은 다음에 가장 먼저 해야 할 일은 정확하게 자신이 소유한 페이지가 어떤지 확인하는 작업이다. 본능적으로 (Windows®용) 노트패드나 손에 익숙한 편집기를 사용해서 바로 작업을 진행하고 싶을 것이다. 하지만 이 시점에서 무턱대고 수정 작업을 하면 상황을 더 꼬이게 만든다. 무엇을 다뤄야 하는지 이해할 필요가 있으며, 5분이나 10분 정도 살펴보면 좀 더 많은 지식이 쌓일 것이다. 웹 브라우저로 사이트를 열어 보자. HTML과 CSS를 강제로 열지 말고, JPG나 GIF로 저장된 이미지인지 걱정하지 말고 단순히 사이트를 열어보자. 노트패드를 모니터에 띄워놓고, 여러분이 목격한 상황을 갈겨쓰자. 하지만 가장 어려운 주문이지만, 큰 그림에 초점을 맞추자. IE7에서 테이블 사이에 한 픽셀짜리 공백이 보여도 참고 넘어가자. 그 대신 초기에 받은 인상을 기록하자. 상단 배너가 페이지를 압도하고, 수직 스크롤이 짜증나고(항상 그렇긴 하지만!), 기타 등등 말이다. 여기서 요점은 여러분 HTML을 바꿀 작은 항목을 스무 단계로 나누는 데 있지 않다. 단지 전반적인 인상을 파악할 뿐이다. 이 사이트를 좋아하는가? 싫어하는가? 내용이 너무 많은가? 이미지가 흐릿한가? 사이트 디자인 과정에서 반드시 수행해야 하는 아주 일반적인 옵션으로 채워넣어야 한다. 구현 부분을 조금 다루더라도, 전체 그림을 얻기 위한 준비 절차에 그쳐야 한다. 이 단계에서 여러분은 또한 진행해야 할 디자인 작업이 많지 않다. 사이트가 여기서 멋지게 보인다면, 작업은 훨씬 더 쉬워진다. HTML이나 CSS를 파고 들기 앞서 사이트를 점검하도록 권장하는 이유가 바로 여기에 있다. 많은 사이트가 구현 과정에서 재앙이 닥치지만 사이트 자체는 멋지게 보인다. 거꾸로 뒤집어보면, HTML과 CSS로 뒤죽박죽된 장면을 목격하고 사이트를 살피다 보면 관점이 흐려지고, 사이트 구현이 여러분 입맛에 맞지 않기 때문이라는 이유로 필요도 없는 디자인을 다시 할지도 모른다. 사이트를 먼저 살펴보고, 결정을 내리고, 그 다음에 HTML과 CSS를 파고 들자. 코드로 파고 들기 전에 웹 페이지 유효성을 확인한다는 한 단계가 더 남아있다(물론 이 단계는 구현에 확실히 한 걸음 다가가도록 만들어준다). 유효성은 웹 페이지가 HTML인지 XHTML인지, 여러분 페이지가 순응해야 할 명세가 어떤 버전인지 살펴보는 작업이다. 일반적으로 여러분 웹 페이지가 이미 따르는 명세를 그대로 이어가기를 원할 것이다. 여기서 명심해야 할 목표는 노력을 줄이는 데 있다. 최대한 빨리 사이트 유지보수를 하고 싶으며, 합리적인 수준에서 최소한의 노력으로 사이트를 확장하고 싶기 때문이다. 사이트를 다시 디자인한다면, 여러분이 가장 편한 기술로 이동하기를 원할지도 모르겠다. 예를 들어, 여러분이 XHTML 전문가라면, 이 사이트를 XHTML로 바꿀 수 있는데, 여러분이 선택한 표준이기 때문이다. 하지만 목표가 효율성이라면, 페이지를 현재 형식으로 유지하는 정책을 따르는 방법이 최선이다.
W3C 마크업 유효성 검사기(참고자료 참조)를 사용해 사이트 URL을 입력한다(그림 1 참조). 그림 1. W3C 유효성 검사기  유효성 검사기는 파일을 올릴 수 있을 뿐만 아니라 기존에 구축한 사이트도 처리할 수 있다. 그림 2. 유효성 검사 결과 요약  이 경우, 유효성 검사기는 여러분 페이지의 인코딩과 doctype을 찾아내며, 이를 통해 다시 유효성 검사를 진행한다. 유효성 검사기는 심지어 여러분 페이지에 일치하는 doctype이 없을지라도, 여러분의 페이지가 무엇인지 최선을 다해 감지해내려고 노력한다. 여러분이 XHTML 1.0으로 doctype을 지정했는데, 페이지가 실제로는 HTML 4.01 transitional이라면, 유효성 검사기는 이 사실을 알려준다. 임의의 doctype을 일치시키려고 노력하는 대신(아마도 지나치게 열성적인 웹 디자이너가 미리 입력했을지도 모르겠다), 유효성 검사기가 여러분 페이지가 무엇인지 알려주는 정보로 시작한다. 이게 가장 효율적인 접근 방법이며, 유지 보수 가능하고 유효한 사이트를 재빨리 만드는 과정에서 도움을 줄 것이다. 페이지가 무엇인지 추측하는 작업 이외에, 유효성 검사기는 이런 추정에 기반을 두고 오류를 보고한다. 특히 사이트를 넘겨받았을 경우는 물론이고 거의 모든 경우에, 여러분 앞에 펼쳐진 페이지가 얼마나 제대로 유지되고 있는지 확신하지 못하면 오류가 존재할 것이다(그림 3은 그림 2에서 나타나지 않는 여러 오류를 보여준다). 그림 3. 유효성 오류  다시 한번 말하지만, 실행이 어려운 충고 하나를 제시한다. 바로 이런 오류를 수정하려고 서둘지 말자. 여러분이 수정하고 싶어한다는 사실을 너무나 잘 알고 있다. 하지만 핵심은 다음과 같다. CSS가 HTML에서 분리되어 있지 않고 행 분리( 이런 단계에서 목표는 여러분이 무엇을 추구하는지 생각해내는 데 있다. 여러분 페이지가 XHTML 1.0을 목표로 하면, 아마도 쉽게 XHTML 1.0으로 돌아갈 수 있을 것이다. 또한 가정을 한 가지 하자. 디자이너가 어떤 이유에서인지 XHTML 1.0을 선택했다면, 여러분이 정확한 이유를 모를지라도 이런 판단을 계속 따르는 편이 안전하다. 여러분 사이트가 기본적으로 가장 느슨한 표준인 HTML 4.01 transition로 되돌아간다면, 어찌되었거나 문제는 없다. 충족해야 하는 기준이 낮기 때문이다. 여기서 제시하는 아이디어는 원래 디자이너가 어떤 요구사항을 받았는지 무관하게 이를 충족하는 설계와 구현 양쪽에서 튼튼한 사이트로 가는 최단거리를 찾는 작업이다. 종종 이런 요구사항이 무엇인지 모를 경우에는 유효성 검사가 바로 역공학을 가능하게 만드는 한 가지 방법이다. 지금까지, 여러분이 유효성 검사기를 수동으로 돌려 사이트에 존재하는 페이지를 모두 하나씩 차례로 돌려봐야 한다고 가정했다. 궁극적으로는 모든 페이지에서 모든 오류를 검출하며, 각 페이지에 적절한 주의를 기울이도록 만드는 방법이 최선이다. 첫 몇 페이지로 작업하다 보면, 종종 (예를 들어 대규모 치환을 통해 헤더 섹션을 변경하는 작업과 같이) 전체 사이트에 적용할 변경 사항이 나오는데, 이를 활용하면 나중에 페이지를 수정하는 작업이 쉬워진다. 하지만 효율성을 강조하면, 유효성 검사를 일괄 작업으로 처리할 필요가 있다. 이런 경우에는 여러분은 W3C 유효성 검사기를 벗어나서 (엄청나게 뛰어난 기술은 아니지만 그럭저럭 쓸만한 기술로 여러 URL을 텍스트 박스에 입력하도록 만들어주는) WDG HTML 유효성 검사기나 (일괄 작업을 수행하도록 만드는 저렴한 프로그램인) CSE HTML 유효성 검사기로 눈을 돌려야 한다(참고자료 참조). 유효성 검사를 일괄 처리할 경우 시간을 절약할지는 몰라도, 대규모 사이트를 다루다 보면 수천 개는 아니더라도 수백 개가 되는 오류에 직면하기 때문에 세부 내역을 놓치기 쉽다는 문제점이 생긴다. 여러분이 대다수 웹 개발자와 같다면, 유효성 검사는 아무리 잘 봐줘도 성가신 존재고, 눈 밖에 나면 끔찍한 악몽이다. 우선 페이지를 유효성 검사기로 돌려야 하며, 수백 개가 넘는 붉은 색 오류 메시지가 나오는데, 사람을 압도해버린다. 하지만 유효성 검사를 하면 페이지 유효성 검사에 들인 노력을 충분히 보상받는 몇 가지 장점이 따라온다. 먼저, 유효한 페이지는 화면에 제대로 출력된다. 유효하지 않은 페이지는 종종 닫는 태그가 빠져 있으며, 부적절한 HTML 태그가 중첩되어 있으며, 심지어 CSS 스타일 태그에 문제도 있다. "있으면 좋은" 항목이 아니라 기대하는 바대로 페이지를 출력하기 위한 사이트 필수 항목이다. 추가적으로, 유효성 검사는 여러분이 페이지에 가한 변경과 갱신을 항상 점검하는 기능적인 기준점을 제공한다. 페이지가 유효성 검사를 통과한 상태에서 갑자기 유효성이 깨진다면, 단순히 점검하지 않은 변경 내역뿐만 아니라 구조나 심지어 사이트 표현 방법을 엉망으로 만든 원인이 무엇인지 알게 된다. 따라서 코드를 매번 변경한 다음에 컴파일하듯이 유효성 검사를 점검 기능으로 생각하기 바란다. 컴파일(또는 유효성 검사)이 실패하면 뭔가 잘못된 상황이다. 마지막으로 구글, 야후!, MSN과 같은 검색 엔진이 유효한 페이지를 좀 더 쉽게 색인하는지에 대해서는 의견이 분분하다. 이런 검색 엔진이 사용하는 알고리즘은 아주 비밀스럽고 계속 바뀌므로 유효성 검사가 관련이 있다고 말하는 문서를 찾더라도 내용이 바뀌는 바람에 소용이 없어졌다고 말할지도 모르지만, 검색 점수나 색인 결과를 높이는 작용을 한다. 결론은 검색 엔진 개발자가 아닌 이상 우리는 내부 사정을 모르지만 (유효성 검사를 통해) 구조적이고 적절히 출력되는 페이지를 사람들이 좀 더 많이 방문하므로 어떤 검색 순위에서도 상위에 나타나리라 기대한다.
이 시점에서 전반적인 사이트 디자인과 (HTML, XHTML 등) 사이트 설계를 위한 명세 지식을 확보했을 것이다. 이제 마지막으로 사이트 자체를 바꿀 시간이 왔다.
HTML transitional, HTML strict, XHTML transitional, XHTML strict 중에 무엇을 택하거나, 페이지에서 스타일을 뽑아내어 외부 CSS 스타일시트로 이동해야 한다. 내용에 표현과 스타일을 섞어 놓은 상황에서, 쉽게 유지보수가 가능한 일관성 있는 사이트를 만드는 간단한 방법은 없다. CSS와 HTML 분리에 대한 수많은 기사가 웹에 올라와 있으므로 따분한 세부 사항으로 독자들을 괴롭히지는 않겠다(참고자료 참조). 하지만 반드시 지켜봐야 할 몇 가지 항목을 여기에 정리해보았다.
작업을 끝내고 나면 HTML 상단은 다음과 같이 보여야 한다.
이 예제는 다중 스타일시트를 포함한다. 핵심 외향과 느낌에 추가해서 사이트의 특화된 영역이 있다면, 다중 스타일시트를 권장하지만, 이는 어디까지나 선택이다. 일단 모든 스타일을 HTML 바깥으로 몰아내었다면, CSS 스타일시트가 하나 이상 만들어진다. (CSS 스타일 시트(CSS stylesheet, cascading style sheet stylesheet)라는 이름이 역전앞 거지라고 들리는 사실을 알고 있다. 하지만 어떻게 표현할지 특별한 생각이 없으므로 우스개소리를 계속 즐기기 바란다.) 각각을 골라서 하나씩 각개격파하자. 예를 들어 다음과 같은 스타일 시트가 있다면,
압축해서 다음과 같은 스타일 시트를 고려해보자.
크게 어려운 내용은 없지 않은가? 좀 더 현실적인 사례를 고려해보자. 이런 문제를 해결하는 한 가지 방법으로 선언을 알파벳 순서로 만든다. 물론 고통스럽긴 하겠지만, 비슷하게 다음과 같은 선언을 한번 생각해보자.
공통 엘리먼트를 제거해서 중앙으로 모아야 한다.
이렇게 해도 선언 두 가지가 여전히 존재하지만, 그래도 한 곳에서 공통 부분을 찾을 수 있다(이 경우에는 h1). CSS 스타일 시트를 훑어보면서 가능한 최고로 조율을 끝내도록 노력하자. 여러분이 만든 규칙을 압축해 대다수 중복을 제거하고, 가능한 규칙을 위로 끌어 올려 정리하자. 예를 들어, 모든 최상위 엘리먼트에 Georgia로 글꼴 설정을 했다면, 이 규칙을 여기에 두통거리를 줄여주는 선택적인 단계를 제시한다. 일단 CSS 준비가 끝나면, 유효성을 검사한다(그림 4 참조)(참고자료 절에서 CSS 유효성 검사기 링크를 찾아본다). 페이지 유효성 검사기와 마찬가지로, CSS 유효성 검사기는 CSS가 제대로 되어 있는지 확인해준다. 현재 구문 오류도 없고 오탈자도 없다(그림 5 참조). 그림 4. CSS 유효성 검사기  그림 5. 성공적인 CSS 유효성 검사 결과  전체 페이지가 유효하다고 확신하는 경우와 비교해서 CSS 유효성은 기술적으로 그렇게 중요하지 않다. 실제로, 유효하지 않은 CSS가 담긴 유효한 HTML(또는 XHTML) 웹 페이지가 존재할 수 있다. 하지만 여전히 CSS 유효성 검사는 모든 사항을 멋지고 깔끔하게 유지하므로 수작업을 통해 CSS를 최적화하도록 만들자.
여러분의 사이트에 다시 한번 유효성 검사를 수행할 시간이 왔다. 이제 많은 오류가 사라졌으며 CSS는 HTML에서 밖으로 빠졌다(그리고 깨끗하게 정리되어 유효성 검사도 끝났다). 이제 여러분이 작업한 내용을 문서로 만드는 작업을 잊어버리지 말자. 아직 doctype이 없다면, 문자 인코딩 정보와 더불어 추가할 필요가 있다. 이렇게 하면 다음 사람이 유지보수하기가 훨씬 쉬워진다. 유효성 검사기에서 결과를 얻을 때, doctype에 초점을 맞추자(그림 6 참조). 이 결과는 유효성 검사기가 최선을 다해 추측한 결과에 따라 여러분에게 웹 페이지가 무엇을 목표로 하며 어떤 버전인지 알려준다. 그림 6. 유효성 검사기가 doctype을 추측하려고 시도하는 모습  이 경우에, 페이지는 아마 XHTML 1.0 Transitional일 가능성이 높다. 이는 초기에 유효성 검사기를 돌렸을 때 얻은 결과와 다를지도 모르지만, 거의 같다(CSS는 일반적으로 HTML과 XHTML 비교에 영향을 미치지 않는다). 물론 지금 당장은 유효성 검사기가 (대다수 경우에) doctype을 추측하고 있다. 하지만 doctype 선언을 추가해서 이런 추측을 공식화한다. HTML을 열어서 상단에 다음과 같은 내용을 추가하자.
이 예제는 XHTML 1.0 transitional이다. XHTML 1.0 strict라면 다음과 같이 추가한다.
HTML 4.01 transitional은 다음과 같이 추가한다.
HTML 4.01 strict는 다음과 같이 추가한다.
HTML doctype에서는 이 모든 내용은 유효성 검사기뿐만 아니라 여러분의 웹 사이트를 이어받을 다른 사람에게 여러분 문서의 목표가 무엇인지 선언한다. 유효성 검사기를 다시 한번 돌릴 수 있는데, 유효성 검사기가 추측한 여러분 페이지의 목표와 일치하지 않도록 엉터리로 doctype을 지정하지 않은 이상 큰 차이는 느끼지 못할 것이다. 다시 한번 오류가 발생할 수 있다. XHTML doctype 중 하나를 사용했다면, 간단한 단계 하나를 더 밟아야 한다. 이 문서에 content type을 지정하는
이는 유효성 검사기(아니면 XHTML 순응 웹 브라우저와 같은 기타 프로그램)가 내용을 읽을 때 무엇을 기대할지 알도록 만든다. HTML 페이지에도 content type을 추가할 수 있지만, HTML 4.01 strict에서만 필요한 내용이다. (HTML에서
CSS와 HTML을 분리했으며, 어떤 HTML/XTHML 버전을 사용하는지 이해하고, doctype과 content type을 지정하고 나면, 미뤄뒀던 오류를 정리할 준비가 되었다. 다시 한번 유효성을 검사하자. 무엇을 목표로 했는지 명세했으므로 오류를 잡기 시작한다. 그림 7은 HTML 문서에 등장하는 전형적인 문제를 보여준다. 그림 7. 한번에 오류 하나씩 고치기  이 정도 오류는 고치기가 아주 쉽다. 이 페이지에는 일단 첫 오류를 수정했으면, 계속해서 유효성 검사를 진행하자. 시간을 소비해서 오류를 수정하고 유효성 검사를 하고 다른 오류를 잡는 반복적인 작업이 조금 짜증나겠지만 유효성 검사기를 사용하는 가장 효과적인 방법이다. 오류 하나는 다른 오류를 줄줄이 달고 나오므로 오류 하나를 수정하면 여러 오류가 사라지므로 9개나 10개 정도만 수정하면 작업이 끝나게 된다. HTML 편집기와 여러분 사이트용으로 하나, 유효성 검사기용으로 하나씩 브라우저 창(또는 탭)을 두 개 띄워놓기 바란다. 오류를 수정하고 나서 편집기로 파일을 저장하고, 양쪽 브라우저 탭에서 새로 고침 버튼을 눌러 갱신된 사이트와 유효성 검사 보고서를 살펴본다. 유효한 페이지를 얻었다면, 이 버전을 잠글 필요가 있다. 백업하고, ZIP 드라이브나 USB 메모리에 복사하자(물론 큰 글씨로 메모를 적어 여러 장소에 분산해 놓아야 한다). 이런 식으로 사이트를 위한 기준점을 확립했다. 이제 변경할 때마다 다음과 같은 몇 가지 작업을 수행해야 한다.
이 기사는 (대다수 담당자 입장에서) 따분하고 지루한 과업에 초점을 맞추며, 웹 사이트가 실제로 보이는 방법에 영향을 미치는 내용은 거의 다루지 않는다. 이렇게 하는 이유는 선행 지식이 없는 상황에서도 사이트를 유지 보수 가능하게 만들기 위해서다. 뭔가 개선점을 찾는 대신 업무 부하를 줄이려고 노력하는 경우가 있다. 디자인 변경을 하고 싶다면 그렇게 하자. 하지만 출발점을 잘 닦아 놓았으므로, CSS를 정리하고 XHTML을 사용할지 아니면 HTML strict를 사용할지 아니면 다른 뭔가를 사용할지 고민하면서 디자인 작업에 들어가는 대신 원래 업무에 집중할 수 있다. 사이트 개선을 원하지 않더라도 어쨌거나 작업은 마친 셈이다. 여러분에게는 유효한 사이트가 있다. 하지만 더욱 중요하게, 이 사이트를 유지 보수 가능하게 만들었기에, 문제가 생겨도 찾아서 수정하기가 쉬울 것이다.
명백히 다른 누군가의 웹 사이트를 다루는 작업은 그리 유쾌하지 않다. 디자인, (잠재적으로 잘못된) HTML과 CSS 선택, 색상, 마크업과 구조 선택에 발목이 잡힌다. 따라서 주기적인 유지 보수를 하기 위해 들어가는 시간을 최소로 소비하며, 사이트 디자인 개선과 다른 즐거운 작업에 자신의 시간을 투입하도록 만드는 목표가 핵심이다. 이렇게 하기 위해 주어진 사이트와 안정적이고 이해도가 높은 사이트 사이에 벌어진 격차를 줄이는 최단 거리를 찾아내는 방법이 최선이다. 이는 사이트 상태가 어떤지, 어디로 가야 하고, 도착을 위해 어떤 단계를 밟아야 할지를 인식함을 의미한다. 이 기사는 여러분이 물려받은 사이트가 디자인 대상을 차지하는 대신, 디자인 승부사들이 작업하기 쉽게 만드는 목표로 작성했다. HTML이든 XTHML이든 strict든 tranditional이든 현존하는 사이트 형식을 따라서 완벽하게 CSS와 HTML 구현으로 바꿔 놓으면 중장기적인 관점에서 상당한 시간을 절약할 수 있다. 이 기사 2부에서는 속력, 접근성, 조직성을 소개할 것이다. 여러 가지 다양한 고려 사항이 있지만, 단순한 유지보수라는 목표는 동일하다. 따라서 화끈하고 새로운 디자인을 할 때 두통거리를 없애려면 웹 사이트를 미리 손봐놓자. 다음 달에 더 많은 내용으로 돌아오겠다. 교육
제품 및 기술 얻기
토론
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
