현재 흐름과 실패 조건

현재 흐름은 사람이 실제로 넘기는 일을 그립니다

“신청 후 승인”이라는 두 칸만 있으면 신청자가 어디서 기다리고 운영자가 어디에 결과를 남기는지 보이지 않습니다. 개발할 화면을 먼저 그려도 현재 막힌 지점은 설명되지 않을 수 있습니다. 이 레슨에서는 현재 업무를 주체·입력·행동·결과·다음 단계로 분해합니다. 목표는 보기 좋은 그림보다 다른 사람이 사례를 같은 순서로 따라갈 수 있는 표입니다. 결과 확인 경로를 찾지 못한 사례와 바로 찾은 사례를 함께 설명해야 합니다.

한 단계는 한 주체의 관찰 가능한 행동입니다

F01은 신청자가 공지를 보고 양식을 제출하는 단계입니다. 입력은 행사 공지, 행동은 신청 양식 제출, 결과는 완료 문구입니다. F02는 운영자가 신청 목록을 검토하고 결과표에 상태를 쓰는 단계입니다. F03은 신청자가 결과표를 찾아 상태를 확인하는 단계입니다. 이 교육 사례의 단계 수는 세 개이지만 실제 업무가 항상 세 단계라는 뜻은 아닙니다. 역할이나 넘겨받는 자료가 바뀌는 곳을 기준으로 더 나눌 수 있습니다.

표의 actor는 그 줄에서 행동하는 역할입니다. input은 행동에 필요한 자료, output은 다음 사람이 확인할 수 있는 결과입니다. action을 ‘처리’라고만 쓰면 무엇이 바뀌었는지 알 수 없으므로 제출, 검토, 결과 기록처럼 구체적인 동사를 씁니다. output의 완료 문구는 신청 접수가 끝났다는 표시이며 승인이 끝났다는 뜻으로 바꾸지 않습니다. 접수, 검토, 결과 기록, 신청자의 결과 확인이 서로 다른 완료 조건이라는 점을 표에서 드러냅니다.

역할 간 전달과 대기를 표시합니다

신청자는 제출 직후 운영자의 검토를 기다릴 수 있습니다. wait에는 ‘검토까지 기간 미확인’이라고 적습니다. 제공 사례에는 정확한 시각이 없어 1일 같은 처리 시간을 만들지 않습니다. 운영자가 결과표에 기록한 뒤에도 신청자가 경로를 모르면 결과 확인은 끝나지 않습니다. 따라서 운영자 작업이 끝난 시점과 신청자의 업무가 끝난 시점을 각각 표시합니다. 결과를 쓴 사람이 완료했다고 말해도 받는 사람이 접근하지 못하면 전달 단계에 조사할 조건이 남습니다.

흐름의 화살표에는 넘기는 정보를 적습니다. F01에서 F02로 신청 목록이 넘어가고 F02에서 F03으로 결과 상태와 접근 경로가 필요합니다. P03의 원자료는 결과표 기록은 설명하지만 신청 양식에 연결 안내가 없다고 합니다. 그래서 실패 후보 위치는 결과 기록 이후의 경로 전달입니다. 실제 시스템이 결과표를 어떤 API로 읽는지는 이번 자료에 없으므로 기술 원인으로 적지 않습니다. 현재 흐름 표와 기술 데이터 흐름은 관련되지만 같은 자료는 아닙니다.

실패 조건은 정상 흐름 옆에서 설명합니다

정상 종료는 신청자가 승인 또는 반려 결과를 확인하는 것입니다. 경로를 아는 P02는 F03에서 바로 종료합니다. 경로를 모르는 P01는 공지와 양식을 열고 운영자에게 문의합니다. 표의 condition에 두 갈래를 설명하고 output에 ‘결과 확인 또는 재문의’를 적습니다. 재문의가 결과 전달의 정상 절차인지 우회 경로인지는 운영자에게 확인할 질문으로 남깁니다. 반복 화살표만 그려 두지 말고 어디에서 누가 무엇을 다시 하는지 서술합니다.

검토가 아직 끝나지 않은 경우와 검토는 끝났으나 결과를 못 찾는 경우를 구분합니다. 둘 다 신청자가 답을 못 얻었다고 말할 수 있지만 필요한 확인이 다릅니다. 첫 경우에는 처리 상태와 예정 안내를 조사하고, 둘째 경우에는 결과표 경로와 상태 표시를 조사합니다. 거절 결과를 본 경우는 승인되지 않았다는 이유만으로 시스템 오류로 분류하지 않습니다. 결과 확인 목표는 승인과 반려 모두에서 달성될 수 있습니다. 업무 규칙과 사용자의 기대를 섞지 않는 것이 핵심입니다.

추가 조건을 가설로 적는 법을 익힙니다

제출 실패, 신청 취소, 결과 수정 같은 예외도 생각해 볼 수 있습니다. 그러나 제공 사례에 없으면 ‘관찰됨’ 칸이 아니라 ‘추가 확인’ 칸에 씁니다. 이 레슨에서 예외를 상상하는 목적은 실제 실패 건수를 늘리는 것이 아니라 흐름이 어떤 조건을 설명하지 못하는지 찾는 것입니다. 운영자에게 취소 요청이 오면 목록과 결과표를 어떻게 맞추는지 묻는 질문을 남길 수 있습니다. 범위를 넘는 출석과 결제 업무는 앞 모듈의 제외 범위로 유지합니다.

사용자 탓으로 실패 조건을 쓰는 실수도 피합니다. ‘신청자가 부주의함’은 표에서 확인할 수 있는 상태가 아닙니다. ‘신청 양식에 결과 경로 안내가 없고 참가자는 공지와 양식을 탐색함’으로 적으면 자료와 행동을 대조할 수 있습니다. 안내가 없다는 사실만으로 원인이 확정되지는 않습니다. 다른 경로의 안내를 놓쳤을 가능성도 있으므로 공지·제출 후 화면·운영자 안내를 어디까지 확인했는지 기록합니다. 확인한 범위를 넘어 모든 안내가 없다고 쓰지 않습니다.

근거를 붙여 표를 검토합니다

각 줄의 evidenceIds는 그 줄을 뒷받침하는 E번호 목록입니다. F03에는 E003의 탐색·문의와 E005의 바로 확인, E006의 연결 안내 부재를 붙입니다. 하나의 근거가 단계 전체를 모두 증명하는 것은 아니므로 단계의 일부가 추정이면 condition이나 wait에 미확인을 표시합니다. 단계 표만 보면 매끄럽더라도 원자료와 다른 순서라면 수정합니다. 흐름을 새 기능의 상태 화면과 알림으로 채우는 것은 현재 분석을 미래 설계로 바꾸는 실수입니다.

미션의 next는 다음 F번호 목록이며 마지막 단계는 빈 목록입니다. 재문의의 반복은 condition에 적고 자동 검사용 뼈대는 순서가 끝나는 구조로 작성합니다. ‘flow.next: 존재하는 ID 목록 필요’는 아직 정의하지 않은 단계로 연결했을 때 나옵니다. ‘시작에서 도달하지 못하는 단계’는 따로 떨어진 행이 있다는 뜻입니다. 검사기는 업무의 진짜 순서를 아는 것이 아니라 참조와 연결을 확인합니다. 첫 행이 시작이며 화살표가 모두 그 시작에서 이어지는지 살펴봅니다.

검토할 때 P01와 P02 역할을 번갈아 맡아 표를 읽습니다. P01로 읽었을 때 실패 위치와 우회 문의가 보이고, P02로 읽었을 때 같은 흐름에서 성공 조건이 보이면 비교가 가능합니다. 운영자 역할에서는 무엇을 보고 무엇을 기록했는지 확인합니다. 결과가 이미 있었는지는 사례별로 확정되지 않았다면 그대로 말합니다. 그림의 빈칸을 메우기 위해 사건의 시각을 만들어 넣지 않습니다. 더 읽기의 시스템 관점 장은 단계 실패와 전체 완료를 구분하는 보충 자료입니다.

제출물은 현재 흐름 표와 두 사례의 경로 설명, 미확인 조건 두 가지입니다. 동료에게 ‘운영자가 결과표를 쓰면 신청자 확인도 끝나는가’와 ‘결과 경로를 알고 있는 신청자는 어디서 종료하는가’를 물어봅니다. 표에서 답을 찾을 수 없으면 주체나 결과 칸을 보완합니다. 다음 레슨에서는 이 실패 위치를 문제 후보의 근거로 사용하므로 표의 E번호를 잃지 않고 보존합니다.