회사 웹사이트의 기준 다섯 가지: 무엇으로 만들었는지보다 먼저 볼 것

회사 웹사이트가 있느냐고 물으면 대부분 있다고 답합니다. 그런데 그 주소로 지난달에 문의가 몇 건 들어왔는지 물으면 답이 갈립니다. 한쪽은 숫자를 말하고, 한쪽은 "요즘은 거의 없죠"라고 답합니다.

같은 "있다"가 아닙니다. 흔히 회사 웹사이트를 있나 없나로 봅니다. 그러면 만들어 두었는데 아무 일도 일어나지 않는 사이트가 설명되지 않습니다. 웹사이트는 있고 없고의 문제가 아니라, 다섯 가지를 하느냐 못 하느냐의 문제입니다. 그리고 그 다섯 가지 중 어디에도 무엇으로 만들었는지는 들어가지 않습니다.

명함에 적을 수 없는 주소

blog.naver.com/회사이름 은 주소가 아니라 세입자 호수입니다. 명함에 적을 수는 있습니다. 건물이 헐리면 같이 없어질 뿐입니다.

실제로 헐린 적이 있습니다. 네이버가 소상공인용으로 10년 가까이 운영한 모두(modoo!)는 2025년 1월 16일에 신규 등록을 막고 그해 6월 26일에 문을 닫았습니다. 공지가 다섯 달 전에 나왔으니 준비할 시간이 없었던 것은 아닙니다. 문제는 준비해도 가져갈 수 없는 것이 있다는 쪽입니다. 원고와 이미지는 백업으로 받아 나올 수 있지만, 그동안 쌓인 주소는 못 가져옵니다. 그 주소를 명함에, 전단지에, 간판에, 거래처 메일 서명에 적어 두었다면 그것들이 전부 한꺼번에 죽습니다.

자체 도메인은 이 문제를 통째로 없앱니다. 도메인이 회사 것이면 그 뒤에 무엇이 붙어 있든 갈아 끼울 수 있습니다. 워드프레스로 시작해서 맞춤 개발로 옮겨도 주소는 그대로고, 검색 엔진이 알고 있는 것도 그대로입니다. 저는 이 항목이 다섯 중 가장 싸면서 가장 늦게 준비되는 항목이라고 봅니다. 사이트를 다 만들고 나서 도메인을 붙이려다 이미 쌓인 것을 못 옮기는 순서로 자주 어긋납니다.

회사 이름으로 검색했을 때 나오지 않는 사이트

지금 네이버와 구글 양쪽에 회사 이름을 쳐 보십시오. 첫 화면에 우리 사이트가 없다면 아래 세 기준은 아직 볼 필요가 없습니다. 아무도 도착하지 못하는 곳을 고치는 일이기 때문입니다.

두 엔진이 같은 방식으로 동작하지 않는다는 점이 국내에서 특히 중요합니다. 구글은 링크를 따라다니며 알아서 찾아가는 쪽에 가깝고, 네이버는 서치어드바이저에 사이트를 등록하고 소유 확인을 거쳐 사이트맵과 robots.txt 를 제출하는 절차가 있습니다. 이 절차를 아무도 밟지 않은 사이트는 존재하지만 네이버에는 없는 것과 같습니다. 국내 중소기업이나 지역 업체를 상대한다면 이쪽이 더 큰 문이라 이 차이가 그대로 문의 수로 나타납니다.

여기서부터는 사이트마다 다릅니다. 등록하고 며칠 만에 잡히기도 하고 몇 주가 걸리기도 하며, 무엇이 그 차이를 만드는지 저도 확신이 없습니다. 확실한 것은 등록하지 않으면 시작조차 안 된다는 부분입니다.

보낸 문의와 도착한 문의의 차이

문의 폼이 화면에 있는 것과, 그 문의가 누군가의 휴대폰을 울리는 것은 다른 일입니다.

끊기는 자리는 대개 셋 중 하나입니다. 폼 제출이 데이터베이스에 저장만 되고 알림을 보내는 부분이 아예 없거나, 알림 메일이 스팸함으로 들어가고 있거나, 받도록 되어 있는 주소의 담당자가 이미 회사에 없습니다. 셋 다 화면에서는 멀쩡해 보입니다. 방문자 쪽에도 "문의가 접수되었습니다"가 정상적으로 뜹니다.

저는 이 항목이 다섯 중 가장 조용히 깨진다고 봅니다. 깨져도 아무도 항의하지 않기 때문입니다. 문의를 보낸 사람은 답이 없으면 다른 곳을 찾아가지 두 번 보내지 않고, 회사 쪽에서는 문의가 안 들어온 것과 구분이 안 됩니다. 그래서 이건 만들어 놓고 믿을 항목이 아니라 주기적으로 직접 한 건 넣어 보고 확인할 항목입니다.

광고를 켜는 순간 필요해지는 것

광고는 돈을 쓰는 쪽이 아니라 무엇이 먹혔는지 아는 쪽에서 갈립니다.

전화로 "어떻게 알고 연락 주셨어요"라고 묻는 방법이 있긴 합니다. 문제는 답하는 사람이 대개 정확히 기억하지 못한다는 점입니다. 네이버에서 검색했다고 말하지만 그전에 인스타그램에서 한 번 보고 이름을 기억한 것일 수도 있습니다. 광고를 두 개 이상 돌리는 순간 이 방식으로는 어느 쪽을 끄고 어느 쪽에 더 넣을지 정할 수 없습니다.

필요한 것은 문의 한 건마다 출처가 붙어서 들어오는 구조입니다. 링크에 붙은 파라미터를 문의 기록에 같이 저장하는 정도로 시작할 수 있고, 광고 채널이 요구하는 전환 추적을 붙이면 광고 관리 화면에서 바로 보입니다.

이 항목에는 순서가 있습니다. 만들 때 같이 해 두면 추가 비용이 거의 없는데, 나중에 붙이면 붙인 날부터의 데이터만 생깁니다. 지난 6개월간 어느 채널이 문의를 만들었는지는 소급해서 알아낼 방법이 없습니다.

CMS 가 존재하는 단 하나의 이유

CMS 를 기능 목록으로 설명하면 끝이 없습니다. 존재 이유는 하나입니다. 개발자를 부르지 않고 글자를 바꾸기 위해서입니다.

이게 왜 영업에 직결되는지는 오래된 회사 사이트를 몇 개만 열어 보면 보입니다. 가격표가 2년 전 것이고, 대표 인사말에 재작년 목표가 적혀 있고, 채용 공고가 이미 끝난 자리입니다. 담당자가 게을러서가 아닙니다. 한 줄을 고치려면 사람을 부르고 견적을 받고 일정을 잡아야 하는 구조라면, 그 한 줄은 안 고쳐집니다. 고칠 수 없는 사이트는 시간이 지날수록 회사를 잘못 소개하게 됩니다.

대신 내주는 것이 있습니다. 워드프레스처럼 직접 설치해 쓰는 CMS 는 코어와 테마와 플러그인을 계속 업데이트해야 하고, 그 관리가 멈추면 보안 문제로 돌아옵니다. 빌더형 서비스는 그 관리를 대신해 주는 대신 정해진 구조 밖으로 나가기 어렵습니다. 어느 쪽을 택할지는 회사 홈페이지 제작 도구 비교에서 도구별로 따로 다뤘습니다.

무료 도구가 다섯 중 둘에서 걸리는 자리

구글 사이트나 노션, 네이버 블로그로 회사 소개를 대신하는 경우는 흔합니다. 만들기 쉽고 돈이 안 들고, 무엇보다 오늘 안에 끝납니다.

다섯 기준을 대 보면 셋은 통과합니다. 걸리는 것은 언제나 첫째와 둘째입니다.

	무료 도구	내 도메인 위의 모든 방식 (빌더·CMS·맞춤 개발)
내 주소	어렵다	된다
네이버·구글 노출	막힌다	된다
문의 도착	된다	된다
유입 측정	제한적	된다
직접 수정	된다	된다 (관리자 화면을 범위에 넣었을 때)

이 표에서 읽어야 할 것은 무료 도구의 점수가 아니라, 오른쪽 열이 한 칸으로 묶인다는 사실입니다. 다섯 기준은 빌더와 맞춤 개발을 가르지 못합니다. 가르는 것은 돈을 내느냐가 아니라 내 도메인 위에 서 있느냐입니다.

막히는 이유도 같은 데서 옵니다. 첫째 기준은 그 도구가 자체 도메인 연결을 허용하느냐에 달려 있고, 둘째 기준은 소유 확인 파일이나 robots.txt, 사이트맵처럼 검색 엔진이 요구하는 것들을 내가 손댈 수 있게 해 주느냐에 달려 있습니다. 도구마다 다르고 정책도 바뀌므로 여기서 목록을 만들지는 않겠습니다. 쓰기로 정하기 전에 그 둘이 되는지만 직접 확인해 보는 편이 확실합니다.

그러니 무료 도구가 나쁜 도구라는 말은 아닙니다. W3Techs 집계로 구글 사이트는 전체 웹사이트의 0.2% 가량인데, 쓰이는 곳을 보면 교육 기관과 사내 페이지에 몰려 있습니다. 사내 위키, 팀이 같이 보는 자료, 행사 안내처럼 첫째와 둘째 기준이 애초에 필요 없는 자리에서는 훌륭한 선택입니다. 고객이 검색해서 찾아와야 하는 회사의 공식 얼굴이 그 자리가 아닐 뿐입니다.

다섯을 만족시키는 길이 여럿인 이유

다섯 가지 어디에도 무엇으로 만들어라는 말이 없습니다. 그게 이 글의 요점입니다.

빌더도, 설치형 CMS 도, 맞춤 개발도 다섯을 전부 넘습니다. 넘는 방식과 드는 비용이 다를 뿐입니다. 그래서 "CMS 와 맞춤 개발 중 어느 쪽이 나으냐"는 다섯 기준으로는 답이 안 나오고, 답을 내려면 여섯 번째 질문이 필요합니다. 플랫폼이 정해 준 구조 밖에 있는 업무가 있는가. 견적 승인 단계, 고객마다 다른 화면, 재고 배정, 역할이 여러 개인 권한 같은 것들입니다.

이게 없으면 맞춤 개발은 돈을 더 쓰는 선택입니다. 회사 소개와 서비스 설명과 사례와 문의가 전부라면 빌더 쪽이 빠르고 운영도 쉽습니다. 반대로 이게 있으면 빌더는 그 지점에서 멈추고, 우회하려고 붙인 것들이 나중에 더 비싸집니다.

여기서 자연스럽게 나오는 반문이 있습니다. 관리자 화면을 붙인 맞춤 개발이면 CMS 가 하는 일을 다 하면서 그 위에 업무까지 얹으니, 결국 더 나은 것 아니냐는 질문입니다. 할 수 있는 일만 놓고 보면 맞습니다. 빌더가 하는데 맞춤 개발이 못 하는 일은 없습니다.

갈리는 곳은 할 수 있느냐가 아니라, 그 관리자 화면이 견적서의 한 줄인지 제품인지입니다. 설치형 CMS 나 빌더의 관리자 화면에는 에디터와 이미지 처리, 미리보기, 수정 이력, 권한 분리, 예약 발행, 폼과 스팸 처리가 이미 들어 있습니다. 오랫동안 수많은 사이트가 쓰면서 다듬어진 결과입니다. 맞춤으로 만드는 관리자 화면은 첫날에 그중 몇 개를 갖고 시작하고, 나머지는 필요해질 때마다 하나씩 값을 치릅니다. 견적서의 "관리자 화면 포함"이 어디까지를 뜻하는지 착수 전에 맞춰 두어야 하는 이유입니다.

두 번째는 그 뒤를 누가 따라가느냐입니다. 브라우저가 바뀌고 결제 모듈이 바뀌고 동의 문구가 바뀝니다. 빌더는 플랫폼이 따라가고, 맞춤 개발은 따라갈 사람이 계약으로 붙어 있어야 합니다. 저는 이 지점이 맞춤 개발에서 가장 흔한 실패라고 봅니다. 직접 고치려고 만든 사이트가 고칠 사람이 없어져서, 빌더로 만든 사이트보다 오히려 더 못 고치는 상태가 됩니다.

그래서 웹사이트를 새로 만들지 말지부터 물을 일이 아닙니다. 지금 있는 것이 다섯 중 몇 개를 하고 있는지 세어 보는 쪽이 먼저고, 대개 다섯 개 전부를 새로 만들어야 하는 경우는 생각보다 적습니다.