홈페이지 제작업체 선정 전 반드시 물어볼 10가지

견적과 시안만으로는 부족한 이유

홈페이지 제작업체를 고를 때 먼저 펼치는 것은 견적서와 화면 시안인 경우가 많습니다. 그런데 계약 뒤에 실제로 멈추는 지점은 다른 데 있습니다. 이 페이지가 산출물에 들어있는지, 관리자 계정은 누구 명의인지, 오픈 뒤에 글을 누가 고치는지. 분위기 좋은 미팅일수록 이 질문들은 뒤로 밀립니다.

질문을 미리 적어 두면 미팅의 성격이 바뀝니다. 소개를 듣는 자리가 아니라 범위와 책임을 확인하는 자리가 됩니다. 아래 열 가지는 흥정 기술이 아닙니다. 서명 전에 해석이 갈라질 지점을 드러내는 질문입니다.

계약서는 나중에 고치기 어렵습니다. 미팅에서 차마 못 물은 내용은, 서명 뒤에는 해석 다툼으로만 남습니다. 질문을 적는 일은 업체를 압박하려는 게 아니라, 우리 쪽 결정 기준을 먼저 세우는 일입니다.

범위와 산출물부터 물어보기

1. 이번 작업의 범위는 페이지 목록인가, 기능 목록인가

페이지 숫자만 적힌 범위는 나중에 해석이 갈라지기 쉽습니다. 회사 소개, 서비스, 문의처럼 이름이 같아도 필요한 입력 항목과 운영 방식이 다를 수 있습니다. 업체에게 페이지 이름 대신, 각 화면이 해야 할 일과 완료의 기준을 말해 달라고 하세요.

산출물 목록도 같이 받으세요. 게시된 페이지만 남기는지, 편집 가능한 관리 화면, 원본 파일, 계정 정보까지 넘기는지. 말로만 들은 산출물은 검수 목록이 되지 않습니다. 범위가 닫히지 않은 채 시안만 오가면, 이후 요청마다 원래 포함이 아니냐는 말부터 나오게 됩니다.

2. 글과 사진, 정책 문구는 누가 준비하고 누가 넣는가

화면은 나왔는데 약관, 개인정보 안내, 채용 공고, 안내 문구가 비어 있는 상황은 드물지 않습니다. 누가 초안을 쓰는지, 누가 최종 문구를 승인하는지, 누가 관리 화면에 입력하는지를 나눠 두지 않으면 오픈 직전 공백이 생깁니다. 사진은 더 그렇습니다. 촬영본, 제공 이미지, 대체 텍스트를 누가 준비하는지가 빠지면 화면만 채워진 빈 페이지가 됩니다.

• 텍스트와 이미지의 준비 주체
• 정책 문구의 검토 주체
• 관리 화면 입력과 검수 주체

계정과 원본은 누구 것인가

3. 도메인, 호스팅, 관리자, 저장소, 디자인 원본의 명의는 누구인가

오픈 날까지 화면이 잘 떠도, 계정이 업체 개인 메일로 만들어져 있으면 이후 수정과 이전이 막힙니다. 담당자가 자리를 옮기거나 메일 계정이 닫히면, 비밀번호를 찾는 일부터 다시 시작됩니다. 도메인, 호스팅, 관리자, 코드 저장소, 디자인 원본을 항목별로 물어보세요. 우리가 보유하는지, 업체가 대신 관리하는지, 대신 관리한다면 접근 권한은 어떻게 공유하는지를 나눠야 합니다.

계정 목록은 홈페이지 관리자만 해당하지 않습니다. 도메인 알림이 가는 메일, 호스팅 결제 명의, 코드 저장소 초대 권한처럼 평소에 잘 안 열어보는 곳이 나중에 발목을 잡습니다. 누가 소유하고 누가 실무로 들어가 보는지를 한 표로 받아 두세요.

4. 업체가 바뀌어도 우리가 바로 들어가 수정할 수 있는가

계약이 끝나거나 담당자가 바뀌는 일은 예외가 아닙니다. 그때 비밀번호를 받아 달라는 요청은 이미 늦은 편입니다. 서명 전에 우리 명의의 관리자 계정과 원본 전달 방식을 확인해 두세요. 접근이 막히면 화면이 정돈된 것과는 별개로 운영이 멈춥니다. 문의 폼의 수신함, 검색 도구, 인증서 만료 알림처럼 눈에 잘 안 보이는 계정도 목록에 넣으세요.

접근성 기준을 명세에 넣을 수 있는지

5. 접근성 성공 기준을 구매 조건이나 검수 항목에 넣을 수 있는가

W3C의 WCAG 2.2는 성공 기준을 명세, 구매, 적합성 점검에 사용할 수 있도록 정리한 문서입니다. 쓰기 편하게 같은 느낌 문장 대신, 어떤 성공 기준을 이번 작업의 검수에 넣을지 물어보세요. 키보드만으로 주요 경로를 이동할 수 있는지, 이미지에 대체 텍스트가 있는지, 명도 대비가 기준에 맞는지처럼, 눈에 보이는 시안 밖에 있는 항목이 실제 사용을 가릅니다.

모든 기준을 한 번에 맞추라고 주장할 필요는 없습니다. 다만 목표 수준이 계약 밖에 있으면, 나중에 들어오는 수정이 범위 다툼이 됩니다. 구매 전에 기준을 적어 두면 검수 때 서로 다른 기억을 덜 가져옵니다.

명세와 구매 조건에 성공 기준을 넣는 일은 WCAG 문서가 이미 전제로 두는 사용 방식입니다. 업체에게 접근성을 신경 쓰는지 막연히 묻기보다, 이번 검수에 어떤 기준을 올릴지 같이 고르자고 하세요.

보안과 개인정보 책임을 나누는지

6. 웹 애플리케이션의 주요 보안 위험을 어떤 목록으로 보는가

문의 폼, 로그인, 파일 업로드, 관리자 화면이 있는 사이트는 소개 페이지만의 작업이 아닙니다. OWASP Top 10은 웹 애플리케이션에서 반복해서 문제가 되는 위험을 요약합니다. 업체가 이 목록을 알고 있는지, 입력값 검증, 권한 구분, 의존 구성 요소 점검을 어떻게 다루는지 물어보세요. 보안을 나중에 붙이자는 말은 범위를 비워 두겠다는 말에 가깝습니다. 관리자 주소가 쉽게 추측되거나, 누구나 같은 권한으로 글을 지울 수 있다면, 화면이 완성돼도 운영 위험이 남습니다.

7. 개인정보, 암호화, 사고 대응의 역할은 누가 맡는가

영국 ICO의 보안 안내처럼, 규제 기관 자료는 보안, 사고, 암호화, 개인정보 책임을 따로 다룹니다. 이 글이 한국 법을 대신 해석하진 않습니다. 그래도 계약서에 역할이 비어 있으면 안 됩니다. 개인정보를 어디에 저장하는지, 접근 권한은 누구인지, 사고가 났을 때 누가 알리고 누가 기록을 남기는지를 물어보세요. 문의 데이터가 업체의 개인 메일로만 쌓이고 있다면, 그 자체로 책임 소재가 흐려집니다.

변경, 검수, 인수인계를 어디에 남기는지

8. 최종 결정은 누가 하고, 범위 밖 요청은 어떻게 기록하는가

시안을 여러 사람이 보면 의견이 쌓입니다. 누가 최종 승인하는지, 범위 밖 요청은 어디에 남기는지를 정해 두지 않으면 작업은 멈추고 해석만 늘어납니다. 변경 기록은 나중에 다툼을 줄이려는 장치가 아니라, 지금 범위를 유지하는 방법입니다. 회의에서 나온 말을 채팅에만 남기면, 시간이 지나 같은 요청이 새 작업처럼 돌아옵니다.

9. 검수 기준과 인수인계 목록은 무엇인가

오픈은 화면이 보이는 순간이 아니라, 우리가 운영할 수 있는 상태가 되는 순간입니다. 검수 항목과 인수인계 목록을 미리 받아 두세요. 목록이 없으면 완료의 기준이 느낌으로 남습니다.

• 페이지와 기능이 범위와 맞는지
• 관리자 계정과 권한 목록
• 도메인, 호스팅, 저장소 접근 방법
• 원본 파일과 문서의 전달 형식

문의 전에 우리 쪽에서 정리할 것

10. 우리가 먼저 준비할 자료는 무엇인가

좋은 질문은 업체만의 숙제가 아닙니다. 우리가 페이지의 목적, 필수 정책 문구, 기존 도메인과 계정 위치, 결정권자를 정리하지 않으면 상대도 범위를 닫지 못합니다. 내부에서 누가 최종 승인자인지만 정해져도, 시안 의견이 한 방향으로 모입니다.

페이지 목적 한 줄, 기존 계정 위치, 결정권자만 적어도 질문이 구체가 됩니다. 자료가 없으면 업체도 범위를 닫지 못하고, 시안만 오가는 대화가 반복됩니다. 첫 문의에 모든 답을 가져올 필요는 없습니다. 다만 빈칸이 어디인지는 알고 가는 편이 낫습니다.

Studio OD 공개 사이트는 홈페이지 작업 범위와 문의 경로를 안내합니다. 문의 전에 위 열 가지를 우리 상황에 맞게 적어 가면, 첫 대화가 소개 시간이 아니라 범위 확인이 됩니다. 금액이나 기간을 이 글에서 단정할 수는 없습니다. 질문 없이 서명하면, 나중에 범위 해석을 다시 해야 합니다.