대화를 잘 끊는 기술 | Task Sizing

Overview

이전 레슨에서 Memory로 세션 간 학습을 유지하는 방법을 배웠습니다. 하지만 하나의 대화 안에서 여러 작업을 이어가면, 파일 읽기 결과와 도구 응답이 쌓이면서 어느 순간 AI가 Dumb Zone에 진입합니다. 이 레슨에서는 Context 관리에서 가장 효과적인 방법인 Task Sizing, 즉 대화를 언제 끊어야 하는지를 판단하는 기준을 배웁니다.

학습 목표

• Task Sizing이 가장 효과적인 Context 관리 방법인 이유를 설명할 수 있습니다
• 새 대화를 시작해야 하는 4가지 신호를 구분할 수 있습니다
• /clear와 /compact의 차이를 이해하고 상황에 맞게 선택할 수 있습니다

Task Sizing: 물을 컵에 나눠 담기

물을 컵에 담는다고 생각해 보겠습니다. 2리터의 물이 있는데 컵 하나에 다 담으려 하면 넘칩니다. 여러 컵에 나눠 담아야 합니다. Task Sizing(태스크 사이징)은 이 원리를 Context Window에 적용한 것입니다. 하나의 대화에 모든 작업을 담으려 하지 말고, 작업 단위로 나눠서 새 대화에 담습니다.

문제는 컵이 생각보다 훨씬 작다는 것입니다. Lesson 01에서 배운 것처럼, 사용자 메시지 외에 System Prompt, 도구 정의, MCP 스키마, CLAUDE.md가 이미 컵의 상당 부분을 차지하고 있습니다. 실제로 사용할 수 있는 공간은 체감보다 좁습니다.

하나의 Context에 하나의 작업 사이클

좋은 Task 단위는 수정 -> 테스트 -> 커밋 한 사이클입니다. 코드를 수정하고, 테스트를 실행해서 검증하고, 문제가 없으면 커밋합니다. 이 사이클이 끝나면 새 대화를 시작합니다.

이 사이클이 하나의 Context Window 안에서 완결되면, AI는 시작부터 끝까지 집중력을 유지합니다. 반대로, 한 대화에서 기능 A를 구현하고, 이어서 기능 B를 디버깅하고, 기능 C의 테스트까지 작성하면, 기능 A의 도구 응답과 디버깅 로그가 Context를 점령해서 기능 C를 작업할 때는 AI가 이미 Smart Zone을 벗어난 상태입니다.

새 메시지를 보내기 전마다 스스로 물어보세요. "이게 새로운 Context여야 하나?"

이럴 때 새 대화를 시작하라

새 대화를 시작해야 하는 4가지 신호입니다.

• 다른 종류의 작업으로 전환할 때: 프론트엔드 구현을 끝내고 백엔드 API로 넘어간다면, 프론트엔드 코드와 도구 응답이 더 이상 필요하지 않습니다
• AI 응답 품질이 눈에 띄게 떨어졌을 때: 같은 수정을 두 번 요청했는데 반영이 안 된다면, Dumb Zone에 진입했거나 실패 패턴이 누적된 것입니다. 어느 쪽이든 이어가는 것보다 새로 시작하는 것이 낫습니다
• 커밋 완료 직후: 커밋은 작업의 자연스러운 구분점입니다. 커밋이 끝나면 그 작업에 관련된 모든 맥락이 더 이상 필요하지 않습니다
• 확신이 없을 때: 새 대화를 시작할지 말지 고민된다면, 새 대화가 거의 항상 더 나은 선택입니다

/clear와 /compact: 두 가지 리셋 방법

대화를 완전히 새로 시작하는 것 외에, 현재 대화 안에서 Context를 리셋하는 두 가지 방법이 있습니다.

/clear: Smart Zone으로 돌아가기

/clear는 Context Window를 완전히 초기화합니다. 대화 기록, 도구 응답, 모든 누적된 정보가 사라집니다. CLAUDE.md는 System Prompt의 일부이므로 유지됩니다. 실질적으로 새 대화를 시작하는 것과 같은 효과입니다.

두 번 수정 요청해도 안 고쳐지면? /clear하고 처음부터 다시 설명하는 것이 낫습니다. Dumb Zone에서 세 번째 시도를 하는 것보다, Smart Zone에서 첫 번째 시도를 하는 것이 성공 확률이 높습니다.

/clear가 효과적인 두 번째 이유: 실패 패턴 리셋

/clear는 Context의 크기를 리셋할 뿐만 아니라 대화의 흐름도 리셋합니다. 드라마를 떠올려 보세요. 주인공이 계속 실패하는 드라마를 보고 있으면, 다음 장면에서도 실패할 거라고 예상합니다. LLM도 마찬가지입니다. 수정을 요청하고, 틀리고, 다시 요청하고, 또 틀리는 대화가 쌓이면, AI는 "이 대화에서는 잘 안 되는 중"이라는 흐름을 이어갑니다. 일부러 못하는 것이 아니라, 지금까지의 대화 흐름에 맞춰서 응답하는 것입니다.

/clear는 이 흐름을 완전히 끊습니다. 실패가 쌓인 대화를 이어가는 대신, 깨끗한 대화에서 처음부터 다시 시작하면 AI도 새로운 흐름으로 응답합니다.

/compact: 요약으로 context를 줄이기

/compact는 대화 기록을 요약하여 토큰 수를 줄입니다. 다만 요약 과정에서 뉘앙스가 손실되므로, /clear가 보통은 더 나은 선택입니다.

핵심 포인트 정리

1. Task Sizing: 스펙 최적화, 도구 조정, MCP 정리보다 작업 크기를 줄이는 것이 가장 효과적인 Context 관리입니다. 좋은 단위는 수정 -> 테스트 -> 커밋 한 사이클입니다
2. 새 대화 시작 신호: 작업 종류 전환, 품질 저하, 커밋 완료, 확신 없음의 4가지 신호로 판단합니다. 고민되면 새 대화가 거의 항상 답입니다
3. /clear 우선 사용: /compact는 뉘앙스를 잃으므로 /clear를 기본으로 사용합니다. /clear는 크기뿐 아니라 실패 패턴(궤적)도 리셋합니다. Smart Zone에서의 첫 시도가 Dumb Zone에서의 세 번째 시도보다 낫습니다

FAQ

• Q: 대화를 너무 자주 끊으면 비효율적이지 않나요?

  • A: CLAUDE.md가 있으므로 새 대화에서도 프로젝트 정보는 자동으로 제공됩니다. 맥락을 다시 설명하는 비용보다, Dumb Zone에서 작업하며 낭비되는 비용이 훨씬 큽니다

• Q: /clear 후에 이전 대화의 결과물을 참조하고 싶으면 어떻게 하나요?

  • A: 코드에 이미 반영되어 커밋된 결과물은 AI가 파일을 읽으면 됩니다. 아직 반영되지 않은 논의 내용이 있다면, 핵심만 요약해서 새 대화의 첫 메시지로 전달하는 것이 좋습니다

• Q: Task Sizing 대신 /compact를 계속 사용하면 안 되나요?

  • A: /compact는 요약 과정에서 중요한 뉘앙스를 잃습니다. "이전에 시도했을 때 충돌이 발생해서 다른 이름을 사용하기로 했다" 같은 맥락이 사라지면, AI가 같은 실수를 반복할 수 있습니다. 깨끗한 시작이 부분적인 요약보다 결과가 좋습니다

이어서 배울 내용

Chapter 03에서 Context 관리의 네 가지 기둥을 배웠습니다. Context Window의 원리(Lesson 01), CLAUDE.md로 프로젝트 규칙을 자동 제공하는 방법(Lesson 02), Memory로 세션을 넘어 학습을 유지하는 방법(Lesson 03), 그리고 대화를 적절히 끊는 기술(이번 Lesson)입니다. 다음 Chapter에서는 이 지식을 실전에 적용합니다. AI에게 바로 코드를 시키기 전에 먼저 계획을 세워야 하는 이유, 그리고 Plan Mode를 사용하는 방법을 배웁니다.

• AI에게 바로 코딩을 시키면 안 되는 이유
• Plan Mode로 탐색 -> 계획 -> 실행 워크플로우 만들기