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