[Linux] 내부망 · 외부망 · 망연계 환경 설치 - 자동화 스크립트 제작기

 

서론

최근 내가 담당한 프로젝트를 운영 서버에 설치하는 작업을 진행하게 되었다.

겉보기에는 단순히 WEB/WAS/DB 설치 후 DB dump를 올리면 끝나는 단순한 작업처럼 보였다.

하지만 실제 현장에서는 인바운드/아웃바운드 통신 문제 때문에 예상보다 훨씬 많은 시간을 소모해야 했다.

이 글에서는 내가 겪은 실제 상황을 바탕으로, 내부망·외부망·망연계라는 개념을 정리하고,

앞으로 같은 문제를 줄이기 위해 준비한 방법을 적어두려고 한다.

---

사건 재구성

• 출장 당시, 외부망에 위치한 WAS 서버에서 내부망에 위치한 DB 서버로 접속해야 했다.
• 당연히 미리 네트워크 정책이 세팅되어 있을 거라 생각하고, 설치와 테스트를 진행했다.
• 그러나 실제로는 DB 통신이 되지 않았고, 뒤늦게 인바운드/아웃바운드·망연계 장비 정책을 다시 확인하고 수정해야 했다.
• 문제를 해결하는 데 상당한 시간이 걸렸고, “이 부분은 반드시 자동화와 사전 점검이 필요하다”는 것을 뼈저리게 느꼈다.

---

내부망 · 외부망 · 망연계란?

🔹 외부망

• 시민이나 일반 사용자가 접속할 수 있는 인터넷 연결망
• 웹 서비스(Web, WAS)가 주로 배치
• 예: 포털, 민원 처리 시스템

🔹 내부망

• 행정/업무 전용 망
• 대외 접근은 차단, 내부 직원이나 시스템만 접근 가능
• DB 서버는 보안상 내부망에 두는 것이 원칙

🔹 망연계

• 내부망과 외부망 사이의 중계 장비/서버
• 서로 다른 망 간의 통신을 직접 열지 않고, 반드시 망연계 서버를 통해 요청을 전달
• 동작 방식:
  1. 외부망 서버의 IP/PORT를 망연계에 등록
  2. 망연계 서버가 내부망의 DB로 요청을 전달 (Port Forwarding, Proxy 방식)
  3. 응답 또한 망연계를 거쳐 외부망으로 반환

즉, 망연계는 두 망 사이의 문지기 역할을 한다.

---

문제 원인

1. 사전 확인 부재: 네트워크 담당자에게 요청은 했지만, 실제 적용 여부를 직접 점검하지 않고 현장에 들어갔다.
2. 통신 정책 미반영: 외부망 → 망연계 → 내부망 간에 필요한 IP/Port가 모두 등록되지 않았다.
3. 수동 점검의 한계: 현장에서 직접 nc, ping, mysql 명령어를 쳐가며 확인하다 보니 시간 낭비가 심했다.

첫 운영 서버 배포이자 당일치기 출장에서 1박 2일간 고생을 좀 했었다..(심지어 장거리이기도 했고)

---

자동화 스크립트 (간단 sh 예시)

출장에서 배운 경험을 바탕으로, 앞으로는 현장에 들어가기 전 자동화 스크립트로 환경을 먼저 점검하기로 했다.

실제로 제작한 자동화 스크립트는 훨씬 더 상세하지만, 간단한 예시만 들어보면 아래와 같다.

#!/bin/bash
# 간단 health-check 예시

# 내부망 DB 포트 확인
nc -z -w3 10.0.0.50 3306 && echo "DB 연결 OK" || echo "DB 연결 FAIL"

# 망연계 서버 확인
nc -z -w3 192.168.100.10 15000 && echo "망연계 OK" || echo "망연계 FAIL"

# 외부 API 통신 확인 (샘플 API)
curl -Is https://api.example.com/health --max-time 5 > /dev/null \
  && echo "API 통신 OK" || echo "API 통신 FAIL"

실제 현장에서는 DB_HOST, GW_HOST, API_URL 등을 변수로 교체해 관리하면 훨씬 편하다.
이 스크립트만 실행해도 “망이 열려 있는지 / 막혀 있는지”를 몇 초 만에 알 수 있다.

---

사실 출발점은 집에서 혼자 진행하던 사이드 프로젝트였다.
그 과정에서 Docker를 접했는데, 짧은 내 지식으로는 도커가 “여러 스크립트를 통합한 이미지 + 클라우드형 패키지”처럼 느껴졌다.

하지만 공공기관 환경은 보안 때문에 폐쇄적이라, 도커를 그대로 쓰기 어렵다.
그렇다면 차선책은 무엇일까

• “도커처럼 완벽히 추상화할 순 없더라도,
• 최소한 사람이 일일이 치던 명령어를 원클릭 스크립트로 묶으면 되지 않을까?”

즉, 작업 시간을 단축하고, 사람이 놓칠 수 있는 네트워크/DB 체크를 자동화하면

• 1박 2일 걸리던 설치 작업을 몇 시간 만에 끝낼 수도 있고
• 인력 소모도 줄어들어 업무 효율이 높아질 것이다.
• 현장에 들어가기 전, 반드시 자동화 스크립트로 네트워크 상태를 점검한다.
• 문제가 발생하면 “DB나 애플리케이션”을 의심하기 전에, 먼저 망연계·인바운드/아웃바운드 정책을 확인한다.
• 네트워크 담당자에게 요청할 때는 IP/PORT/프로토콜을 정확히 문서화하여 전달한다.

아직은 직접 현장에 나가서 시험해봐야 알겠지만,
이 스크립트 하나로 현재 작업 효율이 최소한 50% 이상 상승할 것으로 기대한다. 

앞으로 좀 더 정교화시켜서 다음 작업때는 정식 매뉴얼로 작성할 수 있게 된다면 , 

유지보수 팀도 , 개발팀인 나도 모두가 윈윈할 수 있지 않을까 !

앞으로는 현장에 들어가기 전 반드시 이 스크립트로 점검을 먼저 하고,
“사람이 반복해서 실수하는 부분”은 최대한 도구에 맡겨,
더 빠르고 안정적인 배포 환경에서 작업을 할 수 있다면 좋겠다.

---