# Lit - 빠르고 가벼운 웹 컴포넌트 작성용 라이브러리 > Clean Markdown view of GeekNews topic #22904. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=22904](https://news.hada.io/topic?id=22904) - GeekNews Markdown: [https://news.hada.io/topic/22904.md](https://news.hada.io/topic/22904.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-09-05T09:31:01+09:00 - Updated: 2025-09-05T09:31:01+09:00 - Original source: [lit.dev](https://lit.dev/) - Points: 12 - Comments: 4 ## Summary **Lit**는 **웹 컴포넌트 표준**에 **반응성**과 **선언적 템플릿**, 최소한의 코드만 더해, **5KB**의 작은 크기와 **빠른 렌더링**으로 성능을 극대화합니다. 모든 컴포넌트가 **네이티브 웹 컴포넌트**로 구현되어 프레임워크에 관계없이 **재사용성**이 뛰어나며, **Shadow DOM**을 통한 **스타일 캡슐화**로 CSS 충돌을 방지할 수 있습니다. **Reactive Property**와 **Tagged template Literals** 기반 템플릿 덕분에 상태 관리와 업데이트가 단순해져, 공유 컴포넌트부터 **디자인 시스템 구축**까지 다양한 웹 프로젝트에 이용 가능합니다. ## Topic Body - 웹 컴포넌트 표준을 기반으로 **반응성, 선언적 템플릿, 최소한의 보일러플레이트**만을 추가 - **5KB** 수준의 작은 크기와 **빠른 렌더링**, 변경된 UI 부분만 갱신해 성능과 로딩 속도를 최적화 - 모든 Lit 컴포넌트는 **네이티브 웹 컴포넌트**이며, 프레임워크와 무관하게 HTML이 사용가능한 어디서나 재사용 가능 - **Shadow DOM**을 활용해 기본적으로 스타일 범위를 제한하여, CSS 셀렉터를 간단하게 만들고 다른 스타일과 충돌 방지 - **Reactive Property**로 컴포넌트 API와 내부 상태를 모델링, 속성 변경 시 효율적 재렌더링 지원 - **Tagged template Literals** 기반의 템플릿으로 빠르고 간단함 - 공유용 컴포넌트, 디자인 시스템, 벤더 종속성을 줄이고 유지보수를 강화한 전체 앱 구축까지 다양한 웹 프로젝트에서 사용 가능 - [튜토리얼](https://lit.dev/learn/#filter=tutorial) 제공 - [GitHub](https://github.com/lit/lit/) ## Comments ### Comment 43442 - Author: devstudyman7 - Created: 2025-09-06T19:32:17+09:00 - Points: 1 3년전부터 느끼지만 바닐라 웹컴포넌트 바로쓰는데 빠르고 과도기의 프레임워크로 느껴지긴함 느림.. ### Comment 43520 - Author: cnaa97 - Created: 2025-09-08T23:18:57+09:00 - Points: 2 - Parent comment: 43442 - Depth: 1 무슨말이에요? ### Comment 43402 - Author: bluemir - Created: 2025-09-05T14:11:07+09:00 - Points: 1 web 표준 web component 와 lit-html 만 사용해서 운영 tool 들을 개발하고 있는데, 알아야 하는 정보가 최소화 되어서 좋습니다. lit-html 에서 활용하는 기능은 event handler binding + loop templating 정도만 쓰고 있습니다. (나머지는 웹 표준정도면 충분해서 ..) 변경이 있으면 render를 직접 호출 해야 하는 불편함이 있지만, 오히려 변수 변경을 자동으로 알아채서 비명시적인 동작이 있는 것 보다는, 명시적인 호출이 도움이 되는 면도 있습니다. 운영 tool 이다 보니, 다양한 환경 대응은 우선순위가 낮아서 그렇게 느겼을지도 모르겠네요. ### Comment 43362 - Author: neo - Created: 2025-09-05T09:32:01+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45112720) - 회사 프로젝트에서 Lit을 썼었는데 이제는 안 쓰게 돼서 정말 속이 편해짐 이미 **무거운 프레임워크**를 쓰고 있었는데, 누군가 이력서에 한 줄 더 쓰려고 Lit을 추가한 게 큰 부담이었음 Shadow DOM은 특히 **접근성(A11y)** 문제를 더 심각하게 만들었음. id 스코프가 분리되면서 label-for, describe-by 같은 연결이 깨져버려서 고생이 많았음 물론 어느 정도는 우리 팀의 **스킬 부족** 문제이기도 함 - React 코드베이스에 웹 컴포넌트를 통합하는 과정이 정말 힘들었음. Lit 때문이라기보다는 웹 컴포넌트 자체의 문제라고 생각함 스타일이 스코프되긴 하지만 폰트 크기 같은 중요한 부분은 예외라서, 교체할 때마다 작은 **회귀 버그**가 계속 생김 DX도 많이 떨어졌고, 툴링이 나아지길 기대하지만 지금은 그냥 피곤한 상황임 - Lit에서는 Shadow DOM을 옵션이라, **컴포넌트 단위로 비활성화**할 수 있음 - 누군가 단순히 이력서 채우려고 기술을 도입하는 경우가 실제로 많냐는 의문이 있음. 사실은 그냥 새로운 걸 **써보고 싶어서** 합리화 없이 도입하는 경우가 더 흔한 듯함 - 나는 Lit용 **상태 관리 라이브러리**를 직접 만들었음 (258줄짜리, https://github.com/gitaarik/lit-state) 복잡한 앱에서 중첩된 컴포넌트들이 상호작용할 때 잘 동작했고, React와 비슷하지만 훨씬 **브라우저 네이티브**하고 보일러플레이트가 적으며 렌더링도 빠름 왜 Lit이 더 인기가 없는지 이해가 안 될 정도임 - 나도 Lit 내부 동작을 이해하려고 기본부터 다시 구현해본 적이 있음 핵심 기능은 의외로 단순하고, 대부분 **플랫폼 API**에 의존함 그래서 누구나 직접 구현할 수 있고, 이런 단순함이 큰 가치라고 생각함 참고로 내가 만든 대체 구현체는 https://github.com/ruphin/lite-html 임 - 나는 Lit **메인테이너**임. 오늘 왜 갑자기 HN 메인에 올라왔는지는 모르겠지만 질문 있으면 답해줄 수 있음 - lit-html은 정말 유용해서 거의 모든 개인 프로젝트에 쓰고 있음 CDN으로 바로 불러와서 빌드 스텝 없이 실험할 수 있는 것도 큰 장점임 다른 프레임워크처럼 무겁지 않고, 그냥 **Vanilla JS + HTML** 쓰는 느낌이라 인지 부하가 거의 없음 - Shadow DOM에 대한 얘기가 많아서 내 생각을 정리해봄 Shadow DOM은 기본적으로 컴포넌트 내부 DOM을 분리하는 **프라이빗 트리**임 이걸 통해 **슬롯(slot)** 개념이 가능해지고, 진짜 조합 가능한 컴포넌트를 만들 수 있음 문제는 스타일 캡슐화가 기존 시스템과 통합할 때 큰 장벽이 된다는 점임 그래서 나는 **Open Styleable Shadow Roots**라는 제안을 했는데, 외부 스타일이 내부로 흘러들어가게 하면서도 슬롯은 유지하는 방식임. 아직 브라우저 벤더들을 설득 중임 - Lit은 프레임워크가 방해되지 않는 **깔끔한 도구**라서, 나는 모든 개인/업무 앱을 Lit으로 만들고 있음 관련해서 내가 쓴 글도 있음: https://medium.com/gitconnected/getting-started-with-web-com... - Lit 덕분에 단순한 경우든 복잡한 경우든 개발이 즐거움 가끔은 왜 더 널리 쓰이지 않는지 의문이 들기도 함 - Web Components 표준에 Lit 같은 기능이 포함될 가능성이 있냐는 질문이 있음 - Web Components는 네이티브라 좋은데, **반응성**이 빠져 있어서 채택이 느린 게 사실임 - Lit은 그 공백을 메워주는 자연스러운 확장선임 - 나는 **Converse.js**라는 XMPP 채팅 클라이언트 프로젝트에서 Lit을 썼음 원래 Backbone.js 기반이었는데, lit-html → lit-element → lit 순으로 점진적으로 교체했음 지금은 ` <converse-root />`라는 웹 컴포넌트로 제공돼서 React 같은 다른 프레임워크와도 잘 통합됨 깃헙: https://github.com/conversejs/converse.js / 데모: https://chat.conversejs.org/ - 요즘은 Lit이 필요 없다고 느낌. 그냥 **순수 Web Components**로 작업하는 게 더 편함 서버에서 JSX 같은 템플릿 시스템을 쓰면 충분히 쾌적하고, 클라이언트는 그냥 JS라서 업그레이드 걱정도 없음 - Web Components의 장점은 원하는 방식으로 만들 수 있다는 것임 다만 네이티브 API는 너무 **저수준**이라 DX가 부족하고, Lit은 그 위에 선언적 반응성을 얹어줌 - 나는 Lit이 반복적인 `` 처리와 DOM 연결을 잘 추상화해준다고 생각함 직접 구현하면 귀찮은 부분을 깔끔하게 해결해줌 - 개인적으로는 Lit의 `html` 템플릿 리터럴과 JSX 사이에 큰 차이를 못 느꼈음 오히려 JSX는 **컴파일 단계**가 필요해서 더 번거로움 - 나는 3년째 프로덕션에서 Lit을 쓰고 있음. Web Components API 위에서 가장 좋은 **추상화 계층**이라고 생각함 - 나도 비슷한 경험이 있음 처음엔 의존성 없는 환경에서 직접 Web Components를 만들었는데, 나중에 LitElement로 옮기니 훨씬 편했음 다만 Shadow DOM은 기본값이지만 오히려 문제를 더 만들기도 해서, 지금은 Shadow DOM 없이 LitElement를 쓰고 있음 - 나는 2020년부터 Lit을 프로덕션에서 쓰고 있는데, 절대 후회하지 않음 가장 큰 장점은 **안정적인 기반** 위에 있다는 것임 네이티브 Web Components는 모든 브라우저에서 안정적으로 지원되니까, 프레임워크 교체 리스크 없이 개발에 집중할 수 있음 더 많은 팀이 시도해봤으면 좋겠음 참고로 Lit을 다룬 [HTTP 203 영상](https://www.youtube.com/watch?v=uCHZJy2n8Qs)도 추천함 - 프론트엔드 작업에서 Lit은 정말 **구세주** 같은 존재였음 Angular는 너무 무겁고, React는 옛날 브라우저 한계에 맞춰 설계돼서 지금은 **관성**으로만 남아 있는 느낌임 - 어떤 옛날 브라우저 기능을 말하는 건지 더 구체적으로 듣고 싶음 - 나는 **Aurelia** 프레임워크를 좋아하는데, 표준을 잘 따르고 코드도 간결함 Angular의 보일러플레이트나 React의 훅 복잡함에 비해 훨씬 직관적임 다만 인기는 얻지 못해서 아쉬움 - React가 옛날 브라우저 지원 때문에 유명해졌다는 말이 나오니, 갑자기 내가 늙은 것 같은 기분이 듦 - 나는 **lit-html** 단독 렌더링 라이브러리는 좋아하지만, Lit 전체는 필요성을 못 느꼈음 사실상 ` + Web Components` 조합이면 충분하다고 생각함 - 나는 Vue 3 대규모 프로젝트에서 만든 컴포넌트를 다른 사이트에서 재사용하려고 웹 컴포넌트로 배포하려고 함 그런데 Vue 대신 Lit으로 다시 만드는 게 무슨 이점이 있는지 궁금함 - 나는 Vue와 Lit 둘 다 써봤는데, 개인적으로는 Vue가 조금 더 나았음 Vue 3의 **ref/reactive** 상태 관리가 강력하고, DOM 의존 없이 테스트 가능함 Lit의 반응성은 위젯 단위라서 업데이트 트리거를 직접 관리해야 함 Vue는 라이프사이클이 단순한데, Lit은 여러 콜백을 신경 써야 해서 버그가 생기기 쉬움 특별한 이유가 없다면 **기능 개발**에 집중하는 게 낫고, 기술 스택 교체는 사용자에게 거의 영향이 없음 - 소비자 입장에서는 Vue든 Lit이든 결과물은 Web Components라 차이가 없음 Vue는 프레임워크라 기능이 더 많고, Lit은 네이티브 API에 더 가깝게 구현함 Vue는 빌드가 필요하지만 Lit은 **런타임 로딩**이 가능함 Vue는 다른 타깃으로도 컴파일할 수 있지만, Lit은 Web Components 전용이라 더 깔끔함 결국 팀이 더 익숙한 기술을 쓰는 게 제일 중요함 - 사실 가장 현실적인 접근은, 그냥 **웹 컴포넌트 번들**을 만들어서 내보내고 내부는 원하는 대로 구현하는 것임 소비자는 내부 구현에 관심 없고, 크기와 API만 중요함 어차피 다른 사람들이 자기 환경에 맞게 **어댑터**를 만들어 쓸 것임