"Claude가 내 시스템 프롬프트를 잊어버렸다"가 보통 범위(scope) 문제인 이유
단일 필드는 존재하지 않습니다 — 네 가지 필드와 API가 있을 뿐입니다
Anthropic의 개인화 개요에서는 이를 다음과 같이 명명합니다. "Claude는 경험을 개인화할 수 있는 여러 가지 방법을 제공합니다: 프로필 지침, 프로젝트 지침, 스타일." 여기에 Team 및 Enterprise 요금제를 위한 조직(organization) 레이어와 API의 system 매개변수를 추가하면 전체적인 그림은 다음과 같습니다.
Instructions for Claude (Claude용 지침) — 계정 전체 적용. "지침은 Claude가 답변 시 고려해야 할 일반적인 지침을 이해하도록 돕는 계정 전체 설정입니다." 및 "여기에 추가하는 모든 지침은 Claude와의 모든 대화에 적용됩니다." 왼쪽 하단 모서리에 있는 본인의 이니셜을 클릭한 다음 Settings(설정)를 선택하여 찾을 수 있습니다.
Project instructions (프로젝트 지침) — 단일 프로젝트로 범위 제한. "이 지침은 해당 프로젝트 내의 채팅에만 적용됩니다."
Skills (스킬) — 온디맨드 방식. "Claude와의 대화에 특정 행동이나 기능을 추가"하고 "필요할 때 활성화하는 반복 가능한 행동을 정의"합니다.
Organization instructions (조직 지침) — 상위 수준에서 설정. Team 및 Enterprise 요금제에서는 관리자(Admin) 이상이 "조직 전체의 모든 대화에서 Claude가 따를 맞춤형 지침"을 설정할 수 있습니다.
API system 매개변수 — 말 그대로 시스템 프롬프트라고 불리는 유일한 항목입니다.
다섯 가지 컨테이너, 다섯 가지 동작. "잊어버렸다"는 보고의 거의 대부분은 지침이 잘못된 컨테이너에 들어가 있기 때문에 발생합니다.
필드가 아닌 채팅창에 직접 입력했습니다
가장 흔하게 발생하는 경우입니다. 대화를 시작하고 Claude가 어떻게 행동해야 하는지 설명하는 세 문단을 작성했고, 해당 대화에서는 아주 잘 작동했습니다. 하지만 그 후 새로운 채팅을 시작했습니다.
대화 내의 텍스트는 오직 해당 대화에만 영향을 미칩니다. 상시 적용되는 것은 아무것도 없습니다. 간접적으로 Claude에게 영향을 미칠 수는 있습니다. 메모리 기능이 "커뮤니케이션 선호도 및 작업 스타일"을 캡처하기 때문입니다. 하지만 이는 메모리가 선호도를 추론하는 것일 뿐, 지침이 저장되는 것은 아닙니다. 매번 적용되도록 하려면 필드에 입력해야 합니다.
작업 중인 위치에 비해 잘못된 수준(level)으로 설정되었습니다
계정 전체 지침은 모든 대화에 적용됩니다. 프로젝트 지침은 해당 프로젝트 내부에서만 적용됩니다. 이 두 문장은 서로 반대되는 두 가지 실패 모드를 만들어냅니다.
한 프로젝트의 지침에 작성해 두고 다른 프로젝트나 일반 채팅에서 작업을 진행한 경우입니다. 당연히 지침이 적용되지 않습니다.
또는 계정 전체 지침에 작성해 두고, 자체 지침과 지식 베이스를 가진 프로젝트 내부에서도 충분히 적용될 것이라 기대한 경우입니다. 지침이 존재하긴 하지만, 동일한 내용에 대해 더 구체적으로 정의된 프로젝트 전용 지침과 충돌하게 됩니다.
본인 계정에서 확인해 볼 만한 가용성 참고 사항이 있습니다. 프로젝트 문서는 프로젝트가 "무료 Claude 계정 사용자를 포함한 모든 사용자에게 제공"되며 무료 사용자는 5개로 제한된다고 명시하고 있는 반면, 개인화 개요에서는 프로젝트 지침을 유료 전용으로 설명합니다. 막연히 짐작하기보다는 Settings(설정)를 열어 본인에게 어떤 것이 적용되는지 직접 확인해 보세요.
조직 지침이 우선 적용되고 있으며, 사용자는 이를 볼 수 없습니다
이 경우는 사용자의 위치에서 실제로 보이지 않으며, 문서에 정확히 명시되어 있습니다. 두 수준 간의 상호작용에 대해 다음과 같이 설명합니다. "둘 다 설정된 경우 조직 지침이 우선합니다. 개인 지침이 조직 지침과 직접 충돌하는 경우, Claude는 조직 수준의 지침을 선호합니다." 제공된 예시는 정확합니다. "항상 격식 있는 영어로 답변하십시오"라는 조직 지침이 "캐주얼한 톤을 사용하십시오"라는 개인 지침보다 우선합니다.
그리고 동일한 표의 가시성(visibility) 열에는 조직 지침이 "관리자(Admin) 이상"에게만 보인다고 명시되어 있습니다.
따라서 회사 계정에서는 사용자가 읽을 방법이 없는 텍스트에 의해 사용자의 지침이 지속적으로 무시될 수 있습니다. 개인 지침이 완전히 폐기되는 것은 아닙니다. "조직 지침이 다루지 않는 모든 사항에 대해서는 여전히 개인 지침이 적용됩니다." 하지만 직접적인 충돌이 발생하는 모든 지점에서는 사용자가 지게 됩니다. 이는 Claude의 작성 방식을 표준화하려는 기업에게는 올바른 설계이지만, 혼자서 진단하기에는 가장 까다로운 원인이기도 합니다. 관리자에게 어떤 설정이 되어 있는지 문의해 보세요.
해당 레이어의 두 가지 세부 사항이 더 있습니다. 조직 지침은 최대 3,000자로 제한되며, "변경 사항이 Claude 제품 전반에 적용되는 데 최대 1시간이 걸릴 수 있습니다." 관리자가 방금 무언가를 변경했다면 기다려 보는 것이 합리적인 단계입니다.
API에서는 시스템 프롬프트를 잊어버릴 수 없습니다 — 누락될 뿐입니다
API를 호출하는 경우, system 매개변수는 요청의 일부입니다. 모든 호출과 함께 전송해야 하며, 그렇지 않으면 존재하지 않습니다.
message = client.messages.create(
model="claude-opus-5",
max_tokens=1024,
system="You are a helpful coding assistant specializing in Python.",
messages=[{"role": "user", "content": "How do I sort a list of dictionaries by key?"}],
)저장 공간이 없으므로 잃어버릴 것도 없습니다. API 컨텍스트에서 "Claude가 내 시스템 프롬프트를 잊어버렸다"는 것은 코드 경로에서 이를 전송하지 않게 되었음을 의미합니다. 새로운 클라이언트, 재시도 헬퍼, 스트리밍 브랜치, 또는 자체 요청을 구성하는 프레임워크 등이 원인일 수 있습니다. 나가는 페이로드를 한 번 로그로 기록해 보면 바로 알 수 있습니다.
로드되었음에도 Claude가 여전히 수행하지 않았습니다
마지막 범주는 솔직한 한계이며, Anthropic도 직접 지적하고 있습니다. 지침 우선순위에 대해 다음과 같이 설명합니다. "지침 우선순위 지정은 프롬프트 수준의 지침에 의존합니다. 직접적으로 모순되는 지침이 포함된 드문 극단적인 사례에서는 동작이 달라질 수 있습니다. 지침을 테스트하여 예상한 결과가 나오는지 확인하십시오."
관련 안내: "조직 지침이 서로 모순되는 경우, Claude는 어느 쪽도 안정적으로 따르지 않을 수 있습니다." 또한 Claude의 핵심 학습 내용과 충돌하는 지침은 준수되지 않습니다. 지침은 강력한 문맥(context)일 뿐, 강제 집행이 보장되는 설정 파일이 아닙니다. 지침 파일이 무시되는 것처럼 보이는 네 가지 구체적인 이유를 다룬 더 넓은 범위의 내용은 why agents ignore the instruction files you wrote에서 확인할 수 있습니다.
사람들이 시도하는 방법들
모든 대화의 시작 부분에 지침 블록을 다시 붙여넣기. 영구적으로 이 작업을 반복해야 한다는 점에서 신뢰할 수 있고 영구적인(?) 방법입니다.
더 긴 지침 작성하기. 길이는 해결책이 아니며, 조직 수준에서는 오히려 역효과를 냅니다. 이러한 지침은 "조직의 모든 구성원이 보내는 모든 메시지에 포함"되기 때문입니다.
모든 프로젝트에 동일한 지침을 복사하여 붙여넣기. 네 번째 복사본이 첫 번째 복사본과 달라지기 전까지는 잘 작동하지만, 결국 어떤 것이 최신 버전인지 기억하지 못하게 됩니다.
덮어쓰기 현상을 버그로 간주하고 신고하기. 이해는 가지만, Team 또는 Enterprise 요금제를 사용 중이라면 결론을 내리기 전에 먼저 관리자에게 확인해 보세요.
모든 것을 계정 전체에 적용하기. 이렇게 하면 Claude가 휴가 계획을 세울 때도 코드 리뷰 표준을 적용하게 됩니다. 범위(scope)가 존재하는 데는 이유가 있습니다.
Claude에게 지침을 "항상 기억하라"고 말하기. 이는 메모리에 대한 요청이지 지침 필드가 아닙니다. 메모리는 선호도를 보관할 수는 있지만, 강제 집행 메커니즘은 아닙니다.
해결책: 각 지침을 실제로 적용되는 수준에 배치하기
이 문제를 영구적으로 해결하는 규칙은 설정 변경이 아니라 분류 규칙입니다. 지침은 그것이 항상 참인 가장 좁은 수준(level)에 속해야 합니다.
어디서나 항상 참인 경우 → Instructions for Claude (Claude용 지침). 왼쪽 하단 본인 이니셜 → Settings(설정) → Instructions for Claude. 선호하는 접근 방식, 사용하는 용어, 일반적인 커뮤니케이션 방향. 짧고 진정으로 보편적인 내용만 유지하세요.
특정 작업 범위에서만 참인 경우 → 프로젝트 지침. 프로젝트를 열고 "Set project instructions(프로젝트 지침 설정)"를 클릭하여 작성하고 저장합니다. Claude는 "프로젝트 내의 모든 채팅에 이 지침을 사용"합니다. 역할, 워크플로우 가이드라인, 해당 작업에 대한 요구사항.
호출할 때만 참인 경우 → Skill (스킬). 필요할 때 활성화하는 반복 가능한 행동은 다른 모든 것과 경쟁하는 상시 활성화 필드가 아닌 여기에 속해야 합니다.
조직에서 설정한 경우 → 관리자에게 문의. 회사 계정에서 Claude가 개인 지침과 계속 상충되는 경우, 조직 지침이 우선하며 관리자(Admin) 이상만 볼 수 있습니다. 질문 한 번으로 일주일의 시간을 아낄 수 있습니다.
코드로 전송되는 경우 → 요청 로그 확인. 모든 경로에서 system이 존재하는지 확인하세요.
이러한 분류는 배치를 해결해 줍니다. 하지만 해결할 수 없는 다섯 번째 범주가 있습니다. 바로 지침이 계속 참조하는 상시 지식입니다. "우리 브랜드 스타일을 따르십시오"는 브랜드 스타일이 Claude가 읽을 수 있는 어딘가에 있을 때만 작동하며, 지침 필드는 지침을 위한 것이지 문서를 위한 것이 아닙니다.
이것이 바로 MemoryLake가 제공하는 역할입니다. 개별 계정 설정과 무관하게 어시스턴트가 읽을 수 있는 레이어에 지속 가능한 컨텍스트(context)와 규칙을 보관합니다. 설정은 세 단계로 진행됩니다.
1단계: API 키 생성
MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 도구 전반에 걸쳐 하나의 자격 증명만 사용하면 됩니다.
2단계: 첫 번째 메모리 업로드
지침이 계속 가리키고 있는 실질적인 내용을 짧은 항목(각각 하나의 주장)으로 작성합니다.
표준 자체. "스타일 가이드를 따르십시오"가 아니라 검증 가능한 실제 규칙을 명시합니다.
각 규칙 뒤에 숨겨진 이유. 규칙은 하나의 대화에서만 살아남습니다. "릴리스 노트에 수동태를 사용하지 마십시오 — 지원팀이 통화 중에 이를 소리 내어 읽습니다"는 도구가 바뀌어도 살아남습니다.
어휘. 팀이 특정 방식으로 사용하는 특정 의미를 가진 용어들입니다. 이를 통해 모든 프로젝트에서 용어를 다시 설명해야 하는 번거로움을 덜 수 있습니다.
이미 거부된 사항과 그 이유. 아무도 기록하지 않아 모두가 다시 논쟁하게 되는 범주입니다.
3단계: AI 및 에이전트 연결
사용하는 도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 어시스턴트는 API를 통해 동일한 메모리를 읽습니다.
세 가지 솔직한 한계가 있으며, 첫 번째가 여기서 가장 중요합니다. 메모리 레이어는 강제 집행 메커니즘이 아닙니다. 표준을 사용할 수 있게 만들 뿐이며, 모델이 이를 따르도록 보장하지는 않으므로 위의 "로드되었으나 준수되지 않음" 범주는 여전히 유효합니다. 또한 Claude의 설정에 직접 기록되지 않으므로 지침 필드는 여전히 사용자가 관리해야 하며, 2단계는 수동으로 진행됩니다.
실제 적용 시 변화하는 점
지침이 짧아지고 짧게 유지됩니다. 방향성은 필드에 들어가고, 실질적인 내용은 메모리 레이어에 들어갑니다. 지침 필드가 문서를 붙여넣는 공간이 되지 않으며, 이는 지침이 무시되는 가장 큰 이유를 해결해 줍니다.
조직의 덮어쓰기가 더 이상 미스터리하지 않습니다. 여전히 볼 수는 없지만, 우선순위 규칙을 알고 나면 설명할 수 없던 격식 있는 톤이 설명 가능한 현상이 되며, 해결책은 디버깅 세션이 아닌 대화가 됩니다.
프로젝트 간의 중복이 사라집니다. 표준은 한 번만 존재합니다. 프로젝트 지침은 해당 프로젝트에 특정한 사항만 가리킵니다.
표준이 도구보다 오래 살아남습니다. 지침 필드는 벤더마다 다릅니다. Claude 설정에 작성한 내용은 Cursor나 Codex에 존재하지 않지만, 이들 모두가 읽을 수 있는 메모리 레이어는 존재합니다. 이에 대한 구체적인 형태는 setting up one memory across your AI tools에서 다룹니다.
"또 잊어버렸네"는 2분짜리 확인 작업이 됩니다. 어떤 필드인지, 어떤 범위인지, 어떤 수준인지 확인하면 됩니다. 거의 항상 이 세 가지 중 하나가 원인입니다.
Claude 상시 지침 작성을 위한 모범 사례
작성하기 전에 분류하세요. 보편적 지침, 프로젝트 범위 지침, 온디맨드 지침, 또는 조직 지침인지 구분합니다. 이를 한 번만 제대로 해두면 대부분의 재발을 방지할 수 있습니다.
지침 필드는 문서가 아닌 방향성만 담으세요. Claude에게 어떻게 행동해야 하는지 알려주고, 참조 자료는 검색할 수 있는 곳에 보관하세요.
새로운 대화에서 테스트하세요. 조직 지침에 대한 문서화된 조언은 개인 지침에도 적용됩니다. 저장한 후 새 채팅을 시작하고 몇 가지 다른 종류의 질문을 시도해 보세요.
3,000자 제한을 일반화하지 마세요. 이 수치는 조직 지침에만 구체적으로 문서화된 것입니다. 개인 필드에도 적용된다고 가정하지 마시고, 어느 쪽이든 간결함을 필수 사항으로 취급하세요.
관리자 변경 후 1시간 정도 기다리세요. 조직 지침 변경 사항은 "Claude 제품 전반에 적용되는 데 최대 1시간이 걸릴 수 있습니다."
자가 모순을 피하세요. 서로 충돌하는 두 지침은 둘 다 신뢰할 수 없게 만들 수 있습니다. 필드 내용을 위에서 아래까지 하나의 문서로 읽어보세요.
안전 동작을 우회하도록 지침을 작성하지 마세요. 효과가 없는 것으로 문서화되어 있으며, 노력을 들일 만한 생산적인 영역이 아닙니다.
규칙 옆에 이유를 함께 작성하세요. 이것이 지침을 이식 가능하게 만드는 요소이며, Claude가 단순히 규칙을 적용하는 것과 예상치 못한 상황에서도 규칙을 올바르게 적용하는 것의 차이를 만듭니다. 이에 대한 일반적인 관점은 what persistent memory actually means에서 다룹니다.
결론
Claude 앱에는 잊어버릴 시스템 프롬프트가 존재하지 않습니다. 계정 전체 지침, 프로젝트 지침, 스킬, Team 및 Enterprise 요금제의 조직 지침이 있으며, API에는 매 요청마다 전송하는 system 매개변수가 있을 뿐입니다. "사라진" 지침은 거의 항상 이 중 잘못된 위치에 있거나, 볼 수 없는 조직 레이어에 의해 무시되고 있거나, 종료된 대화창에 직접 입력된 경우입니다.
각 지침을 항상 참인 가장 좁은 수준으로 분류하고, 해당 필드를 짧게 유지하며, 지침이 참조하는 실질적인 내용(표준, 어휘, 결정 사항, 거부 사항)은 도구가 읽을 수 있는 레이어로 이동하세요. 그러면 지침 필드는 어떻게 행동해야 하는지를 말하고, 메모리 레이어는 무엇이 참인지를 보관하게 되어, 서로의 역할을 대신 짊어질 필요가 없어집니다. 문제가 방향성보다는 Claude가 프로젝트 자료 자체를 분실하는 것에 가깝다면, why Claude forgets your project knowledge에서 해당 사례를 다룹니다.