색을 바꿔도 같아 보이던 홈페이지를 고친 방법

01 / DEVELOPMENT NOTES

문제는 색상이 아니라 읽는 순서였습니다

처음 홈페이지는 큰 제목, 넓은 소개 영역, 반복된 카드로 구성했습니다. 색과 문구를 바꿔도 같은 화면처럼 느껴지는 문제가 남았습니다. 실제 서비스보다 “어떤 사람의 공간인가”를 설명하는 문장이 더 먼저, 더 크게 읽혔습니다.

소개 내용도 다시 확인해야 했습니다. 면접 답변 진단 도구를 준비 글처럼 다루거나, AI 홍보 콘텐츠 제작 서비스를 사이드 프로젝트 아카이브로 설명하면 카드가 아무리 깔끔해도 목적지를 잘못 안내합니다.

먼저 서비스의 성격을 확인하고 프로젝트를 글·SNS와 분리했습니다. 현재 홈페이지는 대표 프로젝트 세 개의 이름과 용도를 먼저 보여줍니다. 캐릭터와 소개는 신뢰를 보태되 실제로 써 볼 대상을 가리지 않도록 배치했습니다.

02 / DEVELOPMENT NOTES

그림보다 먼저, 무엇을 하는지

프로젝트 그림은 기능을 짐작하게 해 주지만 그것만으로 용도가 확정되지는 않습니다. 면접 진단 예시, AI 홍보물, CSV 값 비교 앞에 이름과 짧은 목적 설명을 배치했습니다. 코드의 읽기 순서도 시각 순서와 맞췄습니다.

그 다음에는 방문 목적에 따라 이동할 수 있게 했습니다. 프로젝트 바로가기, 글·자료 분류, 검색, 입문 경로, 실험 기록을 연결하되 대표 서비스 카드를 계속 늘리는 방식은 피했습니다. 모든 링크를 똑같이 크게 만드는 대신 어떤 행동을 먼저 할지 정했습니다.

03 / DEVELOPMENT NOTES

정적 홈페이지에 필요한 상태만 두기

HTML·CSS·vanilla JavaScript를 유지했습니다. 링크와 본문은 HTML에 있고 검색·분류·더 보기는 기존 스크립트가 담당합니다. 입문 경로와 템플릿 미리보기는 네이티브 펼침으로 구성해 별도의 앱 상태 없이도 읽을 수 있습니다.

CSV 비교는 합성 상품 코드 하나만 사용하는 설명용 체험입니다. 실제 파일을 받거나 원본을 수정하지 않습니다. 작업 점검 도구도 자동 진단을 붙이는 대신 방문자가 상태를 직접 고르고 기록을 가져가도록 만들었습니다.

점검 상태는 현재 탭의 메모리에만 두고 URL에는 작업 유형만 남겼습니다. 분류한 항목 수를 배포 안전 점수로 부르지 않았습니다. 기능이 많아 보이는 것보다, 실제로 제공하는 범위와 저장하지 않는 것을 분명히 하는 쪽을 선택했습니다.

04 / DEVELOPMENT NOTES

잘 보인다는 판단과, 확인 가능한 검사를 나누기

화면에서는 여러 폭의 가로 넘침과 글자 잘림, 키보드 조작을 확인했습니다. 자동 검사에서는 기존 외부 링크, 프로젝트 수, 검색·URL 복원, 내부 경로와 메타데이터, 다운로드 원문과 미리보기의 일치를 다뤘습니다.

작업 점검 도구의 Blob 생성과 오류 대체 경로는 자동 검사했지만, 당시 인앱 브라우저에서는 실제 파일 저장과 OS 클립보드 전달을 확정하지 못했습니다. 성공 안내만으로 검증 완료라고 하지 않고, API 없이 텍스트를 직접 선택하는 경로를 추가해 실제 화면에서 확인했습니다.

비공개 출처는 공개 원고와 분리하고 Git·웹 배포에서 제외했습니다. 배포 후에는 필요한 페이지의 응답뿐 아니라 내부 문서가 공개되지 않는지도 확인했습니다. 이런 점검도 완전한 보안 감사나 모든 보조기기의 접근성 검증과는 다릅니다.

바뀐 것은 정보 순서와 행동 경로, 실패 시 대안입니다. 클릭률과 전환율의 개선은 별도 관찰이 있어야 합니다. 다음 기능도 공간이 비어 보인다는 이유보다 방문자가 막히는 지점이 확인됐을 때 추가하려고 합니다.