같은 공인 IP에서 두 이커머스 계정이 로그인하면 자동으로 묶일까요? 이 가이드는 NAT, CG-NAT, 프록시, 그리고 계정 연관 그래프가 어떻게 맞물려 작동하는지 설명하고, 팀 안에서 환경, 네트워크, 신원, 활동 로그를 설명 가능하게 유지하는 실전 플레이북을 제시합니다.
크로스보더 이커머스에서 "IP 연관"은 보통 플랫폼이 둘 이상의 계정이 같은 공인 IP(또는 관련 IP)에서 자신의 서비스에 접속한 것을 관찰하고, 그 네트워크 신호를 신원·기기·결제·스토어·행동 데이터와 결합해 계정이 같은 사람에게 속하는지, 함께 운영되는지를 판단한다는 뜻입니다.
먼저 흔한 오해를 바로잡습니다. 같은 IP라고 같은 사람이 아닙니다. 가정, 사무실, 호텔, 학교, 이동통신사는 여러 기기를 하나의 공인 IP 뒤에 둘 수 있습니다. 플랫폼은 리스크 모델의 전부를 공개하지 않기 때문에 "IP를 바꾸면 연관이 사라진다"고 보장하는 도구는 없습니다. 신뢰할 수 있는 접근법은 계정 수와 비즈니스 관계를 플랫폼 규칙 안에 두고, 신원, 권한, 네트워크, 활동 기록을 언제든 설명 가능하게 유지하는 것입니다.
IP가 연관 신호가 되는 이유
웹사이트가 요청을 받으면 보통 발신 공인 IP를 봅니다. 플랫폼은 이를 사용해 네트워크 지역을 대략 추정하고, 비정상 로그인을 표시하며, 트래픽을 제한하고, 공격을 방어하고, 사기를 조사할 수 있습니다. 여러 계정이 거의 같은 시각에, 비슷한 기기로, 비슷한 행동으로, 같은 IP에서 로그인하면 플랫폼은 이를 그래프 안의 상관 신호 중 하나로 취급합니다.
공인 IP가 단일 기기에 묶이는 경우는 드뭅니다. Cloudflare의 멀티유저 IP 주소에 대한 기술 노트는 가정용·사무실용 라우터가 NAT을 통해 하나의 공인 IP를 여러 기기에 공유할 수 있고, 캐리어급 NAT(CG-NAT)은 수백에서 수천 명의 가입자를 한 주소 또는 작은 주소 풀에 매핑할 수 있다고 설명합니다. 공유 네트워크에서 IP만으로 사용자를 가리려 하면 시스템은 오판을 내립니다.
더 정확한 표현: IP는 연관 그래프의 노드일 뿐, 최종 결론이 아닙니다.
플랫폼이 IP之外에 보는 것들
신원과 연락처 정보
반복되는 회사명, 법정대표, 개인 신원, 주소, 전화번호, 이메일, 세금 식별자, 실질적 수익자는 단일 IP보다 비즈니스 관계를 더 잘 설명합니다.
결제와 재무 정보
신용카드, 은행 계좌, 정산 계좌, 청구 주소, 세금 번호, 자금 흐름은 강한 연결을 만듭니다. 서로 다른 계정이 결제 수단을 공유하거나 계정 간 거래를 하면 사기 또는 시장 조작 조사로 이어질 수도 있습니다.
기기와 브라우저 상태
쿠키, 로컬 스토리지, 기기 식별자, 브라우저 핑거프린트, 운영체제, 폰트, 화면 크기, 확장 프로그램은 세션이 동일한 물리적 환경(혹은 매우 비슷한 환경)에서 오는지 판단하는 데 쓰일 수 있습니다.
로그인과 멤버 관계
같은 직원이 여러 스토어에 로그인하거나, 한 에이전시가 여러 클라이언트를 운영하거나, 계정끼리 자원을 공유하도록 권한을 부여하면 그 연결은 쉽게 읽힙니다. 문제는 그 연결이 있는가가 아니라, 플랫폼이 허용하는 연결인지, 팀이 정직하게 신고했는지입니다.
카탈로그, 콘텐츠, 풀필먼트
동일한 상품 이미지, 카피, 재고, 창고, 반송 주소, 운송장 번호, 고객 응대 템플릿, 비정상 주문 패턴은 어떤 IP보다 직접적으로 공동 운영을 드러냅니다.
행동 패턴
동시에 로그인/로그아웃하기, 정해진 순서로 작업하기, 같은 자동화 스크립트 돌리기, 서로 구매·평가하기, 한 계정이 제한되자마자 다른 계정으로 옮겨가기 — 모두 회피 또는 조율된 행동으로 읽힙니다.
IP 연관으로 자주 표시되는 시나리오
여러 계정이 오피스 네트워크를 장기 공유
계정이 정말 같은 회사에 속하고 플랫폼이 그 구성을 허용한다면 공유 네트워크는 자동으로 위반이 아닙니다. 다만 팀은 플랫폼이 제공하는 정식 멤버 역할을 사용하고 비즈니스 관계를 문서로 남겨야 합니다. 계정이 독립이라고 신고되어 있는데 네트워크·결제·기기를 공유하면, 질문이 들어왔을 때 해명하기가 훨씬 어려워집니다.
공용 Wi-Fi와 모바일 네트워크
카페, 공항, 캐리어급 NAT는 많은 사용자를 한 공인 IP 뒤에 묶습니다. 일회성 중복이 동일 운영자의 증거가 될 수는 없지만, 이 네트워크는 안정성과 보안성이 떨어져 추가 로그인 확인이나 최악의 경우 계정 탈취를 유발할 수 있습니다.
무료 또는 빠르게 회전하는 프록시
오픈 프록시는 많은 미지의 사용자에 의해 남용되기 쉽습니다. IP 신뢰도가 낮고, 지리 정보가 흔들리고, 연결이 불안정하며, 트래픽이 가로채일 수도 있습니다. 짧은 시간에 국가나 네트워크를 공격적으로 바꾸면 비정상 로그인 가능성이 올라갑니다.
원격 팀원이 하나의 마스터 비밀번호를 공유
여러 나라에서 같은 마스터 계정에 번갈아 로그인하면 플랫폼은 끊임없이 점프하는 기기·위치·시간 패턴을 봅니다. 팀 또한 누가 무엇을 했는지 추적하기 어렵고, 사람이 떠날 때 접근을 빠르게 회수하기도 어렵습니다.
한 계정이 제한된 후 다른 계정에서 계속 운영
대부분의 플랫폼은 신규 또는 기존 계정을 사용해 제한을 우회하는 것을 금지합니다. eBay의 다중 계정 정책은 구매·판매·별도 제품 라인을 위해 여러 계정을 둘 수 있다고 허용하면서도, 한도를 회피하기 위해 다른 계정을 만들거나 사용하는 것은 명시적으로 금지합니다. 한 계정이 제한되면 비슷한 제한이 연관된 계정으로 확장될 수 있습니다.
계정이 연관되면 어떤 일이 벌어지는가
- CAPTCHA, 기기 확인, 신원/사업자 재확인이 자주 뜬다.
- 리스팅, 구매, 광고, 출금 한도가 낮아진다.
- 리스팅이 내려지고, 트래픽이 제한되며, 계정이 수동 검토로 들어간다.
- 결제가 멈추거나 자금 보류 기간이 늘어난다.
- 한 계정에 내린 조치가 연관 계정으로 퍼진다.
- 최악의 경우 기능 제한, 정지 또는 영구 폐쇄.
eBay의 계정 제한 페이지는 미해결 수수료·구매자 문제, 정책 위반, 본인 확인 불가, 제3자 접근 의심 등을 이유로 꼽으며, 제한이 해제될 때까지 셀러의 지급이 보류될 수 있다고 명시합니다.
Amazon 셀러 포럼의 공식 안내는 정당한 사업적 필요가 있을 때에만 다중 판매 계정을 운영할 것과 모든 계정을 양호한 상태로 유지할 것을 셀러에게 상기시킵니다. 한 계정에 대한 조치가 다른 계정에도 영향을 줄 수 있습니다. 안내는 정당한 예로 별도 브랜드, 별도 회사용 제품, 별도 계정을 요구하는 플랫폼 프로그램 등을 듭니다.
IP 연관 리스크를 설명 가능하고 컴플라이언트하게 만들기
1. 먼저 플랫폼이 다중 계정을 허용하는지 확인
계정을 만들기 전에 Seller Code, Multiple Accounts Policy, 팀 권한 규정, 지역별 자격을 확인합니다. 정당한 사업 필요가 있다면 회사 등록, 브랜드 소유권, 계약, 조직도 같은 근거 자료를 보관합니다. 플랫폼이 1인 1계정만 허용한다면 기술적 우회로 더 만들지 마세요.
2. 정식 서브 계정과 팀 역할을 우선 사용
직원, 에이전시, 서비스 제공자는 마스터 계정 비밀번호를 공유하는 대신 각자의 멤버 신원을 가져야 합니다. 업무 범위에 맞춰 리스팅·주문·광고·리포트 권한을 부여하고 2단계 인증을 켜세요.
3. 신원 정보는 진짜로, 관계는 설명 가능하게
회사, 주소, 전화, 세금, 정산, 실질적 수익자 정보는 일관되어야 합니다. 관련 회사가 실제로 주주·창고·서비스 제공자를 공유한다면, 그 관계는 계약과 플랫폼이 허용하는 인가 메커니즘을 통해 신고되어야지, 마치 독립된 실체인 것처럼 위장되어선 안 됩니다.
4. 안정적이고 신뢰할 수 있는 업무 네트워크 사용
오피스 직원은 정상적인 기업·가정·모바일 네트워크로 접속합니다. 프록시가 정말 필요하면 합법적 출처, 정확한 지역, 안정적인 연결, 인가된 업무에 한정된 사용을 갖춘 서비스를 고르세요. 무료 프록시, 광범위하게 남용되는 데이터센터 출구, 타이머로 공격적으로 회전하는 IP는 피해야 합니다.
"안정"은 IP가 영원히 얼어붙어야 한다는 뜻이 아닙니다. 직원은 출장하고, 통신사는 인프라를 바꾸고, 사건은 마이그레이션을 강제합니다. 핵심은 변화가 실제 업무와 부합하고, 로그인 알림과 사고 기록이 보존되는 것입니다.
5. 각 계정에 명시된 책임자 연결
모든 계정에 대해 법인, 마켓플레이스, 용도, 주 관리자, 주로 쓰는 지역, 기기, 네트워크, 결제 수단, 복구 절차를 기록합니다. 승인 없는 계정 간 로그인은 허용하지 말고, 직원 퇴사나 계약 종료 당일에 접근을 회수하세요.
6. 브라우저 상태를 분리해 운영 실수 줄이기
서로 다른 클라이언트·스토어의 쿠키·로컬 스토리지·확장 프로그램은 분리된 환경에 둡니다. 그래야 잘못된 대시보드를 열거나, 잘못된 청중에 메시지를 보내거나, 한 스토어의 자산을 다른 스토어로 복사하는 일이 줄어듭니다. 분리의 목적은 운영 정확성과 명확한 데이터 경계이지, 실제 정체를 숨기는 것이 아닙니다.
7. 카탈로그와 풀필먼트를 독립적이고 설명 가능하게 유지
여러 합법 스토어가 같은 창고, 고객 응대, 물류 파트너를 공유한다면 플랫폼이 허용하는지 확인하고 서비스 계약을 보관합니다. 서로 구매하거나 가짜 리뷰를 교환하거나 저작권 이미지를 복제하지 말고, 한 계정이 제한된 후 주문과 재고를 다른 계정으로 옮겨 처벌을 회피하지 마세요.
8. 로그인 활동과 보안 알림을 계속 주시
플랫폼의 최근 활동, 기기, 보안 이벤트를 정기적으로 확인하세요. Google의 최근 계정 활동 관련 노트는 시스템이 접근 시각·IP·대략적 위치를 기록하고, 이동통신사와 제3자 앱이 서로 다른 주소를 표시할 수 있다고 알려줍니다. 알 수 없는 로그인을 발견하면 즉시 비밀번호를 바꾸고, 활성 세션을 취소하고, 복구 옵션을 확인하세요.
이미 다중 계정·다중 브랜드·다중 지역이라면: 환경을 어떻게 설명 가능하게 둘 것인가
운영이 "한 스토어, 두 사람"을 넘어서면 위 모든 단계가 여러 브랜드·지역·팀원 위에서 동시에 돌아갑니다. 스프레드시트, 공유 비밀번호, 사후 채팅 로그로는 거의 반드시 무언가가 빠집니다.
바로 이 지점에서 계정, 브라우저 환경, 프록시, 명시된 책임자, 활동 로그를 한 워크스페이스에서 관리하는 것이 가장 좋습니다. PurpleMark를 예로 들면:
- 인가된 각 사업 계정용으로 전용 브라우저 환경을 만들고, 각각의 쿠키, 프록시, 언어, 시간대, 지리 정보, 브라우저 파라미터를 둡니다. 그래야 팀원이 잘못된 대시보드를 열거나 한 스토어의 캐시를 다른 스토어로 끌고 가지 않습니다.
- 각 환경을 특정 프록시에 묶고 outbound IP를 표시합니다. 첫 로그인 전에 환경 안에서 IP 확인 페이지를 열어 출구 IP가 실제 사업 지역과 일치하는지 확인하고, 프록시를 바꿀 때마다 이전 IP, 새 IP, 사유, 일자, 확인 결과를 기록하세요.
- 환경을 브랜드·지역·클라이언트·사업 라인 단위로 그룹화하고, 그룹 설명에 책임자, 연결된 계정, 짧은 메모를 적습니다. 입사·퇴사·역할 변경 시 공유·이전·권한 회수를 통해 환경을 인계합니다.
- 활동 로그를 켜서 로그인, 파라미터 변경, 공유, 이전, 삭제가 멤버와 타임스탬프로 추적되게 합니다. 연관이 의심될 때 팀은 로그에서 출발해 원인 계정을 찾고, 플랫폼 요구에 따라 바로잡을 수 있습니다.
이 단계가 답하는 것은 "환경을 어떻게 운영하며, 누가 위에 있고, 무엇이 바뀌었는가"라는 질문이며, 플랫폼 규칙이나 진짜 신원 정보, 정당한 사업 이유를 대신하지 않습니다.
잘못된 연관이 의심될 때의 대응
상황이 더 커지지 않도록 막기
IP를 계속 바꾸거나, 새 계정을 등록하거나, 로그인을 반복하지 마세요. 계정 간 운영을 동결하고 플랫폼 알림, 타임스탬프, 기기, 네트워크 정보, 멤버 기록을 보관합니다.
원인 계정을 찾기
이전 계정, 글로벌 스토어, 서비스 제공자 로그인, 퇴사자, 공유 결제 수단, 공통 창고, 미검증 마켓플레이스가 있는지 확인합니다. 잊혀진 계정이 연관 체인의 시작점인 경우가 많습니다.
알림의 각 항목을 하나씩 처리
원래의 위반·체불·신원·풀필먼트 문제를 먼저 해결하고, 이후 영향받은 계정을 다룹니다. "IP가 다르다"는 스크린샷은 대화를 진전시키기 어렵습니다. 플랫폼은 다른 증거에 기대어 판단할 수 있습니다.
플랫폼이 검증할 수 있는 자료 준비
회사 등록, 브랜드 소유권, 지분 구조, 계약, 사무실 주소, 멤버 명단, 정산 계좌, 창고 계약, 로그인 로그, 명확한 네트워크 설명이 유용합니다. 공유 IP가 오피스 NAT, 캐리어급 NAT, 외주 서비스 제공자 때문이라면 시간 범위와 사업 맥락을 함께 설명하세요.
공식 이의 제기 채널만 사용
Seller Central, 플랫폼 메시지, 헬프 센터를 통해 제출하세요. 원격 제어, 인증 코드, 사적 결제를 요구하는 "대리 이의 제기 서비스"는 경계해야 합니다.
자주 묻는 질문
같은 IP에서 로그인한 두 계정이 모두 정지되나요?
반드시 그렇지는 않습니다. NAT과 CG-NAT 때문에 많은 사용자가 공인 IP를 공유하며, 플랫폼은 보통 신원·기기·결제·행동·풀필먼트를 함께 따져봅니다. 다만 플랫폼이 다중 계정을 금지하거나 회피 단서가 있다면 공유 IP는 리스크 그림에서 의미 있는 부분이 됩니다.
계정마다 다른 프록시면 안전한가요?
아닙니다. 프록시는 네트워크 출구의 일부만 바꾸며 신원·결제·카탈로그·기기·행동·사업 관계를 바꾸지 못합니다. 저품질 프록시는 평판·지리 정보·계정 탈취 리스크까지 동반합니다.
가족 구성원이 서로 다른 스토어를 운영한다면 어떻게 해야 하나요?
플랫폼 정책을 확인하고, 진짜 신원과 공식 권한이 있는 별도 계정을 사용하며, 실체·카탈로그·결제·풀필먼트의 증거를 보관하세요. 서로의 계정에 로그인하지 말고, 서로에게 구매·평가하지 않으며, 상대 계정으로 제한을 우회하지 마세요.
연관된 후 옛 계정을 바로 닫아도 되나요?
권장하지 않습니다. 증거를 지우거나 처리를 회피하면 이의 제기에서 오히려 불리해질 수 있습니다. 먼저 계정의 원래 문제를 해결하세요. 계정을 닫아도 과거의 연관은 사라지지 않습니다.
정리
IP 연관은 "한 주소 = 한 사람"이 아니라, 플랫폼이 신원·기기·결제·카탈로그·풀필먼트·행동을 네트워크라는 입력과 함께 계정 관계 그래프로 꿰매는 작업입니다. 오피스나 통신사의 공유 IP는 정상입니다. 하지만 비컴플라이언트 다중 계정 구성, 비밀번호 공유, 저품질 프록시, 적극적 회피는 연관을 실제 결과로 바꿔버립니다.
리스크를 줄이는 핵심은 "설명 가능한 컴플라이언스"입니다. 플랫폼이 허용하는 계정만 만들고, 공식 팀 역할을 사용하며, 신원 정보를 진짜로 유지하고, 안정적인 네트워크를 고르고, 브라우저 상태를 분리하고, 멤버 활동을 기록하며, 제한을 받았을 때 먼저 원인 계정을 처리합니다. 환경과 프록시를 잘 관리하면 혼선과 실수가 줄고, "누가 어느 네트워크에 있는지, 무엇이 바뀌었는지, 그 행동이 컴플라이언트인지"를 언제든 조회할 수 있습니다.
