정보는 처음부터 있었다
갱신 시점을 놓치는 상황을 생각해 보면 이상한 점이 하나 있다.
만료일을 몰라서 놓치는 것이 아니다.
계약서에 적혀 있다.
라이선스 증서에도 적혀 있다.
발주서와 견적서에도 남아 있다.
즉, 정보가 없어서 생기는 문제가 아니다.
필요한 날짜는 처음부터 회사 안에 있었다.
그런데도 갱신 시점은 계속 지나간다.
왜 그럴까.
문제는 날짜가 존재하느냐가 아니라, 그 날짜를 시스템이 사용할 수 있는 형태로 가지고 있느냐에 있었다.
문서는 사람이 읽으라고 만들어졌다
라이선스 증서 PDF를 열어보면 만료일은 분명하게 적혀 있다.
사람이 보기에는 충분한 정보다.
제품명도 있고, 시리얼 번호도 있고, 수량도 있고, 만료일도 있다.
필요하면 파일을 열어 확인하면 된다.
하지만 시스템의 입장에서 이 PDF는 조금 다르다.
첨부파일 하나다.
어느 고객사의 문서인지 연결할 수 있고, 필요할 때 다운로드하거나 열어볼 수도 있다.
하지만 그 안에 적힌 날짜 자체를 시스템이 알고 있는 것은 아니다.
그래서 할 수 없는 일이 많다.
이번 달에 만료되는 계약이 몇 건인지 바로 셀 수 없다.
만료일 순서로 정렬할 수 없다.
3개월 안에 만료되는 고객사만 골라낼 수 없다.
만료가 임박한 고객을 담당자별로 나누어 볼 수도 없다.
문서 안에는 분명 정보가 있다.
하지만 그 정보가 문서 안에 머물러 있는 동안에는 읽을 수는 있어도 다룰 수는 없다.
보관되어 있다는 것과 활용할 수 있다는 것은 다른 문제다.
그래서 결국 사람이 옮겨 적는다
문서 안의 날짜를 실제 업무에 사용하려면 결국 한 단계가 더 필요하다.
PDF를 연다.
만료일을 확인한다.
엑셀이나 시스템의 입력 칸에 다시 적는다.
이제야 날짜를 데이터처럼 다룰 수 있다.
정렬할 수 있고, 필터링할 수 있고, 알림도 걸 수 있다.
겉으로 보면 문제가 해결된 것처럼 보인다.
하지만 이 순간 새로운 문제가 시작된다.
옮겨 적는 순간, 진실이 둘이 된다
같은 사실이 두 곳에 존재하게 된다.
원본 날짜는 증서 안에 있다.
그리고 사람이 옮겨 적은 날짜는 엑셀이나 시스템 안에 있다.
둘이 계속 같다면 아무 문제가 없다.
문제는 어느 순간 둘이 달라졌을 때다.
예를 들어 라이선스가 갱신되었다고 해보자.
새로운 증서가 발급되고, 만료일도 바뀐다.
원본 문서에는 새로운 날짜가 적혀 있다.
그런데 기존 엑셀에는 이전 만료일이 남아 있을 수 있다.
이제 같은 계약에 두 개의 날짜가 존재한다.
어느 것이 맞는지는 원본을 다시 열어보기 전까지 알 수 없다.
더 어려운 점은 따로 있다.
사본만 봐서는 틀렸다는 사실을 알 수 없다는 것이다.
엑셀에 적힌 날짜는 언제나 정상적인 값처럼 보인다.
2027년 3월 15일.
2027년 8월 30일.
2028년 1월 10일.
숫자 자체에는 아무 문제가 없다.
하지만 그 값이 3년 전에 옮겨 적은 것인지, 지난달에 갱신된 증서에서 나온 것인지 화면만 보고는 알기 어렵다.
낡은 데이터도 화면에서는 최신 데이터와 똑같은 모습으로 보인다.
그리고 옮겨 적기는 한 번으로 끝나지 않는다
라이선스 정보는 한 번 입력하면 끝나는 데이터가 아니다.
계약이 갱신되면 새로운 증서가 온다.
제품이 추가되어도 새로운 증서가 올 수 있다.
수량이 바뀌거나 계약 조건이 변경되어도 다시 확인해야 한다.
그때마다 같은 과정이 반복된다.
파일을 열고, 내용을 확인하고, 기존 데이터를 찾아서, 새로운 값으로 바꾼다.
이 과정에서 한 번이라도 업데이트가 빠지면, 그 순간부터 관리용 데이터는 원본과 달라지기 시작한다.
그리고 그 차이는 눈에 잘 보이지 않는다.
시트는 아무 경고도 하지 않는다.
조용히 낡을 뿐이다.
만료일은 가만히 있어도 의미가 변한다
여기에는 만료일만의 특성이 하나 더 있다.
많은 고객 정보는 누군가 실제로 변경해야 값이 바뀐다.
회사가 이전해야 주소가 바뀐다.
담당자가 변경되어야 담당자 정보가 바뀐다.
전화번호를 바꿔야 연락처가 달라진다.
아무 변화가 없다면 어제의 정보는 오늘도 그대로 유효하다.
하지만 만료일은 조금 다르다.
날짜 자체는 바뀌지 않는다.
2026년 12월 15일이라는 값은 오늘도 2026년 12월 15일이고, 내일도 2026년 12월 15일이다.
그런데 그 날짜가 가지는 업무상의 의미는 계속 변한다.
작년에는 「아직 한참 남은 계약」이었다.
지난달에는 「슬슬 준비할 때」였다.
이번 주에는 「지금 연락해야 하는 고객」이다.
그리고 어느 날이 지나면, 아무도 데이터를 수정하지 않았는데 「이미 지난 고객」이 된다.
데이터가 변한 것이 아니라, 데이터의 의미가 변한 것이다.
이 차이가 중요하다.
만료일은 저장해 두고 필요할 때 찾아보는 정보가 아니다.
시간이 지나면서 스스로 업무의 우선순위를 바꾸는 정보다.
그래서 담당자가 필요할 때 찾아보는 방식만으로는 충분하지 않다.
찾아볼 이유를 떠올렸을 때는 이미 늦었을 수도 있기 때문이다.
그래서 필요한 것은 알림이 아니었다
이 문제를 이야기하면 가장 먼저 떠오르는 해결책은 알림이다.
만료 90일 전, 30일 전, 7일 전.
담당자에게 메일을 보내거나, 화면에 알림을 띄우거나, 만료 임박 고객을 따로 보여주는 방식이다.
물론 필요한 기능이고, 실제로 갱신 관리에 큰 도움이 된다.
다만 알림에는 중요한 전제가 하나 있다.
시스템 안에 정확한 만료일이 데이터로 들어 있어야 한다.
알림은 날짜를 만들어내지 않는다.
이미 있는 날짜를 기준으로 움직일 뿐이다.
낡은 엑셀의 날짜를 기준으로 알림을 만들면, 낡은 날짜에 맞춰 정확하게 알림을 보내준다.
아예 옮겨 적지 않은 계약은 더 어렵다.
시스템에는 날짜 자체가 없기 때문에 알림을 보낼 수도 없다.
그리고 이 상황이 특히 위험하다.
알림이 오지 않으면 사용자는 자연스럽게 「이번에는 만료되는 고객이 없구나」라고 생각한다.
하지만 실제 의미는 다를 수도 있다.
만료되는 고객이 없는 것이 아니라, 시스템이 그 날짜를 모르고 있는 것일 수 있다.
조용한 것과 문제가 없는 것은 다르다.
그래서 순서를 다시 생각해야 했다.
처음에는 「만료일을 놓치니까 알림을 만들자」로 시작하지만, 한 단계 더 들어가면 질문이 달라진다.
그 알림은 어떤 날짜를 보고 움직일 것인가.
그 날짜는 누가, 언제 입력했는가.
최신 증서를 반영한 값인가.
누락된 계약은 없는가.
이 질문에 답할 수 없다면 알림 기능이 있어도 갱신 관리 전체를 신뢰하기 어렵다.
알림은 마지막 단계다.
문제는 알림 기능이 없어서가 아니었다.
알림이 읽을 수 있는 형태의 날짜가 없었기 때문이다.
다음 글에서는
그렇다면 문서 안에 있는 날짜를 어떻게 데이터로 꺼낼 것인가.
사람이 옮겨 적지 않아도 되고,
옮겨 적는 과정에서 원본과 어긋나지도 않는 방법이 필요했다.
다음 글에서는 Linkspace가 라이선스 증서를 어떻게 읽어서 표로 만드는지 다룬다.
증서 한 장에 여러 건이 들어 있을 때 무엇을 기준으로 고르는지,
이미 등록된 계약이 다시 들어왔을 때 어떻게 처리하는지,
그리고 왜 원본 파일을 버리지 않는지까지 이야기해 보려고 한다.
키워드: 라이선스 만료 관리, 계약 갱신 관리, 만료일 관리, 계약 만료 알림, 라이선스 갱신, 유지보수 갱신, 계약 관리 엑셀, 문서 데이터화, PDF 데이터 추출, 계약서 관리, 갱신율 관리, B2B CRM, 영업관리 프로그램, 고객관리 프로그램