
최종 업데이트: 2026년 10월 21일
디자인 승인 프로세스에서 시간이 새는 곳은 디자인 작업 자체가 아닙니다. 아무도 체계를 잡지 않는 양쪽 끝, 즉 내용이 부실한 채로 들어오는 요청과 아무도 세지 않는 수정 라운드에서 시간을 잃습니다. 앞단은 여섯 가지 답변과 모든 날짜에 붙은 분명한 이유로 해결하세요. 뒷단은 라운드 번호와 지정된 승인자 한 명으로 해결합니다. Quire의 Design Pipeline 템플릿에는 두 가지가 모두 들어 있습니다.
"잠깐만 이것 좀 해 주세요"는 창작 업무에서 가장 비싼 말입니다. 뒤따르는 내용은 대개 기한이 분명한 진짜 요청입니다. 그런데 요청이 아니라 메시지로 도착했기 때문에, 누군가 기억하는 동안에만 존재합니다.
요청자가 여섯 명만 돼도 대기열은 더 이상 대기열이 아닙니다. 각자 자기 요청이 다음 순서라고 믿는 사적인 이해의 모음이 됩니다.
디자인 승인 프로세스는 반복도 견뎌야 합니다. 계약서는 한 번 서명하면 끝나지만, 같은 시안은 서로 다른 버전을 본 사람들이 서너 번씩 결정합니다.
프로세스가 무너지는 곳은 아무도 체계를 잡지 않는 두 지점입니다. 요청이 들어오는 방식, 그리고 첫 번째 검토와 네 번째 검토 사이에 벌어지는 일입니다.
디자인 승인 프로세스: 디자인 작업이 첫 요청부터 기록된 승인에 이르기까지 거치는 경로입니다. 모든 단계가 눈에 보이고, 검토 라운드를 세며, 마지막에 지정된 승인자 한 명이 있습니다.
디자인 승인 프로세스는 Requested, In Design, Internal Review, Awaiting Approval, Changes Requested, Delivered의 여섯 단계로 진행됩니다. 요청은 서면 브리프와 날짜의 이유를 갖추고 들어옵니다. 수정할 때마다 라운드 수가 하나씩 올라가고, 마지막 승인은 지정된 한 사람의 승인으로 요청에 남습니다.
대부분의 팀은 이 처음과 끝을 모두 건너뜁니다.
접수 단계에서 무너집니다. 메시지로 도착한 요청에는 상태가 없어서, 그 요청이 속한 대기열도 보이지 않기 때문입니다. 메시지는 대기 중일 수도, 수락될 수도, 세 번째 순서일 수도 없습니다. 읽음과 안 읽음만 있을 뿐입니다.
그러면 목소리가 큰 요청자가 이깁니다. 판단할 신호가 물량뿐이고, 디자이너가 슬그머니 대기열 역할을 떠안기 때문입니다. 더 나쁜 점은 우선순위를 따질 수 없게 된다는 것입니다. "급해요"를 확인할 기준이 없습니다.
이 문제는 고치기 쉽습니다. 거의 모든 요청에 날짜는 있지만, 이유가 적힌 요청은 거의 없습니다.
이유를 요청에 별도 필드로 적으면 두 종류가 저절로 갈립니다. "인쇄소 마감이 7월 16일이라 여유 없음"은 기한입니다. "정해진 날짜 없음, 현재 템플릿이 모바일에서 깨짐"은 기한이 아닙니다. 둘 다 실제 업무지만, 새치기할 수 있는 쪽은 하나뿐입니다.
Quire에서는 분류 단계가 관문 역할을 합니다. 요청자와 이유가 해당 필드에 없으면 접수 목록을 벗어날 수 없습니다. 그래서 "급해요"를 직접 확인할 수 있게 됩니다.
디자인 대기열은 의견을 낼 수 있는 사람은 많은데 결정하는 사람이 없을 때도 막힙니다. RACI, DACI, RAPID 비교는 아래 모든 내용의 바탕이 되는, 누가 결정하고 누가 조언하는지를 다룬 글입니다.
여섯 가지 답변이 필요합니다. 여섯 가지를 모두 갖춘 요청은 오늘 바로 시작할 수 있습니다. 두 가지가 빠진 요청은 대화로 풀어야 하고, 그 대화에 사흘이 걸립니다.

프로젝트 관리자들은 이 문제를 숫자로 확인했습니다.
요구사항에 관한 PMI의 Pulse of the Profession 조사에 따르면, 실패한 프로젝트의 거의 절반(47%)이 부정확한 요구사항 관리 때문에 목표를 달성하지 못했습니다. 디자인 요청은 축소판 요구사항이고, 모호한 요청도 같은 방식으로 실패합니다. 다만 더 빨리 실패할 뿐입니다.
여섯 가지 중 하나는 별도 필드를 가질 만합니다. 필드가 있어야 답변을 정렬할 수 있기 때문이며, 날짜의 이유는 Why this date 필드가 됩니다.
그 옆에 필드 두 개를 더 둡니다. 요청한 사람을 적는 Requested by, 작업이 몇 번 되돌아왔는지 세는 Review round입니다.
나머지는 업무 설명에 적는 글입니다. 템플릿에는 여섯 가지 전부가 How to request design work 문서로 들어 있어서, 사람들에게 바로 안내할 수 있습니다.
10분이면 직접 확인할 수 있습니다. 무료 Quire 프로젝트를 시작하거나 이미 운영 중인 프로젝트를 열고, Why this date라는 텍스트 필드를 추가한 다음 가장 오래된 진행 중 요청 다섯 개를 채워 보세요. 아마 두 개쯤은 이유가 아예 없을 것이고, 그 순간 논쟁은 끝납니다.
여섯 단계는 Requested, In Design, Internal Review, Awaiting Approval, Changes Requested, Delivered입니다. 이 여섯 단계는 작업이 어디에 있는지를 추적합니다. 결정은 업무에 붙는 승인이라는 별도 기록으로 남기며, 이 둘을 분리해 두는 것이 핵심입니다.
Design Pipeline 템플릿에서 각 단계가 진행되는 방식은 다음과 같습니다.
| 단계 | 진행 내용 | 기록되는 것 | 다음 단계로 넘기는 사람 |
|---|---|---|---|
| Requested | 여섯 가지 답변을 갖춘 요청이 접수 목록에 들어옵니다 | Requested by, Why this date, 마감일 | 분류 담당자가 일정을 잡거나 거절합니다 |
| In Design | 기억이 아니라 서면 브리프를 바탕으로 작업을 시작합니다 | 파일과 질문(업무에 기록) | 디자이너 |
| Internal Review | 팀이 오탈자, 규격, 간격을 먼저 점검합니다 | 업무의 댓글 | 승인자가 보기 전에 팀 동료가 합니다 |
| Awaiting Approval | 완성된 작업이 지정된 승인자 한 명에게 대기합니다 | Creative sign-off의 승인 요청 | 승인자 |
| Changes Requested | 승인자가 수정 사항을 짚고, 작업이 앞 단계로 돌아갑니다 | 피드백, 그리고 Review round에 1 추가 | 다음 라운드를 진행하는 디자이너 |
| Delivered | 승인된 버전이 전달됩니다 | 승인 내용과 승인한 사람, 시점 | 없음(그래서 의미가 있습니다) |
Internal Review는 팀들이 가장 자주 건너뛰지만, 가장 확실하게 값을 하는 단계입니다. 승인자와의 첫 라운드를 모서리 반경이 아니라 아이디어에 쓸 수 있게 됩니다.
Changes Requested는 거꾸로 흐르는 유일한 단계라서 셀 가치가 있습니다. 이 내용은 아래에서 더 다룹니다.
위 표의 모든 단계는 요청하는 팀과 디자인하는 팀 사이의 인수인계입니다. 부서 간 프로젝트 관리 플레이북에서 그 바탕이 되는 책임과 인수인계 구조를 볼 수 있습니다. 먼저 내 파이프라인의 인수인계를 그려 보고 싶다면 비즈니스 프로세스 매핑에서 스윔레인 다이어그램을 포함한 방법을 확인하세요.
바로 쓸 수 있는 디자인 대기열이 들어 있습니다. 위의 여섯 단계, 맞춤형 필드 세 개, 하위 목록 두 개, Creative sign-off 승인 카테고리, 문서 두 개, 대시보드 하나입니다. Quire의 Design Pipeline 템플릿을 열고 Intake: not triaged 하위 목록으로 들어가면, 앞서 한 이야기가 세 줄에 모두 담겨 있습니다.
채용 포스터의 Why this date에는 "채용 박람회가 8월 16일"이라고 적혀 있습니다. 일주일 앞선 마감의 파트너 공동 브랜드 키트에는 "파트너 런칭 날짜 미정"이라고 적혀 있습니다. 같은 대기열, 같은 필드인데 기한은 한쪽뿐입니다.

이런 구성을 가능하게 하는 요소는 다음과 같습니다.
복사하는 데는 1분 정도 걸립니다. 템플릿 이름 옆의 드롭다운을 열고 더 보기에서 사본 생성하기를 선택한 다음, 사본을 둘 조직을 고르세요.

샘플은 내 것처럼 느껴지기 전에 지우세요. 두 번 문제가 생기기 전에는 네 번째 필드를 추가하지 마세요. 세 개는 채워지지만 여섯 개는 무시되고, 무시되는 필드는 데이터처럼 보이기 때문에 없는 것보다 나쁩니다.
Design Pipeline은 Quire 라이브러리에서 단계형 파이프라인에 해당하는 템플릿입니다. 프로젝트 관리 템플릿 모음은 나머지 템플릿을 유한형, 반복형, 단계형 업무로 나누어 정리해, 다음에 필요한 템플릿을 쉽게 찾게 해 줍니다.
요청이 업무가 되면, 메시지 스레드가 하지 못하던 일을 파이프라인 단계가 해 주기 때문입니다. 프로젝트를 열면 누구나 샘플 데이터에서 네 건은 승인자에게 가 있고 세 건은 아직 분류 전이라는 것을 바로 알 수 있습니다. 디자이너에게 읊어 달라고 부탁할 필요가 없습니다.
이것이 창작 업무에서 업무 관리 소프트웨어가 하는 일의 전부입니다. 모든 요청에 단계와 담당자, 대기 순서가 생깁니다. 채팅 스크롤은 이 일을 단 한 번도 해내지 못했습니다.
이 역할의 대부분은 두 하위 목록이 맡습니다. 하위 목록은 메인 목록 옆에 두는, 프로젝트의 저장된 일부분입니다. 둘 다 모두에게 보이고, 승인 열을 켜면 각 행의 판정도 함께 보입니다.
Waiting on a decision에 사흘째 머문다면 누군가 결정을 피하고 있을 가능성이 큽니다.

하나의 구분이 어디를 볼지 결정합니다.
Awaiting Approval 단계는 공용 대기열로, 정렬할 수 있고 월요일에 검토하는 대상입니다.
승인 및 요청 위젯은 나만의 받은편지함입니다. 내가 처리할 승인과 내가 보낸 요청을 세기 때문에, 둘 다 해당 없는 사람에게는 0으로 표시됩니다. 팀 단위의 질문에 답하는 것은 앞쪽뿐입니다.

이미 전용 도구에서 시안에 핀을 꽂아 가며 검토하고 있나요? 마크업에는 그 도구를 계속 쓰고, 시안 링크는 요청에 붙여 넣으세요. 대기열, 라운드 수, 승인은 팀 전체가 볼 수 있는 업무에 그대로 남습니다.
외부 검토자는 디자인 자체보다 계정 만들기에서 더 자주 막힙니다. 보기만 하면 되는 클라이언트는 계정 없이 링크만으로 열 수 있고, 원하면 하위 목록 하나로 범위를 좁힐 수도 있습니다. 방법은 클라이언트가 가입하지 않고도 프로젝트를 공유하는 방법에서 확인하세요.
예산이 수정할 때마다 조금씩 새어 나가는데, 일반적인 환경에서는 이를 기록하는 곳이 없습니다. 1라운드는 괜찮습니다. 예산이 바닥나는 건 4라운드인데, 그 사이 구간을 다루는 프로세스 문서는 거의 없습니다.
그래서 라운드를 세야 합니다. Review round 필드는 막연한 헛바퀴 느낌을 정렬 가능한 열로 바꿔 줍니다. 한 라운드는 정상이고 두 라운드는 괜찮지만, 3라운드가 몰려 있다면 디자인 문제의 탈을 쓴 접수 문제입니다. 브리프가 잘못된 것이고, 다시 그려도 브리프는 고쳐지지 않습니다.
나머지 절반은 라운드 안에 무엇이 담기느냐입니다. 7개 기업의 직원 264명을 대상으로 한 연구에서 Zhenxing Gong과 Na Zhang은, 지지적인 피드백 환경이 사람들의 기분을 거쳐 간접적으로 창의적 성과에 기여한다는 사실을 발견했습니다.
연구진의 결론은 이렇습니다. "지지적인 상사 피드백 환경을 조성하는 것은 창의적 성과를 높이는 데 매우 중요하다." 설문 데이터이므로 인과를 조절하는 수단이 아니라 상관관계로 읽어야 하지만, 요점은 유효합니다. 피드백은 작업에 대한 반응이 아니라 작업의 일부입니다.
그래서 꼭 지킬 규칙이 하나 나옵니다. 피드백은 감정이 아니라 바꿀 내용을 말해야 합니다.
"느낌이 안 와요"는 수정 요청이 아닙니다. "375px에서 배지가 카드 밖으로 나가 있어요"는 수정 요청입니다. 바꿀 내용을 말하지 못하는 검토자는 아직 검토할 준비가 안 된 것이고, 일찍 그렇게 말해 주는 편이 세 라운드 동안 추측하게 만드는 것보다 친절합니다.
Quire에서는 그 피드백이 파일과 함께 업무에 남습니다. 그래서 2라운드는 1라운드와 같은 시안을 기준으로 시작하고, 검토자는 다른 것을 요청하기 전에 지난번에 무엇을 요청했는지 볼 수 있습니다.
템플릿의 사례 연구 원페이저에 실제 예시가 있습니다. 위 목록에서 Creative sign-off: 수정 요청으로 표시된 두 행 중 하나입니다.
이 요청은 2라운드이고, 두 가지 수정 사항을 짚은 댓글이 달려 있습니다. 고객 인용문에 빠진 직함, 그리고 본문 카피와 맞지 않는 수치입니다.
그리고 그 댓글은 1라운드에서 이미 승인한 부분을 명시적으로 지켜 줍니다. 이 점이 생각보다 중요합니다. 이미 정리된 결정을 다시 여는 순간 2라운드가 5라운드가 되기 때문입니다.
클라이언트 작업은 이 문제의 볼륨을 키운 버전입니다. 수정 요청이 우리 팀 밖에서 들어오기 때문입니다. 혼란 없는 에이전시 프로젝트 관리에서 비용을 내는 쪽이 검토자일 때 라운드에 상한을 두는 방법을 다룹니다.
결정 하나에 한 사람이 승인하고, 결정은 요청 자체에 기록됩니다. 승인자가 두 명인 디자인은 승인자가 없는 것과 같습니다. 템플릿은 Creative sign-off 카테고리를 사용하므로, 결정이 한 공간이 아니라 지정된 승인자에게 붙습니다.
어떤 결정이 그 사람의 몫인지도 업무에 적어 두세요. "컬러 팔레트가 아니라 워드마크 락업을 승인해 주세요"라는 한 줄이, 검토자가 아무도 묻지 않은 질문에 답하는 가장 흔한 검토 탈선을 막아 줍니다.
과정은 짧습니다. 요청을 열고 Creative sign-off에서 승인을 요청하면 그 사람에게 전달됩니다. 그 사람은 승인하거나 수정을 요청합니다.
어느 쪽이든 답변은 요청에 남습니다. 수정을 요청하면 작업이 한 라운드 되돌아가므로 Review round가 1 올라갑니다.
설정 하나가 승인을 진짜 관문으로 만듭니다. 프로젝트 설정의 상태에서 승인이 보류 중인 동안 완료를 막는 옵션을 켜면, 승인자가 승인하기 전에는 어떤 업무도 Delivered에 도달하지 못합니다.

사본을 만들자마자 바꿔야 할 것이 하나 있습니다. 샘플은 Creative sign-off에 승인자가 두 명 지정된 채로 제공됩니다. 프로젝트 설정에서 실제 검토자를 지정하고 한 명으로 줄이세요. 승인자가 두 명인 디자인은 다시 승인자가 없는 상태가 되기 때문입니다.
승인은 Premium 이상의 Quire 요금제에서 사용할 수 있습니다. 여섯 단계 파이프라인을 구성하는 맞춤 상태는 무료 요금제를 포함한 모든 요금제에서 제공됩니다. 자세한 내용은 요금제 페이지에서 확인하세요.
각 기능의 작동 방식은 별도 글로 정리해 두었습니다. 맞춤 상태로 만든 승인 흐름과 전용 승인 기능입니다. 이 글은 두 기능이 전제로 하는 계층, 즉 승인에 요청을 공급하는 대기열을 다룹니다.
하나만 가져간다면 라운드 카운터를 가져가세요. 3라운드에 접어든 디자인은 거의 언제나 디자인 문제가 아니며, 그것을 다시 그리느라 쓰는 시간은 모두 증상만 치료하는 데 쓰는 시간입니다.
업무 관리 소프트웨어에서 라운드를 세면, 증거가 알아서 상류를 가리킵니다. 만들 수 없을 만큼 모호했던 그 요청입니다. 나머지는 거기서 따라옵니다.
Design Pipeline 템플릿에는 카운터, 접수 목록, 여섯 가지 답변이 담긴 요청 문서가 이미 갖춰져 있어서 다음 걸음은 작습니다. 지금 요청이 들어오는 채널에 요청 문서를 붙여 넣고, 이번 주 요청 중 여섯 가지에 모두 답할 수 있는 것이 몇 개인지 확인해 보세요.
Quire 가입하기를 하고, 파이프라인을 복사해서 다음 디자인 요청을 그 안에서 진행해 보세요.
누군가 창작물을 요청한 때부터 지정된 한 사람이 승인하기까지의 경로이며, Requested에서 Delivered까지 여섯 단계로 이루어집니다. Quire의 Design Pipeline 템플릿은 이 단계를 상태로 제공하고, 앞단에는 요청 문서를, 뒷단에는 기록되는 승인을 둡니다.
사람들에게 더 나은 접수 창구를 주고, 그쪽이 더 빠른 길이 되게 하세요. 템플릿에는 요청에 필요한 여섯 가지 답변을 담은 요청 문서와, 새 요청이 Requested 상태로 들어오는 접수 하위 목록이 들어 있습니다.
한 라운드는 정상이고 두 라운드는 괜찮으며, 세 라운드면 대개 작업이 아니라 브리프가 잘못된 것입니다. Review round 필드는 이것을 느낌이 아니라 정렬 가능한 열로 만들어 줍니다.
결정 하나에 한 사람이며, 그 사람이 자신의 결정이 무엇인지 알고 있어야 합니다. Quire의 승인 카테고리는 결정을 채널이 아니라 사람에게 붙여 줍니다.
보기만 하면 되는 클라이언트는 가입 없이 링크 공유하기로 열 수 있고, 원하면 하위 목록 하나로 범위를 좁힐 수 있습니다. 결정하는 클라이언트는 지정된 승인자로 프로젝트에 참여하므로, 승인이 요청에 남습니다.
네. Quire에서는 요청마다 업무가 되고, 단계마다 상태가 되며, 승인은 업무에 붙는 승인이 되므로 대기열, 라운드, 결정이 하나의 기록에 모입니다.
다시 그리는 일이 줄어듭니다. Quire에서 검토 라운드를 세면 3라운드가 어디에 몰려 있는지 보입니다. 그 브리프를 고치면 같은 시안에 두 번 비용을 쓰지 않게 되고, 디자이너는 재작업에 쓰이던 시간을 돌려받습니다.