에이전시들이 “서브 계정”을 검색하는 이유는, 하나의 부모 로그인이 그 아래 여러 클라이언트 계정을 보유하는 방식을 대부분의 도구들이 그렇게 부르기 때문이다. 무언가를 구축하기 전에 이것이 Shifter에서 어떻게 매핑되는지 정확히 파악해 둘 필요가 있는데, 올바른 구조는 이 매핑에 따라 달라지기 때문이다.
Shifter에는 플랜 내부에 서브 유저가 존재하지 않는다. 서브 계정의 역할을 하는 단위는 워크스페이스다. 워크스페이스는 자체 플랜, 지갑, 인보이스, 팀을 가진 독립된 공간으로, 동일한 사람이 여러 워크스페이스에 속할 수 있으며 사이드바에서 전환할 수 있다. 사용량은 플랜 단위로 추적된다. 이 두 가지 사실을 구조에 반영하면 나머지는 자연스럽게 따라온다.
서브 계정이 해야 할 일
용어를 걷어내고 보면, 에이전시가 클라이언트 서브 계정에서 원하는 것은 네 가지다.
| 요구 사항 | 의미 | Shifter가 제공하는 방식 |
|---|---|---|
| 격리 | 한 클라이언트의 트래픽과 예산이 다른 클라이언트와 섞이지 않아야 함 | 플랜은 워크스페이스 간에 절대 겹치지 않음 |
| 귀속 | 각 클라이언트에게 든 비용을 명확히 말할 수 있어야 함 | 사용량은 플랜 단위로 보고됨 |
| 접근 제어 | 적합한 사람이 적합한 정보를 볼 수 있어야 함 | 워크스페이스별 Viewer, Billing, Admin 역할 |
| 깨끗한 오프보딩 | 한 클라이언트가 떠나도 다른 클라이언트에게 영향이 없어야 함 | 멤버 제거, 해당 클라이언트의 플랜 종료 |
이 가이드의 나머지 부분은 이 네 가지가 모두 성립하도록 워크스페이스와 플랜을 어떻게 배치할지 선택하는 것이다.
작동하는 두 가지 구조
클라이언트가 소유하는 워크스페이스
각 클라이언트가 자신의 워크스페이스를 소유한다. 클라이언트가 지갑에 충전하고 인보이스를 받는다. 에이전시의 계정 담당자는 각 클라이언트 워크스페이스에 Admin으로 초대되어 그곳에서 수집 작업을 운영한다.
클라이언트가 자체 결제 관계를 유지하는 데 동의한다면 이것이 가장 깔끔한 방식이다. 격리는 완전하며, 각 클라이언트의 인보이스가 독립적이기 때문에 귀속을 위해 별도의 작업이 필요 없고, 오프보딩은 클라이언트가 자신의 워크스페이스에서 에이전시를 제거하는 것으로 끝난다. 에이전시는 하나의 로그인으로 워크스페이스 전환기를 통해 모든 클라이언트에 접근할 수 있다.
에이전시가 소유하는 워크스페이스, 클라이언트당 플랜 하나
에이전시가 하나의 워크스페이스를 소유하고, 그 안에서 각 클라이언트를 위한 별도의 플랜을 구매하며, 각 플랜의 사용량을 기준으로 클라이언트에게 청구한다.
이는 리테이너의 일부로 수집 작업을 재판매하는 에이전시에 적합하다. 귀속은 규칙이 엄격하게 지켜지는 한에서만 유지된다: 한 클라이언트, 한 플랜, 절대 공유하지 않음. 이 방식을 선택하기 전에 알아둬야 할 두 가지 결과가 있다.
- 지갑은 워크스페이스 단위로 범위가 정해지며, 어떤 플랜에서든 초과 사용량은 그 지갑에서 충당된다. 워크스페이스 내 모든 플랜이 같은 자금을 사용하므로, 한 클라이언트의 사용량 급증이 다른 클라이언트가 필요로 하는 여유분을 소진시킬 수 있다. 플랜별 초과 사용량을 면밀히 관찰하거나, 대용량 클라이언트에게는 별도의 워크스페이스를 부여해야 한다.
- 워크스페이스 내부의 모든 것은 그 멤버들에게 보인다. 공유 에이전시 워크스페이스에 클라이언트 담당자를 초대해서는 안 되며, Viewer로도 초대해서는 안 된다. 그렇게 하면 다른 모든 클라이언트의 플랜과 인보이스를 볼 수 있게 되기 때문이다.
많은 에이전시가 결국 혼합형으로 정착한다. 자체 결제를 원하는 대형 계정은 클라이언트 소유 워크스페이스로, 리테이너 방식으로 청구하는 소규모 클라이언트는 에이전시 소유 워크스페이스 내 플랜으로 관리한다.
설정하기
메커니즘은 두 구조 모두 동일하다.
- 패널 사이드바에서 관리하고자 하는 워크스페이스의 Team 페이지를 연다.
- 이메일로 초대하고 역할을 선택한다. 기존 Shifter 사용자는 다음 로그인 시 원클릭 Join을 받고 자신의 계정을 그대로 유지한다. 새 이메일은 매직 링크를 통한 간단한 가입 절차를 거치며 비밀번호가 필요 없다.
- 사이드바 드롭다운에서 워크스페이스를 전환한다. 이는 둘 이상의 워크스페이스에 속하게 되면 나타난다. 화면에 표시되는 모든 것, 즉 플랜, 지갑, 인보이스, 팀이 전환에 따라 바뀐다.
- 각 클라이언트의 플랜은 해당 클라이언트가 속한 워크스페이스에서 구매한다. 플랜은 이후 워크스페이스 간에 이동하지 않으므로, 잘못된 워크스페이스에서 구매하면 다시 구매해야 한다.
각 워크스페이스는 10석의 소프트 한도를 가진다. 대형 클라이언트를 위해 더 많은 자리가 필요하다면, 이는 엄격한 제한이 아니라 지원팀과 상담할 문제다. 클라이언트 관계의 형태가 바뀌는 경우 요청에 따라 워크스페이스 소유권을 이전할 수도 있다.
이 기능 자체는 introducing Team Workspaces에서 설명되어 있다.
역할 선택하기
각 사람에게 필요한 최소한의 역할만 부여한다.
| 역할 | 할 수 있는 것 | 부여 대상 |
|---|---|---|
| Viewer | 플랜, 트래픽, 인보이스 조회; 카탈로그 탐색 | 사용량을 보고 싶어하는 클라이언트 담당자, 오직 자신의 워크스페이스 내에서만 |
| Billing | Viewer가 할 수 있는 모든 것에 더해, 지갑 충전, 인보이스 결제, 플랜 구매 또는 업그레이드 | 카드를 소지한 사람, 양측 모두 가능 |
| Admin | Billing이 할 수 있는 모든 것에 더해, 플랜과 팀 관리 | 수집 작업을 운영하는 에이전시 계정 담당자 |
역할은 전역이 아니라 워크스페이스별로 적용된다. 같은 사람이 한 클라이언트의 워크스페이스에서는 Admin이면서 다른 클라이언트의 워크스페이스에서는 Viewer일 수 있으며, 활성 워크스페이스에서의 역할이 항상 적용되는 역할이다.
클라이언트별 사용량 추적
각 플랜에는 패널, 대시보드 개요, 그리고 플랜 자체의 페이지에 실시간 사용량 뷰가 있으며, 매분 업데이트된다. 이는 사이클 내 남은 대역폭, 일별 소비 추세, 호스트네임 기준 상위 트래픽 목적지를 보여준다.
이 세 가지를 함께 보면 클라이언트 귀속을 잘 운영하기에 충분하다.
남은 대역폭은 클라이언트가 할당량 내에서 사이클을 마칠 수 있는 궤도에 있는지 알려준다.
일별 추세는 소비량이 언제 바뀌었는지 보여주는데, 보통은 새로운 작업, 폭주하는 크롤러, 또는 알리지 않고 범위를 넓혀달라고 요청하는 클라이언트를 의미한다.
호스트네임 기준 상위 목적지는 과소평가되고 있는 지표다. 이를 통해 각 클라이언트의 플랜이 실제로 그 클라이언트의 목표물에 접근하고 있는지 확인할 수 있다. 상위 목적지가 다른 클라이언트의 경쟁사 집합에 속하는 플랜이 있다면, 어딘가의 작업에 잘못된 자격 증명이 들어가 있다는 뜻이다.
사용량 추적이 하지 못하는 것은 플랜의 트래픽을 나중에 나누어 분석하는 것이다. 세션 ID별로나 여러 작업 중 어느 것이 트래픽을 보냈는지로 사용량을 분석해주지는 않는다. 여러 클라이언트가 하나의 플랜을 통해 작업을 실행한다면 나중에 이를 분리할 방법이 없으며, 이것이 바로 클라이언트당 플랜 하나 규칙이 중요한 이유다.
월간 운영 루틴
귀속은 한 번 실행하는 보고서가 아니라 습관이다.
- 각 사이클 시작 시, 각 플랜의 초기 할당량과 사이클 날짜를 기록한다.
- 매주, 각 클라이언트의 소비량을 예상 소비율과 비교하고, 소비된 대역폭을 경과일로 나눈 후 사이클의 총 일수를 곱해 월말 사용량을 재예측한다.
- 추세가 급증할 때, 클라이언트의 범위가 확대되었다고 가정하기 전에 상위 목적지를 확인한다.
- 할당량이 소진되기 전에, 클라이언트별로 초과 사용량을 지갑에서 처리할지 아니면 작업을 일시 중지할지 결정한다. 레지덴셜 플랜의 초과 사용량은 해당 플랜 자체의 GB당 요율로 지갑에서 청구된다.
- 클라이언트가 떠날 때, 해당 담당자를 제거하고, 모든 작업에서 그 플랜의 자격 증명을 폐기하고, 플랜을 종료한다.
주간 점검의 근거가 되는 예측 방법은 forecasting residential proxy bandwidth에 나와 있다.
자격 증명은 격리의 나머지 절반이다
워크스페이스는 플랜을 분리해 준다. 자격 증명을 분리하는 것은 여러분 자신의 시스템이 해야 할 일이다.
각 플랜은 자체 자격 증명을 가진다. 클라이언트별로 시크릿 매니저에 저장하고, 각 클라이언트의 작업에는 그 클라이언트의 플랜만 부여하며, 빠르게 일을 처리하기 위해 한 클라이언트의 자격 증명을 다른 클라이언트의 작업에 복사해서 사용하지 말아야 한다. 그것이 바로 귀속이 조용히 깨지는 방식이다. 프록시 연결 문자열 전체를 로그에 남기지 않아야 하는데, 이는 자격 증명이 로그 수집기로 유출되는 가장 흔한 경로다.
세션 ID는 여러분이 원하는 대로 자유롭게 이름 붙일 수 있다. sid-acme-serp-01처럼 클라이언트 코드를 접두사로 붙이는 데는 비용이 들지 않으며, 패널이 세션 ID별로 사용량을 나누어 분석해주지는 않더라도 여러분 자신의 로그를 읽기 쉽게 만들어준다.
FAQ
Shifter에는 플랜 내부에 서브 유저가 있나요?
없다. 접근은 워크스페이스 단위로 세 가지 역할로 관리되며, 클라이언트 간 격리는 별도의 플랜과, 필요한 경우 별도의 워크스페이스에서 나온다.
하나의 에이전시 로그인으로 몇 명의 클라이언트를 관리할 수 있나요?
하나의 로그인은 필요한 만큼 많은 워크스페이스에 속할 수 있으며, 사이드바에서 전환할 수 있다. 10석 소프트 한도는 로그인당이 아니라 워크스페이스당 적용된다.
클라이언트가 우리의 다른 클라이언트를 볼 수 있나요?
워크스페이스 간에는 볼 수 없다. 하나의 워크스페이스 내에서는 모든 멤버가 모든 것을 볼 수 있으므로, 클라이언트 담당자는 반드시 자신의 워크스페이스에만 초대되어야 한다.
한 클라이언트에서 다른 클라이언트로 플랜을 옮길 수 있나요?
플랜은 구매된 워크스페이스에 그대로 남는다. 처음부터 각 클라이언트의 플랜을 해당 클라이언트의 워크스페이스에서 구매해야 한다.
결론
에이전시가 찾고 있는 서브 계정은 Shifter에서는 워크스페이스이며, 귀속의 단위는 플랜이다. 예외 없이 모든 클라이언트에게 자체 플랜을 부여하고, 클라이언트가 자체 결제를 유지하는 경우에는 클라이언트 소유 워크스페이스를, 재판매하는 경우에는 공유 에이전시 워크스페이스를 선택하며, 클라이언트 담당자를 공유 워크스페이스에 두지 말고, 인보이스 시점이 아니라 매주 플랜별 사용량을 확인한다.
이렇게 구조화하면 격리, 귀속, 접근, 오프보딩이 모두 자연스럽게 따라온다. 이 제품은 residential proxies for agencies 페이지에서 확인할 수 있으며, 요율은 pricing page에 있다.