--- title: "디지털 스택을 유럽으로 옮겨보니, 생각보다 꽤 실전적이었다" published: 2026-05-13T11:42:20.000Z canonical: https://jeff.news/article/2630 --- # 디지털 스택을 유럽으로 옮겨보니, 생각보다 꽤 실전적이었다 한 개발자가 분석, 메일, 비밀번호 관리, 컴퓨트, 오브젝트 스토리지, 백업, 이메일, 에러 추적, AI API까지 유럽 중심 스택으로 옮긴 경험을 정리한 글이다. 핵심은 반미 감정이 아니라 데이터가 어디에 있고, 누가 접근할 수 있고, 정치나 기업 정책 변화에 얼마나 휘둘리는지를 의식하자는 얘기다. ## 왜 굳이 유럽 스택으로 옮겼나 - 글쓴이가 말하는 ‘디지털 주권’은 거창한 구호가 아니라, 내 비즈니스가 의존하는 도구를 누가 통제하는지 따져보자는 얘기임 - 데이터가 어디에 저장되는지, 어떤 관할권을 따르는지, 특정 기업의 정책 변경이나 인수합병 한 방에 접근권이 날아갈 수 있는지를 봐야 한다는 것 - “편해서 쓰는 SaaS”가 어느 순간 비즈니스의 약한 고리가 될 수 있다는 불편함에서 시작함 - 목표는 미국 서비스를 전부 끊는 게 아니라, 가능한 영역부터 유럽 또는 자기 통제권이 더 큰 대안으로 바꾸는 쪽이었음 - 실제로 Cloudflare, Stripe, Claude Code, GitLab, GitHub는 남겨둠 - 이유도 꽤 현실적임. 기능 격차, 네트워크 효과, 결제 전환 리스크, AI 코딩 성능 같은 건 이념만으로 못 이김 > [!IMPORTANT] > 결론은 “유럽 서비스가 전부 더 좋다”가 아님. 생각보다 많은 핵심 인프라를 유럽 기반 또는 셀프호스팅으로 옮겨도 실사용에 큰 문제는 없었다는 게 포인트임. ## 분석, 메일, 비밀번호부터 갈아엎기 - Google Analytics는 가장 먼저 Matomo 셀프호스팅으로 교체함 - 이유는 뻔하지만 강력함. GA는 무료지만 방문자 행동 데이터가 구글 광고 생태계로 흘러가는 구조임 - Matomo를 직접 운영하면 데이터가 자기 서버에 남고, GDPR 대응도 더 깔끔해짐 - 대신 업데이트, 백업, 서버 상태 관리는 직접 챙겨야 함. 공짜 점심은 없음 - 메일은 Proton Mail로 옮겼는데, 여기는 EU는 아니고 스위스 기반임 - 스위스 개인정보보호법이 GDPR과 잘 맞고, 어떤 면에서는 더 강하다는 판단 - Proton은 광고가 아니라 프라이버시를 비즈니스 모델로 삼고, 종단간 암호화도 핵심 구조에 들어가 있음 - Gmail에서 오던 사람은 필터 기능이 답답할 수 있음. Proton은 메일 본문 내용 기준 필터링을 지원하지 않음 - Duo 플랜에서도 커스텀 도메인이 3개로 제한돼서, 여러 프로젝트 도메인을 굴리는 사람은 금방 막힘 - 비밀번호 관리는 1Password에서 Proton Pass로 이동함 - Proton Pass는 종단간 암호화, 오픈소스, 스위스 관할권이라는 점이 장점 - 다만 1Password보다 압도적으로 낫다기보다는, 메일과 캘린더까지 Proton 생태계로 묶는 일관성이 더 컸음 ## 클라우드와 스토리지는 생각보다 덜 아팠다 - Compute는 DigitalOcean에서 Scaleway로 옮겼고, 기대보다 만족도가 높았다고 함 - DigitalOcean은 개발자 경험이 워낙 좋고, UI와 개념 모델이 단순해서 사랑받는 서비스임 - Scaleway는 유럽 대안치고 “쓸 만하겠지” 정도로 기대했는데, 실제로는 서버 생성, 프라이빗 네트워크 구성, 콘솔 품질이 꽤 좋았다고 평가함 - 서버 위치를 고를 때 예상 CO₂ 배출량을 보여주는 것도 인상적인 디테일로 언급됨 - 오브젝트 스토리지는 Scaleway의 S3 호환 스토리지로 옮김 - S3 호환이라 기존 코드에서 엔드포인트와 인증 정보만 바꾸면 되는 수준 - 기존 AWS S3 버킷은 rclone으로 Scaleway S3 버킷에 동기화했는데, 버킷이 커서 일주일 넘게 계속 돌렸다고 함 - 오프사이트 백업은 OVH 오브젝트 스토리지를 선택함 - OVH는 유럽 최대 클라우드 사업자라 가격과 안정성 면에서 기대할 만한 규모가 있음 - 오래된 백업을 콜드 스토리지 클래스로 넘기는 라이프사이클 규칙을 설정하면 Backblaze B2보다 싸졌다고 함 - 문제는 콘솔 UX. OVHcloud 제어판은 미로 같고, 라이프사이클 설정은 문서와 터미널 작업을 뒤져야 했다고 함. 아, 여기서 현실감 확 올라옴 ## 이메일, 에러 추적, AI API도 대안이 있었다 - 트랜잭션 이메일은 SendGrid 대신 Lettermint로 바꿈 - 비밀번호 재설정, 알림, 영수증 같은 일반적인 발송에는 충분한 API와 전달성을 제공함 - SendGrid에 비해 분석 기능과 생태계 통합은 약함 - 복잡한 멀티 스트림 이메일 인프라를 운영 중이면 기능 검토가 먼저 필요함 - 에러 추적은 Sentry 대신 Bugsink 셀프호스팅으로 이동함 - Sentry SDK를 그대로 받을 수 있어서 설정 한 줄 바꾸는 수준으로 이전 가능 - 대신 성능 모니터링, 세션 리플레이, 고급 알림 같은 건 없음 - 글쓴이에게 필요한 건 “프로덕션에서 터지면 스택 트레이스 보여줘”였고, 그 목적에는 충분했음 - AI API는 OpenAI에서 Mistral로 바꿈 - 주로 단순한 모델을 쓰던 워크로드라 품질 저하는 거의 없었다고 함 - Mistral은 파리 본사이고, 오픈 웨이트 모델과 API를 함께 제공한다는 점에서 글쓴이의 방향성과 잘 맞았음 - 돈이 어디로 가는지도 선택 기준에 들어갔다는 대목이 꽤 솔직함 ## 그래도 못 옮긴 것들 - Cloudflare는 그대로 남김 - 미국 회사지만, 글쓴이는 공개 웹사이트 앞단에서 캐싱, DDoS 방어, 전 세계 로딩 속도 개선 용도로만 쓴다고 봄 - 민감한 비공개 데이터가 아니라 어차피 공개될 페이지를 다루기 때문에 주권 계산법이 다르다는 판단 - Bunny CDN도 테스트했지만, Cloudflare의 보안 규칙, Workers, 설정 폭을 대체하기엔 부족했다고 함 - Stripe도 아직 못 옮김 - 대안으로 네덜란드 결제 사업자 Mollie를 보고 있고, iDEAL, Bancontact, SEPA 같은 유럽 결제 수단 커버리지는 오히려 장점임 - 하지만 결제 이전은 웹훅, 과금 로직, 세금 계산서, 고객 플로우를 전부 건드림 - 게다가 글쓴이 사용 사례에서는 Stripe보다 더 비싸다고 함. 이러면 우선순위가 밀릴 수밖에 없음 - AI 코딩 도우미는 OpenAI 대신 Claude Code를 쓰지만, 이것도 미국 회사라 관할권 기준에는 안 맞음 - Mistral Vibe를 원했지만 Claude 수준까지는 못 왔다고 판단함 - Claude Code는 추론 품질과 컨텍스트 처리 능력이 좋아서 실무 도구로 선택됨 - 대신 로컬 모델 가능성도 언급함. Qwen 같은 오픈 웨이트 모델이 실제 워크로드에 점점 쓸 만해지고, 데이터를 로컬 밖으로 안 내보낼 수 있다는 점이 중요함 - GitLab과 GitHub도 남김 - GitLab은 미국 회사지만 셀프호스팅 옵션과 오픈소스 투명성 때문에 당장 유지 - GitHub는 공개 NPM 패키지와 오픈소스 이슈 트래킹 때문에 계속 사용 - 공개 프로젝트는 개발자들이 GitHub에서 찾고, 포크와 스타와 이슈가 거기서 생김. 네트워크 효과는 진짜임 ## 실제로 해보니 어땠나 - 마이그레이션의 마찰은 있었지만, 대체로 감당 가능한 수준이었다고 함 - 많은 작업은 자격 증명 바꾸기, DNS 레코드 수정, 데이터 export/import 정도였음 - 일부는 오래 걸렸지만 치명적인 장애는 없었고, 두 달이 지난 뒤에도 문제 없이 운영 중이라고 함 - 가장 오래 걸린 건 손으로 옮기는 작업보다 조사와 계획이었다는 게 현실적인 포인트임 - 어떤 서비스를 어디로 바꿀지, 전환 타이밍을 언제로 잡을지, 기능 격차를 어디까지 허용할지 정하는 데 시간이 들어감 - 결국 발목을 잡은 건 기술적 불가능이 아니라 관성에 가까웠다고 정리함 --- ## 기술 맥락 - 이 글의 핵심 선택은 SaaS 편의성을 조금 내려놓고 데이터 위치와 관할권을 더 명확히 가져가는 거예요. 왜냐하면 분석, 메일, 백업, 에러 로그 같은 데이터는 평소엔 별거 아닌 것처럼 보여도 장애나 정책 변경이 터지면 서비스 운영권과 바로 연결되거든요. - S3 호환 스토리지를 고른 것도 중요한 포인트예요. 완전히 새 API로 옮기면 애플리케이션 코드와 운영 스크립트를 다 건드려야 하는데, S3 호환이면 엔드포인트와 키 교체만으로 이전 난이도가 확 낮아져요. 그래서 대용량 버킷 동기화가 일주일 넘게 걸려도 코드 변경 리스크는 작게 유지할 수 있었어요. - 셀프호스팅은 자유를 주지만 운영 책임도 같이 줘요. Matomo와 Bugsink는 데이터가 밖으로 안 나간다는 장점이 있지만, 업데이트와 백업과 서버 상태를 직접 봐야 해요. 작은 팀이라면 ‘데이터 통제권’과 ‘운영 시간’ 사이에서 계산을 꼭 해봐야 해요. - 흥미로운 건 글쓴이가 원칙을 세우되 예외를 인정했다는 점이에요. Cloudflare는 공개 웹사이트 앞단이라 남겼고, Stripe는 결제 전환 리스크가 커서 미뤘고, Claude Code는 생산성 때문에 선택했어요. 인프라 의사결정은 순수한 철학 문제가 아니라 제품 리스크, 팀 생산성, 비용이 같이 얽혀 있거든요. ## 핵심 포인트 - 구글 애널리틱스는 셀프호스팅 Matomo로, DigitalOcean과 AWS S3는 Scaleway와 OVH 쪽으로 이전함 - Proton, Scaleway, OVH, Lettermint, Bugsink, Mistral 같은 대안은 대부분 실사용 가능한 수준이었지만 기능 격차와 운영 부담은 남아 있음 - Cloudflare, Stripe, Claude Code, GitLab, GitHub처럼 실용성 때문에 당장 못 옮긴 예외도 명확히 인정함 - 전체 이전은 두 달 정도 걸렸고, 대부분은 실제 작업보다 조사와 전환 타이밍 결정에 시간이 많이 들어감 ## 인사이트 이 글이 재밌는 건 ‘유럽 클라우드가 도덕적으로 낫다’가 아니라, 실제 제품별로 어디까지 옮길 수 있고 어디서 현실과 타협했는지 다 까놓는다는 점이다. 한국 팀도 미국 빅테크 의존도를 줄이고 싶다면 감정론보다 이런 체크리스트가 훨씬 쓸모 있음.