긴 세션에서도 지침이 유지되도록 Lovable 워크스페이스 및 프로젝트 지식을 레이어링하는 방법 (2026년 가이드)

먼저 각 레이어의 용도부터 시작해 보겠습니다.

워크스페이스 지식은 "여러 프로젝트에서 일관되게 유지되어야 하는 규칙과 컨벤션에 가장 적합"합니다. 이를 한 번만 정의하면 "모든 프로젝트의 지식 필드에서 동일한 지침을 반복하는 것을 방지"할 수 있습니다. 워크스페이스 소유자와 관리자만 이를 관리할 수 있으므로, 코딩 표준, 테스트 요구 사항, 아키텍처 규칙과 같은 가드레일을 배치하기에 가장 자연스러운 공간입니다.

프로젝트 지식은 프로젝트 편집 권한이 있는 사람이라면 누구나 편집할 수 있으며, 해당 애플리케이션에 특화된 내용(목적, 스키마, 도메인 용어, 연동 서비스 등)을 담습니다.

두 레이어 모두 모든 메시지의 배경 컨텍스트 역할을 합니다. Lovable은 연결된 서비스의 연동 지식 및 리포지토리의 지침 파일과 함께 "수정을 생성하기 전에 프로젝트가 어떻게 작동하는지 이해하기 위해 프로젝트 지식, 워크스페이스 지식 및 프로젝트 코드를 읽습니다."

이제 한계를 살펴보겠습니다. 각 레이어는 "최대 10,000자까지 지원"합니다. 워크스페이스당 정확히 하나의 워크스페이스 지식만 존재하며, "동일한 워크스페이스 내의 일부 프로젝트 하위 집합에 대해 서로 다른 워크스페이스 수준의 지침을 정의할 수 없습니다." 그리고 두 레이어가 충돌할 때의 해결 방식은 공식 문서에 다음과 같이 신중하게 기록되어 있습니다. Lovable은 "현재 프로젝트에 구체적으로 적용되므로 프로젝트 지식에 정의된 지침을 우선시하도록 권장됩니다."

'보장'이 아니라 '권장'입니다. 이 표현은 이례적으로 솔직하며, 유용한 사실을 알려줍니다. 여기서 충돌 해결은 로더(loader)에 의해 강제되는 우선순위 규칙이 아니라, 모델에 전달되는 선호도 표현이라는 점입니다. 즉, 충돌을 처리하는 가장 확실한 방법은 애초에 충돌을 만들지 않는 것입니다.

글자 수 제한, 단일 워크스페이스 계층, 모호한 충돌 해결 방식, 그리고 긴 세션에서의 주의 사항을 종합해 보면 명확한 지침이 나옵니다. 지식(knowledge)은 배경으로 유지되어야 하고, 짧게 작성되어야 하며, 서로 중복되지 않아야 하는 것들을 위한 것입니다. 그 외의 모든 것은 다른 전달 매체가 필요합니다. 이는 긴 컨텍스트 창이 구조화된 메모리를 대체하기 어려운 이유와 동일한 논리입니다. 용량 자체가 제약 조건이 되는 것은 아닙니다.

두 필드를 글자 수 제한까지 꽉 채우기. 이는 가장 흔한 접근 방식이지만, 긴 세션에서의 주의 사항에 정면으로 위배됩니다. 배경 텍스트가 많아진다고 해서 지침을 더 잘 따르는 것은 아닙니다.

"안전을 위해" 두 레이어 모두에 동일한 규칙 넣기. 이는 문서에서 경고하는 충돌 상황을 유발하며, 규칙이 아닌 선호도에 따라 해결하게 만듭니다. 공식 문서의 조언은 정반대입니다. "공유 규칙은 워크스페이스 지식에 유지하고, 프로젝트별 세부 사항은 프로젝트 지식에 유지하세요."

일부 프로젝트에만 적용할 목적으로 워크스페이스 지식 사용하기. 워크스페이스에는 단 하나의 워크스페이스 지식만 존재하며, 문서에는 워크스페이스의 일부 프로젝트로 범위를 제한하는 방법이 나와 있지 않습니다. 12개의 프로젝트 중 3개에만 적용되는 규칙을 워크스페이스 수준에서 작성하면 12개 프로젝트 모두에 적용됩니다.

지식을 작업 지침(task instructions)을 두는 곳으로 취급하기. 문서에서는 이를 명확히 구분합니다. "지식은 항상 Lovable의 배경 컨텍스트로 포함됩니다. 스킬(Skills)은 요청이 스킬 설명과 일치할 때 온디맨드로 로드됩니다." 가이드라인은 "모든 메시지에 적용되는 규칙에는 지식을 사용하고, 특정 종류의 작업에만 중요한 지침에는 스킬을 사용하라"고 안내합니다.

긴 대화가 짧은 대화처럼 작동할 것이라 가정하기. 그렇지 않으며, 이는 문서에도 명시되어 있습니다. 해결책은 지식 필드를 더 길게 만드는 것이 아닙니다.

에이전트가 탈선할 때 채팅창에서 규칙을 다시 설명하기. 이는 단 하나의 메시지에만 효과가 있을 뿐, 근본적인 해결책이 되지 않습니다. 2시간 후에 규칙이 무너지기 시작한다면, 그 규칙은 잘못된 전달 매체에 담겨 있는 것입니다.

세 가지 전달 매체, 세 가지 역할. 분류 기준은 중요도가 아니라 '관련성의 빈도'와 '지속성'입니다.

1단계: 모든 규칙을 적용 빈도에 따라 나누기

현재 지식 필드에 있는 모든 내용을 가져와 각 줄을 다음 세 가지 더미 중 하나로 분류하세요.

모든 프로젝트의 모든 메시지에 적용되는 규칙: 코딩 표준, 테스트 요구 사항, 아키텍처 제약 조건 등. 이는 워크스페이스 지식에 해당하며, 10,000자를 채우기보다는 한 페이지 정도로 짧게 유지해야 합니다.

이 프로젝트의 모든 메시지에만 적용되는 규칙: 애플리케이션의 역할, 스키마 형태, 도메인 어휘, 존재하는 연동 서비스 등. 이는 프로젝트 지식에 해당합니다.

특정 종류의 작업이 발생할 때만 적용되는 규칙: 마이그레이션을 추가하는 방법, 릴리스 체크리스트, 새 커넥터를 연결하는 방법 등. 이는 스킬(skill)에 해당합니다. 문서화된 테스트 기준은 해당 지침이 "모든 메시지에서 관련이 있는지" 여부입니다. 그렇지 않다면 그것은 스킬입니다.

대부분의 팀은 세 번째 더미가 가장 크며, 그동안 그 내용의 대부분이 지식 필드에 자리 잡고 있어 실제로 매번 적용되어야 하는 규칙들을 가로막고 있었다는 사실을 발견합니다. 이를 분리하는 것만으로도 가장 큰 개선을 이룰 수 있으며, 이는 프로젝트 문서를 에이전트가 실제로 사용할 수 있는 AI 메모리로 전환하는 것과 동일한 방식입니다.

2단계: 긴 세션에서도 유지되어야 하는 규칙은 리포지토리로 이동하기

이제 두 지식 필드에 남은 내용을 훑어보며 더 까다로운 질문을 던져보세요. "이 규칙이 세션 시작 후 3시간이 지난 시점에도 유지되어야 하는가?"

대부분은 그렇지 않습니다. 긴 대화의 후반부에서 어휘 표기법이 일시적으로 어긋나더라도 이름을 바꾸는 비용 정도만 발생합니다. 하지만 일부 규칙은 반드시 유지되어야 합니다. 데이터 손실을 방지하는 제약 조건, 보안 요구 사항, 절대 커밋해서는 안 되는 규칙 등은 일관되게 지켜지지 않을 때 막대한 비용을 초래합니다.

이러한 규칙들은 루트 레벨의 AGENTS.md에 속해야 합니다. FAQ에서는 이를 "세션 길이에 관계없이 항상 Lovable 에이전트에 의해 읽힌다"고 설명합니다. 또한 문서에서는 AGENTS.md 또는 CLAUDE.md와 같은 지침 파일이 "Lovable 에이전트에게 가이드를 제공할 수 있다"고 언급하며, 리포지토리 지침 파일을 모든 메시지에서 읽는 컨텍스트 소스 중 하나로 나열하고 있습니다.

이는 지식 필드를 완전히 포기하라는 의미가 아닙니다. 하나의 전달 매체에는 문서화된 주의 사항이 있고, 다른 매체에는 문서화된 보장이 있음을 인식하고, 타협할 수 없는 몇 가지 중요한 규칙을 보장이 있는 매체에 배치하라는 의미입니다.

3단계: 모든 중복을 제거하고 경계 테스트하기

더미가 분류되었다면 세 가지 전달 매체를 나란히 놓고 중복되는 내용을 모두 삭제하세요. 규칙이 워크스페이스 지식에 있다면 프로젝트 지식에 중복해서 있으면 안 됩니다. AGENTS.md에 있다면 두 필드 모두에 있어서는 안 됩니다.

이 단계는 모호한 충돌 해결 방식을 무의미하게 만듭니다. 프로젝트 지식의 내용이 워크스페이스 레이어와 충돌하지 않는다면, 프로젝트 지식이 워크스페이스 지식을 확실하게 이기는지 여부를 신경 쓸 필요가 없어집니다.

그 다음 경계를 의도적으로 테스트해 보세요. 프로젝트를 시작하고 워크스페이스 규칙이 제어하는 작업을 요청한 뒤 출력을 확인합니다. 프로젝트 규칙이 제어하는 작업을 요청하고 확인합니다. 그런 다음 실제로 긴 세션(1시간 동안의 실제 작업)을 진행한 후 AGENTS.md로 이동한 규칙이 여전히 잘 작동하는지 다시 확인합니다. 주의 사항은 특히 긴 대화에 관한 것이므로, 2분짜리 테스트로는 아무것도 확인할 수 없습니다.

동일한 문서 페이지에 있는 한 가지 실용적인 팁: 대화 중간에 워크스페이스 지식을 업데이트하면 "Lovable은 후속 메시지에서 업데이트된 지침을 사용합니다." 세션을 재시작하지 않고도 규칙을 수정할 수 있으므로 테스트 비용이 매우 저렴합니다.

이러한 분류를 거치면 어떤 도구를 사용하든 변하지 않는 핵심 결정 사항들(아키텍처 제약 조건, 도메인 어휘, 각 표준의 배경 이유 등)이 남게 됩니다. MemoryLake는 이러한 결정 사항들을 한 워크스페이스의 글자 수 제한에 얽매이지 않고 보관할 수 있는 공간입니다.

사용자는 자신의 언어로 직접 항목을 작성합니다. Lovable 워크스페이스 지식, 프로젝트 지식 또는 다른 벤더의 저장소에서 데이터를 마음대로 읽거나 쓰거나 삭제하지 않습니다.

1단계: API 키 생성하기

로그인 후 대시보드에서 키를 생성합니다. 이 키를 통해 에이전트는 Lovable이나 팀에서 사용하는 다른 도구에서 작성된 항목을 읽을 수 있습니다.

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

결정 사항과 그 이유를 한 항목당 하나의 사실로 추가합니다. 지식 필드에는 지침을 담고, 메모리 항목에는 그것이 존재하는 이유를 담습니다. 10,000자 제한으로 인해 어쩔 수 없이 생략해야 했던 '이유(reasoning)'를 보존할 수 있기 때문에 이러한 분리가 중요합니다. 이유가 남아 있어야 1년 후에도 해당 규칙을 검토하고 이해할 수 있습니다.

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

에이전트가 워크스페이스를 가리키도록 설정합니다. 이렇게 하면 워크스페이스 관리자만 워크스페이스 지식을 편집할 수 있는 상황에서도, 다른 도구를 사용하는 팀원이 동일하게 정리된 결정 사항을 활용할 수 있습니다.

첫 번째 변화는 지식 필드가 더 짧아진다는 점이며, 짧게 유지하는 것이 핵심입니다. 긴 세션에서의 주의 사항은 많은 컨텍스트량과 관련이 있으므로, 가벼운 배경 레이어를 유지하는 것이 임시방편이 아닌 직접적인 해결책이 됩니다.

두 번째는 권한 구조가 유기적으로 작동하기 시작한다는 점입니다. 소유자와 관리자만 워크스페이스 지식을 편집할 수 있는데, 이는 가드레일 설정에는 적합하지만 빠른 반복 작업에는 걸림돌이 됩니다. '모든 메시지, 모든 프로젝트'에 적용되는 규칙 더미가 실제로 작아지면, 해당 레이어는 설계상 거의 변경되지 않으므로 관리자 병목 현상이 더 이상 문제가 되지 않습니다.

세 번째는 타협할 수 없는 규칙들이 문서화된 보장을 제공하는 전달 매체를 갖게 된다는 점입니다. 이는 배경 지침이 유지되기를 바라는 것보다 훨씬 의미 있는 업그레이드이며, 리포지토리에 파일 하나만 추가하면 됩니다.

한 달쯤 지나면 나타나는 네 번째 효과가 있습니다. 스킬이 작업별 지침을 담당하게 되면 각 지침을 개별적으로 검토할 수 있게 됩니다. 다른 모든 내용을 읽지 않고도 마이그레이션에 관한 지침만 읽을 수 있습니다. 10,000자짜리 지식 필드는 아무도 검토하지 않으며, 이로 인해 낡은 규칙들이 방치됩니다. 동일한 역학이 팀이 실제로 유지 관리할 수 있는 지식이 아무도 읽지 않는 거대한 문서 더미보다 나은 이유와 지식이 적용되는 시점을 결정하는 트리거를 명시해야 하는 이유를 설명해 줍니다.

또한 여기서 다루지 않는 범위가 무엇인지 아는 것도 중요합니다. 채팅 연동은 연결된 도구에서 실시간 컨텍스트를 가져오고, 커스텀 연동은 자체 지식 파일을 전달하는데, 이 두 가지 모두 두 필드를 대체하는 것이 아니라 추가적인 컨텍스트 소스일 뿐입니다. 소스를 더 많이 추가하는 것은 컨텍스트가 너무 많아서 발생하는 긴 세션 문제를 해결하는 데 도움이 되지 않습니다.

글자 수 제한을 도달해서는 안 되는 상한선으로 취급하세요. 필드당 10,000자는 목표가 아니라 최대치입니다. 한 화면에 들어오는 워크스페이스 레이어가 상자를 가득 채운 레이어보다 훨씬 더 일관되게 준수됩니다.

세 가지 전달 매체를 함께 검토하여 규칙당 하나의 위치만 지정하세요. 중복은 명확한 지침을 선호도에 따라 해결되는 충돌로 바꾸는 주범입니다.

워크스페이스 수준의 규칙은 모든 프로젝트에 적용되는 경우에만 워크스페이스 수준에 두세요. 워크스페이스에는 단 하나의 워크스페이스 지식만 존재하며, 문서에는 그 아래의 하위 범위를 지정하는 메커니즘이 없습니다. 3개의 프로젝트를 위한 규칙은 해당 3개의 프로젝트 지식에 속해야 합니다.

AGENTS.md는 일관성이 깨졌을 때 비용이 많이 드는 규칙을 위해 아껴두세요. 이는 세션 길이에 대한 보장이 문서화된 전달 매체이며, 짧게 유지될 때 비로소 유용합니다.

중요도가 아닌 빈도를 분류 기준으로 삼으세요. 중요하지만 가끔 쓰이는 규칙은 스킬에 속합니다. 중요하다고 해서 지식에 집어넣기 시작하면 지식 필드가 금방 가득 차게 됩니다.

짧은 세션이 아닌 긴 세션 후에 테스트하세요. 문서화된 주의 사항은 긴 대화에 국한됩니다. 빠른 확인으로는 아무것도 검증할 수 없습니다.

필드에 담을 수 없는 규칙의 '이유'를 다른 곳에 기록해 두세요. 기록된 이유가 없는 규칙은 누군가 의문을 제기할 때까지 따르다가 결국 삭제되며, 이로 인해 팀은 여전히 필요했던 제약 조건을 잃게 됩니다. 이는 프로젝트가 기록되지 않은 지식을 잃어버리는 실패와 동일한 문제입니다.

스키마 변경 후에는 다시 검토하세요. 스키마를 설명하는 프로젝트 지식은 소리 없이 낡아지며, 잘못된 사실은 누락된 사실보다 더 나쁩니다. 잘못된 정보를 확신을 가지고 실행하기 때문입니다. 도메인 지식 자체를 지속 가능하고 검토 가능하게 유지해야 업데이트 작업을 수월하게 만들 수 있습니다.

Lovable은 두 개의 지식 레이어, 각 레이어의 글자 수 제한, 단일 워크스페이스 계층, 완곡하게 표현된 충돌 해결 선호도, 그리고 매우 긴 대화에서는 지침이 일관되게 준수되지 않을 수 있다는 주의 사항을 문서화하고 있습니다. 동시에 동일한 페이지에서 세션 길이에 관계없이 항상 읽히는 리포지토리 파일에 대해서도 설명합니다.

이러한 사실들을 종합해 보면, 이는 한계가 아니라 하나의 체계적인 분류 시스템을 보여줍니다. 규칙을 적용 빈도에 따라 분류하세요. 모든 곳의 모든 메시지에 적용되는 것은 워크스페이스 지식에, 이 프로젝트의 모든 메시지에 적용되는 것은 프로젝트 지식에, 가끔 적용되는 것은 스킬에 넣으세요. 그런 다음 일관성이 깨졌을 때 막대한 비용이 발생하는 몇 가지 규칙을 골라 루트 레벨의 AGENTS.md로 이동시키세요.

중복을 제거하고, 경계를 테스트하고, 충분히 긴 세션을 진행한 후 다시 테스트해 보세요. 도구가 바뀌어도 유지될 수 있도록 각 규칙 뒤에 숨겨진 의사결정 이유를 어딘가에 기록해 두세요. 지침은 설정에 불과하지만 의사결정은 자산이기 때문입니다. 이는 Lovable 프로젝트를 다른 곳으로 마이그레이션할 때 규칙은 쉽게 복사되지만 그 배경 이유는 복사되지 않는다는 점을 깨달을 때 팀들이 발견하게 되는 사실입니다.