애틀랜타 권역 — 둘루스, 스와니, 존스크릭, 알파레타 — 에서 확장 중인 한인 식당·마트 사장님들에게서 자주 보는 패턴이 있습니다. 두 번째, 세 번째 지점을 열면서, 집에서 와이파이 설정하듯 첫 지점과 연결합니다. 가정용 공유기, 새 매니저에게 문자로 알려준 공용 비밀번호, 그리고 나머지 모든 것과 같은 네트워크에 꽂힌 POS 단말기. 문제가 터지기 전까진 잘 돌아갑니다 — PCI 심사 중 카드 결제 관련 문제, 한 번도 일한 적 없는 매장에서 여전히 살아있는 퇴사 직원의 로그인, 또는 전화 세 통 없이는 세 지점의 오늘 매출을 볼 방법이 없다는 사실. 바로 이 지점에서 AWS 네트워크 아키텍처가 시작됩니다. 여러 지점에서 카드 결제를 받는 식당·리테일 사업체에게 이건 선택 인프라가 아니라, 카드 결제 업체가 이미 있다고 전제하는 배관입니다.
분리되지 않은 평평한 네트워크가 실제로 안고 있는 위험
대부분의 사장님들은 보안을 "해킹당했는가" — 극적이고 드문 사건으로 생각합니다. 더 흔한 위험은 조용합니다. 경계가 없는 네트워크에서는, 감염된 손님용 와이파이 기기, 6개월 전부터 여전히 연결된 옛 직원 폰, 설치를 위해 잠깐 꽂은 업체 노트북까지 전부 기술적으로 POS 단말기 및 카드 결제 트래픽과 같은 네트워크 구간에 닿을 수 있습니다. 이걸 각자 다른 매니저가 운영하고, 상자에 들어있던 공유기로 각자 알아서 IT 결정을 내리는 세 지점에 곱하면, 한 곳에서 확인할 수도 없는 서로 다른 세 가지 노출 수준이 만들어집니다.
성장 중인 다지점 F&B·리테일 사업체를 감사할 때 가장 자주 발견하는 것들:
- 매장당 하나의 평평한 네트워크 — POS 단말기, 백오피스 컴퓨터, 손님용 와이파이가 전부 같은 네트워크에 있어서, 그 안의 감염된 기기 하나가 카드 결제 트래픽에 닿을 수 있습니다.
- 문자로 돌려쓰는 하나의 공용 POS·와이파이 로그인 — 누가 언제 어디서 로그인했는지 기록이 없습니다.
- 지점 간 연결이 전혀 없음 — 각 매장의 매출·재고 데이터가 각자의 섬에 있어서, "전 지점 오늘 매출"을 확인하려면 전화 세 통이나 앱 로그인 세 번이 필요합니다.
- 회수되지 않은 퇴사 직원과 없어진 지점(문 닫은 팝업, 시즌 매대)의 접근 권한 — 중앙에서 회수할 곳이 없었기 때문입니다.
- 누가 무엇에 언제 접근했는지 기록이 없음 — 카드 거래 분쟁이나 데이터 관련 질문이 생겨도 확인할 기록이 없습니다.
제대로 된 다지점 AWS 구성이 실제로 다루는 영역
이건 POS 시스템을 교체하는 게 아닙니다 — Toast, Clover, Square 모두 이미 결제 처리 자체는 자기 쪽에서 안전하게 처리하고 있습니다. AWS 네트워크 아키텍처가 메꾸는 빈틈은 그 주변 전부입니다 — 지점들이 서로 어떻게 연결되는지, 누가 무엇에 접근할 수 있는지, 그리고 사업 데이터(매출 이력, 재고 수량, 직원 기록)가 실제로 어디에 있고 어떻게 백업되는지.
구체적인 구성 요소들과, 각각이 해결하는 문제:
- 지점 간 사이트투사이트 VPN — 각 매장이 열려 있는 인터넷 대신 중앙의 암호화된 터널로 연결돼서, 매출·재고 데이터가 지점 사이를 이동할 때 절대 비보안 연결을 거치지 않습니다.
- 매장별 네트워크 분리 — POS 단말기가 손님용 와이파이, 백오피스 컴퓨터, 업체 기기와 분리된 독립 네트워크 구간에 있어서, 한 구간의 감염된 기기가 다른 구간의 카드 결제 트래픽에 닿지 못합니다.
- 중앙 IAM(접근 권한 관리) — 모든 지점의 접근 권한을 부여·회수하는 곳이 한 곳뿐이라서, 매니저가 매장을 옮기거나 직원이 퇴사하면 매장별로 로그인을 일일이 찾을 필요 없이 전체 접근이 동시에 차단됩니다.
- 관리형 데이터베이스(RDS)를 통한 실시간 데이터 동기화 — 모든 지점의 매출·재고 수치가 하나의 대시보드로 모여서, 사장님이 POS 앱 세 개에 각각 로그인하지 않고 폰으로 바로 확인할 수 있습니다.
- 중앙 백업·로그(S3 + CloudTrail) — 매출 기록, 재고 이력, 접근 로그가 자동으로 백업되고, 카드 거래 분쟁이나 재고 불일치, 보안 관련 질문이 생기면 언제든 확인할 수 있는 곳에 저장됩니다.
- 네트워크 경계의 웹 애플리케이션 방화벽과 보안 그룹 — 무단 접근 시도가 매장 시스템에 닿기 전에 각 지점에서 자동으로 차단하는 규칙들.
한인 소유 다지점 사업체에게 특히 이게 더 중요한 이유
이런 네트워크·컴플라이언스 작업은 충분히 전문적이라 대부분의 사장님들이 합리적으로 다른 사람에게 맡기는 영역입니다 — 문제는 누구에게, 어떤 언어로 맡기느냐입니다. 큰 일반 MSP도 기꺼이 계약을 받겠지만, PCI 확인 서류와 보안 정책 설명, 지원 전화가 영어로, 그들의 일정대로, 미국 IT·컴플라이언스 관행에 익숙하다는 전제 하에 옵니다 — 1세대나 1.5세대로 가족 식당·마트 그룹을 운영하는 사장님이 굳이 쌓을 이유가 없었던 익숙함이죠. 이건 웹사이트 프로젝트보다도 판돈이 큽니다 — 카드 결제 데이터와 매일의 매출이 걸려 있으니까요. "잠깐, 이게 우리한테 정말 해당되나요"나 "매장 하나가 문을 닫으면 그 데이터는 어떻게 되나요" 같은 질문에 한국어든 영어든 명확한 답을 듣는 것이 중요합니다. 저희는 이 영역도 Zoe Lumos의 다른 모든 일과 똑같이 다룹니다 — 초기 감사부터 지속 관리까지 한 사람이, 금요일 밤 11시에 뭔가 이상해 보이면 카카오톡으로 바로 연락 가능하게.
실제 진행은 어떻게 이뤄지나
저희는 지금 각 지점에 무엇이 있는지 파악하는 것부터 시작합니다 — 짐작이 아니라, 매장별 실제 네트워크, POS 구성, 누가 무엇에 접근하는지 직접 확인합니다. 여기서부터 일반 템플릿이 아니라 사장님 사업의 구체적인 형태(지점 수, POS 업체, 올해 추가로 지점을 여실 계획인지)에 맞춘 아키텍처를 설계하고, 어느 매장도 연결이 끊기지 않도록 지점별로 순차 적용합니다 — 가장 위험한 구멍을 가장 빨리 막아주는 매장별 POS 네트워크 분리부터 시작해서, 지점을 잇는 VPN, 그다음 중앙 접근 권한 관리와 실시간 대시보드 순입니다. 그 기간 내내 직원들은 기존 시스템으로 계속 일합니다 — 지점 하나당 전환 작업은 보통 한산한 시간대에 이뤄지고 하루가 아니라 몇 분입니다. 적용이 끝난 뒤에도 모니터링과 접근 권한 점검이 지속 서비스로 이어집니다 — 세 개의 POS 로그인 중 어떤 게 아직 살아있는지 기억할 필요 없이, 시즌마다 같은 PCI 확인을 반복합니다.