이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
보안 스터디에서 모의해킹 계획 수립을 처음 실습했습니다. 계획의 핵심은 무엇을 어디까지 테스트할지 범위를 명확히 정하는 것임을 배웠는데, 범위가 불명확하면 팀 내 혼선과 운영 영향이 생길 수 있다는 걸 시뮬레이션으로 확인했습니다. 위협 모델을 먼저 정의해서 어떤 공격자 관점에서 테스트할지를 정하는 방식이 효과적이었습니다. 운영 팀과 사전 합의가 없으면 정상 트래픽과 테스트 트래픽이 섞여 실제 알람이 발동하거나 서비스 영향이 생길 수 있다는 점도 고려 대상이었습니다. 테스트 후 결과를 단순 취약점 목록이 아니라 재현 경로와 우선순위로 정리해 전달해야 실제 조치로 이어진다는 걸 배웠습니다.
후속 조치 추적이 없는 모의해킹은 보고서로 끝나고, 보안 수준 향상으로 이어지지 않는다는 점이 핵심이라고 생각합니다.
모의해킹 범위를 명확히 합의하지 않아서 실 운영 시스템에 영향이 생긴 경험을 사례로 봤습니다. 보안 실습 케이스 스터디에서 스코프 문서 없이 진행한 모의해킹 도중 테스트 범위 외 서버에 스캔이 들어가 담당 팀이 실제 침해로 오인한 사례가 있었습니다. 스코프 합의가 없으면 수행 측과 의뢰 측 모두 기준 없이 상황을 판단하게 됩니다. 범위 정의 문서는 분쟁 예방뿐 아니라 테스트 집중도를 높이는 역할도 한다는 것을 배웠습니다.
테스트 계획의 첫 단계는 무엇을 할지보다 무엇을 하지 않을지를 명확히 하는 것입니다. 이후로는 모의해킹 계획 시 대상 IP·도메인·기간·제외 항목을 서면으로 상호 서명 확인하는 절차를 기본으로 설정했습니다. 이 사례가 이후 보안 테스트 계획 시 스코프 문서화를 착수 조건으로 두는 기준이 됐습니다. 모의해킹의 안전성은 기술 수준만큼 스코프 문서화의 완성도에서 나옵니다.
정기 모의해킹 계획을 경영진 입장에서 생각해본 경험이 있습니다. 보안 투자 결정 관련 수업에서 경영진이 모의해킹 결과 보고를 어떻게 읽는지 분석했는데, 기술 취약점 목록보다 위험이 사업에 어떤 영향을 주는지를 먼저 찾는다는 것을 알게 됐습니다. 경영진 입장에서는 어떤 취약점이 발견됐고 조치 후 위험이 얼마나 줄었는지가 투자 근거가 됩니다. 이 시각에서 보면, 모의해킹 계획은 기술 검증 이전에 경영진이 이해할 수 있는 위험 수준과 개선 지표를 함께 정의하는 과정이기도 합니다. 이를 반영해 계획 수립 시 발견 취약점을 사업 영향 심각도로 분류하고 조치 후 재측정 기준을 포함하는 방식을 제안했습니다.
이 관점이 이후 보안 활동을 계획할 때 기술 목표와 함께 경영진 보고 구조를 미리 설계하는 습관을 만들었습니다. 모의해킹 계획의 완성은 취약점 발견만큼 경영진이 판단할 수 있는 위험 지표 정의에 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.