- 제2부 SaaS 보안은 설계에서 시작된다

4. 세 번째 설계: 개인정보의 삭제·백업·복구

SaaS 기업은 고객 데이터를 안전하게 저장하는 데 많은 관심을 기울인다. 데이터베이스를 암호화하고 접근 권한을 제한하며 정기적으로 백업하는 것이 대표적이다. 그러나 데이터를 안전하게 보관하는 것만큼이나, 더 이상 필요하지 않은 데이터를 적절한 시점에 안전하게 삭제하는 것도 중요하다.

개인정보는 수집된 순간부터 파기될 때까지 하나의 생명주기를 갖는다. 서비스 제공에 필요한 정보를 수집하고, 정해진 목적으로 이용하며, 운영 시스템과 백업 저장소에 보관한 뒤 목적이 끝나면 삭제해야 한다. SaaS 보안은 이 전체 과정을 관리하는 일이다. 운영 중인 데이터베이스만 보호하고 백업 파일이나 로그, 외부 분석 도구에 남아 있는 데이터를 관리하지 않는다면 데이터의 생명주기를 제대로 통제한다고 보기 어렵다.

특히 고객이 서비스를 해지했을 때 어떤 데이터가 언제 삭제되는지를 명확히 설명할 수 있어야한다. 사용자가 작성한 문서와 업로드한 파일, 계정정보 등 운영 데이터의 삭제 시점이 정해져 있어야 하며, 삭제 전 데이터를 내려받을 수 있는 기간도 함께 안내하는 것이 바람직하다. 해지 즉시 모든 데이터를 지우는지, 일정한 유예기간을 둔 뒤 삭제하는지에 따라 고객의 대응 방법이 달라지기 때문이다.

백업 데이터는 별도의 기준이 필요하다. 운영 시스템에서 고객 데이터를 삭제하더라도 과거에 만들어진 백업 파일에는 같은 정보가 일정 기간 남아 있을 수 있다. 백업의 보존 기간과 교체 주기를 사전에 정하고, 고객에게도 필요한 범위에서 이를 안내해야 한다. 삭제된 정보가 백업 복구 과정에서 운영 시스템으로 되살아나지 않도록 처리하는 절차도 필요하다.

로그와 분석 데이터도 예외가 아니다. 서비스 이용 기록에는 사용자 식별자와 접속 위치, 검색어, 파일명 등 개인이나 기업의 활동을 추정할 수 있는 정보가 포함될 수 있다. 따라서 어떤 정보를 로그에 남길지, 얼마나 오래 보관할지, 서비스 해지 후에는 어떻게 익명화하거나 파기할지를 결정해야 한다. 통계 목적으로 데이터를 계속 활용하려면 개인이나 특정 고객을 다시 식별할 가능성이 없는지도 검토해야 한다.

외부 서비스에 전달된 데이터는 관리하기가 더욱 어렵다. 이메일 발송, 고객지원, 사용량 분석, 결제, 생성형 AI와 같은 외부 서비스를 사용하면 고객 데이터의 사본이 SaaS 기업의 통제 범위 밖에 저장될 수 있다. 내부 시스템에서 삭제 처리를 완료했더라도 외부 사업자의 시스템에는 정보가 남아 있을 가능성이 있다. 따라서 외부로 전달되는 데이터의 종류와 저장 위치, 보관 기간, 삭제 요청 방법을 계약과 기술 구조를 통해 확인해야 한다.

사용자 화면에 ‘삭제ʼ 버튼이 있다는 것만으로 실제 데이터가 삭제되었다고 단정할 수도 없다. 화면에서 보이지 않도록 상태값만 변경하는 논리적 삭제 방식이 사용될 수 있고, 검색 인덱스와 캐시, 파일 저장소, 복제 데이터베이스에는 같은 정보가 남아 있을 수 있다. 삭제 기능을 설계할 때는 원본 데이터뿐 아니라 관련된 첨부파일과 검색 데이터, 임시 데이터, 외부 전송본까지 어디에 사본이 존재하는지 파악해야 한다.

반대로 필요한 데이터를 너무 빠르게 삭제하는 것 역시 위험하다. 시스템 장애나 사용자의 실수, 랜섬웨어, 잘못된 배포 등으로 데이터가 손상되었을 때 복구할 수 없다면 서비스의 연속성을 보장하기 어렵다. 따라서 데이터 파기 정책과 백업 정책은 서로 분리된 업무가 아니라 함께 설계해야 하는 영역이다.

백업을 설계할 때는 먼저 무엇을 얼마나 자주 백업할 것인지 결정해야 한다. 데이터베이스만 백업하고 사용자가 업로드한 파일이나 서비스 설정을 제외하면 전체 서비스를 정상적으로 복구할 수 없다. 백업 파일에는 운영 데이터와 동일한 개인정보가 들어 있으므로 저장 및 전송 과정에서 암호화하고, 접근 권한도 엄격히 제한해야 한다. 운영 계정이 침해됐을 때 공격자가 백업까지 삭제하지 못하도록 관리 영역을 분리하는 방안도 고려할 수 있다.

무엇보다 중요한 것은 복구 가능성을 실제로 검증하는 것이다. 백업 작업이 성공했다는 알림만 확인해서는 충분하지 않다. 파일이 손상되었거나 암호화 키가 없고, 복구 절차가 문서와 다르다면 사고가 발생했을 때 백업을 사용할 수 없다. 정기적으로 별도의 환경에서 데이터를 복원하고, 서비스가 정상적으로 작동하는지 확인해야 한다. 고객별 데이터를 함께 저장하는 멀티테넌트 SaaS라면 전체 시스템뿐 아니라 특정 고객의 데이터만 선택적으로 복구할 수 있는지도 살펴볼 필요가 있다.

장애 복구 목표도 구체적으로 정해야 한다. 데이터 손실을 어느 시점까지 허용할 수 있는지는 복구시점목표, 즉 RPO로 표현할 수 있다. 예를 들어 RPO가 한 시간이라면 장애 발생 전 최대 한시간 동안의 데이터가 손실될 가능성을 감수한다는 의미다. 서비스를 얼마 만에 정상화할 것인 지는 복구시간목표, 즉 RTO로 정한다. 두 목표를 짧게 설정할수록 더 많은 기술과 비용이 필요하므로 서비스의 중요도와 고객 요구를 고려해 현실적인 수준을 정해야 한다.

결국 삭제·백업·복구는 서로 상충하는 요구를 조정하는 과정이다. 필요 없는 데이터는 정해진 시점에 확실히 삭제하면서도, 장애가 발생하면 필요한 범위까지 안전하게 복원할 수 있어야 한다. 이를 위해서는 데이터가 어디에 저장되고 복제되는지 파악하고, 삭제와 복구 절차를 정기적으로 시험해야 한다.

백업 파일이 존재하는 것과 실제로 서비스를 복구할 수 있는 것은 전혀 다른 문제다. SaaS 기업이 증명해야 할 것은 백업을 수행했다는 사실이 아니라, 사고가 발생했을 때 약속한 시간과 범위 안에서 고객의 서비스를 되살릴 수 있다는 능력이다.

5. 네 번째 설계: 생성형 AI에 고객 데이터가 전달될 때의 위험

문서 요약과 번역, 보고서 작성, 고객 문의 응답, 데이터 분석 등 생성형 AI의 활용 범위가 빠르게 넓어지고 있다. SaaS 기업 입장에서는 자체 AI 모델을 개발하지 않고도 외부 서비스의 API를 연결해 새로운 기능을 신속하게 제공할 수 있다. 기존 기능을 전면적으로 다시 개발하지 않아도 사용자의 업무 효율을 높이고 제품 경쟁력을 강화할 수 있다는 점도 매력적이다.

그러나 생성형 AI 기능을 추가하는 순간 고객 데이터의 처리 범위도 달라질 수 있다. 사용자가 SaaS 화면에 입력한 내용이나 업로드한 문서가 AI의 답변을 생성하기 위해 외부 사업자의 서버로 전달될 수 있기 때문이다. 고객은 자신이 이용하는 SaaS 안에서 모든 처리가 이루어진다고 생각할 수 있지만, 실제 데이터는 SaaS 운영사의 시스템을 벗어나 다른 기업의 인프라에서 처리될 수 있다.

가장 먼저 살펴봐야 할 위험은 개인정보와 기업 기밀의 외부 전송이다. 사용자는 AI에게 업무를 요청하면서 고객 명단이나 계약조건, 매출 자료, 개발 코드, 회의록과 같은 민감한 정보를 입력 할 수 있다. SaaS가 이러한 내용을 별도의 확인 절차 없이 외부 AI 서비스로 전송한다면 고객이 예상하지 못한 데이터 처리가 발생한다. 기업 고객과 체결한 계약이나 내부 보안정책에서 외부 전송을 제한하고 있다면 계약상 문제로도 이어질 수 있다.

프롬프트와 AI의 응답이 얼마나 오래 보관되는지도 확인해야 한다. AI 사업자는 서비스 운영과 품질 관리, 오남용 탐지 등을 목적으로 요청과 응답 기록을 일정 기간 저장할 수 있다. 보관 여부와 기간은 사업자, 서비스 유형, 계약 조건 및 설정에 따라 달라질 수 있으므로 일반 소비자용 서비스의 정책만 보고 판단해서는 안 된다. SaaS가 사용하는 API나 기업용 상품의 구체적인 데이터 처리 조건을 별도로 확인해야 한다.

입력 데이터가 AI 모델의 학습이나 성능 개선에 활용되는지도 중요한 검토 대상이다. 학습에 사용되지 않는다고 하더라도 보안 모니터링이나 장애 분석을 위해 일시적으로 저장될 수 있으므로 데이터의 이용 목적과 보존 정책을 구분해서 살펴봐야 한다. 계약서에 학습 제외 조건이 있는지, 별도의 설정이 필요한지, 하위 처리업체가 데이터를 취급하는지도 확인할 필요가 있다.

데이터가 처리되는 국가와 리전도 고려해야 한다. SaaS의 운영 데이터는 국내 또는 고객이 지정한 리전에 저장하면서도, AI 기능을 호출할 때 입력 내용이 해외 서버로 전송될 수 있다. 이 경우 고객에게 안내한 데이터 저장 위치와 실제 처리 경로가 달라질 수 있다. 개인정보의 국외 이전이나 산업별 보안 요구사항이 적용되는 고객이라면 데이터 흐름을 더 세밀하게 파악해야 한다.

AI가 권한 없는 데이터를 참조하는 문제도 발생할 수 있다. 특히 기업 내부 문서를 검색해 답변을 생성하는 검색증강생성, 즉 RAG를 적용할 때 주의해야 한다. 문서 검색 과정에서 사용자 권한을 제대로 확인하지 않으면 일반 직원의 질문에 경영진 전용 문서나 다른 부서의 자료가 활용될 수 있다. 다른 고객의 문서가 같은 검색 인덱스나 벡터 데이터베이스에 저장되어 있다면 테넌트 간 정보가 섞이는 사고로 이어질 수도 있다.

RAG를 적용했다고 해서 기존의 접근통제 원칙이 사라지는 것은 아니다. 원본 문서에 설정된 테넌트와 사용자 권한이 검색 단계에서도 그대로 적용되어야 한다. 검색된 문서 조각을 AI 모델에 전달하기 전에 현재 사용자가 해당 정보를 열람할 권한이 있는지 다시 확인하고, AI의 답변과 출처에도 같은 기준을 적용해야 한다. 원본 문서가 삭제되거나 권한이 변경되었을 때 검색 인덱스와 임베딩 데이터에도 그 변화가 빠르게 반영되는지 점검해야 한다.

AI가 사실과 다른 내용을 생성하는 위험도 간과할 수 없다. 생성형 AI의 답변은 자연스럽고 설득력 있게 보이지만 언제나 정확한 것은 아니다. 계약 검토, 재무 분석, 인사 평가, 의료·법률 관련 업무처럼 오류의 영향이 큰 영역에서는 잘못된 답변이 실제 업무상 피해로 이어질 수 있다. AI의 결과를 확정된 사실처럼 제공하기보다 참고자료임을 알리고, 출처 표시와 사람의 검토 절차를 마련해야 한다. 중요한 작업을 AI가 자동으로 실행한다면 실행 전 승인이나 결과 취소 기능도 필요하다.

따라서 AI 기능을 도입하기 전에는 먼저 어떤 데이터가 외부로 전송되는지 목록화해야 한다. 사용자가 직접 입력한 문장뿐 아니라 대화 이력, 첨부파일, 사용자 정보, 시스템이 자동으로 추가하는 지시문도 전송 대상에 포함될 수 있다. 업무 수행에 필요하지 않은 정보는 애초에 보내지않고, 개인정보나 비밀정보는 전송 전에 제거하거나 마스킹하는 것이 바람직하다.

외부 AI 사업자에 대해서도 입력 데이터의 학습 활용 여부와 보관 기간, 저장 위치, 삭제 방법, 암호화 방식, 사고 통지 절차 등을 확인해야 한다. 정책은 서비스와 계약 형태에 따라 달라질 수 있으므로 도입 시점의 약관만 검토하고 끝내기보다 변경 사항을 지속적으로 관리해야 한다. AI 기능을 하위 처리업체 목록과 개인정보 처리 관련 안내에 어떻게 반영할지도 함께 검토해야 한다.

고객에게 선택권을 제공하는 방안도 필요하다. 모든 고객에게 AI 기능을 기본적으로 활성화하기보다 조직 관리자가 사용 여부를 결정하거나, 민감한 업무에서는 기능을 끌 수 있도록 설계할 수 있다. 어떤 정보가 AI 처리에 사용되는지 알기 쉽게 안내하고, 사용자가 전송 전에 이를 인지할 수 있도록 하는 것도 중요하다.

마지막으로 특정 AI 공급업체에 대한 의존성도 관리해야 한다. 해당 서비스에 장애가 발생하거나 가격과 정책이 변경되면 SaaS의 핵심 기능이 중단될 수 있다. AI 연동 부분을 제품의 핵심 업무 로직과 분리하고, 장애 시 기본 기능으로 전환하거나 요청을 보류하는 절차를 마련할 필요가 있다. 공급업체를 변경할 경우 기존 사업자에게 전달된 데이터와 로그를 어떻게 삭제할지도 미리 정해야 한다.

생성형 AI는 SaaS의 활용 가치를 크게 높일 수 있지만, 동시에 고객 데이터의 흐름을 더 복잡하게 만든다. AI 기능의 편의성보다 먼저 확인해야 할 것은 고객 데이터가 어디로 이동하고, 누구에 의해 처리되며, 얼마나 오래 남는가이다. 이 질문에 명확하게 답할 수 있을 때 비로소 AI 기능을 안전한 SaaS 제품의 일부로 제공할 수 있다.

—

저작권 정책

SaaS 전환지원센터의 저작물인 『SaaS 보안은 설계에서 시작된다』은 SaaS 전환지원센터에서 『파프리카데이터랩 김유빈 대표』에게 집필 자문을 받아 발행한 전문정보 브리프로, SaaS 전환지원센터의 저작권정책에 따라 이용할 수 있습니다. 다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.