OpenAI는 8월 6일, ChatGPT의 GPT-5.6 Sol을 업데이트하고, Free 사용자에게는 GPT-5.6 Luna를 기본값으로 설정한다고 발표했습니다. Sol은 채팅 내의 응답을 더욱 정확하고 일관되게 만드는 업데이트로, Free 측도 Think 버튼을 포함한 제공 범위가 변경됩니다. 자세한 내용은 공식 발표에 나와 있습니다.

이것이 의미하는 바는, 지난주 ChatGPT로 만든 제안서 초안을 조건을 남기지 않고 이번 주 기획서에 그대로 붙여넣는 작업이 설명 부족 상태가 된다는 것입니다.

저는 영업 자료의 초안 작성에 ChatGPT를 사용합니다. 다만, 출력이 이전보다 좋아졌는지를 단순히 "읽기 편해졌다" 정도로 넘기는 것은 성급한 일입니다. 모델(Model), 사고 방식, 프롬프트(Prompt) 버전, 추출한 일시. 이 4가지가 빠지면, 동일한 안건명의 텍스트가 2개 있더라도 왜 내용이 바뀌었는지 추적할 수 없습니다.

그래서 답변 본문은 텍스트 파일로 보관하고, CSV에는 조건만 한 줄씩 남기도록 하고 있습니다. 이 기사의 Python 코드는 그 이력을 시계열로 나열하여, 본문이 바뀐 행만 diff(차이점)로 출력합니다. ChatGPT를 자동 조작하는 것이 아닙니다. 재사용 전 확인을 빠르게 하기 위한 대장(Ledger)입니다.

모델 업데이트를 환영하면서도, 업무 초안 작성에서는 별개의 문제가 있습니다. 정밀도가 올라가더라도 동일한 답변이 돌아온다는 보장은 없습니다. 상담 제안문에서 바뀐 한 문장이 가격 조건인지, 경쟁사 이름인지, 단순한 말투인지. 그 부분을 보지 않고 재사용하면 리뷰하는 사람만 곤란해집니다.

남길 열(Column)은 6개면 충분합니다.

model과 mode는 답변을 가져온 화면에 보이는 표기 그대로 입력합니다. ChatGPT 화면상의 표시를 가져올 수 없다면, 빈칸인 채로 저장하지 않는 것이 좋습니다. 나중에 "아마 같은 조건이었을 거야"라는 말은 거의 도움이 되지 않습니다.

CSV는 answer_log.csv, 본문은 같은 폴더의 answers에 둡니다. 처음에는 이런 형태입니다.

job,captured_at,model,mode,prompt_version,output_file
商談提案,2026-08-06T16:20:00+09:00,GPT-5.6 Sol,quick,proposal-v3,answers/proposal_0806.txt
商談提案,2026-08-07T09:15:00+09:00,GPT-5.6 Sol,quick,proposal-v3,answers/proposal_0807.txt
...

프롬프트 본문을 CSV에 통째로 넣지 않는 이유는 표를 읽기 어렵게 만들기 때문입니다. proposal-v3.md와 같이 별도 파일로 버전을 관리하고, CSV에는 버전 이름만 기록합니다. 변경하면 v4로 올립니다. 번거로워 보이지만, 나중에 차이점을 읽는 시간보다 짧습니다.

이 CSV는 답변의 우열을 채점하는 표가 아닙니다. 동일한 job이라도 고객으로부터 추가로 들은 조건이나 참조한 자료가 바뀌면 답변이 바뀌는 것은 당연합니다. 그 변경사항까지 동일한 프롬프트 버전에 억지로 밀어 넣으면, 차이점을 보는 사람이 원인을 오해하게 됩니다. 입력한 자료나 조건을 바꾼 날은 proposal-v4와 같이 버전을 올립니다. 모델을 바꿨을 때만 기록하는 표로 만들지 않는 것이 중요합니다.

반대로, 정기적인 회의록 요약처럼 매주 거의 동일한 지시로 수행하는 업무에는 궁합이 좋습니다. 지난주보다 고유명사가 줄었다, 담당자가 바뀌었다, 기한이 사라졌다. 그 변화를 제출 직전이 아니라 저장한 시점에 포착할 수 있습니다. 사용하는 사람이 눈으로 최종 확인한다는 전제는 변하지 않습니다. 확인할 장소를 미리 제시할 수 있을 뿐입니다.

현재로서는 이것만으로 운영되고 있습니다.

이하를 chat_answer_audit.py로 저장합니다. 외부 라이브러리는 사용하지 않습니다. 절대 경로 나 ..를 포함한 저장 위치를 차단하므로, CSV를 다른 안건으로 복사했을 때 관계없는 답변을 읽어버리는 사고도 방지할 수 있습니다.

import csv
import hashlib
import sys
...

실행은 다음의 한 줄입니다.

python chat_answer_audit.py answer_log.csv

오늘 아침, 위의 구성으로 준비한 3건의 테스트 로그를 실행했습니다. 상담 제안 중 2번째 건만 모델, 모드, 프롬프트 버전은 동일하지만 본문에 차분이 있습니다.

job,captured_at,model,mode,prompt_version,sha256,判定
商談提案,2026-08-06T16:20:00+09:00,GPT-5.6 Sol,quick,proposal-v3,12522103fc84,初回
商談提案,2026-08-07T09:15:00+09:00,GPT-5.6 Sol,quick,proposal-v3,c0e86e101e03,同条件で差分あり
...

여기서 알 수 있는 것은 "답변의 질이 떨어졌다"가 아닙니다. 후보 회사가 1개사에서 2개사로 늘어났으므로, 제안서에 붙이기 전에 근거를 재검토할 필요가 있다는 점 하나뿐입니다. diff(차분)가 나오면 실패인 것이 아닙니다. 확인해야 할 답변을 좁힐 수 있다면 성공입니다.

처음에는 답변 본문을 CSV의 셀에 붙여넣었습니다. 줄바꿈이 많은 답변을 여는 순간, 스프레드시트의 행 높이가 무너져 차분을 확인하기는커녕 엉망이 되었습니다. 본문을 .txt로 분리하니, CSV는 조건 목록으로서 읽을 수 있게 되었습니다. 이 부분이 은근히 효과적입니다.

同条件で差分あり (동일 조건에서 차분 있음)

은 답변이 나쁘다는 표시가 아닙니다. ChatGPT의 출력에는 흔들림(fluctuation)이 있습니다. 답변의 비교 대상으로 남겨두어야 할 것은 고유명사, 금액, 날짜, 제안의 결론, 실행 여부의 판단입니다. 어미나 제목의 순서까지 매번 수정하기 시작하면, 감사(audit) 업무가 본업을 잡아먹게 됩니다.

条件変更あり・本文も差分あり (조건 변경 있음 · 본문도 차분 있음)

은 모델, 모드, 프롬프트 버전 중 하나를 변경한 기록입니다. 이 경우에는 답변의 차분뿐만 아니라, 조건의 변경이 의도한 것이었는지를 확인합니다. 예를 들어 제안의 골자를 비교하고 싶은 날에는 quick과 think를 섞지 않고, 동일한 프롬프트 버전으로 다시 가져옵니다.

반대로, 본문이 동일하더라도 완전히 안심할 수는 없습니다. 답변의 근거로 삼은 URL이나 사내 자료의 버전은 이 CSV에서 추적하지 않습니다. 그 정도로 필요한 안건은 제안서 측에 출처란을 만듭니다. 이 작은 장부에 모든 것을 떠맡기지 않는 것이 지속 가능한 방법입니다.

ChatGPT의 업데이트는 편리합니다. 그렇기에 더욱 영업이나 기획에서 사용하는 답변은 "언제, 어떤 조건으로 가져왔는가"를 남기고 싶습니다.

우선 이번 주에 사용한 초안을 딱 1건만 본문과 6열의 CSV로 나누어 저장합니다. 그다음 같은 일을 부탁했을 때 스크립트를 한 번 돌립니다. 본문이 바뀌어 있다면, 다시 붙여넣기 전에 차분을 확인합니다. 그것만으로 충분합니다.

재현성은 거창한 검증 환경에서 시작되지 않습니다. 제안서에 들어가는 한 문장을 나중에 자신의 언어로 설명할 수 있는 상태로 만들어 두는 것. 그 축적이 모델의 업데이트를 업무의 개선으로 바꿉니다.