프롬프트 기법은 트릭이 아니라 패턴 언어다

프롬프트 카탈로그에서 Prompt Engineering Technique으로 묶인 항목은 49개였다. 창작 프롬프트 1,164개와 비교하면 작아 보이지만, 이 묶음은 꽤 중요하다. 여기에는 “무엇을 써라”보다 “어떻게 요청해야 결과가 안정되는가”라는 질문이 들어 있기 때문이다.

흥미로운 점은 기법 프롬프트가 대단히 화려하지 않다는 것이다. JSON으로만 답하라, 예시를 먼저 보이라, 짧고 강한 태그라인을 쓰라, 특정 형식으로 답하라 같은 요청이 많다. 겉으로 보면 작은 문장이다. 하지만 이 문장들은 모델에게 작업의 모양을 알려주는 신호다.

트릭과 패턴은 다르다

프롬프트 기법을 트릭으로 보면 매번 새로운 주문을 찾게 된다. 반대로 패턴으로 보면, 같은 문제를 여러 상황에 다시 적용할 수 있다.

트릭처럼 볼 때	패턴처럼 볼 때
특정 문구가 마법처럼 작동한다고 믿는다	어떤 역할을 하는 문구인지 본다
모델별 우회 문장을 외운다	입력, 출력, 검증 조건을 분리한다
결과가 좋아지면 이유를 기록하지 않는다	성공 조건을 다음 템플릿에 남긴다
실패하면 다른 문구를 덧붙인다	어디서 실패했는지 구조를 본다

프롬프트 기법의 핵심은 더 특이한 표현을 찾는 것이 아니다. 같은 요청을 더 명확한 작업 인터페이스로 바꾸는 것이다.

패턴 언어의 기본 블록

이번 묶음을 PCH 관점으로 다시 보면, 프롬프트 기법은 대체로 다섯 가지 블록으로 나뉜다.

블록	하는 일
역할 고정	모델이 어떤 관점에서 답할지 정한다
출력 계약	표, 목록, JSON, 코드 블록 같은 형식을 고정한다
예시 제공	좋은 답의 모양을 한 번 보여준다
제약 조건	길이, 어조, 독자, 금지 사항을 정한다
복구 규칙	형식이 틀리거나 정보가 부족할 때 다시 처리하게 한다

이 다섯 블록은 독립된 팁이 아니다. 서로 조합되는 작은 언어다. 예를 들어 출력 계약만 있으면 답은 깔끔해질 수 있지만, 근거 기준이 없으면 내용은 여전히 흔들릴 수 있다. 예시만 있으면 톤은 따라오지만, 실패 처리 규칙이 없으면 잘못된 형식을 그대로 낼 수 있다.

좋은 기법은 모델보다 작업을 설명한다

많은 사람이 프롬프트 엔지니어링을 모델을 설득하는 기술로 생각한다. 하지만 실제로 오래 쓰이는 기법은 모델의 심리를 겨냥하지 않는다. 작업을 설명한다.

예를 들어 “좋은 답을 줘”보다 “세 개의 대안을 만들고, 각 대안의 장점, 위험, 필요한 입력을 표로 정리하라”가 낫다. 이유는 더 공손해서가 아니다. 작업의 단위가 보이기 때문이다.

좋은 기법은 다음 질문에 답한다.

1. 모델은 어떤 역할을 맡는가.
2. 사용자는 무엇을 입력해야 하는가.
3. 모델은 어떤 형식으로 답해야 하는가.
4. 답 안에 무엇이 반드시 포함되어야 하는가.
5. 정보가 부족하면 어떻게 멈추거나 되물어야 하는가.

이 질문에 답하지 않는 기법은 잠깐 효과가 있어도 재사용하기 어렵다.

짧은 프롬프트도 업그레이드할 수 있다

카탈로그에는 짧은 창작 요청처럼 보이는 항목도 많이 있었다. 태그라인, 하이쿠, 소네트, 짧은 묘사 같은 것들이다. 이런 프롬프트는 단순해 보이지만, 업그레이드 연습에는 좋다. 짧기 때문에 빠진 조건이 더 잘 보인다.

예를 들어 “짧고 기억에 남는 태그라인을 써라”는 요청은 이렇게 바꿀 수 있다.

층	보강 질문
Prompt	무엇을 위한 태그라인인가
Context	대상 고객, 브랜드 톤, 피해야 할 표현은 무엇인가
Harness	몇 개를 만들고 어떤 기준으로 고를 것인가

이렇게 보면 프롬프트 기법은 긴 프롬프트를 쓰는 법이 아니다. 짧은 요청 안에 숨어 있는 결정을 꺼내는 법이다.

내 카탈로그에 남길 것

앞으로 프롬프트를 저장할 때 원문 옆에 반드시 붙이고 싶은 컬럼이 있다.

컬럼	이유
패턴 이름	나중에 비슷한 작업에 다시 쓰기 위해
출력 계약	결과를 자동으로 검사하거나 재가공하기 위해
실패 조건	모델이 멈춰야 할 순간을 정하기 위해
예시 필요 여부	few-shot이 필요한 작업인지 판단하기 위해
재사용 범위	개인 메모용인지 팀 워크플로용인지 구분하기 위해

이 다섯 가지가 붙으면 프롬프트는 더 이상 외워야 할 문장이 아니다. 필요할 때 꺼내 조립할 수 있는 패턴 언어가 된다.

그래서 프롬프트 기법을 모을 때 중요한 것은 개수보다 분류다. 얼마나 많은 팁을 알고 있는가보다, 그 팁이 어떤 문제를 해결하는지 아는 편이 훨씬 오래 간다.