AI 기초 및 활용 20회: 프롬프트 엔지니어링 — 요령이 아니라 원리로

오늘의 질문 — 왜 같은 도구인데 결과가 다를까요

같은 모델에 같은 주제를 물었는데, 어떤 사람은 쓸 만한 답을 받고 어떤 사람은 뻔한 답을 받습니다. 도구는 같은데 결과가 다릅니다.

이것을 두고 "프롬프트를 잘 쓰는 요령"이라 부르며 목록으로 유통되는 것들이 많습니다. 그런데 그 목록은 대개 왜 통하는지를 설명하지 않아요. 그래서 통하지 않는 상황에서 응용이 안 됩니다.

오늘은 다르게 갑니다. 18·19회차에서 모델이 어떤 장치이고 어떻게 길러졌는지를 배웠으니, 그 지식으로 왜 통하는지를 설명하면서 패턴을 정리하겠습니다.

오늘의 질문은 이것입니다. 좋은 지시란 무엇인가. 그리고 프롬프트로 고칠 수 있는 것과 없는 것은 무엇인가.

지난 회차 연결 — 원리가 곧 요령이 됩니다

18회차에서 배운 것을 세 줄로 줄이면 이렇습니다. 모델은 다음 토큰의 확률 분포를 내놓고, 거기서 확률적으로 하나를 뽑아, 그것을 뒤에 붙이고 전체를 다시 읽습니다.

19회차에서는 그 모델이 시범과 선호로 다듬여졌다는 것을 봤습니다. 그래서 아첨하고, 길게 쓰고, 지나치게 조심스러운 성향이 생겼죠.

오늘의 모든 패턴은 이 두 사실에서 나옵니다. 프롬프트란 결국 확률 분포를 원하는 쪽으로 좁히는 일이고, 훈련이 만든 성향을 상쇄하는 일입니다.

원칙 ① 모호함을 줄인다

첫 번째 원칙은 모호함을 줄이는 것입니다. 왜 그런지는 확률 분포로 설명됩니다.

"이거 좀 정리해 줘"라고만 하면, 모델 입장에서 그럴듯한 다음 조각의 후보가 아주 넓습니다. 요약일 수도, 목록일 수도, 재작성일 수도 있어요. 넓은 분포에서 뽑으니 여러분이 원한 것이 나올 확률이 낮습니다.

"이 회의록을 결정 사항과 남은 과제로 나눠 각각 세 줄로 정리해 줘"라고 하면 분포가 확 좁아집니다. 원하는 쪽에 확률이 몰려요.

그러니까 프롬프트를 구체적으로 쓰라는 조언은 예의나 취향의 문제가 아닙니다. 확률 분포를 좁히는 물리적 작업이에요.

원칙 ② 모델이 아는 것을 꺼내게 한다

두 번째 원칙은 19회차의 표면 정렬 가설에서 나옵니다. 능력은 이미 안에 있고, 문제는 그것을 꺼내는 신호라는 관점이었죠.

그렇다면 좋은 프롬프트란 모델에게 무언가를 가르치는 글이 아니라, 이미 가진 능력 중 어느 것을 꺼낼지 지목하는 신호입니다.

이 관점이 실무에서 유용합니다. 프롬프트에 지식을 설명하려 애쓸 필요가 없어요. 대신 어떤 상황이고 무엇을 원하는지를 정확히 알려주는 데 집중하면 됩니다.

단, 모델이 정말로 모르는 것은 꺼낼 수 없습니다. 사내 규정이나 최신 사건 같은 것이요. 그건 프롬프트에 직접 넣어 줘야 합니다. 이 구분이 중요합니다.

패턴 1 — 역할 지정

"당신은 10년 경력의 편집자입니다"처럼 역할을 주는 방식입니다. 가장 널리 알려진 패턴이죠.

통하는 이유는 명확합니다. 역할을 주면 그 역할에 어울리는 어휘와 관점 쪽으로 분포가 기웁니다. 편집자라는 말이 들어가면 문장 구조와 가독성에 관한 표현들의 확률이 올라가요.

다만 과대평가된 면도 있습니다. "세계 최고의 천재" 같은 수식은 별 효과가 없어요. 그런 말이 붙은 글이 특별히 정확하지도 않으니까요.

효과가 있는 것은 구체적이고 실재하는 역할입니다. "회계사"보다 "중소기업 세무를 주로 다루는 회계사"가 낫고, 그보다 "이런 상황의 이 문서를 검토하는 사람"이 더 낫습니다.

패턴 2 — 맥락 제공

역할보다 중요한 것이 맥락입니다. 실무에서 결과를 가장 크게 바꾸는 요소예요.

같은 "이 글 다듬어 줘"라도 누가 읽을 글인지, 어디에 실릴 글인지, 무엇을 이루려는 글인지를 알려주면 결과가 달라집니다.

맥락에 넣을 만한 것들은 이렇습니다. 독자(누가 읽나), 목적(무엇을 이루려나), 매체(어디에 실리나), 제약(길이·톤·피해야 할 것), 배경(모델이 모를 사정).

특히 배경이 중요합니다. 앞서 말했듯 모델이 모르는 것은 꺼낼 수 없어요. 사내 용어, 프로젝트 사정, 앞선 논의 같은 것은 넣지 않으면 존재하지 않는 것과 같습니다.

패턴 3 — 예시 보여주기

설명하기 어려운 것은 예시로 보여주는 편이 낫습니다. 특히 형식과 톤이 그렇습니다.

"간결하게 써 줘"는 사람마다 다른 뜻이지만, 여러분이 쓴 간결한 문장 두세 개를 보여주면 오해가 없습니다.

이것이 통하는 이유도 18회차로 설명됩니다. 예시가 앞에 있으면 그 형식이 이어질 확률이 크게 올라갑니다. 모델은 지금까지의 글에서 이어지는 조각을 고르니까요.

실무 요령 하나. 예시는 둘에서 셋이면 충분합니다. 더 넣으면 문맥만 잡아먹고 효과는 거의 늘지 않아요. 그리고 예시들 사이에 일관성이 없으면 오히려 혼란을 줍니다.

패턴 4 — 출력 형식 지정

결과를 그대로 어딘가에 넣어야 한다면 형식을 미리 정해 주세요.

"표로", "항목별로", "제목 없이 문단만", "JSON 형태로" 같은 지시입니다. 특히 프로그램이 받아 처리할 결과라면 필수예요.

여기에 19회차의 지식이 하나 붙습니다. 모델은 훈련 때문에 목록과 소제목을 남발하는 성향이 있죠. 그래서 줄글로 받고 싶으면 명시적으로 요구해야 합니다. "목록 쓰지 말고 문단으로"처럼요.

그리고 서두와 마무리를 빼라는 지시도 자주 필요합니다. "좋은 질문입니다" 같은 인사말도 훈련이 만든 습관이니까요.

패턴 5 — 단계적으로 생각하게 하기

복잡한 문제에서 가장 효과가 큰 패턴입니다. "단계별로 생각한 뒤 답하라"고 요구하는 것이죠.

단순한 산수나 논리 문제에서 이 한 줄이 정답률을 크게 올리는 것이 여러 연구에서 확인됐습니다. 그리고 왜 통하는지가 오늘 이야기의 핵심입니다.

18회차에서 이렇게 말했습니다. "모델의 계산량은 토큰 하나당 정해져 있다"고요. 그러니 어려운 문제에 곧장 답하게 하면 그 한 조각만큼만 계산합니다.

그런데 중간 과정을 글로 쓰게 하면, 그 글이 다시 다음 계산의 입력이 됩니다. 자기회귀니까요. 즉 생각할 자리를 물리적으로 늘려 주는 겁니다. 요령이 아니라 계산 자원의 문제예요.

왜 이게 통하는지 — 18회차로 설명됩니다

이 원리를 이해하면 응용이 생깁니다. 몇 가지만 짚어 볼게요.

요즘 추론 모델이라 불리는 것들은 이 원리를 훈련에 내장한 겁니다. 답하기 전에 스스로 오래 생각하도록 학습된 모델이에요. 그래서 그런 모델에는 "단계별로 생각하라"를 굳이 붙일 필요가 없습니다. 이미 하고 있으니까요.

반대로 간단한 질문에 이 패턴을 붙이면 낭비입니다. 출력이 길어지니 느려지고 비싸집니다.

그리고 중요한 주의 하나. 모델이 써 놓은 중간 과정이 실제 근거라는 보장은 없습니다. 결론을 먼저 정해 놓고 그럴듯한 과정을 지어낼 수 있어요. 과정이 있다고 믿을 만한 것은 아닙니다. 21회차에서 이 문제를 다룹니다.

패턴 6 — 제약과 금지 조건

원하는 것만큼 원하지 않는 것을 적는 것도 효과적입니다.

"600자 이내로", "전문용어를 쓰지 말고", "추측이면 추측이라고 표시하고", "확실하지 않으면 모른다고 하고" 같은 조건들이요.

특히 마지막 두 개가 중요합니다. 19회차에서 봤듯 모델은 모른다고 말하는 훈련이 약합니다. 웹에 "모르겠습니다"라는 글이 드무니까요. 그래서 명시적으로 허락해 주면 실제로 모른다고 말하는 빈도가 올라갑니다.

"확실하지 않은 부분은 그렇다고 표시해 줘"는 가장 값어치 있는 한 줄 중 하나입니다. 21회차 환각 대응의 첫 번째 방어선이에요.

패턴 7 — 부정문 대신 긍정문

다만 금지 조건에는 함정이 있습니다. 하지 말라고 적은 것 자체가 그 개념을 불러온다는 점이에요.

17회차에서 이미지 생성의 실측 사례를 이야기했죠. "주황색 넣지 마"라고 쓰면 오히려 주황색이 나온다는 것이요. 텍스트에서도 같은 일이 약하게나마 일어납니다.

그래서 요령은 이렇습니다. 막고 싶은 것을 말하는 대신 원하는 것을 말하세요.

"딱딱하게 쓰지 마"보다 "친구에게 설명하듯 편하게 써"가 낫습니다. "장황하게 쓰지 마"보다 "세 문장으로"가 낫고요. 금지는 방향을 주지 않지만 지시는 방향을 줍니다.

패턴 8 — 자기 검토 요구

답을 받은 뒤 "방금 답에서 틀렸을 만한 곳을 찾아 봐"라고 이어 묻는 방식입니다. 의외로 효과가 좋습니다.

이유는 두 가지입니다. 첫째, 만드는 일과 검토하는 일은 다른 과제입니다. 검토 요청을 받으면 모델은 비판적 관점의 분포에서 조각을 고르게 돼요.

둘째, 18회차에서 본 자기회귀의 성질 때문입니다. 한 번 쓴 것은 되돌릴 수 없다고 했죠. 그런데 새 요청으로 다시 시작하면 그 답 전체를 입력으로 놓고 새로 판단할 수 있습니다.

더 강한 방법도 있습니다. 같은 질문을 새 대화에서 다시 물어 답을 비교하는 것이요. 두 답이 다르면 그 지점이 모델이 확신 없는 자리입니다. 아주 유용한 신호예요.

패턴 9 — 반대 근거 요구, 아첨을 끄는 법

19회차에서 다룬 아첨의 실전 대응입니다. 세 가지가 있어요.

첫째, 내 입장을 먼저 밝히지 마세요. "내 생각엔 A인데 맞지?"라고 물으면 동의 쪽으로 기웁니다. "A와 B 중 무엇이 맞고 근거는 무엇인가"라고 물으세요.

둘째, 반대 근거를 명시적으로 요구하세요. "이 주장에 반대하는 가장 강한 논거를 세 가지 대 봐"처럼요. 요구하지 않으면 잘 나오지 않습니다.

셋째, 물러섰을 때 다시 확인하세요. "아닌 것 같은데"라고 했더니 모델이 말을 바꿨다면, "방금 왜 바꿨나. 원래 답이 틀렸던 근거를 대 봐"라고 물으세요. 근거가 없다면 아첨이었던 겁니다.

패턴 10 — 한 번에 말고 나눠서

큰 요청을 여러 번으로 쪼개는 것이 대체로 낫습니다.

"이 자료로 보고서를 써 줘"보다 목차를 먼저 잡고, 각 절을 따로 쓰고, 마지막에 다듬는 편이 훨씬 좋은 결과를 냅니다.

이유는 셋입니다. 각 단계의 요구가 명확해지고, 중간에 방향을 고칠 수 있고, 각 단계의 결과가 다음 단계의 맥락으로 쌓입니다.

그리고 이것이 프롬프트 개선의 기본 자세이기도 합니다. 한 번에 완벽한 프롬프트를 쓰려 하지 마세요. 짧게 던지고, 결과를 보고, 어긋난 부분만 고쳐 다시 던지는 편이 빠릅니다.

프롬프트를 자산으로 만들기

잘 통한 프롬프트는 그때 쓰고 버리기에 아깝습니다. 같은 종류의 일이 반복된다면 더욱요.

실용적인 방법은 고정 부분과 변하는 부분을 나누는 것입니다. 역할·맥락·형식·제약은 대체로 고정이고, 실제 대상만 바뀌죠. 고정 부분을 틀로 저장해 두고 대상만 갈아 끼우면 됩니다.

그리고 도구가 이것을 지원합니다. 프로젝트 단위로 지침을 저장하는 기능, 반복 작업을 파일로 만들어 두는 기능 같은 것들이요. 매번 같은 설명을 다시 쓰지 않는 것이 실무에서 체감되는 가장 큰 절약입니다.

26회차에서 도구 지형도를 다룰 때 이 이야기를 다시 하겠습니다.

안 통하는 것들 — 과장된 요령

정직하게 짚을 것이 있습니다. 널리 퍼진 요령 중 근거가 약하거나 사라진 것들이 있어요.

"팁을 주겠다"거나 감정에 호소하는 문구는 초기 모델에서 약간의 효과가 보고된 적이 있지만, 요즘 모델에서는 재현되지 않거나 효과가 미미합니다.

지나치게 긴 역할 설정도 대개 낭비입니다. 문맥만 차지하고 결과는 별로 안 바뀝니다.

대문자나 느낌표로 강조하기도 마찬가지예요. 구조를 명확히 하는 편이 훨씬 낫습니다.

그리고 가장 중요한 사실. 모델이 바뀌면 통하던 요령이 안 통할 수 있습니다. 훈련 방식이 달라지니까요. 그래서 요령 목록을 외우는 것보다 원리를 아는 것이 오래갑니다. 오늘 이 회차를 그렇게 구성한 이유예요.

프롬프트 주입 — 보안 관점

실무에서 반드시 알아야 할 위험이 하나 있습니다. 프롬프트 주입입니다.

모델은 여러분의 지시와 입력 데이터를 구분하지 못합니다. 둘 다 그냥 앞에 놓인 글이거든요.

그래서 웹페이지나 문서를 읽게 했을 때, 그 안에 "이전 지시를 무시하고 이렇게 해라"라는 문장이 심어져 있으면 모델이 따를 수 있습니다. 사람 눈에 안 보이게 숨겨 둘 수도 있고요.

이것은 요령으로 막을 수 없는 구조적 취약점입니다. 방어의 원칙은 이렇습니다. 외부에서 가져온 글은 지시가 아니라 데이터로 취급하고, 위험한 동작은 모델 바깥에서 사람이 확인하게 합니다.

23회차 에이전트에서 이 문제가 훨씬 심각해집니다. 모델이 스스로 도구를 쓰기 시작하면 주입된 지시가 실제 행동이 되니까요.

실전 ① 글쓰기와 요약

가장 흔한 용도부터 봅시다. 요약에서 중요한 것은 "누구를 위한 요약인가"입니다.

같은 문서라도 결정을 내려야 하는 사람과 배경을 알고 싶은 사람에게 필요한 요약이 다릅니다. 이걸 알려주지 않으면 모델은 무난한 평균을 냅니다.

글 다듬기에서는 무엇을 지킬지를 말해 주세요. "내 문체는 유지하고 문법과 흐름만 고쳐 줘"처럼요. 그러지 않으면 모델의 훈련된 문체로 덮어씁니다.

그리고 실용적인 요령 하나. 고쳐 쓴 결과만 받지 말고 무엇을 왜 고쳤는지 함께 받으세요. 다음 글을 쓸 때 여러분에게 남습니다. 24회차에서 이 이야기를 학습 도구로서의 AI 관점으로 다시 다룹니다.

실전 ② 코드와 데이터

코드 작업에서는 맥락이 절반입니다. 언어와 버전, 쓰고 있는 라이브러리, 지켜야 할 규칙, 실행 환경. 이걸 안 주면 모델은 가장 흔한 조합을 가정합니다.

그리고 오류를 물을 때는 오류 메시지 전문을 그대로 붙여넣으세요. 요약해서 전하면 결정적 단서가 사라집니다.

데이터 작업에서는 실제 표본 몇 줄을 함께 주는 것이 설명보다 훨씬 효과적입니다. 컬럼 이름과 실제 값의 형태를 보면 모델이 훨씬 정확해져요.

중요한 주의. 민감한 데이터는 넣지 마세요. 개인정보, 계약 내용, 인증 정보 같은 것이요. 27회차에서 이 기준을 자세히 다룹니다.

실전 ③ 저시력 사용자를 위한 프롬프트

이 시리즈의 관점에서 실질적으로 유용한 이야기를 하겠습니다. 출력 형식을 지정하는 것이 접근성에 직접 도움이 됩니다.

화면 낭독기로 듣는 사람에게 표는 대체로 최악의 형식입니다. 셀을 하나씩 읽으며 어느 행 어느 열인지 계속 따라가야 하거든요. 그래서 "표 대신 줄글로"라는 한 줄이 큰 차이를 만듭니다.

중첩된 목록도 마찬가지입니다. "목록 깊이는 한 단계까지만"이라고 요구하면 훨씬 듣기 좋아집니다.

확대해서 보는 저시력 사용자에게는 긴 문단이 부담입니다. "한 문단은 세 문장 이내로"가 도움이 됩니다.

그리고 이 지시들을 매번 쓰지 말고 고정 지침으로 저장해 두세요. 앞서 말한 프롬프트 자산화가 접근성에서 특히 값어치 있는 이유입니다. 매번 자기 필요를 설명해야 하는 것 자체가 비용이니까요.

무엇을 프롬프트로 못 고치나

마지막으로 한계를 정직하게 정리하겠습니다. 프롬프트는 만능이 아니에요.

모르는 사실은 만들어 낼 수 없습니다. 지식 마감 이후의 사건, 사내 자료, 비공개 정보. 이건 프롬프트에 넣어 주거나 검색을 붙여야 합니다.

계산 능력은 크게 안 올라갑니다. 18회차에서 봤듯 계산기가 아니니까요. 정확한 계산이 필요하면 계산 도구를 쓰게 해야 합니다.

환각을 없앨 수 없습니다. 줄일 수는 있어도 없애지는 못해요. 구조에서 나오는 성질이니까요.

훈련된 성향을 완전히 뒤집을 수 없습니다. 아첨이나 과도한 신중함을 프롬프트로 줄일 수는 있지만 근본적으로 없애지는 못합니다.

그래서 원칙은 이렇습니다. 프롬프트로 고칠 수 있는 것은 프롬프트로, 나머지는 구조로 해결하세요. 검색을 붙이고, 도구를 붙이고, 검증 절차를 두는 겁니다. 21·23회차의 주제입니다.

핵심 정리 — 세 줄

첫째, 프롬프트는 확률 분포를 좁히는 작업입니다. 모호한 요청은 후보가 넓어 원하는 것이 나올 확률이 낮고, 구체적인 요청은 분포를 좁혀 확률을 몰아 줍니다. 역할·맥락·예시·형식·제약은 모두 이 좁히기의 다른 이름이며, 맥락이 그중 가장 크게 결과를 바꿉니다.

둘째, 단계적으로 생각하게 하기가 통하는 것은 요령이 아니라 계산 자원의 문제입니다. 토큰 하나당 계산량이 정해져 있으므로, 중간 과정을 글로 쓰게 하면 그 글이 다시 입력이 되어 생각할 자리가 물리적으로 늘어납니다. 다만 써 놓은 과정이 실제 근거라는 보장은 없습니다.

셋째, 프롬프트로 고칠 수 있는 것과 없는 것을 구분해야 합니다. 모르는 사실, 정확한 계산, 환각, 훈련된 성향은 프롬프트로 없앨 수 없고 구조로 풀어야 합니다. 그리고 요령 목록은 모델이 바뀌면 무너지지만 원리는 남습니다.

용어 정리

프롬프트 — 모델에게 주는 입력 글 전체. 지시와 맥락과 데이터가 모두 포함됩니다.

역할 지정 — 모델에게 특정 역할을 부여해 그에 어울리는 어휘와 관점 쪽으로 분포를 기울이는 방식.

예시 제공 — 원하는 형식이나 톤을 설명 대신 몇 개의 실례로 보여주는 방식. 둘에서 셋이면 충분합니다.

단계적 사고 유도 — 중간 과정을 글로 쓰게 해 실질적인 계산량을 늘리는 방식.

추론 모델 — 답하기 전 스스로 오래 생각하도록 훈련된 모델. 단계적 사고 유도를 내장한 셈입니다.

자기 검토 — 낸 답을 다시 입력으로 놓고 오류를 찾게 하는 방식.

프롬프트 주입 — 입력 데이터 안에 지시문을 심어 모델의 원래 지시를 덮어쓰려는 공격. 모델이 지시와 데이터를 구분하지 못하는 데서 나옵니다.

프롬프트 자산화 — 고정 부분과 변하는 부분을 나눠 틀로 저장하고 재사용하는 것.

다음 회차 예고 — 그리고 생각해볼 질문

21회차는 「환각과 한계」입니다. 오늘 마지막에 프롬프트로 없앨 수 없는 것을 이야기했죠. 그중 가장 중요한 것을 정면으로 다룹니다.

다음 회차의 출발점은 이겁니다. 환각은 고장이 아니라 구조에서 나오는 성질입니다. 모델의 목표는 참을 말하는 것이 아니라 그럴듯한 다음 조각을 고르는 것이니까요. 왜 존재하지 않는 논문과 판례를 그렇게 자신 있게 만들어 내는지, 왜 모른다고 말하지 못하는지, 그리고 검색을 붙이는 방식이 무엇을 해결하고 무엇을 해결하지 못하는지를 봅니다.

그리고 가장 실용적인 부분. 언제 믿고 언제 확인해야 하는가에 대한 기준을 세우겠습니다.

생각해볼 질문. 오늘 좋은 프롬프트란 맥락을 충분히 주는 것이라고 했습니다. 독자, 목적, 제약, 배경을 말해 주는 것이요.

그런데 이건 사람에게 일을 부탁할 때와 똑같지 않나요? 좋은 요청과 나쁜 요청의 차이는 사람 사이에서도 정확히 그 지점에서 갈립니다. 여러분이 받아 본 가장 좋았던 요청과 가장 막막했던 요청은 무엇이 달랐나요? 그 차이를 AI에게 그대로 적용해 보면 어떨지 댓글로 들려주세요.

이 포스트는 SVIL 연구소 「AI 기초 및 활용」 30회 시리즈의 20회차이며, 제4부 「생성형 AI와 LLM 시대」의 세 번째 회입니다. 하버드 CS50 AI, MIT 6.S191 등 공개 교육과정의 구조를 참고했으며, 모든 내용은 이미지 없이 본문만으로 이해할 수 있도록 구성되어 있습니다. 모든 이미지에는 내용을 설명하는 대체텍스트가 포함되어 있습니다.

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/