설계 관점을 설명하는 AI 생성 개념 이미지입니다.
메일을 읽었다는 이벤트가 곧 업무 진행 권한을 뜻하지는 않습니다. 작은 내부 도구를 만들 때 이 둘을 하나의 완료 플래그로 묶으면, 전달은 됐지만 아직 결정되지 않은 요청을 끝난 일로 표시하기 쉽습니다.
아래는 실제 오피셜메일 기능이나 운영 구현을 소개하는 글이 아니라, 검토 요청을 설계해 보는 가상의 모델링 예시입니다.
하나의 status가 숨기는 질문
‘확인 완료’라는 상태에는 서로 다른 질문이 섞일 수 있습니다.
- 자료가 상대에게 전달됐는가?
- 어떤 버전을 읽고 의견을 남겼는가?
- 다음 작업을 허용할 결정이 내려졌는가?
이 질문은 반드시 같은 순서로 완료되지 않습니다. 의견이 추가된 뒤 새 버전이 나올 수도 있고, 자료는 전달됐지만 결정 담당자가 아직 정해지지 않았을 수도 있습니다.
상태 대신 책임의 경계부터 나누기
가상의 검토 요청에는 다음 정보를 따로 두는 방식을 생각해 볼 수 있습니다.
| 구분 | 확인할 정보 |
|---|---|
| 전달 | 대상 자료, 수신 대상, 전달 여부 |
| 검토 | 문서 버전, 검토 범위, 의견, 미확인 사항 |
| 결정 | 결정 대상 버전, 허용 범위, 결정자, 결정 내용 |
표의 목적은 특정 데이터베이스 스키마를 강제하는 데 있지 않습니다. 화면에서 어떤 사실을 확인했는지 구분하고, 모르는 값을 억지로 채우지 않기 위한 설계 메모입니다.
이벤트를 다음 의미로 자동 번역하지 않기
읽음 이벤트가 들어왔다는 이유로 결정 상태를 바꾸지 않습니다. 검토자가 ‘좋습니다’라는 의견을 남겼을 때도 그 사람의 역할과 요청 범위를 확인해야 합니다. 조건부 승인은 조건 확인 전의 진행 가능 상태와 구분할 필요가 있습니다.
버전이 바뀌면 기존 결정을 무조건 새 버전에 복사하지 않는 편이 안전합니다. 어느 변경이 재검토 대상인지, 누가 확인할지는 실제 업무 규칙으로 정해야 합니다. 모든 사소한 편집에 동일한 절차를 요구하자는 뜻은 아닙니다.
먼저 작성해 볼 경계 사례
구현을 시작하기 전에 기대 결과를 문장으로 적어볼 수 있습니다.
- 수신 확인만 들어오면 결정은 미정으로 남는다.
- v2에 대한 의견은 v3의 승인 근거로 자동 이동하지 않는다.
- 의견 제공자가 결정 권한을 갖지 않으면 결정 완료로 표시하지 않는다.
- 회신이 없으면 타임아웃을 승인으로 바꾸지 않고 다음 확인 대상으로 남긴다.
- 결정 범위 밖의 작업은 동일 메일에 언급됐더라도 별도 확인한다.
이는 실행한 테스트 결과가 아니라 앞으로 검증할 시나리오입니다. 실제 권한 검사, 변경 이력, 동시 수정 정책은 제품의 요구사항과 위험에 맞춰 추가로 설계해야 합니다.
UI 문구도 모델의 일부
‘완료’ 하나보다 ‘자료 전달됨 · 검토 의견 대기 · 결정 미정’처럼 의미를 드러내면 사람이 상태를 다시 해석할 여지가 줄어듭니다. 다만 상태 수를 늘리는 것 자체가 목표는 아닙니다. 사용자가 다음에 누구에게 무엇을 물어야 하는지 알 수 있는지부터 확인하세요.
의견 제공자와 최종 결정자를 구분하는 관점은 Atlassian의 DACI 역할 안내에서도 참고할 수 있습니다. 이 글의 모델은 이를 바탕으로 한 독립적인 설계 제안입니다.
현재 만드는 도구에서 ‘확인 완료’라는 라벨이 여러 의미를 대신하고 있지는 않은지 한 곳만 골라 점검해 보세요. 업무 메일 서비스는 오피셜메일에서 살펴볼 수 있습니다.
