[PonsLink] 여러 내부 상태를 하나의 사용자 문장으로 접기

회의는 방에 들어온 뒤 시작되는 줄 알았다. 실제로는 그보다 앞에서 이미 시작된다. 누가, 왜, 언제 만나고 싶은지 모르면 좋은 방도 금방 비어 보인다.

그래서 요청 흐름을 먼저 받는 구조로 바꿨다. 요청을 받는 일은 사람을 거르는 장치가 아니라 서로의 시간을 덜 낭비하게 만드는 완충지대였다. 문제는 내부에 여러 상태가 생겼다는 점이다. 사용자에게 그 상태를 그대로 보여 주면 제품은 곧바로 내부 시스템처럼 보인다.

내부 상태와 사용자 문장은 달랐다

요청됨, 검토 중, 추가 정보 필요, 승인됨, 일정 대기, 입장 가능은 운영자에게 필요한 상태다. 방문자에게는 지금 무엇을 기다리고 다음에 무엇을 해야 하는지가 더 중요하다.

모든 내부 상태를 화면에 노출하면 정확해 보이지만 읽기 어려워진다. 반대로 하나의 “진행 중”으로 뭉개면 운영자가 어디에서 멈췄는지 설명할 수 없다.

상태를 문장으로 접는 규칙

내부 상태는 세부적으로 유지하고, 사용자 화면에서는 같은 의미를 묶어 문장으로 보여 주었다. 다만 보류와 거절처럼 다음 행동이 달라지는 상태는 합치지 않았다.

상태 문장은 현재 위치와 다음 행동을 함께 알려야 한다. “검토 중”이라면 기다려야 하는지 추가 정보를 보내야 하는지 알 수 있어야 하고, “승인됨”이라면 언제 입장할 수 있는지가 이어져야 한다.

전이 규칙을 먼저 고정하다

상태 이름만 정하면 운영 중에 다시 흔들린다. 어떤 사건이 다음 상태를 만들고, 누가 되돌릴 수 있고, 세션 권한이 언제 생기는지 전이 규칙을 함께 적었다.

이렇게 해 두면 화면 카피를 바꿔도 내부 계약은 유지된다. 반대로 상태 전이가 불분명한 채 문장만 다듬으면 같은 요청이 다른 화면에서 서로 다르게 보인다.

마치며

요청 상태를 사용자 문장 하나로 접는 일은 정보를 숨기는 일이 아니다. 내부의 복잡함은 보존하되, 방문자가 다음 행동을 결정하는 데 필요한 의미만 앞에 놓는 일이다.