사내 네트워크 보안 정책 문서 작성법 (이음5G 구축 현장에서 배운 5가지)

얼마 전 한 대기업 계열사의 이음5G(5G 특화망) 구축 프로젝트에 참여했는데, 처음 현장에 들어간 날 받은 인상은 “장비는 정말 좋은데 뭔가 계속 삐걱거린다”는 거였어요. 최신 장비가 다 깔려 있는데도 하루가 멀다 하고 크고 작은 문제가 터지고 있었거든요.

몇 주를 붙어서 원인을 하나씩 따라가 보니 결론은 의외로 단순했어요. 장비가 아니라, 그 장비를 누가 어떤 규칙으로 써야 하는지 정해둔 문서가 없었던 거죠. 그래서 이 글은 사내 네트워크 보안 정책 문서를 왜 만들어야 하는지, 그리고 실제로 어떤 순서로 만들어서 저를 현장에 자리 잡게 했는지를 그 프로젝트의 흐름을 따라가며 정리해보려고 해요.

첫 주에 마주친 세 가지

첫 번째는 IoT 센서였어요. 부서마다 필요할 때마다 센서를 따로 사서 망에 붙이다 보니 같은 IP 주소를 쓰는 장비들이 생겼고, 그 바람에 특정 센서 데이터가 몇 시간씩 끊기는 일이 반복되고 있었어요. 보안팀은 이걸 막고 싶었지만 “이렇게 하면 안 된다”고 내밀 근거 규정이 없으니, 생산팀과 회의 때마다 얼굴 붉어지는 일들이 생겼었습니다.

두 번째는 사무동에서 벌어졌는데, 오후만 되면 특정 층 PC들이 사내 시스템에 접속을 못 하는 현상이 며칠째 이어지고 있더라고요. 한참을 추적해서 찾아낸 범인은 한 직원이 자리 와이파이가 약하다며 책상 밑에 꽂아둔 개인 공유기였는데, 이 공유기가 사내망에 제멋대로 IP 주소를 뿌리면서 주변 PC들 설정을 전부 꼬아놓고 있었던 거예요. 그 직원은 그저 일을 편하게 하려던 것뿐이었고, 개인 장비를 연결하면 안 된다는 규정도 없었으니 누구를 탓할 수도 없는 이상한 상황이었죠.

세 번째가 가장 심각했습니다. 공장 안에서는 무인 운반 로봇(AGV)이 5G망으로 제어 신호를 주고받고 있었는데, 점심시간만 되면 로봇들이 잠깐씩 멈춰 서는 거예요. 처음엔 다들 로봇이나 기지국 고장을 의심했지만, 알고 보니 직원들이 같은 망으로 영상을 보기 시작하면서 로봇 제어 신호가 뒤로 밀리고 있었던 거였어요.

세 장면 모두 장비만 놓고 보면 고장 난 건 하나도 없었어요. 문제는 처음부터 끝까지 “규칙이 없다”는 한 가지로 이어져 있었던 거죠.

비싼 장비가 해결해주지 못했던 이유

프로젝트 초반 회의에서 경영진 쪽에서 가장 먼저 나온 이야기는 “보안 솔루션을 더 좋은 걸로 바꾸면 되지 않냐”는 거였어요. 그런데 아무리 고가의 방화벽이나 제로 트러스트 솔루션을 들여와도, 어떤 IP 대역을 허용할지, 예외는 누구 승인을 받아야 하는지가 정해져 있지 않으면 장비는 결국 허술하게 설정될 수밖에 없어요. 장비는 규칙을 실행하는 손일 뿐이고, 그 규칙 자체는 사람이 정해서 문서로 남겨야 하는 게 맞는 거죠.

“5G는 원래 빠르니까 대역폭 걱정은 없다”는 말도 몇 번 들었는데, 점심시간 로봇 사례가 그 생각이 왜 위험한지를 그대로 보여줬어요. 최대 속도가 빠른 것과 어떤 상황에서도 핵심 업무가 끊기지 않는 건 전혀 다른 얘기거든요. 그래서 이 프로젝트의 방향은 장비를 바꾸는 쪽이 아니라, 정책 문서를 처음부터 다시 세우는 쪽으로 정해졌어요.

정책 문서를 다섯 덩어리로 나눈 이유

처음에는 한 권짜리 두꺼운 문서를 만들려고 했는데, 현장에서 겪은 문제들을 하나씩 대입해보니 자연스럽게 다섯 덩어리로 나뉘더라고요. 각 항목이 어떤 문제에서 출발했는지 먼저 표로 정리해보면 이렇습니다.

현장에서 겪은 문제	필요했던 정책
센서 IP 충돌, 책상 밑 개인 공유기	접속과 인증 정책
점심시간 로봇 정지	트래픽 우선순위 정책
구간마다 제각각인 암호화 방식	보안과 암호화 기준
장애 때 누구에게 연락할지 모름	운영과 장애 대응 기준
감사 때마다 근거 자료를 새로 만듦	규제 준수 매핑

접속과 인증 정책은 누가 어떤 장비로 어떤 권한을 가지고 망에 들어올 수 있는지를 정하는 부분인데, 장비를 구분하는 기준과 역할별 권한을 구체적으로 적어두는 게 핵심이에요. 이 프로젝트에서는 “사내망 안에 있으니 믿는다”는 방식 대신 접속할 때마다 단말 상태를 확인하는 제로 트러스트(ZTNA) 방식을 기준으로 삼았고, 백신이 꺼져 있거나 업데이트가 안 된 단말은 핵심 시스템에 들어오지 못하게 막도록 문서에 명시했어요. 책상 밑 공유기 같은 개인 장비 연결도 이 항목에서 정리됐고요.

트래픽 우선순위 정책은 망이 붐빌 때 무엇을 먼저 살릴지 정하는 부분이에요. 5G 단독모드(SA)에서는 네트워크 슬라이싱으로 하나의 망을 여러 개의 가상 망처럼 나눌 수 있어서, 로봇 제어용과 일반 업무용을 분리하고 우선순위를 따로 줄 수 있거든요. 문서에 “로봇 제어 트래픽은 어떤 상황에서도 최우선”이라는 원칙과 슬라이스 구분 방식을 못 박아두고 나서야 점심시간 정지 문제가 사라졌어요.

보안과 암호화 기준은 “데이터는 암호화한다”는 한 줄로 끝내지 않고, 지사와 본사 사이는 IPsec VPN, 서버끼리는 상호 인증(mTLS)처럼 구간별로 방식을 정해두는 부분이에요. 새 장비를 들일 때 모의해킹을 포함한 보안 점검을 어떤 순서로 거칠지도 여기에 같이 넣었어요.

운영과 장애 대응 기준은 야간 작업 승인 절차, 장애 등급별 보고 체계, 정기 점검 주기를 정하는 부분인데, 이게 없으면 장애가 났을 때 결국 장비를 마지막으로 만진 사람이 모든 걸 떠안게 돼요. 실제로 이 현장에서도 새벽 장애 때 누구에게 먼저 연락해야 할지 몰라 담당자 혼자 몇 시간을 붙잡고 있었던 일이 있었는데, 보고 체계를 문서로 정리한 뒤로는 비슷한 상황이 와도 대응 속도가 눈에 띄게 달라졌어요.

규제 준수 매핑은 업종별로 지켜야 하는 규정, 예를 들어 금융업의 망 분리 규정이나 의료 정보 관련 규정을 우리 망 구조의 어느 부분이 충족하는지 연결해 적어두는 부분이에요. 감사가 들어올 때마다 근거 자료를 새로 만들던 일이 이 매핑 표 하나로 정리됐다는 게 보안팀의 가장 큰 만족 포인트였어요.

보안 등급을 나누다 생긴 일

모든 데이터를 똑같은 수준으로 지키려고 하면 비용도 감당이 안 되고 현업도 불편해서 못 버티기 때문에, 데이터의 중요도에 따라 등급을 나누기로 했어요. 처음에는 IT팀 안에서 초안을 만들어 공유했는데, 회의 자리에서 생산팀이 바로 손을 들더라고요. 생산 일정 데이터가 왜 중간 등급이냐는 거였어요.

이야기를 들어보니 그 데이터가 하루만 유출돼도 거래처와의 관계가 흔들릴 수 있는 자료였고, 결국 생산팀 의견대로 최상위 등급으로 올렸어요. 그런데 이 과정이 생각보다 큰 의미가 있었던 게, 그 회의 이후로 생산팀이 정책을 “IT팀이 만든 귀찮은 규칙”이 아니라 “우리가 같이 정한 규칙”으로 대하기 시작했거든요. 최종적으로 정리된 등급 체계는 이렇습니다.

보안 등급	대상	적용 정책
레벨 1 (핵심)	공장 제어 시스템, 핵심 설계 자료, 생산 일정, 고객 정보	망 분리, 구간 전체 암호화, 전용 슬라이스
레벨 2 (사내 업무)	사내 인트라넷, 일반 문서	네트워크 접근 제어(NAC), VPN 기반 접속
레벨 3 (외부·게스트)	게스트 와이파이, 일반 웹 서핑	사내망과 분리해 인터넷으로 바로 연결, 방화벽 통제

지금 돌아보면 등급표 자체보다 그걸 만드는 과정에 현업을 끌어들인 게 더 중요했던 것 같아요. 정책은 결국 사람이 지키는 거라, 정하는 자리에 함께 있었던 사람들이 가장 잘 지키더라고요.

생산팀장님의 한마디 이후 바꾼 문서 쓰는 방식

정책 초안이 어느 정도 나왔을 때 현장 관리자분들께 공유했는데, 생산팀장님께서 문서를 한참 넘겨보시더니 “그래서 우리가 뭘 하면 되는 건데요?”라고 물으셨어요. 그 순간 아차! 눈을 질끈 감았습니다. 문서가 저희끼리만 통하는 용어로만 채워져 있었거든요.

그래서 뭐 어쩌나요. 표현을 전부 다시 썼죠. “AGV 제어 트래픽에 전용 슬라이스 할당”이라고 쓰던 걸 “점심시간에 직원들이 영상을 봐도 로봇이 멈추지 않도록 로봇 전용 도로를 따로 내는 조치”로 바꾸는 식이었는데, 이렇게 고친 버전을 다시 공유했더니 반응이 완전히 달라졌어요. 규칙을 지켜야 하는 이유가 자기 업무와 바로 연결되니까 반감이 확 줄어든 거죠.

같은 이유로 문서 앞쪽에는 망 구성도 한 장을 크게 넣었어요. 몇 페이지짜리 설명보다 그림 한 장이 전체 구조를 훨씬 빠르게 전달하고, 특히 새로 들어온 담당자가 적응하는 데 큰 도움이 되더라고요. 그리고 문서 첫 장에는 매년 정기적으로 검토한다는 주기를 적어두고, 사내 위키에서 누가 언제 무엇을 왜 바꿨는지 이력이 남도록 관리하기로 했어요. 통신 기술이 워낙 빠르게 바뀌어서, 몇 년 전 5G 비단독모드(NSA) 기준으로 만든 규칙은 지금의 단독모드(SA) 환경에 그대로 맞지 않는 경우가 많거든요.

문서를 만든 다음, 지키게 만든 두 가지 장치

정책서를 완성해서 공지했을 때 처음 들은 반응은 역시나 “IT팀이 또 귀찮은 거 만들었네”였어요. 그래서 문서를 강요하는 대신, 지키면 편해지는 구조를 먼저 만들었습니다.

첫 번째 장치는 혜택이었어요. 정책대로 사내 인증을 거쳐 접속한 단말은 일반 단말보다 트래픽 우선순위를 높여서 업무 시스템 접속이 더 빨라지도록 세팅했는데, 그랬더니 처음엔 귀찮아하던 부서들이 오히려 먼저 인증 등록을 요청하기 시작하더라고요. 정책을 지키면 내 업무가 편해진다는 걸 직접 느끼게 해주는 게 백 번 공지하는 것보다 효과가 컸던 거죠.

두 번째 장치는 자동화였어요. 사람의 선의에만 기대면 결국 어디선가 구멍이 생기기 때문에, 정책에 적힌 규칙을 방화벽과 네트워크 접근 제어(NAC) 장비에 실제 설정으로 적용하고, 등록되지 않은 장비가 붙거나 정책에 어긋나는 트래픽이 생기면 관제 화면에 바로 알림이 뜨도록 했어요. 규칙은 사람이 만들고, 지켜지는지 지켜보는 건 시스템에 맡기는 구조인 셈이에요. 그 뒤로 책상 밑 공유기 같은 일은 연결되는 순간 바로 잡혀서 다시 반복되지 않았습니다.

작은 회사에서 시작한다면

이 이야기를 하면 “그건 대기업이니까 가능한 거 아니냐”는 질문을 꼭 받는데, 제 생각은 오히려 반대예요. 전담 보안팀이 없는 회사일수록 문서가 더 필요하거든요. 담당자 한 명이 퇴사하면 망 운영 노하우가 통째로 사라져버리니까요.

처음부터 두꺼운 백서를 쓰려고 하면 지쳐서 포기하기 쉬우니, “누가, 어떤 IP 대역에서, 방화벽의 어떤 포트를 열 권한이 있는가” 정도의 핵심 규칙 두세 장부터 시작해보세요. 그다음 부서별로 필요한 규칙을 하나씩 가지 치듯 붙여나가면 되고, 워드 파일을 메일로 주고받기보다는 사내 위키나 협업 문서 도구에 올려두는 게 관리하기 훨씬 편해요. 맨땅에서 시작하기 막막하다면 미국 국립표준기술연구소(NIST)의 사이버보안 프레임워크처럼 공개된 자료를 뼈대로 삼고 회사 상황에 맞게 다듬어 쓰시면 시간을 크게 아낄 수 있어요.

나중에 6G 같은 새 기술이 들어오면 문서를 다 갈아엎어야 하지 않냐는 질문도 자주 받는데, 그럴 필요는 없어요. 제로 트러스트 원칙이나 데이터 등급 분류 같은 뼈대는 통신 세대가 바뀌어도 그대로 가져갈 수 있고, 새 기술에 해당하는 규칙만 덧붙이면 되거든요. 처음에 뼈대를 잘 세워두는 게 그래서 중요해요.

다시 한다면 처음부터 할 것

프로젝트를 마무리하면서 팀끼리 회고를 했는데, 다들 같은 이야기를 했어요. 다음에 비슷한 프로젝트를 맡으면 장비 발주보다 정책 초안을 먼저 만들자는 거였죠. 장비를 다 깔고 나서 규칙을 만들면 이미 생긴 관행을 되돌리는 데 시간이 훨씬 많이 들거든요.

장비 상자를 뜯어서 전원을 올리는 건 누구나 할 수 있지만, 그 장비를 회사 업무에 맞게 어떻게 길들일지 규칙을 세우는 건 결국 인프라를 기획하는 사람의 몫이더라고요. 혹시 회사 공유 폴더 어딘가에 몇 년째 열어보지 않은 네트워크 가이드라인이 있다면, 이번 주에 한 번 꺼내서 지금의 망과 맞는지 읽어보시는 걸 추천드려요. 거기 적힌 문장 하나하나가 언젠가 장애가 터진 날, 생각보다 큰 힘이 되어줄 거예요.