컨텍스트 손실 없이 Lovable에서 Cursor로 마이그레이션하는 방법 (2026)

코드는 전송되며, 계속해서 동기화됩니다. Lovable의 GitHub 연동은 내보내기 및 양방향 동기화를 지원합니다. Lovable에서 변경한 사항은 GitHub에 동기화되고, 활성화된 GitHub 브랜치에 푸시된 변경 사항은 다시 Lovable로 동기화됩니다. 여기에는 두 가지 레이어가 있습니다. GitHub 앱을 통해 Lovable을 인증하고 프로젝트 간에 재사용할 수 있는 워크스페이스 연결과, 하나의 Lovable 프로젝트를 하나의 리포지토리에 연결하는 프로젝트 리포지토리 링크입니다.

이를 신뢰하기 전에 몇 가지 실제 한계를 알아둘 필요가 있습니다. Lovable은 한 번에 하나의 브랜치만 편집하고 동기화합니다. 일반적으로 리포지토리의 기본 브랜치(보통 main)입니다. 다른 브랜치에서 작업하려면 프로젝트의 GitHub 설정에서 다른 브랜치를 선택해야 하며, 거기서 새 브랜치를 생성할 수도 있습니다. 기존 GitHub 리포지토리를 Lovable로 가져올 수 없으며, 연결을 끊은 후 동일한 리포지토리에 다시 연결할 수 없습니다. 다시 연결하면 새 리포지토리가 생성됩니다. GitHub 앱은 동일한 계정이나 조직에 두 번 설치할 수 없고, 100 MB가 넘는 파일은 동기화에 실패하며, GitHub 사용자 이름이나 조직 이름을 변경하면 연결이 끊어집니다.

환경 변수와 보안 비밀(secrets)은 보통 첫 번째 걸림돌이 됩니다. Lovable의 GitHub 문서에서는 이를 다루지 않으며, 실제로 리포지토리에는 제공업체 키가 저장되지 않습니다. 이 마이그레이션을 진행한 실무자들은 클론한 후 Supabase, Stripe 및 유사한 자격 증명을 수동으로 구성해야 했다고 일관되게 보고합니다. "Lovable에서는 잘 작동했는데"라는 오류가 발생하면 환경 변수가 누락되었기 때문일 가능성이 높으니, 이를 해결하기 위해 한 시간 정도 여유를 두세요.

Knowledge는 전송되지 않으며, 이것이 바로 Cursor가 더 똑똑하지 못하다고 느껴지는 근본적인 이유입니다. Lovable의 Knowledge 기능을 사용하면 에이전트에게 지속적인 지침과 컨텍스트를 두 가지 수준에서 제공할 수 있습니다:

• Workspace Knowledge — 워크스페이스 내 모든 프로젝트에 공유되는 규칙: 코딩 스타일 컨벤션, 명명 규칙, 선호하는 라이브러리 또는 프레임워크, 공유 아키텍처 패턴, 테스트 요구 사항, 코드 품질 또는 린팅 규칙. 워크스페이스 소유자와 관리자만 관리할 수 있습니다.
• Project Knowledge — 단일 프로젝트에 대한 지속적인 지침 및 컨텍스트: 애플리케이션의 역할, 사용자 페르소나, 데이터베이스 스키마, 아키텍처 결정 사항, 도메인 용어, 디자인 가이드라인, 중요한 참조 링크. 프로젝트 편집 권한이 있는 사람이라면 누구나 편집할 수 있습니다.

두 가지 모두 Settings → Knowledge 및 Project settings → Knowledge 아래에 있으며, 둘 다 10,000자로 제한됩니다. 그리고 사람들이 간과하는 부분은, Knowledge가 모든 메시지에서 Lovable의 배경 컨텍스트로 항상 포함된다는 점입니다. 비록 Lovable 자체 문서에서는 대화가 극도로 길어질 경우 일관성이 달라질 수 있다고 언급하고 있지만요.

이 목록을 다시 읽어보면 이것이 규칙 파일이라는 것을 알 수 있습니다. Lovable은 .cursor/rules가 하는 일을 하고 있었던 것입니다. 단지 몇 달 동안 열어보지 않았을 수도 있는 텍스트 상자 안에서 그 일을 수행하고 있었을 뿐입니다.

채팅 기록은 전송되지 않으며, 이것이 진짜 손실입니다. 여러분이 입력한 모든 "아니요, 그렇게 말고", 부딪히며 발견한 모든 제약 조건, 거부한 모든 접근 방식 등은 대화 속에 남아 있으며, 그 대화는 Lovable에 머물러 있습니다. 규칙을 잘 지켰다면 일부는 Knowledge에 들어 있을 것입니다. 하지만 대부분은 그렇지 않으며, 이것이 바로 Lovable이 세션 간에 프로젝트 컨텍스트를 놓치는 현상이 그쪽에서도 흔히 제기되는 불만인 이유입니다.

Step 1: 코드를 Cursor로 가져오고 동기화 상태 확인하기

Lovable 프로젝트에서 Settings를 열고 아직 연결하지 않았다면 GitHub을 연결합니다. 그러면 Lovable의 GitHub 앱이 인증되고 리포지토리가 생성됩니다. 그런 다음 로컬에 클론하고 Cursor에서 해당 폴더를 엽니다.

편집을 시작하기 전에 동기화 방침을 결정하세요. 양방향 동기화는 양날의 검이기 때문입니다:

• 완전한 단절(Clean break) — Lovable 사용을 중단합니다. 클론하여 정상적으로 작업하며, 아무것도 다시 흘러 들어가지 않습니다.
• 둘 다 유지(Keep both) — 빠른 UI 반복 작업에는 Lovable을, 로직에는 Cursor를 사용합니다. 합리적이고 흔한 방식이며, 두 도구는 실제로 경쟁 관계가 아닙니다. 다만 Lovable은 하나의 브랜치만 모니터링한다는 점을 기억하세요. 해당 브랜치에 푸시하는 커밋은 Lovable로 다시 흘러 들어가며, 다른 브랜치에서의 작업은 브랜치 선택기를 전환하기 전까지 Lovable에 보이지 않습니다.

그런 다음 환경을 처리합니다. 존재하는 .env.example 파일을 복사하고, 제공업체 대시보드에서 실제 값을 채워 넣은 후, 코드를 변경하기 전에 앱이 로컬에서 실행되는지 확인합니다. 이 작업을 먼저 수행하면 다음에 발생하는 실패가 누락된 키 때문이 아니라 본인의 코드 변경 때문임을 확실히 알 수 있습니다.

주의할 점: "정리"를 위해 GitHub 연동을 해제하지 마세요. 나중에 동일한 리포지토리를 다시 연결할 수 없으며, Lovable이 새 리포지토리를 생성하게 되므로 정리가 아닌 프로젝트의 포크(fork)가 되어 버립니다.

Step 2: Lovable Knowledge를 Cursor 규칙으로 변환하기

이 단계는 Cursor가 다운그레이드처럼 느껴질지 여부를 결정하는 부분입니다.

Lovable에서 두 가지 Knowledge 수준을 모두 열고 복사합니다. 그런 다음 Lovable보다 더 세분화된 Cursor의 모델에 매핑합니다:

Cursor의 프로젝트 규칙은 버전 관리되는 .mdc 파일 형태로 .cursor/rules에 저장되며, 프론트매터 필드인 description, globs, alwaysApply를 가지며 네 가지 활성화 모드가 있습니다:

• Always Apply — 모든 채팅 세션에 적용
• Apply Intelligently — 에이전트가 설명을 바탕으로 관련이 있다고 판단할 때 적용
• Apply to Specific Files — 파일이 패턴과 일치할 때 적용
• Apply Manually — 채팅에서 @로 언급될 때 적용

Lovable의 Knowledge는 항상 켜져 있었기 때문에, 가장 쉬운 변환 방법은 모든 것을 Always Apply로 만드는 것입니다. 하지만 그렇게 하지 마세요. 수준당 10,000자의 Lovable Knowledge가 있고, Cursor 문서는 규칙을 500행 미만으로 유지하고 조합 가능한 조각으로 나눌 것을 권장합니다. 따라서 방금 제공된 세분화 기능을 활용하세요:

• Workspace Knowledge (코딩 표준, 명명 규칙, 선호하는 라이브러리, 린팅) → 모든 프로젝트에 적용되는 Customize → Rules 아래의 글로벌 설정인 Cursor의 User Rules로 변환합니다. 이것이 가장 유사한 구조적 매칭이며, Lovable에서와 마찬가지로 다음 프로젝트가 이를 상속받게 됨을 의미합니다.
• 리포지토리에 진정으로 글로벌한 Project Knowledge (앱의 역할, 도메인 용어) → .cursor/rules 내의 Always Apply 규칙 또는 프로젝트 루트의 AGENTS.md로 변환합니다. Cursor는 .cursor/rules의 대안으로 AGENTS.md를 지원하며 하위 디렉터리에서도 이를 읽습니다.
• 특정 영역에 국한된 Project Knowledge (데이터베이스 스키마, 디자인 가이드라인) → 범위가 지정된(scoped) 규칙으로 변환합니다. 데이터 레이어를 가리키는 globs가 있는 스키마 규칙은 해당 영역에 있을 때만 로드됩니다. 이는 Lovable이 할 수 있었던 것보다 분명히 더 나은 방식이며, 이번 마이그레이션의 주요 업그레이드 요소입니다.
• 중요한 참조 링크 → @로 언급할 수 있는 규칙으로 유지하거나, AGENTS.md에서 가리키는 리포지토리 내의 문서로 유지합니다. 모든 요청에 포함될 필요는 없습니다.

그런 다음 Knowledge에 전혀 포함되지 않았던 내용을 기록하세요. Lovable 채팅 기록(최소한 최근 2주 분량)을 훑어보며 결정 사항들을 추출합니다. 코드가 아니라 이유를 추출해야 합니다. 왜 이런 컴포넌트 구조를 선택했는지, 어떤 라이브러리를 시도했다가 포기했는지, 클라이언트가 무엇을 거부했는지 등입니다. 각각의 내용을 날짜가 적힌 문서로 리포지토리에 저장하세요. 이는 지루한 작업이지만 전체 마이그레이션에서 가장 가치 있는 시간입니다. 이 프로세스에서 산출물로부터 재구성할 수 없는 유일한 콘텐츠이기 때문입니다.

2단계가 끝날 때 여러분이 구축한 것에 대해 솔직해질 필요가 있습니다. 그것은 결국 동일한 대상을 더 잘 정리한 버전에 불과합니다. Cursor 자체 문서에서도 이 메커니즘이 존재하는 이유를 다음과 같이 설명합니다. "대형 언어 모델은 완료(completion) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다." 규칙은 매번 컨텍스트를 다시 제공하는 방법입니다. 규칙은 여러분이 기록해 두기로 기억한 내용을 담고 있으며, 단지 하나의 도구 전용 포맷일 뿐입니다. 이는 Knowledge를 사용할 때 처했던 상황과 정확히 일치합니다.

2단계가 실제로 무엇이었는지 살펴보세요. 한 제품의 10,000자 텍스트 상자에서 컨텍스트를 복사하여 다른 제품의 파일 형식으로 붙여넣은 다음, 둘 중 어디에도 없었던 부분을 수동으로 재구성한 것입니다.

이제 이 마이그레이션을 수행하는 많은 사람들이 두 도구를 계속 함께 사용한다는 점을 고려해 보세요. 그리고 여기에 아무도 예상하지 못한 분기(divergence) 문제가 있습니다. 여러분의 코드는 GitHub 연동 덕분에 자동으로 동기화 상태를 유지합니다. 하지만 knowledge는 그렇지 않습니다. Cursor에서 내린 결정은 Lovable의 Knowledge에 절대 도달하지 않으므로, Lovable은 한 달 전의 오래된 프로젝트 모습을 기준으로 코드를 계속 생성하게 됩니다. 이러한 괴리는 다른 곳에서 세운 규칙을 조용히 위반하며 새로 생성되는 컴포넌트로 나타납니다. 양방향 코드 동기화와 단방향 지식 동기화의 결합은 동기화가 전혀 없는 것보다 더 나쁜 실패 모드입니다. 겉보기에는 멀쩡해 보이기 때문입니다.

두 도구 모두 읽을 수 있는 하나의 레이어에 지식을 유지하는 것이 이 문제를 해결하는 방법입니다. MemoryLake는 도구 아래에 위치하는 메모리 레이어입니다. 결정 사항, 스키마, 도메인 용어 및 그 이면의 이유를 하나의 저장소에 담아 MCP를 통해 Cursor에서 읽을 수 있고, API를 통해 다른 모든 도구에서 읽을 수 있습니다. 이 저장소는 텍스트 상자 크기로 제한되지 않으며, 다음 도구로 전환할 때 다시 변환해야 하는 포맷도 아닙니다.

공정하게 말해서, Lovable의 Knowledge는 그 역할에 맞게 잘 설계된 기능입니다. 두 가지 범위 수준, 항상 적용됨, 적절한 사람들에 의한 편집 가능성 덕분에 에이전트가 실제로 올바르게 작동하도록 돕습니다. .cursor/rules 역시 일반 텍스트이자 버전 관리되며, 풀 리퀘스트에서 검토되고, 팀원들에게 자동으로 상속됩니다. 고정된 규칙에는 두 가지를 모두 계속 사용하세요. 메모리 레이어는 누적된 기록을 위한 것입니다. 10,000자 필드에 담기에는 너무 길고, 공개하기에는 너무 구체적이며, 누군가 직접 타이핑해 주기만을 바라기에는 너무 쉽게 유실될 수 있는 기록들 말입니다.

Step 1: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 완료하세요. 환경 변수나 보안 비밀 관리자(secret manager)에 보관하세요. 이 프로젝트를 위해 이미 환경 변수를 설정하고 있으므로, GitHub에 동기화되는 파일 대신 거기에 추가하는 것이 좋습니다.

Step 2: 첫 번째 메모리 업로드하기

Knowledge에 담을 수 없었던 문서, 이미지, 파일들을 업로드하세요. 이력과 함께 저장된 스키마, 아키텍처 결정 사항과 그 이유, 디자인 가이드라인, 클라이언트 제약 조건 등이 해당됩니다. 가능한 한 요약본보다는 원본 소스를 업로드하는 것이 좋습니다.

Step 3: AI 및 에이전트 연결하기

Claude, Codex, OpenClaw 및 기타 AI 에이전트에게 MCP 또는 API를 통해 메모리에 대한 액세스 권한을 부여하세요. Cursor는 MCP 서버를 지원하므로 이는 설정 항목에 해당합니다. MCP 클라이언트가 없는 도구의 경우, API를 통해 필요한 내용을 검색하여 프롬프트나 워크플로우에 주입하세요.

첫 번째 차이점은 Cursor에서의 첫 번째 실제 작업에서 나타납니다. 파일 트리만 알고 다른 것은 아무것도 모르는 에이전트 대신, 인증 흐름이 왜 그렇게 설계되었는지 답변할 수 있는 에이전트를 만나게 됩니다. 그 결정이 Lovable 스레드가 아닌 저장소에 들어 있기 때문입니다.

두 번째는 범위가 지정된 규칙이 Lovable이 할 수 없었던 작업을 수행하기 시작한다는 점입니다. 데이터 레이어에 있을 때는 스키마 컨벤션이 로드되고, CSS를 편집할 때는 방해하지 않고 비활성화됩니다. 이는 이번 마이그레이션을 통해 얻을 수 있는 진정한 기능적 이득이며, 모든 것을 Always Apply로 변환하려는 유혹을 참아내야만 실현됩니다.

세 번째는 앞서 언급한 괴리(drift) 문제입니다. 두 도구가 하나의 저장소를 읽을 때, Cursor에서 내린 결정은 다음에 사용하는 어떤 도구에서도 확인할 수 있습니다. 이는 두 도구가 협력하는 것과, 두 도구가 프로젝트에 대해 서서히 서로 다른 의견을 갖게 되는 것의 차이입니다.

그리고 이는 다음 단계에서도 유효합니다. 많은 사람들이 1년 이내에 Lovable → Cursor → 또 다른 도구로 이동합니다. 이러한 패턴은 이제 매우 흔해서 프로토타입 플랫폼에서 실제 에디터로의 마이그레이션이 하나의 장르로 자리 잡았습니다. 도구 내부에 지식을 두면 이 작업을 반복해야 하지만, 도구 아래에 지식을 두면 그럴 필요가 없습니다.

코드를 변경하기 전에 앱이 로컬에서 실행되는지 확인하세요

클론하고, 설치하고, 환경 변수를 구성하고, 실행하세요. "Lovable 코드가 깨졌다"는 보고 중 가장 흔한 원인은 자격 증명 누락이며, 리팩터링을 진행하면서 이를 진단하는 것은 매우 고통스럽습니다. 먼저 정상 실행(green run)을 확인한 다음 작업을 시작하세요.

모든 Knowledge를 Always Apply로 변환하지 마세요

Lovable의 Knowledge는 그것이 유일한 옵션이었기 때문에 항상 켜져 있었습니다. Cursor는 glob 패턴과 설명 기반 활성화를 제공하므로 이를 활용하세요. 모든 것을 Always Apply로 설정하면 영원히 모든 요청에 로드되며, 비대해진 규칙 디렉터리는 이 마이그레이션에서 가장 흔히 하는 후회 중 하나입니다.

규칙뿐만 아니라 이유도 마이그레이션하세요

Knowledge는 Cursor에게 컨벤션이 무엇인지 알려줍니다. 하지만 왜 그런지는 거의 알려주지 않으며, 이 '왜'가 있어야 에이전트가 이미 포기한 라이브러리를 다시 제안하는 일을 방지할 수 있습니다. 어떤 스레드가 중요한지 아직 기억하고 있을 때 채팅 기록에서 그 이유들을 추출해 두세요.

동기화 방침을 명확히 결정하세요

완전한 단절을 선택하거나 둘 다 유지하는 방식을 선택하세요. 둘 다 유지하기로 했다면, Lovable은 한 번에 하나의 브랜치만 모니터링하며 Lovable의 Knowledge는 Cursor 작업으로부터 아무것도 배우지 못한다는 점을 기억해야 합니다. 어떤 도구가 신뢰할 수 있는 단일 원천(source of truth)인지 아무도 모르는 반쯤 마이그레이션된 프로젝트에서는, 직접 작성한 수정 사항 위에 컴포넌트가 덮어씌워져 다시 생성되는 문제가 발생하기 쉽습니다.

Lovable에서 Cursor로의 이동은 실제로는 코드 마이그레이션이 아닙니다. 하나의 브랜치만 동기화되고, 기존 리포지토리를 Lovable로 가져올 수 없으며, 연결을 끊은 후 리포지토리를 다시 연결할 수 없다는 주의 사항만 제외하면 GitHub 양방향 동기화가 코드를 처리해 줍니다. 진짜 마이그레이션 대상은 여러분의 Knowledge입니다. 모든 메시지에 적용되던 두 개의 10,000자 제한 레이어를 워크스페이스 수준의 컨벤션을 위한 User Rules와 프로젝트별 컨벤션을 위한 범위 지정된 .cursor/rules로 변환해야 하며, 오직 채팅 스레드에만 존재했던 모든 결정 사항에 대해 날짜가 적힌 문서를 작성해야 합니다.

신중하게 결정해야 할 선택은 그 이후에 지식이 어디에 저장되느냐 하는 것입니다. Cursor의 규칙에 저장하면 이 에디터의 이 리포지토리에서만 작동하며 다음번에 다시 변환해야 합니다. 두 도구가 모두 읽는 레이어에 저장하면 양쪽 모두에서 최신 상태로 유지됩니다. 이는 사람들이 실제로 처하게 되는 상황, 즉 Lovable과 Cursor를 둘 다 열어두고 사용하는 경우에 가장 중요합니다.