국내에서는 디자인 퀄리티 요구 수준이 향상되면서 디자인 및 UI 개발 프로세스가 캘리포니아와 반대로 가고 있는데, 캘리포니아 스타트업들은 가급적 포토샵 터치를 줄이는 방향으로 디자인을 바꾸고 있는 반면, 국내는 국내 포털을 따라해서 포토샵을 많이 사용하는 방향으로 디자인이 이루어지고 있다.
국내외 디자인 방식의 차이를 두고 '국내 사용자들의 눈이 높다'라고 보는 시각도 있지만, 나는 사용자들이 단지 포털식 디자인에 익숙해져 있을 뿐이고 캘리포니아식 디자인도 초반에 겪는 약간의 이질감을 넘어서면 더 '깔끔한, 세련된' 것으로 인식하게 될거라고 생각한다. 이런 방식으로 디자인하는 습관을 버리지 못했거나, 그렇게 디자인하는 사람들을 해고할 수 없는 것 뿐일 수도 있다.
국내의 디자인 방식은 UI 개발(코더) 과정을 필수적인 것으로 만들어버리고, 클라이언트 또는 서버 개발직군의 선택권을 제한한다. 가령 UI개발자의 손을 거쳐 나온 html과 css파일은 나름의 id와 class값을 가지고 있는데 자바스크립트 개발자는 동작 의도와 맞지 않는 이름의 id를 억지로 사용하거나 일일이 id값을 수정(그 id값이 위치한 css도 수정)해야 한다.
또 서버 개발자는 빌더 형태의 뷰 템플릿(레일스의 경우 HAML)을 사용할 수 없게 되고 프레임워크에서 제공하는 헬퍼 메서드(link_to 등), 코드 조각(Partial) 사용에 제한을 받거나 성가신 수정 작업을 해야 한다. 또 별도의 UI개발자가 작성한 CSS는 스타일 모듈화 보다는 엘리먼트간 스타일 간섭 최소화를 우선하고 있어서 CSS 코드 분량도 많고 재사용도 어렵고 개발한 본인이 아니면 수정도 어렵다.
나는 서버 개발자를 위한 UI개발 도우미(HAML이나 BluePrint) 사용을 반대하는 쪽이지만 어쨌든 국내 디자인 트렌드가 가져온 UI개발 프로세스가 서버 개발자들의 여러 선택권을 제한하는 것은 좋지 않은 것 같다. 물론 해외에도 UI개발 직군 및 UI 개발 프로세스가 있지만 국내의 UI개발과 해외의 UI개발은 목적과 전문성에서 차이가 있다.
내가 느끼는 캘리포니아의 UI개발 직군은 (myspace UI와 디자인을 컨설팅한 adaptive path처럼) 정말 UI 개발만을 '전문적'으로 하거나 컨설팅을 해주는 수준으로 고급화되었고, 국내는 개발자 대신 성가신 작업을 대신 해주는 코더 개념에서 크게 향상되지 못했다고 보는 것이다. 국내 디자인 형태가 그것을 조장했다고 보고. CSS를 얼마나 효율적으로 모듈화해서 사용하느냐가 아니라, 잘게 쪼개진 테두리 이미지들을 어떻게 하면 오차 없이 끼워 넣을 수 있는지를 고민해야 하는 것이다.
포토샵 작업이 중심이 아니라, CSS 스타일과 레이아웃이 디자인의 중심으로 올라오면, 디자인 프로세스 및 UI개발 프로세스의 순서가 클라이언트/서버 개발의 이전이 아닌 이후로 바뀔 수 있다. 실제로 UI/클라이언트/서버 개발을 혼자서 진행하게 될 경우 UI 개발은 앞쪽이 아니라 뒤쪽에 오게 된다. 뷰 코드를 다 작성하고 난 후에 id/class를 추가하면서 css를 작성하는 것이다.
클라이언트/서버 개발자는 디자인과 UI개발 결과물이 나올 때까지 기다리는 것이 아니라, 주요 골격을 미리 완성해놓고 UI개발자와 디자이너의 '도움'을 받는 형태가 된다.
국내외 디자인 방식의 차이를 두고 '국내 사용자들의 눈이 높다'라고 보는 시각도 있지만, 나는 사용자들이 단지 포털식 디자인에 익숙해져 있을 뿐이고 캘리포니아식 디자인도 초반에 겪는 약간의 이질감을 넘어서면 더 '깔끔한, 세련된' 것으로 인식하게 될거라고 생각한다. 이런 방식으로 디자인하는 습관을 버리지 못했거나, 그렇게 디자인하는 사람들을 해고할 수 없는 것 뿐일 수도 있다.
국내의 디자인 방식은 UI 개발(코더) 과정을 필수적인 것으로 만들어버리고, 클라이언트 또는 서버 개발직군의 선택권을 제한한다. 가령 UI개발자의 손을 거쳐 나온 html과 css파일은 나름의 id와 class값을 가지고 있는데 자바스크립트 개발자는 동작 의도와 맞지 않는 이름의 id를 억지로 사용하거나 일일이 id값을 수정(그 id값이 위치한 css도 수정)해야 한다.
또 서버 개발자는 빌더 형태의 뷰 템플릿(레일스의 경우 HAML)을 사용할 수 없게 되고 프레임워크에서 제공하는 헬퍼 메서드(link_to 등), 코드 조각(Partial) 사용에 제한을 받거나 성가신 수정 작업을 해야 한다. 또 별도의 UI개발자가 작성한 CSS는 스타일 모듈화 보다는 엘리먼트간 스타일 간섭 최소화를 우선하고 있어서 CSS 코드 분량도 많고 재사용도 어렵고 개발한 본인이 아니면 수정도 어렵다.
나는 서버 개발자를 위한 UI개발 도우미(HAML이나 BluePrint) 사용을 반대하는 쪽이지만 어쨌든 국내 디자인 트렌드가 가져온 UI개발 프로세스가 서버 개발자들의 여러 선택권을 제한하는 것은 좋지 않은 것 같다. 물론 해외에도 UI개발 직군 및 UI 개발 프로세스가 있지만 국내의 UI개발과 해외의 UI개발은 목적과 전문성에서 차이가 있다.
내가 느끼는 캘리포니아의 UI개발 직군은 (myspace UI와 디자인을 컨설팅한 adaptive path처럼) 정말 UI 개발만을 '전문적'으로 하거나 컨설팅을 해주는 수준으로 고급화되었고, 국내는 개발자 대신 성가신 작업을 대신 해주는 코더 개념에서 크게 향상되지 못했다고 보는 것이다. 국내 디자인 형태가 그것을 조장했다고 보고. CSS를 얼마나 효율적으로 모듈화해서 사용하느냐가 아니라, 잘게 쪼개진 테두리 이미지들을 어떻게 하면 오차 없이 끼워 넣을 수 있는지를 고민해야 하는 것이다.
포토샵 작업이 중심이 아니라, CSS 스타일과 레이아웃이 디자인의 중심으로 올라오면, 디자인 프로세스 및 UI개발 프로세스의 순서가 클라이언트/서버 개발의 이전이 아닌 이후로 바뀔 수 있다. 실제로 UI/클라이언트/서버 개발을 혼자서 진행하게 될 경우 UI 개발은 앞쪽이 아니라 뒤쪽에 오게 된다. 뷰 코드를 다 작성하고 난 후에 id/class를 추가하면서 css를 작성하는 것이다.
클라이언트/서버 개발자는 디자인과 UI개발 결과물이 나올 때까지 기다리는 것이 아니라, 주요 골격을 미리 완성해놓고 UI개발자와 디자이너의 '도움'을 받는 형태가 된다.
댓글을 달아 주세요
좋은 글 감사합니다.^^ 빨리 이런 개념이 우리나라 웹에도 확산되어야 할텐데요. 어느 한 AJAX관련 포스팅에서도 이 개념이 중요하다고 했던게 기억이나네요. 웹프로그래머들은 어떻게 보이느냐를 중요하게 여길게 아니라(어떻게 보이느냐는 브라우져나, 사용자의 설정, 폰트에 따라 또 틀려지므로), 처음에는 웹문서의 구조와 내용에 맞게 코딩을 하고, 거기에 자바스크립트와 CSS를 통해 동작과 디자인을 추가해야한다고 했던 말이 기억나네요. 또한 웹브라우져의 HTML 출력 과정도, HTML만을 먼저 구조화하고 객체로 만든 뒤, 각 HTML 객체에 CSS와 자바스크립트를 적용하는 과정을 거친다고 하더라구요. 이 개념을 알아야 AJAX를 제대로 사용할 수 있다면서..
2008/08/16 22:49방문 감사합니다. 구조화도 중요하지만 어떻게 보이느냐도 사실 중요하죠^^;; 브라우져는 html을 DOM으로 해석해서 담고 있고, 다양한 자바스크립트 프레임워크들은 tag가 아닌 element 단위로 웹 페이지를 다루게 됩니다. 말씀하신 것처럼 디자인 측면의 css와 기능성 측면의 javascript는 서버측 뷰 골격이 완성된 후에 unobtrusive하게 추가되는 것이 바람직하다고 합니다.
2008/08/21 20:48