유럽에 서버를 두었다고 광고하는 클라우드 서비스는 많다. 그러나 그 서버가 실제로는 아마존웹서비스(AWS)나 클라우드플레어 같은 미국 기업의 인프라 위에서 돌아가는 경우가 적지 않다. 스웨덴 스톡홀름에서 에릭 셀린(Eric Selin)이 만든 정적 사이트 호스팅 서비스 statichost.eu는 바로 이 지점을 문제 삼는다. 창업자는 '유럽 호스팅'이라면서 미국 클라우드 위에서 운영되는 방식에 지쳐 대안을 만들었다고 밝힌다. 깃 배포부터 CDN까지 스택의 모든 계층을 유럽 기업이 소유한 유럽 인프라 위에서 돌리며, AWS도 클라우드플레어도 예외 없이 쓰지 않는다는 것이 핵심 주장이다.
무엇을 제공하는가
기능 자체는 최근 정적 호스팅 서비스들과 크게 다르지 않다. 깃(git)에 코드를 푸시하면 빌드와 배포가 이뤄지고, 사용자 정의 도메인을 연결하면 끝이다. 창업자는 첫 사이트를 2분 안에 무료로 배포할 수 있다고 설명한다. 정적 파일로 빌드되는 것이라면 어떤 정적 사이트 생성기(SSG)든, 어떤 깃 제공자든 동작한다고 강조한다. 즉 특정 프레임워크나 특정 깃 호스팅에 묶이지 않는 범용성을 내세운 셈이다. 프런트엔드 개발자가 일상적으로 쓰는 배포 흐름을 그대로 유지하면서 인프라의 국적만 바꾸는 것을 목표로 한다.
차별점은 기능이 아니라 인프라의 소유 구조와 위치에 있다. statichost.eu는 단순히 '유럽에 있는 서버'가 아니라 유럽 회사, 유럽 인프라, 유럽적 가치를 배포부터 CDN까지 일관되게 적용한다고 말한다. 인터넷이 너무 복잡해졌고, 너무 많은 계층과 벤더가 끼어들면서 신뢰가 조용히 미국 기업들에게 넘어갔다는 것이 창업자의 문제의식이다. 누가 인프라 뒤에 있고 데이터가 어디에 놓이는지가 중요하다는 관점이다.
왜 지금 이 주제가 중요한가
이런 주장이 설득력을 얻는 배경에는 유럽의 데이터 주권 논의가 있다. 유럽연합은 개인정보보호규정(GDPR)을 통해 데이터 처리 주체와 위치를 오래 규제해왔고, 미국 클라우드 사업자에 대한 의존을 줄이려는 '디지털 주권' 담론도 꾸준히 확산돼왔다. 미국의 클라우드법(CLOUD Act)처럼 역외 데이터 접근을 둘러싼 법적 긴장도 이런 흐름을 자극한 요인으로 꼽힌다. statichost.eu는 이 맥락을 겨냥해, 데이터센터 위치만이 아니라 그 위에서 도는 관리 계층과 CDN까지 미국 기업을 배제했다는 점을 판매 논리로 삼는다.
한국 실무자에게도 이 사례는 시사점이 있다. 많은 기업이 배포 편의성을 이유로 사실상 소수의 미국 클라우드와 CDN에 인프라를 위임하고 있고, 공급망 관점에서 보면 이는 단일 벤더 종속과 관할권 리스크로 이어진다. statichost.eu가 던지는 질문—내 사이트가 어디에, 누구의 인프라 위에 사는가—은 규제 대응이나 조달 요건이 까다로운 공공·금융·의료 분야에서 특히 실질적인 검토 항목이 될 수 있다. 정적 사이트는 데이터 민감도가 상대적으로 낮은 편이지만, 인프라 국적을 통제 가능한 변수로 다룬다는 발상 자체가 확장 가능한 원칙이다.
한계와 유의점
다만 냉정하게 볼 대목도 있다. statichost.eu는 현재 창업자 개인이 주도하는 초기 단계 서비스로 보이며, 공개된 정보만으로는 가격 정책의 상세, 가용성 보장(SLA), 지원 규모, 지역 엣지 노드의 분포 같은 운영 성숙도를 판단하기 어렵다. 특히 CDN의 강점은 전 세계에 분산된 엣지에서 나오는데, '유럽 인프라만 사용'한다는 원칙은 아시아나 미주 사용자를 대상으로 하는 사이트에서는 지연시간 측면에서 불리하게 작용할 수 있다. 한국에서 접속하는 서비스라면 이 부분을 실제 측정으로 확인해야 한다.
또한 '미국 기업 배제'가 곧 기술적 우월성이나 안정성을 의미하지는 않는다. 그것은 가치와 관할권에 대한 선택이지 성능 지표가 아니다. 대규모 트래픽, 정교한 빌드 파이프라인, 서버리스 함수 같은 고급 기능이 필요한 팀이라면 성숙한 대형 플랫폼과의 기능 격차를 함께 저울질해야 한다. 결국 statichost.eu의 가치는 '기능이 더 많아서'가 아니라 '데이터가 어디에 사는지를 스택 전체에서 통제하고 싶은가'라는 요구가 분명한 조직과 개발자에게 있다. 그런 요구가 있다면 무료로 첫 사이트를 올려 지연시간과 배포 경험을 직접 확인해보는 것이 판단의 출발점이 될 것이다.