new_task 도구 & 컨텍스트 관리 전략

개요

Cline은 특히 복잡하거나 장기 실행 작업 중에 워크플로 연속성 및 컨텍스트 보존 관리를 돕도록 설계된 강력한 내부 도구인 new_task를 포함합니다. 이 도구는 Cline 자체의 컨텍스트 창 사용량 인식 및 .clinerules의 유연성과 결합되어 작업을 세분화하고 작업 세션 간의 원활한 전환을 보장하는 정교한 전략을 가능하게 합니다. 핵심 기능과 사용자 지정 규칙과의 상호 작용 방식을 이해하는 것이 이 기능을 효과적으로 활용하는 데 중요합니다.

핵심 기능

두 가지 기본 기능이 고급 컨텍스트 관리를 가능하게 합니다:
  1. new_task 도구:
    • 기능: 사용자 승인 시 Cline이 현재 작업 세션을 종료하고 즉시 새 세션을 시작하도록 허용합니다.
    • 컨텍스트 미리 로드: 결정적으로 Cline은 도구의 <context> 블록 내에 제공된 특정 컨텍스트로 이 새 작업 세션을 미리 로드할 수 있습니다. 이 컨텍스트는 Cline 또는 .clinerules 파일이 정의하는 모든 것(요약, 코드 스니펫, 다음 단계, 프로젝트 상태 등)이 될 수 있습니다.
  2. 컨텍스트 창 인식:
    • 추적: Cline은 작업 중에 사용 가능한 컨텍스트 창의 현재 사용 비율을 내부적으로 추적합니다.
    • 가시성: 이 정보는 프롬프트에서 Cline에 제공된 environment_details에 표시됩니다.

/newtask 슬래시 명령어 사용

Cline이 newtask 도구를 제안하거나 복잡한 규칙을 정의하는 것에 대한 빠른 대안으로 슬래시 명령어를 사용하여 직접 프로세스를 시작할 수 있습니다.
  • 방법: 채팅 입력 필드에 /newtask를 입력하기만 하면 됩니다.
  • 작업: Cline은 일반적으로 현재 세션을 기반으로 컨텍스트를 제안하는 새 작업을 만들 것을 제안합니다(도구를 사용할 때의 기본 동작과 유사). 새 작업이 생성되기 전에 컨텍스트를 확인하고 잠재적으로 수정하기 위한 ask_followup_question 프롬프트가 계속 표시됩니다.
  • 이점: Cline이 제안하기를 기다리지 않고 분기 탐색 또는 긴 세션 관리를 위해 new_task 기능을 활용하는 빠르고 사용자 시작 방식을 제공합니다.
/newtask 슬래시 명령어 사용에 대한 자세한 내용은 새 작업 명령어 문서를 참조하십시오.

기본 동작 (.clinerules 없이)

기본적으로 특정 .clinerules가 동작을 지시하지 않는 경우:
  • 도구 가용성: new_task 도구가 존재하며 Cline은 이를 사용하도록 선택할 수 있습니다.
  • 컨텍스트 인식: Cline은 컨텍스트 사용 비율을 인식합니다.
  • 자동 트리거 없음: Cline은 컨텍스트 사용량이 특정 비율(예: 50%)에 도달하는 것만으로 작업 핸드오프를 자동으로 시작하지 않습니다. new_task 사용을 제안하는 결정은 전체 작업 진행률 및 프롬프트 지침을 기반으로 한 AI 모델의 추론에서 비롯됩니다.
  • 기본 컨텍스트 미리 로드: 특정 규칙이 <context> 블록 구조를 정의하지 않고 new_task가 사용되는 경우 Cline은 현재 이해를 기반으로 관련 정보(예: 진행 상황 및 다음 단계의 기본 요약)를 미리 로드하려고 시도하지만 이는 규칙 기반 접근 방식보다 덜 포괄적일 수 있습니다.

.clinerules의 힘: 사용자 지정 워크플로 활성화

핵심 기능은 기본적으로 존재하지만 .clinerules에 정의된 사용자 지정 워크플로와 new_task 및 컨텍스트 인식을 결합하면 진정한 힘, 자동화 및 사용자 지정이 나타납니다. 이를 통해 Cline이 컨텍스트 및 작업 연속성을 관리하는 _시기_와 _방법_을 정확하게 제어할 수 있습니다. new_task와 함께 .clinerules를 사용하는 주요 이점:
  • 자동화된 컨텍스트 관리: 특정 컨텍스트 비율(예: >50%, >70%) 또는 토큰 수에서 핸드오프를 자동으로 트리거하는 규칙을 정의하여 최적의 성능을 보장하고 컨텍스트 손실을 방지합니다.
  • 모델별 최적화: 다른 LLM에 대해 알려진 임계값을 기반으로 핸드오프 트리거를 조정합니다(예: 특정 토큰 수를 초과하면 성능이 저하되는 것으로 알려진 모델의 경우 더 일찍 트리거).
  • 지능형 중단점: 컨텍스트 임계값을 통과한 논리적 중지 지점(예: 함수 또는 테스트 완료 후)을 찾도록 규칙을 통해 Cline에 지시하여 더 깔끔한 핸드오프를 보장합니다.
  • 구조화된 작업 분해: 계획 모드를 사용하여 하위 작업을 정의한 다음 .clinerules를 사용하여 각 하위 작업을 완료하면 Cline이 new_task를 통해 자동으로 새 작업을 만들고 다음 하위 작업에 대한 컨텍스트를 미리 로드하도록 합니다.
  • 사용자 지정 컨텍스트 패키징: 매우 상세하고 일관된 핸드오프를 위해 .clinerules<context> 블록의 정확한 구조와 내용을 지정합니다(아래 예 참조).
  • 향상된 메모리 지속성: 세션 전체에 정보를 지속하는 기본적이고 통합된 방법으로 new_task 컨텍스트 블록을 사용하여 파일 기반 메모리 시스템을 잠재적으로 대체하거나 보완합니다.
  • 워크플로 자동화: 특정 유형의 작업을 시작할 때 특정 설정 지침이나 프로젝트 상용구를 항상 미리 로드하는 등 특정 시나리오에 대한 규칙을 정의합니다.

예제 규칙 기반 워크플로: 작업 핸드오프 프로세스

아래 예와 같이 특정 .clinerules에 의해 구동되는 일반적인 워크플로에는 다음 단계가 포함됩니다.
  1. 트리거 식별(규칙 기반): Cline은 규칙에 정의된 핸드오프 지점(예: 컨텍스트 사용량 > 50%, 작업 완료)을 모니터링합니다.
  2. 사용자 확인: Cline은 ask_followup_question을 사용하여 새 작업을 만들 것을 제안하며, 종종 규칙에 의해 정의된 의도된 컨텍스트를 보여줍니다.
    <ask_followup_question>
    <question>[특정 성과]를 완료했으며 컨텍스트 사용량이 높습니다(XX%). 다음 컨텍스트를 미리 로드하여 [남은 작업]을 계속하기 위해 새 작업을 만들까요?</question>
    <options>["예, 새 작업 만들기", "먼저 컨텍스트 수정", "아니요, 이 세션 계속"]</options>
    </ask_followup_question>
    
  3. 사용자 제어: 새 작업이 생성되기 전에 컨텍스트를 승인, 거부 또는 Cline에 수정하도록 요청할 수 있습니다.
  4. 컨텍스트 패키징(new_task 도구): 승인되면 Cline은 .clinerules에 의해 지정된 구조에 따라 컨텍스트를 패키징하는 new_task를 사용합니다.
  5. 새 작업 생성: 현재 작업이 종료되고 지정된 컨텍스트로 미리 로드된 새 세션이 즉시 시작됩니다.

핸드오프 컨텍스트 블록(규칙 정의 구조)

규칙 기반 핸드오프의 효과는 .clinerules<context> 블록을 정의하는 방식에 크게 좌우됩니다. 포괄적인 구조에는 종종 다음이 포함됩니다.
  • ## 완료된 작업: 성과, 수정/생성된 파일, 주요 결정의 상세 목록.
  • ## 현재 상태: 프로젝트 상태, 실행 중인 프로세스, 주요 파일 상태.
  • ## 다음 단계: 남은 작업, 구현 세부 정보, 알려진 과제의 명확하고 우선 순위가 지정된 목록.
  • ## 참조 정보: 링크, 코드 스니펫, 패턴, 사용자 기본 설정.
  • 실행 가능한 시작: 즉각적인 다음 작업에 대한 명확한 지침.

잠재적인 사용 사례 및 워크플로

.clinerules와 결합된 new_task의 유연성은 많은 가능성을 열어줍니다.
  • 사전 예방적 컨텍스트 창 관리: 최적의 성능을 유지하기 위해 특정 비율(예: 50%, 70%) 또는 토큰 수에서 핸드오프를 자동으로 트리거합니다.
  • 지능형 중단점: 컨텍스트 임계값을 통과한 논리적 중지 지점(예: 함수 또는 테스트 완료 후)을 찾도록 Cline에 지시하여 더 깔끔한 핸드오프를 보장합니다.
  • 구조화된 작업 분해: 계획 모드를 사용하여 하위 작업을 정의한 다음 .clinerules를 사용하여 각 하위 작업을 완료하면 Cline이 new_task를 통해 자동으로 새 작업을 만들도록 합니다.
  • 자동화된 세션 요약: 이전 세션의 주요 토론 지점 요약을 항상 포함하도록 <context> 블록을 구성합니다.
  • 상용구/설정 미리 로드: 특정 프로젝트와 관련된 새 작업을 표준 설정 지침 또는 파일 템플릿으로 미리 로드하여 시작합니다.
  • “메모리 뱅크” 대안: 세션 전체에 정보를 지속하는 기본 방법으로 new_task 컨텍스트 블록을 사용하여 파일 기반 메모리 시스템을 잠재적으로 대체합니다.
요구 사항에 가장 적합한 워크플로를 찾으려면 .clinerules를 실험해 보는 것이 좋습니다!

예제 .clinerules: 작업 핸드오프 전략 가이드

다음은 컨텍스트 창 관리를 위해 new_task를 사용하는 데 특별히 초점을 맞춘 예제 .clinerules 파일입니다. 이는 단지 하나의 특정 전략일 뿐이며 핵심 new_task 도구는 다른 사용자 지정 규칙과 다르게 사용될 수 있음을 기억하십시오.
# `new_task` 도구를 사용해야 합니다: 작업 핸드오프 전략 가이드

**⚠️ 중요 지침 - 다음 지침을 따라야 합니다 ⚠️**

이 가이드는 복잡한 작업을 효과적으로 세분화하고 작업 간의 원활한 핸드오프 프로세스를 구현하기 위한 **필수** 지침을 제공합니다. 연속성, 컨텍스트 보존 및 효율적인 작업 완료를 보장하려면 다음 지침을 **반드시** 따라야 합니다.

## ⚠️ 컨텍스트 창 모니터링 - 필수 작업 필요 ⚠️

환경 세부 정보에 표시된 컨텍스트 창 사용량을 **반드시** 모니터링해야 합니다. 사용량이 사용 가능한 컨텍스트 창의 50%를 초과하면 `new_task` 도구를 사용하여 작업 핸드오프를 **반드시** 시작해야 합니다.

200K 컨텍스트 창에서 컨텍스트 창 사용량이 50%를 초과하는 예:

\`\`\`text

# 컨텍스트 창 사용량

105,000 / 200,000 토큰 (53%)
모델: anthropic/claude-3.7-sonnet (200K 컨텍스트 창)
\`\`\`

**중요**: 컨텍스트 창 사용량이 50% 이상인 경우 다음을 **반드시** 수행해야 합니다.

1. 현재 논리적 단계 완료
2. `ask_followup_question` 도구를 사용하여 새 작업 만들기를 제안합니다.
3. 승인되면 포괄적인 핸드오프 지침과 함께 `new_task` 도구를 사용합니다.

## 계획 모드의 작업 분해 - 필수 프로세스

계획 모드는 복잡한 작업을 분석하고 관리 가능한 하위 작업으로 나누도록 특별히 설계되었습니다. 계획 모드에서는 다음을 **반드시** 수행해야 합니다.

### 1. 초기 작업 분석 - 필수

-   사용자 요청의 전체 범위를 철저히 이해하는 것으로 **반드시** 시작해야 합니다.
-   작업의 모든 주요 구성 요소와 종속성을 **반드시** 식별해야 합니다.
-   잠재적인 과제, 예외적인 경우 및 전제 조건을 **반드시** 고려해야 합니다.

### 2. 전략적 작업 분해 - 필수

-   전체 작업을 논리적이고 개별적인 하위 작업으로 **반드시** 나누어야 합니다.
-   종속성(먼저 완료해야 하는 작업)을 기반으로 하위 작업의 우선 순위를 **반드시** 지정해야 합니다.
-   단일 세션(15-30분 작업) 내에 완료할 수 있는 하위 작업을 **반드시** 목표로 해야 합니다.
-   컨텍스트 전환이 의미 있는 자연스러운 중단 지점을 **반드시** 고려해야 합니다.

### 3. 작업 로드맵 만들기 - 필수

-   사용자에게 명확하고 번호가 매겨진 하위 작업 목록을 **반드시** 제시해야 합니다.
-   하위 작업 간의 종속성을 **반드시** 설명해야 합니다.
-   가능한 경우 각 하위 작업에 대한 예상 시간을 **반드시** 제공해야 합니다.
-   도움이 될 경우 작업 흐름 및 종속성을 시각화하기 위해 Mermaid 다이어그램을 **반드시** 사용해야 합니다.

\`\`\`mermaid
graph TD
A[주요 작업] --> B[하위 작업 1: 설정]
A --> C[하위 작업 2: 핵심 구현]
A --> D[하위 작업 3: 테스트]
A --> E[하위 작업 4: 문서화]
B --> C
C --> D
\`\`\`

### 4. 사용자 승인 받기 - 필수

-   제안된 작업 분해에 대한 사용자 피드백을 **반드시** 요청해야 합니다.
-   사용자 우선 순위 또는 추가 요구 사항에 따라 계획을 **반드시** 조정해야 합니다.
-   시작할 하위 작업을 **반드시** 확인해야 합니다.
-   구현할 준비가 되면 사용자에게 실행 모드로 전환하도록 **반드시** 요청해야 합니다.

## 작업 구현 및 핸드오프 프로세스 - 필수 절차

실행 모드에서 작업을 구현할 때 효과적인 작업 핸드오프를 위해 다음 지침을 **반드시** 따라야 합니다.

### 1. 집중적인 구현 - 필수

-   현재 하위 작업을 완전히 완료하는 데 **반드시** 집중해야 합니다.
-   주석 및 커밋 메시지를 통해 진행 상황을 명확하게 **반드시** 문서화해야 합니다.
-   논리적 완료 지점에서 체크포인트를 **반드시** 만들어야 합니다.

### 2. 완료 지점 인식 - 중요

다음과 같은 경우 자연스러운 핸드오프 지점을 **반드시** 식별해야 합니다.

-   현재 하위 작업이 완전히 완료된 경우
-   더 큰 하위 작업에서 논리적 중지 지점에 도달한 경우
-   구현이 예상보다 오래 걸리고 나중에 계속할 수 있는 경우
-   작업 범위가 원래 계획을 벗어난 경우
-   **중요**: 컨텍스트 창 사용량이 50%를 초과하는 경우(예: 200K 컨텍스트 창의 경우 100,000개 이상의 토큰)

### 3. 핸드오프 프로세스 시작 - 필수 작업

완료 지점에 도달하면 다음을 **반드시** 수행해야 합니다.

1. 지금까지 달성한 내용을 요약합니다.
2. 남은 작업을 명확하게 명시합니다.
3. **필수**: `ask_followup_question` 도구를 사용하여 새 작업을 만들 것을 제안합니다.

\`\`\`xml
<ask_followup_question>
<question>[특정 성과]를 완료했습니다. [남은 작업]을 계속하기 위해 새 작업을 만들까요?</question>
<options>["예, 새 작업 만들기", "아니요, 이 세션에서 계속", "생각해 보겠습니다"]</options>
</ask_followup_question>
\`\`\`

### 4. 컨텍스트가 있는 새 작업 만들기 - 필수 작업

사용자가 새 작업을 만드는 데 동의하면 포괄적인 핸드오프 지침과 함께 `new_task` 도구를 **반드시** 사용해야 합니다.

\`\`\`xml
<new_task>
<context>

# 작업 계속: [간단한 작업 제목]

## 완료된 작업

-   [완료된 항목의 상세 목록]
-   [수정/생성된 특정 파일 포함]
-   [내려진 중요한 결정 기록]

## 현재 상태

-   [프로젝트의 현재 상태에 대한 설명]
-   [실행 중인 프로세스 또는 환경 설정]
-   [주요 파일 및 현재 상태]

## 다음 단계

-   [남은 작업의 상세 목록]
-   [해결해야 할 특정 구현 세부 정보]
-   [알려진 해결 과제]

## 참조 정보

-   [관련 문서 링크]
-   [따라야 할 중요한 코드 스니펫 또는 패턴]
-   [현재 세션 중에 기록된 사용자 기본 설정]

[특정 다음 작업]으로 구현을 계속하십시오.
</context>
</new_task>
\`\`\`

### 5. 상세 컨텍스트 전송 - 필수 구성 요소

새 작업을 만들 때 다음을 항상 **반드시** 포함해야 합니다.

#### 프로젝트 컨텍스트 - 필수

-   프로젝트의 전체 목표와 목적을 **반드시** 포함해야 합니다.
-   주요 아키텍처 결정 및 패턴을 **반드시** 포함해야 합니다.
-   기술 스택 및 종속성을 **반드시** 포함해야 합니다.

#### 구현 세부 정보 - 필수

-   현재 세션에서 생성되거나 수정된 파일을 **반드시** 나열해야 합니다.
-   구현된 특정 함수, 클래스 또는 구성 요소를 **반드시** 설명해야 합니다.
-   따르고 있는 디자인 패턴을 **반드시** 설명해야 합니다.
-   테스트 접근 방식을 **반드시** 간략하게 설명해야 합니다.

#### 진행 상황 추적 - 필수

-   완료된 항목의 체크리스트를 **반드시** 제공해야 합니다.
-   남은 항목의 체크리스트를 **반드시** 제공해야 합니다.
-   발생한 모든 차단 요인이나 과제를 **반드시** 기록해야 합니다.

#### 사용자 기본 설정 - 필수

-   사용자가 언급한 코딩 스타일 기본 설정을 **반드시** 기록해야 합니다.
-   사용자가 요청한 특정 접근 방식을 **반드시** 문서화해야 합니다.
-   사용자가 식별한 우선 순위 영역을 **반드시** 강조 표시해야 합니다.

## 효과적인 핸드오프를 위한 모범 사례 - 필수 지침

### 1. 연속성 유지 - 필수

-   작업 간에 일관된 용어를 **반드시** 사용해야 합니다.
-   이전 결정과 그 근거를 **반드시** 참조해야 합니다.
-   명시적으로 방향을 변경하지 않는 한 동일한 아키텍처 접근 방식을 **반드시** 유지해야 합니다.

### 2. 컨텍스트 보존 - 필수

-   핸드오프에 관련 코드 스니펫을 **반드시** 포함해야 합니다.
-   이전 세션의 주요 토론을 **반드시** 요약해야 합니다.
-   해당되는 경우 특정 파일 및 줄 번호를 **반드시** 참조해야 합니다.

### 3. 명확한 다음 작업 설정 - 필수

-   명확하고 실행 가능한 다음 단계로 핸드오프를 **반드시** 시작해야 합니다.
-   남은 작업의 우선 순위를 **반드시** 지정해야 합니다.
-   내려야 할 모든 결정을 **반드시** 강조 표시해야 합니다.

### 4. 가정 문서화 - 필수

-   구현 중에 내린 모든 가정을 명확하게 **반드시** 명시해야 합니다.
-   사용자 입력이 필요할 수 있는 영역을 **반드시** 기록해야 합니다.
-   잠재적인 대안적 접근 방식을 **반드시** 식별해야 합니다.

### 5. 재개 가능성 최적화 - 필수

-   다음 세션이 즉시 작업을 시작할 수 있도록 핸드오프를 **반드시** 구성해야 합니다.
-   환경 구성이 필요한 경우 설정 지침을 **반드시** 포함해야 합니다.
-   신속한 컨텍스트 복원을 위해 맨 위에 간단한 요약을 **반드시** 제공해야 합니다.

## 예제 작업 핸드오프

### 효과적인 작업 핸드오프의 예 #1:

\`\`\`xml
<new_task>
<context>

# 작업 계속: 사용자 인증 시스템 구현

## 완료된 작업

-   기본 Express.js 서버 구조 생성
-   MongoDB 연결 및 사용자 스키마 구현
-   비밀번호 해싱으로 사용자 등록 엔드포인트 완료
-   Joi를 사용한 입력 유효성 검사 추가
-   등록 엔드포인트에 대한 초기 테스트 스위트 생성

## 현재 상태

-   서버가 포트 3000에서 성공적으로 실행됩니다.
-   MongoDB 연결이 설정되었습니다.
-   등록 엔드포인트(/api/users/register)가 완전히 작동합니다.
-   모든 등록 시나리오에 대해 테스트 스위트가 통과합니다.

## 다음 단계

1. 로그인 엔드포인트(/api/users/login) 구현
    - bcrypt를 사용하여 비밀번호 비교
    - 성공적인 로그인 시 JWT 토큰 생성
    - 잘못된 자격 증명에 대한 적절한 오류 처리 추가
2. 인증 미들웨어 만들기
    - JWT 토큰 확인
    - 사용자 정보 추출
    - 만료된 토큰 처리
3. 인증이 필요한 보호된 경로 추가
4. 비밀번호 재설정 기능 구현

## 참조 정보

-   JWT 비밀은 .env 파일에 저장해야 합니다.
-   routes/users.js의 기존 오류 처리 패턴을 따르십시오.
-   사용자 스키마는 models/User.js에 정의되어 있습니다.
-   테스트 패턴은 tests/auth.test.js에 설정되어 있습니다.

등록 엔드포인트에 설정된 것과 동일한 패턴에 따라 로그인 엔드포인트를 구현하여 계속하십시오.
</context>
</new_task>
\`\`\`

### 비효율적인 작업 핸드오프의 예 #2:

_(참고: "YOLO 모드 구현"을 보여주는 원래 규칙에 제공된 예는 직접적인 핸드오프 컨텍스트 블록이라기보다는 향후 고려 사항이 포함된 일반적인 상태 업데이트에 더 가깝습니다. 진정한 비효율적인 핸드오프는 '현재 상태' 또는 '다음 단계'에 세부 정보가 부족할 수 있습니다.)_

## 작업 핸드오프를 사용하는 경우 - 필수 트리거

다음 시나리오에서는 작업 핸드오프를 **반드시** 시작해야 합니다.

1.  **중요**: 컨텍스트 창 사용량이 50%를 초과하는 경우(예: 200K 컨텍스트 창의 경우 100,000개 이상의 토큰)
2.  단일 세션을 초과하는 **장기 실행 프로젝트**
3.  여러 개별 단계가 있는 **복잡한 구현**
4.  **컨텍스트 창 제한**이 다가오는 경우
5.  더 큰 프로젝트 내에서 **초점 영역을 전환**하는 경우
6.  작업의 다른 부분에 **다른 전문 지식**이 도움이 될 수 있는 경우

**⚠️ 최종 알림 - 중요 지침 ⚠️**

환경 세부 정보 섹션에서 컨텍스트 창 사용량을 **반드시** 모니터링해야 합니다. 50%를 초과하면(예: "105,000 / 200,000 토큰 (53%)") `ask_followup_question` 도구와 `new_task` 도구를 차례로 사용하여 작업 핸드오프 프로세스를 사전에 **반드시** 시작해야 합니다. `new_task` 도구를 **반드시** 사용해야 합니다.

이러한 지침을 엄격히 따르면 작업 간의 원활한 전환을 보장하고 프로젝트 추진력을 유지하며 복잡한 다중 세션 프로젝트에서 작업하는 사용자에게 최상의 경험을 제공할 수 있습니다.

```markdown
## 사용자 상호 작용 및 워크플로 고려 사항

-   **선형 흐름:** 현재 `new_task`를 사용하면 선형 시퀀스가 생성됩니다. 이전 작업이 종료되고 새 작업이 시작됩니다. 이전 작업 기록은 백트래킹을 위해 계속 액세스할 수 있습니다.
-   **사용자 승인:** 항상 제어권을 가지며 핸드오프를 승인하고 Cline이 전달하도록 제안하는 컨텍스트를 수정할 기회가 있습니다.
-   **유연성:** 핵심 `new_task` 도구는 유연한 빌딩 블록입니다. 엄격한 컨텍스트 관리, 작업 분해 또는 기타 창의적인 용도 등 요구 사항에 가장 적합한 워크플로를 만들기 위해 `.clinerules`를 실험해 보십시오.
```