맞춤형 홈페이지와 템플릿, 어떤 기준으로 선택할까요?

홈페이지를 새로 맡기려 할 때 가장 먼저 갈리는 질문은 보통 이것입니다. 맞춤형으로 갈까요, 아니면 이미 있는 템플릿을 쓸까요. 화면이 예쁜지보다 먼저 볼 것은, 그 사이트를 누가 운영하고 어떤 정보가 오가야 하는지입니다.

맞춤형과 템플릿은 취향이 아니라 운영 조건입니다

템플릿은 이미 정해진 페이지 뼈대와 편집 화면을 기준으로 글을 넣는 방식입니다. 회사 소개, 서비스 안내, 문의하기처럼 흔한 구성이면 이 뼈대가 잘 맞습니다. 맞춤형은 그 반대에 가깝습니다. 서비스 분류, 문의가 도착하는 경로, 담당자별 수정 범위가 일반 테마의 메뉴와 어긋날 때 구조를 다시 짜는 쪽에 해당합니다.

우리만의 느낌만으로 맞춤형을 고르면 이후 운영에서 빈칸이 생깁니다. 반대로 일단 띄우자는 이유로만 템플릿을 고르면, 필수 페이지를 억지로 끼워 넣거나 테마 파일을 직접 고치게 됩니다. 선택은 미감이 아니라 운영 조건을 적는 일부터입니다. 담당자 사이에서도 맞춤형은 자유롭게 고치는 일, 템플릿은 빨리 여는 일로 받아들여지기 쉬운데, 둘 다 이후 권한과 업데이트 책임을 설명하지는 않습니다.

선택 전에 종이에 적을 네 가지

제작 방식을 고르기 전에 아래를 문장으로 적어 두면, 이후 논의가 화면 취향으로 흘러가지 않습니다.

• 글을 올리고 고치는 사람이 누구인지, 그 사람이 쓸 수 있는 편집 화면은 어느 수준인지
• 꼭 있어야 하는 페이지와, 방문자가 문의하는 경로가 한곳으로 모이는지
• 로고, 소개 문구, 사진처럼 기존 자료가 어디에 있고 쓸 권한이 있는지
• 도메인, 호스팅, CMS 접속 권한을 누가 갖고, 업데이트는 누가 보는지

이 네 가지가 비어 있으면 맞춤형과 템플릿 모두 범위가 흔들립니다. 권한과 자료 위치는 디자인 시안보다 먼저 확인하는 편이 안전합니다. 담당자가 여러 명이면 누가 최종 문구를 확정하는지도 같이 적어 두면 이후 수정 요청이 겹치지 않습니다.

템플릿이 잘 맞는 경우

페이지 종류가 이미 분명하고, 담당자가 테마가 제공하는 편집기 안에서 글을 유지할 수 있으면 템플릿이 실무에 잘 맞습니다. 소개, 서비스, 소식, 문의처럼 흔한 흐름이면 뼈대를 새로 그릴 이유가 크지 않습니다.

업데이트와 직접 수정

템플릿을 고른 뒤에도 운영 책임은 남습니다. 워드프레스 공식 문서는 CMS 업데이트가 한 번으로 끝나지 않는 일이며, 파일을 직접 수정하면 그 내용이 업데이트 과정에서 덮일 수 있다고 설명합니다. 테마나 확장 기능을 고쳐서 원하는 화면을 맞추는 방식은, 당장은 편해 보여도 이후 업데이트 때마다 같은 수정을 반복하게 됩니다.

템플릿을 쓰기로 했다면 직접 수정 범위를 최소로 두고, 제공된 설정과 콘텐츠 입력으로 해결 가능한지부터 보는 것이 좋습니다. 예외가 많아질수록 템플릿이 주는 유지의 단순함이 사라집니다. 소식이 자주 바뀌는 사이트라면, 편집기가 그 빈도를 감당할 수 있는지도 같이 보면 됩니다.

맞춤형을 검토해야 하는 경우

서비스 이름과 분류가 일반 테마의 게시 유형과 맞지 않거나, 문의가 여러 갈래로 나뉘어 담당자에게 다르게 전달되어야 하면 맞춤형 구조를 검토할 이유가 생깁니다. 이때 먼저 볼 것은 시각 장식이 아니라 정보가 놓이는 자리입니다.

상담 신청과 자료 요청이 서로 다른 담당에게 가야 하는데 문의 서식이 하나뿐이라면, 항목만 늘려서는 운영이 정리되지 않습니다. 메뉴가 깊거나, 공개하면 안 되는 내부 메모가 있거나, 페이지마다 보여 줄 자료가 다른 경우도 같은 이유로 구조가 필요합니다.

맞춤형은 무엇이든 가능하다는 뜻이 아닙니다. 오히려 처음에 페이지 목록과 권한 범위를 더 구체적으로 고정해야 이후 손볼 일이 줄어듭니다. 범위가 적히지 않은 맞춤형은 템플릿보다 운영이 더 어려워질 수 있습니다. 누가 초안을 쓰는지와 누가 공개를 허락하는지를 나누어 두는 것도 이 단계에서 정합니다. 공개 전에 문구를 누가 보는지가 비어 있으면, 구조가 새로워도 같은 문장이 여러 버전으로 남습니다.

접근성과 성능은 제작 방식과 별개로 점검합니다

맞춤형이라고 접근성이 저절로 좋아지지 않고, 템플릿이라고 성능이 저절로 안정되지도 않습니다. WCAG 2.2는 접근성 기준이 특정 기술에 묶이지 않으며 테스트할 수 있어야 한다고 둡니다. 키보드만으로 이동할 수 있는지, 링크와 버튼의 이름이 분명한지, 색 대비가 읽기에 충분한지는 제작 방식과 무관하게 확인 대상입니다.

성능도 같습니다. MDN은 웹 성능이 전달되는 자원의 양과 그 자원을 처리하는 방식에 달려 있다고 설명합니다. 이미지가 크고 스크립트가 많으면 맞춤형도 무거워지고, 템플릿도 필요한 자원만 남기면 가벼워질 수 있습니다. 우리만 만든 사이트니까 빠를 것이라는 말은 근거가 되지 않습니다.

움직임보다 정보 흐름

화면 전환과 움직임을 먼저 정하면 자원이 늘어나기 쉽습니다. 정보 구조와 문의 경로가 고정된 뒤에 필요한 연출만 더하는 편이 점검하기 수월합니다. 움직임이 없어도 읽히고 문의가 도착하는지를 먼저 보면, 이후 연출은 범위를 정해 추가할 수 있습니다.

Studio OD에 문의하기 전에 정리할 메모

Studio OD 공개 사이트에서는 작업 범위와 문의 경로를 확인할 수 있습니다. 첫 메시지를 보내기 전에 위에서 적은 네 가지를 짧은 메모로 붙여 두면, 맞춤형인지 템플릿인지부터 이야기하지 않아도 됩니다. 대화는 페이지 목록, 수정 권한, 업데이트 담당처럼 확인 가능한 항목부터 시작하는 편이 분명합니다.

확인되지 않은 효과, 순위, 금액은 고르는 기준이 되지 않습니다. 지금 단계에서 필요한 것은 사이트가 어떤 정보를 담아야 하고, 그 정보를 누가 유지할 수 있는지입니다. 그 답이 먼저 있으면 제작 방식은 따라옵니다.