모든 코드에서 취약점을 찾아낸다. 침투 테스트가 취미이자 직업이며, CVE 제보가 훈장이다.
보안 전문가(SEEX) 유형은 공격자의 사고방식으로 방어를 설계하는 개발자입니다. SEC 유형보다 한 단계 더 깊이 들어가, 실제로 시스템을 침투 테스트하고 취약점을 직접 익스플로잇하며 검증합니다. CTF(Capture The Flag) 대회에 참가하고, 버그 바운티 프로그램에서 취약점을 제보하며, 오픈소스 프로젝트의 보안 이슈를 찾아 CVE를 직접 등록하기도 합니다. '공격을 알아야 방어할 수 있다'는 철학을 몸소 실천합니다.
이 유형은 암호화 이론, 네트워크 프로토콜 취약점, 메모리 보안, 웹 보안(XSS, CSRF, SQLi, XXE, SSRF, Deserialization 등)을 전문적으로 다룹니다. Burp Suite, Metasploit, Ghidra, IDA Pro, Wireshark 같은 도구를 일상적으로 사용하고, 어셈블리 코드를 읽고 분석하는 것을 편하게 여깁니다. 코드를 볼 때 기능과 동시에 공격 표면(attack surface)이 보이는 것이 이 유형의 특징입니다.
SEEX 유형이 팀에 있으면 보안 사고 발생 가능성이 극적으로 낮아집니다. 하지만 이들의 전문화된 보안 지식을 팀 전체가 이해하고 활용하게 만드는 것이 과제입니다. 너무 전문화된 보안 지식은 다른 팀원들이 따라오기 어렵고, 모든 것을 혼자 검토하다 보면 배포 속도의 병목이 되기도 합니다. 보안 교육과 자동화된 보안 테스트를 통해 팀 전체의 보안 수준을 높이는 것이 이상적인 방향입니다.
SEEX 유형은 보안을 단순한 체크리스트로 보지 않습니다. 공격자의 창의성이 방어자의 예측을 항상 앞서간다는 것을 알기 때문에, 끊임없이 새로운 공격 기법을 연구합니다. 최근 발표된 제로데이 취약점, 새로운 익스플로잇 기법, 최신 암호화 논문을 꾸준히 읽습니다. 이 지식이 팀의 보안 아키텍처 설계에 반영될 때 비로소 살아있는 보안이 만들어진다고 믿습니다.
"공격자는 한 가지만 성공해도 됩니다. 방어자는 모든 것을 막아야 해요. 그 비대칭이 무서워서 저는 항상 공격자처럼 생각하는 연습을 합니다."
— SEEX 유형 개발자보안 전문가(SEEX) 유형은 모든 코드를 공격자의 시각으로 읽습니다. 다른 개발자가 기능 구현에 집중할 때, SEEX 유형은 이 기능이 어떻게 악용될 수 있는지를 동시에 생각합니다. SQL 인젝션, XSS, CSRF, SSRF, 인증 우회, 레이스 컨디션 같은 취약점 패턴이 코드를 보는 순간 눈에 들어옵니다. 이들의 코드 리뷰는 팀에서 가장 깐깐하지만 가장 중요합니다.
SEEX 유형의 배경은 다양합니다. 화이트햇 해커 출신으로 버그바운티를 통해 보안에 입문한 경우도 있고, 보안 사고를 직접 경험하고 전문화된 경우도 있습니다. OWASP Top 10을 암기하고, CVSS 점수 계산에 능숙하며, 각 CVE가 어떤 원리로 동작하는지 설명할 수 있습니다. CTF(Capture The Flag) 대회 참가가 취미인 경우가 많습니다.
팀 내에서 SEEX 유형은 때로 개발 속도의 적으로 인식됩니다. 보안 점검 때문에 출시가 미뤄지고, 보안 요구사항 때문에 기획이 수정되는 경험을 반복하다 보면 팀원들의 피로감이 쌓일 수 있습니다. 이들의 역할이 빛을 발하는 순간은 보안 사고가 일어났을 때입니다.
SEEX 유형이 장기적으로 영향력을 키우려면 보안을 개발 프로세스에 자연스럽게 녹이는 DevSecOps 문화를 만드는 것이 중요합니다. 자동화된 보안 스캔, SAST/DAST 도구 파이프라인 통합, 보안 교육을 통한 팀 전체 인식 향상이 이들이 집중해야 할 방향입니다.
SEEX 유형 개발자의 실제 하루를 따라가봅니다.
STRENGTHS
WEAKNESSES
Q. 보안 전문가가 되려면 어디서 시작하나요?
OWASP WebGoat, HackTheBox, TryHackMe 같은 실습 플랫폼으로 시작하는 것을 추천합니다. 기초 네트워크 지식과 최소 하나의 프로그래밍 언어 이해가 전제되어야 합니다.
Q. 버그바운티로 수익을 낼 수 있나요?
HackerOne, Bugcrowd 등의 플랫폼에서 활발히 활동하는 해커들은 연간 상당한 수익을 올리기도 합니다. 다만 초반에는 꾸준한 실력 향상이 필요합니다.
Q. 개발팀과 보안팀의 갈등을 어떻게 해결하나요?
보안 요구사항을 초기 기획 단계부터 포함하는 Shift-Left Security 접근법이 효과적입니다. 출시 직전 보안 점검보다 설계 단계 보안 리뷰가 비용이 훨씬 적습니다.
💡 보안 요구사항을 '안 된다'로 제시하기보다 '이렇게 하면 안전하다'는 대안과 함께 제안해보세요. 팀과의 신뢰를 쌓는 가장 빠른 방법입니다.