프롬프트 기법 메뉴를 하네스로 바꾸는 법

프롬프트 엔지니어링 글을 읽다 보면 기법 목록이 금방 쌓인다. 명확하게 지시하라, XML로 구조화하라, 예시를 넣어라, 검색을 붙여라, 스키마를 써라, 자기 검증을 시켜라. 문제는 기법이 많아질수록 실제로 무엇을 써야 할지 더 흐려진다는 점이다.

PCH-Optimizer catalog의 마지막 28개 항목은 이 문제를 잘 보여준다. 기법은 메뉴일 뿐이고, 메뉴를 실제 작업으로 바꾸려면 결함과 계층에 맞춰 조립해야 한다.

묶음	항목 수	역할
Technique - Prompt	8	문장과 출력 계약을 고친다
Technique - Context	8	정보 선택과 순서를 고친다
Technique - Harness	8	도구, 루프, 상태, 평가를 고친다
Assembly Template	4	유형별 최종 산출물로 조립한다
합계	28	기법과 조립 레이어

이로써 앞선 두 글의 45개, 42개와 합쳐 PCH-Optimizer prompt catalog 115개 항목을 모두 블로그 묶음으로 읽었다.

기법은 처방이 아니라 선택지다

기법 메뉴의 함정은 “좋은 것은 다 넣자”는 태도다. 하지만 PCH-Optimizer의 원리는 반대다. 진단된 결함에 맞는 것만 고르고, 일부러 빼는 기법도 이유를 적는다.

예를 들어 XML 구조화는 좋은 기법이다. 하지만 모든 짧은 프롬프트에 필요한 것은 아니다. 자기 검증 블록도 유용하지만, 단순 창작 프롬프트에 과하게 붙이면 리듬을 깨뜨릴 수 있다. 반대로 장기 실행 에이전트에서는 자기 검증이 선택이 아니라 생존 조건이 된다.

기법은 보편 처방이 아니라 맥락 의존적인 선택지다.

Prompt 기법: 문장을 계약으로 바꾼다

Prompt 계층 기법 8개는 명료화, 적정 역할, XML 구조, 정전 퓨샷, 사고 여지, 출력 스키마, 분해·체이닝, 자기 검증으로 읽을 수 있다.

여기서 중요한 흐름은 문장을 계약으로 바꾸는 것이다.

결함	적용할 수 있는 기법
목표가 흐릿하다	명료·직접·긍정형 지시
역할이 과하거나 약하다	적정 고도의 역할 설정
섹션이 섞인다	XML 또는 구조화 섹션
결과가 매번 흔들린다	출력 스키마와 프리필
작업이 너무 크다	분해·체이닝

Prompt 기법의 목표는 모델을 겁주거나 감동시키는 것이 아니다. 모델이 해야 할 행동과 답변 형식을 선명하게 만드는 것이다.

Context 기법: 정보의 편집자가 된다

Context 계층 기법 8개는 고신호 토큰, 정보 순서, JIT 검색, 인용, 컴팩션, 외부 메모리, context rot 완화, 서브에이전트 격리로 정리된다.

이 묶음은 최신 컨텍스트 엔지니어링 논의와도 잘 맞는다. 컨텍스트는 커질수록 항상 좋아지는 창고가 아니라, 매 턴마다 주의력을 소비하는 예산이다. 그래서 Context 기법은 “더 넣기”보다 “무엇을 언제 보여줄지”를 정하는 편집 기술이다.

실무적으로는 이런 결정이 된다.

• 항상 필요한 정책은 시스템 지시 쪽에 둔다.
• 작업별 자료는 필요할 때 검색하게 한다.
• 장기 상태는 대화가 아니라 파일이나 노트에 남긴다.
• 핵심 정보는 중간에 묻히지 않게 배치한다.
• 서브에이전트는 좁은 컨텍스트로 호출한다.

컨텍스트 기법은 프롬프트를 길게 만드는 법이 아니라, 모델의 시야를 조명하는 법이다.

Harness 기법: 모델 밖의 구조를 설계한다

Harness 계층 기법 8개는 최소 도구 집합, 에이전트 루프, 상태 아티팩트, 초기화/실행 분리, E2E 체크, clean-state handoff, entropy garbage collection, 재현 가능한 평가 하네스로 묶인다.

이 계층은 프롬프트 엔지니어링을 가장 크게 확장한다. 모델에게 “잘해줘”라고 말하는 대신, 모델이 잘할 수밖에 없는 작업대를 만든다.

예를 들어 블로그 발행 에이전트를 생각해보자. 좋은 하네스는 다음을 포함한다.

하네스 요소	블로그 작업에서의 예
도구 집합	파일 읽기, Markdown 작성, 빌드, 배포, URL 검증
루프	자료 확인 -> 초안 -> 번역 -> 빌드 -> 공개 검증
상태 아티팩트	article map, glossary, term decisions
완료 기준	public URL 200, hreflang, 이미지, 본문 핵심 문구
핸드오프	커밋 SHA, 배포 SHA, 남은 작업

여기서 프롬프트는 전체 시스템의 한 부품이다. 하네스가 없으면 좋은 문장도 운영에서 흔들린다.

조립 템플릿은 유형별로 달라진다

Assembly Template 4개 항목은 T1/T2/T7, T3, T4/T5, T6를 다르게 조립한다.

유형	조립 방식
T1/T2/T7	role, context, instructions, examples, output_format, self_check
T3	위 구조에 retrieval_policy와 citation_rules 추가
T4/T5	system_prompt, tool_specs, loop_policy, state_policy
T6	초기화 프롬프트와 실행 프롬프트를 분리

이 차이를 무시하면 프롬프트가 비대해진다. 단발 프롬프트에 에이전트 하네스를 붙이면 과하고, 장기 실행 작업을 단일 프롬프트처럼 다루면 부서진다.

좋은 조립은 “멋진 템플릿 하나”가 아니라 “유형에 맞는 충분한 구조”다.

전체 115개를 블로그 묶음으로 읽기

PCH-Optimizer prompt catalog 전체는 이렇게 세 묶음으로 정리된다.

글	커버한 항목	개수
PCH-Optimizer는 프롬프트 운영체제다	메타, 원리, 입력, 분류, 스코프, 파이프라인, 출력 계약	45
좋은 프롬프트는 진단표와 검증표를 함께 가진다	Prompt/Context/Harness 진단, 검증, 안티패턴	42
프롬프트 기법 메뉴를 하네스로 바꾸는 법	Prompt/Context/Harness 기법, 조립 템플릿	28
합계	PCH-Optimizer prompt catalog 전체	115

이제 카탈로그는 엑셀 파일 하나가 아니라, 블로그에서 계속 확장할 수 있는 주제 지도다.

이 묶음에서 끌어낸 프롬프트 아이디어

내 프롬프트의 결함 진단 결과를 바탕으로,
Prompt / Context / Harness 기법 메뉴에서 필요한 기법만 선택하라.
각 기법에 대해 선택 이유와 일부러 제외한 기법의 이유를 함께 적어라.
마지막에는 대상 유형에 맞는 Assembly Template으로
복사 가능한 최종 프롬프트 또는 에이전트 하네스를 조립하라.

이 프롬프트는 기법을 나열하지 않는다. 진단과 기법과 조립을 연결한다. 그 연결이 생길 때 프롬프트 카탈로그는 단순 참고 자료가 아니라 실제 작업 시스템이 된다.