프롬프트 엔지니어링 공부 노트, 자주 쓰는 패턴 정리

 

ChatGPT를 쓰기 시작한 지 몇 달이 지나면서, 같은 질문인데도 결과가 들쭉날쭉한 경험을 자주 하게 됐어요.
어떤 날은 놀랄 만큼 정리가 잘 되어 나오고, 어떤 날은 엉뚱한 방향으로 흘러갑니다.
그래서 "내가 뭘 다르게 썼지?"를 되짚어 보다가 프롬프트 작성법을 따로 공부하기 시작했습니다.
이번 글은 공부하면서 정리한 패턴 다섯 가지와, 제가 직접 써본 예, 그리고 한계를 적어둔 노트입니다.
전문가가 쓴 글은 아니고, 기획 일을 하면서 써보고 남긴 기록이라고 생각해 주세요.

 

공부하다 보니 좋은 프롬프트의 조건이 좋은 요구사항 정의서와 비슷하다는 생각이 들었어요.
누가 읽는지, 무엇을 원하는지, 어떤 형식으로 받고 싶은지, 하지 말아야 할 것은 무엇인지가 빠지면 결과가 흔들립니다.
사람 개발자에게 "예약 알림 좀 만들어주세요"라고만 말하면 되돌아오는 질문이 많은 것처럼, 모델도 마찬가지입니다.
다만 사람은 되물어주는데, 모델은 되묻지 않고 그럴듯하게 채워 넣는다는 점이 달라요.
그래서 처음부터 빈칸이 없게 쓰는 연습이 필요했습니다.

 

패턴 1, 역할 지정
"당신은 동네 미용실의 예약 안내 담당자입니다"처럼 역할을 먼저 주는 방식입니다.
역할을 주면 말투와 관점이 어느 정도 고정돼요.
같은 질문이라도 "고객센터 상담원" 관점과 "서비스 기획자" 관점에서 나오는 답이 확실히 다릅니다.
다만 역할을 거창하게 주는 것보다, 대상과 상황을 같이 적어주는 쪽이 효과가 컸어요.
"20~30대 고객에게, 짧고 정중하게" 같은 조건이 붙으면 훨씬 쓸 만해집니다.

패턴 2, 예시 제공(few-shot)
원하는 결과물의 예시를 한두 개 보여주는 방식입니다.
설명으로 길게 풀어쓰는 것보다 예시 두 개가 더 정확할 때가 많았어요.
예를 들어 문의를 분류하고 싶다면 이렇게 적어봅니다.
"문의: 내일 오후에 커트 가능한가요? / 분류: 예약 가능 여부"
"문의: 어제 예약한 거 취소하고 싶어요 / 분류: 취소"
"문의: 주차는 되나요? / 분류: 매장 정보"
이렇게 몇 개를 보여준 뒤 새 문의를 넣으면, 분류 이름과 출력 모양까지 따라 해줍니다.
예시를 고를 때는 쉬운 것만 넣지 말고, 애매한 경계 사례도 하나쯤 넣는 게 좋다고 하더라고요.
예시의 말투나 길이를 결과가 그대로 닮는 경향이 있어서, 예시를 고르는 일이 곧 품질을 정하는 일이라고 느꼈습니다.

패턴 3, 단계적으로 생각하게 하기
복잡한 문제를 한 번에 풀게 하면 틀리기 쉽고, "단계별로 나눠서 생각해 보세요"라고 하면 정확도가 올라간다는 이야기를 여러 곳에서 봤습니다.
저도 간단한 계산 문제로 확인해 봤어요.
가상의 상황으로, "영업시간 10시~20시, 브레이크 13시~14시, 서비스 50분, 슬롯 간격 30분일 때 가능한 시작 시각을 구해줘"라고 그냥 물으면 가끔 브레이크를 빼먹었습니다.
반면 "먼저 영업 구간을 나누고, 그다음 각 구간에서 서비스가 들어갈 수 있는 시작 한계를 계산한 뒤 목록을 만들어줘"라고 순서를 주니 훨씬 안정적이었어요.
다만 중간 과정이 길어지면 그 안에서 틀린 계산을 그대로 이어가기도 해서, 결과는 반드시 직접 검산해야 했습니다.

패턴 4, 출력 형식 지정
받은 결과를 다른 곳에 붙여 쓰려면 형식이 고정되어야 합니다.
"표로", "번호 목록으로", "세 줄 이내로", "JSON 형태로"처럼 모양을 명시하면 후처리가 쉬워져요.
특히 항목 이름을 직접 정해주면 좋았습니다.
예를 들어 "제목, 핵심 요약, 확인이 필요한 부분 세 가지 항목으로 나눠서 써줘"라고 하면 매번 같은 틀이 나와서 비교하기도 편합니다.
형식을 지정해도 가끔 틀을 어기는 경우가 있어서, 중요한 곳에서는 "형식 외의 설명은 쓰지 마세요"를 덧붙이곤 합니다.

패턴 5, 제약 조건 명시
하지 말아야 할 것을 적어두는 방식입니다.
"모르는 내용은 추측하지 말고 '확인이 필요합니다'라고 답하세요", "가격은 언급하지 마세요", "200자 이내로" 같은 문장들이죠.
사실 확인이 중요한 일에서는 이 패턴이 가장 중요하다고 느꼈어요.
제약이 없으면 모델은 빈틈을 자연스럽게 메우려고 하고, 그게 그럴듯한 오답이 되기 때문입니다.
제약은 많을수록 좋은 게 아니라, 꼭 지켜야 할 서너 가지로 추려서 쓰는 쪽이 오히려 잘 지켜졌습니다.

 

다섯 가지를 합쳐서 연습용으로 이런 프롬프트를 만들어 봤습니다.
가상의 미용실 상황이에요.

"당신은 동네 미용실의 예약 안내 담당자입니다.
아래 영업 정보만 근거로 고객 문의에 답변 초안을 작성하세요.
영업시간은 10시~20시, 매주 월요일 휴무, 커트는 40분, 파마는 120분입니다.
정보에 없는 내용은 추측하지 말고 '확인 후 안내드리겠습니다'라고 쓰세요.
말투는 정중하고 짧게, 세 문장 이내로 쓰세요.
문의: 이번 주 일요일 저녁에 파마 가능한가요?"

이 프롬프트로 받은 초안은 일요일 영업은 가능하지만 파마는 120분이 걸리니 마감 시간을 고려해 늦은 시작은 어렵다는 취지로 나왔고, 구체적인 빈 시간은 "확인 후 안내"로 넘겼습니다.
이 정도면 운영하시는 분이 다듬어서 보낼 초안으로는 충분해 보였어요.
반대로 제약 문장을 빼고 돌려봤을 때는 "저녁 6시와 7시가 비어 있습니다" 같은 있지도 않은 정보를 만들어 내는 경우가 있었습니다.
같은 모델인데 제약 한 줄 차이로 이렇게 달라지는 걸 보고 꽤 인상 깊었어요.

 

공부하면서 느낀 한계도 정리해 둘게요.

첫째, 같은 프롬프트라도 결과가 매번 조금씩 다릅니다.
그래서 "한 번 잘 나왔다"를 "잘 동작한다"로 착각하면 안 되고, 여러 번 돌려 보며 확인해야 해요.

둘째, 프롬프트는 모델이 모르는 사실을 알려주지 못합니다.
최신 정보나 업장의 내부 정책은 프롬프트에 직접 넣어줘야 하고, 그게 길어지면 따로 문서를 찾아 붙이는 구조가 필요하다는 생각이 들었어요.

셋째, 프롬프트의 요령은 모델이 바뀌면 달라질 수 있어서, 요령 자체보다는 "내가 원하는 것을 빈틈없이 말로 쓰는 습관"을 남기는 쪽이 오래간다고 봅니다.

 

아직 답을 못 찾은 건, 프롬프트를 어떻게 버전 관리하고 품질을 비교할 것인가 하는 문제입니다.

감으로 좋다 나쁘다를 말하는 단계는 넘어서고 싶은데, 기준을 어떻게 세울지는 더 공부해 봐야겠어요.