화면보다 먼저 권한과 상태를 설계하는 이유

화면은 사용자가 보는 흐름을 설명합니다. 하지만 시스템이 허용한 행위와 저장한 상태까지 보여주지는 않습니다. 같은 버튼이라도 누가 눌렀는지에 따라 결과가 달라집니다. 현재 상태나 앞선 처리 여부도 결과에 영향을 줍니다. 그래서 화면을 다듬기 전에 권한과 상태를 정하고 실패 뒤의 복구까지 설계해야 합니다.

누가 어떤 기능을 쓸 수 있는지 정합니다

관리자와 일반 사용자처럼 큰 역할만 두면 관리자에게 권한이 몰리기 쉽습니다. 조회·생성·수정·승인처럼 실제 행위로 나눕니다. 대상 데이터와 허용 조건도 같은 표에서 정합니다.

버튼을 숨기는 것만으로 권한을 지킬 수 없습니다. 서버와 데이터 접근 경계에서도 같은 규칙을 확인합니다. 권한 변경과 중요한 행위는 필요한 범위에서 기록합니다.

어느 상태가 기준인지 정합니다

초안·제출·처리 중은 서로 다른 상태입니다. 완료·거절·취소에서도 가능한 행위가 달라집니다. 상태마다 다음에 갈 수 있는 단계를 정하면 화면과 API가 같은 규칙을 따를 수 있습니다.

표시용 상태와 실제 처리 상태를 섞지 않습니다. 외부 처리가 진행 중인데 화면만 완료로 바뀌면 운영자는 문제를 설명할 수 없습니다.

상태를 바꾸는 사건을 기록합니다

상태 이름만 저장하면 왜 바뀌었는지 알기 어렵습니다. 누가 어떤 요청으로 바꿨는지 남깁니다. 중요한 변경에는 이전 상태와 이후 상태도 기록합니다.

모든 기록을 무기한 보관할 필요는 없습니다. 분쟁 대응과 복구에 필요한 운영 기록을 정합니다. 보관 기간과 접근 권한도 함께 둡니다.

같은 요청은 한 번만 처리합니다

사용자는 버튼을 두 번 누를 수 있습니다. 네트워크가 응답을 잃으면 같은 요청을 다시 보낼 수도 있습니다. 결제나 신청처럼 중복이 문제가 되는 행위에는 요청 식별자를 둡니다.

같은 요청을 여러 번 받아도 결과가 한 번만 반영되도록 처리합니다. 이를 멱등성이라고 합니다. 이미 끝난 요청이라면 기존 결과를 돌려주고 새로운 처리를 시작하지 않습니다.

부분 실패는 별도 상태로 남깁니다

내부 저장은 끝났지만 알림 발송이 실패할 수 있습니다. 외부 시스템은 처리했지만 응답만 잃을 수도 있습니다. 이 상황을 성공이나 실패 하나로 표시하면 실제 상태를 잃습니다.

내부 처리와 외부 요청을 구분하고 확인 단계를 따로 둡니다. 일시 오류와 영구 오류도 구분합니다. 다시 시도할 수 없는 요청은 담당자가 확인할 수 있도록 별도 상태로 남깁니다.

복구는 직접 수정이 아니라 절차로 만듭니다

데이터베이스를 직접 고치는 방식은 작은 실수를 더 큰 장애로 만들 수 있습니다. 보류된 작업과 마지막 시도 그리고 실패 원인을 운영 화면에서 확인할 수 있어야 합니다. 다시 시도하거나 취소하고 되돌리는 작업은 권한이 있는 담당자만 실행합니다.

되돌림 전에 현재 상태와 외부 처리 결과를 다시 확인합니다. 조치 뒤에는 누가 언제 무엇을 바꿨는지 기록합니다.

화면에는 필요한 상태를 보여줍니다

사용자에게 내부 구조를 모두 보여줄 필요는 없습니다. 다만 처리 중인지 완료됐는지는 분명해야 합니다. 다시 시도해도 되는지와 누구의 조치가 필요한지도 알려야 합니다.

화면과 시스템 상태가 같은 사실을 가리킬 때 사용자는 다음 행동을 결정할 수 있습니다. 운영자는 문제가 생긴 지점과 복구 근거를 설명할 수 있습니다.