PCH-Optimizer는 프롬프트 운영체제다

PCH-Optimizer prompt catalog를 다시 보니, 이것은 단순한 “프롬프트 개선 프롬프트”가 아니다. 더 정확히는 프롬프트를 받아서 분류하고, 필요한 계층만 펼치고, 진단하고, 조립하고, 검증하고, 인계하는 작은 운영체제에 가깝다.

이번 글은 115개 카탈로그 항목 중 45개를 다룬다. 원문 전체를 공개 덤프로 옮기기보다, 공개 글에서는 구조와 블로그 아이디어를 뽑아낸다.

묶음	항목 수	읽는 관점
Meta-System Prompt	4	업그레이더의 정체성과 임무
Operating Principle	8	모든 판단의 헌법
Input Metadata	7	프롬프트 앞단의 입력 계약
Target Type Classifier	7	T1-T7 분류기
Layer Scope Rule	4	어떤 계층을 펼칠지 정하는 스위치
Pipeline Stage	9	CLASSIFY에서 HANDOFF까지의 실행 순서
Output Contract	6	최종 답변의 섹션 계약
합계	45	운영체제 레이어

왜 운영체제인가

프롬프트를 업그레이드할 때 흔한 실수는 곧장 문장을 고치는 것이다. 더 친절하게, 더 자세하게, 더 구조적으로. 그런데 PCH-Optimizer는 그 전에 멈춘다. 먼저 이 프롬프트가 어떤 종류의 일인지 묻는다.

단발 지시인가. 예시 기반 추출인가. 근거 기반 생성인가. 도구를 쓰는 에이전트인가. 서브에이전트인가. 장기 실행 하네스인가. 창작·페르소나형인가.

이 질문은 사소하지 않다. 유형이 달라지면 개선해야 할 계층이 달라진다. T1 단발 지시형은 Prompt 계층이 핵심이고 Harness는 접어도 된다. T3 근거 기반 생성형은 Context와 인용 정책이 핵심이다. T4나 T6는 프롬프트 문장보다 도구, 상태, 종료 조건, 검증 루프가 더 중요해진다.

운영체제의 첫 번째 일은 작업을 올바른 프로세스로 배치하는 것이다. PCH-Optimizer도 똑같이 작동한다.

8개의 원리는 커널이다

카탈로그의 Operating Principle 8개는 기법보다 앞선다. 특정 기법을 많이 적용하는 것이 목표가 아니라, 원리를 깨지 않는 선에서 필요한 만큼만 고치는 것이 목표다.

내가 가장 자주 다시 보게 된 원리는 네 가지다.

원리	프롬프트 설계에서의 의미
맥락은 유한·감쇠 자원이다	토큰을 더 넣기보다 고신호 토큰만 남긴다
적정 고도	과도한 하드코딩과 과도한 모호함 사이를 찾는다
모델과 하네스를 분리한다	실패 원인이 문장인지 런타임인지 나눈다
신뢰보다 검증	느낌 평가가 아니라 pass/fail 기준을 붙인다

이 원리들이 없으면 프롬프트 개선은 장식 경쟁이 된다. XML을 붙이고, 예시를 붙이고, 체크리스트를 붙이고, 금지어를 붙인다. 하지만 정작 결과가 좋아졌는지, 어떤 계층이 좋아졌는지 모른다.

원리는 “더 많이”가 아니라 “왜 이만큼인가”를 묻는다.

입력 메타데이터는 프롬프트 앞단의 API다

PCH-Optimizer가 요구하는 입력은 원본 프롬프트 하나로 끝나지 않는다. target model, deployment surface, available tools, constraints, known failures, success criteria 같은 메타데이터가 붙는다.

이것은 API 설계와 닮았다. 함수에 인자가 부족하면 내부에서 추측이 늘어난다. 프롬프트도 마찬가지다. 모델 종류를 모르면 추론형 모델에 맞는 여지를 줄지, 비추론형 모델에 더 명시적인 사고 발판을 줄지 결정하기 어렵다. 배치 표면을 모르면 단발 답변인지, RAG인지, 에이전트 루프인지 알 수 없다.

그래서 프롬프트 업그레이드의 좋은 첫 질문은 이렇다.

이 프롬프트는 어디에서 실행되는가?
모델은 무엇을 볼 수 있는가?
도구와 상태는 있는가?
성공은 어떻게 판정되는가?
이미 실패한 사례는 무엇인가?

이 다섯 질문만 있어도 프롬프트는 훨씬 덜 흔들린다.

T1-T7 분류는 블로그 아이디어 생성기다

Target Type Classifier는 그 자체로 블로그 주제 묶음이 된다.

유형	블로그로 뽑을 수 있는 질문
T1 단발 지시형	한 줄 요청을 어디까지 구조화해야 할까
T2 퓨샷·추출/분류형	예시는 몇 개가 적정한가
T3 근거기반 생성형	인용과 환각 억제는 프롬프트인가 컨텍스트인가
T4 에이전트 시스템 프롬프트	도구를 가진 모델은 왜 하네스가 필요한가
T5 서브에이전트	좁은 역할이 왜 더 강한가
T6 장기실행 하네스	컨텍스트 창을 넘는 작업은 어떻게 이어지는가
T7 창작·페르소나형	목소리와 세계관은 어떻게 계약이 되는가

이 표만으로도 시리즈 하나가 나온다. 중요한 점은 유형을 먼저 정하면 글의 각도도 함께 정해진다는 것이다. T3 글은 출처성, 검색, 인용을 다룬다. T6 글은 상태 아티팩트와 컴팩션을 다룬다. T7 글은 감정 압력과 목소리를 다룬다.

6단계 파이프라인은 글쓰기 파이프라인이기도 하다

PCH-Optimizer의 6단계는 CLASSIFY, DIAGNOSE, ENGINEER, ASSEMBLE, VERIFY, HANDOFF다. 이 순서는 프롬프트 개선뿐 아니라 블로그 글 작성에도 그대로 쓸 수 있다.

단계	프롬프트 업그레이드	블로그 작성으로 바꾸면
CLASSIFY	대상 유형과 범위 판정	이 글의 독자와 문제 유형 정하기
DIAGNOSE	결함과 리스크 찾기	왜 이 주제가 어려운지 드러내기
ENGINEER	필요한 기법 선택	글의 설명 장치와 예시 고르기
ASSEMBLE	복사 가능한 산출물 만들기	읽을 수 있는 글 구조로 조립하기
VERIFY	테스트와 루브릭 붙이기	주장, 수치, 링크, 이미지 확인하기
HANDOFF	변경 로그와 다음 반복	독자가 다음에 해볼 질문 남기기

프롬프트 카탈로그를 블로그로 바꾸는 작업도 결국 이 파이프라인을 탔다. 먼저 전체 카탈로그를 분류했고, 이미 쓴 글과 빈틈을 진단했고, 115개 항목을 세 묶음으로 나눴고, 각 묶음을 글로 조립했다.

출력 계약은 독자를 위한 약속이다

Output Contract 6개 항목은 답변의 번호와 순서를 고정한다. 분류, 진단, 기법 설계, 업그레이드 산출물, 검증, 인계. 이 순서가 있으면 모델 답변은 읽을 수 있는 보고서가 된다.

블로그도 마찬가지다. 좋은 시리즈는 독자에게 반복되는 약속을 준다.

• 이번 글이 다루는 카탈로그 범위
• 왜 이 묶음이 중요한지
• PCH 관점에서 무엇이 보이는지
• 실제로 쓸 수 있는 프롬프트 아이디어
• 다음 글로 이어지는 질문

이 구조를 반복하면 시리즈 전체가 하나의 하네스처럼 작동한다. 독자는 매번 새 글을 읽지만, 읽는 방식은 점점 익숙해진다.

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

당신은 프롬프트 운영체제 설계자다.
내가 제공하는 원본 프롬프트를 바로 고치지 말고,
먼저 T1-T7 유형, 필요한 P/C/H 계층, 성공 기준, 배치 표면을 분류하라.
그 다음 필요한 계층만 펼쳐 업그레이드하고,
마지막에 이 프롬프트를 반복 사용하기 위한 출력 계약과 검증 기준을 제시하라.

이 프롬프트의 핵심은 속도보다 순서다. 바로 답을 만드는 대신, 먼저 운영체제가 작업을 어디에 배치할지 결정한다. 프롬프트 엔지니어링이 문장술에서 시스템 설계로 이동하는 순간이 여기 있다.

다음 글에서는 이 운영체제가 실제로 무엇을 진단하고, 어떤 기준으로 “좋아졌다”고 말할 수 있는지 다룬다.