기업의 기밀부터 개인의 일상까지, 데이터를 맡는 서비스를 만든다는 것

이 글의 기업용 제안서·견적서 검토 서비스는 보안 설계를 설명하기 위해 만든 가상의 사례다. 마인드 로그는 내가 직접 개발한 일상 기록 서비스다. 아래에서 다루는 기술적 통제와 안내 문구는 설계·검토 기준이며, 마인드 로그에 현재 구현된 기능이나 확정된 운영 정책을 설명하는 것은 아니다.

1. 서비스를 만들다 보면, 결국 “이 데이터를 맡겨도 되는가”라는 질문을 만난다

멘토링을 하면서 보안에 관한 질문을 자주 듣는다.

사용자가 자료를 올리고, 서비스가 그 자료를 분석해 유용한 결과를 제공하는 구상은 이제 낯설지 않다. 그런데 자료 안에 회사의 기밀이 들어 있다면 어떨까. 외부에 알려지면 곤란한 계약 조건이나, 아직 공개하지 않은 사업 계획이 포함되어 있다면 어떨까.

이 질문을 조금 더 개인적인 영역으로 옮겨 보자.

내가 최근 개발한 마인드 로그는 일상에서 일어난 일과 자신의 생각을 부담 없이 기록하는 서비스다. 특별한 형식에 맞추지 않고, 그날의 경험이나 떠오른 생각을 자연스럽게 남기는 것이 출발점이다.

그렇게 기록하다 보면 사람의 이름이 들어갈 수도 있다. 가족이나 직장에서 있었던 일이 담길 수도 있고, 다른 사람에게는 말하지 못한 고민을 적을 수도 있다. 사용자는 기록하는 순간마다 “이 문장에 개인정보가 포함되어 있나?”를 검토하지 않는다. 자연스럽게 쓴다는 것은 그만큼 개인적인 내용이 들어갈 수 있다는 뜻이기도 하다.

여러 사람이 각자의 계정으로 사용하는 서비스라면, 개발자가 자신의 기록만 다룰 때보다 훨씬 넓은 책임을 생각해야 한다.

사용자가 데이터를 맡긴다는 것은, 그 데이터가 어떻게 다뤄질지에 관한 판단도 함께 맡긴다는 뜻이다.

어떤 정보를 수집하는지, 누가 접근할 수 있는지, 외부 업체가 처리하는지, 언제까지 남는지, 사용자가 삭제하면 어디까지 지워지는지.

서비스를 만드는 사람은 이 질문들에 기술과 운영, 그리고 사용자에게 보여 주는 설명으로 답할 수 있어야 한다.

2. 기업의 문서와 개인의 일상은 무엇이 같고, 무엇이 다른가

먼저 가상의 기업 서비스를 생각해 보자.

기업이 외부 업체의 제안서와 견적서, 회사 내부의 검토 기준을 올리면 AI가 업무 범위, 가격 조건, 일정, 빠진 항목, 추가로 확인할 질문을 정리해 주는 서비스다. 최종 판단은 담당자가 한다.

여기에는 내부 예산, 협상 조건, 거래처 정보, 앞으로의 사업 계획 등이 들어갈 수 있다. 다른 고객사에 자료가 보이거나, 승인받지 않은 외부 업체로 전달된다면 문제가 된다.

마인드 로그에서 다루는 정보는 성격이 다르다. 개인의 경험과 생각, 인간관계, 공개하고 싶지 않은 사건이 중심이 될 수 있다. 유출의 영향도 금전적 손실에만 머물지 않는다. 관계가 손상되거나, 일상에서 불안과 불편을 겪을 수도 있다.

두 서비스를 설계할 때 확인할 질문을 나란히 놓으면 공통점이 분명해진다.

보호 원칙은 공통으로 적용하되, 구체적인 통제는 데이터의 성격과 예상 피해에 맞춰 설계해야 한다.

기업용 서비스라는 이유로 반드시 모든 개인 서비스보다 높은 보호 수준이 필요한 것도 아니고, 개인용 서비스라는 이유로 가볍게 다뤄도 되는 것도 아니다. 어떤 사람에게는 회사의 문서보다 자신의 하루를 적은 몇 문장이 훨씬 더 민감할 수 있다.

여기서 보안과 개인정보 보호를 함께 생각해야 한다.

보안은 권한 없는 접근과 변경, 손실을 막는 문제를 다룬다. 개인정보 보호는 적절한 목적과 범위 안에서 정보를 수집하고 사용하며, 그 과정을 당사자가 이해하고 통제할 수 있도록 하는 문제까지 포함한다.

암호화가 잘되어 있어도, 서비스 제공에 필요하지 않은 기록을 과도하게 모으거나 사용자가 예상하지 못한 목적으로 이용한다면 설명해야 할 문제가 남는다.

3. 첫 번째 작업은 데이터의 전체 경로를 그리는 것이다

보안을 설계하려면 먼저 어떤 데이터가 어디에 존재하는지 알아야 한다.

데이터베이스에 저장된 원문만 살펴보면 전체 그림을 놓치기 쉽다. 요청을 처리하는 서버, 작업 큐, 검색 색인, 오류 분석 도구, 백업, 외부 처리업체에도 데이터가 남을 수 있다. FTC의 기업용 정보보호 안내 역시 정보의 종류와 위치, 흐름을 파악하고 필요한 정보만 수집·보관하는 것을 출발점으로 제시한다.

마인드 로그와 같은 서비스를 검토한다면 다음 항목을 하나씩 확인할 수 있다.

아래 표는 실제 수집 목록이 아니라, 해당 기능을 사용하는 경우 확인해야 할 항목이다.

특히 파생 데이터는 별도로 살펴야 한다.

원문을 삭제했더라도 그 원문에서 만든 요약이나 검색 색인이 남아 있을 수 있다. 검색용 임베딩도 원문과 다른 형태라는 이유만으로 익명 정보라고 가정할 수 없다. 벡터를 통해 민감한 정보가 드러나거나, 접근 권한이 다른 데이터가 검색 결과에 섞이는 위험을 고려해야 한다.

만약 개인 기록을 분석해 감정이나 건강과 관련된 상태를 추정하는 기능을 도입한다면, 사용자가 직접 입력한 내용에 더해 서비스가 새로 만들어 낸 정보도 관리 대상이 된다.

데이터 흐름을 그리면 질문이 구체적으로 바뀐다

다음은 클라우드 저장과 외부 분석 기능을 사용하는 경우의 개념적인 흐름이다.

문서나 일상 기록은 인증과 원본 저장을 거친다. 외부 처리가 필요하면 수신자와 사용자 선택을 확인한 뒤 승인된 업체로 가고, 아니면 내부에서 처리한다. 결과는 권한 있는 사용자에게 제공되고, 원본과 결과는 보관·삭제·백업으로 이어진다.

이 그림에서 화살표 하나마다 확인할 것이 있다.

왜 이 데이터가 이동하는가? 전체 원문이 필요한가? 누가 수신하는가? 실패했을 때 다른 경로로 전송되는가? 처리 결과와 원본은 언제까지 남는가?

예를 들어 제안서의 일정만 검토하는 작업이라면 내부 예산 전체가 필요한지 따져 볼 수 있다. 특정 일상의 기록 하나를 요약하는 기능이라면 이전의 모든 기록까지 함께 전달해야 하는지 확인할 수 있다.

이렇게 처리 단위로 좁혀 보면 “보안을 잘해야 한다”는 말이 실제 설계 결정으로 바뀐다.

4. 로그인이 되어 있다는 사실과 데이터를 볼 권한은 별개로 확인해야 한다

여러 사용자가 로그인할 수 있다는 것은 사용자 식별의 출발점이다. 그 사용자가 어떤 데이터에 어떤 행동을 할 수 있는지는 별도로 검증해야 한다.

기업용 서비스에서는 다음과 같은 관계가 있다.

• 어느 고객사에 소속되어 있는가?
• 어느 프로젝트에 참여하는가?
• 해당 문서를 읽거나 수정할 수 있는가?
• 보고서를 만들거나 외부로 공유할 수 있는가?

마인드 로그에서는 기본적으로 기록의 소유 관계를 확인해야 한다. 모든 일반 사용자에게 user라는 역할이 있다고 해서 모든 기록에 같은 권한이 생겨서는 안 된다.

권한은 요청마다, 대상 데이터마다, 수행하려는 행동마다 확인하는 구조가 필요하다. OWASP도 기본 거부, 최소 권한, 요청별 권한 검사를 핵심 원칙으로 제시한다.

구현에서는 다음과 같은 지점이 중요하다.

첫째, 사용자 식별을 클라이언트가 보내는 값에 맡기지 않는다.

요청에 포함된 user_id나 tenant_id를 그대로 신뢰하면 안 된다. 서버가 검증한 로그인 정보와 실제 소속·소유 관계를 기준으로 접근 범위를 결정해야 한다.

둘째, 조회 화면 밖에서도 같은 규칙을 적용한다.

검색, 수정, 삭제, 내보내기, 첨부파일 다운로드, 비동기 작업, 공유 링크 모두 권한 검사의 대상이다. 화면에서 보이지 않는다는 사실만으로 접근이 차단되는 것은 아니다.

셋째, 권한 변경이 사본과 대기 중인 작업에도 반영되도록 한다.

퇴사한 직원의 접근 권한을 회수했는데 기존 다운로드 링크가 계속 작동하거나, 개인 기록에 대한 접근 설정을 바꿨는데 이미 등록된 작업이 이전 권한으로 실행된다면 경계가 일관되지 않다.

고객사별 분리는 데이터베이스 외에도 캐시, 파일 저장소, 작업 큐, 검색 시스템에 적용해야 한다.

데이터베이스의 행 단위 접근 정책도 도움이 될 수 있다. 다만 PostgreSQL의 RLS를 사용한다면 슈퍼유저, BYPASSRLS 권한, 테이블 소유자의 동작을 이해해야 한다. 기능을 켰다는 사실만으로 애플리케이션의 모든 경로가 보호되는 것은 아니다. 운영 요청을 처리하는 계정과 스키마를 변경하는 계정의 권한을 분리하는 이유도 여기에 있다.

계정 자체의 보호도 함께 설계해야 한다. 관리 계정의 다중 인증, 세션 만료와 철회, 계정 복구, 민감한 작업 전의 재인증 등을 서비스의 위험에 맞춰 검토할 수 있다.

5. “암호화되어 있습니다”라는 설명에는 범위가 필요하다

암호화는 중요한 보호 수단이다. 다만 무엇을, 어느 구간에서, 누구의 키로 암호화하는지 설명할 수 있어야 한다.

저장 중인 데이터와 이동 중인 데이터

저장 중 암호화는 저장 매체나 사본이 노출되는 위험을 줄이는 데 도움이 된다. 전송 중에는 브라우저와 서버 사이뿐 아니라 서버와 데이터베이스, 외부 API 사이의 통신도 보호해야 한다. TLS를 적용할 때는 인증서 검증과 각 통신 구간의 설정까지 확인해야 한다.

그러나 서비스가 데이터를 분석하려면 어느 시점에는 내용을 읽을 수 있어야 할 수 있다.

서버가 복호화 권한을 가지고 있다면, 저장된 데이터가 암호화되어 있어도 실행 중인 서비스는 내용을 처리할 수 있다. 따라서 암호화와 함께 키 접근 권한, 서비스 계정, 관리자 권한, 운영 절차를 검토해야 한다.

고객이 관리하는 키를 사용하는 CMEK 같은 방식도 키에 대한 통제를 강화할 수 있지만, 서비스가 그 키를 이용해 데이터를 복호화하는 구조라면 곧바로 “서비스 제공자는 내용을 읽을 수 없다”는 뜻이 되지는 않는다.

운영자도 내용을 볼 수 없게 하려면

“다른 사용자에게 비공개”와 “운영자도 읽을 수 없음”은 서로 다른 설계 목표다.

운영자의 일반 업무에서 내용 열람을 막으려면 관리 화면을 제한하고, 지원 업무에 필요한 접근을 별도로 승인하며, 접근 기록을 남기는 방식이 필요할 수 있다.

운영자에게 복호화 능력 자체를 주지 않으려면 키의 생성·보관·복구와 클라이언트의 신뢰 구조까지 검토해야 한다. 사용자 단말에서 암·복호화하는 방식을 선택한다면, 일반적인 서버 측 검색이나 AI 분석을 어떻게 제공할지도 함께 결정해야 한다.

가능한 선택에는 단말 내 처리, 사용자가 지정한 일부 데이터만 별도로 외부 처리하는 방식 등이 있다. 어느 방식을 택하든 사용자에게 약속하는 보호 범위와 실제 처리 방식이 맞아야 한다.

브라우저에서 암호화를 수행하는 경우에는 실행되는 자바스크립트의 무결성도 중요하다. W3C의 Web Cryptography 설명 역시 악의적인 스크립트가 실행될 수 있는 환경에서 암호 API만으로 데이터를 보호할 수 없다는 점을 다룬다.

기밀 컴퓨팅이나 격리 실행 환경을 검토할 수도 있다. 이 경우에도 어떤 운영자와 어떤 공격으로부터 보호하는지, 승인된 프로그램이 무엇을 할 수 있는지, 처리 결과가 어디로 나가는지 확인해야 한다. 격리된 환경 안에서 실행된다는 사실만으로 애플리케이션의 모든 동작이 적절해지는 것은 아니다.

또 하나 중요한 질문이 있다.

계정을 복구할 수 있다는 것과, 암호화 키를 잃어버린 기록을 복구할 수 있다는 것은 같은가?

이 둘의 관계는 선택한 키 관리 방식에 따라 달라진다. 복구할 수 있는 것과 없는 것을 실제 설계에 맞춰 설명해야 한다.

6. 외부 서비스를 연결하는 순간, 데이터의 경계를 다시 확인해야 한다

현실의 서비스는 여러 업체의 기능을 조합해 만들어지는 경우가 많다.

클라우드 저장소, 인증 서비스, 문서 변환, 음성 전사, AI 모델, 임베딩 생성, 오류 분석, 고객지원 도구가 그 예다. 어떤 기능을 사용하는지에 따라 원문이나 일부 메타데이터가 외부에서 처리될 수 있다.

이때 서로 다른 약속을 구분해야 한다.

‘학습에 사용하지 않음’만으로 보관 여부나 처리 위치까지 설명되지는 않는다. 실제 AI 서비스의 공식 문서에서도 학습, 보관, 상태 유지 기능, 악용 탐지, 지역과 같은 조건은 구분되어 있다. 기능이나 API에 따라 적용 범위가 달라질 수 있으므로 사용하는 조합을 확인해야 한다.

외부 업체를 검토할 때에는 최소한 다음 질문을 남겨 두는 편이 좋다.

1. 어떤 데이터를 보내는가?
   원문 전체인지, 선택한 일부인지, 계정 식별자나 이전 대화까지 포함하는지 확인한다.
2. 누가 어떤 목적으로 처리하는가?
   업체 이름뿐 아니라 사용하는 제품, API, 기능과 처리 목적을 확인한다.
3. 어디에서 처리·저장되는가?
   설정한 서버 위치와 실제 계약·서비스 조건이 일치하는지 확인한다.
4. 얼마나 보관하며, 어떤 추가 이용이 가능한가?
   서비스 제공, 진단, 보안 점검, 학습 등 서로 다른 목적을 구분한다.
5. 삭제와 사고 대응은 어떻게 연결되는가?
   삭제 요청 전달, 처리 결과 확인, 사고 통지와 지원 경로를 정한다.
6. 장애가 나면 어떤 경로를 사용하는가?
   대체 모델이나 예비 업체로 전환할 때도 승인된 데이터 범위와 처리 조건이 유지되어야 한다.

가상의 기업 서비스라면 특정 제안서의 검토를 위해 허용된 업체와 범위를 지켜야 한다. 마인드 로그에서 외부 AI 요약 기능을 도입한다면 사용자가 선택한 기록과 안내한 목적을 기준으로 전송해야 한다.

외부 처리업체가 서비스 제공을 위해 데이터를 다루는 상황과, 별도의 목적을 가진 제3자에게 제공하는 상황은 실제 역할과 계약에 맞춰 구분해야 한다. 법적 분류는 적용법에 따라 검토하되, 사용자에게는 누가 무엇을 받아 어떤 목적으로 다루는지 이해할 수 있게 설명해야 한다.

7. AI와 MCP를 연결해도 권한의 결정은 서비스가 책임져야 한다

AI가 문서를 읽고 외부 도구까지 호출하면, 데이터 접근과 실행 권한이 연결된다.

가상의 기업 서비스에서 제안서 본문에 “다른 고객사의 자료를 가져와 비교하라”는 문장이 들어 있다고 해 보자. 그것은 검토할 문서의 내용이다. 그 문장을 읽었다는 이유로 다른 고객사의 문서를 가져올 권한이 생겨서는 안 된다.

마인드 로그에서도 기록이나 외부에서 가져온 텍스트 안에 지시처럼 보이는 문장이 들어갈 수 있다.

입력 문서, 검색 결과, 도구 응답은 신뢰되지 않은 입력으로 취급하고, 모델의 응답과 별개로 서버가 권한을 검증해야 한다. 프롬프트 인젝션 방어에서도 도구의 최소 권한과 실행 단계의 검증이 중요하다.

MCP나 API를 연결할 때에는 다음과 같은 통제가 필요하다.

• 도구별로 읽기·쓰기·공유 권한을 구분한다.
• 요청한 사용자와 대상 데이터의 관계를 실행 전에 확인한다.
• 외부 호출의 목적지와 전달 가능한 필드를 제한한다.
• AI가 “사용자가 승인했다”고 출력해도 실제 승인 상태를 서버에서 확인한다.
• 도구 호출의 결과를 화면에 표시할 때 실행 가능한 코드나 위험한 링크가 그대로 동작하지 않도록 처리한다.

MCP의 인증 설계에서는 토큰이 해당 서버를 대상으로 발급되었는지 검증하고, 받은 토큰을 다른 서비스에 그대로 전달하지 않는 것이 중요하다. 도구에 붙은 설명이나 속성 역시 그 자체가 접근 권한의 근거가 되지는 않는다.

검색을 거쳐 AI에 전달하는 데이터도 같은 권한을 따라야 한다

저장된 자료를 검색해 AI에 전달하는 RAG 구조를 사용한다면, 원문의 접근 권한을 검색 조각과 관련 메타데이터에 연결해야 한다.

기업의 제안서뿐 아니라 내부 검토 기준도 해당 기업의 비공개 자료다. 서로 다른 고객사의 자료를 공용 참고 자료처럼 취급해서는 안 된다.

개인 기록에서도 사용자의 접근 범위를 먼저 적용한 뒤 허용된 자료만 모델에 전달해야 한다. 모델이 답변을 만드는 단계에서 알아서 걸러 주기를 기대하는 구조는 피해야 한다.

8. 개인 서비스에서는 사용자의 기기와 일상적인 화면도 살펴야 한다

마인드 로그처럼 사적인 내용을 다루는 서비스에서는 서버 밖의 경험도 중요하다.

예를 들어 가족과 함께 쓰는 기기에서 로그아웃했는데 이전 기록이 화면에 남아 있다면 어떨까. 알림 미리보기에 일기의 일부가 표시된다면 어떨까. 오류 보고 도구가 문제를 분석한다는 이유로 입력한 기록 전체를 전송한다면 어떨까.

지원하는 플랫폼과 기능에 따라 다음 항목을 확인할 수 있다.

• 공유 기기와 계정 전환: 로그아웃과 사용자 변경 뒤 화면·캐시에 이전 기록이 남는가?
• 알림: 알림 기능이 있다면 잠금 화면에서 민감한 내용이 노출되는가?
• 모바일 화면: 앱 전환 미리보기, 클립보드, 스크린샷 관련 동작을 검토했는가?
• 진단 도구: 오류 보고와 세션 재생 도구가 입력 내용이나 화면을 수집하는가?
• 로컬 저장: 기기에 저장한 데이터가 운영체제의 백업이나 별도의 동기화에 포함되는가?

OWASP의 모바일 보안 기준도 로그, 백업, 알림, 화면 캡처, 클립보드 등에서 발생할 수 있는 의도치 않은 노출을 검토하도록 한다.

모바일 앱을 제공한다면 “기기에만 저장한다”는 설명 역시 실제 백업 동작과 맞는지 확인해야 한다. 운영체제와 앱 설정에 따라 백업 대상과 보호 방식이 달라질 수 있다.

외부 SDK를 붙일 때에는 설정 화면에서 수집 제한을 켰다는 사실에 더해 실제 전송되는 내용을 확인하는 편이 좋다. SDK가 필요한 데이터만 받고 사용자의 선택을 존중하는지도 검토 대상이다.

개인 기록에는 작성자 외의 사람도 등장할 수 있다. 친구나 가족, 직장 동료의 이름과 상황이 적힐 수 있다. 검색·공유·외부 분석 기능을 설계할 때에는 그 기록이 작성자 한 사람에 관한 정보만 담고 있지는 않다는 점도 생각해야 한다.

9. 이용약관, 개인정보 처리방침, 기능 안내는 서로 다른 질문에 답한다

보안에 관한 설명을 이용약관 한 곳에 모두 넣으면 사용자가 필요한 순간에 필요한 내용을 이해하기 어렵다.

서비스에서는 다음 네 가지를 구분해 설계할 수 있다.

이용약관에서 정할 내용

마인드 로그와 같은 서비스라면 계정의 이용 조건, 사용자 콘텐츠에 관한 권리, 서비스를 제공하는 데 필요한 이용 권한의 범위, 계정 종료와 서비스 변경 등을 명료하게 정리할 수 있다.

기술적으로 어떤 처리가 필요한지와 사용자에게 요구하는 권한이 맞아야 한다. 기록을 저장하는 데 필요한 권한과, 그 기록을 다른 목적에 이용하는 권한을 뭉뚱그려 설명하지 않는 것이 중요하다.

개인정보 처리방침에서 설명할 내용

처리방침은 실제 데이터 흐름을 기반으로 작성해야 한다.

수집 항목과 목적, 필수·선택 처리의 구분, 외부 수신자와 역할, 보관 기준, 삭제 방식, 권리 행사 방법, 문의 경로 등이 실제 운영과 맞아야 한다.

“서비스 향상을 위해 정보를 활용할 수 있습니다” 같은 넓은 문장만으로는 사용자가 자신의 기록에 무슨 일이 생기는지 이해하기 어렵다.

필요한 순간에 보여 주는 안내

계정을 만들 때 긴 문서를 읽었다고 해서, 몇 달 뒤 처음 사용하는 분석 기능의 데이터 흐름까지 기억하고 있다고 기대하기는 어렵다.

외부 처리가 새로 발생하거나 처리 범위가 의미 있게 달라지는 기능이라면, 사용자가 결정하는 순간에 핵심 내용을 짧게 안내하고 상세 설명으로 연결할 수 있다. ICO는 개인정보 안내 방식으로 계층화된 설명, 대시보드, 적시 안내 등을 제시한다.

모든 처리를 한 번의 동의로 해결하려 하지 않는다

적용법과 처리 목적에 따라 필요한 법적 근거와 절차는 달라질 수 있다. 모든 처리가 항상 동의에만 근거하는 것도 아니다.

동의를 근거로 하는 처리라면 무엇에 대한 동의인지 분명히 하고, 필요한 선택을 일반 약관과 구분하며, 변경·철회 방법을 설계해야 한다. UK GDPR에 관한 ICO 안내도 개인정보 안내 의무와 동의를 구분하고, 다른 법적 근거가 적용되는 경우에도 명확한 설명이 필요하다고 설명한다.

사용자가 이해한 범위, 화면에서 선택한 범위, 서버가 실제로 실행하는 범위가 서로 일치해야 한다.

10. 마인드 로그에서 외부 AI 기능을 제공한다면, 이렇게 설명할 수 있다

가령 마인드 로그에 선택한 기록을 외부 AI로 요약하는 기능을 도입한다면 어떤 안내가 필요할까.

아래는 문구 구조의 예시다. 실제 업체, 전송 항목, 처리 위치, 보관·학습 조건을 확인한 뒤 대괄호 부분을 채워야 한다.

요약에 사용할 기록을 확인해 주세요
선택한 [기록의 정확한 범위]를 [처리업체명·서비스명]에 보내 요약합니다.
전달하는 정보
[본문·첨부파일·계정 식별 정보 등 실제 전달되는 항목]
처리 목적
[이 기능에서 수행할 구체적인 처리]
처리·저장 위치
[확인된 국가·지역과 필요한 상세 안내 링크]
보관 및 학습 이용 조건
[확인된 보관 기간·예외·학습 이용 여부]
이 기능을 사용하지 않을 경우
[실제로 제공할 수 있는 대안 또는 사용상의 제한]
[선택한 범위로 처리]　[취소]　[자세히 알아보기]

이 안내의 핵심은 버튼을 하나 더 만드는 데 있지 않다. 사용자가 이번 행동의 결과를 판단할 수 있게 하는 것에 있다.

반복해서 같은 조건으로 사용하는 기능이라면 매번 긴 설명을 다시 보여 줄 필요는 없을 수 있다. 대신 현재 설정을 확인하고 변경할 수 있는 위치를 제공하고, 범위나 목적이 바뀔 때 다시 검토할 수 있게 설계하는 편이 좋다.

기능에 필요한 처리와 선택적인 활용도 구분해야 한다. 예를 들어 제품 개선이나 모델 학습을 위한 별도 이용을 검토한다면, 기능 제공을 위한 처리와 같은 항목인 것처럼 묶어 설명해서는 안 된다.

화면의 선택은 서버에서 집행되어야 한다

사용자가 외부 분석을 끄면 해당 선택을 서버, 작업 큐, 재시도 작업, 예비 공급자 연결까지 반영해야 한다.

“분석 안 함”을 선택했는데 오류 분석 도구에 원문이 들어가거나, 대기 중이던 작업이 이전 설정으로 계속 실행된다면 화면과 실제 동작이 어긋난다.

사용자가 선택을 철회했을 때에도 이후의 처리 중단과 이미 전달된 데이터의 삭제는 구분해 다뤄야 한다. 외부 업체에 보낸 사본은 해당 업체의 삭제 경로와 처리 결과 확인이 필요하다.

또한 수집 당시 설명한 목적을 바꾸거나 새로운 활용을 추가할 때에는 적용되는 요구사항을 검토하고 사용자에게 적절히 알려야 한다. FTC는 AI 기업이 개인정보와 기밀성에 관해 한 약속을 지켜야 하며, 중요한 이용 조건을 숨기거나 조용히 바꾸는 행위가 문제가 될 수 있음을 강조한다.

11. 오래 보관할 기록과 짧게 남아야 할 사본을 구분한다

마인드 로그의 목적은 사용자가 자신의 일상을 기록하고 다시 돌아보게 하는 데 있을 수 있다. 그렇다면 사용자가 선택한 기록을 오랫동안 보관하는 것이 서비스의 가치와 연결될 수 있다.

그 목적과 별개로, 처리 과정에서 생기는 모든 데이터를 같은 기간 동안 보관해야 하는 것은 아니다.

원문, 임시 파일, 진단 로그, 외부 처리 사본은 각각 필요한 이유와 보관 기준이 다를 수 있다.

삭제는 여러 위치를 함께 다루는 작업이다

사용자가 기록 하나를 삭제하면 그 기록에서 만든 요약, 검색 색인, 캐시, 처리 대기 작업 등을 어떻게 다룰지 정해야 한다.

특히 삭제된 원문을 오래된 작업이 다시 처리해 파생 데이터를 만들어 내지 않도록 해야 한다.

백업은 별도의 운영이 필요하다. 백업에서 데이터가 제거되는 시점과 제한을 설명하고, 복원할 때 이미 삭제한 데이터가 다시 사용 가능한 상태로 돌아오지 않도록 절차를 마련해야 한다.

따라서 “삭제 완료”라는 문구가 무엇을 뜻하는지 정의해 둘 필요가 있다.

현재 서비스 화면과 운영 저장소에서 삭제된 상태인지, 외부 업체의 삭제까지 완료된 상태인지, 백업 만료는 별도 일정인지가 구분되어야 한다.

데이터가 사라지지 않게 하는 책임도 있다

기밀성만큼 무결성과 가용성도 중요하다.

기업 서비스에서는 어떤 문서와 내부 기준의 버전으로 검토 결과를 만들었는지 추적할 수 있어야 한다. 마인드 로그에서 AI가 요약이나 해석을 제공한다면 사용자가 작성한 원문과 서비스가 생성한 내용을 구분하는 편이 좋다.

백업은 존재 여부와 함께 복원 가능성을 확인해야 한다. 어느 정도의 데이터 손실까지 허용할지, 어느 시간 안에 복구할지 정하고 실제 복원 시험으로 확인할 수 있다.

사용자가 기록을 내보낼 수 있게 한다면, 내보내기 기능도 소유권 확인과 접근 제한의 대상이다. 편의 기능 하나가 대량 유출 경로가 되지 않도록 설계해야 한다.

12. 네트워크, 파일 처리, 개발·배포 과정에서도 같은 원칙을 유지한다

서비스의 보안은 데이터베이스 설정에서 끝나지 않는다. 입력을 받고, 파일을 처리하고, 코드를 배포하는 과정에도 경계가 필요하다.

네트워크와 외부 요청

들어오는 요청에는 인증과 권한 검사, 입력 검증, 필요한 속도 제한을 적용한다. 외부로 나가는 요청에는 허용된 목적지와 전송 범위를 정한다.

사용자가 입력한 URL을 서버가 가져오거나 AI 도구가 외부 주소를 조회한다면, 내부 서비스나 클라우드 메타데이터 주소로 접근하는 SSRF 위험을 고려해야 한다. 리다이렉트와 이름 해석을 포함한 검증이 필요할 수 있다.

업로드와 문서 변환

기업용 서비스에서 문서를 받거나, 개인 서비스에서 첨부파일을 지원한다면 파일의 확장자만 확인해서는 충분하지 않다.

파일 형식과 크기, 처리 자원, 변환 도구의 권한을 제한하고 필요에 따라 격리된 환경에서 처리한다. 기밀 파일을 외부 악성코드 검사 서비스에 전달하는 경우에는 그 전송 자체도 검토해야 한다. OWASP의 파일 업로드 안내 역시 이런 처리 단계와 정보 노출 위험을 다룬다.

개발과 배포

실제 고객 문서나 개인 일기를 개발 환경으로 복사해야 하는지 먼저 따져 보고, 가능한 경우 합성 데이터로 검증한다.

개발·시험·운영 환경을 분리하고, 비밀 키와 배포 권한을 제한하며, 의존성 변경과 설정 변경을 검토하는 절차를 갖춘다. 이러한 활동은 출시 직전 한 번의 점검에 그치지 않고 개발 과정에 포함되어야 한다. NIST의 SSDF도 안전한 소프트웨어 개발 활동을 개발 생명주기에 통합하는 틀을 제시한다.

배포 자동화에서는 지원되는 환경이라면 짧은 수명의 자격 증명을 활용할 수 있다. 다만 어떤 저장소와 워크플로가 어떤 운영 권한을 받을 수 있는지 신뢰 조건을 제한해야 한다.

로그와 사고 대응

문제를 조사하려면 기록이 필요하지만, 조사용 로그가 또 하나의 민감정보 저장소가 되지 않게 해야 한다.

누가 언제 어떤 대상에 어떤 작업을 했고 성공했는지 확인할 수 있도록 설계하되, 원문 전체, 비밀번호, 토큰, 비밀 키 등이 기본적으로 기록되지 않도록 한다. 로그 자체에도 접근 제한과 보관 기준이 필요하다.

사고가 발생했을 때의 담당자, 접근 차단, 자격 증명 폐기, 증거 보존, 외부 업체와의 연락, 복구와 사용자 통지 판단도 미리 정해 두는 편이 좋다. 사고 대응은 탐지 이후의 작업뿐 아니라 사전 준비와 복구까지 이어지는 운영 활동이다.

13. “민감한 내용”이라는 말과 법률상 분류를 구분해야 한다

사용자에게 민감한 정보와 법률이 특정하게 정의하는 민감정보는 항상 같은 범위가 아니다.

개인 기록에 건강이나 관계, 감정이 언급된다고 해서 모든 기록에 하나의 법적 분류를 일괄 적용할 수는 없다. 실제 수집 항목, 서비스가 만드는 추론, 처리 목적, 사업의 형태, 이용자와 사업자의 관할을 함께 검토해야 한다.

동시에 일반적인 일상 기록 서비스라는 이름만으로 관련 의무가 없다고 가정해서도 안 된다.

예를 들어 미국 워싱턴주의 My Health My Data 법은 적용 요건을 충족하는 경우 개인의 신체·정신 건강 관련 정보와 일정한 추론 정보를 폭넓게 다룬다. 또한 법이 요구하는 동의를 관련 없는 내용을 포함한 포괄적인 일반 약관 수락에서 얻는 방식에는 제한을 둔다.

이것이 현재 마인드 로그에 그 법이 적용된다는 판단은 아니다. 어떤 기능을 제공하고 어떤 데이터를 만들거나 수집하느냐에 따라 검토 범위가 달라진다는 예다.

건강 상태를 추론하는 기능, 광고를 위한 프로파일링, 새로운 외부 제공과 같은 변경을 검토한다면 기술적인 구현 계획과 함께 법적 요구사항과 사용자 설명도 다시 확인해야 한다.

14. 출시 전에는 약속과 동작을 함께 시험해 봐야 한다

정책 문서가 준비되었고 보안 기능을 설정했다면, 다음 단계는 실제 동작을 확인하는 것이다.

검토 항목을 구체적인 상황으로 바꾸면 무엇이 부족한지 찾기 쉬워진다.

이런 시험은 OWASP ASVS 같은 기준을 참고해 서비스에 맞게 확장할 수 있다. 중요한 것은 체크리스트를 채우는 데서 멈추지 않고, 실제로 보호해야 하는 경계가 유지되는지 확인하는 것이다.

기업용 서비스라면 담당자가 승인한 범위와 실제 문서 접근이 맞아야 한다. 마인드 로그라면 사용자가 자신의 기록에 대해 이해하고 선택한 범위가 실제 처리와 맞아야 한다.

15. 자연스럽게 기록하도록 권할수록, 우리는 더 구체적으로 설명해야 한다

마인드 로그처럼 개인의 일상을 기록하는 서비스를 생각하면 보안의 의미가 조금 더 가까워진다.

사용자가 남기는 문장은 시스템 안에서는 텍스트일 수 있다. 그러나 사용자에게는 그날의 경험이고, 관계이며, 다른 곳에서는 쉽게 꺼내지 못했던 생각일 수 있다.

기업의 문서도 마찬가지다. 업로드된 파일 하나에는 여러 사람이 준비한 계획과 협상 과정, 조직이 지켜야 할 약속이 담겨 있을 수 있다.

서비스를 만드는 사람은 그 내용을 유용하게 처리하는 능력과 함께, 그 내용을 맡을 준비가 되어 있는지를 계속 확인해야 한다.

어디에 저장되는지 알고 있는가. 누가 읽을 수 있는지 설명할 수 있는가. 외부 업체가 처리한다면 그 범위와 조건을 확인했는가. 사용자가 선택을 바꾸거나 삭제를 요청할 때 실제로 반영할 수 있는가.

그리고 이용약관과 개인정보 안내에 적힌 문장이 코드와 설정, 계약과 운영 절차에서 그대로 지켜지는가.

“부담 없이 기록하세요”라는 말을 하는 서비스라면, 기록을 맡긴 뒤의 부담을 줄이는 일도 함께 설계해야 한다.

나는 기업의 기밀문서와 개인의 일상을 같은 글에서 다루고 싶다. 두 영역 모두 데이터를 맡긴 사람에게 충분한 설명과 실질적인 통제권을 제공해야 하기 때문이다. 그 책임을 기능을 설계하는 처음부터 운영하는 마지막까지 가져가는 것이, 신뢰할 수 있는 서비스를 만드는 일이라고 생각한다.