Claude Code의 성능 저하가 느껴진다면, auto memory를 의심해 보자

TL;DR Claude Code의 auto memory는 편리해 보인다.

하지만, CLAUDE.md / 스킬 프롬프트 (skill prompt) / 워크플로우 YAML / docs에 개발 규약을 제대로 배치해 둔 사용자에게는, 리뷰되지 않는 제2의 규약 레이어가 되기 쉽다. 내 환경에서는 단 3개의 memory가,

실제 워크플로우 YAML과 모순됨
스킬 사양과 실행 순서에서 충돌함
폐기된 프로젝트 방침을 계속 긍정함
사소한 수정에도 과도한 설계를 유발함

이라는 상태였다.

내 환경에서는 auto memory를 비활성화하기 전에는 거의 매번 리뷰가 수렴하지 않는 상태였으나, 비활성화한 후 동일한 kaji 워크플로우를 4번 정도 돌려도 해당 증상은 재발하지 않았다. 우선 중단하고 싶다면 공식 docs에 나와 있는 대로

autoMemoryEnabled: false

또는

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

을 사용하면 된다.

서론

opus 4.8이 출시되었네요. 4.7 출시 때보다 성능 향상이 느껴집니다.

다만, 최근에는 Claude Code의 성능 저하에 관한 이야기를 자주 듣게 됩니다.

이번 이야기는 Claude Code의 성능이 저하되었다고 느껴질 때 auto memory를 조금 확인해 보는 것이 어떻겠냐는 내용입니다.

Claude Code에는 auto memory라는 기능이 있다.

대략 말하자면, Claude가 "이것은 다음번 이후에도 기억해 두는 것이 좋겠다"라고 판단한 정보를 프로젝트별 memory directory에 저장하여 다음 세션에서도 읽는 기능이다.

공식 docs에서도 빌드 명령, 디버깅 시의 깨달음, 아키텍처상의 메모, 코드 스타일 선호도, 작업 습관 등을 저장하는 기능으로 설명되어 있다.

최근 Claude Code 주변에서는,

CLAUDE.md를 키우자 - memory에 취향을 기억시키자
에이전트에게 문맥 (context)을 축적시키자

와 같은 이야기가 많다.

반면, "최근 Claude Code의 동작이 나빠졌다", "Codex로 이관했다"라는 이야기가 보이기 시작했다.

물론 성능 저하를 느꼈을 때의 원인은 하나가 아니다. 모델 측, CLI 측, 컨텍스트 (context) 양, 권한 확인, auto-compact, 프롬프트 설계 등 의심해야 할 곳은 여러 군데가 있다.

이 기사에서는 그중에서도 auto memory가 결과물의 질을 악화시키는 케이스를 다룬다.

이 auto memory의 방향성 자체는 이해한다.

AI 주도 개발 (AI-driven development)에서는 매번 처음부터 설명하는 것이 힘들다. 에이전트가 같은 실수를 반복하지 않도록 과거의 교훈으로서 기억해 준다면 실제로 도움이 되는 장면이 많다.

다만, 실운용에서는 반대로 개발 경험을 악화시키는 장면이 있었다.

이 기사는,

memory는 "편리한 기억"이 아니라, 경우에 따라서는 "리뷰되지 않는 영구 규칙"이 되어 Claude Code의 성능 저하로 보이는 증상을 일으킬 수 있다

라는 이야기다.

전제: 나의 사용 방식

kaji라는 자작 AI 주도 개발 워크플로우 실행 도구를 사용하여 개발하고 있다. kaji 자신도 kaji를 사용하여 개발하고 있다.

이 kaji 리포지토리에서는 다음과 같은 방법으로 개발 규약을 명시적으로 작성하고 있다.

CLAUDE.md
.claude/skills/*/SKILL.md
.kaji/wf/*.yaml

docs / 설계 템플릿
Issue / PR 워크플로우

즉 "Claude에게 전부 맡긴다"가 아니라,

에이전트가 지켜야 할 규칙은 Claude가 확인할 수 있는 곳에 둔다

라는 운용을 하고 있다.

그 상태에서 최근 다음과 같은 증상이 나타나고 있었다.

리뷰 → 수정 → 리뷰의 순환이 좀처럼 수렴하지 않음
사소한 변경임에도 설계가 이상하리만큼 무거움
수정했을 터인 논점이 다른 형태로 부활함
워크플로우가 ABORT되기 쉬움

특히 까다로웠던 점은 이 증상이 어느 날 갑자기 나타난 것이 아니라 서서히 늘어갔다는 것이다.

auto memory를 비활성화하기 직전에는 거의 매번 리뷰가 수렴하지 않는 문제가 발생하고 있었다.

체감상으로는 "Claude Code의 성능이 떨어졌다", "이전보다 판단이 둔해졌다"에 가깝다.

처음에는 워크플로우 (Workflow)나 스킬 (Skill) 설계가 잘못된 것인가 생각했다. 최근 자주 들리는 Claude의 성능 저하도 의심했다.

그러고 보니 최근 Claude가 교훈을 memory에 저장하겠다고 말하기 시작했다는 점이 떠올랐다. 어쩌면 memory와 프로젝트 (PJ) 규약이 충돌하고 있는 것일지도 모른다는 생각에 조사해 보니, 원인의 일부로 Claude Code의 auto memory가 관계되어 있을 것 같았다.

조사한 memory는 단 3건

내 프로젝트 memory는 이 3건뿐이었다.

~/.claude/projects/-home-aki-dev-kaji--bare/memory/
├── user_pm_tool_background.md
├── feedback_issue_work_logging.md
...

3건이라면 뭐, 괜찮아 보였다.

하지만, 이 3건 모두에 어떠한 모순이 있었다.

문제 1: 워크플로우 YAML과 모순되는 memory

가장 심각했던 것이 feedback_no_skip_design.md였다.

내용을 요약하자면 다음과 같다.

경미한 변경이라 할지라도, kaji의 스킬 실행 절차를 돌릴 때는

/issue-design

→

/issue-review-design

을 반드시 거친다.

harness에서 워크플로우를 실행한 경우에는 변경 규모와 관계없이 반드시 설계 단계가 실시되는 설계이기 때문이다.

언뜻 보면 타당해 보인다.

하지만 실제 워크플로우 YAML을 보면 다르다.

워크플로우	설계 단계
`feature-development.yaml`	있음
`feature-development-light.yaml`	있음
`full-cycle.yaml`	있음
`docs-maintenance.yaml`	없음
`docs-maintenance-local.yaml`	없음
`implement-to-pr.yaml`	없음

즉, memory의 "반드시 설계 단계가 실시된다"는 사실이 아니다.

docs-only나 implement-only 경로에서는 설계 단계가 실행되지 않는다.

그럼에도 불구하고 memory는 직면한 문제와 관련하여,

종류나 크기를 불문하고

/issue-design

을 실행한다

라는 규칙을 영구적으로 저장하고 있었다.

이것은 위험하다.

리포지토리의 정규 워크플로우 YAML보다, 뒤에서 저장된 memory가 더 강력하게 작용할 가능성이 있다.

문제 2: 스킬 사양과 실행 순서가 충돌하는 memory

다음은 feedback_issue_work_logging.md이다.

이것은 "Issue 상에 작업 로그를 제대로 남기자"라는 memory이다.

목적 자체는 나쁘지 않다.

문제는 How to apply 부분이다.

verdict (규정된 포맷으로 작업 결과와 다음 단계가 어디인지 기재하는 부분) 출력보다 먼저 Issue 코멘트 게시를 완료한다.

반면, 스킬 사양 측에는 다음과 같은 규약이 있었다.

verdict는 stdout에 그대로 출력할 것. Issue 코멘트나 Issue 본문 업데이트와는 별개로, 최종적인 verdict 블록은 stdout에 남긴다.

스킬 사양은 "Issue 코멘트"와 "stdout verdict"를 별개의 것으로 취급하고 있다.

memory는 "Issue 코멘트 → verdict"라는 직렬 순서를 강제하고 있다.

이 두 가지가 동일한 세션에 로드된다.

그러면 Claude는 무엇을 하는가?

대체로 양쪽을 모두 만족시키려 한다.

결과적으로 불필요한 절차가 늘어난다.

문맥량 (Context amount)도 사용한다.

워크플로우 반복 횟수도 소비한다.

사소하지만, 쌓이면 영향이 크다.

문제 3: 폐기된 방침을 계속 긍정하는 오래된 memory

user_pm_tool_background.md에는 GitLab / GitHub Issues의 비교에 관한 memory가 남아 있었다.

대략 말하자면,

GitHub Issues는 가볍고 기능이 얇다는 뉘앙스를 전달한다
GitLab의 Epic / Iteration / Weight / Time tracking을 overkill로 취급하지 않는다
GitLab 채택은 익숙한 모델로의 회귀로서 평가하는 것이 자연스럽다

라는 내용이다.

이것도 단독으로는 이상하지 않다.

하지만 kaji에서는 이미 GitLab Forge를 완전히 제거한 상태다.

CLAUDE.md에도 현재의 방침으로 다음과 같이 적혀 있다.

Forge: GitHub 단독

즉, memory에는 현재 채택하고 있는 GitHub를 다소 부정적으로 평가하고, 이미 제거한 GitLab을 긍정적으로 평가하는 상태로 남아 있었다.

과거의 판단이 '과거의 판단'이라는 표시도 없이 계속 남아 있는 것이다.

이 또한 다루기 까다로운 성질이다.

문제 4: memory 내부에서도 모순이 발생한다

외부의 프로젝트 상태와 모순되는 것뿐만이 아니다.

memory끼리, 혹은 memory 자체 내부에서도 흔들리고 있었다.

예를 들어 frontmatter의 형식.

# 19일 전의 memory
type: user
# 18일 전의 memory
...

3건 중 1건만 형식이 다르다.

게다가, feedback_issue_work_logging.md에서는 다음과 같이 되어 있었다.

Why: 나중에 Issue만 읽고 전체 플로우를 재구축할 수 있도록 한다
How: verdict 출력보다 먼저 Issue 코멘트를 게시한다

하지만 'Issue만으로 전체 플로우를 재구축'하고 싶다면, verdict 자체를 Issue에 남기지 않으면 목적을 달성할 수 없다.

즉, 목적과 수단도 약간 어긋나 있다.

memory는 '장기적으로 유효한 규칙' 같은 얼굴을 하고 있지만, 적혀 있는 내용은 평범하게 흔들린다.

그리고 그 흔들림은 Git diff나 PR 리뷰에 나타나지 않는다.

왜 이런 memory가 만들어지는가

Claude Code의 실행 파일을 strings로 확인해 보니, memory extraction subagent에 관한 프롬프트(prompt) 파편을 확인할 수 있었다.

중요한 부분은 이 근처다.

You are now acting as the memory extraction subagent.
Analyze the most recent ~N messages above and use them to update
your persistent memory systems.
...

strings로 추출한 파편이므로, 이것만으로 전체 구현을 단정 짓는 것은 위험하다.

다만, 적어도 v2.1.152 실행 파일 내부에는 최근 메시지로부터 memory를 추출하는 subagent용 프롬프트가 포함되어 있었다.

이 설계라면, memory의 작성자는 리포지토리의 진실을 확인하러 가지 않는다.

직전의 대화만을 본다.

소스 파일을 grep 하지 않는다.

git도 보지 않는다.

사실 확인을 하지 않는다.

이 조건에서는 임시방편적인 규칙이 생겨나도 이상할 것이 없다.

memory는 '꾸지람을 들은 순간'을 저장하기 쉽다

실제로 남아 있던 feedback memory는 둘 다 사용자가 강하게 지적한 문맥에서 유래했다.

사소하더라도 Issue에 작업 로그를 남겨야 한다
사소하더라도 설계를 생략해서는 안 된다

이것들은 그 순간만 보면 옳다.

하지만 memory에 들어가면 '문맥이 있는 지적'이 아니라 '다음부터도 적용되는 규칙'이 된다.

여기서 선택 편향(selection bias)이 발생한다.

사용자가 꾸짖은 순간은 문장량이 많다.

감정도 실린다.

'다음부터 주의해 달라'는 형태가 되기 쉽다.

그래서 memory에 남기 쉽다.

반대로, Claude가 적절하게 판단하여 사용자가 묵인한 성공 사례는 memory에 잘 남지 않는다.

결과적으로 memory는 다음과 같이 되기 쉽다.

하지 말아야 할 리스트
생략해서는 안 될 리스트
판단해서는 안 될 리스트

이는 에이전트의 판단을 똑똑하게 만들기보다, 점점 위축시킨다.

실질적 피해: 작은 수정이 거대한 설계로 변한다

가장 알기 쉬운 실질적 피해는 수정 규모와 설계 비용의 균형이 깨지는 것이었다.

본래라면 작은 버그 수정에는 작은 설계만으로도 충분한 경우가 많다.

변경점, 영향 범위, 실패 시의 처리, 테스트 방침이 확인되면 된다.

하지만 memory에 '종류나 크기에 상관없이 설계를 생략하지 않는다'라는 규칙이 있으면, Claude는 안전한 쪽으로 치우치기 쉽다.

결과적으로 작은 수정에도 기능 개발에 맞먹는 설계 문서와 설계 리뷰를 적용하기 시작한다.

내 환경에서는 실질적으로 70줄 정도의 코드 수정에 대해 설계 문서가 502줄까지 불어난 케이스가 있었다.

항목	값
본체 코드 변경	약 70행
...
물론, 설계가 필요한 버그 수정도 있다.

다만, 이 케이스는 사양 전체를 새로 만드는 수준의 변경이 아니라, 기존 로직에 작은 분기(branch)를 추가하는 종류의 수정이었다.

그럼에도 설계 리뷰에서는 수정 그 자체보다, 설계 문서 내의 근거 설정이나 표현의 정합성(consistency)에 대해 여러 차례 논의가 이루어졌다.

적어도 이 수정 규모에 비해서는 과도했다.

게다가, 기본적인 입력 검증(input validation)이 누락되었다

더 큰 문제는 여기다.

502행의 설계가 있었고, 실패 핸들링(failure handling) 섹션도 있었다.

그럼에도 PR 생성 후의 리뷰에서 기본적인 입력 검증 누락이 지적되었다.

이는 CLI 구현에서 상당히 기본적인 확인 사항이다.

왜 누락되었을까?

내 견해는 이렇다.

memory "종류나 크기에 상관없이 설계"
↓
70행의 수정에 502행의 설계
...

memory가 직접 "입력 검증을 누락해라"라고 말한 것은 아니다.

하지만 작성해야 할 양과 시간을 왜곡시켰다.

작성해야 할 양과 시간이 왜곡되면 주의력이 떨어진다.

주의력이 떨어지면 평범한 부분에서 실수가 발생한다.

이 점이 가장 문제라고 느끼고 있다.

워크플로우 ABORT와의 상성이 나쁘다

kaji의 워크플로우에는 리뷰 / 수정 루프에 상한이 있다.

max_iterations: 3
on_exhaust: ABORT

이 설계 자체는 일반적이다.

무한히 리뷰 루프를 돌리지 않기 위한 안전장치다.

하지만 memory가 "경미하더라도 설계", "verdict(판정) 전에 코멘트", "판단하지 마라" 등을 늘려가면, 1 사이클(cycle)당 처리량이 무거워진다.

게다가 리뷰 역할과 작성자 모두 동일한 Claude이기 때문에, 과도한 설계를 과도하다고 멈추기가 어렵다.

결과적으로,

사소한 수정
↓
memory에 의해 기능 개발 수준의 설계
...

이라는 흐름이 발생한다.

이는 워크플로우의 버그라기보다, 리뷰되지 않는 제약 계층(constraint layer)이 워크플로우의 정지 조건을 잡아먹고 있는 상태에 가깝다.

무효화 후의 관찰

auto memory를 무효화한 후, 동일한 kaji 워크플로우를 4회 정도 돌려보았다.

그 범위 내에서는 이전처럼 리뷰가 수렴하지 않는 현상은 발생하지 않았다.

무효화 전에는 이 증상이 점진적으로 증가하여, 마지막에는 거의 매번 발생했었다.

그로부터 무효화 후 4회 동안은 재발하지 않았으므로, 적어도 체감상의 차이는 상당히 크다.

물론 4회 정도이므로 통계적인 증명은 아니다. Issue의 내용이나 수정 규모도 매번 다르다.

다만, 적어도 실운용 측면에서는 auto memory를 끈 이후에 "리뷰 → 수정 → 리뷰"가 무한에 가까운 형태로 늘어나는 증상은 멈췄다.

이는 본 기사의 가설과 일치한다.

memory가 직접 버그를 만든다기보다, 리뷰되지 않는 규칙이 불필요한 설계, 불필요한 절차, 불필요한 보수적 판단을 늘려 워크플로우의 반복 횟수를 소비하고 있었던 것이다.

그 제약 계층을 제거함으로써 워크플로우 본래의 정지 조건으로 돌아갔다고 보는 것이 자연스럽다.

공식 docs와 대조하면, 문제는 "편리함의 이면"에 있다

공식 docs에서는 auto memory를 Claude Code v2.1.59 이후부터 사용할 수 있는 기능으로 설명하고 있다.

또한 다음과 같은 성질도 명시되어 있다.

auto memory는 기본적으로 활성화되어 있음
프로젝트별 memory directory에 저장됨
리포지토리 내의 worktree / subdirectory 간에 동일한 memory directory를 공유함
/memory로 확인 및 전환 가능
autoMemoryEnabled: false 또는 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1로 무효화 가능

이는 편리함을 추구하는 사람에게는 편리할 것이라 생각한다.

특히 아직 리포지토리 측에 규약(convention)이 정비되지 않은 프로젝트에서는, Claude가 알아서 "이 프로젝트의 습관"을 파악해 주는 것이 도움이 될 수도 있다.

하지만 규약을 리포지토리에 두는 사람에게는 이야기가 달라진다.

CLAUDE.md나 스킬 프롬프트(skill prompt)는 Git으로 리뷰할 수 있다.

워크플로우 YAML도 리뷰할 수 있다.

docs도 리뷰할 수 있다.

memory는 다르다.

리뷰되지 않는다.

PR에 나타나지 않는다.

오래되어도 알아차리기 어렵다.

그리고 세션의 시작부터 읽힌다.

이것이 위험하다.

"memory 문제"는 적은 것인가

내가 조사한 바로는, memory (메모리)를 옹호하는 이야기는 상당히 많다.

반면, 문제점을 지적하는 이야기는 적다.

하지만 아예 없는 것은 아니다.

영어권 Reddit에서는 auto memory (자동 메모리)가 동작의 어긋남이나 사용량에 영향을 미치는 것이 아니냐는 문제 제기나, memory (메모리)가 AI를 둔하게 만든다는 취지의 게시물도 나오기 시작했다.

즉, 본 기사는 "아무도 말하지 않은 새로운 발견"으로서가 아니라, 나타나기 시작한 문제 제기들을 리포지토리 규약, 워크플로우 (Workflow) YAML, 스킬 (Skill) 사양과의 모순이라는 관점에서 정리하는 위치를 갖는다.

나의 결론

Claude Code의 memory (메모리)는 다음과 같은 사람들에게는 편리하다고 생각한다.

프로젝트 규약이 아직 미비하다
매번 같은 선호도를 설명하는 것이 번거롭다
memory (메모리)를 정기적으로 정리할 수 있다
약간의 동작 어긋남보다 속도를 우선시하고 싶다

반면, 다음과 같은 사람은 주의하는 것이 좋다.

CLAUDE.md를 제대로 운용하고 있다
스킬 프롬프트 (Skill Prompt)를 Git으로 관리하고 있다
워크플로우 (Workflow) YAML로 에이전트 (Agent)의 움직임을 제어하고 있다
Issue / PR 상의 추적 용이성을 중시한다
리뷰되지 않는 규칙이 늘어나는 것을 싫어한다

나는 후자 쪽이었다.

그래서 현시점의 결론은 이렇다.

리포지토리 (Repository)에 개발 규약을 두고 있다면, auto memory (자동 메모리)는 원칙적으로 무효화해도 좋다.

오래 지속될 규칙은 Git으로 리뷰할 수 있는 곳에 두어야 한다.

대책 요약

auto memory (자동 메모리) 무효화 방법

사용자 설정 또는 프로젝트 설정에 다음을 넣는다.

{
"autoMemoryEnabled": false
}

또는 환경 변수:

export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

일시적으로 전환하는 경우에는, Claude Code 세션에서 /memory를 열어 auto memory (자동 메모리) 전환 기능을 사용한다.

이 기사에서 다루지 않은 것

오해를 살 수 있으므로 명시해 둔다.

Claude Code가 나쁘다는 이야기가 아니다.

Claude의 모델이 나쁘다는 이야기도 아니다.

또한, Claude Code의 성능 저하로 보이는 현상의 원인이 모두 auto memory (자동 메모리) 때문이라고 말하고 싶은 것도 아니다.

이 기사에서 문제 삼고 있는 것은,

리뷰되지 않는 memory (메모리) 계층이, 리뷰되는 리포지토리 측의 규약과 동일한 강도로 작용해 버리는 설계이다.

다만, 실제로 memory file (메모리 파일)이 생성되고, 그곳에 프로젝트 상태와 모순되는 규칙이 남아 워크플로 (workflow)에 악영향을 미쳤다는 관측은 내 수중에 있다.

환경에 따라 아웃풋 (output)의 질이 저하된 것이 아닐까 하는 것이 이 글의 주장이다.

요약

memory (메모리)는 정보가 사라지지 않고 축적되어 가기 때문에, 시간이 경과하여 축적된 정보량이 늘어나면 memory 내부나 문서류와 모순을 일으키기 쉽다.

모델의 판단 기준에 모순이 있으면 아웃풋의 질이 떨어지기 쉽다.

실제로 일어나는 일은, 리뷰 루프 (review loop)가 길어진다.

워크플로가 여러 번 루프를 돈다.

내 환경에서는 auto memory (자동 메모리)를 비활성화하기 직전에는 거의 매번 리뷰가 수렴하지 않는 상태였으나, 비활성화한 후 동일한 워크플로를 몇 번 돌려도 해당 증상은 재발하지 않았다.

그리고 까다로운 점은, 사용자가 그 원인을 찾아내기 어렵다는 것이다.

CLAUDE.md라면 차이점 (diff)에 나타난다.

스킬 프롬프트 (skill prompt)라면 PR (Pull Request)에서 리뷰할 수 있다.

워크플로 YAML이라면 변경 이력을 추적할 수 있다.

memory는 대개 그 외부에 있다.

그래서 AI 주도 개발을 진지하게 하는 사람일수록, 나는 이렇게 말하고 싶다.

에이전트 (agent)에게 기억을 갖게 하기 전에, 그 기억을 리뷰할 수 있을지 먼저 생각하는 편이 좋다.

참고로 opus 4.8을 사용하기 시작하면서 리뷰 NG(거절) 자체가 줄어들었다 (Opus 4.8 고마워!)

부록: 수중의 조사 메모

이 글의 근거가 된 증거는 다음과 같은 관점에서 남겨두었다.

유효했던 memory 3건의 스냅샷 (snapshot)
memory vs 워크플로 YAML의 모순
memory vs 스킬 사양의 충돌
memory 내부 및 상호 모순
구체 사례: #199 설계 리뷰의 루프
리뷰 지적 누락
Claude Code 실행 파일 v2.1.152의 strings 분석

특히 재현 명령어로써는 다음을 사용했다.

claude --version
which claude
strings $(readlink -f $(which claude)) | grep "auto memory"
...

반복하겠지만, 실행 파일 분석은 단편적인 보조 증거일 뿐이다.

주요 증거는 실제로 저장된 memory와 리포지토리 측 규약이 모순되었다는 점이다.

Claude Code의 성능 저하가 느껴진다면, auto memory를 의심해 보자

요약

핵심 포인트

Claude Code의 성능 저하가 느껴진다면, auto memory를 의심해 보자

서론

전제: 나의 사용 방식

조사한 memory는 단 3건

문제 1: 워크플로우 YAML과 모순되는 memory

문제 2: 스킬 사양과 실행 순서가 충돌하는 memory

문제 3: 폐기된 방침을 계속 긍정하는 오래된 memory

문제 4: memory 내부에서도 모순이 발생한다

왜 이런 memory가 만들어지는가

memory는 '꾸지람을 들은 순간'을 저장하기 쉽다

실질적 피해: 작은 수정이 거대한 설계로 변한다

게다가, 기본적인 입력 검증(input validation)이 누락되었다

워크플로우 ABORT와의 상성이 나쁘다

무효화 후의 관찰

공식 docs와 대조하면, 문제는 "편리함의 이면"에 있다

"memory 문제"는 적은 것인가

나의 결론

추천 운용 방식

1. auto memory (자동 메모리)를 중단한다

2. 기존 memory (메모리)를 스냅샷으로 찍은 후 읽는다

3. 남겨야 할 내용만 리포지토리 측으로 옮긴다

4. 오래된 memory (메모리)를 삭제한다

대책 요약

이 기사에서 다루지 않은 것

요약

부록: 수중의 조사 메모

Discussion

댓글