새 대화를 시작해야 하는 순간 | Task Sizing

Overview

Context Window, CLAUDE.md, Memory 까지 세웠으면 남은 질문은 하나입니다. 하나의 대화를 언제 끊고 새로 열어야 하는가입니다.

토큰 한계는 자동 압축이 알아서 처리합니다. 문제는 길이가 아니라, 긴 대화에 쌓이는 노이즈가 다음 답변의 질을 떨어뜨린다는 점입니다. 이 레슨에서는 새 대화를 열어야 하는 세 가지 신호와 /clear, /compact 의 차이를 정리합니다.

학습 목표

• 새 대화를 열어야 하는 세 가지 신호를 판단합니다
• 긴 대화에서 노이즈가 쌓이는 원리를 이해합니다
• /clear 와 /compact 를 언제 쓸지 구분합니다

새 대화를 열어야 하는 세 가지 신호

긴 대화에서 답변 품질이 떨어지는 신호는 다음 세 가지입니다. 하나라도 보이면 새 대화로 옮기는 것이 안전합니다.

신호 1: 무관한 작업 전환

결제 모듈의 버그를 한 시간 동안 추적해 원인을 찾은 직후, 같은 대화에서 "이제 알림 기능 추가해줘" 로 넘어가 봅니다. 모델은 잘 따라오는 듯 답하지만, 결과물을 자세히 보면 어딘가 어색합니다. 큰 그림을 먼저 잡는 대신 작은 함수를 하나씩 끼워 넣는 방식으로 코드를 만들고, 기존 모듈을 건드려야 하는 자리에서 자꾸 우회로를 택합니다.

디버깅 중인 모델은 "작은 변경, 한 번에 한 가설, 사이드 이펙트 최소화" 모드에 깊이 잠겨 있습니다. 새 기능 구현은 정반대(큰 구조부터 잡고 일관되게) 가 맞는 작업인데, 이전 작업의 모드가 그대로 따라오면서 누더기 구조가 만들어집니다. 명시적으로 "큰 구조부터 잡아줘" 라고 지시해도 디버깅 때 굳어진 톤이 다시 슬그머니 따라옵니다.

디버깅 모드에서 안전했던 "최소 변경" 원칙이, 새 기능 구현에선 큰 구조를 잡는 손을 묶어 버립니다.

새 대화를 열고, 지금 시작하는 작업의 모드를 처음부터 다시 깔아 두는 것이 안전합니다.

신호 2: 두 번 빗나가는 수정

같은 수정 요청이 두 번 빗나간 상황을 떠올려 보세요. "여기서 X 를 바꿔달라" 고 했는데 엉뚱한 곳을 고치고, 다시 설명해도 또 놓칩니다. 세 번째 시도에서 모델은 점점 방어적이고 조심스러워집니다. 대답 앞에 경고를 먼저 붙이거나, 작은 수정만 시도하다 물러서는 식입니다.

이유는 모델이 대화 안의 모든 메시지를 다음 답변의 예시로 본다는 점에 있습니다. 첫 시도에서 빗나간 답변과 두 번째에서 또 빗나간 답변이 대화에 남아 있으면, 모델 입장에서는 "이 대화에서 어울리는 답변은 이런 식" 이라는 패턴이 만들어진 셈입니다. 세 번째 답변은 빗나간 두 답변과 비슷한 결로, 다만 좀 더 조심스럽게 다듬어져 나옵니다. 정답에서 멀어진 채 미세 조정만 반복하는 상태입니다.

세 번째 시도를 같은 대화에서 밀어붙이는 것보다, 같은 프롬프트를 새 대화에 그대로 붙여 넣는 편이 풀릴 확률이 높습니다. 모델이 이 문제를 못 푸는 게 아니라, 빗나간 두 답변이 다음 답변의 본보기로 작용하는 게 문제이기 때문입니다. 깨끗한 대화에서는 같은 모델이 다른 답을 내놓는 경우가 많습니다.

신호 3: 작업 완결

한 기능을 PR 까지 머지하고 다음 기능으로 넘어가는 자리, 또는 스펙 논의가 끝나고 구현으로 들어가는 자리는 가장 안전한 끊기 지점입니다. 다음 작업이 무관하든 같은 영역의 다음 단계든, 완결 자리에서 한 번 끊으면 신호 1·2 가 나타나기 전에 미리 차단할 수 있습니다.

신호 1·2 는 이미 문제가 생긴 뒤의 사후 신호고, 신호 3 은 문제가 생기기 전의 예방 신호입니다. 익숙해지면 신호 3 만으로도 대부분의 끊기가 자연스럽게 이뤄집니다.

/clear 와 /compact

새 터미널을 여는 대신 현재 세션 안에서 잔을 비우는 두 명령어가 있습니다.

/clear: 완전 초기화

/clear 는 대화 기록·도구 응답·누적된 정보를 전부 비웁니다. 세션 시작 시점부터 실려 있던 CLAUDE.md 와 Memory 는 그대로 남아, 새 대화를 여는 것과 같은 상태가 됩니다. 직전 대화는 그대로 보관되어, 필요하면 /resume 로 다시 불러올 수 있습니다.

/clear 의 힘은 크기뿐 아니라 대화의 흐름까지 리셋된다는 점입니다. 누적된 실패 신호가 끊기고 깨끗한 상태에서 다시 시작할 수 있습니다.

/compact: 요약으로 압축

/compact 는 대화 기록을 요약해 토큰 수를 줄입니다. Context 가 한계에 가까워지면 Claude Code 가 자동으로 발동하고, /compact <지시문> 으로 수동 실행도 가능합니다. 대화의 골자는 남기므로 같은 작업을 계속 이어가야 하는데 Context 가 꽉 찰 때 쓰입니다. 단, 요약 과정에서 "A 를 시도했다가 충돌 나서 B 로 바꿨다" 같은 실패 경위가 사라지므로, 같은 실수를 반복할 위험이 있습니다.

기본 선택은 /clear 입니다. /compact 는 끊을 수 없는 긴 작업을 어쩔 수 없이 이어가야 할 때만 꺼내는 예외 도구입니다.

핵심 포인트 정리

1. 세 가지 신호: 무관 작업 전환·반복 실패·작업 완결. 이 중 하나가 보이면 새 대화로 옮기는 것이 안전합니다
2. 노이즈가 문제, 길이는 아님: 토큰 한계는 자동 압축이 처리합니다. 새 대화를 여는 이유는 누적된 노이즈이지 양이 아닙니다
3. 기본은 /clear, 예외는 /compact: /clear 는 Context 와 실패 흐름까지 리셋합니다. /compact 는 뉘앙스를 잃으므로 끊을 수 없을 때만 씁니다

FAQ

• Q: 커밋마다 새 대화로 끊으라는 규칙은 이제 틀린 건가요?

  • A: 과보정에 가깝습니다. 같은 기능 안에서 여러 커밋이 이어지는 작업은 한 대화로 끌고 가도 큰 문제가 없습니다. 커밋 자체는 끊는 자리가 아니라, 다음 작업이 같은 완성 기준인가를 점검하는 체크포인트로 쓰면 충분합니다

• Q: 한 대화를 어디까지 이어갈 수 있나요?

  • A: 정해진 토큰 수가 아니라 세 가지 신호가 나오지 않는 범위까지입니다. 같은 완성 기준에 머무는 한 대화가 길어져도 품질이 크게 떨어지지 않습니다. 단, 비용과 레이턴시는 길이에 비례해 늘어나므로, 몇 시간 단위로 한 번 끊는 것이 실용적입니다

• Q: /compact 만 계속 쓰면 안 되나요?

  • A: 요약 과정에서 "A 를 시도했다가 충돌 나서 B 로 바꿨다" 같은 실패 경위가 사라집니다. 같은 실수를 다시 저지르기 쉬워지므로, 깨끗한 시작이 부분 요약보다 대체로 결과가 좋습니다

이어서 배울 내용

Chapter 03 에서 Context 관리의 네 기둥(Context Window 의 원리, CLAUDE.md, Memory, Task Sizing) 을 세웠습니다. 다음 Chapter 는 이 네 기둥을 실전에 적용해 작은 Todo 앱 하나를 처음부터 끝까지 만들어 봅니다. AI 에게 곧바로 코드를 시키는 대신 탐색 → 계획 → 실행 워크플로우로 끊어 가는 법을 연습하는 자리입니다.

• Plan Mode 로 탐색·계획·실행 분리하기
• 요구사항을 한 잔 분량으로 쪼개 구현하기