Cloudflare
buydic.com의 DNS와 공개 Proxy/TLS 앞단입니다. 현재 테스트에서 Cloudflare Tunnel인 cloudflared는 쓰지 않습니다.
LIVE ARCHITECTURE · MOBILE DEEP DIVE
buydic.com은
어떻게 열리고 있을까?
지금 휴대폰에서 https://buydic.com을 열었을 때 요청이 어디를 지나가는지, 그리고 집 인터넷의 공인 IP가 바뀌더라도 같은 도메인으로 서비스를 유지하는 구조를 ELI5부터 실제 구성까지 이어서 설명합니다.
공개 URL 200 OK 확인
자체 Tunnel connected
실제 요청 카운터 증가 확인
실제 홈 IP 변경 수용시험은 별도
1. 지금 실제 요청이 지나가는 길
브라우저 주소창에는 하나의 도메인만 보이지만, 뒤에서는 아래 순서대로 여러 역할이 이어집니다.
📱 휴대폰 / PChttps://buydic.com 요청
☁️ CloudflareDNS · Proxy · 바깥쪽 HTTPS/TLS
🌐 Oracle 앞단 + Caddybuydic.com Host를 보고 로컬 Gateway로 전달
🚪 Mini Cloud Gateway127.0.0.1:18090 · hostname을 Tunnel과 매칭
🔗 자체 Outbound TunnelGateway ↔ Agent 사이의 지속 연결
🤖 Mini Cloud AgentTunnel 요청을 내부 HTTP Service로 전달
🏠 buydic-home Web테스트 홈페이지 HTML 응답
실제 검증: 공개 URL에서
200 OK, X-Mini-Cloud-Test: buydic 응답을 확인했고, 공개 요청 뒤 자체 Tunnel의 requestCount도 증가했습니다.
2. 각 부품은 무슨 일을 하나?
Cloudflare가 모든 일을 하는 것이 아닙니다. 현재 핵심 Tunnel 데이터 경로는 우리가 만든 Mini Cloud가 담당합니다.
Caddy
공개 서버에서 buydic.com 요청을 받아 Mini Cloud Gateway의 로컬 포트로 넘깁니다.
Gateway
HTTP의 Hostname을 보고 어떤 DomainRoute와 Tunnel로 보내야 하는지 결정합니다.
Tunnel
Agent가 Gateway 쪽으로 먼저 만든 지속 연결입니다. 집 공유기에 외부 포트를 열지 않아도 되는 핵심입니다.
Agent
내부 네트워크에서 Tunnel을 유지하고, 들어온 요청을 실제 서비스 주소로 전달합니다.
Service
실제 웹앱입니다. 현재 buydic 테스트에서는 web:8080이 대상입니다.
3. 동적 IP 문제를 어떻게 피하나?
여기가 이 프로젝트의 핵심입니다. 일반 DDNS 방식과 우리가 만든 Outbound Tunnel 방식을 나란히 보면 이해가 쉽습니다.
전통적인 방식
DDNS가 홈 IP를 따라간다
- 집 공인 IP가
1.2.3.4 → 5.6.7.8로 바뀐다. - Agent가 새 IP를 감지한다.
- DNS의 A/AAAA Record를 새 IP로 업데이트한다.
- 공유기 포트포워딩 또는 직접 진입 경로가 필요할 수 있다.
- DNS 캐시와 전파 시간이 영향을 줄 수 있다.
현재 제품의 중심 구조
Domain은 Gateway를 보고 Agent가 나간다
buydic.com은 안정적인 Public Gateway 쪽을 본다.- Home Agent가 내부에서 Gateway로 Outbound 연결을 먼저 만든다.
- 집 공인 IP가 바뀌면 기존 TCP 연결이 끊길 수 있다.
- Agent가 새 네트워크에서 같은 Tunnel ID로 Gateway에 다시 연결한다.
- Domain을 홈 IP로 다시 바꿀 필요가 없다.
ELI5: 집 주소가 계속 바뀌는 사람에게 택배기사가 직접 찾아가는 방식이 DDNS라면, Outbound Tunnel은 그 사람이 항상 같은 물류센터에 먼저 전화선을 연결해 두는 방식입니다. 손님은 언제나 물류센터만 찾으면 됩니다.
4. 집 공인 IP가 실제로 바뀌면
실제 Home Agent를 집 서버에 설치했을 때 기대하는 재연결 흐름입니다.
기존 Tunnel이 연결되어 있다Home Agent → Public Gateway 방향으로 세션이 살아 있습니다.
통신사에서 공인 IP를 바꾼다예: 공유기 재연결, DHCP 임대 변경, 회선 재접속.
기존 네트워크 연결이 끊긴다Agent는 Tunnel 연결 실패를 감지합니다.
Agent가 자동 재연결한다코드의 Tunnel Client는 실패 시 backoff를 두고 Gateway에 다시 연결합니다.
Gateway가 같은 Tunnel Resource로 다시 받는다DomainRoute와 Service 연결 관계는 그대로 유지됩니다.
buydic.com은 그대로다사용자는 새 홈 IP를 알 필요 없이 같은 도메인으로 접근합니다.
5. 지금 buydic 테스트에서 어디까지 실제인가?
현재 검증된 것과 아직 실환경에서 일부러 장애를 만들어 확인하지 않은 것을 구분합니다.
✓
공개 Domain 접속
https://buydic.com/에서 외부 200 응답 확인.
✓
Cloudflare → Caddy → Gateway 전달
공개 요청이 Mini Cloud Gateway까지 실제로 도착함을 응답 헤더로 확인.
✓
Gateway → 자체 Tunnel → Agent → Web
Tunnel 상태 connected와 요청 카운터 증가로 실제 데이터 경로 확인.
✓
소스와 운영 Caddy 설정 동기화
저장소 Caddyfile과 운영 파일의 SHA-256 일치 및 Caddy validate/reload 성공.
…
실제 가정용 동적 IP 변경 수용시험
현재 live acceptance는 같은 서버의 Docker 환경으로 데이터 경로를 검증했습니다. 집 회선의 공인 IP를 실제로 바꾸고 자동 복구되는 시험은 아직 별도 수용 항목입니다.
6. 지금 테스트와 최종 홈서버 배치의 차이
현재 buydic 테스트
Oracle 앞단 서버에 Caddy와 Mini Cloud 테스트 스택을 함께 띄워 도메인 → Gateway → Tunnel → Agent → Web 데이터 경로를 실제 인터넷에서 검증했습니다.
집 서버에 Agent를 둘 때
Gateway는 고정된 공개 서버에 남고 Agent와 Service만 집으로 이동합니다. 집 공유기에서 인바운드 포트를 열지 않고 Agent가 바깥쪽으로 연결합니다.
buydic.com사용자가 기억하는 주소는 그대로
Public Gateway고정된 공개 진입점
Outbound Tunnel집에서 인터넷 방향으로 연결
Home Agent공인 IP가 바뀌어도 다시 접속
Home ServiceNAS · Web · API · 개발 서버 등
7. 그렇다면 DDNS는 필요 없나?
완전히 필요 없는 기능은 아닙니다. 다만 역할이 달라집니다.
DDNS가 유용한 경우
집 장비에 직접 SSH/VPN/특정 포트로 접속하고 싶거나, Public Gateway를 거치지 않는 Direct 경로를 만들 때 유용합니다.
Tunnel 공개에는 필수 아님
웹 서비스를 Public Gateway의 Tunnel로 공개한다면 외부 사용자는 Home Public IP가 아니라 Gateway를 보기 때문에 홈 DDNS를 필수 의존성으로 둘 필요가 없습니다.
프로젝트 PRD도 “DDNS는 첫 학습 기능이지만 최종 서비스 공개 구조의 필수 의존성은 아니다”라는 원칙을 두고 있습니다. DDNS와 Tunnel은 서로 대체재라기보다 Direct 경로와 Relay/Tunnel 경로를 각각 담당할 수 있습니다.
8. HTTPS는 지금 누가 처리하나?
현재 buydic 실험에서는 역할을 단순하게 나눴습니다.
휴대폰 ↔ Cloudflare사용자는
https://buydic.com으로 접속하며 공개 TLS는 Cloudflare 앞단이 처리합니다.Cloudflare ↔ Oracle/Caddy현재 테스트 설정에서는 origin 쪽으로 HTTP 연결을 사용합니다.
Caddy ↔ Mini Cloud Gateway로컬
127.0.0.1:18090으로 reverse proxy 합니다.Gateway 이후자체 Tunnel이 Agent까지 요청을 전달하고 Agent가 내부 Web Service에 전달합니다.
9. 이 구조를 만들면서 배우는 것
DNS와 Domain
도메인이 실제 서버를 어떻게 찾아가는지, DNS Record와 Host routing의 차이를 체감합니다.
Reverse Proxy
Caddy 같은 공개 앞단이 하나의 IP에서 여러 도메인을 어떻게 서비스하는지 배웁니다.
Outbound Tunnel
NAT와 동적 IP 뒤의 서버를 인바운드 포트 오픈 없이 공개하는 원리를 직접 구현합니다.
Control Plane
Node, Service, Tunnel, Domain을 각각 Resource로 관리하고 상태를 연결해서 보는 구조를 익힙니다.
자동 복구
연결이 끊겼을 때 Agent가 재시도하고 같은 논리적 Tunnel로 복귀하는 상태 머신을 다룹니다.
Cloudflare/Tailscale의 핵심 개념
제품을 그대로 복제하기보다 DNS, Tunnel, Identity, Private Network의 핵심 메커니즘을 작은 시스템으로 이해합니다.
10. 초간단 용어집
공인 IP
인터넷에서 집 공유기를 식별하는 주소. 일반 가정 회선에서는 바뀔 수 있습니다.
DDNS
공인 IP가 바뀌면 DNS Record도 자동으로 새 IP에 맞춰 바꾸는 방식.
Gateway
외부 요청을 받아 적절한 Tunnel로 전달하는 공개 입구.
Agent
집/노트북/서버 쪽에서 Control Plane과 Gateway에 연결되는 프로그램.
Outbound Tunnel
내부 서버가 외부 Gateway로 먼저 연결해서 만든 통로. NAT 뒤에서도 만들 수 있습니다.
Reverse Proxy
앞에서 요청을 받고 뒤의 다른 서버로 대신 전달하는 역할.
DomainRoute
buydic.com → 어떤 Tunnel로 보낼지를 나타내는 Mini Cloud의 연결 정보.
TLS
HTTPS 통신을 암호화하고 서버 신원을 확인하는 기술.
Mini Cloud · buydic.com live tunnel deep dive · 2026-10-02