납기가 밀리면 대부분 제작을 의심합니다
외주로 맡긴 디자인이 예정보다 늦게 끝나면 발주 담당자가 먼저 확인하는 쪽은 디자이너입니다. 어디까지 진행됐는지 묻고 일정을 다시 잡습니다. 다음부터는 며칠 더 여유를 두자고 정리합니다.
그런데 업무 하나가 끝나기까지 걸리는 시간은 한 덩어리가 아니라 적어도 두 구간으로 나뉩니다. 디자이너가 첫 결과물을 만드는 동안이 하나, 그 결과물을 받고 나서 우리 회사가 최종 확정을 내리기까지가 다른 하나입니다. 앞쪽은 맡긴 업체가 좌우합니다. 뒤쪽을 좌우하는 것은 맡긴 우리입니다.
플로우웍스에 쌓인 기록으로 두 구간을 따로 재 봤습니다. 센 업무는 2026년 1월 1일부터 8월 21일까지 완료된 3,183건입니다. 결과물 업로드 기록이 남아 있는지, 요청·업로드·완료 시각의 앞뒤가 어긋나지 않는지 확인해 통과한 건만 넣었습니다. 해마다 운영 방식이 달라져 값이 흔들리므로 집계는 2026년에 완료된 업무로 한정했습니다.
제작은 하루가 안 걸리는데 확인은 나흘이 걸립니다
업무 하나가 끝나기까지
2026년 1월~8월 완료 업무 3,183건, 구간별 중앙값
제작 구간업무를 요청서로 등록한 시각부터 디자이너가 첫 결과물 파일을 올린 시각까지
확인 구간첫 결과물이 올라온 시각부터 업무를 최종 확정한 시각까지
제작 구간 중앙값은 0.89일로 나왔고 확인 구간 중앙값은 4.00일입니다. 평균으로 재도 방향은 같습니다. 제작 2.45일, 확인 4.76일이고 요청부터 확정까지 전체 평균은 7.21일이었습니다.
두 구간의 중앙값은 각각 따로 계산한 값이라 더해도 전체 중앙값(6.89일)이 되지 않습니다. 구간끼리 비교할 때 쓰시고 합계가 필요하면 평균을 보세요.
수정 요청이 한 번도 없던 업무도 확인에 사흘 반이 걸립니다
수정 요청이 한 번도 없던 2,484건에서도 확인 구간 중앙값은 3.66일로 나옵니다. 전체 3,183건의 78.0%가 이 경우입니다. 이 사흘 반 동안 디자이너가 한 일은 없습니다. 결과물은 이미 올라와 있는데 아무도 열어 보지 않았거나, 열어 보고도 확정을 누르지 않은 채로 시간만 지나간 겁니다.
확인 구간이 길다고 해서 그동안 아무 일도 없었던 건 아닙니다. 수정 요청이 오가면 디자이너가 다시 작업하니 그 시간은 확인 구간 안에 들어 있어도 실제로는 제작입니다. 그래서 수정 요청 횟수로 나눠 다시 쟀습니다.
수정 요청 횟수별 두 구간 (중앙값)
| 수정 요청 | 업무 수 | 제작 구간 | 확인 구간 |
|---|---|---|---|
| 없음 | 2,484건 | 0.89일 | 3.66일 |
| 1회 | 423건 | 0.93일 | 4.20일 |
| 2회 | 157건 | 0.91일 | 4.90일 |
| 3회 이상 | 119건 | 0.72일 | 8.06일 |
2026년 1월~8월 완료 업무 3,183건. 고객사가 결과물을 받은 뒤 등록한 수정 요청만 셌습니다.
피드백은 열 시간 만에 오는데 최종 확정은 나흘이 걸립니다
수정 요청이 한 번이라도 들어온 업무에서는 첫 결과물이 올라오고 첫 수정 요청이 도착하기까지 중앙값 0.41일, 약 열 시간이 걸렸습니다. 73.5%는 하루 안에 들어왔습니다.
결과물을 열어 보는 데는 하루가 안 걸리는데 확정에는 나흘이 걸립니다. 본 사람과 확정할 수 있는 사람이 다르기 때문입니다. 실무 담당자는 파일을 열어 고칠 곳을 바로 적어 보냅니다. 하지만 “이대로 나가도 됩니다”라고 말할 권한은 팀장이나 대표에게 있고, 그 사람은 아직 이 파일을 본 적이 없습니다.
확정을 누르지 않아 자동으로 끝난 업무가 35.9%
3,183건 가운데 1,144건, 35.9%는 마지막 결과물이 올라온 지 정확히 7일째에 완료됐습니다. 확정 버튼을 누른 사람은 없습니다. 플로우웍스가 예약해 둔 자동 완료를 시한에 맞춰 실행한 겁니다.
플로우웍스에는 안전장치가 있습니다. 디자이너가 결과물을 올리면 7일 뒤 자동 완료를 예약하고 예정일과 남은 시간을 채팅으로 안내해 드립니다. 그 사이 수정 요청을 등록하시면 예정일을 2주 뒤로 미뤄 드립니다. 고객사가 아무 반응을 하지 않아도 업무가 계속 열린 채로 남지는 않습니다.
누적 전체로 넓히면 이 비중은 12.2%로 내려가는데, 자동 완료가 2025년 12월에 생긴 장치라 그 전에 끝난 업무까지 함께 세기 때문입니다. 반대로 마지막 결과물이 올라온 지 하루 안에 확정된 업무는 41.7%였습니다. 확인에 걸린 날수를 늘어놓으면 가운데가 비어 있습니다. 당일에 끝나거나, 아무도 손대지 않은 채 시한까지 가거나 둘 중 하나입니다.
회사마다 확인 구간이 열 배까지 벌어집니다
확인이 늦는 원인이 업무의 성격이라면 회사가 달라져도 값이 비슷해야 합니다. 그렇지 않았습니다. 2026년에 완료된 업무가 10건 이상인 고객사만 골라 고객사별 확인 구간 중앙값이 짧은 순서로 넷으로 나눴습니다.
고객사를 확인 구간이 짧은 순서로 넷으로 나누면 (고객사별 중앙값의 평균)
| 묶음 | 업무 수 | 제작 구간 | 확인 구간 | 자동 완료 |
|---|---|---|---|---|
| 1번째 (가장 빠름) | 369건 | 1.42일 | 0.68일 | 6.8% |
| 2번째 | 405건 | 1.44일 | 1.49일 | 10.8% |
| 3번째 | 387건 | 2.14일 | 3.20일 | 19.9% |
| 4번째 (가장 느림) | 1,592건 | 2.02일 | 7.34일 | 46.1% |
2026년에 완료된 업무가 10건 이상인 고객사, 업무 2,753건. 자동 완료는 마지막 결과물이 올라오고 정확히 7일째에 완료된 업무의 비중입니다.
가장 빠른 묶음의 확인 구간은 0.68일인데 가장 느린 묶음은 7.34일까지 갑니다. 10.8배 차이입니다. 같은 묶음에서 제작 구간은 1.42일에서 2.02일로 1.4배 벌어지는 데 그쳤습니다. 디자이너도 같은 사람들이고 요청하는 화면도 같습니다. 차이가 나는 곳은 회사 안쪽입니다.
여러 건을 동시에 돌리면 확인 구간만 밀립니다
첫 결과물이 올라온 시점에 그 회사에서 함께 진행하던 업무 수별 (중앙값)
| 동시 진행 | 업무 수 | 제작 구간 | 확인 구간 |
|---|---|---|---|
| 0건 | 135건 | 1.62일 | 1.67일 |
| 1~2건 | 345건 | 1.50일 | 1.72일 |
| 3~5건 | 383건 | 1.82일 | 1.96일 |
| 6~9건 | 286건 | 1.75일 | 1.88일 |
| 10건 이상 | 2,034건 | 0.74일 | 6.75일 |
2026년 1월~8월 완료 업무 3,183건.
업무를 많이 맡기는 회사일수록 배정과 착수가 빨라져 첫 결과물이 더 일찍 나옵니다. 그런데 그것을 확인하는 속도는 반대로 갑니다. 동시에 열 건이 열려 있으면 담당자 한 명이 열 건을 다 열어 봐야 하고 최종 확정을 받아 와야 하는 건도 열 건입니다.
계정에 등록된 인원으로 나눠 봐도 방향이 같습니다. 인원이 7명 이상인 계정에서는 47.7%가 확정 없이 자동 완료됐고(업무 1,809건) 2~3명인 계정에서는 17.5%였습니다(업무 315건). 다만 인원이 많은 계정은 발주량도 많아 두 조건이 겹칩니다. 인원 수 자체를 원인으로 읽지는 마세요. 확인이 멈춰 있는 시간은 회사마다 다르고 그 편차는 제작 쪽 편차보다 훨씬 큽니다.
고칠 것은 확인 속도가 아니라 승인 순서입니다
“결과물 오면 빨리 확인합시다”는 이미 여러 번 나눈 이야기일 겁니다. 그 말로 해결되지 않는 이유는 최종 확정을 내릴 사람이 결과물이 나온 뒤에야 이 일을 처음 보기 때문입니다. 그때부터 일정을 잡고 읽고 판단합니다.
1. 결정권자를 요청서 단계에서 한 번 통과시킵니다
승인자 수를 줄이자는 이야기는 아닙니다. 붙는 시점만 앞으로 당기자는 겁니다. 팀장이 결과물 단계에서 처음 보면 그때부터 검토를 시작하지만 요청서 단계에서 한 번 보고 나면 결과물에서는 승인한 조건대로 나왔는지만 확인하면 됩니다.
요청서를 보내기 전에 결정권자에게 확인받을 것은 세 가지로 충분합니다. 어디에 쓸 물건인지, 안에 들어갈 문구와 숫자가 무엇인지, 예산이 얼마인지입니다. 여기까지 합의해 두면 결과물 단계에 남는 논의는 표현뿐입니다.
2. 확인 마감시각을 요청할 때 함께 적습니다
납기는 요청서에 적으면서 확인 기한은 아무도 적지 않습니다. “9월 2일 오전까지 결과물”이라고 쓴다면 “9월 3일 18시까지 확인 회신”도 같이 적습니다. 그리고 그 시각을 지킬 사람의 이름을 적습니다. 실무 담당자가 아니라 최종 확정을 내릴 사람의 이름입니다.
이 문장은 상대를 압박하려고 넣는 게 아닙니다. 확인 기한이 적혀 있지 않으면 결과물이 도착한 날부터 다른 업무와 순서를 다투게 되고 급한 일이 하나만 끼어들어도 뒤로 밀립니다.
3. 사실 확인은 요청서에서 끝냅니다
지금까지 등록된 수정 요청 4,018건의 본문을 훑어보면 네 건에 한 건 넘게 문구·텍스트·오타를 언급합니다. 한 건에 여러 항목이 섞여 있어 중복으로 셌고, 항목별 비중은 결과물 점검표 글에 있습니다. 색이나 배치는 눈으로 보고 나서야 판단할 수 있습니다. 반면 문구·가격·날짜·연락처는 요청서를 쓰는 시점에 이미 정해져 있어야 하는 값입니다.
이런 요청이 결과물 단계에서 나오면 확인 구간을 두 번 돌게 됩니다. 실무자가 문구를 고쳐 달라고 보내면 디자이너가 반영하고, 그다음에 다시 최종 확정을 기다려야 합니다. 요청서에 최종 문구를 확정해 넣으면 이 왕복을 하지 않아도 됩니다. 수정 요청을 몇 번까지 받을지, 어디까지를 수정으로 볼지는 수정 요청 규정을 정리한 글에 따로 담아 뒀습니다.
요청서 서식에 넣을 네 줄
최종 확정자
이 업무를 두고 “이대로 나가도 됩니다”라고 말할 사람 한 명의 이름을 적습니다. 담당자와 같은 사람이면 그렇게 적습니다.
요청서 사전 확인
용도와 올릴 곳, 들어갈 문구와 숫자, 예산 세 가지를 결정권자에게 승인받고 요청서를 보냅니다.
확인 회신 기한
날짜와 시각을 적습니다. 납기 다음 영업일 18시처럼 고정 규칙으로 정해 두면 매번 정하지 않아도 됩니다.
들어갈 문구와 숫자
가격·날짜·연락처·고지 문구까지 확정본으로 넣습니다. 아직 정해지지 않았으면 미정이라고 적습니다.
우리 회사 숫자를 직접 재는 법
플랫폼을 쓰지 않아도 시각 네 개만 기록하면 두 구간이 나옵니다.
- 요청서를 보낸 시각
- 첫 결과물을 받은 시각
- 첫 회신(수정 요청이든 확정이든)을 보낸 시각
- 최종 확정한 시각
첫 번째와 두 번째 사이가 제작 구간, 두 번째와 네 번째 사이가 확인 구간입니다. 세 번째와 네 번째가 벌어져 있다면 파일을 못 봐서 늦은 게 아닙니다. 승인이 안 나온 겁니다. 두 번째와 세 번째가 벌어져 있다면 결과물을 열어 볼 사람부터 정해지지 않은 것이니 창구를 먼저 정리하는 편이 빠릅니다. 부서마다 따로 요청하던 것을 한곳으로 모으는 방법은 요청 창구를 하나로 모으는 글에 정리해 뒀습니다.
열 건 정도만 기록해도 어느 쪽이 긴지 보입니다. 확인 구간이 더 길다면 다음 요청에서 여유를 둘 곳은 디자이너의 납기가 아니라 우리 회사 일정표입니다.
자주 묻는 질문
플로우웍스에서는 정산 기준일이 업무 완료 시점이라 확인이 일주일 밀리면 디자이너가 정산받는 시점도 일주일 뒤로 갑니다. 같은 디자이너에게 다음 업무를 계속 맡길 계획이라면 이 부분도 함께 보시는 편이 좋습니다.
플로우웍스에서는 디자이너가 결과물을 올린 시점에 자동 완료 예정일을 채팅으로 안내해 드리고 남은 시간과 함께 다시 알림을 보내 드립니다. 시간이 더 필요하시면 업무 화면에서 완료 예정일을 직접 늘릴 수 있고, 수정 요청을 등록하시면 예정일을 2주 뒤로 미뤄 드립니다.
숫자를 줄이는 것보다 순서를 정하는 편이 빠릅니다. 요청서 단계에서 다 같이 한 번 보고 결과물 단계에서는 한 명만 최종 확정을 내리도록 정해 둡니다. 여러 명이 결과물 단계에 동시에 붙으면 서로의 회신을 기다리느라 확인 구간이 그만큼 길어집니다.
업무 하나만 놓고 보면 그렇습니다. 다만 실무에서 더 자주 부딪히는 쪽은 다음 업무입니다. 앞 업무를 확정하지 않은 채로 두면 같은 담당자가 뒤 업무의 결과물까지 함께 떠안습니다. 동시 진행 건수가 늘수록 확인 구간이 길어진다는 것은 위 표에서 확인하실 수 있습니다.



