AI에게 건네는 '한 장의 지시서'를 목적·수신자·근거·서식에 맞춰 정확하게 설계해, 재작업 없이 실무에 바로 쓸 결과를 끌어내는 기술.
4컷으로 보기 — 프롬프트는 결재를 올릴 때 상급자에게 건네는 '한 장짜리 기안 메모'다
- 11컷: 엉망 기안 반려 대소동
- 22컷: 등장, 4요소 기안 메모!
- 33컷: 역할·과업·맥락·형식 착착 정리
- 44컷: 한 번에 결재 통과, 칼퇴근
왜 중요한가
스택의 최소 단위이자 모든 AI 활용의 출발점이다. 같은 모델이라도 지시가 모호하면 엉뚱한 결과를, 명확하면 실무에 바로 쓸 초안을 낸다. 비개발 실무자가 가장 먼저·가장 크게 체감하는 개선점이며, 상위 계층(컨텍스트·하네스)도 결국 '좋은 프롬프트를 반복 생성·주입'하는 장치이므로 여기서의 정확성이 그대로 위로 전파된다. 이 계층이 부재하거나 부실하면 나타나는 실패 모드: (1) 결과가 매번 달라 신뢰할 수 없다(재현성 붕괴), (2) 형식이 제각각이라 후속 자동화에 못 태운다, (3) 근거 없는 단정·환각이 걸러지지 않고 그대로 결재선에 올라간다, (4) '프롬프트만 고치면 되겠지' 하며 실제로는 자료 부재(컨텍스트)나 절차 부재(하네스)인 문제를 계속 프롬프트로 때우려다 시간을 낭비한다. 즉 프롬프트 엔지니어링은 단지 '말 잘하는 법'이 아니라, 어디까지가 프롬프트로 풀 문제이고 어디부터가 상위 계층의 문제인지 진단하는 능력까지 포함한다.
행정 실무 비유
프롬프트는 결재를 올릴 때 상급자에게 건네는 '한 장짜리 기안 메모'다. 무엇을 해야 하는지(과업), 누구 입장에서 처리할 일인지(역할), 어떤 근거·배경에서 나온 건인지(맥락), 결과를 어떤 서식으로 돌려줄지(형식)—이 네 가지가 메모에 빠지면 반려되거나 엉뚱한 결과가 돌아온다. 잘 쓴 기안문 한 장이 결재를 한 번에 통과시키듯, 4요소가 갖춰진 프롬프트가 재작업을 없앤다. 나아가 '거부·반려 조건'을 미리 적어두는 것은 위임전결 규정에서 '이 범위를 벗어나면 전결하지 말고 상신하라'고 못박는 것과 같고, 퓨샷 예시는 '이 서식으로 써 오라'며 붙이는 기존 결재 문서 샘플과 같다. 다만 억지로 밀어붙이지는 말자: 프롬프트로 안 되는 일(예: 최신 법령 원문이 필요한 일)은 메모를 아무리 다듬어도 안 되고, 서류철(컨텍스트)을 채워줘야 한다.
🖐 실무 따라하기 — 복붙해서 따라 하면 됩니다
- 1반려되는 프롬프트를 직접 던져 '왜 반려되는지' 눈으로 확인
ChatGPT 또는 Claude 새 대화창(또는 /playground 입력창)에 아래 한 줄을 그대로 붙여넣고 전송한다. 일부러 4요소(역할·과업·맥락·형식)가 빠진 '나쁜 프롬프트'다. 결과를 지우지 말고 그대로 둔다 — 2단계 결과와 비교할 것이다.
프롬프트 (복사해서 AI에 입력)포트홀 민원 회신문 좀 써줘.
→ 결과 누구 명의인지·민원인이 누구인지·형식이 무엇인지 모른 채 AI가 제멋대로 회신문을 만든다. 회사 이름을 [회사명]으로 비우거나, 배상을 덜컥 약속하거나, 이모지·반말이 섞여 나온다. 실행할 때마다 어투·형식이 달라진다. 이 초안은 그대로 결재 못 올린다 = '반려'. 이게 4요소가 빠지면 생기는 문제임을 체감한다.
- 2역할·과업·맥락·형식 4요소 + 제약(금지선)을 넣은 '통과 프롬프트'로 교체
새 메시지로 아래 프롬프트 전문을 처음부터 끝까지 통째로 붙여넣고 전송한다. [역할]/[과업]/[맥락]/[형식] 4개 구획과 마지막 [제약·금지선] 구획이 핵심이다. 대괄호 안 값은 합성 데이터이므로 그대로 둔다.
프롬프트 (복사해서 AI에 입력)[역할] 너는 경상북도청 도로관리과 민원 담당 주무관이다. 공문 문서체로 회신문을 작성한다. [과업] 아래 접수 민원에 대한 '1차 회신문' 초안을 1건 작성한다. 배상 여부를 확정 통보하는 문서가 아니라, 접수 사실 확인 + 현장 확인 예정 안내 + 후속 절차 안내가 목적이다. [맥락] - 접수번호: MW-2026-0001 - 민원인: 홍길동 - 민원 요지: 자택 앞 도로 포트홀로 차량 타이어 파손, 도로 보수 및 손해배상 요구 - 처리 상황: 현장 확인 일정 미정, 배상 가능 여부 미확정 [형식] - 한국어, 공문 문서체(~합니다/~드립니다) - 구성: 제목 → 인사말 → 접수 확인 → 향후 처리 절차(번호 목록) → 문의 안내 → 맺음말 - 분량 400자 이내 [제약·금지선] - 배상 여부·보수 일정을 확정적으로 약속하지 말 것("검토 예정"으로 표현) - 이모지·과장된 사과·반말 금지 - 확인되지 않은 날짜·금액·법조문은 만들어내지 말고 [확인 필요]로 표기할 것→ 결과 1단계와 확연히 다른 결과가 나온다: 도로관리과 명의, 공문 문서체, '제목/인사말/접수 확인/처리 절차(번호 목록)/문의/맺음말' 구조가 잡히고, 배상은 '검토 예정'으로만 표현된다. 지어낸 날짜·금액이 있어야 할 자리는 [확인 필요]로 비어 있다. 이게 결재 올릴 수 있는 '통과' 초안이다.
- 3퓨샷(예시 2개)으로 우리 부서 말투를 고정
결과 말투가 우리 부서 관례와 다르면, 같은 대화창에 이어서 아래 메시지를 붙여넣는다. '이렇게 시작하고 이렇게 끝맺어라'는 짧은 예시 2개(퓨샷)를 주고 2단계 초안을 다시 쓰게 한다.
프롬프트 (복사해서 AI에 입력)우리 부서 회신문 어투 예시를 줄 테니, 이 톤에 맞춰 위 초안을 다시 작성해줘. 예시1(시작): "안녕하십니까. 귀하께서 제출하신 민원(접수번호 ○○)에 대하여 다음과 같이 회신드립니다." 예시2(맺음): "항상 도정에 관심을 가져 주셔서 감사합니다. 추가 문의사항은 도로관리과(○○○-○○○○)로 연락 주시기 바랍니다."
→ 결과 회신문의 첫 문장과 끝 문장이 예시 톤으로 통일된다. 전화번호처럼 실제 값이 필요한 자리는 ○○○-○○○○ 또는 [확인 필요]로 남는다. 매번 달라지던 어투가 예시 2개만으로 고정되는 것을 확인한다(퓨샷 효과).
- 4STEP 체인 + 사고사슬로 '분류→근거→초안'을 한 번에 처리
문서 한 건을 단계로 쪼개 처리하는 STEP 체인이다. 아래 전문을 새 메시지로 붙여넣는다. 각 STEP을 순서대로 수행하되 STEP1·2의 판단 근거를 먼저 보여주고(사고사슬) STEP3 초안을 쓰게 한다.
프롬프트 (복사해서 AI에 입력)아래 민원을 STEP 순서대로 처리해줘. 각 STEP 결과를 구분해서 보여줘. STEP1(분류): 이 민원을 [단순안내 / 현장확인필요 / 배상심의대상] 중 하나로 분류하고, 그렇게 분류한 이유를 한 문장으로 밝혀라. STEP2(누락점검): 회신 전에 담당자가 추가 확인해야 할 사항을 3가지 이내로 뽑아라(예: 현장 확인 일정, 파손 입증자료). STEP3(초안): STEP1·2를 반영해 최종 1차 회신문을 작성하라. 민원: 접수번호 MW-2026-0001, 홍길동, 자택 앞 도로 포트홀로 타이어 파손, 보수·배상 요구.
→ 결과 결과가 STEP1/STEP2/STEP3로 나뉘어 나온다. STEP1은 대개 '현장확인필요' 또는 '배상심의대상'으로 분류하고 이유를 한 줄로 제시(사고사슬). STEP2는 현장 확인 일정·파손 입증자료·배상 근거법령 확인 같은 체크리스트를 준다. STEP3는 그 판단이 반영된 회신문 초안이다 = 문서 한 건이 분류·점검까지 끝나 나온다.
- 5자기검증 + 환각 저감: 초안을 스스로 감사하게 만들기
결재 올리기 전 마지막 관문. 4단계 STEP3 초안을 대상으로 같은 대화창에 아래를 붙여넣어 AI가 자기 결과물을 체크리스트로 검사하게 한다. 표로 답하도록 형식을 지정(구조화 출력)한다.
프롬프트 (복사해서 AI에 입력)방금 작성한 회신문 초안을 아래 체크리스트로 검사하고, 결과를 표로 출력해줘. 통과 못 한 항목은 수정안을 함께 제시해줘. | 점검항목 | 통과/실패 | 문제 부분 | 수정안 | |---|---|---|---| 체크리스트: 1. 배상·보수를 확정적으로 약속한 표현이 있는가? (있으면 실패) 2. 지어낸 날짜·금액·법조문이 있는가? (있으면 실패, [확인 필요]로 바꿔야 함) 3. 접수번호 MW-2026-0001이 정확히 들어갔는가? 4. 공문 문서체가 아니거나 이모지·반말이 있는가? (있으면 실패)
→ 결과 4행짜리 점검 표가 나온다. 이전 단계에서 배상을 약속했거나 임의 날짜를 넣었다면 '실패'로 잡히고 수정안이 제시된다. 표에서 모든 항목이 '통과'가 될 때까지 반복하면 된다. 지어낸 값을 스스로 [확인 필요]로 되돌리는 것이 환각 저감이다. 이 표를 통과한 초안을 복사해 실제 결재 시스템에 붙여넣는다.
스택 내 위치
AI 엔지니어링 스택의 최내층(①). 한 번의 요청—즉 모델에게 건네는 단일 지시서 그 자체를 다룬다. 바로 바깥의 ②컨텍스트가 '지시서 곁에 놓는 서류철(자료·이력·도구설명)'을 다룬다면, 프롬프트는 그 지시서 본문의 문장 설계에 집중한다. 경계는 명확하다: 어떤 자료를 어떻게 검색·주입할지는 컨텍스트의 몫이고, 그 자료가 주어졌다고 가정했을 때 '무엇을·어떻게·어떤 형식으로 시키는가'가 프롬프트의 몫이다. 하네스(③) 이상은 이 프롬프트를 반복 생성·주입하는 장치이므로, 여기서의 정확성이 위 계층으로 전파된다.
핵심 개념 (14)
프롬프트가 갖춰야 할 최소 골격. 누구로서(역할)·무엇을(과업)·어떤 배경에서(맥락)·어떤 산출 형태로(형식) 답하라를 명시한다. 기안 메모의 필수 기재사항에 해당한다.
💡 네 요소 중 하나만 빠져도 모델은 빈칸을 임의로 채우며, 그 임의값이 매번 달라 결과가 흔들린다.
예시 없이 지시만으로 시키는 방식(제로샷)과, 원하는 입력→출력 예시를 1개 이상 붙여 패턴을 학습시키는 방식(퓨샷). 퓨샷은 형식·톤·판정 기준을 말로 설명하기 어려울 때 특히 강력하다.
💡 '이렇게 써 오라'는 말보다 잘 만든 예시 2~3개가 형식과 톤을 훨씬 정확히 고정한다.
'단계별로 생각해 보라'처럼 모델이 결론 전에 중간 추론을 펼치도록 유도하는 기법. 다단계 계산·논리·법령대조처럼 한 번에 답하기 어려운 과업에서 정확도를 높인다.
💡 복잡한 판단을 한 문장으로 요구하면 건너뛴 채 단정한다. 추론을 펼치게 하면 오류가 드러나고 줄어든다.
결과를 표·JSON·불릿·정해진 항목 순서 등 특정 서식으로 내도록 명시하는 것. 구조화 출력(예: JSON 스키마 지정)은 결과를 후속 시스템에 자동으로 태울 수 있게 한다.
💡 형식을 못박지 않으면 산출물이 제각각이 되어 사람이 다시 정리해야 하고 자동화에 못 태운다.
대화 전체에 걸쳐 고정되는 지속 지시(시스템: 역할·규칙·금지선)와, 매 요청마다 바뀌는 구체 과업(사용자)을 분리하는 구조. 시스템 프롬프트는 상위 우선순위로 작동한다.
💡 항상 지켜야 할 규칙을 매번 다시 쓰면 누락·모순이 생긴다. 고정 규칙과 개별 과업을 분리해야 일관성이 산다.
'무엇을 하라'뿐 아니라 '무엇을 하지 말라'(길이 제한, 추측 금지, 특정 표현 금지, 개인정보 미기재 등)를 함께 적는 것. 위임전결 규정의 '이 범위를 벗어나지 말라'에 해당한다.
💡 부정 조건을 안 적으면 모델은 친절하게 과잉 생성하거나 근거 없이 빈칸을 메운다. 경계가 결과 품질을 지킨다.
큰 과업을 여러 개의 작은 프롬프트로 쪼개 순서대로 처리하는 설계. 각 단계의 출력이 다음 단계의 입력이 된다(예: 자료요약→쟁점추출→답변초안).
💡 한 프롬프트에 모든 걸 욱여넣으면 지시가 서로 간섭한다. 단계로 나누면 각 단계를 따로 검증·재사용할 수 있다.
초안을 낸 뒤 같은(또는 별도) 프롬프트로 '위 답에서 틀린 곳·근거 없는 주장을 찾아 고치라'고 다시 시키는 기법. 초안과 검토를 분리해 품질을 끌어올린다.
💡 사람도 초안과 교정을 분리하듯, 모델도 '검토자' 역할을 따로 부여하면 놓친 오류를 스스로 잡아낸다.
근거가 없으면 '모른다'고 답하게 하기, 제공된 자료 안에서만 답하게 하기, 주장마다 출처를 표기하게 하기 등으로 그럴듯한 허위 생성을 줄이는 지시 설계.
💡 근거 없는 단정이 걸러지지 않고 결재선에 올라가면 행정 신뢰가 무너진다. 프롬프트 단에서 1차 방어선을 친다.
프롬프트를 '한 번 쓰고 버리는 말'이 아니라 관리 대상 자산으로 보고, 변경 이력·의도·성능을 기록하며 개선하는 실천. 표준 기안서식을 개정 이력과 함께 관리하는 것과 같다.
💡 어떤 프롬프트가 왜 더 나았는지 기록이 없으면 개선이 우연에 의존한다. 버전관리는 재현성과 조직 확산의 토대다.
과도한 장황함, 서로 모순되는 지시, 부정문 남발, 예시 없는 추상적 요구, 한 프롬프트에 너무 많은 과업 등 결과를 오히려 악화시키는 흔한 잘못.
💡 '길게 쓰면 좋다'는 착각이 대표적이다. 장황·모순은 지시끼리 간섭해 품질을 떨어뜨린다. 무엇을 빼야 하는지가 실력이다.
범위를 벗어난 요청·불확실한 상황에서 무리하게 답하지 말고 '처리 불가' 또는 '추가 정보 요청'을 반환하도록 설계하는 것. 민원 반려 사유 안내와 유사하다.
💡 모델은 기본적으로 '도움을 주려' 무리한 답을 만든다. 안전한 실패(거절)를 명시해야 잘못된 자동처리를 막는다.
눈앞의 문제가 프롬프트로 풀 문제인지, 아니면 상위 계층(자료 부재=컨텍스트, 절차 부재=하네스)의 문제인지 가려내는 판단력. 프롬프트 엔지니어링의 '메타 능력'.
💡 자료가 없어서 나는 오류를 프롬프트만 다듬어 고치려 하면 무한 헛수고에 빠진다. 문제의 계층을 맞게 짚는 것이 가장 큰 절약이다.
프롬프트 산출물을 사람이 언제·무엇을 보고 승인/반려할지 그 접점을 결과에 미리 반영하는 것(예: '검토가 필요한 항목을 별도 표시하라').
💡 AI 초안은 결재 전 초안일 뿐이다. 사람이 확인할 지점을 산출물이 스스로 표시하게 하면 검토 부담이 크게 준다.
학습 목표
- 프롬프트 4요소(역할·과업·맥락·형식)를 말로 설명하고, 주어진 나쁜 프롬프트에서 빠진 요소를 지목할 수 있다.
- 제로샷과 퓨샷의 차이를 이해하고, 형식을 고정하고 싶을 때 예시를 붙일 수 있다.
- 출력 형식을 표·불릿·정해진 항목으로 지정해 결과를 정돈된 형태로 받을 수 있다.
- '모르면 모른다고 답하라' 같은 기본 환각 저감 지시를 프롬프트에 넣을 수 있다.
- 시스템/사용자 프롬프트를 분리해 재사용 가능한 지시 세트를 만들 수 있다.
- 큰 과업을 STEP 체인으로 분해하고 각 단계 출력을 다음 입력으로 연결할 수 있다.
- 자기검증 프롬프트로 초안을 스스로 교정하게 만들 수 있다.
- 같은 과업의 프롬프트 두 버전을 비교해 무엇이 왜 더 나은지 근거를 대고 고를 수 있다(평가 초보).
- 구조화 출력(JSON 스키마 등)을 지정해 산출물을 후속 자동화에 태울 수 있다.
- 거절·경계 사례·HITL 접점을 설계해 안전한 실패와 사람 검토 지점을 산출물에 내장할 수 있다.
- 눈앞 문제가 프롬프트 문제인지 상위 계층(컨텍스트/하네스) 문제인지 진단해 헛수고를 피할 수 있다.
- 프롬프트를 버전관리·평가와 결합해 조직 표준 서식으로 재생산할 수 있다(메타·평가 계층으로의 연결).
세션 구성
| 회차 | 주제 | 시수 | 내용 | 산출물 |
|---|---|---|---|---|
| 1 | 왜 프롬프트인가 · 4요소 골격 | 2h | AI 엔지니어링 스택에서 프롬프트의 위치와 한계. '한 장의 기안 메모' 비유로 역할·과업·맥락·형식 4요소를 도입. 나쁜 프롬프트를 함께 진단하며 빠진 요소를 찾는 실습. 같은 과업을 4요소 전/후로 돌려 결과 차이를 눈으로 확인. | 본인 업무 과업 3개에 대한 '4요소 체크리스트 통과' 프롬프트 3종 |
| 2 | 예시의 힘 · 제로샷·퓨샷과 출력 형식 | 2h | 말로 설명하기 어려운 톤·서식을 예시로 고정하는 법. 좋은 퓨샷 예시를 고르는 기준(대표성·경계 포함·불균형 방지). 출력 형식 지정: 표·불릿·항목 순서. 구조화 출력(JSON) 맛보기와 그것이 왜 자동화의 관문인지. | 퓨샷 2~3개로 서식을 고정한 '민원답변 초안 생성' 프롬프트 |
| 3 | 복잡한 일 쪼개기 · 사고사슬과 STEP 체인 | 2.5h | 한 번에 안 되는 과업을 단계로 분해. '단계별로 생각하라'의 효과와 한계. STEP 체인 설계(자료요약→쟁점추출→초안→검토)와 단계 간 입출력 연결. 프롬프트 분해가 상위 계층(오케스트레이션)으로 자라는 지점 예고. | 4단계 STEP 체인으로 처리한 실제 업무 문서 1건 |
| 4 | 믿을 수 있게 만들기 · 환각 저감·자기검증·거절 설계 | 2.5h | 근거 없는 단정을 줄이는 지시 기법: 자료 내 답변 한정, 출처 표기, '모르면 모른다'. 초안↔검토 분리(자기비판 프롬프트). 경계 사례·거절 유도와 HITL 접점 표시. 시스템/사용자 분리와 금지선 명시. | 환각 저감 + 자기검증 + '검토 필요 항목 표시'가 포함된 프롬프트 세트 |
| 5 | 안티패턴·계층 진단 · 버전관리와 평가로의 연결 | 2h | 장황·모순·부정문 남발 등 안티패턴 교정 워크숍. '이건 프롬프트 문제인가, 자료/절차 문제인가' 계층 진단 훈련. 프롬프트를 자산으로: 변경 이력·의도·성능 기록. A/B 비교로 '더 나은지 어떻게 아는가'(평가 씨앗) 실습. 컨텍스트·하네스로의 다리 놓기. | 개인 프롬프트 라이브러리(버전·의도·간단 평가 기록 포함) 초판 |
실습 랩
랩 1 — 반려당하는 프롬프트를 결재 통과 프롬프트로
목표 · 4요소(역할·과업·맥락·형식)를 적용해 모호한 지시를 실무 즉시 사용 가능한 지시로 재작성한다.
- 본인 업무에서 최근 AI에게 시켰지만 결과가 마음에 안 들었던 요청 1개를 그대로 적는다.
- 그 요청에 역할·과업·맥락·형식 4요소가 각각 있는지 O/X로 표시한다.
- 빠진 요소를 채워 v2를 작성한다. 역할은 '경상북도 OO담당 주무관'처럼 구체적으로, 형식은 '표로, 열은 항목·현황·조치'처럼 명시한다.
- v1과 v2를 같은 모델에 각각 넣고 결과를 나란히 붙여 비교표를 만든다.
- 무엇이 왜 좋아졌는지 한 문장으로 적는다(어느 요소가 결정적이었나).
✅ 성공 기준 · v2 결과가 사람이 손대지 않고 결재 초안으로 쓸 수 있는 수준이며, 개선의 원인을 특정 요소로 지목해 설명할 수 있다.
↗ 확장 · 같은 v2를 시스템 프롬프트(고정 규칙)와 사용자 프롬프트(이번 과업)로 분리해 재사용 가능한 형태로 만든다.
랩 2 — STEP 체인으로 실제 문서 한 건 처리하기
목표 · 한 번에 안 되는 업무를 4단계 프롬프트 체인으로 분해해 처리하고, 마지막에 자기검증과 HITL 표시를 붙인다.
- 처리할 실제 문서/사안 1건을 고른다(예: 장문 보고서 요약 후 답변 작성, 또는 여러 민원의 유형 분류 후 표준답변 배정).
- 단계를 설계한다: ①핵심 요약 → ②쟁점/요구사항 추출 → ③답변·조치 초안 → ④자기검증(근거 없는 주장·틀린 부분 찾아 수정).
- 각 단계를 별도 프롬프트로 작성하고, 앞 단계 출력을 다음 단계 입력으로 그대로 넘긴다.
- ④단계 프롬프트에 '확실치 않아 사람 확인이 필요한 항목은 [검토필요] 태그로 표시하라'를 넣는다.
- 한 프롬프트에 전부 욱여넣은 '한 방' 버전도 만들어 체인 결과와 품질·검토 편의성을 비교한다.
✅ 성공 기준 · 체인 최종 산출물이 [검토필요] 태그로 사람이 볼 지점을 스스로 표시하고, '한 방' 버전보다 오류가 적거나 검토가 쉬움을 근거로 설명할 수 있다.
↗ 확장 · ④ 자기검증을 '초안 작성자'와 다른 역할(엄격한 감사관)로 분리해 자기비판 강도를 높이고 차이를 관찰한다.
사례 연구
상황 · 한 지자체 부서가 반복되는 유사 민원에 매번 답변을 새로 작성하느라 담당자별로 톤·근거·형식이 제각각이었다. 처음엔 'AI야 이 민원에 답변해 줘'라고만 시켰다.
1차(제로샷, 4요소 없음)에서는 답변이 지나치게 사과조이거나, 없는 규정을 그럴듯하게 인용하는 환각이 섞였다. 개선팀은 (a) 역할을 '민원 담당 주무관'으로, (b) 형식을 '인사→사실확인→근거→조치→안내'의 고정 5단 서식으로 지정하고, (c) 잘 쓰인 기존 답변 2건을 퓨샷 예시로 붙였다. 결정적으로 (d) '제공된 규정 발췌 안에서만 근거를 대고, 없으면 [담당자 확인 필요]로 표시하라'는 환각 저감·HITL 지시를 추가했다. 그 결과 근거 날조가 사라지고, 담당자는 [담당자 확인 필요] 표시된 부분만 검토하면 되어 처리시간이 크게 줄었다. 다만 '규정 발췌'를 매번 사람이 붙여넣는 게 병목이었는데, 이는 프롬프트가 아니라 컨텍스트(자료 자동 검색=RAG)의 문제임을 진단하고 다음 계층으로 넘겼다.
교훈 · 프롬프트로 형식·톤·환각은 잡을 수 있지만, '규정을 자동으로 찾아 붙이는' 일은 프롬프트가 아니라 컨텍스트 계층의 몫이다—계층 진단이 시간을 아낀다.
상황 · 고객문의를 유형별로 분류해 담당 부서로 자동 라우팅하려는 팀이 있었다. 초기엔 모델에게 '이 문의 유형이 뭐야?'라고 자연어로 물었다.
자연어 답변('음, 이건 아마 환불 관련 같아요…')은 사람이 읽기엔 좋았지만 시스템이 파싱할 수 없어 자동화가 막혔다. 팀은 출력을 구조화했다: 허용 카테고리를 고정 목록으로 제시하고, 결과를 {"category": <목록 중 하나>, "confidence": <상/중/하>, "reason": <한 문장>} JSON으로만 반환하도록 지정했다. 또 목록에 안 맞으면 임의로 지어내지 말고 category를 'unknown'으로 두고 confidence를 '하'로 표시하게 했다(거절 설계). 이 구조화 출력 덕에 confidence '상'은 자동 라우팅, '중·하'와 'unknown'은 사람 검토 큐로 보내는 HITL 분기가 가능해졌다.
교훈 · 출력 형식을 못박고 '모르면 unknown'을 허용하는 것만으로 프롬프트가 자동화의 관문이 된다. 구조화 출력과 거절 설계는 하네스로 넘어가기 위한 프롬프트 계층의 준비물이다.
흔한 실패 · 안티패턴
- '길게 쓰면 좋다'는 착각으로 프롬프트를 장황하게 부풀려, 정작 중요한 지시가 묻히고 지시끼리 간섭한다.
- 서로 모순되는 지시를 한 프롬프트에 담는다(예: '간결하게' + '가능한 모든 세부사항을 포함하라').
- 부정문만 잔뜩 나열한다('~하지 마'). 모델은 '무엇을 하라'는 긍정 지시에 더 잘 반응한다—금지선은 최소·핵심만.
- 예시 없이 추상적 형용사로만 요구한다('전문적으로', '친절하게'). 퓨샷 한두 개가 형용사 열 개보다 정확하다.
- 한 프롬프트에 과업을 여러 개 욱여넣어(요약+번역+분류+작성) 각각의 품질이 다 떨어진다—분해가 답이다.
- 환각을 프롬프트 표현만 바꿔 없애려 한다. 근본 원인이 '자료 부재'라면 컨텍스트(RAG)로 풀어야 할 문제를 프롬프트로 무한 반복 수정한다.
- 결과가 매번 다른데도 버전·의도를 기록하지 않아, 어쩌다 좋았던 프롬프트를 재현하지 못한다.
- '모델이 알아서 하겠지'라며 거절·경계 조건을 안 적어, 범위 밖 요청에도 무리하게 그럴듯한 답을 만들어 낸다.
- AI 산출물을 검토 없이 그대로 결재선에 올린다—프롬프트가 아무리 좋아도 HITL 접점 설계가 없으면 위험하다.
- 형식을 지정하지 않아 산출물이 제각각이 되고, 후속 자동화에 못 태워 결국 사람이 다시 정리한다.
평가
| 평가 기준 | 초급 | 능숙 | 전문 |
|---|---|---|---|
| 4요소 골격의 완결성 | 역할·과업·맥락·형식 중 일부만 담기며, 빠진 요소를 스스로 알아채지 못한다. | 네 요소를 모두 명시하고 형식을 구체적으로(표/항목 순서) 지정한다. | 과업 성격에 따라 어떤 요소를 더 강조할지 판단하고, 시스템/사용자로 분리해 재사용 가능한 형태로 설계한다. |
| 예시·형식 활용 | 제로샷만 쓰고 형식을 지정하지 않아 결과가 매번 달라진다. | 퓨샷으로 톤·서식을 고정하고 표/불릿 등 출력 형식을 지정한다. | 대표성 있는 예시를 선별하고, 구조화 출력(JSON 스키마)으로 후속 자동화에 태울 수 있게 설계한다. |
| 복잡성 관리(분해·사고사슬) | 모든 걸 한 프롬프트에 욱여넣어 지시가 서로 간섭한다. | 큰 과업을 단계로 분해하고 사고사슬을 유도해 다단계 판단의 정확도를 높인다. | STEP 체인의 단계 경계를 근거 있게 나누고, 각 단계를 독립 검증·재사용하며 오케스트레이션으로 확장할 지점을 안다. |
| 신뢰성(환각 저감·자기검증·거절·HITL) | 근거 없는 단정을 걸러내지 못하고, 사람 검토 지점을 고려하지 않는다. | '모르면 모른다'·출처 표기·자기검증을 넣고 검토 필요 항목을 표시하게 한다. | 거절·경계 사례를 설계해 안전한 실패를 내장하고, HITL 접점을 산출물 구조에 반영한다. |
| 계층 진단·개선(버전관리·평가) | 모든 문제를 프롬프트만 고쳐 풀려 하고, 개선 근거를 기록하지 않는다. | 문제가 프롬프트/자료/절차 중 어디에 속하는지 대체로 진단하고, 프롬프트 버전을 기록한다. | A/B 비교로 개선을 검증(평가)하고, 프롬프트를 조직 표준 서식으로 재생산하며 상위 계층으로 정확히 인계한다. |
- Q1. 다음 프롬프트에서 부족한 점을 두 가지 이상 지적하고 고쳐 보세요: '이 보고서 좀 요약해 줘.'
- Q2. AI가 존재하지 않는 규정을 그럴듯하게 지어내 답했습니다. 프롬프트 차원에서 이를 줄일 방법을 한 가지 이상 쓰세요.
- Q3. '제로샷'과 '퓨샷'의 차이를 한 문장으로 설명하세요.
- Q1. 본인 업무 과업 하나를 골라, 역할·과업·맥락·형식 4요소를 모두 갖추고 출력 형식을 표로 지정한 프롬프트를 작성하세요. 이어서 이 과업을 STEP 체인 3단계로 분해한다면 각 단계를 무엇으로 나눌지 쓰세요.
- Q2. 다음 상황을 진단하세요: '프롬프트를 열 번 넘게 고쳤는데도 AI가 계속 최신 조례 내용을 틀리게 답한다.' 이것이 프롬프트 문제인지, 상위 계층 문제인지 판단하고 근거와 다음 조치를 쓰세요.
- Q3. 자연어로 유형을 답하던 분류 작업을 후속 시스템에 자동으로 태우려 합니다. (a) 출력을 어떻게 구조화할지, (b) 목록에 없는 애매한 입력에는 어떻게 거절/표시하게 할지, (c) 사람 검토(HITL) 분기를 어디에 둘지 설계하세요.
읽을거리 · 도구
- 모델 제공사(Anthropic·OpenAI 등)의 공식 프롬프트 가이드 문서 — 4요소·퓨샷·구조화 출력 등 기법을 제공사 관점에서 최신·정확하게 확인하기 위해. 특정 모델의 시스템/사용자 프롬프트 처리 방식은 제공사 문서가 1차 근거다. (기법의 '이름'보다 '왜 그렇게 동작하는지'를 읽고, 버전이 바뀌면 문서도 갱신됨을 전제로 최신판을 볼 것.)
- Chain-of-Thought(사고사슬) 관련 원 연구의 요지 — 중간 추론을 펼치게 하면 다단계 과업 정확도가 오른다는 아이디어의 근거와 한계를 이해하기 위해. 만능이 아니라 '적합한 과업'이 있음을 아는 게 핵심. (수치·논문명을 외우기보다 '어떤 과업에서 효과가 크고 어디서 효과가 없는지'의 직관을 얻는 데 초점.)
- 평가주도개발(eval-driven) 관점의 프롬프트 개선 사례 글 — 프롬프트를 '느낌'이 아니라 데이터로 개선하는 습관을 들이기 위해. 5세션의 A/B 비교와 자연스럽게 연결되고, 이후 평가·메타 계층으로 가는 다리가 된다. (거창한 프레임워크보다 '작은 정답 셋을 두고 두 프롬프트를 비교'하는 최소 실천부터 흉내 낼 것.)