웹 에디터, 어떻게 만들어야 할까 III

취향의 흔적
- IT/웹, 2008-03-13, resistan

이 글은 웹 에디터의 이상적인 방향을 고민하는 글입니다이었습니다. 우둔함에 스스로도 한번에 풀어내지 못하는 내용이라 아래 글을 이해하는게 어렵다면 첫번째, 두번째 글을 참고해주십시오. 오래 묵혀둔 글이라 두서없이 마무리 하게 됐습니다. 부디 용서를....

웹 에디터가 할 수 있는 일

이 글을 쓰면서 든 의문 중 하나는 과연 웹 에디터가 편집 기능에만 주안점을 두어야 하는 것인가 하는 점이었다. 기본적으로 HTML은 웹이 등장하기 이전부터 사용해왔던 일반적인 문서양식을 출력할 수 있도록 만들어져있다. 그러나 에디터를 보며 워드프로세서를 떠올릴 사용자들은 차트나 도형 같은 것들을 넣고 싶어할지도 모른다. 어떤 사람들은 웹에서 소설을 쓰고 싶어하고, 어떤 사람들은 그림을 그리고 싶어한다.

하지만, HTML 코드라는걸 한번이라도 들여다본 적 있는 사람이라면 다 알고 있는 한계 역시 있다. HTML을 이용해서 그림을 직접 그리는 것은 불가능하다. 그래서 웹 에디터가 최근의 워드프로세서처럼 그리기 도구를 제공할 수 없는 한계를 가지는 것이다. 웹이라는 수단이 우리에게 주는 많은 장점을 생각하면, 또 보다 나은 것을 사용하고자 하는 욕구를 감안한다면, HTML의 한계를 인정할 것인가, 포기할 것인가 하는 점은 그리 쉽게 말할 수 있는 수준의 문제가 아닌 듯 하다.

웹 에디터 기능의 기준

Google Page Creator

구글 페이지 크리에이터에 탑재된 웹 에디터. 헤딩의 레벨을 정할 수 있다. 기본적인 기능 외에도 들여쓰기나 내어쓰기를 조절할 수 있다.

웹 에디터는 기본적으로 단독으로 사용되지 않는다. 입력 양식의 확장판이라고 할 수 있기에, 대게는 게시판이나 질의를 위한 글쓰기 페이지에 사용된다. 그리고 그런 입력 양식은 일반적으로 어떤 사이트의 일부분으로 존재한다.

사이트를 만드는 입장에서 웹 에디터의 출력에 두가지 방식을 고려해볼 수 있다. 그것은 사용자가 입력하는 콘텐츠를 기존 사이트의 디자인에 맞춰서 출력할 것인지, 사용자의 편집 의도대로 출력되게 할 것인지 하는 두가지 방식이다. 대부분의 웹 에디터는 후자쪽으로 만들어지는데, 이는 웹 사이트 전체의 내용과 웹 에디터를 통해 입력하는 콘텐츠의 내용을 별개로 간주하기 때문이 아닐까 한다. 웹 에디터가 존재하는 이유는 그것을 통해 입력된 콘텐츠가 운영자든, 사용자든 입력한 사람의 의도에 맞추어 출력되길 원하기 때문이라 하겠다.

요구되는 점들

사실 이 글을 쓰게된 애초의 목적은, 웹 접근성이나 웹 표준을 지켜서 웹 에디터를 만드려면 어떻게 해야할까에 대한 고민이 있었기 때문이다. 벌써 반년 가까이 지나버린 이야기가 되버렸지만 네이버 스마트 에디터 논쟁을 보며, 과연 웹 에디터에 웹 접근성을 요구하는 것이 절대적으로 옳은가 하는 의문도 들었고, 웹 에디터에 대해 묵혀둔 고민을 어떻게든 좀 풀어보고 싶었다.

우선 웹 접근성을 고려하여 웹 에디터를 만든다는 것은 웹 저작도구 접근성 지침(ATAG)을 충실히 지켜야하는 일일 뿐 아니라, 그 출력물 역시 웹 콘텐츠 접근성 지침(WCAG)에 부합하도록 한다는 의미다. 이는 달리 생각한다면 가장 단순한 형태의 웹 에디터를 요구하는 일일지도 모른다. 내용 입력을 위한 필드가 있고 각각의 요소에 대한 속성을 지정할 수 있게 하는 방식이 되겠다. 쉽게 생각하면 매우 장황한 구조의 입력 양식이 될지도 모르는 일인 것이다.

또한 웹 표준을 고려하여 웹 에디터를 만든다는 것은, 웹 에디터를 통하여 입력되는 콘텐츠의 가치를 높이고자 하는 일이 될 것이다. 사용자로 하여금 구조에 맞춰 콘텐츠를 작성하게 하여 그것이 출력될 때에는 재활용 가능한 형태로 나와야 하는 것이다. 이를 위해서는 위의 스프링노트의 웹 에디터처럼 내용의 구조적인 부분을 사용자가 구체적으로 지정할 수 있도록 만들어 주는 일이 필요할 것이다.

이런 요구 조건이 구현되기 어려운 이유는 많다. 바로 앞에 언급했던 내용만 해도 사용자가 문서 구조에 대해 이해하고 올바르게 작성하는 과정을 요구하기 때문에 상당히 지켜지기 어렵다 하겠다. 또, 마우스 중심의 웹 에디터 인터페이스를 변경해야하는 점 역시 상당히 난제이다. 구현 불가능한 일은 아니겠지만, 웹 에디터의 기능을 모아두는게 일반적이고 이를 원활히 사용할 수 있도록 만들기 위해 레이어를 이용해 옵션을 선택하게 하는 경우도 빈번하다.

누가 웹 에디터를 쓰는가?

앞서도 이야기를 꺼냈지만, 웹 에디터를 제작 혹은 설치하는데 있어 고려해야할 점은 바로 누가 그것을 사용할 것인지에 대한 점이 아닐까 한다. 이런 과정은 웹 에디터를 입력기로 쓸 것인지, 편집기로 쓸 것인지, 사용 입장의 차이를 만들게 된다.

Springnote Editor

스프링노트의 웹 에디터. 사용자 한사람이 쓰기도 하지만, 협업을 통해서도 문서 작성을 해야하는 만큼 입력을 얼마나 쉽게할 수 있는지가 매우 중요한 요소인 서비스이다. 일반적으로 볼 수 있는 웹 에디터의 기능 외에도 단락 제목의 레벨(H1~H6)을 준다거나, HTML 태그로 제공하는 기능에 맞춰 본문 표시 방식을 좀 더 다양하게 할 수 있도록 하고 있는 점이 눈에 띈다.

블로그나 기업 사이트처럼 특정인이 반복적으로 콘텐츠를 입/출력하는 사이트라면 전체 분위기에 맞게 콘텐츠가 출력되는 쪽이 더 일관성을 살리면서 콘텐츠를 유려하게 표현하기 좋을 것이다. 반대로, 커뮤니티처럼 불특정 다수가 사용하는 곳이라면 보다 사용자가 다양한 표현을 할 수 있도록 배려하는 것이 좋겠다.

물론, 이는 사이트를 운영하는 주체가 해당 게시판이나 서비스를 어떻게 운영할 것인지에 대해 결정하고 준비해야할 지점이겠지만 국내의 일반적인 사이트 이용행태를 보면 이 정도의 기준이 적당하지 않을까 한다. 문제는, 불특정 다수에게 편집의 자유를 주는 에디터가 대부분 그것을 제공하는 사이트의 틀까지도 해치는 상황을 왕왕 만들어내고 있다는 점이다. 이는 사용자의 무지나 웹 에디터의 무분별한 사용에 그 원인이 있겠지만, 에디터를 제작하는 입장에서는 이러한 문제를 궁극적으로 해결하기 위해 어떤 방법을 필요로 하는 것 또한 사실이다.

정답이 나올 것이라 생각하며 쓰기 시작한 글은 아니었다지만, 이렇게 정리하려니 찜찜한 면이 없지 않다. 더욱 다각화되는 사용 환경과 조건들을 모두 만족시킬 수 있는 도구를 만드는 일은 웹 에디터 뿐만 아니라, 프로그램이나 서비스 등을 제작하는 모든 제작자들의 희망이자 목적지가 아닐까 한다. 제공할 사이트나 서비스의 특징과 목적을 감안하여 보다 많은 사용성, 접근성을 보장해주는 도구를 만들 수 있도록 더욱 더 노력할 수밖에...