디자인 수정 요청서, 이렇게 쓰면 재수정이 줄어듭니다

디자인 수정 요청서는 이미 제작된 시안이나 결과물을 검토한 뒤, 변경이 필요한 내용을 구조화해서 전달하는 문서입니다.

여기서 중요한 것은 단순히 수정할 내용을 나열하는 것이 아닙니다.

좋은 수정 요청서는 최소한 다음 질문에 답할 수 있어야 합니다.

이 정보가 명확하면 단순한 수정 목록이 아니라 실제 작업 지시가 됩니다.

수정 요청에서 의외로 자주 빠지는 것이 작업물의 버전입니다.

예를 들어 디자이너는 메인페이지_v3를 보고 있는데 고객이 휴대폰에 저장해둔 v2 이미지를 보면서 수정 요청을 전달하면, 아무리 내용을 구체적으로 작성해도 문제가 생깁니다.

그래서 수정 요청을 시작할 때는 먼저 어느 결과물을 기준으로 검토했는지 명확하게 남기는 것이 좋습니다.

예를 들어 다음 정도면 충분합니다.

작업물: 홈페이지 메인 시안 버전: v3 검토일: 2026.09.09 검토자: 홍길동

PDF라면 페이지 번호까지, 웹페이지라면 URL과 PC·모바일 여부까지 함께 남기는 것이 좋습니다.

반응형 웹처럼 화면 크기에 따라 디자인이 달라지는 작업이라면 모바일 390px, PC 1440px처럼 검토 환경까지 남기면 훨씬 정확합니다.

“상단 부분 수정해주세요.”

이 문장은 생각보다 모호합니다.

상단에 로고, 메뉴, 헤드라인, 설명, 이미지, 버튼이 모두 있다면 디자이너는 요청자가 말한 영역부터 다시 찾아야 합니다.

그래서 위치를 설명할 때는 화면의 구조를 기준으로 특정하는 것이 좋습니다.

예를 들어

메인 페이지 → 첫 번째 화면 → 가입하기 버튼

정도로 계층을 적을 수 있습니다.

이미지나 PDF라면 캡처 위에 직접 영역을 표시하는 것이 가장 확실합니다.

디자인 수정 요청의 목적은 문서를 예쁘게 만드는 것이 아니라 수정해야 할 대상을 찾는 시간을 없애는 것입니다.

수정 요청에서 가장 중요한 부분입니다.

고객이 해결 방법까지 지정해버리는 경우가 많습니다.

“폰트를 24px로 키워주세요.” “버튼을 빨간색으로 변경해주세요.”

물론 정확한 규격이 정해져 있다면 이런 요청이 필요합니다.

하지만 디자인 판단이 필요한 상황이라면 해결 방법보다 먼저 현재 무엇이 문제인지와 어떤 결과를 원하는지를 전달하는 편이 좋습니다.

예를 들어 다음 요청을 비교해보겠습니다.

좋지 않은 요청 “메인 문구를 더 크게 해주세요.” 더 좋은 요청 “메인 화면에서 서비스 설명과 가입 버튼이 비슷한 강도로 보여 가장 먼저 읽어야 할 메시지가 잘 드러나지 않습니다. 처음 화면을 봤을 때 메인 문구 → 설명 → 가입 버튼 순서로 인지될 수 있도록 시각적 위계를 조정해주세요.”

두 번째 요청은 디자이너에게 단순히 글자를 키우라는 명령을 하지 않습니다.

대신 현재 발생한 문제와 수정 후 달성해야 하는 목적을 알려줍니다.

따라서 디자이너는 글자 크기뿐 아니라 굵기, 여백, 대비, 배치 등 더 적절한 방법을 판단할 수 있습니다.

이 차이가 중요합니다.

좋은 디자인 피드백은 디자이너의 해결 방법을 대신 결정하는 것이 아니라 해결해야 할 문제를 명확하게 만드는 것에 가깝습니다.

디자인 수정 요청에는 주관적인 표현이 많이 등장합니다.

“조금 더 고급스럽게.” “요즘 스타일로.” “뭔가 심심해요.” “좀 더 눈에 띄게.”

이런 표현 자체가 잘못된 것은 아닙니다. 문제는 이 문장만으로는 서로 생각하는 결과가 같은지 확인할 방법이 없다는 것입니다.

따라서 주관적인 표현 뒤에 판단할 수 있는 기준을 추가해야 합니다.

예를 들어

“조금 더 고급스럽게 해주세요.”

보다는

“현재는 색상과 그래픽 요소가 많아 프로모션 이미지처럼 보입니다. 장식 요소를 줄이고 제품 이미지와 타이포그래피 중심으로 정리해 브랜드가 조금 더 차분하고 프리미엄하게 느껴졌으면 합니다.”

라고 전달하는 편이 낫습니다.

레퍼런스를 함께 보내는 것도 좋습니다.

다만 “이 사이트처럼 만들어주세요”라고 끝내지 말고, 레퍼런스의 어떤 특징을 참고하고 싶은지 함께 설명해야 합니다.

레이아웃인지, 여백인지, 색감인지, 타이포그래피인지가 명확해야 디자이너가 의도를 제대로 해석할 수 있습니다.

실무에서 수정 요청이 반복되는 가장 큰 원인 중 하나는 ‘수정’과 ‘새로운 요구사항’이 한 문서에 섞이는 것입니다.

예를 들어 처음 합의한 상세페이지를 기준으로 글자 크기나 이미지 배치를 조정하는 것은 일반적으로 기존 방향 안에서의 수정입니다.

반면 1차 시안을 확인한 뒤

“아예 다른 분위기로 다시 보고 싶어요.” “타깃을 20대에서 40대로 바꿔주세요.” “상세페이지에 새로운 섹션 세 개를 추가해주세요.”

와 같은 요청이 들어간다면 단순 수정이 아니라 작업 범위 자체가 달라질 수 있습니다.

그래서 수정 요청을 작성할 때는 요청을 다음 세 종류로 구분해서 판단하는 것이 좋습니다.

이 기준을 프로젝트 초기에 합의해두면 “이것도 수정 횟수에 포함되나요?”라는 갈등도 상당 부분 줄일 수 있습니다.

실무에서는 요청서 내용보다 요청하는 사람이 많아서 문제가 생기기도 합니다.

담당자가 오전에 수정 요청을 전달하고, 오후에는 팀장이 다른 의견을 보내고, 다음 날 대표가 처음 방향으로 다시 돌려달라고 하면 디자이너 입장에서는 어떤 의견이 최종 결정인지 알 수 없습니다.

특히 외주 프로젝트에서는 피드백을 전달하는 사람과 최종 결정권자를 가능하면 한 명으로 정하는 것이 중요합니다.

내부에서 의견이 여러 개 발생하더라도 이를 취합한 뒤 한 번의 수정 라운드로 전달하는 편이 좋습니다.

그래야 수정 횟수뿐 아니라 서로 충돌하는 피드백도 줄일 수 있습니다.

아래 정도의 양식이면 대부분의 디자인 프로젝트에서 사용할 수 있습니다.

프로젝트명: 검토 작업물: 버전: 검토자: 요청일: 수정 완료 희망일: 수정 항목 번호: 수정 위치: 예) 메인 페이지 → 첫 화면 → 메인 카피 영역 현재 상태 / 문제: 예) 제목과 설명의 시각적 차이가 크지 않아 핵심 메시지가 바로 인지되지 않음 수정 목적: 예) 사용자가 첫 화면을 봤을 때 제목을 가장 먼저 읽을 수 있도록 정보 위계를 명확하게 조정 필수 조건: 예) 브랜드 메인 컬러와 기존 문구는 유지 참고 자료: 예) 캡처 이미지 또는 레퍼런스 링크 우선순위: 필수 / 중요 / 선택 처리 상태: 확인 전 / 수정 중 / 반영 완료 / 추가 확인 필요

여기서 중요한 것은 모든 칸을 반드시 채우는 것이 아닙니다.

수정할 사람에게 필요한 정보가 충분하다면 간단하게 작성해도 됩니다.

반대로 프로젝트가 복잡할수록 구두나 메신저로 설명하기보다 이런 구조를 사용하는 것이 효과적입니다.

수정 요청서를 잘 작성해도 카카오톡, 이메일, 전화, 문서, Figma 등 여러 채널로 피드백이 흩어지면 결국 다시 정리해야 합니다.

예를 들어 처음에는 이메일로 요청서가 오고, 추가 요청은 카카오톡으로 오고, 이미지 한 장은 문자로 전달받았다면 어느 요청이 최신인지 확인하는 별도의 작업이 필요해집니다.

그래서 수정 요청서를 작성하는 것만큼 중요한 것이 검토 창구를 하나로 정하는 것입니다.

저도 모아로를 만들면서 이 문제를 특히 많이 고민했습니다.

잘 정리된 수정 요청서를 만들어도 작업물과 요청서가 분리되어 있으면 디자이너는 결국

“이 요청이 화면 어디를 말하는 거지?” “이건 v2에 대한 요청인가, v3에 대한 요청인가?” “이 요청은 반영한 건가?”

를 다시 확인해야 하기 때문입니다.

그래서 가능하다면 작업물과 피드백, 버전, 처리 상태가 서로 연결되어 있는 구조가 가장 좋습니다.

수정이 한두 번 반복되는 것은 디자인 작업에서 자연스러운 과정입니다.

하지만 프로젝트마다 비슷한 이유로 수정이 계속 반복된다면 고객이나 디자이너 개인의 문제로만 볼 필요는 없습니다.

검토 프로세스에 문제가 있을 가능성이 큽니다.

어떤 버전을 검토할지 정해져 있는가. 한 번의 검토 라운드에서 의견을 취합하고 있는가. 최종 결정권자가 누구인지 정해져 있는가. 수정과 작업 범위 변경을 구분하고 있는가. 각 요청의 반영 여부를 확인할 수 있는가. 최종 승인이 언제 이루어졌는지 남아 있는가.

이 질문에 명확하게 답할 수 없다면 수정 요청서를 개선하는 것과 함께 검토 방식 자체를 정리해볼 필요가 있습니다.

좋은 수정 요청서는 길고 자세한 문서가 아닙니다.

수정하는 사람이 다시 질문해야 하는 횟수를 줄여주는 문서입니다.

그래서 수정 요청을 작성했다면 전달하기 전에 한 번만 확인해보세요.

“이 내용을 처음 보는 사람이 어느 화면의 무엇을 왜 바꿔야 하는지 알 수 있는가?”

알 수 있다면 좋은 요청에 가깝습니다.

알 수 없다면 문장을 더 길게 쓰기보다 위치, 현재 문제, 원하는 결과 중 빠진 정보가 무엇인지 확인하는 것이 좋습니다.

그리고 이런 과정이 프로젝트마다 반복된다면 요청서 하나를 잘 만드는 것에서 끝내지 말고 수정 요청을 받고, 반영하고, 확인하고, 최종 승인하는 과정 자체를 하나의 워크플로우로 만드는 것을 권합니다.

모아로도 바로 이 문제에서 시작했습니다.

고객에게 작업물을 전달한 뒤 피드백이 카카오톡과 이메일에 흩어지지 않도록 하고, 작업물 위에서 직접 의견을 남기고, 수정 상태와 버전, 최종 승인까지 한곳에서 확인할 수 있도록 만드는 것이 목표입니다.

디자인을 잘 만드는 것만큼 중요한 것이, 만들어진 디자인을 제대로 검토하고 끝내는 과정이기 때문입니다.