프롬프트 엔지니어링 기초: 완벽 가이드
프롬프트 엔지니어링의 핵심 원칙을 마스터하여 어떤 AI 모델에서든 일관되게 더 나은 결과를 얻으세요.
언어 모델이 프롬프트를 실제로 읽는 방식
대규모 언어 모델은 동료가 요청을 이해하듯 이해하지 않습니다. 현재 컨텍스트 윈도우에 있는 모든 내용을 조건으로, 다음 토큰이라는 작은 텍스트 조각을 하나씩 예측할 뿐입니다. 여기서 세 가지 실용적인 결론이 나옵니다.
프롬프트는 명령이 아니라 확률 분포를 형성합니다. 단어 하나를 추가할 때마다 모델이 그럴듯하다고 여기는 이어질 내용이 달라집니다. "원격 근무에 대해 써줘"는 수천 가지 방향을 열어두기 때문에 그 모든 것의 평균 같은 결과가 나옵니다. "40인 규모 디자인 에이전시의 새 원격 근무 정책을 공지하는 300단어 내부 메모를, 따뜻하지만 직접적인 어조로 써줘"는 그 공간을 좁은 범위로 압축하고, 그 대부분은 여러분이 원하던 것에 가깝습니다.
위치가 중요합니다. 모델은 프롬프트의 시작과 끝에 불균형하게 많은 주의를 기울입니다. 긴 프롬프트에서 중간에 파묻힌 지시는 무시될 가능성이 가장 높은데, 이는 흔히 "중간 손실(lost in the middle)" 효과로 보고되는 현상입니다. 작업은 앞부분에 명시하고, 분량이 큰 참고 자료는 중간에 두고, 핵심 제약은 끝에서 다시 언급하세요.
긴 컨텍스트는 성능이 저하됩니다. 대화가 길어지거나 큰 문서를 붙여 넣을수록 모든 지시가 점점 더 많은 텍스트와 경쟁합니다. 열 메시지 전에 정한 규칙을 모델이 따르지 않게 되었다면, 인간적인 의미로 잊어버린 것이 아닙니다. 규칙이 희석된 것입니다. 가장 최근 메시지에서 핵심 지시를 반복하는 것이 저렴하고 확실한 해결책입니다.
강력한 프롬프트의 해부학
신뢰할 수 있는 프롬프트 대부분은 다섯 가지 재료를 담고 있습니다. 매번 다섯 가지가 전부 필요한 것은 아니지만, 출력 품질이 실망스러울 때는 대개 이 중 하나가 빠져 있습니다.
역할. 어떤 관점에서 쓸지 알려주세요: "당신은 개발자 문서를 담당하는 시니어 테크니컬 에디터입니다." 역할 문장이 마법은 아니지만, 어휘와 깊이, 우선순위를 올바른 방향으로 꾸준히 밀어줍니다.
작업. 무엇을 만들어야 하는지 동사로 시작하는 명확한 한 문장으로 명시하세요. 작업을 한 문장으로 표현할 수 없다면 모델도 그 작업에 어려움을 겪습니다.
맥락. 모델이 추측할 수 없는 배경 정보입니다: 독자가 누구인지, 출력이 어디에 쓰일지, 이미 무엇이 결정되었는지. 맥락 누락은 출력이 뻔하게 느껴지는 가장 흔한 이유입니다.
형식. 답변의 모양입니다: 섹션 수, 불릿 사용 여부, 단어 수 제한, 필수 항목. 이것이 없으면 모델이 추측하는데, 그 추측은 대개 여러분이 원하는 것보다 길고 장식이 많습니다.
제약. 피해야 할 것과 함께 대신 해야 할 것을 제시하세요: "마케팅식 과장 표현을 쓰지 마세요. 평이한 동사를 선호하세요." 모든 금지 사항에 긍정적 대안을 짝지어 주는 방식이 금지 목록만 나열하는 것보다 눈에 띄게 잘 작동합니다.
말하지 말고 보여주기: 퓨샷 예시
모델은 추상적인 스타일 설명을 따르는 것보다 패턴을 모방하는 데 훨씬 더 능합니다. 특정한 어조, 구조, 라벨링 방식이 필요하다면 입력과 출력 예시 두세 개를 프롬프트에 직접 포함하세요. 알아둘 세 가지가 있습니다.
- 예시와 서면 지시가 충돌하면 대개 예시가 이깁니다. 그러니 예시를 점검하세요. - 형식은 새어 나옵니다. 모든 예시 답변이 두 문장이면, 지시에 뭐라고 썼든 실제 답변도 두 문장 안팎으로 나옵니다. - 일관성 없는 예시는 없는 것보다 나쁩니다. 모델이 패턴을 평균 내기 때문입니다.
전과 후: 실전 예제
전: "이 고객 피드백을 요약해줘."
이렇게 하면 대개 불만 몇 가지와 칭찬 몇 가지를 언급하는 매끄럽고 뻔한 문단이 돌아오고, 실행에 옮길 만한 내용은 없습니다.
후: "당신은 프로덕트 분석가입니다. 아래 고객 피드백을 다음 분기 로드맵을 계획하는 제품팀을 위해 요약하세요. 불만 사항을 최대 다섯 개의 테마로 묶으세요. 각 테마마다 짧은 굵은 글씨 제목, 테마를 설명하는 한 문장, 대표 인용문 하나를 제시하세요. 마지막에 우선순위를 두어야 할 테마 두 개와 그 이유를 제시하세요. 전체 응답은 250단어 이내로 유지하세요. 피드백이 어떤 테마를 명확히 뒷받침하지 않는다면, 지어내지 말고 그렇다고 말하세요."
두 번째 버전의 모든 문장은 다섯 가지 재료 중 하나에 대응하며, 마지막 문장은 깔끔한 답을 지어내려는 모델의 성향을 직접 겨냥합니다.
흔한 실수
- 서로 무관한 여러 작업을 한 문장에 쌓아 올려 모델의 주의를 분산시키는 것. - "매력적으로", "전문적으로" 같은 모호한 품질 단어를, 그 단어가 여러분에게 무엇을 의미하는지 설명하지 않고 쓰는 것. - 모델이 여러분의 회사, 프로젝트, 한 번도 알려준 적 없는 결정 사항을 알고 있으리라 가정하는 것. - 좋은 답이 어떤 모습인지에 대한 힌트 없이 금지 사항만 나열하는 것. - 첫 번째 출력을 최종본으로 받아들이는 것. 초안으로 취급하고, 텍스트만이 아니라 프롬프트를 다듬으세요. - "이거 맞아?"라고 묻고 그 답을 믿는 것. 모델은 기본적으로 동조적이어서 여러분이 제시하는 것을 그대로 인정해 주는 경우가 많습니다.
한계 알기
어떤 프롬프트도 모델이 모르는 사실에 대해 모델을 신뢰할 수 있게 만들지 못합니다. 모델은 인용, 통계, 제품 세부 정보를 유창하고 자신 있게 지어내며, 잘 구조화된 프롬프트는 그런 날조를 오히려 더 그럴듯해 보이게 만들 수 있습니다. 저희 테스트에서 도움이 된 완화책은 이렇습니다: "모르겠다"라고 답하는 것을 명시적으로 허용하고, 확신이 낮은 주장에 표시를 하도록 요청하고, 가능하다면 원본 자료를 붙여 넣으면서 그 자료만 사용하라고 지시하는 것입니다. 이런 방법은 환각을 줄여 주지만 완전히 없애지는 못하므로, 의존할 내용은 반드시 검증하세요.
출력은 결정적이지도 않습니다. 같은 프롬프트가 실행할 때마다 다른 답을 낼 수 있으므로, 어떤 프롬프트가 잘 작동하는지 혹은 실패하는지 결론 내리기 전에 최소 두 번은 테스트하세요.
반복 가능한 워크플로우
1단계. 작업을 한 문장으로만 쓰세요. 실행해서 모델의 기본 행동을 확인합니다.
2단계. 확인한 빈틈을 겨냥해 맥락, 형식, 제약을 추가합니다.
3단계. 다시 실행하고 "그럴듯한지"가 아니라 실제로 원했던 것과 비교합니다.
4단계. 남은 격차 중 가장 큰 것을 한 번에 하나씩 수정해서, 어떤 변경이 어떤 효과를 냈는지 배우세요.
5단계. 프롬프트가 잘 작동하면 자리 표시자를 넣은 템플릿으로 저장하세요. 검증된 프롬프트 라이브러리는 어떤 개별 요령보다 빠르게 복리로 쌓입니다.
프롬프트 설계는 경험적인 작업입니다. 여러분의 의도가 아니라 모델의 행동만이 유일하게 의미 있는 피드백입니다.