Lovable한국어 문서

Lovable 문서를 작성·업데이트하는 문서 에이전트를 위한 정확성, 구조, 문체, 커넥터 가이드입니다.

문서 인덱스

전체 문서 인덱스는 https://docs.lovable.dev/llms.txt 에서 가져오세요. 다른 페이지를 살펴보기 전에 이 파일로 사용 가능한 모든 문서를 파악하세요.

AGENTS

문서 에이전트 지침

Lovable은 사용자가 자연어 프롬프트로 웹 애플리케이션을 만들 수 있는 풀스택 앱 개발 플랫폼입니다.

이 지침은 Mintlify AI 에이전트가 docs.lovable.dev의 문서를 작성하고 업데이트하는 방법을 정의합니다. 명시적으로 다른 지시가 없다면 항상 일관되게 따르세요.

정확성과 안전

  • 제품 동작, 제한, 가격, 플랜별 제공 범위, UI 요소를 지어내거나 추측하지 마세요.
  • 기능을 사용할 수 있는 플랜(Free, Pro, Business, Enterprise 또는 모든 플랜)을 항상 명시하세요.
  • 빌드에 쓰는 워크스페이스 크레딧과 배포된 앱에 쓰는 Cloud/AI 잔액을 구분하세요.
  • 정보가 문서나 제공된 자료에 명확히 나와 있지 않다면 추측하지 마세요.
  • 불확실하거나 추측에 기대는 세부 정보를 추가하기보다 생략하세요.
  • 필요하면 임의로 빈칸을 채우지 말고 명확한 설명을 요청하세요.
  • 되돌릴 수 없는 작업, 제한 사항, 알 수 없는 부분은 해당할 때 명확히 밝히세요.

필수 정보 흐름(핵심 규칙)

문서 페이지를 작성하거나 업데이트할 때는 다음 서사 순서를 따르세요.

  1. 무엇: 기능, 커넥터, 개념이 무엇인지 설명합니다.
    • 짧은 단락 1~2개로 작성하세요.
  2. 왜: 왜 중요한지 설명합니다.
    • 가치, 결과, 사용하기 알맞은 상황과 알맞지 않은 상황에 집중하세요.
  3. 누가: 누구를 위한 내용인지 설명합니다.
    • 구체적인 활용 사례, 예시 앱, 상황, 표를 사용하세요.
  4. 어떻게: 어떻게 동작하고 사용하는지 설명합니다.
    • 설정 단계, 구성, 필요 조건(계정, 자격 증명), 결제와 사용량 정보, 제한 사항, 되돌릴 수 없는 작업을 포함하세요.
    • 개념 또는 참조 문서라면 “어떻게”에서 세부 절차 대신 개념의 작동 방식을 크게 설명해도 됩니다.
  5. FAQ: 명확성, AI 어시스턴트의 정보 검색, 검색 순위를 개선할 자주 묻는 질문을 추가하세요.

기본 섹션 순서(필수)

콘텐츠에 명백히 맞지 않는 경우가 아니라면 아래 헤딩 순서를 그대로 사용하세요. 섹션 제목은 문서에 가장 자연스럽게 맞추세요.

  • 소개(무엇인지 설명)
  • 사용 이유와 적합한 시점 설명
  • 일반적인 활용 사례와 예시 앱(누가 어떻게 사용하는지 설명)
  • 사전 요건(외부 계정, 워크스페이스 역할과 권한, 가격제 플랜 등 내부·외부 요건 나열)
  • 설치/구성(설치, 연결, 구성 방법과 구성별 세부 사항 설명)
  • 제한 사항(있는 경우)
  • FAQ(선택 사항이지만 SEO를 위해 권장하며, 특정 커넥터 페이지에서는 항상 제외)
  • 문제 해결(선택)

포함할 내용(콘텐츠 체크리스트)

  • 사용자에게 API 키, 계정, 환경 설정, 의존성이 필요하면 사전 요건을 추가하세요.
  • 검색 엔진과 Mintlify AI 어시스턴트가 콘텐츠를 이해하고 순위를 매기는 데 도움이 되도록 FAQ를 추가하세요.
  • 지원 티켓에서 자주 발생하는 문제에는 문제 해결 섹션을 추가하세요.
  • 비용 부담 주체, 사용량 소모, 되돌릴 수 없는 작업을 명확히 밝히세요.

FAQ

  • 대부분의 페이지에 FAQ 3~6개를 포함하세요(페이지 길이에 따라 조정).
  • 사용자가 실제로 물어볼 법한 자연스러운 질문으로 작성하세요.
  • 다음 주제의 질문을 우선하세요.
    • 비용과 부담 주체(Lovable 대 외부 제공자)
    • 계정, 자격 증명, API 키 요건
    • 제한, 할당량, 속도 제한
    • 삭제, 철회, 되돌릴 수 없는 작업
    • 일반적인 오해나 실패 사례
  • 답변은 간결하고 사실에 기반하며 훑어보기 쉽게 작성하세요.
  • 마케팅 표현은 피하고 명확성과 검색 정확도를 최적화하세요.

전역 작성 원칙

  • 소개는 훑어보기 쉽고 짧게 작성하세요.
  • “왜” 섹션에서는 기능보다 결과를 우선하세요.
  • “누가”와 “어떻게”에서는 구체적이고 현실적인 예시를 사용하세요.
  • 정확한 UI 경로를 포함해 모든 단계를 모호함 없이 작성하세요.

SEO와 접근성

  • 사용자가 검색할 법한 키워드를 포함한 설명적인 헤딩을 사용하세요.
  • frontmatter의 title과 description은 명확하고 구체적이며 사용자 중심으로 작성하세요.
  • 발견 가능성을 높이는 데 도움이 되면 frontmatter에 keywords 배열을 추가하세요. 사용자가 검색할 구체적이고 관련성 높은 용어를 쓰고 키워드를 과도하게 나열하지 마세요.
  • 행동을 유도하는 페이지 제목을 선호하세요. 도움이 된다면 제목을 길고 설명적으로 써도 됩니다.
  • 페이지 제목이 길다면 네비게이션에 쓸 짧은 sidebarTitle을 추가하세요.
  • “여기를 클릭”은 피하고 구체적이고 행동을 알 수 있는 링크 텍스트를 사용하세요.
  • 헤딩 레벨을 건너뛰지 말고 논리적인 계층을 유지하세요.
  • 모든 이미지와 다이어그램에 설명적인 대체 텍스트를 추가하세요.
  • 짧은 단락, 목록, 명확한 섹션 구분으로 훑어보기 쉽게 구조화하세요.

Mintlify 컴포넌트(사용 시점)

명확성과 가독성을 높이기 위해 Mintlify 컴포넌트를 의도적으로 사용하세요. 과도하게 사용하지 마세요.

콜아웃

  • 본문을 보완하는 유용한 배경 정보에는 <Note>를 사용하세요.
  • 모범 사례나 전문적인 조언에는 <Tip>을 사용하세요.
  • 파괴적인 작업, 되돌릴 수 없는 단계, 보안 문제, 중요한 제한 사항에는 <Warning>을 사용하세요.
  • 성공을 확인하거나 검증 단계를 제공할 때는 <Check>를 사용하세요.

단계

  • 특히 설치나 구성처럼 순서대로 수행해야 하는 여러 단계의 절차에는 <Steps>와 <Step>을 사용하세요.
  • 작업을 순서대로 수행해야 할 때는 단계 컴포넌트를 우선하세요.
  • 가능하면 검증 단계나 성공 표시를 포함하세요.

탭

  • 플랫폼별 지침이나 서로 다른 대안에는 <Tabs>를 사용하세요.
  • 순차적인 단계에는 탭을 사용하지 마세요.

아코디언

  • 문제 해결, FAQ, 예외 사항, 고급 구성에는 <AccordionGroup>을 사용하세요.
  • 핵심 흐름은 눈에 보이게 두고 세부 사항만 아코디언 안에 넣으세요.

코드 그룹

  • 같은 예시를 여러 언어로 보여 줄 때는 <CodeGroup>을 사용하세요.
  • 한 언어만 필요하면 단일 코드 블록을 사용하세요.

대상 독자와 어조

  • 주로 비기술 독자를 위해 작성하세요.
  • 과도하게 단순화하지는 말되, 직관적이지 않은 개념은 설명하세요.
  • 능동태와 2인칭(“당신”)을 사용하세요.
  • 마케팅 표현보다 명확성, 정확성, 유용성에 집중하세요.

문체와 형식

  • em dash(—)를 절대 사용하지 마세요.
  • 미국식 영어: 전체 문서에 미국식 철자(organization, canceled, grayed out, color)를 사용하세요.
    • 예외: 제품이나 UI가 영국식 철자를 쓰면 그대로 인용하세요(예: Security view의 Cancelled 모의 해킹 상태 배지).
  • 능동태: 누가 행동하는지 분명하게 보이도록 능동태를 선호하세요.
    • 올바른 예: “프로젝트를 삭제하세요.”
    • 잘못된 예: “프로젝트가 삭제됩니다.”
    • 예외: 상태나 결과를 강조할 때는 피동태를 사용해도 됩니다.
      • 예: “프로젝트가 저장됩니다.”
  • 현재형:
    • 일반적인 동작은 현재형으로 작성하세요.
      • 올바른 예: “Save를 클릭하면 설정이 업데이트됩니다.”
    • 미래의 결과에만 미래형을 사용하세요.
      • 올바른 예: “변경 사항이 손실됩니다.”
  • 문장형 대소문자:
    • 모든 헤딩은 문장형 대소문자로 작성하세요.
    • 첫 단어, 고유 명사, 약어만 대문자로 시작하세요.
    • 올바른 예: “Project settings”
    • 잘못된 예: “Project Settings”
  • 연속(Oxford) 쉼표:
    • 나열의 마지막 “and” 또는 “or” 앞에 항상 쉼표를 넣으세요.
    • 예: “Edit, share, and delete projects.”
  • 날짜:
    • July 31, 2025처럼 월 일, 연도 형식을 사용하세요.
    • 1st, 2nd, 3rd처럼 서수를 사용하지 마세요.
  • UI 참조:
    • UI 요소는 Settings, Delete project처럼 굵게 표시하세요.
    • 값, 필드, 식별자는 project_id처럼 인라인 코드로 표시하세요.
    • Settings → Privacy & security → Default project visibility처럼 화살표로 정확한 UI 경로를 적으세요.

커넥터 페이지

용어: “앱 커넥터”는 앱 + 채팅 커넥터와 앱 사용자 커넥터를 모두 포함하는 상위 용어입니다. 앱 사용자 커넥터 페이지와 관리자 페이지의 “App connector controls” 섹션처럼 두 유형에 모두 해당하는 설명에서는 상위 용어를 사용하고, 그 외에는 구체적인 유형 이름을 쓰세요. “채팅 커넥터(MCP 서버)”는 별도 계열입니다.

커넥터 페이지는 integrations/에 있으며 docs.json의 Integrations tab → Connector catalog → CATEGORY 아래에 표시됩니다. 새 페이지는 올바른 범주 하위 그룹(AI & search, Data & databases, Communication & messaging, CRM & sales, Developer tools, E-commerce, Finance & accounting, Maps & location, Marketing & social, Payments & billing, Productivity, Security & compliance, Websites & CMS)에 알파벳 순으로 배치하세요. 개요 페이지에 커넥터 목록이나 개별 커넥터 행을 추가하지 마세요.

위에서부터 아래로 다음 템플릿을 사용하세요.

  1. 소개 단락: 도구가 무엇이고 앱이 무엇을 할 수 있는지 설명합니다.

  2. 연결 유형 표시, 소개 바로 뒤:

    • 여러 연결 유형을 지원하는 커넥터(제품에서 확인): 유형별로 한 행씩 넣은 | Use | If you want to | 선택 표를 사용하세요. 이 페이지가 다루는 유형에 “(this page)”를 표시하고 다른 유형은 /integrations/chat-connectors, /integrations/app-user-connectors에 링크하세요.
    • 단일 유형: 페이지의 유형을 명시하는 한 문장을 쓰세요. 앱 + 채팅의 경우: “CONNECTOR_NAME은 앱 + 채팅 커넥터로 제공됩니다. 빌드 중에는 채팅에서, 게시한 앱에서는 공유 연결 하나로 동작합니다.” 앱 사용자 전용 커넥터(Workday)는 대신 앱 사용자 커넥터라고 명시합니다.
    • 맞춤형 커넥터(Supabase, Stripe, Shopify)나 워크스페이스 보안 커넥터(Aikido, Wiz)에는 표시를 추가하지 마세요.

  3. 설정 단계는 “Connectors를 열고 **CONNECTOR_NAME**을 선택하세요.”로 시작합니다. UI 진입점을 열거하지 말고 커넥터 찾기로 링크하세요. 페이지에서 프로젝트에 연결을 링크하는 첫 언급(보통 연결 방법 소개의 “사용할 프로젝트에 링크” 문장, 또는 단계 뒤의 “채팅에서 Lovable에 프로젝트 링크 요청” 문장)은 프로젝트에 연결 링크로 연결하세요. 이후 언급은 일반 텍스트로 두세요.

  4. 거버넌스 설명은 연결과 클라이언트를 만들 수 있는 사용자와 연결과 클라이언트를 사용할 수 있는 사용자로 링크하세요. 개별 커넥터 옵션은 No one, Admins, Editors & admins입니다. No one은 사실상 커넥터를 비활성화합니다. 별도의 비활성화 스위치는 없으므로 “admin이 커넥터를 비활성화했다”를 독립된 개념처럼 쓰지 마세요.

  5. 공유 관리 스니펫으로 끝내세요(링크 해제와 삭제를 다룸).

    import ManageConnection from '/snippets/manage-connection.mdx';

<ManageConnection connector="{Name}" />

채팅 전용 커넥터(Canva, Miro, 그 외 주요 MCP 서버)는 개별 페이지를 만들지 말고 /integrations/chat-connectors에 나열하세요. 앞의 FAQ 규칙에 따라 커넥터 페이지에는 FAQ 섹션을 두지 않습니다.

예외: Figma는 채팅 커넥터 외에도 Figma 플러그인, 데스크톱 앱을 통한 로컬 MCP 서버, .fig 파일 업로드라는 세 가지 서로 다른 연동 방식을 다루므로 /integrations/figma에 전용 디자인 가져오기 페이지가 있습니다(Connector catalog가 아닌 Design 그룹에 배치). Figma MCP는 /integrations/chat-connectors가 아닌 해당 페이지에서 설명합니다.

프롬프트 예시

  • 모든 프롬프트 예시는 일반 텍스트 코드 블록에 넣으세요.
  • 가독성을 유지하도록 text wrap을 사용하세요.

예:

Integrate the OpenWeatherMap API.
Base URL: https://api.openweathermap.org/data/2.5.
Auth: API key passed as a query parameter appid.
I need an endpoint to fetch the current weather: GET /weather?q={city}&units=metric&appid={API_KEY}.
Docs: https://openweathermap.org/current

관련 주제

On this page

문서 인덱스AGENTS문서 에이전트 지침정확성과 안전필수 정보 흐름(핵심 규칙)기본 섹션 순서(필수)포함할 내용(콘텐츠 체크리스트)FAQ전역 작성 원칙SEO와 접근성Mintlify 컴포넌트(사용 시점)콜아웃단계탭아코디언코드 그룹대상 독자와 어조문체와 형식커넥터 페이지프롬프트 예시관련 주제