핵심 요약
좋은 프롬프트는 모델에게 "무엇을, 어떤 맥락에서, 어떤 순서로, 어떤 형식으로" 해야 하는지 명확히 알려주는 설계도입니다.
Claude 같은 언어 모델은 충분한 배경 정보, 단계별 지시, 예시, 출력 형식을 제공할수록 더 안정적이고 활용 가능한 답변을 만듭니다.
프롬프트 엔지니어링은 모델과 일하는 방식이다
프롬프트 엔지니어링은 단순히 질문을 잘 쓰는 기술이 아닙니다.
모델이 작업을 오해하지 않도록 역할, 목표, 배경, 판단 기준, 출력 형식을 정리해 전달하는 과정입니다.
예를 들어 자동차 사고 보고서를 분석시키려는데 맥락을 충분히 주지 않으면, 모델은 엉뚱하게 "스키 사고"처럼 해석할 수도 있습니다.
즉, 모델의 실수는 종종 모델이 똑똑하지 않아서가 아니라, 우리가 상황판을 제대로 깔아주지 않아서 발생합니다.
좋은 프롬프트의 기본 구조
실무용 프롬프트는 보통 한 번의 요청으로 정확한 결과를 얻어야 합니다.
그래서 대화하듯 주고받기보다, 처음부터 충분한 정보를 담은 하나의 요청을 설계하는 것이 중요합니다.
좋은 구조는 대체로 다음 흐름을 따릅니다.
먼저 작업 설명을 제시합니다. 모델이 어떤 역할로 무엇을 해야 하는지 알려줍니다.
그다음 분석할 콘텐츠를 제공합니다. 이미지, 문서, 사용자 입력, 검색 결과 등이 여기에 해당합니다.
이후 단계별 지시를 줍니다. 어떤 순서로 확인하고 판단해야 하는지 알려주는 부분입니다.
필요하다면 예시를 추가합니다. 특히 어려운 사례나 자주 틀리는 패턴은 예시로 넣는 것이 효과적입니다.
마지막으로 중요한 규칙과 출력 형식을 다시 강조합니다.
맥락이 없으면 모델은 추측한다
모델은 주어진 정보 안에서 가장 그럴듯한 답을 만들려고 합니다.
문제는 정보가 부족할 때도 답을 만들려 한다는 점입니다.
자동차 사고 보고서와 손그림 스케치를 주면서 "사고를 분석하라"고만 하면, 모델은 그림의 모양이나 단어 일부를 바탕으로 잘못된 추론을 할 수 있습니다.
따라서 "이것은 스웨덴어 자동차 보험 사고 보고서이며, 차량 A와 차량 B의 책임 여부를 판단해야 한다"처럼 작업의 배경을 명확히 해야 합니다.
좋은 프롬프트는 모델의 상상력을 줄이고, 관찰과 판단을 분리하게 만듭니다.
어조와 판단 기준도 지시해야 한다
모델에게 단순히 "분석해줘"라고 하면, 모델은 자신감 있게 보이기 위해 애매한 내용도 단정할 수 있습니다.
보험, 법률, 의료, 재무처럼 정확성이 중요한 영역에서는 이 태도가 위험합니다.
따라서 "확실하지 않으면 판단하지 말라", "보이는 정보에 근거해서만 말하라", "추측하지 말라" 같은 기준을 넣어야 합니다.
이런 지시는 모델의 말투뿐 아니라 판단 방식에도 영향을 줍니다.
좋은 프롬프트는 모델에게 답을 강요하지 않습니다. 대신 확실한 것과 불확실한 것을 구분하게 만듭니다.
고정 정보는 시스템 프롬프트에 넣는다
매번 변하지 않는 정보는 시스템 프롬프트에 넣는 것이 좋습니다.
예를 들어 사고 보고서 양식이 항상 동일하다면, 양식의 제목, 열 구조, 각 체크박스의 의미, 작성 방식 등을 미리 알려줄 수 있습니다.
그러면 모델은 매번 양식 자체를 해석하느라 시간을 쓰지 않고, 실제로 체크된 내용과 사고 정황을 분석하는 데 집중할 수 있습니다.
이런 고정 정보는 프롬프트 캐싱에도 적합합니다.
반대로 매번 바뀌는 정보, 예를 들어 실제 사고 보고서 이미지나 손그림 스케치는 사용자 프롬프트 쪽에 넣는 것이 자연스럽습니다.
구조화는 모델의 이해력을 높인다
Claude는 구조가 잘 잡힌 입력을 더 잘 처리합니다.
XML 태그나 마크다운 같은 구분자를 사용하면 정보의 종류를 명확히 나눌 수 있습니다.
예를 들어 <form_description>, <instructions>, <final_verdict>처럼 태그를 사용하면 모델이 각 정보의 역할을 더 쉽게 파악합니다.
이는 사람이 서류철에 라벨을 붙여 정리하는 것과 비슷합니다.
라벨 없이 종이를 쌓아두면 찾기 어렵지만, "규칙", "예시", "출력 형식"처럼 구분해두면 훨씬 안정적으로 작업할 수 있습니다.
예시는 모델을 훈련시키는 가장 실용적인 방법이다
어려운 판단이 필요한 작업에서는 예시가 큰 힘을 발휘합니다.
특히 모델이 자주 틀리는 상황, 회색지대에 있는 사례, 인간 전문가가 이미 정답을 알고 있는 사례를 넣으면 좋습니다.
예를 들어 자동차 사고 분석에서 애매한 교차로 사고, 불완전한 체크 표시, 엉성한 손그림 사례를 예시로 제공할 수 있습니다.
예시는 모델에게 "이런 상황에서는 이렇게 생각하고 이렇게 답하라"는 기준을 보여줍니다.
프롬프트 엔지니어링은 한 번에 완성하는 작업이 아니라, 실패 사례를 모아 다시 프롬프트에 반영하는 반복 작업입니다.
분석 순서를 지정하면 결과가 좋아진다
모델에게 무엇을 볼지만 알려주는 것보다, 어떤 순서로 볼지도 알려주는 것이 중요합니다.
자동차 사고 사례에서는 먼저 보고서 양식을 읽게 하고, 체크된 항목을 확인하게 한 뒤, 그 정보를 바탕으로 손그림 스케치를 해석하게 하는 것이 좋습니다.
사람도 마찬가지입니다. 아무 맥락 없이 손그림만 보면 의미를 파악하기 어렵지만, 보고서 내용을 먼저 알면 그림 속 차량 이동 방향을 더 잘 이해할 수 있습니다.
따라서 "먼저 양식을 검토하라", "그다음 스케치를 확인하라", "마지막으로 두 정보를 종합하라"처럼 단계별 사고 흐름을 제시해야 합니다.
복잡한 작업일수록 순서는 성능입니다.
출력 형식은 애플리케이션을 위한 약속이다
실무에서는 모델의 긴 설명보다, 시스템이 바로 저장하고 처리할 수 있는 결과가 더 중요할 때가 많습니다.
예를 들어 최종 책임 차량, 판단 근거, 신뢰도, 요약만 필요할 수 있습니다.
이때는 모델에게 최종 판단을 특정 XML 태그나 JSON 형식으로 감싸라고 지시할 수 있습니다.
예시는 다음과 같습니다.
<final_verdict>
Vehicle B is at fault.
</final_verdict>이렇게 하면 개발자는 해당 부분만 파싱해 데이터베이스에 저장하거나 다음 단계의 자동화에 사용할 수 있습니다.
좋은 출력 형식은 모델의 답변을 "읽을 수 있는 문장"에서 "처리 가능한 데이터"로 바꿉니다.
프리필과 확장 사고를 활용할 수 있다
모델의 답변 시작 부분을 미리 지정하는 방식도 있습니다.
이를 프리필 응답이라고 볼 수 있습니다.
예를 들어 JSON 출력을 원한다면 모델의 응답이 {로 시작하도록 유도할 수 있습니다.
이 방식은 불필요한 서론을 줄이고, 원하는 형식을 더 안정적으로 얻는 데 도움이 됩니다.
또한 Claude의 확장 사고 기능을 활용하면 모델이 문제를 어떻게 분석하는지 더 깊게 살펴볼 수 있습니다.
이 과정은 최종 프롬프트를 개선하는 데 유용합니다.
모델이 어떤 단계에서 헷갈리는지 확인하고, 그 부분을 시스템 프롬프트의 규칙이나 예시로 보강할 수 있기 때문입니다.
인사이트
좋은 프롬프트는 질문이 아니라 작업 매뉴얼에 가깝습니다.
역할, 맥락, 고정 정보, 단계별 절차, 판단 기준, 출력 형식을 모두 설계해야 모델이 안정적으로 일합니다.
실천 팁은 간단합니다.
처음에는 짧은 프롬프트로 시작하되, 모델이 틀린 이유를 관찰하세요.
그다음 부족한 맥락을 추가하고, 고정 정보는 시스템 프롬프트로 옮기고, 어려운 사례는 예시로 넣고, 마지막에는 출력 형식을 명확히 고정하세요.
프롬프트 엔지니어링의 핵심은 "한 번에 완벽하게 쓰기"가 아니라 "모델의 실패를 구조화된 지시로 바꾸기"입니다.
출처 및 참고 :
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.