전달 메일 모델링: 원문 참조와 새 작업 요청을 분리하기

전달 메일을 업무로 바꾸는 도구를 만든다고 가정해 보겠습니다. 긴 원문 안에 새 담당자와 요청 사항을 덧붙여 저장하면, 고객이 실제로 말한 내용과 운영자가 나중에 해석한 내용이 섞이기 쉽습니다. 작은 설계 스케치에서는 둘을 처음부터 다른 값으로 다뤄볼 수 있습니다.

원문, 안내, 작업은 같은 데이터가 아닙니다

구분	담는 내용	바뀌는 계기
원문 참조	기존 메시지를 찾을 내부 식별자	참조할 메시지가 달라질 때
전달 안내	왜 이 대화를 공유하는지	맥락을 보완할 때
작업 요청	담당자·할 일·필요한 답	새 요청을 합의할 때

이 표는 특정 제품의 구현 설명이 아니라, 새 도구를 검토할 때 사용할 수 있는 모델 제안입니다. 전달 버튼을 누른 사실을 업무 수락이나 고객 승인으로 취급하지 않는 것이 출발점입니다.

원문 옆에 안내를 두는 타입 스케치

아래는 저장소나 메일 프로토콜을 포함하지 않은 TypeScript 형태의 예시입니다. 실서비스에 바로 넣을 수 있는 완성 코드가 아닙니다.

type ForwardBrief = {
  sourceRef: string; // 우리 시스템에서 원문을 찾는 참조
  context: string;
  request?: {
    owner: string;
    action: string;
    replyBy?: string; // 실제 확인된 기한만 입력
  };
  interpretation?: string; // 원문 인용과 분리한 운영자 메모
};

const brief: ForwardBrief = {
  sourceRef: "message-example",
  context: "안내 페이지 문구 검토를 위해 공유",
  request: {
    owner: "검토 담당자",
    action: "수정 가능한 문구의 범위를 알려주세요",
  },
  interpretation: "아직 최종 적용 승인은 받지 않음",
};

sourceRef가 있다고 수신자에게 원문 접근 권한이 생기는 것은 아닙니다. 원문 보관·접근 통제·변경 이력은 별도 설계가 필요합니다. 여기서 말하는 분리는 그 자체로 보안이나 감사 가능성을 보장하지 않습니다.

편집 화면에서도 두 영역을 구분하기

원문을 읽는 영역과 새 요청을 적는 영역의 제목을 다르게 둡니다. 원문 일부를 인용할 때에는 인용한 범위를 표시하고, 생략이나 요약으로 의미가 달라지지 않았는지 확인합니다.

작업 요청이 없는 단순 공유라면 빈 요청을 억지로 만들 필요가 없습니다. 반대로 할 일이 있다면 ‘참고’라는 제목만 남기지 말고 구체적인 행동을 보이게 합니다. 기존 대화를 다른 사람에게 넘기는 과정에서 담당자가 자동 변경된 것으로 표시해서도 안 됩니다.

먼저 확인해 볼 경계 사례

• 참고 공유만 있는 메일에 빈 작업이 자동 생성되지는 않나요?
• 원문을 바꾸지 않고 전달 안내만 수정할 수 있나요?
• 요약을 바꿔도 원문 발신자의 말로 표시되지 않나요?
• 첨부가 빠졌거나 참조를 열 수 없으면 사용자가 알아볼 수 있나요?
• 담당자가 아직 수락하지 않은 요청을 완료 상태로 보이지 않나요?

핵심은 필드 수가 아닙니다. 화면을 보는 사람이 ‘누가 원래 한 말인지’와 ‘지금 누가 무엇을 부탁하는지’를 구별할 수 있어야 합니다. 현재 쓰는 업무 도구에서도 전달 메일 한 건을 골라 이 경계가 보이는지 점검해 볼 수 있습니다.

업무용 메일 서비스에 대한 안내는 오피셜메일 공식 사이트에서 확인할 수 있습니다.

이 글과 표지 그림은 AI를 활용해 작성·제작했습니다. 예시는 가상이며 실제 고객 데이터나 오피셜메일의 구현 상태를 나타내지 않습니다.