네트워크 구성도 작성법 2026 — 구간·장비 표기와 방화벽 정책·인프라 구성도 8단계

네트워크 구성도는 "트래픽이 어디를 지나는가"를 그린 그림이다

네트워크 구성도를 한 줄로 말하면 패킷이 출발지에서 목적지까지 지나는 구간과 장비를 순서대로 그린 그림이다.

서버 목록을 그린 시스템 구성도와 헷갈리기 쉬운데, 보는 축이 다르다. 시스템 구성도는 「무엇이 있나」를 세고, 네트워크 구성도는 「무엇을 지나가나」를 센다.

둘 다 필요하고, 한 장에 섞으면 둘 다 못 읽는다. 서버 상자 사이에 방화벽과 VLAN 을 끼워 넣으면 개발자는 서버를 못 찾고 인프라 담당은 경로를 못 따라간다.

시스템 쪽 작성법은 시스템 구성도 작성법에 따로 정리했다.

인프라 구성도와는 또 다른가

「인프라 구성도」는 현장에서 두 가지 뜻으로 쓰인다.

• 넓은 뜻 — 서버·네트워크·스토리지를 다 합친 그림. 시스템 구성도와 거의 같은 말로 쓰인다.
• 좁은 뜻 — 자원 배치도. 어느 랙에 어떤 장비가 몇 U 로 들어가는지, 전원과 회선이 어디로 들어오는지.

둘 중 무엇을 뜻하는지 먼저 물어보는 편이 빠르다. 문서 이름으로 다투는 것보다 「거기에 IP 대역이 들어가나요」 한 마디가 정확하다. 들어가면 네트워크 구성도 쪽이고, 랙 유닛과 전원이 들어가면 배치도 쪽이다.

클라우드로 오면 좁은 뜻이 거의 사라진다. 랙도 전원도 우리 것이 아니기 때문이다. 그래서 클라우드 사업에서 「인프라 구성도를 달라」고 하면 대개 VPC·서브넷·보안 그룹이 그려진 그림, 즉 네트워크 구성도를 뜻한다. 반대로 온프레미스 사업에서 같은 말을 하면 배치도를 기대하는 경우가 많다.

⚠️ 산출물 목록에 「인프라 구성도」라고만 적으면 나중에 다툰다. 계약서에는 「구간·대역·정책이 포함된 네트워크 구성도」처럼 무엇이 들어가는지로 적는 편이 안전하다. 문서 이름은 조직마다 다르지만 들어갈 항목은 다르지 않다.

무엇을 그리나 — 구간·장비·주소 세 층

네트워크 구성도는 세 층으로 읽는다. 층이 섞이면 못 읽는 그림이 된다.

구간을 먼저 그리고 그 안에 장비를 놓는다. 장비부터 나열하면 어느 장비가 어느 신뢰 경계에 있는지가 사라지고, 그 순간 보안 검토가 불가능해진다.

[인터넷]
   │
[방화벽 FW-01]
   │
[DMZ  10.0.10.0/24]  ── 웹 서버 2대, 리버스 프록시
   │
[방화벽 FW-02]
   │
[내부  10.0.20.0/24]  ── WAS 2대, 배치 1대
   │
[내부  10.0.30.0/24]  ── DB 2대 (이중화)

DMZ 를 두는 이유는 하나다. 외부에서 닿아야 하는 것과 절대 닿으면 안 되는 것을 분리하기 위해서다. DB 가 DMZ 에 있으면 그건 DMZ 가 아니라 그냥 공인망이다.

선이 무엇을 뜻하는지 먼저 정한다

구성도를 받고도 못 읽는 가장 흔한 이유가 이것이다. 같은 선이 그림마다 다른 뜻으로 쓰인다.

셋은 같은 그림에서 전혀 다른 모양이 된다. 물리로는 스위치 하나에 다 꽂혀 있어도, 논리로는 VLAN 으로 갈려 있고, 정책으로는 한쪽 방향만 열려 있을 수 있다.

범례(legend)를 한 줄 넣어 달라고 요청하면 된다. 「실선 = 물리 결선, 점선 = 허용 정책, 화살표 = 방향」 한 줄이면 충분하고, 그 한 줄이 없어서 회의가 한 번 더 생긴다.

⚠️ 화살표 방향을 「데이터가 흐르는 방향」으로 그리는 사람과 「접속을 시작하는 방향」으로 그리는 사람이 섞여 있다. 방화벽 정책은 후자로만 말이 되므로, 보안 검토용 그림이면 반드시 접속 개시 방향으로 통일한다.

IP 대역과 VLAN 을 어디까지 적나

전부 적으면 못 읽고, 안 적으면 쓸모가 없다. 기준은 그 그림을 누가 무엇에 쓰는가다.

개별 서버 IP 를 그림에 박지 않는다. 서버는 늘어나고 줄어드는데 그림은 안 따라간다. 그림에는 대역을 적고, 개별 IP 는 자원 목록 표로 뺀다. 그래야 서버가 한 대 늘어도 그림을 다시 안 그린다.

⚠️ 공인 IP 를 문서에 적을 때는 배포 범위를 정한다. 계약서 부속으로 나가는 문서에 공인 IP 대역과 방화벽 정책이 같이 적히면 그 문서 자체가 보안 자산이 된다.

방화벽 정책은 그림에 넣지 말고 표로 뺀다

정책을 화살표로 그리기 시작하면 선이 스무 개를 넘고, 그 순간 아무도 안 본다.

그림에는 「어느 구간에서 어느 구간으로 열려 있다」까지만 그리고, 실제 정책은 표로 관리한다.

번호를 붙여 두면 장애 때 「FW-003 이 막혔다」로 말이 통한다. 번호가 없으면 매번 「WAS 에서 DB 가는 거요」라고 설명해야 하고, 그 설명이 사람마다 달라진다.

정책 표는 줄어들지 않는다는 점을 염두에 둔다. 임시로 연 것을 닫는 절차가 없으면 1년 뒤에 아무도 용도를 모르는 정책이 절반이 된다. 비고 칸에 누가 언제 왜 열었는지를 적어 두는 것이 유일한 방어다.

클라우드는 그림의 단위가 다르다

온프레미스의 스위치·방화벽이 클라우드에서는 논리 자원으로 바뀐다. 이름만 다르고 역할은 같다.

프라이빗 서브넷에 있는 것은 인터넷에서 못 닿는다 — 이것이 클라우드에서 DMZ 를 대신하는 구조다. DB 를 퍼블릭 서브넷에 두고 보안 그룹으로만 막는 구성이 흔한데, 그건 방화벽 규칙 하나가 잘못되면 그대로 노출된다는 뜻이다.

⚠️ NAT 게이트웨이는 트래픽 종량 과금이다. 프라이빗 서브넷의 서버가 외부 API 를 많이 부르면 여기서 비용이 붙는다. 구성도에 NAT 이 그려져 있으면 월 비용 항목에 그것이 있는지 확인한다.

이중화는 「무엇이 죽어도 되는가」로 그린다

이중화를 그리면 상자가 두 배가 되고 그림이 복잡해진다. 그래서 어디를 이중화했는지가 아니라, 어디가 단일 장애점인지를 읽을 수 있게 그려야 한다.

단일 장애점(SPOF)을 그림에 표시해 달라고 요청하는 편이 빠르다. 이중화된 곳을 세는 것보다 안 된 곳을 세는 것이 짧다. 회선이 한 가닥이면 서버를 아무리 이중화해도 그 회선이 SPOF 다.

전환 시간도 같이 적는다. 「이중화돼 있습니다」와 「장애 시 30초 안에 전환됩니다」는 다른 약속이고, 후자만 검증할 수 있다.

검수할 때 볼 것

네트워크 구성도를 받으면 다섯 가지만 확인해도 대부분의 문제를 막는다.

1. 구간이 신뢰 경계로 나뉘어 있는가 — 외부에서 닿는 것과 안 닿는 것이 갈려 있는가
2. 범례가 있는가 — 선과 화살표의 뜻이 적혀 있는가
3. DB 가 외부에서 직접 닿는 구간에 있지 않은가
4. 단일 장애점이 표시돼 있는가
5. 관리 접속 경로가 그려져 있는가 — 운영자는 어디로 들어오나

⚠️ 5번이 자주 빠진다. 서비스 트래픽만 그리고 운영 접속(SSH·RDP·DB 툴)을 안 그리면, 실제로는 열려 있는데 문서에는 없는 경로가 생긴다. 사고는 대개 그 경로로 난다.

흔한 실수 5가지

① 장비를 다 그리고 구간을 안 그린다 상자는 많은데 어느 것이 외부에 노출되는지 모르는 그림이 된다. 구간이 먼저다.

② 물리와 논리를 한 장에 섞는다 케이블 결선과 트래픽 경로가 같은 선으로 그려지면 둘 다 못 읽는다. 두 장으로 나눈다.

③ 개별 서버 IP 를 그림에 박는다 서버는 늘어나는데 그림은 안 따라간다. 대역만 적고 개별 IP 는 표로 뺀다.

④ 방화벽 정책을 전부 화살표로 그린다 선이 스무 개를 넘으면 아무도 안 본다. 구간 간 허용만 그리고 정책은 표로.

⑤ 그림에 기준일과 버전이 없다 파일이 세 개 돌아다니는데 어느 것이 최신인지 아무도 모른다. 한구석에 「2026-09-30 기준 / v1.2」 한 줄이면 된다.

네트워크 구성도 완성 8단계

[ ] 1. 사용자 유형과 진입 경로 정리 (외부 이용자 / 내부 직원 / 운영자)
[ ] 2. 신뢰 경계로 구간을 나눈다 (인터넷 / DMZ / 내부 / 관리)
[ ] 3. 구간마다 대역을 배정한다 (개별 IP 아님)
[ ] 4. 구간에 장비를 놓는다 (방화벽·LB·스위치)
[ ] 5. 범례를 정한다 (실선·점선·화살표의 뜻)
[ ] 6. 방화벽 정책은 별도 표로 번호를 붙여 뺀다
[ ] 7. 단일 장애점을 표시하고 전환 시간을 적는다
[ ] 8. 기준일·버전 표기 → 검토 → 확정

막히는 지점은 2번과 6번이다.

2번(구간 나누기) 에서 「우리는 작아서 구간이 하나면 된다」로 넘어가기 쉽다. 그래도 최소 두 구간은 나눈다 — 외부에서 닿는 것과 안 닿는 것. 이 둘이 안 갈리면 나중에 보안 요구가 들어왔을 때 구조를 다시 짜야 한다.

6번(정책 분리) 은 미루면 영영 안 한다. 그림에 화살표로 그려 두면 「이미 문서화했다」고 느껴지기 때문이다. 정책은 바뀌는 것이고 그림은 안 바뀌는 것이므로, 바뀌는 것을 표로 빼 두는 편이 유지가 된다.

AI-Native 팀이 네트워크 구성도를 다루는 방식

트리숲은 AI-Native Team 으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 네트워크 구성도에서 어려운 것은 그리는 일이 아니라 실제 구성과 어긋나지 않게 유지하는 일이다.

• 선언과 실물 대조 — 인프라 정의(IaC)의 서브넷·보안 그룹과 문서의 구간·정책 표가 일치하는지 확인해, 그림에만 있고 실제로는 없는 경로를 잡는다
• 열려 있는데 문서에 없는 경로 탐지 — 보안 그룹 규칙을 정책 표와 대조해 「누가 언제 왜 열었는지」가 비어 있는 행을 뽑는다
• 변경 이력 유지 — 구간·대역이 바뀔 때 그림·정책 표·운영 문서 세 곳이 같이 갱신됐는지 대조한다

네트워크 구성도의 가치는 장애가 났을 때 어느 구간을 볼지 5분 안에 좁혀지는가로 판가름난다. 대조를 자동화해 사람이 구조 판단에 집중하게 만드는 것이 AI-Native 개발 방식의 관점이다.

AI 기능 없이 순수 웹·앱 개발이 필요하다면 포텐랩(Potenlab)도 좋은 선택이다. MVP 부터 플랫폼 개발까지 전문으로 한다.

자주 묻는 질문

네트워크 구성도와 시스템 구성도 중 뭐가 먼저인가요? 시스템 구성도가 먼저다. 무엇이 있는지 정해야 어디에 놓을지가 정해진다. 다만 보안 요구가 강한 사업(공공·금융)은 구간 설계가 먼저 오기도 한다.

작은 서비스도 네트워크 구성도가 필요한가요? 클라우드 한 대로 돌리는 규모면 시스템 구성도에 구간 표시만 얹어도 된다. 외부에서 닿는 것과 안 닿는 것이 갈리는 순간부터 따로 그리는 편이 낫다.

어떤 도구로 그리나요? 상관없다. 읽히기만 하면 파워포인트도 충분하다. 다만 편집 가능한 원본을 함께 받는다 — 이미지만 받으면 다음 담당자가 수정을 못 해 처음부터 다시 그린다.

클라우드인데도 네트워크 구성도가 필요한가요? 필요하다. 이름이 VPC·서브넷·보안 그룹으로 바뀔 뿐 구간과 정책은 그대로 있다. 오히려 콘솔에서 몇 번 클릭으로 열리기 때문에 문서가 없으면 더 빨리 어긋난다.

외주 개발사가 그려 주나요? 인프라까지 포함한 계약이면 개발사가 그린다. 인프라를 발주처가 직접 운영한다면 구간·대역은 발주처가 정하고 개발사는 거기에 맞춘다. 이 경계를 계약 전에 정하지 않으면 착수 후에 서로 기다린다.

정리

네트워크 구성도는 트래픽이 지나는 구간의 지도다. 시스템 구성도가 「무엇이 있나」를 센다면, 네트워크 구성도는 「무엇을 지나가나」를 센다.

실무에서 결과를 가르는 지점은 셋이다.

1. 구간을 신뢰 경계로 나눴는가 — 외부에서 닿는 것과 안 닿는 것이 갈려 있어야 한다
2. 범례가 있는가 — 선의 뜻이 안 적혀 있으면 아무도 같은 그림을 보지 않는다
3. 정책을 표로 뺐는가 — 그림은 안 바뀌고 정책은 바뀐다

이 셋만 챙겨도 장애 때 어느 구간을 볼지 5분 안에 좁혀진다.

서버·DB 쪽 그림은 시스템 구성도 작성법에, 화면 배치는 메뉴구조도 작성법에 정리했다.

데이터가 어느 표에 담기는지는 테이블 정의서·ERD 작성법을, 문서 전체 지도는 외주 산출물 문서 7단계를 참고하면 된다.