프롬프트 엔지니어 이야기

EBS 특집 강연 멋진 신세계 AI : 질문하는 인간이 진화한다 2025년 EBS 특집 강연 멋진 신세계 AI의 2부 두 번째 강연 파트를 맡았습니다. "프롬프트, 질문의 기술"이 주제입니다. 올해는 작년보다 AI 활용이 더욱 커지며, 협업 도구로 자리 잡을 전망입니다. 이때, 명확한 의사 소통과 목적 설정이 필수입니다. 질문(=프롬프트)을 어떻게 하느냐에 따라 출력물의 질을 좌우하게 됩니다. 다니엘 카너먼의 책 <Thinking, Fast, and Slow> 중에서 '빠른 사고'와 '느린 사고'의 특징을 잘 보여주는 한 구절입니다. ✏️ 인간의 사고는 빠르고 직관적인 시스템 1과, 느리고 논리적인 시스템 2로 이루어져 있다. 우리는 대부분의 일상에서 시스템 1을 따라 직관적으로 판단하지만, 복잡하고 중요한 문제일수록 시스템 2가 주도적으로 사고해야 제대로 된 결정을 내릴 수 있다. ✅ LLM의 '빠른 사고'와 '느린 사고' LLM은 빠른 사고에 탁월합니다. 풍부한 데이터를 토대로 직관적이고 신속하게 답변을 생성합니다. 하지만, 복잡한 맥락을 다루거나 추론이 필요한 도메인에서는 느린 사고를 의도적으로 요구하면 답변의 품질이 크게 달라집니다. ✅ AI에게 '느린 사고' 유도하기 단계별 사고 (Chain-of-thought) 가장 친숙한 방법이 생각의 사슬기법입니다. 문제를 해결하기 위해 단계별로 언어 모델에게 사고하게 하는 것이죠. 결과만 요청하지 않고 '왜'와 '어떻게'를 적재 적소에 요구하는 방법도 있습니다. 이전 글에서는 인간의 사고 과정을 반영한 여러 프롬프팅 방법도 소개드렸는데요. 그것들이 느린 사고에 해당합니다.

생성형 AI 와 LLMs 그리고 인간의 언어 언어 훼손을 최소화하는 프롬프트 엔지니어링 "정확"과 "적확"은 다릅니다. 둘다 맞음을 의미하지만 사용되는 맥락과 뉘앙스 차이가 있습니다. 프롬프트로 작업을 한창하는데 LLM은 정확과 적확을 정확으로 치환합니다. 그러느라 애를 먹는 일이 많습니다. LLMs와 대화 혹은 작업하다보면 생성형 AI만의 표현과 어휘에 무뎌지게 됩니다. AI가 만들어내는 표현들이 생경하다보다 단어가 가진 의미가 훼손 됐다는 느낌이죠. 사람의 언어미묘한 '여운'을 느낄 수 있지만, AI의 단어에는 감각이 빠져있다 생각합니다. 전통적으로 언어는 인간이 긴 시간 동안 축적해 온 문화적, 사회적 맥락을 바탕으로 자연스럽게 발전해 왔습니다. 그런데 AI가 방대한 텍스트를 빠른 속도로 학습하고 생성하다 보니, 맥락을 제대로 반영하지 못하거나(‘기계 학습적 도출’), 아예 전에 없던 새로운 단어가 갑작스레 생겨나는 식의 변형이 일어나고 있습니다. 물론 언어는 언제나 변화해 왔습니다. 다만 오늘날 생성형 AI가 만들어내는 단어나 표현들은 인간의 사고방식에 직접 영향을 주고, 더 나아가 언어의 의미 영역에 새로운 “변형”을 일으킬 수 있다는 점이 중요합니다. 특히 다음 세 가지 측면에서 주의가 필요합니다. ✔️언어 구조와 의미 변화 ✔️언어 감각 상실 ✔️언어 다양성 감소 저만 해도 AI가 생성한 표현들을 ‘검증 없이’ 그대로 받아들이게 됩니다. 긴 문장을 쓰거나 의견을 정리할 때 ChatGPT나 클로드를 사용하는 것이 익숙해지다 보니, 오히려 인간이 새로운 표현을 직접 만들고 창의성을 발휘하는 능력이 줄어들지 않을까 하는 우려도 생깁니다. 결국 이러한 시대일수록, AI를 사용하는 우리 스스로가 능동적으로 언어와 문화적 다양성을 지켜나가는 노력이 중요해집니다. 이에 따라 프롬프트와 프롬프트 엔지니어링으로 보완하기 위한 연구와 시도가 활발히 이루어지고 있습니다. 대표적인 연구 논문은 "프롬프트 프로그래밍을"을 제안한 "Prompt Programming for Large Language Models: Beyond the Few-shot Paradigm"과 출력 언어 품질을 개선하는 방법을 제안한 "The Art of Prompting: Techniques and Applications of Prompt Engineering" 입니다.

Thinking LLMs: 모델을 생각하게 하는 프롬프팅 생성형 AI를 개선하기 위한 새로운 접근법을 찾으려는 시도는 추론 모델에 대한 관심을 불러일으켰습니다. 기존의 Brute Force, 모델을 단순히 크게 확장하는 전략은 이전처럼 효과를 발휘하지 못합니다. 언어 모델이 잘하지 못하는 것은 답하기 전에 생각하는 능력입니다. 이러한 한계를 극복하기 위해 모델을 사고하게 하는 프롬프팅 & 프롬프트 엔지니어링도 활발히 연구가 이루어지고 있습니다. 사람처럼 사고하게 하면 언어모델이 단순 지시문을 따르는 수준을 넘어, 더 유연하고 정확한 추록을 하게 됩니다. 사람이 문제를 풀 때 단계를 나누고 논리를 세우는 것처럼, 언어 모델 역시 이런 방식을 적용하면, 더 나은 결과를 얻을 수 있는 거죠. 최근에 발표된 o3 모델은 응답시간도 조절할 수 있다고 하죠. 최종 답변을 하기 전에 "생각"을 생성하게 하면 추론 성능이 좋아지기 때문입니다. 사고와 관련된 프롬프팅/엔지니어링 논문을 '모델의 사고'라는 테마로 엮었습니다. 함께 읽어보시면 좋을듯하여 논문의 레퍼런스도 첨부합니다. 요약하면 다음과 같습니다. ✅ 모델의 사고를 위한 프롬프팅 방법 Chain of Thought(CoT) : 논리적인 연결을 따라 생각하기. Zero-shot CoT: 단계를 나누지 않고 한 번에 답을 구하는 방식. Contrastive CoT: 대조를 통해 상황을 비교하며 분석. Analogical Prompting : 유사한 사례를 바탕으로 답을 도출. Step-Back Prompting: 한 발 물러서서 다시 문제를 바라보기. Thread of Thought: 필요한 정보만 선별해서 요약해서 생각하기. 생성형 AI 의 발전은 인간의 사고방식과 닮아가는 과정일지도 모릅니다.

Openai o1 과 프롬프트 Openai o1 은, AI Mathematics Evaluation(AIME) 수학적 문제 해결 능력 평가나, GPQA(General Purpose Question Answering) 다양한 종류의 질문에 대해서 얼마나 잘 대답하는지의 평가 지표에서 결과가 특히 뛰어납니다. 하지만, 결과가 뛰어나다고 해서, 반드시 end user 가 체감할 수 있는 무언가로 이어지진 않습니다. 반드시, 모델의 실용적인 접목 측면에서도 바로 적용가능한 것으로 이어지진 않습니다. 프롬프트를 꾸준히 들여다보고 써오고 있지만 LLM이 빠르게 발전할 때마다, 더욱 어려움을 느낍니다. 프롬프트 엔지니어의 일이란, 각 모델이 어떤 프롬프롬트의 응답을 잘 수행하고, 잘 못하는지를 판단하는 일입니다. GPT-4o는 실패했지만, o1에서만 잘 작동하는 프롬프트를 발견하는 것은 쉽지 않은 일입니다. GPT 3.5-turbo와 GPT-4의 사용에서 확연한 유의미한 차이를 느끼는 것처럼요. o1 이 현실 적용 가능한 과제를 해결하게 하기 위해서는, 더 어렵고 더 마법같은 프롬프트를 찾아야합니다. 또 다른 o1의 능력은 추론(Reasoning)입니다. AI 모델이 인간의 언어를 사용하여 사고 과정을 "나열"하는 것을 보고 있자니 놀랍습니다. 복잡한 문제를 몇 단계로 나누어서, 실수가 있으면 실수를 인식하고 수정하고, 다양한 접근 방식을 시도합니다. 사람의 사고 과정과 유사한데요. 그렇다면, 프롬프트 역시 역으로 인지과정을 거꾸로 밟아가며 세밀하고 정교하게 제작해야 할 필요가 있을 것 같습니다. 현재의 프롬프트 "과업"은 또 다른 "과업"이 되겠습니다. Evals https://openai.com/index/openai-o1-mini-advancing-cost-efficient-reasoning/ #Oepnaio1 #prompt #promptengineering

프롬프트 엔지니어링의 종말과 o1의 역학 프롬프트 엔지니어링 분야에 종사한다면 "프롬프트 엔지니어는 사라질 직업이다." "프롬프트 엔지니어링은 LLM이 대신 해줄거라 필요 없어질거다" 라는 말을 종종 듣죠. 지난 몇 년 동안 LLM의 성능을 극대화하기 위해 프롬프트를 미세 조정하고, 생성형 AI 서비스를 만들기 위해 프롬프트의 중요성이 강조되었습니다. 프롬프트 엔지니어링은 여러 언어 모델의 복잡성을 유용향 형태로 쉽게 다룰 수 있게 해주니까요. 하지만 o1 이 프롬프트 엔지니어링의 역학을 바꿨습니다. o1 만큼은 정교한 프롬프트 설계가 필요하지 않습니다. OpenAI의 o1 프롬프트 가이드를 보면 다음과 같습니다. ☑ 팁 1. 프롬프트를 간결하고 명확하게 사용할 것 ☑ 팁 2. 언어모델에게 자체적인 판단을 내릴 수 있는 여유를 줄 것 ☑ 팁 3. Chain-of-thought prompts 를 피할 것, think step-by-step 이나 explain your reasoning 불필요. 정교한 프롬프트가 오히려 모델의 추론 성능을 저해한다니, 기존의 프롬프트 엔지니어링을 보기 좋게 뒤집었습니다. GPT-4 같은 모델은 섬세하게 작업할 수록 결과물을 고도화 할 수 있었는데요. o1 은 테스트해보니, 밀도높은 프롬프트를 거부하는 반응을 보입니다. 그렇다고 해서, '프롬프트 엔지니어'는 사라질, '프롬프트 엔지니어링은 필요없는' 을 의미하는 것은 아닙니다. 단지 역할이 바뀐 것 뿐입니다. o1 시대 (편의상) 에는 프롬프트 엔지니어들인 고밀도의, 광범위한 세부사항에 중점을 둔 프롬프트를 제작하는 대신, 여러 산업의 문제를 "우아하게", "구조화"하여 푸는데 집중할 것 같습니다. o1의 메커니즘에도 여전히 중요한 것은 "우아한 프롬프트"와 "프롬프트 구조화" 입니다. 프롬프트 엔지니어링 수업에서 여러 방법들을 소개했는데요. 앞으로 o1 모델을 활용하는 더 우아한, 더 구조화를 위한 delimeters 소개가 이어질 것 같습니다. 그래서, AI가 추론 능력을 발휘 할 수 있는 공간과 최적화된 프롬프트의 환경을 디자인해야 하지 않을까 해요. AI에게 공간을 깔끔하게 내어주기 위해서요. 우아한 백조도 수면 아래서는 부단히 헤엄칩니다. 오늘의 o1 의 메커니즘은 숱한 정교한 프롬프트 엔지니어링의 시도로 이루어 낸 결과입니다. OpenAI의 o1은 가까운 미래, 아니 내일의 한 glimpse 입니다. 이 모델과 공존하기 위해서라도, 실용적이고 신뢰할 수 있는 AI의 결과물을 얻기위해 바지런히 프롬프트 엔지니어의 역할을 다해야 할 것 같습니다. #promptengineering #prompt #o1model #llm #adviceonprompting

프롬프트 엔지니어에 대한 고찰 프롬프트 엔지니어링이 단순 프롬프트를 잘 쓰는 것이 아닌, 전문적인 역량과 스킬이 필요한 이유가 잘 설명된 글입니다. 이 글에 대한 네 가지 reflection 을 해봤습니다. 1️⃣ 프롬프트와 프롬프트 엔지니어링에 대한 정의 시중에 많은 정의가 있지만 여전히 혼재되어 있어 재고(Revisiting)가 필요하다고 생각합니다.LLM의 아키텍처 개념을 사용하여 설명하면 어느 의미에서 프롬프트와, 프롬프트 엔지니어링인지 정확해지는 것 같습니다. 2️⃣ 프롬프트 엔지니어는? 생성형 AI 기업의 프롬프트 엔지니어는 LLM의 최종 출력층에서 "프롬프트 최적화를 하는 사람" 입니다. LLM <-> End user 사이에 위치하여 모델의 출력을 조정하고, 고도화하는 작업을 합니다. 프롬프트 엔지니어의 포지션은 최종 출력층이지만, 그 이전 층의 트랜스포머 아키텍처, 구송 요소들의 작동 원리를 알아야 프롬프트 최적화를 할 수 있습니다. 때문에, 단순히 ChatGPT의 답변을 잘 받았다고 혹은 문장을 잘 썼다고 프롬프트 엔지니어라 할 수 없을 것 같습니다. 3️⃣ Q(Query), K(Key), V (Value)가중치 행렬 활용 = 단어의 빈도수 제가 프롬프팅을 할 때 Q, K, V 값을 활용할 수 있도록 google ngram을 사용합니다. ngram 에 A단어/B단어의 빈도수를 비교하여, 가장 많이 쓰이는 단어를 프롬프트로 작성합니다. 예를들어, generate 보다는 develop 이 현대 영어(1980-현재)에서 더 빈도수가 큰 단어입니다. develop을 썼을 때, 원하는 결과를 쉽게 얻을 수 있었어요. LLM이 학습한 데이터 내 단어의 빈도수가 많을 수록, 언어의 semantic, syntax 의 관계가 더 커져, 원하는 결과물을 이끌어 낼 수 있었기 때문입니다. Attention 가중치가 올라갔다고 판단할 수 있을까요? 4️⃣ Q, K, V 가 무효할 때 = 언어의 Pragmatics 가 커질 때 Tokenizer 를 통해, 단어를 쪼개고 의미를 나누고, 문법의 패턴을 익힌다 하더라도 Pragmatics은 LLM이 하지 못하는 영역입니다. 그래서 엉뚱한 소리를 하거나, 이상한 답변을 해요. 특히 한국어는 더 그렇습니다. 한국어는 "고맥락"의 언어입니다. 문장이 발화된 상황에 의존하여, 발화 된 뜻을 상황속에서만 파악할 수 있습니다. 예를들어, 한국어에서 "괜찮아"가 맥락 의존적인 표현인데요. "커피마실래?" "괜찮아" 마시겠다는 건지, 안 마시겠다는 건지는 발화의 의도를 발화 상황에서 파악해야 합니다. 따라서, 이런 task 를 수행하는 기능 구현을 위한 프롬프트를 제작할 때는 "엔지니어링"을 해야 합니다. shot 으로 LLM에게 정보를 주거나, turn을 활용하여 role-play demonstration 을 하기도 해요. 결론: 요즘 한국어를 분석하면, 화용이 더 강해집니다. 언어의 형태나 의미보다는 기능이 더 중요해지는 거죠. meme이나, 주어를 생략하고 말하거나, 줄임말을 쓰는 것이 증거예요. 한국어의 화용을 LLM이 잘 이해할 수 있도록하는 프롬프트 엔지니어링이 필요할 것 같습니다.