보안 엔지니어 이력서 작성법 - 운영한 솔루션 이름만으로는 무엇을 막았는지 알 수 없습니다

여기서 말하는 보안 엔지니어는 기술로 공격을 찾아내고 막는 엔지니어입니다. 서비스를 공격자처럼 점검하는 취약점 진단·모의해킹, 보안 이벤트를 탐지하고 사고에 대응하는 관제·침해사고 대응, 클라우드와 사내 인프라의 접근을 통제하는 보안 인프라, 개발 과정에서 보안 검토와 점검을 하는 개발보안, 게임 안티치트처럼 제품 안에 보안 기능을 만드는 제품 보안이 모두 여기에 들어갑니다. 인증 심사와 개인정보 정책이 중심인 보안컨설팅(ISMS-P)은 다른 직무라 이 글에서는 다루지 않습니다. 이 직무의 경력을 "EDR, DLP, WAF 운영", "웹·모바일 모의해킹 수행", "보안관제 및 침해사고 대응" 같은 문장으로 적는 경우가 많습니다. 이런 문장은 어떤 솔루션을 다뤘는지는 알려 주지만 무엇을 찾아냈고 무엇을 막았는지는 알려 주지 않습니다. 담당자가 확인하려는 것은 어느 영역을 맡았는지, 찾아내거나 막은 것이 무엇이었는지, 같은 문제가 다시 생기지 않게 무엇을 바꿨는지입니다.

맡은 영역이 분명해야 한다

같은 보안 엔지니어 공고라도 회사마다 하는 일이 크게 다릅니다. 기업 채용 분석의 보안 엔지니어 공고 57건(2026년 10월 분석 기준)을 보면 맡는 일은 크게 다섯 가지입니다.

• 진단·공격: 웹·모바일·API·인프라 취약점 진단, 모의해킹, 레드팀
• 탐지·대응: 보안관제(SOC), 탐지 룰 개발, 위협 헌팅, 침해사고 대응(CERT), 디지털 포렌식, 악성코드 분석
• 보안 인프라·접근통제: 클라우드 보안 설정, IAM과 암호키 관리, 데이터 암호화와 DLP, 엔드포인트·네트워크 보안 솔루션, SASE와 제로트러스트
• 개발보안: 설계 단계의 보안 리뷰와 위협 모델링, CI/CD에 소스코드·오픈소스 점검을 붙이는 DevSecOps
• 제품 보안: 게임 안티치트, 모바일 앱 위변조 방지, 차량 사이버보안처럼 제품 안에 보안 기능을 만드는 일

영역마다 요구하는 경험이 다릅니다. 쿠팡의 Staff Security Engineer (Penetration Tester) 공고는 Burp Suite, Metasploit 같은 침투 테스트 도구를 써 본 경험을 요구했고, LG유플러스의 침해사고 예방 및 대응 공고는 디스크·메모리 포렌식 분석 경험을 필수로 적었습니다. 크래프톤의 Game Security S/W Engineer 공고는 C++ 개발 역량과 Windows 내부 동작, x64 Assembly 이해를 요구해 시스템 개발자 공고에 가깝습니다. 그래서 여러 영역을 오갔다면 프로젝트마다 어느 영역의 일이었는지 밝히고, 지원하는 공고의 영역에 해당하는 경험을 자세히 씁니다. 관제 경력이라면 교대 근무로 이벤트를 1차 분석했는지, 탐지 룰을 만들고 고쳤는지, 사고를 끝까지 조사했는지도 밝힙니다. 같은 관제 경력이라도 이 셋은 담당자가 보는 것이 서로 다릅니다. 이웃 직무와의 경계는 맡은 책임으로 나누면 분명해집니다. ISMS-P 심사 자료를 준비하고 정책 문서를 관리한 경력은 보안컨설팅 경력이고, 그 기준을 IAM 정책이나 로그 수집 설정으로 직접 구현했다면 보안 엔지니어 경력입니다. 서버를 운영하면서 요청받은 방화벽 포트를 열어 준 정도라면 인프라 경력이고, 보안 정책의 기준을 세우고 과다 허용 정책을 점검해 정리했다면 보안 쪽 경력으로 봅니다. 규제가 요구하는 것을 기술 통제로 만드는 일도 보안 엔지니어가 맡습니다. 토스의 Security Engineer (클라우드 보안) 공고는 금융 컴플라이언스 기준을 충족하도록 망 분리, 데이터 보호, 접근 통제 체계를 설계·구축·운영하는 일을 업무로 적었습니다. 이런 경력이라면 어느 규제 기준을 어떤 기술 통제로 구현했는지 적습니다.

진단은 찾은 취약점의 조치까지

취약점 진단 경력은 몇 건을 찾았는지만 적으면 절반만 적은 것입니다. 담당자는 무엇을 대상으로 어떤 방식으로 찾았고, 찾은 취약점이 실제로 조치됐는지까지 봅니다. 위버스컴퍼니의 서비스 보안점검 공고는 소스코드 분석을 바탕으로 취약점 재현, 원인 분석, 영향 평가, 개선 검증을 독립적으로 해 본 경험을 자격 요건으로 요구했습니다. 이 공고의 업무에는 주문·결제 과정에서 절차 우회, 금액 변조, 중복 처리 같은 위험을 찾는 일도 들어 있습니다. 그래서 진단 경력에는 대상(서비스 수, 웹·앱·API·인프라 구분), 방식(블랙박스·화이트박스, 자동 도구와 수동 분석), 찾은 취약점의 위험도별 건수, 조치율과 재점검 결과를 적습니다. 자동 스캐너로 찾기 어려운 권한 우회나 비즈니스 로직 취약점을 찾았다면 따로 밝힙니다. 토스의 Security Researcher (모의해킹/취약점 분석) 공고는 비즈니스 임팩트를 기준으로 리스크를 설명할 수 있는 사람을 찾는다고 적었습니다. 위험도를 점수로만 쓰지 말고 그 취약점으로 무엇이 가능했는지(다른 사용자의 주문 조회, 결제 금액 변경 등)를 함께 쓰는 게 좋습니다. 이 자리는 서비스 구조와 비즈니스 흐름을 분석해 위협 모델링과 보안 설계도 맡습니다. 출시 전에 설계를 리뷰했다면 몇 건을 검토했고 설계 단계에서 무엇을 바꿨는지도 씁니다.

진단 업체·관제 업체 경력이라면

보안 엔지니어 가운데는 진단 전문 업체나 관제 업체에서 여러 고객사를 맡아 온 사람이 많습니다. 이 경우 취약점 조치는 고객사가 하므로 조치율을 알기 어려울 때가 흔합니다. 대신 맡은 고객사와 프로젝트 수, 각 프로젝트의 역할(PM인지 수행 인력인지), 이행 점검에서 확인한 조치 건수를 적습니다. 무신사페이먼츠의 CERT/취약점진단 공고는 전자금융기반시설 취약점 분석·평가 같은 금융 규제 대응 점검을 업무로 적었습니다. NAVER Cloud의 인프라 보안 담당자 공고는 주요정보통신기반시설 취약점 분석·평가 기준(CCE)에 따라 진단해 본 경험을 우대합니다. 이런 법정 점검을 해 봤다면 기준 이름과 대상 규모를 함께 씁니다. 기업 보안팀처럼 결과를 끝까지 책임지는 자리로 옮기려 한다면 고객사에 조치 방안을 어떻게 설명했고 재점검에서 무엇이 달라졌는지를 자세히 쓰는 게 좋습니다.

탐지는 오탐을 얼마나 줄였는지까지

관제와 침해사고 대응 경력은 "보안 이벤트 분석"이라는 말로 뭉뚱그리기 쉽습니다. 힐링페이퍼의 보안 엔지니어 (Detection & Response) 공고는 알람 처리 결과로 탐지 룰·임계치·예외 조건을 조정하고, 탐지의 유효성을 검증하며 불필요한 알람과 반복 분석 업무를 줄여 본 경험을 자격 요건으로 요구했습니다. 알람 처리 시간, 미처리 티켓, 반복 발생률 같은 운영 지표로 품질을 개선한 경험은 우대 사항입니다. 탐지 경력에는 다룬 로그 소스, 처리량(EPS나 하루 로그량), 맡은 탐지 룰 수와 함께 오탐 비율이 어떻게 달라졌는지를 적습니다. 오탐을 줄였다면 실제 위협을 놓치지 않았는지 확인한 방법도 적어야 합니다. 줄이기만 하고 검증하지 않았다면 미탐이 늘었을 수도 있기 때문입니다. 침해사고 대응은 사고 하나를 시간 순서로 적을 수 있어야 합니다. 최초 인지 경로, 침입 경로와 영향 범위를 확인한 로그와 포렌식, 격리와 복구에 각각 걸린 시간, 재발을 막으려고 바꾼 것을 적습니다. 넷마블의 침해대응 CERT 공고도 침해지표(IOC)를 도출하고 탐지 정책을 개선해 유사 사고의 재발을 막는 일을 주요 업무로 꼽았습니다.

보안 정책과 업무가 부딪칠 때

접근통제와 보안 솔루션 운영은 정책을 만들었는지보다 그 정책이 업무를 막을 때 어떻게 처리했는지가 실력을 보여 줍니다. 컬리의 네트워크 보안 솔루션 운영 공고는 서비스별 WAF 예외 정책 관리, SASE 예외 신청 검토, 과다 허용·미사용 정책의 정기 점검을 업무로 적었습니다. CJ올리브영의 엔드포인트 보안 및 SecOps 엔지니어 공고는 보안성과 사용자 편의성을 함께 고려해 현실적인 해결책을 설계하는 사람을 우대합니다. 그래서 통제 경력에는 대상 규모(계정·단말·서버 수), 바꾸기 전후의 권한 상태, 예외 처리 건수와 그 기준을 적습니다. 쿠팡의 Staff IAM Engineer 공고는 퇴사 시 접근 권한을 즉시 회수하는 자동화와 소스코드·CI/CD 파이프라인에 하드코딩된 시크릿을 찾아 Vault로 옮기는 일을 업무로 적었습니다. 이런 일을 했다면 권한 회수까지 걸린 시간과 남아 있던 장기 키·시크릿 수가 얼마나 줄었는지를 숫자로 적습니다.

재발을 막는 자동화와 체계

보안 업무를 코드로 자동화한 경험은 여러 공고가 요구합니다. 채널코퍼레이션의 Security Engineer 공고는 이 경험을 자격 요건으로 적고, 이 자리가 "사는 사람"보다 "만드는 사람"에 가깝다고 설명했습니다. 토스의 Security Researcher (모바일보안) 공고는 취약점 하나를 찾는 데서 그치지 않고 같은 문제가 다시 생기지 않도록 플랫폼이나 시스템으로 해결해 본 경험을 요구했습니다. 자동화 경력은 스크립트를 만든 사실보다 무엇이 줄었는지로 적습니다. 사람이 하던 점검이 몇 시간에서 몇 분이 됐는지, 배포 파이프라인에서 막은 건수가 얼마인지, 같은 유형의 취약점이 다음 진단에서 몇 건 나왔는지가 그 숫자입니다. 비상교육의 개발보안/DevSecOps 리드 공고처럼 CI/CD 단계에 보안 품질 게이트를 두는 자리라면 빌드를 막는 기준을 어떻게 정했고 개발팀이 그 기준을 받아들이게 하려고 무엇을 했는지도 씁니다. 파이프라인을 만드는 일은 DevOps 엔지니어도 합니다. 무엇을 막을지 기준을 정하고 예외를 승인한 사람이 지원자 본인이었다는 점을 밝혀야 보안 경력으로 인정받습니다.

AI를 쓴 경험과 AI를 점검한 경험은 다르다

보안 엔지니어 공고에서 AI는 두 가지 뜻으로 나옵니다. 하나는 AI 도구로 보안 업무를 하는 경험입니다. 뤼튼테크놀로지스의 Security Engineer 공고는 Claude Code, Codex 같은 AI 도구로 보안 이벤트를 분석하고 위협에 대응한 경험을 자격 요건으로 요구했습니다. 앞에서 본 CJ올리브영 공고의 자격 요건에도 생성형 AI의 특성과 한계를 이해하고 결과의 정확성과 보안성을 검증하는 역량이 들어 있습니다. 이런 경험이라면 AI로 무엇을 자동화했는지와 AI가 낸 틀린 결과를 무엇으로 걸러 냈는지를 함께 적습니다. 다른 하나는 AI 기능 자체를 공격하고 점검하는 경험입니다. 당근의 Security Engineer - 인프라 (보안, AI Security) 공고는 프롬프트 인젝션, 권한 오남용, 도구 호출 조작 같은 LLM·AI 에이전트 공격 기법을 연구하고 적용하는 일을 업무로 적었습니다. 이런 경험이라면 어떤 AI 기능을 대상으로 어떤 공격을 시험했고 무엇을 막았는지 적습니다. 두 경험은 이력서에서 나눠 써야 담당자가 어느 쪽인지 알 수 있습니다.

같은 경력을 이렇게 적으면

강한 문장에는 무엇을 대상으로 했는지, 처음 상태가 어땠는지, 지원자가 바꾼 것과 그 결과, 그리고 그 결과를 무엇으로 확인했는지가 들어 있습니다. 같은 SIEM과 진단 도구를 썼더라도 강한 문장에는 면접에서 물어볼 거리가 훨씬 많습니다.

공개할 수 없는 취약점과 사고를 적는 법

보안 경력에는 그대로 적으면 안 되는 내용이 많습니다. 아직 패치되지 않았을 수 있는 취약점의 위치와 재현 방법, 사고를 겪은 회사나 고객사의 이름, 탐지 룰의 구체적인 조건은 이력서에 쓰지 않습니다. 면접에서 룰을 설명할 때도 회사 룰 원문 대신 일반화한 로직으로 말합니다. 이력서에는 서비스의 종류(이커머스 결제, 사내 업무 시스템 등), 취약점과 사고의 유형, 규모, 걸린 시간, 바꾼 통제나 체계의 이름을 씁니다. "고객사 랜섬웨어 사고 대응"보다 "제조업 고객사 서버 40대가 감염된 랜섬웨어 사고에서 최초 인지 3시간 안에 감염 구간 네트워크를 격리하고, 48시간 안에 침투 경로와 영향 범위를 확정"처럼 쓰면 회사와 세부 기법을 밝히지 않고도 규모와 맡은 역할을 보여 줄 수 있습니다. 언론에 보도된 사고라면 업종과 규모만으로 회사가 특정될 수 있으니 시기를 빼거나 규모를 범위로 씁니다. 숫자 자체를 회사 밖에 적어도 되는지는 회사의 보안 규정에서 먼저 확인하는 게 안전합니다.

실무 경력 없이 보여 줄 수 있는 것

취약점 진단이나 침해사고 분석은 회사 밖 실습으로도 실적을 보여 줄 수 있는 분야입니다. 안랩의 디지털 포렌식 공고는 신입 지원자에게 CTF, 보안 동아리, 개인 연구, GitHub 활동 같은 실습 경험을 요구했습니다. 당근 AI Security 공고는 AI 보안 경험을 실무 경력, 버그바운티, 개인 연구, CTF, 블로그 등 어떤 형태든 환영한다고 밝혔습니다. 현대오토에버와 여기어때의 모의해킹 공고, 메가존클라우드의 침해사고 분석가 공고는 해킹대회 입상이나 버그바운티 실적을 우대합니다. 이력서에는 대회 이름과 순위만 쓰지 말고 맡은 분야(웹, 리버싱, 포렌식 등)와 푼 문제의 유형까지 밝히는 게 좋습니다. 버그바운티는 그 프로그램의 공개 정책이 허용하는 범위 안에서 조치와 공개가 끝난 건만 유형과 위험도로 적습니다. CVE를 받았다면 담당자가 직접 확인할 수 있도록 번호도 적습니다. 토스의 Security Researcher (모의해킹/취약점 분석) 공고는 높은 윤리 의식을 함께 일할 사람의 조건으로 적었습니다. 실습도 허가받은 대상과 범위 안에서 한 것만 이력서에 올립니다. 보안 솔루션 운영과 클라우드 접근통제는 실제 사용자와 서비스가 있어야 해 볼 수 있는 일이라 혼자 경험하기 어렵습니다. 이쪽을 목표로 한다면 개인 클라우드 계정에서 최소 권한 IAM 정책을 설계해 본 기록, 로그 수집과 탐지 룰을 구성하고 공격을 재현해 탐지되는지 확인한 기록부터 이력서에 적을 수 있습니다. 관제 직무를 준비한다면 정보보안기사 같은 자격증과 보안관제 전문 교육 과정 수료 이력도 도움이 됩니다. 메가존클라우드의 보안관제 공고가 이 둘을 우대합니다.

진단과 사고 대응을 마친 날 숫자를 남겨 둔다

진단 결과와 사고 보고서는 회사 시스템에 남아 있어서 회사를 옮기면 다시 볼 수 없습니다. 이력서를 쓸 때쯤이면 기억에는 "취약점을 꽤 많이 찾았다", "오탐을 많이 줄였다" 정도만 남습니다. 그래서 진단이나 사고 대응을 하나 마칠 때마다 맡은 일, 바꾼 통제나 체계의 이름, 취약점·사고 유형, 비율이나 걸린 시간을 몇 줄로 남겨 두는 것이 좋습니다. 고객사와 서비스 이름, IP와 시스템 이름, 취약점의 위치, 사고 날짜는 적지 않습니다. 회사의 보안 서약이 허용하는 범위 안에서만 기록합니다. GridResume 커리어 기록에 이렇게 적어 두면 이력서를 쓸 때 대상과 숫자가 들어간 문장을 바로 만들 수 있습니다.

정리하면

보안 엔지니어 이력서에 들어가야 할 것은 다섯 가지입니다.

• 진단, 탐지·대응, 보안 인프라, 개발보안, 제품 보안 가운데 어느 영역을 맡았는지
• 찾아내거나 막은 것의 유형과 규모, 그리고 그것이 실제로 해결됐는지
• 탐지와 통제를 바꾼 뒤 오탐, 예외, 처리 시간이 어떻게 달라졌고 그것을 무엇으로 확인했는지
• 같은 문제가 다시 생기지 않게 자동화하거나 체계로 바꾼 것
• 공개할 수 없는 내용을 뺀 유형과 숫자

같은 솔루션을 운영했더라도 이 다섯 가지가 적혀 있으면 담당자는 지원자가 무엇을 막아 왔는지 알 수 있습니다.