메일에서 들어온 요청을 작은 업무 도구로 옮길 때, 제목 하나로 식별·표시·상태를 전부 해결하고 싶어집니다. 하지만 사람이 읽는 문구와 시스템이 관리할 값은 역할이 다릅니다.
제목은 바뀔 수 있는 표시값입니다
고객이 회신 중 제목을 고치거나 팀원이 더 읽기 쉽게 정리할 수 있습니다. 같은 제목의 요청도 있을 수 있죠. 제목이 같다는 이유만으로 같은 업무라고 단정하거나, 제목이 달라졌다는 이유로 새 업무를 만들면 중복과 누락을 함께 만들 수 있습니다.
작은 내부 도구라도 식별자는 따로 두고 제목은 수정 가능한 표시값으로 다루는 편이 명확합니다. 아래는 제품 기능 소개가 아니라 가상의 데이터 설계 예시입니다.
{ "task_id": "task-example-01", "project_label": "가을 카탈로그", "requested_action": "시안 A 검토", "requested_due_at": null, "subject_display": "가을 카탈로그 / 시안 A 검토 요청", "status": "확인 필요" } requested_due_at을 비워둔 것은 아직 기한을 정하지 않은 상황이기 때문입니다. 빈 값을 자동으로 ‘내일’로 채우는 식의 편의 기능은 실제 약속을 새로 만들어버릴 수 있습니다.
세 가지를 분리해서 검토하세요
- 검색 단서: 사람이 나중에 떠올릴 프로젝트명이나 자료명입니다. 제목을 구성할 때도 도움이 됩니다.
- 요청 행동: 검토, 선택, 회신 등 상대에게 필요한 행동입니다. 본문 첫 문장의 요청과 맞아야 합니다.
- 업무 상태: 확인 중인지 완료됐는지 판단할 별도 값입니다. ‘완료’라는 단어가 제목에 있다고 상태를 자동 변경하지 않습니다.
메일 제목과 같은 표시값이 담당자 지정이나 승인 증거까지 대신하도록 만들지 않는 것이 핵심입니다. 메일 스레드와 업무 항목을 연결하는 정책도 별도로 정해야 합니다. 여기서 특정 메일 서비스의 식별자나 스레드 동작을 보장하는 것은 아닙니다.
화면에서는 이렇게 보여줄 수 있습니다
가상 검토 요청이라면 목록 제목은 ‘가을 카탈로그 / 시안 A 검토 요청’으로, 상세 화면에는 검토 범위와 실제 합의한 기한을 따로 표시합니다. 이후 참고용 파일을 받았다고 기존 요청을 완료 처리하지는 않습니다. 사람이 다음 행동을 확인할 수 있는 화면과 상태 전이 기준을 함께 설계해야 합니다.
개인정보나 민감한 내용을 제목에 과하게 노출하지 않는 것도 중요합니다. 알림이나 목록처럼 본문보다 넓게 노출되는 화면을 함께 생각해보세요.
먼저 한 항목으로 검증하기
작은 도구를 만든다면 제목이 같은 두 요청, 제목을 바꾼 기존 요청, 기한이 없는 요청을 각각 테스트해보세요. 식별과 표시가 분리돼 있는지 빠르게 확인할 수 있습니다. 특정 라이브러리 없이도 데이터와 화면 요구사항을 점검할 수 있는 출발점입니다.
사람에게 읽기 쉬운 제목을 쓰는 기준은 업무 메일 제목 작성 가이드에 정리했습니다. 지금 만드는 도구에서도 ‘보기 좋은 제목’과 ‘믿을 수 있는 상태값’이 같은 필드에 섞여 있지 않은지 확인해보세요.
