매달 10일경이면 회계 팀에서 동일한 요청을 보냅니다. 각 고객사로부터 5개의 파일이 필요합니다: 은행 거래 내역서, 영수증 아카이브, 급여 보고서, 매출 요약서, 그리고 재고 문서입니다. 템플릿은 친절하고 정확하며 검증되었습니다. 고객의 이름을 부르며 인사를 건네고, 필요한 파일을 나열하며, 명확한 마감 기한을 제시합니다. 첫 번째 발송은 잘 작동합니다. 고객은 깔끔한 목록을 보고 응답합니다.

문제는 두 번째 이메일부터 시작됩니다.

한 고객사가 4개의 파일만 보냈다고 가정해 봅시다. 다섯 번째인 은행 거래 내역서는 도착하지 않았습니다. 영수증 아카이브는 도착했지만 해당 월이 틀려서 팀에서 반려했습니다. 급여 보고서는 사실 사흘 전에 Slack으로 전달되어 누군가 이미 처리했습니다. 재고 문서는 이 고객사에는 아예 해당되지 않는 사항인데, 이 사실은 첫 번째 메시지를 보낸 후에야 알게 되었습니다. 만약 원래의 템플릿을 다시 보낸다면, 또다시 5개의 파일을 요청하게 됩니다. 그중 4개의 요청은 이제 무의미합니다. 하나는 오히려 잘못된 정보를 제공합니다. 문구는 괜찮습니다. 이메일에 '기억력'이 없을 뿐입니다.

이메일 템플릿은 이름, 날짜, 지침을 처리하는 데 능숙합니다. 일회성 요청이라면 대개 그것으로 충분합니다. 한 사람이 메일을 보내고, 고객이 답장하면, 그 사람이 바로 업무를 마무리합니다. 히스토리는 한 사람의 머릿속과 하나의 편지함에 머뭅니다.

문제는 다음 메시지가 첫 번째 이메일 이후에 발생한 사건들에 의존할 때 시작됩니다. 템플릿은 여전히 원래의 목록을 보여줍니다. 어제 은행 거래 내역서가 도착했다는 사실을 알지 못합니다. 급여 보고서가 반려되었다는 사실도 모릅니다. 그 데이터는 편지함(어쩌면 여러 개의 편지함)에 들어있고, 리마인더를 생성하는 애플리케이션은 이를 읽을 방법이 없습니다.

'Open' 상태만으로는 부족할 때

전체 요청을 'open'과 같은 단일 상태로 추적하면 중요한 세부 사항을 놓치게 됩니다. 항목들은 독립적으로 움직입니다. 다음 커뮤니케이션이 정확하려면 각 항목마다 고유한 상태가 필요합니다.

  • Bank statement: 누락됨. 고객이 아직 보내지 않았습니다.
  • Receipt archive: 업로드되었으나 검토 전임. 내부 확인을 기다리며 폴더에 보관 중입니다.
  • Payroll report: 반려됨. 고객이 파일을 보냈으나 형식이 틀렸거나 해당 급여 기간이 아닙니다.
  • Sales report: 다른 채널을 통해 수신됨. Slack, 전화, 또는 우편을 통해 전달되었으며 팀에서 이미 기록했습니다.
  • Inventory document: 해당 없음. 이 고객사는 이를 제공할 필요가 없으며, 시스템은 더 이상 요청을 멈춰야 합니다.

이러한 세분화가 없다면 리마인더는 눈먼 상태가 됩니다. 누락된 파일과 반려된 파일을 똑같이 취급합니다. 이미 받은 파일을 마치 받지 못한 것처럼 취급합니다. 이는 고객의 시간을 낭비하고 신뢰를 깎아먹습니다. 관련 없는 리마인더가 두세 번 반복되면 고객은 대충 훑어보고는 시스템이 고장 났다고 생각하게 됩니다.

필요한 것만 구축하십시오

처음부터 거대한 규칙 엔진을 만들지 마십시오. 첫날부터 20개의 조건 분기가 있는 워크플로우 자동화가 필요한 것은 아닙니다. "고객의 조치가 여전히 필요한 것은 무엇인가?"라는 단 하나의 질문에 답할 수 있을 만큼의 데이터만 추적하는 것부터 시작하십시오.

요청된 각 항목에는 지속 가능한 결과(durable result)가 필요합니다. 즉, 애플리케이션이 다음 메시지를 작성할 때 읽을 수 있는 곳, 즉 이메일 스레드 외부의 기록이 있어야 한다는 뜻입니다. 이 기록이 복잡할 필요는 없습니다. 항목 이름, 현재 상태, 타임스탬프, 짧은 메모를 담은 구조화된 테이블 정도로도 충분합니다. 중요한 것은 데이터가 편지함 너머까지 살아남아야 한다는 점입니다.

이렇게 하면 이메일의 역할이 바뀝니다. 템플릿은 여전히 톤과 구조를 제어합니다. 인사는 따뜻하게 유지되고 지침은 명확합니다. 하지만 문서 목록은 요청 데이터에서 가져와야 합니다. 리마인더는 하나의 쿼리(query)가 됩니다. 고객의 조치가 필요한 항목만 보이도록 목록을 필터링합니다. 내부 검토를 기다리는 항목은 제외합니다. 이미 수락된 항목도 제외합니다.

업로드가 반려되었다면 리마인더에 그 이유를 설명해야 합니다. 고객이 단순히 보내는 것을 잊은 것처럼 일반적인 목록에 문서를 다시 슬그머니 올려두어서는 안 됩니다. 고객은 자신이 무언가를 업로드했다는 사실을 알고 있습니다. 그렇지 않은 척하는 것은 당신이 체계적이지 못하다는 인상을 줄 뿐입니다.

인수인계 테스트 (The Handoff Test)

이러한 추가 데이터 모델이 필요한지 확인하는 간단한 방법이 있습니다. 이렇게 물어보십시오.

다른 팀원이 전체 이메일 스레드를 읽지 않고도 이 요청을 넘겨받아 처리할 수 있는가?

단일 파일의 경우에는 답이 중요하지 않습니다. 하지만 여러 요소가 복잡하게 얽힌 매달 반복되는 요청의 경우에는 매우 중요합니다. 담당자가 휴가 중일 때, 동료가 무엇이 누락되었는지 몇 초 만에 파악할 수 있습니까? 관리자가 이메일 10통과 공유 폴더 3개를 열어보지 않고도 고객이 업무를 제때 처리했는지 알 수 있습니까? 만약 거절 사유가 서명과 전달 메시지 아래에 파묻힌 스레드의 네 번째 메시지에만 기록되어 있다면, 귀하의 시스템은 데이터베이스가 해야 할 일을 사람에게 강요하고 있는 것입니다.

템플릿은 메시지를 개선합니다. 추적 가능한 요청은 이력을 보존합니다. 하나는 말하는 방식을 다루고, 다른 하나는 알고 있는 정보를 다룹니다.

스크립트가 아닌 쿼리

항목 단위의 상태(item-level states)를 갖추게 되면, 이메일 생성은 스크립트 작성에서 쿼리 수행으로 전환됩니다. 이전에는 문단을 작성한 뒤 내용이 여전히 정확하기를 바랐습니다. 이제는 데이터에 질문합니다. "이 항목들 중 고객의 조치가 여전히 필요한 것은 무엇인가?" 여러분은 필터링된 목록을 바탕으로 리마인더를 작성합니다. 조치가 필요한 항목이 없다면 리마인더를 아예 보내지 않습니다. 만약 두 개의 항목에 조치가 필요하고 그중 하나가 특정 사유로 거절되었다면, 이메일은 해당 사실을 바탕으로 스스로 구성됩니다.

이