개발 제안서나 견적서를 처음 받으면 익숙하지 않은 단어가 한꺼번에 등장합니다. 반응형, CMS, 테스트 환경, API, 리다이렉트처럼 평소에는 쓸 일이 많지 않은 말들입니다.
뜻을 물어보면 대부분 어렵지 않은 내용입니다. 그런데 상담 자리에서는 모르는 단어가 계속 나오고, 하나씩 질문하기도 조심스러워집니다. 결국 금액과 제작 기간만 비교하고 나머지는 업체의 설명에 맡기게 되는 경우가 있었습니다.
저희도 사이트를 의뢰하는 분들과 이야기하면서 같은 질문을 여러 번 받았습니다. 설명하다 보니 기술 용어의 정확한 정의보다 더 궁금한 것은 따로 있었습니다.
“이게 있으면 무엇이 달라지나요?”
“이번 견적에는 어디까지 들어 있나요?”
“사이트를 공개한 뒤에도 필요한가요?”
그래서 자주 등장하는 말을 실제 운영의 관점에서 다시 정리해 봤습니다.
반응형 — 같은 내용을 화면 크기에 맞게 보여 주는 일
반응형 사이트는 휴대전화, 태블릿, 컴퓨터에서 같은 내용을 각 화면에 맞게 보여 줍니다. 단순히 화면의 폭을 줄이는 것과는 조금 다릅니다. 작은 화면에서는 메뉴의 모양이 바뀌고, 나란히 있던 내용이 위아래로 놓이며, 손가락으로 누르기 편하도록 버튼의 크기도 달라집니다.
요즘 제작되는 사이트에서는 기본에 가까운 항목입니다. 다만 “모바일에서도 열립니다”와 “모바일 이용 흐름까지 확인했습니다”는 범위가 다를 수 있습니다. 문의나 예약이 중요한 사이트라면 작은 화면에서 입력과 제출까지 실제로 확인했는지가 더 의미 있었습니다.
시안 — 완성 전에 합의하는 화면의 기준
시안은 색, 글자, 이미지와 배치를 미리 확인하는 화면입니다. 완성된 사이트와 똑같이 움직이지는 않지만, 서로 생각하는 결과가 같은지 확인하는 데 사용합니다.
견적에서는 시안의 개수와 수정 범위가 차이를 만들었습니다. 첫 화면만 시안으로 확인하고 나머지는 같은 기준으로 제작하는 경우도 있고, 주요 화면을 각각 확인하는 경우도 있습니다. 수정 횟수만 보는 것보다 어느 단계에서 무엇을 확인하는지가 실제 진행에 더 영향을 줬습니다.
접근성 — 더 많은 사람이 같은 기능을 이용할 수 있게 하는 일
접근성은 글자 크기와 색의 차이를 충분히 두고, 이미지를 보지 못할 때 설명을 제공하고, 마우스 없이도 화면을 이용할 수 있게 만드는 일입니다.
특정한 사람만을 위한 부가 기능으로 생각하기 쉽지만, 햇빛 아래에서 휴대전화를 보거나 일시적으로 손을 쓰기 어려운 상황에도 도움이 됩니다. 공공기관과 관련된 서비스나 이용자의 연령대가 넓은 사이트에서는 어느 수준까지 적용하고 확인할지 처음부터 범위에 담기는 경우가 많았습니다.
CMS — 개발자 없이 내용을 관리하는 화면
CMS는 글, 이미지, 공지사항 같은 콘텐츠를 운영자가 직접 올리고 수정하는 관리 기능입니다. 인사이트나 사례처럼 계속 늘어나는 내용이 있다면 운영 과정에서 자주 사용하게 됩니다.
CMS가 있다는 말만으로 실제 사용 범위를 알기는 어렵습니다. 제목과 본문만 바꿀 수 있는지, 검색 결과에 표시될 설명과 대표 이미지도 관리할 수 있는지, 발행 전 미리보기가 있는지에 따라 운영 방식이 달라집니다.
사이트를 공개한 뒤 자주 바뀌는 내용을 먼저 떠올려 보면 CMS의 범위를 정하기 쉬웠습니다. 거의 바뀌지 않는 회사 소개까지 복잡한 관리 기능으로 만들 필요는 없지만, 매주 올라오는 글을 수정할 때마다 개발자를 기다리는 구조도 오래 쓰기 어려웠습니다.
관리자 화면 — 운영에 필요한 정보를 확인하는 곳
관리자 화면은 문의, 신청, 회원이나 콘텐츠처럼 운영에 필요한 정보를 확인하는 공간입니다. 같은 이름을 사용해도 들어 있는 기능은 크게 다를 수 있습니다.
문의 목록만 보는 화면이 필요한 경우도 있고, 담당자를 지정하거나 상태를 바꾸고 자료를 내려받는 기능까지 필요한 경우도 있습니다. 고객 정보를 다룬다면 누가 어떤 정보까지 볼 수 있는지도 함께 정해야 했습니다.
운영자가 실제로 하루 동안 하는 일을 기준으로 설명하면 필요한 범위가 비교적 분명해졌습니다. “관리자 페이지 포함”이라는 한 줄보다, 어떤 업무를 그 안에서 처리할 수 있는지가 중요했습니다.
테스트 환경 — 방문자에게 보여 주기 전에 확인하는 공간
개발 제안서에서는 스테이징이라는 말로 자주 등장합니다. 실제 사이트와 비슷한 별도의 공간에서 변경 내용을 먼저 확인하는 방식입니다.
운영 중인 화면을 바로 수정하면 작업 중인 내용이 방문자에게 보일 수 있습니다. 테스트 환경이 있으면 담당자가 새 문구와 기능을 먼저 살펴본 뒤 실제 사이트에 반영할 수 있습니다.
매일 바뀌는 서비스와 한 번 만들고 거의 바뀌지 않는 소개 페이지가 같은 환경을 필요로 하지는 않습니다. 다만 고객 정보가 저장되거나 예약·결제와 연결된 사이트에서는 변경 사항을 공개 전에 확인할 공간이 도움이 됐습니다.
배포 — 작업한 내용을 실제 사이트에 반영하는 일
배포는 개발을 마친 내용을 방문자가 보는 사이트에 반영하는 과정입니다. “작업이 끝났다”와 “실제 사이트에서 볼 수 있다” 사이에 배포 과정이 있습니다.
실제 운영에서는 누가 배포할 수 있는지, 언제 반영하는지, 문제가 생기면 이전 상태로 돌아갈 수 있는지가 함께 중요했습니다. 작은 문구 수정은 바로 반영해도 괜찮지만, 문의나 결제 흐름의 변경은 이용이 적은 시간에 진행하기도 합니다.
도메인과 호스팅 — 주소와 사이트가 머무는 공간
도메인은 사람들이 입력하는 사이트 주소이고, 호스팅은 화면과 기능이 실행되는 공간입니다. 두 항목 모두 정기 비용이 생길 수 있습니다.
운영하면서는 비용보다 명의와 접근 권한이 더 중요하게 느껴졌습니다. 제작사가 관리를 대신하더라도 회사가 소유권과 계정 접근 방법을 알고 있으면 담당 업체가 바뀔 때 이어받기 수월합니다.
누가 결제하고 있는지, 갱신 안내는 어디로 오는지, 계정은 누구 명의인지가 인수 자료에 남아 있으면 몇 년 뒤에도 확인하기 편했습니다.
리다이렉트 — 이전 주소의 방문자를 새 주소로 안내하는 일
사이트를 새로 만들면서 주소 구조가 달라질 수 있습니다. 리다이렉트는 예전 주소로 들어온 사람을 알맞은 새 주소로 자동으로 보내 줍니다.
이 작업이 빠지면 검색 결과나 과거에 공유한 링크를 눌렀을 때 없는 페이지가 나타날 수 있습니다. 새 화면을 만드는 일에 집중하다 보면 놓치기 쉽지만, 기존 사이트에 검색 방문자가 있었다면 공개 전에 함께 정리할 부분이었습니다.
SEO — 검색 엔진이 내용을 이해하도록 준비하는 일
SEO는 검색 결과에 잘 나타날 수 있도록 사이트의 제목, 설명, 주소와 구조를 정리하는 작업입니다. 검색 순위를 약속하는 일과는 다릅니다.
기본 항목이 갖춰졌더라도 콘텐츠와 경쟁 상황에 따라 결과가 나타나는 데 시간이 걸립니다. 제작 범위에서는 각 화면의 제목과 설명을 입력할 수 있는지, 검색 엔진이 읽을 수 있는 구조인지, 새 글이 검색용 목록에 포함되는지 정도를 살펴봤습니다.
“SEO 포함”이라는 표현이 보이면 무엇을 작성해 주는지와 운영자가 나중에 직접 바꿀 수 있는지를 함께 보면 범위를 이해하기 쉬웠습니다.
사이트맵 — 검색 엔진을 위한 주소 목록
사이트맵은 사이트 안에 어떤 페이지가 있는지 검색 엔진에 알려 주는 목록입니다. 방문자가 보는 메뉴와는 역할이 다릅니다.
페이지가 몇 개 없는 소개 사이트에서는 단순한 파일일 수 있습니다. 글이나 사례가 계속 추가되는 사이트라면 새 콘텐츠가 발행될 때 목록도 함께 갱신되는지가 중요했습니다. 처음 한 번 만드는 것과 운영 중 자동으로 유지되는 것은 다른 범위였습니다.
API 연동 — 다른 서비스와 정보를 주고받는 연결
예약, 결제, 문자, 이메일처럼 외부 서비스를 사이트와 연결할 때 API라는 표현이 자주 등장합니다. 사용자가 상담을 신청하면 예약 도구에 일정이 잡히거나 담당자에게 알림이 가는 과정도 이런 연결을 통해 이뤄질 수 있습니다.
연결 기능은 화면만으로 완료 여부를 판단하기 어렵습니다. 외부 서비스의 계정과 비용, 실패했을 때의 처리, 전달되는 정보의 범위도 함께 살펴야 했습니다. 연동 대상이 바뀌거나 이용 정책이 달라질 때 누가 관리하는지도 운영 범위에 영향을 줬습니다.
캐시 — 이미 받은 내용을 잠시 기억하는 방식
캐시는 화면을 더 빨리 보여 주기 위해 한 번 받은 내용을 잠시 보관하는 방식입니다. 덕분에 같은 페이지를 다시 열 때 기다리는 시간이 줄어듭니다.
내용을 수정했는데 바로 보이지 않는 경우에도 캐시가 원인일 수 있습니다. 시간이 지나면 바뀌기도 하고, 별도로 갱신해야 할 수도 있습니다. 운영자가 글을 발행했을 때 언제 방문자 화면에 반영되는지 알 수 있게 해 두면 혼란이 줄었습니다.
백업 — 문제가 생겼을 때 돌아갈 수 있는 자료
백업은 사이트의 파일과 저장된 정보를 별도로 보관하는 일입니다. 중요한 것은 “백업이 있다”는 말보다 얼마나 자주 저장되는지, 얼마나 오래 보관되는지, 실제로 복구할 때 어느 시점으로 돌아갈 수 있는지였습니다.
콘텐츠가 거의 바뀌지 않는 사이트와 매일 신청 정보가 쌓이는 서비스는 필요한 주기가 다릅니다. 고객 정보가 있다면 보관 위치와 접근 권한도 함께 고려해야 했습니다.
용어를 운영 장면으로 바꾸면 견적이 읽혔습니다
개발 용어를 모두 기억할 필요는 없었습니다. 단어를 실제 운영 장면으로 바꾸어 생각하면 견적의 차이가 조금 더 잘 보였습니다.
같은 회사 소개 사이트라도 한 제안에는 화면 제작만 들어 있고, 다른 제안에는 모바일 확인, 관리 기능, 테스트 공간, 이전 주소 정리와 공개 후 지원까지 포함될 수 있습니다. 겉으로 보이는 페이지 수가 같아도 금액이 달라지는 이유였습니다.
제안서를 볼 때는 낯선 용어의 뜻을 아는 것보다 해당 항목으로 무엇을 할 수 있는지, 누가 사용하는지, 공개 후에도 관리되는지를 설명하고 있는지에 눈이 갔습니다. 설명이 구체적이면 포함된 범위와 빠진 범위를 구분하기 쉬웠습니다.
모든 항목을 넣는 것이 좋은 선택은 아니었습니다. 짧게 운영할 안내 페이지라면 복잡한 관리자 기능이 필요하지 않을 수 있습니다. 반대로 문의가 쌓이고 콘텐츠가 계속 바뀌는 사이트라면 처음부터 운영 방식을 생각한 제안이 시간이 지난 뒤 다루기 편했습니다.