01. 프롬프트 엔지니어링이란 무엇인가

새 동료에게 일을 맡긴다고 생각해보자

아주 똑똑하지만 당신의 회사·프로젝트에 대해 아무것도 모르는 신입이 첫 출근을 했다고 상상해봅시다. 능력은 뛰어나지만, 당신의 머릿속에 있는 맥락은 하나도 공유돼 있지 않습니다. 이 사람에게 "보고서 좀 써줘"라고만 하면 결과가 들쭉날쭉할 수밖에 없습니다. 무엇에 관한 보고서인지, 누가 읽는지, 얼마나 길어야 하는지, 어떤 형식인지를 말해주지 않았으니까요.

프롬프트 엔지니어링은 바로 이 "지시를 명확히 하는 일"입니다. 똑똑한 협력자에게 원하는 결과를 일관되게 얻어내기 위해, 무엇을·왜·어떻게 원하는지를 분명하게 전달하는 기술입니다. 여러 제공자의 공식 가이드가 약속이라도 한 듯 같은 비유를 쓰는데, 핵심은 한결같습니다: 명료하게, 구체적으로, 의도를 담아 전달하라.

정의

프롬프트 엔지니어링이란, 언어 모델이 원하는 출력을 일관되게 내도록 입력(프롬프트)을 설계하고 다듬는 과정입니다. 여기서 두 단어가 중요합니다.

• 일관되게: 한 번 운 좋게 좋은 답을 얻는 것이 아니라, 같은 종류의 작업에서 반복적으로 좋은 결과를 얻는 것이 목표입니다.
• 다듬는: 한 방에 완벽한 프롬프트를 쓰는 것이 아니라, 써보고 → 결과를 보고 → 고치는 반복(iteration)이 본질입니다. 세 제공자의 가이드가 공통으로 강조하는 점입니다.

📌 핵심: 프롬프트 엔지니어링은 "마법 단어를 외우는 것"이 아니라 "명확한 사고를 모델이 따라올 수 있게 글로 옮기는 것"입니다.

무엇이 아닌가 — "마법 주문" 통념

이 분야에서 가장 흔하고 가장 해로운 오해는, 어떤 비밀스러운 문구를 넣으면 모델이 마법처럼 잘한다는 믿음입니다. 예를 들어 이런 것들이 인터넷에 떠돕니다.

• "잘하면 200달러 팁을 주겠다"고 하면 더 열심히 한다
• "내 커리어가 이것에 달려 있다"고 협박(?)하면 품질이 올라간다
• 특정 마법 문구를 맨 앞에 붙이면 검열을 우회한다

⚠️ 흔한 실수·미신: 이런 "주문"류 조언의 문제는 두 가지입니다. 첫째, 효과가 있었다 해도 특정 모델·특정 버전에서 우연히 관찰된 것일 때가 많아 일반 진리가 아닙니다. 둘째, 모델이 바뀌면 무력화되거나 오히려 역효과가 납니다. 모델 제공자들도 이 점을 명시적으로 경고합니다. 한 가이드의 표현을 빌리면, 모델을 트릭으로 강제하려는 "프롬프트 엔지니어링 민담(folklore)"은 모델이 진화하면 통하지 않게 되므로, 정공법인 원칙 기반 기법을 쓰는 편이 낫습니다.

가장 선명한 반례 하나를 미리 들어두겠습니다. 한때 거의 모든 곳에서 권장되던 "단계별로 생각해(think step by step)"라는 문구는, 추론이 내장된 최신 모델에서는 불필요하거나 오히려 성능을 떨어뜨릴 수 있습니다. (자세한 내용은 2부 단계적 사고 장에서 다룹니다.) 어제의 정답이 오늘의 오답이 되는 분야라는 뜻입니다.

🧪 직접 검증법: "이렇게 하면 더 잘한다"는 조언을 들으면, 그 문구가 있는 프롬프트와 없는 프롬프트를 같은 작업에 각각 5~10번씩 돌려 결과를 비교해보세요. 차이가 없거나 미미하다면, 그것은 당신의 모델에서는 "주문"이 아니라 그저 토큰 낭비입니다.

그럼 왜 어떤 표현은 실제로 효과가 있을까

오해를 풀었으니 균형을 맞춰봅시다. 표현을 바꿨더니 결과가 정말 나아지는 경우도 분명히 있습니다. 다만 그것이 "마법"이어서가 아니라, 모델에게 실제로 더 많은/더 나은 정보를 주었기 때문입니다.

예를 들어 "전문 변호사의 입장에서 이 계약서의 위험을 검토하라"가 효과가 있는 이유는 주문이어서가 아니라, 모델에게 어떤 관점·어휘·깊이로 답해야 하는지에 대한 구체적 신호를 주기 때문입니다. 같은 원리로, "초등학생도 이해하게 설명하라"가 통하는 것은 청자와 난이도라는 진짜 정보를 추가했기 때문입니다.

[효과 없는 "주문"]            [효과 있는 "정보 추가"]
"완벽하게 답해줘"      vs     "각 항목을 한 문장으로, 근거와 함께"
"진짜 잘해야 해"       vs     "독자는 비전문가야. 전문용어는 풀어 써"

왼쪽은 모델에게 아무런 추가 정보를 주지 않는 빈 강조입니다. 오른쪽은 출력의 형식·청자·기준이라는 구체적 신호를 줍니다. 효과의 차이는 "간절함"이 아니라 "정보량"에서 옵니다.

이것이 이 안내서를 관통하는 한 문장입니다: 효과는 간절함이 아니라 정보에서 온다.

기법·상황·트레이드오프 미리보기

앞으로 배울 기법들을 큰 그림에서 미리 봅니다. (각각은 이후 장에서 자세히 다룹니다.)

⚠️ 흔한 실수·미신: 위 표의 "언제 도움이 되나"를 읽고 "그럼 다 쓰면 되겠네"라고 생각하기 쉽습니다. 하지만 모든 기법을 한꺼번에 쌓아 올리면 프롬프트가 비대해지고, 서로 충돌하며, 정작 중요한 지시가 묻힙니다. 좋은 프롬프트 엔지니어는 기법을 더하는 만큼 덜어내는 데도 능합니다.

이 기술은 누구에게 필요한가

흔히 개발자의 일로 여겨지지만, 실은 LLM으로 결과물을 만드는 누구에게나 해당합니다.

• 기획자·마케터: 일관된 톤의 카피·기획안 초안
• 작가·편집자: 아이디어 확장, 문체 교정, 구조 잡기
• 분석가·연구자: 자료 요약, 데이터 해석 보조, 초안 검토
• 개발자: 위 모든 것에 더해 API·자동화·평가까지

🔧 개발자 노트: 최근 업계에서는 "프롬프트 엔지니어"라는 직함은 사실상 사라지고, 대신 모든 직군의 기본 소양으로 흡수되는 흐름이 관찰됩니다. 동시에 프로덕션 레벨에서는 단순 프롬프트 작성을 넘어 "컨텍스트 엔지니어링"(3부)이라는 더 본격적인 엔지니어링 과제로 무게중심이 옮겨가고 있습니다. 즉, 캐주얼한 프롬프팅은 누구나 하는 일이 되었고, 시스템 차원의 컨텍스트 설계가 전문 기술로 남았습니다.

이 장에서 배운 것

• 프롬프트 엔지니어링은 모델에게서 원하는 결과를 일관되게 얻기 위해 입력을 설계·반복 개선하는 기술이다.
• "마법 주문"은 대개 특정 모델에서 우연히 관찰된 것이거나, 모델 진화로 무력화·역효과가 나는 통념이다.
• 표현 변경이 효과를 내는 진짜 이유는 "간절함"이 아니라 모델에게 더 나은 정보(관점·청자·형식·기준)를 주기 때문이다.
• 모든 기법을 쌓는 것이 아니라, 상황에 맞게 더하고 덜어내는 판단이 핵심이다.
• 이 기술은 개발자만의 것이 아니라 LLM을 쓰는 모든 직군에 유용하다.

✍️ 확인 문제

1. "이 코드를 완벽하게 리뷰해줘. 진짜 중요한 일이야."라는 프롬프트가 왜 기대만큼 효과가 없을지, 이 장의 "정보 vs 간절함" 관점에서 설명해보세요.

1. 다음 중 "마법 주문" 통념에 해당하는 것을 모두 고르고, 그렇게 판단한 이유를 적어보세요.
   • (a) "팁을 줄 테니 잘해줘"
   • (b) "독자는 신입 개발자야. 전문 용어는 한 줄로 풀어 써줘"
   • (c) "이 문구를 맨 앞에 넣으면 항상 더 똑똑해진대"
   • (d) "출력은 표로, 각 행은 항목명과 위험도(상/중/하)로"

1. (실습) 아래 프롬프트를 "간절함"을 빼고 "정보"를 더하는 방향으로 개선해보세요. 무엇을·왜 바꿨는지 한두 문장으로 설명도 함께 적어보세요.

> "우리 신제품 출시 이메일 정말 잘 써줘. 엄청 중요해!!"

다음 → 02. LLM이 텍스트를 다루는 방식