20가지 프롬프트 엔지니어링 패턴 (feat. oh-my-claudecode)

프롬프트 엔지니어링

Prompt Engineering이란 다양한 목적에 따라 LLM을 효율적으로 사용할 수 있도록 프롬프트를 개선하고 최적화하는 기술이다.

"Garbage In, Garbage Out (GIGO)"이 프롬프트에도 똑같이 적용된다. 쓰레기를 넣으면 쓰레기가 나온다. AI 모델은 마법을 부리는 게 아니라, 사용자 입력값을 바탕으로 확률적인 결과를 계산하는 기계에 가깝다. 따라서 명확한 입력값을 넣어줘야만 사용자가 원하는 결과를 반환한다.

⛔️ BAD example

"자바로 유저리스트 필터링하고 정렬하는 코드 짜줘."

-> 어떤 기준으로 필터링하고, 어떤 기준으로 정렬할지 알 수 없음.

✅ GOOD example

"""

주어진 객체 리스트를 필터링 하고, 정렬하는 Java 코드 작성

- User 객체(id, name, age, active) 리스트

- 필터링 조건: 나이(age)가 20세 이상인 사용자

- 정렬 조건: 이름(name) 순 asc
- 구현 방식: Stream API를 활용하고, NPE 방지 로직을 포함

"""

-> 명확한 구현 방식과 조건, 활용해야 할 라이브러리, 주의사항을 모두 명시하여 명확한 지시를 제공함.

프로덕션 레벨에서의 활용

RAG, AI Agent, LLM pipeline 등에서 지속적으로 사용되는 프로덕션 급에서 사용되는 프롬프트는 완전히 새로운 접근이 필요하다. 약 3개월 정도 적극적으로 활용하고 있는 오픈소스 프로젝트를 분석해서 여러 가지 프롬프트 엔지니어링 기법들을 추출해 봤다.

Github: oh-my-claudecode Github
https://github.com/Yeachan-Heo/oh-my-claudecode

oh-my-claudecode는 32개의 에이전트와 40개 이상의 skill을 일관된 시스템으로 운용하며 에이전틱 코딩을 도와주는 Claude CLI 플러그인이다. 이 오픈소스 코드베이스 전체를 분석해서 실용적인 프롬프트 엔지니어링 기법을 추출했다.

1. 구조화 및 명확성

1.1) XML 시멘틱 태그 (구조적 경계 설정)

마크다운 (##) 보다 강력한 경계 설정을 위해 XML 태그를 사용해서 명령 준수율을 상승시킬 수 있다.

LLM 모델은 훈련 과정에서 마크다운과 XML 기반 데이터를 학습했다.
XML 태그는 열고 닫는 구조로 되어있기 때문에 시작과 끝의 경계가 명확하여 오해 없이 깔끔하게 분리할 수 있게 된다.
마크다운 헤더 (##)는 어디가 섹션의 끝인지 명확하지 않다는 문제를 해결할 수 있다.

<Role>
Oracle - Strategic Architecture & Debugging Advisor
**IDENTITY**: Consulting architect. You analyze, advise, recommend. You do NOT implement.
</Role>

<Critical_Constraints>
YOU ARE A CONSULTANT. YOU DO NOT IMPLEMENT.
FORBIDDEN ACTIONS (will be blocked):
- Write tool: BLOCKED
- Edit tool: BLOCKED
</Critical_Constraints>

항상 XML 태그를 쓰는 게 아니라, 강조해야 될 부분 또는 시작과 끝의 경계가 필요한 경우에만 사용한다.

✅ 핵심 요약

한 단어에 명확한 의미를 담아야 한다. BAD: <Section_1>, GOOD: <Critical_Constraints>
구조를 깊게 파지 말고(depth) 평면적이고 독립적인 모듈들로 태그를 분리한다.
행동의 시작과 끝을 태그로 열고 닫음으로써, 지시사항이 끝나는 지점을 기계적으로 단절시키는 것이 핵심이다.

1.2) 7단계 강조 계층

일반 텍스트, **볼드**, ALL CAPS, 이모지 등 지시사항의 경중에 따라 강조 수준을 분배한다.

이 프로젝트에서는 표현 방식에 따라 7단계의 시각적 / 구조적 강조 계층 표현을 사용한다.

같은 명령이라도 준수율은 20%에서 95%까지 차이가 날 수 있다.

일반 텍스트: `You should read file before editing` (준수율 최저). 단순 권장사항으로 이해한다.
볼드 처리: `**You should read file before editing**` 조금 더 수준 높은 권유. 여전히 우선순위에서 밀릴 가능성이 크다.
ALL CAPS 처리: `CRITICAL: Read files before editing` 문서 내 경고로 각인되며 눈에 확 들어온다.
이모지 경고: `⚠️⚠️⚠️ CRITICAL RULE: NEVER MODIFY THE PLAN FILE ⚠️⚠️⚠️` 가장 눈에 잘 띄며, 절대 위반하면 안 되는 룰 임을 파악하게 만든다.
다중 형태 반복: 똑같은 말을 복붙 하는 게 아니라 문장, 체크리스트, Anti-Pattern 리스트 등 여러 곳에 여러 형태로 삽입하여 회피를 막는다.
결과 프레이밍: `Write code before test? DELETE IT. Start over. No exceptions.` 지시를 위반할 경우 일어날 행동을 명시적으로 선언하여 인과관계를 단단하게 연결한다.
시스템 레벨의 물리적 차단: `disallowedTools: [Write]`처럼 스크립트로 차단한다. 이 것은 프롬프트 지침이 아니라 하드웨어적 한계로 강제한다. 다양한 AI Tool은 이렇게 시스템적인 차단을 제공한다.

⚠️ 주의사항 (늑대 소년 효과)

프롬프트를 처음 작성할 때 흔히 저지르는 실수는 1부터 10까지 전부 볼드 처리, 이모지, ALL CAPS를 범벅으로 발라놓는 것이다.

"모든 것을 강조하면 아무것도 강조되지 않는다."

가장 필수적인 규칙 1~2개에만 이모지 경고(Level 4)와 결과 명시 처리(Level 6)를 조합하고, 나머지는 자연스럽게 문장형으로 깎아내야 한다. 또한, 필수 금지사항인 <Anti-Pattern>은 프롬프트 최 하단에 위치시켜 LLM의 Recency Effect(가장 마지막에 읽은 것을 제일 강하게 기억하는 것)를 활용하는 것이 좋다.

✅ 핵심 요약

모든 규칙을 동등하게 강조하지 말고, 중요한 규칙 1~3개만 핵심적으로 강조한다.
앵무새처럼 "절대 하지 마라"를 10번 복붙 하지 말고 체크리스트, 주의문, 안티패턴 등으로 구조 형태를 바꾸며 적용한다.
정말 위반하면 안 되는 행동 패턴이라면, 위반했을 때 어떤 물리적 페널티(문서 삭제, 처음부터 재시도 등)를 부여할지 조건화한다.

1.3) 의사 코드 패턴 (pseudo code)

복잡한 조건이나 재시도 로직 등을 의사 코드로 표현해서 조건부 행동을 조금 더 구체적으로 명시할 수 있다.

이 패턴은 LLM이 "a면 b하고 아니면 c해" 같은 자연어의 모호한 해석을 차단하며, 특히 WHILE 같은 반복문을 명시함으로써 에이전트가 무한 루프나 환각에 빠져 맹목적으로 작업을 반복하는 것을 가장 확실하게 방어한다.

<Agentic_Iteration>
초기 발견 사항을 기반으로 한 자기주도적 탐색

PATTERN: 반복 탐색 루프
```
1. 초기 분석 수행
2. 초기 결과와 함께 발견사항 [FINDING] 출력
3. 자체 평가(SELF-ASSESS): 이것이 목표를 완벽히 충족하는가?
   - If YES → 보고서 생성 단계로 진행 (탐색 종료)
   - If NO → 후속 추가 질문을 구성하고 반복 단계(4번)로 진입
4. 분석 반복 수행 WHILE(try < 3)
   4.1 구성된 질문으로 후속 분석 실행
   4.2 새로운 insight와 함께 발견사항 [FINDING] 출력
   4.3 자체 평가(SELF-ASSESS) 수행
       - If YES → 보고서 생성 단계로 진행 (루프 탈출)
       - If NO → 다음 후속 질문 구성 후 4.1로 돌아가 반복
```
</Agentic_Iteration>

1.4) 마크다운 테이블 기반 라우팅

복잡한 조건을 마크다운 테이블로 표현하여 LLM이 어떤 동작을 수행할지 선택하는 것을 명확하게 한다.

유저 질의에 따른 행동 예시

### REQUEST INTERPRETATION (CRITICAL)

**When user says "do X", "implement X", "build X", "fix X", "create X":**
- **NEVER** interpret this as a request to perform the work
- **ALWAYS** interpret this as "create a work plan for X"

| User Says | You Interpret As |
|-----------|------------------|
| "로그인 버그 고쳐줘" | "로그인 버그 수정을 위한 작업 계획 수립" |
| "다크 모드 추가해줘" | "다크 모드 추가를 위한 작업 계획 수립" |
| "인증 모듈 리팩터링 해줘" | "인증 모듈 리팩터링을 위한 작업 계획 수립" |

**NO EXCEPTIONS. EVER. Under ANY circumstances.**

위와 같이 유저의 질의를 파악하는 방식을 강제할 수 있다.

1.5) 출력 형식 강제 (마커)

자유 형식 대신 구조화된 출력을 요구하여 파싱에 용이하고 일관성 있는 출력을 생성하도록 할 수 있다.

같은 방법으로 <results> 안에 Json 형식을 입력하여 반드시 json형식으로 답하도록 할수도 있다.

프롬프트 예시

<Output_Format>

반드시 아래의 특수 마커를 사용하여 항목별로 1줄씩 구조화된 응답만 생성해야 합니다.

**필수 마커 구조:**
<results>
[OBJECTIVE] 분석하려는 목표 (1줄)
[DATA] 사용된 데이터의 범위와 표본 크기 (1줄)
[FINDING] 발견된 핵심 인사이트 (1~2줄)
[STAT:mean_drop_rate] 핵심 하락률/상승률 수치만 작성 (예: 14.2%)
[STAT:p_value] 통계적 유의미성 수치 (예: p < 0.05)
[LIMITATION] 이 분석의 한계점이나 통제되지 않은 변수 (1줄)
</results>
</Output_Format>

응답 예시

[OBJECTIVE] 가격 5% 인상이 20대 사용자의 구매 전환율에 미치는 영향 분석
[DATA] 기간: 2026.01~02월, 조작군(A/B)에 속한 20대 활성 사용자 45,000명
[FINDING] 가격을 인상한 실험군에서 결제창 이탈률이 대조군 대비 유의미하게 크게 증가함
[STAT:mean_drop_rate] 14.2%
[STAT:p_value] p < 0.001
[LIMITATION] 주말에 오픈된 프로모션 쿠폰 변수가 완벽히 통제되지 않았음 (신뢰도 약간 하락)

1.6) 추상성 제거 (수치화된 임계값)

프롬프트 내에 "오래 걸리면", "너무 복잡하면" 과 같이 추상화된 명령보다는 "5분 이상", "3개 파일 초과 시" 와 같이 정확한 숫자를 명시한다.

- 2+ independent tasks with >30 seconds work → Run in parallel
- Cross-file dependencies (3+ files) → architect-medium
- 3+ fix attempts fail → Circuit breaker activates
- Session timeout: 5 minutes idle
- Max iterations: 3 (default)
- Output freshness: 5-minute evidence staleness

2. 자아 통제 및 인지 유도

2.1) 페르소나 할당(신화적 이름)

추상적인 "agent-1" 이 아닌, 역할의 본질을 담은 신화적 이름을 사용했다.

Oracle(architect): 델파이 신전의 예언자 - 보이지 않는 패턴을 발견
Prometheus(planner): 인류에게 불을 가져온 타이탄 - 미래를 설계
Metis(analyst): 지혜의 여신 - 요구사항 격차 분석
Sisyphus-Junior (executor): 끊임없이 작업하는 실행자

이름만으로 역할의 본질이 전달되고, 에이전트가 정체성에 맞게 행동하도록 유도한다.

<Role>
You are Prometheus, the strategic planning consultant. Named after the Titan who brought
fire to humanity, you bring foresight and structure to complex work through thoughtful
consultation.
</Role>

✅ 단순 역할 부여

이렇게 강하게 페르소나를 부여하지 않더라도, 아래와 같이 Role을 명확히 부여하는 것만으로도 하지 않는 것보다 훨씬 낫다.

BAD: XXX를 수행해줘.
GOOD: 당신은 뛰어난 Java 개발자입니다. XXX를 수행하세요.
BEST: 당신은 20년차 시니어 Java개발자로, Spring Boot 기반 대규모 시스템 설계 경험이 풍부한 아키텍트입니다. XXX를 수행하세요.

✅ 핵심 요약

상투적인 "agent 1"와 같은 이름 대신 에이전트가 수행할 본질을 담은 이름을 부여한다.
양립할 수 없는 특성을 억지로 섞으면 않는다. "꼼꼼한 회계사이자 거침없는 예술가" 와 같은 컨셉은 혼란을 가중시킨다.
명시적 규칙보다 정체성(Identity)을 주입해라. LLM은 단순한 부정 명령("~하지 마라") 보다 "네 정체성은 이것이다"를 훨씬 더 잘 지켜낸다.

2.2) Anti-Pattern 리스트(NEVER / ALWAYS 패턴)

금지사항과 필수사항을 구체적으로 나열한다. 앞에서 설명한 XML 시멘틱 태그, 강조 규칙(ALL CAPS)을 활용하여 강조한다.

NEVER: 절대 하지 말아야 할 것
ALWAYS: 반드시 해야할 것

```markdown
<Anti_Patterns>
NEVER:
- Give advice without reading the code first
- Suggest solutions without understanding context
- Make changes yourself (you are READ-ONLY)
- Provide generic advice that could apply to any codebase
- Skip the context gathering phase

ALWAYS:
- Cite specific files and line numbers
- Explain WHY, not just WHAT
- Consider second-order effects
- Acknowledge trade-offs
</Anti_Patterns>
```

단순히 "하지 마라"를 넘어서 구체적인 행동 사례를 제시한다.

2.3) 의도 분석 강제

명령 실행 전에 반드시 의도 분석을 강제한다. 도구 호출 전 의도 분석을 요구하여 <analysis> 태그 안에 쓰고 작업을 시작하도록 강제한다.

### 1. Intent Analysis (Required)
Before ANY search, wrap your analysis in <analysis> tags:

<analysis>
**Literal Request**: [What they literally asked]
**Actual Need**: [What they're really trying to accomplish]
**Success Looks Like**: [What result would let them proceed immediately]
</analysis>

2.4) 점진적 질문 공개 (사용자 역질문)

사용자에게 질문이 필요할 때 한번에 5개의 질문을 던지지 않고, 하나씩 순서대로 질문하고 답을 기반으로 다음 질문을 이어나가도록 설계한다. 이렇게 하면 정보 과부하를 방지하고, 사용자가 집중할 수 있게 한다.

### MANDATORY: Single Question at a Time

**Never ask multiple questions in one message.**

| BAD | GOOD |
|-----|------|
| "What's the scope? And the timeline? And the priority?" | "What's the primary scope for this feature?" |

**Protocol:**
1. Ask ONE question
2. Use AskUserQuestion tool for that ONE question
3. Wait for response
4. THEN ask next question (informed by the answer)

**Why:** Multiple questions get partial answers. Single questions get thoughtful responses.

2.5) 메타 인지 지시

LLM에게 단순히 명령하는게 아니라, "질문 전에 질문의 타입을 분류하라" 와 같은 메타 지시를 준다.

"무엇을 하라"를 넘어 "어떻게 생각하고 행동하라" 를 제공하는 것이다.

예시

## Adaptive Planning Protocol

Before asking ANY question, classify it:

### NEVER Ask User About (explore instead):
- Codebase structure or patterns
- Where things are implemented
- What technologies are in use

### ALWAYS Ask User About:
- Priorities (speed vs quality)
- Timelines and deadlines
- Scope decisions
- Risk tolerance

3. 검증 및 오류 제어

3.1) Iron Law 패턴(검증 없이 완료 선언 금지)

LLM은 코드를 수정한 논리적 행위에 만족해서, 실제 테스트 없이 완료를 선언하는 "만족 편향"을 가진다. 이를 해결하기 위해 반드시 검증 후에 완료를 선언하도록 하여 거짓 완료 선언을 90% 이상 차단할 수 있다.

✅ 검증 방안 예시

추측성 단어 검열: 시스템 프롬프트를 통해 "should", "probably", "seems"와 같은 단어 사용을 Red Flag로 규정하고, 감지 즉시 답변을 멈추고 테스트를 돌리도록 강제한다.
1대 1 증거 매핑: 버그를 고쳤다면 test결과를, 기능을 추가했다면 빌드 성공과 에러 0건 로그를 증거로 제출해야만 완료 선언을 허용한다. 이 증거는 느낌이 아닌 터미널 출력값을 기준으로 한다.
증거 5분 룰: 증거는 반드시 5분 이내에 실행된 최신 기록이어야 한다.
3-Failure 서킷브레이커: 같은 수정을 3회 연속 실패하면 즉시 서킷 브레이커를 발동시켜, 맹목적인 재시도를 멈추고 아키텍트 에이전트에게 재분석을 요청한다.

이외에도 다양한 방법을 활용해서, LLM이 실패를 성공이라고 생각하고 완료를 선언하는 환각을 방지할 수 있다.

<Verification_Before_Completion>
## Iron Law: NO CLAIMS WITHOUT FRESH EVIDENCE

Before expressing confidence in ANY diagnosis or analysis:

### Verification Steps (MANDATORY)
1. **IDENTIFY**: What evidence proves this diagnosis?
2. **VERIFY**: Cross-reference with actual code/logs
3. **CITE**: Provide specific file:line references
4. **ONLY THEN**: Make the claim with evidence

### Red Flags (STOP and verify)
- Using "should", "probably", "seems to", "likely"
- Expressing confidence without citing file:line evidence
- Concluding analysis without fresh verification
</Verification_Before_Completion>

3.2) 증거 유형 테이블

LLM에게 검증을 지시할 때 장황한 자연어 설명보다. 주장-증거-명령이 1:1:1로 매핑된 구조화된 테이블 형태로 프롬프트를 주입하는 것이 훨씬 효과적이다.

✅ 효과

검색과 매칭의 직관성: LLM이 테이블의 행을 탐색하여 현재 상황에 해당하는 행을 즉시 찾아내고, 명령을 수행할 수 있도록 한다.
강제적 예외 차단: 표의 행 중에 하나를 반드시 찾도록 강제하여 물리적인 제약을 준다. 표에 else 행은 없다.

## Evidence Requirements

YOU MUST consult this table before ANY completion claim:

| Claim Type | Required Evidence | Verification Command |
|------------|-------------------|---------------------|
| Bug fixed | Previously failing test now passes | `npm test -- <test_name>` |
| Feature implemented | lsp_diagnostics clean + build success | `lsp_diagnostics` then `npm run build` |
| Code refactored | All existing tests pass | `npm test` |
| Issue debugged | Root cause identified with file:line | Show code snippet + explain |
| Performance optimized | Benchmark shows improvement | `npm run benchmark` (before/after) |
| Security patched | Vulnerability scan clean | `npm audit` or `snyk test` |

BEFORE claiming anything, find the matching row and execute the verification command.

3.3) 3회 실패 서킷 브레이커

LLM이 같은 문제에 대해 3회 연속 실패할 경우, 맹목적인 재시도를 강제로 멈추게 하는 강제 장치이다.

이 경우에 문제의 근본적인 가정을 재검토하여 실패 패턴을 인식하고 전략을 바꾸도록 유도한다.

3번의 의미: 1~2회 실패는 우연이나 실수일 수 있지만, 3회 연속 실패는 버그의 근본 원인이나 접근 방식 자체가 완전히 틀렸음을 확정하는 기준으로 삼을 수 있다.
작동 방식: 서킷 브레이커가 발동하면 LLM은 자신이 보고 있는 파일이 틀렸음을 인지하도록 한다.
강제 전환: 명령 수행을 즉시 멈추고, 시야를 넓혀 전체 흐름, 세션, DB 등 다른 영역을 처음부터 재분석하도록 한다.

### 3-Failure Circuit Breaker
If 3+ fix attempts fail for the same issue:
- **STOP** recommending fixes
- **QUESTION** the architecture - Is the approach fundamentally wrong?
- **ESCALATE** to full re-analysis
- **CONSIDER** the problem may be elsewhere entirely

| Symptom | Not a Fix | Root Cause Question |
|---------|-----------|---------------------|
| "TypeError: undefined" | Adding null checks everywhere | Why is it undefined in the first place? |
| "Test flaky" | Re-running until pass | What state is shared between tests? |

이 패턴은 LLM이 틀린 가설에 갇혀 끊임없이 반복하며 토큰을 낭비하거나, 무한 루프에 빠지는 것을 원천 차단한다.

3.4) 실패 복구 프로토콜

에이전트가 3번 이상 거듭하여 실패한 경우 동작하는 자가 학습 메커니즘이다.

중지(STOP): 일단 수행중이던 의미 없는 행위를 중단한다.
복구(REVERT): 이전에 정상 작동하던 상태로 시스템을 롤백한다.
기록 및 상담(DOCUMENT & ESCALATE): 실패 사유와 로그를 issue.md와 같은 외부에 기록해두고, 상위 에이전트에게 분석을 요청한다. 스스로 분석하는건 의미없기 때문에, 꼭 다른 세션 또는 상위 에이전트에 요청해야한다.
조직적 학습(RECORD): 해당 파일의 에러 원인을 기록함으로써, 다음에 같은 실수를 반복하지 않게 만든다.

### 3-Failure Circuit Breaker
If 3+ fix attempts fail for the same issue:
1. **STOP** recommending fixes
2. **REVERT** to last known good state (git checkout)
3. **DOCUMENT** in notepad/issues.md
4. **ESCALATE** to architect for full re-analysis
5. **RECORD** failure pattern for future avoidance

4. 시스템 오케스트레이션 및 라우팅

4.1) 역할 경계 테이블

역할의 경계를 마크다운 테이블로 표현하여 역할을 명확히 구분하고, 무한루프를 방지한다. "이러한 상황에서는 이런 에이전트에게 위임하라" 를 단순 텍스트가 아닌 마크다운 테이블로 표현하여 강조한다.

<Role_Boundaries>
...
## Hand Off To

| Situation | Hand Off To | Reason |
|-----------|-------------|--------|
| Requirements gaps detected | `analyst` (Metis) | Gap analysis is Metis's job |
| Need codebase context | `explore` | Codebase facts via exploration |
| Code analysis needed | `architect` (Oracle) | Code analysis is Oracle's job |
| Plan ready for review | `critic` | Plan review is Critic's job |
...
</Role_Boundaries>

4.2) 자연어 상태 머신 (Phase 분리)

작업 워크플로우를 명확한 phase로 분리하고, 전이 조건을 분명히 한다. 이렇게 하면 아래와 같은 이점을 얻을 수 있다.

성급한 결론 방지: LLM은 질문을 받으면 데이터를 확인하기도 전에 곧바로 답변을 생성하려는 특징이 있다. Phase1에서 정보수집을 가장 먼저 하도록 강제함으로써, 전체 문맥을 파악하지 않고 답변 생성을 시작하려는 실수를 막아준다.
순차적이고 체계적인 사고 유도: 정보 수집 -> 깊은 분석 -> 해결책 구조화라는 3단계의 논리적인 파이프라인을 받도록 만들어, 인간이 복잡한 문제를 풀 때 거치는 사고방식을 LLM에 주입한다.
명확한 모드(Phase) 전환 통제: "분석이 끝나기 전까지는 절대 코드를 작성하지 마라"처럼 단계별 전이 조건을 명시하여, LLM이 문맥 파악도 없이 성급하게 코드를 짜는 오작동을 통제한다.

<Operational_Phases>
## Phase 1: Context Gathering (MANDATORY)
Before any analysis, gather context via parallel tool calls:
1. **Codebase Structure**: Use Glob
2. **Related Code**: Use Grep/Read
3. **Dependencies**: Check project manifest
4. **Test Coverage**: Find existing tests

## Phase 2: Deep Analysis
After context, perform systematic analysis

## Phase 3: Recommendation Synthesis
Structure your output:
1. **Summary**: 2-3 sentence overview
2. **Diagnosis**: What's actually happening and why
3. **Root Cause**: The fundamental issue
4. **Recommendations**: Prioritized, actionable steps
5. **Trade-offs**: What each approach sacrifices
</Operational_Phases>

4.3) 템플릿 상속 ( <Inherits_From> )

복잡한 공통 규칙 (base-agent.md)을 중복해서 쓰지 않고, 상속받아 사용하도록 한다.

에이전트가 여러개로 늘어날 때 수많은 핵심 규칙들을 일일히 복사 붙여넣기 하면 누락될 수 있다.

프로그래밍의 규칙이 프롬프트엔지니어링에서도 동일하게 적용된다.

<Inherits_From>
Base: architect.md - Strategic Architecture & Debugging Advisor
</Inherits_From>

4.4) 복잡도에 따른 3-Tier 모델 경계

작업 복잡도에 따라 적절한 모델 Tier로 라우팅 하도록 해서, 비용 효율성과 품질의 균형을 확보한다.

Claude의 경우 Haiku, Sonnet, Opus로 구분되어있다. 아래와 같이 구분하는것도 많이 사용한다.

Haiku: 간단한 읽기 작업
Sonnet: 계획에 따른 작업 실행
Opus: 요구사항 분석, 계획 생성, 검증

| Domain | LOW (Haiku) | MEDIUM (Sonnet) | HIGH (Opus) |
|--------|-------------|-----------------|-------------|
| Analysis | `architect-low` | `architect-medium` | `architect` |
| Execution | `executor-low` | `executor` | `executor-high` |
| Search | `explore` | `explore-medium` | `explore-high` |

4.5) 에이전트 위임 구조 (컨텍스트 유실 방지)

에이전트에게 작업을 위임할 때는 최대한 완벽한 컨텍스트를 전달하여 재작업을 최소화 한다.

oh-my-claudecode에서는 상황마다 각기 다른 명시할 정보 템플릿을 정하고, 항상 이 형식에 맞는 정보를 다른 에이전트에게 전달한다.

### Exploration Template

For exploration, research, or search tasks.

**Sections:**
- **TASK**: What needs to be explored
- **EXPECTED OUTCOME**: What the orchestrator expects back
- **CONTEXT**: Background information
- **MUST DO**: Required actions
- **MUST NOT DO**: Constraints
- **REQUIRED SKILLS**: Skills needed
- **REQUIRED TOOLS**: Tools to use

**Location:** `src/agents/templates/exploration-template.md`

이렇게 7단계 규격으로 꼼꼼히 위임하면, 작업을 넘겨받은 새로운 에이전트가 앞선 맥락(Context)을 완벽히 이해하고 바로 작업에 착수할 수 있어 컨텍스트 유실로 인한 재작업을 획기적으로 줄일 수 있다.

정리: 공통 원칙

20가지 패턴을 관통하는 핵심 원칙들을 정리하면 아래와 같다.

6가지 원칙

1. 추상성 제거 (구체성 > 추상성)

"복잡하면 xxx해라" -> "3개 이상의 파일과 연관되어 있으면 xxx해라"
"중요하면" -> "CRITICAL, MANDATORY 대문자 마커 사용"
"잘 작동하면" -> "빌드 성공, lsp_diagnostics 에러가 0건이면"

2. 반복 & 변주를 통한 통제

똑같은 지시를 단순 복붙하지 말고, XML 태그 / 체크리스트 / 예시 등 구조와 형태를 바꿔가며 여러번 노출 시킨다.
제약 사항을 여러 레벨에 걸쳐 명시한다. ( 자연어 금지 명령 + 시스템적인 권한 설정 등 결합)

3. 구조적 경계 설정

XML 시멘틱 태그: 프롬프트 의미 단위 분할
역할 경계 테이블: 책임 소재와 임계점 명확화
자연어 상태 머신(Phase): 단계별 워크플로우를 강제해 기계적인 진행 유도

4. 증거 기반

모든 주장에 터미널 출력값 같은 객관적 증거 요구
검증 없이는 "완료 선언" 불가능 (Iron Raw 등)
file:line 참조 필수 등 실재하는 데이터 기반 증거 제시

5. 실패를 대비한 설계

3회 실패 서킷 브레이크: 무한 루프 차단
자신이 해결 할 수 없는 문제를 발견하면 상위 에이전트에게 위임(Escalation)
실패를 덮지 않고 이전 상태로 롤백하고, 원인 및 처리 과정을 기록해 학습하는 복구 프로토콜

6. 계층적 사고

3-Tier 복잡도 분류 (LOW/MEDIUM/HIGH)로 모델 연산량과 토큰 비용 분배
7단계 강조 계층으로 프롬프트 지시사항의 경중을 조절
한 번에 모든 정보를 쏟아내지 않고 사용자에게 답하는 점진적 공개 활용

저작자표시 (새창열림)

'AI' 카테고리의 다른 글

[ AI ] 바이브 코딩/에이전틱 코딩 개발 방법론 - AI 모델간 planning 교차 검증 (0)	2026.01.24
[ Claude ] 클로드 코드 상세 세팅 알아보기 (0)	2026.01.24
[ AI ] 클로드 스킬(Claude Skills, Agent Skill) 사용 방법, 커스텀해서 에이전트 만들기 (2)	2026.01.16
[Spring AI] 벡터 DB - Qdrant 스프링부트 연동과 ollama를 이용한 임베딩 (0)	2025.09.01
[Spring AI] Spring Boot에 LLM을 도입하기 전 꼭 알아야 할 RAG 개념 정리 (0)	2025.07.15

프롬프트 엔지니어링

프로덕션 레벨에서의 활용

1. 구조화 및 명확성

1.1) XML 시멘틱 태그 (구조적 경계 설정)

✅ 핵심 요약

1.2) 7단계 강조 계층

⚠️ 주의사항 (늑대 소년 효과)

✅ 핵심 요약

1.3) 의사 코드 패턴 (pseudo code)

1.4) 마크다운 테이블 기반 라우팅

유저 질의에 따른 행동 예시

1.5) 출력 형식 강제 (마커)

프롬프트 예시

응답 예시

1.6) 추상성 제거 (수치화된 임계값)

2. 자아 통제 및 인지 유도

2.1) 페르소나 할당(신화적 이름)

✅ 단순 역할 부여

✅ 핵심 요약

2.2) Anti-Pattern 리스트(NEVER / ALWAYS 패턴)

2.3) 의도 분석 강제

2.4) 점진적 질문 공개 (사용자 역질문)

2.5) 메타 인지 지시

예시

3. 검증 및 오류 제어

3.1) Iron Law 패턴(검증 없이 완료 선언 금지)

✅ 검증 방안 예시

3.2) 증거 유형 테이블

✅ 효과

3.3) 3회 실패 서킷 브레이커

3.4) 실패 복구 프로토콜

4. 시스템 오케스트레이션 및 라우팅

4.1) 역할 경계 테이블

4.2) 자연어 상태 머신 (Phase 분리)

4.3) 템플릿 상속 ( <Inherits_From> )

4.4) 복잡도에 따른 3-Tier 모델 경계

4.5) 에이전트 위임 구조 (컨텍스트 유실 방지)

정리: 공통 원칙

6가지 원칙

1. 추상성 제거 (구체성 > 추상성)

2. 반복 & 변주를 통한 통제

3. 구조적 경계 설정

4. 증거 기반

5. 실패를 대비한 설계

6. 계층적 사고

'AI' 카테고리의 다른 글

티스토리툴바