사이트에 붙은 부품은,
전부 관리할 일로 돌아옵니다

결론부터 말씀드리면 — 사이트를 무엇 위에 만들지는 기술 취향이 아니라 그 사이트가 실제로 할 일로 정해야 합니다. 쓰지 않는 기능도 일단 붙으면 부품이 되고, 부품은 업데이트와 보안과 비용으로 사이트가 떠 있는 내내 돌아옵니다. 설명하고, 믿게 하고, 문의를 받는 사이트라면 대개 그보다 훨씬 적은 부품으로 충분합니다.

기능이 많은 견적이 든든해 보이는 이유

견적을 받다 보면 기능 목록이 길수록 안심이 됩니다. 게시판, 회원가입, 관리자 페이지, 공지사항, 검색. 지금 당장은 안 쓰더라도 "나중에 필요할지 모르니" 넣어 두자는 말에는 반대할 이유가 잘 보이지 않습니다. 비슷한 금액이라면 더 많이 들어 있는 쪽이 이득처럼 보이기도 합니다.

그런데 견적서에 한 줄로 적힌 기능은 사이트 안에서 한 줄로 끝나지 않습니다. 게시판은 글을 저장할 데이터베이스가 되고, 관리자 페이지는 누구나 주소를 알면 두드릴 수 있는 로그인 화면이 되고, 기능 하나를 쉽게 붙이려고 깐 플러그인은 그 플러그인을 만든 사람의 업데이트 일정에 사이트를 묶어 둡니다. 방문자가 올 때마다 그 자리에서 페이지를 조립하는 서버도 그중 하나입니다.

신규 브랜드의 첫 사이트에서 이 차이가 크게 갈리는 건, 이 부품들을 돌볼 사람이 대개 따로 없기 때문입니다. 대표님이 직접 하거나, 제작 업체가 하거나, 아무도 하지 않습니다. 그리고 세 번째 경우가 가장 조용하게 일어납니다.

부품마다 따라오는 것

부품이 늘면 관리 목록이 늘어납니다. 플러그인과 프로그램은 업데이트가 나오고, 업데이트를 미루면 이미 알려진 약점이 열린 채로 남습니다. 업데이트를 하면 이번에는 다른 부품과 맞지 않아 화면 한쪽이 깨지기도 합니다. 서버와 데이터베이스는 호스팅 비용과 백업이 필요하고, 멈추는 지점이 하나씩 늘어납니다.

이 일들은 계약서에서 잘 보이지 않습니다. 제작비는 한 번 청구되지만 관리는 매달, 혹은 문제가 생길 때마다 청구됩니다. 관리 계약이 끝나는 순간 그 목록을 누가 넘겨받는지는 납품 뒤에 멈춘 사이트는 고장 난 게 아니다에 정리해 뒀는데, 부품이 적으면 넘겨받을 목록 자체가 짧아집니다.

비교·검증 중인 방문자에게는 이 관리 공백이 그대로 보입니다. 브라우저의 보안 경고, 깨진 레이아웃, 마지막 글이 오래전에 멈춘 공지사항 게시판. 처음 본 이름을 확인하러 온 사람에게 이런 화면은 "이 회사는 지금 운영되고 있는가"라는 질문으로 읽힙니다. 쓰지 않는 게시판이 어떻게 신호가 되는지는 홈페이지 속 블로그는 소식란이 아니라 입구에서 다뤘습니다.

미리 완성해 두는 사이트라는 선택지

이 문제를 줄이는 방법 중 하나가 정적 사이트입니다. 이름은 어렵지만 원리는 단순합니다. 방문자가 올 때마다 페이지를 조립하는 대신, 페이지를 미리 완성해 두고 그대로 보내는 방식입니다. 조립할 것이 없으니 응답이 빠르고, 털릴 데이터베이스나 로그인 화면이 없으니 보안 업데이트 목록이 짧고, 호스팅 부담도 작습니다. 이 칼럼이 올라가 있는 밑그림 사이트도 이렇게 만들었습니다.

신규 브랜드나 고단가 전문서비스의 첫 사이트가 하는 일은 대부분 이 방식으로 감당됩니다. 무엇을 하는 곳인지 설명하고, 믿을 근거를 보여 주고, 문의를 받는 일입니다. 문의도 폼 서비스나 메신저 링크처럼 그 일을 전문으로 하는 바깥 서비스에 맡길 수 있습니다. 어떤 채널을 열지는 카톡·전화·폼, 무엇을 열지에 따로 정리했습니다.

다만 이건 기술을 고르는 이야기가 아닙니다. 정적 사이트가 답인 경우가 많을 뿐, 출발점은 사이트가 할 일의 목록입니다.

구조를 고르기 전에, 이 순서로 정합니다

1. 사이트가 할 일을 동사로 적습니다. 설명한다, 증명한다, 문의를 받는다, 예약을 받는다, 결제한다, 회원에게만 보여 준다. 기능 이름이 아니라 동사로 적으면 정말 필요한 일과 있으면 좋을 것 같은 일이 갈립니다. 동사마다 옆에 "지금"인지 "언젠가"인지 적습니다.
2. "언젠가"는 지금 구조에 넣지 않습니다. 대신 그때 붙일 수 있는지만 확인합니다. 아직 회원이 없는데 회원가입을 만들어 두면, 쓰이기 전까지 관리 비용만 먼저 냅니다. 무엇을 첫 화면에 둘지 고르는 기준은 메인에 다 넣으면 아무것도 안 보인다와 같습니다. 빼는 결정이 먼저입니다.
3. 대표님이 직접 고칠 자리를 따로 셉니다. 가격, 사례, 공지처럼 자주 바뀌는 자리가 어디인지, 얼마나 자주 바뀌는지를 적습니다. 그 자리가 몇 곳뿐이라면 사이트 전체를 관리자 페이지 위에 올리지 않고 그 자리만 편집할 수 있게 만드는 방법이 있습니다. 직접 고칠 자리가 필요한 이유는 납품 뒤에 멈춘 사이트에 있습니다.
4. 업체에 부품 목록을 묻습니다. 질문은 세 가지면 됩니다. "이 사이트는 무엇 위에 만들어지나요?", "업데이트가 필요한 부품은 무엇이고 누가 하나요?", "관리 계약이 끝나면 그 일은 어떻게 되나요?" 답이 기술 이름으로만 돌아온다면, 그 기술이 대표님 쪽에 무슨 일을 남기는지로 다시 물어봅니다.
5. 옮길 수 있는지 확인합니다. 원고와 사진의 원본이 사이트 밖에 따로 있는지, 도메인이 대표님 명의인지 봅니다. 부품이 특정 플랫폼에 묶여 있으면 나중에 구조를 바꿀 때 같은 내용을 다시 옮겨 담아야 합니다. 그 비용은 템플릿으로 시작할 때 나중에 청구되는 비용에 썼습니다.

서버가 필요한 사이트도 있습니다

모든 사이트를 정적으로 만들라는 뜻은 아닙니다. 회원만 볼 수 있는 자료, 사이트 안에서 일어나는 결제, 여러 직원이 매일 올리는 글, 실시간으로 바뀌는 예약 현황처럼 방문자마다 다른 화면을 보여 줘야 하는 일은 서버가 필요합니다. 그때도 사이트 전체를 그 구조로 바꾸기보다, 그 일을 전문으로 하는 서비스에 맡기고 연결하는 방법을 먼저 검토할 만합니다. 판매가 중심이라면 그 판단은 쇼핑몰로 끝나는 구매와 끝나지 않는 구매로 이어집니다.

반대쪽 실수도 있습니다. 정적 사이트를 골랐다고 저절로 빨라지지는 않습니다. 큰 사진을 원본 그대로 올리고, 외부 도구를 이것저것 붙이고, 첫 화면에 무거운 연출을 얹으면 부품이 다른 자리에서 다시 늘어납니다. 그 점검은 사이트가 느릴 때 먼저 잃는 건 처음 온 사람과 모션이 방해가 되는 건 양이 아니라 자리에 있습니다. 업체를 고를 때도 기준은 쓰는 기술의 이름이 아니라 남는 관리 목록이 얼마나 짧은가입니다.

지금 사이트로 확인해 보세요

제작 전이라면 견적서를 옆에 두고, 이미 운영 중이라면 지금 사이트를 열고 답해 보세요.

• 사이트가 할 일을 동사로 다섯 줄 안에 적을 수 있는가?
• 사이트에 붙은 기능 중 지난 몇 달간 한 번도 쓰지 않은 것이 있는가?
• 업데이트가 필요한 부품의 목록과 각각의 담당자를 말할 수 있는가?
• 관리자 로그인 화면이 있다면, 그 화면이 꼭 필요한 이유를 한 줄로 쓸 수 있는가?
• 관리 계약이 끝나도 사이트가 그대로 떠 있고 옮길 수 있는가?

두 번째 줄에 "있다"고 답하셨다면, 그 기능은 지금 일은 하지 않고 관리 목록에만 올라가 있는 부품입니다. 지울 수 있는지부터 업체에 물어보세요.