Daybreakin Things

Posted
Filed under 컴퓨터

아래의 태터캠프 후기 글에서도 언급했지만 스킨 규격에 대한 내 생각을 한번 죽 정리해보고자 한다.

기존 스킨 규격의 특징

  • 각종 치환자와 블록 태그들의 집합체.
  • 드림위버나 나모 같은 위지윅 에디터에서 바로 편집할 수 있다. HTML을 가장 높은 자유도로 편집 가능.

TTSKIN 2.0 (draft)의 특징

  • 치환자 및 블록 태그 최소화, HTML의 자유도를 거의 없앰.
  • CSS Selector만 맞추면 디자인과 마크업을 분리할 수 있다. (웹표준 기반의 개발방법론에서 스킨 규격은 publisher의 역할이라고 볼 수 있다.)
  • 각 서비스가 큼지막한 치환 영역을 ‘알아서’ 렌더링한다. 스킨이 같아도 각 서비스가 원하는 기능을 맘대로 집어넣을 수 있는 여지가 많다.

기존 스킨의 문제점

  • 여러 서비스에서 같은 규격을 사용하다보니, 각자가 원하는 기능을 추가하기 위해선 치환자를 추가해야 하는데 어떤 형식으로 만들어야 하는지에 대한 정의가 없기 때문에 통일성이 없다. (고로 스킨을 다 따로 만들어야 한다)
  • 치환자 및 블록 태그의 종류가 너무 많고, 어떤 것은 html 태그 덩어리를 생성하고 어떤 것은 단순한 문자열이나 숫자만 생성하고, 또 어떤 것은 특정 html 태그 안의 속성을 생성하기도 하는 등 사용법이 다 달라 이미 있는 스킨을 고치기는 비교적 쉬워도 새로 만들기는 어렵다.

TTSKIN 2.0의 문제점

  • 디자이너가 편집 결과물을 직접 보면서 작업하기 힘들다.
  • 순수한 웹표준 기반 개발방법론에 익숙하지 않은 사람들은 ‘이게 뭥미?’ 상태.
  • HTML에 대한 지나친 제약?

개발자(스킨 규격을 해석하는 소프트웨어를 만드는 사람들)가 원하는 것

  • 해석 속도가 빠르게 나오도록 구현할 수 있어야 한다.
  • php 코드 등이 실행될 여지를 없애서 보안성을 높여야 한다.
  • 여러 서비스에서 서로 다른 기능을 구현하더라도 하나의 스펙으로 추상화하여 다같이 통용될 수 있다면 멋질 것이다. (새로운 기능 추가에 대한 확장성이 뛰어나야 한다)

디자이너(스킨 규격을 이용해 스킨을 만드는 사람들)가 원하는 것

  • 일단 무조건 만들기 쉬운 게 짱. 이해하기 쉬워야 한다.
  • 만들면서 레퍼런스를 복잡하게 뒤질 필요가 없으면 좋겠다. (외울 것이 적어야 한다)
  • 실제 스킨이 적용된 결과를 바로바로 보면서 작업할 수 있어야 한다.
  • HTML과 CSS를 최대한 맘대로 건드릴 수 있으면 좋겠다.

사용자가 원하는 것

  • 기존에 있는 스킨 가지고 내가 원하는 그 무엇(위젯이 될 수도 있고, 라이선스 표시 같은 것이 될 수도 있고)을 쉽게 넣을 수 있었으면 좋겠다.
  • 비록 개발자나 디자이너 수준은 아니더라도 좀 쉽게 내맘대로 조작하면 좋겠다.
  • 하나의 스킨 가지고 여러 곳에 복사해서 써먹을 수 있으면 좋겠다.

Trade-off가 일어나는 부분

  • HTML에 대한 자유도 vs. 서비스 독립성
  • 뛰어난 확장성을 가진 규격 vs. 디자이너들의 이해도

몇 가지 대안들

  • Django Template처럼 간단한 프로그래밍이 가능한 템플릿 엔진을 도입한다.
    • 기존에 있는 것을 쓰기엔 무거워 보이고, 직접 구현하기에도 만만하지 않음.
    • 확장성도 뛰어나고 HTML 자유도도 높지만 역시 디자이너들의 이해도 문제가 걸림.
  • 기존 스킨 규격에서 치환자들만 다시 정리한다.
    • 어쩌면 여러 면에서 가장 현실적인 대안.
    • 확장성을 어떻게 확보할 것인지가 관건.
  • 그냥 다 포기하고 각 서비스 알아서 독자 규격 사용하도록 놔둔다.
    • Project Tattertools의 의미 퇴색이 문제.

매우 괴상한 규격을 만들긴 했지만 나름대로 이런 고민들을 하고 있다. 좋은 의견 있으면 꼭 댓글이나 트랙백으로 달아주었으면 좋겠고, 차기 스킨 규격 제작에 꼭 반영할 수 있도록 노력하겠다.

사실 이런 걸 두고 정말 ‘공학적인 문제’ 또는 ‘정답 없는 문제’라고 말할 수 있겠지. ㅠ_ㅠ 이런 문제를 학교 수업에서는 거의(?) 다루지 않는데, 과연 교수님들한테 이런 상황을 설명하면 어떤 대답을 하실지 궁금하다. (‘그냥 너가 알아서 해’ 이런 거 빼고.)

melt-snow

잠깐 든 생각인데요. 웹 디자이너 입장에서 만들고 고치기 쉽게 하려면, 결국 스킨 매니저의 제작자 버전 툴이 필요하겠다는 생각이 듭니다.

제가 스킨 매니저를 써보면서 이거 꽤 편리한데? 하고 느끼면서도, 동시에 일정 수준 이상의 요구는 받아들이기 어려운 인상을 받았습니다. 나중에 버전 업 하면서 스킨 구조에 따라 분리해서 특정 영역만 따로 편집도 가능해졌지만, 매번 로딩하는 시간도 문제고 인터페이스가 불편하더군요.

물론 간편하게 편집할 때는 쓸만했지만 길다란 스킨 파일 html 보면서 css 따로 보려니 여간 고역이 아니었습니다. 데스크탑 에디터에 있는 라인 북마크 기능 같은 것도 없으니 그만큼 불편함도 있었습니다.

그래서... 웹 디자이너가 만족할만한 편집을 가능하게 하려면 데스크탑용 스킨 퍼블리셔 툴을 만들 필요가 있지 않나 합니다. 비용이 다른 방향으로 더 늘어나기는 합니다만, 잘 만들어서 꾸준히 관리할 수 있다면 어렵게 웹에서 구현하는 것보다 나을지도... (옛날 같으면 이 부분에서 ActiveX가 등장했겠죠. 지금은 Air나 Silverlight가 대안이 되겠네요.)

데스크탑 툴로 구현하면 레퍼런스 같은 건 적절히 참조할 수 있게 intelli-sense 정도의 기능으로 부가하고, html의 편집할 부분에 따라 css 영역이 자동으로 뽑혀 표시되는 등의 편의성이 만족될 것 같습니다. 문제는 누가 만드느냐인데... ..결자해지라고 하시면 전 도망 =3

>과연 교수님들한테 이런 상황을 설명하면 어떤 대답을 하실지 궁금하다.

lifthrasiir님에게 물어보면 왠지 “휴리스틱하게”라는 대답이 나올 듯한 기분이 드네요. 아희~

daybreaker 

역시 문제는 결자해지죠.;; 티스토리에서 소개했던 콘솔UI로 사실 TNF 내부에서 아이디어 나온 것은 몇 년(?) 되었으나 구현할 사람이 없어서 못했고, 이런 식으로 묻혀있는 아이디어들이 한둘이 아닙니다. ㅠㅠ

제가 아직 학생인지라, '다른 직종'(예를 들면 웹디자이너)의 사람들과 직접 협업을 해본 적이 없어서 정말 궁금해요. 웹디자이너 바로 옆에 앉혀두고 짝프로그래밍(?!)이라도 하고 싶은 심정입니다.

polarnara 

스킨 디자이너 입장에서는, (앞뒤 다 잘라먹고) 스킨 치환자가 하는 역할이 CSS selector로 바뀌었을 뿐이라는 생각도 들 수 있지 않을까요. 이전엔 스킨 치환자 레퍼런스를 뒤져야 했다면, 이젠 CSS selector 레퍼런스를 뒤져야 하니까요. 치환자가 html 블록을 만들기도 하고 문자열을 만들기도 하던 것이, 각 selector들이 블록 타입인가 인라인 타입인가만 알면 된다는 걸로 범위가 줄어들기는 합니다만..
아 그리고 이건 제가 잘 모르는 부분일수도 있는데, dl 태그는 definition list 태그 아닌가요? entryInfo에 dl 태그가 쓰이는 게 적합한건지 궁금합니다.

daybreaker 

어떻게 보면 selector가 치환자 역할을 대신한다고 볼 수도 있겠군요. 문제는 개발자 입장에선 selector만 서로 맞춰주면 되는 거지만 디자이너 입장에선 '비주얼 피드백'이 필요하다는 거죠.;
dl 태그의 경우, "항목 이름: 항목 내용" 이런 패턴을 표현하는 데 사용된 것입니다. 사실 언제 ul을 쓰고 언제 ol을 써야 하는지와 같은 부분은 딱히 정답이 없는 것 같아요.

익살

디자이너가 이해할 수 있다, 없다도 중요하겠지만, 이해도 하면서 쉽게 그리고 예쁘게 고칠 수 있어야 한다는게 문제겠네요. 정말 중요한 문제일 것 같습니다. 화이팅입니다 ^^;;;

.... 교수님들께 이런 정황을 설명드리면, 이런 정황을 끝까지 잘 들어주시고 이해하시는 교수님들이 몇분 안계실 것 같은데요 ㅋㅋ

daybreaker 

가끔가다 이런 사소한(?) 기술적 문제도 결정하기 어려워하는 저 자신을 볼 때마다 엄청난 규모의 기업들을 움직이는 CEO들은 얼마나 머리털을 쥐어뜯을지(?) 상상도 안 되네요. ㅎㅎ;

비밀방문자

관리자만 볼 수 있는 댓글입니다.

daybreaker 

음, 굳이 비밀댓글로 안 다셔도 되는데...=3=3 ^^;
그 부분을 고려하기 이전에 일단 현재 스킨 스펙에는 문제가 많다는 인식을 공유한 상태라 새 스펙을 어떻게 만들지가 더 문제지요.; 말씀하신 부분은 그 이후에 생각할 문제 같습니다.

비밀방문자

관리자만 볼 수 있는 댓글입니다.

daybreaker 

앗, 제가 아는 분이셨군요;;; 저는 인신공격이나 개인정보를 담아야 하는 경우 같은 특별한 상황이 아니라면 블로그에서 공개된 토론을 더 좋아하기 때문에 일단 주욱 댓글 붙여보겠습니다. (괜찮으시다면 위의 댓글들도 이메일 주소만 지워서 공개로 전환하고 앞으로 댓글도 공개로 달아주셨으면 합니다.)

제로보드의 경우 php 코드를 직접 쓸 수 있는, 사실상 무한대의 자유로움을 통해(스킨인지 플러그인인지 구분이 불가능할 정도로) 엄청나게 다양한 변종 제작이 가능했습니다. 단지 이것만이 제로보드 성공의 이유인가는 확실하지 않지만 어쨌든 사람들은 원하는 것을 대부분 만들어내거나 다른 사람이 만든 것으로 구할 수 있었습니다.

하지만 텍스트큐브의 스킨 규격에서 그런 장점을 도입하지 못하는 이유는 티스토리처럼 '서비스'이면서 스킨 편집이 가능하기 위해선 보안을 고려하지 않을 수 없기 때문입니다. 원래의 스킨 규격에서 치환자 문법을 별도로 정의하고 스킨 태그 블록 외에는 어떠한 프로그래밍적 요소도 사용할 수 없게 한 것도 이런 이유였습니다.

현재 제로보드(이제 eXpress Engine으로 이름이 바뀌었죠)는 HTML comment 안에 자체 템플릿 문법을 넣고 이를 php로 변환하여 실행하는 구조를 취하고 있습니다. 자유도도 높고, 비교적 학습 난이도도 낮지만 역시 서비스하기에는 보안 문제가 걸립니다. (제로보드의 보안이 약하다는 것이 아니라, 서비스에 적용하기 위해선 애초부터 가능성을 없애버리자는 것이 취지입니다)

문제는, 저조차도 지금의 스킨 스펙 스타일이 디자이너들이 정말 원하는 것인지, 그리고 말씀하신 것처럼 사용자들이 원하는 것이 정말 사용자들이 원하는 것인지 확신이 서지 않는다는 점입니다. 사실 오픈소스 개발자 입장에서 정말로 사용자의 입장을 알아내기까지는 너무나 큰 비용이 필요하기 때문에(디자인이나 UX 다 제쳐놓고서도 구상하는 기능 구현하기만 해도 일손이 모자랍니다), 보다 사용자나 디자이너 관점에서 바라보기 용이한 티스토리와 텍스트큐브닷컴 관계자분들의 지속적인 피드백을 얻으려고 했는데요, 구글의 TNC 인수 과정을 거치면서 커뮤니케이션 문제가 있었습니다. (스킨 규격 작업 시작한 게 7월 초였습니다만 처음 피드백을 받은 게 지난 토요일의 태터캠프였습니다) 사실 제로보드처럼 NHN 같은 큰 기업에서 아예 풀타임으로 개발시키며 회사 자원을 대주지 않는 이상 대다수 오픈소스 커뮤니티에서 디자이너의 부족은 굉장히 현실적으로 큰 문제이고, 텍스트큐브도 마찬가지라서 이들의 입장을 반영하기엔 어려움이 많습니다.

일단 말씀하신 대전제에는 저도 동의합니다. 그리고 사실 저도 지금 만든 스킨 규격이 100% 맘에 들지는 않습니다. ㅠㅠ; 기존 스펙을 정리하려고 했을 때 사실 XML namespace를 활용한 형태를 처음에 생각했었는데 해석 속도의 문제가 걸려서 채택하지 않았던 것이기도 합니다. 이래저래 조건이 까다롭네요.

validator를 통해 간접적으로 실현한다는 것도 일단은 괜찮은 아이디어 같습니다. 치환자들을 새롭게 정의할 수 있도록 확장성 있게 만들어두면 기본 syntax 검사는 할 수 있겠죠. 하지만 역시 그 스킨이 각 서비스가 제공하는 기능을 오류없이 사용할 수 있음을 보장하는가에 대한 문제까지 커버하지는 못할 것 같습니다. (음, 티스토리나 텍스트큐브닷컴이 새 기능과 확장 치환자를 추가할 때마다 저희와 항시적인 커뮤니케이션을 유지한다면 가능하겠지만...)

아무튼 좋은 의견 감사드리고, 또 댓글 달아주시면 대환영입니다. ㅋㅋ

[로그인][오픈아이디란?]