Quick Flow
반복 수정은 "더 좋게 고쳐 줘"가 아니라 기준 초안과 변경 계약을 비교하는 작업입니다. 매 turn에 유지·변경·삭제할 범위, 새 제약, 확인할 결과를 함께 적으면 대화의 앞선 합의를 다시 해석하는 일을 줄일 수 있습니다. ChatGPT의 대화 맥락은 version control이 아니므로 중요한 상태는 별도 문서와 diff로 보관합니다.
baseline 초안
-> 유지 / 변경 / 삭제를 분리
-> 변경 뒤 통과 조건을 지정
-> 수정본 + 변경 요약 + 미확인 항목을 받음
-> 원본과 diff·근거를 사람이 확인| 수정 목적 | 반드시 적을 것 | 완료 확인 |
|---|---|---|
| 문체만 변경 | 유지할 사실·수치·구조 | 사실과 section이 바뀌지 않았는지 |
| 일부 요구 추가 | 바뀌는 section과 우선순위 | 기존 요구와 충돌하지 않는지 |
| 오류 수정 | 근거 source와 수정 대상 | claim·수치·날짜가 원문과 맞는지 |
| 대형 재작성 | baseline version과 제외 범위 | 삭제·이동·새 내용의 이유가 남는지 |
변경 계약
수정 요청에는 원본을 판단 기준으로 고정하고, 무엇을 바꾸지 않을지를 먼저 씁니다. "간결하게"처럼 모호한 방향어만 주면 content 삭제, tone 변경, 구조 변경이 함께 일어날 수 있습니다. 유지해야 하는 사실·API name·수치·인용, 바꿔도 되는 표현·순서·길이를 구분합니다.
기준 초안: v3의 <draft> 전체
유지: API 이름, 가격 수치, 인용 source, H2 수
변경: 도입을 2문장으로 줄이고 반복 설명을 합친다
삭제: 출시 전 roadmap 언급
통과 조건: 700자 이하, claim마다 source 유지, 변경 목록 반환
확인 불가: source가 없는 새 claim은 추가하지 않는다대화에서 "앞의 버전을 기준으로"라고 해도 사용자가 보는 문서의 실제 file version, 협업자가 만든 변경, source의 최신 상태를 자동으로 비교하지는 않습니다. 파일·URL·정책처럼 최신성이 중요한 input은 해당 turn에 다시 제공하고, 기준 날짜와 revision을 적습니다.
검증과 되돌리기
| 결과 | 먼저 볼 것 | 다음 행동 |
|---|---|---|
| 기존 사실이 사라짐 | 유지 목록과 변경본 diff | 삭제 이유를 확인하고 해당 section만 복원 |
| 새 claim이 생김 | source·날짜·citation | 근거가 없으면 제거 또는 미확인 표시 |
| 형식이 무너짐 | output contract | section·길이·schema를 명시해 재수정 |
| 변경 범위가 너무 큼 | baseline과 변경 요약 | 파일·section 단위로 요청을 좁힘 |
| 이전 합의와 충돌 | 우선순위와 최신 요구 | 충돌 항목을 표면화하고 사람에게 선택 요청 |
수정본만 받지 말고 변경한 항목, 의도적으로 유지한 항목, 근거가 부족해 보류한 항목을 함께 받습니다. 이것은 ChatGPT의 self-report를 신뢰하기 위한 장치가 아니라 사람이 원본 대조를 빠르게 시작할 수 있게 하는 index입니다.
자주 틀리는 부분
긴 대화에서 이전 지시가 남아 있다는 사실을 문서의 정확한 revision 보장으로 해석하면 안 됩니다. 배포·계약·코드처럼 되돌리기가 중요한 산출물은 source file, Git diff, 승인 기록을 기준으로 관리합니다.
참고 링크
1 sources