https://slohero.com/blog/ 슬로히어로의 홈페이지 기획·디자인·개발·운영 가이드 ko Fri, 02 Oct 2026 06:33:52 +0000 https://slohero.com/blog/weebly-shutdown-migration 1. 이전처 선택보다 자료 회수가 먼저입니다 사이트가 공개되지 않아도 바로 자료를 포기할 단계는 아닙니다. 공식 안내상 계정 접속은 2026년 12월 26일까지 가능하며 그 기간에 자료와 도메인을 옮기도록 안내합니다. 먼저 종료 후 자료 내보내기 안내 에 따라 Download My Data와 사이트별 Archive를 진행하세요. 파일을 실제로 열어 확보한 자료와 부족한 자료를 구분한 뒤 새 서비스의 가져오기 가능 여부를 판단합니다. 2. 옮길 자료와 다시 만들 기능을 나누세요 내용: 소개 글, 사진, 블로그, 상품 정보를 정리합니다. 기능: 문의 폼, 예약, 회원, 결제, 배송, 알림을 목록으로 만듭니다. 주소: 도메인과 기존 주요 URL을 확보합니다. 운영: 주문·문의 등 기록의 확보 범위와 관리 담당자를 정합니다. 원고와 사진을 가져오는 일과 예약·결제 기능을 다시 연결하는 일은 다릅니다. 내보내기 파일이 있다고 기존 디자인과 기능이 새 서비스에서 그대로 실행된다고 가정하지 마세요. 3. 새 홈페이지는 필요한 기능을 기준으로 고르세요 현재 필요 검토할 구성 계약 전에 확인 소개·연락처·사진 간단한 홈페이지 빌더 또는 정적 사이트 도메인 연결, 직접 수정 방법, 사진·원고 이전 범위 상담·예약 폼과 예약을 제공하거나 연결할 수 있는 서비스 알림 수신, 개인정보 처리, 예약 중복 방지 상품 판매 국내 결제·주문·배송을 지원하는 쇼핑몰 구성 기존 상품 자료의 가져오기, 결제 심사, 주문 기록 보관 기존 디자인 유지 재구축이 가능한 제작 방식 확보한 화면·파일로 재현 가능한 범위와 유지보수 담당 아임웹·Wix·카페24·워드프레스 등 이름만 비교하기보다, 확보한 파일을 후보 서비스에 실제로 넣을 수 있는지 확인하세요. 요금과 기능은 바뀔 수 있으므로 현재 제공 범위와 이전 비용을 별도로 확인합니다. 4. 자료 회수와 새 사이트 제작을 병행하세요 현재: 계정 접근과 자료 내려받기를 시작하고, 원본 파일을 별도로 보관합니다. 자료 확인 후: 최소한의 소개·연락처 페이지를 준비하고, 원고와 사진을 옮깁니다. 공개 전: PC·모바일, 문의 알림, 예약·결제, 주요 링크를 시험합니다. 마무리: 도메인과 이메일 연결을 확인하고 이전 완료 기록을 남깁니다. 제작이 오래 걸리더라도 자료 확보를 뒤로 미루지 마세요. 다운로드 오류나 도메인 이전 제한이 발견되면 대응 시간이 필요합니다. 접속 종료일에 맞춰 마지막 작업을 몰아두는 방식은 피합니다. 5. 도메인과 검색 주소를 함께 정리하세요 Weebly에서 도메인을 구입했는지, 외부 등록기관에서 연결만 했는지부터 구분합니다. 전자는 이전 잠금과 인증코드, 후자는 새 호스팅을 가리키는 DNS 설정을 확인해야 합니다. 업무용 메일이 연결되어 있다면 MX 등 관련 설정도 함께 기록합니다. 가능하면 주요 페이지의 기존 주소 구조를 유지하세요. 변경이 필요하면 자신이 제어할 수 있는 서버·호스팅에서 옛 경로를 새 경로로 연결합니다. 접근 권한이 없는 Weebly 공용 하위 도메인에 임의로 301 이동을 설정할 수 있다고 가정해서는 안 됩니다. 기존 도메인과 검색 주소를 정리하는 방법 도 참고하세요. 이전은 검색 순위 유지 보장이 아니며, 새 사이트 공개 후 수집 상태를 따로 확인해야 합니다. 6. 종료 후 자주 묻는 질문 9월 27일이 지났으면 자료를 못 받나요? 공식 안내는 12월 26일 계정 접속 종료 전 자료 다운로드를 안내합니다. 공개 사이트 주소가 열리지 않는 것과 관리자 계정에서 내보내는 것은 별개입니다. 계정 로그인과 메뉴부터 확인하세요. 백업 파일 하나로 새 사이트가 완성되나요? 아닙니다. 자료 포함 범위, 새 서비스의 가져오기 지원, 필요한 기능을 확인해야 합니다. 다운로드 후 파일을 열어 검수하는 단계가 필요합니다. 자료를 받으면 계정을 바로 삭제해도 되나요? 자료 누락, 도메인 이전, 연결 서비스 점검이 끝난 뒤 판단하세요. 작업 중 필요한 접근 경로를 먼저 닫지 않는 편이 좋습니다. 7. 공식 안내와 확인 범위 종료 일정과 자료 회수 경로는 2026년 9월 28일 확인한 Weebly 공식 종료 안내 를 기준으로 갱신했습니다. 개별 고객 계정의 내보내기 결과까지 확인한 것은 아닙니다. 이 글은 종료 후 이전 순서를 정리한 안내입니다. 실제 작업 범위는 확보한 파일, 도메인 상태, 필요한 기능을 확인한 뒤 정해야 합니다. Fri, 28 Aug 2026 00:00:00 +0900 https://slohero.com/blog/weebly-shutdown-migration https://slohero.com/blog/weebly-backup 1. 사이트가 닫혀도 자료를 가져올 기간은 남아 있습니다 한국을 포함한 종료 대상 국가의 공개 사이트는 2026년 9월 27일 게시 중단 일정입니다. 하지만 공식 안내는 12월 26일까지 계정에 접속해 사이트·도메인·데이터를 다른 서비스로 옮길 수 있다 고 명시합니다. 2026년 9월 28일 현재, 먼저 할 일은 공개 주소를 긁는 작업이 아니라 관리자 계정에 로그인해 제공되는 내보내기를 실행하는 것 입니다. 로그인 종료일과 모든 데이터의 실제 삭제 시점은 같은 뜻이 아닙니다. 공식 문서만으로 모든 데이터가 그날 즉시 삭제된다고 단정하지 않습니다. 2. Download My Data와 Archive를 확인하세요 계정 자료: Account Settings → My Data → Download My Data 에서 내려받기를 진행합니다. 특정 사이트 자료: Website → Edit Site → Settings → Archive를 확인합니다. 여러 사이트가 있다면 사이트별로 점검합니다. 보관: 받은 원본 파일을 별도 폴더에 보관하고 복사본을 만들어 내용 확인과 이전 작업을 진행합니다. 이는 공식 종료 안내가 제시한 경로입니다. 실제 계정에서의 다운로드 완료나 파일 구성을 대신 검증한 것은 아닙니다. 메뉴가 없거나 오류가 나면 계정 소유자가 Weebly 지원팀 에 내보내기 문제를 문의하세요. 3. 다운로드 완료보다 파일 내용 확인이 중요합니다 파일이 내려받아졌다는 사실만으로 새 사이트 복원이 끝나지는 않습니다. 내 사이트에 필요한 자료가 실제로 들어 있는지 부터 대조하세요. 자료 확인할 내용 페이지와 이미지 소개·서비스·연락처 원고, 사진 원본, 메뉴와 페이지 목록 블로그와 상품 게시글·상품 수와 실제 내보낸 자료의 대응 여부, 제목·본문·가격·옵션 운영 자료 주문·문의·회원 등 필요한 기록의 포함 여부와 별도 내보내기 가능 여부 주소와 연결 정보 기존 URL, 도메인 등록기관, 연결된 이메일·외부 서비스 목록 위 표는 확인 목록이며 특정 내보내기에 모든 항목이 포함된다는 보장은 아닙니다. 빠진 항목은 접근 가능한 관리 화면, 기존 원본 파일, 알림 메일 등과 대조하고 별도로 보관하세요. 개인정보가 담긴 파일은 공개 폴더에 올리지 않습니다. 새 서비스가 Weebly 내보내기 파일을 자동으로 불러올 수 있는지도 별개입니다. 실제 파일을 확인한 뒤 가져오기 또는 수동 재구축 범위를 정하는 것이 안전합니다. 4. 도메인 이전도 계정이 열려 있을 때 진행하세요 Weebly에서 도메인을 구매했다면 Dashboard의 Websites → Domains에서 해당 도메인의 Manage → Manage Domain으로 이동해 이전 잠금과 EPP 인증코드를 확인합니다. 이후 절차는 새 등록기관에서 진행합니다. 공식 안내에는 신규 등록 또는 등록자 연락처 변경에 따른 60일 이전 제한 이 설명되어 있습니다. 이전 직전에 연락처부터 바꾸지 말고 현재 제한 여부를 확인하세요. 국가별 도메인은 절차가 다를 수 있으므로 지원팀에 확인합니다. 외부 등록기관에서 구입한 도메인을 연결만 했다면 등록기관 이전이 필요한지부터 구분합니다. 새 사이트 연결 전에 기존 DNS 설정과 이메일 관련 기록을 보관하세요. 도메인 연결을 바꾼 후에는 웹사이트뿐 아니라 업무용 메일도 점검합니다. 5. 공개 사이트 백업 명령은 종료 후 복구 방법이 아닙니다 이전 버전의 글은 공개 사이트가 살아 있을 때 HTML·이미지를 내려받는 방법을 먼저 안내했습니다. 게시 중단된 주소에 같은 명령을 실행해도 사라진 원본을 복구할 수는 없습니다. 지금은 공식 계정 내보내기를 우선 사용하세요. 과거에 보관한 HTML·이미지·화면 캡처가 있다면 복구 자료로 함께 활용할 수 있습니다. 웹 아카이브의 과거 화면은 누락과 시점 차이가 있으므로 완전한 백업 대신 보조 자료로 취급합니다. 6. 12월 26일 직전까지 기다리지 마세요 계정 로그인과 소유자 이메일 수신 여부를 확인합니다. Download My Data와 사이트별 Archive를 진행합니다. 내려받은 파일을 열어 핵심 페이지·사진·운영 자료를 대조합니다. 빠진 자료를 지원팀에 문의하고, 도메인 이전 제한을 확인합니다. 새 사이트를 구성하고 도메인·문의 폼·이메일을 시험합니다. 2026년 12월 26일은 공식 계정 접속 종료일 입니다. 정확한 종료 시각·시간대가 안내되지 않았으므로 마지막 날 완료를 전제로 계획하지 마세요. 자료 확인과 이전이 끝나기 전에는 계정 삭제를 요청하지 않습니다. 이전할 곳을 고르는 기준은 위블리 종료 후 이전 안내 , 기존 주소 정리는 도메인과 검색 주소 이전 글 에서 이어서 볼 수 있습니다. 7. 확인한 공식 근거 2026년 9월 28일 Weebly 공식 종료 안내 의 고객 영향·해야 할 일·도메인 이전 항목을 직접 확인했습니다. 해당 문서는 한국을 대상 국가에 포함하고, 9월 27일 게시 중단과 12월 26일 계정 접속 종료를 구분합니다. 문서 첫 문단에는 별도의 서비스 정리 날짜도 표시되어 있습니다. 이 글은 고객 행동에 직접 연결되는 상세 일정과 자료 다운로드 안내를 기준으로 작성했습니다. 계정별 접근 상태와 내보내기 결과는 직접 확인해야 합니다. Tue, 25 Aug 2026 00:00:00 +0900 https://slohero.com/blog/weebly-backup https://slohero.com/blog/website-renewal-content-audit 홈 / 블로그 / 제작 기준과 기획 SLOHERO / WEBSITE PLANNING 홈페이지 리뉴얼 콘텐츠 정리: 남길 페이지·합칠 페이지·삭제할 페이지 홈페이지 리뉴얼 전에 기존 페이지를 보존·수정·통합·삭제로 분류하는 방법입니다. 콘텐츠 정리표와 URL 이동 예시, 공개 전후 SEO 점검 항목을 제공합니다. 슬로히어로 · 제작 기준과 기획 · 2026년 9월 26일 이 글에서 살펴볼 내용 1. 화면이 아니라 URL 목록부터 확보하기 2. 보존·수정·통합·삭제를 나누는 판단표 3. 가상의 기업 서비스 사이트를 정리해보기 4. URL을 바꿀 때는 대응되는 내용으로 연결하기 5. 바로 사용할 수 있는 콘텐츠 정리표 6. 공개 전과 공개 후에 나눠 검수하기 자주 묻는 질문 홈페이지 리뉴얼은 새 화면을 만드는 일과 함께 기존 정보의 역할을 다시 정하는 작업 입니다. 오래됐다는 이유만으로 페이지를 지우거나, 검색 유입이 있다는 이유만으로 틀린 정보를 그대로 남기는 것은 피해야 합니다. 고객에게 필요한지, 정보가 정확한지, 다른 페이지와 겹치는지, 외부에서 연결되어 있는지를 함께 확인하세요. 각 URL을 목록으로 만든 뒤 보존·수정·통합·삭제 중 하나로 분류하고, 주소가 달라진다면 대응 페이지를 기록합니다. 디자인 시작 전에 이 정리표를 만들면 새 사이트의 분량과 원고 준비 범위를 더 정확하게 정할 수 있습니다. 1. 화면이 아니라 URL 목록부터 확보하기 현재 사이트의 메뉴에 보이는 페이지만 조사하면 빠지는 자료가 생길 수 있습니다. 검색으로 방문하는 글, 이전 캠페인, 파일 다운로드, 숨겨진 상세 페이지까지 확인하세요. CMS 목록과 사이트맵, 방문 분석, 검색 도구, 내부 링크를 함께 살펴보는 방식이 도움이 됩니다. 각 주소에는 페이지 제목, 역할, 담당자, 마지막 확인일을 붙입니다. 방문이나 검색 자료를 사용한다면 기간과 출처를 기록합니다. 특정 달에 방문이 적었다는 사실만으로 계절성 안내나 기존 고객 지원 페이지가 불필요하다고 판단해서는 안 됩니다. 분석 자료가 없으면 ‘미확인’으로 적습니다. 데이터가 없다는 것과 방문자가 없다는 것은 다릅니다. 담당자에게 고객 사용 여부를 확인하고, 외부에 배포한 링크나 QR 코드, 계약 후 안내 자료에서 해당 주소를 사용하는지도 살펴보세요. 2. 보존·수정·통합·삭제를 나누는 판단표 2. 보존·수정·통합·삭제를 나누는 판단표 — 비교·점검표 분류 선택하는 상황 필요한 작업 보존 현재도 정확하고 고객에게 필요한 고유 정보 주소 유지, 새 디자인 적용, 연결 확인 수정 목적은 유효하나 조건·표현·자료가 오래됨 사실 갱신, 담당자 검수, 관련 링크 정리 통합 같은 질문을 여러 페이지에서 중복 설명 대표 페이지 선정, 고유 내용 합치기, 대응 URL 이동 삭제 제공하지 않는 내용이며 보존 이유와 대응 콘텐츠가 없음 연결 제거, 적절한 상태 코드, 별도 보관 여부 확인 검색 유입은 중요한 판단 자료지만 유일한 기준은 아닙니다. 브랜드의 신뢰를 뒷받침하는 회사 정보, 실제 고객이 사용하는 안내, 문의 후에 보내는 준비 자료처럼 검색량과 다른 역할을 맡는 페이지도 있습니다. 3. 가상의 기업 서비스 사이트를 정리해보기 아래 URL은 정리 방식을 설명하는 가상 예시입니다. 슬로히어로의 실제 페이지나 측정 결과가 아닙니다. 3. 가상의 기업 서비스 사이트를 정리해보기 — 비교·점검표 기존 페이지 확인한 문제 판단 처리 계획 /services/team-photo 현재 서비스이며 자료가 정확함 보존 URL 유지, 관련 사례 연결 /price-2023 현재 조건과 다른 요금 안내 수정 또는 통합 정보 갱신 후 유효한 가격 안내로 연결 /faq-booking·/reservation-guide 같은 예약 질문이 중복됨 통합 고유 답변을 /booking-guide에 모으고 대응 이동 /event/summer-old 종료 행사이며 이후 안내 자료로 쓸 필요 없음 삭제 검토 외부 연결·보존 필요 확인 후 404 또는 410 처리 /case/project-a 실제 작업이지만 이미지가 누락됨 수정 원본·공개 권한 확인 후 복구, 담당 범위 표시 행사 페이지가 끝났다고 무조건 지우는 것은 아닙니다. 결과 기록이나 참가자 안내로 가치가 남아 있다면 ‘종료된 행사’임을 표시하고 보관할 수도 있습니다. 반대로 잘못된 가격이나 제공하지 않는 서비스를 현재 정보처럼 남겨서는 안 됩니다. 4. URL을 바꿀 때는 대응되는 내용으로 연결하기 기존 주소를 유지할 수 있다면 불필요한 주소 변경을 줄이는 것이 관리에 도움이 됩니다. 변경이 필요하면 예전 주소와 새 주소를 일대일로 매핑하세요. 여러 페이지를 하나로 통합할 때는 기존 페이지의 핵심 내용이 새 페이지에서 충분히 이어지는지 확인합니다. Google은 사이트 이동 시 적절한 새 URL로 서버 측 영구 리디렉션을 설정하고, 관련 없는 여러 주소를 홈페이지로 한꺼번에 보내는 방식은 피하라고 안내합니다. 새 주소에서 내용을 찾을 수 있어야 한다는 뜻입니다. Google URL 변경과 사이트 이전 안내 대응 페이지가 없고 콘텐츠를 완전히 제거했다면 404 또는 410 상태가 적절할 수 있습니다. 방문자에게 안내 화면을 보여주더라도 서버가 정상 페이지처럼 200을 반환하는지 별도로 확인하세요. 반대로 의미가 다른 서비스로 이동시켜 방문자가 정보를 잘못 이해하게 만드는 것은 좋은 해결책이 아닙니다. 리디렉션은 그 자체로 순위를 보장하는 장치가 아닙니다. 주소 변경과 내용 변경이 크다면 검색엔진이 다시 처리하는 동안 노출이 달라질 수 있습니다. 기존 주소에서 새 주소로 실제 이동하는지와 새 페이지의 내용을 함께 점검해야 합니다. 5. 바로 사용할 수 있는 콘텐츠 정리표 5. 바로 사용할 수 있는 콘텐츠 정리표 — 비교·점검표 기록 항목 적을 내용 기존 URL·제목 현재 공개 주소와 페이지 제목 고객에게 하는 일 어떤 질문·업무를 해결하는 페이지인가 확인 자료 방문·검색·외부 링크 자료의 기간과 출처, 없으면 미확인 정보 정확성 유지되는 사실, 바뀐 조건, 담당자 확인 결과 처리 분류 보존·수정·통합·삭제 중 선택과 이유 새 URL·이동 처리 유지 주소 또는 대응 새 주소, 리디렉션·상태 코드 실행 책임 원고·개발·검수 담당과 완료 예정일 공개 후 확인 실제 응답, 링크, 검색 도구에서 확인한 상태 정리표를 단순 삭제 목록으로 사용하지 마세요. 어떤 정보를 누가 고칠지, 어느 시점에 공개할지까지 이어져야 실제 리뉴얼 작업에 사용할 수 있습니다. ‘추후 수정’처럼 담당자와 시점이 없는 표시는 누락되기 쉽습니다. 6. 공개 전과 공개 후에 나눠 검수하기 공개 전에는 테스트 사이트에서 새 페이지의 내용과 주소, 내부 링크, 대표 주소 설정, 이미지와 문의 흐름을 확인합니다. 작업용 사이트의 검색 차단 설정을 운영본으로 그대로 가져오지 않았는지도 확인하세요. 다만 실제로 비공개여야 할 관리자·개인 자료까지 공개하는 것은 별개의 문제입니다. 공개 직후에는 대표 주소 몇 개만 보는 것으로 끝내지 말고, 정리표에 기록한 기존 주소의 이동과 삭제 상태를 확인합니다. 메뉴·사례·다운로드 링크를 통해 실제 고객의 경로를 따라가 보세요. 문의나 예약은 확인 가능한 테스트 환경·절차로 검수하고, 운영 알림이 불필요하게 여러 번 전송되지 않게 계획합니다. 6. 공개 전과 공개 후에 나눠 검수하기 — 비교·점검표 시점 확인할 항목 공개 전 내용 승인, 기존·신규 URL 대응표, 내부 링크, 모바일, 문의 흐름 공개 직후 실제 리디렉션·상태 코드, 대표 주소, 검색 차단 설정, 사이트맵 데이터가 쌓인 뒤 검색 노출·클릭·색인 변화, 유입 페이지, 오류 URL, 실제 문의 변화 사이트맵에는 대표로 노출할 정상 페이지를 반영하고, 이동한 옛 주소나 삭제 페이지가 계속 남지 않게 관리합니다. 검색 자료는 동일한 기간·기기·지역 조건으로 비교하고, 외부 캠페인이나 계절성처럼 함께 달라진 조건도 기록하세요. 자주 묻는 질문 오래된 글은 모두 지워야 하나요? 작성 시점이 오래되었어도 정확하고 유용한 정보라면 유지할 수 있습니다. 현재 조건이 달라졌다면 수정하고, 역사적 기록이라면 해당 시점의 내용임을 분명히 표시합니다. 오래됨과 불필요함은 같은 기준이 아닙니다. 삭제할 페이지를 모두 메인으로 보내면 안전한가요? 관련 없는 페이지로 일괄 이동시키는 방식은 권하지 않습니다. 기존 질문에 답하는 대응 페이지가 있으면 연결하고, 없다면 삭제 상태와 이용자 안내를 적절히 처리합니다. 검색 순위는 리뉴얼 직후 비교하면 되나요? 바로 점검할 수 있는 것은 접속·이동·검색 허용 설정 같은 기술 상태입니다. 검색 순위와 유입 변화는 재수집과 데이터 집계 시간을 고려해 관찰해야 합니다. 일정 기간이 지나면 반드시 회복된다는 보장은 없으므로 원인과 조건을 함께 봅니다. 리뉴얼 작업을 의뢰하기 전에는 리뉴얼 업체 선정과 이관 범위 를, 새 구조를 정할 때는 고객 질문으로 사이트맵 만들기 를 함께 확인해보세요. 작성: 슬로히어로 · 글의 개념을 표현하는 삽화는 AI로 제작했습니다. 본문의 가상 예시와 실제 자료는 구분해 표시했습니다. Sat, 26 Sep 2026 00:00:00 +0900 https://slohero.com/blog/website-renewal-content-audit https://slohero.com/blog/website-page-roles 홈 / 블로그 / 제작 기준과 기획 SLOHERO / WEBSITE PLANNING 회사소개·서비스·작업사례 페이지 구성: 각각 무엇을 설득해야 할까? 회사소개, 서비스 소개, 포트폴리오 페이지의 목적과 구성 순서를 비교합니다. 소개 문구를 반복하지 않고 회사의 신뢰·의뢰 범위·제작 근거를 연결하는 방법입니다. 슬로히어로 · 제작 기준과 기획 · 2026년 9월 26일 이 글에서 살펴볼 내용 1. 페이지별로 풀어야 할 질문부터 구분하기 2. 회사소개 페이지는 사람과 운영 주체를 이해시키는 자리 3. 서비스 소개는 의뢰 범위를 판단할 수 있어야 한다 4. 작업사례는 결과 화면과 판단 근거를 함께 보여주기 5. 세 페이지를 연결하면 같은 자료도 깊이가 생긴다 자주 묻는 질문 참고한 자료와 함께 읽을 글 회사소개, 서비스 소개, 작업사례 페이지는 서로 다른 질문에 답합니다. 회사소개는 누가 책임지고 일하는지, 서비스는 무엇을 어떤 범위로 제공하는지, 작업사례는 그 역량을 어떤 작업에서 확인할 수 있는지 를 보여줍니다. 세 페이지의 역할을 나누면 같은 슬로건이 반복되는 홈페이지를 줄일 수 있습니다. 회사소개를 반드시 먼저 읽게 할 필요는 없습니다. 검색으로 서비스 상세에 들어오거나 지인의 링크로 사례부터 보는 방문자도 있습니다. 각 페이지가 자기 역할을 수행하면서 필요한 근거와 다음 행동으로 연결되도록 설계해야 합니다. 1. 페이지별로 풀어야 할 질문부터 구분하기 1. 페이지별로 풀어야 할 질문부터 구분하기 — 비교·점검표 페이지 방문자의 중심 질문 핵심 자료 적절한 다음 행동 회사소개 누가 어떤 기준으로 책임지고 일하나? 운영 주체·역할·업무 방식·확인 가능한 이력 서비스·사례 살펴보기 서비스 소개 내 문제를 어디까지 해결해주나? 대상·제공 범위·진행 과정·조건·제외 사항 관련 사례 확인·범위 문의 작업사례 비슷한 일을 어떻게 해결했나? 과제·담당 범위·선택 이유·결과물·확인된 변화 해당 서비스 확인·유사 프로젝트 문의 예를 들어 ‘고객 중심의 창의적인 솔루션’이 세 페이지에 반복된다면, 문구를 더 멋지게 바꾸기 전에 자료의 역할부터 살펴보세요. 회사소개에는 그 기준을 지키는 업무 방식, 서비스에는 실제 제공 항목, 사례에는 어떤 문제에 어떻게 적용했는지가 필요합니다. 2. 회사소개 페이지는 사람과 운영 주체를 이해시키는 자리 회사소개 페이지 구성의 출발점은 거창한 선언보다 자신을 명확히 밝히는 것입니다. 어떤 분야에서 일하는지, 업무를 누가 맡는지, 고객과 어떤 방식으로 소통하는지를 정리하세요. 사업 규모와 관계없이 정확한 정보가 중요합니다. 1인 스튜디오가 팀 사진처럼 보이는 이미지를 넣거나 외부 협력자의 실적을 자사 실적으로 표시해서는 안 됩니다. 권장하는 내용 흐름은 한 문장 소개 → 주요 업무와 대상 → 일하는 기준 → 담당 역할 → 확인 가능한 이력 → 서비스와 사례 연결 입니다. 연혁이 중요한 회사라면 관련 시점을 포함할 수 있지만, 의미를 설명하지 않는 연도 목록이 페이지를 대부분 차지할 필요는 없습니다. 가상의 디자인 스튜디오라면 “브랜드 소개와 고객 문의 흐름을 함께 설계하는 웹 디자인 스튜디오입니다”라고 소개한 뒤 기획·디자인·개발의 책임 범위를 보여줄 수 있습니다. 외부 파트너와 협업한다면 그 역할을 사실에 맞게 설명합니다. 전문성은 사람 수를 커 보이게 만드는 표현보다 누가 무엇을 책임지는지에서 드러납니다. 회사소개에 넣을 자료와 확인할 점 대표·담당자 소개: 실제 담당 업무와 관련 경험을 중심으로 작성합니다. 업무 기준: 진행 중 어떤 결정에 적용되는지 예를 붙입니다. 수상·인증·협력 이력: 주체, 대상, 시점을 확인하고 오해가 없게 표시합니다. 연락 정보: 실제 이용할 수 있는 문의 경로를 제공합니다. 3. 서비스 소개는 의뢰 범위를 판단할 수 있어야 한다 서비스 소개 페이지를 읽고도 “그래서 무엇을 받을 수 있나요?”라는 질문이 남는다면 설명을 보완해야 합니다. 웹사이트 제작이라면 단순히 ‘반응형·SEO·고퀄리티’라고 나열하기보다 포함 페이지, 원고 지원 범위, 문의 기능, 관리자 제공 여부, 검수와 인계 내용을 구체화합니다. 모든 프로젝트의 범위를 고정할 필요는 없습니다. 공통 제공 내용과 협의가 필요한 항목을 구분하면 됩니다. 촬영, 번역, 결제 연동, 기존 데이터 이전처럼 추가 작업이 발생하는 조건을 미리 밝혀두면 문의의 맥락이 정확해집니다. 내용 순서는 고객 상황 → 제공하는 해결 방식 → 산출물과 범위 → 관련 사례 → 진행 과정 → 협의 조건과 FAQ → 문의 를 출발점으로 삼을 수 있습니다. 가격을 공개하기 어렵다면 비용이 달라지는 요인과 견적에 필요한 정보를 설명하세요. ‘문의’라는 한 단어로 판단에 필요한 내용을 모두 미루지 않는 편이 좋습니다. 3. 서비스 소개는 의뢰 범위를 판단할 수 있어야 한다 — 비교·점검표 막연한 표현 판단에 도움이 되는 설명 예시 운영이 편한 홈페이지 공지와 작업사례를 담당자가 수정하는 관리 화면 제공 여부를 협의합니다 SEO 최적화 페이지 제목·설명·대표 주소·내부 연결·사이트맵 등 적용 범위를 견적에 명시합니다 맞춤형 디자인 주요 화면 시안, 모바일 대응, 수정 범위와 승인 단계를 정합니다 사후 관리 제공 오류 대응과 콘텐츠 수정의 기간·범위·비용을 구분합니다 위 문장은 설명 방식의 예시입니다. 실제 계약 범위를 확정한 문구가 아니므로, 자기 서비스에 적용할 때는 제공 가능한 조건으로 수정해야 합니다. 4. 작업사례는 결과 화면과 판단 근거를 함께 보여주기 포트폴리오에 완성 화면만 나열하면 취향은 전달되지만 문제 해결 방식은 드러나기 어렵습니다. 사례 하나라도 방문자의 상황, 작업 목표, 담당 범위, 주요 선택, 결과물을 연결해 설명하면 의뢰자가 자기 프로젝트와 비교하기 쉬워집니다. 가상의 예약 서비스 개편 사례라면 “메뉴를 단순화했다”에서 멈추지 않고 “서비스별 예약 조건이 흩어져 있어, 상세 페이지에 준비 사항과 예약 버튼을 함께 배치했다”처럼 결정 이유를 적습니다. 화면에는 설명한 구역을 함께 보여주세요. 디자인 시안인지 실제 운영 중인 서비스인지도 표시합니다. 기본 구성: 프로젝트 개요 → 해결할 과제 → 직접 맡은 범위 → 주요 결정과 이유 → 대표 화면 → 확인된 결과와 남은 과제. 문의가 늘었다는 수치를 쓰려면 측정 기간과 기준, 비교 조건이 있어야 합니다. 그런 자료가 없다면 전환 개선을 주장하지 말고, 확인할 수 있는 변화만 적습니다. 예를 들어 ‘문의 필드 8개를 필수 4개와 선택 2개로 정리했다’는 실제 구현 내용으로 검증할 수 있습니다. 그 자체가 문의 증가를 증명하는 것은 아닙니다. 5. 세 페이지를 연결하면 같은 자료도 깊이가 생긴다 서비스 페이지에는 해당 업무의 사례를, 사례에는 실제 적용한 서비스와 범위 문의를 연결합니다. 회사소개에는 일하는 방식이 드러나는 사례를 선정하세요. 모든 페이지 하단에 똑같은 최신 글을 넣기보다, 지금 읽는 내용에 필요한 자료를 선택하는 편이 좋습니다. 예를 들어 운영 기능을 설명하는 서비스 페이지에서 시각 효과가 화려한 사례만 연결하면 근거가 어긋납니다. 담당자가 자료를 등록하거나 예약을 처리하는 과정을 보여주는 사례가 더 적절할 수 있습니다. 관련성이 링크 수보다 우선입니다. 자주 묻는 질문 회사가 작으면 회사소개 페이지를 생략해도 되나요? 별도 페이지가 반드시 필요한 것은 아닙니다. 메인이나 서비스 페이지 안에 운영 주체, 담당 역할, 문의 정보를 충분히 제공할 수도 있습니다. 독립 페이지의 필요성은 자료와 방문 목적을 보고 판단합니다. 아직 작업사례가 없으면 어떻게 하나요? 자체 제작이나 콘셉트 프로젝트를 만들고 그 성격을 분명히 표시하세요. 실제 고객의 의뢰처럼 쓰거나 가상의 후기·성과를 넣지 않습니다. 문제 설정과 구현 결과, 직접 맡은 범위를 설명하면 작업 방식을 보여줄 수 있습니다. 세 페이지의 SEO 키워드도 달라야 하나요? 페이지 목적에 맞게 제목과 설명을 작성하면 자연스럽게 초점이 달라집니다. 서비스 페이지는 실제 서비스와 대상, 사례는 프로젝트의 과제와 구현, 회사소개는 브랜드와 운영 주체를 중심으로 구성합니다. 같은 키워드를 모든 제목에 억지로 반복할 필요는 없습니다. 참고한 자료와 함께 읽을 글 Google은 독창적인 정보, 내용의 출처와 작성 주체, 읽은 뒤 목적을 달성할 수 있는 충분한 설명을 콘텐츠 점검 기준으로 제시합니다. 이 글의 페이지 구분과 예시는 해당 원칙을 참고한 실무 구성 제안입니다. Google의 유용한 콘텐츠 안내 페이지를 어떤 메뉴에 넣을지는 홈페이지 사이트맵 만들기 , 내용을 화면으로 옮기는 순서는 홈페이지 원고와 디자인 에서 이어서 다룹니다. 작성: 슬로히어로 · 글의 개념을 표현하는 삽화는 AI로 제작했습니다. 본문의 가상 예시와 실제 자료는 구분해 표시했습니다. Sat, 26 Sep 2026 00:00:00 +0900 https://slohero.com/blog/website-page-roles https://slohero.com/blog/website-copy-before-design 홈 / 블로그 / 제작 기준과 기획 SLOHERO / WEBSITE PLANNING 홈페이지 원고와 디자인, 무엇부터 시작할까? 콘텐츠 준비 순서 홈페이지 원고를 완성한 뒤 디자인해야 할까요? 핵심 내용·와이어프레임·문장 수정의 순서, 원고 길이에 따른 화면 구성과 의뢰 전 준비표를 예시로 설명합니다. 슬로히어로 · 제작 기준과 기획 · 2026년 9월 26일 이 글에서 살펴볼 내용 1. 디자인 전에 확정할 내용과 나중에 다듬을 문장 2. 페이지별 원고를 여섯 칸으로 준비하기 3. 원고 길이에 따라 화면은 어떻게 달라질까? 4. 빈 시안 대신 실제 원고로 구조를 확인하기 5. 원고와 디자인을 주고받는 다섯 단계 6. SEO 문장은 별도로 덧붙이는 장식이 아니다 자주 묻는 질문 홈페이지 제작은 전달할 내용과 페이지 목적을 먼저 정하고, 실제 문장을 넣은 구조를 보면서 원고와 디자인을 함께 다듬는 방식 이 효율적인 출발점입니다. 모든 문장을 처음부터 확정해야 하는 것은 아닙니다. 다만 서비스 범위와 핵심 메시지도 정하지 않은 채 빈 화면을 꾸미면, 나중에 들어온 자료가 구조를 크게 바꿀 수 있습니다. 가령 세 개의 서비스 카드를 디자인했는데 실제 상품은 조건이 서로 다른 다섯 종류라면 카드 수만 늘리는 것으로 해결되지 않을 수 있습니다. 비교표나 개별 상세 페이지가 필요해질 수도 있습니다. 디자인에 영향을 주는 내용부터 확인하는 이유입니다. 1. 디자인 전에 확정할 내용과 나중에 다듬을 문장 ‘원고를 먼저 준비한다’는 말은 글쓰기 작업 전체를 한 번에 끝낸다는 뜻이 아닙니다. 사실과 범위를 정하는 일, 읽히는 문장을 만드는 일을 구분하면 진행하기가 수월합니다. 1. 디자인 전에 확정할 내용과 나중에 다듬을 문장 — 비교·점검표 먼저 정할 내용 디자인과 함께 다듬을 내용 주요 고객과 페이지의 목적 제목의 길이와 강조 단어 제공 서비스·대상·제외 범위 문단 구분과 소제목 실제 가격 조건과 진행 절차 모바일에서의 줄바꿈 공개 가능한 사례·사진·후기 사진 선택과 텍스트 배치 문의 후 처리 방식과 담당자 버튼 표현과 보조 안내 위치 ‘누가 확인할지 미정인 문의 폼’은 버튼 모양으로 해결할 수 없습니다. 반대로 핵심 사실이 준비되어 있다면 제목이 아직 다듬어지지 않았어도 구조 설계를 시작할 수 있습니다. 미확정 항목에는 담당자와 결정 기한을 붙여두세요. 2. 페이지별 원고를 여섯 칸으로 준비하기 처음부터 긴 소개서를 쓰기보다 페이지마다 목적, 질문, 답, 근거, 행동, 담당자를 적어보세요. 아래는 가상의 기업 촬영 서비스 페이지를 준비하는 예입니다. 2. 페이지별 원고를 여섯 칸으로 준비하기 — 비교·점검표 준비 항목 작성 예시 목적 기업 담당자가 촬영 범위를 이해하고 일정 상담을 신청한다 주요 질문 팀 프로필과 사무실 사진을 같은 날 촬영할 수 있나? 핵심 답 인원·공간·희망 컷을 확인해 촬영 동선을 제안한다 확인 자료 실제 촬영물, 제공 파일 규격, 보정 범위, 사용 조건 다음 행동 인원·장소·희망일을 적어 촬영 일정 상담하기 확인 담당 촬영·보정 담당자가 범위와 납품 조건 확인 이 내용이 모이면 페이지의 첫 문장과 필요한 구역을 정할 수 있습니다. 자료가 없는 부분도 드러납니다. 실제로 확인되지 않은 납품 일정이나 제공 범위를 AI가 채운 문장으로 확정하지 않도록 주의하세요. 예시 표는 준비 방식의 설명이며 슬로히어로의 촬영 상품 조건이 아닙니다. 3. 원고 길이에 따라 화면은 어떻게 달라질까? 같은 서비스를 설명해도 짧은 문구와 상세한 안내는 맡는 역할이 다릅니다. 모든 내용을 첫 화면에 넣거나 모든 설명을 카드 한 줄로 줄일 필요는 없습니다. 짧은 문구 — 첫 화면과 카드에 적합 예시: 팀의 인상을 일관되게 담는 기업 프로필 촬영. 첫 화면에서는 이 문구 옆에 대표 이미지를 놓고, 대상과 진행 방식은 보조 문장으로 설명할 수 있습니다. 하지만 이 한 문장만으로 인원, 촬영 장소, 보정 범위까지 알 수는 없습니다. 상세 설명으로 이어지는 흐름이 필요합니다. 중간 길이 — 서비스 소개 구역에 적합 예시: 팀 프로필과 업무 공간을 같은 기준으로 촬영합니다. 인원과 장소, 필요한 컷을 확인한 뒤 촬영 순서와 제공 범위를 안내합니다. 한 구역의 제목과 두 문장 설명으로 배치하기 좋습니다. 관련 이미지와 함께 두 열로 구성할 수 있고, 모바일에서는 제목·설명·이미지 순서로 읽히게 할 수 있습니다. 실제 문장을 넣어보면 같은 두 문장이라도 화면 높이와 시선 흐름이 달라짐을 알 수 있습니다. 긴 설명 — 조건별 목록이나 표로 분리 촬영 인원별 진행 방식, 출장 조건, 보정과 추가 작업, 파일 전달, 일정 변경까지 설명해야 한다면 긴 문단 하나보다 항목별 제목과 표가 유용합니다. 큰 글자로 억지로 줄이거나 글꼴 크기를 계속 낮추는 대신 정보 구조를 바꿔야 하는 구간입니다. 3. 원고 길이에 따라 화면은 어떻게 달라질까? — 비교·점검표 원고 상태 적절한 화면 구성 자주 생기는 문제 주제 문장 하나 큰 제목 + 대표 이미지 + 보조 설명 설명이 짧다는 이유로 의미 없는 수식어 추가 개념 설명 두세 문장 소제목 + 본문 + 관련 이미지 문장 길이에 상관없이 카드 높이를 고정 조건이 여러 개인 안내 항목별 목록·비교표·FAQ 작은 글자로 모든 조건을 한 번에 삽입 서로 다른 서비스 설명 목록과 상세 페이지 분리 검토 하나의 큰 슬라이드에 내용을 몰아넣음 4. 빈 시안 대신 실제 원고로 구조를 확인하기 와이어프레임은 내용의 순서와 비중을 확인하는 간단한 화면 설계입니다. 로고와 색을 정교하게 표현하기 전에 실제 제목, 대표 설명, 이미지 종류, 버튼 목적을 넣어보세요. ‘텍스트가 들어갑니다’라는 문장만 있으면 실제 내용의 길이와 난이도를 판단하기 어렵습니다. 서비스가 세 종류라면 각각 다른 이름과 설명을 넣습니다. 사례 제목이 길어질 수 있다면 긴 제목도 시험합니다. 이름이나 금액처럼 운영 중 길이가 달라지는 정보는 예상 범위를 반영합니다. 처음 샘플 하나만 예쁘게 보이는 화면보다 실제 자료를 받아들이는 화면이 운영에 유리합니다. 내용이 길어졌을 때는 먼저 정보가 필요한지 판단합니다. 필요한 조건이라면 제목·목록·표로 나누거나 적절한 상세 페이지로 연결합니다. 단순히 글자를 세로로 늘이거나 가로로 압축해 맞추지 마세요. 글꼴의 원래 비율을 유지하고 크기·폭·행간·줄바꿈으로 읽기 편하게 조정합니다. 5. 원고와 디자인을 주고받는 다섯 단계 자료 확인: 서비스 범위, 사실, 고객 질문, 이미지 사용 권한을 확인합니다. 페이지 구조: 페이지마다 전달할 결론과 필요한 근거를 배치합니다. 초안 적용: 실제 제목·본문·버튼을 간단한 화면에 넣습니다. 동시 조정: 중복 문장을 줄이고 시선 흐름·줄바꿈·모바일 순서를 다듬습니다. 최종 검수: 사실과 링크, 문의 안내, 검색 제목·설명을 함께 확인합니다. 수정 의견도 구체적으로 적는 편이 좋습니다. ‘더 고급스럽게’보다 ‘제공 범위가 첫 화면에서 보이지 않는다’, ‘주요 버튼과 상세 안내가 같은 강조 수준이라 선택하기 어렵다’는 의견이 다음 수정으로 연결됩니다. 6. SEO 문장은 별도로 덧붙이는 장식이 아니다 핵심 서비스가 홈페이지 제작이라면 제목과 첫 설명에 그 사실이 자연스럽게 드러나야 합니다. 그렇다고 ‘홈페이지 제작’을 모든 문장과 이미지 설명에 반복할 필요는 없습니다. 방문자가 묻는 대상·범위·진행·조건에 충분히 답하는 원고를 먼저 만드세요. Google은 검색 결과의 제목 링크를 만들 때 title 요소뿐 아니라 페이지의 큰 제목 등 여러 신호를 활용한다고 설명합니다. 검색용 제목과 화면 제목의 주제가 일치하도록 작성하는 것이 좋습니다. 정해진 글자 수를 맞추는 것만으로 검색 결과의 표시나 순위를 보장할 수는 없습니다. Google 제목 링크 안내 자주 묻는 질문 원고가 없으면 홈페이지 제작을 시작할 수 없나요? 고객과 서비스, 제공 범위를 정리하는 단계부터 시작할 수 있습니다. 제작사가 인터뷰와 초안 작성을 지원하는지 확인하고, 사실 확인과 최종 승인 담당자를 정하세요. 문장 작성 지원과 자료 조사·촬영은 범위가 다를 수 있습니다. AI로 원고를 쓰면 바로 사용해도 되나요? 초안 정리와 표현 대안에는 활용할 수 있습니다. 공개 전에는 서비스 조건, 수치, 이력, 출처를 확인하고 실제 브랜드에 맞게 고쳐야 합니다. 존재하지 않는 사례나 후기가 섞이지 않았는지 반드시 점검합니다. 원고 수정은 언제 마감하는 것이 좋나요? 디자인 착수 전에 핵심 범위와 구조를 합의하고, 세부 문구는 시안을 보면서 정리하는 방식을 권합니다. 페이지 수나 기능이 달라지는 변경과 단순 표현 수정의 처리 범위도 미리 정하면 일정 관리에 도움이 됩니다. 원고 자료를 준비할 때는 홈페이지 기획서 예시 , 페이지별 필요한 내용은 회사소개·서비스·작업사례 구성 을 함께 확인해보세요. 작성: 슬로히어로 · 글의 개념을 표현하는 삽화는 AI로 제작했습니다. 본문의 가상 예시와 실제 자료는 구분해 표시했습니다. Sat, 26 Sep 2026 00:00:00 +0900 https://slohero.com/blog/website-copy-before-design https://slohero.com/blog/template-nocode-custom-development 홈 / 블로그 / 제작 기준과 기획 SLOHERO / WEBSITE PLANNING 템플릿·노코드·맞춤 개발 비교: 홈페이지 제작 방식 선택 기준 템플릿, 노코드, 맞춤 개발을 디자인·기능·수정·이전·운영비로 비교합니다. 단순 소개형부터 예약 업무형까지 필요한 조건에 맞춰 제작 방식을 고르는 판단표입니다. 슬로히어로 · 제작 기준과 기획 · 2026년 9월 26일 이 글에서 살펴볼 내용 1. 비교 전에 필수 조건 다섯 가지를 적기 2. 템플릿·노코드·맞춤 개발 비교표 3. 상황별로 선택하는 세 가지 예시 4. 내보내기 가능과 완전한 이전은 다르다 5. 제작비와 운영비를 같은 기간으로 비교하기 6. 슬로히어로가 제안하는 선택 순서 자주 묻는 질문 홈페이지 제작 방식은 멋진 화면을 만들 수 있는지만으로 결정하기 어렵습니다. 필요한 기능, 누가 수정할지, 바꿀 수 없는 제약, 자료를 옮길 수 있는지, 유지할 인력과 비용 을 함께 봐야 합니다. 처음 만드는 속도와 공개 이후의 운영 조건을 한 번에 비교하는 것이 핵심입니다. 먼저 용어를 구분해야 합니다. 템플릿은 준비된 디자인 구조를 재사용하는 방식이고, 노코드는 시각적 편집 도구로 사이트를 만드는 방식입니다. 맞춤 개발은 요구에 맞춰 기능과 코드를 설계하는 접근입니다. 셋은 서로 완전히 배타적이지 않습니다. 노코드에서 템플릿을 사용할 수도 있고, 템플릿 위에 별도 코드를 추가할 수도 있습니다. 1. 비교 전에 필수 조건 다섯 가지를 적기 ‘맞춤형이 더 좋다’ 또는 ‘노코드면 충분하다’는 결론부터 내리지 마세요. 같은 회사 소개 사이트라도 운영자가 매주 자료를 올리는지, 별도의 고객 인증과 승인 과정이 필요한지에 따라 조건이 달라집니다. 방문자가 할 일: 소개 읽기, 문의, 결제, 예약, 로그인 중 무엇이 필요한가? 운영자가 할 일: 문구 수정, 사례 등록, 접수 처리, 권한 관리 중 무엇을 직접 할 것인가? 연결할 시스템: 이메일 알림 수준인가, 기존 업무 데이터와 양방향으로 연결해야 하는가? 이전 조건: 자료와 도메인, 소스, 기능을 어디까지 옮길 수 있어야 하는가? 운영 자원: 정기 비용과 기술 담당자를 어느 범위까지 유지할 수 있는가? 특히 예약은 구체적으로 적어야 합니다. 날짜를 받아 담당자가 확인하는 문의 폼과, 실시간 잔여 수량·결제·취소·중복 예약 방지가 필요한 서비스는 다른 요구입니다. 화면 이름이 같다고 제작 범위가 같지는 않습니다. 2. 템플릿·노코드·맞춤 개발 비교표 아래는 일반적인 선택 기준입니다. 실제 범위는 플랫폼, 요금제, 플러그인, 구현 방식과 계약에 따라 달라집니다. 고정된 가격 순서나 품질 등급으로 읽지 않는 것이 좋습니다. 2. 템플릿·노코드·맞춤 개발 비교표 — 비교·점검표 비교 기준 템플릿 활용 노코드 중심 구축 맞춤 개발 중심 구축 시작점 준비된 화면·구조를 수정 편집기와 제공 기능으로 구성 요구에 맞는 화면·기능 설계 디자인 조정 템플릿 구조와 편집 범위 확인 도구가 허용하는 레이아웃·코드 범위 확인 폭넓게 설계 가능하나 구현·검수 필요 특수 업무 기본 기능과의 차이가 클수록 추가 작업 외부 서비스·코드 확장 가능 여부 확인 복잡한 규칙에 맞게 설계 가능 콘텐츠 수정 기반 CMS와 템플릿에 따라 다름 운영자 편집 흐름을 직접 시험 관리 기능을 따로 설계·구현해야 할 수 있음 유지 관리 테마·플러그인·기반 서비스 점검 플랫폼 비용과 외부 연동 관리 서버·의존성·보안·장애 대응 담당 필요 이전·인계 라이선스와 자료·소스 확보 범위 확인 내보내기 범위와 호스팅 제약 확인 소스·데이터·문서·계정 인계 계약 확인 템플릿을 써도 이미지, 문구, 여백, 구성 순서를 적절히 조정하면 브랜드에 맞는 결과를 만들 수 있습니다. 반대로 맞춤 개발이어도 내용과 디자인 판단이 부족하면 완성도가 낮을 수 있습니다. 제작 방식이 결과의 전문성을 자동으로 결정하지는 않습니다. 3. 상황별로 선택하는 세 가지 예시 회사 소개와 간단한 문의가 중심인 경우 서비스와 사례를 소개하고 문의를 받는 구조라면 템플릿이나 노코드 기반부터 검토할 수 있습니다. 브랜드 표현 범위, 모바일 사용성, 문의 알림, 기본 검색 설정을 실제로 확인하세요. 필요한 기능이 충분히 지원된다면 별도의 복잡한 시스템이 우선일 이유는 없습니다. 담당자가 콘텐츠를 자주 등록하는 경우 사례·공지·자료를 반복적으로 올린다면 관리 기능이 중요합니다. 도구 이름보다 ‘긴 제목의 사례 등록’, ‘대표 이미지 교체’, ‘비공개 저장 후 확인’ 같은 실제 작업을 시험해보세요. 초기에 사용하기 쉬워도 항목 수가 늘었을 때 분류·검색·권한이 부족할 수 있습니다. 예약·승인·고객별 권한이 업무에 연결되는 경우 예약 중복 방지, 결제 상태, 여러 담당자의 승인, 고객별 자료 접근 같은 규칙이 있다면 전체 처리 흐름을 먼저 설계해야 합니다. 맞춤 개발이 적합할 수 있지만, 검증된 외부 시스템을 연동하는 선택도 가능합니다. 중요한 것은 접수 성공뿐 아니라 실패·취소·재시도·권한 오류까지 처리할 수 있는지입니다. 세 예시는 판단 연습을 위한 가상 조건입니다. 기능 목록만으로 구현 방식을 확정하지 말고 운영자가 처리할 일과 예외 상황을 함께 확인합니다. 4. 내보내기 가능과 완전한 이전은 다르다 HTML 파일을 받을 수 있다고 기존 사이트가 다른 환경에서 그대로 작동하는 것은 아닙니다. 게시물 데이터, 회원, 결제, 검색, 폼 처리와 관리자 기능은 별도 조건이 있을 수 있습니다. 도메인을 보유하는 일과 서비스의 기능·데이터를 이전하는 일도 구분해야 합니다. 예를 들어 Webflow의 코드 내보내기 안내는 정적 코드 내보내기와 플랫폼의 CMS·전자상거래 등 기능을 구분합니다. 이 조건은 계약 시점에 공식 문서에서 다시 확인해야 합니다. Webflow 코드 내보내기 공식 안내 견적을 받을 때는 “이전할 수 있나요?”에서 한 단계 더 구체적으로 질문하세요. 어떤 파일과 데이터를 받는지, 어느 형식인지, 새 환경에서 다시 구현할 기능이 무엇인지, 도메인과 계정의 소유·접근 권한은 누구에게 있는지를 문서로 남깁니다. 5. 제작비와 운영비를 같은 기간으로 비교하기 처음 견적만 비교하면 유료 앱, 호스팅, 관리 기능, 콘텐츠 수정과 추가 개발 비용이 빠질 수 있습니다. 플랫폼의 실시간 가격을 단정하기보다 견적서에 적용한 요금제와 확인일을 적어두세요. 할인 기간 이후 금액과 사용량 한도도 확인합니다. 5. 제작비와 운영비를 같은 기간으로 비교하기 — 비교·점검표 비용 항목 비교할 때 확인할 내용 최초 제작 기획·디자인·개발·자료 입력·검수·교육 범위 반복 비용 호스팅·플랫폼·도메인·유료 앱·외부 연동 변경 작업 문구 수정·페이지 추가·기능 변경의 비용 기준 운영 대응 업데이트·장애·백업·복구를 맡을 주체 종료·이전 파일·데이터 반출과 새 환경에서의 재구현 범위 비교 기간은 같은 조건으로 맞춥니다. 첫해 비용은 최초 제작비에 같은 기간의 반복 비용과 예상 변경 작업을 더해 살펴볼 수 있습니다. 아직 확정되지 않은 작업을 포함했다면 가정으로 표시해야 합니다. 일반적인 비용 항목은 홈페이지 제작 견적서 비교법 에서도 확인할 수 있습니다. 6. 슬로히어로가 제안하는 선택 순서 우선 필수 기능과 운영 담당자의 작업을 문장으로 적습니다. 다음으로 후보 방식에서 가장 어려운 작업 하나를 실제로 시험합니다. 콘텐츠 수정이 핵심이면 편집을, 업무 연동이 핵심이면 데이터 처리와 실패 대응을 확인하세요. 마지막에 디자인 구현 범위, 운영 비용, 인계 조건을 같은 표에서 비교합니다. 필요하지 않은 기능까지 모두 직접 만드는 것보다 중요한 요구를 안정적으로 만족시키는 편이 낫습니다. 동시에 제작 도구가 편하다는 이유로 고객의 업무를 도구의 제약에 억지로 맞추지 않아야 합니다. 도구 선택은 프로젝트의 조건을 설명할 수 있는 결정이어야 합니다. 자주 묻는 질문 노코드로 만든 홈페이지도 SEO가 가능한가요? 도구 이름만으로 가능 여부나 순위를 정할 수 없습니다. 페이지 제목과 본문, URL, 내부 링크, 색인 제어, 속도와 모바일 사용성을 원하는 수준으로 관리할 수 있는지 확인합니다. 콘텐츠 품질과 경쟁 환경도 검색 노출에 영향을 줍니다. 맞춤 개발이면 운영자가 직접 수정할 수 있나요? 자동으로 제공되는 것은 아닙니다. 수정할 항목과 관리 화면, 권한, 교육을 별도 범위로 명시해야 합니다. 소스를 받는 것과 비개발자가 콘텐츠를 편집하는 것은 다른 조건입니다. 템플릿으로 시작했다가 나중에 바꿀 수 있나요? 가능 여부와 비용은 플랫폼과 자료 구조에 따라 달라집니다. 초기부터 도메인 소유, 콘텐츠 백업, 데이터 내보내기, 주소 유지 계획을 확인하면 이전 준비에 도움이 됩니다. 이전할 때 유지할 자료는 리뉴얼 콘텐츠 정리 에서 살펴보세요. 작성: 슬로히어로 · 글의 개념을 표현하는 삽화는 AI로 제작했습니다. 본문의 가상 예시와 실제 자료는 구분해 표시했습니다. Sat, 26 Sep 2026 00:00:00 +0900 https://slohero.com/blog/template-nocode-custom-development https://slohero.com/blog/homepage-first-screen 홈 / 블로그 / 제작 기준과 기획 SLOHERO / WEBSITE PLANNING 홈페이지 첫 화면 구성: 방문자가 바로 이해하는 5가지 요소 홈페이지 첫 화면에 넣을 핵심 문구·이미지·신뢰 근거·버튼을 정리합니다. 같은 브랜드의 히어로 영역 3안과 모바일 점검표로 우리 사이트에 맞는 구성을 선택해보세요. 슬로히어로 · 제작 기준과 기획 · 2026년 9월 26일 이 글에서 살펴볼 내용 1. 첫 화면을 만들기 전에 방문 이유를 한 문장으로 적기 2. 홈페이지 히어로 영역에 들어갈 다섯 요소 3. 같은 브랜드의 첫 화면 세 가지 안 비교 4. 첫 화면 이미지와 버튼은 같은 이야기를 해야 한다 5. 모바일에서 다시 확인할 항목 자주 묻는 질문 참고한 원칙과 함께 읽을 글 홈페이지 첫 화면은 방문자가 “여기는 무엇을 하는 곳이고, 나에게 어떤 도움이 되는가”를 판단하는 자리입니다. 회사 이름과 멋진 사진만으로 그 답이 전달되기는 어렵습니다. 대상 고객, 제공하는 가치, 그 가치를 보여주는 이미지, 믿을 근거, 다음 행동 을 함께 정리하면 첫 화면의 우선순위가 선명해집니다. 다섯 요소를 모두 크게 넣으라는 뜻은 아닙니다. 주제 문구와 대표 이미지가 중심을 잡고, 짧은 설명과 버튼이 이해를 돕는 구조가 출발점입니다. 이 글에서는 가상의 사무실 정리 서비스를 같은 조건에서 세 가지 방향으로 설계해봅니다. 예시는 설명을 위한 구성으로, 실제 고객 사례나 성과를 뜻하지 않습니다. 1. 첫 화면을 만들기 전에 방문 이유를 한 문장으로 적기 기업 홈페이지를 방문하는 사람은 거래처 담당자, 구매 예정자, 지원자처럼 서로 다른 목적을 가질 수 있습니다. 모든 방문자를 첫 화면에서 똑같이 설득하려 하면 메시지가 흐려집니다. 우선 사업상 중요한 방문자와 그 사람이 가장 먼저 확인할 질문을 정하세요. 사무실 정리 서비스를 찾는 운영 담당자라면 “우리 규모도 가능한가”, “업무를 멈춰야 하는가”, “무엇을 어디까지 정리해주는가”가 중요할 수 있습니다. 이때 첫 문구가 “공간에 새로운 가치를 더합니다”라면 핵심 정보가 빠집니다. “업무 흐름에 맞춰 사무실 수납과 공용 공간을 정리합니다”처럼 대상과 업무를 먼저 밝히는 편이 선택에 도움이 됩니다. 광고를 보고 들어온 방문자라면 광고에서 약속한 서비스가 같은 표현으로 이어져야 합니다. 검색으로 들어온 사람에게는 업종과 제공 범위가 보이는지 확인하세요. 브랜드를 이미 아는 재방문자에게 필요한 예약·로그인·자료실은 별도 메뉴로 쉽게 접근할 수 있게 둡니다. 2. 홈페이지 히어로 영역에 들어갈 다섯 요소 첫 화면의 큰 소개 영역을 흔히 히어로 영역이라고 부릅니다. 아래 표는 내용을 준비하는 순서입니다. 실제 화면의 순서와 비중은 서비스의 성격에 맞게 조정합니다. 2. 홈페이지 히어로 영역에 들어갈 다섯 요소 — 비교·점검표 요소 먼저 답할 질문 사무실 정리 서비스의 구성 예시 핵심 문구 누구의 어떤 일을 돕는가? 업무 흐름에 맞춰 사무실을 정리합니다 보조 설명 어디까지 제공하는가? 현황 확인부터 수납 분류·배치·사용 안내까지 대표 이미지 설명을 어떤 장면으로 보여줄까? 실제 제공 방식이 드러나는 수납·공용 공간 사진 신뢰 근거 이 말을 무엇으로 확인할 수 있나? 촬영·공개 허가를 받은 작업 사례 링크 행동 버튼 방문자가 다음에 무엇을 하면 되나? 정리 범위 상담하기 / 작업 사례 보기 신뢰 근거가 부족하다면 임의의 고객 수나 만족도를 넣지 마세요. 작업 범위, 진행 순서, 담당자의 역할처럼 확인 가능한 정보를 공개하는 것도 방법입니다. 후기나 고객 로고는 사용 허가와 실제 관계가 확인된 것만 사용합니다. 3. 같은 브랜드의 첫 화면 세 가지 안 비교 조건은 동일합니다. 대상은 소규모 기업의 운영 담당자, 서비스는 사무실 정리, 목표는 상담 신청입니다. 달라지는 것은 방문자가 처음 주목할 정보입니다. A안 — 서비스 이해를 먼저 돕는 구성 문구: 업무 흐름에 맞춰 사무실을 정리합니다. 왼쪽에 서비스 문구와 제공 범위를 놓고, 오른쪽에 실제 정리된 공간을 크게 배치합니다. 주요 버튼은 ‘정리 범위 상담하기’, 보조 링크는 ‘작업 과정 보기’입니다. 처음 접하는 브랜드이거나 서비스 범위를 설명해야 할 때 출발점으로 삼기 좋습니다. B안 — 고객의 문제를 먼저 보여주는 구성 문구: 공용 물품을 찾느라 멈추는 시간, 공간부터 점검하세요. 문제 상황을 짧게 제시한 뒤 ‘분류 기준과 배치를 함께 정리하는 사무실 정리 서비스’라는 설명을 붙입니다. 문제에 공감하는 방문자에게 어울립니다. 다만 문구만 읽고 컨설팅인지 소프트웨어인지 헷갈릴 수 있으므로 업종과 실제 제공 업무를 반드시 가까이에 표시합니다. C안 — 결과물을 먼저 보여주는 구성 문구: 우리 사무실에 적용할 정리 방식을 살펴보세요. 대표 작업 사진과 ‘공용 수납 / 회의 공간 / 자료 보관’ 같은 구체적인 설명을 중심에 놓습니다. 주요 버튼은 ‘작업 사례 보기’, 상담은 보조 버튼으로 둡니다. 결과물 비교가 의뢰 결정에 중요한 경우 유용하지만, 공개 가능한 실제 사례가 충분해야 합니다. 3. 같은 브랜드의 첫 화면 세 가지 안 비교 — 비교·점검표 선택안 우선하는 정보 적합한 상황 보완할 점 A. 서비스 중심 대상과 업무 범위 브랜드·서비스를 처음 접하는 방문자가 많음 일반적인 소개에 그치지 않도록 차이를 구체화 B. 문제 중심 방문자가 겪는 불편 특정 문제를 다룬 광고와 연결 실제 판매하는 서비스 종류를 명시 C. 사례 중심 작업 결과와 적용 장면 결과 비교가 구매 판단의 중심 사진의 맥락·범위·실제 사례 여부 표시 위 조건의 신규 브랜드라면 A안을 우선 검토하고, 바로 다음 구역에서 사례를 보여주는 구성이 합리적입니다. 이것은 조건에 따른 설계 제안이며 전환율이 검증된 결과는 아닙니다. 운영 후 유입 경로와 실제 문의 내용을 보고 문구와 순서를 조정해야 합니다. 4. 첫 화면 이미지와 버튼은 같은 이야기를 해야 한다 업무 공간 서비스를 설명하는데 관련 없는 풍경이 화면을 채우면, 문구가 모든 설명을 맡게 됩니다. 서비스 장면을 촬영할 수 있다면 그 사진을 우선 검토하고, 개념을 설명하는 글이나 서비스라면 주제와 연결되는 삽화도 사용할 수 있습니다. 실제 작업 사진과 AI로 만든 개념 이미지는 역할을 구분해 표시하세요. 버튼은 이동한 뒤 보게 될 내용을 예고해야 합니다. ‘자세히 보기’보다 ‘작업 사례 보기’, ‘무료 체험’보다 실제 제공 내용에 맞는 ‘체험 신청하기’가 더 구체적입니다. 가격 확인을 기대하게 만든 버튼이 상담 폼으로만 이어진다면 제목이나 도착 페이지를 수정하는 편이 좋습니다. 회전 배너가 여러 개라면 중요한 설명이 두 번째 장에 숨지 않는지 살펴보세요. 영상은 브랜드에 맞는 장면을 보여줄 수 있지만, 정지 이미지 상태에서도 문구와 버튼이 이해되어야 합니다. 화면을 채우기 위해 영상을 넣는 것보다 영상이 설명에 어떤 기여를 하는지 먼저 판단합니다. 5. 모바일에서 다시 확인할 항목 5. 모바일에서 다시 확인할 항목 — 비교·점검표 점검 확인 방법 수정 방향 문구 작은 화면에서 제목을 한 번에 읽어보기 의미 단위로 줄바꿈하고 불필요한 수식어 줄이기 이미지 세로 화면에서 중요한 피사체 확인 모바일 구도를 별도로 지정하고 핵심 부분 보존 버튼 엄지로 누르고 도착 페이지 확인 충분한 조작 공간, 구체적인 버튼명, 올바른 연결 첫 로딩 느린 연결에서도 제목과 버튼 확인 큰 영상·이미지의 용량과 로딩 우선순위 점검 내용 흐름 화면 아래로 계속 읽을 이유 확인 다음 구역의 제목이나 내용 일부로 흐름 연결 첫 화면에 모든 내용을 넣을 필요는 없습니다. 중요한 것은 화면 높이 하나에 억지로 맞추는 일이 아니라, 첫 부분에서 의미를 전달하고 다음 내용을 자연스럽게 찾게 하는 일입니다. 자주 묻는 질문 첫 화면 제목은 꼭 한 줄이어야 하나요? 아닙니다. 기기 크기와 글꼴에 따라 줄 수는 달라집니다. 두 줄이더라도 대상과 제공 가치가 분명하면 됩니다. 한 줄을 맞추려고 글자를 과도하게 줄이거나 중요한 단어를 삭제하지 마세요. 문의 버튼을 가장 크게 만들면 문의가 늘어나나요? 버튼 크기만으로 결과를 예측할 수 없습니다. 문의 전에 필요한 설명과 신뢰 근거가 충분한지, 신청 과정이 부담스럽지 않은지 함께 봐야 합니다. 사례를 먼저 보려는 방문자에게는 사례 링크가 유용한 다음 단계일 수 있습니다. 첫 화면의 SEO는 어떻게 준비하나요? 방문자가 이해할 수 있는 주제 제목과 본문을 실제 텍스트로 제공합니다. 중요한 설명을 이미지 안에만 넣지 말고, 이미지 대체 텍스트는 그림이 전달하는 내용을 적습니다. 핵심 키워드를 반복하기보다 페이지 전체가 해당 서비스에 대한 질문에 답하도록 구성하세요. 참고한 원칙과 함께 읽을 글 NN/g는 홈페이지가 조직의 역할과 사용자가 할 수 있는 일을 분명히 전달하고, 구체적인 예시와 행동 경로를 제공해야 한다고 설명합니다. 위 세 가지 안은 이 원칙을 참고해 슬로히어로가 구성한 가상 예시입니다. NN/g 홈페이지 디자인 원칙 첫 화면 뒤의 전체 구조는 고객 질문으로 사이트맵 만들기 , 사이트 전체 점검은 좋은 홈페이지의 기준 에서 이어서 확인할 수 있습니다. 작성: 슬로히어로 · 글의 개념을 표현하는 삽화는 AI로 제작했습니다. 본문의 가상 예시와 실제 자료는 구분해 표시했습니다. Sat, 26 Sep 2026 00:00:00 +0900 https://slohero.com/blog/homepage-first-screen https://slohero.com/blog/good-website-criteria 홈 / 블로그 / 제작 기준과 기획 SLOHERO / WEBSITE PLANNING 좋은 홈페이지의 기준: 첫인상부터 문의·운영까지 6가지 좋은 홈페이지는 첫인상뿐 아니라 정보 이해, 신뢰, 문의 과정, 모바일 사용성, 운영까지 갖춰야 합니다. 예시와 6가지 실전 점검표로 우리 사이트를 살펴보세요. 슬로히어로 · 제작 기준과 기획 · 2026년 9월 26일 이 글에서 살펴볼 내용 1. 첫 화면에서 무엇을 하는 곳인지 알 수 있다 2. 고객이 궁금해하는 순서로 정보가 나온다 3. 설명을 믿을 수 있는 근거가 있다 4. 다음 행동과 그 이후의 과정이 분명하다 5. 사용하는 환경이 달라져도 편하게 이용할 수 있다 6. 공개한 뒤에도 정보를 정확하게 유지할 수 있다 우리 홈페이지를 살펴보는 여섯 가지 질문 우리 브랜드에 필요한 홈페이지를 준비하고 있나요? 마음에 드는 홈페이지를 발견하면 먼저 화면에 눈이 갑니다. 사진의 분위기, 글자의 크기, 색의 조합, 스크롤할 때 나타나는 움직임. 이런 요소는 브랜드의 첫인상을 만듭니다. 그런데 우리 회사에 필요한 홈페이지를 고르려면 몇 가지를 더 살펴봐야 합니다. 처음 방문한 사람이 우리가 하는 일을 이해할 수 있는지. 궁금한 정보를 쉽게 찾을 수 있는지. 충분히 알아본 뒤 문의하거나 예약할 수 있는지. 그리고 운영자가 필요한 내용을 계속 관리할 수 있는지. 좋은 홈페이지의 기준은 이처럼 실제로 사용하는 장면에서 구체적으로 드러납니다. 1. 첫 화면에서 무엇을 하는 곳인지 알 수 있다 방문자는 홈페이지에 들어오기 전까지 우리 회사에 대해 거의 모를 수 있습니다. 검색 결과에서 들어왔을 수도 있고, 누군가 보내준 링크를 눌렀을 수도 있습니다. 그런 사람에게 첫 화면은 소개의 시작입니다. 어떤 서비스를 제공하는지, 누구를 위한 서비스인지, 어떤 도움이 되는지가 자연스럽게 전달되어야 합니다. 브랜드 이름과 멋진 문장이 있어도 이 내용을 파악하기 어렵다면 방문자는 설명을 찾는 일부터 해야 합니다. 예를 들어 예약 관리 서비스를 소개한다고 해보겠습니다. “비즈니스의 새로운 가능성을 엽니다”라는 문장은 여러 업종에 사용할 수 있습니다. 여기에 “예약 접수부터 일정 변경, 고객 안내까지 한곳에서 관리합니다”라는 설명이 더해지면 서비스의 역할이 구체적으로 보입니다. 첫 화면의 모든 문장을 기능 설명으로 채울 필요는 없습니다. 브랜드의 분위기를 만드는 문장과 실제 제공하는 일을 설명하는 문장이 함께 있으면 됩니다. 사진과 영상도 같은 역할을 해야 합니다. 방문자가 그 화면을 보고 서비스나 결과물을 더 잘 이해할 수 있어야 합니다. 첫 화면의 문장, 이렇게 구체화할 수 있습니다 아래는 예약 관리 서비스를 가정한 설명용 예시입니다. 1. 첫 화면에서 무엇을 하는 곳인지 알 수 있다 — 비교·점검표 항목 처음 문장 구체화한 문장 대상 당신의 비즈니스를 위해 예약으로 운영하는 스튜디오와 매장을 위해 역할 새로운 가능성을 엽니다 예약 접수·일정 변경·고객 안내를 한곳에서 관리합니다 다음 행동 자세히 보기 예약 관리 기능 살펴보기 처음 방문한 사람이 첫 화면만 보고 “이곳은 누구에게 어떤 일을 해주는 곳인가”를 자기 말로 설명할 수 있나요? 2. 고객이 궁금해하는 순서로 정보가 나온다 회사에 있는 자료의 순서와 고객이 궁금해하는 순서는 다를 수 있습니다. 회사에서는 연혁과 철학부터 소개하고 싶을 수 있습니다. 하지만 제작을 맡길 업체를 찾는 고객은 작업 사례, 가능한 제작 범위, 진행 방식부터 확인하고 싶을 수 있습니다. 홈페이지의 구조는 이런 방문 목적을 고려해야 합니다. 스튜디오 예약을 준비하는 사람이라면 촬영 분위기를 살펴본 뒤 상품 구성과 이용 조건을 확인하고, 가능한 일정과 예약 방법을 찾을 수 있습니다. 갤러리를 방문하려는 사람에게는 현재 전시와 관람 시간, 위치가 먼저 필요할 수 있습니다. 정보가 충분히 있어도 찾기 어렵다면 방문자에게는 없는 정보처럼 느껴집니다. 메뉴 이름도 중요합니다. 운영자에게 익숙한 내부 용어나 추상적인 표현을 사용할 때는, 처음 온 사람이 그 안에 무엇이 있는지 예상할 수 있는지 확인해야 합니다. 페이지를 읽는 동안 다음 질문의 답이 자연스럽게 나타나는지 살펴보세요. “무엇을 하는 곳이지?” “내가 찾는 서비스가 맞나?” “어떤 결과를 기대할 수 있지?” “어떻게 시작하면 되지?” 주요 고객이 자주 묻는 세 가지 질문을 적어보세요. 홈페이지에서 각각의 답을 어디에서 찾을 수 있나요? 3. 설명을 믿을 수 있는 근거가 있다 “전문적입니다.” “세심하게 진행합니다.” “높은 완성도를 제공합니다.” 이런 문장은 회사가 중요하게 생각하는 태도를 전달합니다. 방문자가 실제로 판단하려면 그 태도가 드러나는 자료가 함께 필요합니다. 제작사라면 실제 작업 화면과 맡은 범위가 근거가 될 수 있습니다. 어떤 요구가 있었고, 무엇을 만들었으며, 사용자가 어떻게 이용하는지 설명하면 작업을 더 구체적으로 이해할 수 있습니다. 제품을 판매한다면 실제 사용 모습과 소재, 크기, 관리 방법이 선택에 도움이 됩니다. 공간을 소개한다면 전체 분위기와 함께 동선, 시설, 이용 조건을 확인할 수 있어야 합니다. 자료가 많을수록 좋은 것도 아닙니다. 방문자가 판단하는 데 필요한 장면을 골라 보여주는 편이 효과적일 수 있습니다. 작업 사례 한 건을 올리더라도 다음 내용이 있으면 이해하기 쉽습니다. 어떤 상황과 요구에서 시작했는지 어디까지 작업했는지 주요 화면이나 기능이 어떤 역할을 하는지 결과를 확인할 수 있는 자료가 무엇인지 성과 수치를 제시한다면 측정 기간과 기준을 함께 설명해야 합니다. 자체 콘셉트 작업이나 예시 화면은 그 성격을 밝혀두는 것이 좋습니다. 홈페이지에 적힌 가장 중요한 장점 옆에, 방문자가 직접 확인할 수 있는 자료가 있나요? 4. 다음 행동과 그 이후의 과정이 분명하다 홈페이지를 충분히 읽은 사람은 다음에 무엇을 하면 될까요? 문의, 예약, 구매, 자료 다운로드처럼 페이지마다 기대하는 행동이 있을 수 있습니다. 방문자가 그 행동을 선택할 수 있는 위치에 안내가 있어야 합니다. 버튼의 문구도 과정을 설명하는 일부입니다. “신청하기”만으로는 무엇이 신청되는지 모호할 수 있습니다. “상담 일정 요청하기”, “견적 문의 보내기”처럼 구체적인 표현을 쓰면 누르기 전에 결과를 예상하기 쉽습니다. 버튼 다음의 경험도 살펴봐야 합니다. 문의에 어떤 정보를 적어야 하는지, 신청하면 바로 확정되는지, 담당자의 확인이 필요한지 알려주세요. 제출이 완료되면 접수 여부와 이후 절차를 안내해야 합니다. 특히 예약 요청과 예약 확정은 다를 수 있습니다. 방문자가 오해하지 않도록 현재 상태를 명확히 보여주는 것이 중요합니다. 입력 항목 역시 실제 처리 과정에 필요한지 검토해야 합니다. 처음 상담을 시작하는 데 필요한 정보와, 계약 후 받아도 되는 정보를 구분하면 신청 과정을 정리하기 쉽습니다. 예약의 각 단계에서 알려줘야 할 것 담당자 확인을 거쳐 예약이 확정되는 서비스를 가정했습니다. 실제 안내는 서비스의 처리 방식에 맞춰 작성합니다. 4. 다음 행동과 그 이후의 과정이 분명하다 — 비교·점검표 단계 고객의 질문 필요한 안내 요청 전 누르면 바로 예약되나요? 먼저 희망 일정을 접수하며, 담당자 확인 후 확정된다는 설명 입력 중 무엇을 적어야 하나요? 필요한 정보, 필수 항목, 입력 오류를 고치는 방법 접수 후 제대로 전달됐나요? 접수 완료 여부, 아직 확정되지 않았다는 상태, 회신 방법 확정 후 언제 어디로 가면 되나요? 확정 일시와 장소, 준비 사항, 변경·취소 방법 처음 온 사람도 버튼을 누르면 무슨 일이 일어나는지, 완료한 다음에는 무엇을 기다리면 되는지 알 수 있나요? 5. 사용하는 환경이 달라져도 편하게 이용할 수 있다 제작 중에는 큰 모니터로 홈페이지를 보는 시간이 많습니다. 고객은 이동 중에 휴대폰으로 접속하거나, 화면을 확대해 읽거나, 키보드로 메뉴를 이동할 수 있습니다. 좋은 홈페이지는 이런 사용 환경을 함께 고려합니다. 모바일에서는 내용을 좁은 화면에 배치하는 것과 함께 읽는 순서, 글자 크기, 버튼 간격을 살펴봐야 합니다. 고정된 메뉴가 내용을 가리지 않는지, 긴 제목과 입력창이 잘리지 않는지도 확인해야 합니다. 이미지가 나타나기 전에도 어떤 페이지인지 이해할 수 있는지, 중요한 안내를 색상만으로 구분하고 있지는 않은지, 움직이는 요소 때문에 읽기가 어려워지지는 않는지도 검토할 부분입니다. 확인할 때는 페이지를 눈으로 훑어보는 데서 한 걸음 더 나아가 실제 행동을 해보는 것이 좋습니다. 상품을 비교하고, 문의를 작성하고, 입력 오류를 수정하고, 완료 안내까지 읽어보세요. 중간에 막히거나 헷갈리는 부분이 발견될 수 있습니다. 휴대폰으로 처음부터 문의 완료까지 직접 진행했을 때, 확대하거나 돌아가거나 추측해야 하는 구간이 있나요? 6. 공개한 뒤에도 정보를 정확하게 유지할 수 있다 홈페이지를 공개한 뒤에도 회사의 정보는 바뀝니다. 상품과 가격이 달라지고, 새로운 작업이 쌓이고, 담당자와 운영 시간이 변경됩니다. 이런 내용을 제때 반영할 수 있어야 홈페이지가 계속 제 역할을 할 수 있습니다. 자주 바뀌는 항목은 누가, 어떤 방식으로 수정할지 미리 정하는 것이 좋습니다. 모든 홈페이지에 복잡한 관리자 기능이 필요한 것은 아닙니다. 변경 빈도와 담당자의 업무 방식에 맞는 관리 방법이 필요합니다. 문의가 접수되었을 때 확인할 사람과 전달 경로도 정해져 있어야 합니다. 고객에게 보이는 화면과 내부 처리 과정이 이어져야 하기 때문입니다. 운영하면서 살펴볼 항목도 정할 수 있습니다. 고객이 같은 질문을 반복한다면 설명이 부족하거나 찾기 어려운지 확인합니다. 문의 과정에서 어려움을 겪는다면 입력 항목과 안내를 점검합니다. 오래된 사례가 첫 화면에 남아 있다면 현재 보여주고 싶은 역량과 맞는지 검토합니다. 이렇게 실제 사용에서 발견한 문제를 반영하면 다음 수정의 이유가 분명해집니다. 가격, 일정, 작업 사례가 바뀌었을 때 누가 어떻게 수정하는지 정해져 있나요? 접수된 문의를 확인하는 과정도 마련되어 있나요? 우리 홈페이지를 살펴보는 여섯 가지 질문 홈페이지를 검토할 때 다음 항목을 직접 확인해보세요. 평가 점수를 매기기보다, 어디에서 막혔고 무엇을 바꿔야 하는지 적어두면 다음 수정이 구체적이 됩니다. 우리 홈페이지를 살펴보는 여섯 가지 질문 — 비교·점검표 기준 직접 해볼 일 기록할 것 이해 사이트를 처음 보는 사람에게 첫 화면만 보여주고, 어떤 일을 하는 곳인지 물어보기 실제 설명과 다르게 이해한 내용 정보 고객이 자주 묻는 세 가지 질문의 답을 찾아보기 찾지 못했거나 여러 번 돌아간 정보 신뢰 핵심 장점을 뒷받침하는 작업·제품·서비스 자료를 확인하기 설명에 비해 근거가 부족한 부분 행동 문의나 예약을 시작해 완료 안내까지 진행하기 다음 행동이나 현재 상태가 모호한 구간 사용 휴대폰과 PC에서 이용하고, 키보드로 메뉴와 입력창 이동하기 읽기·이동·입력을 방해한 요소 운영 가격·일정·사례 한 가지를 바꾸는 담당자와 절차 확인하기 담당자가 없거나 방법이 불명확한 작업 여섯 항목의 우선순위는 홈페이지의 목적에 따라 달라집니다. 작품을 보여주는 포트폴리오와 예약을 받는 스튜디오, 제품을 판매하는 쇼핑몰은 고객이 방문하는 이유부터 다르기 때문입니다. 먼저 가장 중요한 방문자 한 명과, 그 사람이 홈페이지에서 해결해야 할 일 하나를 정해보세요. 그리고 실제 방문자의 입장에서 첫 화면부터 끝까지 이용해보세요. 좋은 홈페이지의 기준은 그 과정에서 더 선명해집니다. 브랜드를 이해할 수 있고, 선택에 필요한 근거를 찾을 수 있고, 원하는 일을 무리 없이 마칠 수 있는 홈페이지. 그 경험이 쌓이면서 화면의 인상도 브랜드에 대한 신뢰로 이어집니다. 우리 브랜드에 필요한 홈페이지를 준비하고 있나요? 슬로히어로는 브랜드의 첫인상부터 고객의 이용 과정, 공개 이후의 운영까지 함께 생각하며 웹사이트를 만듭니다. 만들고 싶은 사이트와 주요 고객, 필요한 기능을 알려주세요. 프로젝트에 맞는 구성과 제작 범위부터 함께 정리하겠습니다. 홈페이지 제작 안내 보기 작성: 슬로히어로 · 글의 개념을 표현하는 삽화는 AI로 제작했습니다. 본문의 가상 예시와 실제 자료는 구분해 표시했습니다. Sat, 26 Sep 2026 00:00:00 +0900 https://slohero.com/blog/good-website-criteria https://slohero.com/blog/customer-question-sitemap 홈 / 블로그 / 제작 기준과 기획 SLOHERO / WEBSITE PLANNING 홈페이지 사이트맵 만들기: 고객 질문을 메뉴 구조로 바꾸는 방법 회사소개·서비스 메뉴부터 정하기 전에 고객 질문을 모아보세요. 질문을 페이지와 메뉴로 바꾸는 사이트맵 예시, 페이지 분리 기준과 검증 방법을 정리했습니다. 슬로히어로 · 제작 기준과 기획 · 2026년 9월 26일 이 글에서 살펴볼 내용 1. 회사 내부 분류보다 고객의 질문을 먼저 모으기 2. 질문을 페이지로 바꾸는 표 만들기 3. 페이지로 독립시킬지, 한 페이지에 묶을지 결정하기 4. 전체 사이트맵과 상단 메뉴를 구분하기 5. 메뉴 이름은 클릭하기 전에 이해되어야 한다 6. 사이트맵을 원고와 운영 계획에 연결하기 자주 묻는 질문 참고한 자료와 다음 단계 홈페이지 사이트맵은 고객이 찾는 정보를 어떤 페이지에 담고 어떻게 연결할지 정하는 설계도입니다. 메뉴 이름부터 고르기보다 고객 질문을 모으고, 같은 판단에 필요한 질문을 묶은 뒤, 페이지와 이동 경로를 정하는 순서 로 만들면 구조를 설명하기 쉬워집니다. 여기서 말하는 사이트맵은 기획 단계의 페이지 구조도입니다. 검색엔진에 URL 목록을 알리는 XML 사이트맵과는 역할이 다릅니다. 페이지 구조를 먼저 설계하고, 공개 후 검색엔진이 발견해야 할 주소를 XML 사이트맵에 반영합니다. 1. 회사 내부 분류보다 고객의 질문을 먼저 모으기 회사 내부에서 ‘사업1팀’과 ‘사업2팀’으로 업무를 나누더라도 방문자는 그 구분을 모를 수 있습니다. 고객이 어떤 서비스가 필요한지 판단할 수 있는 이름과 설명이 필요합니다. 상담 메일, 문의 폼, 영업 담당자의 설명, 기존 사이트 검색어에서 실제 질문을 모으세요. 아직 문의 기록이 없다면 가설부터 적을 수 있습니다. 대신 실제 고객에게 확인하지 않은 질문이라는 점을 구분해두고, 상담이 쌓일 때 수정합니다. 경쟁사 메뉴를 그대로 복사하면 그 회사의 서비스 구조와 고객을 함께 가져오는 셈이므로 우리 사업에 맞는지 별도로 판단해야 합니다. 가상의 기업 교육 서비스를 예로 들어보겠습니다. 의뢰 담당자가 알아야 할 것은 조직도보다 교육 대상, 주제, 운영 방식, 일정 협의, 강사와 사례일 수 있습니다. 질문을 적을 때는 ‘콘텐츠’ 같은 추상적인 단어 대신 “신입사원 대상으로 진행할 수 있나요?”처럼 실제 문장으로 씁니다. 2. 질문을 페이지로 바꾸는 표 만들기 2. 질문을 페이지로 바꾸는 표 만들기 — 비교·점검표 고객 질문 필요한 답과 근거 담을 페이지 다음 행동 우리 팀에 맞는 교육이 있나요? 대상·목표·주제별 제공 범위 교육 프로그램 해당 프로그램 상세 보기 무엇을 배우고 어떤 결과물이 남나요? 구성·실습·제공 자료 예시 프로그램 상세 운영 방식 확인 온라인과 방문 교육 모두 가능한가요? 장소·인원·장비·진행 조건 운영 안내 일정·조건 문의 비슷한 조직에서 진행한 적 있나요? 공개 허가를 받은 사례와 진행 범위 교육 사례 관련 프로그램 보기 누가 진행하며 믿을 수 있나요? 강사 소개·검증 가능한 이력·담당 역할 팀 소개 프로그램·사례 확인 견적에 무엇을 알려드려야 하나요? 대상·인원·희망 일정·주제 입력 안내 교육 문의 접수 후 절차 확인 이 표의 장점은 페이지를 추가할 이유가 분명해진다는 점입니다. ‘팀 소개 페이지가 필요하다’보다 ‘강사와 운영 주체를 확인하려는 질문에 답해야 한다’가 더 구체적인 기획 기준이 됩니다. 예시의 프로그램 구성이나 실적은 실제 업체의 자료가 아닙니다. 3. 페이지로 독립시킬지, 한 페이지에 묶을지 결정하기 질문마다 페이지를 하나씩 만들면 정보가 지나치게 잘게 나뉩니다. 반대로 모든 질문을 메인에 넣으면 원하는 답을 다시 찾기 어렵습니다. 같은 선택을 돕는 내용은 함께 묶고, 방문 목적과 필요한 근거가 충분히 다른 내용은 분리 하는 방식으로 판단하세요. ‘온라인 진행 가능 여부’와 ‘준비 장비’는 운영 안내에 함께 둘 수 있습니다. 그러나 리더십 교육과 데이터 분석 교육처럼 대상·목표·교육 내용이 다른 프로그램은 각각 설명할 자료가 충분하다면 별도 상세 페이지가 유용합니다. 제목만 바꾸고 내용이 거의 같은 페이지를 늘리는 방식은 피합니다. 3. 페이지로 독립시킬지, 한 페이지에 묶을지 결정하기 — 비교·점검표 판단 항목 같은 페이지에 묶기 별도 페이지 검토 고객의 목적 하나의 서비스를 선택하는 같은 과정 서로 다른 서비스를 찾는 방문 설명 자료 짧은 조건이나 한두 개 답변 독립적인 범위·사례·FAQ가 충분함 공유 필요 페이지의 특정 구역 링크로 충분 광고·영업 메일에서 전용 주소가 필요 운영 방식 같은 담당자·주기로 갱신 등록·수정 방식이나 담당자가 다름 4. 전체 사이트맵과 상단 메뉴를 구분하기 사이트맵에 포함된 모든 페이지를 상단 메뉴에 올릴 필요는 없습니다. 프로그램 상세는 프로그램 목록에서, 개별 사례는 사례 목록에서 들어가도록 구성할 수 있습니다. 이용 안내와 개인정보 안내처럼 위치가 예상되는 정보는 하단 메뉴도 활용합니다. 교육 서비스 예시의 상단 메뉴는 ‘교육 프로그램 / 운영 안내 / 교육 사례 / 팀 소개’로 묶고 ‘교육 문의’를 별도 행동 버튼으로 둘 수 있습니다. 프로그램 아래에는 주제별 상세 페이지, 사례 아래에는 개별 사례가 연결됩니다. 메뉴 수를 특정 숫자에 맞추는 것보다 이름만 보고 목적지를 예측할 수 있는지가 중요합니다. 구조 예시: 홈 → 교육 프로그램 → 프로그램 상세 → 관련 교육 사례 → 교육 문의. 이 흐름은 유일한 경로가 아닙니다. 검색에서 프로그램 상세로 바로 들어온 사람도 홈을 거치지 않고 운영 조건과 문의를 찾을 수 있어야 합니다. 상세 페이지의 관련 링크와 문의 연결을 함께 설계해야 하는 이유입니다. 5. 메뉴 이름은 클릭하기 전에 이해되어야 한다 ‘솔루션’, ‘가치’, ‘경험’이라는 말이 브랜드에는 어울려도 방문자가 목적지를 예상하기 어려울 수 있습니다. 브랜드 언어를 쓰더라도 메뉴명이나 설명에서 실제 내용을 밝혀주세요. ‘교육 프로그램’과 ‘교육 사례’처럼 비슷해 보이는 두 메뉴는 각각 무엇이 들어가는지 짧게 설명해도 좋습니다. 새 구조를 점검할 때는 화면 디자인 없이 메뉴와 페이지 제목만 보여주고 질문해보세요. “방문 교육에 필요한 장비를 어디에서 찾겠어요?”처럼 실제 과제를 제시합니다. 정답을 먼저 알려주지 않고 선택과 이유를 기록하면 분류의 모호한 지점을 발견할 수 있습니다. 적은 사람을 대상으로 한 확인은 개선 단서를 주지만 전체 고객의 행동을 대표하는 통계로 해석해서는 안 됩니다. 6. 사이트맵을 원고와 운영 계획에 연결하기 구조가 정해지면 각 페이지에 담당자, 필요한 자료, 주요 버튼, 공개 여부를 붙입니다. 자료가 준비되지 않은 페이지는 제목만 있는 채로 공개하기보다 준비 일정을 정하는 편이 낫습니다. 기획서에는 ‘회사소개 작성’ 대신 ‘운영 주체·담당 역할·연락 경로 확인’처럼 완료 조건을 적으세요. 리뉴얼이라면 기존 URL도 함께 기록해야 합니다. 메뉴 이름을 바꾸더라도 주소를 반드시 바꿀 필요는 없습니다. 주소 변경이 필요하다면 대응 페이지와 이동 처리를 별도 목록으로 관리합니다. 이 부분은 리뉴얼 콘텐츠 정리 방법 에서 구체적으로 다룹니다. 자주 묻는 질문 작은 홈페이지도 사이트맵이 필요한가요? 한 페이지 사이트도 내용 구역과 이동 순서를 정리하면 도움이 됩니다. 고객 질문, 답할 구역, 주요 행동을 한 장에 적는 정도로 시작할 수 있습니다. 복잡한 도구보다 구조를 공유할 수 있는지가 중요합니다. 사이트맵을 만들면 SEO가 끝나나요? 아닙니다. 기획 구조는 출발점입니다. 각 페이지에 실제 도움이 되는 내용이 있어야 하고, 내부 링크·접근 가능한 HTML·색인 허용·대표 주소 등도 확인해야 합니다. XML 사이트맵 제출 역시 모든 URL의 색인이나 검색 노출을 보장하지 않습니다. Google 사이트맵 안내 참고한 자료와 다음 단계 웹사이트 기획에서 목적과 방문자, 정보 구조를 함께 정리하는 접근은 Orbit Media의 웹사이트 기획 가이드 를 참고했습니다. 위 교육 서비스 질문표와 구조는 이해를 돕기 위한 자체 구성 예시입니다. 구조를 정했다면 페이지별 설득 역할 을 확인하고, 실제 의뢰용 문서에는 홈페이지 기획서 예시 를 활용해보세요. 작성: 슬로히어로 · 글의 개념을 표현하는 삽화는 AI로 제작했습니다. 본문의 가상 예시와 실제 자료는 구분해 표시했습니다. Sat, 26 Sep 2026 00:00:00 +0900 https://slohero.com/blog/customer-question-sitemap https://slohero.com/blog/planning-doc-example 홈페이지 기획서는 ‘누가 들어와서 무엇을 확인하고 어떤 행동을 해야 하는지’를 제작사와 합의하는 문서입니다. 처음부터 두꺼운 자료를 만들 필요는 없습니다. 목적·페이지·기능·자료·담당자를 먼저 정리하고, 예약이나 결제처럼 규칙이 필요한 기능에만 상세 내용을 덧붙이면 됩니다. 아래에 기업 소개형과 예약 문의형 기획서 예시를 넣었습니다. 두 예시는 설명을 위해 만든 가상 프로젝트이며 실제 고객의 의뢰서가 아닙니다. 작성용 빈 양식과 완료 예시 내려받기 YOUR PROJECT / WORKSHEET 홈페이지 기획서, 여기서 작성해 보세요 미정인 항목은 비워 두어도 됩니다. 작성 내용은 서버로 전송하거나 저장하지 않습니다. 페이지를 닫기 전에 복사하거나 파일로 내려받으세요. 작성 내용 정리 기능은 자바스크립트가 필요합니다. 위의 Word 또는 PDF 빈 양식을 이용하세요. 01. 목적 홈페이지가 해결해야 할 업무 02. 방문자와 핵심 행동 누가 어떤 상황에서 무엇을 해야 하나요? 03. 페이지와 역할 메뉴 이름과 각 페이지에서 확인할 내용 04. 기능과 처리 방식 입력 → 처리 → 결과와 운영자 행동 05. 준비 자료 원고·사진·로고의 준비 상태와 제공 담당자 06. 참고 방향 참고 링크와 좋아하는 부분을 함께 적으세요 07. 일정과 승인 담당자 희망 오픈일, 반드시 지켜야 할 날짜, 최종 승인자 08. 예산 범위와 완료 기준 포함·제외할 일과 확인 방법 작성 내용 정리하기 내용 복사 텍스트로 저장 작성 내용 인쇄 / PDF 빈 문서가 필요하면 Word 양식 · PDF 양식 을 이용하세요. 기존 텍스트 양식과 완료 예시 도 제공합니다. 홈페이지 기획서에는 어떤 항목이 필요한가요? 항목 적을 내용 피할 표현 목적 홈페이지로 해결하려는 업무 “예쁘게”, “매출을 많이” 방문자 어떤 상황에서 들어오는 사람인지 “누구나” 핵심 행동 문의·예약·자료 확인 등 모든 행동을 같은 비중으로 나열 페이지 페이지별 역할과 주요 내용 “일반 회사 홈페이지처럼” 기능 입력·처리·결과·운영자 행동 “예약 가능하게” 자료 원고·로고·사진의 준비 상태 “나중에 드릴게요” 참고 방향 참고할 부분과 피할 부분 링크만 여러 개 전달 일정·담당자 희망일·필수 마감·최종 승인자 확인 담당자가 없는 일정 목표가 아직 정해지지 않았다면 “사이트를 본 사람이 전화하기 전에 무엇을 알면 좋을까?”부터 적어 보세요. 회사 소개 문구보다 먼저 필요한 내용을 찾을 수 있습니다. 예시 1. 기업 소개와 견적 문의를 위한 5페이지 가상 기업 ‘한빛부품’의 소개형 홈페이지를 가정하겠습니다. 상품을 온라인으로 판매하지 않고, 구매 담당자가 제작 가능 품목을 확인한 뒤 견적을 문의하는 용도입니다. 기획 항목 작성 완료 예시 목적 구매 담당자가 가공 품목과 의뢰 조건을 확인하고 견적을 요청하게 한다. 방문자 새 공급업체를 찾는 제조업 구매 담당자. 모바일과 사무실 PC에서 접속한다. 핵심 행동 품목·수량·희망 납기를 적어 견적 문의를 보낸다. 페이지 메인, 회사 소개, 가공 품목, 제작 사례, 견적 문의의 5개 페이지 문의 기능 회사명·담당자·회신 연락처·품목·수량·희망 납기·문의 내용 입력. 파일 첨부는 이번 범위에서 제외 처리 방식 담당자 메일 알림과 관리 화면 저장. 접수 안내는 즉시 보여주되 견적 확정으로 표현하지 않음 자료 상태 로고 보유. 품목 설명 초안 있음. 사진 12장은 고객이 제공하고 사용 가능한지 확인 참고 방향 큰 제품 사진과 단순한 메뉴. 자동 재생 영상과 과도한 화면 효과는 제외 담당자 총무 담당자가 의견 취합, 대표가 디자인과 원고 최종 승인 일정 자료 확정 후 세부 일정 협의. 박람회 전 공개가 필요하므로 행사일을 별도 전달 제외 범위 회원가입, 온라인 결제, 재고 연동, 다국어 완료 기준 모바일에서 품목을 읽고 테스트 문의를 보내면 관리 화면과 담당자 메일에서 확인 가능 이 예시에서 견적을 바꾸는 질문 “제작 사례 페이지”가 사례 3건을 한 화면에 정리하는 것인지, 사례마다 상세 페이지를 만드는 것인지 확인해야 합니다. 후자라면 페이지 수와 입력 작업이 늘어날 수 있습니다. 첨부파일도 마찬가지입니다. 문의 양식에 도면 업로드를 추가하려면 허용 형식·용량·보관·접근 권한까지 정해야 합니다. 기능 이름 한 줄이 아니라 실제 사용 방식을 써야 제작 범위가 보입니다. 예시 2. 상담으로 예약을 확정하는 스튜디오 홈페이지 가상 스튜디오 ‘온빛사진’은 홈페이지에서 결제를 받지 않고 희망 촬영일을 접수한 뒤 담당자가 일정을 확인한다고 가정하겠습니다. 기획 항목 작성 완료 예시 목적 촬영 상품을 소개하고 예약 상담에 필요한 정보를 한 번에 받는다. 방문자 가족사진 촬영을 알아보는 고객. 주로 휴대폰으로 사진과 가격 조건을 비교한다. 핵심 행동 상품과 희망일을 선택해 상담을 신청한다. 페이지 촬영 소개, 상품 안내, 포트폴리오, 예약 문의 예약 방식 실시간 확정 예약이 아닌 희망일 접수. 접수 뒤 담당자가 연락해 확정 입력 항목 선택 상품, 희망일, 인원, 이름, 회신 연락처, 전달할 요청 운영자 작업 문의 상태를 접수·연락 완료·예약 확정·취소로 구분 자료 상태 촬영 상품 3종 설명과 금액표 제공. 사진은 사용 동의가 확인된 이미지로 전달 일정 규칙 홈페이지에서 가능 날짜를 실시간 보장하지 않음. 확정 여부는 담당자가 확인 수정 범위 상품 설명·금액·포트폴리오는 운영자가 직접 수정하도록 요청 제외 범위 온라인 결제, 자동 환불, 작가별 실시간 일정 연동 완료 기준 문의가 저장되고 담당자가 상태를 바꿀 수 있음. 고객에게 접수와 예약 확정을 혼동시키지 않음 이 문서라면 제작사는 ‘예약 달력과 결제까지 연결된 시스템’을 견적에 넣어야 하는지 되묻지 않아도 됩니다. 이후 실시간 예약이 필요해지면 별도 기능으로 확장 범위를 정할 수 있습니다. 슬로히어로의 실제 리즈 제작 사례 는 예약 가능 여부, 상품 금액, 관리자와 사진 셀렉을 연결한 다른 범위의 작업입니다. 같은 스튜디오 홈페이지라도 필요한 업무 흐름이 다르면 기획서와 견적이 달라집니다. REAL WORK / RIZZ 기획서의 문장은 어디에 나타날까요? “촬영 분위기를 보고 문의한다”는 목적은 큰 작업 사진과 간결한 메뉴로 이어집니다. PC에서는 사진을 넓게 보여주고, 모바일에서는 세로 화면에 맞춰 첫인상을 구성합니다. 함께 실은 이미지는 실제 제작 화면입니다. 아래 흐름도는 이 완성 화면을 바탕으로 재구성한 설명용 예시이며, 고객의 원본 기획서는 아닙니다. 리즈 홈페이지 제작 사례 ↗ PC · 작업 분위기를 먼저 보여주는 구성 Mobile · 화면에 맞춘 구성 공개된 완성 화면을 바탕으로 재구성한 기획 설명. 실제 의뢰서나 제작 당시의 원본 와이어프레임이 아닙니다. 목표를 먼저 적습니다 예쁜 예약 페이지보다, 누가 무엇을 요청하는지 한 문장으로 정합니다. 입력 순서를 정합니다 필요한 선택을 작은 단계로 나눠, 방문자가 다음 행동을 알 수 있게 합니다. 완료 상태를 정합니다 신청 접수와 예약 확정을 구분합니다. 실제 운영 방식은 제작 전에 합의합니다. 페이지 목록은 한 줄씩 역할을 나눠 적으세요 방문자가 각 페이지에서 답을 얻을 질문을 적으면 불필요한 메뉴를 줄일 수 있습니다. 페이지 방문자가 해결할 질문 필요한 자료 메인 이 업체가 내가 찾는 일을 하는가? 핵심 제안·대표 사진·문의 경로 서비스 정확히 어디까지 제공하는가? 포함·제외 범위·절차 사례 비슷한 일을 해본 적이 있는가? 결과물·작업 범위·확인 가능한 설명 문의 무엇을 보내면 답을 받을 수 있는가? 입력 항목·처리 안내·연락처 ‘회사 소개’와 ‘대표 인사말’에 같은 내용이 반복된다면 합칠 수 있습니다. 반대로 서로 다른 고객이 찾는 서비스는 각각 설명할 페이지가 필요할 수 있습니다. 메뉴 개수보다 역할의 차이를 먼저 보세요. 기능은 ‘입력 → 처리 → 결과’로 설명하세요 “문의 폼 추가”보다 다음 문장이 구체적입니다. 고객이 회사명·이메일·문의 내용을 입력하면 문의가 저장되고 담당자에게 알림이 갑니다. 고객에게는 접수 완료를 보여줍니다. 담당자는 관리 화면에서 내용을 확인하고 처리 상태를 바꿉니다. 여기에 실패 상황을 덧붙이면 검수 기준이 됩니다. 필수 항목이 비어 있으면 제출되지 않는다. 전송 실패 시 성공 메시지를 보여주지 않는다. 제출 버튼을 연속으로 눌러도 같은 요청이 중복 접수되지 않도록 처리한다. 담당자는 테스트 문의와 실제 문의를 구분해 확인할 수 있다. 개인정보 입력·보관 범위는 운영 목적과 실제 처리 방식에 맞춰 정해야 합니다. 양식에 많은 항목을 넣는 것보다 담당자가 상담을 시작하는 데 필요한 정보를 고르는 것이 먼저입니다. 홈페이지 제작 준비사항도 기획서에서 관리하세요 자료를 보냈는지만 표시하면 최종 버전을 찾기 어렵습니다. 파일과 담당자, 확정 여부를 함께 적으세요. 자료 담당자 현재 상태 전달 기준 로고 브랜드 담당 확정 배경 없는 원본과 사용 색상 페이지별 원고 사업 담당 초안 검토자를 거친 최종 문구 제품·공간 사진 운영 담당 선별 중 파일명과 사용할 위치 가격·운영시간 최종 승인자 확인 필요 실제 고객 안내에 쓸 값 도메인·운영 계정 계정 관리자 접근 확인 필요 초대·권한 인계 방식 협의 비밀번호나 개인 고객 자료를 기획서 본문에 적어 전달할 필요는 없습니다. 계정 초대와 필요한 권한을 별도로 정하고, 제작용 예시는 실제 개인정보를 제거한 자료로 준비하세요. 자주 묻는 질문 홈페이지 기획서는 꼭 PPT로 만들어야 하나요? 아닙니다. 문서·메모·표 중 함께 수정하고 확인하기 쉬운 형식이면 됩니다. 전달 형식보다 필요한 결정이 빠짐없이 적혀 있는지가 중요합니다. 한 장이면 충분한가요? 첫 상담에서는 충분할 수 있습니다. 예약 규칙, 관리자 권한, 데이터 이전처럼 세부 결정이 필요한 항목은 부록을 추가해야 합니다. 한 장에 맞추려고 중요한 조건을 빼지 마세요. 참고 사이트를 그대로 만들어 달라고 해도 되나요? 좋아하는 색상·정보 배치·사용 흐름을 구분해 전달하는 편이 좋습니다. 다른 회사의 원고·사진·디자인을 그대로 사용하기보다 우리 자료와 목적에 맞는 구성을 요청하세요. 기획이 안 돼 있어도 의뢰할 수 있나요? 가능합니다. 대신 기획 정리와 원고 작성까지 의뢰할지 먼저 정해야 합니다. 홈페이지 제작 비용 에서 자료 준비 범위가 견적에 미치는 영향을 확인할 수 있습니다. 양식을 채웠다면 미확정 항목을 숨기지 말고 그대로 표시해 보내주세요. 슬로히어로 홈페이지 제작 상담 에서 필요한 결정부터 함께 정리할 수 있습니다. Sat, 05 Sep 2026 09:00:00 +0900 https://slohero.com/blog/planning-doc-example https://slohero.com/blog/homepage-cost YOUR BUDGET / YEAR ONE 홈페이지 첫해 총예산 계산기 초깃값은 계산을 설명하기 위한 가상 예시입니다. 실제 업체 견적이나 슬로히어로 요금이 아닙니다. 부가세를 포함한 금액으로 바꿔 넣으세요. 견적에 이미 포함된 추가 항목은 0원, 아직 모르는 항목은 빈칸으로 두세요. 제작비 (원) 합의한 화면·기능 자료 준비비 (원) 원고·사진 등 별도 업무 월 운영비 (원) 호스팅·유료 도구 등 연간 도메인비 (원) 첫해 지원이면 0원 연간 수정 건수 (건) 예상 추가 수정 횟수 수정 1건 비용 (원) 견적받은 건별 금액 FIRST YEAR TOTAL / 첫해 합계 2,084,000원 제작·자료 1,700,000원 + 첫해 운영·수정 384,000원 제작비 + 자료 준비비 + 월 운영비 × 12 + 연 도메인비 + 수정 건수 × 건별 비용 실제 견적에 있는 다른 유료 항목도 별도로 확인하세요. 실시간 계산은 자바스크립트가 필요합니다. 아래 계산 예시와 작성 양식을 이용하세요. 홈페이지 제작 비용은 페이지 수에 원고·디자인·기능·운영 범위를 더해야 비교할 수 있습니다. 공개 상품 중에는 템플릿 기반 5페이지를 77만원부터 안내하는 경우도 있지만, 이 가격을 모든 5페이지 홈페이지의 기준으로 삼을 수는 없습니다. 예산을 잡을 때는 처음 만드는 비용과 첫해 운영비를 나누고, 무엇을 포함하는지 함께 적어야 합니다. 이 글은 2026년 9월 23일 확인한 공개 가격과 슬로히어로의 제작 사례를 바탕으로 비용을 읽는 방법을 설명합니다. 비공개 고객 계약 금액이나 확인하지 않은 시장 평균은 제시하지 않습니다. 공개된 홈페이지 제작 가격은 어떻게 읽어야 하나요? 페이지디 공식 제작 비용 안내 는 선택한 레이아웃을 활용하는 상품과 맞춤 제작을 구분합니다. 조회 당시 표시된 시작 가격은 다음과 같습니다. 상품의 공개 조건 시작 가격·부가세 포함 선택 레이아웃 기반, 내용 페이지 또는 게시판 5개 이내 770,000원부터 선택 레이아웃 기반, 내용 페이지 또는 게시판 10개 이내 1,100,000원부터 선택 레이아웃 기반, 내용 페이지 또는 게시판 20개 이내 1,760,000원부터 디자인 시안부터 진행하는 맞춤 제작 별도 견적 같은 안내에는 자료 제공 방식, 추가 기능의 별도 견적, 호스팅·도메인 첫해 지원 조건도 적혀 있습니다. 위 표는 한 업체의 공개 상품 예시 입니다. 시장 전체의 시세표도 아니고, 기능과 자료가 다른 프로젝트의 비교 견적도 아닙니다. 가격에 “부터”가 붙어 있다면 기본 사양과 추가 요인을 같이 확인하세요. 첫해 무료인 운영 항목은 두 번째 해에 얼마가 되는지도 받아 두면 좋습니다. 같은 5페이지의 견적이 달라지는 5가지 1. 원고와 사진을 누가 준비하나요? 고객이 확정한 원고와 사진을 배치하는 작업, 인터뷰를 통해 메시지를 정리하는 작업, 사진을 새로 촬영하거나 보정하는 작업은 범위가 다릅니다. “이미지가 포함된다”는 말도 무료 이미지 검색인지, 유료 이미지 구매인지, 직접 제작인지 구분해야 합니다. 이미 가진 자료를 활용할 수 있으면 비용을 줄일 여지가 있습니다. 2. 기존 디자인을 조정하나요, 새로 설계하나요? 정해진 레이아웃에 브랜드 색상과 자료를 적용하면 처음부터 화면 구조를 정하는 업무를 줄일 수 있습니다. 반면 서비스의 설명 순서, 페이지마다 다른 배치, 독자적인 화면 효과를 요청하면 설계와 확인 과정이 늘어납니다. 맞춤 제작 여부는 도구 이름보다 실제 제공 범위로 확인하세요. 웹빌더를 써도 디자인 작업이 클 수 있고, 코드로 만들어도 기존 구성 요소를 활용할 수 있습니다. 3. 버튼을 연결하나요, 기능을 만드나요? “예약 가능”이라는 설명만으로는 견적을 비교할 수 없습니다. 외부 예약 링크, 희망일 접수, 실시간 가능 날짜, 예약 변경·취소는 서로 다른 작업입니다. 슬로히어로의 리즈 홈페이지 제작 사례 는 날짜와 상품 금액 확인, 예약 관리, 촬영 후 사진 셀렉을 연결했습니다. 화면 수가 같아도 이런 업무 흐름을 포함하면 단순 회사 소개 사이트와 확인 범위가 달라집니다. 실제 제작 화면 · 리즈 온라인 예약 / 사례 전체 보기 ↗ BEYOND THE PAGE COUNT 같은 ‘예약 버튼’도 만드는 범위는 다릅니다. 외부 예약으로 연결 이미 사용하는 서비스의 링크를 안내합니다. 외부 서비스 요금은 따로 확인합니다. 희망 일정 접수 날짜와 정보를 받아 담당자가 확인합니다. 접수 결과와 확정 안내를 구분합니다. 운영 흐름까지 연결 예약 가능한 날짜, 상품, 상태 변경과 관리 화면까지 연결합니다. 예외 상황의 검수도 늘어납니다. 이미지는 기능의 범위를 설명하는 실제 작업 사례입니다. 해당 프로젝트의 계약 금액을 의미하지 않습니다. 4. 기존 자료를 정리하고 옮겨야 하나요? 자료 이전은 복사 횟수만의 문제가 아닙니다. 파일명·제목·이미지·연결 관계를 정리하는 일도 포함될 수 있습니다. 슈갤러리 제작 사례 는 전시·작가·작품 정보를 연결하고 전시장 사진을 작품 이미지로 정리했습니다. 이처럼 자료를 사용 가능한 상태로 만드는 작업은 페이지 디자인과 별도 항목으로 확인해야 합니다. 공개 사례에는 해당 업무의 실제 계약 단가가 없으므로 임의 금액을 붙이지 않습니다. 5. 완성 이후 누가 운영하나요? 관리자에서 직접 바꿀 수 있는 항목, 제작사에 요청할 수정, 외부 서비스 이용료가 초기 견적에 영향을 줍니다. 저렴한 제작비가 장점이 될 수 있지만, 매번 바꿀 내용까지 외부 의뢰가 필요한 구조라면 운영비를 함께 계산해야 합니다. 첫해 예산은 이렇게 계산하세요 첫해 총비용 = 제작비 + 자료 준비비 + 12개월 운영비 + 예상 추가 작업비 아래는 계산 방법을 보여주는 가상 예시입니다. 실제 업체 견적이나 슬로히어로 상품 가격이 아니며, 금액은 모두 부가세 포함이라고 가정합니다. 예산 항목 계산 금액 제작비 5페이지·반응형·문의 양식 등 합의 범위 1,500,000원 원고·사진 정리 별도 맡기는 자료 준비 200,000원 호스팅·도구 이용료 월 20,000원 × 12개월 240,000원 도메인 연간 24,000원 예상 내용 수정 연 4건 × 30,000원 120,000원 첫해 총예산 전체 합계 2,084,000원 제작 계약금만 보고 150만원으로 예산을 잡으면, 이 가정에서는 첫해에 필요한 58만4천원이 빠집니다. 반대로 원고 정리나 수정이 기본 견적에 이미 포함돼 있다면 다시 더하지 않아야 합니다. 비용 항목 옆에 포함·별도·해당 없음·미확정 을 적어 두세요. 아직 묻지 않은 항목을 0원으로 계산하면 예산이 과소 산정됩니다. 제작 예산 작성 양식 내려받기 견적을 줄이고 싶다면 무엇을 바꾸는 게 좋을까요? 방문자가 목표를 달성하는 데 필요하지 않은 범위를 먼저 조정하세요. 첫 오픈에 필요하지 않은 메뉴는 후속 작업으로 분리합니다. 회사 소개·서비스 원고와 사용할 사진을 내부에서 확정합니다. 외부 예약·상담 도구로 해결되는지 검토합니다. 비슷한 상세 페이지는 공통 구조를 사용합니다. 수정 의견을 한 번에 모으고 결정 기준을 정합니다. 다만 문의 수신 확인이나 모바일 검수까지 빼면 적은 비용으로도 운영 가능한 결과를 받는다는 목표에서 멀어질 수 있습니다. 비용을 줄이는 항목과 공개에 필요한 완료 기준은 구분하세요. “SEO 포함”이라는 견적에서는 무엇을 확인하나요? 검색 기본 설정은 작업 항목으로 확인할 수 있어야 합니다. 페이지별 제목과 설명, 검색로봇 접근, 대표 주소, 사이트맵, 관련 페이지 연결 등을 구분해 요청하세요. 반면 “검색에 등록한다”와 “특정 키워드로 상위에 나온다”는 같은 약속이 아닙니다. 네이버도 페이지 주제에 맞는 제목과 콘텐츠 등 콘텐츠 작성 권장 사항 을 안내합니다. 설정 완료 여부와 실제 검색 성과는 별도로 확인해야 합니다. 슬로히어로의 제작 범위는 어떻게 정하나요? 슬로히어로는 목적·참고 사이트·필요한 기능을 확인하고, 결제 전에 메인 화면과 디자인 방향의 1차 초안을 보여주는 방식으로 진행합니다. 이후 작업 범위와 견적을 확정합니다. 도메인 구입비, 유료 폰트·이미지와 외부 서비스 이용료는 별도입니다. 필요한 예약·관리자·게시판의 범위와 수정 조건도 상담에서 확인할 수 있습니다. 현재 안내는 홈페이지 제작 서비스 에서 볼 수 있습니다. 특정 금액만으로 모든 기능이 포함된다고 판단하기보다, 원하는 결과에 필요한 항목이 견적에 들어 있는지 확인해 주세요. 자주 묻는 질문 홈페이지를 무료로 만들 수 있나요? 무료 제작 도구로 시작할 수 있습니다. 다만 직접 작업하는 시간, 독립 도메인, 유료 기능, 공개·운영 조건까지 모두 무료라는 뜻은 아닙니다. AI 홈페이지 제작 가이드 에서 직접 만드는 경우의 확인 항목을 볼 수 있습니다. 페이지가 두 배면 비용도 두 배인가요? 반드시 그렇지는 않습니다. 같은 틀에 자료를 추가하는지, 서로 다른 디자인과 기능을 만드는지에 따라 달라집니다. ‘1페이지’의 길이와 포함 콘텐츠 기준도 확인해야 합니다. 가장 싼 견적을 선택해도 괜찮나요? 필요한 범위와 운영 조건이 같다면 합리적인 선택일 수 있습니다. 다만 빠진 항목을 더한 총비용까지 비교해야 합니다. 홈페이지 제작 견적서 비교법 에 세 견적을 같은 조건으로 맞추는 예시를 담았습니다. 유지비를 따로 계산해야 하나요? 네. 첫해 지원 여부, 다음 갱신 비용, 내용 수정과 관리 범위를 나누세요. 홈페이지 유지보수 비용 에서 수정 빈도에 따른 예산을 계산할 수 있습니다. 필요한 페이지와 기능, 준비된 자료를 알려주시면 비교 가능한 범위부터 정리하겠습니다. 홈페이지 제작 상담하기 Tue, 18 Aug 2026 09:00:00 +0900 https://slohero.com/blog/homepage-cost https://slohero.com/blog/landing-page-cost 랜딩페이지 제작 비용은 화면 한 장의 가격이 아니라 원고·디자인·문의 기능·측정 설정을 어디까지 맡기는지에 따라 달라집니다. 견적을 비교할 때는 섹션 수와 제작 범위를 맞춘 뒤, 처음 만드는 비용과 공개 후 유지비를 나누어 보세요. 광고비와 운영비를 제작비에 섞으면 실제로 무엇을 구매하는지 판단하기 어렵습니다. 이 글에서는 문의를 받는 1페이지 사이트를 기준으로 비용 항목, 계산 예시, 의뢰 문장과 오픈 검수표를 정리합니다. 아래 숫자는 계산 방법을 보여주는 가정 예산 이며, 시장 평균이나 슬로히어로의 판매 가격이 아닙니다. 랜딩페이지 견적에는 무엇이 포함돼야 하나요? 가장 먼저 “한 페이지”의 길이와 역할을 정해야 합니다. 첫 화면과 문의 버튼만 있는 페이지와, 상품 설명·가격·사례·FAQ가 이어지는 페이지는 같은 한 장이어도 작업량이 다릅니다. 비용 항목 견적서에 적을 범위 빠지기 쉬운 조건 기획·원고 누구를 설득하고 무엇을 신청하게 할지 고객 원고 배치인지, 새 원고 작성인지 디자인 섹션 수와 PC·모바일 화면 시안 개수, 사진·아이콘 제작 페이지 구현 버튼·화면 효과·기기 대응 휴대폰에서의 배치와 동작 검수 문의 기능 입력·저장·알림·접수 완료 이메일 수신, 중복 접수, 외부 서비스 비용 측정 설정 방문·문의 완료 확인 버튼 클릭과 실제 문의 완료 구분 수정·검수 의견 취합 횟수와 완료 기준 범위 변경, 오픈 후 수정 조건 공개·운영 도메인 연결·호스팅·계정 인계 갱신비, 서비스 이용 한도, 운영 담당자 외부 예약 서비스에 연결하는 버튼만 필요하다면 자체 예약 기능을 만들 이유가 없습니다. 반대로 방문자가 날짜와 상품을 고르고 담당자가 예약 상태를 관리해야 한다면 일반 문의형 랜딩페이지보다 범위가 커집니다. 같은 조건의 예산은 어떻게 계산하나요? 가정을 먼저 고정하면 금액을 바꿔도 비교 기준이 유지됩니다. 예시 조건: 국문 1페이지·6개 섹션, 고객이 로고와 사진 제공, 원고 정리 포함, PC·모바일 대응, 문의 양식 1개, 문의 완료 측정, 수정 2차례. 회원·결제·자체 예약·광고 집행은 제외합니다. 항목 가정 금액 화면 디자인·페이지 구현 700,000원 원고 정리 200,000원 문의 저장·알림 설정 150,000원 문의 완료 측정 설정 100,000원 최초 제작 합계 1,150,000원 호스팅·빌더 이용료: 월 20,000원 × 12개월 240,000원 도메인: 연 24,000원 24,000원 첫해 총예산 1,414,000원 모든 금액을 부가세 포함이라고 가정한 예입니다. 실제 견적에서는 세금 포함 여부를 먼저 통일하세요. 유료 사진·유료 폰트·폼 서비스·초과 사용료가 따로 있으면 해당 줄을 추가합니다. 여기서 제작비를 줄이려면 어떤 업무를 직접 할지 정해야 합니다. 원고를 직접 확정하면 원고 정리 비용을 줄일 수 있지만, 그만큼 내부 작성 시간이 필요합니다. 문의 기능을 외부 서비스로 바꾸면 초기 작업은 줄어들 수 있어도 이용료와 데이터 관리 조건이 생길 수 있습니다. 랜딩페이지 견적 요청·검수 양식 내려받기 광고용 랜딩페이지와 회사 홈페이지는 어떻게 다른가요? 광고에서 약속한 내용에 바로 답하고 한 가지 주요 행동으로 안내하는 것이 랜딩페이지의 역할입니다. 회사 소개·여러 서비스·채용·자료실을 모두 찾아볼 수 있어야 한다면 별도의 회사 홈페이지가 더 적합할 수 있습니다. 예를 들어 “기업 촬영 견적” 광고에서 들어온 사람에게 필요한 것은 촬영 가능한 대상, 결과물, 의뢰 절차와 견적 요청 방법입니다. 처음부터 모든 사업 부문을 둘러보게 하면 방문자가 다시 필요한 내용을 찾아야 합니다. 다음 6개 섹션이면 의뢰 범위를 설명하기 좋습니다. 대상과 제안: 어떤 고객에게 무엇을 제공하는가 결과물: 무엇을 받을 수 있는가 근거: 실제 사례·작업 화면·확인 가능한 경험 조건: 포함 범위와 준비해야 할 것 절차·질문: 진행 방식과 결정 전에 궁금한 점 문의: 필요한 정보와 문의 후 진행 안내 이 구성 자체가 전환율 상승을 보장하지는 않습니다. 광고의 대상·제안·유입 품질·가격에 따라 결과는 달라집니다. 전환 측정을 넣었다면 어디까지 확인해야 하나요? 문의 버튼 클릭 수와 실제 접수 수를 분리해야 합니다. 버튼을 누르고 입력을 그만두거나 오류가 나도 클릭은 발생할 수 있기 때문입니다. 확인 지점 질문 확인 방법 버튼 클릭 폼이나 상담 경로로 이동했는가 버튼 목적지와 클릭 기록 확인 제출 완료 유효한 문의가 저장됐는가 테스트 식별자를 넣고 관리 화면에서 대조 알림 수신 담당자가 문의를 받았는가 메일·알림에서 같은 테스트 건 확인 분석 기록 성공한 접수를 이벤트로 구분했는가 설정한 이벤트와 실제 접수 건 대조 GA4는 폼 상호작용과 주요 이벤트를 측정하는 방법을 안내합니다. 다만 사이트의 폼 구현 방식에 맞게 동작하는지 확인해야 합니다. 이벤트가 보인다는 이유만으로 이메일 수신이나 저장 성공까지 확인된 것은 아닙니다. Google Analytics 리드 측정 안내 테스트 기기의 이벤트는 GA4 DebugView 에서도 확인할 수 있습니다. 분석 설정을 맡길 때는 “설치 완료” 대신 어떤 행동을 어떻게 확인했는지 결과를 받아 두세요. 실제 제작 사례에서는 문의 경로를 어떻게 정했나요? 슬로히어로의 자연산한의원 홈페이지 사례 는 여섯 진료 안내 페이지에서 카카오톡 상담으로 이동하도록 구성했습니다. 독립된 진료 내용을 읽고 외부 상담 채널로 넘어가는 구조입니다. 이 방식과 사이트 내부에 문의 내역을 저장하는 방식은 필요한 작업이 다릅니다. 상담을 어디서 처리할지부터 정하면 불필요한 기능을 줄일 수 있습니다. 이 사례에서 공개하지 않은 전환율이나 문의 증가율을 제작 효과로 제시하지는 않습니다. 견적 문의를 보낼 때 복사할 문장 국문 랜딩페이지 1개를 제작하려고 합니다. 첫 화면·서비스·사례·포함 범위·FAQ·문의의 6개 섹션입니다. 로고와 사진은 제공하고, 원고 정리는 의뢰하고 싶습니다. PC·모바일 대응, 문의 저장과 이메일 알림, 접수 완료 측정을 포함해 주세요. 수정 횟수, 도메인·운영료, 외부 서비스 이용료, 오픈 후 수정 범위를 구분한 견적과 자료 확정 후 일정을 요청합니다. 회원가입·결제·자체 예약 기능은 이번 범위에서 제외합니다. 실제 요구와 다른 부분만 고쳐 여러 업체에 같은 문장을 보내세요. 비교 방법은 홈페이지 제작 견적서 비교법 에서 이어서 볼 수 있습니다. 자주 묻는 질문 템플릿으로 만들면 비용이 적게 드나요? 기존 디자인을 활용하면 작업을 줄일 수 있습니다. 다만 원고·이미지 제작, 기능 연결, 모바일 검수까지 자동으로 없어지는 것은 아닙니다. 템플릿 활용으로 줄어드는 업무를 확인하세요. 제작비에 광고비도 포함되나요? 계약 범위에 따라 다릅니다. 페이지 제작, 광고 소재, 광고 운영 수수료, 매체 집행비를 별도 항목으로 받으면 비교하기 쉽습니다. 랜딩페이지도 검색에 나오나요? 공개 설정과 문서 구조에 따라 검색 수집 대상이 될 수 있습니다. 광고 유입용으로 공개했다는 것만으로 검색 상위 노출이 따라오지는 않습니다. 특정 질문에 답하는 내용과 검색 수집 설정을 함께 준비해야 합니다. 오픈 후 수정은 모두 무료인가요? 오류 수정, 문구 변경, 새 섹션과 기능 추가는 서로 다른 작업입니다. 각각의 기간·횟수·비용을 확인하세요. 장기 운영 예산은 홈페이지 유지보수 비용 에서 따로 계산할 수 있습니다. 랜딩페이지에 담을 제안과 문의 처리 방식이 정해졌다면, 참고 화면과 함께 전달해 주세요. 슬로히어로 홈페이지 제작 상담 에서 필요한 범위부터 정리할 수 있습니다. Sat, 19 Sep 2026 09:00:00 +0900 https://slohero.com/blog/landing-page-cost https://slohero.com/blog/homepage-quote 홈페이지 제작 견적서는 최초 총액보다 같은 범위로 맞춘 금액과 첫해 운영비를 비교해야 합니다. 반응형·문의 기능·자료 입력·계정 인계가 빠진 견적에 필요한 항목을 더하고, 부가세와 운영비의 기준을 통일하세요. 확인되지 않은 비용은 0원이 아니라 ‘미확정’으로 남겨야 합니다. 이 글에서는 가상 견적 3개를 실제로 채운 비교표로 설명합니다. 아래 A·B·C는 실존 업체가 아니며, 금액은 비교 방법을 보여주기 위해 설정한 예시입니다. 빈 견적 비교표와 질문 목록 내려받기 1. 견적서보다 먼저 ‘같이 만들 것’을 정하세요 세 업체에 서로 다른 설명을 보내면 금액을 비교해도 의미가 약합니다. 먼저 다음 요구사항을 한 장으로 고정합니다. 이번 비교의 공통 조건 국문 5페이지: 메인·회사·서비스·사례·문의 로고·최종 원고·사진은 고객이 제공 PC·모바일 화면과 문의 저장·알림 포함 운영에 필요한 관리자 권한과 사용 안내 포함 도메인 연결, 페이지 제목·설명과 사이트맵 설정 포함 회원가입·결제·실시간 예약·데이터 이전은 제외 수정은 취합한 의견 2차례, 새 기능 추가는 별도 협의 이 조건은 소개형 사이트의 비교 예시입니다. 실제로 필요한 기능이 다르다면 홈페이지 기획서 예시 에서 범위를 먼저 정리하세요. 2. 부가세와 ‘포함’의 뜻을 맞추세요 같은 100만원이라도 세금 포함 여부가 다르면 결제 금액이 달라집니다. 견적 상단에 공급가액·세액·최종 결제액을 구분해 달라고 요청하세요. 또한 “문의 기능 포함”은 폼 화면만 있다는 의미인지, 저장·메일 알림·실제 수신 검수까지 포함하는지 확인해야 합니다. 금액을 비교하기 전에 같은 단어가 같은 결과를 뜻하는지 맞추는 과정이 필요합니다. 공개된 업체 가격도 이런 조건과 함께 읽어야 합니다. 예를 들어 페이지디 제작 비용 안내 는 선택 레이아웃, 자료 제공, 별도 기능의 조건을 구분합니다. 해당 업체의 시작 가격을 다른 범위의 맞춤 견적과 바로 비교하면 안 됩니다. 3. 필요한 항목을 더해 같은 범위로 맞추세요 아래는 모든 금액이 부가세 포함이며, 추가 단가까지 회신받았다고 가정한 표입니다. ‘포함’이라고 적힌 금액은 다시 더하지 않습니다. 비교 항목 가상 A 가상 B 가상 C 최초 제시 제작비 800,000원 1,200,000원 1,500,000원 모바일 대응 추가 200,000원 포함 포함 문의 저장·알림 추가 150,000원 포함 포함 운영 계정·사용 안내 추가 100,000원 100,000원 포함 동일 범위 제작비 1,250,000원 1,300,000원 1,500,000원 처음에는 A와 C의 차이가 70만원이지만 필요한 항목을 맞추면 25만원으로 줄어듭니다. 이 단계만으로 A가 나쁜 견적이라는 뜻은 아닙니다. 기본 범위를 작게 구성해 고객이 선택하도록 하는 상품일 수도 있습니다. 중요한 것은 추가 항목을 넣은 최종 범위를 확인하고 계약하는 것입니다. 별도라고만 적혀 있고 단가가 없다면 아직 비교가 끝난 상태가 아닙니다. 4. 첫해 운영비까지 더하면 순서가 바뀔 수 있습니다 이번에는 각 견적의 운영료가 아래와 같다고 가정하겠습니다. 비교한 운영료는 호스팅·도구 이용료이며, 내용 수정과 장애 관리 등 추가 업무는 동일하게 포함하지 않았다고 가정합니다. 비교 항목 가상 A 가상 B 가상 C 동일 범위 제작비 1,250,000원 1,300,000원 1,500,000원 월 운영료 50,000원 20,000원 10,000원 12개월 운영료 600,000원 240,000원 120,000원 연 도메인 비용 24,000원 24,000원 24,000원 첫해 총비용 1,874,000원 1,564,000원 1,644,000원 이 가정에서는 최초 제작비가 가장 낮은 A보다 B의 첫해 총비용이 31만원 적습니다. 현실에서는 운영료에 포함된 서비스가 다를 수 있습니다. A가 장애 점검이나 콘텐츠 수정까지 포함한다면 위처럼 단순 비교하면 안 됩니다. 필요한 운영 업무를 동일하게 맞추거나, 가격 차이가 어떤 추가 서비스에 대한 것인지 따로 적어야 합니다. ‘첫해 무료’ 항목이 있다면 첫해와 갱신 이후 금액도 나누세요. 계약 유지 기간과 해지 시 인계 조건이 다르면 그 차이 역시 선택에 영향을 줍니다. 5. 숫자로 비교하기 어려운 5개 항목도 확인하세요 확인 항목 답변을 받을 질문 남겨둘 기록 담당자 질문·수정·오픈을 누가 책임지나요? 실제 담당자와 연락 경로 완료 기준 화면 외에 어떤 기능을 테스트하나요? 테스트 항목과 결과 자료와 계정 어떤 계정·파일·데이터를 넘겨받나요? 인계 대상 목록 수정 범위 문구 변경과 새 기능 추가를 어떻게 구분하나요? 포함·제외 기준 오픈 후 대응 오류와 추가 요청은 어떤 절차로 처리하나요? 접수·회신·작업 기준 ‘소스코드 제공’이라는 한 줄도 사용하는 플랫폼에 따라 의미가 달라집니다. 외부 서버에서 같은 기능으로 운영할 수 있는지, 내보낸 파일에 데이터와 문의 기능까지 따라오는지 확인해야 합니다. 예를 들어 Webflow는 일반 코드 내보내기에 CMS 기능과 폼 처리 등이 포함되지 않는다고 안내합니다. 이는 단순히 ZIP 파일을 받는 것과 같은 운영 환경을 인계받는 것이 다를 수 있음을 보여줍니다. Webflow 코드 내보내기 공식 안내 6. 모호한 답변은 이렇게 다시 물어보세요 받은 답변 이어서 보낼 질문 “반응형 포함입니다.” 휴대폰에서 메뉴·문의·표까지 어떤 화면을 확인하나요? “기본 SEO를 해드립니다.” 페이지 제목·설명·대표 주소·사이트맵 중 어떤 항목을 설정하나요? “수정 가능합니다.” 몇 차례이며, 한 차례의 범위와 전달 기한은 어떻게 되나요? “관리자 제공입니다.” 내가 직접 바꿀 수 있는 항목을 목록으로 받을 수 있나요? “유지보수는 별도입니다.” 건별·월 정액 중 가능한 방식과 포함 업무를 알려주세요. “자료는 이전해 드립니다.” 어떤 자료를 몇 건까지, 누가 정리하고 어떤 기준으로 확인하나요? 내용이 비어 있다는 사실만으로 업체를 단정할 필요는 없습니다. 빠진 조건을 질문했을 때 구체적으로 정리해 주는지가 더 유용한 판단 근거입니다. 7. 비교표를 보내 최종 확인을 받으세요 전달드린 공통 요구사항을 기준으로 포함·별도·제외 항목을 표시해 주세요. 별도 항목은 단가 또는 산정 기준을 부탁드립니다. 최초 제작비와 12개월 운영비, 이후 갱신비를 구분하고, 수정 범위·운영 계정 인계·오픈 검수 항목도 확인하고 싶습니다. 답변을 받으면 최초 견적과 추가 확인 내용을 하나의 최종 범위로 정리하세요. 메신저 여러 곳에 흩어진 설명보다 어떤 문서가 최종 합의인지 분명한 편이 작업 중 혼선을 줄입니다. 자주 묻는 질문 견적서는 몇 군데 받는 것이 좋나요? 후보의 작업 범위와 결과를 실제로 비교할 수 있을 만큼 받으면 됩니다. 여러 개를 받는 것보다 같은 요구사항을 보내고 빠진 조건에 답을 받는 과정이 중요합니다. 시간당 단가가 적힌 견적이 더 좋은가요? 투입 시간을 이해하는 데 도움이 될 수 있지만, 시간만으로 결과를 판단하기는 어렵습니다. 페이지·기능·수정·납품 범위와 완료 기준도 함께 확인하세요. 가장 비싼 견적이 안전한가요? 가격만으로 알 수 없습니다. 비슷한 프로젝트의 공개 결과, 실제 담당 체계, 범위와 검수 기준을 확인해야 합니다. 기존 홈페이지를 바꾸는 견적도 같은 방식인가요? 기본 비교는 같지만 자료 이전과 기존 주소 처리, 계정 인계가 추가됩니다. 홈페이지 리뉴얼 업체 선정 기준 을 함께 확인하세요. 받은 견적에서 빠진 항목이 있다면 먼저 질문 목록부터 채워 보세요. 슬로히어로 홈페이지 제작 상담 에서는 필요한 페이지와 기능을 기준으로 제작 범위를 정리합니다. Sat, 19 Sep 2026 09:00:00 +0900 https://slohero.com/blog/homepage-quote https://slohero.com/blog/homepage-maintenance-cost 홈페이지 유지보수 비용은 사이트를 계속 열어두는 비용과 내용을 바꾸는 비용을 나눠야 정확해집니다. 수정이 드물면 건별 의뢰가 유리할 수 있고, 일정한 수정이 반복되면 월 정액이 유리할 수 있습니다. 다만 장애 대응·백업·복구까지 포함된 계약은 단순 문구 수정 요금과 따로 비교해야 합니다. 이 글은 공개된 건별 요금과 명시적인 계산 가정으로 운영 빈도에 따른 차이를 보여줍니다. “월 얼마가 적정하다”는 하나의 숫자보다, 우리 사이트에서 실제로 맡길 일을 기준으로 판단하는 방법입니다. 유지보수 비용에는 어떤 일이 들어가나요? 구분 대표 항목 비교할 기준 고정 운영비 도메인·호스팅·빌더·유료 서비스 갱신 주기, 용량·트래픽, 사용 한도 콘텐츠 수정 문구·사진·배너·가격표 변경 건수·페이지 수·이미지 제작 포함 여부 운영 관리 업데이트·점검·백업·장애 대응 실행 주기, 응답 시간, 복구 범위 추가 개발 예약·회원·결제·관리자 기능 변경 별도 요구사항·작업 범위·검수 도메인과 호스팅 비용을 냈다고 사진 교체까지 포함되는 것은 아닙니다. 반대로 운영자가 직접 내용을 바꾼다고 서버 장애나 계정 복구까지 스스로 해결할 수 있는 것도 아닙니다. 업체에 “유지보수 포함인가요?”라고 묻기보다 “매달 가격 문구 한 번, 배너 한 번을 바꾸고 장애가 나면 연락받고 싶습니다” 라고 업무를 적는 편이 정확합니다. 공개된 건별 요금은 어느 정도인가요? 2026년 9월 19일 확인한 페이지디 공식 유지보수 요금표 에는 다음 금액이 안내돼 있습니다. 해당 업체의 작업 항목 공개 금액 서브페이지 텍스트 수정·추가 페이지당 33,000원 서브페이지 이미지 수정·추가 페이지당 55,000원 기본 호스팅 연 79,000원 안내된 영문 도메인 연 24,000원 이 표는 해당 업체가 제작한 홈페이지에 적용하는 부가세 포함 요금 입니다. 모든 사이트에 적용되는 시장 평균이나 다른 업체의 제공 가격이 아닙니다. 수정 범위·대상 사이트·선입금과 처리 일정도 원문에서 함께 확인해야 합니다. 이렇게 공개 가격을 볼 때는 금액만 복사하지 말고 단위를 봐야 합니다. “텍스트 한 곳”과 “페이지 한 장”, “배너 이미지 교체”와 “배너 디자인 제작”은 다른 항목일 수 있습니다. 수정 빈도에 따라 1년 비용은 얼마나 달라지나요? 계산을 위해 위 가격표의 텍스트 수정 33,000원, 호스팅 79,000원, 도메인 24,000원을 사용하겠습니다. 월 정액은 비교 방법을 보여주기 위해 월 55,000원, 매월 텍스트 수정 2건 포함 이라고 가정합니다. 이 월 정액 상품은 실제 업체 상품이 아닙니다. 두 방식은 같은 텍스트 수정 작업을 제공하고, 공통 고정비는 연 103,000원이라고 가정합니다. 정액의 미사용 건수는 다음 달로 이월되지 않으며, 초과 수정은 건당 33,000원으로 계산합니다. 모든 금액은 부가세 포함 기준입니다. 수정 패턴 건별 의뢰 연간 합계 가정한 월 정액 연간 합계 1년 내내 수정 없음 103,000원 763,000원 두 달마다 1건: 연 6건 301,000원 763,000원 매월 1건: 연 12건 499,000원 763,000원 매월 2건: 연 24건 895,000원 763,000원 매월 3건: 연 36건 1,291,000원 1,159,000원 계산식은 단순합니다. 건별 방식: 연 고정비 + 건당 수정비 × 연간 수정 건수 월 정액: 연 고정비 + 월 요금 × 12 + 월별 포함 건수를 넘은 작업비 이 가정에서는 매월 2건씩 수정할 때 정액이 연 132,000원 적습니다. 반면 매월 1건만 수정하면 건별 의뢰가 연 264,000원 적습니다. 단, 연간 24건이 전부 한 달에 몰리는 경우는 매월 2건씩 요청하는 경우와 다릅니다. 같은 가정에서 한 달에 24건을 처리하면 정액 포함 2건을 넘는 22건이 추가돼 연간 총액은 1,489,000원 입니다. 월별 소진 조건을 확인하지 않으면 “연 24건 포함”으로 잘못 계산하기 쉽습니다. 유지보수 비용 계산·요청 양식 내려받기 가격이 조금 높아도 운영 관리가 필요한 경우 앞의 계산은 텍스트 수정만 같다고 가정한 비교입니다. 다음 업무가 필요하다면 수정 건수 외에 대응 체계를 확인해야 합니다. 사이트가 멈췄을 때 누가 먼저 확인하고 알려주는가 백업은 무엇을 얼마나 자주 보관하는가 복구 요청 시 누가 언제부터 작업하는가 문의 알림이 오지 않을 때 어느 범위까지 점검하는가 외부 서비스나 유료 기능의 만료를 누가 확인하는가 “24시간 대응”이라는 문구도 접수 가능 시간인지, 담당자가 확인하는 시간인지, 복구 완료를 약속하는 시간인지 구분하세요. 최초 회신과 해결 완료는 같은 기준이 아닙니다. 관리자가 직접 가격을 바꿀 수 있어도 예약 규칙이나 시스템 문제까지 고칠 수 있다는 뜻은 아닙니다. 리즈 홈페이지 사례 처럼 운영자가 상품과 예약 상태를 관리하도록 구성하면 반복 입력은 줄일 수 있지만, 기능 변경과 장애 점검의 담당자는 별도로 정해야 합니다. 유지보수 계약 전에 받을 답 6가지 포함 업무: 텍스트·이미지·배너 제작·페이지 추가 중 어디까지인가 한 건의 단위: 요청 한 번인가, 페이지 하나인가, 작업 시간인가 초과 조건: 초과 단가와 미사용분 이월 여부는 무엇인가 응답·작업 시간: 접수, 최초 회신, 작업 시작을 각각 언제 하는가 관리 범위: 업데이트·백업·복구·외부 연동은 누가 맡는가 해지·인계: 계정·자료·백업을 어떤 형태로 받을 수 있는가 초기 제작 오류를 고치는 하자 수정과 고객이 새로 요청하는 내용 변경도 나누어야 합니다. “무상 수정”이라는 표현만으로 둘 다 포함된다고 판단하지 마세요. 수정 요청을 한 번에 전달하는 방법 수정할 주소: 현재 내용과 바꿀 내용: 적용할 이미지·파일: PC·모바일 모두 적용 여부: 희망 완료일과 사유: 완료 확인 담당자: 기존 문구와 바꿀 문구를 함께 적고, 사진은 실제 사용할 파일로 전달하면 재확인이 줄어듭니다. “요즘 느낌으로 전체 수정”처럼 범위가 큰 요청은 단순 유지보수 대신 별도 개선 작업으로 견적을 받는 편이 낫습니다. 자주 묻는 질문 홈페이지 유지보수 계약은 꼭 해야 하나요? 운영 방식에 따라 다릅니다. 수정이 드물고 내부에서 계정·갱신·문제 대응을 관리할 수 있다면 필요할 때 의뢰할 수 있습니다. 반대로 운영 책임자가 없거나 중단 대응이 중요하면 관리 계약의 범위를 검토하세요. 유지보수비 0원이면 운영비도 없나요? 그렇지는 않습니다. 외주 수정료를 받지 않더라도 도메인·호스팅·플랫폼·외부 서비스 비용은 남을 수 있습니다. 무료의 적용 대상을 확인해야 합니다. 다른 업체가 만든 홈페이지도 수정할 수 있나요? 기술 구조, 계정 접근, 코드와 데이터의 상태, 기존 계약 조건을 먼저 확인해야 합니다. 같은 문구 수정이라도 수정 가능한 환경을 넘겨받지 못하면 진단과 인계 작업이 추가될 수 있습니다. 처음 제작할 때부터 운영자가 직접 바꿀 내용과 외부에 맡길 내용을 구분하면 이후 비용을 예측하기 쉽습니다. 초기 예산까지 함께 계산하려면 홈페이지 제작 비용 을, 업체 변경이 필요하다면 리뉴얼 업체 선정 기준 을 확인하세요. Sat, 19 Sep 2026 09:00:00 +0900 https://slohero.com/blog/homepage-maintenance-cost https://slohero.com/blog/ai-homepage-production AI 홈페이지 제작 도구로 회사 소개와 문의 페이지의 초안을 만들 수 있지만, 무료 생성과 실제 사업용 운영의 조건은 다릅니다. 독립 도메인, 문의 저장, 사용량, 관리자 권한과 다른 환경으로 옮기는 방법까지 확인해야 합니다. 첫 화면이 만들어졌다면 다음 단계는 추가 생성보다 실제 고객이 사용할 수 있는지 검수하는 일입니다. 이 글은 2026년 9월 19일 확인한 공식 자료를 바탕으로 작성한 선택·검수 가이드 입니다. 세 도구를 동일 조건에서 직접 사용한 성능 순위나 제작 속도 실험 결과는 아닙니다. AI로 직접 만들기 좋은 경우는 무엇인가요? 회사·서비스 소개, 포트폴리오, 간단한 문의 접수처럼 목적과 범위가 분명하고 운영자가 내용을 직접 확인할 수 있다면 검토할 수 있습니다. 반면 다음 항목이 핵심이라면 화면 생성과 함께 기능 설계·검증을 도와줄 담당자가 필요한지 살펴보세요. 여러 상품·인원·담당자의 일정이 연결되는 예약 결제·취소·환불과 주문 상태의 처리 회원별로 다른 정보를 보여주는 권한 기존 고객·상품·문의 데이터의 이전 내부 업무 시스템과의 연결 도구에 ‘예약’ 또는 ‘회원’ 기능이 있다는 것과 우리 업무의 모든 규칙을 처리할 수 있다는 것은 다릅니다. 먼저 필요한 행동과 예외를 적고 지원 범위를 확인해야 합니다. AI 홈페이지 제작 도구 3개는 무엇을 비교해야 하나요? 소개형 사이트를 만든다는 공통 목적 아래, 공식 문서로 확인되는 생성·운영 방식과 이전 조건을 비교했습니다. 사용성 점수나 결과물 품질을 임의로 매기지 않았습니다. 도구 공식 안내에서 확인한 방향 선택 전에 확인할 조건 Readdy 설명을 통한 생성·수정, 자체 백엔드와 공개·도메인 연결 요금제별 사이트·문의·크레딧 한도, 코드와 데이터의 인계 범위 Wix AI Website Builder AI 생성과 수동 편집, Wix의 운영·사업 도구 연결 필요한 유료 기능, 플랫폼에서 계속 운영할 계획인지 Webflow AI 사이트·디자인·문구 생성과 CMS 작업 지원 공개용 Site 요금제와 작업용 Workspace 구분, 내보내기 제약 근거: Readdy 도움말 , Wix AI 공식 소개 , Webflow AI 공식 소개 선택 기준은 “어느 도구가 무조건 1등인가”보다 내가 바꿔야 할 내용과 처리해야 할 문의를 스스로 관리할 수 있는가 입니다. 필요한 페이지 한 개를 먼저 만들어 같은 문구 수정과 모바일 확인을 해보면 판단에 도움이 됩니다. ‘무료’에서 ‘유료’로 넘어가는 항목은 따로 보세요 다음 질문에 답을 적어야 실제 운영 비용이 보입니다. 내가 가진 도메인으로 공개할 수 있는가 몇 개의 사이트를 공개할 수 있는가 문의·파일·방문량 등에 사용 한도가 있는가 AI 수정에 필요한 크레딧이 충분한가 외부 폼·메일·예약 서비스를 별도로 결제해야 하는가 다음 갱신 때 같은 조건이 유지되는가 예를 들어 조회 당시 Readdy 요금표 의 1년 결제 화면은 Starter를 월 환산 15달러로 표시했습니다. 단순 연 환산은 180달러이며, 세금·환율·추가 이용료는 별도로 확인해야 합니다. 월 환산 표시와 매달 결제하는 금액을 혼동하지 않는 것 이 중요합니다. Wix도 무료로 제작을 시작할 수 있지만 독립 도메인 연결 등에는 유료 요금제가 필요하다고 안내합니다. Webflow는 사이트 공개와 작업 공간의 요금제가 나뉘므로 어떤 기능을 위해 결제하는지 확인해야 합니다. Wix 무료·유료 조건 , Webflow Site·Workspace 구분 코드 파일을 받으면 어디든 그대로 옮길 수 있나요? 반드시 그렇지는 않습니다. 화면 파일, 콘텐츠 데이터, 로그인·문의 처리와 외부 서비스는 따로 움직일 수 있습니다. Wix: 일반 Wix 사이트는 Wix 서버에서 운영하는 구조이며 외부 호스팅을 지원하지 않는다고 안내합니다. 공식 안내 Webflow: 일반 코드 내보내기에는 CMS 기능과 폼 처리 등이 포함되지 않습니다. 정적 화면을 옮기는 것과 같은 기능을 다시 운영하는 것을 구분해야 합니다. 공식 코드 내보내기 안내 Readdy: 공식 요금표에 코드 내보내기가 제시돼 있습니다. 구매 전에 해당 요금제와 프로젝트의 지원 여부, 데이터·서버 기능의 이전 방법을 따로 확인하세요. 공식 요금표 “내 사이트를 소유한다”는 설명을 봤다면 구체적으로 어떤 계정·파일·데이터를 받을 수 있는지 질문하세요. 다른 사람에게 운영을 맡길 계획이라면 이 부분이 도구 선택 기준이 됩니다. 처음 입력할 프롬프트는 이렇게 작성하세요 “세련된 홈페이지를 만들어줘”보다 방문자와 범위, 하지 않을 일, 검수 기준을 적는 편이 요구사항을 전달하기 쉽습니다. 기업 촬영 서비스를 소개하고 견적 문의를 받는 국문 홈페이지를 만들어 주세요. 방문자는 회사 행사와 프로필 촬영을 준비하는 담당자입니다. 메인·서비스·사례·진행 절차·문의의 5개 페이지로 구성해 주세요. 모바일에서 서비스 범위와 문의 버튼을 쉽게 찾도록 해주세요. 실제로 제공하지 않은 고객명·후기·성과 수치·인증을 만들지 마세요. 사진과 원고는 제가 제공할 자료를 기준으로 사용하고, 없는 자료는 임시 영역이라고 표시해 주세요. 문의는 회사명·회신 연락처·촬영 목적·희망일을 받습니다. 저장과 알림 연결이 끝나지 않았다면 작동 완료라고 표시하지 말고 필요한 설정을 알려주세요. 회원가입과 결제는 이번 범위에서 제외합니다. 생성된 결과에 적힌 기능 설명도 그대로 믿지 말고 테스트하세요. 화면에 성공 메시지가 뜨는 것만으로 데이터가 저장됐다고 볼 수는 없습니다. 공개 전에 직접 해볼 8가지 테스트 테스트는 본인이 관리하는 제작·검수용 사이트에서 진행하세요. 실제 고객의 개인정보 대신 테스트용 값을 사용합니다. 시험 하는 방법 통과 기준 내용의 사실성 주소·가격·경력·후기·사진을 원자료와 대조 만들어낸 정보가 없음 모바일 사용 휴대폰에서 처음부터 문의까지 이동 가려진 내용·못 누르는 버튼이 없음 정상 문의 식별 가능한 테스트 문구로 한 건 접수 저장된 내용과 담당자 수신 확인 잘못된 입력 필수 정보를 비우거나 잘못 입력 수정할 위치를 알려주고 성공 처리하지 않음 연속 제출 같은 요청을 빠르게 반복 제출 중복 처리 기준대로 동작 운영자 수정 가격 한 줄과 이미지 하나를 바꾸고 공개 실제 주소에 변경이 반영됨 접근 권한 로그아웃·다른 테스트 계정으로 보호 화면 확인 공개하면 안 되는 내용에 접근할 수 없음 검색 기본 정보 각 페이지 제목·설명·수집 설정 확인 페이지별 내용과 맞고 의도치 않은 차단이 없음 AI 홈페이지 제작 프롬프트·검수 기록지 내려받기 각 항목은 통과·실패·해당 없음으로 기록하고 실패한 이유를 남기세요. 기능이 없는 사이트에서 ‘해당 없음’을 적는 것과, 시험하지 않고 ‘통과’로 적는 것은 다릅니다. AI로 만들면 검색에도 잘 나오나요? AI를 사용했다는 사실만으로 상위 노출이 정해지는 것은 아닙니다. 페이지가 어떤 질문에 답하는지, 내용과 제목이 맞는지, 검색로봇이 접근할 수 있는지 확인해야 합니다. 네이버는 콘텐츠 작성 권장 사항 에서 제목과 설명 등 기본 기준을 안내합니다. 도구가 SEO 점수를 보여주더라도 실제 네이버 노출·클릭과는 구분해야 합니다. 공개 후에는 URL 검사 와 검색 성과를 따로 확인하세요. 슬로히어로의 자연산한의원 제작 사례 에서도 AI 모델 이미지 활용과 검색 기본 설정은 서로 다른 작업으로 소개합니다. AI 이미지를 사용했다는 사실이 검색 성과를 입증하는 것은 아닙니다. 자주 묻는 질문 AI로 만들면 제작비가 0원인가요? 도구 체험은 무료일 수 있습니다. 실제 운영에는 유료 공개 기능·도메인·외부 서비스와 본인의 작업 시간이 들 수 있습니다. 홈페이지 제작 비용 의 첫해 예산 방식으로 계산하세요. 코딩을 몰라도 사용할 수 있나요? 시각 편집과 생성 기능으로 시작할 수 있습니다. 다만 원하는 기능이 제대로 작동하는지 확인하고 문제를 해결할 담당자는 필요합니다. 어려운 기능은 지원 범위 안에서 줄이거나 별도 검토를 받는 방법이 있습니다. AI 초안을 만든 뒤 제작사에 맡겨도 되나요? 가능하지만 현재 도구와 요금제, 계정·파일·데이터 인계 가능 범위를 먼저 확인해야 합니다. 제작사가 기존 결과를 이어서 수정할 수 있는지, 새로 구현해야 하는지에 따라 비용이 달라집니다. 만든 화면이 있다면 주소와 해결되지 않은 기능을 함께 보내주세요. 슬로히어로 홈페이지 제작 상담 에서 유지할 부분과 추가 작업이 필요한 부분을 나누어 확인할 수 있습니다. Sat, 19 Sep 2026 09:00:00 +0900 https://slohero.com/blog/ai-homepage-production https://slohero.com/blog/homepage-production-period 홈페이지 제작 기간은 페이지 수보다 자료 준비 상태와 기능 범위에 따라 달라집니다. 소개와 문의 중심이라면 몇 주 단위로 계획할 수 있지만, 예약·결제·관리자·자료 이전이 붙으면 설계와 검수 기간을 따로 잡아야 합니다. 계약할 때는 “4주”라는 답보다 언제 시작해서 무엇을 확인한 뒤 오픈하는지 적힌 일정표 를 받는 것이 중요합니다. 아래 기간은 납기를 보장하는 시장 평균이 아니라, 작업 범위를 나누기 위한 계획 예시입니다. 실제 일정은 자료와 기능을 확인한 뒤 정해야 합니다. 제작 범위 처음 검토할 계획 범위 먼저 확인할 조건 원페이지·단순 랜딩페이지 2~4주 원고·이미지 준비, 문의 방식, 디자인 변경 범위 회사 소개·서비스·사례·문의 등 5~10페이지 3~6주 메뉴 확정, 페이지별 원고, 의사결정 기한 예약·회원·운영자 관리가 연결된 사이트 4~8주 이상 처리 규칙, 예외 상황, 데이터와 권한 테스트 결제·다국어·대량 자료 이전이 포함된 사이트 별도 산정 외부 심사·연동, 번역, 이관량, 오픈 전 검증 같은 5페이지여도 준비된 원고를 배치하는 작업과 예약 업무를 설계하는 작업은 일정이 다릅니다. 반대로 같은 틀을 반복하고 자료가 정리돼 있으면 페이지가 많아도 제작 부담이 줄어들 수 있습니다. 제작 기간은 계약일부터 계산하나요? 계약일, 자료 확정일, 실제 착수일을 구분해야 합니다. 계약과 입금이 끝나도 다음 작업에 필요한 자료가 없거나 제작사의 배정 일정이 남아 있으면 화면 제작이 바로 시작되지 않을 수 있습니다. 일정표에 다음 네 날짜를 적어 두세요. 범위 확정일: 페이지와 기능을 어디까지 만들지 결정한 날 자료 확정일: 이번 제작에 쓸 원고·사진이 준비된 날 실제 착수일: 제작 담당자가 작업을 시작하는 날 오픈 목표일: 공개 전 검수까지 마쳐야 하는 날 예상 오픈일은 이 중 실제 착수일을 기준으로 계산합니다. 자료 확정 전에 일부 디자인을 시작할 수는 있지만, 임시 문구와 이미지로 승인한 화면은 최종 자료가 들어온 뒤 다시 확인해야 합니다. 4주 일정표에는 고객의 확인 시간도 들어가야 합니다 다음은 회사 소개·서비스·사례·문의로 구성된 홈페이지의 20영업일 예시 입니다. 실제 고객 프로젝트의 소요일을 옮긴 표가 아닙니다. 주말·공휴일·외부 서비스 대기와 별도 자료 준비 기간은 제외했습니다. 단계 영업일 예시 제작사 작업 발주자가 끝내야 할 일 구조 확정 1~2일차 메뉴·페이지·기능 목록 정리 누락 범위와 담당자 확인 첫 화면 시안 3~5일차 메시지와 디자인 방향 제시 참고 화면과 다른 지점 검토 시안 승인 6일차 질문 답변·수정 방향 정리 의견을 모아 최종 승인 전체 페이지 제작 7~11일차 콘텐츠·반응형 화면·문의 기능 적용 연락처·사진·원고 사실 확인 1차 검수 12~13일차 테스트 주소와 검수표 전달 PC·휴대폰에서 수정사항 취합 수정·기능 검증 14~17일차 수정 반영·문의 수신 등 검증 수정 결과 승인 공개 준비 18~19일차 도메인·검색 설정·계정 인계 운영 계정과 실제 수신 확인 최종 확인·오픈 20일차 실제 주소에서 최종 점검 공개 승인 이 일정에서 6일차의 승인이 3영업일 늦어지고 후속 작업을 병행할 수 없다면, 오픈 목표는 23영업일차로 이동합니다. 반면 지연된 자료가 아직 착수하지 않은 하위 페이지에만 쓰인다면 전체 일정이 똑같이 밀리는 것은 아닙니다. 그래서 지연 시에는 일수를 기계적으로 더하기보다 어느 다음 작업이 멈췄는지 확인해야 합니다. 제작사는 영향받는 작업과 변경 오픈일을 설명하고, 발주자는 자료·결정 마감일을 다시 정하면 됩니다. 제작 일정·검수 양식 내려받기 페이지 수보다 기능이 기간을 바꾸는 이유 “예약 페이지 한 장”에도 서로 다른 일이 들어갈 수 있습니다. 외부 예약 서비스로 이동하는 버튼 희망 날짜를 받는 문의 양식 가능한 날짜만 보여주는 예약 달력 상품·작가·시간·결제·취소 상태가 함께 움직이는 예약 시스템 이 네 가지를 같은 일정으로 비교하면 요구사항이 빠집니다. 버튼 연결과 업무 규칙을 갖춘 시스템은 확인해야 할 항목이 다르기 때문입니다. 슬로히어로의 리즈 제작 사례 에는 예약 가능 여부, 상품 금액 계산, 운영자 관리와 촬영 후 사진 셀렉이 연결돼 있습니다. 이처럼 여러 단계가 이어지는 기능은 화면뿐 아니라 입력한 정보가 다음 단계에 정확하게 전달되는지 까지 확인해야 합니다. 이 사례의 공개 자료에 없는 실제 제작 기간을 추정해 제시하지는 않습니다. 일정이 밀릴 때 무엇부터 확인해야 하나요? 원인과 해결 담당자를 나누면 막연한 독촉을 줄일 수 있습니다. 멈춘 지점 확인할 내용 다음 행동 디자인을 시작하지 못함 메시지·필수 메뉴·참고 방향이 정해졌는가 한 장 기획서와 첫 화면 문구 확정 시안 수정이 반복됨 승인자가 여러 명이고 기준이 다른가 최종 승인자와 수정 취합 담당자 지정 제작이 중간에 멈춤 제작사 인력 배정 또는 구현 문제가 있는가 남은 작업·담당자·수정 일정을 서면 확인 기능이 계속 늘어남 처음 합의한 범위와 다른 요청인가 추가 범위·비용·일정 승인 후 반영 검수가 끝나지 않음 수정 요청이 여러 채널로 들어오는가 하나의 검수표에서 요청과 완료를 관리 “마음에 들지 않는다”는 의견도 필요하지만, 실행하려면 위치와 이유가 있어야 합니다. “메인 첫 문단을 두 줄로 줄이고, 모바일 문의 버튼이 가격 안내 바로 아래에 보이게 해주세요”처럼 전달하면 수정 완료 여부를 함께 판단할 수 있습니다. 2주 안에 오픈해야 한다면 무엇을 줄여야 하나요? 우선 오픈과 후속 작업을 나누세요. 첫 공개에 필요한 회사·서비스 정보와 문의 경로를 먼저 확정하고, 준비되지 않은 상세 사례나 복잡한 기능은 별도 일정으로 분리할 수 있습니다. 다만 문의가 실제로 도착하는지, 모바일에서 사용할 수 있는지, 운영 계정을 누가 갖는지 확인하는 과정은 남겨야 합니다. 디자인 수정을 줄이는 것과 검수를 생략하는 것은 결과가 다릅니다. 지금 당장 제공할 수 있는 자료와 꼭 필요한 기능을 홈페이지 기획서 예시 에 적어 보내면 제작사가 우선 오픈 가능한 범위를 판단하기 쉽습니다. 언제 제작 완료로 볼 수 있나요? 화면이 보이는 것과 운영할 수 있는 상태를 구분해야 합니다. 공개 승인은 다음 항목을 확인한 뒤 내리는 편이 좋습니다. 실제 도메인과 HTTPS 접속이 정상이다. PC와 휴대폰에서 주요 메뉴·버튼·본문을 사용할 수 있다. 테스트 문의가 지정된 메일이나 관리 화면에 도착한다. 전화·지도·상담·외부 예약 링크가 맞다. 운영자에게 필요한 계정과 사용 방법이 전달됐다. 페이지 제목·설명·검색 수집 설정을 확인했다. 미완료 작업과 오픈 후 수정 범위가 기록돼 있다. 홈페이지 오픈일과 네이버 검색 노출일은 별개입니다. 사이트를 공개하고 수집을 요청해도 노출 여부와 순위는 따로 확인해야 합니다. 네이버는 URL 검사 로 문서의 수집·색인 상태를 확인하는 방법을 안내합니다. 자주 묻는 질문 사진과 원고가 없어도 시작할 수 있나요? 구조와 디자인 방향을 먼저 정할 수 있습니다. 다만 촬영·원고 작성 주체와 자료 전달일을 정하지 않으면 최종 일정이 비어 있게 됩니다. 임시 자료를 최종 자료로 교체하는 작업도 일정에 포함하세요. 코딩으로 만들면 무조건 오래 걸리나요? 도구 이름만으로 정할 수 없습니다. 기존 구성 요소를 활용하는 개발은 빠를 수 있고, 웹빌더도 복잡한 기능과 자료 정리가 필요하면 오래 걸립니다. 사용할 방식과 함께 실제 작업 범위를 비교해야 합니다. 수정 횟수만 적으면 일정이 정해지나요? 횟수뿐 아니라 한 차례 수정의 범위, 의견 전달 기한, 제작사의 회신·반영 기한이 필요합니다. 새 페이지 추가와 문구 변경을 같은 수정으로 취급하는지도 확인하세요. 희망 오픈일이 있다면 페이지 목록, 자료 준비 상태, 필요한 기능을 함께 보내주세요. 슬로히어로는 이를 바탕으로 디자인 방향과 작업 범위를 정리하고 견적·일정을 안내합니다. 홈페이지 제작 상담하기 Tue, 15 Sep 2026 09:00:00 +0900 https://slohero.com/blog/homepage-production-period https://slohero.com/blog/renewal-agency 홈페이지 리뉴얼 업체는 새 화면의 디자인뿐 아니라 기존 계정·자료·주소·운영을 어떻게 이어받는지 확인해 선택해야 합니다. 현재 사이트의 문제를 먼저 진단하고, 이전할 대상과 오픈 검수 방법이 견적에 적혀 있는지 보세요. 필요한 범위가 정해지지 않으면 저렴한 견적과 빠른 일정도 제대로 비교하기 어렵습니다. 기존 사이트가 있다면 첫 상담에 현재 주소를 보내는 것부터 시작하면 됩니다. 제작사가 무엇을 유지하고 무엇을 바꿀지 설명할 수 있어야 합니다. 전체 리뉴얼이 필요한지 먼저 구분하세요 불편한 지점이 한 부분에 모여 있다면 전체를 새로 만들기 전에 부분 개선을 검토할 수 있습니다. 현재 문제 먼저 확인할 내용 검토할 작업 내용이 오래됨 관리자가 직접 수정할 수 있는가 원고·사진 갱신 모바일에서 일부 화면이 깨짐 특정 구간 문제인가, 전체 구조 문제인가 부분 보정 또는 반응형 재설계 문의가 오지 않음 유입·문의 동선·폼 수신 중 어디가 문제인가 원인 진단 후 해당 구간 개선 자료가 흩어져 찾기 어려움 분류·검색·상세 정보 구조가 필요한가 콘텐츠 구조와 관리 방식 개편 원하는 기능을 추가하기 어려움 현재 플랫폼·데이터 구조가 지원하는가 기능 확장 또는 재구축 운영 계정에 접근하지 못함 기존 업체와 계정·자료를 인계할 수 있는가 인계 확인 후 제작 범위 결정 단순히 느리다는 이유만으로 서버를 바꾸거나, 문의가 적다는 이유만으로 디자인을 전부 바꾸면 원인을 남겨둘 수 있습니다. 실제로 어떤 경로가 불편한지 화면과 기록을 보고 진단하는지 확인하세요. 리뉴얼 견적에는 5개 이관 범위가 필요합니다 1. 도메인과 운영 계정 도메인 등록기관의 계정, 갱신 담당자, DNS 변경 권한을 확인합니다. 홈페이지 업체를 바꾼다고 도메인 등록기관까지 반드시 바꿔야 하는 것은 아닙니다. 공개 도메인 조회에는 등록자 정보가 가려질 수 있으므로 조회 결과만으로 소유 관계를 단정하지 마세요. 실제 관리 계정과 등록기관에서 확인할 수 있는 계약·등록 정보를 함께 확인하는 편이 정확합니다. 회사 메일도 같은 도메인을 쓰고 있다면 홈페이지 변경 시 메일 설정이 영향을 받는지 확인해야 합니다. 웹사이트 연결과 메일 연결을 구분해 작업 계획에 넣으세요. 2. 파일·디자인·관리자·데이터 다음 제작사가 무엇을 이어받을 수 있는지 형태를 적어 두세요. 인계 대상 확인할 질문 운영자 계정 회사가 필요한 권한으로 직접 접속할 수 있는가 웹 파일·코드 받을 수 있는 파일과 실행에 필요한 환경은 무엇인가 콘텐츠 데이터 글·상품·문의 등이 어떤 형식으로 나오는가 디자인 자료 원본 제공 범위와 사용 가능한 라이선스는 무엇인가 외부 서비스 폼·예약·분석·메일 계정의 담당자는 누구인가 서비스형 웹빌더에서는 전체 사이트를 다른 서버로 그대로 옮기지 못할 수 있습니다. Wix도 자사 사이트의 외부 호스팅을 지원하지 않는다고 안내합니다. 따라서 ‘소스코드 납품’만 요구하기보다 콘텐츠·도메인·운영 계정을 어떤 방법으로 인계할 수 있는지 확인해야 합니다. Wix 외부 호스팅 안내 3. 옮길 콘텐츠의 수와 연결 관계 “게시글 이전 포함”보다 게시글 수, 이미지·첨부파일, 작성일·분류, 관련 페이지 연결을 구분한 목록이 필요합니다. 예를 들어 게시글 50개·이미지 200개를 옮긴다는 가상 조건에서도 이미지가 글 안의 어느 위치에 들어가는지, 첨부파일이 계속 열리는지, 작성일을 유지할지에 따라 작업이 달라집니다. 화면 틀을 만드는 비용과 자료 정리·입력·검수 비용을 나누어 받으세요. 슬로히어로의 슈갤러리 제작 사례 는 전시·작품·작가를 연결하는 구조를 보여줍니다. 이런 사이트는 글의 총개수만 맞추는 것보다 서로 연결된 정보가 새 구조에서도 이어지는지 확인하는 일이 중요합니다. 4. 기존 페이지 주소 기존 주소로 들어오는 검색 방문자와 외부 링크가 어디로 이동하는지 정해야 합니다. 대표 주소 하나만 새 사이트로 연결해도 모든 하위 페이지가 처리되는 것은 아닙니다. 기존 주소의 상태 검토할 처리 같은 내용이 같은 주소에 남음 주소와 주요 정보 유지 내용은 유지하지만 주소가 바뀜 대응하는 새 페이지로 영구 이동 설정 여러 글을 하나로 합침 통합된 내용이 있는 새 페이지로 연결 대체 콘텐츠 없이 완전히 삭제 삭제 상태에 맞는 응답 처리 Google은 이전 주소와 새 주소의 대응표, 관련 있는 목적지로의 이동, 새 사이트맵과 모니터링을 안내합니다. 모든 주소를 무관한 메인 화면으로 보내는 방식은 피하는 편이 좋습니다. Google 사이트 이전 가이드 이는 Google 공식 가이드이며 네이버 순위 유지 보장을 뜻하지 않습니다. 네이버 상태도 별도로 확인해야 합니다. 5. 오픈 후 확인과 되돌리는 방법 오픈 전에는 테스트 주소에서 확인하고, 오픈 직후에는 실제 주소에서 다시 확인합니다. 문의·예약·메일처럼 외부 서비스가 연결되는 항목은 운영 환경에서 확인해야 합니다. 문제가 생겼을 때 되돌릴 대상과 담당자도 정하세요. 사이트 파일만 되돌릴지, 새로 들어온 문의나 예약 데이터는 어떻게 보존할지에 따라 복구 작업이 달라집니다. 업체 비교표는 어떻게 채우나요? 다음은 응답 내용을 정리하는 가상 예시입니다. 실존 업체의 평가가 아닙니다. 필수 확인 항목 가상 A의 답 가상 B의 답 비교 판단 기존 사이트 진단 현재 화면·운영 방식 확인 후 범위 제안 새 디자인만 제안 B에 기존 문제 진단 요청 자료 이전 대상·건수·형식과 검수 방식 제시 ‘이전 가능’만 표기 B의 범위·추가비 미확정 주소 변경 기존·신규 주소 대응표 제공 메인으로 일괄 연결 제안 주요 하위 주소 처리 재협의 운영 계정 회사 계정과 초대 방식 명시 제작사 계정에서 계속 관리 관리·이관 조건 비교 필요 오픈 검수 문의 수신·모바일·주소 확인 ‘오픈 완료’만 표기 완료 기준 확인 필요 추가 비용 초과 이전·추가 기능 단가 제시 진행 후 협의 최종 금액 비교 불가 답이 부족한 항목을 ‘나쁨’으로 채점하기보다, 결정 전에 필요한 답을 받는 표로 쓰세요. 단가와 범위가 확인되지 않은 상태에서 총액 순위를 매기면 의미가 약합니다. 리뉴얼 업체 비교·이관 양식 내려받기 홈페이지 리뉴얼 비용은 왜 신규 제작과 다를까요? 새 화면 제작에 더해 기존 시스템 파악, 자료 정리·이전, 주소 처리와 인계가 필요할 수 있기 때문입니다. 반대로 자료와 디자인을 대부분 재사용하는 부분 개선이라면 작업을 줄일 수도 있습니다. 견적은 다음 항목으로 나누어 받으면 됩니다. 새 화면·기능 제작 + 콘텐츠 정리·이전 + 주소·외부 연동 처리 + 공개 검수·인계 각 항목에 대상과 수량을 붙이세요. “리뉴얼은 무조건 신규보다 비싸다”거나 “기존 사이트가 있으니 항상 싸다”는 기준으로 정하기 어렵습니다. 금액 비교 방법은 홈페이지 제작 견적서 비교법 에 정리했습니다. 자주 묻는 질문 기존 업체에 다시 맡기는 편이 나을까요? 현재 구조를 알고 있다는 장점은 있습니다. 다만 기존 문제를 어떻게 개선할지, 계정과 자료를 어떤 조건으로 운영할지는 새 견적에서 확인해야 합니다. 익숙한 관계와 명확한 범위는 별개입니다. 도메인을 유지하면 검색 순위도 유지되나요? 보장되지 않습니다. 하위 주소, 콘텐츠, 연결 구조와 검색 수집 상태가 함께 바뀔 수 있습니다. 중요한 기존 페이지를 확인하고 이전 후 검색 상태를 점검해야 합니다. 옛 서버는 언제 해지하나요? 새 사이트 안정화, 자료 확보, 외부 연동과 주소 이동 설정을 확인한 뒤 결정합니다. 기존 서버 해지와 기존 주소의 이동 연결을 없애는 것은 다릅니다. Google은 영구 이동 연결을 일반적으로 최소 1년 유지하도록 안내하므로, 서버를 해지하더라도 필요한 연결을 다른 환경에서 계속 제공할지 확인하세요. 공식 이전 가이드 업체가 코드나 자료를 바로 주지 않으면 어떻게 하나요? 기존 계약과 플랫폼의 인계 방법부터 확인하세요. 받을 수 있는 자료·권한·형식을 정리한 뒤 새 업체에 검토를 요청하면 재사용 가능 범위와 새로 만들 범위를 나눌 수 있습니다. 현재 사이트 주소와 불편한 점, 유지하고 싶은 기능을 보내주세요. 슬로히어로 홈페이지 제작 상담 에서 부분 개선과 전체 리뉴얼 중 필요한 범위부터 확인할 수 있습니다. Sat, 05 Sep 2026 09:00:00 +0900 https://slohero.com/blog/renewal-agency https://slohero.com/blog/weebly-shutdown-domain-seo 1. 왜 보통의 이전 안내가 여기서는 안 통하나 일반적인 사이트 이전에서 순위를 지키는 방법은 정해져 있습니다. 옛 주소로 들어온 요청을 새 URL로 돌려보내는 301 영구 이동 을 걸어두는 것입니다. 검색엔진이 옛 주소를 다시 방문했을 때 "이 페이지는 저기로 갔다"는 답을 받아야, 쌓아둔 평가가 새 주소로 넘어갑니다. 문제는 그 답을 옛 서버가 해줘야 한다는 점입니다. 서비스가 종료되면 응답할 서버 자체가 없어집니다. 남는 것은 응답 없음이거나 등록기관의 안내 화면인데, 어느 쪽도 "저기로 갔다"는 뜻이 아닙니다. 검색엔진은 사라진 페이지로 처리하고, 몇 차례 재방문 뒤 색인에서 뺍니다. 그래서 순서를 뒤집어야 합니다. 보통은 새 사이트를 만든 뒤 옛 사이트에서 연결 하지만, 이번에는 옛 사이트가 살아 있는 동안 주소의 소유권을 확보 해두고, 새 사이트가 그 주소를 이어받는 방식으로 갑니다. 날짜 감각이 필요합니다. 9월 27일에는 방문자가 못 보게 되고, 12월 26일에는 계정과 그 안의 자료가 지워집니다. 아직 자료를 안 꺼내셨다면 9월 27일 전에 지금 당장 백업하는 법 이 먼저입니다. 2. 먼저 확인 — 내 주소가 어느 쪽인가 여기서 결과가 완전히 갈립니다. 브라우저 주소창을 보세요. (가) 내 도메인을 쓰고 있다 — example.co.kr 처럼 직접 등록한 주소가 떠 있다면 좋은 쪽입니다. 이 주소만 지키면 검색엔진이 쌓아둔 평가는 대체로 따라옵니다. 플랫폼이 바뀌어도 주소가 같으면 이전이라고 부를 일 자체가 생기지 않습니다. (나) 플랫폼이 준 무료 주소를 쓰고 있다 — 주소에 서비스 이름이 들어가 있다면 그 주소는 처음부터 내 것이 아니었습니다. 서비스가 닫히면 주소도 같이 닫히고, 그 주소에 쌓인 검색 평가는 옮길 방법이 없습니다. 이 경우 할 수 있는 일은 손실을 인정하고 새로 쌓는 것입니다. 다만 완전히 맨땅은 아닙니다. 3번과 8번에서 다룹니다. (가)에 해당하더라도 한 가지 더 봐야 합니다. 그 도메인을 어디서 샀는가 입니다. 가비아·후이즈 같은 국내 등록기관에서 사서 연결만 해두셨다면 할 일은 연결 설정 변경뿐입니다. 종료되는 플랫폼 안에서 함께 구매하셨다면 인증코드를 받아 다른 등록기관으로 이전 해야 하고, 이 절차는 계정이 살아 있는 동안에만 가능합니다. 어디를 향하고 있는지는 아래로 바로 확인됩니다. # 등록기관과 만료일 확인 (여기서 회사 이름을 봅니다) whois example.co.kr | head -30 # 지금 어느 서버를 보고 있나 dig +short example.co.kr 윈도우라면 nslookup example.co.kr 로 두 번째 줄을 대신할 수 있습니다. 등록기관 이름이 낯선 해외 회사로 나온다면 (가)이면서도 이전 절차가 필요한 경우일 가능성이 큽니다. 3. 오늘 안에 받아둘 것 — 옛 주소 목록 순위 작업 전체에서 마감이 있는 항목은 이것 하나 입니다. 사이트가 내려가면 어떤 페이지가 어떤 URL이었는지 확인할 방법이 사실상 사라집니다. 목록이 없으면 새 사이트에서 무엇을 어디로 연결할지 결정할 수 없습니다. 세 곳에서 모으시면 됩니다. 첫째, 사이트맵. 내주소/sitemap.xml 을 브라우저에 그대로 입력하면 플랫폼이 만들어둔 페이지 목록이 나옵니다. 통째로 저장해두세요. 둘째, 서치콘솔. 구글 서치콘솔에 사이트를 등록해두셨다면 실적 보고서에서 페이지별로 실제 유입이 있던 URL 을 내려받을 수 있습니다. 사이트맵이 "있는 페이지 전부"라면 이쪽은 "값어치가 있던 페이지"라, 우선순위를 정할 때 이게 더 유용합니다. 셋째, 검색창. 구글에 site:example.co.kr 을 넣으면 색인된 URL이 나열됩니다. 서치콘솔을 안 쓰셨다면 이 방법이 유일한 대안입니다. 화면을 넘겨가며 주소를 그대로 복사해두세요. 세 목록을 합쳐 엑셀 한 장으로 만드시고, 옆 칸에 새 사이트에서의 URL 을 적을 자리를 비워두세요. 이 표가 다음 단계의 작업 지시서가 됩니다. 페이지가 열 장 남짓인 소개형 사이트라면 삼십 분이면 끝납니다. 4. 도메인을 지키면 "이전"이 아니게 된다 가장 많이 받는 질문이 "새 사이트를 만들면 순위가 처음부터 다시 시작되나요" 인데, 같은 도메인을 쓰신다면 대체로 아닙니다. 검색엔진이 평가를 쌓아둔 단위는 플랫폼이 아니라 주소 입니다. 편집기가 위블리에서 다른 것으로 바뀐 사실은 검색엔진이 알지도 못하고 관심도 없습니다. 구글도 주소 변경 도구 안내에서 같은 취지를 분명히 하고 있습니다. 도메인이나 하위 도메인이 바뀔 때만 그 도구를 쓰라고 하면서, www가 있는 주소와 없는 동일한 주소 간에 이동하는 경우 나 같은 도메인 안에서 경로만 옮기는 경우에는 필요 없다고 적고 있습니다. 즉 도메인이 그대로면 신고할 이사 자체가 없습니다. 다만 조건이 하나 붙습니다. 페이지 주소까지 그대로여야 온전합니다. 새 플랫폼은 대개 주소 규칙이 다릅니다. 같은 소개 페이지가 /about.html 에서 /pages/about 으로 바뀌는 식입니다. 도메인은 지켰는데 그 아래 경로가 전부 달라지면, 검색엔진 입장에서는 있던 페이지 수십 개가 한꺼번에 사라지고 새 페이지 수십 개가 생긴 것 으로 보입니다. 3번에서 만든 표가 필요한 이유가 여기 있습니다. 5. 새 사이트 쪽에서 옛 경로를 받아주는 법 옛 서버에 못 거는 301을 새 서버에 겁니다. 도메인이 새 사이트를 가리키게 된 순간부터, 옛 URL로 들어오는 요청도 새 서버에 도착합니다. 그때 "이 경로는 저 경로로 갔다"고 답해주면 됩니다. 방향은 같고 응답하는 주체만 바뀌는 셈입니다. 설정 위치는 어디에 올리느냐에 따라 다릅니다. 대표적인 세 가지입니다. # Netlify / Cloudflare Pages — 최상위에 _redirects 파일 /about.html /about 301 /contact.html /contact 301 /blog/hello /notes/hello 301 # Apache 계열 웹호스팅 — .htaccess Redirect 301 /about.html /about Redirect 301 /contact.html /contact # Nginx location = /about.html { return 301 /about; } 국내 빌더처럼 파일을 못 올리는 서비스라면, 관리 화면에 "URL 리디렉션" 또는 "주소 전달" 메뉴가 있는지 확인하세요. 없는 서비스도 많습니다. 없다면 차선책은 새 사이트의 URL 규칙을 옛것에 맞추는 것 입니다. 페이지 이름을 정할 수 있는 빌더라면, 새로 짓지 말고 옛 이름을 그대로 쓰시면 연결 작업 자체가 사라집니다. 이게 가장 적은 노동으로 끝나는 길입니다. 전부 옮길 필요도 없습니다. 3번에서 유입이 있던 페이지를 골라두셨다면 상위 스무 개만 연결해도 실질적인 손실은 대부분 막힙니다. 나머지는 방문자를 첫 화면으로 보내는 것으로 충분합니다. 6. 도메인까지 바뀔 수밖에 없다면 무료 주소를 쓰셨거나, 이 참에 주소를 바꾸기로 하셨다면 절차가 하나 늘어납니다. 구글 서치콘솔의 주소 변경 도구 입니다. 도메인 단위 이동일 때만 씁니다. 이 도구는 마법이 아니라 기한이 있는 안내문 에 가깝습니다. 구글 문서에 따르면 이전을 시작한 뒤 180일 동안 옛 사이트보다 새 사이트를 우선해 보여주고, 그 기간이 지나면 두 사이트의 관계를 더 이상 인식하지 않습니다. 즉 180일 안에 새 주소가 자기 힘으로 서 있어야 합니다. 그리고 이 도구는 옛 사이트에 301이 걸려 있다는 전제 에서 가장 잘 작동합니다. 위블리처럼 옛 서버가 사라지는 경우에는 그 전제가 무너지므로, 효과가 정상적인 도메인 이사만큼 나오지 않을 수 있다는 점을 감안하셔야 합니다. 이것이 도메인을 지키는 쪽을 먼저 권하는 이유입니다. 7. 얼마나 걸리고, 언제까지 두나 두 숫자만 기억하시면 됩니다. 몇 주 와 1년 입니다. 회복 속도에 대해 구글은 중간 규모 사이트 기준으로 a few weeks or more for Google to gradually start showing the new URLs 라고 적고 있습니다. 큰 사이트는 더 걸립니다. 바꾼 다음 날 순위를 확인하고 실패했다고 판단하는 것이 가장 흔한 실수입니다. 페이지가 열 장 남짓이면 대개 이보다 빠르지만, 2~3주는 기다려보셔야 판단이 섭니다. 연결 설정을 언제까지 두느냐에 대한 답은 더 분명합니다. 같은 문서가 Keep the redirects for as long as possible, generally at least 1 year 라고 명시합니다. 최소 1년 이고, 지울 이유가 없다면 계속 두는 편이 낫습니다. "이제 다 넘어갔겠지" 하고 6개월 만에 정리하는 것은 손해입니다. 8. 구글만 손보면 절반이다 국내 사이트는 유입 경로가 갈립니다. 아래 세 가지를 같이 처리하셔야 체감이 달라집니다. 네이버. 서치어드바이저에 새 사이트를 등록하고, 사이트맵을 제출한 뒤 주요 페이지에 대해 수집을 요청하는 절차를 직접 밟아야 합니다. 구글 서치콘솔을 등록했다고 자동으로 처리되지 않습니다. 소개형 사이트일수록 네이버 유입 비중이 큰 경우가 많아 이쪽을 빠뜨리면 체감 손실이 큽니다. 남이 걸어둔 링크. 블로그·카페·언론 기사·협회 명단에 옛 링크가 박혀 있습니다. 이건 내 설정으로 못 고칩니다. 도메인을 지켰다면 저절로 해결되고, 도메인이 바뀌었다면 연락해서 고쳐달라고 부탁하는 것 외에 방법이 없습니다. 구글도 사이트 이동 안내에서 내부 링크·외부 링크·SNS 프로필·광고 캠페인의 링크를 가능한 한 많이 업데이트하라 는 취지로 권합니다. 무료 주소를 쓰셨던 (나) 유형에게는 이 항목이 사실상 유일한 회복 수단입니다. 내 손이 닿는 곳. 인스타그램·네이버 플레이스·명함·전단·카카오톡 채널 프로필. 검색엔진 이야기가 아니라 그냥 사람이 눌러보는 링크이고, 이게 끊기면 매출이 먼저 끊깁니다. 목록을 만들어 하나씩 지워가며 고치세요. 9. 자주 나오는 오해 "플랫폼을 바꾸면 순위가 리셋되나요" — 주소가 그대로면 아닙니다. 다만 페이지 내용을 통째로 새로 쓰거나, 본문이 자바스크립트로만 그려지도록 만들면 그때는 떨어집니다. 새 사이트에서 본문 글자가 첫 응답에 들어 있는지 는 따로 확인하셔야 합니다. "임시로 302를 걸어두고 나중에 301로 바꿔도 되나요" — 권하지 않습니다. 302는 "잠깐 딴 데 있다"는 뜻이라 평가를 넘기는 신호가 약합니다. 처음부터 301로 거세요. "9월 27일에 순위가 사라지나요" — 그날 바로는 아닙니다. 검색엔진이 사라진 페이지를 확인하고 색인에서 빼는 데 시간이 걸립니다. 그 시간이 유예 기간이지만, 도메인이 살아 있어야만 쓸 수 있는 유예 입니다. 계정이 지워지는 12월 26일 이후에는 되돌릴 수단이 없습니다. 이전처를 아직 못 정하셨다면 어디로 옮기나 — 이전처 비교 를 참고하세요. § 이 글의 근거 리다이렉트 유지 기간( generally at least 1 year ), 이동 후 회복에 걸리는 기간, 사이트맵·링크 갱신 권장 사항은 구글의 URL 변경이 있는 사이트 이동 문서 원문에서 직접 확인했습니다. 주소 변경 도구의 적용 조건과 180일 이라는 신호 이전 기간은 주소 변경 도구 도움말 에서 확인한 값입니다. 위블리 종료 일정(9월 27일 사이트 비공개 · 12월 26일 계정 삭제)은 앞선 두 편에서 독립된 영문 자료를 교차 대조해 확인한 값을 그대로 이어 씁니다. 원문 대조 실패: 공식 안내 페이지는 본문이 자바스크립트로 그려져 이번에도 원문 문구를 직접 확인하지 못했으니, 날짜는 실제 계정 화면의 안내와 한 번 더 대조해보시길 권합니다. 네이버 서치어드바이저에 구글의 주소 변경 도구에 해당하는 기능이 있는지는 이번 조사 범위에서 확인하지 못해, 8번에는 등록·사이트맵 제출·수집 요청 이라는 확인된 절차만 적었습니다. 이 글은 검색 결과의 회복을 보장하지 않습니다. 검색엔진의 처리 방식은 공개되지 않은 부분이 많고, 같은 절차를 밟아도 결과는 사이트마다 다릅니다. 다만 도메인을 잃지 않는 것 과 옛 URL 목록을 미리 받아두는 것 은 결과와 무관하게 되돌릴 수 없는 손실을 막아주는 두 가지라, 이것만은 마감 전에 끝내시길 권합니다. 관련 글은 블로그 목록 에 모아두었습니다. Wed, 02 Sep 2026 00:00:00 +0900 https://slohero.com/blog/weebly-shutdown-domain-seo https://slohero.com/blog/ai-cyberattack-small-business-website-checklist 1. 무슨 일이 있었나 2026년 8월 27일, 오픈AI · 앤스로픽 · 구글 · 마이크로소프트 · 메타 같은 개발사와 크라우드스트라이크 · 옥타 · 포티넷 등 보안 기업, 금융사와 인터넷 인프라 회사를 포함해 100곳이 넘는 기업 이 공동 서한에 이름을 올렸습니다. 요지는 민간과 정부가 지역 · 국가 · 국제 단위에서 함께 방어 체계를 세우자는 것입니다. 서한의 핵심 문장은 이렇습니다. “In the coming months, AI-enabled cyber attacks will become far more widespread and sophisticated as models around the world become increasingly capable.” (앞으로 몇 달 사이, 전 세계 모델의 성능이 올라가면서 AI를 활용한 사이버 공격은 훨씬 광범위하고 정교해질 것이다.) 경쟁 관계인 회사들이 같은 문서에 서명했다는 점이 이 소식의 무게입니다. 다만 이 서한은 대기업과 정부를 향한 것이고, 직원 없이 사이트 하나를 운영하는 쪽에는 “그래서 나는 뭘 하지”가 남습니다. 그 답을 아래에 적었습니다. 2. 왜 작은 사이트가 표적이 되나 노려서 공격당하는 게 아니라, 훑다가 걸립니다. 자동화 도구는 인터넷 전체를 순회하며 알려진 취약점과 흔한 비밀번호를 시험합니다. 사람이 개입하지 않으니 매출 규모를 가리지 않습니다. 언어 모델이 붙으면서 달라진 건 공격 방식보다 속도와 문장 품질 입니다. 어색한 번역투로 알아채던 피싱 메일이 이제 자연스러운 한국어로 옵니다. 국내 수치도 방향이 같습니다. 과학기술정보통신부와 한국인터넷진흥원(KISA)이 2026년 8월 3일 공개한 집계에 따르면 2026년 상반기 침해사고 신고는 1,236건 으로 전년 동기 1,034건보다 19.5% 늘었습니다. 이 가운데 서버 해킹이 487건, 디도스가 373건(전년 대비 56.7% 증가), 랜섬웨어가 145건(76.8% 증가)이었습니다. 더 눈여겨볼 숫자는 피해자 구성입니다. KISA가 2025년 1월 발표한 직전 연도 자료에서 랜섬웨어 피해 신고의 94%가 중소기업 이었습니다. 보안 담당자가 없는 조직이 통계의 대부분을 채운다는 뜻입니다. 3. 관리자 계정부터 (10분) 침해 경로에서 가장 흔한 건 정교한 해킹이 아니라 추측 가능한 로그인 입니다. 세 가지만 보세요. 아이디가 admin 인가. 그렇다면 새 관리자 계정을 만들고 기존 계정을 삭제하세요. 자동 대입 공격은 아이디를 이미 안다고 가정하고 비밀번호만 돌립니다. 비밀번호를 다른 서비스와 함께 쓰는가. 유출된 목록을 그대로 대입하는 방식이 여전히 가장 잘 통합니다. 2단계 인증이 켜져 있는가. 워드프레스 · 카페24 · 아임웹 · 구글 워크스페이스 모두 무료로 제공합니다. 퇴사자나 외주 작업자의 계정이 남아 있는지도 같이 확인하세요. 오래된 협력사 계정이 통로가 되는 사례가 실제로 보고됩니다. 4. 업데이트는 자동으로 (5분) 공개된 취약점은 공개된 순간부터 스캔 대상이 됩니다. 대응 시간을 사람에게 맡기지 말고 자동 적용으로 돌려두는 편 이 안전합니다. 워드프레스라면 코어 마이너 업데이트는 기본값이 자동이지만, 플러그인과 테마는 각 항목에서 따로 켜야 합니다. 쓰지 않는 플러그인은 비활성화가 아니라 삭제 하세요. 비활성 상태여도 파일이 서버에 남아 있으면 취약점은 그대로입니다. 관리 화면 편집기를 막는 설정도 함께 넣어두면 좋습니다. // wp-config.php — 관리 화면에서 테마·플러그인 파일 편집 차단 define( 'DISALLOW_FILE_EDIT', true ); 계정이 탈취돼도 서버 파일을 브라우저에서 바로 고쳐 심는 경로 하나는 닫힙니다. 5. 백업은 ‘복원까지’ 해봐야 백업 (10분) 백업을 켜뒀다는 것과 되살릴 수 있다는 것은 다릅니다. 실제로 문제가 터졌을 때 복원해 본 적 없는 백업 이 깨져 있거나, 같은 서버에 있어서 함께 암호화된 경우가 흔합니다. 확인할 것은 세 가지입니다. 최근 파일이 실제로 생성돼 있는가 (날짜와 용량을 눈으로 확인) 사본 하나가 웹서버 바깥 에 있는가 (외부 스토리지, 다른 계정) 테스트 환경에 한 번 되살려 봤는가 복원 리허설은 1년에 한 번이면 충분합니다. 그 한 번이 사고 당일의 하루를 벌어줍니다. 6. 노출되면 안 되는 파일 확인 (5분) 개발 중에 올려두고 잊은 파일이 그대로 공개돼 있는 경우가 많습니다. 브라우저 주소창에 직접 넣어보거나 아래처럼 확인하세요. 200 이 뜨면 조치가 필요합니다. # 응답 코드만 확인 (404 정상 / 200 이면 점검) for p in .env .git/config wp-config.php.bak backup.zip phpinfo.php; do printf '%-22s ' "$p" curl -s -o /dev/null -w '%{http_code}\n' "https://example.com/$p" done example.com 을 본인 주소로 바꿔서 돌리면 됩니다. .env 나 .git 이 열려 있으면 데이터베이스 접속 정보와 소스 전체가 노출된 상태라 최우선으로 막아야 합니다. 압축 백업 파일을 웹 폴더에 두는 습관도 이 기회에 정리하세요. 7. 문의 폼과 도메인 만료 (10분) 생성 모델이 퍼진 뒤 눈에 띄게 늘어난 건 사람처럼 읽히는 폼 스팸 입니다. 예전 필터는 반복 문구와 링크 개수로 걸렀지만, 지금은 업종에 맞는 문의처럼 자연스럽게 들어옵니다. 대응은 두 가지입니다. 캡차를 걸어 자동 제출 자체를 줄이고, 폼 응답을 이메일에만 의존하지 말고 별도로 저장해 두는 것입니다. 스팸 판정으로 진짜 문의가 묻히는 일이 실제 손실입니다. 그리고 매년 몇 건씩 반복되는 사고가 도메인 만료 입니다. 결제 카드가 바뀌었는데 갱신 설정을 놓쳐 사이트가 통째로 사라지고, 만료된 주소를 제3자가 선점하는 경우까지 생깁니다. 도메인과 호스팅의 자동 갱신 여부와 등록 이메일 을 오늘 같이 확인하세요. 쓰지 않는 메일 주소로 등록돼 있으면 경고 메일이 어디에도 닿지 않습니다. 8. 그래서 오늘 할 일 위 항목을 순서대로 옮기면 이렇게 됩니다. 관리자 아이디 변경과 2단계 인증 → 플러그인 자동 업데이트와 미사용 항목 삭제 → 백업 파일 실재 확인 → 노출 파일 점검 → 폼 스팸 대응 → 도메인 자동 갱신 → 최근 로그인 기록 확인 . 대부분 30분 안에 끝나고, 비용은 들지 않습니다. 공동 서한이 말한 “몇 달”은 대응 계획을 세우기에 짧은 기간입니다. 하지만 위 목록은 계획이 아니라 오늘 끝낼 수 있는 작업입니다. 자동화된 공격은 늘 더 쉬운 대상 을 먼저 고릅니다. 기본을 채워 넣는 것만으로 순서에서 밀려납니다. 사이트를 새로 만들 계획이라면 이 항목들이 처음부터 들어가 있는 편이 훨씬 쌉니다. SLOHERO가 만드는 홈페이지는 계정 · 백업 · 갱신 구조를 기본값으로 잡아둡니다. 실제 작업 사례 와 다른 글 도 참고하세요. § 이 글의 근거 공동 서한 관련 내용은 2026년 8월 27일 테크크런치 보도를 따랐습니다( 원문 보기 ). 서한 전문 자체는 공개 주소를 확인하지 못해 원문 대조에 실패 했고, 인용문과 서명 기업 목록은 해당 보도에 실린 범위까지만 옮겼습니다. 서명 기업 수는 “100곳 이상”으로만 보도돼 정확한 숫자는 적지 않았습니다. 2026년 상반기 침해사고 수치(1,236건 · 서버 해킹 487건 · 디도스 373건 · 랜섬웨어 145건)는 과학기술정보통신부와 KISA가 2026년 8월 3일 공개한 집계로, 기관 원문 페이지를 열지 못해 데일리시큐 · NK경제 · 지디넷코리아 보도를 교차 대조해 확인했습니다. 반면 “랜섬웨어 피해 신고의 94%가 중소기업”은 KISA가 2025년 1월 24일 배포한 자료에서 직접 확인한 2024년 기준 수치입니다. 본문의 점검 항목은 위 자료와 SLOHERO의 유지보수 경험을 함께 반영한 것으로, 특정 제품이나 서비스의 후원을 받지 않았습니다. Wed, 02 Sep 2026 00:00:00 +0900 https://slohero.com/blog/ai-cyberattack-small-business-website-checklist https://slohero.com/blog/ai-website-client-handoff 1. 왜 "계정 하나 넘기면 끝"이 아닌가 AI 빌더로 만든 사이트는 겉보기에 한 덩어리지만, 실제로는 서로 다른 회사의 서비스 서너 개가 묶여 돌아갑니다. 채팅으로 만들었다는 이유로 결과물도 한 곳에 있다고 생각하기 쉽습니다. 그런데 화면을 그리는 곳, 그 화면을 인터넷에 올려두는 곳, 회원과 주문을 담아두는 곳, 주소를 파는 곳이 각각 다른 회사입니다. 넘겨받는 쪽 입장에서 ‘내 사이트’가 되려면 이 네 군데의 계정이 전부 그쪽 이름으로 되어 있어야 합니다. 하나라도 제작자 계정에 남아 있으면 어떻게 되는지는 간단합니다. 제작자가 카드를 해지하거나 계정을 정리하는 순간 그 부분이 멈춥니다. 사이트는 열리는데 로그인만 안 되거나, 화면은 뜨는데 주소가 만료되는 식으로 반쪽만 죽습니다. 넘기는 사람도 몇 달 뒤에 남의 사이트 요금을 계속 내고 있는 상태가 됩니다. 그러니 인계는 파일을 주는 일이 아니라 결제 수단과 소유자 이름을 옮기는 일 에 가깝습니다. 2. 첫째 — 빌더 계정 (Lovable 기준) Lovable은 프로젝트 설정 안에 소유권 이전 메뉴가 있습니다. 다만 아무에게나 넘길 수 있는 것은 아닙니다. 공식 문서가 안내하는 경로는 이렇습니다. “Go to Project settings → Transfer ownership and select a workspace member.” 프로젝트 설정에서 소유권 이전을 고르고 워크스페이스 구성원을 지정하라는 뜻입니다. 여기서 걸리는 조건이 하나 있습니다. “Collaborators and pending invitees are not eligible.” 협업자 자격이거나 초대장을 아직 수락하지 않은 상태면 대상이 되지 않습니다. 즉 고객을 먼저 정식 구성원으로 초대해 수락까지 끝낸 뒤에야 이전 버튼이 의미를 갖습니다. 설정의 People 메뉴에서 초대하고, 고객이 메일을 열어 수락한 것을 확인한 다음 넘기십시오. 이 순서를 건너뛰고 목록에서 이름을 찾다가 안 보여서 헤매는 경우가 흔합니다. 코드 자체의 권리는 문서가 짧게 못 박아 두었습니다. 누가 코드를 소유하느냐는 물음에 “You as the creator do!” 라고 답합니다. 만든 사람 것이라는 뜻이고, 그래서 계약서에 ‘결과물 일체를 발주자에게 귀속’ 같은 문장이 들어 있다면 그 약속을 실제로 이행하는 행위가 바로 이 이전 작업입니다. 문서상 권리와 계정상 소유자를 같이 맞춰야 말이 됩니다. 내보내기 경로도 열어 두는 편이 좋습니다. 문서는 코드를 “transfer your code to GitHub or GitLab and do whatever you'd like with it” 라고 설명합니다. 저장소로 한 번 빼두면 나중에 빌더를 떠나더라도 결과물이 남습니다. 반대 방향은 막혀 있습니다 — “currently there is no way to start a Lovable project from already existing code”. 기존 코드를 가져와 새 프로젝트를 시작하는 길은 없다는 뜻이니, 저장소는 백업이지 복귀 경로가 아니라는 점만 알아두면 됩니다. 3. 둘째 — 배포 계정 (Vercel 기준) 배포는 무중단으로 옮길 수 있습니다. 대신 따라오지 않는 목록 이 꽤 깁니다. Vercel 문서는 팀 사이 프로젝트 이동을 “zero downtime” 으로 설명합니다. 권한 조건은 보내는 팀에서는 소유자, 받는 팀에서는 구성원입니다. 설정 화면의 General 맨 아래 Transfer Project에서 시작하고, 소요 시간은 데이터 양에 따라 10초에서 10분 사이 라고 안내합니다. 진행 중에는 새 배포를 만들거나 설정을 고칠 수 없으니 트래픽이 적은 시간대에 하는 편이 낫습니다. 같이 옮겨지는 것은 배포 기록, 환경변수, 도메인과 별칭, 깃 저장소 연결, 크론 작업 등입니다. 문제는 안 옮겨지는 쪽입니다. 문서가 명시한 항목 가운데 실무에서 자주 사고가 나는 것만 추리면 이렇습니다. 이전 후 다시 붙여야 하는 것 - 통합(Integrations) → 연결이 끊긴다. 수동으로 다시 추가 - vercel.json 의 env / build.env → 환경변수로 옮겨두지 않으면 사라진다 - Blob 저장소, Global Config → 별도 이전 절차가 따로 있다 - 로그·모니터링 데이터 → 넘어가지 않는다 (사용량도 초기화) 도메인은 규칙이 조금 다릅니다. example.com 처럼 루트 주소를 쓰고 있으면 도메인 자체가 받는 팀으로 넘어갑니다. 그런데 blog.example.com 같은 하위 주소만 쓰고 있었다면, 그 하위 주소는 위임되지만 루트 도메인은 원래 계정에 그대로 남습니다. 문서는 이 경우 원래 계정이 계속 소유자로서 요금을 부담한다고 적고 있습니다. 하위 도메인으로 서비스하던 사이트를 넘겼는데 몇 달 뒤 제작자 카드에서 도메인 값이 계속 빠져나가는 상황이 여기서 나옵니다. 4. 셋째 — 데이터베이스 (Supabase 기준) 회원과 주문이 들어 있는 곳입니다. 네 군데 중 가장 늦게 손대되, 가장 꼼꼼히 확인해야 합니다. Supabase는 조직 단위로 프로젝트를 옮깁니다. 조건은 두 줄로 정리됩니다. “You need to be the owner of the source organization.” 그리고 받는 쪽 조직에 대해서는 “You need to be at least a member of the target organization you want to move the project to.” 보내는 조직에서는 소유자, 받는 조직에서는 최소한 구성원이어야 한다는 뜻입니다. 요금은 시점으로 나뉩니다. 문서는 보내는 조직이 “the source organization will still be charged for the usage up until the transfer” 라고, 즉 이전 시점까지의 사용량을 부담한다고 밝힙니다. 그 이후분은 받는 조직 청구서에 잡힙니다. 정산을 깔끔하게 끊고 싶다면 결제 주기가 바뀌는 날짜 근처를 피하는 편이 설명하기 쉽습니다. 중단 시간도 조건부로 생깁니다. “Transferring a project might come with a short 1-2 minute downtime if you're moving a project from a paid to a Free Plan.” 유료에서 무료 요금제로 내려가는 경우 1–2분 정도 멈출 수 있다는 안내입니다. 제작자가 유료로 쓰던 프로젝트를 고객의 무료 조직으로 넘기는 상황이 정확히 여기에 해당하니, 고객에게 미리 말해두면 됩니다. 넘어가지 않는 항목도 확인해야 합니다. 문서는 이전을 시작하기 전에 GitHub 연동 연결이 없어야 하고, 프로젝트 범위 역할과 로그 드레인 설정도 없어야 한다고 요구합니다. 연동을 잠시 끊고 옮긴 뒤 다시 붙이는 순서가 됩니다. 받는 조직의 요금제가 낮으면 쓰던 기능이 사라지거나 권한이 좁아질 수 있다는 경고도 함께 실려 있습니다. 5. 넷째 — 도메인, 그리고 순서를 마지막에 두는 이유 주소를 파는 회사의 계정이 진짜 소유권입니다. 그리고 이건 맨 나중에 옮기는 게 안전합니다. 빌더에서 연결해 둔 커스텀 도메인은 ‘연결’일 뿐입니다. 실제 권리는 등록업체 계정에 있고, 그 계정 안의 등록자 정보가 누구 이름인지가 전부입니다. 국내 등록업체를 쓴다면 등록자 정보 변경 또는 기관이전 절차를 밟게 되고, 해외 업체를 쓴다면 계정 간 이동 기능을 씁니다. 등록 직후나 정보 변경 직후에는 이전이 일정 기간 막히는 정책이 있는 곳이 많으니, 일정이 촉박하면 등록업체 정책을 먼저 확인하고 역산 하십시오. 구체적인 대기 기간은 업체마다 달라 여기서 숫자로 적지 않습니다. 순서를 마지막에 두는 이유는 단순합니다. 도메인이 새 계정으로 넘어가면 네임서버나 연결 설정을 다시 잡아야 할 수 있는데, 이때 빌더와 배포가 이미 고객 계정에 있어야 고객이 직접 확인하고 고칠 수 있습니다. 반대로 주소부터 넘겨놓고 나머지를 옮기면, 화면이 안 뜨는 상태에서 양쪽이 서로 다른 계정을 들여다보며 원인을 찾게 됩니다. 권장하는 차례는 이렇습니다. ① 고객 계정 만들고 각 서비스에 정식 구성원으로 초대 → 수락 확인 ② 빌더 프로젝트 소유권 이전 ③ 배포 프로젝트 이전 → 끊어진 통합·환경변수 다시 연결 ④ 데이터베이스 이전 → 연동 재연결, 백업 한 번 ⑤ 도메인 등록업체 계정 이전 → 주소로 접속해 눈으로 확인 ⑥ 결제·메일·외부 API 키 전부 재발급하고 옛 키 폐기 6. 가장 자주 빠뜨리는 것 — 키를 새로 발급하지 않는다 계정을 전부 옮겨도 키가 그대로면 인계가 끝난 게 아닙니다. 결제사 시크릿 키, 메일 발송 키, 외부 API 키는 계정 소유자가 바뀐다고 자동으로 바뀌지 않습니다. 제작 과정에서 그 값이 어디를 거쳐 갔는지 생각해 보면 이유가 분명해집니다. 채팅 기록에도, 예전 저장소에도, 로컬 파일에도 남아 있을 수 있습니다. 넘긴 뒤에는 고객 계정에서 새로 발급하고 옛 키는 폐기하는 것이 맞습니다. 특히 결제 키는 자리를 잘못 잡으면 재발급으로도 못 막습니다. 승인 호출이 브라우저 코드에 들어 있으면 새 키를 넣어도 다시 노출될 뿐입니다. 이 구조를 서버 쪽으로 옮기는 방법은 Lovable에 토스페이먼츠 붙이기 — 시크릿 키를 프론트에 두지 않는 법 에 따로 정리해 두었습니다. 인계 전에 이 점검을 한 번 하고 넘기시길 권합니다. 7. 넘길 때 같이 주는 종이 한 장 계정 이전이 끝나면, 고객이 6개월 뒤에 열어볼 문서가 하나 필요합니다. 인계 사고의 상당수는 권한이 아니라 기억에서 납니다. 어느 회사 계정으로 무엇이 돌아가는지, 요금이 어디서 빠지는지, 무언가 고장 났을 때 어디부터 보는지를 고객이 모르는 상태로 남습니다. 한 장이면 충분하니 아래 항목만 채워 함께 넘기십시오. 사용 중인 서비스 이름과 각각의 로그인 계정, 요금제와 결제 수단, 도메인 만료일, 데이터 백업을 받는 방법, 그리고 ‘이건 건드리지 마세요’에 해당하는 설정 두어 개. 여기에 이전 완료 날짜를 적어 두면 나중에 요금 정산을 두고 이야기할 때 기준이 됩니다. 문서를 만들지 않으면 반년 뒤 제작자에게 전화가 오고, 그때는 이미 계정이 없어 확인해 줄 수도 없습니다. § 이 글의 근거 소유권 이전 경로와 협업자 제외 조건, 코드 귀속, 저장소 내보내기 문구는 Lovable 공식 문서 에서 확인했습니다. 배포 이전의 무중단 여부, 10초–10분 소요, 함께 옮겨지는 항목과 옮겨지지 않는 항목, 하위 도메인 위임 규칙은 Vercel 프로젝트 이전 문서 에서 가져왔습니다. 조직 소유자 권한 조건, 청구 시점 분리, 1–2분 중단 조건, 사전에 해제해야 하는 연동 목록은 Supabase 프로젝트 이전 문서 가 원문입니다. 확인하지 못해 뺀 것도 밝혀둡니다. 도메인 등록업체별 이전 제한 기간, 국내 등록업체의 등록자 정보 변경 수수료, 그리고 v0·Bolt 등 다른 빌더의 소유권 이전 메뉴 위치는 이번 조사에서 원문으로 못 박지 못해 숫자와 단정적 표현을 넣지 않았습니다. 화면 구성과 메뉴 이름은 서비스 업데이트로 바뀔 수 있으니 실제 작업 전에 각 공식 문서를 한 번 더 확인하시기 바랍니다. 다른 글은 블로그 목록 에, 문의는 SLOHERO 홈 에서 받습니다. Sun, 30 Aug 2026 00:00:00 +0900 https://slohero.com/blog/ai-website-client-handoff https://slohero.com/blog/ai-builder-business-info-footer 1. 왜 AI 빌더에서만 이 일이 생기나 국내 호스팅형 서비스는 법정 표시 항목을 채우는 자리를 미리 만들어 둡니다. 코드로 만들어진 사이트에는 그 자리가 없습니다. 아임웹이나 카페24로 쇼핑몰을 열어 본 분이라면 관리자 화면 어딘가에서 상호와 사업자등록번호를 입력한 기억이 있을 겁니다. 값을 넣으면 모든 페이지 아래쪽에 자동으로 붙습니다. 국내 서비스가 국내 규제를 전제로 만들어졌기 때문에 가능한 편의입니다. AI 빌더는 사정이 다릅니다. 대부분 해외에서 만들어진 코드 생성 도구고, 결과물은 그냥 리액트 컴포넌트입니다. 푸터도 ‘법정 표시 영역’이 아니라 디자이너가 그린 장식에 가깝습니다. 채팅으로 “멋진 홈페이지 만들어줘”라고만 했다면 아래쪽에는 회사 슬로건과 소셜 아이콘 몇 개가 들어가 있을 것이고, 상호도 신고번호도 그 어디에도 없습니다. 빠뜨린 게 아니라 애초에 물어보지 않았던 것입니다. 그래서 이 작업은 ‘설정 채우기’가 아니라 ‘없는 것을 만들어 넣기’입니다. 순서를 알고 하면 30분이면 끝나지만, 순서를 모르면 무엇을 넣어야 하는지부터 막힙니다. 2. 첫 단계 — 신고번호가 필요한 사업자인지부터 신고번호를 넣는 방법을 찾기 전에, 신고 대상인지를 먼저 확인하는 편이 빠릅니다. 면제 기준이 있습니다. 정부가 운영하는 소비자24의 상담 사례는 통신판매업 신고 면제 기준을 이렇게 안내합니다. “직전연도 통신판매 거래횟수 50회 미만” 이거나 “「부가가치세법」상 간이과세자인 사업자” 라는 두 갈래이고, 근거는 법 제12조제1항 단서 규정이며 구체적인 내용은 「통신판매업 신고면제 기준에 대한 고시」에 정해져 있다는 설명입니다. 이 기준이 중요한 이유는 AI 빌더 이용자의 상당수가 여기 걸리기 때문입니다. 서비스를 막 시작해 주문이 아직 몇 건 없는 단계이거나, 판매는 거의 없고 소개와 문의 접수가 주된 목적인 사이트라면 상황이 다를 수 있습니다. 반대로 이미 거래가 활발한데 신고를 안 한 상태라면 사이트에 번호를 적는 문제가 아니라 신고 자체를 먼저 해야 합니다. 다만 ‘50회’를 어떻게 세는지, 두 요건의 관계를 실제 사례에 어떻게 적용하는지는 개별 판단이 필요한 영역입니다. 여기서 단정적으로 답하지 않겠습니다. 신고와 면제 여부는 정부24 통신판매업신고 안내 와 관할 시·군·구청, 또는 공정거래위원회에 확인하시는 편이 확실합니다. 3. 무엇을 표시하나 — 목록은 원문에서 확인하십시오 여기서는 항목을 단정해 나열하지 않습니다. 이번 조사에서 조문 전문을 직접 열지 못했기 때문입니다. 사이버몰 운영자의 표시 의무는 전자상거래 등에서의 소비자보호에 관한 법률에 정해져 있고, 국가법령정보센터에서 확인한 현행 법률의 시행일은 2026년 7월 21일 입니다. 그런데 해당 페이지는 조문 본문을 자바스크립트로 그려 넣는 구조여서, 이번 확인 과정에서는 제목과 시행일 같은 정보만 읽히고 조문 텍스트가 나오지 않았습니다. 원문 대조에 실패했다는 뜻입니다. 그래서 ‘몇 조 몇 호에 무엇이 적혀 있다’는 식의 서술은 이 글에 넣지 않았습니다. 대신 이렇게 하시길 권합니다. 국가법령정보센터의 해당 법률 을 브라우저에서 직접 열어 사이버몰 운영자의 표시 의무 조항을 그대로 읽고, 거기 적힌 항목을 하나씩 옮겨 적으십시오. 남의 사이트 푸터를 베끼는 방식은 권하지 않습니다. 업종과 판매 형태에 따라 필요한 항목이 다를 수 있고, 베낀 쪽이 이미 낡았을 수 있습니다. 번호를 표시하는 경우에는 소비자가 그 번호를 확인할 수 있는 경로도 함께 두는 것이 일반적인 실무입니다. 공정거래위원회는 통신판매사업자 조회 화면을 운영하고 있으니, 푸터에서 이곳으로 가는 링크를 함께 걸어 두면 됩니다. 4. 어디에 넣나 — 한 페이지가 아니라 공통 푸터 별도 ‘회사소개’ 페이지 안쪽에만 적어 두는 구성은 피하는 편이 좋습니다. 표시 의무는 소비자가 쉽게 볼 수 있는 자리를 전제로 합니다. AI 빌더로 만든 사이트는 페이지가 여러 개인 경우가 많고, 방문자가 첫 화면이 아닌 어느 페이지로도 바로 들어올 수 있습니다. 그러니 특정 페이지 하나에만 적어 두면 그 페이지를 거치지 않은 방문자에게는 없는 것과 같습니다. 실무적으로는 공통 푸터 컴포넌트를 하나 만들어 모든 화면에 붙이는 방식이 가장 단순합니다. 리액트 기반 결과물이라면 레이아웃 파일 한 곳만 고치면 전체에 반영됩니다. 빌더에 요청할 때도 ‘푸터에 넣어줘’가 아니라 ‘공통 레이아웃의 푸터 컴포넌트에 넣어서 모든 페이지에 나오게 해줘’라고 말해야 한 페이지에만 들어가는 일을 막을 수 있습니다. 5. AI 빌더 특유의 함정 — 화면엔 보이는데 소스엔 없다 가장 놓치기 쉬운 자리입니다. 브라우저에는 멀쩡히 뜨는데 HTML에는 그 글자가 없는 상태가 실제로 생깁니다. 이게 왜 생기는지는 오늘 이 글을 쓰면서 겪은 일이 그대로 예시가 됩니다. 법령 조문을 확인하려고 국가법령정보센터 페이지를 프로그램으로 열었더니, 사람이 브라우저로 보면 조문이 잘 나오는 그 페이지에서 조문 본문이 한 글자도 잡히지 않았습니다. 화면을 자바스크립트가 나중에 그려 넣기 때문입니다. 사람 눈에 보이는 것과 기계가 받아 가는 것이 다를 수 있다는 걸 보여주는 사례입니다. AI 빌더 결과물은 대개 이 구조입니다. 첫 응답으로는 거의 빈 껍데기를 보내고 스크립트가 화면을 채웁니다. 푸터에 넣은 사업자 정보도 마찬가지라, 검색엔진이나 각종 수집 도구가 그 내용을 못 읽는 상태가 될 수 있습니다. 표시했다고 생각했는데 확인하는 쪽에서는 안 보이는 셈입니다. 확인은 어렵지 않습니다. 브라우저에서 개발자도구가 아니라 ‘페이지 소스 보기’ 를 열고 상호나 번호를 검색해 보십시오. 개발자도구는 스크립트가 다 돈 뒤의 결과를 보여주기 때문에 이 점검에는 맞지 않습니다. 명령줄이 편하다면 아래 한 줄로도 됩니다. # 첫 응답 HTML 안에 상호가 들어 있는지만 본다 curl -s https://내사이트주소/ | grep -c "주식회사무엇" # 0 이 나오면 → 화면에만 있고 HTML 에는 없다는 뜻 0이 나왔다면 고치는 방향은 두 가지입니다. 서버에서 미리 그려 보내도록 바꾸거나(빌더에 따라 설정 하나로 되는 경우가 있습니다), 그게 어렵다면 푸터 내용을 스크립트가 만드는 부분이 아니라 문서에 고정된 텍스트로 두는 것입니다. 어느 쪽이든 ‘소스에 글자가 있는가’를 기준으로 다시 확인하면 됩니다. 이 점검은 사업자 정보에만 해당하는 게 아닙니다. 영업시간, 가격, 예약 안내처럼 손님이 확인하고 움직이는 정보 가 소스에 없으면 같은 문제가 생깁니다. 손님을 대신해 사이트에 들어오는 AI가 늘면서 이 자리가 실제 문의 수에 영향을 주기 시작했는데, 그 이야기는 GPT-6 아스트라가 예약을 대신한다 — 예약받는 사이트가 확인할 것 에 따로 정리했습니다. 6. 빌더에 넣는 요청과 점검 목록 채팅으로 시킬 때는 위치와 렌더링 방식을 문장에 같이 넣어야 합니다. 값 자체는 각자 다르니 자리만 잡아 두고, 실제 내용은 법령 원문을 보고 채우십시오. 요청 문장은 이런 모양이 됩니다. 공통 레이아웃의 푸터 컴포넌트에 사업자 정보 영역을 추가해줘. - 모든 페이지에 나와야 한다 (특정 페이지 전용 아님) - 값은 하드코딩된 텍스트로 넣어라. 조건부 렌더링이나 API 호출로 나중에 채우지 마 - 공정위 통신판매사업자 조회로 가는 링크를 함께 넣어라 - 글자 크기는 작아도 되지만 배경과 충분히 대비되게 넣을 항목과 값은 내가 아래에 준다: (법령 원문에서 확인한 항목을 여기에 붙여넣기) ‘하드코딩된 텍스트로’와 ‘나중에 채우지 마’를 명시하는 이유가 앞 절에서 본 문제입니다. 이 말이 없으면 도구가 상태값이나 설정 파일에서 끌어오는 구조로 만들 때가 있고, 그러면 첫 응답 HTML에 글자가 안 실립니다. 마무리 점검은 네 줄이면 충분합니다. 첫째, 모든 페이지 아래쪽에 같은 내용이 나오는가. 둘째, 소스 보기에서 상호와 번호가 검색되는가. 셋째, 조회 링크가 실제로 열리는가. 넷째, 글자색이 배경에 묻혀 안 보이지는 않는가. 마지막 항목은 사소해 보이지만, 디자인을 예쁘게 뽑는 도구일수록 푸터 글자를 배경과 비슷한 회색으로 깔아 두는 일이 흔합니다. 7. 사이트를 넘기거나 넘겨받을 때 사업자 정보는 사이트가 아니라 사업자에 붙는 값입니다. 주인이 바뀌면 같이 바뀌어야 합니다. 제작을 맡겼다가 넘겨받은 사이트라면 푸터에 제작사 정보가 그대로 남아 있는 경우가 있습니다. 반대로 제작자 입장에서는, 넘긴 사이트에 자기 상호와 번호가 계속 붙어 있는 상태를 방치하면 곤란해집니다. 인계 시점에 푸터를 함께 점검 목록에 넣어 두십시오. 계정과 도메인을 옮기는 순서는 AI로 만든 홈페이지 인수인계 — 계정 4개와 따라오지 않는 것들 에 따로 정리해 두었습니다. 사업자 정보 교체는 그 목록의 마지막 칸에 함께 적어 두면 빠뜨리지 않습니다. § 이 글의 근거 통신판매업 신고 면제 기준의 두 갈래와 근거 조항, 고시 존재는 정부가 운영하는 소비자24 상담 사례 에서 확인했습니다. 현행 법률의 시행일 2026년 7월 21일은 국가법령정보센터 해당 법률 페이지에서 확인했습니다. 원문 대조에 실패한 부분을 밝힙니다. 사이버몰 운영자의 표시 항목을 정한 조문은 위 페이지가 자바스크립트로 본문을 그리는 구조여서 이번 조사에서 조문 텍스트를 직접 읽지 못했습니다. 그래서 항목 목록, 조·호 번호, 표시 위치에 관한 법령 문구를 이 글에 옮기지 않았고, 대신 독자가 원문을 직접 열어 확인하도록 링크만 걸었습니다. 국내 서비스형 빌더가 안내하는 하단 필수정보 목록도 대조해 보려 했으나 해당 도움말 페이지가 접근을 막아(403) 확인하지 못했습니다. 신고 여부와 표시 항목은 공정거래위원회 나 관할 시·군·구청에 확인하시기 바랍니다. 이 글은 일반적인 정보 정리이며 법률 자문이 아닙니다. 화면 구성과 메뉴 이름은 각 도구의 업데이트로 바뀔 수 있습니다. 다른 글은 블로그 목록 에, 문의는 SLOHERO 홈 에서 받습니다. Sun, 30 Aug 2026 00:00:00 +0900 https://slohero.com/blog/ai-builder-business-info-footer https://slohero.com/blog/lovable-tosspayments-edge-function 1. 왜 시키는 대로 하면 막히나 러버블은 프런트엔드를 아주 잘 만듭니다. 문제는 카드 승인이 프런트엔드 일이 아니라는 데 있습니다. 토스페이먼츠가 주는 키는 두 종류입니다. 하나는 브라우저에서 결제창을 띄울 때 쓰는 클라이언트 키, 다른 하나는 API를 호출할 때 쓰는 시크릿 키입니다. 개발자센터 문서는 두 번째 키에 대해 이렇게 못 박습니다. “시크릿 키는 외부에 노출되면 안 돼요. GitHub, 클라이언트 코드 등 외부에 보이는 곳에 추가하지 마세요.” 브라우저에서 도는 코드는 전부 ‘클라이언트 코드’입니다. 번들에 넣어도, 환경변수처럼 생긴 이름에 담아도, 개발자도구에서 그대로 읽힙니다. 러버블이 만들어준 파일 안에 test_sk_ 나 live_sk_ 로 시작하는 문자열이 보인다면 그 지점에서 멈춰야 합니다. 러버블 잘못이라기보다, 요청을 "결제 붙여줘" 한 줄로 던졌을 때 도구가 가장 짧은 길을 고른 결과에 가깝습니다. 2. 흐름을 셋으로 쪼개면 경계가 보인다 토스페이먼츠 문서는 한 건의 거래를 요청 → 인증 → 승인 세 단계로 설명합니다. 앞의 둘은 브라우저, 마지막 하나는 서버 몫입니다. 구매자가 버튼을 누르면 SDK가 창을 띄웁니다(요청). 카드사 화면에서 본인 확인이 끝나면 정해둔 성공 주소로 돌아옵니다(인증). 여기까지는 아직 돈이 움직이지 않았습니다. 마지막 단계에서 서버가 승인 API를 불러야 비로소 “구매자의 카드 한도 또는 은행 계좌에서 차감”됩니다. 이 호출을 빠뜨리면 화면상으로는 성공처럼 보이는데 정산에는 아무것도 잡히지 않습니다. 그러니까 러버블에게 맡길 것과 옮겨야 할 것의 선은 여기입니다. 창을 띄우는 코드는 브라우저에 두고, 마지막 한 번의 호출만 밖으로 빼면 됩니다. 3. 키를 둘 자리 — Edge Function 시크릿 러버블은 이미 이 문제의 해법을 갖고 있습니다. Supabase Edge Function입니다. 러버블 공식 문서는 민감한 자격증명을 이렇게 다룬다고 적고 있습니다. “Secrets are stored in your Supabase project, where your edge functions can read them; they never appear in your app’s code or repository.” 프로젝트에 보관되고 함수만 읽어가며, 앱 코드나 저장소에는 나타나지 않는다는 뜻입니다. 문서가 예로 드는 용도 자체가 “프런트엔드 코드에 노출할 수 없는 자격증명을 쓰는 모든 작업”입니다. 실무 순서는 단순합니다. 개발자센터에서 발급받은 시크릿 키를 Supabase 프로젝트의 시크릿으로 등록하고, 러버블 채팅에는 이렇게 요청하십시오. confirm-payment 이라는 Edge Function을 만들어줘. - paymentKey, orderId, amount 를 받는다 - 시크릿은 TOSS_SECRET_KEY 로 읽는다 (프런트엔드에 넣지 마) - 승인 결과를 payments 테이블에 저장한다 프런트엔드에는 클라이언트 키만 남기고, 성공 페이지에서 이 함수를 호출해줘. ‘프런트엔드에 넣지 마’를 문장에 직접 넣는 것이 생각보다 크게 작동합니다. 이 말이 없으면 도구는 다시 짧은 길로 갑니다. 4. 승인 호출 — 콜론 하나로 막히는 자리 엔드포인트는 POST /v1/payments/confirm 이고, 필수 파라미터는 paymentKey · orderId · amount 세 개입니다. 인증에서 대부분 한 번은 걸립니다. 시크릿 키를 그냥 base64로 바꾸면 실패합니다. 키 뒤에 콜론( : )을 붙인 다음 인코딩해야 합니다. 문서에도 “잘못된 요청입니다. : 를 포함해 인코딩해주세요”라는 안내가 그대로 실려 있습니다. 함수 안쪽은 대략 이런 모양이 됩니다. const secret = Deno.env.get("TOSS_SECRET_KEY"); const auth = btoa(secret + ":"); // ← 콜론을 빼면 인증 실패 const res = await fetch( "https://api.tosspayments.com/v1/payments/confirm", { method: "POST", headers: { "Authorization": "Basic " + auth, "Content-Type": "application/json", }, body: JSON.stringify({ paymentKey, orderId, amount }), } ); const data = await res.json(); if (!res.ok) { // 승인 실패. data.code / data.message 를 그대로 남겨둘 것 return new Response(JSON.stringify(data), { status: res.status }); } 실패 응답을 삼키지 마십시오. 나중에 원인을 찾을 단서가 code 와 message 뿐인 경우가 많습니다. 5. 금액 대조 — 빠뜨리기 쉬운 한 줄 성공 주소로 돌아온 금액을 그대로 믿고 승인하면 안 됩니다. 주소창에 실려 오는 값은 브라우저를 거쳐 온 값입니다. 토스페이먼츠 문서가 검증을 권하는 이유도 여기 있습니다. “클라이언트에서 결제 금액을 조작해 승인하는 행위를 방지할 수 있어요.” 요청을 만들 때 orderId 와 금액을 데이터베이스에 먼저 적어두고, 승인 직전에 대조하십시오. const { data: order } = await supabase .from("orders").select("amount").eq("id", orderId).single(); if (!order || order.amount !== amount) { return new Response("amount mismatch", { status: 400 }); } // 여기를 통과한 뒤에만 승인 API 를 부른다 쿠폰이나 적립금을 쓰는 화면이라면 이 대조가 특히 중요합니다. 할인 계산을 브라우저에서만 하고 있으면 값이 얼마든지 바뀔 수 있기 때문입니다. 6. 자주 나는 오류 두 가지 키를 섞어 쓴 경우와, 함수 주소를 잘못 부른 경우가 대부분입니다. INVALID_API_KEY — 테스트 키는 test 로 시작합니다. 문서는 “세트가 아닌 키를 사용하거나 테스트 또는 라이브 키를 섞어 사용하면 INVALID_API_KEY 오류가 발생”한다고 밝힙니다. 브라우저에는 테스트 클라이언트 키를 넣고 함수에는 라이브 시크릿 키를 넣어둔 상태, 실서비스 전환 중에 흔히 생깁니다. 두 자리를 같은 세트로 맞추십시오. 승인이 아예 안 도는 경우 — 성공 페이지가 함수를 호출하지 않고 그냥 ‘주문이 완료되었습니다’만 띄우는 화면일 때입니다. 러버블이 만든 성공 페이지에 승인 호출이 실제로 들어 있는지 확인하고, 테스트 환경에서 한 건 통과시킨 뒤 상점 관리자 화면에 그 건이 잡히는지 눈으로 보십시오. 화면의 문구가 아니라 관리자 화면의 목록이 기준입니다. 7. 러버블 Cloud를 쓸 때와 자체 Supabase를 쓸 때 지금 당장은 차이가 없지만, 넘겨줄 사이트라면 자체 프로젝트를 권합니다. 러버블 문서는 둘을 이렇게 구분합니다. Cloud는 “Automatic, no extra account”로 별도 계정 없이 바로 쓰고 비용은 러버블 크레딧으로 나갑니다. 자체 Supabase는 계정과 프로젝트가 필요하고 요금도 Supabase에서 따로 청구됩니다. 결제 코드 자체는 어느 쪽이든 같습니다. 다만 실제 카드 거래가 오가는 사이트라면, 관리 화면과 로그를 직접 여는 쪽이 편합니다. 승인 실패가 났을 때 함수 로그를 바로 볼 수 있어야 하고, 나중에 사이트를 다른 사람에게 넘길 때도 계정 소유가 명확해야 합니다. 이 인수인계 문제는 따로 다룰 만한 주제라, 블로그 목록 에 이어지는 글을 올려두겠습니다. § 이 글의 근거 승인 엔드포인트와 필수 파라미터 세 개, 시크릿 키 노출 금지 문구, 콜론을 포함한 base64 인코딩, 테스트 키 접두어와 INVALID_API_KEY 조건, 요청·인증·승인 3단계와 금액 위변조 방지 안내는 모두 토스페이먼츠 개발자센터 원문에서 확인했습니다 — 코어 API , API 키 , 결제 흐름 이해하기 . 시크릿 보관 방식과 Cloud·자체 프로젝트 비교는 Lovable 공식 문서 에서 가져왔습니다. 본문에 넣지 않은 것도 밝혀둡니다. v2 SDK의 npm 패키지 이름, 테스트용 클라이언트 키 값, 멱등키 헤더의 정확한 이름, 인증 후 승인까지의 제한 시간은 이번 확인 과정에서 원문으로 못 박지 못해 문장째 뺐습니다. 그 네 가지는 연동 전에 개발자센터에서 직접 확인하시기 바랍니다. 코드는 설명을 위한 최소 형태이며, 실제 적용 시에는 오류 처리와 중복 호출 방지를 더해야 합니다. 문의는 SLOHERO 홈 에서 받습니다. Fri, 28 Aug 2026 00:00:00 +0900 https://slohero.com/blog/lovable-tosspayments-edge-function https://slohero.com/blog/vibe-coding-interactive-web ↑ 이 글에서 만드는 결과물입니다. 드래그해서 돌려보세요. 전체 화면으로 보기 ↗ 1. 무엇을 만들었나 카드 45장이 지구본처럼 구를 이루고 천천히 돈다. 그러다 카드 하나를 향해 화면이 쑥 들어가 1초쯤 머물고, 다시 물러나 전체 구를 보여준다. 마우스로 드래그하면 손으로 굴릴 수 있고, 카드를 클릭하면 확대, 한 번 더 클릭하면 원래 크기로 돌아온다. 말로 쓰면 복잡한데 구성은 이게 전부다. orbit.html — 962줄. HTML·CSS·JS·셰이더가 전부 여기 있다 images/ — card-01.jpg ~ card-20.jpg 빌드 도구 없음. npm install 없음. 파일을 브라우저로 열면 바로 돈다. 2. 왜 이게 따라 할 만한 작업인가 인터랙티브 웹사이트라고 하면 보통 웹팩 설정, React, 상태관리, 셰이더 공부 6개월을 떠올린다. 실제로는 막히는 지점이 딱 3개 였고 나머지는 AI에게 시키면 됐다. 바이브코딩이 실패하는 경우는 대부분 이 3개를 모르는 채로 "멋있게 만들어줘"라고 하기 때문이다. 카드를 구 표면에 어떻게 배치하지? 선택한 카드가 정면에 오게 하려면 몇 도를 돌려야 하지? 확대했을 때 왜 화면이 뿌옇게 뭉개지지? 이 3개만 이해하면 나머지는 "이렇게 해줘"로 끝난다. 하나씩 보자. 3. 이미지부터 — 나노바나나는 프롬프트를 JSON으로 쓴다 먼저 이미지가 있어야 한다. 카드는 45장이지만 이미지는 20장이면 충분하다. 중요한 건 20장이 따로 노는 게 아니라 한 세트로 보이는 것 이다. 그래서 프롬프트를 문장이 아니라 JSON으로 썼다. { "style": "editorial studio photograph, soft diffused light", "background": "seamless warm grey #dedede, no gradient", "subject": "a single ceramic vase, centered", "framing": "subject fills 66% of frame height", "aspect_ratio": "4:3", "negative": "text, watermark, harsh shadow, busy background" } style , background , framing , aspect_ratio 는 20장 전부 고정하고 subject 만 바꾼다. 이렇게 하면 매번 다른 톤으로 뽑히는 사고가 안 난다. 꼭 지킬 것 하나. aspect_ratio 를 격자 칸 비율과 똑같이 맞춰라. 나는 1.27:1을 썼다. 이 기준이 틀리면 카드마다 이미지가 잘려 지저분해진다. 피사체가 프레임에서 차지하는 비율(66%)까지 고정한 이유도 같다. 어떤 건 크고 어떤 건 작으면 구가 울퉁불퉁해 보인다. 4. 문제 1 — 카드를 구 표면에 배치하기 가장 많이 헤맨 부분이다. 원통, 바퀴, 나선까지 네 번을 다시 만들었다. 정답은 지구본의 위도·경도 격자 였고, 핵심은 한 줄이다. 적도에서 멀어질수록 열 개수를 cos(위도) 만큼 줄인다. for (let r = 0; r < ROWS; r++) { const lat = -Math.PI/2 + (Math.PI/ROWS) * (r + 0.5); const cols = Math.max(MIN_COLS, Math.round(COLS_EQ * Math.cos(lat))); // ↑ 이 cos 하나가 전부다 for (let c = 0; c < cols; c++) { const lon = (Math.PI*2/cols) * c + (r % 2) * (Math.PI/cols); // 벽돌쌓기 const cl = Math.cos(lat), sl = Math.sin(lat); cells.push({ dir: new THREE.Vector3(Math.cos(lon)*cl, sl, Math.sin(lon)*cl) }); } } 이걸 빼면 극지방에서 카드들이 서로를 뚫고 겹친다. cos 을 넣는 순간 위로 갈수록 자연스럽게 줄어든다. 위도 띠 7줄, 적도 11열로 시작해 총 45장 이 나왔다. 여기에 두 가지를 더했다. 빈칸 14% — 일부러 자리를 비운다. 그 틈으로 반대편 카드가 비쳐 보이면서 "속이 빈 껍질"이라는 게 드러난다. 꽉 채우면 그냥 공이다. 홀수 줄 반 칸 밀기 — 벽돌 쌓듯 어긋나게 해서 세로줄이 눈에 띄지 않게 한다. 이미지 20장으로 45장을 채우는 방법도 여기서 나온다. i % 20 을 쓰면 같은 세로줄에 같은 이미지가 반복돼 티가 확 난다. 황금비를 쓰면 흩어진다. const IMG_IDX = i => Math.floor(((i * 0.6180339887498949) % 1) * 20); // ↑ 황금비. 규칙적으로 보이지 않게 퍼뜨린다 5. 문제 2 — 선택한 카드를 정면으로 가져오기 카드 위치 벡터만 알면 삼각함수 두 줄이다. const d = card.position.clone().normalize(); const spinY = Math.atan2(-d.x, d.z); // 좌우로 몇 도 const tiltX = Math.atan2(d.y, Math.hypot(d.x, d.z)); // 위아래로 몇 도 여기서 한 번 크게 깨졌다. 회전과 기울기를 같은 오브젝트에 넣었더니 카드가 엉뚱한 데로 갔다. 3D 회전은 순서가 바뀌면 결과가 달라지기 때문이다(오일러 각). 그룹을 세 겹으로 쪼개니 해결됐다. roll(Z축) > tilt(X축) > ring(Y축) > 카드들 각 그룹이 축 하나씩만 담당하면 순서가 꼬일 일이 없다. 이런 건 AI에게 "회전이 이상해"라고만 하면 못 고친다. "오일러 순서 때문인 것 같으니 그룹을 축별로 분리해줘" 라고 해야 한 번에 된다. 바이브코딩이 잘 먹히는 조건이 이것이다 — 증상이 아니라 원인을 말할 것. 그리고 카메라가 카드까지 날아가는 대신 카드를 앞으로 끌어내고 1.12배 키웠다. 카메라만 들이대면 화면이 카드로 꽉 차서(94%) 답답하다. 원본 영상은 63%였고, 카드를 끌어내는 방식이 이 여백을 살린다. 6. 문제 3 — 확대하면 왜 뿌옇게 뭉개지나 거리에 따라 흐리게 만드는 코드를 넣었더니 카메라가 구 안쪽 으로 들어갔을 때 전부 뭉개졌다. 안쪽에서는 카드가 가까운데도 "멀다"고 계산된 것이다. 한 줄로 끝났다. t *= (1 - inside01 * 0.88); // 구 안에 있으면 흐리게 할 이유가 없다 블러 자체도 후처리 없이 간다. 밉맵 레벨만 낮춰서 읽으면 공짜다. vec4 c = texture2D(uMap, uv, dim * uBlur); // 세 번째 인자가 밉 바이어스 포스트프로세싱을 붙였으면 코드가 세 배로 늘고 모바일에서 버벅였을 것이다. 7. 남은 잔버그 3개 — 여러분도 똑같이 만난다 완성 후에도 잔버그 3개가 남는다 — 모바일 터치 관성, 다크모드 전환 시 잔상, 첫 로딩 흰 화면 . 셋 다 원인이 같고(상태 초기화 누락) 아래 코드로 해결된다. 뒷면 이미지가 좌우 반전 → 셰이더에서 gl_FrontFacing 으로 UV를 뒤집는다 60fps에선 0.6초, 15fps에선 2.4초 → 매 프레임 일정 비율로 보간(lerp)하면 이렇게 된다. performance.now() 기준 실제 경과 시간으로 바꿔야 한다 각도가 계속 커져서 이상해짐 → 삼각함수에 넣기 전에 ((v % m) + m) % m 으로 감싼다 8. 타이밍은 감이 아니라 숫자로 맞췄다 "영상처럼 자연스럽게"는 AI에게 시켜도 안 된다. 원본 영상을 ffmpeg으로 프레임 단위로 뜯어 재봤다. 구간 원본 영상 내 결과 한 바퀴 주기 3.42~3.72초 3.64초 확대 상태 유지 1.88초 1.83초 축소 상태 유지 1.40초 1.64초 전환 0.35초 0.42초 이 숫자를 그대로 상수로 박았다. const TOUR = { OUT_HOLD: 1820, IN_HOLD: 880, FLY_IN: 420, FLY_OUT: 420, FLY_BACK: 540 }; 이 방법을 추천한다. 참고 영상이 있다면 ffmpeg -i ref.mp4 -vf fps=10 f%03d.png 으로 프레임을 뽑고, 어느 프레임에서 멈추고 어느 프레임에서 움직이는지 세보라. 30분이면 된다. "느낌"으로 열 번 고치는 것보다 빠르다. 9. 정리 — 순서대로만 하면 된다 순서만 지키면 된다 — 이미지(JSON 프롬프트) → 뼈대(three.js 6단계) → 인터랙션 → 잔버그 수리 . 코딩 지식보다 "무엇을 요청할지"가 결과를 가른다. 나노바나나로 이미지 20장. 스타일·배경·비율은 JSON으로 고정, subject 만 교체 격자 좌표 만들기. cos(위도) 로 열 줄이기 + 빈칸 14% 카드 배치. mesh.lookAt(pos.clone().multiplyScalar(2)) — PlaneGeometry는 +Z가 정면이라 이 한 줄로 끝난다 클릭 시 정면 정렬. atan2 두 줄 + 그룹 3단 분리 타이밍 상수 박기. 참고 영상에서 실측 잔버그 3종 처리. 뒷면 UV / 실시간 트윈 / 각도 래핑 총 962줄, 파일 하나다. 나는 구조를 네 번 갈아엎었는데 위 순서대로 가면 그럴 일이 없다. 바이브코딩으로 인터랙티브 웹을 만들 때 진짜 실력은 코드를 쓰는 게 아니라 어디서 막힐지 미리 아는 것 이다. 이 글의 4~7번이 그 목록이다. 그대로 들고 시작하면 된다. § 자주 묻는 질문 Q. three.js를 몰라도 되나요? Scene , Camera , Mesh 세 단어의 뜻만 알면 됩니다. 나머지는 위 6단계를 그대로 요청하면 나옵니다. 정확히 말하면 three.js를 배우는 게 아니라 무엇을 요청해야 하는지 를 배우는 겁니다. 바이브코딩의 실제 학습 곡선은 여기에 있습니다. Q. 이미지가 20장보다 적으면요? 됩니다. IMG_COUNT 만 바꾸면 됩니다. 다만 10장 밑으로 내려가면 황금비로 흩어도 반복이 눈에 띕니다. Q. 모바일에서 돌아가나요? 돕니다. 포스트프로세싱을 안 썼기 때문입니다. 대신 카드 45장 × 텍스처 20장이라 이미지는 가로 1100px 정도로 줄여서 넣으세요. Q. 라이선스는요? three.js는 MIT입니다. 이미지는 나노바나나로 직접 생성한 것이니 문제없습니다. Wed, 19 Aug 2026 00:00:00 +0900 https://slohero.com/blog/vibe-coding-interactive-web