프롬프트 1,400개를 지도처럼 읽기: PCH 카탈로그가 보이게 한 것

처음에는 단순한 정리 작업처럼 보였다. 책에서 프롬프트를 뽑고, 텍스트로 바꾸고, 엑셀에 넣으면 끝날 것 같았다. 그런데 11개의 원문 TXT에서 1,400개의 프롬프트 후보를 뽑아 놓고 보니, 이 작업은 프롬프트 수집이 아니라 작은 지도 제작에 가까웠다.

좋은 프롬프트는 한 문장이 아니다. 어떤 프롬프트는 작업의 출발점이고, 어떤 프롬프트는 맥락을 고정하는 장치이며, 어떤 프롬프트는 반복 실행을 통제하는 하네스에 가깝다. 그래서 이번 카탈로그는 원문 프롬프트 전문을 밖으로 옮기는 대신, 내부적으로 ID와 출처를 보존하고 공개 글에서는 패턴만 읽는 방식으로 다루기로 했다.

이번 묶음의 핵심 숫자는 이렇다.

항목	값
변환한 원문 TXT	11개
추출한 프롬프트 후보	1,400개
Prompt N 형식 블록	1,001개
가장 큰 범주	Creative Writing & Storytelling
실무형 범주	Content, Marketing, Product, Research, Education, Coding

여기서 흥미로운 점은 분포다. 창작 프롬프트가 압도적으로 많고, 실무 프롬프트는 상대적으로 적다. 처음에는 이 비율이 불균형처럼 보이지만, 조금 다르게 읽으면 좋은 힌트가 된다. 창작 프롬프트는 세계, 인물, 사건, 감정, 제약을 한꺼번에 다루는 훈련장이다. 반면 실무 프롬프트는 대개 한 줄 명령에서 시작해 맥락과 검증을 나중에 보강해야 한다.

프롬프트를 세 층으로 읽기

PCH는 Prompt, Context, Harness의 약자다. 같은 문장처럼 보여도 실제 역할은 다르다.

층	질문	카탈로그에서 보인 신호
Prompt	무엇을 하라고 하는가	쓰기, 요약, 분석, 생성, 변환
Context	무엇을 알고 해야 하는가	독자, 자료, 상황, 세계관, 제약
Harness	어떻게 반복하고 검증할 것인가	출력 형식, pass/fail, 단계, 체크리스트

많은 프롬프트는 Prompt 층에서 시작한다. “블로그 아이디어를 만들어라”, “코드를 설명하라”, “장면을 써라” 같은 요청이다. 하지만 실제로 쓸 만한 프롬프트는 Context를 요구한다. 누구를 위한 글인지, 어떤 자료를 근거로 삼는지, 어느 정도 깊이로 답해야 하는지, 무엇을 피해야 하는지 정해져야 한다.

그리고 반복해서 쓰려면 Harness가 필요하다. 결과가 좋은지 어떻게 판단할 것인가. 출력은 표인가, 글인가, JSON인가. 실패했을 때 다시 물어볼 기준은 무엇인가. 이 층이 없으면 프롬프트는 매번 운에 기대게 된다.

카탈로그는 프롬프트 저장소가 아니라 운영판이다

프롬프트를 많이 모으면 좋아질 것 같지만, 실제로는 금방 막힌다. 100개를 넘어가면 찾기 어렵고, 1,000개를 넘어가면 “많다”는 사실 말고는 잘 보이지 않는다. 그래서 이번 작업의 목적은 저장이 아니라 운영이다.

카탈로그에 필요한 열은 원문만이 아니었다.

• 원본 ID
• 출처 책과 줄 범위
• 추출 패턴
• MECE 카테고리
• PCH 층
• 대상 유형
• 의도 요약
• PCH 업그레이드 프롬프트

이 구조가 생기자 프롬프트가 검색 대상에서 설계 대상으로 바뀐다. “마케팅 프롬프트를 찾아줘”가 아니라 “마케팅 프롬프트 중 Context가 약한 것을 Harness까지 보강하자”가 된다. 이 차이가 크다.

내가 얻은 첫 번째 결론

프롬프트 엔지니어링은 더 멋진 문장을 쓰는 일이 아니라, 작업의 계약을 명확히 하는 일에 가깝다. 모델에게 맡길 일, 사용자가 제공해야 할 맥락, 결과를 검증할 기준이 한 프롬프트 안에서 만날 때 비로소 재사용 가능한 도구가 된다.

그래서 앞으로 이 카탈로그는 세 방향으로 읽어볼 생각이다.

1. 창작 프롬프트는 어떻게 세계와 감정의 제약을 만든다.
2. 실무 프롬프트는 왜 한 줄 명령에서 하네스로 확장되어야 한다.
3. 좋은 프롬프트 모음은 어떻게 개인의 LLM Wiki와 연결될 수 있다.

프롬프트는 문장이 아니라 인터페이스다. 이번 카탈로그는 그 인터페이스를 다시 설계하기 위한 첫 번째 지도다.