top of page

Terms of Service와 Privacy Policy만으로는 부족하다? (Feat. DPA, AUP, 그리고 Cookie Policy)

3시간 전
5분 분량

미국 스타트업들이 웹사이트나 SaaS 서비스를 출시할 때 가장 먼저 준비하는 문서는 보통 이용약관(Terms of Service) 과 개인정보처리방침(Privacy Policy) 이다. 물론 이 두 문서는 매우 중요하다. 하지만 실제 서비스를 운영하다 보면 이것만으로는 부족한 경우가 많다. 특히 B2B SaaS, AI 서비스, 데이터 처리 플랫폼처럼 고객 데이터를 다루거나 다수의 사용자가 서비스를 이용하는 구조라면 데이터 처리 계약(Data Processing Addendum, “DPA”), 허용된 사용 정책(Acceptable Use Policy, “AUP”), 쿠키 정책(Cookie Policy) 등도 역시 중요한 역할을 한다.

​

이 문서들은 단순한 부속 문서가 아니다. 각각 개인정보 처리 책임, 서비스 오남용 통제, 온라인 추적기술의 투명성이라는 서로 다른 리스크를 관리한다.


DPA란?

​

DPA는 고객과 서비스 제공자 사이에서 개인정보를 어떻게 처리할 것인지 정하는 계약이다. 예를 들어 기업 고객이 SaaS 업체에 고객명, 이메일 주소, 직원정보 또는 이용자 데이터를 업로드하는 경우, SaaS 업체는 고객을 대신하여 개인정보를 처리하는 위치에 놓일 수 있다. 이때 본 계약이나 Terms of Service만으로는 데이터 처리와 관련된 책임관계가 충분히 명확하지 않을 수 있다.

​

DPA에는 일반적으로 다음과 같은 내용이 포함된다.

  • 어떤 개인정보를 처리하는지

  • 어떤 목적으로 처리하는지

  • 개인정보 처리 기간

  • 보안조치(Security Measures)

  • 하위처리업체(Subprocessor) 사용

  • 개인정보 침해사고(Data Breach) 발생 시 통지

  • 데이터 주체의 권리 요청에 대한 협조

  • 계약 종료 후 데이터 반환 또는 삭제

  • 국가 간 데이터 이전(Cross-Border Transfer)에 관한 사항

​

특히 GDPR에서는 controller와 processor 관계에서 계약에 포함되어야 할 사항을 구체적으로 요구하고 있다. 따라서 유럽 이용자 또는 유럽 고객 데이터를 처리하는 SaaS 기업이라면 DPA가 사실상 필수적인 경우가 많다.

​

미국에서도 DPA는 중요하다. 대형 기업 고객은 벤더 심사 과정에서 거의 항상 보안 및 개인정보 관련 계약을 요구하고, California 등 미국 주 개인정보법에 따라 service provider 또는 processor 관계를 적절히 계약으로 정리해야 하는 경우도 있다.

​

DPA는 언제 준비하는 것이 좋을까?

​

B2B SaaS라면 첫 대형 고객과 계약을 체결하기 전에 표준 DPA를 준비해 두는 것이 좋다. 준비가 되어 있지 않으면 고객이 자신의 DPA를 보내오게 되고, 결과적으로 서비스 제공자인 스타트업에게 과도하게 불리한 조건을 협상해야 하는 상황이 생길 수 있다.

​

따라서 회사가 실제로 어떤 데이터를 처리하고, AWS·Google Cloud·Stripe 등 어떤 하위처리업체를 사용하는지 먼저 파악한 뒤, 실제 서비스 구조에 맞는 표준 DPA를 만드는 것이 중요하다.


AUP란?

​

AUP는 서비스 이용자가 무엇을 해서는 안 되는지를 정하는 정책이다. Terms of Service가 서비스 이용관계 전반을 규정한다면, AUP는 그중에서도 특히 금지되는 이용행위(Prohibited Use) 를 구체적으로 정하는 문서라고 이해하면 쉽다.

​

대표적으로 다음과 같은 행위를 금지할 수 있다.

  • 불법적인 목적으로 서비스 이용

  • 타인의 지식재산권 침해

  • 스팸, 피싱, 악성코드 배포

  • 시스템 또는 네트워크에 대한 무단 접근

  • 보안기능 우회 또는 서비스 방해

  • 자동화된 방식의 과도한 scraping

  • 서비스 기능을 복제하거나 역설계하는 행위

  • 다른 이용자의 개인정보 침해

​

실제로 주요 클라우드 및 SaaS 사업자들도 AUP에서 불법행위, 무단접근, malware, spam, scraping, 시스템 교란 등을 별도로 금지하고 있다. AI 서비스의 경우에는 여기에 더해 위험한 콘텐츠 생성, 모델 악용, 개인정보 추출, 불법적 자동화 등 서비스 특성에 맞는 제한이 추가될 수 있다.

​

왜 Terms of Service 안에 전부 넣지 않을까?

​

물론 Terms of Service 안에 금지행위를 모두 넣을 수도 있다. 하지만 실제로는 AUP를 별도 문서로 두는 것이 관리하기 편한 경우가 많다. 서비스가 성장하면서 새로운 악용 사례가 발생하면 AUP만 업데이트하기가 쉽고, 고객 계약이나 Terms 전체를 매번 수정하지 않아도 된다. 특히 플랫폼, API, AI, 클라우드 서비스처럼 사용자 행동에 따라 법적·보안 리스크가 크게 달라지는 서비스라면 AUP를 별도 문서로 두는 것이 유용하다.


Cookie Policy란?

​

Cookie Policy는 웹사이트나 서비스가 사용하는 쿠키(cookie), 픽셀(pixel), SDK 및 기타 온라인 추적기술에 대해 설명하는 문서이다. 쿠키는 이용자의 브라우저에 저장되는 작은 정보로, 로그인 상태 유지, 사용자 설정 기억, 웹사이트 분석, 광고 타게팅 등에 사용될 수 있다. FTC 역시 쿠키가 사용자를 인식하고, 이용행태를 추적하며, 맞춤형 광고 등에 활용될 수 있다고 설명한다.

​

Cookie Policy에는 일반적으로 다음과 같은 내용이 포함된다.

  • 어떤 종류의 쿠키를 사용하는지

  • 필수 쿠키와 비필수 쿠키의 구분

  • 분석용 쿠키

  • 광고·마케팅용 쿠키

  • 제3자 쿠키 제공자

  • 쿠키의 보관기간

  • 이용자가 쿠키 설정을 변경하는 방법

​

특히 Google Analytics, Meta Pixel, LinkedIn Insight Tag, HubSpot과 같은 도구를 사용하는 경우에는 실제로 어떤 데이터가 수집되고 누구에게 전달되는지 확인해야 한다.


Cookie Policy와 Privacy Policy는 같을까?

​

둘은 겹치는 부분이 있지만 역할이 다르다. Privacy Policy는 회사가 개인정보를 어떻게 수집·이용·공유하는지를 전체적으로 설명하는 문서이고, Cookie Policy는 그중에서도 웹사이트의 쿠키와 추적기술에 보다 구체적으로 초점을 맞춘 문서이다. 따라서 Cookie Policy를 Privacy Policy 안에 포함할 수도 있고 별도 문서로 만들 수도 있다. 중요한 것은 문서 형식보다 실제 웹사이트에서 사용되는 추적기술이 정확하게 반영되어 있는지이다.

​

특히 유럽 및 영국 규제를 고려해야 하는 경우에는 비필수 쿠키를 사전에 설정하기 전에 이용자의 유효한 동의를 받아야 하는 상황이 많다. 단순히 Privacy Policy 어딘가에 쿠키 사용 사실을 기재하는 것만으로는 충분하지 않을 수 있다. 영국 ICO 역시 비필수 쿠키에 대해서는 사용자가 명확한 적극적 행동을 통해 동의해야 한다고 설명한다.


이 문서들은 언제부터 준비해야 할까?

​

모든 스타트업이 설립 직후부터 DPA, AUP, Cookie Policy를 전부 준비해야 하는 것은 아니다. 오히려 회사의 서비스 구조에 따라 우선순위를 정하는 것이 현실적이다.

​

B2B SaaS이면서 고객의 개인정보를 처리한다면 DPA의 우선순위가 높다. 이용자가 콘텐츠를 업로드하거나 API·AI 기능을 자유롭게 사용할 수 있는 플랫폼이라면 AUP가 중요하다. 웹사이트에서 분석도구나 광고 추적기술을 적극적으로 사용한다면 Cookie Policy와 Consent Banner를 함께 검토해야 한다.

​

즉, 단순히 “우리도 문서를 하나 만들어 두자”가 아니라 실제 서비스에서 어떤 데이터가 수집되고, 사용자가 무엇을 할 수 있으며, 어떤 외부 업체가 관여하는지를 먼저 파악해야 한다.

​

가장 흔한 실수는 다른 업체의 양식을 복사해서 만드는 것!

​

DPA, AUP, Cookie Policy는 다른 회사 문서를 복사해 만들기 특히 위험한 문서들이다. 예를 들어 실제로는 사용하지 않는 subprocessor가 DPA에 들어가 있거나, 반대로 실제 사용하는 클라우드 업체가 빠져 있을 수 있다. Cookie Policy에는 Google Analytics를 사용하지 않는다고 되어 있는데 실제 웹사이트에서는 추적하고 있을 수도 있다.

​

AUP 역시 서비스 특성에 맞지 않는 금지행위를 그대로 가져오면 실제 위반 상황에서 집행하기 애매해질 수 있다. 특히 개인정보 관련 문서는 단순히 그럴듯 해 보이는 문구보다 실제 회사의 데이터 흐름(Data Flow) 과 일치하는지가 훨씬 중요하다. FTC 역시 기업에게 어떤 개인정보를 수집하고 어디에 저장하며 어떤 외부 업체가 이를 처리하는지 먼저 파악하도록 권고한다.


실무적으로 어떻게 준비하면 좋을까?

​

가장 좋은 방법은 먼저 간단한 내부 점검부터 하는 것이다. 회사가 어떤 개인정보를 수집하는지, 어디에 저장하는지, 어떤 SaaS·클라우드·결제·분석 업체에 전달하는지 정리한다. 그 다음 고객 데이터 처리 여부, 사용자 생성 콘텐츠, API 사용 방식, 웹사이트 추적도구를 확인한다. 그 내용을 바탕으로 Terms of Service와 Privacy Policy뿐 아니라 DPA, AUP, Cookie Policy가 서로 모순되지 않도록 작성하는 것이 중요하다.

​

예를 들어, Privacy Policy에서는 데이터를 제3자에게 제공하지 않는다고 해놓고 DPA에는 여러 subprocessors가 기재되어 있거나, AUP에서는 특정 자동화 행위를 금지하지만 실제 제품은 해당 기능을 적극적으로 제공하는 식의 불일치가 없어야 한다.



Terms of Service와 Privacy Policy는 온라인 서비스를 운영하는 데 필요한 기본 문서이다. 하지만 서비스가 성장하고 고객 데이터, 사용자 콘텐츠, 분석 및 광고기술을 적극적으로 활용하기 시작하면 그것만으로는 충분하지 않은 경우가 많다.

​

DPA는 고객 데이터를 어떻게 처리할 것인지, AUP는 사용자가 서비스를 어떻게 사용해서는 안 되는지, Cookie Policy는 웹사이트에서 어떤 추적기술을 사용하는지를 각각 규율한다.

​

결국 중요한 것은 문서의 숫자를 늘리는 것이 아니다. 회사의 실제 데이터 흐름과 서비스 구조를 파악한 뒤, 그에 맞는 문서를 준비하는 것이다.

​

초기 스타트업일수록 Terms of Service와 Privacy Policy만 작성하고 끝내기보다, 우리 서비스에는 DPA, AUP, Cookie Policy 중 어떤 것이 필요한지 한 번쯤 점검해 보는 것이 향후 엔터프라이즈 고객 계약이나 개인정보 컴플라이언스 과정에서 상당한 시간과 비용을 줄여줄 수 있다.

최근 게시물

전체 보기
미국 SEC Form D, 자주 묻는 질문 (FAQ)

미국에서 스타트업을 운영하면서 투자를 받거나, 또는 미국 스타트업에 투자를 진행할 경우 SEC Form D 파일링 이야기를 자주 접하게 될 것이다. 단순한 신고처럼 보여도 제출 기한, 수정 신고 여부, 주별 Blue Sky Filing과의 관계 등 실무상 헷갈리는 부분이 적지 않다. ​ 이번 글에서는 SEC의 Form D FAQ를 바탕으로, 스타트업과 투자

 
 
 
업무 중 작성한 AI 프롬프트는 누구의 것일까? (Feat. 생성형 AI 시대의 업무상 창작물과 소유권 문제)

ChatGPT, Claude, Gemini와 같은 생성형 AI가 업무 현장에 빠르게 도입되면서 새로운 법적 질문들이 등장하고 있다. 그중 최근 기업들이 관심을 갖기 시작한 주제 중 하나가 바로 “직원이 업무 중 작성한 프롬프트(prompt)의 권리는 누구에게 귀속되는가?”라는 문제이다. ​ 불과 몇 년 전만 하더라도 직원이 작성하는 업무 결과물이라고 하면

 
 
 

댓글


bottom of page