이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
보안 리스크 평가를 수행할 때는 자산 식별부터 시작합니다. 어떤 자산을 보호할 것인지가 명확해야 이후 단계가 방향을 잃지 않습니다. 인턴 시절 내부 시스템 리스크 평가 작업을 보조하며, 정보 자산 목록표를 작성하는 것이 평가의 기반임을 배웠습니다. 두 번째로는 각 자산에 대한 위협과 취약점을 매핑합니다. 위협은 외부 공격자가 될 수 있고, 취약점은 패치가 안 된 소프트웨어일 수 있습니다.
두 가지가 맞물릴 때 실제 리스크가 됩니다. 세 번째로는 리스크의 발생 가능성과 영향도를 기준으로 우선순위를 매깁니다. 모든 리스크를 동시에 처리할 수 없기 때문에, 가장 큰 피해를 낳을 수 있는 것부터 통제 방안을 적용하는 것이 효율적입니다. 마지막으로 통제 조치 후 잔여 리스크를 재평가하는 것도 평가의 일부입니다.
리스크 평가에서 발생 가능성이 낮다고 판단해 낮은 우선순위로 분류했던 항목이 실제로 발생하면서 대응 비용이 컸던 경험이 있습니다. 가능성만 보고 영향도가 크다는 점을 충분히 반영하지 않은 것이었습니다. 이후에는 발생 가능성과 영향도를 2축으로 평가하고, 가능성이 낮아도 영향도가 높은 항목은 별도로 관리하는 방식으로 바꿨습니다. 가능성 낮음 + 영향도 높음 항목은 발생 시 대응 계획을 미리 만들어두는 것이 효율적이라는 것을 배웠습니다. 리스크 평가는 현재 위험도를 순위 매기는 것만이 아니라 발생 시 영향을 얼마나 빠르게 줄일 수 있는지도 함께 고려합니다.
이 경험이 이후 보안 리스크 평가 시 영향도 높은 저발생 항목을 별도 관리하는 기준이 됩니다. 보안 리스크 평가에서 발생 가능성이 낮은 항목이라도 영향도가 크면 대응 계획을 별도로 수립해야 리스크 관리가 완성된다는 원칙을 지킵니다.
보안 리스크 평가 결과를 공유했는데 팀마다 위험도에 대한 해석이 달라 우선순위 논의에서 시간이 많이 걸린 경험이 있습니다. '높음' 등급이 개발팀에게는 다음 분기 내 처리 수준으로 이해됐고, 보안팀에게는 즉시 조치 수준으로 인식됐습니다. 이후에는 리스크 등급에 처리 기한을 명시하는 방식으로 바꿨습니다. '높음 = 2주 이내', '중간 = 다음 스프린트 포함', '낮음 = 분기 내' 형태로 기준을 공유하니 등급 해석 논의가 없어지고 바로 행동으로 연결됐습니다. 리스크 평가는 기술적 판단만이 아니라 이해관계자가 같은 언어로 읽을 수 있어야 실행까지 이어집니다. 이 관점이 이후 리스크 평가 결과 작성 시 처리 기한 기준을 포함하는 기준이 됩니다. 보안 리스크 평가 결과가 행동으로 연결되려면 기술적 정확성만이 아니라 이해관계자가 동일하게 해석할 수 있는 공통 기준이 함께 정의돼야 한다는 원칙을 지킵니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 도루코 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.