실무 프롬프트는 왜 하네스가 필요할까

창작 프롬프트가 컨텍스트 설계의 감각을 보여준다면, 실무 프롬프트는 하네스의 필요성을 보여준다. 이번 카탈로그에는 카피라이팅, 마케팅, 제품, 리서치, 교육, 코딩 프롬프트가 비교적 작은 묶음으로 들어 있었다. 수는 많지 않지만, 실제 업무에서는 이쪽이 더 자주 호출된다.

실무 프롬프트의 특징은 간단하다. 대부분 한 줄로 시작한다.

• 블로그 아이디어를 만들어라.
• 리뷰를 분석해 불만을 요약하라.
• 마케팅 캠페인 작업 목록을 만들어라.
• 코드를 설명하거나 변환하라.
• 학습자에게 개념을 쉽게 설명하라.

이 요청들은 틀리지 않았다. 다만 이대로는 반복 가능한 도구가 되기 어렵다. 같은 프롬프트를 내일 다시 썼을 때 같은 수준의 결과가 나올지 알 수 없고, 누가 검토해도 통과 기준이 분명하지 않다.

한 줄 프롬프트의 약점

한 줄 프롬프트는 빠르다. 하지만 빠른 만큼 숨겨진 결정을 모델에게 떠넘긴다.

숨겨진 결정	모델이 임의로 채우는 것
독자	초보자인지 전문가인지
목적	설득인지 설명인지 의사결정인지
자료	어떤 근거를 써야 하는지
형식	표, 글, 목록, JSON 중 무엇인지
품질 기준	무엇이 좋은 답인지

그래서 실무 프롬프트를 업그레이드할 때는 더 길게 쓰는 것이 목표가 아니다. 숨겨진 결정을 밖으로 꺼내는 것이 목표다.

하네스는 결과를 붙잡는 장치다

Harness는 모델을 통제하기 위한 딱딱한 틀이 아니다. 반복 가능한 작업을 만들기 위한 최소한의 작업대다. 좋은 하네스에는 보통 네 가지가 들어간다.

구성요소	질문
입력 계약	사용자가 무엇을 제공해야 하는가
출력 계약	모델은 어떤 형식으로 답해야 하는가
검증 기준	어떤 답이 통과인가
실패 처리	정보가 부족하면 어떻게 해야 하는가

예를 들어 “고객 리뷰를 요약하라”는 프롬프트는 이렇게 확장될 수 있다.

1. 리뷰 원문, 제품명, 분석 목적을 입력으로 받는다.
2. 긍정/부정 테마, 반복 불만, 대표 근거, 우선순위를 표로 낸다.
3. 근거 없는 추측은 분리한다.
4. 리뷰 수가 적거나 편향되어 있으면 먼저 경고한다.
5. 마지막에 다음 액션 3개를 제안한다.

이것이 하네스다. 결과를 멋지게 만드는 장식이 아니라, 결과가 일에 쓰일 수 있게 붙잡는 구조다.

PCH 업그레이드의 실제 감각

이번 카탈로그에서 모든 프롬프트는 PCH 업그레이드 컬럼을 갖도록 만들었다. 핵심은 원본 의도를 유지하면서도 사용자가 바로 실행할 수 있는 형태로 바꾸는 것이다.

내가 실무 프롬프트를 업그레이드할 때 보는 순서는 이렇다.

1. 동사를 찾는다. 생성, 분석, 요약, 변환, 평가 중 무엇인가.
2. 빠진 입력을 찾는다. 대상, 자료, 제약, 목적이 있는가.
3. 출력 형식을 정한다. 글, 표, 체크리스트, JSON 중 무엇이 맞는가.
4. 검증 기준을 붙인다. 누락, 추측, 과장, 형식 오류를 어떻게 잡을 것인가.
5. 반복 실행을 생각한다. 다음 번에도 같은 방식으로 쓸 수 있는가.

이 순서를 거치면 프롬프트는 “부탁 문장”에서 “업무 인터페이스”로 바뀐다.

프롬프트 모음의 다음 단계

실무 프롬프트는 많을수록 좋은 것이 아니다. 같은 유형의 프롬프트가 많아지면 오히려 선택 피로가 생긴다. 중요한 것은 대표 프롬프트를 뽑고, 각 대표 프롬프트를 하네스로 바꾼 뒤, 나의 실제 작업 흐름에 연결하는 것이다.

예를 들면 이런 묶음이 가능하다.

묶음	대표 하네스
콘텐츠 제작	아이디어 → 아웃라인 → 초안 → 압축 요약
마케팅 분석	리뷰 → 테마 → 우선순위 → 실험안
리서치	자료 → 주장 → 근거 → 반론 → 빈칸
코딩	요구사항 → 구현 → 테스트 → 실패 케이스
교육	개념 → 예시 → 오개념 → 연습문제

결국 실무 프롬프트의 목적은 “한 번 좋은 답”이 아니다. 다음에도 쓸 수 있는 작은 업무 장치를 만드는 것이다.

그래서 나는 앞으로 프롬프트를 저장할 때 원문만 남기지 않으려 한다. 함께 남겨야 할 것은 실행 조건, 출력 계약, 검증 기준이다. 이 세 가지가 붙을 때 프롬프트는 내 작업 흐름의 일부가 된다.