플로우차트는 언제 충분하고
언제 부족할까?

같은 ‘공지 답변 서비스’도 묻는 질문에 따라 그림이 달라진다

사용자가 학교 공지를 묻고 시스템이 문서를 검색한 뒤 답변을 만들며, 민감한 내용은 담당자 승인을 기다린다고 합시다. “어떤 단계를 거치는가?”에는 플로우차트가 맞습니다. “승인 대기 상태에서 무엇이 일어나면 바뀌는가?”에는 상태도가 낫습니다. “검색과 안전 검사를 함께 하는가?”에는 활동도, “화면·서버·검색 서비스 사이 요청 순서는?”에는 시퀀스도가 적합합니다. 대상과 질문을 먼저 정하면 한 그림에 모든 정보를 밀어 넣는 일을 피할 수 있습니다.

도표는 독자가 풀어야 할 질문을 기준으로 고르며 시스템 크기는 보조 정보로 봅니다. 같은 작은 기능도 오류 응답 순서를 점검할 때는 시퀀스도가 필요하고, 큰 서비스도 전체 신청 절차만 소개할 때는 플로우차트 한 장으로 충분할 수 있습니다. 먼저 독자가 그림을 본 뒤 답해야 할 문장을 한 줄로 씁니다. 그 문장의 동사가 ‘거친다, 머문다, 동시에 한다, 주고받는다’ 가운데 무엇인지 보면 첫 후보를 좁힐 수 있습니다.

행동과 조건을 한 줄씩 따라갈 때 충분하다

플로우차트는 처리 단계를 사각형, 조건을 마름모, 흐름을 화살표로 나타냅니다. 입력 질문 확인→문서 검색→자료 있음?→답변 작성 또는 추가 질문처럼 한 주체가 수행하는 비교적 짧은 절차에 잘 맞습니다. 각 분기에는 ‘예/아니요’보다 ‘관련 문서 있음/없음’처럼 조건의 뜻을 적고, 모든 길이 종료나 다음 행동에 닿는지 확인합니다. 순서와 선택을 설명하는 목적이라면 이 정도 문법으로 충분합니다.

좋은 플로우차트는 어느 상자에서 시작해 어느 끝점에 도달하는지 한 번에 따라갈 수 있습니다. 조건문마다 가능한 값을 빠짐없이 적고, 두 갈래가 다시 만난다면 합류 뒤 행동이 양쪽에 모두 적용되는지 확인합니다. 담당자나 메시지 같은 정보는 꼭 필요할 때만 작은 라벨로 덧붙입니다. 그 정보가 중심이 되는 순간에는 레인이나 시퀀스도로 옮기는 편이 읽기 쉽습니다.

대상이 머무는 상태와 사건을 보려면 상태도로 바꾼다

초안이 작성 중, 자동 검사 중, 사람 승인 대기, 게시 가능, 보류 가운데 어디에 있는지를 묻는다면 플로우차트의 행동 상자만으로는 부족합니다. 상태도는 비교적 지속되는 상태를 노드로, 상태를 바꾸는 사건과 조건을 화살표 라벨로 표시합니다. ‘검토’는 행동이고 ‘승인 대기’는 상태입니다. 승인 요청 사건으로 승인 대기에 들어가고, 승인됨이라는 사건과 출처 확인 완료 조건이 함께 충족되면 게시 가능으로 전이합니다. UML은 상태 머신과 활동을 서로 다른 행동 모형으로 규정합니다.[1]

상태도에서는 같은 사건이 현재 상태에 따라 다른 결과를 낼 수 있습니다. ‘취소 요청’이 작성 중에는 즉시 취소로 가고, 게시 가능 뒤에는 별도 회수 절차를 시작할 수 있습니다. 그래서 화살표 라벨을 사건 [조건] / 후속 행동 순서로 적고, 사건 없이 시간이 지나 바뀌는 경우도 시간 조건으로 밝힙니다. 각 상태에서 들어오는 길과 나가는 길을 확인하면 도달할 수 없거나 빠져나올 수 없는 상태를 찾을 수 있습니다.

분기·병렬·합류가 핵심이면 활동도를 사용한다

문서 검색과 개인정보 검사를 동시에 시작한 뒤 두 작업이 모두 끝나야 답변을 만들 수 있다면 활동도의 분할 막대와 합류 막대가 관계를 분명히 보여 줍니다. 플로우차트에서도 두 갈래를 그릴 수 있지만, 선택 분기와 병렬 분기가 같은 선 모양으로 보이면 ‘둘 중 하나’와 ‘둘 다’를 혼동하기 쉽습니다. 활동도는 토큰이 흐르는 행동 모형으로 분기, 병합, fork, join을 구별합니다. 역할 레인을 더하면 누가 수행하는지도 함께 볼 수 있습니다.

분할 뒤 작업 둘 가운데 하나만 끝났을 때 다음 행동을 시작할 수 있는지도 명시합니다. 두 결과가 모두 필요하면 합류 막대가 기다리고, 먼저 끝난 하나만 필요하면 별도의 조건이나 취소 규칙이 필요합니다. 병렬 가지마다 실패했을 때의 경로도 확인합니다. 활동도는 동시에 수행되는 일을 보여 주며 실제 밀리초 단위 순서는 실행 추적 자료로 검증합니다.

참여자 사이 요청과 응답의 시간 순서를 보려면 시퀀스도를 고른다

사용자 화면이 서버에 질문을 보내고, 서버가 검색 서비스와 모델 제공자를 호출하며, 시간 초과 뒤 다시 요청하는 상황에서는 참여자별 생명선과 메시지 화살표가 필요합니다. 플로우차트에 화면·서버·검색·모델을 모두 상자로 넣으면 행동 순서는 보이지만 누가 보낸 요청인지, 응답이 어느 호출과 짝을 이루는지 흐려집니다. 시퀀스도는 위에서 아래로 시간을 읽고, 가로 화살표로 송신자·수신자·메시지를 확인합니다.

시퀀스도에는 호출 ID나 응답 조건을 적어 요청과 결과를 짝지을 수 있습니다. 재시도가 있으면 첫 요청의 시간 초과, 두 번째 요청, 늦게 도착한 첫 응답의 처리 규칙을 순서대로 그립니다. 참여자가 많아 가로 폭이 넓어지면 한 시나리오씩 나누고 공통 참여자 이름을 유지합니다. 시간의 길이를 정확히 비교하려면 별도의 워터폴을 함께 사용합니다.

도표 이름보다 먼저 독자가 확인할 질문을 준다

“이 글을 플로우차트로 그려 줘”라고 요청하면 LLM은 모든 내용을 순서 상자로 바꾸려 할 수 있습니다. 원문, 독자, 확인할 질문, 반드시 보존할 관계를 먼저 제공하고 후보 도표를 비교하게 합니다. 선택 이유와 놓치는 정보를 쓰게 한 뒤 도표를 만들도록 지시합니다. 한 도표로 감당하기 어려우면 개요 플로우차트와 세부 상태도처럼 둘로 나누게 합니다. 원문에 없는 조건·역할·메시지는 확정하지 못하게 합니다.

다음 원문을 읽고 먼저 ‘독자가 확인해야 할 질문’을 한 문장으로 써 주세요.
후보: 플로우차트 / 상태도 / 활동도 / 시퀀스도.
비교: 각 후보가 잘 보여 주는 관계와 놓치는 관계를 표로 정리한다.
선택: 질문에 가장 맞는 도표 하나를 고르고 이유를 쓴다.
분할: 한 그림이 복잡하면 개요와 세부 도표로 나누되 관계를 바꾸지 않는다.
검사: 시작·종료, 분기 조건, 상태 사건, 병렬 합류, 송수신자를 목적에 맞게 확인한다.
금지: 원문에 없는 순서·조건·상태·역할·메시지를 만들어 넣지 않는다.
출력: ①질문 ②후보 비교 ③선택 도표 ④빠진 정보 ⑤원문 대조표.

모든 관계를 한 플로우차트에 넣으면 선이 의미를 잃는다

한 장에 상태, 담당자, 메시지, 병렬 작업, 예외, 시간을 모두 넣으면 상자가 늘고 선이 교차합니다. 독자는 화살표가 행동 순서인지 메시지인지 상태 전이인지 구분하기 어렵습니다. 수정할 때 중심 질문을 하나 고르고 그 질문에 필요한 관계만 남깁니다. 다른 관계는 별도 도표로 옮기고 공통 ID를 붙여 서로 참조합니다. 개요의 ‘사람 승인’ 단계는 상세 상태도의 S3 ‘승인 대기’와 연결된다는 식입니다.

분리한 그림 사이에는 추적 가능한 연결점이 필요합니다. 플로우차트의 P4 ‘승인 요청’, 상태도의 S3 ‘승인 대기’, 시퀀스도의 M7 ‘승인 알림’처럼 ID를 붙이면 서로 다른 관점이 같은 사건을 가리키는지 확인할 수 있습니다. 한 그림을 고칠 때 연결된 ID를 검색해 다른 그림도 함께 점검합니다. 이렇게 나누면 선은 줄어들고 관계의 종류는 더 정확해집니다.

도표가 답해야 할 문장을 먼저 쓰고 비교표로 결정한다

플로우차트는 짧은 절차와 조건, 상태도는 대상의 생애와 사건, 활동도는 행동의 분기·병렬·역할, 시퀀스도는 참여자 사이 메시지 순서에 강합니다. 같은 사건을 여러 도표로 그리면 모순도 찾을 수 있습니다. 흐름도에서는 승인 실패가 종료로 향하는데 상태도에서는 수정 중으로 돌아간다면 원문과 운영 규칙을 다시 확인해야 합니다. UML 2.5.1은 활동, 상태 머신과 상호작용을 구별된 행동 모형으로 다루며, 목적에 맞는 관점을 선택하는 근거가 됩니다.[1]

확인하려는 질문을 바꾸어 도표를 선택하자

아래 실습은 같은 공지 답변 서비스를 네 질문으로 바라봅니다. 절차, 현재 상태와 전환 사건, 병렬 작업과 합류, 서비스 사이 요청·응답 중 하나를 고르면 중심 도표와 보완 도표가 제시됩니다. 추천은 검토를 시작할 첫 선택입니다. 실제 원문에 관계가 여러 종류로 섞였다면 도표 두 개로 나누고 공통 단계 ID로 연결하세요.

먼저 참여자 수를 한 명으로 두고 네 질문을 차례로 바꿔 보세요. 그다음 서비스 사이 요청·응답을 선택하고 참여자를 네 명으로 늘립니다. 중심 도표가 달라지는 까닭을 출력 문장의 ‘관계’ 항목에서 확인합니다. 마지막에는 여러분이 다루는 문서 한 단락을 가져와 확인 질문을 한 문장으로 쓰고, 추천 도표가 놓치는 정보를 보완 도표에 배치해 보세요.

선택 이유를 한 문장으로 설명할 수 없다면 확인 질문을 더 구체적으로 고칩니다. 도표 이름을 먼저 정하기보다 독자가 확인할 관계를 먼저 정하는 연습이 이 실습의 핵심입니다.

완성한 두 그림에서는 같은 사건과 단계에 동일한 ID를 붙이세요. 수정할 때 연결된 그림을 함께 찾을 수 있고 서로 어긋난 규칙도 발견하기 쉬워집니다.