PK-PDCA 브릿지
글자 크기
색
PK-PDCA BRIDGE · AI 활용 가이드

프롬프트 방법론의 흐름
프롬프트 엔지니어링에서 그래프까지, 다섯 가지 방법

"프롬프트만 잘 쓰면 된다"에서 시작해 컨텍스트 설계, 점검 절차(하네스), 반복 루프(에이전트), 단계 그래프(워크플로)로 방법이 차례로 넓어졌습니다. 뒤의 방법은 앞의 방법을 버리지 않고 품습니다. 이 가이드는 다섯 방법의 뜻·관계·언제 필요한지를 정리하고, 방법마다 중괄호 만 바꿔 쓰는 프롬프트를 드립니다.

이 가이드의 한 줄

뒤의 방법은 앞의 방법을 품는다
문제가 커질 때만 다음 방법으로 넓힌다

※ 용어와 도구 이름은 2026-09 기준입니다. "컨텍스트 엔지니어링"과 "하네스"는 2025년 이후 널리 쓰이기 시작한 말이고 도구마다 메뉴 이름이 다릅니다. 이 가이드는 도구 중립으로 원리만 다룹니다.

1. 다섯 방법 한눈표

방법정의(한 줄)핵심 질문손에 쥐는 것PK-PDCA 대응
① 프롬프트 엔지니어링한 번의 요청문을 잘 쓰는 기술무엇을, 누구에게, 어떤 형식으로R+RTCFE 6칸 프롬프트P 계획
② 컨텍스트 엔지니어링AI가 볼 자료·지침·기억·도구를 설계하는 일매번 붙이지 않아도 되게 무엇을 고정할까지침, 프로젝트·지식 파일, 참조 자료 묶음K 지식 · A 자산화
③ 하네스AI 작업을 감싸는 점검·제한·중단 절차틀렸을 때 어떻게 걸러내고 멈출까점검표, 금지 규칙, 자기 검증 절차, 스킬C 검증
④ 루프(에이전트)계획→실행→검증→수정을 스스로 반복하는 방식몇 바퀴 돌고 언제 멈출까목표·성공 기준·바퀴 수 상한이 있는 실행문D 실행 (PDCA 한 바퀴)
⑤ 그래프(워크플로)여러 단계를 분기·병렬·복귀로 잇는 설계어떤 순서로, 어디서 갈라지고, 어디로 돌아갈까단계 표(입력·출력·끝의 표시), 복귀 조건코스·강의 설계 전체

2. 방법별 설명 — 뜻과 언제 필요한가

① 프롬프트 엔지니어링 (Prompt Engineering)

한 번의 요청을 참조·역할·지시·맥락·형식·예시/예외로 채운다
언제
거의 모든 일의 시작. 소상공인·시니어 실무는 프롬프트만으로 대부분 끝납니다.
한계
같은 배경을 매번 붙이게 되고, 결과 검증은 사람이 다 해야 합니다.

② 컨텍스트 엔지니어링 (Context Engineering)

AI가 읽는 창(맥락) 안에 무엇을 넣고 뺄지 설계한다
언제
같은 일을 주 2회 이상 반복할 때. 지침(맞춤 설정), 프로젝트·지식 파일, 참조 자료 묶음이 도구입니다.
한계
자료가 많아지면 AI가 중요한 것을 놓칩니다. "적게, 정확하게"가 원칙입니다.

③ 하네스 (Harness)

AI 작업을 감싸는 틀 — 점검표, 금지 규칙, 멈춤 조건
언제
틀리면 비용이 큰 일(가격·법규·의료·공문). 스킬·체크리스트·자기 검증 절차가 하네스입니다.
한계
절차가 길면 AI가 절차 자체를 요약해 버립니다. 항목 5개 이내로.

④ 루프 (Loop) · 에이전트 (Agent)

계획 → 실행 → 검증 → 수정을 스스로 반복한다
언제
한 번의 답으로 끝나지 않는 일(초안→검토→수정, 조사→정리→보고). 바퀴 수 상한과 멈춤 조건이 없으면 쓰지 않습니다.
한계
바퀴마다 비용이 들고, 잘못된 기준으로 돌면 틀린 답이 정교해집니다.

⑤ 그래프 (Graph) · 워크플로 (Workflow)

여러 단계를 분기·병렬·복귀로 잇는 설계도
언제
팀 업무, 코스 설계, 문서 한 벌(계획서·워크북·슬라이드)처럼 단계가 여럿이고 서로 검증해야 할 때.
한계
설계 비용이 큽니다. 한 사람의 반복 업무에는 과합니다.

공통 원칙

앞의 방법이 튼튼해야 뒤의 방법이 선다
뜻
그래프를 그려도 각 단계 안은 결국 프롬프트입니다. 문제 정의(P)가 흐리면 다섯 방법 어디서도 결과가 나오지 않습니다.

3. 방법 사이의 관계 — 포함 관계로 읽는다

관계설명
컨텍스트 ⊃ 프롬프트컨텍스트는 프롬프트가 읽을 재료입니다. 좋은 지침이 있어도 요청문(프롬프트)이 흐리면 소용없습니다.
하네스 ⊃ 프롬프트·컨텍스트하네스는 프롬프트와 컨텍스트를 감쌉니다. "무엇을 하라"(프롬프트)와 "무엇을 알고 하라"(컨텍스트)에 "어떻게 걸러라"(하네스)를 더합니다.
루프 ⊃ 하네스루프의 한 바퀴 안에 하네스가 들어 있어야 합니다. 검증 없는 루프는 틀린 답을 반복해 다듬습니다.
그래프 ⊃ 루프그래프의 각 단계가 루프일 수 있습니다. 단계 사이의 순서·분기·복귀만 그래프가 맡습니다.
다음 방법으로 넓히는 기준

같은 배경을 세 번 이상 붙였다 → 컨텍스트. 결과가 틀려 손해가 난 적이 있다 → 하네스. 한 번의 답으로 끝난 적이 없다 → 루프. 단계가 넷 이상이고 서로 검증해야 한다 → 그래프.

거꾸로, 넓은 방법을 쓰는데 결과가 나쁘면 앞의 방법(특히 문제 정의와 프롬프트 요청문)부터 다시 봅니다.

4. 우리 플랫폼에서 지금 쓰고 있는 것

  1. ① 프롬프트 — R+RTCFE 6칸과 프롬프트 3단.
    세션 앱의 기본·전문·인터뷰형 프롬프트, 업무 지시서 173종, 메타 프롬프트 도우미.
  2. ② 컨텍스트 — 지침·프로젝트·지식 파일·스킬.
    가이드 「클로드 AI 활용법」의 지침·프로젝트·스킬 절, 「AI 자산화 방법」의 그릇 5종. 문제 정의 5번 문항(가진 것)이 컨텍스트의 입력입니다.
  3. ③ 하네스 — 판별 단계와 안전 문구.
    세션 앱 검증 단계의 판정표, 전문 프롬프트에 자동으로 붙는 안전 문구(불확실성·질문 우선·출처·과장 금지), 문서 생성 스킬의 자가 점검표.
  4. ④ 루프 — 세션 7단계.
    시작 → 문제 정의 → 확인 → 지식 → 프롬프트 → 검증 → 자산이 PDCA 한 바퀴입니다. 검증에서 걸리면 프롬프트로 돌아갑니다.
  5. ⑤ 그래프 — 코스와 문서 한 벌.
    예술창업 코스의 파트 분기(3트랙), 강의계획서·워크북·슬라이드를 한 번에 만들고 서로 대조하는 내보내기 절차.

※ 기준 2026-09. 도구별 메뉴 이름(맞춤 설정·Gem·프로젝트·스킬·커넥터)은 바뀌므로 가이드 「AI 자산화 방법」의 기준 시점 표를 함께 봅니다.

5. 판정 퀴즈 — 어느 방법이 필요한가

6. 방법별 프롬프트 5종 — 안만 바꿔 쓴다

모두 도구 중립입니다. 컨텍스트는 지침·프로젝트 설정칸에, 나머지는 대화창에 붙여 넣습니다.

가. 프롬프트 (Prompt) — R+RTCFE 6칸

[R·참조] 아래 자료를 근거로만 답하세요: {자료를 붙여 넣기 또는 "없음"}
[R·역할] 당신은 {업종}의 {직무} 10년차 실무자입니다.
[T·지시] {만들 것}을 {개수}개 만들어 주세요.
[C·맥락] 대상은 {누구}, 상황은 {언제·어디서}, 목적은 {무엇을 위해}.
[F·형식] {형식: 예 — 제목 1줄 + 본문 3문장 + 해시태그 5개}, 존댓말, {글자 수} 이내.
[E·예시/예외] 좋은 예: {한 줄}. 하지 말 것: 과장, 없는 사실, {금지 항목}.
모르는 사실은 "확인 필요"라고 적고, 시작 전에 궁금한 점이 있으면 먼저 물어보세요.

나. 컨텍스트 (Context) — 지침·프로젝트 설정

이 대화(또는 프로젝트)의 고정 맥락입니다. 앞으로 모든 답에 적용하세요.

■ 나: {이름 또는 역할}, {업종}, 고객은 {누구}.
■ 말투: {존댓말 / 간결 / 따뜻함}, 금지 표현: {예: 최고, 무조건, 100%}.
■ 참고 자료(아래 붙임): {메뉴판 / 제품 규격 / 지난 글 3개 / 브랜드 소개}
■ 자주 하는 일: {1. 게시글 2. 답변 문자 3. 행사 안내}
■ 항상 지킬 규칙: 없는 사실 금지, 가격·일정은 내가 준 것만, 개인정보 쓰지 않기.
■ 결과 형식 기본값: {형식}.

지금은 설정만 확인하고, "준비됐습니다. 어떤 일을 할까요?"라고만 답하세요.

다. 하네스 (Harness) — 점검 절차

아래 작업을 할 때 반드시 이 점검 절차(하네스)를 거치세요.

작업: {예: 신제품 소개글 작성}
1) 시작 전: 필요한 정보가 빠졌으면 작업하지 말고 질문 목록을 먼저 보여준다.
2) 작업 중: 근거가 없는 숫자·이름·날짜는 쓰지 않고 [확인 필요]로 표시한다.
3) 끝난 뒤 자기 점검표를 채운다:
   - 사실 확인: 붙임 자료와 어긋난 곳 { }
   - 과장·허위 표현 { }
   - 개인정보·저작권 위험 { }
   - 대상 눈높이(어려운 말) { }
   - 형식·글자 수 준수 { }
4) 점검표에 하나라도 ✕가 있으면 고친 뒤 다시 점검한다(최대 2회).
5) 최종 답 맨 아래에 "점검 완료 / 남은 위험: { }"를 적는다.

라. 루프 (Loop) — 바퀴 수 상한

목표: {예: 이번 주 블로그 글 1편을 발행 가능한 상태로 만들기}
성공 기준: {예: 1,200자 이내, 제목에 지역명, 출처 2개 이상, 과장 없음}
가진 자료: {붙임}
제약: {시간 / 도구 / 금지 사항}

다음 루프를 따르세요. 한 바퀴마다 결과를 보여주고 내 확인을 기다리세요.
계획 → 실행 → 자기 검증(성공 기준 대조) → 부족한 점 목록 → 다시 계획.
최대 3바퀴. 3바퀴 뒤에도 기준을 못 채우면 무엇이 막혔는지와 나에게 필요한 결정을 정리해서 멈추세요.

마. 그래프 (Graph) — 단계 설계

다음 작업을 단계 그래프로 설계하고, 각 단계의 입력·출력·판단 기준을 표로 만든 뒤 실행하세요.

작업: {예: 기관 강의 제안서 한 벌 만들기}
단계 후보: [A 요청서 분석] → [B 커리큘럼 초안] → [C 강의계획서] ┬→ [D 워크북 목차]
                                                        └→ [E 슬라이드 목차]
→ [F 교차 검증: C·D·E가 서로 맞는가] → 통과 시 [G 최종 묶음], 실패 시 [B]로 복귀.

규칙:
- 단계마다 "이 단계가 끝난 표시"를 한 줄로 정의한다.
- 병렬 단계(D·E)는 같은 입력을 쓰고 서로 참조하지 않는다.
- 되돌아가는 조건(F 실패)을 미리 정한다. 되돌아가기는 최대 2회.
- 각 단계 결과를 {단계 이름} 제목 아래에 저장하고, 마지막에 전체 표를 다시 보여준다.

인쇄 버튼이 동작하지 않는 환경에서는 「새 창에서 열기」 후 Ctrl+P(휴대폰: 공유→인쇄)를 누르면 PDF로 저장됩니다.