작업을 시작하기 전에 무엇이 승인될지 정하세요.

일반적인 요청을 실제 사용 상황으로 바꾸세요

「내 비주얼을 개선해 주세요」는 파일을 확대하라는 뜻일 수도, 배경을 제거하라는 뜻일 수도, 색을 통일하라는 뜻일 수도, 다른 분위기를 만들라는 뜻일 수도 있습니다. 이 작업들은 같은 기준으로 평가할 수 없습니다. 먼저 결과물이 어디에 쓰일지, 그리고 그 결과물을 받는 사람이 무엇을 할 수 있어야 하는지 물어보세요. 소프트웨어나 GPU 이름은 그다음입니다.

사람, 결과, 용도를 연결하는 문장을 쓰세요: 「매장 담당자가 이 컬렉션의 사진 열두 장을 상품 페이지에서 교체할 수 있어야 한다.」 알려진 제약을 덧붙이고, 아직 열려 있는 질문도 적으세요. GOV.UK의 Service Manual은 사용자 니즈와 그것이 충족되었는지 확인하는 기준을 이렇게 구분할 것을 제안합니다. 여기서는 이 방식을 작은 작업에 맞게 응용합니다.

기대하는 결과물을 다섯 줄로 설명하세요

시작하는 데 긴 요구사항 명세서는 필요하지 않습니다. 좋은 납품을 알아볼 수 있게 해 주는 내용을 적고, 만들기 전에 이 문서를 검토받으세요. 받는 사람이 필요한 형식을 아직 모른다면, 그 사람이 자기 도구에서 열어 볼 수 있는 작은 내보내기 파일을 만들어 보세요. 그러면 불확실성이 구체적인 확인 작업이 됩니다.

아래 표는 각색해서 쓰는 작업 템플릿이며, 대여가 제공하는 기능 목록이 아닙니다. 개인 작업이라면 고객 이름을 자신의 점검 항목으로 바꾸세요. 그래도 결과물이 적합한지는 누군가 결정해야 합니다.

필수 요건과 선호를 구분하세요

차단 요소가 있으면 결과물을 원래 용도로 쓸 수 없게 됩니다. 잘못된 제품, 읽을 수 없게 된 텍스트, 누락된 문서, 열 수 없는 형식 등이 여기에 해당하죠. 반면 선호는 이미 사용 가능한 여러 결과물 중에서 우선순위를 정하는 기준입니다. 이 차이를 시험 전에 분명히 알려주세요. 그렇지 않으면 뒤늦게 나온 미적 판단이 제작 결함으로 오해받을 수 있습니다.

‘아주 예쁜’, ‘똑똑한’, ‘전문적인’처럼 해석에 따라 달라지는 기준은 피하세요. 대신 허용된 예시와 관찰 가능한 항목을 함께 제시하세요. 누락된 영역이 없는 윤곽, 제공된 기준과 일치하는 색상, 올바른 구절에 근거한 답변 등이죠. 판단이 주관적일 수밖에 없다면 누가 최종 결정을 내리는지 명시하고 그 사람의 기준 예시를 보관하세요.

업무와 무관한 제약을 쌓아두지 마세요. 방법을 선택하기 위한 시험은 문서화된 권장 사항과 몇 가지 코멘트가 달린 결과물로 마무리해도 됩니다. 이를 곧바로 배포할 수 있는 완성품처럼 제시해서는 안 됩니다.

예시: 작은 컬렉션을 위한 이미지 열두 장

이 가상의 예시에서 한 프리랜서가 컬렉션의 비주얼을 교체하기 위해 이미지 열두 장을 의뢰받습니다. 최초 요청은 ‘더 깔끔한 결과물’이었습니다. 대화를 거쳐 범위는 다음과 같이 정리됩니다. 1,600 × 1,600픽셀 PNG 열두 장, 흰색 배경에 중앙 정렬된 제품, 로고와 제품 세부 사항은 변경하지 않음. 이 수치는 예시에서 선택한 값이며 온라인 판매 전반에 적용되는 보편적인 규칙은 아닙니다.

그녀는 첫 번째 확인용으로 세 개의 항목을 고릅니다. 밝은 물체, 어두운 물체, 텍스트가 있는 포장재입니다. 고객은 전체 배치 작업 전에 이 샘플들의 구도와 배경을 승인합니다. 테스트한 세 이미지는 열두 장의 결과물에 포함될 수 있으며, 주문 수량에 자동으로 추가되지는 않습니다.

각 결과물에 상태를 부여하고 재작업에 이유를 달아주세요

예시의 첫 번째 검토에서 이미지 아홉 장이 승인되고 두 장은 수정이 필요하며 한 장은 읽을 수 없는 원본 때문에 차단되었다고 가정해봅시다. 총합은 여전히 열두 장입니다. ‘승인’, ‘재작업’, ‘차단’ 상태를 표시한 표가 있으면 남은 작업을 즉시 파악할 수 있습니다. 폴더에 파일 열두 개가 들어 있다는 사실만으로는 같은 결론에 도달할 수 없습니다.

수정 후 두 건의 재작업이 승인됩니다. 결과는 승인 열한 건과 차단된 입력 하나가 됩니다. 따라서 기대한 완전한 납품은 이루어지지 않은 셈입니다. 프리랜서는 사용 가능한 원본을 요청하거나 열한 장으로 범위를 정하는 데 명시적으로 합의합니다. 열두 번째 참조를 목록에서 사라지게 하는 대신 해당 버전과 함께 결정을 보관합니다.

각 피드백에 대해 파일 식별자, 관찰된 결함, 기대하는 변경 사항을 요청하세요. ‘image-007의 텍스트가 왜곡되었으니 원본의 표기를 유지해 주세요’ 정도면 재작업 방향을 잡기에 충분합니다. ‘별로예요’라고만 하면 요청 사항을 처음부터 다시 구성해야 합니다.

검증 일정을 캘린더에 넣고 변경 사항을 처리하세요

샘플과 납품을 검토할 시점을 정하세요. 검증을 담당할 사람이 부재 중이라면 그 지연을 일정에 반영하세요. 예산 가이드에서는 대여 준비, 실제 작업, 대기, 재작업, 내보내기를 구분합니다. 대여를 유지한 채 대기하는 시간은 계산이 돌아가지 않아도 사용 시간을 차지합니다.

새로운 요청이 생기면 실행하기 전에 그 영향을 설명하세요. 이미지 열두 장을 스무 장으로 늘리거나, 형식을 추가하거나, 다른 스타일을 요청하는 것은 범위를 바꾸는 일입니다. 새 수량, 추가 검사, 수정할 일정을 기록하세요. 알려진 결함의 수정과 필요 범위의 확장은 하나의 목록에 뒤섞여 남아 있어서는 안 됩니다.

또한 몇 번의 검토를 진행할지도 합의하세요. 예를 들어 샘플 검토 한 번, 그리고 계획된 재검토 한 번처럼요. 결과가 계속 거부된다면 끝없이 시도를 추가하기 전에 방법과 범위에 대해 다시 논의하세요.

이 문서는 업무 결정을 정리한 것이며, 해당 프로젝트의 상업적 합의를 대체하지 않습니다. 또한 계산 시간을 추산할 수도 없습니다. 선택한 소프트웨어와 파일로 실행 가능한지 확인하려면 첫 번째 시도가 여전히 필요합니다.

이 범위 설정이 실제 결정을 가능하게 하는지 확인하세요

대화 맥락 없이 이 문서를 다시 읽어보세요. 만들어야 할 파일을 명확히 말할 수 있나요? 거부된 출력을 알아볼 수 있나요? 검증 담당자를 찾을 수 있나요? 답이 빠져 있다면 업무를 확장하기 전에 이 부분을 보완하세요. 또한 고객이 제공한 요소(소스 버전, 참고 이미지, 사용 허가)를 확인받으세요.

흔한 실수는 전체 묶음부터 시작하는 것, 생성된 파일을 승인된 결과로 계산하는 것, 그리고 매 시도 후에 기준을 바꾸는 것입니다. 최초 문서를 보관하고 수정 사항을 기록하세요. 어떤 샘플도 요구 사항을 충족하지 못한다면, 방법을 재검토하거나 이 방향을 중단하는 것이 올바른 결정일 수 있습니다. 유용한 범위 설정은 이런 결론을 가능하게 합니다.