주로 남의 소스를 건드리는 하이에나 같은 코딩을 하고 있는 이온디입니다.
소스 작업을 하다보면 정말 다양한 스타일의 코드를 만나볼 수 있는데요,
디자이너, 개발자, 퍼블리셔 직군이나 그 직군에서도 개개인의 능력에 따라 혹은 스타일에 따라
다양한 형식의 코드들을 만나볼 수 있습니다.
HTML 돔 구조야, 뼈대를 잡는 일이니깐 구조를 잡는데는 이견은 없지만,
UI/UX를 신경쓰는 개발자는 없지요. (__);;
(그래도 생각해보면 제로님 정도는 그나마 디자인을 신경쓰는 개발자가 아니었나 싶습니다.)
오늘 이야기해볼 것은 바로 CSS인데요,
퍼블리셔가 아닌 개발자들이 코딩해놓은 CSS를 건드리는 일은 정말로 '괴발개발'인 경우가 종종 있습니다.
1) 같은 역할, 같은 디자인인데 다른 클래스명을 남발하는 경우
2) .body .container .widget .font{...} 너무 꼼꼼하게 클래스명을 한줄한줄마다 지정한 경우
3) css의 문법에 맞지 않는 경우(해당 속성을 잘못 쓰는 경우)
4) XE에서의 경우 같은 기능을 담당하는 경우인데, 스타일이 다른 경우
백엔드 개발자 뿐만 프론트를 담당하는 경우에도 물론 있을 수는 있지만,
왠만한 퍼블리셔분들의 코딩 수준은 저보다 뛰어난 경우가 많아 오히려 제가 배울 정도였고요;
이런저런 다양한 경우들로 인하여 XE에서는 XE만의 CSS를 재정립해야하는 경우들이 많이 있습니다.
레이아웃에서 로그인이나 멤버, 게시판 관련한 특별한 클래스를 재정의해줘야하고요.
물론 해당 모듈 스킨에서 작업해도 되지만, 레이아웃을 큰 틀인 테마 개념으로 봤을 때,
레이아웃에서 특정한 기능들은 어느 정도 통일해주는 것이 좋아서 레이아웃의 CSS 디렉토리에서 해당 기능들을 재정의해줍니다.
(예전 테마 기능이 왜 없어졌는지 아쉬울 뿐입니다. 워드프레스나, 그누보드나, 왠만한 CMS들은 모든 기능들을 한 디렉토리에서 관리하지만, XE에서는 해당 기능들 디렉토리 안에 스타일 스킨이 따로 있지요.
요즘같이 번들링 도구가 잘 나와있는 시점에서는 오히려 그런 것들이 사이트의 전반적인 속도를 높여주거나 관리의 효율적 이점을 제공해주는 게 아닌가 싶습니다.)
<SCSS를 통하여 모든 CSS 파일을 먼저 임포트해서 쓴 경우>
예를 들어서 저 위의 코드를 예전 같으면 레이아웃에서 각각의 CSS를 별도로 불어왔을 겁니다.
<link rel="stylesheet" href="{$tpl_path}css/theme.min.css">
요즘엔 이런 식으로 하나만 가져와서 미니파잉된 소스를 불러올 수가 있습니다.
개발하는 입장에서 크롬개발자도구를 열어서 볼 경우는 별도 CSS를 각각 로드하는 경우가 편할 수 있지만,
사용하는 입장에서는 점점 불러오는 CSS의 갯수가 많은 것보다 하나를 불러오는게 속도면에서 낫겠고요.
(몇바이트 수준이라 실감할 정도로 그 차이를 느끼기는 쉽지 않습니다.)
개발은 일반 사용자가 하기엔 요즘은 너무 그 수준이 높아 역시 개발자가 하는 게 맞을 듯 싶고
제 입장에서도 요즘 퍼블리싱 기술이 점점 따라가기가 어렵더군요 ㅠ
그리고 저렇게 파일명을 기능에 따라 분류할 경우 오히려 직관적이라서 추후에 자기 소스를 관리하기도 쉽습니다.
이게 문제입니다.
개발자와 일반 사용자는 명확하게 분리되는 개념이 아닙니다.
일반 사용자가 필요에 따라 이것저것 건드리다가 점점 실력이 발전해서 개발자가 되고 하는 거죠.
제로보드 시절부터 웹을 만져온 우리 세대 개발자들 중 상당수가 이런 사람들 아닌가요?
minify의 예를 드셨는데, XE에서는 xe.css를 압축하여 xe.min.css를 만듭니다.
xe.css를 수정하더라도 xe.min.css를 재생성하지 않으면 변경사항이 적용되지 않습니다.
물론 __DEBUG__를 사용하면 xe.css가 로딩되도록 할 수도 있지만, 압축 효과는 전혀 못 보게 되죠.
만약 xs.css에 뭔가 개선할 것이 있어서 깃허브에 PR을 넣는다고 하면
그 PR만 받아서는 테스트 자체가 불가능합니다. xe.min.css를 재생성해봐야 합니다.
그러려면 HTML, CSS, PHP 등의 기본적인 기술 뿐 아니라
node.js라는 전혀 생소한 언어를 사용하여 minify 프로그램을 설치해서 사용해야 합니다.
일반적인 웹호스팅 서버에서는 돌아가지도 않습니다.
개발자와 일반 사용자의 간격이 넓어지는 이유는 그 간격을 넓힘으로써 이익을 보는 사람들이 있기 때문입니다.
주로 개발자들이죠. 요즘 개발자들이 만들어내는 대부분의 툴들은 개발자들만의 전유물입니다.
컴공과에서 배운 이론을 순수하게 지킨다는 명목으로 일반 사용자는 감히 범접할 수 없는 진입장벽을 만들어 놓고,
그 벽을 넘어야만 프로젝트에 참여할 수 있는 자격이 주어집니다.
그리고는 이걸 오픈소스라며 뻔뻔하게 배포합니다.
이런 프로젝트에 일반 사용자는 당연히 참여하지 않겠죠? 그러면 "거봐, 걔네들은 참여 안 하잖아"라며
더욱 개발자 위주로만 모든 툴들을 바꿔가는 악순환을 부추깁니다.
기술의 부익부 빈익빈 현상이지요.
적어도 XE타운에서 소개되는 기술들은 이런 이분법적인 사고방식을 밑바닥에 깔고 있지 않았으면 좋겠습니다.
여기를 드나드는 분들 중 상당수는 일반 사용자와 개발자 사이의 넓은 스펙트럼 어딘가에 있으니까요.
일반 사용자와 개발자의 관계는 흑과 백이 아니라 보라색과 빨간색입니다.
그 사이에는 빨주노초파남보 다양한 종류의 헤비유저, 파워유저, 개발자 지망생 등등이 있지요.
SCSS는 훌륭한 기술입니다. 얼마든지 쓰셔도 좋습니다.
그러나 하나의 거대한 파일로 합쳐서 압축해 놓으면 암호화된 덩어리에 지나지 않습니다.
암호화하여 배포되는 자료에 대해 @웹지기 님이 아래 글에서 지적하신 문제점들을 그대로 떠안게 되지요.
- 내가 더이상 이 자료를 유지보수해 주지 않더라도 사용자의 눈높이에서 커스터마이징이 가능한가?
- 어딘가 한 줄을 수정했을 때 즉각적으로 그 효과를 확인할 수 있는가?
이런 부분도 진지하게 고민해 보았으면 좋겠습니다.
해결책이 없는 게 아니거든요. 신기술에 꽂혀서 정신이 없으니까 거기까지 신경쓰기 귀찮을 뿐이죠.