영업 메일 변경 후 승인 검수, 기한이 바뀌면 다시 승인할까

2026년 11월 기준, 영업 메일 후속 업무의 담당자·기한·원문 근거가 바뀌면 다시 검토합니다. 승인 범위 밖의 내부 메모만 바뀌면 기존 승인을 유지할 수 있습니다.

견적 자료를 보낼 날짜를 월요일로 승인한 뒤, 후속 메일에서 화요일을 요청했다고 가정해 보겠습니다. 업무 카드에 승인 완료 표시가 남아 있어도 월요일을 확인한 사람이 화요일까지 승인한 것은 아닙니다. 승인 기록에는 사람이 본 버전을 남기고, 현재 업무 버전이 달라지면 새 내용을 확인할 때까지 반영을 보류합니다.

이 글은 메일에서 뽑은 요청을 공용 업무 큐에 반영하는 현업·IT 책임자를 위한 인수 기준입니다. 개별 요청의 대기·완료 정의는 영업 메일 후속 업무 큐, ‘내일’ 같은 표현을 날짜로 확정하는 절차는 영업 메일 기한 추출 검수에서 다룹니다.

어떤 변경부터 다시 승인하나요?#

승인자는 작업명, 담당자, 기한, 판단의 근거가 된 원문 구간을 함께 봅니다. 이 필드 중 하나를 수정하면 업무의 검토 버전을 올립니다. 원문이 다른 메시지로 바뀌거나 같은 저장본의 근거 구간이 달라져도 다시 검토합니다. 승인 시점에는 근거가 바뀌지 않도록 버전이 붙은 참조나 접근을 통제하는 스냅숏을 남깁니다.

교대자가 남긴 확인 메모처럼 반영 내용과 판단 근거에 영향을 주지 않는 필드는 별도로 수정할 수 있습니다. 다만 고객에게 전달되는 설명이나 승인 판단에 쓴 메모라면 승인 범위에 포함합니다. 필드 이름보다 실제 쓰임새로 구분합니다.

검토 화면에는 승인 버전, 현재 버전, 변경 전후 값과 근거를 함께 보여줍니다. 새 내용을 보기 전에는 다시 승인할 수 없게 합니다. 반영되지 않은 이전 승인은 이력에서 찾을 수 있게 남기고, 현재 카드에서는 재검토 상태로 구분합니다.

반영 버튼을 눌렀을 때 무엇을 검수하나요?#

승인한 버전과 현재 버전이 일치하고 업무가 반영 대기일 때만 상태를 바꾸도록 인수표에 적습니다. 아래 예시는 각 행을 승인 버전 1에서 따로 시작해 반영 조건이 맞는지 확인합니다.

UPDATE followup
SET state = 'ready'
WHERE id = 1
  AND state = 'pending'
  AND review_revision = 1
  AND approved_revision = 1
RETURNING id, review_revision;

가상 업무의 반영 대기 상태가 pending이고 화면이 요청한 버전이 1인 경우입니다. 갱신이 0행이면 이미 반영됐거나 업무 상태·버전·대상이 달라졌을 수 있습니다. 권한을 다시 확인하고 최신 업무를 읽은 뒤 이유에 맞는 안내를 표시합니다. 같은 승인 요청을 최신 버전으로 바꿔 자동 재시도하면 사람이 보지 않은 내용이 적용될 수 있습니다.

HTTP로 검토 결과를 저장한다면 서버가 제공한 버전 표식인 ETag와 If-Match를 사용할 수 있습니다. 예를 들어, 오래된 화면의 새 승인 요청이 서버의 버전과 다르면 API가 412를 반환하도록 계약합니다. 조건 비교와 실제 저장은 한 번에 처리하고, ETag는 이 API가 보호하는 변경의 범위를 반영해야 합니다. 이미 반영된 요청을 처리하는 규칙과 사용자 권한 확인은 따로 둡니다.

모든 변경에 재승인이 필요한가요?#

기한이 바뀌는 경우와 교대 메모를 고치는 경우에 같은 절차를 강제하면 검토가 밀릴 수 있습니다. 승인에 영향을 주는 필드를 좁게 정의하고 내부 메모를 분리하면 작은 수정은 계속할 수 있습니다. 반대로 원문 근거를 덮어쓴 뒤 화면의 문구가 같다는 이유로 이전 승인을 이어 쓰면 승인자가 봤던 자료를 복원하기 어렵습니다.

이미 큐에 반영되거나 외부로 전달된 업무의 오류는 수정 요청으로 처리합니다. 과거의 승인과 반영 이력은 보존하고 바뀐 내용의 재검토를 받습니다. 외부 전달을 되돌릴 수 있는지는 상대 시스템과 업무 절차에 따라 달라집니다.

어떤 근거를 사용했나요?#

• IETF RFC 9110 §13.1.1 If-Match, 2022년 6월. HTTP 조건 요청에서 ETag의 강한 비교와 갱신 충돌 방지를 설명합니다.
• PostgreSQL 16 트랜잭션 격리와 UPDATE. Read Committed의 행 조건 재평가와 실제 갱신된 행의 반환을 설명합니다.
• GitHub 보호 브랜치 규칙. 리뷰한 변경 범위가 바뀌면 기존 승인을 해제하도록 설정할 수 있는 공개 예입니다.

위 문서와 알파카랩스 업무 자동화·API 연동 서비스는 2026년 11월 8일 확인했습니다. 공개 서비스는 시스템 연동 범위, 사람이 확인할 예외, 수동 전환과 운영 인수 조건을 협의한다고 안내합니다. 인수표의 버전 정책은 이 글의 설계 예시입니다.

영업 메일 변경 후 승인 FAQ#

승인 버전 인수표 초안 협의#

이름·주소·실제 계약 조건을 제거한 변경 전후 표본 한 쌍을 준비해 주세요. 첫 범위 협의에서 어떤 항목을 바꾸면 다시 승인할지, 검토 화면과 반영 API에서 무엇을 확인할지 정리합니다. 소요 시간은 표본과 검수 범위를 확인한 뒤 협의합니다.