좋은 프롬프트는 진단표와 검증표를 함께 가진다

프롬프트를 고친 뒤 “좋아졌다”고 말하려면 근거가 필요하다. 더 길어졌기 때문에 좋아진 것이 아니고, 더 그럴듯해졌기 때문에 좋아진 것도 아니다. PCH-Optimizer catalog에서 가장 실무적인 부분은 바로 이 지점이다. 개선을 느낌이 아니라 진단표와 검증표로 바꾸려 한다.

이번 글은 115개 중 42개 항목을 다룬다.

묶음	항목 수	역할
Prompt Layer Diagnostic	8	지시 문자열의 결함을 찾는다
Context Layer Diagnostic	8	모델 앞에 놓이는 정보의 결함을 찾는다
Harness Layer Diagnostic	8	도구·루프·상태·평가 결함을 찾는다
Verification & Evaluation	10	좋아졌는지 판정한다
Anti-Pattern Guardrail	8	자주 망가지는 방향을 막는다
합계	42	진단과 판정 레이어

진단은 목록화가 아니다

PCH-Optimizer의 진단 표는 단순 체크리스트가 아니다. 각 행은 현재 상태, 결함·리스크, 개선 방향을 함께 요구한다. 이 세 칸이 중요하다.

현재 상태 -> 결함·리스크 -> 개선 방향

현재 상태만 쓰면 관찰 기록이다. 결함만 쓰면 비판이다. 개선 방향만 쓰면 처방전이지만 근거가 약하다. 세 칸이 함께 있을 때 비로소 진단이 된다.

예를 들어 “출력 형식 없음”이라는 말은 아직 진단이 아니다. 더 나은 진단은 이렇다.

현재 상태	결함·리스크	개선 방향
출력 형식이 자유 서술이다	후처리와 비교가 어렵고 누락을 찾기 힘들다	표 또는 JSON 스키마를 지정하고 필수 필드를 둔다

이 정도가 되어야 프롬프트를 어떻게 고칠지 보인다.

Prompt 진단: 문장의 실패를 본다

Prompt Layer Diagnostic 8개 항목은 목표, 역할, 지시, 출력 계약, 예시, 사고 발판, 실패 처리, 구조를 본다. 이것은 가장 익숙한 프롬프트 엔지니어링 영역이다.

하지만 여기서도 핵심은 “예쁘게 고치기”가 아니다. 목표가 모호한지, 역할이 과한지, 지시가 부정형으로만 되어 있는지, 출력 계약이 없는지, 예시가 대표성을 가지는지 따진다.

좋은 질문은 이런 식이다.

• 이 프롬프트의 목적은 한 문장으로 말할 수 있는가.
• 역할은 필요한 만큼만 주어졌는가.
• 금지문보다 해야 할 행동이 더 선명한가.
• 출력은 사람이든 코드든 검증할 수 있는 형태인가.
• 예시는 망라가 아니라 대표 사례인가.

Prompt 진단은 문장을 다듬는 작업처럼 보이지만, 실제로는 산출물의 계약을 선명하게 하는 작업이다.

Context 진단: 모델이 보는 것을 본다

Context Layer Diagnostic은 훨씬 덜 눈에 띄지만 더 자주 실패한다. 필수 정보, 순서, 검색 전략, 그라운딩과 인용, 메모리, 토큰 예산, context rot, 제거할 중복을 본다.

프롬프트가 좋아도 컨텍스트가 나쁘면 모델은 평균적인 답을 낸다. 반대로 프롬프트가 평범해도 컨텍스트가 잘 선별되어 있으면 결과는 좋아진다.

내가 여기서 얻은 블로그 아이디어는 “컨텍스트를 많이 주는 법”이 아니다. 오히려 “컨텍스트를 버리는 법”이다.

질문	이유
이 정보가 없으면 어떤 행동이 무너지는가	고신호 토큰만 남기기 위해
같은 사실이 두 번 이상 들어갔는가	토큰 예산을 회수하기 위해
핵심 정보가 중간에 묻혔는가	긴 창에서 회상 손실을 줄이기 위해
검색해야 할 정보와 미리 넣을 정보를 나눴는가	JIT 검색과 사전적재를 구분하기 위해

컨텍스트 엔지니어링의 핵심은 친절함이 아니라 편집이다.

Harness 진단: 런타임의 실패를 본다

Harness Layer Diagnostic은 프롬프트 문장만 보고는 절대 보이지 않는 실패를 잡는다. 도구 집합, 에이전트 루프, 상태 아티팩트, 자기 검증, context management, 초기화/실행 분리, failure-mode mitigation, evals and metrics가 여기에 들어간다.

예를 들어 에이전트가 자꾸 일을 끝냈다고 착각한다면, “끝까지 해라”라는 문장을 추가하는 것만으로는 부족하다. 완료 판정 기준, 체크포인트, 테스트 명령, 진행 상태 파일, 실패 시 재시도 정책이 필요하다. 이것은 프롬프트가 아니라 하네스의 문제다.

하네스 진단은 이런 질문을 던진다.

• 모델이 쓸 도구는 최소이고 모호하지 않은가.
• 루프는 gather, plan, act, verify 순서를 갖는가.
• 상태는 대화창 밖의 파일이나 구조화 아티팩트로 남는가.
• 완료 판정은 모델의 선언이 아니라 검증 명령으로 결정되는가.
• 실패했을 때 같은 실수를 반복하지 않도록 기록되는가.

여기서 프롬프트 엔지니어링은 거의 소프트웨어 운영에 가까워진다.

검증은 느낌을 쪼갠다

Verification & Evaluation 10개 항목은 “좋은 답”을 쪼개서 판정 가능한 기준으로 만든다. Happy path, edge case, adversarial, regression이 있고, 스키마 준수, 지시 충실, 환각 억제, 종료 정확성 같은 루브릭이 붙는다.

중요한 것은 기준을 측정 방법과 합격선으로 바꾸는 일이다.

흐릿한 기준	운영 가능한 기준
관련성이 높다	필수 입력 5개 중 5개를 모두 반영한다
일관성이 있다	출력 필드가 스키마와 100% 일치한다
근거가 충분하다	사실 주장마다 출처 또는 “근거 없음” 표시가 있다
끝까지 했다	테스트 명령이 통과했고 미완료 항목이 0개다

이렇게 바꾸면 프롬프트 개선은 취향 싸움에서 벗어난다.

안티패턴은 금지문이 아니라 방향 전환이다

Anti-Pattern Guardrail 8개 항목도 흥미롭다. 엣지 케이스를 욱여넣는 것, 과도한 규정적 지시, 모호한 도구 추가, 맥락 비대화, 요청하지 않은 페르소나 발명, 섹션 중복, vibe 평가, 상태 아티팩트 생략 같은 문제를 잡는다.

여기서 중요한 점은 단순히 “하지 마라”가 아니라 대체 행동으로 바꾸는 것이다.

안티패턴	대체 행동
엣지 케이스 망라	대표 예시를 정전으로 큐레이션
모호한 도구 추가	도구 집합을 최소화하고 사용 조건 명시
vibe 평가	pass/fail 루브릭으로 전환
상태 아티팩트 생략	진행 파일, 체크포인트, 회귀 테스트 남기기

금지는 모델에게 빈칸을 남긴다. 대체 행동은 다음 발판을 준다.

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

내 프롬프트를 바로 리라이팅하지 말고 먼저 진단하라.
Prompt, Context, Harness 각 계층에 대해
현재 상태 / 결함·리스크 / 개선 방향을 표로 작성하라.
그 다음 가장 치명적인 결함 3개만 골라 개선하고,
마지막에는 happy path, edge case, adversarial, regression 테스트와
pass/fail 루브릭을 붙여라.

이 프롬프트는 “더 멋지게”가 아니라 “더 판정 가능하게” 만든다. PCH-Optimizer가 강한 이유는 바로 여기에 있다. 좋은 프롬프트를 문장으로만 보지 않고, 실패를 관찰하고 검증을 붙일 수 있는 작업 대상으로 만든다.

다음 글에서는 이 진단 결과를 실제 기법 메뉴와 조립 템플릿으로 어떻게 바꾸는지 다룬다.