넷시티 메인 화면의 상단 메뉴와 하단 서비스 링크는 겉으로 보면 여러 사이트가 나란히 붙은 포털처럼 보인다. 그러나 실제 인터넷 접속 조건은 훨씬 빡빡하다. 외부에서 열려 있는 웹 관문은 사실상 HTTPS 443 하나다. HTTP 80을 열어 리다이렉트로 넘기는 흔한 방식도 아니고, 각 서버의 내부 웹 포트나 카메라 포트, 개발 포트가 직접 외부에 노출되는 구조도 아니다. 사용자가 만나는 것은 모두 https:// 주소이고, 내부 서비스는 그 뒤에서 Nginx와 SNI, 리버스 프록시로 분기된다.
이번 구축기는 www.netcity.co.kr/index.php를 기준으로 정리했다. 상단 메뉴에는 매거진, 스페이스, AI/IT 뉴스, 블로그진, IS, 스트리트, 포럼이 붙어 있고, 하단에는 올드팝, 넷무비, 우분투, 링크 디렉토리, Meet, 웹하드, 스마트팜 같은 별도 서비스가 이어진다. 여기에 모바일 서버 허브와 서버 191 릴레이 같은 물리 장비 기반 노드까지 붙는다. 어려운 점은 이 모든 것을 “포트 여러 개를 열어서 해결”하지 않고 443 하나로 끝내야 한다는 데 있었다.
문제는 포트가 아니라 관문이었다
일반적인 개인 서버 구축에서는 서비스마다 포트를 하나씩 열고 싶어진다. 웹은 80, HTTPS는 443, 개발 미리보기는 3000, Node 앱은 5173, 카메라는 8080 또는 8088, 파일 서비스는 또 다른 포트로 열어두는 식이다. 로컬 네트워크에서는 빠르고 편하지만, 인터넷에 그대로 내놓으면 관리가 어려워지고 공격면도 넓어진다. 특히 여러 장비가 섞인 환경에서는 어느 장비의 어느 포트가 외부에 열려 있는지 추적하는 것부터 일이 된다.
넷시티의 목표는 반대였다. 외부 접속자는 오직 443으로만 들어온다. 그 뒤에서 Host 헤더와 SNI 이름을 보고 magazine.netcity.co.kr, space.netcity.co.kr, news.netcity.co.kr, mobile.netcity.co.kr, link.netcity.co.kr 같은 목적지로 나눈다. 내부에서는 서버 191, 서버 197, 모바일 장비, 릴레이 페이지, 게시판 루트가 각자 다른 경로와 포트를 쓸 수 있지만, 외부 사용자는 그 차이를 알 필요가 없다.
확인 결과 상단 메뉴와 주요 하단 사이트들은 동일한 공인 IP 114.108.*.*를 바라보고 있었다. 대표 호스트들을 대상으로 80과 443을 점검했을 때 80은 filtered, 443은 open으로 정리됐다. 즉 공개 웹 경로는 HTTPS 443에 집중되어 있고, 평문 HTTP를 전제로 한 접근은 막혀 있다.
상단 메뉴는 사이트 목록이 아니라 라우팅 지도다
메인 페이지의 상단 메뉴는 단순 링크 모음이 아니다. 실제로는 공개 관문에서 목적지를 나누기 위한 라우팅 지도에 가깝다. magazine.netcity.co.kr은 매거진형 콘텐츠로, space.netcity.co.kr는 스페이스 섹션으로, news.netcity.co.kr는 AI/IT 뉴스 게시판으로, forum.netcity.co.kr는 포럼으로 연결된다. 모두 같은 443 관문을 통과하지만, 브라우저의 도메인 이름이 다르기 때문에 Nginx는 각각 다른 서버 블록이나 프록시 대상으로 분기할 수 있다.
여기서 핵심은 “메뉴를 먼저 만들고 서버를 나중에 붙인 것”이 아니라, 서버들이 이미 존재하는 상황에서 사용자가 헤매지 않도록 상단에 질서를 세운 것이다. 사이트가 하나 늘어날 때마다 포트를 하나 더 여는 대신, DNS와 Nginx 라우팅을 추가하고 메뉴에 도메인을 연결한다. 운영자는 내부 구조를 바꿀 수 있고, 사용자는 항상 HTTPS 주소만 기억하면 된다.
하단 사이트들은 느슨한 확장 계층이다
하단 서비스 메뉴는 상단보다 더 운영적인 성격을 가진다. 올드팝, 넷무비, 우분투, 링크 디렉토리, Meet, 웹하드, 스마트팜 같은 항목은 모두 사용 빈도와 역할이 다르다. 어떤 것은 독립 사이트이고, 어떤 것은 특정 기능의 입구이며, 어떤 것은 내부 장비와 연결된 관리 페이지에 가깝다. 하지만 외부 노출 원칙은 같다. 사용자는 https://서비스.netcity.co.kr/ 또는 https://www.netcity.co.kr/경로로 접근하고, 내부 포트 번호를 직접 입력하지 않는다.
이 구조의 장점은 하단 서비스가 늘어나도 방화벽 규칙을 복잡하게 늘릴 필요가 없다는 데 있다. 새 사이트를 붙일 때 필요한 것은 대체로 세 가지다. 첫째, DNS 이름을 같은 공인 IP로 향하게 한다. 둘째, Nginx에 해당 도메인의 서버 블록 또는 프록시 규칙을 만든다. 셋째, 메인 메뉴나 하단 링크에 그 주소를 등록한다. 이렇게 하면 내부 장비가 노트북이든, 스마트폰이든, 오래된 서버 191이든 외부 입구는 계속 443 하나로 남는다.
모바일 서버와 내부 포트는 뒤에 숨긴다
가장 까다로운 부분은 모바일 서버와 장비형 서버다. mobile.netcity.co.kr는 192.168.0.197 기반의 Ubuntu/스마트폰 서버 허브를 묶고, USB 안드로이드 장비와 GD-C100 웹캠, Termux, ADB, 포워딩 구조를 한 화면에서 안내한다. 이런 시스템은 내부적으로 여러 포트를 쓴다. 그러나 공개 인터넷에서는 그 포트를 직접 열지 않고, HTTPS 도메인과 경로로만 보여준다.
외부 사용자가 443으로 들어오면 Nginx는 요청 도메인과 경로를 보고 내부 장비로 넘긴다. 내부에서는 127.0.0.1이나 사설 IP의 특정 포트가 동작할 수 있다. 하지만 그것은 운영자가 볼 내부 배선이다. 외부에 직접 노출되는 것은 인증서가 붙은 HTTPS 엔드포인트 하나다. 이 차이를 지키는 것이 443-only 환경의 핵심이다.
서버 191 릴레이를 443 뒤에 붙인 과정
서버 191은 이 구조를 설명하기 좋은 사례다. 릴레이 페이지 안에는 내부 웹 상태, USB 웹캠, uStreamer, 네트워크 상태, 시스템 정보가 들어 있다. 화면에는 내부적으로 웹 80/tcp, 카메라 8088/tcp 같은 운영 항목이 보인다. 그러나 이것을 그대로 외부에 열면 443-only 원칙이 깨진다. 그래서 공개 주소는 https://www.netcity.co.kr/relay-server-2/로 두고, 그 뒤에서 내부 서버 191의 필요한 경로만 프록시한다.
이 방식은 오래된 장비를 살릴 때 특히 유용하다. 서버 191처럼 사양이 낮은 노드도 내부에서는 자기 역할만 하면 된다. TLS 종료, 외부 접속, 도메인 분기, 보안 헤더, 공개 URL 관리는 앞단 Nginx가 맡는다. 서버 191은 웹캠과 상태 페이지를 안정적으로 내보내고, 외부 사용자는 443으로만 접근한다. 결과적으로 작은 장비도 전체 도시형 웹 구조 안에 들어올 수 있다.
영상 송출도 서버가 책임지는 구조여야 한다
영상 송출 시스템도 같은 원칙으로 보아야 한다. 방송 프로그램이나 캡처 프로그램에서 화면을 만들 수는 있지만, 핵심은 서버에서 송출 흐름을 붙잡는 것이다. OBS, FFmpeg, yt-dlp, streamlink, PHP 관리 화면, 셸 스크립트 같은 도구는 각각 쓸모가 다르다. 그러나 운영 구조에서는 이 도구들을 서버가 자동으로 조합해야 한다.
오토메틱 설계가 중요한 이유는 송출이 사람의 손동작보다 오래 버텨야 하기 때문이다. 서버는 입력 소스가 늦게 켜지면 기다리고, 끊기면 재시도하고, 자막과 미리보기를 갱신하고, 공개 주소는 443 뒤에 유지해야 한다. 프로그램은 부품이고, 서버는 지휘자다. 넷시티의 영상 송출 구조는 결국 “여러 프로그램을 응용하되 서버가 최종 송출을 자동 관리하는 방식”으로 가야 안정적이다.
구축 순서
실제 구축은 다음 순서로 잡는 것이 가장 안정적이었다. 먼저 모든 공개 사이트 이름을 정리한다. 상단 메뉴 그룹은 www, magazine, space, news, blogzine, is, street, forum으로 나누고, 하단 서비스 그룹은 pops, movie, dev, link, meet, smartfarm 같은 기능형 노드로 둔다. 서버형 항목은 mobile과 relay-server-2처럼 별도 이름이나 경로를 부여한다.
그 다음 DNS를 하나의 공인 IP로 모은다. 이번 점검에서 주요 도메인은 모두 114.108.*.*로 확인됐다. 이어서 Nginx에서 도메인별 서버 블록을 만든다. 정적 PHP 루트로 보낼 사이트는 해당 문서 루트로 연결하고, 내부 장비나 별도 프로세스로 보내야 하는 서비스는 proxy_pass로 묶는다. 이때 내부 포트는 방화벽에서 외부로 열지 않는다. 외부에서는 443만 허용하고, 내부 포트는 로컬 또는 사설망에서만 접근하도록 둔다.
마지막으로 메뉴와 카운터를 연결한다. 넷시티의 상단 메뉴는 사용자가 자주 이동하는 핵심 사이트를 보여주고, 하단 메뉴는 기능형 사이트를 느슨하게 묶는다. 방문 수나 상태 배지는 각 사이트의 JSON, DB, HTML에서 읽어올 수 있지만, 메뉴의 링크 자체는 계속 HTTPS 공개 주소를 사용한다. 이렇게 하면 내부 구조가 바뀌어도 공개 링크의 안정성이 유지된다.
어려웠던 점
가장 어려운 지점은 리다이렉트가 아니라 “비노출”이었다. 80을 443으로 넘기는 방식은 편하지만, 이번 환경에서는 80 자체가 필터링되는 조건으로 보았다. 따라서 처음부터 모든 링크와 메뉴를 HTTPS로 작성해야 했다. 내부에서 테스트할 때는 http://127.0.0.1, http://192.168.0.xxx 같은 주소가 필요하지만, 기사나 공개 페이지, 메뉴에는 이런 주소가 직접 노출되지 않도록 정리해야 한다.
두 번째 어려움은 장비형 서버의 성격 차이다. 뉴스 사이트와 포럼은 일반 웹 루트로 다룰 수 있지만, 모바일 서버나 웹캠 릴레이는 내부 장비 상태에 따라 살아나거나 꺼진다. 그래서 프록시 타임아웃, 빈 화면 처리, 상태 안내, 캡처 이미지 갱신이 필요하다. 단순히 연결만 되는 것이 아니라, 꺼져 있을 때도 사용자가 무엇을 보고 있는지 알 수 있어야 한다.
세 번째는 운영 문서화다. 443-only 구조는 한 번 만들면 단순해 보이지만, 실제로는 DNS, Nginx, PHP 루트, 내부 포트, 장비 전원, SSL 인증서, 메뉴 링크가 모두 맞아야 한다. 하나라도 어긋나면 사용자는 “사이트가 안 열린다”고만 느낀다. 그래서 이번 기사처럼 상단 메뉴, 하단 서비스, 서버형 노드, 포트 점검 결과를 한 문서에 남겨두는 것이 중요하다.
정리
넷시티의 443-only 구축은 포트를 아끼는 설정이 아니라 운영 철학에 가깝다. 외부 사용자는 오직 HTTPS 443으로 들어오고, 내부의 복잡한 장비와 서비스 포트는 Nginx/SNI/리버스 프록시 뒤에 숨긴다. 상단 메뉴는 핵심 사이트의 도시 지도이고, 하단 메뉴는 기능형 서비스의 확장 계층이며, 서버 191과 모바일 서버는 그 뒤에서 실제 장비를 담당한다.
이 구조는 만들기 어렵지만, 완성되면 관리가 단순해진다. 공개 포트가 줄어들고, 링크가 안정되고, 오래된 장비와 스마트폰 서버까지 하나의 HTTPS 도시 안으로 들어온다. 넷시티의 상단 메뉴와 하단 사이트들은 그래서 단순한 링크 묶음이 아니다. 443 하나만 열린 인터넷 환경에서 여러 서버를 한 도시처럼 보이게 만든 구축 결과물이다.