▲

XSLT - 웹을 위한 Native, Zero-Config 빌드 시스템

 (github.com/pacocoursey)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • XSLT는 복잡한 빌드 시스템 없이 바로 사용할 수 있는, 웹을 위한 기본 제공 빌드 도구임
  • 대부분의 정적 사이트 빌드시스템은 복잡성, 이해 어려움, 프레임워크 의존성 문제가 있음
  • XML과 XSLT를 활용하면 브라우저에서 바로 HTML을 생성 가능, 동적인 데이터 처리 및 마크업 생성이 용이함
  • 모든 주요 브라우저가 XSLT 기반 변환을 지원하여 추가 JavaScript나 별도 툴 없이 사용 가능함
  • 완벽한 솔루션은 아니지만, 웹 표준에 기반한 심플하고 유연한 대안으로 활용 가치가 높음

소개 및 문제의식

  • 대부분의 정적 웹사이트 개발 과정은 데이터를 위한 파일(.json, .md, .txt), 별도의 빌드 시스템(Hugo, Next.js, Astro 등), HTML 산출물 구조로 이뤄짐
  • 빌드 시스템은 복잡성이 증가하고, 작은 블로그조차 이해와 운영이 점점 어려워짐
  • 프레임워크를 배제하고 간단한 HTML, CSS, 표준 명세(HTTP, URI, HTML)만으로 작업하려다 보면, 헤더나 푸터 반복 등 유지보수에서 한계 발생함
  • HTML import, web component 등도 시도했지만, 전자는 지원이 없고, 후자는 JavaScript 엔진 의존 문제로 대안이 되지 못함

웹 브라우저를 빌드 시스템으로

  • 웹 브라우저 자체가 다양한 데이터 변환(text/html, text/markdown, application/xml 등)을 지원한다는 점에 착안함
  • 웹 명세를 깊이 있게 살펴보고, 불필요한 외부 도구와 프레임워크 없이 문제 해결법을 고심함

XSLT의 활용

  • RSS 피드를 예쁘게 보여주고 싶어서 XSLT 명세를 발견함
  • XSLT는 XML 데이터와 HTML 출력 구조 모두를 표현하는 공식 표준 기술임
  • 사용 방법은 간단함
    • 예를 들어 blog.xml에 데이터를 정리
    • 다음과 같이 XSLT 스타일시트 연결
      • <?xml-stylesheet type="text/xsl" href="blog.xsl"?>
    • blog.xsl에는 HTML 템플릿 및 데이터 매핑 규칙 작성
  • 템플릿, 반복, 변수, 외부 파일 import 등 대부분의 빌드 시스템 기능이 지원됨

실행 방법 및 장점

  • 별도 도구 없이 XML 파일을 웹 브라우저로 열기만 하면 변환 결과가 바로 렌더링됨
  • XML 포맷은 HTML과 유사하여 인간 친화적이고 유지보수 용이, JSON 대신 사용해도 불편함 적음
  • 주요 웹 브라우저는 모두 XSLT 기반 변환을 네이티브로 지원하여, 클라이언트가 직접 변환 결과를 확인 가능
  • JavaScript, 별도 빌드 도구, 번들러가 필요 없다는 점이 대단히 큼
  • XSLT는 궁극적인 만능 해결책은 아니지만, 심플하면서 확장성 있는 웹 빌드 대안임

결론

  • 과거의 기술(XSLT)과 명확한 표준의 가치를 재발견
  • 웹 브라우저를 빌드 시스템으로 활용하는 방안은 웹 개발 도구 상자에 추가할 만한 유용한 옵션임
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 내가 몸담았던 회사는 XML 템플릿에 XSLT를 매우 많이 사용하는 곳이었고, 아마 아직도 그럴 가능성이 높음. 솔직히 좋지 않은 선택지였고, 가능하다면 다른 걸로 옮기고 싶어했을 것임

    1. XSLT는 최신 표준이 있음에도 여전히 1.0 버전이 주를 이루는데, 이 버전은 신규 표준에 비해 제한적이고 기이한 구석이 많음
    2. XSLT 템플릿의 성능 문제는 해결이 극도로 어려운 난이도임. XSLT는 튜링 완전 함수형 스타일 언어 특성상 성능이 안 보임. 대부분 문서에선 괜찮지만, 100개짜리 행이 들어오면 갑자기 터짐. 테이블을 처리하는 코드가 O(N^2) 성능을 가지고 있어 최적화도 거의 불가능함. 예를 들어, 행마다 O(N) 짜리 XPath가 들어가 있을 수도 있음. 내 기억으로는 해당 템플릿이 한 문서를 처리하는 데 7분 넘게 걸렸음.
      JS도 문제는 있지만, 적어도 이런 알고리즘 복잡도를 안 고칠 수밖에 없는 상황은 아님

    • XSLT/XPath는 1.0 이후로 꽤 발전함. key(index) 등 다양한 기능이 나와서 처리 속도 많이 빨라짐. Saxon 같은 품질 좋은 XSLT 구현체 쓰면 성능 문제도 훨씬 덜함. XML을 다른 것으로 변환할 때 XSLT만큼 논리 구조화에 편리한 것도 드물다고 생각함

    • XSLT는 배우기가 상당히 어려움. 마치 몽환적인 프롤로그 같기도 하고, 정말 숙련되면 스도쿠 풀 때의 짜릿함 느껴짐. 하지만 대부분의 경우 그렇게까지 복잡한 템플릿이 필요하지 않아서 표준적인 선택지가 되기는 힘듦. 그리고 XML 자체도 누구나 좋아하는 포맷은 아님

    • XSLT 1.0이 아직도 많이 쓰인다는 부분이 이해가 잘 안 됨. 2013년에도 이미 1.0은 거의 퇴물 취급이었고, XSLT 2 쓸 수 있는 Saxon은 무료에 성능도 굉장히 좋았음. 큰 문서든 작은 문서든 변환할 때 성능 문제 한 번도 경험한 적 없음

    • XSLT가 등장하던 시절은 본문이 매우 긴 XML을 처리하는 게 당연시되던 시기였음. 그런데 이렇게 반복 루프가 중첩되면 당연히 터지기 마련인 부분 특이사항임

    • 혹시 상용 버전의 Saxon을 쓰는지 궁금함. 가격도 비싸지 않고, 새로운 표준 지원 및 성능, 여러 기능 때문에 IMHO 정말 값어치 하는 선택이라고 생각함. 예전에 사용했을 때 상당히 똑똑한 최적화가 들어간 것으로 기억함

  • 90-00년대 브라우저는 서로 제각각이라 JS를 도입해서 동작을 맞추기 시작했음
    사실 우리가 원했던 건 멋진 CSS 스타일이었지만 그때는 제대로 쓸 수 없었음
    시간이 지나고 하나의 브라우저가 주도하게 되며 다른 브라우저들도 많이 비슷해졌고(Highlander 법칙, 하지만 Firefox도 꽤 선전 중)
    이미 프레임워크가 당연해져서 모든 브라우저에 동일한 UI를 맞추는 용도로 정착함. 그리고 패러다임 자체가 JSON 데이터 렌더링으로 이동함
    지금은 서버에서 전통적인 웹페이지를 생성해도 빠르고 메모리도 적게 쓰는 시대임
    왜 이런 생각을 하냐면, 최근 레거시 시스템에서 마이그레이션하면서 페이지 단위 HTTP 요청 방식(2000년대 표준)으로 동작하는 사이트를 다시 경험했음. 한 번 액션할 때마다 새로고침이 필요했지만, 오히려 React 쓰는 시스템보다 훨씬 빨랐음
    이유는

    1. 인터넷이 매우 빨라졌음
    2. 휴대폰 메모리가 풍부한데 JS 프레임워크가 그걸 낭비함
    3. 백엔드는 예나 지금이나 CRUD, CRUD, CRUD(+페이지네이션, +트랜잭션)임

    • AJAX와 DOM 갱신은 단순히 빨라지기 위해 등장한 게 아님. 웹의 패러다임, 즉 '웹사이트/웹문서'에서 벗어나기 위해서 였음. 전체 페이지 리로드는 문서 중심 패러다임에는 의미 있는 방식임. HN처럼 단순한 예시에서는 이러한 구조가 아주 잘 맞음. 많은 사이트가 JS 프레임워크 대신 이런 구조로도 충분히 동작함.
      하지만 "모두가 전체 페이지 리로드로 회귀할 수 있다"는 건 현실과 거리가 있음. 실제로 복잡한 인터렉션을 요구하는 '웹 어플리케이션'에는 페이지 전체 리로드가 아주 나쁜 UX임.
      요약하면,
      '웹사이트', '웹문서', '간단한 폼' 등은 전체 페이지 리로드만으로도 충분한 경우가 많지만
      '웹 어플리케이션'처럼 복잡한 데이터 화면/조작이 필요한 경우는 그렇지 않음

    • 내가 기억하는 당시의 타임라인은 조금 다름. JS는 브라우저 동작 통일화 용도보단 인터랙티브 요소를 처음부터 위해 썼음(DHTML, AJAX 등). 진짜로 레이아웃 잡는 것은 브라우저마다 거의 꼼수와 에이전트 감지에 의존했음. CSS가 더 강력해져도 일관성 문제는 쉽게 해결되지 않았음. CSS garden, 시맨틱 마크업, 테이블 남발 등이 그 시절의 분위기였고, 최초 ACID 테스트 패스까지도 정말 오래 걸렸음. 프레임워크가 UI 일관성에 어떤 영향을 줬는지 회의적임—jQuery 이후부터는 CSS 자체가 비주얼 일관성 주범이었음.
      물론 개인의 기억일 수 있음

    • 최신 기술 스택에서는 서버 렌더링 전통 웹페이지가 빠르고 경량임에 공감함
      내 .NET/Kestrel/SQLite 스택에서는 SSR 응답이 4ms 넘기 힘듦. 대부분 100마이크로초대임. 각 페이지마다 여러 쿼리와 복잡한 조인 써서 뷰에 맞는 데이터 형상 만드는 방식임
      100,000행 테이블 만드는 극단적인 케이스에서도 HTML 문자열 조합 전 데이터 가공을 잘하면 성능이 확 올라감. LINQ 성능도 엄청 좋지만, 행별로 콜렉션 만들면 데이터 건수가 많아질수록 오히려 매우 비효율적임
      내 경험상 HTML 템플릿 엔진과 데이터베이스를 최대한 가깝게 붙여놓아야 퍼포먼스 최적화에 가장 좋았음. 최종적으로 DOM은 그냥 바이트 스트림임. 굳이 복잡한 AST/파서 만드는 것보다 StringBuilder랑 SQL 쿼리만 조합해도 충분함.
      이런 간단한 방식에 대한 반론은 언제나 "개발자는 HTML 이스케이프 못 믿겠다"는 보안 담당자 논란뿐이었음

    • "최신 기술로 서버에서 예전 방식 고전 웹페이지로 충분히 대응 가능"이라는 얘긴, 만약 네트워크 레이턴시가 높으면 전혀 다른 얘기가 될 수 있음
      참고링크

  • 2000년대 엔터프라이즈 XML이 너무 비대해지면서 기술이 시대에 뒤떨어진 것처럼 보였고, 결국 모두가 JSON의 '깔끔함'에 빠짐. 사실 XSLT, XPath 같은 기술들은 이미 완성도 높아서 오늘날도 여전히 고민하는 문제를 많이 해결해줬었음
    나도 예전에 XSLT include 엄청 남용해봤는데, PHP 스트림 래퍼로 <xsl:include href="mycorp://invoice/1234">; 같은 거 쓰곤 했음
    솔직히 지금은 다소 구식 감각일 수 있지만, 브라우저에서 로컬 XSLT 처리시키는 건 여전히 불안함. 예전엔 호환성지뢰밭이었기 때문임

    • XML의 "기본" 요소들이 JSON에서 여전히 그리움. 예를 들면 진짜 표준화된 스펙이라든가, 스키마 정의 등은 XML이 훨씬 우위였는데 JSON이 따라잡는 데 거의 10년 걸림
      마지막으로 XML 제대로 만져본 게 EXI라는 전송 기술이었음. XML 문서를 압축 바이너리 스트림으로 바꿔주는 방식이었는데, 구조체 ↔ 아스키 변환 ↔ 압축/전송 ↔ 역변환 물론 번거로웠음. 지금은 protobuf, gRPC가 대세지만, XML이 계속 쓰였다면 모든 게 호환 가능한 표준 기반이라는(내 이상적 상상 속) 세상이 펼쳐졌을지도 모름. 사실 현실적으로 protobuf/gRPC와 JSON API 사이엔 엄청난 장벽이 생겼지만, 그게 오히려 나은 일일 수도 있음

    • XML은 괜찮은 포맷이라고 생각함. 분량이 많고 장황하긴 한데, YAML에 비하면 정밀성과 표현력 면에서 훨씬 뛰어남
      XPath는 익숙해지기 어렵지만 실험해보면 결국 원하는 걸 할 수 있음
      XSLT는 완전히 정신 나간 개념이라 생각함. 퇴출되어야 함

    • Rimworld라는 게임이 모든 설정 데이터를 XML로 저장하고, XPath로 모딩 가능하게 해둠. 이 조합이 정말 강력함. 로컬 데이터 커스터마이즈에는 이만한 게 없음. 그런데 대부분 게임들은 XML이 "구식"이라는 낙인 때문에 이런 걸 안 쓰려는 듯
      Rimworld의 XPath 모딩 공식 문서

    • 2000년대 초반 엔터프라이즈 XML이 비대해졌다는 얘기는 정말 사실임. 원래 XML은 SGML을 웹에 쓸 수 있게 단순화한 버전으로, 마크업 전달/보카블러리 확장 목적임. 결국은 SVG와 MathML만 살아남았음. 웹 붐에 휩쓸려 W3C/MS가 SOAP, WS-* 스펙등을 마구 쏟아냄. 한때는 Scheme 뼈를 지닌 XSLT 등 언어도 XML에 억지로 맞췄던 광기 가득한 시기였음. 심지어 JavaScript도 이름만큼은 Java에 빗댄 그런 시대

    • Xpath는 네임스페이스 때문에 질릴 만큼 장황한 쿼리를 써야 해서 아쉬움

  • 요즘도 XSLT로 내 피드를 스타일링해서 씀.
    RSS 피드 샘플
    XSLT 샘플

    • 이런 걸 보면 블로그란 게 그냥 RSS 피드여야 하지 않았을까라는 생각 하게 됨

    • XML이 원래 이런 걸 해줄 수 있다는 걸 늘 잊곤 함. 뭔가 직관적으로 어색하게 느껴짐

    • 정말 멋지게 잘 만들었음. 다른 사람들도 이런 예시 꽤 창의적으로 도입해봤으면 함

  • 첫 직장(19살때)에서 Google Search Appliance 커스터마이징 맡은 적 있었음. 수백만 원짜리 노란 Dell 서버들에 CentOS 깔고 구글스러운 파이썬, CIFS 문서 전체 텍스트 검색을 도입하는 프로젝트였음.
    2011년 무렵 XHTML이 대세였고, Google Search Appliance에서는 백엔드 XML 데이터를 XSLT로 XHTML로 변환함. 샘플 템플릿 폭파시켜가며 사내 인트라넷에 맞는 괴작 UI를 만들었고, Coldfusion, StackOverflow, W3Schools 등 기존 자산을 짜깁기해서 낑궈넣었음
    이 경력은 얼른 이력서에서 지움. 이후 DoD(국방부) 하청업체들이 자꾸 "XML 전문가"랍시고 문서 시스템 현대화 프로젝트에 부르려 해서 피곤했음
    다음에 JSX 써서 JSON에서 TypeScript 인터페이스로 배열 돌리는 걸 하며 한숨쉴 때 내 얘기를 생각해보길. 그나마 XSLT로 그 짓 하는 것보단 나음

  • 나는 단순함 추구자가 맞음. 원시인의 readme처럼 쉬운 문서 좋아함. 가끔은 원시인처럼 키보드 휘두르는 기분도 듦. 웹사이트는 안 하며 XSLT도 잘 모름. 가끔 XML로 해킹하고, 사용자를 위한 걸 보여주고 싶어짐. 파일 포맷 너무 많아 머리 아픔. 그래도 보기 좋은 건 좋아함. 나도 이거 쓸지도 모름
    명세 읽어줘서 고맙고, 툴 만들어줘서 감사함

  • XML이 장황하고 복잡해 보인다고들 하지만, 직접 다뤄 보면 훌륭한 포맷임
    DTD로 검증하고 XSLT로 출력해서 사람이 보기 쉽게 만들 수 있음
    내 기준에선 XML은 C++ 같은 텍스트 포맷임. 성숙하고, '배터리 포함', 강력하고, 어떤 언어든 연결 가능함
    오래된 성숙한 언어가 그렇듯, 사람들은 XML도 괴짜 콘텐츠라고 욕하는 게 트렌드가 된 게 아쉬움. 용도에 안 맞으면 안 쓰면 되지만, 너무 과하게 혐오할 이유는 없음

    • DTD가 아니라 XSD는 왜 안 쓰는지 궁금함

  • "브라우저에서 XSLT가 바로 동작한다"는 얘기가 신기함. 내가 마지막으로 XSLT 썼던 게 20년 전인데, 그때는 엄청 복잡한 엔터프라이즈 자바 덕분에 XSLT 고유 미학이 다 묻히는 느낌이었음.
    그런데 XSLT가 브라우저에서 기본 동작한다면, 호스트 프레임워크 없는 진짜 정적 템플릿의 성배가 코앞에 있었던 건가?

    • 브라우저들은 XSLT 1.0만 지원함. 그리고 이마저도 앞으로는 사라질 수 있다 얘기도 있음. 차라리 브라우저가 3.0까지 지원해주면 정적 웹페이지 생성에 엄청 쓸만해질 텐데 아쉬움

    • '대형 엔터프라이즈 자바' 타워를 꼭 써야 했던 건 아닌 경험도 있었음. 우리는 tomcat과 몇몇 apache 라이브러리만으로 썼고, 꽤 잘 동작했음. CMS에서 XML로 만든 HTML에, 개인화는 XML 태그 형태로 넣고, 서버 사이드 캐싱 프록시 덕에 변환도 빨라서 많은 트래픽도 소화 가능했음. 핵심은 XSLT 출력 스트림을 즉시 클라이언트로 내보내고, 메모리 전체 버퍼링 안 하는 거였음.
      요즘은 wasm 기반으로 뭔든지 브라우저에서 돌릴 수 있지만, 초창기 JS는 치명적이었고 디자이너들은 포토샵 PSD나 잘 넘겨주면 다행이었음. Google Maps, Gmail 나오던 시절 치열하게 javascript heavy UI 만들고, 당시 Netscape와 Internet Explorer 둘 다 지원해야 했던 진짜 헬

    • XHTML 붐이 일기 시작했던 것도 실은 바로 이 '정적 템플릿 성배' 때문이었음. 그런데 실제로 아는 사람들은 은어처럼 말을 아꼈고, 아무도 대놓고 얘기하지 않았던 묘한 분위기였음

    • 2008년에 브라우저 내 XSLT 사이트에서 일한 적 있었고, 그 전 초창기 2000년대에도 이미 지원했었음

    • Chrome은 libxslt, Firefox는 Transformiix라는 1.0 엔진이 탑재됨. Chrome은 exsl:node-set만 지원하고, Firefox는 다양한 EXSLT 확장 지원함(전부는 아님)
      간단한 XSLT 프로세서 정보와 사용 가능한 확장 리스트 알려주는 작은 도구도 공개함.
      GitHub - xslt-detect-ext
      브라우저에서 out/detect.xslt 파일을 드래그해서 정보 확인할 수 있음(Chrome, Firefox). Safari는 예전 Windows 버전에서는 안 됨

  • 90년대 고등학생 시절 "웹디자이너"로 불리던 시기에 DSSSL 방언 파이프라인을 사용해 뉴스피드에서 사이트를 자동으로 생성하는 걸 했었음. 나는 지금도 XSLT 변환을 좋아함. bananas XI reader 같은 툴을 이용해 실제 텍스트 변환 및 템플릿 작업도 직접 함
    하지만 이런 툴링을 진정으로 좋아하는 사람들 정말 적었고, 결국 내 자리를 누가 대신하면 도입된 기술은 빠르게 사라지곤 했음
    bananas XI reader

  • 2000년대 초 XML과 XSLT 열풍이 얼마나 심했는지 보여주자면, 내가 일했던 회사에서는 XML을 실시간 속도로 파싱하고 XSLT까지 칩에서 바로 처리하는 ASIC을 만들 정도였음. 당시 미래의 인터넷은 모두 XML/XSLT로 돌아간다고 믿었음.
    실제로 이 회사는 인텔에 인수 당했고, 그 기술은 SSE 가속기 쪽에 들어갔음

    • ASIC에서 XML 해석, XSLT까지 바로 가능한 그런 구조가 주류가 됐다면 지금쯤 웹사이트 속도 엄청나게 빠를 상상 해봄

    • IBM은 아직도 이런 기능이 비슷하게 내장된 하드웨어(DataPower Gateway)를 판매 중임

답변달기