광고 대행사가 클라이언트 계정을 안전하게 분리하는 방법
여러 클라이언트의 SNS·쇼핑몰 계정을 동시에 운영하는 대행사가 계정 분리를 소홀히 하면 한 클라이언트의 사고가 다른 클라이언트까지 번질 수 있습니다. 실무에서 겪은 계정 분리 기준을 정리했습니다.
대행사 업무의 특성상 계정 분리는 선택이 아니다
제가 지금 팀에서 관리하는 클라이언트 계정만 세어봐도 인스타그램, 유튜브, 각종 커머스 채널을 합쳐 꽤 많은 수입니다. 대행사에서 일하시는 분들은 다 아시겠지만, 한 사람이 여러 브랜드의 계정을 동시에 만지는 게 이 업계의 기본 구조예요. 문제는 이 구조 자체가 리스크를 안고 있다는 겁니다.
제가 처음 팀장을 맡았을 때 겪었던 사고 하나를 말씀드리면, 신규로 들어온 클라이언트 계정을 급하게 세팅하면서 기존에 쓰던 브라우저 환경을 그대로 재사용한 적이 있어요. 며칠 뒤 전혀 관련 없는 다른 클라이언트 계정에서 로그인 이상 알림이 떴습니다. 두 계정이 같은 브라우저 지문, 같은 IP 대역을 공유하고 있었기 때문에 플랫폼 입장에서는 이 둘을 '연결된 계정'으로 판단한 거죠. 클라이언트 계정 하나가 흔들리니 옆 계정까지 같이 흔들리는 걸 눈앞에서 봤습니다.
왜 계정이 서로 '연결'되는가
플랫폼은 로그인 IP나 아이디·비밀번호만으로 계정을 구분하지 않습니다. 브라우저가 가진 여러 특성값, 흔히 말하는 브라우저 지문(핑거프린트)까지 종합적으로 봅니다. 화면 해상도, 설치된 폰트, 하드웨어 정보 조합 같은 값들이 동일하면 다른 아이디로 로그인해도 같은 사람이 운영하는 계정으로 묶일 가능성이 커집니다.
대행사 구조에서 이게 특히 위험한 이유는, 담당자 한 명이 하루에도 여러 클라이언트 계정을 오가며 작업하기 때문이에요. 같은 PC, 같은 브라우저 창에서 로그아웃-로그인만 반복하면 겉보기엔 분리된 것 같아도 시스템 입장에서는 동일한 환경으로 인식됩니다.
실무에서 적용하는 분리 기준
제가 팀 운영 규칙으로 정착시킨 원칙은 크게 세 가지입니다.
1. 클라이언트별 독립 프로필
안티디텍트 브라우저를 도입한 이후로는 클라이언트 계정마다 별도의 브라우저 프로필을 만들어 씁니다. 프로필마다 브라우저 지문이 독립적으로 부여되기 때문에, 같은 담당자가 여러 계정을 관리하더라도 플랫폼 입장에서는 서로 다른 사용자로 보입니다. 프로필을 섞어 쓰지 않는 것만으로도 사고 빈도가 눈에 띄게 줄었어요.
2. 계정별 프록시 분리
같은 사무실 공인 IP로 여러 클라이언트 계정에 동시 로그인하는 건 여전히 흔한 실수입니다. 프록시를 계정 단위로 나눠서, 최소한 IP 레벨에서라도 서로 다른 접속 경로를 갖도록 합니다. 다만 프록시만 바꾸고 브라우저 환경은 그대로 두는 경우를 종종 보는데, IP만 다르고 나머지 지문이 같으면 분리 효과가 크게 떨어진다는 점은 꼭 짚고 싶습니다.
3. 계정별 육성 히스토리 독립 관리
신규 계정은 처음부터 사람이 쓰는 것처럼 자연스러운 활동 패턴을 쌓아가는 워밍업 과정이 필요합니다. 이 과정을 클라이언트 계정마다 독립적으로 진행해야 하는데, 급하다는 이유로 워밍업 없이 바로 본 업무에 투입하는 경우 계정 정지로 이어지는 걸 여러 번 봤습니다.
대행사 조직 차원의 운영 규칙
계정 분리는 도구만으로 끝나지 않습니다. 팀 운영 관점에서 아래 규칙을 같이 지켜야 실효성이 있어요.
| 항목 | 권장 방식 |
|---|---|
| 담당자 배정 | 클라이언트별 전담 프로필 지정, 담당자 교체 시 프로필도 함께 인수인계 |
| 접근 권한 | 계정 접속 이력을 팀 내에서 확인 가능하도록 기록 |
| 신규 계정 세팅 | 워밍업 기간을 프로젝트 일정에 미리 반영 |
| 계정 정지 발생 시 | 해당 계정 프로필만 격리, 다른 계정과 프록시·프로필 공유 여부 즉시 점검 |
| 클라이언트 인수인계 | 계정 자격정보와 함께 사용하던 프로필 환경도 통째로 전달 |
특히 신규 클라이언트가 들어올 때마다 '일단 급하니까 기존 환경에서 로그인부터 해보자'는 유혹이 큽니다. 저희 팀은 이 부분을 아예 프로세스로 강제해서, 신규 계정 세팅 요청이 오면 프로필 생성이 선행되지 않으면 다음 단계로 넘어가지 못하도록 체크리스트를 만들어뒀습니다.
계정 정지가 다른 계정으로 번지지 않게
가장 무서운 건 계정 하나의 정지가 아니라 연쇄 정지입니다. 클라이언트 입장에서는 자기 계정만 문제라고 생각하지만, 대행사 내부에서 환경이 얽혀 있으면 다른 클라이언트 계정까지 검토 대상에 오를 수 있습니다. 저는 새로 합류하는 팀원들에게 항상 이 얘기를 제일 먼저 합니다. '네가 지금 로그인하는 이 브라우저 창이 다른 클라이언트 계정과 물리적으로 얼마나 떨어져 있는지 생각하고 작업하라'고요.
계정 분리는 한 번 세팅해두면 끝나는 게 아니라, 팀이 커지고 클라이언트가 늘어날수록 계속 점검해야 하는 항목입니다. 특히 담당자가 바뀌거나 여러 명이 한 계정을 나눠서 관리할 때 분리 원칙이 흐트러지기 쉬운데, 이 지점에서 문제가 자주 터진다는 걸 현장에서 계속 느끼고 있습니다.