한 번의 답변을 고치는 방법을 익혔다면, 다음 작업에서도 같은 실수를 반복하지 않도록 수정 이유를 기록할 차례입니다. 이 글은 프롬프트를 여러 번 사용할 때 버전과 검토 기준을 남기는 방법을 다룹니다. 아래 예시는 기록 양식과 연습용 문장으로, 직접 AI를 실행하거나 성능 향상을 확인한 결과가 아닙니다.
반복 개선과 지속적 관리의 차이
한 번의 답변에서 빠진 항목을 찾아 요청문을 수정하는 절차는 반복 개선을 위한 프롬프트 수정 방법에서 다룹니다. 여기서는 시간이 지난 뒤 같은 종류의 작업을 다시 할 때 어떤 버전을 꺼내고, 원자료와 검토 기록을 어떻게 연결할지 설명합니다. 한 번 잘 작동한 요청문도 자료·독자·모델이 달라지면 그대로 적합하다고 볼 수 없습니다.
연습용 작업: 주간 안내 메일의 초안
가상 업무에서 매주 공개 공지 한 건을 직원에게 알리는 메일 초안을 만든다고 가정합니다. 실제 공지나 발송 기록은 제공되지 않았습니다. 목적은 공지에서 ‘누가 / 언제까지 / 무엇을 해야 하는지’를 뽑아 초안을 만들고, 다음 주에도 같은 기준으로 확인하는 것입니다.
버전을 남길 때 기록할 네 칸
① 버전과 날짜: 요청문을 바꾼 시점과 버전명(v1, v2)을 적습니다. ② 적용 범위: 어떤 종류의 공지와 독자를 대상으로 했는지 적습니다. ③ 바꾼 이유: 실제로 관찰한 누락이나 오해가 무엇인지 적습니다. ④ 검토 기준: 사람에게 다시 확인할 날짜·대상·신청 절차 같은 항목을 적습니다. 모델 이름이나 기능, 검색 가능 여부가 달라졌다면 별도 조건으로 기록합니다.
두 요청문을 비교하는 연습용 기록
v1 연습용 요청: “아래 공식 공지를 직원에게 공유할 메일 초안으로 정리해줘. [공식 공지 붙이기]” 예상 점검 항목: 대상과 기한이 빠지지 않았는가? 여기서 특정 AI가 실제로 정보를 빠뜨렸다고 가정하지 않습니다.
v2 연습용 요청: “아래 공식 공지만 사용해 직원용 메일 초안을 써줘. 제목 한 줄, 해당 대상, 해야 할 일, 마감일, 확인이 필요한 항목을 구분해줘. 공지에 없는 신청 주소는 만들지 말고 ‘담당자 확인 필요’로 적어줘. [공식 공지 붙이기]” 변경 이유의 예시: v1에서 어떤 항목이 누락됐는지 실제 사용자가 확인했을 때만 그 이유를 기록합니다.
버전 번호가 올랐다고 품질이 향상됐다고 쓰지 마세요. 같은 원문과 같은 평가 항목을 가지고 출력물을 비교하고, 사실과 맞는지 사람이 확인해야 합니다. 여기에는 결과 비교표나 실행한 AI 답변을 만들어 넣지 않았습니다.
다음 주에 재사용하기 전 확인할 것
새 공지의 독자와 목적이 이전과 같은지, 필요한 항목이 바뀌지 않았는지, 회사의 공식 용어와 날짜가 최신인지 확인합니다. 이전 버전은 그대로 덮어쓰지 말고 복사해 수정 이유를 남깁니다. ‘항상 공지를 정확히 정리한다’는 표현 대신 이번 원문에서 무엇을 검증했는지 기록합니다.
멈출 때와 다시 손볼 때
목적에 필요한 항목이 원문과 맞고, 작성자가 검토할 정보가 분리되어 있다면 표현만 계속 바꾸지 않아도 됩니다. 다른 종류의 공지에서 누락이 반복되거나 독자가 달라지면 그때 범위를 다시 정의합니다. 이 글의 목표는 프롬프트 자체의 성능을 증명하는 것이 아니라, 다음 작업에 쓸 수 있는 변경 기록을 남기는 것입니다.