memory 질문

Question

claude.md에 구현전에 고려해야할 사항을 적어두었습니다. ex) 1. 테스트 환경 1-1. DB 접속 방법 1-2. 로그 확인 방법 라이브 서비스 환경 2-1. 로컬에서 DB 접속 불가 이런식으로 각 환경에 맞게 디버깅하는 방식을 적어두었는데 처음에는 claude.md의 내용을 기억하고 테스트 환경의 DB에 접속하는 등 잘 이행을 하다가 context가 길어지면 라이브 서비스의 DB를 로컬에서 접근 시도하려는등 memory에 문제가 있는것 같습니다. 이런 경우는 어떻게 해결해야할까요?

americasnail · Answer

안녕하세요. 김다현님, 좋은 질문을 해주셨습니다 :) 말씀해주신 상황은 memory가 부족해서 생긴 문제라기보다는, Context Harness가 길어지면서 현재 작업 대상 환경이 흐려지는 문제 라고 볼 수 있습니다 따라서, CLAUDE.md 테스트 환경, 라이브 환경, DB 접속 방법, 로그 확인 방법을 잘 적어두셨더라도, context가 길어지면 Claude가 현재 작업이 테스트 환경 기준인지, 라이브 환경 기준인지 를 헷갈릴 수 있습니다. 예시를 들어보면, 테스트 환경 - 로컬에서 DB 접속 가능 - 테스트 로그 확인 가능 라이브 환경 - 로컬에서 DB 직접 접속 불가 - 별도 로그 확인 방식 필요 처음에는 Claude가 CLAUDE.md를 잘 참고해서 테스트 DB에 접속할 수도 있지만, 그런데 대화가 길어지고, 여러 작업이 섞이고, context가 압축되거나 요약되면 Claude가 “현재 기준이 테스트인지 라이브인지”를 놓칠 수 있기 때문에 라이브 서비스인데도 테스트 환경처럼 로컬 DB 접속을 시도하는 결과가 나올 수 있습니다. 그래서, 여러 원인이 있습니다 첫 번째, context window는 제한된 자원입니다. Claude가 모든 정보를 항상 같은 중요도로 기억한다고 보면 안 됩니다. CLAUDE.md에 정보가 있어도, 현재 작업에서 어떤 환경을 기준으로 해야 하는지 명확히 고정하지 않으면 context 안에서 환경 정보가 섞일 수 있습니다. 두 번째는 CLAUDE.md 는 정보 저장소이지만, 실행 보장 장치가 아니기 때문에, CLAUDE.md에 “라이브에서는 로컬 DB 접속 불가”라고 적어두는 것은 좋은 방향입니다. 하지만 그것만으로 Claude가 매번 해당 규칙을 반드시 적용한다고 보장되지는 않습니다. Claude에게는 작업 전에 “현재 target environment가 무엇인지”를 먼저 확정하게 해야 합니다. 마지막으로는 context가 길어지면 요약 과정에서 세부 조건이 약해질 수 있습니다. Claude Code는 긴 세션에서 context를 관리하거나 요약하는 방식으로 작업을 이어갑니다. 이때 “테스트 환경에서는 가능하지만 라이브 환경에서는 불가” 같은 세밀한 조건이 약해질 수 있습니다. 그래서 환경별 규칙은 memory에 기대기보다, 작업 시작 시 다시 고정하는 것이 좋습니다. 그래서 해결방안으로 추천드리는 방식은 CLAUDE.md에 모든 정보를 길게 넣는 것보다, 환경별로 문서를 나누고 작업 시작 시 target environment를 고정하는 것입니다. 예를 들면 이렇게 나눌 수 있습니다. CLAUDE.md docs/env/test.md docs/env/staging.md docs/env/production.md CLAUDE.md에는 전체 환경 정보를 길게 넣기보다, 어떤 환경 문서를 읽어야 하는지만 적습니다. # Environment Profiles Before debugging or modifying code, always identify the target environment. Target environment must be one of: - test - staging - production For test environment, read: docs/env/ test.md For production environment, read: docs/env/ production.md Do not proceed until the target environment is clear. 그리고 각 환경 파일에는 해당 환경의 규칙만 적습니다. 예를 들어 docs/env/production.md에는 이렇게 둘 수 있습니다. # Production Environment Rules - Do not connect to the production DB from local. - Do not run destructive SQL commands. - Use production log viewer for debugging. - Before modifying code, summarize the production constraints. - Before finishing, provide the production-safe verification plan. 추가적으로 프롬프트에서도 target environment를 명시하는 것이 좋습니다. 작업을 요청할 때도 이렇게 시작하는 것이 좋습니다. Target environment: production Read CLAUDE.md first. Then read docs/env/production.md. Use only the production environment rules. Do not use test DB access rules. Do not attempt local DB connection for production. Before debugging, summarize: 1. Target environment 2. DB access rule 3. Log checking method 4. Forbidden actions 5. Verification plan Do not modify code until this summary is complete. 이렇게 하면 Claude가 현재 작업 기준을 먼저 고정하고 시작하게 됩니다. 만약 더 강제하고 싶으시다면, Hook을 사용하는 것이 좋습니다 permission / deny는 특정 명령어 실행이나 위험한 파일 접근을 막을 때 유용한 도구입니다. 하지만 “테스트 환경과 라이브 환경을 헷갈리지 않게 하는 것”은 단순 permission 문제라기보다 작업 절차 문제입니다. 그래서 더 강제하고 싶다면 Hook으로 막는 것이 좋습니다. 예를 들면, production 작업인데 로컬 DB 접속 명령어가 나오면 차단하는 식입니다. production 환경 → local DB 접속 명령 차단 → destructive SQL 차단 → 외부 production API 직접 호출 차단 즉 역할을 나누면 이렇게 볼 수 있습니다. CLAUDE.md → 전체 작업 규칙과 환경 문서 위치 docs/env/test.md → 테스트 환경 전용 규칙 docs/env/production.md → 라이브 환경 전용 규칙 Prompt → 이번 작업의 target environment 지정 Hook → 금지된 명령어 실행 차단 Verification → 환경별 검증 명령어 분리 따라서, 이 문제는 memory 하나로 해결하려고 하기보다, 현재 작업 환경을 먼저 고정하는 Context Harness 컨텍스트 하네스로 다루는 것이 좋습니다. 즉, Claude가 모든 환경 정보를 계속 기억하게 만드는 것이 아니라, 매 작업마다 “지금은 어떤 환경 기준으로 작업하는가”를 기준으로 만드는 것 이 더 안정적인 방식이라고 할 수 있습니다 감사합니다 좋은 하루 되세요!