워크플로우 상태 라벨: 팀이 공유할 수 있는 7가지 명확한 상태

불분명한 상태가 작업을 더디게 하는 이유

모호한 워크플로우 상태 라벨은 바쁜 척하는 혼란을 만듭니다. 사람들은 항목을 옮기지만 실제로 무엇이 바뀌었는지는 아무도 확신하지 못합니다. '진행 중'으로 표시된 티켓이 어떤 사람에게는 "생각을 시작했다"는 뜻이고, 다른 사람에게는 "차단되었다" 또는 "검토 대기"인 경우가 있습니다.

그 불일치는 세 가지 예측 가능한 문제를 만듭니다: 재작업, 인수인계 실패, 그리고 소음성 알림. 상태가 다음 사람이 무엇을 해야 하는지 알려주지 않으면 작업이 왔다 갔다 합니다. 인수인계가 모호한 라벨 안에 숨겨져 있으면 누군가 알아차릴 때까지 방치됩니다. 모두가 단지 활동을 ‘신호’하기 위해 상태를 바꾼다면 피드가 흐려지고 실제 변화는 놓치기 쉽습니다.

또 다른 흔한 증상은 같은 라벨이 화면마다 다르게 쓰이는 것입니다. 한 동료는 「준비됨」을 "검토 준비"로 쓰고, 다른 이는 "시작 가능"으로 사용할 수 있습니다. 매니저가 보드를 확인할 때 팀이 기다리고 있는지, 작업 중인지, 완료인지 알기 어렵습니다.

목표는 모든 예외를 설명하는 것이 아닙니다. 정상적인 흐름을 더 적은 상태로 명확하게 만드는 것이 목표입니다. 상태가 어디서나 일관되면 인수인계가 빨라지고 “이게 진짜로 완료된 건가요?” 같은 질문이 줄어듭니다.

팀이 어디서 시작해야 할지 모르면 대부분의 작업을 포괄하는 5~7개의 상태를 목표로 하세요: 신규 항목용 하나, 활동 중인 작업용 하나, 대기나 차단된 작업용 하나, 검토·승인용 하나, 완료용 하나. 기본이 안정되고 모두가 같은 의미로 사용할 때만 세부사항을 추가하세요.

상태 라벨이 의미해야(그리고 의미하지 말아야) 할 것

상태 라벨은 다음에 무슨 일이 일어날지에 대한 공유된 약속입니다. 누군가 상태를 바꾸면, 추가 질문 없이도 다음 단계가 예측되어야 합니다.

좋은 워크플로우 상태 라벨은 작업의 현재 현실을 설명해야지 개인의 의견을 담아서는 안 됩니다. 라벨이 사실이라면 팀은 항목이 이동 중인지, 대기인지, 차단되었는지, 다음에는 누가 처리해야 하는지 알 수 있습니다.

상태는 우선순위, 담당자, 카테고리, 진행 노트와 동일하지 않습니다. 그런 필드들은 중요할 수 있지만, 상태에 섞어 넣으면 상태가 신뢰할 수 없게 됩니다.

또한 "상태(state)"와 "단계(stage)"를 분리하면 도움이 됩니다. 상태는 지금 무엇이 참인지(예: "차단: 고객 회신 대기")이고, 단계는 프로세스에서 항목이 어디에 위치하는지(예: "검토")입니다. 둘을 섞을 수는 있지만 한 상태가 둘 다 설명하려고 하면 흔히 모호해집니다.

유용한 상태는 다음 세 가지 중 하나를 촉발해야 합니다:

• 다음 소유자(누가 처리할지)
• 다음 행동(다음에 무엇을 할지)
• 대기 조건(무엇을 기다리는지)

간단한 현실 점검: 작은 리스트 뷰에서 라벨만 읽고도 다음에 무엇을 해야 할지 알 수 있나요? 답이 "상황에 따라 다르다"면 라벨이 결정을 숨기고 있는 것입니다(우선순위 규칙이나 담당 지정 등 다른 곳에서 내려야 할 결정).

얼마나 많은 상태를 사용해야 하는가, 그리고 왜 5~7개가 적당한가

상태 시스템은 한눈에 작업을 읽기 쉽게 만들어야 합니다. 상태가 너무 많으면 사람들은 본 것을 신뢰하지 않게 됩니다. 너무 적으면 인수인계를 관리하는데 필요한 세부 정보가 사라집니다.

대부분의 팀에게 5~7개 상태가 적절한 중간지점입니다. 한 화면에 들어오고, 칸반 보드나 간단한 리스트 뷰에서 잘 작동하며 차단된 항목, 작업 중인 항목, 검토 대기 항목을 구분할 수 있는 신호를 제공합니다.

집합을 작게 유지하면 '상태 찾기'가 줄고(12개 옵션 중 하나를 추측하는 일), 보고가 쉬워지며 우선순위·소유자·유형을 별도의 필드로 유지하도록 강제합니다.

이름은 달라질 수 있고 괜찮습니다. 어떤 팀은 "In Progress"라고 하고 다른 팀은 "Doing"이라고 합니다. 달라져도 안 되는 것은 의미입니다. "In Review"가 어떤 때는 "QA 대기"를 의미하고 다른 때는 "고객 대기"를 의미하면 보드는 소음이 됩니다.

의미를 일관되게 유지하려면 한 가지 진실의 출처를 마련하세요: 각 상태와 그 의미, 항목이 해당 상태에 들어오고 나갈 때의 규칙을 간단히 정리한 팀 문서입니다. 두 분 안에 읽을 수 있을 정도로 짧게 유지하고, 사람들이 작업을 보는 모든 곳에서 같은 상태 집합을 사용하세요.

시작할 수 있는 간단한 7개 상태 세트

명확하게 유지되는 워크플로우 상태 라벨을 원하면 현재 누가 소유하는지, 다음에 무슨 일이 일어나는지, 그리고 "완료"가 무엇인지 답해주는 작은 집합으로 시작하세요.

다음은 대부분의 팀에 적당하면서 과도하게 세분화되지 않는 단순한 7개 상태 세트입니다.

핵심 규칙: 단독으로 "대기(Waiting)"를 사용하지 마세요. 멈춘 이유가 있다면 "차단됨"으로 표시하고 메모에 의존성을 명시하세요(예: "Blocked: 고객 회신").

각 상태 정의(진입 및 퇴장 규칙 포함)

명확한 워크플로우 상태 라벨은 각 상태가 지금 무엇이 참인지를 답할 때 가장 잘 작동합니다.

신규 (New)

무엇이 참인지: 항목이 접수되었으나 아직 아무도 평가하지 않았습니다.

무엇이 참이 아닌지: 우선순위, 범위, 담당자가 합의되지 않았습니다.

진입: 요청이 제출됩니다.

퇴장: 누군가 읽고 "분류됨"으로 이동합니다.

예: "지원 담당자가 스크린샷 한 장으로 버그 리포트를 기록한다."

분류됨 (Triaged)

무엇이 참인지: 팀이 요청을 충분히 이해해 라우팅하고 유효함을 확인했습니다.

무엇이 참이 아닌지: 시작 준비가 된 상태는 아닙니다.

진입: 누군가 기본 컨텍스트(요약, 영향, 관련 영역)를 추가합니다.

퇴장: 작업 준비(준비됨)로 옮기거나 의도적으로 처리 거부합니다(프로세스 밖에서 처리, 상태로서의 거부 아님).

예: "PM이 실제 버그로 표시하고 재현 단계를 적는다."

준비됨 (Ready)

무엇이 참인지: 누락된 정보 없이 바로 시작할 수 있습니다.

무엇이 참이 아닌지: 작업이 이미 시작된 상태는 아닙니다.

진입: 수용 기준이 명확하고 의존성이 해결되어 있습니다.

퇴장: 누군가 작업을 시작해 의미 있는 첫 변경을 하면(진행 중) 상태가 바뀝니다.

예: "폼 필드와 검증 규칙이 합의되었다."

진행 중 (In Progress)

무엇이 참인지: 실제로 작업이 이뤄지고 있습니다.

무엇이 참이 아닌지: 큐에 대기 중인 상태는 아닙니다.

진입: 누군가 맡아 작업을 시작합니다.

퇴장: 검토할 만큼 완료되어 검토 중으로 가거나, 의존성으로 인해 차단됨으로 바뀝니다.

예: "개발자가 상태 드롭다운을 구현하고 로직을 저장한다."

검토 중 (In Review)

무엇이 참인지: 동료 검토, QA 또는 이해관계자 승인이 진행 중입니다.

무엇이 참이 아닌지: 새로운 기능이 계속 추가되는 상태는 아닙니다.

진입: 수행자가 검증을 위해 제출합니다.

퇴장: 팀의 정의된 완료 기준을 만족해 승인되면 완료가 되거나(완료), 피드백을 받고 되돌아갑니다(진행 중).

예: "QA가 웹과 모바일에서 모두 동작을 확인한다."

차단됨 (Blocked)

무엇이 참인지: 특정하고 명시된 의존성 때문에 작업이 계속될 수 없습니다.

무엇이 참이 아닌지: 단순히 우선순위가 낮은 상태가 아닙니다.

진입: 담당자가 혼자 해결할 수 없는 의존성에 부딪힐 때 표시합니다.

퇴장: 의존성이 제거되고 작업이 다시 시작됩니다(보통 진행 중으로).

예: "Blocked: 운영 로그 접근 권한 대기 중".

완료 (Done)

무엇이 참인지: 합의된 수용 기준을 만족하고 배포되었거나 배포 준비가 되어 있습니다.

무엇이 참이 아닌지: 검토, 테스트 또는 후속 조치가 필요한 상태가 아닙니다.

진입: 검토를 통과하고 릴리스 단계가 완료됩니다(팀 정의에 따름).

퇴장: 없음; 재오픈은 명확한 이유로 새 사이클을 시작합니다.

예: "수정사항이 배포되어 버그가 더 이상 재현되지 않는다."

단계별: 60분 안에 상태 시스템 만들기

혼란스러운 상태는 한 번의 집중 회의로 고칠 수 있습니다. 목표는 완벽한 모델이 아니라 실제로 작업이 이동하는 방식과 맞는 공유된 라벨 집합과 팀이 반복할 수 있는 규칙입니다.

60분 워킹 세션(단 하나의 결과물)

작업에 관여하는 각 역할에서 한 사람씩 데려오세요(요청자, 수행자, 검토자, 승인자). 현재 보드나 리스트를 화면에 공유하세요.

먼저 실제 흐름을 지도화(맵)합니다(이상적 흐름이 아니라 실제로 일어나는 흐름). 한 가지 전형적인 항목을 골라 실제로 어떤 일이 일어났는지, 대기 시간까지 포함해 추적하세요. 단계는 평범한 동사로 적으세요("초안 작성", "검토", "승인"). 어떤 단계가 가끔만 발생하면 분기(branch)로 표기하세요.

다음으로 중복을 제거하고 모호한 라벨을 바꾸세요. 같은 의미의 라벨("In Progress" vs "Doing")은 합치고, 모호한 것("Pending")은 행동으로 옮길 수 있는 용어("Blocked: 고객 회신")로 바꾸세요. 라벨을 한 문장으로 설명할 수 없다면 준비되지 않은 것입니다.

그다음 진입·퇴장 규칙을 추가하세요. 각 상태에 대해 진입할 때 무엇이 참이어야 하고 퇴장할 때 무엇이 참이어야 하는지 적으세요. 짧게 유지하세요. 예: "검토 중은 수행자가 제출하면 진입하고, 피드백을 반영하고 검토자가 승인하면 퇴장한다."

그다음 각 인수인계에 대한 소유자를 정하세요. 각 상태는 기본 소유자(역할 단위로 괜찮음)를 가져야 합니다. 이렇게 하면 항목이 멈추는 일이 줄어듭니다. 예: "검토 중인 항목은 수행자가 아니라 검토자가 소유한다."

마지막으로 최근 항목 10개로 테스트하고 조정하세요. 지난 몇 주의 완료되었거나 활동 중인 항목 10개를 골라 각 시점에 해당 항목에 맞는 상태를 지정해 보세요. 자주 논쟁이 일어나면 라벨이 겹치는 것입니다. 항목을 배치할 수 없다면 상태가 부족하거나 두 가지 개념이 섞여 있는 것입니다.

회의 후 정의를 한 곳에 게시하고 사람들이 보는 모든 곳의 라벨을 일치시키세요.

웹과 모바일 화면에서 상태를 일관되게 유지하기

웹에서 한 의미인 상태가 모바일에서 약간 다르게 보이면 사람들은 신뢰를 잃습니다. 채팅으로 묻거나 세부를 다시 확인하거나 자체적인 "실제 상태"를 코멘트로 만들기 시작합니다. 워크플로우 상태 라벨의 목적은 장식이 아니라 공유된 사실입니다.

상태를 하나의 공유 필드이자 하나의 진실의 출처로 다루세요. 같은 라벨은 철자, 대소문자, 의미까지 모든 곳에서 동일하게 나타나야 합니다: 리스트, 상세 화면, 알림, 내보내기, 푸시 메시지 등.

작은 화면에서 실제로 통하는 규칙

모바일 화면은 긴 이름과 약한 시각적 디자인을 벌주듯 다룹니다. 데스크톱 표에서 괜찮던 상태가 폰에서는 잘려서 읽기 어려운 배지로 보일 수 있습니다.

• 이름을 짧게 유지하세요(가능하면 1~2단어).
• 색을 일관되게 사용하되 색상에만 의존하지 마세요.
• 가장 긴 라벨을 기준으로 디자인해 잘려서 의미가 사라지지 않게 하세요.
• 플랫폼 간 순서를 일관되게 유지하세요.
• "In Progress" vs "Working"처럼 거의 같은 라벨을 피하고 하나를 선택하세요.

배치도 중요합니다. 상세 뷰에서 제목 근처에 상태를 두어 설명을 읽기 전에 상태가 보이게 하세요. 리스트 뷰에서는 항상 같은 위치에 표시하세요.

접근성 기본 원칙은 모두에게 도움이 됩니다. 색상은 힌트일 뿐 메시지는 아닙니다. 항상 텍스트 라벨을 표시하고(예: 완료에는 체크 아이콘) 스크린 리더 사용자나 색각 이상이 있는 사람도 빠르게 의미를 알 수 있게 하세요.

상태가 흐트러지게 만드는 흔한 실수들

상태가 "작업이 어디에 있는가"를 의미하지 않고 "사람들이 작업에 대해 어떻게 느끼는가"를 나타내기 시작하면 상태는 흐트러집니다. 그렇게 되면 보드는 바빠 보이지만 누구도 신뢰하지 않습니다.

흐트러짐의 한 원인은 모든 작은 단계마다 라벨이 있는 경우입니다. 작업이 한 시간에 세 번 움직일 수 있다면 사람들은 업데이트를 멈추거나 "충분히 가까운" 상태를 고릅니다. 각 이동이 실제로 준비 상태나 책임의 변화를 의미할 때만 작은 집합이 잘 작동합니다.

또 다른 흐트러짐 포인트는 서로 다른 차원을 한 필드에 섞는 것입니다. 우선순위와 긴급성은 중요하지만 상태와 섞이면 안 됩니다. "긴급"이 상태가 되면 "검토 중"과 경쟁하게 되고 보고의 의미가 퇴색됩니다.

다음 패턴을 관찰하세요:

• 명확한 차이가 없는 여러 개의 "거의 완료" 라벨
• 개인용 일회성 라벨("샘 기다리는 중")
• "진행 중"이 주차장(park)처럼 되는 경우
• 서면 진입·퇴장 규칙의 부재
• 새 화면에서 다른 상태 이름이나 순서를 보여주는 경우

흐트러짐을 막으려면 상태 집합의 책임자를 정하고 변경을 드물게 하세요. 변경할 때는 무엇이, 왜, 무엇을 대체하는지 적어 두세요.

예시: 요청 하나가 시작에서 완료까지 가는 흐름

고객이 지원팀에 이렇게 씁니다: "모바일에서 주문 내역 페이지가 주문이 있어도 빈 상태를 보여요." 지원은 이 항목을 제품 수정으로 기록하고 릴리스로 이어집니다.

신규: 지원이 스크린샷, 기기 정보, 올바른 화면이 무엇인지 캡처합니다.

분류됨: PO가 실제 버그인지 확인하고 소속(모바일 앱 등)을 정하고 영향을 명확히 합니다.

준비됨: 재현 단계가 확인되고 수용 기준이 명확합니다.

진행 중: 엔지니어가 문제를 재현하고 API는 데이터를 반환하지만 화면이 잘못 필터링하고 있음을 발견해 수정 작업을 시작합니다.

차단됨: 엔지니어가 오래된 계정에서 필드가 빠져 있어 백엔드 변경이 필요함을 발견하고, 메모에 "Blocked: 백엔드에 레거시 필드 매핑 필요"라고 적습니다.

검토 중: 의존성이 해결된 뒤 QA가 iOS와 Android에서 빈 상태 동작을 확인합니다.

완료: 수정이 승인되어 배포되었거나 다음 릴리스 창에 큐잉되어 있으면(팀 규정에 따라 완료로 간주) 지원이 라이브 확인 후 고객에게 회신합니다.

혼란을 막는 요소에 주목하세요: "차단됨"에는 하나의 이유와 하나의 다음 행동이 있고 소유권이 튀지 않습니다. 누구든 항목을 열어 보면 누가 공을 들고 있는지 알 수 있습니다.

팀 일관성을 유지하기 위한 빠른 체크리스트

보드가 지저분하게 느껴진다면 10분 안에 이유를 찾을 수 있습니다.

10분 보드 스캔

보드를 훑으며 다음 신호를 찾아보세요:

• 모든 상태는 "지금 무엇이 사실인가"에 답하는가?
• 각 상태는 기본 소유자(역할 단위 가능)와 명확한 다음 행동을 가지는가?
• 두 상태가 동시에 같은 항목을 설명할 수 있는 경우는 없는가?
• 항목이 며칠째 결정 없이 방치되어 있지는 않은가(오래 머무를 수 있다면 퇴장 규칙 추가)?
• 동일한 작업 유형이 동일한 핵심 단계를 통과하는가, 예외는 문서화되어 있는가?

사람들이 카드의 위치에 대해 의견이 다르면 그 상태는 다른 상태와 겹치거나 정의가 충분하지 않은 것입니다.

웹 + 모바일 일관성 체크

같은 워크플로우를 폰에서 열어 라벨이 좁은 공간에서도 여전히 통하는지 확인하세요.

• 리스트 뷰에서 라벨이 짧고 잘리지 않는가?
• 색에만 의존하지 않고 텍스트로도 명확한가?
• 상태 변경은 한 책임자(팀 리드나 운영)가 승인하는가, 개인이 임의로 결정하지 않는가?
• 변경 시 간단한 메모를 남겨 정의가 흐트러지지 않게 하는가?

다음 단계: 유지·측정·개선

상태 시스템은 규칙집처럼 다뤄야 유용합니다: 안정적이되 검토는 합니다. 목표는 끊임없는 변경이 아니라 일관된 사용입니다.

가벼운 주기(예: 매월 30분 리뷰)를 정해 보드에 관여하는 역할별로 한 사람씩 참여시키세요. 최근 항목 5~10개를 가져와 예외를 찾아 고칩니다.

추적할 만한 간단한 신호들:

• 차단에 머문 시간(및 주요 원인)
• 두 상태 사이를 왔다 갔다 하는 항목
• 정상 주기 시간을 넘겨 방치된 항목

무언가 이상하다고 느껴질 때 바로 새 상태를 추가하려 하지 마세요. 새 상태는 다음을 만족할 때만 추가하세요: 새로운 상태가 진짜로 다르고, 사람들이 다음에 무엇을 해야 할지를 바꾸며, 자주 발생한다. 대부분의 경우 해결책은 더 간단합니다: 정의를 조여라, 진입 규칙을 추가하라, 소유권을 명확히 하라.

마지막으로, 내부 도구로 워크플로우를 구축한다면 상태를 화면별 텍스트가 아니라 공유 데이터로 취급하세요. AppMaster (appmaster.io)와 같은 도구에서는 Data Designer에서 상태 필드를 한 번 정의하고 웹과 네이티브 모바일 앱 전반에서 재사용할 수 있어 "내 폰에서는 다른 의미" 문제가 줄어듭니다.