Tenlune의 디자인은 이미 정해져 있었습니다. 색은 무채색으로 고정했고, 화면에서 유일하게 색이 나오는 곳은 작업물 이미지뿐입니다. 서체와 간격, 홈 화면의 섹션 순서까지 최종안이 나와 있었습니다.
그런데 그 상태로는 누구에게도 주소를 보낼 수 없었습니다. 헤더의 메뉴는 네 개인데 그중 세 개를 누르면 빈 페이지가 나왔고, 문의를 넣을 곳이 없었으며, 사이트 제목에는 예전 작업 폴더 이름이 그대로 남아 있었습니다. 디자인이 끝났다고 웹사이트가 끝난 것은 아니었습니다. 이 글은 그 간극을 메우는 동안 무엇을 고민하고 다듬었는지에 대한 기록입니다.
‘완성’의 기준을 옮겼다
Tenlune이 만드는 것은 작은 웹사이트와 웹서비스, 그리고 반복 업무를 줄이는 자동화입니다. 규모가 크지 않기 때문에 오히려 “어디까지 하면 끝인가”를 분명히 정해둘 필요가 있었습니다.
기준은 이렇게 잡았습니다. 처음 방문한 사람이 이곳이 무엇을 하는 곳인지 이해하고, 어떤 일을 맡길 수 있는지 확인하고, 문의를 넣고, 실제로 답변을 받는 데까지 이어질 것. 화면이 잘 보이는 것은 그 흐름의 일부일 뿐이고, 한 군데서라도 끊기면 완성이 아니라고 봤습니다.
눈에 잘 보이지 않는 절반
가장 먼저 한 일은 비어 있던 페이지들을 실제 내용으로 채우는 것이었습니다. 서비스 안내, 소개, 문의 페이지가 링크만 있고 실체가 없었습니다. 채우면서 이미 확정된 문구는 그대로 쓰고, 확인되지 않은 경력이나 이력은 지어내지 않았습니다.
개인정보처리방침도 실제로 수집하는 정보에 맞게 다시 정리했고, 잘못 남아 있던 사이트 정보도 바로잡았습니다. 겉으로 잘 드러나지 않지만, 실제 운영을 시작하려면 갖춰져 있어야 하는 부분들이었습니다.
나중에 이어서 관리할 수 있는 구조
사이트를 만든 뒤에도 쉽게 수정하고 이어서 관리할 수 있도록 몇 가지 구조적 원칙을 정했습니다.
색과 서체, 글자 크기, 간격 같은 기준은 한 곳에서만 관리합니다. 나중에 회색 톤 하나를 바꿀 때 여러 군데를 뒤질 일이 없습니다. 여러 페이지에서 똑같이 쓰이는 요소 — 문의 영역, 가격·기간 안내, 섹션 머리말 — 는 복사해 붙이지 않고 공통 요소로 만들어 재사용합니다. 같은 내용이 여러 곳에서 어긋나는 일을 구조로 줄이는 편이 확실합니다.
반대로, 한두 번만 쓰이는 것을 미리 일반화하지는 않았습니다. 지금 필요하지 않은 유연함은 대개 나중에 짐이 됩니다. 작업 사례 데이터는 디자인과 분리해 두었습니다. 언젠가 화면을 손보더라도 그동안 쌓인 기록과 그 구조는 그대로 남아야 하기 때문입니다.
실제 서비스 환경 정리
로컬에서 잘 보이는 것과 실제 서비스 환경에서 안정적으로 동작하는 것은 다른 문제였습니다. 운영 도메인을 정리하고 HTTPS와 이전 주소 연결, 남아 있던 오래된 참조와 캐시까지 점검했습니다. 화면에서는 보이지 않지만, 실제 주소를 고객에게 전달하기 위해 필요한 작업들이었습니다.
덜어내는 것도 작업이다
기능을 추가하는 것만큼 불필요한 것을 덜어내는 데도 신경 썼습니다. 특정 페이지에서만 필요한 스크립트는 그곳에서만 불러오고, 웹폰트 역시 실제 사용하는 범위만 로드해 불필요한 전송량을 줄였습니다.
문의가 도착하기까지
문의를 막는 가장 큰 장벽은 가격이 아니라 불확실성이라고 봤습니다. 보내면 그다음에 무슨 일이 일어나는지 모르면, 사람은 대개 창을 닫습니다.
그래서 문의 영역에 순서를 먼저 적어뒀습니다. 만들고 싶은 것을 적어 보내면 2영업일 안에 가능 여부와 대략적인 범위를 회신하고, 요구사항을 정리한 뒤 일정과 금액을 확정하고 시작합니다. 폼도 나눴습니다. 견적 도구에서 넘어온 예상 구성은 따로 자동으로 채워지고, 하고 싶은 이야기를 적는 칸은 늘 비어 있는 상태로 방문자를 맞습니다. 접수된 문의에서도 이 두 내용이 구분되어 확인되도록 구성했습니다. 혹시 메일 전달에 문제가 생겨도 문의 내용 자체가 사라지지 않도록 별도의 안전장치도 두었습니다.
규칙이 숫자를 정하고, 설명은 그다음이다
서비스 페이지에는 예상 견적을 가늠해보는 작은 도구가 있습니다. 만들고 싶은 것과 필요한 기능, 예산을 고르면 예상 범위와 기간을 보여줍니다.
여기서 지킨 원칙이 하나 있습니다. 가격과 기간 숫자는 오직 규칙이 정합니다. 서비스별 시작가, 기능별 추가 범위, 유형별 불확실성 폭이 한 곳에 정의돼 있고 계산은 그 값만 읽습니다. 예상 견적이 입력한 예산을 넘으면 억지로 금액을 깎지 않고, “지금 진행할 부분”과 “예산이 늘면 추가할 부분”으로 나눠 보여줍니다. 여러 기능을 함께 만들면 겹치는 구현이 줄어드는 조합은, “할인”이 아니라 무엇이 공유되어 작업이 줄어드는지로 설명합니다.
그 위에 AI 설명을 얹었습니다. 다만 AI는 숫자를 만지지 않습니다. 규칙이 이미 확정한 값을 사실로 받아서, 왜 이 구성이 적당한지, 무엇이 공유되어 중복이 줄었는지를 두세 문장으로 풀어 쓰는 것까지만 합니다. 외부 호출이 느리거나 실패하면 설명은 조용히 생략되고, 규칙이 계산한 견적은 그대로 남습니다.
숫자와 설명을 이렇게 갈라둔 이유는 단순합니다. 숫자에는 재현성과 책임이 필요하고, 설명에는 읽기 쉬움이 필요합니다. 둘을 한 덩어리로 맡기면 어느 쪽도 믿기 어려워집니다.
검색에 걸리는 것도 운영의 일부다
검색 노출 역시 사이트를 운영하기 위한 기본 준비라고 생각했습니다.
페이지마다 검색 결과와 링크 공유에서 필요한 제목과 설명, 대표 주소를 정리하고, 검색엔진이 사이트의 구조와 각 페이지의 역할을 이해하기 쉽도록 기본 정보를 갖췄습니다. 검색을 위한 문구를 억지로 반복하기보다, 사람이 읽었을 때 먼저 이해되는 구조를 유지하는 것을 기준으로 삼았습니다.
아직 끝난 제품이라고 말하지 않는다
처음부터 모든 것을 완벽하게 만들어둘 수는 없습니다. 대신 실제 사용을 막는 문제는 바로 고치고, 더 좋아질 수 있는 부분은 기록해두고 하나씩 개선하는 방식을 택했습니다. 사례 글에 처음부터 “개선 기록” 칸을 넣어둔 것도 같은 이유입니다. 나중에 소급해서 지어낼 수 없는 기록이라, 비어 있더라도 자리부터 만들어뒀습니다.
작은 웹사이트를 완성한다는 건 어느 시점에 “끝”이라고 선언하는 일이 아니었습니다. 누군가에게 주소를 건넸을 때 무엇을 하는 곳인지 이해할 수 있고, 필요한 정보를 찾고, 실제 문의까지 이어질 수 있는 상태를 만드는 일이었습니다. 그다음부터는 실제로 사용하면서 더 나은 방향을 찾아가는 일에 가깝습니다.
이 Journal에는 앞으로 Tenlune을 만들고 운영하면서 발견한 문제와 선택, 개선 과정을 계속 기록하려 합니다.