우리 조직에 딱 맞게 자유롭게 설정하는 '업무상태' 관리
실제 업무 단계를 반영한 진척상태를 정의하고 프로젝트에 적용하는 방법

어느 IT 회사의 프로젝트 매니저 주찬님은 늘 같은 고민을 하고 있었습니다.
개발팀, 마케팅팀, 영업팀이 모두 플로우로 프로젝트를 관리하고 있었지만, 업무 상태는 늘 똑같이 ‘대기 / 진행 / 완료’로만 표시되고 있었기 때문입니다.
표시는 간단했지만, 실제로는 일이 훨씬 더 복잡했습니다.디자인 시안이 고객사 컨펌을 기다리는지, 개발 이슈가 내부 검토 중인지, 영업 제안이 계약 직전 단계인지, 한눈에 구분하기가 어려웠습니다.
기본 상태칩에서 시작되는 작은 변화
처음에는 플로우에 기본으로 제공되는 상태칩부터 사용했습니다.
업무 작성 창에서 ‘대기, 진행, 피드백, 완료, 보류’ 정도의 상태만 선택할 수 있었습니다.
“일단 ‘대기’로 만들어 둘게요.”
“지금 손 대고 있는 건 ‘진행’으로 바꿔 둘게요.”
하지만 프로젝트가 커질수록 문제가 드러났습니다.
진행이라고 되어 있는 업무 안에도 내부 협의가 필요한 일, 외부 파트너 컨펌을 기다리는 일, QA 검수를 통과하지 못한 일 이 뒤섞여 있었습니다.
상태 이름만으로는 “지금 이 일이 어디까지 왔는지”가 잘 보이지 않았습니다.

상태 설정 편집창으로 ‘우리 팀 언어’를 만들다
주찬 매니저는 상태 설정 편집창을 열고, 팀별로 상태를 다시 설계하기로 했습니다.
여기서 각 상태 그룹(대기, 진행, 완료, 보류)에 원하는 상태를 추가하고, 이름과 색상까지 변경했습니다.
그래서 먼저 공통 구조는 "대기/진행/완료/보류" 이렇게 기준을 맞추고, 그 안에 들어가는 세부 상태는 부서·프로젝트 특성에 맞게 나누었습니다.

1) 개발팀 프로젝트
준비단계: 요구사항 정리 대기, 설계 검토 대기
개발중: 개발 중, 코드 리뷰 중, QA 테스트 중
배포완료: 배포 완료, 핫픽스 완료
보류/재검토: 일정 보류, 사양 변경 검토
2) 마케팅 캠페인
기획준비: 아이디어 수집, 콘텐츠 기획 대기
집행중: 콘텐츠 작성 중, 디자인 의뢰 중, 채널 세팅 중, 집행 중
종료: 캠페인 종료, 리포트 작성 완료
대기보류: 예산 재조정 대기
3) 영업팀 제안 프로젝트
리드확보: 리드 확인, 제안 요청 검토
제안진행: 제안서 작성 중, 미팅 준비 중, 견적 발송 완료
계약종료: 계약 완료, 미계약 종료
고객보류: 고객 결정 보류, 장기 검토 건
이렇게 상태를 바꾸자, 각 팀은 우리 팀이 실제로 일하는 흐름 그대로를 플로우에 담을 수 있었습니다.
색상도 팀별로 직관적으로 보이도록 정리했습니다.
위험하거나 급한 상태는 진한 색, 완료는 차분한 색으로 통일해 한눈에 구분되도록 했습니다.
직급별로 다르게 보이는 화면, 같은 데이터
프로젝트 내의 업무 목록에서는 각 업무 옆에 커스텀한 상태칩이 나열되어 보입니다.
여기서 직급별로 보는 포인트가 달라졌습니다.
실무자
개별 업무를 열지 않고도자신의 업무가 ‘내부 협의 중’인지 ‘컨펌 중’인지 바로 확인하고,
상태를 클릭해 즉시 변경할 수 있어서 더 이상 “이거 어디까지 되었나요?”라는 질문을 덜 받게 되었다고 말했습니다.
팀 리더
전체 업무를 모아보는 화면에서 상태 열 기준으로 정렬하고,특정 상태만 필터링해서 현재 병목 구간을 바로 확인했습니다.
예를 들면 ‘내부 협의 중’만 모아 보면서 “이 부분은 이번 주 안에 의사결정을 끝내야 합니다.”라고 명확하게 지시할 수 있었습니다.
본부장·임원
상세 단계까지는 들어가지 않고,상태칩의 분포만 보고도 “지금은 실행보다 의사결정 대기 건이 많구나.” 같은 흐름을 읽을 수있다고 했습니다.
같은 데이터를 보더라도, 실무자, 리더, 임원이 각자 필요한 깊이에서 프로젝트를 파악할 수 있게 된 것입니다.
실제 이슈 케이스와 해결 과정
이슈 1. ‘진행’ 업무가 너무 많아 우선순위가 보이지 않았던 마케팅팀
이슈: 캠페인 프로젝트에서 대부분의 업무가 ‘진행’으로 묶이면서 어떤 일은 한 달 넘게 진행 상태에 머무르는 일이 생겼습니다.
해결: 마케팅팀은 ‘진행’ 안을 다시 쪼개 아래와 같이 나누었습니다.
내부 검토 중
디자인 의뢰 중
채널 세팅 중
집행 중
리포트 작성 중
이후 팀 리더는 전체 업무 모아보기에서 ‘디자인 의뢰 중’ 상태만 필터링해 디자인팀과 공유하고 우선순위를 정리했습니다.
그 결과, 캠페인 준비 단계에서 막히는 시간이 크게 줄어들었다고 합니다.
이슈 2. 개발 QA 이슈가 메신저와 메일 사이에서 사라지던 개발팀
이슈: 버그 리포트가 여러 채널로 흩어지면서 어떤 이슈는 처리되었는지, 어떤 이슈는 아직 재현되는지 파악하기 어려웠습니다.
해결: 개발팀은 플로우 프로젝트에 아래와 같은 상태칩을 따로 만들었습니다.
버그 접수
원인 분석 중
수정 중
QA 검증 중
배포 완료
이제 QA 담당자는 네 번째 이미지와 같은 전체 업무 모아보기에서 ‘QA 검증 중’만 모아서 오늘 테스트해야 할 목록을 확인하고, 개발자는 ‘수정 중’ 상태만 보고 자신이 맡은 이슈를 관리했습니다.이슈가 메신저에서 잊히는 일은 거의 사라졌습니다.
이슈 3. 새로 합류한 직원들이 팀의 일하는 방식을 이해하기 어려웠던 사례
이슈: 새로운 팀원이 들어올 때마다 “이 일은 어느 단계에서 누구에게 넘어가나요?”라는 질문이 반복되었습니다.
해결: 각 프로젝트에서 상태칩을 실제 업무 흐름 순서대로 정렬했습니다. 그리고 상태 설명에 간단한 가이드를 적어두었습니다.
내부 협의 중: 팀 내부 의견 정리 단계
컨펌 중: 부서장·고객 승인 대기 단계

신입 직원은 업무를 생성할 때 상태 목록만 봐도 “아, 이 팀이 이렇게 일하는구나”를 자연스럽게 이해하게 되었습니다.온보딩 시간이 눈에 띄게 줄었다는 피드백이 나왔습니다.
부서·직급·프로젝트 각기 다른 성향을, 하나의 프로젝트 화면
단계 이름과 색상만으로도 “이 업무는 지금 어디에 막혀 있는지, 누가 도와줘야 하는지, 언제까지 끝나야 하는지”가 명확하게 드러나기 시작했습니다.
단순히 일을 기록하는 수준을 넘어서, 각 부서와 직급, 프로젝트 목표에 맞게 업무 흐름을 설계하고 관리하는 도구로 플로우 상태칩이 활용되고 있습니다.
“예전에는 모두가 같은 ‘진행’ 안에 숨어 있었던 일들이, 지금은 상태칩 하나만 봐도 어디까지 왔는지 바로 보입니다."
"팀의 언어로 프로젝트를 만드는 게 이렇게 중요하다는 걸 깨달았습니다.”
Writer & Editor: 이나영 Graphic: 김유리