백성빈

Network Security Engineer

1997.07.14

010-5188-2346

bsung6512@gmail.com

경기 의왕시

Core Competencies

“보안 운영은 단순하게, 결과는 숫자로.”
방화벽 정책 3만 건 단순화, 라우팅 테이블 90% 경량화, 정탐 신뢰도 스코어링으로 정확도 개선.
보안 솔루션 운영 과정에서 인프라 구조의 개선점을 도출하고, 데이터에 기반한 객관적인 판단으로 보안 엔지니어링의 방향성을 찾아 나아갑니다.

Technical Skills

Security Solutions

Firewall WAF IPS NAC SWG NDLP Anti-DDoS

Automation & Dev

Splunk Python JavaScript SQL VBA Shell

Infra & Analysis

Linux AWS Docker Wireshark Regex Syslog

Career Timeline

13
14
15
16
17
18
19
20
21
22
23
24
25
김해율하고등학교
공군작전정보통신단
중사 (만기제대)
학점은행제(학사)
경상남도경찰청
신한DS
정보처리기사
CPPG
ISRM

Career Description

총 8년 5개월의 직장 경력 중 7년 이상을 보안 및 인프라 운영에 집중하며 전문성을 키워왔습니다.
공백 없는 사회생활을 통해 다져진 성실함을 바탕으로, 현재는 네트워크 보안 전문가로서의 입지를 단단히 다져나가고 있습니다.

#대규모_네트워크_보안_운영 #보안_운영_자동화 #집요한_문제_해결

신한DS

대리 (재직 중)
2023.10 ~ 현재 (2년 4개월)

신한은행 온프레미스 네트워크 보안 운영

아키텍처 최적화

SSL 가속 구간 트래픽 흐름 개선(IPS→WAF)으로
WAF 부하 20% 절감
라우팅 테이블 재구성으로 90% 경량화
(Default 라우팅 변경, /32 Host 제거)

운영 업무 자동화

방화벽 정책 분석 도구 개발 및 고도화
(정책 검토 10분 → 1분)
SOAR-FW 연동으로 악성 IP 차단 자동화
(수동 대응 1시간 → 완전 자동화)

심층 문제 해결

패킷 분석으로 웹페이지 접속 불가 원인 규명 및 해결
TCP 3-Way Flag로 비대칭 경로 탐지 및 정상화
대규모 방화벽 정책 간소화 (3만건 → 4천건)

컴플라이언스 준수

ISMS-P, ISO27001 인증 심사 수검
재해복구(DR) 및 DDoS 모의훈련 참여

경상남도경찰청

비IT 경력 경장 (의원면직)
2022.06 ~ 2023.07 (1년 1개월)

사이버 마약범죄 수사

공군 작전정보통신단

중사 (만기제대)
2016.05 ~ 2021.04 (5년)

인프라(서버·네트워크·보안장비) 운영 및 관리

인프라 고가용성 확보

이중화 구성 설계를 통한 무중단 서비스 운영 환경 구축
IPS 패턴 분석 및 정기적인 정책 최적화 수행

ESM 시스템 구축

통합 로그 분석 시스템 도입 제안 및 구축 주도
보안 이벤트 대응 시간 50% 이상 단축

주요 성과

80억 규모 서버 교체 사업 기술 평가 및 성능 시험 담당
사업 기간 단축 기여로 공군작전사령관 표창 수상

자산 및 접근 통제

NAC 활용 단말 접근 관리 및 비인가 접근 통제절차 수립
불용 IT 자산 식별 및 취약점 조치 프로세스 운영

Personal Statement (1/3)

장비를 바꿔야 할 때, 저에게는 재설계의 기회였습니다

저는 네트워크 보안 업무에서 구축과 운영은 뗄 수 없는 관계라고 생각합니다. 구조를 설계할 때 운영까지 고려하는 관점이 꼭 필요하고, 특히 저에게 있어 구축은 장비를 교체하거나 신설하는 작업뿐만 아니라, 트래픽 흐름과 정책 구조, 운영 방식 전반을 함께 다시 고민하는 과정이었습니다.

대표적으로, 부서 단위로 분산되어 있던 소규모 사무실 네트워크를 센터 기준으로 집선·통제하도록 아키텍처를 재구성하는 프로젝트에 참여했습니다. 해당 사용자들의 트래픽이 경유할 신규 방화벽을 센터에 구축하고, 기존 14대의 방화벽 정책을 하나의 정책으로 통합해야 했습니다.
이 과정에서 가장 중요한 과제는 정책을 누락 없이 이관하는 것이었습니다. 처음에는 기존 정책을 모두 병합하면 되지 않을까 했지만, 총합 3만 건이 넘는 정책 수를 확인하면서 안일했던 접근 방식에 대해 경각심을 갖고 정책의 목적과 유사성에 기준을 두어 구조화하는 방향으로 접근을 시작했습니다.
공통적으로 적용되는 기본 정책은 그룹화하고, 포트만 다른 유사 정책은 통합했으며, 사용자 신청 기반으로 생성된 기간 정책은 유효한 것만 선별해 기본 정책 하단에 위치하도록 재배치했습니다. 동시에 신규 정책은 항상 최하단에 추가되도록 하여 Hit Count 기준으로 사용자 신청 정책이 실제 사용되는지 여부를 판단할 수 있는 구조를 병행하여 만들었습니다.
이렇게 약 한 달 동안 정제하여 정책 수를 약 4천 건으로 축소하면서도 이관 이후 정책 누락 없이 안정적으로 업무를 이어갈 수 있었습니다.

이후에는 비대면 뱅킹 후단 구간의 방화벽을 교체하는 구축 작업을 수행했습니다. 웹 서버와 WAS, 서버팜으로 연결되는 핵심 구간이었기 때문에 작업으로 인한 장애 가능성을 최소화할 수 있도록 사전 준비 과정에 더욱더 무게를 두고 접근했습니다.
신규 장비는 약 한 달간 에이징을 거쳐 초기 불량 여부를 검증했고, 인터페이스 및 Zone 설계, 정책 마이그레이션을 선행한 뒤, 마이그레이션 완료 시점부터 교체 시점까지 정책 변경을 제한하는 기간을 두어 운영 리스크를 최소화했습니다.
특히 마이그레이션 과정에서 기존의 Zone을 그대로 따라가지 않고 다시 살펴보았습니다. 기존 방화벽에서는 외부가 External, 내부 백본이 Internal, WAS와 대외기관이 각각 DMZ로 구성되어 있었으나, 대외기관 연계 트래픽은 그 성격상 DMZ 영역이 아닌 외부와의 통신으로 보는 것이 타당하다고 판단했습니다.
그래서 교체할 장비에서는 대외기관 인터페이스를 External로 재정의했고, 기존 DMZ 존에 속해 있던 관련 정책을 IP와 라우팅 기준으로 선별해 대외기관 정책만 External로 수정하여 마이그레이션했습니다. 이를 통해 Zone 구성을 명확히 하고, 이후 정책 관리와 트러블슈팅 시 혼선을 줄일 수 있었습니다.

이러한 경험들을 거치며, 되돌릴 수 없는 큰 작업일수록 단기적인 편의보다 장기적인 관리 용이성과 판단 기준의 명확함이 더 중요하다는 것을 체감했습니다.
정책의 수를 줄이고 굳이 Zone을 다시 설정한 것도 깔끔한 구성을 만들기보다는 장애나 이슈 발생 시 불필요한 추측과 확인 과정을 줄이기 위함이었습니다. 실제로 구조가 단순해질수록 운영자의 판단 속도가 빨라졌고, 휴먼 에러도 눈에 띄게 줄어드는 것을 체감할 수 있었습니다.

Personal Statement (2/3)

동료들과 쉽게 일할 수 있도록 도구를 만들었습니다

네트워크 보안 운영 업무를 하며 느낀 가장 큰 비효율은 사람의 기억과 숙련도에 의존하는 구조라고 생각했습니다. 복잡한 네트워크 인프라 속에서 하루 업무 시간의 절반 가까이를 방화벽 정책 신청서 검토에 쓰기도 했었습니다. 출발지와 목적지 IP를 기준으로 통신 경로를 판단해 60개가 넘는 방화벽들 중 무엇을 경유하는지 한눈에 파악하는 것은 기존 담당자에게도 쉽지 않은 일이었고 신규 인력에게는 더욱 높은 진입 장벽이었습니다.
저 역시 입사 초기에 아키텍처를 정확히 파악하지 못해 정책을 잘못된 방화벽에 적용하는 실수를 했었습니다. 이렇듯, 숙련도에 의존하면 문제가 발생할 수 있다는 것을 저 또한 입사 초기에 겪었다보니 구조적으로 해결해야 할 문제라고 판단했습니다.

처음에는 Excel VBA로 간단한 스크립트를 만들어, 어떤 IP가 어느 방화벽 구간에 속해 있는지를 한눈에 확인할 수 있도록 했습니다. 출발지와 목적지 IP를 입력하면 적용 대상 방화벽을 자동으로 보여주는 방식이었는데, 이를 통해 정책 검토 시간이 곧바로 단축되는 효과를 확인할 수 있었습니다.
이후 이 도구로 운영 전반의 품질을 개선할 수 있겠다는 생각이 들었고, 퇴근 후와 주말 시간을 활용해 웹 기반 도구로 고도화했습니다. 내부망 환경에서도 동작할 수 있도록 외부 모듈에 의존하지 않는 구조를 설계하고 Python과 순수 JavaScript로 모든 기능을 구현했습니다. IP와 포트를 입력하면 방화벽 정책뿐 아니라 NAT, 라우팅, 컴플라이언스 위반 여부까지 함께 분석해 테이블 형태로 제공하도록 설계하여, 운영자가 실제 검토하는 데 사용하는 요소들을 직관적으로 보여주는 것에 초점을 맞췄습니다.
그 결과, 신청 건당 많게는 10분까지 걸리던 검토 시간을 1분 이내로 줄일 수 있었고, 동료들로부터 "이 도구가 없었을 때는 어떻게 일했는지 모르겠다"는 좋은 피드백을 받을 수 있었습니다.
이후에는 D3.js를 활용해 네트워크 토폴로지를 시각화하고, 해당 토폴로지를 기반으로 경로가 자동 탐색되도록 확장했습니다. 눈으로 구조를 확인할 수 있게 되면서 구간 이해도가 크게 높아졌고, 특히 신규 입사자 온보딩 과정에서 설명과 학습에 소요되는 시간을 절반 이상 줄이는 효과를 얻었습니다. 단순 반복 업무를 줄이는 것에 그치지 않고, 누구나 실수 없이 일관된 결과를 도출할 수 있는 환경을 직접 설계해 본 값진 경험이었습니다.

또한 외부 위협에 대한 대응 속도를 개선하고 반복적인 업무를 줄이기 위해 SOAR와 방화벽 API를 연동하여 악성 IP를 자동으로 차단하도록 구성했습니다.
이전에는 SOAR에 등록된 티켓을 보고 악성 IP를 20여 대의 전단 방화벽에 수동으로 등록해야 했습니다. 이를 개선하기 위해 방화벽 제조사에서 제공하는 API 정의서를 토대로 SOAR에서 직접 호출할 수 있도록 흐름을 설계하여 개발을 요청했습니다. 운영 리스크를 최소화하기 위해 초기에는 중요도가 낮은 일부 전단 방화벽에만 적용해 정상 동작 여부를 검증한 뒤 점진적으로 전체 구간으로 확장했습니다.
현재는 해당 작업을 스케줄링으로 자동 수행하고 있으며, 성공·실패 여부만 메일로 수신해 확인하고 있습니다. 웹 통제 장비(SWG)에도 같은 방법을 적용하여 악성 URL 차단 또한 수동 작업이 아닌 일관된 흐름으로 처리할 수 있도록 했습니다. 이를 통해 반복적인 수작업을 제거하는 동시에, 위협 정보 반영 속도와 운영 안정성을 함께 확보할 수 있었습니다.

이러한 경험을 통해 저는 업무의 효율은 개인의 숙련도뿐만 아니라 판단 기준을 구조화하는 것에 달려있다는 것을 깨달았습니다. 현업의 불편함을 관행적으로 감내하지 않고, 원인을 구조적으로 정의하고 개선으로 연결해 온 것이 저의 강점입니다. 토스뱅크에서도 직무 속에 반복되는 일들을 시스템화하여 더 혁신적이고 안정적인 네트워크 보안 환경을 만드는 데 기여하고 싶습니다.

Personal Statement (3/3)

욕심이 나서, 토스뱅크를 선택했습니다

저의 이직 사유를 한 단어로 정리하면 '욕심'입니다. 지금까지 금융권에서 방화벽, WAF 등 핵심 보안 인프라를 운영하며 안정성과 리스크 관리의 중요성을 충분히 체득해 왔습니다. 사소한 실수가 장애로 이어질 수 있기에 보안은 언제나 보수적이어야 한다는 원칙 역시 몸으로 배웠습니다.

다만 경험이 쌓일수록 그저 주어진 구조를 운영하는 역할을 넘어 "왜 이렇게 설계되어 있는지, 더 나은 구조는 없는지"를 끝까지 고민하고 판단하는 역할로 성장하고 싶다는 욕심이 커졌습니다.
지금의 환경에서는 이러한 열망을 실행으로 옮기기 어려운 한계도 분명히 있습니다. 금융권 특성상 운영과 설계, 의사결정의 책임이 여기저기 흩어져 있고, AI나 자동화 역시 규제와 관성 속에서 제한적으로 다뤄지는 경우가 많았습니다.
구조를 바꿔보고 싶어도 자동화나 새로운 시도를 이야기하기에는 조심스러운 환경이었고, 고객사의 자산을 운영하는 입장이기 때문에 그동안 저는 이런 생각들을 혼자 정리할 수밖에 없었습니다.

저는 지금까지 네트워크 보안 업무를 수행하며, "보안이 피할 수 없는 영역이라면 불편을 감수하게 만들 것이 아니라 서비스 흐름 속에 자연스럽게 녹아들게 할 수는 없을까"라는 의문을 품어왔습니다. 토스뱅크는 제가 느끼던 이러한 갈증을 가장 정면으로 해소할 수 있는 조직이라고 생각합니다.
금융권에서는 보안상의 이유로 검증되지 않은 오픈소스 도입을 꺼려하고는 하는데, 토스뱅크는 실제로 업무 자동화를 위한 n8n과 같은 도구를 업무에 과감하게 도입하며 새로운 표준을 만들어 가고 있다는 점이 인상 깊었습니다. 변화에 주저하지 않으면서도 책임과 원칙을 함께 지켜가는 토스뱅크의 방식은 제가 직접 경험해 보고 싶었던 팀의 모습이었고, 무엇보다 같은 문제의식을 가진 동료들과 함께 더 높은 기준을 만들어 갈 수 있다는 점이 정말 기대됩니다.
입사 후에는 빠르게 변하는 보안 위협 속에서 어떻게 하면 대응 속도와 정확도를 높이면서도 사용자 경험을 저해하지 않을 수 있을지를 팀과 함께 고민하고 싶습니다. 금융 서비스에서 보안은 곧 신뢰의 얼굴인 만큼, 그 과정 역시 사용자 경험과 조화를 이루어야 한다고 생각합니다. 보안을 강화하면서도 사용자는 이를 의식하지 않게 만들고, 서비스의 흐름을 방해하지 않으면서도 더 안전한 환경을 제공하는 역할을 수행하고 싶습니다.

토스뱅크는 이러한 문제의식에 가장 깨어있는 은행입니다. 안 되는 명분을 찾아내기보다 어떻게 가능하게 만들지를 끊임없이 고민하고 실행하는 모습에서 깊은 인상을 받았습니다. 지켜야 할 원칙은 타협하지 않되, 비효율적인 관행은 기술적 개선으로 돌파하며 보안의 품질을 높이는 과제를 함께해나가고 싶습니다.
더 나은 선택을 만들기 위해 고민을 함께 공유하고, 혼자의 판단이 아니라 팀의 논의로 답을 만들어 가는 문화 속에서라면, 저 역시 주어진 역할에 안주하지 않고 한 단계 더 어려운 책임을 자처하는 욕심을 가져볼 수 있을 것이라 생각합니다. 금융 서비스가 자연스럽고 안전하게 확장될 수 있도록 보안의 기준을 한 단계 끌어올리는 역할을 토스뱅크에서 동료들과 함께해 나가고 싶습니다.

지금까지 긴 글 읽어주셔서 감사합니다.

다음 장부터 케이스별 상세 사례를 담았습니다.

직무에서 겪었던 문제 상황과 해결 과정, 결과를 구체적으로 소개드리고자 합니다.

Detailed Experience (1/5)

Case 01

금융보안원 DDoS 모의훈련 대응

▶ Situation

금융보안원 주관 DDoS 모의훈련에 참여하여, 실제 공격 상황을 가정한 트래픽 탐지부터 대응, 클라우드 대피소 전환을 통한 서비스 정상화까지 전 과정을 점검했습니다.

이 훈련은 대규모 DDoS 공격 발생 시 빠르게 대응할 수 있는지를 점검하고, 자체적으로는 현재 운영 중인 클라우드 대피소 전환 절차가 실제 상황에서도 문제없이 작동하는지 확인하기 위한 목적이 있었습니다.

▶ Action

1. 사전 준비: 훈련 시나리오와 대응 매뉴얼을 토대로 온프레미스 DDoS 방어 장비의 임계치 및 차단 정책을 훈련 환경에 맞게 사전 튜닝하였고, Radware 클라우드 대피소의 BGP 연동 상태를 점검했습니다.

2. 훈련 당일 실시간 대응: 훈련 시작과 동시에 온프레미스 DDoS 장비에서 트래픽 급증을 확인했습니다. 장비가 가용 범위 내에서 정상적으로 트래픽을 처리하는지 약 5분간 확인한 뒤, 대규모 공격 상황을 가정하여 Radware 클라우드 대피소로 수동 전환을 진행했습니다. 이 과정에서 통신팀과 함께 BGP 광고 우선순위가 정상적으로 변경되었음을 확인했으며, 전환 약 3분 후 온프레미스 장비의 차단 트래픽이 줄어들고 Radware에서 필터링된 정상 트래픽만 GRE 터널을 통해 유입되는 것을 확인했습니다.

3. 훈련 종료 후 복구 및 분석: 금융보안원 훈련 종료 통보 후 클라우드 대피소 전환을 원복하고, 전환 및 복구에 걸린 시간과 응답 지연 여부를 확인했습니다.

▶ Result

훈련을 통해 실제 DDoS 공격 상황에서도 Radware 클라우드 대피소로 전환이 원활하게 이루어지고, 공격 트래픽이 정상적으로 차단되는 것을 확인할 수 있었습니다.

훈련 개시 후 약 10분 이내에 대피소 전환 및 서비스 정상화를 완료하였으며, 훈련 전 과정에서 서비스 가용성 100%를 유지했습니다.

또한 훈련 과정에서 확인된 내용을 바탕으로 BGP 광고와 GRE 터널 점검 항목을 정리해 체크리스트를 보완했고, 이후 실제 장애나 침해 사고 대응 시 참고할 수 있도록 관련 절차를 정리했습니다.

Detailed Experience (2/5)

Case 02

SSL 가속 구간 아키텍처 변경을 통한 보안장비 리소스 확보

▶ Situation

기존의 대고객 트래픽 흐름에서는 외부 트래픽이 SSL 가속기에서 복호화된 이후 WAF → IPS 순서로 처리되어 웹 서버로 들어가도록 구성되어 있었습니다.

IPS는 단순 스캔성 공격 등 넓은 범위의 위협을 빠르게 식별·차단하는 역할에 강점이 있음에도, 트래픽이 IPS보다 WAF를 먼저 통과하며 불필요한 리소스 소모가 발생하는 비효율적인 구조였습니다.

▶ Action

이 구간의 노후화 교체 사업을 기회로 삼아, 보안 장비 간 트래픽 흐름을 IPS → WAF 순서로 재배치하는 것을
제안했습니다.

1. 보안 장비 역할 관점에서 구조 고민: IPS 단계에서 패턴 기반 Known Threat을 선제적으로 필터링하고, WAF에서 웹 트래픽 심층 분석에 집중하는 것이 각 장비의 설계 목적에 부합한다고 판단했습니다.

2. 담당자 설득 및 유관 부서 협업: 구성 변경에 따른 서비스 안정성 우려를 해소하기 위해, 장비의 역할과 처리 효율 관점에서 은행 담당자를 설득했습니다. 이후 통신팀과 협업하여 구성 변경 방안을 구체화하고 테스트 계획을 수립하여 구축했습니다.

3. 운영 영향 최소화를 위한 사전 검증: 운영 리스크를 최소화하기 위해 변경된 구성을 검증할 수 있는 Pool을
먼저 구성하고, 개발팀의 출발지 IP만 해당 구간을 경유하도록 제한하여 사전 업무 점검을 진행했습니다.

▶ Result

이러한 구조 개선을 통해 WAF를 통과하는 평균 Throughput을 20% 이상 경감시켰습니다.

또한, 노후화 교체 사업 일정에 맞춰 단계적 검증과 적용을 병행함으로써 서비스 중단을 최소화한 상태에서 단순 장비 교체에 그치지 않고 보안운영 환경을 고려한 아키텍처 개선을 함께 수행하여, WAF의 트래픽 처리 효율과 위협 탐지 가시성을 동시에 향상시키는 성과를 달성했습니다.

Detailed Experience (3/5)

Case 03

패킷 분석을 통한 장애 원인 분석 및 재발 방지 프로세스 수립

▶ Situation

WAF 펌웨어 패치 작업 직후, 직원 인터넷망 PC에서 이 WAF 구간에 있는 특정 웹서버로 접속 시 브라우저에서 ERR_EMPTY_RESPONSE 오류가 발생했습니다.

해당 요청이 WAF 로그에 남지 않아 단순 로그 분석만으로는 장애 원인을 파악하기 어려운 상황이었습니다.

▶ Action

단순 롤백으로는 문제 해결이 어렵다고 판단하여, 통신팀과 협업해 Hop 단위로 패킷 흐름을 추적하며 원인을
분석했습니다.

1. 세션 구간별 TCP 흐름 분석: WAF가 Full Proxy로 동작하는 구조임을 고려해, 클라이언트–WAF 구간과 WAF–서버 구간을 분리하여 분석했습니다. 클라이언트와 WAF 간 3-Way Handshake는 정상적으로 수립되었으나, WAF가 서버로 전달한 SYN에 대한 SYN-ACK 응답이 보이지 않았습니다.

2. L2 관점 추적: MAC Address를 기준으로 흐름을 추적해보니, 클라이언트와 서버가 각각 인지하고 있는 WAF의 MAC 주소가 상이했습니다. 클라이언트는 Standby 상태의 WAF 2호기와 세션을 수립했으나, 서버 응답은 Active 장비인 WAF 1호기로 전달되며 패킷이 Drop되고 있었던 것입니다.

3. Root Cause 도출: 펌웨어 패치로 인해 인접 방화벽이 Failover된 이후 ARP Cache가 갱신되지 않아 잘못된 MAC 정보를 참조하고 있음을 원인으로 특정하여 ARP 테이블 클리어를 통해 트래픽 흐름을 정상화할 수 있었습니다.

▶ Result

단순히 재기동부터 시도했더라면 정확한 원인을 알지 못한 채 정상화될 수도 있었겠지만, 트래픽 흐름과 장비
동작 특성부터 짚고 넘어감으로써 근본적인 원인을 분석하여 문제를 해결했던 경험이었습니다.

이후 해당 구간 작업 시 ARP 테이블 정합성 검증을 체크리스트에 포함하도록 프로세스를 개선했습니다.

Detailed Experience (4/5)

Case 04

로그 분석을 통한 방화벽 라우팅 테이블 최적화

▶ Situation

대외기관 전단 방화벽의 Default 라우팅이 내부망 방향으로 설정된 탓에, 그간 대외기관 연결 시마다 /32 단위의 호스트 라우팅을 수동으로 추가해 왔습니다.

이로 인해 관리하기 어려운 수천 개의 라우팅 항목이 있었고, 헷갈리기 쉬운 구조로 인해 라우팅 설정 누락 등 휴먼 에러가 발생할 가능성이 높은 상태였습니다. 장비 스펙상 라우팅 개수 제한에 도달해 제조사의 기술 지원을 받은 적도 있었습니다.

저 역시 처음에는 관행대로 기존 운영 방식에 따랐지만, 결국 장비 스펙 한계에 도달했을 때 단순한 라우팅 추가는 임시방편일 뿐이라는 점을 깨닫고 구조적 문제를 먼저 고민했어야 했다는 문제의식을 갖게 되었습니다.

▶ Action

Splunk를 활용해 2년간의 트래픽 로그를 기준으로 라우팅 테이블을 재설계했습니다.

1. 로그 기반 재설계 방향 수립: 사설·공인 IP 대역이 혼재된 환경에서 임의 정리나 경험 기반 판단은 장애 리스크가 매우 크다고 판단하여 실제 허용 트래픽 로그를 기준으로 라우팅 구조를 재정비하기로 결정했습니다.

2. 라우팅 테이블 설계: Default 라우팅을 대외기관 방향으로 설정하고, 최근 2년간의 로그를 분석해 실제 사용 중인 IP들을 Interface별로 구분하여 반영함으로써 라우팅 테이블 구조를 근본적으로 정비했습니다.

3. 운영 영향 검증 및 적용: 로그 기반 검증과 주요 대외기관 트래픽 점검을 통해 경로 정상 여부를 확인한 뒤 운영 환경에 적용했으며, 장애 발생 시 즉시 복구할 수 있도록 사전 백업 및 롤백 절차를 함께 준비했습니다.

▶ Result

이를 통해 비대해진 라우팅 테이블 라인 수를 90% 이상 정리하며 장비 리소스를 최적화했습니다.

동시에 라우팅 구조가 단순화되면서 신규 대외기관 연계 시 수작업 설정 부담과 휴먼 에러 가능성을 크게 줄였고, 이후 운영에서도 예측 가능하고 관리하기 쉬운 라우팅 체계를 확보할 수 있었습니다.

Detailed Experience (5/5)

Case 05

차단 기준 수립을 통한 오탐 최소화 및 운영 효율 개선

▶ Situation

금융 서비스 환경에서는 단 한 건의 오탐도 서비스 장애로 직결될 수 있어, 차단 정책을 수정할 때는 항상 서비스 안정성이 최우선이었습니다.

매월 학습된 WAF 시그니처를 정기적으로 차단 적용하고 있었으나, 신규 시그니처가 누적되면서 차단 여부를
결정하기 위해 수십 건의 시그니처를 매번 개별 분석하면서 정책을 일관되게 검토하는 데 한계가 있었기 때문에 운영 효율성을 도모하고 판단의 정확도를 높일 수 있는 구조적인 개선의 필요성을 느꼈습니다.

▶ Action

1. 차단 기준 재정의: 학습된 WAF 시그니처를 무조건 차단하는 방식 대신 과거 이벤트 로그를 기반으로 차단이 가능한 조건을 명확히 정의하는 방향으로 접근했습니다.

2. 위험 지표를 통한 차단 판단: SOAR와 연동해 공격자 IP가 블랙리스트(TI)에 포함되는지 대조하고, 평상시
트래픽 대비 새벽 시간대 등 특정 시간대의 비정상적 트래픽 급증 여부를 가중치로 반영하고, SQL Injection
페이로드 내 sleep 키워드 등 공격 의도가 명확한 패턴의 매칭 강도를 점수화하여 종합했습니다.

3. 차단·검토 분리 운영: 종합 점수가 기준치를 초과하는 경우에만 자동 차단을 적용하고, 그 외 시그니처는
수동 검토 대상으로 분리해 차단 안정성과 운영 효율을 동시에 확보했습니다.

▶ Result

월 단위로 검토해야 했던 차단 대상 시그니처 수를 크게 줄이면서도 오탐 없이 안정적인 차단 운영을 유지할 수 있었습니다.

시그니처를 단순히 ID 순서대로 검토하던 방식에서 벗어나, 위협 수준에 따른 자동 차단과 수동 검토 체계를 분리함으로써 보안 정책 운영의 일관성을 확보했습니다.

End of Document

감사합니다

"반복은 자동화하고, 판단은 더 정확하게.
일하는 방식을 설계하는 엔지니어가 되겠습니다."

Portfolio

https://portfolio.beeen.my/

포트폴리오에서는 자동화 도구의 개발 과정과 데모를 확인하실 수 있습니다.

본 문서의 레이아웃 디자인은 Gemini의 도움을 받았습니다.
본 문서에 작성한 모든 내용은 AI의 그 어떤 도움도 받지 않고 직접 작성하였습니다.