블랙박스를 거부하다 — 왜 모든 판정에 그 근거를 함께 싣는가
모든 보안팀이 아는 순간이 있습니다. 어떤 도구가 이메일을 악성으로 표시합니다. 분석가는 그 경고를 보고 유일하게 쓸모 있는 질문 — 왜? — 을 던지지만, 도구가 내놓는 답은 점수 하나뿐입니다. 그래서 분석가는 그 이메일을 처음부터, 손으로 다시 조사합니다. 일을 덜어주기로 되어 있던 그 판정을 믿어도 되는지 판단하기 위해서 말입니다.
우리는 일찌감치 WhiteMail은 이렇게 하지 않겠다고 결정했습니다. 그 결정이 제품 전체를 빚었습니다.
왜 블랙박스가 사라지지 않는가
대부분의 탐지 시스템은 근거 없이 결론만 출력합니다. "악성입니다", 숫자 하나, 잘해야 분류명 하나. 근거는 읽을 수 있는 형태로 존재하지 않거나, 구현 세부사항쯤으로 여겨집니다.
업계의 답은 설명 가능한 AI(xAI)였습니다. 주요 특징(feature)을 드러내고, 어떤 신호가 점수에 기여했는지 보여주는 식입니다. 아무것도 없는 것보다는 낫습니다. 하지만 가중치 붙은 특징 목록은 조사가 아닙니다. 그것은 모델이 무엇을 봤는지를 알려줄 뿐, 이 이메일에 실제로 무슨 일이 벌어지고 있는지를 말해주지 않습니다. 분석가는 그것을 동료에게, 혹은 임원에게 "무슨 일이 있었는지"에 대한 설명으로 건넬 수 없습니다.
우리가 대신 만든 것
WhiteHat는 전문가들 + 오케스트레이터 구조이기 때문에, 근거가 사후에 재구성되는 것이 아니라 그 자체가 결정입니다. 모든 판정에 대해 다음을 볼 수 있습니다.
- 이메일이 어떻게 분석됐는지 — 각 에이전트의 점수와 그가 제기한 구체적 신호(Reply-To 불일치, SPF 실패, 유사 도메인, 긴급 송금 요청).
- 어떤 맥락이 고려됐는지 — 발신자 이력과, 메일이 기대고 있는 관계.
- 결론에 이른 경로 — 디버그 로그가 아니라 분석가의 사건 기록처럼 읽히는, 한국어와 영어 양쪽으로 쓰인 평이한 서술.
서술이 이중언어인 것은 현지화 체크박스가 아닙니다. 하나의 판정은 SOC 분석가, 그 메일을 받은 재무 담당자, 그리고 대응을 최종 승인하는 임원 모두에게 신뢰받아야 합니다. 우리가 겨냥하는 팀들에서 이들은 모두 같은 언어로 일하지 않습니다. 설명은 각 언어에서 똑같이 일급(first-class)이어야 합니다.
그 아래에 깔린 원칙
핵심 전환은 "시스템을 믿어라" 에서 "시스템이 어떻게 판단했는지 보라" 로의 이동입니다. 근거가 판정과 함께 따라오면 세 가지가 뒤따릅니다. 신뢰가 올라가고, 오탐이 재조사 대신 몇 초 만에 해소되며, 모두가 같은 기록을 읽기 때문에 대응이 일관됩니다.
꿰뚫어 볼 수 없는 판정은 결국 다시 하게 됩니다. 그래서 우리는 조사 그 자체를 제품으로 만들었습니다. 판정은 그 머리기사일 뿐입니다.
분석 콘솔에서 아무 결과나 열어, 그 뒤에 있는 에이전트별 근거 전체를 읽어 보세요.