Pingbo는 처리해야 할 메일을 어떻게 가려낼까요

Pingbo의 역할은 받은편지함에서 정말 중요한 메일을 찾아 알려 주고, 나머지는 그대로 두는 것입니다. 말로는 간단하지만, 제대로 판단하기는 쉽지 않습니다.

Pingbo의 다른 기능도 이 판단이 맞아야 의미가 있습니다. 답장이 필요한 메일이어야 미리 작성한 초안이 쓸모 있고, 실제로 상대의 답을 기다리고 있어야 후속 확인 일정도 필요합니다. 꼭 봐야 할 메일을 빠뜨리면 중요한 일을 놓칩니다. 반대로 불필요한 메일까지 보여 주면, 결국 일반 메일 앱처럼 하나씩 확인해야 합니다. 그래서 저희는 이 판단이 얼마나 정확할 수 있는지를 가장 먼저, 가장 엄격하게 검증합니다.

이 글에서는 저희의 측정 방법과 결과를 모두 공개합니다. 이 글에 나오는 모든 수치와 각 모델이 메일마다 내놓은 답, 그리고 그 수치를 다시 계산하는 코드는 pingbo-bench에 공개해 두었습니다.

메일 분류는 스팸을 걸러 내는 데서 시작했습니다

컴퓨터가 처음 맡은 이메일 업무는 일부를 버리는 일이었습니다. 1997년 Microsoft Research의 한 팀이 베이즈 방법으로 스팸 필터를 개발하기 시작했고, 1998년 A Bayesian Approach to Filtering Junk E-Mail을 발표했습니다. 원리는 간단합니다. 각 단어가 스팸과 일반 메일에 나타나는 빈도를 구한 뒤, 새 메일에 들어 있는 단어별 확률비를 곱합니다. ‘무료’, ‘당첨’은 스팸일 가능성을 높이고, ‘회의’, ‘안건’은 일반 메일일 가능성을 높입니다. 2002년 Paul Graham이 공개한 A Plan for Spam은 개발자가 자기 메일함으로 오후 한나절이면 학습시킬 수 있는 방법으로 널리 알려졌습니다.

하지만 스팸 발송자도 어떤 단어가 걸리는지 알게 되면서, 단어만 세는 방식으로는 부족해졌습니다. Gmail은 고정된 규칙에서 데이터를 학습하는 모델로 전환했습니다. 2019년에는 대형 모델로 본문 밖의 정보까지 분석했습니다. 누가 어디서 보냈는지, 발신자 신원이 확인됐는지, 같은 메일이 수십억 개의 받은편지함에서 어떻게 처리됐는지, 사용자가 어떤 메일을 스팸으로 신고했는지 등을 살폈습니다. Gmail이 스팸의 99.9% 이상을 차단하는 방식입니다. 방법은 달라졌지만, 질문은 같았습니다. 이 메일이 스팸인지 판단하는 것입니다.

스팸을 거른 뒤 메일을 보여 주는 방식은 크게 달라지지 않았습니다. Gmail, Outlook, Yahoo는 여전히 대화를 각각 나누고, 최신 대화를 맨 위에 놓습니다. 받은편지함은 어떤 메일을 열었는지는 알지만, 어떤 일을 끝냈는지, 누구를 기다리는지, 무엇을 더 해야 하는지는 모릅니다. 하나의 일이 다섯 개의 대화에 걸쳐 3주 동안 이어지면, 그 관계를 기억하고 연결하는 일은 사용자 몫입니다. Pingbo는 계약 갱신, 채용, 분쟁 해결처럼 같은 일에 속한 대화를 하나의 안건으로 묶습니다. 관련된 사람, 약속, 기한, 다음 할 일도 함께 기록해 업무가 끝날 때까지 이어 갑니다.

Pingbo가 판단하는 것은 이 안건에 사용자의 대응이 필요한지, 필요하다면 무엇을 해야 하는지입니다. 발신자가 직접 쓴 요청과, 지금 누가 행동해야 하는지를 읽어야 알 수 있습니다. ‘부탁’, ‘승인’이라는 단어를 찾는 것만으로는, 직접 승인을 요청한 메일인지 참고하라고 전달한 메일인지 구분할 수 없습니다. 언어 모델은 이런 뜻을 읽을 수 있습니다. 다만 자유롭게 답하게 하면 하나의 의견을 돌려줄 뿐입니다. 제품에 쓰려면 그 의견을 근거가 분명한 판단으로 바꿔야 합니다.

판단이 정해지면 다음 할 일이 정해집니다

이 판단은 개별 메일이 아니라 안건을 기준으로 합니다. Pingbo가 대화를 읽기 전에 Gmail이 이미 스팸을 걸러 냅니다. Pingbo는 남은 업무를 안건으로 모으고, 진행 중인 안건을 두 영역에 나눠 놓습니다. 어느 영역에 들어가느냐에 따라 이후 처리가 달라집니다.

확인 필요에는 아직 직접 해야 할 일이 모입니다. 카드에는 어떤 대응이 필요한지도 표시됩니다. 답장 필요는 답해야 할 질문이 있다는 뜻입니다. 카드를 열기 전에 초안이 준비되므로, 검토해서 보내거나 수정할 수 있고, 먼저 Pingbo와 상의할 수도 있습니다. 조치 필요는 양식 제출이나 청구서 승인처럼 답장 이외의 일이 필요하다는 뜻이며, 카드에 구체적인 할 일이 적힙니다. 보드를 확인할 때면 밤사이 진행된 내용이 정리되어 있고, 답장도 준비되어 있습니다.

대기 중에는 진행 중이지만 오늘 직접 처리할 필요는 없는 업무가 들어갑니다. 상대의 답을 기다리거나, 경과만 지켜보면 되는 경우입니다. Pingbo는 후속 확인이 필요한지 판단해 날짜를 정하고, 그 일정에 맞춰 다시 알려 줍니다. 날짜가 되면 대화 기록을 바탕으로 누구에게 무엇을 확인할지 적힌 카드가 다시 나타납니다. 지금 후속 조치를 선택하거나 아직을 눌러 더 기다릴 수 있습니다.

안건을 완료로 표시하면 보드에서 빠집니다. Pingbo는 근거가 되는 메일을 첨부해 완료를 제안할 뿐입니다. 받아들일지 거절할지는 사용자가 결정하며, 시스템이 임의로 종료하지 않습니다.

업무가 아닌 메일도 별도로 정리해 보드에 올리지 않습니다. 선별됨에는 별다른 행동이 필요 없는 대량 발송 메일, 자동 알림, 참고 자료가 들어갑니다. 영수증, 알림, 읽지 않는 메일링 리스트도 삭제하지 않고 보관하므로 검색할 수 있습니다. 읽기에는 뉴스레터, 진행 상황 공유, 공지처럼 한 번 읽으면 되고 추가 대응은 필요 없는 메일이 모입니다.

이런 판단을 위해 모델은 정해진 양식에 순서대로 답합니다. 각 답변은 다음에 선택할 수 있는 항목을 제한합니다. 먼저 지금 행동할 사람이 사용자인지 상대인지 판단한 뒤, 안건을 어느 영역에 둘지 정합니다. 그다음 앞서 소개한 네 가지 상태 중 하나를 선택합니다. 답장해야 하면 초안을 첨부해 답장 필요, 다른 일을 해야 하면 조치 필요, 상대를 기다리면 대기 중으로 분류합니다. 대화가 끝났다면 완료를 제안하고 사용자의 결정을 기다립니다. 답장이 필요하다고 판단할 때는, 실제로 답장을 요청한 문장을 메일에서 인용해야 합니다.

이 과정을 거쳐야 모델의 답변으로 업무를 정리하고, 초안을 쓰고, 다음 할 일을 준비할 수 있습니다. 하지만 판단할 항목이 늘면 틀릴 수 있는 지점도 늘어납니다. ‘예’ 또는 ‘아니요’만 답할 때보다 어려워지는 만큼, 모델의 답을 그대로 믿지 않고 실제 성능을 측정해야 했습니다.

무엇을 기준으로 평가했을까요

평가에는 실제 업무 메일 508통을 사용합니다. Sappelli 외(2016), Information Sciences의 연구 데이터에 Enron 메일 아카이브를 연결해 본문을 확보했습니다. 원래 연구에서는 두 평가자가 1,145통을 읽고 각 메일이 수신자에게 무엇을 요구하는지 기록했습니다. 저희는 두 사람의 판단이 일치한 508통만 채택했습니다. 주의 깊게 읽은 두 사람도 합의하지 못한 메일을 다른 답변의 채점 기준으로 삼을 수는 없기 때문입니다.

원래 분류는 네 가지입니다. 112통은 즉시 답장 필요, 67통은 나중에 답장 필요로, 오늘은 아니어도 답해야 하는 메일입니다. 285통은 답장은 필요 없지만 내용을 알아 둘 책임이 있는 메일이었고, 44통은 무시해도 되는 메일이었습니다. Pingbo가 판단할 것은 어떤 일이 사용자의 주의를 필요로 하는지입니다. 그래서 앞의 두 분류를 확인 필요로 묶고, 내용을 알아 둘 책임이 있는 메일은 대기 중에 대응시켰습니다. 무시해도 되는 메일은 Pingbo에서는 선별됨이 보드 밖에 붙들어 둡니다. 이번 평가에서 채점하는 것은 답장이 필요한지 아닌지, 이 한 가지뿐입니다. 그래서 112 + 67 = 답장이 필요한 179통, 285 + 44 = 답장이 필요 없는 329통입니다.

이 비율이 가장 기본적인 비교 기준입니다. 508통 모두에 ‘답장 불필요’라고 답하면 329통은 맞히지만, 답장해야 할 179통은 모두 놓칩니다. 한 글자도 읽지 않아도 **329 ÷ 508 = 64.8%**의 정확도를 얻는 셈입니다. 이보다 낮으면 아무것도 하지 않는 것보다 못합니다.

정확도는 전체 판단 중 맞힌 비율이지만, 어떤 실수를 했는지까지 알려 주지는 않습니다. 두 시스템이 똑같이 508통 중 406통을 맞혀 80%를 기록했다고 가정해 보겠습니다. 하나는 답장해야 할 179통 중 77통을 찾고, 불필요한 메일은 하나도 표시하지 않습니다. 다른 하나는 160통을 찾는 대신 불필요한 메일 83통도 표시합니다. 점수는 같지만, 놓친 메일은 각각 102통과 19통으로 크게 다릅니다. 그래서 세 지표를 함께 공개합니다. 정확도는 전체적으로 얼마나 맞혔는지, 재현율은 답장해야 할 메일을 얼마나 찾았는지, 정밀도는 보여 준 메일 중 실제 답장이 필요한 비율을 나타냅니다.

이 기준으로 평가한 모델은 세 가지 질문에 답하기 위해 고른 32개입니다. OpenAI의 16개와 Anthropic의 11개로는 선도 모델의 성능을 확인합니다. 가중치가 공개된 Qwen3.6은 자체 하드웨어에서 실행해, 외부 모델을 빌리지 않고 Pingbo가 어디까지 할 수 있는지 살펴봅니다. 나머지 소형 모델 네 개로는 이 일을 휴대전화가 어디까지 맡을 수 있는지 봅니다. Gemma와 두 버전의 Ornith는 언젠가 휴대전화에서도 실행할 수 있을 만큼 작습니다. Apple의 온디바이스 모델은 iOS 26과 macOS 26에서 Apple Intelligence를 구동하는 모델로, 최근 iPhone에는 이미 탑재되어 있습니다. Qwen3.6과 이 네 모델, 모두 다섯 개는 저희 장비에서 실행했기 때문에 그래프에서는 자체 운영으로 묶었습니다. 32개 모두 같은 508통을 평가했습니다.

다만 이 데이터셋은 Pingbo를 위해 만든 것이 아니므로, 수치를 믿기 전에 데이터셋 자체를 먼저 검증했습니다. 두 평가자의 판단은 네 가지 분류에서 가장 많이 엇갈렸고, Pingbo 채점에 쓰는 두 가지 선택은 수신자가 실제로 답장했는지와 잘 맞았습니다. 다시 채점한 100통 가운데 24통에서는 세 번째 평가자가 답장이 필요한지를 데이터셋과 다르게 봤습니다. 평가 방법은 글 끝의 부록에서 자세히 설명합니다.

단순한 프롬프트에서 완전한 제품 프레임워크로

Pingbo에는 모델뿐 아니라 저희가 직접 만든 실행 프레임워크가 있습니다. 앞서 설명한 양식, 답변 검증, 결과를 화면에 보여 주기 전의 처리 코드가 여기에 포함됩니다. 이 과정이 모델의 성능을 높일 수도, 낮출 수도 있으므로 측정해서 확인해야 합니다. 그래서 변경할 때마다 같은 508통을 32개 모델 모두로 다시 평가했습니다. 다른 조건은 그대로 두었으므로, 점수가 달라졌다면 메일이 바뀌어서가 아니라 저희가 고친 부분 때문입니다. 다만 각 단계는 한 번씩만 실행한 결과이고, 같은 모델도 실행할 때마다 답이 조금씩 달라지므로 메일 한두 통 차이는 큰 의미가 없습니다. 그림 2는 그 전체 기록입니다.

OpenAI 16

• gpt-5.6-luna
• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.5
• gpt-5.4
• gpt-5.4-mini
• gpt-5.4-nano
• gpt-5.2
• gpt-5.1
• gpt-5
• gpt-5-mini
• gpt-5-nano
• gpt-4.1
• gpt-4.1-mini
• gpt-4.1-nano
• gpt-4o-mini

Anthropic 11

• claude-opus-5
• claude-opus-4-8
• claude-opus-4-7
• claude-opus-4-6
• claude-opus-4-5-20251101
• claude-fable-5-1
• claude-fable-5
• claude-sonnet-5
• claude-sonnet-4-6
• claude-sonnet-4-5-20250929
• claude-haiku-4-5-20251001

자체 운영 5

• qwen3.6-35b-a3b-mxfp4
• ornith-1.5-9b-mlx-full
• ornith-1.5-9b-mlx-6bit
• gemma-4-E4B-it-qat-4bit
• apple-fm-on-device

0단계에서는 프레임워크 없이 각 모델에 메일을 그대로 보여 주고 물었습니다. 모델은 메일 한 통을 읽고 평가자가 사용한 네 가지 분류 중 하나를 고르며, 저희는 그 답이 답장이 필요하다는 뜻인지로, 이 글의 다른 수치와 같은 방식으로 채점했습니다. 32개 모델의 성적을 순서대로 놓았을 때 중앙값은 77.0%로, 절반이 이보다 높았습니다. 비교 기준을 넘은 모델은 29개였습니다. 모델 자체로도 판단의 상당 부분을 할 수 있다는 뜻입니다. 하지만 분류 하나만으로는 누구에게 다시 연락할지 정하거나, 답장 초안을 만들거나, 보드에 다음 할 일을 준비할 수 없습니다.

1단계에서 처음으로 양식 전체를 채우게 하자 성적이 오히려 떨어졌습니다. 모든 항목에 답하려다 보니, 모델이 원래 없던 일을 만들어 내기 시작했습니다. 예를 들어 동료가 수정본만 보냈는데, 아무 요청도 없는 메일에 ‘피드백이나 승인 답장 보내기’를 제안했습니다. 중앙값은 65.0%로 내려가 비교 기준과 거의 같아졌고, 기준을 넘은 모델은 17개뿐이었습니다. 직접 질문했을 때와 비교하면 32개 중 28개의 성능이 나빠졌습니다. 저희가 만든 처리 과정이 문제였습니다.

2단계에서는 이 문제를 수정했습니다. 답장이 필요하다고 판단하려면, 답장을 요청한 문장을 인용하도록 했습니다. 프로그램도 그 문장이 메일 본문에 실제로 있는지 확인합니다. 인용문을 찾지 못하면 답장이 필요하다고 판정할 수 없습니다. 중앙값은 81.3%로 올랐고, 24개 모델이 비교 기준을 넘었습니다. 프레임워크 안에서 직접 질문했을 때 못지않은 성적을 낸 모델이 32개 중 23개로, 처음으로 절반을 넘었습니다.

3단계의 수정은 2단계에서 받아들인 인용문을 다시 읽으면서 시작됐습니다. 그중 5분의 1은 새로 온 메일이 아니라, 아래에 첨부된 이전 대화에서 가져온 문장이었습니다. 발신자가 과거에 받은 질문에 답하고 있는데, 시스템은 그 옛 질문을 지금 사용자에게 하는 요청으로 오해했습니다. 끝인사나, 할 일에는 추가해야 하지만 답장은 필요 없는 업무 인계도 답장 요청으로 잘못 분류했습니다. 그래서 요청은 현재 메일에서 발신자가 직접 쓴 내용이어야 한다는 조건을 추가했습니다. 중앙값은 82.5%, 비교 기준을 넘은 모델은 27개, 최고 점수는 85.0%였습니다. 32개 중 25개가 프레임워크 안에서 더 좋은 성능을 냈습니다.

3단계는 사용자에게 가장 의미 있는 개선이지만, 그림 2에서는 크게 눈에 띄지 않습니다. 자체 하드웨어에서 실행하는 모델의 성적이 6.3%포인트 올라, 다른 모델과의 격차가 7.9%포인트에서 2.8%포인트로 줄었습니다. 판단의 품질은 모델뿐 아니라 Pingbo의 처리 방식에서도 나옵니다. 기반 모델을 바꾸더라도 이 개선은 남으므로, 그때그때 가장 뛰어난 모델에만 의존하지 않아도 됩니다.

대가도 있었습니다. 다만 그 대가는 수치 하나로 짐작하는 것과 다릅니다. 같은 모델에서 답장해야 할 메일 가운데 답장 필요 카드로 올라온 비율은 68.2%에서 62.0%로 떨어졌고, 답장 필요 카드 가운데 실제로 답장이 필요했던 비율은 61.6%에서 76.6%로 올랐습니다. 그렇게 답장 필요 카드로 올라오지 못한 19통 가운데 18통은 조치 필요 카드가 되어 목록에 그대로 남았습니다. 그래서 대기 중까지 간 메일은 13통에서 10통으로 줄었습니다. 매번 세 지표를 다시 측정하는 이유는 무엇이 좋아지고 무엇을 잃었는지 확인하기 위해서입니다. 모든 모델에 도움이 되는 것도 아닙니다. 32개 중 일곱 개는 직접 질문했을 때 더 잘했고, 대부분 크기가 가장 작거나 가장 많이 압축한 모델이었습니다. Pingbo가 모델을 고를 때 가격만 보지 않고 비용과 실측 성능을 함께 저울질하는 이유입니다. 이 한계를 가장 분명하게 보여 준 것은 Apple의 온디바이스 모델입니다. 직접 질문하면 70.1%로 비교 기준을 넘지만, 프레임워크 안에서는 모든 단계에서 비교 기준에 못 미쳤습니다. 3단계에서 이 모델이 Pingbo의 지시문과 함께 한 번에 읽을 수 있는 분량은 4,096개 토큰, 영어 단어로 약 3,000개입니다. 508통 중 153통은 이 안에 들어가지 않았습니다. 나머지 355통 중 306통에서는 메일을 어디에 둘지 처음 내린 판단이 규칙에 맞지 않아 거부됐습니다. 안건이 된 메일은 한 통도 없었고, 답장 초안도 전혀 만들지 못했습니다. 프레임워크가 모델을 도우려면, 먼저 모델이 그 프레임워크를 감당할 수 있어야 합니다.

Pingbo가 현재 사용하는 것은 3단계의 처리 과정입니다. 그다음은 단계를 더하는 문제가 아니라, 이 과정을 어떤 설정으로 사용할지 선택하는 문제입니다.

메일을 놓칠까요, 방해를 줄일까요

같은 처리 과정도 불필요한 알림을 줄이는 쪽으로, 또는 필요한 메일을 최대한 찾는 쪽으로 설정할 수 있습니다. 그림 3은 각 모델을 설정별로 측정한 결과입니다.

OpenAI 16

• gpt-5.6-luna
• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.5
• gpt-5.4
• gpt-5.4-mini
• gpt-5.4-nano
• gpt-5.2
• gpt-5.1
• gpt-5
• gpt-5-mini
• gpt-5-nano
• gpt-4.1
• gpt-4.1-mini
• gpt-4.1-nano
• gpt-4o-mini

Anthropic 11

• claude-opus-5
• claude-opus-4-8
• claude-opus-4-7
• claude-opus-4-6
• claude-opus-4-5-20251101
• claude-fable-5-1
• claude-fable-5
• claude-sonnet-5
• claude-sonnet-4-6
• claude-sonnet-4-5-20250929
• claude-haiku-4-5-20251001

자체 운영 5

• qwen3.6-35b-a3b-mxfp4
• ornith-1.5-9b-mlx-full
• ornith-1.5-9b-mlx-6bit
• gemma-4-E4B-it-qat-4bit
• apple-fm-on-device

표 1의 첫 번째 행은 답장 필요 카드만 표시합니다. 두 번째 행은 조치 필요 카드도 포함하며, 이것이 Pingbo의 기본 설정입니다. 세 번째 행에서는 각 안건을 한 번 더 읽고, 첫 번째 결과와 독립적으로 판단합니다.

두 평가자가 기록한 것은 메일에 답장이 필요한지입니다. 확인 필요는 이보다 범위가 넓어서, 다른 행동을 요청한 메일도 포함하지만 데이터셋에는 그 구분이 없습니다. 두 번째 행은 241통, 첫 번째 행은 133통을 보여 주므로 108통이 늘어납니다. 이 중 31통은 두 평가자 모두 답장이 필요하다고 본 메일이어서, 찾아낸 수가 119통에서 150통으로 늘어납니다. 나머지 77통은 채점할 때 오류로 계산됩니다. 그렇다고 Pingbo가 표시하지 말았어야 한다고 단정할 수는 없습니다. 데이터셋에 ‘행동이 필요한 메일’이라는 표시가 없기 때문입니다. 그중에는 확인 필요에 들어가야 할 실제 업무도 있고, 진짜 오판도 있습니다. 기존 기록으로는 둘을 나눌 수 없으므로, 어느 쪽이라고 주장하지 않습니다. 정밀도가 89%에서 62%로 떨어지는 것은 이 77통이 더해졌기 때문입니다.

Pingbo가 목록에 올리지 않는 메일도 수치로 확인해야 합니다. 표 1 가운데 행인 Pingbo의 기본 설정에서 gpt-5.5는 241통을 표시하므로, 나머지 267통은 확인 필요에 들어가지 않습니다. 답장해야 할 179통 중 150통을 찾았으니, 29통은 답장이 필요한데도 목록에서 빠졌고, 나머지 238통은 답장이 필요 없다고 기록된 메일입니다. 앞으로 해야 할 일은 이 29통을 줄이는 것입니다.

이 267통이 모두 한 영역으로 가는 것도 아니고, 평가 기록이 그 메일들에 아무것도 필요 없었다고 말하는 것도 아닙니다. Pingbo는 이 가운데 46통을 대기 중에, 124통을 완료에 넣습니다. 95통은 애초에 안건이 되지 않아 읽기나 선별됨에 남고, 두 통은 모델 호출이 실패한 경우입니다. 평가자가 기록한 것은 답장이 필요한지 하나뿐입니다. 그래서 그 메일들이 여전히 사용자에게 무언가를 요구하고 있는지는 여기의 어떤 수치로도 알 수 없습니다.

이 모델과 이 설정에서는 두 지표를 동시에 가장 좋게 만들 수는 없습니다. 필요한 메일을 더 많이 찾으려면 불필요한 메일도 더 보여 주게 되고, 어디서 균형을 잡을지는 숫자만으로 정할 수 없습니다. 다만 이것이 법칙은 아닙니다. 한 번 더 읽는 판단을 더하면 32개 모델 중 다섯 개는 두 지표가 함께 좋아지며, claude-opus-5도 그중 하나입니다. 이 모델들에서는 한 번 더 읽는 과정이 앞 단계에서 빠뜨린 메일을 찾아내면서도 목록은 그만큼 넓히지 않기 때문입니다. 두 실수의 비용도 다릅니다. 필요한 메일을 놓치면 상대는 답장을 기다리는데, 사용자는 그 사실조차 모를 수 있습니다. 불필요한 메일을 하나 더 보여 주는 경우에는, 대개 확인하는 데 1초 정도가 들 뿐입니다.

지금 Pingbo가 할 수 있는 일

이번 평가에서는 답장이 필요한 메일 가운데 Pingbo가 찾아낸 수와 확인 필요에 올리지 않은 수를 집계했습니다. 이 508통의 메일은 다수에게 맞는 기준을 찾는 데 도움이 되지만, 사용자 개개인에게 무엇이 맞는지까지 알려 주지는 못합니다. 예를 들어 스타트업 창업자는 투자자가 보낸 답장이라면 아무리 짧아도 놓치고 싶지 않을 수 있습니다. 반면 하루 종일 참조 메일을 받는 회사 관리자는 본인이 직접 처리해야 할 소수의 메일만 보고 싶을 수 있습니다. 하나의 기준으로 두 요구를 모두 충족할 수는 없습니다.

부록에서 자세히 설명하듯, 데이터셋 자체에도 한계가 있습니다. ‘답장이 필요한가’라는 단순한 질문에서도 두 평가자의 일치율은 70%였습니다. 어느 수준을 넘으면 점수를 더 높이는 것이 Pingbo를 개선하기보다 평가 라벨에 맞추는 일이 될 수 있습니다. 실제 메일에서는 상황이 더 복잡한 경우가 많습니다. 대화는 길어지고, 참여자는 많아지며, 요청은 전달된 메일 속에 숨어 있기도 합니다. 저희는 사용자 각자의 기준에서 99.99% 올바른 판단을 내리는 Pingbo를 목표로 합니다. 데이터셋을 아무리 꼼꼼하게 검증하고 새로운 데이터셋을 더 모아도, 표준 데이터셋만으로는 이 목표에 도달할 수 없습니다.

자기 메일을 어떻게 처리해야 하는지 아는 사람은 사용자 본인입니다. 그래서 Pingbo가 사용자마다 기준을 세우고, 사용하면서 계속 조정하도록 만들고 있습니다. 처음 설정할 때 몇 가지를 묻고, 그다음에는 실제 행동에서 배웁니다. 확인 필요에 올리지 않은 메일에 답장한다면, 그 메일을 어디에 두었든 Pingbo가 읽어 낼 수 있는 신호입니다. 다만 판단이 틀렸다는 증거는 아닙니다. 답장이 늘 필요한 것은 아니기 때문입니다. 확인 필요에서 답장 없이 빼낸 메일도 또 하나의 신호일 뿐, 더 확실하지는 않습니다. 그 메일이 요청한 일을 이미 처리했을 수도 있기 때문입니다. 이런 신호들을 모아 시간을 두고 함께 읽어 가면서 기준이 사용자에게 맞게 움직입니다. 그래서 표 1의 선택은 모두에게 같은 기본값이 아니라, 각 사용자에게 맞춰 계속 달라지는 판단이 됩니다.

Pingbo는 사용자가 무엇을 중요하게 여기는지 배우며 계속 적응하는 에이전트입니다. 대응이 필요하다고 할 때는 발신자의 원문을 근거로 누가 무엇을 요청했는지, 왜 처리해야 하는지 알려 주고 답장 내용도 미리 준비합니다. 지금 처리하지 않아도 된다고 알려 주는 일은 안심하고 잠시 미뤄 둘 수 있습니다. 그러면 정말 신경 써야 할 일에 시간과 에너지를 쏟을 수 있습니다.

부록: 이 평가를 얼마나 믿을 수 있을까

Sappelli 연구진의 데이터셋은 Pingbo를 위해 만든 것이 아닙니다. 이 데이터셋은 메일을 네 가지로 나누지만, Pingbo는 메일을 확인 필요와 대기 중 가운데 어디에 둘지 판단합니다. 이 글의 모든 수치는 이 데이터셋을 기준으로 하므로, Pingbo를 평가하는 데 쓰기 전에 두 가지를 확인해야 했습니다. 네 가지 분류의 정답을 어디까지 믿을 수 있는지, 그리고 Pingbo를 채점하는 두 가지 선택은 그에 비해 어떤지입니다. 두 사람이 같은 답을 냈다고 해서 반드시 맞는 것은 아닙니다. 원래 네 가지 분류에서는 1,145통 중 508통, 즉 44%만 판단이 일치했습니다. 판단이 엇갈린 메일에서는 세 번째 평가자도 대체로 그 분류의 손을 들어 주지 않았습니다. 두 가지 선택으로 물으면 같은 두 사람의 판단이 훨씬 자주 일치했고, 그 답은 수신자가 실제로 답장했는지와도 맞아떨어졌습니다. 다만 두 검증 모두 메일 한 통 한 통에서 어느 답이 옳은지는 말해 주지 않습니다. 어떻게 확인했는지는 아래에서 설명합니다.

초기 결과에서 의문이 든 것은 모델이 틀리는 방식이었습니다. 32개 모델에 원래 네 가지 분류로 508통을 나누게 했습니다. 데이터셋의 답에 가장 가까운 여덟 모델을 두 개씩 짝지어 비교하면 답이 평균 78% 일치했지만, 각 모델이 데이터셋의 답과 일치한 비율은 평균 63%에 그쳤습니다. 단순히 모델의 능력이 부족하다면 실수도 제각각이어서, 다른 모델이나 평가자와 비슷한 정도로 답이 달라야 합니다. 그런데 이 모델들은 평가자가 틀렸다고 한 답에 반복해서 함께 도달했습니다. 모델들의 답이 일치한다고 해서 그 답이 맞다는 증거가 되지는 않습니다. 같은 실수를 함께 저질렀을 수도 있기 때문입니다. 다만 표준으로 삼은 답을 다시 읽어 볼 이유로는 충분했습니다.

그래서 여덟 모델 모두 데이터셋과 다르게 답한 메일 57통을 골라, 답의 출처를 가린 채 다시 평가했습니다. 모델과 데이터셋의 답이 처음부터 같았던 43통도 대조용으로 섞었습니다. 채점 역할을 맡은 모델 역시 32개 중 하나입니다. 이 43통은 채점 모델이 아무렇게나 답하지 않고 채점 자료를 실제로 읽었다는 것을 보여 줍니다. 다만 43통에서는 모델과 데이터셋의 답이 같으므로, 채점 모델이 그저 모델 쪽 손을 들어 준 것은 아니라는 점까지는 보여 주지 못합니다. 100통을 모두 채점할 때까지 답의 출처는 공개하지 않았습니다. 그림 A1이 그 결과입니다.

의견이 갈린 메일에서 채점 모델은 45번 모델의 답을, 5번 데이터셋의 답을 택했고, 7번은 어느 쪽도 택하지 않았습니다. 처음부터 일치했던 43통에서는 모두 데이터셋과 같은 판단을 했습니다. 공정한 동전을 50번 던져 45 대 5처럼, 또는 그보다 더 한쪽으로 치우친 결과가 나올 확률은 약 2억 4천만 번에 한 번입니다. 통계에서는 이런 확률을 p값이라고 합니다. 이번 이항 검정의 결과는 4.2e-9로, 흔히 쓰는 기준인 0.05보다 훨씬 작았습니다. 짚어 둘 점이 두 가지 있습니다. 먼저 이 57통은 의견 차이가 가장 큰 사례를 고른 것이지, 무작위 표본은 아닙니다. 그래서 이 결과가 보여 주는 것은 모델과 데이터셋의 판단이 가장 크게 갈리는 지점일 뿐, 나머지 메일에서 어느 쪽이 얼마나 자주 틀리는지도, 둘 중 어느 쪽이 옳은지도 말해 주지 않습니다. 또 채점 자료에는 긴 메일이 4,000자까지만 실리는데, 100통 중 여섯 통이 여기에 걸렸습니다. 이 여섯 통에서는 채점 모델이 다른 모델들보다 적게 읽은 셈입니다.

데이터셋 전체가 쓸모없다는 뜻은 아닙니다. 네 가지로 나누는 기준에서는 평가자들도 합의하기 어려웠던 것입니다. 두 사람이 모두 분류를 남긴 메일은 1,145통 중 1,115통이고, 그중 607통에서 의견이 달랐습니다. 138통은 둘 다 답장이 필요하다고 봤고, 지금 해야 하는지 나중에 해도 되는지만 달랐습니다. 134통은 둘 다 답장이 필요 없다고 봤지만, 읽을 필요가 있는지에 대한 판단이 달랐습니다. 이 272통은 분류가 달라도 답장의 필요 여부에는 이견이 없었습니다. 답장이 필요한지만 묻는 두 가지 선택으로 바꾸면, 같은 두 사람은 1,115통 중 780통, 즉 70%에서 판단이 일치합니다.

하지만 두 사람의 의견이 같다고 해서 반드시 맞는 것은 아닙니다. 그래서 두 가지 선택의 정답을 평가자의 판단과 무관한 사실과 비교했습니다. 수신자가 실제로 답장했는지입니다. Enron 아카이브에는 각 메일 이후에 오간 메일도 남아 있습니다. 수신자 중 한 사람이 30일 안에 보낸 메일 가운데 제목이 같거나 원래 메일을 인용한 메일을 답장으로 봤습니다. 다만 이것은 대략적인 기준입니다. 아카이브에는 어떤 메일이 어떤 메일의 답장인지에 대한 기록이 없어서 수신자가 메일을 다른 곳으로 전달한 경우도 답장으로 세고, 저희가 찾은 답장 115통 중 72통은 제목이 같다는 것만 근거로 합니다. 수신자 본인이 보낸 메일이 아카이브에 없다면 답장했는지 알 수 없으므로, 답장이 보이지 않아도 증거가 되지 않습니다. 그래서 먼저 아카이브의 직원 명단에 수신자가 들어 있는 209통만 셌습니다.

정답이 실제 답장과 아무 관계가 없다면, 답장이 필요하다고 표시된 메일과 그렇지 않은 메일이 답장을 받는 비율은 비슷해야 하고, 두 비율의 차이는 0에 가까워야 합니다. 실제로는 데이터셋이 답장이 필요하다고 한 메일의 51.8%가 답장을 받았고, 나머지는 24.8%로 차이가 26.9%포인트였습니다. 이 차이는 한정된 메일에서 추정한 값이므로 95% 신뢰구간으로 범위를 나타내면 12.342.1%포인트이고, 하한도 0보다 큽니다. 아카이브에서 한 번이라도 메일을 보낸 수신자까지 포함하면 491통이 되고, 차이는 14.3%포인트로 줄어듭니다. 신뢰구간은 6.222.4%포인트로, 하한 역시 0보다 큽니다. 즉, 답장이 필요하다고 표시된 메일은 실제로 답장을 더 자주 받았습니다. 이는 데이터셋 전체에서 나타나는 연관성일 뿐, 정답 하나하나가 맞다는 증거는 아닙니다.

세 번째 방법은 답장이 확인된 메일을 모두 더해 257통으로 세는 것이고, 이때 차이는 33.6%포인트까지 벌어집니다. 이 방법을 마지막에 두는 것은, 257통을 고르는 기준에 지금 검증하려는 답장 여부가 일부 섞여 있기 때문입니다. 같은 메일에서 여덟 모델의 다수결 답은 차이가 더 작아, 209통에서는 14.8%포인트, 257통에서는 23.0%포인트, 491통 전체에서는 5.5%포인트였습니다. 신뢰구간이 서로 겹칠 때는 어느 쪽 차이가 더 큰지 구간만으로는 가릴 수 없습니다. 그래서 메일 한 통 한 통에서 두 답을 짝지어 비교했습니다. 세 묶음 모두 데이터셋의 차이가 더 컸는데, 그 폭은 209통에서 12.1%포인트, 257통에서 10.6%포인트, 491통 전체에서 8.8%포인트였습니다. 이 폭도 추정한 값이므로 신뢰구간으로 나타내면 209통은 0.624.2%포인트, 257통은 0.321.2%포인트, 491통 전체는 3.0~14.7%포인트이고, 셋 다 하한이 0보다 큽니다. 다만 209통과 257통은 하한이 0을 간신히 넘는 수준입니다. 또한 연관성이 있다는 것이 매번 맞다는 뜻은 아닙니다. 정답은 발신자가 답장을 기대했다는 기록인데, 수신자는 바빠서 답장하지 않을 수도 있습니다. 그래서 답장이 없는 메일이라고 해서 정답이 틀렸다고 볼 수는 없습니다.

두 가지 선택의 정답에도 흠은 있습니다. 다시 채점한 100통 가운데 24통은 채점 모델의 답을 따르면 답장이 필요한지까지 바뀝니다. 같은 메일이 이 묶음에 두 번 이상 들어간 경우가 있어서, 이 24통은 저희가 채점하는 508건 가운데 26건, 즉 5.1%에 해당합니다. 다만 이 수치는 정답이 틀린 메일이 몇 통인지 추정한 값이 아니라, 저희가 의심스럽다고 확인한 메일을 센 것입니다. 100통은 의견이 갈린 메일을 골라 모은 것이고, 채점을 맡은 것 역시 또 하나의 모델이며, 나머지 395통은 다시 읽지 않았기 때문입니다. 이 24통이 말해 주는 것은, 이 데이터셋에서 최상위에 가까운 점수를 정확한 값으로 읽어서는 안 된다는 점입니다.

그렇다면 이 데이터셋을 측정 기준으로 삼아도 될까요? 네 가지 분류라면 안 됩니다. 이 글의 어떤 수치도 그 분류로 채점하지 않습니다. 이 분류에서는 두 평가자의 판단이 44%만 일치했고, 판단이 가장 크게 갈린 메일에서는 채점 모델이 45 대 5로 모델 쪽 답을 택했습니다. 반면 이 글의 모든 점수가 실제로 쓰는 두 가지 선택, 즉 답장이 필요한지를 묻는 질문에서는 검증 결과가 반대로 나왔습니다. 같은 두 사람의 판단이 70%에서 일치합니다. 그리고 그 답은 답장한 사람을 세는 세 가지 방법 모두에서 수신자가 실제로 답장했는지와 맞아떨어졌습니다. 게다가 여덟 모델의 다수결 답보다 더 가깝게 맞아떨어졌는데, 중요한 것이 바로 이 비교입니다. 모델보다 나을 것 없는 정답으로는 모델을 채점할 수 없기 때문입니다.

이 가운데 어느 것도 정답 하나하나가 맞다는 증거는 아니고, 여기서 한 검증으로는 그것을 보여 줄 수도 없습니다. 검증은 모두 간접적이고, 다시 채점한 100통은 의견이 갈린 메일을 골라 모은 것이며, 나머지 395통은 다시 읽지 않았기 때문입니다. 이 검증이 말해 주는 것은, 이 데이터셋을 측정에 쓸 만큼은 믿을 수 있다는 점입니다. 대신 메일 한 통 단위가 아니라 몇 통 단위로 읽어야 합니다. 저희가 채점하는 508건 가운데 26건이 의심스러운 이상, 다른 모델을 한두 통 차이로 앞선 모델은 앞선 것이 아닙니다. 이 글의 모든 수치는 이 기준으로 읽어야 합니다.