디자인/개발 과정의 재고

Presentation Layer에서 Back-end 개발과 Front-end 개발, 그리고 디자인을 분리하는 방법에 대한 자료를 찾다가, JSTL, JSF, FreeMarker에 대해 알게 됐다. 그 중 FreeMarker 프로젝트 블로그에서 'The Designer/Developer Division of Labor Revisited'란 글을 발견!

백엔드 웹개발과 디자인 사이의 회색지대인 UI개발 영역(여기서는 웹사이트 통합 개발자website integrator란 표현을 씀)의 필요성에 대한 내용이며, 초벌 번역임. 다시 할지는 모르겠고...

The Designer/Developer Division of Labor Revisited

템플릿 엔진과 관련해 알려진 일반적인 개념은 두 개의 기본 그룹(비즈니스 로직을 고민하는 프로그래머와 웹사이트의 미려함을 추구하는 디자이너) 사이의 노력을 조합하는 일이다.

나는 이와 같은 견해가 상당히 일반적이며, 판에 박힌 듯이 만연한 개념이라고 생각한다. 물론, 이 경우에 우리는 모두 용의자가 될 수 있다. 이에 대한 아이디어를 우리는 FreeMarker의 문서 중 소개 페이지에서 충분히 설명하고 있다. 사실 우리 문서를 살펴보면, 2가지 분업에 대해 지지하는 가운데, 디자이너를 위한 독립적인 설명이 있는 반면, 특별히 프로그래머를 위한 페이지도 있다.

물론 이에 대해 개념상 정확하다고 볼 수 있다. 결국 두 가지 종족(어쨌든 일반적으로 구분하면)이 존재하며, 대부분의 사람들은 적어도 막연하게 뇌의 반쪽들이 각각 특별한 일을 수행한다는 두뇌 매핑에 대한 연구들을 알고 있다. 그리고 이러한 특징에 따라 웹 개발에 참여하는 두 부류의 사람들이 존재한다(개념적으로 각 분야에 적합한 방식을 갖고 있는).

나는 이런 의견이 틀렸다고 생각하지 않는다. 물론 서로 다른 사람들은 각자의 영역에서 전문적이다. 하드코어 프로그래머가 웹 페이지 디자인을 하고 있는 것은 재앙에 가깝다. 또한 그래픽 디자인을 잘하는 사람에게 프로그래밍 작업을 기대하는 것은 명백히 잘못된 일이다. 내가 여기서 발전시키고자 하는 아이디어는 일반적으로 두 분야의 제작방식은 지나치게 단순화됐다는 점이다. 그리고 더 낫다고 추전하는 것은 바로 3가지 기본 역할로 분담하는 것이다. 바로 어플리케이션 프로그래머, 그래픽 디자이너, 그리고 웹 사이트 통합 개발자(website integrator)이다.

예컨데, 어플리케이션 프로그래머는 자바와 같은 언어를 사용해서 코드를 짠다는 것은 자명한 일이다. 좀 더 자세히 설명하면, 그들은 데이터를 조작하는 알고리즘과 백 엔드 데이터 구조를 정의한다. 템플릿 시스템과 관련하여 이상적으로 어플리케이션 프로그래머는 시스템의 프론트 엔드에 데이터를 표현하는 일에서 손을 뗄 수 있고, 적절하게 디스플레이 된다는 것을 가정한다. 그래픽 디자이너는 가장 웹사이트의 미적인 부분을 고민하고, 프리핸드나 일러스트레이터와 같은 프로그램들과 대부분의 시간을 보낸다(솔직히 말해 나는 전문 프로그래머다. 이와 같은 프로그램들이 어떤 모양을 갖고 있는지 알지 못하고, 프로그램을 열어본 적도 없다).

두 개의 카테고리로 나눠 웹 개발 작업을 수행할 때의 문제점은 중간에 아주 커다란 회색 지대가 남게 된다는 것이다. 일반적으로 무언가 일정 레벨의 복잡성을 갖게 되면, 분명한 카테고리에 맞아 떨어지도록 모든 것을 나눌 수는 없다. 따라서 대개 발생할 수 있는 일이라 볼 수 있다. 그러나 이것은 아주 아주 큰 회색 지대라는 점에 문제가 있다. 이것은 그것을 구성하는 제 각각의 전문영역과 관련있는 다른 전문영역들에 대한 이해가 적어도 확립되어야 한다. 그리고 변화 과정에서 어느 단계에 진입하면 웹과 관련한 다양한 표준(자바스크립트 DHTML, CSS 그리고 FreeMarker와 같은 관련 기술)들을 마스터해야 한다. 지금까지 Oracle DB 관리자나 Unix 시스템 관리자 같은 업무는 독립된 직업으로 분류하고 있으며, 이와 같은 기술을 알아야 할 필요가 없다. 따라서 앞으로 점점 더 그럴 것(전문 영역이 생겨야 한다는 점)이라 생각한다.

오래전부터 나는 웹 개발을 이분법적으로 두 분야의 디자인/개발로 나눠 작업하는 것보다 세 분야로 구분해서 작업하는 것이 훨씬 더 효과적이라고 생각해왔다. FreeMarker의 개념으로 본다면 누가 어떤 특징을 가지고 있으며, 사람들에게 동기부여를 하는 방법에 대한 이 세상의 기본적인 문제들을 보다 더 깔끔하게 해결할 것이다(또한 3-way 패러다임이 웹 어플리케이션 프레임웍과 같은 다른 분야의 문제 해결에 있어서 고민하고 있는 사람들에게도 유효할 것이라고 본다).

자 이제 2-way 개발 방식에 대해서 살펴보면, 어떻게 동적인 페이지를 갖는 웹 사이트를 각자 제작할 수 있는가? 내가 일반적으로 사용하는 한가지 방법을 예로 들면, 프로그래머가 기본적으로 엉성한 페이지 템플릿을 갖는 기본적인 웹 어플리케이션을 제작한 다음 디자이너에게 전달하여 그것을 아름답게 꾸민다. 다른 방법은 디자이너와 같은 프로그래머가 아닌 사람들이 가상 데이터와 형태들로 디자인된 웹 페이지(기능상 동작하지 않는)를 제작한 다음, 개발자가 템플릿들로써 기능을 붙이는 작업을 하는 형태이다.

그러므로 동작하는 템플릿에서 비주얼을 만드는 과정을 택하거나 동작하지 않는 디자인된 템플릿으로 기능을 붙이는 것이 일반적이다. 당신은 이 두 가지 접근 방식을 선택한다. 어느 것이 낫다고 보는가? 내 생각엔 이런 논쟁은 닭이 먼저냐 달걀이 먼저냐 이야기 하는 것과 마찬가지로 무의미한 일이다. 어떤 방식을 사용하더라도 동일한 결과를 얻을 수 있기 때문이다.

실제로 이런 방식은 존재의 이유가 있었고, 2-way 패러다임은 상당히 이상적이었다. 위와 같은 시나리오는 프로토타입을 만드는 초기단계에 실제로 문제가 있다. 그들은 프로젝트의 전체 수행 기간 동안에 지속적으로 발생하는(때론 혼돈과 혼란으로 이어지는) 다양한 반복과 요구사항의 변경은 고려하지 않는다. 또한 프로젝트와 관련해서 작업 초기에 재사용이 가능한 presentation 요소가 있는지에 대한 의구심이 들게 한다. 물론 동일한 문제가 반복되는 상황에서 매번 맨땅에 헤딩하고 싶은 사람은 없다. 그리고 일반적으로 장기간 프로젝트를 해결하는 최선의 접근 방법으로 빠른 결과를 기대하는 프로토타이핑 개발 방식을 선택하는 것은 위험하다. 결과가 그리 좋지 않을 것이다.

웹 개발은 사이트를 다양한 브라우저에서 사용 가능토록 만들거나 서로 다른 해상도를 지원하는 등 여러 가지 문제해결에 있어 초보자에게는 상당히 많은 노력을 요구한다. 또한 상품이나 서비스를 현지화 하고 제품으로 출시하는데 있어 복잡 다단한 문제가 산적해 있다. 게다가 새로운 요구사항은 개발 과정에서 항상 마지막 단계에 나타나는 것이 일반적이라는데 더 큰 문제가 있다.

한편으로 이런 문제들은 본질적으로 해결하기가 쉽지 않으며, 다른 한편 늘 반복되는 똑 같은 문제들이 일어난다(비록 약간 다른 양상을 보이지만). 어떤 경우라도 브라우저나 해상도 문제와 관련하여 테이블 기반으로 최적의 표현 방식을 찾았다면, 다른 문제에서도 같은 방법을 적용하기 위해 재사용 가능한 해결책으로 만들어 두는 것이 당연하다. 특히 스페인어 버전의 사이트를 만드는 프로젝트에 참여하거나 비슷한 구조의 다른 내용의 작업을 하는 경우에 필요하다. 물론 가장 기본 적인 재사용은 copy-paste(복사/붙여넣기) 그리고 수정이 있다. 그러나 하드코어 프로그래밍에 있어서는 이런 반복작업 말고 더욱 장기적인 이득을 취하기 위해 노력한다. 일단 한번 문제를 해결하면 그것을 캡슐화하여 재사용할 수 있어야 한다. 자바와 다른 언어에서 이런 재사용은 일반적이지만 HTML에 동일하게 적용할 수는 없다.

그래픽 디자이너는 데이터의 표현의 문제를 해결하는 데는 익숙하지만, 재사용 가능한 해법으로 일반화하는 능력은 없고 훈련하기도 쉽지 않다. 하지만 하드코어 자바 프로그래머 역시 전형적으로 이와 같은 일을 잘 할 것이라고 보진 않는다. 만일 우리가 일반적인 문제에 직면해 있고, 디자이너나 프로그래머가 전통적으로 해결할 수 없다고 본다면, 마지막으로 그것을 제 3의 누군가가 담당해야 할 것이라는 결론에 도달한다. 바로 ‘웹 사이트 통합개발자(website integrator)’라는 팀원이 필요하다. 즉, 재사용 가능한 표현 요소(presentational elements)의 캡슐화를 주도할 사람이다.

이런 시나리오를 가정해보자. 아주 큰 웹 사이트를 갖고 있는 회사가 있다. 이 웹 사이트는 공통점이 없는 웹 기반 프로젝트를 서로 다른 부서에서 복잡하게 수행하고 있다. 결국 모든 노력을 통합할 필요가 생겼고 회사의 공통된 룩앤필(look-and-feel)을 전체적으로 갖추려 한다. 마침내 공통의 재사용이 가능한 building block의 제작이 필요하다. 이 블록들은 두 가지 장점을 갖는데, 불필요한 노력들을 줄이고, 전체 사이트에서 공통점을 유지하는 룩앤필을 갖도록 재사용이 가능한 형태가 될 것이다.

<>

번역 : 양주일