비슷한 명령을 여러 줄 붙여 넣는 작업은 루프로 바꾸고 싶어진다. 주제와 대상 독자가 다른 12개 항목을 순서대로 처리한다면, 공통 지시는 한 번만 쓰고 목록만 바꾸면 될 것 같다. 여기까지는 간단하다. 여덟 번째 항목에서 멈춘 뒤 다시 시작할 때 앞의 일곱 개를 건드리지 않는 방법은 조금 더 생각해야 한다.
이 글은 GPT-5.6 가이드를 읽고 만든 배치 프롬프트 설계안이다. 실제 12개 작업을 끝내고 시간 절감이나 성공률을 측정한 보고가 아니다. 초안 생성과 검사를 연결하되, 공개 발행은 예시의 권한 범위에서 제외했다. 블로그 글 외에도 자료 검토나 파일 변환 같은 반복 작업에 적용할 수 있도록 입력, 상태와 복구를 구분했다.
짧게 쓸 지시와 반드시 남길 제약
OpenAI의 GPT-5.6 안내는 중복 지시와 예시를 정리하되 필요한 요구사항과 승인 경계를 유지하라고 설명한다. 작동하는 구성을 기준으로 지시 묶음을 하나씩 줄이고 같은 평가를 다시 수행하는 방식이다. 내부 평가의 개선 수치를 내 작업의 보장된 성과로 옮겨 적을 수는 없다. GPT-5.6 모델 가이드
모델 이름도 기록해 두는 편이 낫다. 문서에서 gpt-5.6 별칭은 gpt-5.6-sol로 연결된다. 다만 앱의 표시 이름, API 모델 식별자와 실제 사용할 수 있는 설정은 혼동하지 않아야 한다. 시험 기록에는 모델, 도구 버전, 추론 설정과 작업 시각을 남긴다. 가이드의 API 설정이 모든 Codex 화면에 똑같이 노출된다고 가정하지 않는다. GPT-5.6 Sol 모델 문서
줄일 대상은 ‘정확하게 해’, ‘끝까지 해’, ‘빠뜨리지 마’ 같은 반복 문장이다. 반면 출력 경로, 원본 보존, 확인되지 않은 사실 처리, 외부 발행 금지는 남겨야 한다. 이들은 표현을 꾸미는 지시가 아니라 결과의 합격 조건이다. 간결하게 쓰라는 말 때문에 필요한 설명이나 글의 실질 분량까지 줄여서는 안 된다.
작업별 입력과 공통 규칙도 분리한다. 목록에는 식별자, 주제, 독자, 입력 자료만 둔다. 공통 절차에는 읽기, 작성, 검사와 보고를 적는다. 이렇게 나눠야 주제 하나를 바꾸다가 전체 작업의 안전 조건을 실수로 바꾸는 일을 줄일 수 있다.
열두 줄 명령을 상태가 있는 작업 목록으로 바꾼다
예를 들어 네 가지 주제와 세 독자 수준의 조합을 시험한다고 하자. 12개는 이 설계의 예시 수량이지 글을 많이 찍어내야 한다는 권장은 아니다. 같은 주제를 독자 수준만 바꿔 얕게 반복할 위험도 있으므로, 실제 발행 후보라면 각 항목이 해결할 질문부터 달라야 한다.
각 항목에는 task_id를 부여한다. 순번만 식별자로 쓰면 중간에 항목을 끼웠을 때 기존 결과와 연결이 어긋날 수 있다. 입력의 버전을 함께 기록하고, 같은 식별자라도 자료가 바뀌면 재검토가 필요한 상태로 표시한다. 완료 목록과 현재 입력을 비교할 수 있어야 한다.
상태는 아래처럼 나눌 수 있다. 이것은 설명용 스키마이며 특정 도구에 내장된 상태 이름이 아니다.
| 상태 | 의미 | 다음 행동 |
|---|---|---|
| queued | 아직 시작하지 않음 | 승인된 입력을 확인 |
| drafting | 초안 생성 중 | 결과 파일 저장 후 검사 |
| checking | 파일은 있으나 검사를 끝내지 않음 | 검사 결과와 누락 항목 기록 |
| complete | 필요한 검사와 결과 확인을 완료함 | 동일 입력이면 다시 생성하지 않음 |
| blocked | 출처·권한·입력 문제로 진행 불가 | 이유를 보고하고 독립 작업만 계속 |
complete는 모델이 완료라고 말했는지가 아니라 결과 파일과 검사 기록이 존재하는지로 결정한다. 예시에서는 본문, 요약, 참고자료, 검사 로그를 확인해야 한다. 파일이 있다는 것만으로 통과시키면 절반만 저장된 원고가 완성본이 될 수 있다. 반대로 초안은 좋은데 외부 링크 확인만 일시적으로 실패했다면 처음부터 새로 쓸 필요 없이 검사 단계부터 재개할 수 있다.
반복 실행을 위한 프롬프트 예시
다음은 실제로 실행하지 않은 설계 예시다. 경로와 검사 명령은 독자의 프로젝트에서 확인한 것으로 채워야 한다. 존재하지 않는 스킬 이름을 프롬프트에 적고 설치돼 있다고 가정해서는 안 된다.
목표: 승인된 작업 목록의 각 항목을 작성하고 검사한 뒤 결과표를 남긴다.
입력: 작업 목록, 원본 자료, 현재 프로젝트의 글 작성 지침.
범위:
- 지정한 입력 자료를 읽고 지정한 출력 폴더 안에서 초안을 작성한다.
- 원본 자료와 이미 검증된 결과는 보존한다.
- 외부 발행, 메시지 전송, 결제, 저장소 권한 변경은 하지 않는다.
- 기존 파일을 수정하도록 승인된 항목은 백업과 변경 내역을 남긴다.
진행:
1. 목록의 식별자 중복과 입력 누락을 확인한다.
2. 결과 기록을 읽고 동일 입력으로 검증 완료한 항목은 건너뛴다.
3. 각 항목의 초안을 만들고 프로젝트의 실제 검사 절차를 실행한다.
4. 실패하면 원인을 분류하고 해당 단계만 제한적으로 다시 수행한다.
5. 출처나 권한이 필요하면 blocked로 기록한다. 독립 항목은 계속한다.
6. 항목마다 상태, 결과 경로, 검사 증거와 미해결 이유를 기록한다.
7. 마지막에 완료·보류·실패 수와 다음 행동을 보고한다.
규칙이 길어지면 본문을 반복 복사하기보다 프로젝트 지침을 참조하게 할 수 있다. 다만 참조하라고만 쓰고 읽었는지 확인하지 않으면 효과가 없다. 실행 초기에 적용할 지침 파일과 작업 목록 버전을 기록하도록 설계한다. 프롬프트에는 이번 작업에서 달라지는 범위만 남긴다.
검사도 ‘알아서 검수’라고 쓰는 대신 실제 확인 항목을 알려준다. 제목과 본문이 같은 질문을 다루는지, 출처가 주장을 뒷받침하는지, 개인 경험이 근거 없이 추가됐는지 등을 본다. 기계적으로 확인할 필드와 사람이 읽어야 할 내용을 나누면 어디까지 자동 통과했는지 설명하기 쉽다.
재시도는 횟수보다 실패 종류를 먼저 본다
모든 실패에 두 번 더 시도하라는 지시는 간단하지만 비용을 낭비할 수 있다. 네트워크의 일시적 응답 오류와 권한 거부는 같은 문제가 아니다. 공개 문서를 잠시 못 읽은 경우에는 제한된 재시도가 가능하다. 로그인이나 새로운 권한이 필요하면 동일 요청을 반복하지 않고 멈춘다.
본문 형식이 틀렸다면 생성 전체를 다시 하기보다 누락된 필드를 고친다. 참고자료의 제목과 URL이 맞지 않으면 해당 출처부터 확인한다. 주장을 뒷받침할 자료가 없으면 그 주장을 삭제하거나 확인할 질문으로 보류해야 한다. 표현만 바꿔 같은 주장을 유지하는 것은 복구가 아니다.
예시 운영 기준으로 같은 일시 오류에 추가 시도 두 번을 허용할 수 있다. 이 수치는 공급자의 필수 규칙이 아니라 내부 한도다. 요청 비용과 시간 제한도 함께 두고, 계속 실패하면 오류 종류와 마지막 시각을 기록한다. 실패를 숨기기 위해 검사 기준을 낮추는 행동은 허용하지 않는다.
다른 항목을 계속해도 되는지는 의존성으로 판단한다. 여러 원고가 같은 접근 불가 자료를 필요로 한다면 공통 원인을 먼저 해결해야 한다. 서로 다른 공개 자료를 쓰는 독립 원고라면 보류 항목을 기록한 채 나머지를 처리할 수 있다. ‘중단하지 말라’는 표현이 이 구분을 대신하지 못한다.
중간 종료 뒤에는 완료 보고가 아니라 파일 상태를 읽는다
일곱 번째 항목의 초안 저장 직후 프로그램이 종료됐다고 가정해 보자. 결과표에는 drafting이 남아 있지만 파일은 있을 수 있다. 재개 시 무조건 새 파일을 만들면 중복이 생긴다. 먼저 작업 식별자와 파일의 입력 버전을 확인하고, 저장 상태가 온전하면 검사 단계로 이동하도록 설계한다.
원본 또는 검증된 결과가 바뀌었는지도 확인한다. 파일 해시를 기록하면 동일 파일 여부를 비교할 수 있지만 해시가 내용의 품질을 보증하지는 않는다. 검수 이후 내용이 바뀌었을 때 검사를 다시 해야 한다는 신호로 쓰는 것이다. 날짜만 비교하면 사람이 수정한 파일을 놓칠 수 있다.
병렬 실행을 넣을 때는 기록 파일 충돌도 생긴다. 각 작업이 같은 결과표 전체를 덮어쓰게 하지 않고, 항목별 결과를 모아 최종 집계하는 방법을 고려할 수 있다. 공유 파일 갱신을 직렬화하는 방법도 있다. 구현 방식은 달라도 완료 상태가 실제 결과보다 먼저 기록되지 않아야 한다는 조건은 같다.
시험은 처음부터 모든 항목에 걸 필요가 없다. 정상 입력, 출처 누락, 중단 후 재개를 대표하는 소수 항목으로 시작하겠다. 확인할 것은 생성 속도보다 중복이 생기는지, 원본이 보존되는지, 실패 이유가 남는지다. 이 조건이 맞아야 전체 목록으로 확대할 수 있다.
반복해서 사용할 절차가 안정되면 스킬로 옮길 이유가 생긴다. 한 번의 프롬프트를 짧게 만드는 목적과 여러 작업에서 같은 기준을 유지하는 목적은 다르다. 스킬에는 검증된 절차와 실패 처리를 넣고, 실행할 때에는 이번 목록과 권한 범위를 전달하면 된다. 아직 측정하지 않은 자동화 효과는 이 시험 기록이 쌓인 뒤에 이야기하겠다.
참고자료
- OpenAI — Model guidance, Using GPT-5.6: 간결한 지시, 승인 경계와 작업별 평가에 대한 기준.
- OpenAI — GPT-5.6 Sol: 모델 식별자와 지원 설정 확인.
- OpenAI — Build skills: 반복 절차를 스킬로 정리할 때 참고할 공식 안내.