6장: 프롬프트를 통한 동작 조정

5장에서는 시스템 프롬프트의 어셈블리 아키텍처를 분석했습니다. 섹션 등록, 캐시 경계, 다중 소스 합성. 하지만 건축은 단지 뼈대일 뿐입니다. Claude Code를 진정으로 만드는 것은 무엇입니까? "숙련된 엔지니어처럼 행동하는 것"이 ​​거기에 붙은 근육입니다. 뼈대: 신중하게 표현된 행동 지침. 이 장 각각 소스 코드가 포함된 6개의 재사용 가능한 동작 조정 패턴을 추출합니다. 예, 효과 뒤에 숨은 원칙, 템플릿 귀하의 요청에 따라 직접 채택할 수 있습니다.

6.1 행동 조종의 본질: 경계 설정

생성 확률 공간 대규모 언어 모델의 출력은 다음을 통한 샘플링 프로세스입니다. 확률 분포. 시스템 프롬프트의 동작 지시어는 다음과 같습니다. 본질적으로 이 확률 공간에 울타리가 세워졌습니다. 원하는 행동이 일어날 확률과 원하지 않는 행동을 억제하는 것. 하지만 울타리의 표현에 따라 울타리가 솔리드로 기능하는지 여부가 결정됩니다. 벽이나 흐릿한 선.

Claude Code의 시스템 프롬프트 소스 코드 읽기 (restored-src/src/constants/prompts.ts 그리고 restored-src/src/tools/BashTool/prompt.ts), 우리는 다음을 발견했습니다. Anthropic의 엔지니어들은 지침을 마구잡이로 쌓지 않고 형성했습니다. 암시적 패턴 언어. 이러한 패턴이 작동하는 이유는 단지 "올바른 말을 하라"고 하지만 그들의 표현 구조가 다음과 일치하기 때문입니다. 모델의 주의 메커니즘과 지시 따르기 형질.

이 장에서는 이러한 패턴을 명시적으로 설명하고 이를 6가지 동작으로 명명합니다. 스티어링 패턴:

1. 미니멀리즘 지침
2. 점진적인 확대
3. 가역성 인식
4. 도구 선호도 조정
5. 에이전트 위임 프로토콜
6. 숫자 앵커링

6.2 패턴

1: 미니멀리즘 지침

6.2.1 패턴

정의 핵심 아이디어: 모델의 '유용성' 경향을 과도한 엔지니어링을 명시적으로 금지하여 작업의 실제 범위를 지정합니다.

대규모 언어 모델은 자연스럽게 "약간의 추가 작업"을 수행하는 경향이 있습니다. 추가 오류 처리, 문서 주석 보완, 소개 추상화 레이어. 이는 대화 시나리오에서는 미덕이지만 코드 생성의 재앙. 미니멀리즘 지침은 특정 "하지 말아야 할 것"이 더 중요하다는 것을 모델에게 가르치기 위한 반례 "무엇을 해야 하는가"보다 중요합니다.

6.2.2 소스 코드

예 예 1: 조기 추상화에 대한 세 줄의 코드

일회성 작업을 위한 도우미, 유틸리티 또는 추상화를 만들지 마세요. 가상의 미래 요구 사항을 고려하여 설계하지 마세요. 적당한 양의 복잡성은 작업에 실제로 필요한 것입니다. 추론적인 추상화는 없습니다. 하지만 절반만 ​​구현된 구현도 없습니다. 세 개의 유사한 코드 줄 조기 추상화보다 낫습니다.

소스 위치: restored-src/src/constants/prompts.ts:203

마지막 문장 - "유사한 세 줄의 코드가 한 줄의 코드보다 낫습니다. 조기 추상화" - 전체에서 가장 뛰어난 스트로크입니다. 미니멀리즘 지침. 구체적인 수치 임계값을 제공합니다. 세 줄 - 모델에 명확한 기준을 제공합니다. "공통 함수를 추출해야 하는가" 결정. 이 앵커가 없으면 모델은 기본적으로 DRY(Don't Repeat Yourself)로 설정되고 AI 지원 프로그래밍의 맥락은 종종 과도한 추상화로 이어집니다.

예 2: 요청한 것 이상으로 기능을 추가하지 마세요

기능을 추가하거나, 코드를 리팩터링하거나, 이전보다 "개선"하지 마십시오. 물었다. 버그 수정에는 주변 코드를 정리할 필요가 없습니다. 간단한 기능 추가 구성이 필요하지 않습니다. 독스트링, 주석, 유형을 추가하지 마세요 변경하지 않은 코드에 대한 주석. 논리가 다음과 같은 경우에만 주석을 추가하세요. 자명하지 않습니다.

소스 위치: restored-src/src/constants/prompts.ts:201

이 지시문의 구조에 주목하세요. 먼저 일반 원칙("하지 마세요. 요청한 것 이상의 기능을 추가하세요."), 그런 다음 세 가지 특정 반례(버그 수정에는 주변 코드를 정리할 필요가 없습니다. 간단한 기능에는 추가 구성이 필요하지 않으며 설명을 추가하지 마십시오. 변경되지 않은 코드). 이 "일반 규칙 + 반례" 구조는 다음과 같습니다. 모델은 추상적 원리를 매핑해야 하기 때문에 매우 효과적입니다. 지침을 따를 때의 구체적인 시나리오 및 반대 사례 이 매핑에 대한 고정점을 제공합니다.

예 3: 불가능한 시나리오에 대한 방어를 추가하지 않음(개미만 해당)

오류 처리, 대체 또는 유효성 검사를 추가할 수 없는 시나리오에는 추가하지 마세요. 일어나다. 내부 코드와 프레임워크 보장을 신뢰하세요. 시스템에서만 유효성을 검사합니다. 경계(사용자 입력, 외부 API). 기능 플래그를 사용하지 마십시오. 코드만 변경할 수 있는 경우 이전 버전과의 호환성이 심해집니다.

소스 위치: restored-src/src/constants/prompts.ts:202

이 지시문은 일반적인 LLM 행동 패턴을 직접적으로 공격합니다. 지나치게 방어적인 프로그래밍. 이 모델은 광범위한 "최고"를 보았습니다. 연습' 항목을 학습 데이터에 포함하고 있으며 모든 처리를 강조합니다. 가능한 오류. 그러나 실제 내부 코드에서는 많은 오류 경로가 절대 발생하지 않습니다. 트리거됩니다. 이 지시문은 다음을 통해 새로운 판단 체계를 제공합니다. "내부 코드 및 프레임워크 보장을 신뢰하십시오"라는 문구: 구별 시스템 경계와 내부 호출 사이.

6.2.3 작동 이유

미니멀리즘 지침은 세 가지 메커니즘으로 인해 작동합니다.

1. 반례는 긍정적인 규칙보다 따르기가 더 쉽습니다. "X를 하지 마세요"가 "Y만 하세요"보다 더 정확합니다. X의 경계는 Y의 경계보다 더 명확합니다. 모델은 다음을 수행할 수 있습니다. 생성된 각 토큰을 "이것이 X를 수행하고 있습니까?"와 비교하여 확인하십시오.
2. 특정 숫자는 기본 경험적 방법보다 우선 적용됩니다. 숫자 앵커 "세 줄의 반복 코드"는 모델의 내장을 재정의합니다. DRY 휴리스틱. 특정 숫자가 없으면 모델은 다음으로 대체됩니다. 훈련 데이터에서 가장 일반적인 패턴입니다.
3. 시나리오 분류는 모호성을 줄입니다. "a 버그 수정에는 주변 코드 정리가 필요하지 않습니다." "언제 조금 더 추가 작업을 수행해야 합니까?"라는 모호한 질문을 명확하게 분류 작업: "현재 작업은 버그 수정인가요, 아니면 리팩터링인가요?"

6.2.4 재사용 가능

템플릿 [미니멀리즘 지침 템플릿]

작업 범위를 넘어서는 {features/refactoring/improvements}를 추가하지 마세요. {작업 유형 A}에는 {일반적인 과잉 엔지니어링 동작 A}가 필요하지 않습니다. {작업 유형 B}에는 {일반적인 과잉 엔지니어링 동작 B}가 필요하지 않습니다. {N} 줄의 반복 코드가 조기 추상화보다 낫습니다. {경계 조건 지우기}인 경우에만 {추가 조치를 취하세요}.

6.3

패턴 2: 점진적 에스컬레이션

6.3.1 패턴

정의 핵심 아이디어: '포기'와 '무한' 사이의 중간 경로를 정의합니다. 루프'를 통해 모델이 먼저 진단하고 조정한 다음 마지막으로 안내합니다. 도움을 요청하세요.

LLM은 실패에 직면할 때 두 가지 극단적인 경향이 있습니다. 포기하고 사용자에게 도움을 요청하거나 정확한 방법을 끊임없이 다시 시도합니다. 동일한 작업. 점진적 에스컬레이션 패턴은 모델의 명확한 3단계를 정의하여 장애 대응을 합리적인 범위로 프로토콜 - 진단, 조정, 에스컬레이션.

6.3.2 소스 코드

예 예 1: 3단계 오류 처리

접근 방식이 실패하는 경우 전술을 전환하기 전에 이유를 진단하십시오. 오류를 읽고, 가정을 확인하고 집중적인 수정을 시도해 보세요. 동일한 작업을 다시 시도하지 마세요 단 한 번의 실패 후에도 실행 가능한 접근 방식을 포기하지 마십시오. 실제로 문제가 발생한 경우에만 Ask_user_question을 사용하여 사용자에게 에스컬레이션하세요. 조사 후 마찰에 대한 첫 번째 반응이 아닙니다.

소스 위치: restored-src/src/constants/prompts.ts:233

이 지시어는 단일로 완전한 실패 처리 프로토콜을 정의합니다. 절:

• 1단계(진단): "오류를 읽고 가정을 확인하세요." -- 먼저 무슨 일이 일어났는지 이해해
• 2단계(조정): "집중적인 수정 시도" -- 목표를 설정합니다. 진단에 따른 수정
• 3단계(에스컬레이션): "사용자에게 에스컬레이션합니다... 정말로 막혔습니다." -- 진짜 막다른 골목에서만 도움을 요청하세요.

핵심 설계는 두 가지 "하지 말 것" 사이의 긴장감에 있습니다: "재시도하지 마십시오" 동일한 작업을 맹목적으로 수행"(무한 루프 금지) 및 "하지 않음" 단일 실패 후 실행 가능한 접근 방식을 포기합니다."(조기 금지 포기). 이 양면 제약 조건은 모델이 중간을 찾도록 강제합니다. 두 극단 사이의 길.

예 2: Git 작업에 대한 진단 우선

파괴적인 작업을 실행하기 전(예: git Reset --hard, git push --force, git checkout --), 더 안전한 대안이 있는지 고려합니다. 동일한 목표를 달성하는 것입니다. 파괴적인 작업은 다음과 같은 경우에만 사용하세요. 정말 최선의 접근 방식입니다.

소스 위치: restored-src/src/tools/BashTool/prompt.ts:306

이 지시문에는 "더 안전한 대안이 있습니까?" 평가가 필요합니다. 고위험 작업을 실행하기 전에. 단순히 금지하는 것이 아니다. 하지만 모델이 먼저 추론 단계를 완료해야 합니다. 선택을 하는 것.

예 3: 절전 명령에 대한 진단 대안

수면 루프에서 실패한 명령을 재시도하지 말고 근본 원인을 진단하십시오.

소스 위치: restored-src/src/tools/BashTool/prompt.ts:318

이는 점진적 에스컬레이션 패턴의 가장 최소한의 형태입니다. 금지 사항을 동시에 포함하는 단일 문장("재시도하지 마십시오. 수면 루프") 및 대안("근본 원인 진단")이 있습니다. 특히 일반적인 LLM 동작 패턴을 대상으로 합니다. - 명령이 실행될 때 실패하면 모델이 루프에서 sleep && retry될 수 있으며 이는 다음과 같은 경우에 재앙이 됩니다. 대화형 환경.

6.3.3 작동 이유

점진적 에스컬레이션의 효과는 다음과 같습니다.

1. 양면 제약은 긴장감을 조성합니다. 동시에 정의 "너무 빨리 포기하지 마세요"와 "무한히 재도전하지 마세요"를 강요합니다. 각 실패 후에 명시적인 추론 단계를 수행하는 모델: "am 맹목적으로 재시도하는 건가요, 아니면 정보를 바탕으로 조정하는 건가요?"
2. 단계 순서는 사고 사슬에 매핑됩니다. 진단 -> 조정 -> 에스컬레이션 시퀀스는 모델의 체인과 자연스럽게 정렬됩니다. 생각. 모델은 이 프로토콜을 다음 단계로 직접 인코딩할 수 있습니다. 추론 체인.
3. 최후의 수단으로 에스컬레이션합니다. '사용자에게 묻기'를 최종으로 설정 옵션은 불필요한 상호 작용 중단을 줄이고 개선합니다. 자율 완료율.

6.3.4 재사용 가능

템플릿 [점진적 에스컬레이션 템플릿]

{작업}이 실패하면 먼저 {진단 조치}({특정 진단 단계})를 수행합니다. 동일한 작업을 맹목적으로 다시 시도하지 말고 실행 가능한 접근 방식을 포기하지 마십시오. 한 번의 실패 후에도 마찬가지입니다. 첫 번째 대응이 아닌 {escalation Condition}인 경우에만 {escalate action}입니다. 마찰에.

6.4

패턴 3: 가역성 인식

6.4.1 패턴

정의 핵심 아이디어: 가역성과 폭발성을 기준으로 작업을 분류합니다. 반경, 고위험 작업에 대한 확인 프레임워크를 구축합니다.

클로드에서 가장 복잡하고 세심하게 디자인된 패턴입니다. 코드의 신속한 엔지니어링. 단순히 "위험한 작업"을 나열하는 것이 아닙니다. 하지만 완전한 위험 평가 프레임워크를 구축하여 모델을 교육합니다. "두 번 측정하고 한 번 자르세요."

6.4.2 소스 코드

예 예 1: 가역성 분석 프레임워크

행동의 가역성과 폭발 반경을 신중하게 고려하십시오. 일반적으로 파일 편집이나 실행과 같은 되돌릴 수 있는 로컬 작업을 자유롭게 수행할 수 있습니다. 테스트. 그러나 되돌리기 어려운 작업의 경우 공유 시스템에 영향을 미칩니다. 현지 환경이 위험하거나 파괴적일 수 있으므로 확인하세요. 계속하기 전에 사용자와 상담하세요.

소스 위치: restored-src/src/constants/prompts.ts:258

이 지시문은 가역성 및 폭발 반경. 이 두 가지 차원은 2x2 결정 매트릭스를 형성합니다.

그림 6-1: 가역성과 폭발 반경 결정 매트릭스. Claude 코드는 이 두 가지를 사용하여 작업을 네 가지 범주로 분류합니다. '자유롭게 실행'에서 '필수 확인'까지

예 2: 고위험 작업의 전체 목록

소스 코드는 다음과 같은 네 가지 주요 작업 범주를 제공합니다. 확인, 각각 구체적인 예 포함 (restored-src/src/constants/prompts.ts:261-264):

예 3: Git 안전 프로토콜

Git 안전 프로토콜:

• Git 구성을 절대 업데이트하지 마세요.
• 절대 파괴적인 git 명령을 실행하지 마세요(push --force, Reset --hard, checkout ., 복원 ., clean -f, 분기 -D) 사용자가 명시적으로 요청하지 않는 한 행위.
• 사용자가 아닌 이상 후크(--no-verify, --no-gpg-sign 등)를 건너뛰지 마십시오. 명시적으로 요청합니다
• 메인/마스터에 강제 푸시를 실행하지 마세요. 사용자가 요청할 경우 경고합니다.
• 중요: 사용자가 수정하지 않는 한 항상 새로운 커밋을 생성하세요. 명시적으로 git 수정을 요청합니다. 사전 커밋 후크가 실패하면 커밋이 발생하지 않았습니다. 따라서 --amend는 PREVIOUS 커밋을 수정합니다. 작업이 파괴되거나 이전 변경 사항이 손실될 수 있습니다.

소스 위치: restored-src/src/tools/BashTool/prompt.ts:87-94

Git 안전 프로토콜은 가장 세련된 구현입니다. 가역성 인식 패턴. 몇 가지 디자인 포인트에 주목하세요:

1. 대문자 사용 금지 -- "피하다" 또는 "하지 않으려고 노력하다"가 아니라 절대적입니다. 금지. 대문자는 "증가"와 유사하게 작동합니다. 무게에 주의하세요'라는 메시지가 표시됩니다.
2. "사용자가 명시적으로 요청하지 않는 한" -- 각 NEVER 규칙은 다음과 같습니다. 명시적인 면제 조건을 사용하면 모델이 사용자가 명시적으로 요청하면 거부합니다.
3. 중요한 표시 + 인과관계 설명 -- 가장 미묘한 규칙 수정과 새 커밋에 대해 CRITICAL로 표시될 뿐만 아니라 규칙이 존재하는 이유를 설명합니다(후크가 실패하면 커밋이 아직 발생하지 않았으며 수정하면 이전 커밋이 수정됩니다.) 인과적 설명을 통해 모델은 사고의 정신을 일반화할 수 있습니다. 단순히 문자 그대로의 텍스트를 따르는 것이 아닌 새로운 시나리오에 대한 규칙 기계적으로.

예 4: 일회성 승인은 영구 승인과 동일하지 않습니다. 권한 부여

사용자가 작업(git push 등)을 한 번 승인했다고 해서 해당 작업이 승인된 것은 아닙니다. 모든 상황에서 이를 승인하므로 사전에 조치가 승인되지 않는 한 CLAUDE.md 파일과 같은 지속 가능한 지침은 항상 먼저 확인하세요. 승인은 지정된 범위를 의미하며 그 범위를 초과하지 않습니다. 범위를 일치시키세요 실제로 요청된 내용에 대한 귀하의 행동.

소스 위치: restored-src/src/constants/prompts.ts:258

이 지시는 위험한 LLM 경향을 공격합니다. 단일 권한부터 범용 권한까지. 모델은 다음에서 볼 수 있습니다. 사용자가 이전에 git push에 동의한 후 실행하는 컨텍스트 이후의 다른 시나리오에서는 확인 없이 푸시됩니다. 이 규칙 '라는 문구를 통해 권한 범위에 대한 정확한 개념을 확립합니다. "지정된 범위, 그 이상은 아닙니다."

6.4.3 작동 이유

가역성 인식의 효과는 다음에서 비롯됩니다.

1. 차원 분석이 열거형을 대체합니다. 나열보다는 모든 위험한 작업(완전히 불가능함)을 가르칩니다. 두 가지 차원을 사용하여 자율적으로 평가하는 모델 "가역성" 및 "폭발 반경". 구체적인 예 목록은 다음과 같습니다. 포괄적인 적용 범위가 아닌 보충 교정입니다.
2. 정확한 면제를 생성하지 않는 한 절대 +하지 마세요. 절대 금지 + 명시적 예외는 모델의 회색 영역의 "창의적인 해석".
3. 인과적 설명은 일반화를 촉진합니다. "이유"를 설명합니다. 규칙이 존재하면(수정의 인과 사슬과 같은) 모델이 다음을 수행할 수 있습니다. 보이지 않는 시나리오에서 올바른 행동을 이끌어냅니다.
4. "두 번 측정하고 한 번 자르세요"를 니모닉으로 사용합니다. 이 영어 관용구는 끝은 전체 프레임워크의 인지적 앵커 역할을 하며, 모델이 다음과 같은 경우 전체 위험 평가 프로토콜을 기억하도록 돕습니다. 가장자리 케이스에 직면합니다.

6.4.4 재사용 가능

템플릿 [가역성 인식 템플릿]

작업을 실행하기 전에 가역성과 폭발 반경을 평가하십시오. {list of reversible local actions}을(를) 자유롭게 실행할 수 있습니다. {되돌릴 수 없는/공유 시스템} 작업의 경우 실행하기 전에 사용자에게 확인하세요.

절대:

• {위험한 작업 1}, 사용자가 명시적으로 요청하지 않는 한
• {위험한 작업 2}, 사용자가 명시적으로 요청하지 않는 한
• [중요] {가장 미묘하게 위험한 작업}, 왜냐하면 {인과적 설명} 때문입니다.

사용자가 {작업}을 한 번 승인한다고 해서 모든 상황에서 승인을 의미하는 것은 아닙니다. 권한은 지정된 범위로 제한됩니다.

6.5

패턴 4: 도구 기본 설정 조정

6.5.1 패턴

정의 핵심 아이디어: 일반 Bash에서 모델 도구 선택 리디렉션 도구 설명 텍스트를 통해 특수 도구에 대한 명령.

Claude Code는 풍부한 전문 도구(읽기, 편집, 쓰기, Glob, Grep), 그러나 모델의 훈련 데이터는 cat, grep, sed로 가득 차 있습니다. find 및 기타 Unix 명령. 지도 없이 자연스럽게 모델이 Bash 도구를 통해 이러한 명령을 실행하는 경향이 있습니다. 도구 기본 설정 조정 패턴은 리디렉션 지침을 모델의 기본값을 가로채서 도구 설명의 가장 빠른 위치 도구 선택 경로.

6.5.2 소스 코드

예 예 1: Bash 도구 설명의 전면 로드 차단

중요: 이 도구를 사용하여 find, grep, cat, head, tail, sed를 실행하지 마십시오. awk 또는 echo 명령(명시적으로 지시하지 않거나 사용자가 지정한 후에는 제외) 전용 도구가 작업을 수행할 수 없음을 확인했습니다. 대신 적절한 전용 도구를 사용하면 훨씬 더 나은 경험을 제공할 수 있습니다. 사용자:

• 파일 검색: Glob 사용(find 또는 ls 아님)
• 콘텐츠 검색: Grep 사용(grep 또는 rg 아님)
• 파일 읽기: 읽기 사용(cat/head/tail 아님)
• 파일 편집: 편집 사용(sed/awk 아님)
• 파일 쓰기: 쓰기 사용(echo >/cat <<EOF 아님)
• 통신: 텍스트를 직접 출력합니다(echo/printf 아님).

소스 위치: restored-src/src/tools/BashTool/prompt.ts:280-291 (getSimplePrompt()에 의해 조립됨)

이 지침의 디자인은 세 가지 정교함을 갖추고 있습니다.

1. 위치 우선순위. 이 텍스트는 기본 기능 바로 다음에 나오는 Bash 도구 설명 설명. 모델이 Bash 호출을 고려하기 시작하면 도구에서 이 리디렉션 지시문은 도구의 첫 번째 제약 조건입니다. 만남.
2. 삽입 비교가 아님. 각 매핑 규칙에는 "무엇을 사용하는 것"과 "사용하지 않는 것" 형식입니다. Use Grep (NOT grep or rg)은 직접 이진 비교를 생성합니다. 모델의 결정 주저를 줄입니다.
3. 사용자 경험의 정당성. "이것은 훨씬 더 나은 경험을 제공할 것입니다. 사용자 경험'은 이 규칙을 따르는 이유를 제공합니다. 단순히 무조건적인 명령을 내리는 것이 아니라.

예 2: 시스템 프롬프트의 중복 강화

관련 전용 도구가 있는 경우 Bash를 사용하여 명령을 실행하지 마십시오. 제공됩니다. 전용 도구를 사용하면 사용자가 더 잘 이해하고 당신의 작업을 검토하십시오. 이는 사용자를 지원하는 데 매우 중요합니다.

• 파일을 읽으려면 cat, head, tail 또는 sed 대신 Read를 사용하십시오.
• 파일을 편집하려면 sed 또는 awk 대신 Edit를 사용하십시오.
• 파일을 생성하려면 heredoc 또는 에코 리디렉션을 사용하여 cat 대신 Write를 사용하십시오.
• 파일을 검색하려면 find나 ls 대신 Glob을 사용하세요.
• 파일 내용을 검색하려면 grep 또는 rg 대신 Grep을 사용하십시오.
• 시스템 명령 및 터미널 전용 Bash 사용 예약 쉘 실행이 필요한 작업.

소스 위치: restored-src/src/constants/prompts.ts:291-302

이 콘텐츠는 다음의 매핑 테이블과 거의 중복됩니다. 배쉬 도구 설명. 이건 실수가 아니라 의도적인거임 중복 강화. 두 명령 모두에 동일한 지시문을 배치합니다. 시스템 프롬프트 및 도구 설명 위치는 모델의 주의가 어느 경로로 이동하면 제약 조건에 직면하게 됩니다.

예 3: 내장 도구에 대한 조건부 적용

const embedded = hasEmbeddedSearchTools()

const toolPreferenceItems = [
  ...(embedded
    ? []
    : [
        `File search: Use ${GLOB_TOOL_NAME} (NOT find or ls)`,
        `Content search: Use ${GREP_TOOL_NAME} (NOT grep or rg)`,
      ]),
  `Read files: Use ${FILE_READ_TOOL_NAME} (NOT cat/head/tail)`,
  // ...
]

소스 위치: restored-src/src/tools/BashTool/prompt.ts:280-291

Ant 내부 빌드(ant-native 빌드)가 find 및 grep을 매핑하는 경우 쉘 별칭을 통해 내장된 bfs 및 ugrep에 대한 리디렉션 독립형 Glob/Grep 도구는 불필요해집니다. 소스코드는 건너뛴다 이 두 가지 매핑은 hasEmbeddedSearchTools() 조건을 통해 이루어집니다. 이것 조건부 적응은 프롬프트에 다음이 포함되지 않도록 보장합니다. 자기 모순적인 지시.

6.5.3 작동 이유

도구 선호 조정의 효과는 다음에서 비롯됩니다.

1. 가장 빠른 시점에서 결정 경로를 가로채기. 모델 도구를 선택할 때 먼저 도구 설명을 읽습니다. "하지 마세요"를 삽입하면 X에는 ​​나를 사용하고 대신 Y를 사용하세요"라는 Bash 도구 설명은 다음과 같습니다. 모델이 선택을 하기 전에 개입하는 것과 같습니다.
2. 이진 비교는 모호성을 제거합니다. 형식 Use Grep (NOT grep or rg)은 개방형 선택(" which 검색할 도구")를 이진 판단("Grep 도구 또는 grep 명령")을 사용하여 결정의 복잡성을 줄입니다.
3. 중복 강화로 주의 사각지대를 커버합니다. 모델의 주의력은 긴 맥락에서 감소합니다. 같은 것을 배치 서로 다른 두 위치에 제약을 가하면 제약 조건이 "표시"됩니다.

6.5.4 재사용 가능

템플릿 [도구 기본 설정 조정 템플릿]

{작업 카테고리}가 필요한 경우 {특수 도구 이름}({일반 대체 명령} 아님)을 사용하세요. 전문 도구를 사용하면 {사용자 경험 이점}을 제공합니다.

{일반 도구 이름}은 {적법한 용도의 명시적 목록}에만 사용해야 합니다. 확실하지 않은 경우 기본적으로 특수 도구를 사용하고 {대체 조건}인 경우에만 {일반 도구}로 대체합니다.

6.6

패턴 5: 에이전트 위임 프로토콜

6.6.1 패턴

정의 핵심 아이디어: 다중 에이전트에 대한 정확한 위임 규칙 정의 협업, 재귀 생성 방지, 컨텍스트 오염 및 결과 제작.

AI 시스템이 하위 에이전트를 생성할 수 있으면 새로운 실패 모드가 나타납니다. 재귀적으로 자신을 무한히 생성할 수 있고, 하위 에이전트를 엿볼 수도 있습니다. 중간 출력(자체 컨텍스트를 오염시키거나)을 조작할 수 있습니다. 하위 에이전트가 반환되기 전의 결과입니다. 에이전트 위임 프로토콜 일련의 정확한 규칙을 통해 이러한 실패 모드를 방지합니다.

6.6.2 소스 코드

예 예 1: 포크 대 신규 에이전트 선택 프레임워크

중간 도구 출력이 그렇지 않은 경우 자신을 포크하십시오(subagent_type 생략). 귀하의 상황에 맞게 유지할 가치가 있습니다. 기준은 질적입니다. 이 출력이 다시 표시됩니다." — 작업 크기가 아닙니다.

• 연구: 개방형 질문을 포크합니다. 연구가 세분화될 수 있는 경우 독립적인 질문인 경우 하나의 메시지에서 병렬 포크를 실행합니다. 포크가 친다 이를 위한 새로운 하위 에이전트 - 컨텍스트를 상속하고 캐시를 공유합니다.
• 구현: 그 이상을 요구하는 구현 작업을 포크하는 것을 선호합니다. 몇 가지 편집.

소스 위치: restored-src/src/tools/AgentTool/prompt.ts:83-88

이 지시문은 포크 사이의 선택 기준을 설정합니다. (컨텍스트 상속 분기) 및 새로운 에이전트(완전히 새로운 에이전트). 그만큼 중요한 통찰력은 기준이 작업 크기가 아니라 "내가 나중에 이 출력을 다시 참조하세요." 이 정성적 기준은 아래의 두 가지 구체적인 시나리오와 결합하면 다소 모호합니다(연구 및 구현) 모델에 충분한 앵커링을 제공합니다.

예 2: "보지 마세요" - 상황 위생 규칙

엿보지 마십시오. 도구 결과에는 output_file 경로가 포함됩니다. 읽지 않거나 사용자가 명시적으로 진행 확인을 요청하지 않는 한 이를 종료합니다. 당신은 완료 알림; 그것을 믿으십시오. 비행 중에 성적표 읽기 포크의 도구 소음을 사용자의 컨텍스트에 삽입하여 포크 지점을 무효화합니다.

소스 위치: restored-src/src/tools/AgentTool/prompt.ts:91

"Don't peek"은 Claude 전체에서 가장 창의적인 문구 중 하나일 수 있습니다. 코드 프롬프트. 두 가지 일상 단어를 사용하여 정확하게 설명합니다. 복잡한 기술적 제약: 하위 에이전트의 중간 내용을 읽지 마세요. 출력 파일. 이어지는 설명에서는 그 이유를 설명합니다. 하위 에이전트의 도구 소음을 주요 에이전트의 컨텍스트로 끌어들입니다. 포크의 목적을 무효화합니다(주 컨텍스트를 깨끗하게 유지).

이 규칙에 해당하는 엔지니어링 문제는 다음과 같습니다. 하위 에이전트의 결과는 주 에이전트가 가지고 있는 파일에 기록됩니다. 읽기 도구를 통해 읽을 수 있는 능력. 주체가 중간을 읽는다면 하위 에이전트가 완료되기 전에 결과가 반쯤 완성된 도구 호출 출력이 주 에이전트의 컨텍스트 창에 들어가 귀중한 시간을 낭비하게 됩니다. 토큰예산.

예 3: "경주하지 마세요" -- 결과 조작 보호

경주하지 마십시오. 발사 후에는 포크가 무엇을 발견했는지에 대해 아무것도 알 수 없습니다. 산문이 아닌 어떤 형식으로든 포크 결과를 조작하거나 예측하지 마십시오. 요약 또는 구조화된 출력. 알림은 사용자 역할로 도착합니다. 나중에 메시지를 보내세요. 그것은 결코 당신이 직접 쓰는 것이 아닙니다. 만약 사용자는 알림이 도착하기 전에 후속 조치를 요청하고 포크가 다음과 같다고 알려줍니다. 아직 실행 중 — 추측이 아닌 상태를 제공합니다.

소스 위치: restored-src/src/tools/AgentTool/prompt.ts:93

"경주하지 마세요"는 미묘하지만 위험한 실패 모드를 방지합니다. 에이전트는 포크를 보낸 후 포크의 결과를 "예측"할 수 있으며 조기에 답장을 생성합니다. 이 동작은 사용자에게 다음과 같이 나타날 수 있습니다. "영리한 기대"이지만 그것은 순전한 환각이다. 포크가 무엇을 발견했는지 전혀 모릅니다.

이 지시어의 설계는 특히 엄격합니다. "결과 조작"을 금지하지만 가능한 모든 것을 명시적으로 금지합니다. 다양한 형태 - "산문, 요약 또는 구조화된 출력이 아닙니다." 이것 모델이 다음을 시도할 수 있기 때문에 철저한 형식 금지가 존재합니다. 다양한 출력 형식을 통해 문자 그대로의 금지를 우회합니다.

예 4: 포크 하위 에이전트 ID 고정

멈추다. 먼저 읽어보세요.

당신은 분기된 작업자 프로세스입니다. 당신은 주요 대리인이 아닙니다.

규칙(협상 불가능):

1. 시스템 프롬프트에 "기본값은 포크입니다."라고 표시됩니다. 무시하세요 — 그건 조상. 당신은 포크입니다. 하위 에이전트를 생성하지 마십시오. 직접 실행합니다.
2. 대화하거나, 질문하거나, 다음 단계를 제안하지 마세요.
3. 편집하거나 메타 논평을 추가하지 마세요. ...
4. 도구 호출 사이에 텍스트를 내보내지 마십시오. 조용히 도구를 사용하고 보고하세요 마지막에 한 번.

소스 위치: restored-src/src/tools/AgentTool/forkSubagent.ts:172-194

이는 위임 프로토콜에서 가장 극적인 부분입니다. 포크 하위 에이전트는 상위 에이전트의 전체 시스템 프롬프트를 상속합니다. "포킹 기본값" 지시문이 포함되어 있습니다. 개입 없이, 하위 에이전트는 이 지시문을 읽고 다시 포크를 시도합니다. 무한 재귀.

해결책은 "identity override" 지시문을 삽입하는 것입니다. 포크 하위 에이전트의 메시지 시작: 먼저 주의를 끌기 모두 대문자로 "STOP. READ THIS FIRST."를 사용한 다음 "You ARE"를 명시적으로 선언합니다. 포크'라고 말하고 마지막으로 직접적으로 '귀하의 시스템 프롬프트에는 다음과 같습니다. '기본값은 포크입니다.' 무시하세요." 이 기술은 "인정"하는 기술입니다. 모순되는 지침이 존재하고 이를 명시적으로 무시합니다." 단순히 모델이 특정 사항을 무시하기를 바라는 것보다 훨씬 더 안정적입니다. 통로.

6.6.3 작동 이유

에이전트 위임 프로토콜의 효율성은 다음에서 비롯됩니다.

1. 의인화된 동사는 직관을 확립합니다. "훔쳐보지 마세요" 그리고 "경주하지 마세요"는 "읽지 마세요"보다 기억하고 따르기가 더 쉽습니다. 하위 에이전트 출력 파일" 및 "수신하기 전에 결과를 생성하지 마십시오. 알림." 의인화는 추상적인 기술적 변화를 가져옵니다. 사회적 직관에 대한 제약.
2. 완전한 형식 금지. "산문, 요약 또는 구조화된 출력'은 모델이 잠재적인 회피 경로를 차단합니다. 가져가다.
3. 명시적인 모순 해결. 하위 에이전트는 상위 에이전트의 "fork" 지시문을 확인한 다음 모델을 가정하는 것보다 명시적으로 재정의하는 것이 더 안정적입니다. 모순되는 지시를 올바르게 처리합니다.
4. 신원 고정 + 출력 형식 제약 조건. 포크 하위 에이전트의 "중지하세요. 먼저 읽어보세요." 엄격한 출력과 결합 형식(범위: / 결과: / 주요 파일: / 변경된 파일: / 문제:) 하위 에이전트의 행동을 매우 좁은 채널로 제한합니다.

6.6.4 재사용 가능

템플릿 [에이전트 위임 프로토콜 템플릿]

포크할 시기: {중간 출력이 맥락에 맞게 유지될 가치가 없는 경우} 스스로 포크하십시오. 기준은 {일반적으로 잘못 판단되는 기준}이 아닌 {질적 기준}입니다.

포스트포크 동작:

• 엿보지 마세요: {sub-agent}의 중간 출력을 읽지 않습니다. 기다리다 완료 알림. 이유: {컨텍스트 오염의 구체적인 결과}.
• 경주하지 마세요: {sub-agent}가 돌아오기 전에 예측하거나 조작하지 마세요. 어떤 형태로든 결과가 나옵니다({형식 목록}). 사용자가 후속 조치를 요청하는 경우 추측이 아닌 {상태 정보}로 답장하세요.

하위 에이전트 ID 포크: 당신은 주체가 아닌 분기된 작업자 프로세스입니다. {재귀를 유발할 수 있는 상위 프롬프트의 지시문}은 다음에 적용되지 않습니다. 귀하는 직접 실행하고 더 이상 위임하지 않습니다.

6.7 패턴 6:

숫자 고정

6.7.1 패턴

정의 핵심 아이디어: 모호한 정성적 설명을 정확한 설명으로 대체합니다. 모델에 직접 측정 가능한 출력 눈금자를 제공합니다.

"더 간결하게", "짧게 유지", "너무 장황하게 말하지 마세요" -- 질적 지시사항은 제약력이 거의 없다. "간결함"에 대한 모델의 이해는 훈련의 분포에 따라 달라집니다. 도메인과 스타일에 따라 달라지는 데이터입니다. 숫자 앵커링은 특정 제공을 통해 측정 가능한 제약에 대한 주관적인 판단 숫자.

6.7.2 소스 코드

예 예 1: 도구 호출 간의 단어 제한

길이 제한: 도구 호출 사이에 텍스트를 25단어 이하로 유지합니다. 최종 유지 작업에 더 자세한 내용이 필요한 경우를 제외하고 100단어 이하로 응답하세요.

소스 위치: restored-src/src/constants/prompts.ts:534

이 지시어는 현재 Anthropic 내부 사용자에게만 활성화됩니다. (개미 전용), 다음 주석이 포함됩니다.

// Numeric length anchors — research shows ~1.2% output token reduction vs
// qualitative "be concise". Ant-only to measure quality impact first.

소스 위치: restored-src/src/constants/prompts.ts:527-528

1.2% 출력 토큰 감소는 별것 아닌 것처럼 들릴 수도 있지만, Claude Code가 매일 처리하는 요청량, 절대값 이 비율의 비용 절감 효과는 상당합니다. 더 중요한 것은, 이 1.2%는 단지 "간결하다"를 "25단어 이하"로 대체함으로써 달성된 것입니다. -- 코드 변경이 없으며 순수 프롬프트 최적화입니다.

두 숫자 앵커의 서로 다른 디자인을 확인하세요.

• ≤25 단어(도구 호출 간): 이는 엄격한 제약입니다. 도구 호출 사이의 텍스트는 일반적으로 불필요합니다. 모델은 사용자에게 설명하는 대신 다음 도구를 직접 호출합니다. 하고 있어요.
• 100단어 이하(최종 답변): 제외됩니다. 조건("작업에 더 자세한 내용이 필요하지 않는 한"), 왜냐하면 최종 응답 길이는 실제로 작업 복잡성에 따라 달라집니다.

예 2: 포크 하위 에이전트에 대한 보고서 길이 제한

8. 지침에서 달리 명시하지 않는 한 보고서를 500단어 미만으로 유지하십시오. 사실적이고 간결하게 작성하세요.

소스 위치: restored-src/src/tools/AgentTool/forkSubagent.ts:186

포크 하위 에이전트의 500단어 제한은 명확한 엔지니어링 목표를 제공합니다. 하위 에이전트의 보고서는 주 에이전트의 컨텍스트에 삽입되고 지나치게 긴 보고서는 주체의 컨텍스트 창을 낭비합니다. 500단어 대략 600-700개의 토큰에 해당합니다. "충분한 정보 제공"과 "맥락 공간 보존".

예 3: 커밋 메시지 길이 지침

"이유"에 초점을 맞춘 간결한(1-2 문장) 커밋 메시지 초안을 작성하세요. "무엇"보다는

소스 위치: restored-src/src/tools/BashTool/prompt.ts:103

"1-2 문장"은 단어 개수가 아닌 숫자 앵커링의 또 다른 형태입니다. 하지만 문장 수. 이 앵커는 콘텐츠 지침과 결합되어 있습니다. "'무엇'이 아닌 '왜'에 초점을 맞추는 동시에 길이와 품질 모두.

6.7.3 Ant 전용

실험결과 숫자 앵커링 패턴은 몇 가지 신속한 최적화 중 하나입니다. 명시적으로 정량화된 효과 데이터가 포함된 Claude Code:

표 6-1: Numeric Anchoring에 대한 Ant 단독 실험 결과. 현재 내부 사용자만 품질 영향을 측정할 수 있도록 활성화되어 있습니다. 배포를 확장하기 전에

ant-only의 점진적인 출시 전략은 그 자체로 주목할 만합니다. 그만큼 소스 코드에서 조건부 확인:

...(process.env.USER_TYPE === 'ant'
  ? [
      systemPromptSection(
        'numeric_length_anchors',
        () => 'Length limits: keep text between tool calls to ≤25 words...',
      ),
    ]
  : []),

이 패턴은 Claude Code의 프롬프트 전체에서 반복적으로 나타납니다. 행동 지침이 먼저 내부 사용자에게 공개되고 데이터가 수집한 후 외부로 출시할지 여부가 결정됩니다. 사용자. 이는 프롬프트 엔지니어링의 A/B 테스트 방법론입니다.

6.7.4 작동 이유

숫자 앵커링의 효과는 다음과 같습니다.

1. 주관적인 해석을 제거합니다. "25단어"는 모호하지 않습니다. "간결하다"는 것이 아닙니다. 모델은 각 토큰을 생성한 후 계산할 수 있습니다. 임계값에 접근하고 있는지 판단합니다.
2. 고정 효과. 인지 심리학 연구에 따르면 인간은 수량 추정을 할 때 이전 숫자에 기반을 둡니다. LLM 동작은 유사합니다. 프롬프트에 나타나는 숫자는 출력 길이에 대한 기준점.
3. 하드 제약 + 소프트 면제 조합. "25단어 이하"는 엄격한 제약; "작업에 더 자세한 내용이 필요하지 않는 한"은 소프트입니다. 면제. 이 조합을 통해 모델은 숫자로 기본 설정됩니다. 합리적인 상황에서 돌파구를 허용하면서 제한하십시오.

6.7.5 재사용 가능

템플릿 [숫자 고정 템플릿]

길이 제한:

• {출력 유형 A}: ≤{N} 단어/문장/줄을 유지합니다.
• {출력 유형 B}: {면제 조건}이 아닌 한 ≤{M} 단어/문장/줄을 유지합니다. 사실적이고 간결하게 작성하세요.

6.8 패턴 요약

다음 표에는 6가지 행동 조정 패턴이 요약되어 있습니다. 이 장에서는 각각 대표적인 소스 코드 인용문이 포함되어 있습니다. 직접 재사용 가능한 프롬프트 템플릿:

표 6-2: 6가지 행동 조종 패턴 요약. 각 패턴 명확하게 적용 가능한 시나리오와 재사용 가능한 템플릿 구조가 있습니다.

6.9

교차 패턴 디자인 원칙 이 6가지 패턴을 검토하면서 몇 가지 기본 교차 패턴 디자인 원칙이 등장합니다:

원칙 1: 부정적인 정의가 긍정적인 설명보다 성능이 뛰어납니다. "X를 하지 마세요"는 "Y를 하세요"보다 모델이 따르기가 더 쉽습니다. 금지의 경계가 허가의 경계보다 더 명확합니다. 6개 패턴 중 5개는 "하지 마세요"와 같은 부정 형식을 광범위하게 사용합니다. / "절대로" / "아니요."

원칙 2: 구체적인 예는 추상 규칙에 대한 교정자입니다. 모든 추상 규칙("가역성 고려")은 다음 목록과 쌍을 이룹니다. 구체적인 예("git Reset --hard, push --force..."). 예는 다음과 같습니다 규칙을 대체하는 것이 아니라 보정 포인트를 사용하여 모델을 돕습니다. 규칙의 적용 범위와 세분성을 이해합니다.

원칙 3: 인과관계 설명은 일반화를 촉진합니다. 규칙이 적용되는 경우 "왜냐하면..."이라는 설명이 수반됩니다(예: 수정 및 새 커밋), 모델은 다음에서 규칙의 정신을 파생할 수 있습니다. 보이지 않는 시나리오. 순전히 필수 규칙은 훈련 내에서만 작동합니다. 분포; 인과적 설명을 통해 규칙은 문자 그대로를 초월할 수 있습니다. 텍스트.

원칙 4: 중복성은 의도적입니다. 도구 기본 설정 조정 두 위치에 동일한 매핑 테이블을 배치합니다. 가역성 인식 시스템 프롬프트와 Bash 도구 모두에서 Git 안전 규칙을 정의합니다. 설명. 이러한 중복은 과실이 아니라 공학적 주의력 저하를 측정합니다.

원칙 5: 점진적 출시는 신속한 엔지니어링의 일부입니다. 숫자 앵커링(Numeric Anchoring)의 개미 전용 실험은 그 프롬프트를 보여줍니다. 수정에는 A/B 테스트와 점진적인 출시도 필요합니다. 코드 변경. USER_TYPE === 'ant' 조건부 확인은 이 방법론을 코드로 구현합니다.

6.10 사용자가 할 수 있는 것

하세요 본 장에서 추출한 6가지 행동 조향 패턴을 바탕으로, 독자가 직접 포함할 수 있는 실용적인 권장 사항은 다음과 같습니다. 자신만의 프롬프트에:

1. 'Y를 하세요'를 'X를 하지 마세요'로 바꾸세요. 기존 프롬프트를 검토하세요. 긍정적인 설명을 부정적인 제약으로 변환합니다. "간결한 코드 생성"은 "기능을 추가하지 않음"보다 덜 효과적입니다. 요청한 것 이상으로. 버그 수정에는 주변 코드가 필요하지 않습니다. 정리되었습니다." 특정 반례는 모델이 이해하기 더 쉽습니다. 추상적이고 긍정적인 목표보다 따르세요.

2. 실패 시나리오에 대한 3단계 프로토콜을 정의합니다. 에이전트는 잠재적으로 실패할 수 있는 작업(API 호출, 명령 실행, 파일 작업), "진단"을 명시적으로 정의합니다. -> 조정 -> 프롬프트에서 "경로를 에스컬레이션합니다. 동시에 금지합니다. 두 가지 극단적인 방법 모두: 맹목적인 재시도와 단일 실패 후 포기입니다.

3. 형용사를 숫자로 바꾸세요. "keep it concise"를 다음으로 바꾸세요. "단어 25개 이하" 또는 "1~2개 문장". 클로드 코드(Claude Code)의 데이터는 이를 보여줍니다. 단일 변경만으로 1.2%의 출력 토큰 감소를 달성했습니다. 당신의 자신의 시나리오에 따라 각 출력 유형에 대한 특정 수량 제한을 설정하십시오.

4. 도구 설명에 리디렉션 테이블을 삽입합니다. 도구 세트가 있는 경우 "범용 도구"(예: Bash)가 포함되어 있는 경우 "어떤 시나리오"를 배치하세요. 최대한 빨리 어떤 대체 도구를 사용해야 하는지 매핑 테이블을 사용해야 합니다. 설명의 위치. 동시에 독점 선언 전문 도구 설명. 양방향 폐쇄 루프가 멀다 단방향 제약보다 더 효과적입니다.

5. **고위험에 대한 가역성 평가 프레임워크 구축 ** 단순히 "위험한 작업"을 나열하지 마십시오(불가능). 철저하게); 대신, 자율적으로 평가하도록 모델을 가르치세요. "가역성"과 "폭발 반경"이라는 두 가지 차원을 사용합니다. 정확한 면제 구조가 아니면 NEVER +와 결합하여 다음을 제공합니다. 모델은 실행 가능한 의사결정 프레임워크입니다.

6. 소규모 점진적 출시부터 먼저 검증합니다. 새로운 동작 지시어는 먼저 소수의 사용자에게 공개되어야 합니다. 광범위하게 출시되기 전에 효과 데이터를 수집한 시나리오입니다. Claude Code의 USER_TYPE === 'ant' 점진적 출시 메커니즘은 참조 가능한 패턴 - 즉각적인 수정에도 A/B 테스트가 필요합니다.

6.11 요약

이 장에서는 Claude가 명명한 6가지 행동 조정 패턴을 추출했습니다. 코드의 소스 코드입니다. 이러한 패턴은 임의의 단어 선택이 아니라 실험적으로 검증된 엔지니어링 관행 - "세 줄" 1.2% 토큰 감소에 대한 미니멀리즘 지침의 코드" 앵커 Numeric Anchoring의 각 패턴은 명확한 디자인 의도를 가지고 있으며, 측정 가능한 효과.

이러한 패턴의 일반적인 특징은 정밀도입니다. 특정 숫자를 사용하는 모호한 형용사, 긍정적인 설명 대체 반례를 사용하여 무조건적인 명령을 인과적인 명령으로 대체 설명. 이 정밀도는 우연이 아닙니다. 근본적인 진실: 대규모 언어 모델의 신뢰성 지시사항을 따르는 것은 정확도와 양의 상관관계가 있습니다. 그 지시.

다음 장은 런타임 동작 관찰과 디버깅: 세심하게 설계된 프롬프트에서 예상치 못한 상황이 발생할 때 실제 대화 상황, 시스템이 어떻게 감지, 녹음, 하고 대답합니다.

버전

에볼루션: v2.1.91 변경 사항

다음 분석은 v2.1.91 번들 신호 비교를 기반으로 합니다.

v2.1.91에는 새로운 tengu_rate_limit_lever_hint 이벤트가 도입되었습니다. 새로운 속도 제한 조정 메커니즘 - 모델이 속도에 접근할 때 제한이 적용되면 시스템은 프롬프트 수준을 통해 모델의 행동을 조정합니다. "레버 힌트"(예: 도구 호출 빈도를 줄이거나 라이터를 사용하는 등) 운영) 단순히 속도 제한이 해제될 때까지 기다리는 것이 아닙니다.