memory 질문

안녕하세요. 김다현님,좋은 질문을 해주셨습니다 :)말씀해주신 상황은 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.mddocs/env/test.mddocs/env/staging.mddocs/env/production.mdCLAUDE.md에는 전체 환경 정보를 길게 넣기보다, 어떤 환경 문서를 읽어야 하는지만 적습니다.# Environment ProfilesBefore debugging or modifying code, always identify the target environment.Target environment must be one of:- test- staging- productionFor test environment, read:docs/env/test.mdFor production environment, read:docs/env/production.mdDo 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: productionRead 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 environment2. DB access rule3. Log checking method4. Forbidden actions5. Verification planDo 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가 모든 환경 정보를 계속 기억하게 만드는 것이 아니라, 매 작업마다 “지금은 어떤 환경 기준으로 작업하는가”를 기준으로 만드는 것이 더 안정적인 방식이라고 할 수 있습니다 감사합니다 좋은 하루 되세요!

Design a Toast Notification System 미션 관련 질문드립니다.

안녕하세요 유대상님,좋은 의견 정말 감사합니다.검토후에 추후 반영하겠습니다 :)감사합니다 ☺️

코드 구현을 파이썬으로 하라고 명시했나요?

안녕하세요 이용훈님,좋은 질문입니다.맞습니다. MD 파일 자체에 “반드시 Python으로 구현하라”는 조건이 없다면, Claude Code가 꼭 Python을 선택해야 하는 것은 아닙니다.Python은 이 과정을 보여주기에 비교적 코드가 짧고, 테스트 작성이 쉽고, 실습 환경 구성이 단순해서 선택한 것입니다.실제로는 JavaScript/TypeScript, Java, Kotlin, Go 등 다른 언어로도 같은 방식으로 진행할 수 있습니다.만약 특정 언어로 구현하고 싶다면 문제 MD 파일이나 프롬프트에 다음처럼 명시하면 됩니다.Use TypeScript for this implementation. Do not use Python.좋은 질문 감사합니다. 이 부분은 추후에 실습 자료에도 “언어 선택은 문제 MD 또는 프롬프트에서 명시한다”는 설명을 보강해두겠습니다.좋은 하루 되세요!

강의자료가 누락됐어요

안녕하세요 착한가지가지님, 누락 확인되어 현재 반영중에 있습니다 감사합니다 ☺️

섹션5 수업노트와 실습자료 문의

안녕하세요 이선희님,질문 감사합니다.섹션 5 첫번째 강의에서 영상 하단의 강의 노트를 통해 보실 수 있습니다 🙂감사합니다. 좋은 하루 되세요!

claude.md 질문

안녕하세요 김다현님,좋은 질문을 해주셨습니다.결론부터 말씀드리면, 이 경우는 permission / deny만으로 해결할 문제라기보다는 Context Harness와 작업 절차 설계 문제에 더 가깝습니다.permission / deny는 보통 이런 것들을 막을 때 적합합니다.특정 명령어 실행특정 파일 수정상위 폴더 접근.env 접근production API 호출위험한 삭제 명령반면 질문해주신 상황은 위험한 행동을 막는 문제라기보다는, Claude가 작업 전에 반드시 어떤 서버 기준을 읽고 적용하게 만들 것인가에 가깝다고 볼 수 있습니다. CLAUDE.md에 서버별 정보를 적어두는 것과, Claude가 매번 그 내용을 자동으로 참고해서 작업하는 것은 조금 다릅니다.특히 서버별 환경이 중요한 작업이라면, CLAUDE.md에 정보를 적어두는 것에서 끝내기보다 Claude가 작업 전에 반드시 target server를 확인하고, 해당 서버 섹션을 읽고, 그 기준으로 계획을 세우도록 흐름을 만들어주는 것이 좋습니다. 예를 들어, CLAUDE.md 맨 위에 이런 규칙을 둘 수 있습니다.Before modifying any code, always identify the target patch server. If the target server is provided, read the matching server profile in CLAUDE.md first. Before editing code, summarize: 1. Target server 2. Server-specific constraints 3. Allowed commands 4. Verification command그리고 아래와 같은 프롬프트에서도 target server를 명시하는 것이 좋습니다.Target server: patch-server-a Read CLAUDE.md first. Use the patch-server-a section as the source of truth. Summarize the server constraints before editing code. Do not modify files until the plan includes the target server and verification command.만약 이 절차를 더 강하게 고정하고 싶다면, server-patch-harness 같은 Skill로 만드는 것도 좋습니다.예를 들어 서버별 작업을 할 때 항상 아래 순서로 진행하게 만드는 방식입니다.target server 확인CLAUDE.md의 해당 서버 섹션 읽기서버별 제약 요약수정 계획 작성검증 명령어 확인그 다음 코드 수정더 강제하고 싶다면 Hook을 사용할 수도 있습니다. 예를 들어, target server가 정해지지 않은 상태에서는 Edit이나 Write를 막는 식입니다. 정리하면 이렇게 보시면 됩니다.CLAUDE.md → 서버별 정보 저장 Prompt → 이번 작업의 target server 지정 Skill → 서버별 작업 절차 고정 Hook → target server 없이 수정하지 못하게 차단 Permission / deny → 위험한 행동 제한그래서 이 경우에는 permission / deny 로 해결하시기보다는,CLAUDE.md + 명시적인 target server 프롬프트 + 필요하면 Skill 또는 Hook이렇게 구성하는 것이 더 안정적이기 때문에 권장드리는 방법입니다. 즉, 서버별 정보는 CLAUDE.md에 두되, 그 정보를 반드시 읽고 적용하는 절차는 Skill이나 Hook으로 하네스 엔지니어링을 진행하는 방향이 더 적합합니다.감사합니다. 좋은 하루 되세요 🙂

섹션1의 자료는 따로 없나요?

안녕하세요.강의자료의 노션 맨 위의 섹션에 링크로 첨부해두었습니다 🙂감사합니다.

37번 강의가 잘못된거 같습니다.

안녕하세요! 가나다님, 잘못 설정이 되어있어서 조치를 하였습니다.불편을 드려 죄송한 말씀 드리며, 좋은 주말 되시길 바랍니다 🙂감사합니다.

섹션 1 강의자료 없나요

안녕하세요. DAE-HEE LEE님, 강의자료의 노션 맨 위의 섹션에 링크로 첨부해두었습니다 🙂감사합니다.

강의자료 오류

반디집을 통해 다시 압축해서 강의자료에 업로드 하였습니다. 다운로드 확인 부탁드립니다.이상 있으시면 언제든지 다시 남겨주세요 감사합니다.