제품이나 서비스 종료를 설명하는 발표에서는 무엇이 중단되고, 누가 그 기능에 의존하며, 각 사용자가 어떻게 업무를 이어갈 수 있는지 보여줘야 합니다. 종료 날짜만으로는 전환 계획이 되지 않습니다. 사용자의 구체적인 작업을 대체 경로, 담당자, 공지 전에 필요한 결정과 연결하는 슬라이드가 유용합니다.
이 글에서는 가상의 예약 포털을 예로 듭니다. 브라우저 사용자, API 연동 담당자, 과거 기록이 필요한 사용자에게는 서로 다른 안내가 필요합니다. 먼저 이 경로를 짧은 설명 문서에 정리한 뒤 Presenti로 Word 문서를 프레젠테이션 초안으로 바꿀 수 있습니다. 발표 자료는 전환을 설명할 뿐, 계정이나 예약, 과거 기록을 이전하지는 않습니다.
무엇이 중단되는지 정확하게 말하기
“기존 포털을 종료합니다”라는 말은 제품팀에는 분명해 보여도 고객에게는 여러 질문을 남깁니다. 계속 로그인할 수 있을까요? 이미 잡힌 예약은 유효할까요? 연동 시스템이 멈출까요? 작년 기록을 조회할 수 있을까요?
수명 주기 용어를 쓰기 전에 달라지는 동작을 설명하세요. 예를 들어 Microsoft의 수명 주기 용어집(영문)은 자사 정책에서 사용 중단 예정, 제거, 서비스 종료를 구분합니다. 용어 하나로 우리 서비스의 실제 변경 내용을 대신 설명할 수는 없습니다.
가상의 포털에서 첫 번째로 제안한 변경은 기존 브라우저 화면에서 신규 예약을 받지 않는 것입니다. 이것만으로 기존 예약, API 요청, 기록 접근, 지원의 처리 방식까지 결정되지는 않습니다. 항목을 별도 행에 적으세요.
| 사용자의 작업 | 이 예시의 변경안 | 팀이 결정해야 할 사항 |
|---|---|---|
| 브라우저에서 예약 생성 | 신규 예약을 새 포털로 전환합니다. | 접근 가능한 사용자, 적용 시점, 도움을 받을 곳. |
| 전환 전에 생성한 예약 관리 | 신규 예약 중단만으로 정해지지 않습니다. | 조회, 변경, 취소할 수 있는 경로. |
| API로 예약 생성 | 연동에 대한 별도의 전환이 필요합니다. | 엔드포인트, 인증, 필드 매핑, 오류 처리, 전환 방식. |
| 과거 기록 조회 | 기록 접근 경로를 정해야 합니다. | 제공 기록, 조회 방식, 접근 권한, 적용되는 보존 정책. |
이 표는 작은 변경 공지가 의도치 않게 더 큰 약속으로 확대되는 것을 막아 줍니다. 지원 담당자도 즉석에서 정책을 추측하지 않고 변경을 설명할 수 있습니다.
계정 등급이 아니라 사용자 작업별로 전환 경로 정리하기
한 고객사가 브라우저를 쓰면서 API 연동을 유지하고 과거 기록도 조회할 수 있습니다. 서로 겹치지 않는 고객 구분이 아니라, 중복될 수 있는 이용 경로로 보세요. 영향을 받는 조직 수를 셀 때는 별도로 중복을 제거해야 합니다. 세 경로의 건수를 더하면 같은 조직을 여러 번 셀 수 있습니다.
GOV.UK의 서비스 종료 안내(영문)는 종료 후 사용자에게 무엇이 필요한지를 먼저 살피고, 직접 사용자와 API 사용자를 구분합니다. 발표에서도 “각 사용자가 계속할 수 있어야 하는 작업은 무엇인가?”를 물어보세요.
| 현재 경로 | 다음 경로 | 전환을 안내하기 전에 필요한 근거 |
|---|---|---|
| 접수 담당자가 기존 포털에서 예약을 만듭니다. | 새 브라우저 포털에서 신규 예약을 만듭니다. | 해당 계정으로 로그인, 예약 생성, 도움말 확인이 가능합니다. 기존 예약의 처리 방식은 따로 설명합니다. |
| 업무 시스템이 API로 예약을 전송합니다. | 지원되는 대체 연동을 사용합니다. | 연동 담당자가 필수 필드와 동작을 매핑하고, 대표 요청을 실행해 봤으며, 전환 방식에 합의했습니다. |
| 기록 사용자가 지난 예약을 찾습니다. | 승인된 보관소 또는 조회 절차를 이용합니다. | 권한 있는 사용자가 필요한 기록을 찾아 읽을 수 있습니다. 보존과 접근 문제를 판단할 책임자가 있습니다. |
“새 플랫폼”으로 화살표를 그렸다고 작업이 끝난 것은 아닙니다. 목적지에서 할 작업을 보여주세요. 새 예약은 잘 만들 수 있어도 기존 예약을 취소하는 방법은 없을 수 있습니다. 대체 서비스의 기능이 더 많더라도 그 공백은 슬라이드에 남겨야 합니다.
API 연동에서는 매핑을 구체적으로 설명하세요. 기존 서비스의 예약 참조 번호가 새 서비스에서는 다른 식별자가 될 수 있습니다. 호출 시스템이 원래 참조 번호를 유지하는지, 새 번호를 저장하는지, 조회가 필요한지를 기록합니다. 여기의 명칭은 예시이며, 실제 규약은 발표 작성자의 추측이 아니라 API 문서에 따라야 합니다.
내부 일정안과 고객에게 하는 약속 구분하기
내부 발표에는 미해결 의존 관계가 있어도 예정일을 표시할 수 있습니다. 고객 공지에서는 승인된 범위만 약속해야 합니다. 임시 일정이 담긴 슬라이드가 전달되더라도 확정된 약속처럼 보이지 않게 상태를 표시하세요.
예약 사례에서는 API 매핑보다 브라우저 접근 준비가 먼저 끝날 수 있습니다. 기록 접근에는 또 다른 선행 조건이 있을 수 있습니다. 세 경로를 별도 레인으로 나눠 대체 경로 준비, 사용자 통보, 사용자 작업 완료, 기존 경로 중단이라는 이정표를 각각 표시하세요. 차트를 깔끔하게 만들려고 모든 경로의 종료일을 하나로 맞추지 마세요.
회의의 결정 범위가 좁을 수도 있습니다. 브라우저 변경 공지만 승인하고 API 종료일은 아직 알리지 않는 식입니다. 이는 서비스 전체 종료를 승인하는 것과 다릅니다. 일정 옆에 실제 결정 범위를 적으세요.
계약, 환불, 접근성, 기록 보존 의무가 전환에 영향을 준다면 적용되는 승인 정책과 책임자를 설명 자료에 포함합니다. 일반 공지 양식으로 그 조건을 결정할 수는 없습니다. “기록에 계속 접근할 수 있도록 승인하는 팀은 어디인가?”처럼 미해결 질문을 구체적으로 쓰세요. 포괄적인 경고 문구로 슬라이드를 채우지 않는 편이 좋습니다.
서로 다른 세 작업에 맞는 공지 작성하기
다음 양식은 가상의 포털 사례에 속합니다. 사용하기 전에 대괄호 안을 승인된 내용으로 바꾸세요. 각 공지는 영향을 받는 작업부터 설명한 뒤 필요한 행동과 도움을 받을 경로를 안내합니다.
브라우저에서 예약하는 사용자에게
[날짜, 시각, 시간대]부터 신규 예약은 [새 포털 링크]에서 생성해 주세요. 해당 시점에 현재 포털은 신규 예약 접수를 중단합니다. 변경 전에 만든 예약은 [확정된 기존 예약 처리 경로]에서 조회, 변경, 취소할 수 있습니다. 다음 예약을 생성하기 전에 [승인된 접근 안내]에 따라 새 포털에 로그인해 주세요. 접근할 수 없다면 조직명과 진행하려는 작업을 적어 [지원 채널]로 문의해 주세요.
기존 예약을 설명하는 문장은 중요합니다. 이 문장이 없으면 다음 달 예약이 있는 사람은 자신에게도 해당하는 공지인지 알 수 없습니다. 그 경로가 정해지지 않았다면 모든 브라우저 사용자를 대상으로 보이는 공지를 보내기 전에 해결해야 합니다.
연동 담당자에게
현재 연동은 예약 전송에 [영향을 받는 API 또는 버전]을 사용합니다. 이 인터페이스는 [승인된 날짜, 시각, 시간대]에 요청 접수를 중단할 예정입니다. 대체 API 문서는 [문서 링크]에 있습니다. 인증, 필수 필드, 응답 식별자, 오류 동작을 검토한 뒤 [기술 담당 창구]와 전환을 조율해 주세요. 연동 이름과 제안하는 전환 시간대를 [지원 채널]로 보내 주세요. 브라우저 사용자가 이동해도 이 연동이 자동으로 바뀌지는 않습니다.
계약 담당자뿐 아니라 실제로 연동을 유지하는 사람에게 보내세요. 일반 공지만으로는 소프트웨어를 수정하고 작업 일정을 잡아야 하는 사람에게 전달되지 않을 수 있습니다.
과거 기록이 필요한 사용자에게
현재 예약 포털의 기록이 필요하다면 [승인된 조회 경로]를 이용해 주세요. [접근 권한이 있는 사용자 또는 역할]에게 [확인된 기록 범위와 형식]을 제공합니다. 현재 포털을 통한 접근은 [승인된 날짜, 시각, 시간대]에 변경됩니다. 제공 범위 밖의 기록이나 접근 요건은 [기록 지원 채널]에 문의해 주세요. 적용되는 보존 정책은 [승인된 정책 링크]에서 확인할 수 있습니다.
정확한 범위와 동작을 확인하지 않았다면 “모든 데이터가 자동으로 이전됩니다”라고 덧붙이지 마세요. 다운로드 가능한 보고서, 검색 가능한 보관소, 수정 가능한 예약 이력은 서로 다른 결과물입니다. 사용자가 실제로 받게 될 것을 설명해야 합니다.
전환 경로와 메시지를 중심으로 짧은 발표 구성하기
“브라우저의 신규 예약은 새 포털로 전환하고, API와 기록 경로는 별도로 확정한다”처럼 제안하는 변경을 정확하게 밝히며 시작합니다. 이어서 범위 표와 세 이용 경로를 보여주면 청중이 일정에 앞서 영향을 논의할 수 있습니다.
발표 중간에는 예정된 이정표와 대표 공지 한 개를 보여주세요. 나머지 두 공지는 부록이나 첨부 설명 자료로 옮기면 본회의 자료를 읽기 쉬워집니다. 마지막 슬라이드에는 요청하는 결정, 결정 권한이 있는 사람, 그 결정에 포함되지 않는 미해결 사항을 적습니다.
Word 설명 문서에서는 이용 경로마다 제목을 나누세요. 범위 표, 승인된 공지 문구, 각 이정표의 상태를 넣습니다. 슬라이드를 요청할 때도 세 경로를 구분하고 미정인 날짜는 미정으로 남기도록 지정하세요. 제품 이름만으로 이전 일정을 만들어 달라고 요청하지 마세요.
더 넓은 커뮤니케이션 활동에는 이해관계자 커뮤니케이션 계획을 활용해 대상, 채널, 메시지 책임자를 정리할 수 있습니다. 종료 발표 자료는 각 공지가 설명해야 할 구체적인 변경을 제공합니다.
기존 경로가 중단된 후 누가 돕는지 보여주기
기존 포털의 마지막 날이 전환 업무의 마지막 날은 아닐 수 있습니다. 저장한 북마크로 들어오거나, 이전 예약을 문의하거나, 목록에 없던 연동을 발견하는 사람이 생길 수 있습니다. 문의를 받는 지원팀에 명확한 처리 경로를 마련해 주세요.
이 예시에서는 브라우저 지원 창구가 새 포털 접근을, 기술 창구가 연동 질문을, 기록 창구가 조회 요청을 맡습니다. 직원에게 각 요청의 담당 경로와 전달할 정보를 알려주세요. 담당이 불분명한 공용 수신함만 있으면 사용자는 같은 설명을 반복하게 됩니다.
회의를 마칠 때 승인된 범위와 남은 결정을 따로 기록하세요. 좋은 발표는 사용자가 다음에 할 일을 이해하게 하고, 팀이 “제 업무는 어떻게 되나요?”라는 질문에 답을 지어내지 않고 설명할 수 있게 합니다.
