들어가며 — 문을 열어야 하는 숙명
앞선 글에서 우리는 사무실 네트워크를 아홉 개의 세계로 나눴습니다. 그곳의 규칙은 단순했습니다. 안에서 서로를 못 보게 벽을 세우고, 밖에서는 아무도 못 들어오게 문을 걸어 잠그면 됐습니다. 사내망은 본질적으로 닫힌 세계입니다. 직원과 서버와 장비들만 있으면 되고, 인터넷에서 낯선 이가 찾아올 일은 없습니다.
데이터센터의 서비스망은 정반대입니다. 이곳에는 실제 고객이 접속하는 서비스가 삽니다. 홈페이지, 웹 애플리케이션, API, 메일 서버. 이들은 존재 이유 자체가 “외부에서 접속되는 것”입니다. 문을 걸어 잠글 수가 없습니다. 오히려 전 세계 누구든 찾아올 수 있도록 문을 열어두어야 합니다. 그것이 서비스의 숙명입니다.
그런데 문을 연다는 것은, 초대받지 않은 손님도 들어올 수 있다는 뜻입니다. 인터넷에 서버를 노출하는 순간, 그 서버는 끊임없는 탐색과 공격에 시달립니다. 이것은 과장이 아닙니다. 공인 IP 하나를 인터넷에 올리면 몇 분 안에 자동화된 스캐너들이 문을 두드리기 시작합니다. 열려 있는 포트를 찾고, 알려진 취약점을 시험하고, 흔한 비밀번호를 대입해 봅니다. 이들은 특정한 우리를 노린 것이 아니라, 그저 인터넷 전체를 훑으며 만만한 먹잇감을 찾는 기계들입니다.
우리가 데이터센터 서비스망을 설계할 때 마주하는 근본적인 긴장은 여기 있습니다. 열어야 하지만, 지켜야 한다. 이 글은 그 긴장을 어떻게 다루는가에 대한 이야기입니다. 필요한 만큼만 문을 열고, 그 열린 문마저 여러 겹으로 지키는 우리의 방식을 풀어보겠습니다.
📋 프로젝트 관리의 시선으로
1편이 “내부를 나누는 이야기”였다면, 2편은 “외부로부터 지키는 이야기”입니다. 하지만 사고방식은 같습니다 — 노출(범위)은 최소로, 통제는 여러 겹으로, 변경은 되돌릴 수 있게. 이것은 프로젝트에서 공격 표면(=리스크 노출)을 줄이고, 방어선을 다중화하고, 릴리스를 안전하게 관리하는 일과 정확히 겹칩니다. 이 글은 파티션 설계·리눅스 선택·사내망 분리 이야기와 같은 믿음 위에 서 있습니다 — 한 곳의 실패가 전체의 실패가 되지 않게 미리 설계한다.
공격 표면이라는 개념
외부로부터 지키는 일의 출발점은 공격 표면(attack surface)이라는 개념입니다. 공격 표면이란 외부의 공격자가 접근하거나 노려볼 수 있는 모든 지점의 총합입니다. 열려 있는 포트 하나하나, 노출된 서비스 하나하나가 전부 공격 표면입니다. 표면이 넓을수록 공격받을 여지가 많고, 좁을수록 방어가 쉬워집니다.
그래서 서비스망 보안의 첫 번째 원칙은 명확합니다. 공격 표면을 최소화한다. 꼭 필요한 것만 외부에 노출하고, 나머지는 전부 감춥니다. 서버에 열 개의 서비스가 돌더라도 외부에서 접근해야 할 것이 웹 하나뿐이라면, 오직 그 웹만 노출하고 나머지 아홉은 철저히 가립니다.
이것을 우리가 지키는 방식으로 정리하면 이렇습니다.
- 노출은 예외, 차단은 기본. 외부에서 내부로 들어오는 문은 기본적으로 전부 닫혀 있습니다. 특정 서비스를 외부에 열어야 할 명확한 이유가 있을 때만, 그 서비스 하나에 대해서만 문을 엽니다. “일단 다 열고 위험한 것만 막는” 방식이 아니라 “다 막고 필요한 것만 여는” 방식입니다.
- 서버를 직접 노출하지 않는다. 외부에서 오는 요청이 내부 서버에 직접 닿게 두지 않습니다. 반드시 방화벽과 중간 관문을 거치게 합니다. 서버는 인터넷에서 보이지 않는 곳에 숨어 있고, 오직 관문을 통해서만 요청을 받습니다.
- 서비스망을 다시 나눈다. 사내망을 나눴던 것처럼, 데이터센터 안에서도 외부에 노출되는 영역과 내부 데이터가 있는 영역을 분리합니다. 설령 노출된 영역이 뚫리더라도, 진짜 중요한 데이터가 있는 안쪽까지는 닿지 못하게 합니다.
[ 공격 표면: 넓은 노출 vs 좁은 노출 ]
나쁜 예 — 서버를 직접, 여러 포트로 노출
인터넷 ──▶ 서버 :22 (SSH) ← 공격 대상
──▶ 서버 :3306 (DB) ← 공격 대상
──▶ 서버 :8080 (관리) ← 공격 대상
──▶ 서버 :443 (웹) ← 공격 대상
네 개의 문 = 네 배의 위험
좋은 예 — 단일 관문, 최소 노출
인터넷 ──▶ 관문 :443 ──▶ (내부) 서버들
하나의 문만 노출, 나머지는 전부 내부에 은닉📋 프로젝트 관리 관점 — 노출을 줄이면 관리할 리스크가 줄어든다
“공격 표면을 최소화한다”는 것은, 프로젝트로 치면 범위와 노출을 최소로 유지하는 것과 같습니다. 통제해야 할 지점이 많아질수록 빠뜨리는 곳이 생기고, 그 하나가 사고의 입구가 됩니다. 꼭 필요한 것만 열고 나머지는 닫는 화이트리스트 사고는, 리스크를 “셀 수 있는 수”로 묶어줍니다 — 열어둔 것만 관리하면 되니까요. 관리 가능한 리스크는 좁게 정의된 리스크입니다.
첫 번째 관문 — 방화벽과 최소 개방
외부로부터의 방어는 겹겹의 관문으로 이뤄집니다. 그 가장 바깥에 서는 것이 방화벽입니다. 방화벽은 인터넷과 우리 네트워크 사이의 경계에 서서, 오가는 모든 트래픽을 검문하는 문지기입니다.
여기서 우리가 다루는 두 가지 개념이 NAT와 포트포워딩입니다. 조금 풀어 설명하면 이렇습니다. 우리의 내부 서버들은 인터넷에서 직접 보이지 않는 사설 주소를 씁니다. 외부에서는 오직 방화벽의 공인 주소 하나만 보입니다. 외부의 요청이 이 공인 주소로 들어오면, 방화벽이 “이 요청은 내부의 이 서버로 보내라”고 길을 이어주는 것이 포트포워딩입니다. 그 반대로 내부 서버가 인터넷으로 나갈 때 사설 주소를 공인 주소로 바꿔주는 것이 NAT입니다.
이 구조의 핵심은, 외부에서 내부 서버의 진짜 위치를 알 수 없다는 점입니다. 공격자에게 보이는 것은 방화벽뿐이고, 그 뒤에 서버가 몇 대 있는지, 어떤 주소를 쓰는지는 감춰집니다. 그리고 방화벽에서는 오직 열어야 할 서비스의 포트만 포워딩을 설정하고, 나머지는 전부 닫아둡니다.
[ 방화벽을 통한 최소 개방 ]
외부 요청 (공인 IP :443)
│
▼
┌───────────────┐
│ 방화벽 │ ← 공인 IP 하나만 노출
│ :443 만 허용 │ ← 그 외 인바운드 전부 차단
└───────┬───────┘
│ 포트포워딩 (443 → 내부 웹서버)
▼
┌───────────────┐
│ 내부 웹서버 │ ← 사설 IP, 외부에서 안 보임
└───────────────┘문을 여는 작업에서 가장 위험한 순간이 하나 있습니다. 기존 장비에서 새 방화벽으로 회선을 넘기는 절체(cutover)입니다. 인터넷이 들어오는 메인 관문을 통째로 교체하는 이 작업은, 잘못되면 회사 전체의 인터넷과 모든 외부 서비스가 동시에 멈출 수 있는 가장 긴장되는 순간입니다. 우리는 이런 작업을 결코 즉흥적으로 하지 않습니다. 보조 회선으로 새 방화벽을 미리 완벽히 검증한 뒤, 문제가 생기면 즉시 원래대로 되돌릴 수 있는 안전장치를 갖춰두고, 최소한의 중단으로 회선을 넘깁니다.
이 절체 전략과 포트포워딩을 실제로 어떻게 구성하고 검증하는지는 실전 기록에서 가장 긴장감 있게 다룬 부분입니다.
📎 실전 구축 편
외부 공개 서비스를 위한 포트포워딩 구성과, 서비스 중단을 최소화하며 메인 방화벽을 교체하는 무중단 절체 전략(2단계 검증 + 즉시 롤백)은 이 편에 있습니다.
→ 중소기업 네트워크 구축 – 04. NAT·포트포워딩과 무중단 WAN 절체
📋 프로젝트 관리 관점 — 되돌릴 수 없는 변경은 하지 않는다
절체(cutover)는 프로젝트에서 운영 전환·본배포(go-live)에 해당하는, 가장 리스크가 큰 순간입니다. 우리가 지키는 규율 — 사전 검증(스테이징) → 안전장치(롤백 경로) 확보 → 최소 중단으로 전환 — 은 그대로 릴리스 관리와 변경 관리의 정석입니다. “즉흥적으로 하지 않는다”는 말은, 곧 되돌아갈 길 없는 변경은 계획 없이 실행하지 않는다는 원칙입니다. 롤백 없는 배포는 배포가 아니라 도박입니다.
두 번째 관문 — 오기 전에 거른다
방화벽으로 문을 최소화했다면, 다음 단계는 그 문으로 오는 트래픽을 도착하기 전에 미리 거르는 것입니다. 모든 요청을 다 받아서 하나하나 검사하는 것보다, 애초에 위험한 것들을 입구에서부터 돌려보내는 편이 훨씬 효율적이고 안전합니다.
우리가 쓰는 방법 중 하나가 지역 기반 차단입니다. 앞서 이야기했듯, 인터넷에 노출된 서비스에 대한 무차별 공격의 상당수는 소수의 특정 지역에서 집중적으로 발생합니다. 만약 우리 서비스가 사업상 특정 국가와 아무런 관계가 없다면, 그 지역에서 오는 트래픽을 통째로 차단하는 것만으로 공격 시도의 상당 부분을 입구에서 쳐낼 수 있습니다. 이것은 거친 방법이지만, 공격 표면을 줄이는 데 대단히 효과적입니다.
[ 도착 전 필터링 — 지역 기반 차단 ]
전 세계에서 오는 요청
┌──────────────────────────────┐
│ 정상 사용자 + 무차별 스캐너 │
└──────────────┬───────────────┘
▼
┌──────────────────┐
│ 지역 기반 필터 │ ← 사업과 무관한
│ (입구에서 차단) │ 고위험 지역 차단
└────────┬─────────┘
▼
공격 시도 상당수 사전 제거
→ 뒤쪽 방어선의 부담 경감다만 우리는 이런 차단을 신중하게 다룹니다. 지역 차단은 강력한 만큼 거칠어서, 막은 지역에서 정당한 접속(해외 출장자, 해외 협력사)이 필요해질 수 있습니다. 그래서 “사업상 절대 관계없는 지역”부터 보수적으로 시작하고, 정당한 사용자를 위한 우회 경로를 함께 설계합니다. 보안이 정당한 사용을 가로막아서는 안 되기 때문입니다.
또 하나 입구에서 준비하는 것이 암호화 인증서입니다. 외부에 노출되는 모든 서비스는 반드시 암호화된 연결(HTTPS)로 제공되어야 합니다. 그래야 사용자와 서버 사이의 통신이 도청당하지 않습니다. 우리는 이 인증서를 자동으로 발급하고 자동으로 갱신되도록 구성합니다. 인증서에는 유효기간이 있어서, 사람이 수동으로 관리하면 언젠가 갱신을 잊어 서비스가 먹통이 되는 사고가 반드시 일어납니다. 그래서 이 과정을 완전히 자동화해, 사람 손이 닿지 않아도 인증서가 늘 유효하게 유지되도록 합니다.
이 지역 차단 준비와 인증서 자동화는, 문을 활짝 열기 전에 미리 깔아두는 방어 기반입니다. 실전 기록에서는 이것을 “절체 전에 미리 준비하는 보안”으로 다뤘습니다.
📎 실전 구축 편
지역 기반 차단(GeoIP) 준비와, 사람 손 없이 자동 발급·갱신되는 SSL 인증서(ACME/Let’s Encrypt) 구성은 이 편에서 화면 단위로 다룹니다.
→ 중소기업 네트워크 구축 – 05. 보안 설정 ①: 절체 전 보안 기반 (GeoIP·ACME)
📋 프로젝트 관리 관점 — 예방은 값싸고, 통제는 사용을 막지 않아야 한다
두 가지 원칙이 겹쳐 있습니다. 첫째, 인증서 자동 갱신은 “사람이 언젠가 반드시 잊는다”는 전제 위에서 사람의 실수를 설계로 제거하는 것 — 사후 대응보다 값싼 사전 예방입니다. 둘째, 지역 차단을 “보수적으로 시작하고 우회 경로를 함께 설계”하는 것은 통제가 정당한 사용을 가로막지 않게 하는 균형입니다. 보안이든 프로세스든, 일을 못 하게 만드는 통제는 결국 우회되고 무력화됩니다. 좋은 통제는 마찰을 최소화합니다.
세 번째 관문 — 단일 진입점과 침입 탐지
방화벽으로 문을 좁히고, 입구에서 위험을 걸렀다면, 이제 열린 문 안쪽을 지킬 차례입니다. 여기서 우리가 세우는 두 개의 관문이 단일 진입점과 침입 탐지입니다.
단일 진입점의 발상은 이렇습니다. 외부에 공개하는 웹 서비스가 여러 개라도, 그 모두를 인터넷에 하나씩 노출하지 않습니다. 대신 모든 외부 요청을 받는 단 하나의 관문을 세우고, 그 관문이 요청을 보고 알맞은 내부 서버로 나눠 보냅니다. 이 관문을 리버스 프록시라고 부릅니다.
이 구조의 장점은 여럿입니다. 외부에 노출되는 지점이 단 하나로 줄어드니 공격 표면이 최소화됩니다. 암호화 처리, 접근 제어, 로그 기록 같은 보안 기능을 이 관문 한 곳에 집중시켜 일관되게 관리할 수 있습니다. 그리고 내부 서버들은 이 관문 뒤에 완전히 숨어, 외부에서는 그 존재조차 알 수 없습니다.
[ 단일 진입점 (리버스 프록시) ]
외부 요청들
app.example.com ─┐
api.example.com ─┤
www.example.com ─┤
▼
┌────────────────────┐
│ 단일 관문 (:443) │ ← 유일한 노출 지점
│ · 암호화 종단 │
│ · 접근 제어 │
│ · 로그 집중 │
└─────────┬──────────┘
│ 도메인 보고 분배
┌────────────┼────────────┐
▼ ▼ ▼
웹 서버 API 서버 정적 서버
(내부 은닉) (내부 은닉) (내부 은닉)그리고 마지막으로, 문 안으로 들어온 트래픽이 실제로 나쁜 짓을 하는지 감시하는 침입 탐지를 둡니다. 앞의 방어선들이 “어디에서 왔는가”로 걸렀다면, 침입 탐지는 “무슨 행동을 하는가”로 판단합니다. 알려진 공격 패턴과 오가는 트래픽을 대조해, 수상한 행동을 탐지하거나 차단합니다. 지역 차단과 침입 탐지는 서로를 보완합니다. 하나는 출신지로, 하나는 행동으로 위협을 거르는 셈입니다.
여기서 우리가 중요하게 지키는 원칙이 하나 있습니다. 탐지부터, 그다음에 차단. 침입 탐지 시스템을 처음부터 “차단 모드”로 켜면, 정상적인 트래픽을 공격으로 오인해 막아버리는 사고가 납니다. 그래서 우리는 먼저 “탐지만 하는 모드”로 일정 기간 돌리면서 무엇이 걸리는지 관찰하고, 오탐을 걸러낸 뒤에야 비로소 “차단 모드”로 전환합니다. 성급한 차단은 방어가 아니라 자해가 될 수 있기 때문입니다.
이 단일 진입점 구성과 침입 탐지의 단계적 도입은 실전 기록에서 “절체 후 세우는 능동 방어선”으로 상세히 다뤘습니다.
📎 실전 구축 편
모든 외부 요청을 443 한 점으로 받는 리버스 프록시(Caddy) 구성과, 침입 탐지(Suricata)를 탐지 모드로 시작해 검증 후 차단 모드로 전환하는 단계적 도입은 이 편에 있습니다.
→ 중소기업 네트워크 구축 – 06. 보안 설정 ②: 절체 후 방어선과 접근 (Caddy·Suricata)
📋 프로젝트 관리 관점 — 새 통제는 ‘관찰’로 시작해 ‘집행’으로 간다
“탐지부터, 그다음에 차단”은 그대로 파일럿·단계적 도입의 원칙입니다. 새 프로세스나 통제를 처음부터 강제 집행하면, 오탐(정상을 위반으로 오인)이 정당한 업무를 막아 통제 자체가 사고의 원인이 됩니다. 먼저 관찰 모드로 데이터를 모으고, 오탐을 튜닝한 뒤 집행하는 것 — 성급한 집행은 방어가 아니라 자해라는 이 교훈은, 조직에 새 규칙을 들일 때도 똑같이 유효합니다.
겹겹의 방어 — 심층 방어라는 철학
지금까지 이야기한 관문들을 한 걸음 떨어져 보면, 하나의 일관된 철학이 드러납니다. 심층 방어(defense in depth)입니다. 어느 단 하나의 방어선도 완벽하다고 믿지 않고, 여러 겹의 방어를 겹쳐 쌓는 것입니다. 한 겹이 뚫려도 그다음 겹이 막고, 그것도 뚫려도 또 다음 겹이 막습니다.
방화벽이 문을 최소화하고, 지역 차단이 입구에서 거르고, 인증서가 통신을 암호화하고, 단일 관문이 노출을 줄이고, 침입 탐지가 행동을 감시하고, 서비스망 내부의 분리가 최악의 경우에도 데이터를 지킵니다. 이 각각은 완벽하지 않지만, 겹쳐 쌓이면 공격자가 뚫어야 할 벽이 여러 겹이 됩니다.
[ 심층 방어 — 겹겹의 관문 ]
공격자
│
▼ ① 방화벽 — 필요한 문만 개방
▼ ② 지역 차단 — 출신지로 필터
▼ ③ 단일 관문 — 노출 지점 최소화
▼ ④ 침입 탐지 — 행동으로 감시
▼ ⑤ 서비스망 내부 분리 — 최후의 격리
│
▼
진짜 데이터 (여러 겹을 다 뚫어야 도달)이것은 우연이 아니라, 앞선 글들에서부터 우리가 일관되게 지켜온 태도입니다. 서버의 디스크를 나눌 때도, 사내망을 아홉 개로 가를 때도, 그리고 지금 서비스망에 겹겹의 관문을 세울 때도, 우리는 같은 원칙을 따릅니다. 한 곳의 실패가 전체의 실패가 되지 않게, 미리 여러 겹의 경계를 설계한다. 데이터센터 서비스망은 인터넷을 정면으로 마주 보는 가장 위험한 자리이기에, 이 원칙이 가장 두껍게 적용되는 곳이기도 합니다.
📋 프로젝트 관리 관점 — 어떤 단일 통제도 완벽하다고 믿지 않는다
심층 방어의 전제는 “모든 방어선은 언젠가 뚫린다”는 겸손입니다. 프로젝트 리스크 관리도 똑같습니다. 하나의 검토, 하나의 승인, 하나의 백업에 전부를 걸지 않고 — 예방·탐지·완화·복구를 층층이 겹쳐 둡니다. 한 통제의 실패가 곧 사고가 되지 않도록. “완벽한 단일 대책”을 믿는 계획이 가장 취약한 계획입니다. 겹겹의 통제가 곧 회복탄력성(resilience)입니다.
맺으며 — 열되, 지키는 기술
인터넷에 서비스를 노출한다는 것은, 전 세계를 향해 문을 여는 일입니다. 그 문으로 고객이 찾아오고, 동시에 위협도 찾아옵니다. 이 둘을 갈라낼 방법은 없습니다. 같은 문으로 들어오기 때문입니다. 우리가 할 수 있는 것은, 문을 필요한 만큼만 열고, 그 문을 여러 겹으로 지키며, 들어온 이가 나쁜 짓을 하는지 끝까지 지켜보는 것입니다.
좋은 서비스망 설계란 문을 걸어 잠그는 것이 아닙니다. 그것은 서비스의 죽음입니다. 진짜 좋은 설계는 활짝 열려 있으면서도 안전한 것입니다. 고객은 아무 불편 없이 서비스를 이용하는데, 그 뒤편에서는 겹겹의 방어선이 조용히 위협을 걸러내고 있는 상태. 사용자는 방어선의 존재조차 느끼지 못하지만, 그 방어선이 있기에 서비스가 흔들림 없이 유지됩니다.
우리가 데이터센터 서비스망에 이토록 공을 들이는 이유는, 고객이 인터넷을 향해 문을 열면서도 두 다리 뻗고 잘 수 있게 하기 위해서입니다. 열되, 지킨다. 이 균형을 설계하는 것이 우리가 하는 일입니다. 그리고 그것은 좋은 프로젝트 관리가 하는 일과 같습니다 — 기회를 향해 문을 열되, 리스크가 그 문으로 함께 들어와 판을 뒤엎지 못하게 지키는 것.
지금까지 우리는 두 개의 세계를 지었습니다. 닫힌 사내망과, 열린 서비스망. 하지만 실제 회사는 이 둘이 따로 놀지 않습니다. 본사의 직원이 데이터센터의 서버를 관리해야 하고, 두 곳의 시스템이 서로 통신해야 합니다. 다음 편에서는 이 물리적으로 떨어진 두 세계를, 마치 하나의 네트워크인 것처럼 안전하게 잇는 방법 — 인터넷 위에 전용선을 그리는 IPsec 터널 — 을 다루겠습니다.
