실제로 전송되는 항목
Git 동기화가 전달하는 내용
Lovable의 문서는 코드가 위치한 곳부터 시작합니다. "Lovable로 빌드할 때 프로젝트 코드는 Lovable 플랫폼 내부에 저장되고 관리됩니다." Git 동기화는 프로젝트를 사용자가 소유한 저장소에 연결하며, 그 이후에는 "Lovable에서 변경한 사항이 저장소에 커밋되고, 동기화된 브랜치에 푸시된 커밋이 Lovable 프로젝트에 다시 나타납니다."
이로 인해 코드 측면은 간단해집니다. 어떤 코딩 어시스턴트와도 호환됩니다. "Lovable은 어떤 도구로 만들었든 관계없이 동기화된 브랜치에 푸시된 커밋을 수신하므로, Git과 연동되는 모든 IDE나 코딩 어시스턴트가 지원됩니다." 유료 플랜에서는 Git을 연결하지 않고도 코드베이스를 다운로드할 수 있습니다.
설정 시 고려해야 할 몇 가지 제한 사항이 있습니다.
- 한 번에 하나의 브랜치만. Lovable은 동기화된 브랜치만 편집하고 동기화합니다. 다른 브랜치의 커밋은 병합하기 전까지 Lovable에 나타나지 않습니다.
- 내보내기 전용. Lovable 문서에 따르면 "기존 저장소를 Lovable로 가져올 수 없습니다." 연결 시 항상 새 저장소가 생성됩니다.
- 데이터 및 비밀 정보 제외. 저장소에는 구조를 정의하는 데이터베이스 마이그레이션 파일을 포함한 프로젝트 코드가 포함되지만, "데이터베이스 내부의 데이터는 절대 포함되지 않습니다." 또한 "Lovable에 저장한 비밀 정보(Secrets)는 저장소에 포함되지 않습니다."
Lovable에 남는 내용
Knowledge가 핵심입니다. Lovable은 이를 "Lovable 에이전트에게 지속적인 지침과 컨텍스트를 제공하는 방법"으로 설명하며, 두 가지 수준으로 제공됩니다. 워크스페이스 Knowledge는 코딩 표준 및 명명 규칙과 같은 공유 규칙을 보유합니다. 프로젝트 Knowledge는 앱의 목적, 데이터베이스 스키마, 아키텍처 결정, 도메인 용어와 같이 특정 앱에 특화된 내용을 담습니다. 각각 최대 10,000자까지 지원합니다.
Knowledge는 저장소의 파일이 아니라 설정 필드입니다. Git 동기화에 대한 Lovable의 안내는 이를 간접적으로 지적합니다. "Lovable은 사용자가 작성한 코드와 자신이 생성한 코드를 동일하게 취급하며, 이후 요청에서 둘 다 변경할 수 있습니다." Lovable의 권장 사항은 여러 요청에 걸쳐 유지되어야 하는 제약 조건을 프로젝트 Knowledge에 넣고, 의존하는 동작에 대한 테스트를 유지하는 것입니다. 이는 Lovable 내부에서는 좋은 조언이지만, 가장 중요한 제약 조건들이 복제본에는 포함되지 않는다는 것을 의미합니다.
두 번째는 기술(Skills)입니다. 워크스페이스 기술은 반복적인 작업을 위한 명명된 플레이북이며, 항상 로드되는 것이 아니라 필요할 때 로드됩니다. 이는 저장소가 아닌 워크스페이스 설정에 저장됩니다.
세 번째는 프로젝트 채팅입니다. Git 동기화 문서는 코드를 다루지, 코드를 생성한 대화 내용을 다루지 않습니다. 그곳에서 이루어진 결정은 누군가 기록하지 않는 한 저장소에 도달하지 않습니다.
Claude Code가 대신 읽는 내용
Claude Code는 모든 세션이 시작될 때 지침 파일을 읽습니다. 기본 파일은 CLAUDE.md입니다. 또한 AGENTS.md도 읽을 수 있는데, 이번 마이그레이션에서 중요한 조건이 하나 있습니다. "기본적으로 Claude는 작업 디렉토리나 그 상위 디렉토리에 CLAUDE.md가 없을 때만 AGENTS.md를 읽습니다." Claude Code의 AGENTS.md 기본값 가이드에서 이 확인 작업에 포함되는 파일들을 다룹니다. Anthropic은 "AGENTS.md를 직접 읽으려면 Claude Code v2.1.277 이상이 필요하다"고 명시하고 있습니다.
기술(Skills)은 더 직접적으로 이전됩니다. "Claude Code 기술은 여러 AI 도구에서 작동하는 Agent Skills 오픈 표준을 따릅니다." 프로젝트 기술은 .claude/skills/<skill-name>/SKILL.md에 위치하며, Anthropic은 프로젝트 기술을 "팀원들도 사용할 수 있도록 커밋하라"고 권장합니다.
Claude Code는 또한 사용자의 수정 사항과 선호도를 바탕으로 Claude가 직접 작성하는 노트인 자동 기억(auto memory)을 유지합니다. 이러한 노트는 Claude Code 세션에서 생성되므로, 사용자가 직접 기록하지 않는 한 Lovable 채팅에서 학습된 내용은 포함되지 않습니다.
두 도구가 만나는 지점: Lovable의 MCP 서버
Lovable은 외부 클라이언트가 연결할 수 있는 MCP 서버를 운영하며, Claude Code는 Lovable이 문서화한 지원 클라이언트 중 하나입니다. "Lovable MCP 서버는 모든 플랜에서 사용할 수 있습니다." 이는 Lovable의 채팅 커넥터와는 반대 개념입니다. Lovable이 도구에 접근하는 대신, 도구가 Lovable에 접근하는 방식입니다.
마이그레이션에서 유용한 부분은 읽기 도구(read tools)입니다. 문서화된 목록에는 Knowledge 텍스트를 반환하는 get_workspace_knowledge 및 get_project_knowledge, "전체 콘텐츠를 포함한" 기술을 반환하는 list_workspace_skills 및 get_workspace_skill, "프로젝트의 최근 메시지를 최신순으로 나열"하는 list_messages, 그리고 프로젝트의 히스토리와 파일을 위한 list_edits 및 read_file이 포함됩니다.
즉, Claude Code가 Knowledge와 기술을 직접 읽을 수 있으므로 수동으로 복사할 필요가 없습니다. 다만 두 가지 주의사항이 있습니다. Knowledge 쓰기 도구는 내용을 추가하는 것이 아니라 대체합니다. set_project_knowledge의 설명은 "기존 콘텐츠를 완전히 대체합니다"로 끝나므로, Lovable을 계속 사용 중이라면 에이전트가 함부로 Knowledge를 덮어쓰게 하지 마세요. 또한 list_messages는 최근 메시지만 반환하므로 전체 채팅의 아카이브가 아니라 최신 결정 사항을 검토하는 용도로 사용해야 합니다.
시작 전 확인 사항
Enterprise 워크스페이스. 타사 MCP 액세스는 "Enterprise 워크스페이스에서 기본적으로 비활성화되어 있습니다." 소유자나 관리자가 먼저 활성화해야 합니다.
범위 및 비용. Lovable은 연결이 "하나의 프로젝트에 국한되지 않음"과 "도구 호출이 실제 크레딧을 사용하고 실제 프로젝트를 편집함"을 경고합니다. FAQ에 따르면 크레딧은 create_project 및 send_message에 적용되며 다른 도구는 무료이므로, Knowledge와 기술을 읽는 데는 크레딧이 소모되지 않아야 합니다. Lovable 에이전트에게 메시지를 보내는 경우에는 소모됩니다.
권한 확인. "워크스페이스 소유자와 관리자만 워크스페이스 Knowledge를 관리할 수 있습니다." 커스텀 기술은 편집자 등급 이상부터 다운로드할 수 있습니다. Lovable의 내장 기술에 대해 FAQ는 "워크스페이스에 추가한 기술만 다운로드할 수 있습니다"라고 설명합니다. 관리자가 아니라면 현재 워크스페이스 Knowledge를 관리자에게 요청하세요.
조직의 규칙. Knowledge에는 내부 참조가 포함되는 경우가 많고, 프로젝트 채팅에는 클라이언트 세부 정보가 포함될 수 있습니다. 새로운 도구나 파일로 옮기기 전에 허용 여부를 확인하세요.
수동 마이그레이션
1단계: 코드 동기화 후 Lovable에서 Knowledge와 기술 추출하기
프로젝트 설정의 Git 항목에서 프로젝트를 저장소에 연결하고, 진행 중인 Lovable 편집이 완료될 때까지 기다립니다. 동기화 상태 카드를 통해 Lovable과 제공업체가 동일한 커밋 상태인지 확인할 수 있습니다. 저장소를 클론하고 기능 브랜치(feature branch)에서 작업하여 Lovable의 동기화된 브랜치를 깨끗하게 유지하세요.
다음으로 컨텍스트를 추출합니다. Lovable 문서의 설정 단계를 따라 Claude Code를 Lovable의 MCP 서버에 연결합니다. 그런 다음 Claude Code에게 프로젝트 Knowledge와 워크스페이스 Knowledge를 읽어 각각 임시 파일(scratch file)에 저장하도록 요청하세요. 사용하기 전에 직접 읽어보시기 바랍니다. 몇 달 전에 작성된 Knowledge에는 이미 변경된 규칙이 포함되어 있을 수 있습니다. MCP 연결을 원하지 않는다면 프로젝트 설정의 Knowledge 항목에서 텍스트를 직접 복사하세요.
기술의 경우, Lovable은 워크스페이스 설정의 Skills 항목에서 커스텀 기술을 zip 파일로 다운로드할 수 있게 해줍니다. Lovable은 자사의 기술이 "Anthropic의 Claude 및 Agent Skills 컨벤션을 따르는 다른 도구와 동일한 SKILL.md 형식을 사용한다"고 밝히고 있으므로 별도의 변환이 필요 없습니다.
마지막으로 최근 채팅을 검토하세요. Claude Code에게 MCP를 통해 프로젝트의 최근 메시지를 나열하도록 요청하거나, 직접 채팅을 스크롤하며 Knowledge에 반영되지 않은 결정 사항들을 기록하세요. 예를 들어 특정 라이브러리를 선택한 이유, 시도했다가 포기한 것, 절대 변경해서는 안 되는 동작 등이 있습니다. 각 항목에 날짜를 기입하세요.
2단계: 두 도구가 모두 읽는 하나의 지침 파일 작성 및 기술을 저장소로 이동
두 도구는 기본적으로 서로 다른 파일을 읽습니다. Lovable의 Knowledge FAQ에 따르면 "루트 레벨의 AGENTS.md 파일은 세션 길이에 관계없이 항상 Lovable 에이전트가 읽으며", CLAUDE.md와 같은 지침 파일도 에이전트를 안내할 수 있습니다. Claude Code는 CLAUDE.md가 없을 때만 AGENTS.md를 읽습니다.
따라서 Claude Code와 함께 Lovable을 계속 사용할 계획이라면 공유 규칙을 루트 레벨의 AGENTS.md에 넣으세요. 두 도구 모두 이를 읽습니다. Claude 전용 지침이 필요한 경우, Anthropic이 권장하는 패턴은 CLAUDE.md 내부에 @AGENTS.md 임포트 구문을 넣어 AGENTS.md를 "모든 도구가 공유하는 단일 파일"로 유지하는 것입니다. Lovable도 CLAUDE.md를 읽을 수 있으므로 이 파일은 짧게 유지하세요.
그런 다음 Lovable 컨텍스트의 각 부분을 변환합니다.
- 프로젝트 Knowledge는
AGENTS.md가 됩니다. 짧고 직접적인 규칙으로 다시 작성하세요. Anthropic의 가이드는 "CLAUDE.md파일당 200행 미만을 목표로 할 것"을 권장하며, 여기서도 동일한 원칙이 도움이 됩니다. - 워크스페이스 Knowledge는 공유 규칙이 됩니다. 모든 프로젝트에 적용되는 규칙을 각 저장소의
AGENTS.md에 넣거나, 개인적인 규칙은 사용자 수준의 Claude Code 지침에 보관하세요. - 채팅 결정 사항은 결정 기록 파일이 됩니다. 날짜별 항목으로 구성된 하나의 파일을 만들고 최신순으로 정렬하세요.
AGENTS.md에서 이 파일을 링크하세요. - 기술은
.claude/skills/로 이동합니다. 다운로드한 각 기술의 압축을 풀어 개별 폴더에 넣고 커밋하세요.
Lovable은 또한 클라이언트에게 자사 MCP 서버를 다루는 법을 가르치는 기술을 제공하며, 문서에서는 Claude Code를 위한 위치로 .claude/skills/lovable-mcp/SKILL.md를 제안합니다. Claude Code에서 Lovable을 계속 빌드할 계획인 경우에만 이를 추가하세요.
Claude Code 세션을 시작하고 로드된 내용을 확인하세요. AGENTS.md만 있는 경우, 대화형 세션에서 CLAUDE.md를 찾을 수 없어 AGENTS.md를 로드했다는 메시지가 표시됩니다. CLAUDE.md가 있는 경우 /context를 실행하여 Memory 파일 아래에 나타나는지 확인하세요. 그런 다음 Claude에게 로드된 규칙을 요약해 달라고 요청하세요. 누락된 것이 있다면 채팅이 아니라 파일을 수정하세요.
이전에 다른 브라우저 기반 빌더에서 이동해 본 적이 있다면, Replit에서 Claude Code로 마이그레이션하는 가이드도 동일한 패턴을 따릅니다.
더 나은 방법: 두 도구 모두 사용할 수 있는 한 곳에 프로젝트 결정 사항 유지하기
수동 마이그레이션은 Lovable의 Knowledge와 채팅을 Claude Code가 읽는 파일로 변환합니다. 결정 기록 파일은 가장 가치 있는 부분입니다. 동시에 Lovable과 Claude Code가 동일한 코드에서 계속 작업하기 때문에 내용이 어긋나기 가장 쉬운 부분이기도 합니다.
MemoryLake는 이러한 결정 사항들을 사용자가 직접 관리하는 하나의 목록으로 유지하여 Claude Code 및 다른 어시스턴트에서 사용할 수 있게 해주는 기억 계층(memory layer)입니다.
사용자는 자신의 언어로 직접 항목을 작성합니다. Lovable Knowledge, 워크스페이스 기술, Claude Code 기억 또는 어떤 벤더의 저장소에서도 내용을 읽거나 쓰거나 삭제하지 않습니다. 프로젝트 세부 정보를 복사하기 전에 조직의 정책을 확인하세요.
1단계: API 키 생성
로그인 후 대시보드에서 키를 생성합니다. 이 키는 Lovable이나 Anthropic 계정과 별개인 MemoryLake 워크스페이스에 속합니다.

2단계: 첫 번째 기억 업로드
수동 마이그레이션의 1단계에서 기록한 결정 사항부터 시작하세요. 항목당 하나의 결정을 날짜 및 이유와 함께 작성합니다.

3단계: AI 및 에이전트 연결
Claude Code와 사용하는 다른 어시스턴트를 연결하세요. 그러면 동일한 결정 사항이 특정 도구의 설정에 갇혀 있지 않고 연결된 각 도구에서 사용 가능해집니다.

실제적인 변화
첫 번째 차이점은 Lovable의 컨텍스트를 읽고 검토할 수 있게 된다는 것입니다. 이전에는 설정 필드에 머물러 있던 Knowledge가 이제 저장소의 파일이 되어 코드와 함께 버전 관리됩니다.
두 번째는 작업 번복이 줄어든다는 점입니다. Lovable은 이후 요청에서 사용자가 작성한 코드를 변경할 수 있습니다. 두 도구가 모두 읽는 루트 AGENTS.md에 제약 조건이 있으면 Lovable과 Claude Code 모두에게 명확하게 전달됩니다.
세 번째는 기술이 계속 작동한다는 것입니다. 두 도구 모두 동일한 SKILL.md 형식을 사용하므로, 워크스페이스에서 다듬은 워크플로우를 다시 작성하지 않고도 Claude Code에서 실행할 수 있습니다. 다만 기술은 절차를 전달할 뿐 결정 사항을 전달하지는 않으므로, 기술이 기억을 대체할 수 없는 이유와 결정 기록 파일이 여전히 중요한 이유가 여기에 있습니다.
네 번째는 반복적인 설명이 줄어든다는 점입니다. 올바른 지침 파일로 시작하는 세션에서는 프로젝트나 상황을 다시 설명할 필요가 없습니다. 이에 대해서는 Claude Code가 프로젝트 컨텍스트를 잊어버리는 경우에 대한 가이드에서 다루고 있습니다.
Lovable에서 Claude Code로 이동하기 위한 모범 사례
Lovable을 별도의 브랜치에 유지하세요. 기능 브랜치에서 작업하고 동기화된 브랜치로 병합하세요.
동기화된 히스토리를 다시 쓰지 마세요. Lovable 문서는 이미 동기화된 브랜치에 있는 커밋에 대해 강제 푸시(force-push), 리베이스(rebase) 또는 스쿼시(squash)를 하지 말라고 권고합니다.
복사하기 전에 Knowledge를 읽어보세요. 오래된 규칙은 잘못된 규칙인 경우가 많습니다.
하나의 루트 AGENTS.md를 사용하세요. 두 도구 모두 이를 읽습니다.
MCP 쓰기 작업을 신중하게 다루세요. Knowledge 쓰기는 필드 전체를 대체합니다.
기술을 저장소에 커밋하세요. 그래야 Claude Code가 프로젝트 기술을 찾을 수 있습니다.
채팅 결정 사항을 기록하세요. Lovable이 프로젝트 컨텍스트를 잊어버리는 경우에 대한 가이드에서 설명하듯이, 채팅 내용은 코드와 함께 이동하지 않습니다.
결론
Lovable에서 Claude Code로 이동하는 과정은 코드는 쉽지만 컨텍스트는 신중해야 합니다. Git 동기화는 Claude Code가 작업할 수 있는 저장소를 제공합니다. 하지만 Lovable의 Knowledge, 기술, 채팅은 사용자가 직접 꺼내오지 않는 한 Lovable에 그대로 남습니다.
Lovable의 MCP 서버는 이 과정을 더 쉽게 만들어 줍니다. 쓰기 도구만 주의해서 다룬다면 Claude Code는 프로젝트 및 워크스페이스 Knowledge, 커스텀 기술, 최근 메시지를 직접 읽을 수 있습니다. 기술은 두 도구가 동일한 SKILL.md 형식을 사용하므로 그대로 이동할 수 있습니다.
공유 규칙은 루트 레벨의 AGENTS.md에 넣고, Claude 전용 지침이 필요한 경우 이를 임포트하는 짧은 CLAUDE.md를 추가하며, 날짜가 기입된 결정 기록 파일을 유지하세요. 이것이 바로 마이그레이션하지 않았을 때 매번 수정을 통해 다시 구축해야 했을 컨텍스트입니다.