구독 계정 하나를 여러 명이 공유하면 좌석 비용을 줄일 수 있어 보이지만 실제 비용은 더 커질 수 있습니다. 서비스 약관 위반, 자격 증명 확산, 사용자별 추적이 어려운 로그, 퇴사 후 남는 권한이라는 네 가지 문제와 좌석 구매 등 적절한 대안을 설명합니다.
SaaS 도구에 사용자 좌석 하나를 추가하는 비용은 결코 작지 않을 수 있습니다. 팀원이 늘수록 이 비용은 더 뚜렷하게 느껴집니다.
그래서 하나의 로그인 정보를 함께 쓰는 방식이 자연스럽게 보일 수 있습니다. 특히 가끔 보고서를 확인하거나 잠시 고객을 위해 데이터를 검토하는 정도라면 더욱 그렇습니다. 하지만 그 대가는 자주 과소평가되며 서비스 약관, 자격 증명, 활동 로그, 팀 구성 변화 등 여러 영역에 흩어져 있습니다. 각 영역마다 서로 다른 문제가 생깁니다.
약관은 명확합니다: 계정은 공유하지 않는 것이 원칙입니다
대부분의 SaaS 제품은 사용자 좌석 단위로 라이선스를 제공합니다. 여러 사용자를 명시적으로 지원하는 엔터프라이즈 또는 팀 요금제를 제외하면, 다른 요금제는 일반적으로 한 명의 사용자만 쓰도록 제한됩니다. 서비스 약관에서는 여러 사람이 동일한 로그인 정보를 공유하는 행위를 명시적으로 금지하는 경우가 많고, 플랫폼은 이를 발견하면 접근을 일시 중지하거나 취소할 수 있습니다. 쉽게 놓치는 부분이 하나 있습니다. 이런 방식으로 이용이 종료되면 보통 환불이 제공되지 않아 이미 지불한 비용을 그대로 잃을 수 있습니다.
눈에 잘 띄지 않는 비용도 있습니다. 공유의 목적은 비용 절감이지만, 플랫폼이 접근 인원에 따라 요금을 받는 구조는 변하지 않습니다. 결국 절약한 금액은 라이선스 비용을 규정 위반 위험으로 바꾼 것에 가깝고, 문제가 생기기 전까지는 그 위험이 잘 보이지 않을 뿐입니다.
비밀번호를 여러 사람이 알면 누가 무엇을 했는지 알기 어렵습니다
공유를 하려면 비밀번호가 여러 사람 사이를 오가게 됩니다. 보통 메신저, 메모 같은 곳을 통해 전달되며, 한 번 남긴 내용이 오래 유지되는 기록이 되기 쉽습니다.
문제는 비밀번호 자체뿐 아니라 그로 인해 생기는 두 가지 결과입니다. 첫째, 노출 범위가 넓어집니다. 공유에 참여하는 사람이 많을수록 누군가가 같은 비밀번호를 다른 서비스에서 재사용했거나, 사용 중인 기기가 침해되어 계정의 진입점이 될 가능성이 커집니다. 둘째, 책임 소재를 확인하기 어려워집니다. 계정으로 데이터를 내보내거나 설정을 바꾸거나 보내면 안 되는 내용을 전송했을 때, 사후에 확인할 수 있는 것은 그 계정이 무엇을 했는지뿐이고 실제로 누가 실제로 조작했는지는 알기 어렵습니다. 고객에게 데이터 흐름을 설명해야 하는 팀에게는 특히 까다로운 문제입니다.
활동 로그는 사람보다 계정을 기록합니다
SaaS 관리 시스템의 활동 기록은 일반적으로 계정 단위로 저장됩니다. 누가 보고서를 내보냈는지, 어떤 설정을 바꿨는지, 어떤 데이터를 삭제했는지에 대한 기록도 결국 하나의 계정 이름으로 남는 경우가 많습니다.
여러 사람이 같은 계정을 사용하면 이러한 추적 가능성이 끊깁니다. 팀 내부에서도 누가 변경했는지 확인하기 어렵고, 플랫폼의 이상 탐지 시스템 역시 같은 문제를 겪습니다. 동일한 계정이 여러 도시, 여러 기기, 여러 네트워크 출구에서 로그인하고 동시에 여러 세션이 존재하면 플랫폼이 이를 이상 징후로 표시할 수 있습니다. 흔한 대응은 강제 로그아웃, 임시 정지 또는 재인증 요구입니다. 이 도구가 일상 업무에 꼭 필요한 경우 근무 시간에 접근이 차단되면 추가 좌석 몇 개 비용보다 훨씬 큰 손실이 생길 수 있습니다.
프록시를 바꾸거나 브라우저 지문을 통일하는 방법은 탐지 가능성을 낮출 수 있을 뿐, 여러 사람이 하나의 계정을 공유하는 행위를 규정에 맞게 만들지는 못합니다. 또한 모든 로그인을 하나의 환경에 묶으면 그 환경에 문제가 생겼을 때, 예를 들어 IP가 표시되거나 환경이 비정상으로 판단될 경우 모든 사람의 접근이 동시에 끊겨 장애 범위가 더 커질 수 있습니다.
사람이 떠나도 권한은 남을 수 있습니다
직원이 퇴사하거나 외주 협력이 끝났을 때 공유 계정의 권한 회수는 담당자가 불명확한 경우가 많습니다. 이유는 단순합니다. 계정이 모두의 것이어서 명확한 인수인계 절차가 없기 때문입니다.
몇 가지 위험이 그대로 남습니다. 퇴사한 구성원이 여전히 비밀번호를 알고 있을 수 있고, 다른 누가 저장해 두었는지도 알 수 없습니다. 이전에 발급된 세션 쿠키가 아직 유효할 수도 있습니다. 해당 사용자가 이 계정으로 자동화 스크립트나 API 호출을 구성했다면 그런 접근 경로 역시 자동으로 사라지지 않습니다. 문제가 발견되었을 때는 이미 데이터가 변경된 뒤일 수 있습니다.
또한 팀 구성원이 바뀔 때마다 전체 사용자의 비밀번호를 다시 바꿔야 하는데, 공유 방식에서는 이를 완전히 적용하기가 쉽지 않습니다.
규정에 맞는 대안은 복잡하지 않습니다
공유하려는 이유를 나눠 보면 적절한 대안도 비교적 명확합니다.
- 장기간 사용하는 고정 구성원이 필요한 경우: 추가 사용자 좌석을 구매합니다. 이는 여러 사람이 이용하는 방식 중 공식적으로 지원되는 유일한 방법이며, 로그의 사용자별 추적 가능성도 회복할 수 있습니다.
- 팀 규모가 큰 경우: 플랫폼에 다중 사용자 팀 요금제나 엔터프라이즈 요금제가 있는지 확인합니다. 이런 요금제는 보통 역할에 따라 무엇을 보고 수정할 수 있는지 제한하는 권한 모델을 제공합니다.
- 접근을 중앙에서 관리해야 하는 경우: SSO를 사용합니다. 구성원이 퇴사하면 중앙에서 일괄적으로 비활성화할 수 있어 누군가가 권한 회수를 기억해야 할 필요가 없습니다.
- 고객에게 결과를 잠시 보여 주기만 하면 되는 경우: 보고서를 내보내거나 읽기 전용 공유 링크를 생성해 고객이 계정에 로그인하지 않고도 데이터를 확인하게 합니다.
계정 공유와 다중 계정 사용은 서로 다른 문제라는 점도 중요합니다. 계정 공유는 여러 사람이 하나의 자격 증명을 함께 쓰는 것이고, 다중 계정은 각자 자신의 자격 증명을 가지고 같은 기기에서 서로 간섭 없이 사용해야 하는 상황입니다. 후자는 그 자체로 규정에 맞는 운영이 될 수 있습니다. 예를 들어 팀이 모든 구성원에게 각각 좌석을 구매하고 각자 계정을 보유하고 있다면, 같은 브라우저 안에서 쿠키와 세션이 서로 덮어쓸 수 있습니다. 계정마다 독립된 브라우저 환경을 제공하면 세션, 캐시, 데이터를 분리할 수 있습니다. PurpleMark는 바로 이런 환경 격리 기능을 제공합니다. 이는 여러 개의 정상적인 계정이 한 기기에서 안정적으로 공존하도록 돕는 기능이며, 여러 사람이 하나의 로그인 정보를 공유하는 행위가 서비스 약관을 위반한다는 사실을 바꾸지는 않습니다.
비용을 계산한 뒤 선택하세요
계정 공유의 본질은 약간의 좌석 비용을 아끼는 대신 규정 준수 위험을 감수하는 것입니다. 가끔, 일시적으로, 한 사람이 사용하는 경우에는 한동안 문제가 없어 보일 수 있지만, 팀 규모에서는 접근 취소나 데이터 사고가 발생했을 때 절약한 금액보다 훨씬 큰 비용을 치를 수 있습니다.
먼저 라이선스 비용을 계산한 뒤 적절한 방식을 선택하세요. 좌석을 구매할 수 있다면 구매하고, 데이터를 내보낼 수 있다면 내보내는 것이 좋습니다.
구체적인 라이선스 규칙은 각 제품의 공식 약관을 기준으로 확인해야 합니다.
