Claude가 내 코딩 스타일을 고수하게 만드는 방법 (2026)

메모리가 켜져 있지 않거나, 두 가지 버전의 메모리가 존재할 수 있습니다

먼저 어떤 버전을 사용 중인지 확인해야 합니다. 버전에 따라 토글 스위치의 위치가 다르기 때문입니다. 문서에 명시된 테스트 방법은 다음과 같습니다. Settings > Memory에서 Memory가 보인다면 새로운 버전을 사용 중인 것입니다. "Settings > Capabilities에서 Memory가 보인다면 레거시 메모리 버전을 사용 중인 것입니다."

새로운 버전의 경우, 메모리는 사용자가 직접 활성화해야 하는 옵트인 기능입니다. Settings > Memory로 이동하여 Generate memory from chats를 켜세요. 이 기능은 "무료, Pro, Max 요금제를 사용하는 Claude 사용자"가 사용할 수 있으며, 웹, Claude Desktop, Claude Mobile에 적용되고, "현재 Cowork에서는 사용할 수 없습니다." Enterprise 요금제를 사용하는 경우 추가적인 제한이 있습니다. 구성원은 "조직의 소유자가 이 기능을 활성화한 경우에만 개별적으로 이 기능을 활성화할 수 있습니다."

두 버전은 수정 사항이 반영되는 방식에서도 차이가 납니다. 새로운 버전은 "카테고리별로 정리된 개별 항목 세트로 메모리를 구축"하며, "Claude는 정해진 일일 일정에 따르지 않고 대화하는 동안 실시간으로 이러한 항목을 읽고 쓰고 업데이트합니다." 반면 레거시 버전은 "24시간마다 업데이트되는" 요약본입니다. 레거시 버전에서는 오늘 오후에 수정한 스타일이 아직 메모리에 반영되지 않았을 수 있습니다.

Anthropic은 이 기능이 순차적으로 배포 중이라고 설명하므로, 짐작만 하기보다는 어떤 버전을 사용 중인지 다시 한번 확인해 보는 것이 좋습니다.

프로젝트 메모리는 분리되어 있으며, 대부분의 경우 이것이 진짜 원인입니다

이것은 "방금 말했는데 왜 또 그러지?" 하는 상황을 가장 많이 만드는 경계선입니다. 프로젝트 내의 메모리는 해당 프로젝트에만 머뭅니다. 프로젝트가 아닌 일반 채팅은 자체 공간을 가집니다. 따라서 아무런 오류가 없더라도 스타일이 사라지는 현실적인 시나리오는 세 가지가 있습니다.

일반 채팅에서 스타일을 학습시킨 후 프로젝트 내부에서 작업을 시작했거나, 프로젝트 A에서 학습시키고 프로젝트 B를 열었거나, 팀에서 새 서비스를 위해 새 프로젝트를 시작하여 아무것도 없는 상태에서 시작한 경우입니다.

이 중 어느 것도 버그가 아닙니다. 공식 문서에서는 각 프로젝트를 "집중되고 관련성이 높으며 독립적으로" 유지하기 위해 이러한 격리가 목적이라고 명시하고 있습니다. 하지만 이는 메모리만으로는 여러분이 하는 모든 작업에 걸쳐 하나의 코딩 스타일을 유지할 수 없음을 의미합니다. 무언가가 기준이 되는 단일 원본(canonical copy) 역할을 해야 합니다.

메모리는 사용자가 직접 작성하는 것이 아니라 대화에서 도출됩니다

메모리는 대화를 바탕으로 생성됩니다. 이는 사용자가 직접 작성할 필요가 없다는 점에서 유용하지만, 동시에 저장되는 내용이 실제 스타일 가이드가 아니라 Claude가 요약한 선호도에 불과한 이유이기도 합니다. "탭 사용, 너비 4, 세미콜론 금지, named export만 사용, 테스트 파일 병합 배치"는 명확한 사양입니다. 하지만 메모리가 보관하는 것은 그 사양에 대한 인상에 가깝습니다.

또한 설계상 제외되는 두 가지 카테고리가 있습니다. 시크릿(Incognito) 채팅은 메모리에 기여하지 않습니다. "이 모드가 켜져 있으면 Claude는 대화를 기억하지 않으므로 Claude의 메모리나 대화 기록에 저장되지 않습니다." 그리고 단 한 번의 채팅에서만 언급하고 다시 반복하지 않은 수정 사항은 기억할 가치가 있는 기준을 넘지 못했을 수 있습니다.

다른 사람의 지침이 내 지침을 덮어쓰고 있을 수 있습니다

If you're on a Team or Enterprise plan, there's a layer above you. Organization instructions let "Admins and above on Team and Enterprise plans set custom instructions that Claude follows in every conversation across your organization," and the precedence is stated plainly: "When both are set, organization instructions take precedence. If an individual instruction directly contradicts an organization instruction, Claude favors the organization-level instruction."

여기서 알아두어야 할 점은 노출 범위입니다. "관리자 이상만" 조직 지침을 보거나 편집할 수 있습니다. 따라서 조직 수준에서 설정된 포맷이나 언어 표준이 개인의 선호도보다 우선할 수 있으며, 사용자는 이를 방해하는 텍스트를 볼 수 없습니다. 개인 지침은 "조직 지침이 다루지 않는 모든 사항에 대해 여전히 적용됩니다." 어떤 지침 컨테이너가 우선하는지에 대한 더 넓은 지도는 how to stop Claude forgetting your system prompts에서 확인할 수 있습니다.

수정 사항을 반복해서 말하며 기억해 주기를 바라기. 때로는 효과가 있습니다. 그것이 메모리의 목적이니까요. 하지만 확인 단계가 없는 방식이기 때문에, 3주가 지난 후에도 여전히 제대로 기억하고 있는지 확신하지 못하게 됩니다.

모든 채팅에 전체 스타일 가이드를 붙여넣기. 확실하지만 비용이 많이 드는 방식이며, how to stop re-explaining context to AI에서 설명하는 반복 루프에 빠지게 됩니다.

프로젝트 지식(Project knowledge)에 스타일 가이드 넣기. 직관은 맞았으나 범위가 틀렸습니다. 프로젝트별로 적용되므로 N개의 복사본을 유지 관리해야 하고 결국 서로 달라지게 됩니다. 이 문제의 일반적인 형태는 giving Claude permanent domain knowledge에서 다룹니다.

개인 지침에 "좋은 관행을 따르라"고 작성하기. 실행하기에는 너무 모호합니다. Anthropic이 제안하는 지침 가이드가 해결책입니다. "'전문적으로 행동하라'와 같은 모호한 지침 대신 '격식 있는 영어로 응답하세요. 축약어, 속어, 이모티콘은 사용하지 마세요'와 같이 구체적인 방향을 제시하세요." 코드 스타일도 동일하게 다루어야 합니다.

린터(Linter)가 해야 할 일을 메모리가 해결해 줄 것이라 가정하기. 포맷터가 강제할 수 있는 포맷팅은 프롬프트 수준에서 요청할 일이 아닙니다. 도구가 결정할 수 없는 선택 사항들을 위해 지침을 아껴두세요.

팀 컨벤션과 개인 스타일을 하나로 취급하기. 이 둘은 범위와 보관 위치가 다릅니다. 팀 측면의 문제는 why Claude forgets your house conventions에서 다룹니다.

세 단계로 진행됩니다. 첫 번째는 메모리가 나를 방해하는 대신 나를 위해 일하게 만드는 것입니다. 두 번째는 중요한 부분을 결정론적으로 만드는 것입니다. 세 번째는 복사본을 유지 관리하는 수고를 없애는 것입니다.

메모리 패널을 열고 직접 편집하기. 이 단계는 사람들이 가장 많이 건너뛰는 단계입니다. Settings > Memory로 이동하세요. "메모리 패널은 카테고리별로 그룹화되어 Claude가 사용자에 대해 기억하는 모든 것을 나열합니다. 항목을 선택하면 요약 및 세부 정보를 볼 수 있습니다. 항목을 변경하려면 'Tell Claude what to change or remove' 상자를 사용하세요. 항목을 완전히 삭제하려면 'Delete'를 선택하세요." 실제로 기술적 선호도에 대해 어떤 내용이 들어 있는지 읽어보세요. 잘못된 항목은 수정하고, 지난 3월에 포기한 프로젝트의 항목은 삭제하세요.

대화식으로 추가할 수도 있습니다. Claude에게 기억해 주었으면 하는 내용을 말하면 대화창을 벗어나지 않고도 업데이트됩니다. 레거시 버전의 경우, 이 방식으로 편집하면 "다음 대화에 즉시 적용되므로 일일 종합이 실행될 때까지 기다릴 필요가 없습니다."

타협할 수 없는 규칙은 메모리가 아닌 지침(instructions)에 넣기. 코드 리뷰 코멘트라고 생각되는 모든 것은 개인 지침에 검증 가능한 수준으로 구체적으로 작성해야 합니다. 예: "Functional React components only, named exports, no default exports. Tests colocated as *.test.ts. No semicolons." 메모리는 경향을 학습하지만, 지침은 규칙을 명시합니다. Anthropic의 자체 주의 사항을 기억하세요. "지침 우선순위 지정은 프롬프트 수준의 지침에 의존합니다. 직접적으로 상충되는 지침이 포함된 드문 예외적인 경우 동작이 달라질 수 있습니다. 지침을 테스트하여 예상한 결과가 나오는지 확인하세요."

포맷팅은 포맷터가 담당하게 하기. 들여쓰기, 따옴표, 줄 바꿈 길이는 실행되는 설정 파일의 몫입니다. 지침의 용량은 도구가 결정할 수 없는 아키텍처 형태의 선호도를 위해 아껴두세요.

사양에 단 하나의 보금자리를 제공하기. 이 부분은 메모리도 지침도 해결해 주지 못하는 부분입니다. 메모리는 설계상 프로젝트별로 적용됩니다. 프로젝트 지식은 정의상 프로젝트별로 적용됩니다. 개인 지침은 항상 켜져 있는 짧은 텍스트 블록일 뿐 문서가 아닙니다. 따라서 이유가 첨부된 실제 스타일 사양은 결국 중복되거나 어디에도 남지 않게 됩니다.

이것이 바로 MemoryLake가 해결하는 문제입니다. 도구가 읽을 수 있는 레이어에 영구적인 선호도와 그 이유를 보관하므로, 모든 프로젝트와 모든 어시스턴트가 동일한 버전을 보게 됩니다. 설정은 세 단계로 이루어집니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 연결하는 도구 전체에서 하나의 자격 증명만 사용하면 됩니다.

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

각각 하나의 주장만 담긴 짧은 항목들을 업로드합니다. 규칙이나 메모리 항목 대신 여기에 들어가야 할 내용은 다음과 같습니다.

이유가 첨부된 스타일 선택. "공유 패키지에서 번들러의 트리 쉐이킹이 default export를 놓치기 때문에 named export만 사용합니다." 규칙은 전반부만 명시합니다. 오직 이 이유만이 해당 규칙이 아직 없는 프로젝트에서 제안이 다시 나타나는 것을 방지합니다.

에코시스템 기본값과 다른 컨벤션. 잘 훈련된 모델의 직관이 합리적이지만 여러분의 코드베이스에는 맞지 않는 모든 경우입니다. 이는 새로운 프로젝트를 시작할 때마다 반복해서 수정하게 되는 사항들입니다.

의도적으로 거부한 패턴. 시도했다가 철회한 추상화와 그 이유입니다. 이는 설정 파일이나 커밋 메시지에는 존재하지 않기 때문에, 새로운 세션이 시작될 때마다 다시 제안되곤 합니다.

스택에 특화된 어휘. 여러분이 "서비스", "핸들러", "모듈"이라고 부르는 것들 — 리뷰 코멘트에서는 당연하게 여겨지지만 새로운 에이전트는 알지 못하는 단어들입니다.

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

사용하는 도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 어시스턴트는 API를 통해 동일한 메모리를 읽습니다. 실질적인 효과는 한 번 작성한 스타일 사양을 에디터의 에이전트도 동일하게 읽게 된다는 점입니다.

세 가지 솔직한 한계가 있습니다. MemoryLake는 Claude 메모리 항목이나 지침을 대신 작성해 주지 않습니다. 이는 Anthropic의 영역이며, 도구가 연결되지 않은 채팅을 제어하는 역할을 하므로 여전히 직접 올바르게 설정해야 합니다. MemoryLake는 사용자나 에이전트가 입력한 내용만 보관하므로 2단계는 수동으로 진행됩니다. 그리고 이것은 맥락(context)이지 강제(enforcement)가 아닙니다. 포맷터나 린터가 확인할 수 있는 모든 사항에 대해서는 설정 파일이 가장 확실한 보증 수단입니다.

"진짜 기억하고 있을까?"라는 의문을 직접 눈으로 확인할 수 있게 됩니다. 메모리 패널은 카테고리별로 항목을 나열합니다. 패널을 열고 기술적 선호도를 읽고 잘못된 부분을 수정하세요. 더 이상 추측할 필요가 없습니다.

새로운 프로젝트가 더 이상 맨땅에서 시작되지 않습니다. 프로젝트 메모리는 설계상 격리되어 있으므로, 이에 맞서 싸우는 대신 프로젝트가 읽을 수 있는 곳에 기준이 되는 사양을 보관하는 것이 해결책입니다.

지침이 더 짧고 구체적으로 변합니다. 추론 과정이 다른 곳에 보관되면, 항상 켜져 있는 지침 블록은 검증 가능한 몇 가지 구체적인 규칙으로 되돌아갈 수 있습니다.

에디터와 채팅이 일치하게 됩니다. 브라우저의 Claude와 IDE의 에이전트가 동일한 선호도를 읽게 됩니다. 이 형태는 what persistent memory actually means에서 다룹니다.

팀 표준과 개인 취향이 충돌하지 않게 됩니다. 조직 지침이 개인 지침보다 우선하므로, 개인 레이어는 조직 레이어와 경쟁하는 대신 조직 지침이 다루지 않는 부분을 보완해야 합니다.

먼저 어떤 메모리 버전을 사용 중인지 확인하세요. Settings > Memory는 새로운 버전이고, Settings > Capabilities 아래의 Memory는 24시간마다 요약이 업데이트되는 레거시 버전입니다.

한 달에 한 번 메모리 패널을 확인하세요. 잘못된 항목이 들어갈 수 있으며, 잘못된 항목은 지침과 충돌하기 때문에 아예 없는 것보다 나쁩니다.

검증할 수 있을 만큼 구체적으로 규칙을 작성하세요. "함수형 컴포넌트, named export 사용"은 검증 가능하지만, "현대적인 React 관행을 따르라"는 검증할 수 없습니다.

린터가 강제할 수 있는 일에 메모리를 의존하지 마세요. 포맷팅은 설정 파일에 맡기고, 프롬프트는 판단이 필요한 영역을 처리하도록 하세요.

프로젝트 격리를 예상하고 이에 대비하세요. 한 프로젝트에서 학습된 스타일은 다음 프로젝트에 도달하지 않습니다. 모든 프로젝트의 외부에 기준이 되는 버전을 보관하세요.

시크릿 채팅은 아무것도 기여하지 않는다는 점을 기억하세요. 시크릿 채팅에서 아무리 열심히 설명했더라도 저장되지 않았습니다.

Team 및 Enterprise 요금제에서는 조직 지침 내용을 확인하세요. 조직 지침이 우선하며 관리자 이상만 볼 수 있으므로, 알 수 없는 재정의 현상에는 단순한 이유가 있을 수 있습니다.

규칙 옆에 이유를 함께 저장하세요. 정당한 이유가 포함된 스타일 선택은 새 프로젝트, 새 도구, 새 팀원 사이에서도 살아남습니다. 규칙만으로는 살아남지 못합니다. 이에 대한 일반적인 사례는 why agents ignore the instruction files you wrote에서 다룹니다.

Claude의 메모리는 "기술적 선호도 및 코딩 스타일"을 캡처하는 것으로 문서화되어 있으므로, 기본적으로 이 기능이 작동한다고 가정해야 합니다. 작동하지 않는다면 구체적인 장애물이 있는 것입니다. 보통 다음 네 가지 중 하나입니다. 메모리가 꺼져 있거나 24시간 주기인 레거시 버전을 사용 중이거나, 프로젝트 경계를 넘어 독립된 메모리 공간으로 들어갔거나, 선호도가 규칙으로 명시되지 않고 경향으로 학습되었거나, 눈에 보이지 않는 조직 지침이 개인 지침보다 우선하는 경우입니다.

이 중 세 가지는 약 10분 만에 해결할 수 있습니다. 메모리를 켜고, 메모리 패널을 열어 내용을 수정하고, 타협할 수 없는 사항들을 검증 가능한 구체적인 지침으로 옮기면 됩니다. 네 번째인 프로젝트 격리는 의도된 설계이며, 어떤 설정으로도 끌 수 없습니다.

그렇기 때문에 스타일 사양 자체를 단일 프로젝트나 도구의 외부, 즉 모든 것이 읽을 수 있는 레이어에 한 번만 작성하고 이유를 첨부하여 보관해야 합니다. 그러면 새로운 리포지토리, 새로운 프로젝트, 새로운 에이전트가 빈 도화지와 뻔한 대화 대신 여러분이 이미 설명한 동일한 컨벤션을 가지고 시작할 수 있게 됩니다.