쉬운 설명
LLM은 '입력 다음에 올 글'을 예측합니다. 어떤 입력을 주느냐에 따라 답의 품질이 크게 달라집니다. 같은 모델·같은 질문이라도 프롬프트를 어떻게 짜느냐에 따라 답이 짧고 모호할 수도, 길고 구조화될 수도 있습니다. 그래서 '모델을 잘 다룬다'의 첫 번째 의미는 '좋은 프롬프트를 쓴다'입니다.
프롬프트는 보통 다음 요소를 조합합니다. ① 시스템 메시지(역할·말투·제약을 정함), ② 컨텍스트(관련 자료·이전 대화), ③ 지시(무엇을 하고 어떤 형식으로 답할지), ④ 예시(few-shot — 좋은 입출력 쌍 몇 개를 보여 주기), ⑤ 사용자 질문. 단순한 일에는 ⑤만 있어도 되지만, 복잡한 일일수록 ①~④가 결과 품질을 좌우합니다.
'프롬프트 엔지니어링'이란 단어는 거창하지만, 실무에서 자주 쓰는 기법은 몇 가지로 압축됩니다. 역할 지정('당신은 ___입니다'), 단계 분해('먼저 ___, 다음에 ___'), 출력 형식 지정(JSON·표·번호 매기기), 사고 과정을 적어 달라고 요청(chain-of-thought), 예시 1~3개 제공. 이런 작은 장치들이 모이면 답의 정확도와 일관성이 눈에 띄게 올라갑니다.
프롬프트가 다른 방법들과 어떻게 비교되는지도 알아 두면 도움이 됩니다. 모델 자체를 바꾸지 않아도 되니 가장 싸고 빠르고 안전합니다. 단점은 같은 효과를 매번 같은 입력으로 보장하기 어렵다는 점입니다. 같은 프롬프트라도 모델 버전·날짜에 따라 답이 달라질 수 있습니다. 그래서 평가용 입출력 묶음(eval set)을 만들어 두고 변경마다 비교하는 습관이 중요합니다.
주의할 점: 프롬프트에 너무 의존하면 안 되는 정보도 있습니다. 비밀번호·API 키·고객 개인정보를 프롬프트에 그대로 적으면, 모델 운영자의 로그나 다른 사용자의 답변으로 흘러들어 갈 수도 있습니다. 또 '한 번 잘 작동한 프롬프트'가 모델 업데이트 후 갑자기 어긋날 수 있으니, 운영 중인 프롬프트는 버전을 관리하고 평가를 자동화해 두는 것이 안전합니다.
비유로 보면
프롬프트는 도시락 주문서와 비슷합니다. '저녁용', '매운 거 빼고', '두 명분', '재료 알레르기는 없음' 같은 작은 단서가 늘수록 도시락이 점점 우리 입맛에 가까워집니다. 같은 주방장에게 같은 식재료를 시켜도, 주문서 한 줄이 결과를 결정합니다.
어디에서 만나나
챗봇 응대, 자동 글쓰기·요약, 코드 도우미, 데이터 추출·라벨링, 사내 검색 보조, 마케팅 카피 — 거의 모든 LLM 응용의 첫 번째 튜닝 손잡이가 프롬프트입니다. 회사들이 '프롬프트 라이브러리'를 두고 팀 단위로 좋은 프롬프트를 공유하기 시작했습니다.
작은 예시
이메일을 정리하는 작업에 '메일 본문을 3줄로 요약해 주세요'라고만 적으면 결과가 들쭉날쭉합니다. 같은 일을 '아래 메일을 ① 핵심 결정 ② 마감일 ③ 다음 액션의 3개 항목으로 요약해 줘. 각 항목은 한 줄 이내'로 적으면 답이 거의 항상 같은 형식으로 정리됩니다.
자주 하는 오해
한 줄 정리
프롬프트는 LLM의 가장 싼 튜닝 도구입니다. 모델을 바꾸기 전에, 프롬프트를 먼저 다듬는 습관이 거의 항상 이득을 냅니다.