|
난이도 : 중급 Alister Lewis-Bowen, Senior Software Engineer, IBM
Stephen Evanchik, Software Engineer, IBM
Louis Weitzman, Senior Software Engineer, IBM
2006 년 9 월 29 일
2006 년 10 월 23 일 수정 본
시리즈를 통해서, IBM Internet Technology Group 팀이 무료로 사용할 수 있는 소프트웨어 슈트를 사용하여
커뮤니티 웹 사이트를 디자인, 개발, 전개하는 과정을 설명합니다. 오픈 소스 커뮤니티는 복잡한 웹 애플리케이션에 유용한 개발 및
제품 환경을 만들 수 있는 다양한 툴들을 제공합니다. 이러한 툴들을 토대로 제품화 과정을 단순화 할 방법들을 설명합니다. 이
시리즈에서는 Drupal, MySQL, PHP, Apache, Eclipse 같은 오픈 소스 툴을 사용하여 복잡한 웹 사이트를
실행할 수 있는 툴과 기술들을 설명합니다. 첫 번째 시리즈에서는 우리가 사용했던 방법과 다른 소프트웨어 툴들을 비교하고, 우리가
이를 어떻게 향상시켰는지를 설명합니다.
머리말
오
늘날, 웹 사이트는 비즈니스에 있어 중요한 부분이고, 웹 사이트를 만들고 전개하는 툴은 보다 유연하고 사용하기 쉽게 변해가고
있다. 하지만 표준 인터랙션 방식(Blog) 보다 더 많은 것을 요하는 복잡한 웹 애플리케이션을 만드는 일이란 간단한 일이
아니다. 가끔은, 기업 내 각 애플리케이션은 커스터마이징이 필요하다.
이 시리즈에서는 가상의 기업
International Business Council (IBC)의 예를 들어서 웹 사이트 기능을 효과적으로 극대화 하는 방법을
설명하겠다. IBC는 협업 커뮤니티에서 사원들을 외부 비즈니스 파트너들과 연결한다. 하지만 기존 웹 사이트로는 현재의 비즈니스
필요를 채울 수 없기 때문에 사이트는 다시 설계되어야 한다. 새롭게 커스터마이징 된 웹 사이트에는 문서 스토리지, 디스커션
그룹, 특별한 작업그룹, 컨퍼런스 스케줄링, 스케줄 세션 디스크립션, 세션 종료, 기타 태스크들을 갖추어야 한다.
사
용자의 역할은 전략적인 결정을 개선하여 기업의 오퍼링을 강화하는 것이다. 사용자 커뮤니티는 작업그룹의 핵심 이슈와 관련하여
구성된다. 이 커뮤니티는 컨퍼런스 세팅에서 일년에 여러 차례 직접 미팅을 하고 있다. 컨퍼런스에서 이슈들이 규명되고 미팅을
거치면서 해결된다. 웹 사이트는 컨퍼런스 같은 커뮤니티 활동에 대한 정보를 제공하고, 미팅에서 제기된 이슈와 관련한 진행 과정을
트래킹 하는 방식으로서 사용된다.
기존 웹 사이트는 문서를 교환하고 향후 이벤트에 대해 멤버에게 업데이트
하는 방식을 제공하는 문서 리파지토리에 기반하고 있다. 하지만 웹 사이트는 커뮤니티 인터랙션을 조성하는데 적합하지 않다. 특히
Weblog, 디스커션 그룹, RSS 피드 같은 향상된 기능을 갖춘 Web 2.0이 나와있는 상황에서는 말이다. 이 팀의 목표는
커뮤니티의 인터랙션을 활성화 하고 커뮤니티 활동을 지원하는 전개 프레임웍을 제공하는 것이다.
문제점
보
안 웹 사이트로 만들 것이기 때문에, 액세스가 허용되기 전에 계약(terms and conditions) 문서의 만기와 승인을
지원할 세션 관리가 필요하다. 또한 콘텐트도 직접 편집할 수 있어야 한다. 콘텐트에 어떤 액션이라도 취해지면 인터랙션 제어가
해당 콘텐트의 옆에 배치되도록 해야 한다.
기존 웹 사이트와 관련된 다른 문제들은, 이 웹 사이트가
일관성 없는 비주얼 언어, 네비게이션, 정보 아키텍처에 기반하고 있다는 점이다. 콘텐트는 가끔 리파지토리에 있는 문서 안에
숨겨진다. 다운로드 해서 보기 전까지는 문서에 무엇이 있는지를 알 수 없다. 이러한 분석을 통해서 우리 팀은 문서 리파지토리의
모델이 잘못된 모델이라는 것을 인식했다. 우리는 이것 보다 더 많은 일을 수행할 콘텐트 관리 시스템이 필요하다.
디자인 프로세스
우
리의 디자인 프로세스는 분석에서 프로토타이핑, 그리고 평가까지 반복적이였다. 엔드 유저를 가능한 빨리 질문서, 디자인 대안,
프로토타이핑에 참여시켰다. 우리는 비즈니스 목표와 엔드 유저의 필요에 맞춰 결정을 내리고 싶었다. 기능적 요구 사항이나 개발에
착수하기 전에, 사용자를 조기에 개입시킬수록 유용하고 좋은 결정을 더욱 빠르게 내릴 수 있다는 것을 깨달았다. 매우 값진
피드백을 모으기 위해 애쓰는 대신, 사용자가 디자인 프로세스에 참여하고 있다는 것을 인식시켰다. 또한 사용자 커뮤니티에 많은
신뢰도 쌓았다.
디자인을 이해하는 또 다른 요소는 정보 아키텍처를 이해하는 것이다. 예를 들어, 사용자 리서치를 통해서 가장 중요한 요구 사항들 중 하나가 다음의 주요 영역들로 액세스 하는 것이라는 것을 알았다: - 작업 그룹에 관한 정보
- 과거와 앞으로의 컨퍼런스에 대한 정보
- 모든 멤버에 관한 정보로의 액세스
명확하고 단순한 아키텍처가 필요했던 사용자 피드백을 통해서도 이것은 분명해졌다.
사이트에 방문하는 세 가지 계층의 사용자(또는 개인)를 분석을 통해 규명했다: 고객, 작업그룹 리더, 관리자이
다. 이들은 우리의 디자인과 의사 결정 과정을 구성했다. 어떤 정보가 중요한 것인지, 이것을 주요 인물들에게 어떻게
연관시키는지를 배워서, 콘텐트 아키텍처와 이것의 계층, 이것이 표현되는 방법, 각 계층의 사용자들이 정보와 인터랙팅 하는 방법을
만들 수 있었다. 예를 들어, 컨퍼런스 정보에는 아젠다나 세션 아이템, 아이템들의 스케줄링, 컨퍼런스의 관심 주제, 컨퍼런스을
통해 해결되었던 액션 아이템 등이 포함된다.
 | | 자세한 디자인 프로세스는 본 시리즈의 다음 기술자료에서 설명하겠다. |
|
분
석이 진행되면서 추가 기능들이 나타나기 시작했다. 예를 들어, 활동적인 커뮤니티를 지원하기 위해서는 콘텐트에 디스커션과 코멘트를
달 수 있도록 하고, 피드백과 온라인 협업을 지원해야 했다. 또 중요했던 클라이언트 요구 사항으로는 독자적인 브랜드나 비주얼의
사용 문제였다. 웹 사이트는 다른 배경을 가진 사용자들이 협업하는 중립적인 장소이므로 특정 기업이나 백그라운드로 시각적인 제휴를
하면 불필요한 분열이 조장될 수 있다.
개발 환경
개
발 프로세스를 완화하기 위해서, 기존 콘텐트 관리 시스템을 사용하여 시의 적절한 솔루션을 만들고 싶었다. 대부분의 콘텐트 관리
시스템들은 기본적인 기능을 지원했지만 구체적인 커스터마이징에 대한 뚜렷한 필요가 있었다. 기존 제품으로는 충분하지 않았다. 오픈
소스 커뮤니티에 적용되었던 작업 환경에 기반하여 개발을 하고 싶었다. 결국 우리가 사용했던 툴은 그러한 관습에서 온 것이다.
개
발 환경에 여러 가지 목표가 있었다. 이를 테면, 네트워크와는 독립적으로 코드 변경을 작성하고 테스트 할 수 있어야 한다는
것이다. 변경 사항들이 충분히 테스트 되면 그 코드를 개발 팀과 공유하고 싶었다. 이러한 반복적인 개발 사이클에서 우리는 원격
버저닝 시스템 CVS를 사용하게 되었고, 이것을 통해 팀 멤버들을 연결시키고 우리 모두가 공유할 수 있는 코드 베이스를 관리할
수 있었다.
우리는 프로젝트를 지원하고 통합 개발 환경(IDE)에 모든 기술들을 사용하기 위해
Eclipse를 선택했다. Eclipse는 많은 확장을 제공하고 Concurrent Versions System (CVS)와
매우 단순하게 통합된다. Eclipse 퍼스펙티브는 현재 액티비티를 지원하는 여러 뷰와 에디터를 제공한다. 우리는 PHP 모듈과
HTML 프라그먼트를 편집하고 있었다. Eclipse는 코드의 로컬 변경 사항을 트래킹 한다. 따라서 파일에 CVS로 체크하지
않아도 로컬 머신에서 파일의 이전 버전을 복구할 수 있다. 이러한 Eclipse 기능들로 인해 코드를 다시는 잃지 않는다.
우리는 개발과 테스트 환경을 중앙화 하여 코드와 팀의 다른 멤버들과의 작업을 최적화 할 수 있었다. 여러분의 시간은 파일과 다른
리소스를 관리하는 것이 아닌 코드를 작성하고 테스트 하는데 할애되어야 한다.
콘텐트 관리 시스템의 선택은
우리가 사용해야 하는 다른 툴과 관련되어 있다. Drupal의 경우, 페이지 개발에는 PHP, HTML, and
Cascading Style Sheets (CSS)를, 백엔드 스토리지에는 MySQL을 의미한다.
요구 사항
콘텐트 관리 시스템을 선택할 때 도움이 될 요구 사항들을 모았다. 그러한 기능들은 존재하지 않았지만 시스템이 쉽게 확장되어 이러한 기능들을 포함시키길 바랬다. 요구 사항들은 다음과 같다.
- 표현과 콘텐트의 분리
- 콘텐트에 In-place 주석달기
- 콘텐트 In-place 편집
- 쓰레디드 디스커션 그룹
- 액세스 권한 제어
- 콘텐트 검색
- 콘텐트 보기 전 인증
- 세션 제어(법적 계약의 종료일과 서명 포함)
- 디스커션을 통한 지원 커뮤니티 인터랙션
- 콘텐트 관리 시스템의 단순한 교육 과정
- 클라이언트에 양도할 콘텐트 관리 시스템의 단순한 관리 인터페이스
그림 1은 이 웹 사이트의 최종 디자인에서 나온 일반 페이지이다. 디자인과 구현의 다른 측면을 보면서 이 페이지를 보다 자세히 설명하겠다.
그림 1. 전형적인 IBC 웹 사이트 페이지
오픈 소스 콘텐트 관리 솔루션
전
체 콘텐트 관리 시스템 프레임웍에 제한된 콘텐트 퍼블리쉬만을 허용하는 웹 로그(Blog) 엔진 시스템부터 커스텀 콘텐트 관리
시스템을 구현할 수 있는 애플리케이션 프레임웍까지, 웹 사이트 콘텐트를 관리하는 많은 방법이 있다. 오픈 소스가 가진 광범위한
선택권 때문에 자신에 필요에 맞는 올바른 솔루션을 선택하기 어렵다.
결국 우리는 Drupal을 선택했다.
이렇게 결정한 이론적 근거는 충분하다. 다음 섹션에서는 Drupal, Mambo, Typo3, Ruby on Rails,
Movable Type, WordPress, TextPattern 등 후보 시스템들에 대해 설명하겠다.
콘텐트 관리 시스템의 비교
Drupal
"Drupal
은 개인 또는 사용자 커뮤니티가 웹 사이트 상에 다양한 콘텐트를 쉽게 퍼블리쉬, 관리, 구성할 수 있도록 하는 소프트웨어이다.
수 만 명의 사람들과 조직들이 Drupal을 사용하여 수십 가지의 웹 사이트를 설정하고 있다:- 커뮤니티 웹 포탈과 디스커션 사이트
- 기업 웹 사이트/인트라넷 포탈
- 개인 웹 사이트
- Aficionado 사이트
- 이-커머스 애플리케이션
- 리소스 디렉토리
Drupal
에는 콘텐트 관리 시스템, Blog, 협업 작성 환경, 포럼, 뉴스레터, 사진 갤러리, 파일 업로드/다운로드를 가능케 하는
기능이 포함되어 있다. Drupal은 GPL 라이센스 하에 배포되는 오픈 소스 소프트웨어이고 수 천명의 사용자 및 개발자
커뮤니티에 의해 관리 및 개발되고 있다. Drupal은 무료로 다운로드 및 사용할 수 있다." (출처: CMS Matrix)
Drupal은 다른 콘텐트 관리 시스템(CMS)에 비해 비교적 젊은 편이다. 하지만 프레임웍은 잘 작성되었고, 강력하고 확장성도 놀랍다. 개발 커뮤니티의 지원도 받고 있다.
다른 CMS와 마찬가지로 프레임웍은 확장성이 놀랍다. 우리에게 필요로 했던 많은 기능들이 웹 사이트의 핵심 기능이 될 수 있는 모듈로서 제공되었다.
프레임웍과 템플릿 시스템은 모두 PHP로 작성된다. 태그 언어를 배울 필요가 없다. 프레임웍에서 분리되는 것도 쉽다. (물론 이는 별로 권장하고 싶지는 않지만, 이 정도까지의 유연성을 보장하고는 있다.)
세션 관리는 코어 함수에 구현되었다. 이는 다른 CMS가 제공하는 것 이상이다. 나중에 몇 가지 문제를 해결할 때 도움이 된다.
Drupal
은 확장성 또는 개인 사용자 레벨에서 엔터프라이즈 레벨까지 웹 사이트가 쉽게 확대될 수 있는 것으로 알려져 있다. 이 프레임웍은
심각한 트래픽 상황 동안 문제를 일으킬 수 있는 사이트 부분을 억제할 수 있는 기능도 있다.
“Drupal
방식”으로 사이트를 구현하는 명확한 방법이 있지만 다른 CMS와 비교할 때 적은 편이다. PHP를 사용하기 때문에 비즈니스 로직
레이어에서 (PHP 템플릿 엔진을 사용하는) 표현 레이어간 자유롭게 이동할 수 있다는 점 또한 매력적이다.
Drupal의 액세스 컨트롤은 확장 기능을 사용하면 보다 세분화 될 수 있다. Drupal 4.7은 4.6을 보강하여 릴리스 되었다.
Mambo
“Mambo
오픈 소스는 오늘날 가장 세련된 오픈 소스 콘텐트 관리 시스템이다. Mambo는 설정과 관리가 쉽다. 설치 유틸리티는 4 단계
마법사 인터페이스를 사용하여 해박한 기술적 지식 없이도 전체 시스템을 설치할 수 있다. 일단 설치되면 시스템에는 실행할 준비가
되어있는 많은 기능들을 선택할 수 있다. 콘텐트는 HTML, XML, DHTML에 대해 알지 못해도 추가, 편집, 조작될 수
있다. 자신에게 친숙한 에디터를 사용하여 콘텐트를 입력하고 Publish만 클릭하면 된다. 고급 사용자들은 자신의
스킬에 맞는 레벨에서 시스템을 제어할 수 있다. 코어 파일은 PHP로 작성되고 [Mambo는 Linux™, Apache,
MySQL, P for PHP, Perl, Python (LAMP) 기반이다.] 쉽게 수정될 수 있다. 시스템은 강력하고
입증되었으며, 대형 사용자 커뮤니티와 전문 개발자 커뮤니티의 후원을 받는다. (2006년 초에, Mambo는 5살이 되었다.)”
(출처: CMS Matrix)
Mambo는 대중성을 띄게 되었고 매우 쉬운 설치와 매력적인 관리 인터페이스를 제공한다. 클라이언트가 웹 사이트를 관리해야 한다면 CMS의 백엔드는 매우 중요하다.
손
쉬운 설치를 통해 우리가 필요로 하는 거의 모든 기능을 사용할 수 있고 테마 설정을 할 준비가 된 상태가 된다. 하지만, 많은
CMS가 그렇듯, 템플릿 만들기는 태그 시스템으로 제한된다. 태그를 대체하는 마크업의 도움을 받을 수 있다. 마크업이 유효하고,
문법적으로 구조화 되고, CSS ID와 클래스 애트리뷰트로 적절히 구축된다면 다행이다. 하지만 그렇지 않다면, 생성된 아웃풋을
정정하는 방법을 모색하기 위해 애플리케이션의 중심부까지 파고들어야 한다.
Mambo는 다른 CMS가 제공하는 것 이상의 것이지만 제한된 세션 관리를 제공했다.
개발 경로는 혼란스러웠고 이 솔루션의 미래는 확실치 않았다. Mambo의 개발 트랙은 여러 솔루션으로 나뉜다. Miro는 상용 제품이고 Joomla는 Mambo에서 만들어진 새로운 CMS이다.
Typo3
“Typo3
는 엔터프라이즈급 오픈 소스 콘텐트 관리 시스템으로서 GPL 하에서 배포된다. 전 세계 122,000개 이상의 서버에서
실행된다. 이 애플리케이션은 43개의 언어로 번역되었고 60개국에서 27,000명 이상의 사용자 커뮤니티에서 활발히 개발되고
있다. 사용자 중에는 BASF, DaimlerChrysler, EDS, Konika-Minolta, Volkswagen,
UNESCO를 비롯하여 많은 대학, 정부 기관, 비영리 기구들이 있다.” (출처: CMS Matrix )
Typo3는 크다. 대형 애플리케이션. 대형 커뮤니티. 대규모 채택. 대규모 확장 기능과 기여. 교육 과정 역시 대단하다. Typo3가 우리가 필요로 하는 모든 것을 수행할 것임은 의심할 여지 없지만 복잡함 외에도 다른 문제들이 있다.
많
은 핵심 및 기여 모듈에서 만들어진 마크업은 90년대 중반부터 후반까지 구조를 사용했다. 많은 테이블 레아아웃이 있지만,
효과적으로 배치된 CSS ID와 클래스 애트리뷰트를 사용하지 않았고 가끔은 사용할 수 없는 구조도 있었다. 우리는 현재의 베스트
프랙티스를 사용하여 개발 반복 과정을 유연하게 유지하고 싶었기 때문에 이는 도움이 되지 않았다. 템플릿을 만드는 시스템 역시
다른 솔루션에 비해 매우 복잡했다. 웹 콘텐트의 테마를 만드는 방법을 이해하느라 드는 시간도 너무 많이 걸렸다.
관리 인터페이스도 어색하고 오래되었다. 특히 Mambo와 비교할 때 더욱 그랬다. 우리는 사이트 관리를 사용자에게 넘겨야 하기 때문에 이는 중요한 고려 사항이었다.
더 많은 시간이 있었다면 Typo3가 옵션이 되었을 수도 있었다. 하지만, 다른 CMS를 사용하여 재 작성 하는 것이 더 나았다. 표준 기반의 xHTML과 CSS를 사용하는 문제가 새 버전의 Typo3에서 다루어 질 것이다.
Ruby on Rails
“Ruby
는 순수한 객체 지향 프로그래밍 언어로서 프로그래밍을 멋있고 재미있게 만드는 깨끗한 신택스를 제공한다. Ruby는
Smalltalk의 개념적 우수성과 Python의 편리함, Perl의 실용성을 성공적으로 결합했다. 1990년대 초반 일본에서
만들어진 Ruby는 영어 책과 문서를 사용할 수 있게 되면서 지난 몇 년 동안 전 세계적으로 대중성을 확보했다. Rails는
오픈 소스 Ruby 프레임웍으로서 데이터베이스의 지원을 받는 웹 애플리케이션을 개발할 때 사용된다. Rails의 기본 원리는
less software와 convention over configuration이다. Less software는 적은 라인의
코드로 애플리케이션을 구현하는 것을 의미한다. 코드를 작게 유지하면 개발은 빨라지고 버그는 줄어든다. 이로서 코드는 이해하기도
쉽고 관리 및 향상하기도 쉬워진다. Rails는 코드 부담을 확실히 줄여준다.
Convention
over configuration은 장황한 XML 설정 파일의 종말을 의미한다. Rails에는 더 이상 XML이 없다. 설정
파일 대신, Rails 애플리케이션은 간단한 프로그래밍 규약을 사용하여 리플렉션과 발견을 통해 모든 것을 규명한다. 애플리케이션
코드와 실행 데이터베이스에는 이미 Rails가 알아야 할 모든 것이 포함되어 있다." (출처: Rolling with Ruby on Rails)
전
형적인 콘텐트 관리 시스템은 인증을 받은 사용자들이 콘텐트 형성 페이지를 웹 사이트의 일부로서 만들 수 있도록 한다. Ruby
On Rails (ROR)는 이를 제공하지 않는다. 대신 웹 애플리케이션 프레임웍을 제공한다. ROR을 사용하여 커스텀 CMS를
구현할 수 있다.
프로젝트를 진행하면서 ROR과 관련한 많은 말들이 있었고, 대개는 37Signals와 Base Camp 같은 실제 온라인 ROR 애플리케이션의 어레이 때문에 생겨난 것들이다.
프레임웍을 통해 데이터베이스로 바인딩 하는 방식을 좋아했다. 개발의 반복적인 부분들의 속도를 높이는데 도움이 되었다.
프레임웍을 조사할 당시, 이 프레임웍은 다소 Blog 중심이었다. 안정성도 문제였지만 향후 프로젝트에는 사용하기로 했다.
커스텀 CMS를 구현하는 것은 매력적인 일이다. 예를 들어, 커스텀 솔루션을 통해 테마 작성이 가능한 관리 인터페이스를 만들 수 있다. 하지만 시간이 제한되었기 때문에 CMS 프레임웍이 필요했다.
Blog 엔진
Blog
의 생성을 지원하는 기존 퍼블리쉬 시스템을 사용하는 것도 고려해 보았다. 우리는 이전에 그와 같은 시스템을 사용하여 카테고리와
데이터가 사용되는 방식을 재정의 함으로서 Blog가 아닌 웹 사이트용 콘텐트를 지원했다. 이러한 유형의 솔루션들은 Drupal,
Mambo, Typo3 같은 것과 비교되지도 않는다. 예를 들어, Drupal과 Typo3에서 제공하는 세션 관리는 지원되지
않는다. 하지만 간단한 CMS를 만드는 단순하고 빠른 방식을 제공한다.
솔루션이 Blog 중심이라면 다음과 같은 대안들도 있다:
Movable Type
“Movable Type은 강력하고 커스터마이징이 가능한 퍼블리쉬 플랫폼으로서 사용자들은 개인 퍼블리쉬 시스템 내에서 매력적이고
표현적인 웹블로그를 만들 수 있다. 서버 기반 소프트웨어로서 실행되는 Movable Type은 개인과 기업들이 채택하여 많은
기능들, 오픈 아키텍처, 서드 파티 플러그인의 강력한 라이브러리를 활용하고 있다. 전 세계에서 헌신된 개발자들이 만든 수 백
개의 플러그인을 기반으로 구현되는 이 애플리케이션은 Movable Type 시스템에서 구현될 수 있다.” (출처: CMS Matrix)
가
장 대중적인 Blog 퍼블리쉬 시스템들 중 하나인 이 Perl 구현은 많은 기여자들과 지원 구조를 갖고 있다. 제조자인 Six
Apart에 의해서 제품 개발을 지원하기 위해 비용 부담이라는 장애물이 생겼다. 우리는 오픈 소스 솔루션을 만들어야 하기 때문에
Movable Type을 사용할 수 없었다.
WordPress
“WordPress는 예술적 경지에 이른, 개인용 퍼블리쉬 플랫폼으로서 미학적인 측면, 웹 표준, 가용성에 초점을 맞추고 있다.
WordPress는 무료이기도 하고 값을 매길 수 없다. WordPress는 블로깅 소프트웨어어와 작업할 때 사용하는 것이다.
WordPress의 기본 기능은 사용하기 쉬운 플러그인 아키텍처를 통해 배가될 수 있다. (새로운 기능들이 쉽게 추가된다.)"
(출처: CMS Matrix)
WordPress는 우리 프로젝트 시점에 위상이 높아지고 있었다. Drupal과 비슷하고, wiki 스타일의 문서화 시스템을 갖추었다. 코어 코드는 깨끗하고 확장이 쉽고, 사용자 인터페이스 역시 사용하기 쉽다.
템플릿팅 시스템은 전형적인 탭 기반 시스템으로서 다른 Blog 퍼블리쉬 플랫폼과 비교된다. 시스템에서 생성된 아웃풋은 현재 베스트 프랙티스를 지원하고 콘텐트 레이아웃과 접근성을 보다 쉽게 만든다.
WordPress의 한 가지 단점은 캐싱 기능이 부족하다는 점이다.
TextPattern
"
웹블로그를 포함한 모든 종류의 웹 사이트를 위한 무료의 유연하면서도 사용이 쉬운 콘텐트 관리 시스템이다. 인터넷에 퍼블리쉬 될
때 초보자이든 전문가든 마찬가지로 문제에 봉착한다. 워드 프로세서와 그래픽 애플리케이션에서는 누구나 개인용 컴퓨터에서 텍스트와
이미지를 관리할 수 있지만, 월드와이드 웹에서 사용할 수 있으려면 다중 언어 프로그래밍 스킬, 컴퓨터 기반 그래픽 디자인의
효율성, 그리고 무엇보다도, 인내심이 필요하다. 어쨌든 꾸준히 버티는 사람들도 웹의 불변성, 가장 평이한 텍스트만 다루는 것,
WYSIWYG Web 에디터를 사용할 때의 예측 불가능한 결과 때문에 좌절할 것이다. TextPattern은 온라인에 퍼블리쉬
할 때의 문제점을 극복하고 잘 구성된 표준 순응의 웹 페이지의 생성을 단순화하기 위해 설계된 웹 애플리케이션이다.” (출처: CMS Matrix)
WordPress와 마찬가지로 TextPattern도 여느 블로그 퍼블리쉬 시스템과 비슷하다. 깔끔한 관리 인터페이스가 있고 사용하기 쉽다. 하지만 세션 제어와 캐싱 같은 우리가 필요로 하는 많은 기능들이 부족하다.
그림 2는 위에서 설명한 제품에 대한 소프트웨어 요구 사항이다.
그림 2. 콘텐트 관리 프레임웍에 대한 소프트웨어 요구 사항
Drupal을 사용하기로 한 결정
솔
루션 채택이 쉽고, 프레임웍의 설치가 쉬우며 사용하는 방법을 쉽게 파악할 수 있는 웹 사이트 디자인을 만들고 싶었다. Ruby
on Rails (ROR)도 매력적이었지만 CMS를 작성하는데 너무나 많은 시간이 들기 때문에 ROR은 제외했다.
각
사람에 대한 정보에 효과적인 액세스 제어를 할 수 있었다면 강력하고 유연한 세션 및 사용자 관리로 구현이 더 쉬웠을 것이다.
물론, 기존 프레임웍에 기여하는 활발한 커뮤니티의 도움을 받아 강력한 인프라스트럭처를 갖는다면 구현 속도도 높아질 것이다.
또 다른 핵심 요소는 동시 사용자의 수가 증가할 때 확장성을 높일 수 있는 능력이었다.
콘
텐트가 디스플레이 되었던 방식을 쉽게 조절할 수 있다는 것도 중요했다. 디자인의 반복과 향후 조정 과정 동안 유연성을 원했다.
소위 "themability"도 xHTML, CSS와 관련하여 현재의 웹 디자인 방식을 사용하는데 필요했다.
그림 3은 후보 제품들이 요구 사항에 어떻게 부합하는지를 비교한 것이다. 블로그 엔진이 제공하는 것 이상의 어떤 것을 필요로 했다는 것이 명확해졌다.
그림 3. 요구 사항에 기반하여 후보 평가하기
Mambo는 설치가 쉽다는 점과 UI 때문에 매우 매력적인 후보였지만 그 당시 개발 트랙이 없어졌기 때문에 지원 부분을 확신할 수 없었다.
Typo3는 거대한 커뮤니티와 성숙도를 자랑했다. 하지만 Typo3의 교육 과정은 Drupal과 비교할 때 너무 길었다.
Drupal
방식을 익히는데 얼마 간의 시간을 투자해야 했고 프레임웍도 합리적이었다. 또한 Drupal은 프레임웍과 유연성을 올바르게
결합하여 작업을 수행하는데 필요한 프레임웍이 준비되었다. 이 모든 것을 심사 숙고한 다음 Drupal을 사용하기로 했다. 오픈
소스 CMS는 지속적으로 변하고 있고 앞으로 이 분야에 새로운 엔트리가 생길 것이다.
Drupal 상세
Drupal에는 많은 빌트인 기능이 포함되어 있고 활발한 커뮤니티의 지원을 받고 있다. 기본적인 기능은 다음과 같다: - Apache의 mod_rewrite 기능을 사용하는 친숙한 URL.
- Drupal의 모듈 프레임웍을 사용하여 쉽게 확장됨.(커뮤니티는 분류법 디스플레이, jabber 인증, 개인 메시지, 북마크 같은 기능을 제공하는 유용한 모듈을 개발했다.)
- 사용자 선호에 기반한 콘텐트와 표현을 위한 개인화된 환경.
- 콘텐트의 보기 및 편집에 대한 액세스를 정의하는 역할 기반 권한 시스템.
- 콘텐트 인덱싱을 통한 검색 지원.
- Drupal은 데이터베이스 추상화 레이어에서 작성되기 때문에 프레임웍은 다른 데이터베이스 백엔드로 쉽게 확장된다.
- 폴, 쓰레디드 코멘트, 디스커션, 콘텐트 신디케이션 같은 콘텐트 폼 지원.
- HTML, CSS, PHP를 사용하는 템플릿팅 시스템에서 콘텐트와 스타일링을 분리함.
- 로깅, 분석, 웹 기반 관리 지원
- 온라인 도움말
Drupal 확장하기
우리는 Drupal의 모듈 프레임웍을 사용하여 우리 웹 사이트를 지원하는데 필요한 확장 기능들을 추가했다. 확장 기능은 다음과 같다: - 익스트라넷 환경 만들기 -- 정보를 보기 전에 인증을 요구하는 폐쇄 액세스 사이트
- 사용자와 웹 사이트 인터랙션에 기반한 세션 종료
- 계약 정책 구현
- “인 플레이스(in place)” 편집을 제공하는 기존 콘텐트 편집 인터페이스의 확장(웹 페이지에서 이들이 편집하는 것을 권한이 있는 사용자에게 보여주고 그 콘텐트를 편집할 수 있도록 하는 것.)
- 모든 멤버들이 봐야 하는 일반 정보를 공표하는 공지 관리
- 작업 그룹 미션, 현재 상태, 액션 아이템의 관리
- Ajax를 사용하여 컨퍼런스 세션과 아젠다의 생성을 관리함
- 멤버 정보와 정보 검색을 위한 확장 뷰 및 관리 인터페이스
- 사이드 바로 디스플레이 된 추가 정보 블록을 통해 멤버 역할과 이들이 소유하거나 만든 데이터에 기반하여 데이터 디스플레이 하기
- 특정 콘텐트 영역에 관심을 가진 멤버들에게 주간 정보를 이메일로 전달함
| | 확장 기능에 대해서는 후속 기술자료에서 자세히 다루겠다. |
|
우리는 Drupal 4.6에서 웹 사이트를 개발했지만 현재 Drupal 4.7을 사용할 수 있다. 본 시리즈는 Drupal 4.7을 중심으로 설명한다.
기타 콘텐트 관리 프레임웍
콘텐트 관리 프레임웍은 많이 있다. 각자의 필요에 따라 평가해보기 바란다. 이 글에서는 다음 프레임웍의 장단점을 살펴보았다:
요약
오
픈 소스 소프트웨어를 사용하여 협업 웹 사이트를 디자인, 개발, 전개하는 방법을 설명했다. 프로젝트의 개요와 요구 사항을
설명하고 여러 콘텐트 관리 시스템들을 비교해 보았다. 또한 Drupal을 사용하기로 한 이유와 우리의 목표에 맞게 Drupal을
확장하는 방법도 설명했다.
다음 글을 기대해 주기 바란다. 애플리케이션 디자인 과정을 다룬 유연한 디자인
방법을 설명할 예정이다. 웹 사이트나 애플리케이션을 디자인하는 과정이다. 개발 프로세스의 기술적 측면을 설명하는 것과 아울러
개발 툴 슈트와 지원 기술을 활용하는 방법도 단계별로 설명하겠다. 개발 환경을 개인화 하여 작동시키는 방법도 설명하겠다: - Drupal 시작하기
- Drupal과 MySQL, PHP, CSS, Ajax 같은 소프트웨어 툴과의 인터랙션
- 커스텀 Drupal 모듈 구현하기
- 전개 및 튜닝
여러분이 강력한 콘텐트 관리 툴을 사용하고 웹 애플리케이션을 효율적으로 커스터마이징 할 수 있기를 바란다.
기사의 원문보기
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | Alister
Lewis-Bowen은 IBM Internet Technology Group의 소프트웨어 엔지니어이다. 1993년부터 IBM
UK에서 인터넷 및 웹 기술과 관련 분야에서 일했다. 미국으로 건너와 IBM이 후원하는 스포츠 이벤트용 웹 사이트 작업을 했으며
ibm.com의 시니어 웹 마스터로서 활동하고 있다. (alister@us.ibm.com) |
| 
| | Stephen
Evanchik은 IBM Internet Technology Group의 소프트웨어 엔지니어이다. 많은 오픈 소스 소프트웨어
프로젝트의 기여자이며, 그의 IBM TrackPoint 드라이버는 리눅스 커널에서 가장 주목할 만한 것이다. (evanchik@us.ibm.com) |
| 
| | Louis Weitzman은 IBM Internet Technology Group의 소프트웨어 엔지니어이다. 30년 동안 디자인 및 전산 분야에서 일해왔다. ibm.com에서 사용중인 XML, 프라그먼트 기반 콘텐트 관리 |
|
