Claude에서 도메인 지식이 머무를 곳이 없는 이유
먼저, 사람들이 똑같이 부르는 세 가지를 구분하세요
이 부분을 잘못 이해하면 대부분의 시도가 실패합니다. 각각의 정보가 속해야 할 위치가 다르기 때문입니다:
도메인 지식(Domain knowledge)은 모든 작업에서 변함없이 유지되는 정보입니다. 청구 심사가 작동하는 방식, 일반적인 의미와 달리 여러분의 분야에서 '코호트(cohort)'가 의미하는 바, 모든 프로젝트를 제약하는 규정 등이 이에 해당합니다. 이는 단일 프로젝트보다 오래 지속되며 끊임없이 재사용됩니다.
프로젝트 지식(Project knowledge)은 사양서, 데이터 세트, 계약서 등 하나의 작업 단위를 위한 자료입니다. 이는 구체적이며 프로젝트가 끝나면 만료됩니다. 이 사례는 Claude가 프로젝트 지식을 잊어버리는 이유에서 다루고 있습니다.
사내 컨벤션(House conventions)은 포맷팅, 검토 기준, 명명 규칙 등 팀이 일하는 방식입니다. 이 또한 다르며, Claude가 사내 컨벤션을 잊어버리는 이유에서 다루고 있습니다.
도메인 지식을 프로젝트 지식으로 저장하려고 하면 프로젝트마다 복사본을 유지 관리해야 합니다. 지침(instruction)으로 저장하려고 하면 설정 필드의 용량 한계에 금방 부딪히게 됩니다.
계정 전체 필드는 문서가 아닌 방향성을 위한 것입니다
'Claude 지침(Instructions for Claude)'은 실제로 계정 전체에 적용됩니다: '여기에 추가하는 모든 지침은 Claude와의 모든 대화에 적용됩니다.' 그리고 문서화된 예시들도 도메인 자료에 적대적이지 않습니다. Anthropic은 여기에 넣을 수 있는 항목으로 '자주 사용하는 용어 또는 개념'과 '자주 접하는 일반적인 시나리오'를 나열하고 있습니다.
따라서 압축된 용어집은 여기에 두는 것이 좋습니다. 10개의 용어를 각각 한 줄로 정의하는 것은 매우 효과적이지만 잘 사용되지 않는 방법입니다. 하지만 방대한 말뭉치(corpus)는 여기에 맞지 않습니다. 이는 상시 지침을 위한 텍스트 상자이며, 여기에 포함된 모든 단어는 주제와 상관없이 여러분이 나누는 모든 대화에 함께 전송됩니다. 여기에 분야의 참고 자료를 가득 채우면, 단 하나의 대화를 개선하기 위해 관련 없는 다른 모든 대화의 품질을 떨어뜨리게 됩니다.
프로젝트 지식은 강력하지만, 하나의 프로젝트 안에 갇혀 있습니다
프로젝트 지식은 문서를 담기에 적합한 컨테이너이며, 잘 작동합니다. '이 공간에 업로드하는 모든 항목은 해당 프로젝트 내의 모든 대화에서 사용됩니다.' 그리고 유료 요금제에서는 용량이 확장됩니다: '프로젝트 지식이 컨텍스트 한계에 도달하면, Claude는 원활하게 RAG 모드를 활성화하여 응답 품질을 유지하면서 용량을 최대 10배까지 확장합니다.' 이 향상된 용량은 Pro, Max, Team, Enterprise 요금제에서 제공되는 것으로 문서화되어 있습니다.
문제는 첫 단어에 있습니다. 프로젝트는 '자체 대화 기록과 지식 베이스를 갖춘 독립된 작업 공간을 생성할 수 있도록' 합니다. '독립된(Self-contained)' 공간이라는 점이 핵심이며, 바로 이 때문에 도메인 말뭉치가 한 곳에 머물면서 다른 프로젝트에 서비스를 제공할 수 없는 것입니다.
프로젝트 메모리도 동일한 설계로 인해 격리되어 있습니다
메모리 기능도 이 간극을 메워주지 못합니다: '각 프로젝트는 자체적인 독립된 메모리 공간과 전용 프로젝트 요약을 가지므로, 각 프로젝트 내의 컨텍스트는 집중되고 관련성이 높으며, 다른 프로젝트나 프로젝트 외 대화와 분리됩니다.'
그리고 메모리는 애초에 문서 저장소가 아닙니다. Claude의 메모리가 집중하는 것은 여러분에 대한 작업 컨텍스트입니다. 즉, 여러분의 역할과 전문적인 배경, 커뮤니케이션 선호도 및 작업 스타일, 기술적 선호도 및 코딩 스타일, 프로젝트 세부 정보 및 진행 중인 작업 등입니다. 이는 유용한 정보이지만, '이 업계에서 결제 타이밍이 작동하는 방식'과는 다른 범주입니다.
같은 영역에 두 가지 작은 함정이 더 있습니다. 컨텍스트는 '정보가 프로젝트 지식 베이스에 추가되지 않는 한 프로젝트 내 대화 간에 공유되지 않습니다.' 즉, 한 대화에서 설명한 정의를 동일한 프로젝트 내의 다음 대화에서는 사용할 수 없습니다. 그리고 프로젝트를 생성할 때 '프로젝트 이름과 설명을 입력합니다(Claude는 이 세부 정보에 액세스할 수 없습니다).' 프로젝트 이름을 Insurance Claims — EU로 지정해도 Claude에게는 아무런 의미가 전달되지 않습니다.
모든 프로젝트에 동일한 파일을 업로드하는 것은 유지 관리의 지옥입니다
대부분의 사람들이 이렇게 하고 있으며, 첫날에는 잘 작동합니다. 하지만 3개월이 지나면 5개의 프로젝트에 규정 요약본이 들어가 있고, 그중 3개는 개정 전의 것이며, 어떤 대화에서 어떤 버전을 사용했는지 알 길이 없어집니다. 지식이 낡은 것이 아니라, 여러분의 복사본들이 서로 달라진 것입니다.
사람들이 시도하는 방법들
모든 대화의 맨 위에 배경 지식 붙여넣기. 효과적이고 제한이 없습니다. 이는 AI에게 컨텍스트를 반복해서 설명하지 않는 방법에서 설명한 루프입니다.
각 프로젝트에 동일한 PDF 업로드하기. 접근성 문제는 해결하지만 버전 분열을 야기합니다. 또한 사람들이 같은 문서를 평생 다시 업로드하게 되는 이유이기도 합니다.
전체 도메인을 위한 하나의 거대한 프로젝트 만들기. 이렇게 하면 관련 없는 모든 작업이 하나의 메모리 공간과 하나의 요약을 공유하게 되어, 클라이언트 작업을 위해 원했던 격리 상태가 사라집니다.
계정 전체 지침 필드에 참고 자료 채워 넣기. 일정 예약에 관한 대화를 포함하여 여러분이 나누는 모든 대화에 도메인 말뭉치가 적용됩니다.
대화 검색 기능이 찾아내길 기대하기. 검색은 요청 시에만 작동하며, 문서화된 경계 내에서만 작동합니다. 프로젝트 내부의 검색은 해당 프로젝트 내에만 머뭅니다. 이는 상시 지식 베이스가 아닌 검색(retrieval)일 뿐이며, 이 차이는 매우 중요합니다: RAG가 메모리가 아닌 이유.
메모리가 알아서 학습하기를 기다리기. 메모리는 여러분과 프로젝트에 관한 업무 관련 컨텍스트에 집중합니다. 분야의 참고 자료를 흡수하도록 설계되지 않았으며, 이를 문서 저장소처럼 취급하면 보이지 않는 공백이 생기게 됩니다.
해결책: 하나의 도메인 레이어 위에 프로젝트 파일을 얹는 구조
효과적인 구조는 항상 참인 것과 이번 작업에서만 참인 것을 분리하고, 하나의 컨테이너에 두 가지 역할을 모두 요구하지 않는 것입니다.
프로젝트 지식은 프로젝트 자료용으로 유지하세요. 이와 싸우지 마세요. 이것이 올바른 도구입니다. 사양서, 데이터, 계약서, 현재 초안 등이 이에 해당합니다. 유료 요금제에서는 필요할 때 용량이 확장되며, Google Drive에서 추가된 문서는 동기화되므로 오래된 업로드 파일 대신 최신 버전으로 작업할 수 있습니다.
계정 전체 지침에 짧은 용어집을 넣으세요. 여러분의 분야에서 특정 방식으로 사용하는 10~15개의 용어를 각각 한 줄씩 정의하세요. Anthropic은 일반적인 용어와 전형적인 시나리오를 해당 필드에 적합한 콘텐츠로 명시하고 있습니다. 이를 20페이지 분량으로 만들고 싶은 유혹을 뿌리치세요.
모든 프로젝트에 실제 범위를 부여하고 그 안에 컨텍스트를 넣으세요. 각 프로젝트는 자체 메모리와 요약을 가지므로 작업 단위당 하나의 프로젝트를 생성하세요. 그리고 프로젝트 이름과 설명은 Claude에게 보이지 않는다는 점을 기억하고, 범위 지정에 중요한 사항은 지침이나 지식 베이스에 넣으세요.
그런 다음 도메인 자체에 프로젝트 외부의 단일 보금자리를 마련해 주세요. 이것이 Claude가 제공하지 않는 부분이며, 바로 MemoryLake가 하는 역할입니다. MemoryLake는 모든 프로젝트, 모든 일반 대화, 그리고 여러분이 사용하는 다른 도구에서 읽을 수 있는 영구 지식 저장 메모리 레이어입니다. 설정은 3단계로 진행됩니다.
1단계: API 키 생성
MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 도구 전반에 걸쳐 하나의 자격 증명만 사용하면 됩니다.

2단계: 첫 번째 메모리 업로드
여기서 저지르기 쉬운 실수는 문서를 그대로 업로드하는 것입니다. 사용할 수 있는 형태의 도메인 지식은 인덱싱되는 것이 아니라 추출(extracted)되어야 합니다. 즉, 검증 가능한 형태로 진술된 하나의 주장으로 구성된 짧은 항목들이어야 합니다. 캡처해야 할 사항은 다음과 같습니다:

일반적인 의미와 다른 정의. 모든 분야에는 내부적으로 특정 의미를 갖는 단어가 있습니다. 모델은 일반적인 의미를 자신 있게 사용하기 때문에, 이러한 단어들은 다른 어떤 것보다 보이지 않는 오류를 더 많이 유발합니다.
규칙과 그 규칙을 만들어낸 제약 조건. "결제는 T+2로 진행된다"는 사실입니다. "결제는 T+2로 진행되므로 조정(reconciliation) 작업은 당일에 처리할 수 없다"는 잘못된 제안을 방지하는 지식입니다.
경계 및 예외 사항. 일반적인 규칙이 적용되지 않는 경우입니다. 이는 가장 가치가 높으면서도 어딘가에 기록되어 있을 가능성이 가장 낮은 자료입니다.
제외된 사항과 그 이유. 여러분의 분야에서 이미 포기한 접근 방식들입니다. 이것이 없으면 새로운 대화를 나눌 때마다 모델이 이를 다시 제안하게 됩니다.
기준일이 포함된 중요한 수치. 임계값, 한도, 요율 등입니다. 날짜를 기재해 두면 오래된 항목이 스스로 드러나게 됩니다.
실제 비율을 예상해 보세요. 40페이지 분량의 참고 문서에서 일반적으로 15~30개의 항목이 추출됩니다. 만약 200개를 만들고 있다면, 지식을 추출하는 것이 아니라 문서를 그대로 필사하고 있는 것입니다.
3단계: AI 및 에이전트 연결
사용하는 도구들을 연결하세요. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트들은 MCP 서버를 가리켜 연결하고, 다른 어시스턴트들은 API를 통해 동일한 메모리를 읽습니다. 이렇게 하면 각 프로젝트가 자체 파일을 유지하는 동안, 여러분이 어디서 작업하든 도메인 레이어를 읽을 수 있게 됩니다.

세 가지 솔직한 한계가 있습니다. 이것은 프로젝트 지식을 대체하지 않습니다. 프로젝트 파일은 프로젝트 내에 있어야 하며, MemoryLake는 문서 관리 시스템이 아닙니다. MemoryLake는 여러분이나 에이전트가 기록한 내용만 보관하므로 2단계는 실제 작업이 필요합니다. 또한 규정 준수나 보존 시스템이 아닙니다.
실제 업무에서 달라지는 점
프로젝트를 시작할 때 더 이상 분야의 기초를 다시 다질 필요가 없습니다. 새로운 프로젝트를 시작해도 도메인 레이어는 이미 읽을 수 있는 상태입니다. 업계 전체가 아닌 사양서만 업로드하면 됩니다.
개정 사항에 대한 단일 진실 공급원(Single source of truth). 규정이 변경되면 3개의 오래된 복사본이 포함된 5개의 프로젝트 지식 베이스를 수정하는 대신, 단 하나의 항목만 업데이트하면 됩니다.
프로젝트 격리가 순수하게 유용해집니다. 반복해서 설명하는 비용을 치르지 않고도 작업 단위 간에 원하는 격리 상태를 유지할 수 있습니다.
정의가 흔들리지 않습니다. 한 곳에서 한 번 정의된 용어는 모든 프로젝트와 모든 도구에서 동일한 방식으로 사용됩니다.
다른 도구들도 이를 상속받습니다. 도메인 지식은 여러 어시스턴트 간에 완전히 동일한 컨텍스트입니다. 일단 Claude 외부로 나오면, Cursor와 여러분의 에이전트들도 동일한 내용을 읽게 됩니다. 이는 지식 근로자를 위한 교차 도구 메모리에서 설명한 형태입니다.
도메인 지식을 위한 모범 사례
저장하기 전에 분류하세요. 도메인, 프로젝트, 컨벤션 중 어디에 해당하는지 확인하세요. 각각 다른 보금자리와 수명을 가지고 있으며, 이를 혼용하는 것이 유지 관리 문제를 야기합니다.
업로드하지 말고 추출하세요. 문서는 읽기 위한 것입니다. 항목(entry)은 검색하기 위한 것입니다. 이 변환 과정에 가치가 있습니다.
규칙 옆에 이유를 함께 적으세요. 이유는 Claude가 예상치 못한 상황을 처리할 수 있게 해줍니다. 단순한 규칙만으로는 불가능합니다.
모든 수치 데이터에 날짜를 기재하세요. 임계값과 요율은 변경됩니다. 날짜가 없는 숫자는 미래의 오류가 됩니다.
하나의 항목에는 하나의 주장만 담으세요. 길게 결합된 항목은 검색이 잘 되지 않으며, 한쪽이 잘못되었을 때 수정하기 어렵습니다.
예외 사항을 기록하세요. 경계선에 있는 사례들이 그럴듯한 답변과 정확한 답변의 차이를 만듭니다.
계정 전체 용어집은 짧게 유지하세요. 이는 여러분이 나누는 모든 대화에 함께 전송됩니다. 10개의 용어는 유용하지만, 한 장(chapter) 분량은 관련 없는 작업에 비용을 부과하는 것과 같습니다.
분야에 변화가 생기면 검토하세요. 과거에 어떻게 작동했는지 설명하는 노트를 덧붙이기보다는 예전 항목을 삭제하세요. 두 개의 모순된 항목은 하나의 오래된 항목보다 나쁩니다. 이는 AI 메모리의 본질과 한계에서 다루는 일반적인 문제입니다.
결론
Claude는 컨텍스트를 담을 수 있는 훌륭한 컨테이너들을 가지고 있지만, 그중 어느 것도 도메인 지식에 맞는 형태를 띠고 있지 않습니다. 계정 전체 지침 필드는 상시 지침을 위한 것이며 모든 대화에 따라다닙니다. 프로젝트 지식은 문서를 두기에 적합한 곳이지만 단일 독립 프로젝트 내에 갇혀 있으며, 해당 프로젝트의 메모리 또한 마찬가지입니다. 메모리 자체는 분야의 참고 자료보다는 여러분에 대한 작업 컨텍스트에 집중합니다.
따라서 실용적인 설정은 분리하는 것입니다. 프로젝트 파일은 프로젝트 내에 둡니다. 짧은 용어집은 계정 전체에 적용합니다. 그리고 도메인(정의, 규칙, 이유, 예외 사항, 이미 제외된 사항들)은 모든 프로젝트와 모든 도구가 읽을 수 있는 레이어로 한 번만 추출합니다. 이것이 바로 새로운 프로젝트를 시작할 때 이미 여러분의 분야를 이해한 상태로 시작하고, 개정이 필요할 때 5개의 복사본을 찾아 헤매는 대신 단 하나의 항목만 수정하면 되는 방식입니다.