옛날에는 비주얼 HTML 편집기가 큰 인기를 끌었습니다. 브라우저처럼 생긴 프로그램을 열고 소스 코드나 스크립트, 디자인까지 깊이 신경 쓰지 않은 채 그저 페이지를 작성하면 되었죠. 마법은 화면 뒤편 어딘가에서 일어났습니다. 그러다 서서히 온라인 CMS가 등장하기 시작했고, 결국 오늘날의 표준이 되었습니다. 하지만 여전히 웹 콘텐츠를 오프라인에서 작성하고 싶다면 어떻게 해야 할까요?
다소 역설적으로 들릴 수 있습니다. 어차피 언젠가는 결과물을 업로드해야 할 테니까요. 그럼에도 오프라인 방식으로 작성할 수 있다는 데에는 분명한 장점과 편리함이 있습니다. 더구나 CMS를 전혀 사용하지 않는다면 순수 HTML을 직접 작성하는 일은 꽤 지루한 작업이 됩니다. 훌륭한 프런트엔드가 있다면 '기계가 무엇을 해석하고 표시할까'보다는 '사람들이 무엇을 읽길 원하는가'에 집중할 수 있죠. 문제는 2018년 시점에서 이것이 얼마나 어려운 일이냐는 것입니다.
당신을 위한 HTML 편집기들
한때는 수십 가지의 WYSIWYG 편집기가 저마다 매력적인 기능을 선보였지만, 동시에 각자의 비일관성, 엉망진창 코드, 미완성 기능도 함께 안고 있었습니다. 필자는 2006년에 오래된 Nvu를 접했고, KompoZer가 등장하자 이것으로 갈아탔으며, 그 후로 줄곧 어떤 형태로든 이를 활용해 왔습니다. 코드 걱정 없이 글을 쓸 수 있는 단순함 덕분이었죠. 다른 어떤 프로그램도 따라올 수 없는 실용성이 있었습니다. 그러나 KompoZer는 오랫동안 업데이트되지 않았고, 새로운 활력이 필요한 상황입니다. 그렇다면 지금 선택 가능한 것들은 무엇일까요?
Bluefish
오랫동안 존재해 온 프로그램입니다. 하지만 순수한 WYSIWYG 편집기는 아니며, 사실상 일반 텍스트 편집기와 크게 다르지 않습니다. 할 수 있는 최선은 외부 브라우저를 실행해 미리보기를 보여주는 정도입니다. 나쁘지 않아 보이지만, 결국 Bluefish는 다소 투박하고 기술자 취향의 느낌이라 간단한 글쓰기 용도로는 적합하지 않습니다.
게다가 사용 중 여러 가지 문제에 부딪혔습니다. 예컨대 출력 관련 하위 메뉴가 매우 풍부해서 코드 유효성 검사, HTML→XML 변환, HTML 정리(Tidy) 등을 지원한다고 하는데, 정작 시스템에 Tidy가 설치되어 있는데도 실행에 실패했습니다.
Brackets
현대적이고 세련되지만 어쩐지 다소 압도적이라는 표현이 Brackets를 설명하기에 가장 적절합니다. 2015년 OCS-Mag의 HTML 편집기 특집에서도 이 프로그램을 상세히 다룬 바 있습니다. 클래식한 글쓰기의 세계와 메타데이터가 넘치는 최신 코딩의 세계를 잇는 도구로, 초심자보다는 숙련된 사용자를 겨냥한 설계입니다. 라이브 미리보기 기능이 있긴 하지만, 작성 중인 페이지의 실제 모습을 제대로 보여주지는 못합니다. 결국 우리가 찾는 것과는 거리가 있습니다.
BlueGriffon
오래된 Nvu 편집기의 후속작입니다. Nvu는 KompoZer로 포크되기도 했는데, KompoZer는 이미 개발이 중단된 지 오래지만 적어도 Windows 버전은 여전히 쓸 만합니다. Linux에서는 구버전 라이브러리가 필요해 번거로울 수 있습니다.
BlueGriffon은 외모부터 제격이고 HTML5도 잘 처리합니다. 전반적으로 꽤 깔끔한 옵션들을 갖추고 있으며, 사실상 남은 유일한 진짜 WYSIWYG 편집기라고 할 수 있습니다. 대체로 해야 할 일은 해내고, 코드 수준의 문제는 신규 사용자가 눈치채기 어렵겠지만, 필자는 오프라인 HTML 편집기에 미래가 있는지 의문이 드는 여러 문제들을 경험했습니다.
BlueGriffon에는 눈에 띄는 사용성 문제들이 있습니다. 이미지를 추가하거나 다른 문서로 링크할 때 기본값이 상대 경로가 아닌 절대 경로로 설정됩니다. 그래서 매번 번거롭게 추가 클릭을 해야 하고, 깜빡하면 페이지가 깨져 버립니다. 예를 들어 현재 작성 중인 파일과 같은 디렉터리에 있는 dedoimedo.html로 링크한다고 해봅시다. 상대 경로로는 a href="dedoimedo.html"이 완전히 유효한 링크이며, 두 파일이 같은 디렉터리에 있기만 하면 잘 작동합니다. 반면 C:\dedoimedo\dedoimedo.html 같은 절대 경로는 온라인에서는 무의미하며, 로컬 컴퓨터 밖에서는 어디서든 깨져 버립니다.
매번 수동으로 체크박스에 표시해야 합니다. 또 BlueGriffon은 KompoZer만큼 단축키를 활용하지 않습니다. 링크 삽입, 이미지 삽입, 맞춤법 검사 호출을 위한 단축키가 전혀 없죠. 마우스 가운데 버튼 클릭도 아무 유용한 동작을 하지 않는데, KompoZer에서는 탭(문서)을 열고 닫는 등 현대 브라우저답게 작동합니다. 텍스트 일부를 선택해 스타일을 적용하려면 먼저 span으로 정의한 뒤 클래스/스타일을 적용해야 하는 반면, KompoZer는 이 과정을 자동으로 처리해 클릭과 마우스 조작을 줄여줍니다. 마지막으로 BlueGriffon도 코드를 변경하는데, 이에 대해서는 뒤에서 다시 다룹니다.
SeaMonkey (Composer)
BlueGriffon이 '남은 유일한 진짜 WYSIWYG'라고 말씀드렸는데, 사실 약간 과장이었습니다. 현재 활발히 개발·지원되는 가운데 제가 테스트한 범위에서는 두 개가 존재합니다. 단, 둘은 아주, 아주 밀접하게 연관되어 있죠. 만능 멀티플레이어인 SeaMonkey 스위트에도 Composer(KompoZer와 혼동 주의)가 포함되어 있으며, BlueGriffon과 비슷한 기능을 약간 다른 외형으로 제공합니다.
장단점도 본질적으로 같습니다. HTML5 지원과 이미지 관련 문제까지 포함해서요. 다만 문제가 나타나는 방식이 조금 다릅니다. 어떤 페이지에서는 새 이미지를 아예 링크하지 못하고, 어떤 페이지에서는 항상 file:/// 접두사가 붙은 절대 경로로 시작하며 Relative URL 체크박스가 회색으로 비활성화됩니다. 실제로 작동하게 하려면 URL을 수동으로 편집해 상대 경로가 아닌 부분을 제거해야 합니다. 느리고 번거로운 작업이죠. 게다가 SeaMonkey에는 원본 소스 서식을 유지하겠다는 버튼이 있음에도 실제로는 그렇게 동작하지 않습니다. 코드 변경에 관해서는 잠시 후 더 설명하겠습니다.
전반적으로 의외로 투박한 옵션들이 있었는데, 이는 KompoZer에서 오래전에 해결된 것들이라 더욱 이상하게 느껴졌습니다. Linux 설치에는 몇몇 32비트 라이브러리가 필요하며, 없으면 다음과 같은 오류가 발생할 수 있습니다.
XPCOMGlueLoad error for file /home/roger/Downloads/seamonkey/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
필자에게 필요한 라이브러리 전체 목록(의존성 자동 해결 포함)은 다음과 같습니다. 64비트 openSUSE KDE, Kubuntu, Ubuntu에서 여러 형태로 테스트했습니다.
libgtk-3-0-32bit libgthread-2_0-0-32bit libXt6-32bit
KompoZer
오래되고 믿음직한 일꾼입니다. KompoZer는 HTML5와 CSS3를 지원하지 않으므로 최신 코드를 불러오면 화면이 어색해 보일 수 있습니다. 반면 워크플로우는 단연코 가장 매끄럽습니다. 단축키, 상대 링크 등 다른 프로그램들이 놓친 편의 기능들을 갖추고 있죠. 최신 릴리스는 2007년, 베타 버전은 2010년 것입니다. 놀랍죠.
HTML Tidy
이 주제에 대해 필자는 거의 10년 전인 2009년에도 글을 쓴 적이 있습니다. 당시 HTML Tidy의 놀라움을 소개했는데, Firefox 확장(그 좋던 시절!)과 Notepad++ 플러그인 등 다양한 형태로 제공되었습니다. GUI도 있었고 CSS를 다듬는 별도 도구도 있었죠. 선택지가 무척 많았습니다.
2018년에는 상황이 조금 다릅니다. 원조 Tidy는 한때 사실상 죽었지만, 최근 HTML5 호환에 초점을 맞춰 부활했습니다. 이제 독립 실행형 프로그램과 로더블 라이브러리(DLL)로 존재하며, Notepad++ 플러그인으로는 Tidy2라는 이름으로 설치할 수 있습니다.
설치 문제
하지만 '깔끔한 코드의 희망봉'까지 순항지만은 아닙니다. 새 Tidy가 얼마나 잘 작동하는지 확인하고 싶었습니다. Linux에서는 이미 구버전 Tidy가 설치되어 있어서 새 버전을 설치하려면 강제로 제거하고 관련 라이브러리도 정리해야 했습니다. 다행히 모두 저장소에서 제공되므로 크게 고생할 일은 없습니다.
Windows에서는 독립 실행형과 DLL 모두 잘 작동합니다. Notepad++에서는 32비트 버전에서만 플러그인을 사용할 수 있습니다. 구버전 HTML Tidy는 완전히 깨져 있어 실행하려고 하면 Notepad++가 비활성화합니다. 새 버전을 얻으려면 먼저 텍스트 편집기를 최신 버전으로 업데이트한 뒤 플러그인 관리자로 tidy-html5 기반의 Tidy2를 설치해야 합니다. 이렇게요.
KompoZer를 통해서도 독립 실행형 버전을 필요할 때 사용할 수 있습니다. 다소 이상하게 들리겠지만 KompoZer에는 자체 확장 기능이 있으며, 그중 하나인 HandCoder는 Tidy 실행 파일을 요청 시 호출할 수 있습니다. 기술적으로는 경로를 어떤 버전의 Tidy로든 설정할 수 있어, 최신 빌드(테스트 당시 2017년 11월판)까지 구버전과 최신 HTML 페이지 모두에 대해 문제없이 실행됩니다. 실제로 2007년 KompoZer와 낡은 HandCoder 확장이 2005년부터 2017년까지의 Tidy 버전을 모두 호출할 수 있었습니다. 훌륭하죠.
새 Tidy 사용하기
전반적으로 프로그램은 잘 작동하는 편입니다. 특히 Tidy2가 훨씬 폭넓은 플래그와 옵션을 제공하는 점이 인상적이었습니다. 온라인 참고 문서만 봐도 시간 가는 줄 모르며, 모든 기능이 어떻게 작동하는지 파악하느라 몇 시간이든 보낼 수 있습니다.
그럼에도 새 Tidy/Tidy2가 코드를 다루는 방식에는 많은 문제가 있었습니다. 진지하고 똑똑한 개발자들이 자신들의 프로그램이 정돈된 마크업을 출력하는 방식에서 꽤 명백한 선택지들을 고민하지 않았다는 점이 의아했습니다.
Tidy2를 중심으로 보면, 첫째 공백(space)으로 코드를 들여쓴다는 점입니다. 탭이 아니죠. 큰 문서에서는 문자 수가 늘어나 결국 파일 크기가 커지므로 낭비입니다. 탭 1K가 공백 4K가 됩니다. 둘째, 스크립트와 스크립트 속성을 포함해 코드를 훼손합니다. Google(AdSense나 Analytics) 같은 퍼블리셔의 JavaScript 스니펫은 '있는 그대로' 사용하도록 요구하므로 큰 문제가 될 수 있습니다. 따옴표나 앰퍼샌드 같은 특수 문자도 치환하는데, 이는 스크립트와 URL을 깨뜨릴 수 있습니다.
이 시점에서 참고 문서를 찾아봤습니다. Notepad++ 인터페이스를 통해 오프라인 문서로 제공되거나 온라인에서 읽을 수 있는데, 그 목록은 2008년경의 것이네요. 세 가지 구성 옵션이 있으며 각각 개별적으로 조정할 수 있습니다.
설정은 대략 다음과 같습니다:
indent: auto
indent-spaces: 2
wrap: 120
markup: yes
output-xml: yes
input-xml: no
quote-marks: no
quote-nbsp: no
quote-ampersand: no
...
수많은 시행착오 끝에 알게 된 사실은, 코드를 외양과 기능 모두 최대한 원본 그대로 유지하고 싶다면 다음 변수들을 설정해야 한다는 점입니다.
quote-marks: no
quote-nbsp: no
quote-ampersand: no
preserve-entities: yes
literal-attributes: yes
최소한 위 다섯 줄은 URL과 스크립트 변수가 변경되지 않도록 보장해 줍니다. 그러나 Tidy2(물론 Tidy 자체도)는 요청하지 않아도 form이나 ins 블록 같은 것들을 여전히 수정·변경하므로, 서드파티 코드 스니펫과 함께 사용하는 것은 사실상 불가능합니다. 예를 들어 다음 코드는 절대 안전하게 유지되지 않습니다.
<ins class="adsbygoogle"
style="display:block"
data-ad-format="autorelaxed"
data-ad-client="ca-pub-xxxxxxxxxx"
data-ad-slot="yyyyyyyyyy"></ins>
여기서 몇 가지 핵심 질문이 나옵니다. 왜 Tidy는 코드의 특정 부분을 건너뛰도록 허용하지 않을까요? 왜 어떤 조작도 없이 마크업만 깔끔하게 정리하는 것이 불가능할까요? Tidy는 '정리(tidy)'를 해야지 코드 유효성 검사까지 해선 안 되거나, 최소한 그것은 선택 사항이어야 합니다. 예쁜 들여쓰기에 관해서라면 필자가 recursive LDD라는 작은 프로그램(LDD의 재귀 구현체)에서 비슷한 것을 구현해 본 적이 있습니다. 화면에 코드를 출력할 때 재귀 함수에 진입한 횟수 x 구분자(탭)를 기준으로 들여쓰기에 필요한 탭 수를 계산하는 방식이죠. HTML을 XML로 변환하는 등의 짓을 하지 않고도 충분히 가능한 일입니다.
여기서 또 다른 문제에 부딪힙니다. markup=no를 선택하면 Tidy가 문서를 싹 지워 버립니다. output=html을 선택하면 아무것도 하지 않습니다. 들여쓰기도, 빈 줄 삭제도 안 하죠.
그 밖의 비일관성
더 심각한 것은 출력물이 어떤 모습이어야 하는지에 대한 표준이 없어 보인다는 점입니다. 지난 12~13년 가까이 Tidy를 다뤄온 필자는 코드를 다루는 방식이 최소 세네 가지는 달라지는 것을 봤습니다. 예를 들어 2005년 버전은 단락을 다음과 같이 포맷합니다.
<p>
Text here
</p>
반면 새 Tidy는 이렇게 처리합니다.
<p>Text here</p>
구버전 Tidy는 모든 요소에 대해 줄바꿈 후 들여쓰기를 적용했습니다. 새 Tidy는 div 같은 일부 요소에만 이를 적용하고 단락이나 목록에는 적용하지 않습니다. 코드 캡슐화 문제도 있습니다. 2005년 Tidy는 스크립트를 전혀 변경하지 않았습니다(form과 ins는 여전히 훼손했지만). 2009년 Tidy는 코드를 <![CDATA[]]> 블록으로 감쌌습니다. 최신 Tidy는 2005년 버전과 비슷하게 동작하는 듯하지만, 거의 무작위적인 수의 들여쓰기 공백을 추가해 스크립트를 코드 블록 깊숙이 밀어 넣으며, '정돈된' 계층 구조 출력과는 전혀 연관이 없습니다. 짐작하시겠지만 이는 큰 문제입니다. 특히 파일이 수백 개에 달하고, 당신을 위해 변경을 해줘야 할 프로그램의 출력물을 일일이 검증하고 싶지 않다면 더욱 그렇습니다.
코드 출력 문제와 다른 HTML 편집기들
안타깝게도 HTML 코드를 원치 않는 방식으로 변경하는 것은 Tidy만이 아닙니다. BlueGriffon도 자기 멋대로입니다. 여는 단락 괄호, 줄바꿈, 텍스트, 줄바꿈, 닫는 단락 괄호라는 구식 문법을 만나면 코드를 다음과 같이 한 줄로 인라인 처리합니다.
<p> Text here </p>
블록 시작과 끝에 실제로 공백 두 개를 '추가'합니다. 최악은 이 공백들이 화면에는 표시되지 않는다는 점입니다. 뒤편에서 무슨 일이 벌어지는지, 왜 이런 기묘한 관례를 따르는지 궁금해집니다. 이미지와 닫는 div 같은 다른 요소들 사이에도 이런 공백을 삽입합니다. 미치고 팔립니다.
BlueGriffon에는 자체 마크업 기능도 있는데, 사용해 보니 코드 일부를 변경했고 그때마다 줄 수가 달리 표시되었습니다. 편집된 페이지들은 끔찍하게 망가졌고, 일부 div는 완전히 박살났습니다. 마지막으로 BlueGriffon도 form과 ins 블록을 훼손합니다.
SeaMonkey(Composer)도 비슷한 문제가 있었습니다. 단락 줄을 변경했는데, 자체 스타일을 사용해 추가 탭에 패딩 공백까지 붙였습니다. 올바른 체크박스를 선택했음에도 여전히 소스를 수정해 ins 블록을 망쳤습니다.
결론
알고 있습니다. 독립형 코드 작성은 '현대적인' 방식이 아닐 겁니다. 하지만 유효한 코드로 간단한 HTML/CSS 작업을 하고 싶다면 심각한 곤경에 처합니다. 텍스트 편집기와, 스스로 내세운 일을 잘하지 못하는 코드 집어삼키는 비주얼 편집기 사이에서 선택해야 하기 때문입니다. 게다가 코드 정리에 관해서라면, 이야기마세요. 와일드 웨스트입니다. 조심하세요. 스크립트와 form을 정말로 깨뜨릴 수 있고, 최악은 코드가 어떻게 깨져야 하는지에 대한 어떤 관례도 존재하지 않는다는 점입니다. 마지막으로 WordPress Gutenberg 개편 같은 CMS 세계의 변화가 다가오는 상황에서, 깨끗한 코드의 미래가 우리에게 어떤 모습으로 올지, 아니면 그런 미래 자체가 존재할지 정말 걱정됩니다.
아이러니하게도 이 모든 작업에서 전반적으로 가장 좋은 성과를 내는 것은 근본 한계와 최신 표준 미지원에도 불구하고 2007년산 도구인 KompoZer입니다. 하지만 이것이 군중 중 가장 덜 침습적이고 가장 생산적이기 때문입니다. BlueGriffon과 SeaMonkey도 잘 작동하지만, 이 고대의 문제들을 현대적인 외피와 섞어 놓은 것은 어떤 도움도 되지 않습니다. KompoZer는 2000년대 초반의 UI 버그들을 해결했고, 이후 세대의 기준점이 되었어야 마땅했습니다. 결국 남는 것은 차선의 선택들뿐입니다.
어느 쪽으로 가든 사용 편의성, 시각적 편리함, 코드 혼돈, 순수한 효율성 사이에서 타협해야 합니다. 2018년은 오프라인 작업이나 깔끔하고 준수한 코드를 원하는 이들에게 별로 호의적이지 않아 보입니다. 밝은 면을 찾자면, Notepad++나 Brackets로 마음껏 작업할 수는 있습니다. 그나마 다행이죠. 본질적으로 우리는 한 바퀴 돌아 제자리에 왔고, 실질적으로 얻은 것이 없습니다. 스펙트럼 반대편에서 온라인 CMS 세계는 클라우드 여행과 같습니다. 사람들은 자신의 콘텐츠를 운영할 멋진 API와 그럴싸한 UI를 갖고 있지만, 무대 뒤편에 대한 접근권은 없으며, 그것은 끔찍하고 복잡한 난장판입니다. What You See is What Once Was — 보이는 것이 곧 과거의 것이죠. 추상화의 세계에 오신 것을 환영합니다. Dedoimedo였습니다.
감사합니다.