결제 화면의 버튼 간격을 고치던 세션이 있었습니다. Claude는 이미 컴포넌트 구조와 디자인 토큰, 모바일 화면의 깨지는 지점을 읽었고 CSS 두 파일을 수정했습니다. 여기까진 좋았습니다. 그런데 대화 중간에 “결제 기록에도 새 상태가 필요하다”는 요청이 붙었습니다. Claude는 앞서 읽은 UI 문맥을 끌고 데이터베이스 변경안을 만들기 시작했습니다. 새 열의 기본값과 기존 행의 백필 순서는 빠졌고, CSS 검증도 끝나지 않은 채 수정 파일만 늘어났습니다.

핵심 컨텍스트가 많이 찼다는 이유만으로 새 대화를 시작할 필요는 없습니다. 목표가 그대로라면 `/context`로 무엇이 자리를 차지하는지 확인하고, 보존할 내용을 지정한 `/compact`로 이어 가면 됩니다. 반대로 UI 수정에서 DB 마이그레이션처럼 목표와 위험이 바뀌었다면 압축이 아니라 종료 메모를 남긴 뒤 `/clear`로 분리하는 편이 안전합니다. 권한과 메모리는 대화를 정리하는 기능이 아니므로, 컨텍스트 문제를 해결하려고 건드리면 오히려 사고 범위만 커집니다.

버튼 간격 수정이 스키마 변경으로 새었습니다. 처음 목표는 좁았습니다. 결제 화면에서 긴 한국어 문구가 들어오면 버튼 높이가 달라지는 문제를 데스크톱과 모바일에서 고치는 일이었습니다. 허용 범위는 결제 컴포넌트와 스타일 파일, 검증은 기존 화면 테스트와 두 화면 크기의 브라우저 확인이었습니다. Claude는 `PaymentActions.tsx`와 `checkout.css`를 읽고 수정했지만 아직 모바일 캡처를 확인하지 않은 상태였습니다.

이때 “결제 실패와 취소를 구분하려면 DB에도 상태가 하나 더 필요하지 않을까?”라는 질문이 들어왔습니다. 이는 짧은 곁가지가 아닙니다. UI는 되돌리기 쉬운 파일 수정이지만 마이그레이션은 기존 행, 구버전 서버, 잠금, 배포 순서까지 봐야 합니다. 그런데 같은 대화를 계속 쓰자 Claude는 UI에서 사용한 `cancelled`라는 화면 문구를 그대로 열거형 값으로 제안하고, 이미 파일 편집 승인을 받은 흐름을 따라 마이그레이션 파일까지 만들려 했습니다.

문제는 컨텍스트의 길이보다 목표가 둘로 갈라진 데 있습니다. `/compact`를 실행하면 UI 대화가 짧아질 뿐, 덜 검토된 DB 가설도 요약에 남을 수 있습니다. 이 상태에서 “계속해”라고 하면 짧아진 잘못된 방향을 더 자신 있게 이어 갈 가능성이 있습니다.

먼저 상태와 문맥을 따로 확인합니다. 상태 확인은 한 명령으로 끝나지 않습니다. `/status`는 현재 버전, 모델, 계정과 연결 상태를 보여 줍니다. `/context all`은 대화 창에서 무엇이 컨텍스트를 차지하는지 펼쳐 보여 줍니다. 여기에 저장소 상태를 더해야 실제 작업 위치를 알 수 있습니다. 슬래시 명령은 Git 브랜치나 미커밋 파일을 대신 확인해 주지 않습니다.

아래 순서에서 UI 관련 파일과 테스트 결과가 대부분이고 목표가 여전히 버튼 수정이라면 같은 세션을 이어도 됩니다. 반대로 마이그레이션 조사, 테이블 정의, 운영 배포 이야기가 섞였거나 수정 파일이 약속한 범위를 벗어났다면 압축 전에 멈춥니다.

대화 상태와 저장소 상태를 함께 보는 점검 순서
/status
/context all

! git status --short --branch
! git diff -- PaymentActions.tsx checkout.css

확인 질문
- 원래 목표가 아직 하나인가?
- 약속한 파일 밖의 변경이 생겼는가?
- 실패한 검증과 미실행 검증을 구분할 수 있는가?
- 다음 행동의 권한과 실패 비용이 처음과 같은가?

권한은 문맥 청소가 아니라 사고 반경을 정합니다. `/permissions`는 허용, 매번 질문, 거부 규칙과 작업 디렉터리를 관리하는 화면입니다. UI 파일 편집을 승인했다는 사실은 DB 명령이나 배포까지 승인했다는 뜻이 아닙니다. 새 작업이 등장했을 때 권한을 넓히기보다, 지금 세션이 그 작업을 맡아야 하는지 먼저 판단해야 합니다.

이 사례에서는 마이그레이션 파일 작성과 DB 명령을 거부하거나 승인 대기 상태로 두고 UI 검증만 끝내는 것이 맞습니다. 반대로 읽기 전용으로 스키마 구조를 잠깐 확인하는 일이 UI 결과를 설명하는 데 꼭 필요하다면 범위를 정확히 적어 별도 승인을 받을 수 있습니다. “자꾸 물어봐서 불편하다”는 이유로 넓은 셸 권한을 허용하는 것은 컨텍스트 문제를 권한 문제로 바꾸는 잘못된 선택입니다.

메모리에는 이번 사건이 아니라 다음에도 지킬 규칙만 남깁니다. `/memory`에서는 프로젝트의 `CLAUDE.md` 같은 지침 파일을 편집하고 자동 메모리 항목을 볼 수 있습니다. 프로젝트 지침과 자동 메모리는 새 대화에도 다시 들어오지만, 강제되는 보안 설정은 아닙니다. “DB를 절대 수정하지 말 것”처럼 반드시 막아야 하는 행동은 권한 거부나 훅으로 통제해야 합니다.

이번 UI 작업의 픽셀 값, 임시 테스트 URL, 아직 검증하지 않은 DB 가설은 메모리에 넣지 않습니다. 반면 이 저장소에서 스키마 변경은 별도 티켓과 승인, 전진 호환 마이그레이션을 요구한다는 규칙이 모든 작업에 계속 적용된다면 프로젝트 지침으로 남길 가치가 있습니다. 일회성 진행 상황을 영구 메모리에 넣으면 다음 세션이 시작부터 낡은 사건을 사실처럼 받아들입니다.

같은 UI 목표라면 보존 항목을 지정해 압축합니다. UI 수정만 계속하고 대화가 길어진 경우에는 `/compact`가 맞습니다. 공식 명령은 뒤에 요약 초점을 붙일 수 있습니다. 단순히 `/compact`만 실행하기보다 목표, 결정, 변경 파일, 검증 결과와 금지 범위를 지정하면 중요한 진행 상태가 일반적인 요약 문장에 묻히는 일을 줄일 수 있습니다.

프로젝트 루트의 `CLAUDE.md`는 압축 뒤 다시 읽혀 들어오지만, 대화에서만 말한 지시는 자동으로 영구 지침이 되지 않습니다. 하위 디렉터리의 지침은 해당 경로의 파일을 다시 읽을 때 들어올 수 있으므로, 압축 직후 중요한 규칙이 사라졌다고 느껴지면 어떤 파일에서 온 규칙인지 확인해야 합니다.

같은 UI 작업을 이어 갈 때의 압축 요청
/compact 다음 내용만 보존하세요:
- 목표: 결제 버튼의 긴 문구에서 높이와 정렬 수정
- 허용 파일: src/checkout/PaymentActions.tsx, styles/checkout.css
- 완료: 데스크톱 1440px 화면 확인, 관련 단위 테스트 통과
- 남음: 390px 모바일 화면, 키보드 포커스 확인
- 금지: DB 스키마, API 계약, 배포 변경
- 보류: cancelled 상태 추가 제안은 별도 작업으로 넘김

DB 마이그레이션은 종료 메모 뒤 새 대화로 넘깁니다. UI 작업을 마치거나 안전한 중단점까지 되돌린 뒤에는 대화 밖에 종료 메모를 남깁니다. 이 메모는 멋진 요약보다 재현 가능한 사실이 중요합니다. 현재 커밋, 변경 파일, 실행한 명령과 결과, 하지 않은 일, 다음 작업이 읽어야 할 원천을 적습니다. 비밀값과 고객 데이터는 넣지 않습니다.

그다음 `/clear ui-button-fix`처럼 이전 대화에 이름을 붙이며 빈 컨텍스트로 새 대화를 시작할 수 있습니다. 새 DB 대화에서는 마이그레이션에 필요한 지침과 스키마 파일만 읽게 하고 처음에는 계획 또는 읽기 권한만 줍니다. UI 대화에서 나온 `cancelled` 값은 결정이 아니라 조사해야 할 후보라고 명시합니다.

작업 경계를 넘기기 전에 보존할 종료 메모
## 종료 상태: 결제 버튼 UI
- 기준: main / 8f31c2a
- 변경: PaymentActions.tsx, checkout.css
- 확인: UI 단위 테스트 통과, 1440px 렌더 정상
- 미확인: 390px 렌더, 실제 결제 흐름
- 하지 않음: DB·API·배포 변경
- 별도 조사: 실패와 취소 상태를 DB에서 나눌 필요성
- 주의: `cancelled`는 화면 문구에서 나온 후보이며 스키마 합의가 아님
- 다음 시작: 스키마, 쓰기 경로, 기존 행과 구버전 호환을 읽기 전용으로 조사

/clear ui-button-fix

재개는 대화를 되살리지만 파일 상태를 되돌리지 않습니다. `/resume`는 이름이나 세션 ID로 이전 대화를 선택해 이어 갑니다. `/clear`로 비운 이전 대화도 보존되므로 `ui-button-fix`를 다시 불러올 수 있습니다. 하지만 재개되는 것은 대화입니다. 그사이 다른 사람이 커밋했거나 브랜치가 바뀌었거나 미커밋 파일이 정리됐을 수 있습니다.

따라서 재개 직후 첫 행동은 “계속 수정해”가 아닙니다. 현재 브랜치와 커밋, 변경 파일을 확인하고 종료 메모의 상태와 대조합니다. 서로 다르면 과거 대화의 파일 위치와 테스트 결과를 현재 사실로 사용하지 않습니다. 종료 메모가 없거나 기준 커밋을 찾을 수 없다면 자동으로 추정해 이어 가지 말고 읽기 전용 재조사로 돌아갑니다.

압축, 초기화, 되감기를 혼동하지 않습니다. 잘못된 DB 제안이 나온 직후 `/compact`를 하면 틀린 가설을 짧게 보존할 수 있습니다. `/clear`는 새 대화를 만들지만 이미 수정된 파일을 되돌리지 않습니다. `/rewind`는 이전 체크포인트에서 대화나 코드를 되돌리는 별도 기능이므로, 파일 변경 자체를 취소해야 할 때 검토할 수 있습니다. 다만 데이터베이스에 이미 실행한 명령이나 외부 서비스의 변경까지 되돌려 주는 만능 롤백은 아닙니다.

어떤 명령을 쓸지 애매하면 목적어를 확인하면 됩니다. 컨텍스트 용량을 줄이는 대상은 `/compact`, 새 목표를 분리하는 대상은 `/clear`, 과거 대화를 찾는 대상은 `/resume`, 파일과 대화의 이전 체크포인트를 고르는 대상은 `/rewind`입니다. 행동 범위는 `/permissions`, 다음 세션에도 필요한 지침은 `/memory`가 맡습니다.

이 조건에서는 작업을 중단합니다. 현재 수정 파일을 설명하지 못하거나, UI 작업인데 마이그레이션과 배포 명령이 승인 목록에 들어갔거나, 압축 뒤 금지 범위가 사라졌다면 더 진행하지 않습니다. 실패 테스트가 무엇이었는지 알 수 없고 “대부분 통과했다”는 말만 남은 경우도 새 편집을 시작할 근거가 없습니다.

종료 메모에 기준 커밋과 미검증 항목을 남길 수 있을 때까지 상태를 다시 조사합니다. 외부 DB 변경이 이미 실행됐다면 `/clear`나 `/rewind`부터 누르지 말고 실제 변경 기록과 복구 절차를 확보합니다. 컨텍스트를 깨끗하게 만드는 것보다 현실의 변경 상태를 잃지 않는 일이 먼저입니다.

이 사례의 결과는 단순합니다. UI 세션은 두 파일과 화면 검증으로 닫혔고, DB 작업은 읽기 전용 조사로 새로 시작했습니다. 새 대화에서는 화면 문구가 아니라 기존 상태 값, 쓰기 경로, 배포 호환성을 기준으로 변경 필요성을 다시 판단할 수 있었습니다. 세션을 잘 관리한다는 것은 대화를 오래 보존하는 기술이 아니라, 목표가 달라지는 순간 작업의 증거와 권한을 끊어 주는 기술에 가깝습니다.

UI 목표만 담은 세션으로 다시 시작합니다. 다음은 컨텍스트 정리 동작을 보여 주는 예시입니다. 계획 모드로 시작해 UI 파일과 규칙만 읽게 합니다.

엉킨 세션을 분리한 첫 프롬프트
cd /path/to/project
claude --permission-mode plan

AGENTS.md, 결제 버튼 컴포넌트, 디자인 토큰과 UI 테스트만 읽으세요.
DB와 서버 파일은 읽거나 수정하지 마세요.
반환 형식: 현재 UI 문제 / 관련 파일 / 수정안 / 검증 / 범위 밖 요청
허용 도구: Read, Glob, Grep
Edit와 Bash는 계획 검토 뒤 승인합니다.

압축할지 새 세션으로 갈지 사람이 결정합니다. UI 계획이 그대로라면 후속 프롬프트로 "CSS 두 파일만 수정하고 모바일 회귀를 실행하세요. DB 상태 요청은 범위 밖으로 반환하세요."라고 보냅니다. DB 마이그레이션이 필요하다는 사실이 나오면 UI 세션을 압축해 억지로 이어 가지 않고 종료 메모를 남깁니다.

컨텍스트 정리 뒤에도 변경 차이는 남습니다. 대화를 지우거나 압축해도 파일 변경은 사라지지 않습니다. 다음 명령은 UI 작업 범위와 검증을 다시 확인하는 예시입니다.

UI 변경과 남은 상태 확인 예시
npm test -- ui
git diff -- web/components web/styles
git status --short

중단, 압축, 새 시작의 경계. 같은 UI 목표에서 관련 파일이 많아졌을 뿐이면 보존 항목을 지정해 압축합니다. DB, 운영 데이터, 배포처럼 목표와 위험이 달라지면 새 세션으로 갑니다. 재개 시 현재 브랜치와 변경 차이가 종료 메모와 다르면 먼저 원인을 확인합니다.