<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Waylog Blog · Web</title>
    <link>https://waylog.pages.dev/category/web</link>
    <description>Waylog Blog의 Web 카테고리에 속한 글 모음</description>
    <language>ko-KR</language>
    <lastBuildDate>Thu, 21 May 2026 13:50:29 GMT</lastBuildDate>
    <pubDate>Sat, 18 Apr 2026 00:00:00 GMT</pubDate>
    <generator>Next.js</generator>
    <atom:link href="https://waylog.pages.dev/category/web/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Web Components로 프레임워크 독립 디자인 시스템 만들기: Custom Elements·Shadow DOM·Lit으로 React·Vue와 함께 쓰는 법</title>
      <link>https://waylog.pages.dev/posts/web-components-custom-elements-design-system-interop</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/web-components-custom-elements-design-system-interop</guid>
      <pubDate>Sat, 18 Apr 2026 00:00:00 GMT</pubDate>
      <category>Web</category>
      <description>프레임워크가 바뀌어도 컴포넌트는 살아남아야 한다 우리 프론트엔드 개발자들은 매 23년 주기로 반복되는 피로감을 잘 압니다. 조직이 React에서 Vue로, Vue에서 다시 React로, 혹은 Next.js에서 SvelteKit으로 이동할 때마다 디자인 시스템 컴포넌트를 처음부터 다시 작성해야 하는 상황입니다. 우리 팀이 경험한 사례가 있습니다. 멀티 테넌트 B2B SaaS 제품에서 메인 앱은 React 18을 쓰고, 고객사 임베딩용 위젯은 Vue 3, 어드민 패널은 Svelte로 구성된 상황이었습</description>
    </item>
    <item>
      <title>View Transitions API 실전: SPA 페이지 전환 애니메이션을 CSS와 JavaScript로 제어하는 방법</title>
      <link>https://waylog.pages.dev/posts/view-transitions-api-spa-page-animation</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/view-transitions-api-spa-page-animation</guid>
      <pubDate>Mon, 09 Feb 2026 00:00:00 GMT</pubDate>
      <category>Web</category>
      <description>페이지 전환, 여전히 깜박임으로 마무리되고 있지 않습니까 우리 프론트엔드 개발자들은 SPA를 만들면서 묘한 역설을 경험합니다. 서버 왕복 없이 화면을 바꿔도 사용자는 여전히 &quot;뚝&quot; 끊기는 느낌을 받습니다. React Router나 Next.js App Router가 라우팅 자체는 해결했지만, 이전 화면이 사라지고 새 화면이 나타나는 시각적 연속성은 개발자 각자가 Framer Motion, GSAP, 또는 CSS 클래스 교체로 구현해야 했습니다. 우리 팀이 이커머스 상세 페이지에서 Hero 이미지 </description>
    </item>
    <item>
      <title>브라우저 보안 강화 실전: CSP, Trusted Types, Nonce 기반 스크립트로 XSS 줄이기</title>
      <link>https://waylog.pages.dev/posts/browser-security-csp-trusted-types-xss</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/browser-security-csp-trusted-types-xss</guid>
      <pubDate>Sat, 18 Oct 2025 00:00:00 GMT</pubDate>
      <category>Web</category>
      <description>XSS는 프론트엔드 문제가 아니라 서비스 신뢰 문제다 Cross-Site Scripting(XSS)은 오래된 취약점이지만 여전히 강력합니다. 공격자가 사용자의 브라우저에서 임의 스크립트를 실행할 수 있다면 세션 탈취, 계정 조작, 피싱 UI 삽입, 내부 API 호출이 가능해집니다. React와 같은 프레임워크가 기본 escaping을 제공하지만, 그것만으로 충분하지 않습니다. dangerouslySetInnerHTML, 서드파티 스크립트, Markdown 렌더링, 레거시 jQuery 코드, 광고 </description>
    </item>
    <item>
      <title>웹 접근성(A11y)과 Core Web Vitals: 차세대 SEO와 사용자 경험(UX) 최적화의 모든 것</title>
      <link>https://waylog.pages.dev/posts/web-accessibility-core-vitals</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/web-accessibility-core-vitals</guid>
      <pubDate>Mon, 05 May 2025 00:00:00 GMT</pubDate>
      <category>Web</category>
      <description>보이지 않는 가치의 증명: 프론트엔드 장인정신의 진짜 척도 화려한 디자인 패턴, 최신 프론트엔드 프레임워크, 그리고 복잡한 상태 관리. 우리 프론트엔드 개발자들은 수많은 신기술들을 학습하고 프로젝트에 적용하며 살아갑니다. 그러나 정작 우리가 만드는 서비스의 &quot;본질&quot;, 즉 &quot;얼마나 많은 사람들이, 얼마나 쾌적하게 이 정보를 소비할 수 있는가?&quot;라는 근원적인 물음에는 소홀한 경우가 많습니다. 2026년 현재, 웹 접근성(Accessibility, a11y)과 구글의 Core Web Vitals(우수 </description>
    </item>
    <item>
      <title>프론트엔드 폼 검증 설계: Zod 스키마, 서버 검증, 에러 UX를 일관되게 만드는 방법</title>
      <link>https://waylog.pages.dev/posts/frontend-form-validation-zod-server-actions</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/frontend-form-validation-zod-server-actions</guid>
      <pubDate>Mon, 12 Aug 2024 00:00:00 GMT</pubDate>
      <category>Web</category>
      <description>폼은 가장 작은 제품 흐름이다 회원가입, 결제 정보 입력, 게시글 작성, 관리자 설정 저장까지 대부분의 웹 서비스는 폼에서 중요한 상태가 바뀝니다. 그래서 폼 검증은 단순히 빨간 글씨를 띄우는 기능이 아닙니다. 잘못된 입력을 막고, 사용자가 무엇을 고쳐야 하는지 알려주며, 서버가 신뢰할 수 있는 데이터를 받게 하는 제품 흐름입니다. 많은 프로젝트에서 폼 검증은 시간이 지나며 흩어집니다. 프론트엔드에는 정규식이 있고, 서버에는 다른 규칙이 있고, 데이터베이스에는 또 다른 제약이 있습니다. 그러면 사</description>
    </item>
  </channel>
</rss>
