Is a design system just a Lovable project?

Yes, a design system is a regular Lovable project that is marked as a design system. It can be opened and edited like any other project, and other projects can connect to it. If the design system wraps an external npm package, the package itself isn't editable from Lovable, only the wrapper layer in the design system project is. Changes to the underlying components have to be made in the upstream npm package and republished there.

Can I connect more than one design system to a project?

No. A project can be connected to at most one design system at a time. To switch, remove the current one first: open the Design system section in Project settings → General, then choose ⋯ → Remove on the connected one.

Can any project be turned into a design system?

No. A design system is created as its own dedicated project from the Create design system flow (the + menu, then Design systems). An existing project can't be converted into one. Once created and released, it becomes available for other projects in the workspace to connect to.

How do I see which design system is connected to my project?

Select the project name in the top bar and choose Design system, or go to Project settings → General and open the Design system section. It shows the connected design system and opens a dialog to browse and attach available ones.

Are design systems versioned?

Yes. Every release bumps the version. Connected projects record the version they were last attached at, and an Update available prompt appears in the chat whenever a newer version is released.

What is the difference between a released and a draft design system?

A draft design system exists as a project but has not been released yet, so it has no schema or rendered documentation. You cannot use a draft design system as the basis for a new project. Release it first. Once released, the design system gets a version number and becomes selectable in the design system picker.

Can I remove a design system from a project?

Yes. In Project settings → General, open the Design system section, then choose ⋯ → Remove on the attached design system and confirm. This severs the managed link: your project stops receiving updates from that design system, and the agent no longer follows its rules. The component files stay under src/design-system as ordinary, editable code, so nothing already using them breaks; they are now yours to maintain.

Can I edit the design system from a connected project?

The design system's source and documentation are managed by the design system project. The files in src/design-system// and .lovable/rules/libraries// are present in a connected project's git, so you can read and import them, but local edits will be replaced the next time you accept an update. For permanent changes, propose them in the design system project.

Do I need to publish my design system to npm?

No. Design systems are an in-Lovable feature. Components and documentation flow directly between your Lovable projects. If you also want to publish your design system to a public npm or a private registry for use outside Lovable, that's a separate flow.

What's the difference between a from-scratch and an npm-wrapper design system?

A from-scratch (local) design system holds its component source directly in the design system project. Lovable reads tokens and components from that source when you release. An npm-wrapper design system wraps an external npm package: Lovable reads the component surface from the package's published type definitions, and the project holds only a thin wrapper layer. For a public npm package nothing extra is needed. For a package on a private registry, the package must be scoped (@scope/name) and you add a scoped .npmrc backed by a workspace build secret so both releasing and connected projects can authenticate.

What technologies do design systems support?

Lovable design systems support React-based component libraries out of the box. The design system declares its required stack and dependencies through its schema, and Lovable adapts the setup automatically. Your library determines what gets wired up, not a fixed list of supported frameworks. If your design system is built with other frameworks such as Vue, Angular, or Svelte, reach out to your CSM or FDE.

Why does the agent sometimes make extra edits right after I attach a design system?

When you attach a design system, Lovable runs an automatic setup verification pass to check that the design system is wired up correctly (configuration, CSS imports, theme providers, dependencies, and import paths). If the agent finds gaps, it applies fixes and reruns verification. Successful verifications are silent and do not appear in the chat. Verification turns are billed at zero credits.

Do design systems replace templates?

No, design systems do not replace templates. Templates and design systems serve different purposes and are often used together. Templates are best for initial project scaffolding, while design systems provide ongoing UI and design guidance across projects.

React version mismatch

If your design system uses React 19 but the project defaults to React 18, or vice versa, tell Lovable explicitly. For example: My design system requires React 19. Please update the project dependencies accordingly.

Conflicting dependencies

If your design system uses a different styling solution than the project's defaults, ask Lovable to remove the conflicting dependencies. For example: Please uninstall the project's default styling dependencies. My design system uses [your styling solution] instead.

Preview looks broken right after connecting

Setup verification usually catches this and fixes the wiring automatically. If something still looks off, open the chat in the connected project and ask Lovable to verify the design system is wired up correctly. It will rerun the check and propose fixes.

Lovable is not using the components I expect

The adherence scanner catches most violations automatically. If it misses something, point it out in the chat, for example by asking Lovable to use the Button from the design system, not a custom one. Lovable will replace the local implementation with the design system component.

Release fails: private package needs a scoped registry

Your design system wraps a package on a private registry, but Lovable has no recorded way to authenticate to it. Make sure the package is scoped (@scope/name) and add the registry and auth lines for that scope to .npmrc, backed by a workspace build secret. Add the NPM_TOKEN secret under Workspace settings → Build secrets, then release again.

Release fails: registry auth failed or package not found

The upstream package could not be fetched. Confirm the build-secret token can read the package, that the package name and scope are correct, and that the .npmrc registry line points at the right host. For the Lovable-managed registry, make sure the workspace's managed npm registry is enabled in workspace settings. Then release again.

Release fails: the package ships no typed exports

A wrapped npm package is read through its published type definitions. If the upstream package ships no .d.ts types or exports map, there is nothing to extract. Wrap a package that ships types, or build the components as a local (from-scratch) design system instead.

Release does nothing or reports an empty design system

Lovable could not identify any tokens or components in the project. For a local design system, check that tokens live in a top-level styling file (CSS variables, tailwind.config, or a theme/tokens file) and that components are exported from src/index.ts or live under src/components/. Ask Lovable to run the design system discovery step, then release again.

Lovable에서 재사용 가능한 디자인 시스템을 만들어 React 컴포넌트 라이브러리, 스타일링 가이드라인, 엔터프라이즈 프로젝트 전반의 설정을 표준화합니다.

디자인 시스템

Lovable에서 재사용 가능한 디자인 시스템을 만들어 React 컴포넌트 라이브러리, 스타일링 가이드라인, 엔터프라이즈 프로젝트 전반의 설정을 표준화합니다.

Lovable 디자인 시스템은 Enterprise 플랜에서 사용할 수 있으며 React 컴포넌트로 구현된 디자인 시스템과 기본적으로 작동합니다.

디자인 시스템을 사용하면 컴포넌트 라이브러리, 스타일링 가이드라인, 설치 지침을 한 번 정의하고 워크스페이스의 모든 프로젝트에서 재사용할 수 있습니다. 디자인 시스템이 프로젝트에 연결되면 컴포넌트, 규칙, 업데이트가 디자인 시스템 프로젝트에서 연결된 모든 프로젝트로 흐릅니다.

Lovable에서 디자인 시스템은 전용 프로젝트로 생성됩니다. 이 프로젝트는 디자인 시스템의 source of truth 역할을 하며 워크스페이스의 다른 프로젝트에 연결할 수 있습니다.

얻는 것

UI 컴포넌트, 토큰, 스타일을 위한 중앙 집중식 source of truth
연결된 모든 프로젝트에 바로 전달되어 곧장 사용할 수 있는 라이브러리의 React 컴포넌트
새 버전을 게시하면 연결된 프로젝트의 채팅에 Update available 프롬프트가 표시되는 원클릭 업데이트
연결하거나 업데이트할 때마다 Lovable이 와이어링(빌드 구성, CSS 가져오기, 테마 공급자, 의존성)을 확인하고 누락된 부분을 수정하는 자동 설정 검증
작업을 진행하는 동안 Lovable이 raw color, 커스텀 컴포넌트나 커스터마이즈된 컴포넌트, 그 밖에 디자인 시스템에서 벗어난 편차를 잡아내는 준수 강제

디자인 시스템 작동 방식

Lovable의 디자인 시스템은 컴포넌트, 스타일, 설정 지침이 프로젝트 전반에 어떻게 적용되는지 정의합니다. 디자인 시스템은 그 자체가 Lovable 프로젝트이며 다른 프로젝트처럼 열고 편집할 수 있습니다.

디자인 시스템의 구성

Lovable의 디자인 시스템은 다음 세 가지 핵심 요소로 이루어집니다.

컴포넌트: React 컴포넌트 라이브러리
스키마와 가이드라인: 기계 판독형 스키마(토큰, 컴포넌트 카탈로그, 제약)와 Lovable이 생성할 때마다 읽는 렌더링된 문서
설치: 설정 지침과 필수 구성

이러한 자료를 이미 갖추고 있다면 Lovable에서 디자인 시스템 프로젝트를 만들어 기존 자료를 참조할 수 있습니다. 문서가 흩어져 있거나 불완전하다면 Lovable 안에서 디자인 시스템을 직접 만들고 개선할 수 있습니다.

디자인 시스템 프로젝트와 `.lovable` 폴더

디자인 시스템 프로젝트는 특별한 .lovable 폴더를 소유합니다. 디자인 시스템을 게시하면 Lovable이 다음 파일을 생성합니다.

design-system.json: 토큰, 컴포넌트 카탈로그(variants, props, examples), 스택 제약을 포함한 표준화된 기계 판독형 스키마입니다. source of truth에 해당합니다.
rules/components.md: 스키마에서 렌더링한 컴포넌트 카탈로그입니다.
rules/design-tokens.md: 스키마에서 렌더링한 토큰 참조입니다.
rules/library-guidelines.md: 스키마에서 렌더링한 스택 요구사항과 사용 규칙입니다.
system.md: 고수준 설치 지침과 디자인 철학입니다. 이 파일은 게시 전반에 보존되며, Lovable이 스키마에서 다시 생성하지 않습니다.

system.md는 프로젝트 설정의 Knowledge 탭에서, 또는 Lovable과 직접 채팅하여 편집할 수 있습니다. 나머지 파일은 게시할 때마다 다시 생성됩니다.

디자인 시스템이 프로젝트에 적용되는 방식

프로젝트가 디자인 시스템에 연결되면 Lovable은 file-copy attach를 수행합니다.

디자인 시스템의 React 컴포넌트가 연결된 프로젝트의 src/design-system/<design-system-slug>/에 복사됩니다. Lovable은 그곳에서 컴포넌트를 가져옵니다.
디자인 시스템의 .lovable 지식 파일(스키마, 렌더링된 규칙, system.md)이 .lovable/rules/libraries/<design-system-slug>/에 복사됩니다. Lovable은 생성할 때마다 이 파일을 읽습니다.
필요한 런타임 의존성이 연결된 프로젝트의 package.json에 병합됩니다.
lovable.toml의 [[libraries]] 항목이 어떤 디자인 시스템이 어떤 버전으로 연결되어 있는지 기록합니다.

이렇게 복사된 컴포넌트는 연결된 프로젝트에서 읽고 사용할 수 있는 평범한 로컬 React 리소스가 됩니다. 다만 이 컴포넌트를 직접 편집하지 마세요. 로컬에서 수정한 내용은 디자인 시스템의 업데이트를 다음에 수락할 때 교체됩니다. 영구적인 변경이 필요하다면 해당 디자인 시스템 프로젝트에서 제안하세요.

업데이트

디자인 시스템의 새 버전을 게시하면 연결된 모든 프로젝트의 채팅에 Update available 프롬프트가 표시됩니다. 업데이트를 수락하면 Lovable이 새 버전을 대상으로 file-copy attach를 다시 실행합니다. 이때 이전 디자인 시스템 파일을 제거하고, 새 파일을 복사하고, 의존성을 다시 병합하고, 설정 검증을 다시 실행합니다. 연결된 프로젝트 자체의 코드는 건드리지 않습니다.

설정 검증

디자인 시스템이 프로젝트에 연결된 후(프로젝트 생성 시점이든 기존 프로젝트든) 에이전트는 디자인 시스템이 올바르게 와이어링되었는지 확인하는 조용한 검증 패스를 실행합니다. 이 패스에서는 다음을 확인합니다.

빌드 파이프라인이 디자인 시스템의 소스 폴더를 인식하고 실패하지 않는지
디자인 시스템의 스타일링 진입점이 프로젝트가 스타일을 로드하는 모든 곳에서 가져와지는지
디자인 시스템이 요구하는 wrapper 컴포넌트나 공급자가 적절한 범위에 배치되어 있는지
필요한 모든 의존성이 package.json에 선언되어 있는지

모든 것이 올바르게 와이어링되어 있으면 검증은 채팅에 아무 흔적도 남기지 않습니다. 누락된 부분이 있으면 Lovable이 후속 생성에서 이를 바로잡고, 모든 것이 제자리를 잡거나 수정하지 못한 항목의 짧은 체크리스트가 채팅에 나타날 때까지 검사를 다시 실행합니다.

설정 검증 턴은 0 크레딧으로 청구되며 워크스페이스 사용량에 포함되지 않습니다.

준수 검사

연결된 프로젝트에서 작업하는 동안 Lovable은 생성할 때마다 디자인 시스템 위반 여부를 검사합니다.

디자인 시스템 토큰을 써야 할 곳에 들어간 raw color 리터럴
디자인 시스템의 토큰이나 스케일을 우회하는 일회성 값
디자인 시스템의 기본값을 재정의하는 인라인 스타일
디자인 시스템에서 가져와야 할 것을 로컬 컴포넌트로 구현한 사례

위반이 발견되면 Lovable이 생성을 끝내기 전에 자동으로 수정을 재시도합니다.

핵심 참고 사항과 제한

.lovable 폴더는 디자인 시스템 프로젝트가 소유하며 연결된 프로젝트에서는 편집할 수 없습니다.
연결된 프로젝트는 마지막으로 연결된 디자인 시스템의 버전을 기록합니다. 업데이트는 채팅 프롬프트에서 수락할 때 적용됩니다.
Lovable 디자인 시스템은 React 컴포넌트 라이브러리와 기본적으로 작동합니다.
디자인 시스템은 디자인 시스템 만들기 흐름에서 전용 프로젝트로 생성됩니다.
게시하지 않은 디자인 시스템은 새 프로젝트의 기반으로 사용할 수 없습니다. 먼저 초기 버전을 게시하세요.
프로젝트는 한 번에 최대 하나의 디자인 시스템에만 연결할 수 있습니다. 다른 것으로 바꾸려면 현재 것을 먼저 제거하세요. Project settings → General에서 Design system 섹션을 열고 연결된 디자인 시스템에서 ⋯ → Remove를 선택합니다.
디자인 시스템을 제거하면 관리 연결이 끊깁니다. 프로젝트는 더 이상 업데이트를 받지 않고 에이전트도 규칙을 강제하지 않습니다. 복사된 파일은 src/design-system/ 아래에 평범한 편집 가능 코드로 남으므로 이를 사용하는 부분은 깨지지 않으며, 이제부터 직접 유지·관리하게 됩니다.
디자인 시스템이나 관련 문서가 VPC 안에서 호스팅된다면 어카운트 팀에 문의해 안내를 받으세요.
디자인 시스템은 React를 지원합니다. Vue, Angular, Svelte 같은 다른 프레임워크는 현재 지원하지 않으므로 결과가 다를 수 있습니다. 필요하다면 CSM이나 FDE에 문의하세요.
디자인 시스템으로 만든 새 프로젝트는 현재 디자인 시스템이 Vite/React 기반이더라도 TanStack 템플릿 위에 스캐폴딩되며, 스타일링 프레임워크가 빌드에 항상 자동으로 와이어링되지는 않습니다. Vite를 사용하는 소비자는 Tailwind 3을 끌어올 수 있는데, 이는 Tailwind 4와 충돌합니다. 이런 경우 Lovable의 설정 검증이 대개 첫 생성에서 와이어링을 바로잡습니다. 그래도 스타일이 잘못 보이면 연결된 프로젝트에서 Lovable에게 디자인 시스템의 스타일링 프레임워크를 와이어링해 달라고 요청하세요. 결정적 스캐폴딩과 스타일링 설정은 개선 중인 알려진 제한입니다.

디자인 시스템 만들기

접근 권한 준비 (비공개 패키지만 해당)

컴포넌트 라이브러리나 패키지가 비공개라면 Workspace settings → Build secrets로 이동해 필요한 빌드 시크릿(예: npm 토큰)을 추가하세요.

디자인 시스템 프로젝트 생성

lovable.dev 프롬프트 박스의 + 드롭다운에서 Design을 선택한 다음 Use a design system을 선택합니다.

모달에서 Create design system을 선택합니다.

그러면 새 디자인 시스템 프로젝트가 생성됩니다. Lovable이 프로젝트에 이름을 지정하며, 이 이름은 프로젝트 설정에서 바꿀 수 있습니다.

디자인 시스템에 의미 있는 이름을 붙이세요. 이 이름은 나중에 디자인 시스템을 프로젝트에 연결할 때 사용됩니다.

Lovable과 채팅하여 디자인 시스템 구성

디자인 시스템은 크게 두 가지 방식으로 설정할 수 있습니다.

옵션 A: 기존 라이브러리 가져오기

디자인 시스템이 어떻게 배포되는지 채팅에서 Lovable에게 알려주세요.

npm 패키지: 패키지 이름을 알려줍니다. 공개 패키지는 자동으로 가져오며, 비공개 패키지는 먼저 Workspace settings → Build secrets에 npm 토큰을 추가하세요.
공개 Git 리포지토리: 리포지토리 URL을 공유하면 Lovable이 그곳에서 컴포넌트를 가져옵니다.
비공개 리포지토리 또는 흩어진 파일: 비공개 리포지토리를 가져오는 기능은 없습니다. 리포지토리를 직접 클론하거나 파일을 내보낸 뒤 업로드하면 Lovable이 통합합니다.

가져오고 나면 Lovable이 게시 시점에 컴포넌트 소스에서 스키마를 추출합니다. variants, props, examples는 자동으로 캡처됩니다. 스키마가 추론할 수 없는 사용 맥락(디자인 철학, 서술형 사용 규칙, 설치 특이사항)은 프로젝트 설정의 Knowledge 탭에서, 또는 Lovable과 직접 채팅하여 system.md를 편집하세요.

npm 패키지나 공개 리포지토리를 가져올 때는 가이드 질문을 건너뛰고 패키지 이름이나 리포지토리 URL만 알려줘도 됩니다.

옵션 B: 구조화된 지침으로 디자인 시스템 빌드

문서가 흩어져 있거나 불완전하다면 디자인 시스템을 빌드하도록 Lovable을 명시적으로 안내하세요. 이 방식으로 다음을 할 수 있습니다.

PDF, Markdown 파일, 스크린샷, 그 밖의 에셋 가져오기
컴포넌트, 패턴, 토큰, 스타일링 가이드라인 정의
설치·설정 지침 작성
연결된 프로젝트 전반에서 모든 것을 동적으로 업데이트

권장 프롬프트 구조

[고수준 목표]

[설치 지침]

[시스템 설정을 위한 기타 맥락, 예: 기술 스택과 제약]

[컴포넌트 라이브러리 요청]

[더 많은 맥락을 제공할 문서, 사이트, PDF, MCP 링크. Lovable이 웹사이트를 크롤링할 수 있으니
여기에 폭넓은 맥락을 담아도 됩니다.]

첫 실행이 끝나면 Lovable이 작동하는 디자인 시스템 프로젝트를 생성합니다. 다음은 그 예입니다. https://design-system-demo.lovable.app/

디자인 시스템 게시

디자인 시스템 프로젝트에서 Release version을 선택합니다. Lovable이 스키마를 생성하고, 문서를 렌더링하고, 버전을 올리고, 모든 것을 디자인 시스템 프로젝트의 리포지토리에 커밋합니다. 이제 새 프로젝트를 만들거나 기존 프로젝트에 연결할 때 이 디자인 시스템을 선택할 수 있습니다.

연결된 프로젝트에 업데이트를 푸시하고 싶을 때마다 다시 게시하세요.

라이브러리를 깔끔하게 게시하도록 준비하기

디자인 시스템이 어떻게 게시되는지는 컴포넌트가 어디서 오는지에 따라 달라집니다. 경로는 두 가지이며, 각각 고유한 사전 조건이 있습니다.

로컬 소스(Path A): 컴포넌트 소스가 디자인 시스템 프로젝트 자체에 있습니다. Lovable에서 빌드했든, 공개 Git 리포지토리에서 가져왔든, 직접 업로드했든 마찬가지입니다. 게시하면 해당 소스에서 토큰과 컴포넌트를 곧바로 읽습니다.
npm wrapper(Path B): 디자인 시스템이 외부 npm 패키지를 래핑합니다. 게시하면 패키지의 게시된 타입 정의에서 컴포넌트 표면을 읽고, 프로젝트는 얇은 wrapper 레이어만 보유합니다.

Lovable은 프로젝트를 만들 때 경로를 기록하고, 이를 사용해 게시 시점에 스키마를 빌드합니다. 아래 사전 조건을 제대로 갖추면 게시, 연결, 준수가 모두 수동 정리 없이 작동합니다.

로컬 소스(Path A)

로컬 디자인 시스템은 Lovable이 토큰과 컴포넌트를 찾을 수 있을 때 깔끔하게 게시됩니다.

토큰은 최상위 스타일링 파일에서 찾습니다. src/index.css나 src/styles/tokens.css 같은 파일의 CSS custom property, tailwind.config, 또는 theme·tokens 소스 파일이 그 대상입니다. 트리 깊숙이 묻힌 컴포넌트 로컬 스타일시트는 토큰 소스로 취급하지 않습니다.
컴포넌트는 배럴(src/index.ts 또는 src/index.tsx)이 있으면 그곳에서, 없으면 src/components/ 아래 파일에서 찾습니다.
system.md는 스키마가 추론할 수 없는 모든 것, 곧 디자인 철학, 서술형 사용 규칙, 설치 특이사항을 담습니다. 직접 손으로 작성하며, 게시해도 덮어쓰지 않습니다.

구조화된 지침으로 처음부터 디자인 시스템을 빌드할 때는 업로드(PDF, Markdown, 스크린샷, 그 밖의 에셋)로 초기 자료를 제공할 수 있습니다. Lovable은 이를 최선을 다해 해석합니다. 모든 파일이나 형식이 작동하는 컴포넌트나 토큰으로 바뀐다는 보장은 없으므로, 첫 실행 후 생성된 스키마와 컴포넌트를 검토하고 결과가 기대와 다른 부분을 반복해서 개선하세요.

npm wrapper(Path B)

wrapper 디자인 시스템은 업스트림 패키지와 wrapper가 모두 양호할 때 깔끔하게 게시됩니다.

업스트림 패키지는 타입이 지정된 export를 제공해야 합니다(.d.ts 진입점 또는 exports 맵). 게시하면 이 타입에서 컴포넌트 표면을 읽습니다. 타입을 제공하지 않는 패키지는 추출할 것이 없어 게시가 실패합니다.
src/를 거의 비워 두세요. wrapper에서는 실제 컴포넌트가 npm 패키지에서 오므로 프로젝트에는 얇은 wrapper나 provider 파일만 있으면 됩니다. src/에서 제외되지 않은 모든 것이 연결된 프로젝트로 복사되므로, src/에 남은 불필요한 스캐폴딩은 모든 소비자에서 잡음이 됩니다.

wrapper 자체는 업스트림 패키지가 어디에 호스팅되는지에 따라 두 가지 경우로 나뉩니다.

공개 npm 패키지

업스트림이 공개 npm 레지스트리에 게시되어 있으면 그 밖에 필요한 것은 없습니다. 디자인 시스템이 해당 패키지 이름을 래핑한다고 표시하기만 하면 됩니다. 게시하면 공개 레지스트리에서 패키지를 가져옵니다.

비공개 레지스트리 패키지

업스트림이 비공개 레지스트리(예: GitHub Packages나 자체 호스팅 레지스트리)에 있으면, 게시와 연결된 프로젝트 모두가 설치할 수 있도록 두 가지가 필요합니다.

패키지에 스코프가 지정되어야 합니다(@scope/name).
워크스페이스 빌드 시크릿으로 뒷받침되는 스코프 지정 .npmrc. 해당 스코프의 레지스트리와 인증 라인을 다음과 같이 추가합니다.
```
@scope:registry=https://your-registry.example.com
//your-registry.example.com/:_authToken=${NPM_TOKEN}
```
NPM_TOKEN은 Workspace settings → Build secrets 아래에 저장된 토큰을 참조합니다. 디자인 시스템을 만들 때 레지스트리 URL과 시크릿을 제공하거나 (Lovable이 .npmrc를 대신 작성) .npmrc 라인을 직접 작성할 수 있습니다. 스코프 지정 비공개 패키지에 기록된 인증이 없으면 게시가 중단되고 이 라인을 추가하라고 요청합니다. 연결된 프로젝트가 연결 시점에 인증하도록 하는 것도 바로 이 구성이기 때문입니다.

이는 Lovable이 관리하는 워크스페이스 레지스트리(관리형 레지스트리 참조)를 포함해 직접 운영하는 비공개 레지스트리에 게시하는 패키지에도 적용됩니다. 레지스트리를 설정하고 패키지를 그곳에 게시했다면 다른 스코프 지정 비공개 패키지처럼 이름으로 래핑하세요.

연결된 프로젝트에 복사되는 것

연결은 디자인 시스템 프로젝트의 두 부분만 각 연결된 프로젝트로 복사합니다. src/ 아래의 컴포넌트 소스와 .lovable/ 지식 파일입니다. 소비자에게 새어 나가지 않도록 몇 가지는 기본적으로 제외됩니다.

쇼케이스와 데모 페이지. src/pages/나 src/routes/ 아래의 모든 것, 그리고 모든 *.stories.ts·*.stories.tsx 파일이 제외됩니다. 쇼케이스를 그곳에 두면 미리보기 앱을 모든 소비자에게 배포하지 않고도 라이브러리를 미리 볼 수 있습니다.
테스트와 스캐폴드 진입점(src/main.tsx, src/App.tsx, 테스트 파일 등)도 제외됩니다.
지식 파일은 .lovable/rules/*.md에 있으며 항상 전파됩니다. 지식은 절대 제외되지 않습니다.

프로젝트 루트의 .dsignore 파일로 제외 항목을 조정할 수 있습니다. 이 파일은 gitignore 문법을 사용하며 기본값 위에 겹쳐 적용됩니다. 추가 내부 파일을 제외하거나, 기본값이라면 빠뜨렸을 항목을 다시 포함할 때 사용하세요.

디자인 시스템을 프로젝트에 연결하기

프로젝트는 한 번에 하나의 디자인 시스템을 사용합니다. 나중에 Project settings → General의 Design system 섹션에서 제거할 수 있습니다(섹션을 연 다음 연결된 디자인 시스템에서 ⋯ → Remove 선택). 그러면 관리 연결이 끊기고, 복사된 파일은 src/design-system/ 아래에 평범한 편집 가능 코드로 남습니다(이를 사용하는 부분은 깨지지 않지만 더 이상 관리·업데이트되지 않습니다).

각 프로젝트의 설정에서 어떤 디자인 시스템이 연결되어 있고 어떤 디자인 시스템을 연결할 수 있는지 확인할 수 있습니다.

새 프로젝트에 디자인 시스템 연결

lovable.dev 프롬프트 박스의 + 드롭다운에서 Design으로 이동해 Use a design system을 선택하고, 사용할 디자인 시스템을 고른 다음 프롬프트를 입력합니다. Lovable이 선택한 디자인 시스템을 사용해 새 프로젝트를 생성합니다.

선택할 수 있는 것은 게시된 디자인 시스템뿐입니다. 사용하려는 디자인 시스템이 Draft로 표시되어 있다면 디자인 시스템 프로젝트를 열고 먼저 게시하세요.

기존 프로젝트에 디자인 시스템 연결

기존 프로젝트에 디자인 시스템을 연결하려면 아래 단계를 따르세요.

상단 바에서 프로젝트 이름을 선택하고 Design system을 선택합니다(또는 Project settings → General을 열고 Design system 섹션을 찾습니다).
Attach design system을 클릭해 에디터에서 디자인 시스템 대화상자를 엽니다.
그리드에서 디자인 시스템을 선택합니다.

Lovable이 디자인 시스템의 컴포넌트와 지식 파일을 프로젝트에 복사하고, 의존성을 병합하고, 설정 검증을 자동으로 실행합니다.

디자인 시스템 다듬기

디자인 시스템은 진화하도록 만들어졌습니다. 초기 설정을 마친 뒤에는 .lovable 폴더의 내용과 컴포넌트 소스를 반복해서 개선하세요.

구조 확인
.lovable 폴더를 열어 Lovable이 스키마와 문서를 어떻게 생성했는지 확인합니다. 이 파일들은 다음 업데이트에서 연결된 모든 프로젝트에 적용됩니다.
불일치 수정
컴포넌트가 올바르게 렌더링되지 않으면 Lovable에게 이를 수정하고 동시에 스키마를 업데이트해 달라고 요청하세요. 다시 게시해 연결된 프로젝트에 수정 사항을 푸시합니다.
세부 정보 추가
필요에 따라 추가 컴포넌트 문서, 토큰 정의, 사용 패턴을 요청하세요. 게시할 때마다 버전이 올라가고 연결된 프로젝트에 사용 가능한 업데이트가 알려집니다.

`.lovable` 폴더 구조

게시할 때 Lovable이 이 구조를 자동으로 생성합니다.

디자인 시스템 프로젝트의 구조는 다음과 같습니다.

.lovable/
├── design-system.json          # 표준 스키마 (tokens, components, constraints)
├── system.md                   # 고수준 설치 지침, 직접 작성
└── rules/
    ├── components.md           # design-system.json에서 렌더링
    ├── design-tokens.md        # design-system.json에서 렌더링
    └── library-guidelines.md   # design-system.json에서 렌더링

연결된 프로젝트에서는 디자인 시스템의 .lovable 파일이 네임스페이스가 지정된 하위 폴더로 복사됩니다.

.lovable/
└── rules/
    └── libraries/
        └── <design-system-slug>/
            ├── design-system.json
            ├── system.md
            ├── components.md
            ├── design-tokens.md
            └── library-guidelines.md

해당 컴포넌트 소스는 연결된 프로젝트의 src/design-system/<design-system-slug>/에 있으며 @/design-system/<design-system-slug>/...로 가져옵니다.

디자인 시스템

얻는 것

디자인 시스템 작동 방식

디자인 시스템의 구성

디자인 시스템 프로젝트와 `.lovable` 폴더

디자인 시스템이 프로젝트에 적용되는 방식

업데이트

설정 검증

준수 검사

핵심 참고 사항과 제한

디자인 시스템 만들기

접근 권한 준비 (비공개 패키지만 해당)

디자인 시스템 프로젝트 생성

Lovable과 채팅하여 디자인 시스템 구성

디자인 시스템 게시

라이브러리를 깔끔하게 게시하도록 준비하기

로컬 소스(Path A)

npm wrapper(Path B)

공개 npm 패키지

비공개 레지스트리 패키지

연결된 프로젝트에 복사되는 것

디자인 시스템을 프로젝트에 연결하기

새 프로젝트에 디자인 시스템 연결

기존 프로젝트에 디자인 시스템 연결

디자인 시스템 다듬기

`.lovable` 폴더 구조

MCP 서버로 외부 디자인 시스템 문서 가져오기

문제 해결

FAQ

관련 주제

On this page

접근 권한 준비 (비공개 패키지만 해당)

디자인 시스템 프로젝트 생성

Lovable과 채팅하여 디자인 시스템 구성

디자인 시스템 게시

React 버전 불일치

충돌하는 의존성

연결 직후 미리보기가 깨져 보임

Lovable이 예상한 컴포넌트를 사용하지 않음

게시 실패: 비공개 패키지에 스코프 지정 레지스트리가 필요함

게시 실패: 레지스트리 인증 실패 또는 패키지를 찾을 수 없음

게시 실패: 패키지가 타입 지정 export를 제공하지 않음

게시가 아무 작업도 하지 않거나 빈 디자인 시스템으로 보고됨

디자인 시스템은 그냥 Lovable 프로젝트인가요?

한 프로젝트에 두 개 이상의 디자인 시스템을 연결할 수 있나요?

아무 프로젝트나 디자인 시스템으로 전환할 수 있나요?

어떤 디자인 시스템이 제 프로젝트에 연결되어 있는지 어떻게 확인하나요?

디자인 시스템에도 버전이 있나요?

게시된 디자인 시스템과 초안 디자인 시스템의 차이는 무엇인가요?

프로젝트에서 디자인 시스템을 제거할 수 있나요?

연결된 프로젝트에서 디자인 시스템을 편집할 수 있나요?

디자인 시스템을 npm에 게시해야 하나요?

처음부터 만드는 디자인 시스템과 npm wrapper 디자인 시스템의 차이는 무엇인가요?

디자인 시스템은 어떤 기술을 지원하나요?

디자인 시스템을 연결한 직후 에이전트가 가끔 추가 편집을 하는 이유는 무엇인가요?

디자인 시스템이 템플릿을 대체하나요?

On this page