WhiteHat를 만들며 — 왜 하나의 모델이 아니라 네 명의 에이전트인가
AI 이메일 보안 제품이라면 누구나 초기에 던지는 당연한 질문이 있습니다. 그냥 이메일 한 통을 통째로 거대 모델에 넣고 "이거 악성이야?"라고 물어보면 되지 않나?
우리도 정확히 거기서 시작했습니다. 데모까지 가는 가장 빠른 길이니까요. 하지만 그것은 이 문제에 맞지 않는 형태였고, 그 이유들이 WhiteHat가 실제로 어떻게 작동해야 하는지를 가르쳐 줬습니다.
하나의 거대한 프롬프트가 놓치는 것
단일하고 통짜인 판단에는, 실제 운영에서 중요한 세 가지 실패 양상이 있습니다.
- 서로 전혀 다른 종류의 증거를 뭉갠다. SPF 통과 여부는 검증 가능한 사실입니다. 메일이 강압적으로 느껴지는지는 판단입니다. 표시이름이 도메인과 맞는지는 조회입니다. 이 모두를 구분 없는 하나의 프롬프트로 밀어 넣으면, 강한 신호와 약한 신호가 구분되지 않고 모델은 그것들을 죽처럼 평균 내버립니다.
- 스스로를 깔끔하게 설명하지 못한다. 답이 하나의 프롬프트에서 나온 하나의 숫자라면, "왜"는 사후에 지어낸 이야기일 뿐입니다. 결정적이었던 단계를 짚을 수 없습니다. 애초에 단계가 없었으니까요.
- 개선하기 어렵다. 무언가를 놓쳤을 때 고칠 컴포넌트가 없습니다. 프롬프트를 살짝 비트는 수밖에 없고, 그 과정에서 다른 것이 조용히 퇴행합니다.
효과가 있었던 형태: 전문가들 + 오케스트레이터
진짜 분석가는 문제 전체를 한 생각에 담지 않습니다. 서로 다른 종류의 작업을 차례로 거칩니다. 그래서 우리는 WhiteHat를 네 명의 전문가로 만들었고, 각자가 한 종류의 증거를 책임집니다.
- SA-01 · 신원(Identity) — 이 도메인에서 평소 누가 보내는가, 그리고 표시이름·Reply-To·Return-Path가 서로 맞는가?
- SA-02 · 인프라(Infrastructure) — SPF / DKIM / DMARC, 도메인 생성 시점과 신생 여부, 유사 도메인, 악용 TLD.
- SA-03 · 링크 & 비주얼(Links & Visual) — 표시 URL과 실제 URL의 불일치, 단축 URL, 리다이렉트 체인, 원시 IP URL, QR 코드 미끼.
- SA-04 · 의도(Intent) — 이 메일은 실제로 무엇을 요구하는가? 긴급 송금, 자격증명 탈취, 계좌 변경, 압박 전술.
각 에이전트는 한 가지에 날카롭고, 점수와 구체적인 신호를 함께 내놓습니다. 그다음 WhiteHat가 오케스트레이션합니다. 결과들을 대조하고 서로 견주어, 위험 점수와 이중언어 내러티브가 담긴 하나의 판정(허용 / 표시 / 차단)을 만듭니다.
이렇게 얻는 것은 정확도만이 아닙니다. 모든 판정이 사람이 읽고 신뢰할 수 있는 단계들로 분해된다는 점입니다. "왜"는 나중에 들려주는 이야기가 아니라, 결정 그 자체의 구조입니다.
이것이 앞으로 의미하는 것
작업을 이렇게 쪼개면, 다른 에이전트를 흔들지 않고 한 에이전트만 날카롭게 다듬을 수 있고, 공격이 진화함에 따라 새 전문가를 더해 갈 수 있습니다. 오케스트레이터는 그대로 두고, 전문가 명단만 늘려 가면 됩니다.
이것이 WhiteHat에 건 우리의 베팅입니다. 조사는 하나의 판단이 아닙니다. 여러 종류의 판단을 대조하는 일이며, 바로 그 점이 조사를 설명 가능하게 만듭니다.
WhiteMail의 모든 판정은 각 에이전트의 점수와 신호를 보여줍니다. 분석 콘솔에서 확인해 보세요.