하나의 홈페이지를 끝까지 만드는 기록
A SHARED START
짧은 의뢰가
함께 일할 기준이 되기까지.
질문 목록 · 범위표 · 업무 분담표
프로젝트 브리프 v1
“작업 사진을 잘 보여주고, 상담도 받을 수 있으면 좋겠어요.” 홈페이지 제작은 이렇게 짧은 문장으로 시작하곤 합니다. 문제는 이 말을 듣고 각자가 떠올리는 완성 화면이 서로 다를 수 있다는 데 있습니다.
누군가는 사진이 크게 나오는 첫 화면을 생각합니다. 누군가는 업종별로 사례를 찾는 기능을 떠올리고, 다른 사람은 예약 날짜까지 정할 수 있는 상담 시스템을 기대합니다. 같은 의뢰를 받았어도 만들 일은 전혀 달라집니다.
홈페이지 제작 의뢰서는 이런 기대를 함께 확인하는 출발점입니다. 이 글에서는 하나의 가상 의뢰를 질문, 요구사항, 범위와 업무 분담으로 정리해 보겠습니다. 마지막에는 다음 단계로 넘길 수 있는 프로젝트 브리프가 남습니다.
이번 연재의 예제는 기업의 업무 공간을 디자인하는 가상 스튜디오 ‘프로젝트 W’입니다. 공간 기획, 실내 디자인, 가구 제안을 제공하며 사무실 이전이나 공간 개선을 준비하는 기업 담당자를 만나고 싶어 합니다.
아래 대화와 문서, 작업사례 수량은 실습을 위한 설정입니다. 실제 고객의 의뢰나 슬로히어로의 수행 실적을 재현한 것이 아닙니다. 사진 역시 이 예제를 위해 제작한 AI 콘셉트 이미지입니다.
가상의 첫 의뢰
회사 소개와 작업 사진을 보여줄 홈페이지가 필요합니다. 공간이 넓고 시원하게 보였으면 좋겠고, 휴대폰에서도 보기 편했으면 합니다. 관심 있는 분들이 상담을 신청할 수 있고, 나중에는 저희가 작업사례를 직접 추가하고 싶습니다.
이 문장에는 디자인에 대한 기대, 방문자의 행동, 운영 방식이 함께 들어 있습니다. 먼저 요청을 보존한 상태로 나누어 읽습니다. 아직 나온 적 없는 기능까지 의뢰 내용에 섞어 넣지는 않습니다.
해외 참고 사례로는 업무 공간 컨설팅 회사 Sketch Studios를 살펴봅니다. 제작사 MadeByShape는 이 프로젝트에서 브랜드 전략, 콘텐츠, 디자인과 개발을 다뤘다고 공개합니다. 연재에서는 그 회사의 내부 과정을 추정하지 않고, 서비스와 작업사례를 홈페이지에서 연결하는 방식만 참고합니다. 제작 사례 보기
“어떤 디자인을 좋아하세요?”에 앞서 확인할 것이 있습니다. 누가 방문하며, 무엇을 이해하고, 어떤 행동을 하길 바라는지입니다. 고객이 처음부터 전문 용어로 답할 필요는 없습니다. 제작팀이 질문을 통해 답변을 작업 가능한 말로 정리하면 됩니다.
예를 들어 ‘상담 신청’이라는 표현만으로는 문의 폼을 확정할 수 없습니다. 연락처를 보내는 것인지, 희망 시간을 고르는 것인지, 일정이 즉시 확정되는 것인지에 따라 화면과 운영 업무가 달라지기 때문입니다.
프로젝트 W의 첫 상담에서는 다음처럼 질문하고 답변을 기록합니다. 표의 답변은 모두 연재용 가정입니다.
| 확인할 질문 | 프로젝트 W의 예시 답변 | 제작에 미치는 영향 |
|---|---|---|
| 어떤 고객을 만나고 싶은가요? | 사무실 이전·개선을 검토하는 기업 담당자 | 서비스 범위와 비슷한 작업사례를 찾기 쉽게 구성 |
| 문의 전에 무엇을 알아야 하나요? | 무엇을 맡길 수 있는지, 어떤 순서로 진행하는지 | 서비스 설명과 진행 방식에 필요한 원고 준비 |
| 상담 신청 후에는 누가 처리하나요? | 스튜디오 담당자가 내용을 보고 연락 | 우선 문의 접수형으로 검토. 자동 예약 확정은 제외 |
| 사진과 사례 설명은 얼마나 있나요? | 예제 사례 6건을 준비할 예정 | 사진·설명의 준비 상태와 담당자를 따로 관리 |
| 직접 수정하려는 것은 무엇인가요? | 작업사례의 사진과 설명 | 사례 등록 기능 필요. 전체 화면 편집은 별도 판단 |
| 예산과 공개 일정은 정해졌나요? | 아직 협의가 필요 | PM과 고객 책임자가 범위를 보고 착수 확정 전에 협의 |
답이 없는 항목은 ‘미정’으로 남겨도 됩니다. 다만 누가 무엇을 확인해서 언제 답할지까지 적어야 다음 단계가 멈추지 않습니다. 이 예제의 예산과 일정은 확정되지 않았으므로 확정 견적이나 납기를 약속할 수 있는 상태도 아닙니다.
요구사항은 기능 이름을 많이 적는 문서가 아닙니다. 무엇을 만들고, 어떤 상태가 되면 제대로 만들어졌다고 볼지 함께 적는 문서입니다. 요청을 구체화하는 과정에서 고객의 의도가 달라지지 않았는지도 확인해야 합니다.
| 처음 받은 요청 | 이번 예제에서 정리한 요구사항 | 완료를 확인하는 방법 |
|---|---|---|
| 작업 사진을 잘 보여주세요 | 사례별 대표 사진·설명·서비스 분야를 목록과 상세에서 제공 | 지정 사례를 찾아 사진과 설명을 확인하는 경로 점검 |
| 상담 신청을 받고 싶어요 | 문의 내용을 제출하고 담당자가 접수 여부를 확인 | 테스트 문의의 제출·완료 안내·수신을 확인 |
| 나중에 저희가 수정할게요 | 운영자가 사례의 제목·사진·설명을 추가하고 수정 | 운영자가 예제 사례 한 건을 직접 등록 |
| 휴대폰에서도 보기 편하게 해주세요 | 좁은 화면에서도 메뉴·본문·문의 입력을 사용할 수 있게 구현 | 합의한 모바일 환경에서 핵심 행동을 실제 수행 |
| 공간이 넓고 시원하게 보였으면 해요 | 공간 사진의 비율과 여백을 고려한 시각 방향 검토 | 후속 디자인 단계에서 실제 원고·사진을 넣은 시안 비교 |
마지막 요청은 기능처럼 합격 여부를 한 줄로 끝내기 어렵습니다. 따라서 지금은 디자인 방향으로 기록하고, 나중에 시안으로 비교할 것을 정합니다. 아직 보지 않은 화면을 ‘고급스러움 완료’로 처리하지 않습니다.
여기까지의 표는 초안입니다. 2편에서 방문자의 질문과 운영 조건을 더 살펴보면 항목이 바뀔 수 있습니다. 수정된 이유와 날짜를 남겨야 팀이 같은 버전으로 일할 수 있습니다.
‘사례를 보여준다’는 요청에도 여러 구현 범위가 가능합니다. 목록에서 상세로 이동하는 구조로 충분할 수 있고, 검색과 복수 조건 필터가 필요할 수도 있습니다. 가능해 보이는 기능을 모두 첫 공개 범위에 넣으면 자료 준비와 검수 범위도 함께 커집니다.
프로젝트 W에서는 다음 내용을 1차 범위안으로 잡습니다. 예산과 일정 협의, 다음 편의 운영 조건 검토를 거쳐 확정할 제안입니다.
| 구분 | 1차 범위안 |
|---|---|
| 화면 유형 | 홈, 서비스 목록·상세, 작업사례 목록·상세, 소개, 문의의 7가지 |
| 초기 콘텐츠 | 서비스 3종, 연재용 가상 작업사례 6건 |
| 주요 기능 | 모바일 메뉴, 사례 목록·상세 탐색, 문의 접수와 알림, 관리자 사례 등록 |
| 보조 화면 | 개인정보 안내, 404, 문의 완료·오류 상태 등을 별도 목록으로 관리 |
| 이번 범위에서 제외 | 온라인 결제, 회원 기능, 실시간 예약 확정, 다국어 |
| 추가 판단 | 사례 필터, 관리자 수정 범위, 자료 입력 분담, 호스팅과 제작 도구 |
화면 유형 7개와 페이지 주소 7개는 다릅니다. 서비스 상세는 하나의 틀로 여러 서비스를 보여주고, 사례 상세도 같은 틀로 6건을 보여줄 수 있습니다. 견적과 일정에 영향을 주는 것은 틀의 종류뿐 아니라 들어갈 자료의 양, 기능과 상태 화면까지 포함한 작업량입니다.
범위 밖 요청이 나오면 변경 내용을 기록하고 비용·일정·검수에 미치는 영향을 확인합니다. 예를 들어 문의 접수형을 실시간 예약형으로 바꾸려면 예약 가능 시간 관리와 중복 예약 처리까지 검토해야 합니다. 기존 문구만 바꾸고 끝나는 작업으로 보지 않습니다.
제작사가 화면을 만드는 동안 고객 쪽에서도 할 일이 생깁니다. 서비스 설명이 맞는지 확인하고, 공개할 사진을 고르고, 여러 사람의 의견을 모아야 합니다. 이 역할이 비어 있으면 제작팀은 어떤 답변을 기준으로 진행해야 할지 알기 어렵습니다.
Orbit Media의 공개 고객 안내에서도 제작사의 디자인·개발 업무와 고객의 자료 제공·피드백·승인 업무를 구분합니다. 이 원리를 프로젝트 W의 규모에 맞춰 다음과 같이 적용합니다. 아래 분담은 이 연재의 제안이며 모든 제작사가 같은 방식으로 일한다는 뜻은 아닙니다. Orbit Media 고객 체크리스트
| 업무 | 작성하거나 실행할 사람 | 확인하고 결정할 사람 | 넘길 결과 |
|---|---|---|---|
| 의뢰와 미정 사항 정리 | 제작사 PM | 고객 책임자 | 브리프와 질문 목록 |
| 서비스·사례 자료 준비 | 고객 자료 담당 | 고객 책임자 | 사용할 사진과 사실 확인된 설명 |
| 구조와 화면 제안 | 제작사 기획·디자인 | 고객 책임자, 필요한 실무자 | 사이트 구조와 시안 |
| 기능 구현 가능성 검토 | 개발 담당 | PM과 고객 책임자 | 구현 조건과 범위 영향 |
| 피드백 취합 | 고객 책임자 | 고객 내부 결정권자 | 서로 충돌하지 않는 검토 의견 |
| 완료 확인 | 제작팀과 고객 운영 담당 | 고객 책임자 | 미해결 항목과 공개 여부 판단 |
한 사람이 여러 역할을 맡아도 괜찮습니다. 다만 ‘참고 의견을 주는 사람’과 ‘최종 판단을 내리는 사람’은 구분합니다. 실제 이름과 연락 창구는 착수 문서에 기록하고, 이 공개 예제에는 역할 이름만 사용합니다.
예제의 협업 규칙도 간단히 적습니다. 문서마다 기준 버전을 두고, 검토 요청에 필요한 결정과 답변 기한을 함께 씁니다. 서로 다른 의견이 오면 고객 책임자가 먼저 정리하고, 새 요청으로 범위가 바뀌면 PM이 영향을 기록합니다. thoughtbot의 공개 팀 협업 문서 역시 팀별 상황에 맞게 규칙을 조정하도록 설명합니다. thoughtbot Team Charter
PROJECT W / BRIEF 01
| 프로젝트 브리프 v1 | 내용 |
|---|---|
| 프로젝트 | 프로젝트 W 홈페이지 제작 — 연재용 가상 예제 |
| 방문자 | 사무실 이전·개선을 검토하는 기업 담당자와 사업주 |
| 사이트 목적 | 서비스와 작업 방식을 이해하고 적합한 상담을 요청하도록 돕기 |
| 기본 범위안 | 7가지 화면 유형, 서비스 3종, 가상 사례 6건과 보조 화면 |
| 운영 요구 | 담당자가 작업사례를 추가·수정하고 문의를 확인 |
| 자료 책임 | 고객 자료 담당이 준비, 고객 책임자가 사실과 공개 가능 여부 확인 |
| 결정 책임 | 고객 책임자가 의견을 취합, 제작사 PM이 기준 문서 관리 |
| 미정 항목 | 예산·일정, 제작 도구·호스팅, 입력 분담, 필터 필요 여부 |
| 다음 행동 | PM과 고객 책임자가 예산·일정을 착수 확정 전에 협의. 기획·개발·운영 담당이 2편에서 기능과 운영 조건 검토 |
| 확인할 결과 | 서비스·문의 경로를 이해할 수 있는지, 테스트 문의가 접수되는지, 운영자가 사례를 등록할 수 있는지 |
이 문서가 계약과 상세 명세를 대신하는 것은 아닙니다. 당장 공유해야 할 목표와 범위안, 남은 결정을 한곳에 모은 첫 기준입니다. 합의되지 않은 항목에는 담당자와 확인 시점을 붙이고, 다음 단계에서 얻은 정보에 맞춰 갱신합니다.
다음 질문에 답할 수 있다면 첫 상담의 내용을 다음 작업으로 넘길 준비가 된 것입니다. 미정 항목이 있어도 담당자와 확인 시점이 있어야 합니다.
홈페이지 제작 의뢰서를 잘 정리한다는 것은 모든 답을 미리 준비한다는 뜻이 아닙니다. 서로 다르게 이해할 수 있는 말을 확인하고, 지금 정한 것과 다음에 정할 것을 나누는 일입니다. 그 기준이 있어야 기획자와 디자이너, 개발자가 같은 프로젝트를 이어서 만들 수 있습니다.
다음 편에서는 프로젝트 W의 방문자가 던질 질문을 정리하고, 서비스 확인에서 상담 요청까지의 흐름과 운영 조건을 구체화합니다. 제작 도구도 그 조건을 보고 선택하겠습니다.
이 글은 아래 회사가 공개한 업무 자료를 참고해 가상 예제에 적용한 글입니다. 특정 회사의 내부 매뉴얼 전체나 비공개 프로젝트를 재현하지 않았습니다. 자료 확인일은 2026년 10월 2일입니다.
방문자의 질문과
운영 조건부터 정하기