마인크래프트 서버 구축 변천사 : OCI 기반 24시간 서버 구축기
1. 서론: 사용자 경험(UX)과 인프라 설계
단순히 서버를 여는 것과 서비스를 구축하는 것의 차이는 사용자 편의성에 있다고 생각합니다. 인터넷을 찾아보면 vpn(wireguard, tailscale), VLAN(하마치) 등 멀리 떨어진 플레이어에게 서버를 열 수 있는 방법은 많습니다. 다만 클라이언트들의 설치가 필요하거나 더 깊은 설정이 필요하고 친구가 복잡한 IPv4:Port 주소조차 필요없이 외우기 쉬운 도메인 하나로 언제 어디서든 접속할 수 있는 환경을 만드는 것이 목표였습니다.
제가 보유한 최상의 자원인 Ryzen 5 9600X(DDR5 32GB, RTX 5060) 사양의 메인 PC를 서버 노드로 활용하고자 했습니다. 압도적인 성능을 제공하지만, 운영 환경을 고려하여 몇 가지 문제를 생각해볼 수 있었습니다.
1. 보안 위협 (Security Risk)
마인크래프트의 기본 포트인 TCP 25565를 개방하기 위해 공유기에서 포트포워딩(Port Forwarding)을 수행하는 순간, 우리 집의 공인 IP가 인터넷에 노출됩니다. 이는 Shodan과 같은 악성 스캐너의 직접적인 타겟이 되어 보안 취약점 공격에 무방비로 노출될 위험이 큽니다.
2. 가용성 저하 (Availability Issues)
악성 봇이나 DDoS 공격이 발생할 경우, 트래픽 과부하로 인해 집안 전체의 인터넷 네트워크를 관리하는 공유기가 다운될 수 있습니다. 이는 개인의 프로젝트 실패를 넘어 가족 공동의 인터넷 인프라가 마비되는 결과를 초래합니다.
왜 Nginx Proxy Manager(NPM)를 쓰지 못하나?
이미 웹 서비스 배포용으로 사용 중인 NPM을 활용하려 했으나 명확한 한계가 있었습니다. Nginx는 기본적으로 L7(Application Layer) 정보를 기반으로 작동하는 역프록시(Reverse Proxy)입니다. 하지만 마인크래프트 패킷은 TCP(L4) 통신이므로, HTTP 헤더 정보가 없는 순수 TCP 패킷을 NPM만으로 처리하기에는 제약이 컸습니다.
"사용자 경험(UX) vs 기술적 편의성"
Cloudflare Tunnel 도입도 고려했지만, 외부 접속자(친구들)가 별도의 클라이언트 프로그램을 설치해야 한다는 점이 큰 장벽이었습니다. 저는 **"주소창에 도메인 하나만 치고 들어온다"**는 UX를 포기할 수 없었습니다.
최종 선택: Fast Reverse Proxy (FRP)
이러한 제약 사항을 모두 해결하기 위해 Go 언어 기반의 **Fast Reverse Proxy (FRP)**를 도입했습니다.
- Public IP 은닉: OCI VPS를 Entry Point로 사용하여 실제 서버의 IP 주소를 숨깁니다.
- L4 Tunneling: TCP 패킷을 암호화된 터널로 안전하게 중계합니다.
- No Client-side Install: 접속자는 별도의 프로그램 없이 도메인 주소만으로 접속이 가능합니다.
2. OCI와 Edge Node의 결합
이 문제들을 해결하면서 클라이언트에 서비스를 안정적으로 제공하기 위해 OCI(Oracle Cloud) Always Free 자원과 집의 N4000 노드를 결합한 하이브리드 구조를 설계했습니다.

| 계층 | 구성 요소 | 역할 및 선정 이유 |
| Public Entry | OCI VPS (AMD) | FRP Server 운영. 외부 패킷의 첫 수신지이자 집 IP 은닉용 가리개 역할. |
| Control Hub | Intel N4000 | 패킷 분배 및 내부망 전체 접근을 위한 허브. |
| Compute Engine | Ryzen 9600X | 고성능 연산이 필요한 메인 서비스 구동. |
1. Request: 외부 클라이언트가 도메인을 통해 접속을 시도합니다.
- Public Entry: 패킷은 먼저 **OCI VPS(FRPS)**에 도착합니다. 이때 집의 실제 공인 IP는 철저히 은닉됩니다.
- Secure Tunneling: VPS의 FRP 서버는 암호화된 Fast Reverse Proxy Tunnel을 통해 집 내부의 **N4000(Control Node)**으로 패킷을 토스합니다.
- Local Routing: N4000의 FRP Client가 패킷을 수신하고, 내부망(LAN)을 통해 실제 게임 서버가 구동 중인 **PC(Ryzen 9600X)**로 트래픽을 라우팅합니다.
- Response: 게임 데이터는 역순으로 터널을 타고 클라이언트에게 안전하게 전달됩니다.
한계점
초기에는 메인 작업용 PC(9600X)를 연산 노드로 활용하고 OCI를 게이트웨이로만 사용하는 하이브리드 방식을 채택했으나, 실제 운영 시 다음과 같은 고질적인 문제들에 직면했습니다.
1. 서비스 가용성의 제약: 24/7 운영 불가
- 문제: 메인 PC는 개인 작업 및 휴식을 위해 수시로 재부팅되거나 종료됩니다.
- 영향: 서버를 24시간 안정적으로 호스팅할 수 없었으며, 사용자가 접속하고 싶을 때 서버가 닫혀 있는 상황이 빈번하게 발생하여 서비스 신뢰도가 하락했습니다.
2. 로컬 리소스 잠식: "JVM 메모리 점유 문제"
- 문제: 마인크래프트 서버(Java) 특성상 안정적인 구동을 위해 **8GB 이상의 RAM(Xmx8G)**을 사전에 할당(Reservation)해야 했습니다.
- 영향: 32GB의 램 중 25% 이상이 상시 점유되어, 메인 PC에서 고사양 게임이나 무거운 작업을 병행할 때 시스템 병목 현상이 발생했습니다.
3. OCI Cloud Native로의 전환 (최적화 및 자동화)
로컬 서버 운영의 한계를 극복하기 위해 모든 컴퓨팅 자원을 **OCI(Oracle Cloud Infrastructure)**로 이전하며, 하이브리드 클라우드 구조를 클라우드 네이티브 환경으로 고도화했습니다.

1. 시스템 아키텍처 변화 (Before & After)
- 이전 (Hybrid):
OCI VPS→FRP Tunnel→Home Network→9600X- 물리적 거리에 따른 Network Latency 발생 및 집 인터넷 환경에 따른 가용성 의존도 높음.
- 현재 (Full Cloud):
OCI VPS (AMD)↔OCI ARM Node (24GB RAM)- 오라클 내부 **고속 백본망(VCN)**을 활용하여 데이터 경로를 단축하고 응답 속도를 극대화함.
2. 기술적 핵심 인사이트
- 리소스 극대화: Always Free 티어의 ARM Ampere A1 노드를 활용, 4 OCPU와 24GB RAM을 할당하여 메모리 집약적인 Java 애플리케이션(Minecraft)을 비용 0원에 안정적으로 구동.
- 보안 통일성: VCN 내에서도 **FRP(L4 Tunneling)**를 유지하여, 추후 홈 서버(9600X)로의 확장성을 열어둠과 동시에 보안 관문을 단일화함.
- 운영 자동화 (L7): 서비스 로그를 실시간 파싱하여 Discord Webhook API와 연동. 인프라 상태를 모바일로 즉시 확인 가능한 모니터링 체계 구축.
3. Why OCI ARM Node?
- 가용성 확보: 99.9% 가동률을 보장하는 OCI 클라우드 인프라로 24시간 무중단 서비스 실현.
- 로컬 자원 해방: 메인 PC의 RAM 8GB를 다시 온전한 작업 용도로 회복.
- 비용 제로 최적화: Always Free 티어의 24GB RAM을 활용하여, 내 컴퓨터보다 더 넉넉한 자원을 비용 지출 없이 서버에 할당.
4. 왜 VCN이 아닌 FRP인가?
OCI 내부 인스턴스 간(AMD ↔ ARM) 통신은 일반적인 VCN(Virtual Cloud Network) 설정만으로도 가능합니다. 하지만 저는 모든 구간에 **FRP(Fast Reverse Proxy)**를 적용했습니다.
- 보안 정책의 통일성: 집(Home-Lab) 서버는 보안상 공인 IP 은닉을 위해 반드시 FRP 터널이 필요합니다. 클라우드 노드 간 통신에도 동일한 아키텍처를 적용하여 관리 포인트의 통일성을 확보했습니다.
- 공격 표면 최소화: 모든 외부 트래픽은 VPS(AMD)라는 단일 관문을 통해서만 들어옵니다. 이를 통해 실제 연산 노드(ARM)의 직접 노출을 차단했습니다.
- Zero-day 대응력: 마인크래프트 서버 자체에 Zero-day 취약점이 발생하더라도, Docker 기반의 FRP 격리와 VPS 단계의 Fail2Ban을 통해 내부망 침투 시도를 입구에서 차단할 수 있는 계층적 방어 체계를 구축했습니다.
4. Troubleshoot: Split DNS Issue와 L3 계층의 이해
인프라 구축 중 발생했던 문제로 내부망 접속 불가 현상이 있었습니다.
- 증상: 외부에서는 도메인으로 잘 접속되는데, 집 내부망에서는 접속이 실패함.
- 원인 분석: 집 내부 DNS 서버인 AdGuard Home의 DNS Rewrite 중 와일드카드 설정 때문이었습니다. 내부 사용자가 도메인을 질의할 때, 패킷이 OCI 공인 IP로 나가지 못하고 내부 사설 IP(그것도 완전히 다른 노드)로 유도되는 경로 오류가 발생했습니다.
- 해결: AdGuard Home에서 특정 도메인에 대한 DNS Rewrite 예외 설정을 적용하여 해결했습니다. 이 과정을 통해 L3 계층에서 네임 서버가 패킷 경로에 미치는 영향을 다시 생각해보았습니다.