테크니컬 라이터는 XML기반 저작으로의 전환이 그다지 유쾌하지 않다.  하지만 왜 누군가가 애써 패러다임을 전환하려고 하는 것일까?

관리자들에게 XML은 다음과 같은 기회를 준다.

쉬운 도구의 선택과 관리
DTP의 경우 모든 도구들이 자신만의 포맷을 가지고 있기 때문에 이종간의 호환이 불가능하다.
그래서 컨텐츠 관리 시스템 역시 선택의 폭이 한정적이였다.
XML은 텍스트 기반의 application-neutral 포맷을 지향하기 때문에 관리자는 다양한 저작, 출판, 컨텐츠 관리 도구를 선택할 수 있다.

자동 편집
말한 바와 같이 XML의 경우 저작자는 단지 컨텐츠의 저작에만 힘을 쓴다.
완성된 컨텐츠를 편집하는 것은 모두 자동화되어 있다.
물론 출판 환경을 셋업하는 것은 큰 노력이 투여되는 작업이지만, 일단 프로세스가 확립되면 결과물이 인쇄물이던, web이던, 온라인 도움말이던 간에 편집 과정은 자동화된다.
즉, 문서를  만들 때 마다 되풀이 되었던 편집에 대한 공수가 사라지게 되고 이것이 전체 문서 생산에 필요한 비용을 감소시킨다.

정보 품질의 향상
기존의 편집에 들었던 노력을 온전히 내용의 품질을 향상시키는 쪽으로 전환 할 수 있기 때문에 정보의 품질이 향상된다.
또 탬플릿과 문서 구조를 강제하여 정보의 일관성이 향상되며, 메타데이터를 이용하여 검색과 관리가 편해져 문서의 재활용, 재사용성이 향상된다.

비용절감
XML을 이용하는 가장 큰 이유는 비용 절감이다.  특히 컨텐츠가 로컬라이즈 되야 하는 경우라면 절감 효과는 더 크다.

XML 기반 저작 프로세스를 도입하기 위해서 관리자는 반드시 아래 두가지 사항을 해결해야 한다.
인력
내부 인력이던 컨설턴트던 XML 도입, 교육,  문제 해결을 위한 인력을 확보해야 한다.

기존 스텝의 저항
XML 도입을 통한 대부분의 이익은 관리자에게 돌아간다.
문제는 기존의 테크니컬 라이터에게 영향을 준다는 점이다.  기존의 오랜 프로세스가 변화하게 되고, 새로운 것을 배워야하고, 기존의 방식으로는 해결될 수 없어 새로운 정책을 수립해야하는 몇가지 문제들에 대해서 부딪치게 되는 것은 테크니컬 라이터의 몫이기 때문에 저항과 회의심을 갖게 되는 것은 당연할 수도 있다.

저항에 대한 예측과 해결
진정한 테크니컬 라이터라면  저항은 그다지 거세지 않을 것이다.
그들은 이미 XML 기반의 기술 문서 저작 방법에 대해 어느정도 알고 있으며, 오히려 이를 환영할 수 도 있다.
하지만 저항에는 반드시 이유가 있다.
라이터들은 자신의 사용도구에 꼼꼼하다.  그렇기 때문에 XML이 기존의 도구의 기능을 모두 커버하지 못하거나 라이터의 요구를 해결해 줄 수 없다면 기능이나 요구의 중요성을 떠나서 저항의 소지가 될 가능성이 크다.

그래서 implementation이 중요하다
구현 단계에서 부터 워크플로, 필요 기능에 대한 요구 분석이 상세해야 하며, 이 과정에서 XML 기반 저작에 대한 비전과 실체를 라이터들에게 적극적으로 이해시켜야 한다.

라이터의 견해에서 파일럿 시스템을 구축하고 이를 출판 시스템까지 천천히 확대하는 것이 저항을 최소화 하는 방법이다.  이 과정에서 기존 시스템이 가지고 있던 단점 (반복적인 일의 반복 또는 구현되지 않던 문제)를 찾아 내고 이를 해결하는 것도 라이터에게 중요한 가치를 줄 것이다.

스텝을 유심히 살피고 그 중 얼리어답터를 리더로 뽑아라.
그들은 아마도  XML 솔루션이 줄 비용적인 가치에 대해서는 별 관심 없을 것이다.  단지 새로운 기술과 도구에 대해 흥미를 가지고 테스트하려고 할 것이며, 그렇게 완성된 프로토타입을 확장하는 것이 좋은 방법이다.
새로운 기술을 대하는 그들의 태도는 아마도 XML이 가지고 있는 몇가지 기술적인 부족함을 용서할 것이다.

그렇다고해도 회의론자들은 있다.
회의론자들은 문제를 찾는데 열심일 것이고 모든 문제를 당신을 탓으로 돌릴 것이다.
문제를 발견한다는 것은 전문성이 없으면 불가능하고, 개선의 실마리를 준다는 점에서 의미 있다.
그렇기에 당신은 그들을 자신의 편으로 만들어야 하며 얼리어답터와 회의론자 모두에게 인정 받을때 implementation은 성공적이라고 할 수 있다.

새로운 시스템을 도입하는 것은 적지 않은 시간이 걸리기 때문에 또 하나 고려해 볼 수 있는 옵션이 유지/보수이다.
파일럿에서 본격적인 시스템으로 옮겨 가면, 약간의 컨텐츠가 생길 것이다.
이것을 바탕으로 신규로 제작되는 컨텐츠를 만드는 일을 현업에서 진행하고, 그 때 발생하는 문제를 유지/보수팀이 해결해 주는 방식이다.   또 유지/보수의 상시 운용을 위해서를 레거시 데이터를 변환하는 작업을 진행 시킬 수도 있다.
레거시의 변환에서 파일럿때는 발견하지 못한 문제와 개선점을 도출할 수도 있기 때문이다.

패러다임 전환은 많은 노력을 요구하고, 그렇기 때문에 저항은 필연적이다.
저항을 극단적으로 생각하면 반드시 실패한다. 
반드시 라이터의 입장에서 프로젝트의 위험요소를 고려해야 하고, 그들을 설득하고, 융화시키고, 그들이 새로운 도구와 시스템에 적응할 수 있도록 충분히 지원해야 한다.