규칙 없이는 제대로 해낼 수 없습니다
본격적으로 시작하기 전에, 초등학교 때 선생님이 자주 “리밍”에게 편지를 쓰라고 했던 일을 기억하나요?
첫머리에는 흔히 “안녕하세요”라고 쓰고, 끝에는 때때로 “삼가 인사드립니다” 같은 형식을 넣어야 했습니다. 특히 시험에서는 하나라도 빠지면 감점됐습니다.
그때는 왜 이렇게 번거로워야 하는지 늘 궁금했습니다. 쪽지처럼 하고 싶은 말을 그냥 쓰면 안 되는 걸까요?
직장에 다닌 뒤 저는 이메일을 자주 써야 했습니다. 처음에는 일정한 형식을 따르지 않았는데, 급해지면 무언가를 빠뜨리기 쉽다는 것을 알게 됐습니다.
제 이름을 빼먹기도 하고 날짜를 누락하기도 했으며, 상대방이 다음에 무엇을 해야 하는지 알려 주지 않는 때도 있었습니다.
시간이 지나면서 저는 어릴 때처럼 일정한 순서에 따라 이메일을 점검하기 시작했습니다. 아무리 바빠도 핵심 내용을 빠뜨릴 가능성이 줄었습니다.
같은 일은 여러 업계에서도 볼 수 있습니다. 간호사, 승무원, 장비 조작자는 체크리스트에 따라 반복해서 확인합니다. 아주 단순해 보이는 일인데도 왜 그렇게 할까요?
사람은 누구나 빠뜨리는 것이 있기 때문입니다. 고정된 절차가 실수를 완전히 막아 주지는 않지만 누락을 줄일 수는 있습니다.
Prompt 작성도 마찬가지입니다.
작업이 복잡할 때 순서대로 점검할 수 있는 참고 템플릿을 준비할 수 있을까요?
그럴 수 있습니다.
하지만 이것은 누락을 줄이는 도구일 뿐, 모든 모델과 모든 작업에 맞는 “최고의 공식”은 아닙니다.
좋은 Prompt에는 무엇이 들어가야 할까요?
모든 정보를 넣고 자세할수록 좋을까요?
물론 아닙니다.
중국 시트콤 《무림외전》에서 옌샤오류는 자주 이렇게 묻습니다. “성은 뭐고 이름은 뭐야? 어디서 왔고 어디로 가? 식구는 몇 명이야? 한 사람당 밭은 몇 묘고, 밭에는 소가 몇 마리야?”
아주 구체적으로 들리지만, 당장 처리할 일과 관계없는 정보도 많습니다. 정보가 지나치게 많으면 오히려 방해가 될 수 있습니다.
정보가 너무 적으면 모델은 추측할 수밖에 없습니다. 관련 없는 정보가 너무 많아도 방해가 됩니다.
먼저 현실적인 상황 하나를 보겠습니다. 장산에게 쇠고기 파이 두 개를 사다 달라고 부탁하기입니다.
쇠고기 파이 두 개 사기
완전한 요구사항이 다음과 같다고 가정해 봅시다.
장산에게 지금 아래층 로손 편의점에 가서 개당 7위안인 쇠고기 파이 두 개를 사 달라고 하세요.
쇠고기 파이는 데워서 각각 종이봉투 두 개에 따로 담고, 20분 안에 가져와야 합니다.
여기에는 어떤 핵심 정보가 있을까요?
먼저 누구에게 사 오라고 할까요? 명확한 사람이 있어야 합니다. 사람들 사이에서 “쇠고기 파이 두 개 사다 줘”라고만 말하면 장산은 자신에게 한 말인지 알 수 없습니다. 이것이 역할 또는 대상입니다.
어디로, 언제 갈까요? 그렇지 않으면 장산이 내일 사거나 다른 매장에 갈 수도 있습니다. 이것이 행동의 시간과 장소입니다.
무엇을 몇 개, 얼마에 살까요? 이것이 작업과 제약입니다.
데워야 할까요? 이것이 구체적인 조작입니다.
어떻게 포장할까요? 이것이 전달 형식입니다.
얼마 만에 가져와야 할까요? 이 역시 제약 조건입니다.
장산에게 “가서 뭐 좀 사다 줘”라고만 말했다고 해 봅시다.
우리 마음속에 있던 쇠고기 파이 두 개를 정확히 사 올 수 있을까요?
가능성이 전혀 없는 것은 아닙니다. 하나도 빠짐없이 사 온다면 장산이 우리를 아주 잘 아는 것이겠죠.
하지만 대부분은 다시 물어보거나 스스로 추측할 수밖에 없습니다.
사람도 그런데 AI는 어떨까요?
모델에게 소설을 써 달라고 하면서 “소설 한 편 써 줘”라고만 하면, 머릿속에서 생각한 내용과 정확히 맞을 가능성은 낮습니다.
참고할 수 있는 구조
복잡한 Prompt에서는 다음 항목 중 필요한 내용을 선택할 수 있습니다.
Role(역할)
모델이 어떤 관점에서 작업하기를 원하는지 또는 결과가 누구를 위한 것인지 설명합니다.
역할을 쓴다고 모델이 실제 직업 자격을 얻거나 다른 분야의 지식을 “차단”하는 것은 아닙니다. 정말 유용한 것은 “코드 검토자의 방식으로 위험을 찾아라” 같은 역할 뒤의 구체적인 기준이지, “당신은 세계 최고의 엔지니어다” 같은 말이 아닙니다.
Skills(필요한 능력)
요약, 분류, 번역 또는 코드 설명처럼 작업에 필요한 능력을 나열합니다.
이것이 모델에 새로운 기능을 설치하는 것은 아닙니다. 작업에 필요한 처리 방식에 주의를 기울이도록 도울 뿐입니다. 간단한 작업에서는 이 항목을 생략해도 됩니다.
Action(행동)
모델이 무엇을 완료해야 하는지 직접 말합니다.
예를 들면 회의록에서 할 일을 추출하기, 코드의 오류를 검사하기, 주제에 따라 이야기 개요 작성하기가 있습니다.
Constraints(제약)
해서는 안 되는 일, 정보가 부족할 때 처리할 방법, 길이, 언어, 안전과 사실의 경계를 설명합니다.
예: 원문에 없는 정보를 추가하지 않기, 불확실하면 “제공되지 않음”이라고 쓰기, 한국어로 답하기.
Format(형식)
Markdown, 표, JSON 또는 고정된 필드 중 어떤 형태로 받을지 설명합니다.
Example(예시)
규칙이 추상적일 때 입력과 출력 예시를 하나 제공해 모델이 대응 관계를 이해하도록 돕습니다.
구조를 하나의 Prompt에 넣기
# Role
공상 과학 이야기 편집자
## Action
사용자가 제시한 주제에 따라 등장인물 설정, 이야기의 갈등과 3막 개요를 제공하세요.
## Constraints
- 기존 작품의 유명한 등장인물이나 줄거리를 사용하지 않습니다.
- 정보가 부족하면 필요한 확인 질문을 먼저 나열하고 임의로 채우지 않습니다.
- 세계관은 가상이어도 되지만 내부 규칙은 처음부터 끝까지 일관되어야 합니다.
## Format
Markdown을 사용해 “등장인물, 갈등, 개요, 확인할 질문”의 네 부분으로 출력하세요.
## Example
등장인물: 성간 항로를 수리하는 엔지니어.
갈등: 한 번의 수리 작업에서 두 문명 사이에 감춰진 역사가 드러난다.
이 템플릿은 그대로 복사해야 하는 표준 답안이 아닙니다.
문장 하나를 자연스럽게 다듬는 일이라면 여섯 부분을 모두 쓸 필요가 없습니다. 긴 자료, 여러 사람의 협업 또는 프로그램의 후속 처리가 포함된 작업일수록 구조의 가치가 커집니다.
간단한 작업은 간단히 쓰세요.
복잡한 작업에서는 템플릿으로 빠진 것이 없는지 확인하세요.
이전 장: 좋은 출력을 얻는 여섯 가지 방법
다음 장: 모델에서 JSON 데이터 출력하기
Independent product builder · AI, agents and real workflows.