구독 전 확인해야 할 데이터 반출과 vendor lock-in

다운로드 버튼이 있다고 해서 서비스를 쉽게 떠날 수 있는 것은 아닙니다. 내보내기 파일이 불완전하거나, 특정 관리자만 요청할 수 있거나, 다른 서비스가 재구성하지 못하는 형식일 수 있습니다. 대화는 받을 수 있어도 프로젝트, 메모리, 사용자 지침, 에이전트 설정, 공유 권한, 인용 기록, 평가 결과와 연동 상태가 남을 수 있습니다.

따라서 데이터 이동성은 기능 설명이 아니라 실제 업무 흐름으로 검증해야 합니다. 중요한 질문은 “파일을 받을 수 있는가?”가 아니라 “다른 환경에서 업무를 계속하는 데 필요한 기록과 맥락을 보존할 수 있는가?”입니다.

NIST AI 위험 관리 프레임워크는 이익, 비용, 가정, 책임, 모니터링과 생애주기 결정을 함께 관리하도록 합니다. 공급자 공식 문서도 요금제, 워크스페이스 유형, 소유자 역할과 제품 영역에 따라 내보내기 범위가 달라질 수 있음을 보여줍니다. 아래 절차는 구독이 핵심 업무에 깊게 들어가기 전에 이탈 가능성을 시험하는 방법입니다.

1. 공급자를 고르기 전에 데이터와 업무 자산 목록 만들기

내보내기 페이지보다 먼저 업무가 무엇을 만드는지 정리합니다.

대표 자산은 다음과 같습니다.

• 대화와 생성 결과물;
• 업로드한 원문 파일과 추출된 텍스트;
• 프로젝트, 폴더, 컬렉션, 지식 베이스;
• 프롬프트, 템플릿, 사용자 지침, 저장된 에이전트;
• 인용, 출처 위치, 평가 기록, 승인 근거;
• 사용자 역할, 공유 규칙, 워크스페이스 멤버십, 감사 로그;
• API 키, webhook, connector, 예약 작업, 자동화 상태;
• 사용량, 과금, 지연, 오류율, 품질 측정값.

각 자산을 필수, 유용, 폐기 가능으로 구분합니다. 개인 아이디어 정리는 대화와 최종 파일만 필요할 수 있습니다. 운영 업무는 권한, 버전 이력, 출처 증거와 재현 가능한 설정까지 필요합니다.

이 목록이 없으면 중요한 자산이 빠졌는데도 내보내기가 완전해 보일 수 있습니다.

2. 보관용 archive와 재사용 가능한 이전 패키지 구분하기

archive는 데이터를 내려받을 수 있다는 사실만 증명합니다. 업무를 계속할 수 있다는 뜻은 아닙니다.

재사용 가능한 이전 패키지는 다음 질문에 답할 수 있어야 합니다.

• 어떤 메시지가 어떤 대화와 프로젝트에 속하는가?
• 시각, 작성자 역할, 출처 링크와 첨부파일이 보존되는가?
• 프롬프트와 에이전트 지침을 다시 만들 수 있는가?
• 원본 파일 이름과 형식이 유지되는가?
• 다른 도구가 직접 가져올 수 있는가, 사람이 다시 구성해야 하는가?
• 레코드 관계가 유지되는가, 평면 텍스트만 남는가?

예를 들어 OpenAI의 현재 공식 도움말은 대화와 계정 데이터 내보내기를 설명하지만, 별도의 계정 간 이전 문서에서는 내보낸 대화를 업로드해 참고할 수 있어도 기존 sidebar, 개별 대화 구조, 구독, 워크스페이스 멤버십, 메모리, GPT와 계정 설정을 그대로 복원하지는 못한다고 설명합니다. 이것이 보관 접근과 운영 이동성의 차이입니다.

내보내기 형식과 다른 환경에서 사용할 수 있도록 변환하는 작업을 기록합니다. JSON, CSV, Markdown과 원본 파일은 화면 캡처나 폐쇄 형식보다 점검하기 쉽지만, 형식만으로 충분하지 않습니다. schema와 관계 정보도 필요합니다.

3. 정확한 계정·요금제·워크스페이스의 반출 범위 확인하기

개인 계정, 팀 워크스페이스, 교육용 환경과 기업 환경이 같은 통제를 제공한다고 가정하지 않습니다.

실제로 사용할 요금제와 역할을 기준으로 확인합니다.

• 일반 멤버도 내보낼 수 있는가, 소유자나 관리자만 가능한가?
• 개인 데이터, 워크스페이스 데이터 또는 둘 다 포함되는가?
• 공유 프로젝트와 조직 레코드가 포함되는가?
• 감사 로그는 별도 요청이 필요한가?
• 데이터 residency 같은 설정이 내보내기 자격을 바꾸는가?
• 퇴사자가 직접 요청할 수 있는가, 관리자가 처리해야 하는가?
• 해지 후 export가 준비되기 전에 접근 권한이 끝나는가?

공식 문서는 변경될 수 있고 실제 계정 화면은 일반 도움말과 다를 수 있습니다. 시험용 워크스페이스에서 현재 설정을 확인하고 시험 날짜, 요금제와 사용 역할을 기록합니다.

팀 업무라면 정기 export 담당자와 대체 담당자를 지정합니다. 한 사람의 계정에만 의존하는 이동성은 연속성 위험입니다.

4. 실제 내보내기 파일과 metadata 검사하기

시험 계정에 민감하지 않은 대표 데이터를 넣은 뒤 조기에 내보내기를 요청합니다. 해지 직전까지 기다리지 않습니다.

다음을 확인합니다.

• 파일명, 확장자, 인코딩과 압축 형식;
• 대화 식별자와 프로젝트 관계;
• 시각과 timezone;
• 메시지 역할과 수정 이력;
• 출처 URL, 인용문과 citation;
• 업로드·생성 파일;
• 설정, 지침과 구성 레코드;
• 삭제·보관·공유·임시 콘텐츠의 처리;
• manifest 또는 schema 설명.

몇 개 레코드를 직접 열고 가능하면 간단한 로컬 도구로 파싱합니다. 기대 대화 수와 첨부 수를 셉니다. 원본 파일 hash를 비교합니다. 한국어, 긴 문서, 표와 코드 블록이 온전히 남는지도 확인합니다.

기술적으로 export가 성공해도 식별자, 출처 근거 또는 첨부 관계가 사라지면 업무 요건에서는 실패일 수 있습니다.

5. 대체 환경에서 대표 업무 하나 복구하기

가장 강한 이동성 검증은 작은 복구 rehearsal입니다.

대표 업무 하나를 골라 다른 서비스나 중립적인 로컬 형식에서 다시 구성합니다. 다음 항목을 포함합니다.

1. 정상 대화 또는 프로젝트 하나;
2. 업로드 원문 파일 하나;
3. 재사용 프롬프트나 지침 세트 하나;
4. 출처 확인이 필요한 생성 결과 하나;
5. 승인 또는 의사결정 기록 하나;
6. 협업이 중요하다면 권한이 있는 공유 항목 하나.

자동으로 옮겨지는 것, 변환 가능한 것, 사람이 다시 만들어야 하는 것을 나눕니다. 걸린 시간과 사라진 동작을 기록합니다.

성공 조건은 UI가 똑같은 것이 아닙니다. 접근할 수 없는 기억이나 화면 캡처에 의존하지 않고 업무를 계속하는 데 필요한 증거와 맥락을 보존하는 것입니다.

결과를 다음처럼 분류합니다.

• portable — 필수 자산을 옮기거나 문서화된 제한 작업으로 복구할 수 있음;
• partially portable — 핵심 레코드는 이동하지만 중요한 설정이나 관계를 수동 복구해야 함;
• locked in — 핵심 자산, 권한 또는 업무 상태를 허용 가능한 비용으로 복구할 수 없음.

6. 화면에 보이지 않는 의존성까지 지도화하기

vendor lock-in은 저장된 텍스트보다 주변 의존성에서 생기는 경우가 많습니다.

다음을 점검합니다.

• 공급자 전용 프롬프트·에이전트 기능;
• 전용 검색 인덱스와 embedding;
• 다른 곳에서 재현하기 어려운 connector;
• API 응답 형식과 tool-call schema;
• custom function, 인증과 권한 mapping;
• 특정 모델 행동을 전제로 한 승인 기준;
• dashboard, alert, 평가와 과금 보고서;
• 공급자 통제에 연결된 조직 정책.

대화를 전부 내보낼 수 있어도 승인 로직, 모니터링 또는 integration이 공급자 행동에 묶여 있으면 이전 비용은 커집니다.

중요 프롬프트, schema, test case, 승인 기준과 출처 레코드는 공급자 중립 저장소에 유지합니다. 가능하면 업무 상태를 모델 대화 밖에 둡니다. 공급자를 유일한 기록 시스템이 아니라 실행 구성요소로 취급합니다.

7. 확장 전에 migration과 exit 비용 계산하기

완전한 export가 있어도 이전 비용은 발생합니다. 사용을 확대하기 전에 추정합니다.

포함할 비용은 다음과 같습니다.

• export 요청과 대기 시간;
• parsing, 변환과 검증;
• 프롬프트, 에이전트, 프로젝트와 권한 재구성;
• 원문 재색인;
• 대체 서비스 회귀 테스트;
• 보안·개인정보 검토;
• 이전 중 병행 운영;
• 사용자 재교육과 문서 수정;
• 중단 시간, 지연 업무와 rollback 능력.

하나의 숫자보다 scenario로 계산합니다.

이 비용을 제품 가치와 함께 판단합니다. 높은 가치가 있는 서비스라면 일정 switching cost를 감수할 수 있습니다. 다만 장애나 계약 종료 때 처음 발견해서는 안 됩니다.

8. 이탈 조건을 정하고 export rehearsal 반복하기

제품, 요금제와 업무는 변합니다. 도입 전에 통과한 이동성 시험도 새로운 기능과 integration이 추가되면 낡을 수 있습니다.

다음 상황에서 export와 복구 rehearsal을 다시 실행합니다.

• 요금제 또는 워크스페이스 전환;
• 주요 가격·계약 변경;
• 핵심 integration 추가;
• 저장 데이터 민감도 상승;
• export 권한이나 관리자 역할 변경;
• 반복 장애;
• 품질 하락 또는 지원 의무 미충족;
• 인수합병, 제품 종료 또는 전략적 이탈 결정.

중요 업무는 통제된 위치에 정기 export를 보관하고 archive를 실제로 열 수 있는지 확인합니다. export 날짜, 원본 계정, workspace, plan, file hash, 기대 레코드 수, 시험 결과와 남은 문제를 기록합니다.

내보낸 파일에는 민감한 대화와 첨부가 포함될 수 있습니다. 필요한 기간보다 오래 보관하지 말고 원본 데이터와 같은 수준의 접근 통제, 암호화, 보존과 삭제 규칙을 적용합니다.

데이터 이동성 판단표

구독 전 경고 신호

다음 상황이면 도입을 잠시 멈춥니다.

• 요금제별 export 범위가 다른데 대상 요금제가 불명확함;
• 공급자가 제외 항목을 설명하지 못함;
• 공유 workspace 기록이 한 소유자에게 의존함;
• 전용 소프트웨어 없이는 export를 검사할 수 없음;
• 대화는 이동하지만 원문·설정·증거는 남음;
• 핵심 업무가 중립 명세 없는 공급자 전용 agent에 의존함;
• export 완료 전 해지로 접근이 종료될 수 있음;
• 실제 restore rehearsal을 한 적이 없음;
• 중요한 의사결정의 유일한 기록이 서비스 안에만 있음.

이 신호가 제품을 자동 탈락시키는 것은 아닙니다. 사용을 확대하기 전에 switching cost를 통제해야 한다는 의미입니다.

구독 전 짧은 이동성 체크리스트

• 필수 데이터, 설정, 관계와 integration 목록을 만든다.
• 정확한 plan·workspace·role의 export 자격을 확인한다.
• 비민감 대표 데이터로 시험 export를 요청한다.
• 파일 형식, 식별자, metadata와 첨부를 검사한다.
• 다른 환경에서 대표 업무 하나를 복구한다.
• 수동 작업 시간과 사라진 동작을 기록한다.
• 프롬프트, schema, test와 결정 기록을 공급자 밖에 둔다.
• 정상·긴급 이탈 비용을 추정한다.
• export 담당자와 대체 담당자를 지정한다.
• 재검토 날짜와 이탈 trigger를 정한다.

확인한 기준 자료

• NIST AI RMF Core (새 창에서 열림)
• OpenAI: Exporting your ChatGPT history and data (새 창에서 열림)
• OpenAI: Transfer exported conversations between ChatGPT accounts (새 창에서 열림)
• Google: Download your Gemini Apps data (새 창에서 열림)
• Google: Download your data (새 창에서 열림)
• Anthropic: Export Claude data (새 창에서 열림)