Quick Flow
긴 작업은 계획 자체가 아니라 무엇을 끝냈는지 확인할 증거까지 요청해야 관리할 수 있습니다. 목표가 모호하거나 결과물이 여러 개인 작업에서만 계획을 먼저 받고, 짧은 요약·문장 교정처럼 즉시 답할 수 있는 요청은 바로 실행하게 합니다.
목표: [완성할 산출물]
범위: [포함할 것] / 제외: [이번에 하지 않을 것]
완료 조건: [사람이 확인할 수 있는 결과 2~4개]
시작 전에 목표를 한 문장으로 재진술하고 3단계 계획을 제시해줘.
각 단계 뒤에는 다음만 보고해줘.
- 완료: 실제로 끝난 산출물과 확인 방법
- 진행 중: 다음 행동과 막힌 이유
- 보류: 확인할 수 없거나 내 결정이 필요한 항목
계획과 실제 결과가 다르면 이유와 수정한 계획을 함께 적어줘.| 작업 규모 | 먼저 받을 것 | 진행 보고를 넣는 시점 |
|---|---|---|
| 짧은 답변·형식 변환 | 결과물 | 보통 넣지 않음 |
| 조사·문서 초안 | 범위와 2~3단계 계획 | 자료 확인 또는 초안 뒤 |
| 여러 파일·외부 도구 작업 | 선행 조건, 단계, 완료 증거 | 의존 단계가 끝날 때마다 |
계획을 작업 계약으로 만들기
계획을 세워 줘만으로는 항목이 빠졌는지 판단하기 어렵습니다. 목표, 범위, 제외 범위, 완료 조건을 함께 적으면 계획은 단순한 목차가 아니라 작업 계약이 됩니다. 완료 조건은 좋은 결과처럼 추상적으로 쓰지 말고 요구사항 표 8개가 채워짐, 링크가 실제로 열림, 수정 파일과 검증 결과를 제시함처럼 확인 가능하게 적습니다.
목표: 지원자 안내 문서를 개정한다.
포함: 신청 자격, 일정, 제출물, 문의 경로
제외: 디자인 변경과 영문 번역
완료 조건:
1. 네 항목이 모두 본문에 있다.
2. 날짜와 링크는 제공한 원본과 일치한다.
3. 변경 요약과 확인이 필요한 항목이 분리되어 있다.
작업 전에는 위 조건을 충족하는 3단계 계획만 제시해줘.계획은 요청 해석을 점검하는 도구이지, 실제 실행 기록이 아닙니다. 특히 파일 수정, 검색, 발송처럼 바깥 상태가 바뀌는 작업은 하겠다 또는 완료했다라는 문장만으로 끝내지 말고 파일 경로, 검색 결과, 화면 상태처럼 확인 가능한 결과를 받아야 합니다.
진행 보고를 읽는 법
진행 보고는 긴 응답을 늘리는 장식이 아니라 다음 선택을 빠르게 하기 위한 상태표입니다. 한 단계가 끝났다고 할 때는 산출물과 확인 방법을 같이 적게 하고, 보류 항목은 숨기지 않게 합니다.
| 상태 | 보고에 있어야 할 내용 | 다음 행동 |
|---|---|---|
| 완료 | 끝난 결과와 확인 근거 | 다음 의존 단계로 진행 |
| 진행 중 | 남은 일, 현재 막힌 조건 | 범위·권한·입력을 보완 |
| 보류 | 알 수 없는 사실 또는 사용자 결정 | 필요한 질문을 최소화 |
| 실패 | 시도한 방법과 실패 원인 | 대안 방법 또는 범위 축소 선택 |
각 단계가 끝나면 "완료"라고만 쓰지 말고,
완료한 산출물, 확인한 근거, 남은 불확실성을 한 줄씩 적어줘.
근거를 확인할 수 없으면 완료가 아니라 보류로 표시해줘.초안 작성처럼 본질적으로 주관적인 작업은 사람이 최종 승인자입니다. ChatGPT의 자체 상태 보고는 검토 순서를 알려 주는 색인으로 쓰고, 계약·배포·코드 반영처럼 되돌리기 어려운 결과는 원본과 실제 상태를 따로 확인합니다.
계획을 바꿔야 할 때
새 요구가 들어오거나 선행 자료가 비어 있으면 처음 계획을 고집하는 편이 더 위험합니다. 변경된 목표, 영향을 받는 단계, 이전 완료 조건 중 더 이상 성립하지 않는 항목을 짧게 드러낸 뒤에만 계획을 갱신합니다. 이때 이미 끝난 결과를 다시 만들 필요가 없다면 유지 항목으로 명시합니다.
모든 요청에 계획과 상태 보고를 붙이면 실제 결과보다 진행 문장이 길어집니다. 한 번의 답으로 검토할 수 있는 요청은 결과 형식과 분량만 정하고 바로 받으세요. 계획이 필요한 작업에서도 진행 보고는 확인 지점에만 두는 편이 좋습니다.
참고 링크
1 sources