AEM 및 엣지 전송 서비스: 웹의 근원으로 돌아가다

얼마 전까지만 해도 웹 사이트 구축은 텍스트 파일 하나만 있으면 꿈처럼 간단했습니다. HTML을 조금 작성하고, CSS를 조금 넣고, 그날 기분이 좋았다면 바닐라 자바스크립트도 조금 넣었을 것입니다. 브라우저는 제 몫을 다했고, 펑! 웹사이트가 생겼습니다. 그게 다입니다. 56,000개의 연결이 처리할 수 있는 최대치였으니까요.

그 후 초고속 인터넷과 V8이 등장하면서 프레임워크, 빌드 도구, 라이브러리, 끝없는 추상화 계층이 모두 시작되었습니다. 번들링, 트랜스파일링, 폴리필링의 소용돌이 속에서 인터넷은 본래의 단순함에서 벗어나 일반 HTML, CSS, 바닐라 자바스크립트가 얼마나 강력한지 잊어버렸습니다.

하지만 최근 Adobe의 Edge 전달 서비스 및 문서 작성 기능을 사용하면서 전화 접속 시 발생하는 특유의 악수 소리와 같은 익숙한 느낌을 받았습니다. EDS는 콘텐츠 우선, HTML로 구동되고 CSS로 스타일링되며 기본적으로 빠른 웹의 근원으로 돌아가게 해 주었습니다.

이 게시물은 웹이 원래 어떻게 만들어졌는지 기억하는 그 느낌에 관한 글입니다. 왜 그럴까요? 프런트엔드가 비대해지고 스택이 복잡해지는 세상에서는 단순함이 그 어느 때보다 중요하기 때문입니다.

초기 웹: 간단하고, 정직하고, 빠름

초기 웹의 단순함에는 아름다움이 있었습니다. 텍스트 편집기를 열고 HTML을 작성하고 약간의 인라인 CSS를 추가하고 상호작용이 필요한 경우 바닐라 JS가 포함된 스크립트 태그를 넣었을 것입니다. 이것이 바로 워크플로였습니다. 빌드 단계가 없습니다. 배포가 없습니다. 종속성이 없습니다. 서버에 FTP로 업로드하면 끝입니다.

성공했습니다. 정말 빨랐습니다. 누구나 액세스할 수 있습니다. 속도가 느린 컴퓨터에서 깨지거나 단락을 렌더링하기 위해 3MB의 축소된 자바스크립트를 로드하지 않았습니다. '소스 보기'를 통해 실제로 무언가를 배울 수 있습니다. 작성하신 내용이 그대로 렌더링된 것입니다. 마법은 없습니다. 추측하지 마세요.

개발자가 모든 권한을 가졌고 진입 장벽이 낮았습니다. CS 학위나 프레임워크의 수명 주기 방법에 대한 20부짜리 강좌가 필요하지 않습니다. 브라우저, 텍스트 편집기, 아이디어만 있으면 됩니다.

웹이 뚱뚱해졌을 때

그 후 Chrome의 V8 엔진이 등장했고, 현대 자바스크립트 르네상스가 시작되었습니다. 갑자기 JS는 단순한 장난감이 아니었습니다. 빠르고 강력하며 어디에서나 사용할 수 있었습니다. 처음에는 마법처럼 느껴졌지만, 사실 우리는 판도라의 상자를 연 것뿐입니다.

우리는 두더지 언덕에서 산을 만들기 시작했습니다. 정적 파일 몇 개만 있던 사이트가 이제 "Hello World"를 뱉어내는 데만 종속성 스택, 번들러, 컴파일러, RAM의 절반이 필요해졌습니다. npm 설치는 피부 관리 루틴이 아닌 의례가 되었습니다. 여러분과 여러분의 빌드를 망가뜨리는 악마를 소환하는 것에 가깝습니다.

레이어 위에 레이어를 쌓아 올렸습니다. 도구를 관리할 수 있는 도구 애초에 복잡하지 않았던 일들을 추상화합니다. 프론트엔드 세계는 문서 대신 '앱'에 집착하게 되었습니다. 그리고 그 혼란 속에서 우리는 구조를 위한 HTML, 스타일을 위한 CSS, 동작을 위한 JS라는 기본을 잊어버렸습니다.

Adobe 문서 작성으로 들어갑니다: 콘텐츠만

Adobe의 문서 작성 - 솔직히 말해서? 신선한 공기를 마실 수 있습니다. 언뜻 보기에는 워드 문서를 편집하는 것처럼 보입니다. 그도 그럴 것이... 거의 그렇기 때문입니다. 협업용으로 제작되어 사용이 간편하고 배우기 쉽습니다. 누구나 쉽게 기여할 수 있는 깔끔한 콘텐츠만 있으면 됩니다.

편집 중인 문서가 워드프레스에 복사 붙여넣기되기를 기다리는 것이 아닙니다. 페이지가 됩니다. 거기서 작성한 내용이 웹으로 전달되므로 헤드리스 혼돈이나 마크다운을 통해 JSON을 파이프라인으로 변환하지 않아도 됩니다.

가능한 최선의 방법으로 콘텐츠를 우선시합니다. 글쓰기에 대한 엔지니어링을 할 필요 없이 그냥 글을 쓰면 그 변화만으로도 큰 변화가 일어납니다. 즉, 시스템을 서로 붙이려고 애쓰는 시간을 줄이고 실제로 중요한 것, 즉 메시지에 집중하는 데 더 많은 시간을 할애할 수 있습니다.

EDS의 실제 모습과 작동 원리

Adobe Edge Delivery Services(줄여서 EDS)는 프로젝트 헬릭스 또는 Adobe 프랭클린으로 불리는 조용한 혁명처럼 느껴질 수 있습니다. Adobe DA 문서(또는 Word, SharePoint, Google 문서)의 콘텐츠를 표와 제목으로 구조화한 다음 바닐라 JS 및 CSS 블록을 사용하여 웹으로 전달하는 것은 너무 단순해 보입니다. 빌드 도구가 없습니다. 배포 스크립트가 없습니다. 복잡한 CMS 통합이 필요 없습니다. 작성, 저장, 발송만 하면 됩니다.

그리고 어쩐지... 그게 요점입니다.

"잠깐만요, 왜 이렇게 복잡하게 만들었죠?"라는 생각이 들게 하는 설정입니다.

EDS는 모든 것을 앱으로 전환하는 대신 인터넷이 원래 작동하던 방식인 웹사이트로 문서를 전환합니다.  이 문서는 콘텐츠에 중점을 두고 있습니다. 레이아웃이나 상호작용이 필요한 경우 블록을 사용합니다. 각 블록은 문서의 구조를 해석하고 이를 깔끔하고 효율적인 HTML로 변환하는 방법을 알고 있는 로직 덩어리(콘텐츠 + CSS + JS)에 불과합니다. Google 문서를 읽고 표를 살펴볼 수 있다면 블록이 어떻게 작동하는지 파악할 수 있습니다.

더 좋은 점은 모든 코드가 GitHub의 오픈 소스이고, 개발 워크플로우가 Git 기반이며, AEM Sidekick과 같은 브라우저 확장 프로그램을 사용하여 모든 블록이 수행 중인 작업을 실시간으로 확인할 수 있다는 것입니다. 중요하지 않은 것들에 짓눌리지 않으면서도 중요한 모든 면에서 현대적입니다.

이것이 실제로 중요한 이유

이 모든 단순함은 단순히 향수를 불러일으키는 것이 아니라 실용적입니다. 잡음을 제거하고 약간의 CSS와 JS를 사용하여 실제 HTML을 전달하는 데 집중하면 모든 것이 더 좋아집니다.

EDS 사이트는 100점 만점에 100점 정도로 빠른데, 이는 부담을 주는 부풀려진 JS 프레임워크가 없기 때문입니다. 고양이 사진을 보여주기 위해 앱을 부트스트랩하는 것이 아니라 HTML을 배포하는 것입니다.

접근성 및 SEO? 그 안에 있습니다. 깔끔한 HTML은 화면 리더와 검색 엔진이 콘텐츠를 실제로 이해한다는 의미입니다. 해킹도 없고 후프도 없습니다.

개발 경험이 있으신가요? 대학을 중퇴했습니다. 새벽 2시에 체인 깊숙한 곳에 있는 패키지가 잘못되었다고 해서 설정을 조정하거나 깨진 빌드를 디버깅하는 일은 없을 것입니다. 블록을 만듭니다. 스타일을 지정합니다. 잔디를 만집니다.

콘텐츠 워크플로? 요리하게 두세요. 작성자와 편집자는 이미 익숙한 도구(Google 문서, Word, SharePoint)에서 작업하고 업데이트는 바로 게시됩니다. 게이트키핑이 없습니다. "그 문장에 띄어쓰기를 추가할 수 있나요?"에 대한 Jira 티켓이 없습니다.

요컨대, 개발자와 작성자, 사용자 등 관련된 모든 사람이 더 빠르게 빌드하고, 더 쉽게 유지 관리하며, 더 쉽게 액세스할 수 있습니다.

백 투 더 퓨처

발전이란 더 많은 도구, 더 많은 레이어, 더 많은 추상화를 추가하는 것이라고 생각하기 쉽습니다. 하지만 때로는 모든 것을 걷어내고 애초에 웹을 훌륭하게 만든 이유를 기억하는 것이 최선일 때도 있습니다.

Adobe Document Authoring과 EDS는 단순히 작업을 더 쉽게 만들어 주는 것이 아니라 더 명확하게 만들어 줍니다. 개발자와 콘텐츠 제작자에게 다시 공통 언어를 제공합니다. 기본에 불과한 HTML, CSS, JS가 여전히 놀랍도록 강력하다는 사실을 일깨워줍니다.

웹을 재창조하는 것이 아닐 수도 있습니다. 어쩌면 그것은 방해에서 벗어나는 것일 수도 있습니다.

엣지 전송 서비스에 대해 더 자세히 알아보고 싶으신가요?
엣지 전송을 위한 문서 작성에 대한 블로그를 확인하거나 YouTube에서 팟캐스트 토론을 들으며 콘텐츠 전송을 어떻게 혁신할 수 있는지 알아보세요.

저자 소개

팟캐스트 에피소드 & 블로그 게시물