AWS(Amazon Web Services) 본사는 벨뷰·린우드에서 차로 금방인 시애틀에 있고, 이 지역에서는 한인 네일샵 그룹, 레스토랑 체인, 병의원이 두 번째, 세 번째 매장을 점점 더 많이 열고 있습니다. 아이러니한 건 그중 AWS를 쓰는 곳이 거의 없다는 겁니다. 새 매장이 열릴 때마다 각자의 POS, 각자의 예약장부나 예약 앱, 각자의 스프레드시트가 생기고, 사장님은 매장이 하나든 넷이든 똑같은 방식으로 사업을 운영하게 됩니다 — 오늘 하루가 어땠는지 알아보려고 매니저마다 따로 문자를 보내면서요. AWS가 바로 옆에 있어도, 그게 실제로 무엇을 해결해줄 수 있는지 한국어로 쉽게 설명해준 사람이 없었다면 아무 소용이 없습니다.
매장 하나에선 통했던 스프레드시트가 둘이 되면 무너지는 이유
매장 하나짜리 사업은 감각으로 돌아갑니다 — 사장님이 보통 그 자리에 있거나 전화 한 통 거리에 있고, POS 하나가 모든 이야기를 들려줍니다. 두 번째 매장이 열리는 순간 그게 더 이상 사실이 아니게 되는데, 대부분의 사장님은 예전 시스템을 교체하지 않고 그 주변에서 더 열심히 일합니다 — 하루 매출을 더하려고 POS 로그인을 두 번 오가고, 어느 직원이 어느 매장에서 옮겨왔는지 머릿속으로 기억하고, 각 PC의 백업이 실제로 돌아가고 있길 바라면서요. 한동안은 버팁니다. 하지만 세 매장이 한꺼번에 바쁜 명절 연휴, 매니저가 예고 없이 그만두는 순간, 또는 더 이상 근무하지 않는 매장의 로그인을 아무도 확인하지 않았다는 사실 — 이런 순간에는 버티지 못합니다.
성장 중인 다매장 한인 사업체에서 가장 자주 보는 위험들:
- 통합된 시각이 없음 — 매출, 예약, 재고가 매장마다 각자 다른 시스템에만 존재해서, "사업이 어떻게 돌아가고 있는가"를 알려면 여기저기 전화를 돌려야 합니다.
- 접근 권한이 매장이 아니라 사람을 따라다니지 않음 — 다른 매장으로 옮기거나 퇴사한 직원이 몇 달 뒤에도 체인의 다른 매장 로그인이 여전히 작동하는 경우가 흔합니다.
- 백업이 계산대 하나에만 있음 — 각 매장의 POS 단말기나 사무실 PC가 그 자체로 단일 장애점이고, 매장 전체를 아우르는 공유된 자동 백업이 없습니다.
- 공유된 고객·예약 기록이 없음 — 두 매장을 모두 이용하는 단골이 서로 다른 두 명의 고객처럼 보이고, 한 매장의 노쇼가 다른 매장에서는 표시되지 않습니다.
- 한 매장이 멈췄을 때의 대책 없음 — 바쁜 주에 한 매장의 인터넷, POS, 서버 중 하나가 고장 나면 빠르게 복구할 문서화되고 테스트된 방법이 없습니다.
다매장 사업을 위한 AWS 클라우드 컨설팅이 다루는 영역
AWS는 아마존의 클라우드 인프라 플랫폼으로, 하드웨어를 사는 대신 사용한 만큼 빌려 씁니다. "컨설팅"이란 소프트웨어 스타트업을 위한 일반 템플릿이 아니라, 다매장 사업이 실제로 운영되는 방식에 맞는 구체적인 구성 요소들을 설계하는 것을 뜻합니다.
다매장 AWS 구성의 구체적인 요소들과, 각각이 해결하는 문제:
- RDS(관리형 데이터베이스) — 각 매장의 POS나 예약 시스템에서 나오는 매출·예약·재고 데이터가 하나의 데이터베이스로 모여, 아무에게도 전화하지 않고 대시보드 하나로 통합 숫자와 매장별 숫자를 볼 수 있습니다.
- IAM(접근 권한 관리) — 접근 권한이 매장이 아니라 역할(role)에 묶여서, 직원이 옮기거나 퇴사하면 매장마다 로그인을 찾아다닐 필요 없이 한 번에 모든 곳에서 접근이 차단됩니다.
- S3 저장소 + 자동 백업 — 모든 매장이 같은 일정으로 같은 안전한 저장소에 백업되어, 계산대 하나나 사무실 PC 한 대의 고장이 그 매장 기록 전체의 단일 장애점이 되지 않습니다.
- Site-to-Site 또는 Client VPN — 매장들과 중앙 사무실이 암호화된 터널로 연결되어, 매장 간 오가는 데이터가 열려 있는 일반 인터넷을 타지 않습니다.
- CloudFront(CDN)와 오토스케일링 — 공유된 예약 사이트나 주문 플랫폼이 프로모션이나 명절 연휴에 모든 매장에서 몰리는 트래픽을 느려지지 않고 감당합니다.
- 비용 최적화 — 항상 켜져 있는 부분(공유 데이터베이스, 대시보드)에는 예약 인스턴스나 Savings Plans를 적용해, 매일 돌아가는 예측 가능한 인프라에 온디맨드 가격을 계속 내지 않도록 합니다.
AWS 본사가 옆집이어도, 그게 사장님 회사의 언어로 말해주지는 않습니다
시애틀·벨뷰 지역의 대부분의 한인 사장님들은 AWS를 "아마존 쇼핑 회사의 클라우드 뭔가" 정도로 알고 있고, 그게 네일샵이나 레스토랑 그룹에 적용된다고 생각해본 적이 거의 없습니다. 이 간극은 사장님이 몰라서 생긴 게 아니라, 그걸 설명해주는 사람이 없어서 생긴 간극입니다. 일반 현지 클라우드 컨설턴트는 테크 기업에 판매하고 엔지니어와 대화하도록 만들어져 있어서, "접근 권한 관리가 왜 중요한가요", "한 매장의 인터넷이 근무 중에 끊기면 어떻게 되나요" 같은 질문을 하는 다매장 리테일·서비스 사업체는 너무 작은 질문 취급을 받거나, 사업에서 굳이 쌓을 이유가 없었던 기술적 배경을 전제한 전문 용어투성이 답을 받게 됩니다. 저희는 이 영역도 사업의 다른 모든 부분과 똑같이 다룹니다 — 한국어든 영어든, 첫 상담부터 지속 관리까지 같은 담당자가, 카카오톡으로 바로 연락 가능하게.
실제로는 이렇게 구축됩니다
저희는 모든 매장을 아우르는 감사(audit)로 시작합니다 — 각 매장이 어떤 시스템을 쓰고 있는지, 누가 무엇에 접근할 수 있는지, 내일 뭔가 고장 난다면 어느 단일 장애점이 가장 크게 아플지 파악합니다. 여기서부터 사업이 실제로 운영되는 방식에 맞춰 AWS 구성 요소를 설계하고, 어느 매장의 일과도 방해받지 않도록 단계적으로 구축합니다 — 보통 통합 대시보드부터 시작합니다. 가장 빠르게 눈에 보이는 성과이고 직원들이 기존 POS를 쓰는 방식은 전혀 바뀌지 않기 때문입니다. 그다음 가장 위험한 구멍을 막아주는 접근 권한 관리와 백업으로 이어지고, 공유 예약·주문 플랫폼처럼 고객과 맞닿는 부분으로 마무리합니다. 구축이 끝나도 관계가 끝나는 게 아닙니다 — 모니터링, 백업 확인, 접근 권한 점검이 지속 서비스로 이어집니다. 저희가 장기 클라이언트의 웹사이트를 관리하는 방식과 똑같습니다.