책에 포함된 노트Claude Code 실전 활용법: 설치부터 자동화·MCP·운영까지

컨텍스트 엔지니어링 2: /clear·/compact·세션 분리·두 번 수정 규칙

2026-03-22Views 12약 8분

긴 대화는 친절해 보이지만, Claude Code에서의 "긴 세션"은 종종 정확도를 떨어뜨리고 비용과 지연을 올립니다. 컨텍스트 윈도우는 모델의 작업 기억이고, 시스템 지침·대화 히스토리·도구 출력·검색 결과·응답까지 모두 같은 공간을 경쟁합니다.¹ 그래서 대화를 계속 쌓는 방식은, 결국 중요한 정보가 밀려나거나(누락/잘림) "있긴 있는데 못 쓰는" 상태(주의 분산, lost-in-the-middle)에 빠지기 쉽습니다.⁴⁶

이 챕터의 목표는 단순합니다. 컨텍스트 부패(context rot)와 컨텍스트 비대화(context bloat)의 징후를 빠르게 감지하고, /clear로 재시작하거나 /compact로 압축하고, 애초에 작업을 세션 단위로 쪼개서 품질을 일정하게 유지하는 것입니다.⁶⁵

컨텍스트가 길어질수록 '느려지고, 흔들리는' 이유

컨텍스트 윈도우 제한은 "토큰이 넘으면 에러" 같은 단순한 문제만이 아닙니다. 실제로는 에러가 나기 전부터 다음 현상이 먼저 나타납니다.

첫째, 길어진 입력은 계산량과 지연을 키웁니다. 모델이 더 긴 시퀀스를 처리할수록 비용과 지연, 타임아웃 리스크가 함께 올라가며, 운영팀은 토큰 예산을 CPU/메모리 예산처럼 다뤄야 합니다.¹ 실험 기반 글에서도 컨텍스트가 특정 지점에 가까워지면 응답 시간이 급격히 튀는 구간이 관찰됩니다.²

둘째, "긴 컨텍스트 = 더 똑똑함"이 아닙니다. 길이가 커질수록 모델이 중요한 단서를 제대로 집어 쓰지 못하는 경향이 있고, 특히 중간에 묻힌 정보가 약해지는 문제가 자주 보고됩니다.⁴⁶

셋째, 에이전트형 워크플로에서는 도구 출력이 컨텍스트를 가장 빠르게 태웁니다. 파일 여러 개를 읽고, grep 결과를 쌓고, 테스트 로그를 그대로 누적하면, 몇 번의 도구 호출만으로도 작업 공간이 "데이터 더미"로 바뀝니다.¹

여기서 핵심 결론은 하나입니다.

긴 대화가 답이 아니라, 짧고 선명한 세션이 답이다.

컨텍스트 부패/블로트의 징후: "지금 리부트할 타이밍"을 잡아라

컨텍스트 관리에서 가장 어려운 건 명령을 외우는 게 아니라, 리부트 타이밍을 감으로 버티지 않는 것입니다. 아래 징후가 보이면, '더 설명'이 아니라 '컨텍스트 정리'가 먼저입니다.⁶⁵

같은 제약을 반복해서 말했는데도, Claude가 계속 무시하거나 반대로 행동한다.¹
이미 확인한 파일을 다시 읽고 또 읽으며, 계획이 원점으로 돌아가는 느낌이 든다.¹⁹
수정 범위가 커지지 않았는데도 응답이 점점 장황해지고, 결론이 흐려진다(주의 분산).[^^6]
테스트 로그/스택트레이스/검색 결과 같은 "원자료"가 대화 안에 산처럼 쌓여 있다.¹
auto-compact가 애매한 타이밍에 터지면서, 중요한 디테일이 요약에서 사라진다.¹¹

이런 상태에서 "조금만 더"를 하면, 대부분은 더 꼬입니다. 다음 섹션부터는 이때 쓸 수 있는 두 가지 리셋 버튼(/clear와 /compact)을 구분해 봅니다.

/clear: 완전 리부트(작업 단위 종료용)

/clear는 대화 히스토리를 완전히 지우고 새 세션처럼 시작합니다. 별도의 요약도 남기지 않기 때문에, 컨텍스트 공간을 가장 크게 회복합니다.¹¹¹⁵

/clear가 가장 강력한 순간은 "문제 해결이 아니라 문제 전환"입니다. 예를 들어, 인증 버그를 고치다가 갑자기 UI 작업으로 넘어가면, 방금까지의 대화는 거의 전부 소음이 됩니다. 이때 /compact로 요약을 남기면, 소음을 압축해서 들고 가는 셈이 될 수 있습니다.¹¹

실전에서는 /clear를 작업 단위 경계로 사용합니다.

버그 수정 1건 완료 → /clear
PR 하나 준비 완료 → /clear
전혀 다른 모듈로 이동 → /clear

단, 완전 리부트는 "아무 것도 남지 않는" 것이 단점입니다. 그래서 /clear 직전에 남겨야 하는 최소한의 상태가 있습니다.

첫째, 현재 브랜치에서 바뀐 파일 목록입니다. 둘째, 어떤 테스트가 왜 실패했는지(혹은 무엇으로 검증 완료했는지)입니다. 셋째, 다음 세션에서 이어갈 다음 행동입니다. 이 셋만 있으면, 대화 히스토리가 없어도 다시 달릴 수 있습니다.

/compact: 체크포인트 압축(같은 작업을 이어갈 때)

/compact는 세션을 끝내지 않고, 지금까지의 대화를 요약(압축)한 상태로 재시작하는 명령입니다. 도구 출력(파일 읽기/grep/명령 출력 등)처럼 토큰을 많이 먹는 덩어리를 정리하고, 작업의 핵심만 남기게 설계되어 있습니다.¹¹

여기서 중요한 차이를 하나만 기억하면 됩니다.

/compact는 기억을 남긴다(요약)
/clear는 기억을 지운다(초기화)

즉, 같은 작업을 계속하는데 컨텍스트가 무거워졌다면 /compact, 작업을 끝내고 다른 일로 간다면 /clear가 기본값입니다.¹¹¹⁵

auto-compact를 기다리지 말고, 수동으로 '좋은 지점'에서 압축하기

자동 압축(auto-compact)은 컨텍스트가 임계치에 가까워졌을 때 시스템이 판단해 실행될 수 있는데, 이 타이밍이 항상 작업 흐름의 "좋은 끊김"과 일치하지는 않습니다.¹¹ 실제 사용자들도 자동 압축이 중간에 터지면 모델이 다시 헤매는 사례를 자주 이야기합니다.¹²¹⁹

그래서 권장되는 습관은 하나입니다.

압축은 "마무리 지점"에서 내가 건다.

예를 들어,

원인 분석(탐색) 끝
해결 방향(계획) 확정
1차 수정 + 테스트 실패 확인까지 끝

이런 지점에서 /compact를 걸면, 요약에 담아야 할 정보가 명확해집니다.

/compact에 '무엇을 남길지' 지시하라(Compact Prompt)

요약은 본질적으로 손실 압축입니다. 무엇을 남길지 지정하지 않으면, "디버깅을 진행했고 몇 파일을 수정했다" 같은 뭉뚱그린 요약이 남아 다음 스텝에서 다시 파일을 전부 재탐색하게 됩니다.¹¹

그래서 /compact는 보통 이렇게 씁니다.

/compact 다음을 반드시 남겨줘:
1) 수정한 파일 경로와 변경 요약
2) 현재 실패 중인 테스트/에러 메시지 원문(가능하면 1~3줄)
3) 원인 가설과 반증/확인한 것
4) 다음에 바로 할 명령 1~3개

이 방식은 "대화 내용을 요약해 주세요"가 아니라, 다음 세션을 위한 인수인계 문서를 만드는 방식입니다.¹²

세션 분리: '한 세션 = 한 목표'가 가장 싸고 정확하다

컨텍스트 비대화의 가장 흔한 원인은 사실 기술이 아니라 습관입니다. 하나의 세션을 너무 오래, 너무 다양한 목적에 재사용하는 겁니다.⁵ 그러면 모델은 지금 문제를 풀 때도 과거의 잡다한 맥락을 함께 읽어야 하고, 그만큼 집중력이 떨어집니다.⁶

세션 분리의 기준은 간단합니다.

사용자 의도가 바뀌면 세션도 바꾼다.

예를 들어 "버그 수정"과 "리팩터링"은 인간에게는 이어진 작업처럼 느껴져도, Claude Code에는 다른 목표 세트일 때가 많습니다. 버그 수정은 재현/원인/최소 수정이 핵심이고, 리팩터링은 변경 범위 통제/회귀 테스트/코드 구조가 핵심입니다. 목표가 바뀌면 필요한 컨텍스트도 바뀝니다.

실무 팁으로는 세션을 끊기 전에 /rename으로 이름을 붙이고, 나중에 /resume로 다시 여는 방식이 유용합니다.¹⁵ 이렇게 하면 "세션을 버리는" 부담이 줄고, 오히려 더 자주 끊을 수 있습니다.

두 번 수정 규칙: 컨텍스트를 '기능'과 '품질'로 분리하라

긴 세션이 망가지는 대표적인 패턴은 이렇습니다.

탐색과 실험이 길어지며 컨텍스트가 더러워진다.
그 상태에서 리팩터링/정리까지 한 번에 하려다가, Claude가 스스로 만든 흔적(임시 코드, 실패한 시도)을 제대로 지우지 못한다.¹⁹

이를 막기 위한 실전 규칙이 두 번 수정 규칙입니다.

첫 번째 수정은 "기능/버그" 자체를 최소 변경으로 해결하는 데만 집중합니다. 이때 목표는 깔끔한 코드가 아니라, 재현 케이스가 사라지고 테스트가 통과하는 상태를 만드는 것입니다.

두 번째 수정은 "품질"을 위한 세션으로 분리합니다. 첫 세션에서 필요한 결과물은 이미 확보했으니, 두 번째 세션은 컨텍스트를 새로 시작(/clear)하거나 최소한 정리(/compact)한 뒤, 코드 정리·중복 제거·이름 개선·주석/문서·추가 테스트 같은 일을 수행합니다.

이 규칙이 주는 이점은 명확합니다. 첫 세션은 탐색 로그와 시행착오를 마음껏 쌓아도 됩니다. 대신 그 더러움은 두 번째 세션으로 가져가지 않습니다. 결국 '정답을 찾는 컨텍스트'와 '코드를 다듬는 컨텍스트'를 분리하게 됩니다.⁵