에이전시들이 “서브 계정”을 검색하는 이유는 대부분의 도구가 하나의 부모 로그인이 여러 클라이언트 계정을 그 아래에 거느리는 구조를 지칭할 때 이 단어를 쓰기 때문이다. 무언가를 구축하기 전에 이것이 Shifter에서 어떻게 대응되는지 정확히 짚어볼 가치가 있다. 올바른 구조는 여기에 달려 있기 때문이다.
Shifter에는 이 역할을 나누어 맡는 두 가지 도구가 있다. 워크스페이스는 자체 플랜, 지갑, 인보이스, 팀을 가진 독립된 공간이며, 같은 사람이 여러 워크스페이스에 속하면서 사이드바에서 전환할 수 있다. 서브 계정은 프록시 사용자명 안의 라벨로, 하나의 플랜 트래픽을 클라이언트별로 나누고, 패널과 API에서 각각 별도로 집계된다(2026년 10월에 도입). 사용량은 플랜 단위로, 그리고 그 안에서는 서브 계정 단위로 추적된다. 이 사실을 구조에 반영하면 나머지는 자연히 따라온다.
서브 계정이 해야 할 일
용어를 걷어내면, 에이전시가 클라이언트 서브 계정에 바라는 것은 네 가지다.
| 요구사항 | 의미 | Shifter가 제공하는 방식 |
|---|---|---|
| 격리 | 한 클라이언트의 트래픽과 예산이 다른 클라이언트와 섞이지 않음 | 플랜은 워크스페이스 간에 절대 교차하지 않음 |
| 귀속 | 각 클라이언트에게 든 비용을 말할 수 있음 | 사용량이 플랜 단위, 서브 계정 단위로 각각 집계됨 |
| 접근 제어 | 적절한 사람이 적절한 것만 봄 | 워크스페이스별 Viewer, Billing, Admin 역할 |
| 깔끔한 종료 | 클라이언트가 떠나도 다른 누구에게도 영향 없음 | 멤버 제거, 해당 클라이언트 플랜 종료 |
이 가이드의 나머지는 네 가지가 모두 성립하도록 워크스페이스와 플랜을 배치하는 방법을 고르는 것이다.
작동하는 두 가지 구조
클라이언트 소유 워크스페이스
각 클라이언트가 자신의 워크스페이스를 소유한다. 클라이언트가 지갑에 자금을 채우고 인보이스를 받는다. 에이전시의 계정 담당자는 각 클라이언트 워크스페이스에 Admin으로 초대되어 그곳에서 수집 작업을 운영한다.
클라이언트가 자신의 청구 관계를 직접 유지하는 데 동의하는 경우 이것이 가장 깔끔한 배치다. 격리는 완전하고, 각 클라이언트의 인보이스가 그 자체로 독립적이므로 귀속에 별도 작업이 필요 없으며, 종료는 클라이언트가 자신의 워크스페이스에서 에이전시를 제거하는 것으로 끝난다. 하나의 에이전시 로그인으로 워크스페이스 전환기를 통해 모든 클라이언트에 접근할 수 있다.
에이전시 소유 워크스페이스, 클라이언트당 플랜 하나
에이전시가 워크스페이스 하나를 소유하고, 그 안에 각 클라이언트를 위한 별도 플랜을 구매하며, 각 플랜의 사용량으로 클라이언트에게 청구한다.
이는 수집 작업을 리테이너의 일부로 재판매하는 에이전시에 적합하다. 규칙이 엄격하게 지켜지는 한 귀속은 유지된다: 한 클라이언트, 한 플랜, 절대 공유 없음, 또는 공유 플랜에서는 한 클라이언트, 한 서브 계정. 이를 선택하기 전에 알아둘 만한 두 가지 결과가 있다.
- 지갑은 워크스페이스에 종속되며, 어떤 플랜에서든 발생하는 초과분은 그 지갑에서 충당된다. 워크스페이스 내 모든 플랜이 같은 자금 풀을 쓰기 때문에, 한 클라이언트의 급증이 다른 클라이언트가 의존하는 여유분을 소진시킬 수 있다. 플랜별 초과 사용을 면밀히 지켜보거나, 사용량이 많은 클라이언트에게는 별도 워크스페이스를 주어라.
- 워크스페이스 내부의 모든 것은 멤버에게 보인다. 공유 에이전시 워크스페이스에 클라이언트 담당자를 Viewer로라도 초대하면 안 된다. 다른 모든 클라이언트의 플랜과 인보이스가 보이기 때문이다.
많은 에이전시가 결국 혼합 형태로 정착한다: 자체 청구를 원하는 대형 계정은 클라이언트 소유 워크스페이스로, 리테이너로 청구되는 소형 클라이언트들은 하나의 에이전시 워크스페이스에 플랜으로 담는 식이다.
설정하기
어느 구조든 메커니즘은 동일하다.
- 관리하려는 워크스페이스에서 패널 사이드바를 통해 팀 페이지를 연다.
- 이메일로 초대하고 역할을 선택한다. 기존 Shifter 사용자는 다음 로그인 시 원클릭으로 참여할 수 있으며 자신의 계정을 그대로 유지한다. 새 이메일은 비밀번호 없이 매직 링크를 통한 간단한 가입 절차를 거친다.
- 사이드바의 드롭다운에서 워크스페이스를 전환한다. 둘 이상의 워크스페이스에 속하게 되면 이 드롭다운이 나타난다. 화면의 모든 것, 즉 플랜, 지갑, 인보이스, 팀이 그에 따라 바뀐다.
- 각 클라이언트의 플랜은 해당 클라이언트가 속한 워크스페이스에서 구매한다. 플랜은 이후 워크스페이스 간에 이동하지 않으므로, 잘못된 곳에서 구매하면 다시 구매해야 한다.
각 워크스페이스는 10개 좌석이라는 소프트 캡을 가진다. 대형 클라이언트를 위해 더 필요하다면, 이는 고정된 한계가 아니라 고객지원과 상의할 사안이다. 클라이언트 관계의 형태가 바뀌면 요청에 따라 워크스페이스 소유권을 이전할 수도 있다.
기능 자체는 팀 워크스페이스 소개에 설명되어 있다.
역할 선택하기
각 사람에게 필요한 최소한의 역할만 부여하라.
| 역할 | 할 수 있는 일 | 부여 대상 |
|---|---|---|
| Viewer | 플랜, 트래픽, 인보이스 보기; 카탈로그 탐색 | 자신의 워크스페이스에서만 사용량을 보고 싶은 클라이언트 이해관계자 |
| Billing | Viewer가 할 수 있는 모든 것에 더해, 지갑 충전, 인보이스 결제, 플랜 구매 또는 업그레이드 | 카드를 소유한 사람, 양쪽 모두 |
| Admin | Billing이 할 수 있는 모든 것에 더해, 플랜과 팀 관리 | 수집 작업을 운영하는 에이전시 계정 담당자 |
역할은 전역이 아니라 워크스페이스별로 적용된다. 같은 사람이 한 클라이언트의 워크스페이스에서는 Admin이면서 다른 클라이언트의 워크스페이스에서는 Viewer일 수 있으며, 항상 활성 워크스페이스의 역할이 적용된다.
클라이언트별 사용량 추적
각 플랜은 패널의 대시보드 개요와 플랜 자체 페이지에서 실시간 사용량 뷰를 제공하며, 매분 갱신된다. 주기 내 남은 대역폭, 일별 소비 추이, 호스트네임 기준 상위 트래픽 목적지를 보여준다.
이 세 가지만 있으면 클라이언트 귀속을 잘 운영하기에 충분하다.
남은 대역폭은 클라이언트가 할당량 내에서 주기를 마칠 수 있을지 알려준다.
일별 추이는 소비가 언제 변했는지 보여주며, 대개 새로운 작업, 폭주하는 크롤러, 또는 말없이 더 큰 범위를 요청한 클라이언트 중 하나다.
호스트네임 기준 상위 목적지는 과소평가된 지표다. 이를 통해 각 클라이언트의 플랜이 실제로 그 클라이언트의 타겟을 치고 있는지 확인할 수 있다. 상위 목적지가 다른 클라이언트의 경쟁사군에 속한다면, 어딘가의 작업에 잘못된 자격 증명이 들어가 있는 플랜이라는 뜻이다.
하나의 플랜을 여러 클라이언트로 나누려면 각 클라이언트에게 서브 계정을 부여하라: 해당 클라이언트의 작업에서 사용자명 바로 뒤에 -subaccount-CLIENT를 추가하면, 패널과 사용량 API가 각각을 별도로 집계한다. 라벨 없이 전송된 트래픽은 나중에 나눌 수 없으므로, 공유 플랜에서는 모든 작업에 라벨을 붙여라.
한 클라이언트를 위한 요청으로, 라벨 뒤에 타겟팅과 세션이 붙은 모습은 다음과 같다:
curl -x customer-USERNAME-subaccount-client_a-country-us-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 \
http://ip-info.com/json그리고 같은 클라이언트의 10월 트래픽을 API로 조회하면:
curl "https://shifter.io/api/v1/memberships/68057/subaccounts/client_a/usage?start=2026-10-01&end=2026-11-01&api_token=YOUR_API_TOKEN"서브 계정 이름은 1자에서 16자의 문자, 숫자, 밑줄로만 구성되며 하이픈은 쓸 수 없고 대소문자를 구분한다. 별도 설정은 필요 없다: 서브 계정은 첫 요청 후 몇 분 안에 나타난다. 서브 계정은 트래픽만 추적하며, 플랜의 대역폭을 공유할 뿐 클라이언트별 한도를 설정하지는 않는다.
월간 운영 루틴
귀속은 한 번 돌리고 마는 보고서가 아니라 하나의 습관이다.
- 각 주기 시작 시, 각 플랜의 초기 할당량과 주기 일자를 기록한다.
- 매주, 각 클라이언트의 소비량을 예상 소비 속도와 비교하고, 소비된 대역폭을 경과 일수로 나눈 뒤 주기 내 총 일수를 곱해 월말 사용량을 재예측한다.
- 추이가 급변할 때, 클라이언트의 범위가 커졌다고 가정하기 전에 상위 목적지를 먼저 확인한다.
- 할당량이 소진되기 전에, 초과분을 지갑에서 충당할지 작업을 일시 중지할지 클라이언트별로 결정한다. 레지덴셜 플랜의 초과분은 해당 플랜 자체의 GB당 요율로 지갑에서 청구된다.
- 클라이언트가 떠날 때, 해당 인원을 제거하고, 모든 작업에서 그 플랜의 자격 증명을 폐기하고, 플랜을 종료한다.
주간 점검의 바탕이 되는 예측 방법은 레지덴셜 프록시 대역폭 예측하기에 있다.
자격 증명은 격리의 또 다른 절반이다
워크스페이스는 플랜을 분리해준다. 자격 증명을 분리하는 것은 여러분 자신의 시스템이 해야 할 일이다.
각 플랜은 고유한 자격 증명을 가진다. 이를 시크릿 매니저에 클라이언트별로 저장하고, 각 클라이언트의 작업에는 그 클라이언트의 플랜만 사용하게 하며, 당장 일을 빨리 끝내려고 한 클라이언트의 자격 증명을 다른 클라이언트의 작업에 복사해 넣지 말아야 한다. 그것이 귀속이 조용히 무너지는 방식이기 때문이다. 전체 프록시 연결 문자열을 로그로 남기지 말아야 한다. 이는 자격 증명이 로그 수집기로 유출되는 가장 흔한 경로다.
세션 ID는 원하는 대로 이름 붙일 수 있다. 클라이언트 코드를 접두사로 붙이는 것, 예를 들어 sid-acme-serp-01은 비용이 들지 않으며 자신의 로그를 읽기 쉽게 만든다. 패널은 세션 ID 기준으로 사용량을 분석해주지 않는다. 그것이 바로 서브 계정이 존재하는 이유다.
FAQ
Shifter에 플랜 내부 서브 사용자가 있는가?
플랜 내부에 별도의 로그인은 없지만, 서브 계정이 플랜의 트래픽을 클라이언트별로 나눈다: 프록시 사용자명 안의 라벨로, 패널과 API가 각각 별도로 집계한다. 접근 권한은 워크스페이스별로 세 가지 역할로 관리되며, 클라이언트 간 완전한 격리는 별도의 플랜, 필요하다면 별도의 워크스페이스에서 비롯된다.
하나의 에이전시 로그인으로 몇 명의 클라이언트를 관리할 수 있는가?
하나의 로그인은 필요한 만큼 많은 워크스페이스에 속할 수 있으며, 사이드바에서 전환할 수 있다. 10개 좌석 소프트 캡은 로그인이 아니라 워크스페이스당 적용된다.
클라이언트가 우리의 다른 클라이언트를 볼 수 있는가?
워크스페이스를 넘어서는 볼 수 없다. 하나의 워크스페이스 안에서는 모든 멤버가 모든 것을 보므로, 클라이언트 담당자는 반드시 자신의 워크스페이스에만 초대해야 한다.
플랜을 한 클라이언트에서 다른 클라이언트로 옮길 수 있는가?
플랜은 구매된 워크스페이스에 그대로 남는다. 처음부터 각 클라이언트의 플랜을 그 클라이언트의 워크스페이스에서 구매하라.
요점
Shifter에서 워크스페이스는 접근 권한과 청구를 분리하고, 서브 계정은 플랜 내부의 트래픽을 나눈다. 모든 클라이언트에게 자신의 플랜이나 자신의 서브 계정을 부여하고, 클라이언트가 자체 청구를 원한다면 클라이언트 소유 워크스페이스를, 재판매하는 경우라면 공유 에이전시 워크스페이스를 선택하며, 클라이언트 담당자를 공유 워크스페이스에 들이지 말고, 인보이스 시점이 아니라 매주 클라이언트별 사용량을 확인하라.
이렇게 구조화하면 격리, 귀속, 접근 제어, 종료 처리가 모두 자연스럽게 따라온다. 제품은 에이전시를 위한 레지덴셜 프록시 페이지에 있으며, 요금은 가격 페이지에서 확인할 수 있다.