
**순서도(Flowchart)**는 시작부터 종료까지의 작업, 판단, 입력·출력과 흐름을 표준화된 기호와 화살표로 나타낸 그림입니다. 핵심은 “다음 단계는 무엇이며, 어떤 조건에서 다른 길로 가는가?”를 검토하는 데 있습니다. 실제 업무 순서도에는 담당자, 예/아니오 조건, 예외 경로와 종료 조건까지 적습니다. 시작하려면 목적과 시작·종료 경계를 먼저 정합니다.
이 글은 가상의 요청 승인 예시, 7단계 작성법과 복사 가능한 검토 체크리스트를 제공합니다.
핵심 요약
- 타원은 시작·종료, 직사각형은 처리, 마름모는 판단, 평행사변형은 입력·출력을 나타내는 데 주로 씁니다.
- 마름모의 각 출구에는
예/아니오처럼 서로 겹치지 않는 조건을 적고, 모든 경로가 다음 단계나 종료점에 닿게 합니다.- 업무 순서도라면 단계마다 담당 역할을 붙이고 정상 경로와 예외·재작업 경로를 함께 검토합니다.
- 순서도는 절차를 설명하고 검토하는 도구이며, 실제 업무 실행·승인·자동화·성과 측정을 대신하지 않습니다.
한국 국립특수교육원의 소프트웨어 교육 자료는 순서도를 일의 처리 과정이나 알고리즘을 약속된 기호와 도형으로 표현한 것으로 설명합니다. ISO 5807:1985는 데이터, 프로그램, 시스템 흐름도 기호와 작성 관례를 다룹니다.
“고객 문의를 처리한다”처럼 시작과 끝이 불명확하면 서로 다른 장면을 그리게 됩니다. 문의 접수를 시작, 답변 발송 또는 이관을 종료로 정하고 복잡한 세부 단계는 하위 그림으로 분리합니다.
순서도는 승인·반려·재작업처럼 갈림길이 있거나, 새 담당자에게 절차를 넘기거나, 문서와 실제 작업이 같은지 확인할 때 특히 유용합니다. 아이디어 관계를 자유롭게 확장하려면 마인드맵 가이드가 더 적합합니다. 순서도의 화살표는 논리적 방향이며 소요 시간이나 보고 체계를 자동으로 뜻하지 않습니다.
검색 결과에서는 이 네 용어가 자주 섞이지만, 질문과 산출물이 다릅니다.
| 도구 | 주로 답하는 질문 | 핵심 표현 | 적합한 상황 | 주의할 점 |
|---|---|---|---|---|
| 순서도 | 다음 단계와 조건 분기는 무엇인가? | 처리, 판단, 화살표, 시작·종료 | 절차 설명, 알고리즘 개요, 예외 검토 | 시간·성과를 자동으로 보여 주지 않음 |
| 프로세스 맵 | 전체 프로세스가 어떻게 가치를 전달하는가? | 단계, 역할, 입력·출력, 때로 지표 | 현행 프로세스 분석과 개선 | 상세 표기법은 조직마다 다를 수 있음 |
| 업무 워크플로 | 실제 업무가 누구에게 어떻게 넘어가는가? | 상태, 담당자, 승인 규칙, 시스템 동작 | 운영 절차와 자동화 설계 | 그림만으로 실행되는 것은 아님 |
| 의사코드 | 프로그램 논리를 문장에 가까운 코드로 어떻게 표현하는가? | 조건문, 반복문, 변수, 함수 | 개발 전 알고리즘 검토 | 비개발 이해관계자에게 어려울 수 있음 |
미국품질협회(ASQ)는 흐름도를 단계 순서를 보여 주는 프로세스 분석 도구로 설명하고, 실제 담당자와 현재 상태를 확인하라고 권합니다. 네 도구 중 무엇을 쓸지는 목적과 상세 수준으로 정합니다.
기호는 장식이 아니라 독자에게 보내는 약속입니다. 조직에서 다른 표기법을 이미 사용한다면 범례를 먼저 두고 일관되게 적용합니다.
| 기호 | 일반적인 의미 | 안에 적을 내용 | 예시 |
|---|---|---|---|
| 타원·둥근 사각형 | 시작 또는 종료 | 사건이나 종료 상태 | 요청 접수, 결과 전달 완료 |
| 직사각형 | 처리·작업 | 동사와 대상 | 담당자가 자료 검토 |
| 마름모 | 판단·조건 | 예/아니오로 답할 질문 | 필수 정보가 완전한가? |
| 평행사변형 | 입력 또는 출력 | 들어오거나 나가는 자료 | 신청서 입력, 결과 통보 |
| 문서 모양 | 문서·기록 | 생성하거나 참조하는 문서 | 검토 기록 저장 |
| 작은 원 | 같은 페이지의 연결 | 대응되는 연결 문자 | A에서 A로 이동 |
| 화살표 | 흐름 방향 | 필요할 때 조건·전달물 | 아니오: 보완 요청 |
Microsoft의 Visio 안내도 시작·종료, 처리, 판단, 데이터 기호를 소개하며 팀의 합의된 의미를 일관되게 쓰라고 설명합니다.
읽기 쉬운 순서도를 위한 기본 규칙은 다섯 가지입니다.
동사 + 대상으로 이름을 붙입니다.예/아니오, 통과/실패 같은 조건을 붙입니다.다음은 설명만을 위한 가상의 예시입니다. 실제 AFFiNE의 승인 절차나 특정 기업의 운영 데이터를 나타내지 않습니다. 한 팀이 외부 게시물 요청을 검토한다고 가정합니다.
범위: 요청이 양식으로 들어온 시점부터 승인 결과를 요청자에게 전달한 시점까지입니다. 역할은 요청자, 접수 담당자, 검토 담당자와 승인자 네 가지입니다.
예이면 승인 결과를 기록합니다. 아니오이면 반려 사유를 기록하고, 수정 가능한 경우 보완 요청으로 되돌립니다. 범위 밖 요청이면 종료: 반려로 끝냅니다.
재제출 허용 횟수와 반려가 종료인지 수정 대기인지는 조직 정책으로 정해야 합니다. 순서도는 결정을 보이게 할 뿐 대신하지 않습니다. 인수인계가 많다면 역할별 구역인 스윔레인을 사용합니다.
“신입 담당자가 게시 요청을 같은 순서로 처리하도록 한다”처럼 사용 장면과 독자를 적습니다.
시작 사건과 종료 상태를 합의하고 반려·취소·시간 초과도 종료인지 확인합니다.
실제 담당자에게 작업과 전달물을 묻습니다. 회의 결정은 AI 회의록 검증 가이드처럼 원문과 대조합니다.
자료 확인은 처리, 자료가 완전한가?는 판단입니다. 긴 기준은 정책 문서나 체크리스트로 연결합니다.
성공 경로를 먼저 연결한 뒤 예/아니오, 실패, 취소와 시간 초과를 추가합니다.
단계마다 책임 역할을 정하고 정보 누락, 권한 부족, 시스템 장애와 재작업을 점검합니다. 예외 뒤에는 알림, 기록, 재시도 또는 종료를 적습니다.
정상 사례와 예외 사례를 끝까지 추적해 그림을 수정하고 버전·검토일·소유자를 남깁니다.
다음 목록을 복사해 검토 기록에 붙여 넣을 수 있습니다.
[ ] 순서도의 목적, 독자, 범위가 한 문장으로 적혀 있는가?
[ ] 시작 사건과 모든 종료 상태가 표시되어 있는가?
[ ] 각 처리 상자에 한 가지 행동과 담당 역할이 있는가?
[ ] 모든 판단 상자가 질문이며 출구 조건이 겹치지 않는가?
[ ] 예/아니오, 실패, 취소, 시간 초과 경로가 다음 단계로 연결되는가?
[ ] 정보 누락, 권한 부족, 시스템 오류 같은 예외 후 행동이 있는가?
[ ] 선의 교차와 역방향 이동을 줄였고 연결점이 모호하지 않은가?
[ ] 최근 정상 사례와 예외 사례로 끝까지 따라가 보았는가?
[ ] 관련 정책, 양식, 기록 위치가 최신 문서로 연결되는가?
[ ] 소유자, 검토일, 버전과 다음 검토 시점이 기록되어 있는가?
판단 결과가 없습니다. 마름모의 출구 가까이에 조건을 붙입니다.
정상 경로만 있습니다. 정보 누락, 반려 등 영향이 큰 예외를 포함합니다.
담당자가 없습니다. 처리 상자나 스윔레인에 책임 역할을 표시합니다.
한 상자에 여러 행동이 있습니다. 담당자나 입력·출력이 달라지면 분리합니다.
선이 교차합니다. 단계를 다시 배치하고 반복 흐름은 하위 순서도로 분리합니다.
소유자와 검토일이 없습니다. 세컨드 브레인 구축 가이드처럼 배경 기록을 연결하되 승인된 절차와 개인 메모는 구분합니다.
이 글을 위해 2026년 8월 6일, 로그인된 AFFiNE Web의 AFFiNE Blog 작업 공간에서 TEMP KO 순서도 실사용 검증 2026-08-06 문서를 만들고 Edgeless로 전환했습니다. 시작, 요청 접수, 정보 완전?, 담당자 검토, 승인?, 결과 전달, 종료 도형을 놓고 연결선으로 정상 경로를 이었습니다. 정보가 부족하거나 승인이 나지 않을 때 보완 요청으로 돌아가는 분기도 수동으로 추가했습니다.
실제 작업에서 확인한 점은 구체적입니다. Edgeless에서 타원·직사각형·마름모를 선택하고 도형 안에 한국어 단계를 입력할 수 있었고, 연결선으로 분기와 되돌아가는 경로를 표현할 수 있었습니다. 반면 예/아니오 같은 분기 문구는 읽기 좋은 위치에 직접 배치하고 겹침을 다시 조정해야 했습니다. 문서 제목과 설명은 같은 문서의 Page 맥락으로 보관할 수 있지만, 그림의 업무 논리가 맞는지는 담당자가 검토해야 합니다.
이 경험을 제품 능력보다 넓게 해석하지 않습니다. AFFiNE은 이 사례에서 순서도를 자동 실행하지 않았고, 승인 정책을 검증하거나 병목을 측정하거나 예외를 자동 처리하지 않았습니다. 팀은 도형, 연결, 조건, 담당자와 검토 기록을 직접 유지해야 합니다. AFFiNE의 상업적 이해관계를 가진 제품 팀이 작성한 글이므로 기능 설명은 이번 수동 재현과 공식 Whiteboard 범위로 제한했습니다.
한 가지 다음 단계: AFFiNE Web을 열고 시작·종료와 가장 중요한 판단 하나만 먼저 배치한 뒤, 실제 사례로 예외 경로를 검토해 보세요.
순서도는 작업이나 알고리즘이 진행되는 순서를 약속된 도형과 화살표로 나타낸 그림입니다. 시작과 종료, 처리, 입력·출력, 판단을 구분해 다음 단계와 조건 분기를 빠르게 확인하게 합니다. 그림 자체가 업무를 실행하거나 정확성을 보장하지 않으므로 운영 규칙과 담당자의 실제 검토도 함께 필요합니다. 중요한 절차는 실제 사례로 다시 따라가야 합니다.
보통 타원이나 둥근 사각형은 시작·종료, 직사각형은 처리, 마름모는 판단, 평행사변형은 입력·출력에 사용합니다. 화살표는 진행 방향을 잇고 작은 원은 떨어진 부분을 연결합니다. 처음에는 이 네 기호만으로도 충분합니다. 조직 표준이 다르면 범례를 먼저 제시하고 같은 의미를 일관되게 사용하세요. 연결선에는 필요할 때 조건을 적습니다.
목적과 독자를 정한 뒤 시작·종료 경계를 먼저 고정합니다. 실제 단계를 수집해 처리와 판단으로 나누고 정상 경로를 연결한 다음 예/아니오와 예외 경로, 담당자를 추가합니다. 마지막으로 정상 사례와 실패 사례를 따라가며 빠진 단계와 막힌 경로를 수정하고, 복잡한 부분은 하위 순서도로 분리합니다. 검토 결과는 버전과 날짜로 남깁니다.
작은 순서도는 각 처리 상자에 접수 담당자: 정보 확인처럼 역할을 함께 적을 수 있습니다. 역할 간 전달이 많다면 스윔레인을 만들고 각 단계가 책임 역할의 구역 안에 놓이게 합니다. 협업자가 여러 명이어도 최종 책임 역할 하나를 명시해야 인수인계와 예외 대응이 모호해지지 않습니다.
두 도구는 겹치지만 완전히 같다고 볼 필요는 없습니다. 순서도는 단계의 순서와 조건 분기를 명확히 보여 주는 데 초점을 두고, 프로세스 맵은 역할, 입력·출력, 고객 가치나 지표까지 더 넓게 다룰 수 있습니다. 먼저 해결할 질문과 필요한 상세 수준을 합의한 뒤 이름과 표기법을 선택하세요.
좋은 순서도는 시작, 종료, 처리, 판단과 예외가 끊김 없이 연결된 검토 도구입니다. 범위를 정하고 조건과 담당자를 붙인 뒤 정상·예외 사례로 확인하고 소유자와 검토일을 기록하세요.