클라이언트가 급하게 신규 계정 여러 개를 요청할 때, 대행사가 먼저 짚어야 할 것들
클라이언트가 당장 신규 계정을 여러 개 만들어달라고 할 때 대행사가 착수 전에 확인해야 할 리스크와 커뮤니케이션 포인트를 정리했습니다.
급한 요청일수록 먼저 멈춰야 하는 이유
저는 광고 대행사에서 여러 브랜드의 인스타그램과 유튜브 계정을 동시에 운영하는 팀장입니다. 그래서 이런 전화를 자주 받습니다. "경쟁사가 계정 5개로 돌리던데 저희도 당장 5개 만들어주세요." "이번 주말 프로모션 전까지 신규 계정 10개 세팅해주세요."
문제는 이런 요청이 거의 항상 '급하다'는 전제를 깔고 들어온다는 점입니다. 그리고 급하게 처리된 신규 계정 생성은 나중에 계정 정지로 돌아오는 경우가 생각보다 많습니다. 신규 계정은 플랫폼 입장에서 가장 신뢰도가 낮은 상태로 시작하는데, 여기에 '짧은 시간 안에 여러 개'라는 조건이 더해지면 플랫폼이 보기엔 가장 의심스러운 패턴이 만들어지기 때문입니다.
그래서 저는 이런 요청이 들어오면 바로 착수하지 않고, 먼저 클라이언트와 짚어야 할 체크포인트를 정리해서 공유합니다. 오늘은 그 체크포인트를 정리해보겠습니다.
1) 계정 생성 '속도'가 가장 먼저 의심받는 신호다
짧은 시간 안에 비슷한 환경에서 여러 계정이 만들어지면, 플랫폼의 자동 탐지 시스템은 이걸 하나의 그룹 행동으로 인식할 가능성이 높아집니다. 사람이 손으로 하나씩 가입해도 마찬가지입니다. 중요한 건 '누가 만들었는지'가 아니라 '얼마나 짧은 간격으로, 얼마나 비슷한 조건에서 만들어졌는지'입니다.
그래서 제가 클라이언트에게 가장 먼저 설명하는 건, 계정 생성은 하루에 몰아서 끝내는 작업이 아니라 며칠에서 몇 주에 걸쳐 분산해야 하는 작업이라는 점입니다. 급한 마음은 이해하지만, 이 단계를 생략하면 오히려 캠페인 시작 전에 계정이 막히는 상황이 발생합니다.
2) 계정끼리 연결고리가 남으면 전부 같은 묶음으로 보인다
신규 계정 여러 개를 동시에 만들 때 흔히 생기는 실수는, 계정들이 서로 연결될 만한 흔적을 그대로 남기는 것입니다. 예를 들면
- 같은 이메일 도메인을 순차적으로 사용 (brand1@, brand2@ 식의 패턴)
- 전화번호 인증을 같은 번호대로 반복
- 프로필 사진이나 소개글을 복붙해서 돌리기
- 같은 네트워크 환경에서 짧은 간격으로 로그인
이런 흔적은 플랫폼이 계정을 개별적으로 평가하지 않고 '하나의 집합'으로 묶어서 보게 만듭니다. 한 계정이 문제가 생기면 나머지도 같이 흔들릴 수 있다는 뜻입니다. 저희 팀은 이걸 막기 위해 계정별로 환경을 분리하는 걸 원칙으로 두는데, 이때 안티디텍트 브라우저를 활용해 계정마다 브라우저 지문을 다르게 유지하는 방식을 씁니다. 다만 이것만으로 안전이 담보되는 건 아니고, 생성 속도와 행동 패턴을 같이 관리해야 의미가 있습니다.
3) '계정만 만들면 끝'이 아니라 육성 계획까지 패키지로 설명해야 한다
클라이언트가 원하는 건 보통 '계정 생성'이지만, 실제로 필요한 건 '정지되지 않고 운영 가능한 계정'입니다. 이 차이를 초기에 명확히 하지 않으면, 나중에 계정이 정지됐을 때 책임 소재를 두고 불필요한 갈등이 생깁니다.
그래서 저는 신규 계정 요청이 들어올 때 다음을 세트로 제안합니다.
| 단계 | 내용 | 대략 소요 |
|---|---|---|
| 생성 | 계정별 환경 분리, 생성 간격 확보 | 분산 진행 |
| 워밍업 | 실제 사람처럼 보이는 초기 활동 쌓기 | 1~4주 |
| 본격 운영 | 콘텐츠 업로드, 광고 집행 시작 | 워밍업 이후 |
이 표를 클라이언트에게 공유하면 '당장 오늘 돌릴 수 있는 것'과 '안전하게 돌릴 수 있는 시점'의 간극을 이해시키기 훨씬 쉬워집니다.
4) 프록시와 IP는 보조 수단일 뿐, 단독으로 믿지 않는다
계정을 분리할 때 프록시로 IP를 다르게 쓰는 것도 흔한 방법이지만, IP만 바꾼다고 계정이 서로 무관하게 보이는 건 아닙니다. 플랫폼은 IP 외에도 브라우저 환경, 행동 패턴, 가입 시점 간격 등을 종합적으로 봅니다. 그래서 저희는 프록시를 쓸 때도 '이것 하나로 문제가 해결된다'는 식으로 클라이언트에게 설명하지 않습니다. 여러 요소를 같이 관리해야 한다는 점을 분명히 하는 게, 나중에 문제가 생겼을 때 서로 당황하지 않는 길입니다.
5) 계약 전에 '정지 시 책임 범위'를 문서로 합의한다
급한 요청일수록 계약서를 꼼꼼히 쓸 시간이 없다고 생각하기 쉽지만, 저는 오히려 이럴 때 더 명확하게 짚고 넘어갑니다. 신규 계정은 기존 계정보다 정지 리스크가 구조적으로 높기 때문에, 계정이 정지됐을 때 재가입 비용과 책임을 누가 지는지, 재운영까지 걸리는 기간을 어떻게 볼 것인지 사전에 합의해두는 게 중요합니다. 이 부분을 생략하고 진행했다가 나중에 클라이언트와 관계가 틀어지는 경우를 여러 번 봤습니다.
정리
클라이언트의 급한 요청을 거절할 필요는 없습니다. 다만 '빠르게'와 '안전하게'는 양립하기 어려운 경우가 많다는 걸 초반에 설명하고, 생성 속도 조절, 계정 간 연결고리 차단, 워밍업 기간 확보, 책임 범위 합의까지를 하나의 패키지로 제안하는 게 대행사 입장에서는 결과적으로 클라이언트를 더 안전하게 보호하는 방법입니다.