버전 관리

핵심 요약

• 약관은 본문을 덮어쓰지 말고 "새 버전 발행"으로 관리해 동의 시점의 원문을 보존해야 합니다.
• 고객이 동의한 것은 현재 약관이 아니라 그 시점의 특정 버전이므로, 분쟁·감사에서는 동의한 전문과 버전 식별이 핵심 증거입니다.
• 동의 상태는 granted(최신 동의), pendingReConsent(새 버전 발행으로 재동의 필요), withdrawn(철회) 모델로 전환 설계합니다.
• 새 버전 발행은 과거 동의 기록을 무효화하는 행위가 아니며, 최신 버전 동의가 필요하면 재동의 상태로 전환해 추가 동의를 받습니다.
• changeSummary는 "문구 수정"이 아니라 무엇이 왜 바뀌었는지와 재동의·기능 제한 등 운영 영향을 한 문장으로 기록합니다.

약관 운영에서 가장 중요한 원칙은 동의 시점의 원문을 보존하는 것입니다. 그래서 약관 본문을 덮어쓰지 않고 "새 버전 발행"을 기본으로 합니다.

왜 버전을 나누는가

• 고객이 동의한 것은 "현재 약관"이 아니라, 그 시점의 특정 버전입니다.
• 분쟁/민원/감사에서 필요한 것은 "동의했다"는 주장보다, 동의한 전문과 버전 식별입니다.

버전 발행과 동의 상태 전환(권장 플로우)

상태 모델 예시

• granted: 최신 버전에 동의함
• pendingReConsent: 새 버전이 발행되어 재동의가 필요함
• withdrawn: 철회됨(선택 동의에서 주로 발생)

새 버전 발행 절차(운영 가이드)

1. 약관 목록에서 개정할 약관을 선택합니다.
2. 새 버전 발행(또는 유사 기능)을 클릭합니다.
3. 변경된 본문을 입력합니다.
4. 변경 요약(changeSummary)을 작성합니다.
5. 발행 후 기존 고객의 상태가 pendingReConsent로 전환되는지 확인합니다.
6. 고객에게 개정 안내를 발송하고 재동의를 수집합니다.

changeSummary 작성 요령

변경 요약은 나중에 회고하거나 감사에 대응할 때 큰 도움이 됩니다.

• "문구 수정" 대신, 무엇이 왜 바뀌었는지를 한 문장으로 씁니다.
• 운영 영향(재동의 필요 여부, 기능 제한 여부)을 포함합니다.

예시:

• "제3자 제공 대상 업체 1곳 추가(결제 처리 목적)"
• "마케팅 수신 동의 철회 경로를 설정 화면으로 통일"
• "환불 정책: 구독 해지 시점 기준으로 정산 방식 변경"

참고 자료

• 국가법령정보센터 (한국어)