서비스 약관과 이용약관, 차이가 있을까요?

게시하기 전에 다음 목록을 확인하세요.

1. 제품 유형과 독자에 맞춰 대표 이름 하나를 고릅니다.
2. 푸터, 가입 절차, 결제, 앱 스토어 등록 정보, 거래 관련 이메일에서 정확히 그 이름을 사용합니다.
3. EULA나 허용 가능한 이용 정책도 사용한다면, 주 약관에 그 문서들의 관계와 충돌 시 어느 문서가 우선하는지를 명시합니다.
4. 새 서비스 약관(Terms of Service) 페이지 옆에 예전 이용약관(Terms of Use) 페이지를 그대로 두지 마세요. 리디렉션하거나 시행일과 함께 보관 처리하세요.
5. 문서에 계약 당사자의 정확한 법인명과 연락처가 적혀 있는지 확인합니다.
6. 모든 버전에 날짜를 적고 각 버전의 사본을 보관합니다.

마지막 단계는 잊기 쉽고, 나중에 되살리기는 고통스럽습니다. 2년 전 구매에 관한 분쟁이 생기면 오늘 게시된 버전이 아니라 그 사용자가 당시 동의한 버전이 필요합니다. 날짜가 적힌 사본을 모은 간단한 보관 폴더와 각 계정이 어떤 버전을 수락했는지에 대한 기록만으로도 소규모 사업자에게는 대개 충분하며, 아무것도 없는 것보다 훨씬 낫습니다.

짧게 답하면, 일반적인 법적 의미에서는 없습니다. 계약법은 페이지 제목이 아니라 당사자가 무엇에 합의했는지를 봅니다. 명확한 수락 절차와 공정한 조항을 갖춘 이용약관(Terms of Use)이라는 제목의 문서가 아무도 읽으라는 요청을 받은 적 없는 서비스 약관(Terms of Service) 페이지보다 더 큰 힘을 가집니다.

흔히 쓰이는 세 가지 이름은 강조점이 조금씩 다르다는 신호를 주는 경향이 있습니다.

• 서비스 약관(Terms of Service)은 SaaS 제품, 플랫폼, 온라인 계정처럼 지속적인 서비스를 떠올리게 합니다.
• 이용약관(Terms of Use)은 웹사이트, 앱, 콘텐츠를 이용하는 규칙을 떠올리게 하며, 대개 결제가 없는 경우입니다.
• 약관 및 조건(Terms and Conditions)은 가장 포괄적인 이름으로, 온라인 쇼핑몰과 영국식 영어에서 흔히 쓰입니다.

이는 관행일 뿐 규칙이 아닙니다. 대기업은 세 가지를 모두 사용하며, 때로는 구조가 거의 같은 문서에 쓰기도 합니다. 구독을 판매하면서 계약을 이용약관(Terms of Use)이라고 불러도 아무 문제가 없습니다.

정말 문제가 되는 것은 서로 다른 이름으로 상충하는 규칙을 담은 두 문서를 게시하는 경우입니다. 예를 들어 이용약관(Terms of Use) 페이지는 30일 이내 환불을 약속하고 서비스 약관(Terms of Service) 페이지는 모든 환불을 거부하는 식입니다. EU와 영국의 소비자 계약에서는 표준 약관의 모호함을 소비자에게 유리하게 해석하므로, 이런 혼란은 사업자에게 손해가 됩니다.

사용자가 기대하는 이름을 고른 다음 푸터 링크, 가입 체크박스, 결제, 이메일, 앱 스토어 등록 정보 등 모든 곳에서 그 이름을 사용하세요. 어떤 이름을 고르느냐보다 일관성이 더 중요합니다.

제품 유형별 실무 가이드:

• 온라인 쇼핑몰: 약관 및 조건(Terms and Conditions)을 쓰고, 때로는 구매 규칙을 위한 판매 약관(Terms of Sale)을 함께 둡니다. 전자상거래 이용약관 생성기를 참고하세요.
• SaaS 또는 구독 제품: 서비스 약관(Terms of Service)을 쓰며, 규모가 큰 기업 고객에게는 주문서나 별도 계약을 함께 쓰는 경우가 많습니다.
• 콘텐츠 웹사이트나 블로그: 콘텐츠 소유권, 허용되는 이용, 외부 링크에 초점을 맞춘 이용약관(Terms of Use)을 씁니다.
• 모바일 앱이나 게임: 서비스 약관(Terms of Service)이나 이용약관(Terms of Use)에 이용 허락 조항을 더합니다. 바로 여기서 EULA 문제가 등장합니다.
• 커뮤니티나 마켓플레이스: 서비스 약관(Terms of Service)을 쓰며, 커뮤니티 가이드라인이나 판매자 약관을 참조 방식으로 편입하는 경우가 많습니다.

다른 언어에는 각자의 이름이 있습니다. 독일 기업은 Allgemeine Geschäftsbedingungen을, 체코 기업은 obchodní podmínky를 게시하지만, 모든 고객에게 제시하는 표준 약관이라는 역할은 같습니다.

확신이 서지 않는다면 온라인 제품에는 서비스 약관(Terms of Service)이 가장 널리 통용되는 일반적인 선택입니다.

최종 사용자 사용권 계약, 즉 EULA는 이용 허락입니다. 사업자나 그 라이선서가 소유한 소프트웨어 사본을 설치하고 사용할 수 있는 권한을 사용자에게 부여합니다. 일반적인 EULA 조항은 다음을 다룹니다.

• 사용자가 소유하거나 관리하는 기기에서의 개인적이고 양도할 수 없는 사용 등 이용 허락의 범위
• 복제, 수정, 재배포, 리버스 엔지니어링에 대한 제한
• 소프트웨어와 그 업데이트의 소유권
• 이용 허락의 종료
• 보증 부인과 책임 제한

서비스 약관은 계정, 행위, 사용자 콘텐츠, 결제, 모더레이션, 지원 등 지속적인 서비스와의 관계를 규율합니다. 요즘 많은 제품은 소프트웨어이면서 서비스이기도 해서, 약관에 이용 허락 섹션을 넣고 별도의 EULA는 두지 않습니다.

한 가지 주의할 점이 있습니다. 일부 제한은 사업자가 마음대로 부과할 수 없습니다. EU에서는 소프트웨어 지침 2009/24/EC에 따라 적법한 사용자가 필요한 백업 사본을 만들거나, 프로그램의 작동 방식을 관찰하고 테스트하거나, 좁은 상호운용성 예외 범위 내에서 디컴파일하는 것을 막는 계약 조항은 무효입니다. 예외 없이 모든 리버스 엔지니어링을 금지하는 EULA는 이러한 경우에 아예 적용되지 않을 수 있습니다.

사용자가 설치한 소프트웨어가 서버 개입이 거의 또는 전혀 없이 계속 작동하는 경우, 즉 데스크톱 애플리케이션, 다운로드형 게임, 플러그인, 온프레미스 도구, 오프라인 모바일 앱이라면 전용 EULA가 필요할 가능성이 가장 큽니다.

앱 스토어는 상황을 바꿉니다. Apple은 App Store Connect에서 맞춤 EULA를 제공하지 않는 한 App Store 앱에 표준 EULA로 알려진 자체 Licensed Application End User License Agreement를 적용합니다. 맞춤 EULA에는 계약이 Apple이 아니라 사업자와 사용자 사이에 체결된다는 확인 등 Apple의 최소 조건이 포함되어야 합니다.

Google Play에서는 개발자 배포 계약(Developer Distribution Agreement)에 따라 앱에 자체 EULA를 첨부할 수 있으며, Google Play 자체 약관이 사용자가 그곳에서 얻은 콘텐츠에 대한 기본 이용 허락을 부여합니다.

계정이나 구독도 운영하는 대부분의 앱에서는 소프트웨어에 대해 스토어 사용권 계약이나 맞춤 EULA에 의존하고, 서비스 자체에 대해서는 서비스 약관을 게시하는 것이 실무적인 답입니다. 앱 이용약관 가이드에서 각 링크를 어디에 표시해야 하는지를 포함해 이 구성을 자세히 다룹니다.

규모가 큰 서비스는 약관을 여러 문서로 나누는 경우가 많습니다. 각 문서는 대개 참조 방식으로 편입되는데, 이는 주 약관에서 다른 문서가 계약의 일부를 이룬다고 명시한다는 뜻입니다.

• 허용 가능한 이용 정책(acceptable use policy): 금지 행위를 자세히 나열한 목록으로, 호스팅, API, AI 제품에서 흔히 쓰입니다.
• 커뮤니티 가이드라인: 게시, 댓글, 상호작용에 관한 쉬운 규칙으로, 모더레이션 결정을 뒷받침합니다.
• 판매 약관: 주문, 배송, 반품, 환불에 관한 구매 규칙입니다.
• 구독 또는 결제 약관: 갱신, 해지, 체험판, 가격 변경을 다룹니다.
• 개인정보처리방침: 계약의 일부는 전혀 아니지만 계약에서 링크됩니다.

문서를 나누면 어떤 영역이 자주 바뀌거나 마켓플레이스의 판매자처럼 별도의 독자가 있을 때 도움이 됩니다. 반면 여러 문서가 같은 주제를 다른 표현으로 반복하면 해가 됩니다. 좋은 원칙은 각 주제가 정확히 한 문서에만 있고 나머지 문서는 그곳으로 링크하는 것입니다.

EU 사용자의 콘텐츠를 모더레이션한다면 디지털 서비스법(Digital Services Act)이 콘텐츠 제한과 모더레이션 절차를 이용약관에 설명하도록 요구한다는 점을 기억하세요. 따라서 주 약관은 별도의 가이드라인을 명확히 가리켜야 합니다.

미국 법원은 20년 동안 온라인 계약을 제시 방식에 따라 분류해 왔으며, 결과를 좌우한 것은 한 번도 문서의 이름이 아니었습니다.

• 클릭랩(Clickwrap): 사용자가 링크된 약관에 동의한다고 분명히 적힌 상자에 체크하거나 버튼을 클릭합니다. 고지가 명확하면 법원은 대체로 이를 집행합니다.
• 사인인랩(Sign-in-wrap): 가입 버튼 근처의 고지에 계속 진행하면 동의하는 것이라고 적혀 있습니다. 결과는 고지가 얼마나 눈에 잘 띄는지에 달려 있습니다.
• 브라우즈랩(Browsewrap): 약관이 사이트 어딘가에 링크만 되어 있고, 이용하면 수락한 것으로 본다고 합니다. 법원은 이를 집행하기를 꺼리는 경우가 많습니다.

Specht v. Netscape (2d Cir. 2002) 사건에서 무료 소프트웨어를 다운로드한 사용자들은 다운로드 버튼 아래로 스크롤해야만 볼 수 있었던 사용권 조건에 구속되지 않았습니다. Nguyen v. Barnes & Noble (9th Cir. 2014) 사건에서는 웹사이트 하단에 링크된 약관이 쇼핑객이 그 약관을 알았다는 증거가 없는 한 그를 구속하지 않았습니다. Berman v. Freedom Financial Network (9th Cir. 2022) 사건에서는 클릭이 곧 동의라는 점을 분명히 밝히지 않은 작은 회색 고지 문구로는 충분하지 않았습니다.

이 교훈은 어떤 이름을 쓰든 적용됩니다. 동의 시점에 약관을 명확히 제시하고 사용자가 동의했다는 사실을 기록하세요. 약관 작성 단계별 가이드에서 방법을 보여드립니다.

Legal Policy Generator는 답변에 따라 선택된 버전 관리 조항으로 서비스 약관(Terms of Service)을 만듭니다. 다른 곳에서는 이용약관(Terms of Use)이나 약관 및 조건(Terms and Conditions)이라고 부르는 바로 그 계약입니다. 실행 시점에 AI가 조항을 작성하지 않으므로 같은 답변은 언제나 같은 문서를 만듭니다.

설문은 제품이 실제로 어떻게 작동하는지 묻고, 해당하는 섹션만 활성화합니다.

• 계정, 이용 자격, 허용되는 이용
• 사용자 콘텐츠, 모더레이션, EU 디지털 서비스법(Digital Services Act) 정보
• 캘리포니아 자동 갱신 문구를 포함한 구독과 자동 갱신
• EU, 영국, 호주, 브라질, 캐나다, 뉴질랜드의 환불과 소비자 권리
• 미국 DMCA 통지와 미국 중재
• 책임, 분쟁, 약관 변경

설문과 전체 미리보기는 계정 없이 무료이며, 기본 HTML과 PDF 다운로드도 무료입니다. 고급 지역 모듈이나 선택 모듈은 $5입니다. 먼저 결과물이 어떤지 감을 잡고 싶다면 SaaS 약관 예시나 서비스 약관 템플릿 페이지를 읽어 보세요. 생성된 약관은 입력한 사실을 반영할 뿐이며 법률 자문이 아닙니다.