홈페이지 제작 의뢰를 마치고 1차 시안을 받아보는 순간, 많은 담당자가 비슷한 표정을 짓습니다. 분명히 요구사항 문서를 넘겼고, 킥오프 미팅도 했는데 결과물이 머릿속에 그리던 것과 완전히 다릅니다.
이때 흔히 '개발사가 대충 봤나?'라고 생각하지만, 실제 원인은 조금 더 구조적입니다. 요구사항 문서 자체가 해석의 여지를 너무 많이 남기는 형식으로 작성되어 있는 경우가 대부분입니다.
"모던하고 신뢰감 있는 디자인", "깔끔하면서도 전문적인 느낌" — 이런 표현은 클라이언트에게 명확하게 느껴지지만, 디자이너에게는 수십 가지 해석이 가능한 열린 질문입니다.
'모던하다'는 것이 여백이 많은 미니멀 레이아웃인지, 다크 모드 기반인지, 대형 타이포그래피 중심인지는 사람마다 다릅니다. 레퍼런스 URL 없이 형용사만 있는 디자인 요구사항은 사실상 요구사항이 아닙니다.
"회원가입 기능 필요", "예약 시스템 구현" — 이것은 기능 목록이지, 동작 흐름이 아닙니다. 개발사는 이 문장을 보고 가장 일반적인 형태로 구현합니다.
그런데 클라이언트가 원하는 예약 시스템은 카카오 알림톡 연동, 관리자 승인 후 확정, 취소 시 자동 환불 처리까지 포함한 것일 수 있습니다. 기능명만 있고 유저 플로우(사용자가 어떤 순서로 무엇을 하는지)가 없으면 구현 결과는 복불복이 됩니다.
요구사항 문서 곳곳에 "추후 협의", "디자인 단계에서 결정"이라는 표현이 많을수록 실제 개발이 시작된 뒤 갈등이 집중됩니다. 개발사는 빈 자리를 자신의 판단으로 채우고, 클라이언트는 그 판단이 자신의 기대와 다르다는 것을 결과물을 보고 나서야 알게 됩니다.
실무에서 개발사가 작업을 시작하기 전에 반드시 확인하고 싶은 정보는 크게 세 가지입니다.
"이 페이지에서 방문자가 무엇을 해야 하는가" — 목적 "그 행동을 어떤 순서로 유도할 것인가" — 흐름 "이미 마음에 드는 사례가 있는가" — 기준점
이 세 가지가 갖춰진 요구사항은 형식이 엉성해도 작업이 방향을 잃지 않습니다. 반대로 이 세 가지가 빠진 요구사항은 100페이지짜리 문서여도 해석 충돌이 발생합니다.
레퍼런스 URL을 공유할 때 "이 사이트처럼 만들어주세요"로 끝내면 안 됩니다. 어떤 요소가 좋은지 구체적으로 지목해야 합니다.
예를 들어, "이 사이트의 헤더 영역에서 배경 이미지 위에 텍스트가 올라오는 방식, 그리고 스크롤 시 메뉴가 상단에 고정되는 동작이 마음에 듭니다. 색상 팔레트는 우리 브랜드 색으로 바꿔야 합니다"처럼 쪼개서 전달해야 합니다.
기능 목록 대신 사용자 시나리오 형식으로 작성합니다. "사용자가 예약 버튼을 누르면 → 날짜 선택 캘린더가 뜨고 → 시간대를 고른 뒤 → 이름과 연락처를 입력하면 → 관리자에게 카카오 알림톡이 발송된다"처럼 동사 중심으로 흐름을 적으면 개발사가 누락 없이 구현할 수 있습니다.
계약 시점에 와이어프레임 검수 → 디자인 시안 검수 → 퍼블리싱 검수 → 기능 테스트 순서로 검수 단계를 명시적으로 계약서에 포함시켜야 합니다. 각 단계에서 수정 범위와 횟수를 합의해두면 최종 결과물에서의 충격이 줄어듭니다.
가장 피해야 할 반응은 "전부 다시 해주세요"입니다. 이 말은 개발사와의 관계를 즉각 경직시키고, 추가 비용 분쟁의 씨앗이 됩니다.
대신 "어떤 부분이 왜 기대와 다른지" 항목별로 정리해서 전달하는 것이 효과적입니다. "전체 색감이 너무 밝습니다 → 우리 브랜드 컬러 HEX 값은 #2B3A55입니다", "메인 배너 문구 위치가 왼쪽 정렬이어야 합니다" 같은 방식으로 구체화하면 수정 범위가 명확해지고 재작업 비용도 최소화됩니다.
Q. 요구사항 문서 형식이 따로 정해져 있나요? A. 정해진 형식은 없습니다. 중요한 것은 형식이 아니라 '목적, 흐름, 기준점'이 담겨 있는지입니다. 워드 문서, 노션, 구글 슬라이드 어떤 형태든 이 세 가지가 있으면 충분합니다.
Q. 레퍼런스 사이트가 경쟁사인데 공유해도 되나요? A. 전달해도 됩니다. 개발사는 레퍼런스를 그대로 복사하는 것이 아니라 방향성 파악에 사용합니다. 다만 "이 기능은 참고하되, 이 색상 조합은 피해달라"처럼 맥락을 함께 전달하면 더 좋습니다.
Q. 계약서에 수정 횟수가 명시되어 있는데, 요구사항 오해로 인한 수정도 횟수에 포함되나요? A. 이 부분은 계약서 문구에 따라 다릅니다. 일반적으로 '클라이언트 변심에 의한 수정'과 '요구사항 미반영에 의한 수정'을 구분하는 조항을 초기 계약 시 포함시키는 것이 좋습니다.
Q. 기획을 도와주는 에이전시가 있나요? A. 네. 일부 에이전시는 개발 전 단계에서 정보 구조 설계(IA), 와이어프레임, 사용자 흐름 설계를 함께 진행합니다. 이 과정을 거치면 요구사항 오해로 인한 재작업 가능성이 크게 줄어듭니다.
Q. 홈페이지 제작 기간 중 담당자가 바뀌면 어떻게 해야 하나요? A. 요구사항 문서와 중간 검수 결과물을 문서화해두면 인수인계 시 혼선을 줄일 수 있습니다. 구두 합의 사항도 이메일이나 메신저로 남겨두는 습관이 중요합니다.
홈페이지 제작에서 결과물 불일치는 대부분 나쁜 의도가 아니라 불완전한 커뮤니케이션 구조에서 비롯됩니다. 요구사항을 더 많이 쓰는 것보다, 더 구체적으로 쓰는 것이 핵심입니다.
에이달(ADALL)은 기획 단계부터 클라이언트와 함께 사용자 흐름과 정보 구조를 설계하며, 각 검수 단계에서 명확한 피드백 루프를 운영합니다. 결과물이 기대와 달라 곤란했던 경험이 있다면, 먼저 프로젝트 문의를 통해 현재 요구사항의 빈틈을 함께 점검해보세요.
📞 02-2664-8631 | 📧 master@adall.co.kr 서울특별시 강서구 방화대로31길 2, 5~6층
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기