an article about XSLT

말씀하신 것들은 기본적으로 자바라는 전제를 깔고 있습니다.
XML은 그런 전제를 제거하는 것을 주요 목적으로 하고 있죠.

casterxml이나 hibernate에 익숙한데, 프로젝트를 .net 플랫폼에서 수행해야 한다면 어떻게 될까요?
물론 펜더님이시라면 xslt를 알고 있는 상태에서 caster나 hibernate를 쓰시는 것이겠지만, 역시 xslt는 필요하다(알아둘 필요가 있다)고 생각합니다.

내용도 좋지만 여기 글 올린 분들의 글 속에서 자신의 주장과 타인에 대한 배려가 함께 조화를 이루는게 너무 아름답습니다.
아직 시작이긴 하지만 참 오랜만에 좋은 토론을 보는것 같아서 제 기분도 좋아 지네요. :D

제 의도를 조금 잘못 파악하신 것 같습니다. 저의 주장은 XSLT를 배울 필요가 없다는 뜻이 아니라 XSLT를 거의 프로그램 언어의 수준으로 확장하는 시도는 생산성이나 유지보수 등등의 측면에서 하등 이익이 없다는 뜻이었습니다. 말씀하신 대로 XML은 플랫폼이란 틀을 벗어나 이종 시스템 간의 통신을 돕기도 합니다만 이 경우도 역시 백엔드는 무얼로 구성하든 하등 문제가 될 것이 없습니다. 그렇다면 어차피 최종 결과물이 XML인 이상 백엔드를 굳이 XSLT에 데이터베이스 접속 정보까지 익스텐션으로 하드코딩을 하는 구성 보다는 OR 매퍼등을 적절히 쓰는게 훨씬 나은 설계가 아닌가 하는 지적이었습니다.

사실 저도 초기에 비슷한 시스템을 구축한 적이 있습니다. 한참 XML이 지금의 웹서비스와 같이 거품과 함께 유명세를 타던 때였는데, 때맞춰서 MS-SQL에 XML 확장 모듈이 나왔습니다. 즉 데이터베이스 서버 자체적으로 HTTP 리퀘스트를 받아 적절한 데이터를 미리 정한 xml 형태로 응답하는 것입니다.

여기에 XSLT만 덧씌우면 바로 HTML이 되기 때문에 이를 이용해서 간단한 웹사이트를 사실상 코딩 없이 만든 적이 있습니다. 아마 이런 정도가 XSLT가 프로그램의 역할을 대신해서 쓰일 수 있는 이상적인 경우가 아닌가 싶습니다.

반면에 이런 식의 구성 - 즉, XML/XSLT 자체에 스크립팅이나 확장 등으로 프로그램이 할 역할을 분담시키는 시스템의 규모가 커질 경우 분명 문제가 발생합니다.

우선 비슷한 역할을 하는 이질적인 산출물이 많이 발생합니다. 같은 개념을 나타내기 위해 데이터베이스와 클래스, 그리고 XML 관련 코드가 별도로 존재하며 이를 서로 동기화 하는 작업에도 일정한 노력이 듭니다. 반면 퍼시스턴스 엔진과 XML 바인딩을 사용하는 경우 비즈니스 적으로 중요한 개념은 모두 '클래스'라는 객체지향언어를 다루는 프로그래머에게 가장 익숙한 형태로 단일한 뷰를 통해 제공됩니다. 이 경우 아예 '어댑터'란 개념 자체가 필요 없이 도메인 객체 하나로 처리가 가능합니다. 예를들어 pseudo 코드를 보면 :

Order order = (Order) session.load("1234");
Marshaller.marshal(order, writer);

이렇게 데이터베이스에서 '1234'라는 PK를 가진 주문 '객체'를 가져와서 writer에 이를 XML 형식으로 쓸 수 있습니다. XSL 안에서 동일한 내용을 처리 한다면 구현에 따라 차이는 있지만 데이터베이스의 스키마, 접속정보가 들어가야 하며 이런 정보의 변경시 여러 부분을 수정해야 합니다. 또한 IDE를 통해 코드 자동완성, 리팩터나 디버깅을 사용할 수 없고 무엇보다 언어 내에서 간단하게 처리할 수 있는 부분도 별도의 확장이나 스크립팅을 통해 제한적으로 쓸 수밖에 없습니다.

하다못해 XSLT안에서 예외처리나 로깅, 그리고 SQL 관련한 캐쉬나 커넥션 풀등을 자유롭게 이용하는게 불가능하진 않지만 매우 번거로운 작업임은 분명합니다.

따라서 제 생각엔 특히 어느 정도 규모가 있는 서버 응용프로그램을 만든다면 XSLT의 역할은 최대한 본래의 목적인 XML 문서의 변환으로 제한하는 것이 바람직한 것 같습니다.

iolo님의 의도는 이해했습니다. 다만 첫 글에 링크된 내용들을 읽어 보시면 XSLT를 'functional programming'으로 사용하는 방법입니다. 그리고 글을 올리신 분께서도 데이터베이스 접근 등 XSLT의 이런 측면을 활용하는 구체적인 예들을 제시하셨고 저는 이런 접근 방법이 최선이 아닐 수 있다는 지적을 한 것 뿐입니다.

처음 올리신 분께서도 단순히 'XSLT라는 기술이 있다더라'는 말씀을 하신 건 아닌 것 같은데요, 제가 잘못 이해했나요? :)