대표에게 모든 버튼을 주면 편한 화면이 되는 것일까. 회사 현황을 확인하는 일과 주문을 직접 승인하는 일은 서로 다른 책임일 수 있다.
나는 공개 체험의 역할 구성을 새 승인 모델과 연결해 생각했다. 이번 합성 정책에서는 대표는 읽고, 실제 확인 권한을 가진 담당자는 자신이 처리할 대기함을 읽게 했다.
현황 숫자와 처리할 일은 같은 목록이 아니다
매출·미수금은 규모와 상태를 이해하는 데 도움이 된다. 승인 대기는 누가 다음 행동을 해야 하는지를 알려 준다. 같은 카드 모양으로 보일 수 있어도 두 값의 원본과 집계 기준은 다르다. 나는 모든 대기 건수를 곧바로 대표의 할 일로 붙이지 않기로 했다. 읽기 권한이 있다는 사실이 승인 책임을 뜻하지 않기 때문이다.
기존 공개 체험은 역할 선택에 따라 메뉴 설명을 바꾸며 실제 권한 서버는 없다. 이번 로컬 실험은 명시적인 역할 정책으로 목록을 구한다. 이 둘을 합쳐 운영 ERP가 완성된 것처럼 소개하지 않는다. 화면을 간단하게 만드는 질문과 허용된 행동을 서버에서 확인하는 질문을 구별하면서 공통 합성 자료로 관계를 설명했다.
담당자가 실제로 확인할 대기함
inbox는 같은 회사의 pending 승인 회차를 읽되 자신의 신청은 제외한다. 예제 정책에서 자기 승인을 허용하지 않으므로 신청자에게 승인 버튼을 보여 주는 목록을 만들지 않는다. 담당자는 다른 사람이 제출한 현재 대상을 확인할 수 있다. 대표나 직원 역할에는 이 승인 대기함을 반환하지 않는다.
이 선택이 실제 회사의 유일한 역할 구조라는 뜻은 아니다. 대표가 최종 승인자인 회사라면 명시적인 정책과 테스트를 더해야 한다. 직함만으로 모든 행동을 허용해서는 안 된다. 누가 어떤 단계에 책임이 있는지 정한 뒤 목록과 행동을 같은 정책에서 파생하면 설명도 검증도 분명해진다.
목록을 본 순간과 누르는 순간은 다르다
대기함을 열어 둔 사이 신청자가 수량을 바꿀 수 있다. 이전 목록에 보인 문서가 지금도 승인 대상인지는 실행할 때 다시 확인해야 한다. 이번 approve 명령은 문서 상태와 현재 내용 버전, 최신 pending 회차의 대상을 함께 검사한다. 오래된 목록에서 눌렀다는 이유로 변경된 내용을 승인하지 않는다.
화면에서는 현재 결과를 다시 읽고 어떤 내용이 달라졌는지 비교할 길이 필요하다. 모듈은 서버 쪽 판단을 로컬 DB에서 재현했을 뿐 브라우저의 대기함 갱신이나 실제 사용자 알림은 구현하지 않았다. 목록을 예쁘게 보여 준 것과 현재 대상만 처리할 수 있게 한 것을 따로 확인해야 한다. 이 글은 그 경계를 공유한다.
집계와 필드도 역할에 맞춰 좁힌다
다른 회사의 승인 대기를 제외하는 일은 화면 필터만으로 끝나지 않는다. 데이터베이스 조회에서 회사 조건을 적용하고 읽는 사용자의 역할을 확인한다. 직원의 문서 조회는 자기 담당 범위로 제한한다. 성공 결과가 단순하더라도 서버가 믿을 수 있는 주체에서 시작해야 한다는 전제는 같다. 합성 Actor 값을 외부 입력으로 받는 것은 인증 구현이 아니다.
이 작은 실험은 대기 건수의 성능이나 전사 보고서 전체를 다루지 않는다. 실제 업무에서는 중복 회차, 만료된 대상, 위임과 부재중 처리가 집계에 어떤 영향을 주는지 정해야 한다. 합계가 맞는지와 그 숫자가 누구의 할 일을 뜻하는지는 다른 확인이다. 대표의 한눈에 보는 화면에도 그 의미를 가까이 설명하는 편이 좋다.
처음에는 적게 보여 주고 근거로 내려가게
공유 기록에는 같은 문서에 대해 담당자 대기함은 한 건이고 대표 대기함은 비어 있는 예시가 있다. 대표가 아무것도 모른다는 뜻은 아니다. 같은 회사의 문서 현황은 읽지만 승인할 행동은 없다는 정책을 드러낸다. 독립 테스트에서 읽기 허용과 승인 거절이 함께 유지되는지 확인했다. 숫자만으로 역할을 추측하지 않게 한 것이다.
실제 화면으로 옮길 때는 건수에서 승인 대상과 변경 근거로 내려갈 수 있게 만들고, 처리 뒤 목록이 현재 결과를 반영하는지도 살펴봐야 한다. 이번에는 로컬 합성 결과와 코드만 확인했으며 실브라우저 사용성 검수를 수행하지 않았다. 나는 대표에게 필요한 정보를 덜어내는 일과 권한을 무작정 넓히지 않는 일을 함께 설계하는 재료로 이 기록을 남긴다.