DEV Community: austin

주소모음 서비스를 만들면서 사이트 탐색 UX를 단순화한 방법

austin — Wed, 21 Oct 2026 02:59:52 +0000

주소모음 서비스를 만들면서 사이트 탐색 UX를 단순화한 방법

웹사이트를 만들 때 처음에는 콘텐츠가 많을수록 사용자에게 도움이 될 거라고 생각했습니다.

그래서 다양한 사이트를 한 화면에 최대한 많이 보여주려고 했습니다.

그런데 실제로 운영하면서 반대 문제가 생겼습니다.

사이트가 많아질수록 사용자는 선택하기 어려워졌고, 원하는 사이트를 찾으려면 화면을 계속 내려보거나 여러 페이지를 돌아다녀야 했습니다.

결국 문제는 사이트 개수보다 탐색 구조에 있었습니다.

사이트를 먼저 보여주는 대신 카테고리를 먼저 보여줬습니다

제가 운영하고 있는 프로젝트는 레이더(Radar)입니다.

radarjuso.com은 여러 분야의 웹사이트를 카테고리별로 정리해서 보여주는 주소모음 서비스입니다.

초기에는 사이트 목록 자체를 강조했지만, 운영하면서 사용자가 먼저 원하는 분야를 선택할 수 있도록 구조를 바꿨습니다.

현재 가장 중요하게 보고 있는 탐색 흐름은 단순합니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 선택지 비교 → 필요한 사이트 확인

예를 들어 사용자가 AI 관련 사이트를 찾고 있다면 전체 사이트 목록을 훑는 대신 AI 카테고리부터 들어갈 수 있도록 하는 방식입니다.

카테고리마다 역할을 나눴습니다

카테고리가 늘어나면서 또 다른 문제가 생겼습니다.

서로 다른 페이지들이 비슷한 설명과 키워드를 사용하기 시작했습니다.

그래서 각 페이지의 목적을 다시 정리했습니다.

홈은 서비스 전체를 설명
카테고리는 특정 분야의 사이트를 탐색
상세 페이지는 개별 사이트의 기본 정보를 확인

이렇게 역할을 구분하니 UX뿐 아니라 콘텐츠를 작성할 때도 훨씬 명확해졌습니다.

검색과 탐색을 같은 기능으로 보지 않았습니다

처음에는 검색창만 잘 만들면 사용자가 원하는 사이트를 쉽게 찾을 거라고 생각했습니다.

하지만 검색은 이미 사이트 이름을 알고 있는 사람에게 더 유용했습니다.

반대로 어떤 사이트를 써야 할지 아직 모르는 사람에게는 탐색 기능이 더 중요했습니다.

그래서 Radar에서는 검색뿐 아니라 카테고리를 둘러보면서 새로운 사이트를 발견할 수 있는 구조도 같이 중요하게 보고 있습니다.

사용 목적이 다른 두 사용자를 모두 고려하는 셈입니다.

알고 있는 사이트 찾기 → 검색

새로운 사이트 찾기 → 카테고리 탐색

내부 링크도 사용자 흐름에 맞췄습니다

페이지가 늘어나면서 처음에는 관련 페이지를 최대한 많이 연결했습니다.

하지만 내부 링크가 많아질수록 사용자가 어디로 이동해야 하는지 오히려 모호해졌습니다.

지금은 현재 페이지와 실제로 관련 있는 이동 경로만 남기는 방향으로 조정하고 있습니다.

기본 구조는 다음과 같습니다.

홈 → 카테고리 → 사이트 정보 → 관련 카테고리

SEO를 위해 링크를 추가하는 것보다 실제 사용자가 다음에 어떤 페이지를 필요로 할지를 먼저 생각하게 됐습니다.

주소모음 서비스도 결국 정보 구조 문제였습니다

Radar를 만들면서 가장 크게 바뀐 생각은 이것입니다.

주소모음 사이트라고 해서 링크만 많이 모으면 되는 게 아니었습니다.

사이트가 늘어날수록 더 중요한 것은 분류, 탐색, 비교, 재발견이었습니다.

사용자가 원하는 사이트를 빨리 찾는 것도 중요하지만, 몰랐던 사이트를 발견할 수 있게 만드는 것 역시 디렉터리 서비스의 중요한 역할이라고 생각합니다.

현재 이런 구조를 실제로 적용하면서 계속 테스트하고 있는 프로젝트가 radarjuso.com입니다.

카테고리형 서비스나 디렉터리를 만들고 있다면 사이트 수를 늘리기 전에, 사용자가 어디에서 시작하고 어떤 순서로 원하는 정보까지 이동하는지부터 확인해보는 것이 꽤 도움이 될 수 있습니다.

카테고리 페이지끼리 검색 의도가 겹칠 때 바꾼 것들

austin — Tue, 20 Oct 2026 03:31:05 +0000

카테고리형 사이트를 운영하다 보면 처음에는 페이지를 세분화하는 게 무조건 좋다고 생각하기 쉽습니다.

저도 처음에는 각 주제별로 페이지를 많이 만들고, 중요한 키워드를 여러 페이지에 반복해서 넣으면 검색 노출에 도움이 될 거라고 생각했습니다.

그런데 실제로 운영하면서 문제가 생겼습니다.

서로 다른 페이지가 비슷한 검색어를 사용하기 시작했고, 어떤 페이지가 어떤 검색 의도를 담당하는지 점점 애매해졌습니다.

문제는 페이지 수가 아니라 역할이었습니다

제가 운영하고 있는 레이더(Radar)는 여러 웹사이트를 카테고리별로 정리해서 보여주는 주소모음 서비스입니다.

사이트는 radarjuso.com입니다.

카테고리가 늘어나면서 주소모음, 링크모음, 사이트 추천, 최신주소 같은 표현이 여러 페이지에서 반복되기 시작했습니다.

처음에는 별문제가 없어 보였지만, 시간이 지나면서 각 페이지가 서로 다른 역할을 갖고 있는지 다시 보게 됐습니다.

예를 들어 모든 페이지가 비슷한 키워드를 사용하면 검색엔진 입장에서는 어떤 페이지가 더 적합한 결과인지 구분하기 어려울 수 있습니다.

그래서 페이지 역할을 다시 나눴습니다.

페이지마다 검색 의도를 분리했습니다

지금은 사이트 구조를 대략 이렇게 보고 있습니다.

홈페이지: 레이더 전체 서비스와 주소모음 구조 설명
카테고리 페이지: 특정 분야의 사이트 탐색
상세 페이지: 개별 사이트 정보와 주소 확인

예를 들어 AI 카테고리라면 AI 사이트 추천, AI 툴 모음, 유용한 AI 사이트처럼 해당 분야와 직접 연결되는 검색어를 중심으로 잡습니다.

반대로 모든 페이지에서 주소모음이라는 표현을 똑같은 강도로 반복하지 않습니다.

공통 키워드는 브랜드와 전체 서비스 설명에 남기고, 개별 페이지는 각자의 검색 의도를 담당하도록 바꿨습니다.

내부 링크도 같이 정리했습니다

검색 의도를 분리한 뒤 내부 링크 구조도 다시 봤습니다.

예전에는 관련성이 조금만 있어도 다른 카테고리로 연결했습니다.

지금은 사용자가 실제로 다음에 볼 가능성이 있는 페이지를 중심으로 연결합니다.

기본 흐름은 다음처럼 단순하게 유지하려고 합니다.

홈 → 카테고리 → 개별 사이트 → 관련 카테고리

내부 링크가 많다는 것보다 왜 그 페이지로 이동해야 하는지가 더 중요하다고 느꼈습니다.

지금 적용하고 있는 방식

현재 radarjuso.com에서는 다음 원칙을 중심으로 계속 구조를 조정하고 있습니다.

각 페이지는 하나의 명확한 역할을 갖는다.
비슷한 키워드를 모든 페이지에 반복하지 않는다.
카테고리마다 실제 검색 의도에 맞는 표현을 사용한다.
내부 링크는 관련성과 사용자 이동 흐름을 기준으로 연결한다.
사이트 탐색과 최신주소 확인을 서로 다른 목적처럼 본다.

완벽한 구조라고 생각하지는 않습니다.

다만 카테고리형 사이트를 운영하면서 가장 크게 바뀐 생각은 페이지를 더 만드는 것보다 각 페이지가 왜 존재하는지 설명할 수 있어야 한다는 점입니다.

비슷한 디렉터리나 콘텐츠 사이트를 운영하고 있다면, 새로운 페이지를 추가하기 전에 기존 페이지들의 검색 의도가 서로 겹치고 있지 않은지 먼저 확인해보는 것도 꽤 도움이 될 수 있습니다.

제가 이 구조를 실제로 테스트하고 있는 사이트는 radarjuso.com입니다.

카테고리형 사이트의 색인과 크롤링 구조를 다시 설계한 이유

austin — Fri, 16 Oct 2026 02:25:46 +0000

페이지를 만들었다고 자동으로 색인되는 건 아니었습니다

카테고리형 웹사이트를 운영하면서 처음에는 페이지를 만들고 사이트맵에 넣으면 검색엔진이 자연스럽게 크롤링하고 색인할 거라고 생각했습니다.

실제로는 그렇지 않았습니다.

페이지는 정상적으로 열리고 내부 링크도 존재했지만, 일부 카테고리는 오랫동안 색인되지 않거나 크롤링 우선순위가 낮아 보이는 경우가 있었습니다.

그때부터 단순히 페이지 수를 늘리는 것보다 검색엔진이 사이트 구조를 얼마나 쉽게 이해할 수 있는지가 더 중요하다고 보기 시작했습니다.

먼저 카테고리 구조부터 다시 확인했습니다

제가 운영하는 레이더 주소모음은 여러 웹사이트를 카테고리별로 정리해서 보여주는 주소모음·주소안내 서비스입니다.

사이트는 radarjuso.com입니다.

처음에는 카테고리를 세분화할수록 사용자에게 더 많은 선택지를 줄 수 있다고 생각했습니다.

하지만 페이지가 늘어나면서 비슷한 검색 의도를 가진 카테고리가 생기기 시작했고, 제목이나 설명에서도 비슷한 키워드가 반복됐습니다.

예를 들어 여러 페이지가 동시에 주소모음, 사이트모음, 최신주소안내 같은 표현을 강하게 사용하면 각 페이지가 어떤 역할을 하는지 모호해질 수 있다고 판단했습니다.

그래서 먼저 페이지마다 검색 의도를 다시 나눴습니다.

모든 페이지에 같은 키워드를 넣지 않았습니다

예전에는 주요 키워드를 최대한 많은 페이지에 넣는 게 좋다고 생각했습니다.

운영하면서는 오히려 반대로 바뀌었습니다.

메인 페이지는 사이트 전체의 역할을 설명하고, 각 카테고리 페이지는 해당 분야에 맞는 검색 의도를 담당하도록 분리했습니다.

즉,

홈 → 전체 주소모음 서비스 설명

카테고리 → 특정 분야 사이트 탐색

상세 페이지 → 개별 사이트 정보 및 주소 확인

처럼 페이지의 역할을 나눴습니다.

예를 들어 모든 카테고리에서 단순히 주소모음, 링크모음만 반복하는 대신, AI 카테고리는 AI 사이트 탐색, 커뮤니티 카테고리는 커뮤니티 사이트 탐색처럼 페이지별 중심 주제를 구분하는 방식입니다.

실제로 레이더에 적용한 변경사항

구조를 분석하는 것에서 끝내지 않고 radarjuso.com에 몇 가지 변경을 직접 적용했습니다.

1. 메인 페이지와 카테고리 페이지의 역할을 분리했습니다

메인 페이지에서는 레이더 주소모음이 어떤 서비스인지, 사용자가 어떻게 카테고리를 탐색하는지를 설명하는 데 집중했습니다.

반대로 개별 카테고리 페이지에서는 사이트 전체를 반복해서 설명하기보다 해당 카테고리를 찾는 사용자가 실제로 궁금해할 내용을 중심으로 구성했습니다.

결과적으로 모든 페이지가 같은 키워드를 놓고 경쟁하는 구조를 줄이는 방향으로 바꿨습니다.

2. 카테고리별 핵심 키워드를 따로 정했습니다

처음에는 여러 페이지에서 주소모음, 링크모음, 최신주소 같은 공통 키워드를 비슷하게 사용했습니다.

이후에는 공통 키워드는 사이트 전체 브랜드와 연결하고, 개별 카테고리에는 해당 분야의 검색어를 더 강하게 배치했습니다.

예를 들어 AI 관련 페이지라면 AI 사이트 추천, AI 툴 모음, 유용한 AI 사이트처럼 실제 카테고리 의도와 맞는 표현을 중심으로 잡는 방식입니다.

즉, 공통 키워드를 없앤 것이 아니라 페이지마다 우선순위를 다르게 준 것에 가깝습니다.

3. 내부 링크를 무조건 많이 넣는 방식을 줄였습니다

예전에는 관련성이 조금이라도 있으면 다른 카테고리 링크를 추가하는 식으로 구성했습니다.

지금은 내부 링크를 넣을 때 사용자가 다음에 어떤 페이지를 볼 가능성이 있는지를 먼저 생각합니다.

기본 흐름은 다음처럼 단순화했습니다.

메인 → 카테고리 → 개별 사이트 → 관련 카테고리

반대로 현재 페이지와 직접적인 관련성이 낮은 카테고리까지 무리하게 연결하는 방식은 줄였습니다.

4. 사이트맵에 실제 정식 URL만 유지했습니다

사이트맵도 다시 확인했습니다.

검색에 노출시키려는 실제 페이지가 포함되어 있는지, 불필요하거나 잘못된 URL이 들어가 있지 않은지 확인하고 메인 페이지와 주요 카테고리 URL을 기준으로 관리했습니다.

제가 여기서 배운 건 사이트맵을 제출하는 것과 좋은 크롤링 구조를 만드는 것은 전혀 다른 작업이라는 점입니다.

사이트맵은 URL을 알려줄 뿐이고, 어떤 페이지가 중요한지는 결국 내부 구조와 콘텐츠를 통해 다시 전달해야 했습니다.

5. 카테고리 진입 방식을 더 단순하게 만들었습니다

사용자가 첫 화면에서 너무 많은 링크를 마주하면 선택이 오히려 어려워질 수 있었습니다.

그래서 바로 개별 사이트를 전부 보여주는 것보다,

먼저 카테고리를 선택하고 → 그 안에서 관련 사이트를 탐색하는 방식

을 더 명확하게 보여주는 쪽으로 정리했습니다.

현재 레이더에서 계속 유지하려는 핵심 탐색 흐름도 이것입니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 선택지 비교 → 필요한 주소 확인

6. 최신주소안내를 별도의 검색 의도로 봤습니다

이 부분은 운영하면서 생각보다 중요했습니다.

사이트를 검색하는 사용자 중에는 새로운 웹사이트를 찾는 사람도 있지만, 이미 알고 있는 사이트의 현재 주소를 확인하려는 사람도 있습니다.

그래서 사이트 발견과 최신주소 확인을 완전히 같은 검색 의도로 취급하지 않았습니다.

페이지 문구에서도 단순히 “사이트를 모아놓았다”는 설명만 반복하지 않고, 기존에 사용하던 사이트를 다시 찾거나 변경된 주소를 확인하는 목적까지 구분해서 설명하기 시작했습니다.

내부 링크도 크롤링 경로를 기준으로 정리했습니다

내부 링크 역시 많이 넣는 것보다 구조가 중요했습니다.

모든 페이지에서 모든 카테고리로 연결하는 대신, 상위 카테고리에서 관련 하위 페이지로 이동하고 상세 페이지에서는 다시 관련 카테고리로 돌아갈 수 있도록 흐름을 정리했습니다.

현재 레이더에서는 기본적으로 다음 구조를 중요하게 보고 있습니다.

메인 페이지 → 카테고리 → 관련 사이트 → 다른 관련 카테고리

사용자에게도 자연스럽고, 검색엔진 입장에서도 중요한 페이지와 페이지 간 관계를 파악하기 쉬운 구조를 만드는 게 목표였습니다.

사이트맵도 단순 제출에서 끝내지 않았습니다

사이트맵을 제출했다고 해서 모든 URL이 동일하게 처리되는 것도 아니었습니다.

그래서 사이트맵에는 실제로 검색에 노출시키고 싶은 정식 URL만 포함시키고, 존재하지 않거나 중복되는 주소가 섞이지 않는지 계속 확인했습니다.

또 카테고리 URL이 내부 링크에서 실제로 연결되어 있는지도 같이 확인했습니다.

결국 사이트맵은 크롤러에게 URL 목록을 알려주는 역할이고, 사이트 전체의 정보 구조까지 대신 만들어주는 것은 아니었습니다.

색인 문제를 보면서 가장 많이 바뀐 생각

운영 초반에는 색인이 늦으면 콘텐츠를 더 추가하거나 키워드를 늘리는 쪽부터 생각했습니다.

지금은 먼저 아래를 확인합니다.

이 페이지가 사이트 안에서 명확한 역할을 가지고 있는가
다른 페이지와 검색 의도가 과도하게 겹치지 않는가
내부 링크를 통해 정상적으로 접근할 수 있는가
사이트맵에 올바른 URL이 포함되어 있는가
사용자가 실제로 이 페이지에서 얻을 정보가 있는가

결국 색인과 크롤링 문제는 단순한 기술 설정만의 문제가 아니라 정보 구조와 콘텐츠 역할이 같이 연결된 문제에 가까웠습니다.

제가 이런 구조를 실제로 적용하면서 계속 테스트하고 있는 사이트가 레이더 주소모음 radarjuso.com입니다.

카테고리형 서비스나 디렉터리를 운영하고 있다면 페이지를 더 만드는 것보다 먼저 검색엔진과 사용자가 모두 이해할 수 있는 구조인지, 그리고 실제로 각 페이지가 서로 다른 역할을 가지고 있는지부터 확인해보는 게 꽤 중요하다고 느끼고 있습니다.

처음에는 카테고리가 많아지는 게 좋은 일이라고 생각했습니다.

austin — Fri, 09 Oct 2026 06:11:52 +0000

처음에는 카테고리가 많아지는 게 좋은 일이라고 생각했습니다.

페이지가 늘어나면 다룰 수 있는 검색어도 많아지고, 사용자가 선택할 수 있는 범위도 넓어질 거라고 봤습니다.

제가 운영하고 있는 **레이더(Radar)**도 처음에는 이런 방식으로 확장했습니다.

레이더는 여러 웹사이트를 카테고리별로 정리해서 보여주는 주소안내·주소모음 서비스이고, 현재 radarjuso.com에서 운영하고 있습니다.

그런데 카테고리가 늘어나기 시작하면서 예상하지 못했던 문제가 생겼습니다.

서로 다른 페이지인데 비슷한 키워드를 쓰고 있었습니다

예를 들어 AI 관련 페이지를 만들면서 다음과 같은 표현을 사용했습니다.

유용한 AI 사이트
AI 사이트 추천
AI 툴 모음
AI 서비스 모음

처음에는 비슷한 검색어를 여러 페이지에 나눠서 사용하는 게 괜찮아 보였습니다.

하지만 콘텐츠가 쌓이면서 어떤 페이지가 어떤 검색어를 중심으로 가져가야 하는지 점점 애매해졌습니다.

제가 콘텐츠를 작성할 때조차

“이 키워드는 기존 페이지에서도 사용하지 않았나?”

라는 생각을 자주 하게 됐습니다.

페이지 수는 늘었는데 각 페이지의 역할은 오히려 흐려지고 있었습니다.

그래서 페이지마다 한 가지 역할을 먼저 정했습니다

이후부터는 새 페이지를 만들기 전에 먼저 질문 하나를 던지고 있습니다.

이 페이지를 찾는 사람은 정확히 무엇을 원하는가?

예를 들어 AI 관련 페이지라면 단순히 AI라는 큰 주제로 묶지 않고, 사용자가 새로운 서비스를 발견하려는지, 무료 도구를 찾으려는지, 여러 서비스를 비교하려는지를 먼저 봅니다.

커뮤니티 역시 마찬가지였습니다.

온라인 커뮤니티, 커뮤니티 사이트 추천, 인기 커뮤니티처럼 표현은 비슷해도 실제로 원하는 결과는 조금씩 다를 수 있습니다.

그래서 지금은 키워드부터 정하는 대신 페이지의 검색 의도부터 정하고 그다음 키워드를 선택하는 방식으로 바꿨습니다.

비슷한 페이지는 합치기도 했습니다

페이지를 많이 만드는 것이 항상 좋은 것은 아니었습니다.

내용을 작성해보니 설명이 거의 비슷해지는 두 페이지가 있다면 억지로 따로 유지하기보다 하나로 합치는 편이 더 자연스러운 경우도 있었습니다.

실제로 운영하면서는 다음 기준을 자주 보고 있습니다.

두 페이지의 검색 목적이 정말 다른가?
사용자에게 서로 다른 결과를 보여줄 수 있는가?
설명을 작성했을 때 내용이 반복되지 않는가?
하나의 페이지로 합쳤을 때 오히려 더 이해하기 쉬운가?

이 질문에 명확하게 답하기 어렵다면 페이지를 분리할 이유가 약하다고 판단하고 있습니다.

내부 링크 방식도 바꿨습니다

처음에는 내부 링크가 많을수록 좋을 것 같아서 가능한 페이지들을 서로 연결하려고 했습니다.

그런데 실제로 읽어보면 관련성이 약한 링크까지 들어가면서 본문이 복잡해졌습니다.

그래서 지금은 비슷한 키워드를 가진 페이지를 무조건 연결하는 게 아니라, 사용자가 다음으로 궁금해할 가능성이 높은 페이지만 연결하는 방향으로 바꾸고 있습니다.

SEO를 위해 링크를 넣는다는 생각보다 사용자의 다음 행동을 기준으로 판단하는 방식입니다.

Radar에서는 이렇게 정리하고 있습니다

현재 radarjuso.com에서는 AI, 커뮤니티, 구인구직, 해외직구, 금융·재테크 등 서로 다른 목적의 사이트를 각각의 카테고리로 나누고 있습니다.

레이더의 기본 흐름은 단순합니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 사이트 비교 → 필요한 주소 확인

그리고 기존에 이용했던 사이트를 다시 찾아야 하는 경우를 위해 최신주소안내 역할도 함께 가져가고 있습니다.

하지만 운영하면서 느낀 건 카테고리를 많이 만드는 것보다 각 카테고리가 왜 존재하는지 설명할 수 있는 구조가 훨씬 중요하다는 점입니다.

지금 새 페이지를 만들기 전에 확인하는 것

현재는 카테고리 페이지를 추가하기 전에 최소한 다음 네 가지를 확인합니다.

기존 페이지와 검색 의도가 겹치지 않는가
이 페이지에서만 제공할 수 있는 정보가 있는가
사용자가 카테고리 이름만 보고 목적을 이해할 수 있는가
기존 페이지와 자연스럽게 연결할 이유가 있는가

이 기준을 적용하고 나니 예전처럼 페이지를 빠르게 늘리지는 않게 됐습니다.

대신 페이지별 역할은 훨씬 명확해졌습니다.

처음에는 웹 디렉터리니까 카테고리가 많을수록 좋다고 생각했는데, 직접 운영해보니 오히려 페이지를 만들지 않는 판단도 SEO 구조의 중요한 부분이라는 걸 알게 됐습니다.

비슷한 콘텐츠 중심 사이트를 운영해보신 분들은 카테고리 페이지끼리 검색 의도가 겹치기 시작했을 때 통합하는 편인지, 아니면 더 세분화해서 차별화하는 편인지 궁금합니다.

카테고리형 웹사이트를 만들면서 직접 겪은 SEO와 탐색 구조 문제

austin — Tue, 06 Oct 2026 03:12:31 +0000

카테고리형 웹사이트를 만들면서 직접 겪은 SEO와 탐색 구조 문제

처음 레이더(Radar)를 만들 때는 구조가 꽤 단순할 거라고 생각했습니다.

사이트를 분야별로 나누고, 각 카테고리에 관련 웹사이트를 넣으면 끝이라고 봤습니다. 실제로 초반에는 그렇게 만들었습니다.

그런데 사이트가 조금씩 커지면서 예상하지 못했던 문제가 계속 생겼습니다.

현재 레이더는 radarjuso.com에서 운영하고 있습니다.

사이트가 늘어나자 카테고리가 애매해지기 시작했습니다

처음에는 AI, 커뮤니티, 구인구직처럼 큰 카테고리만 만들어도 충분했습니다.

그런데 사이트가 늘어나면서 어디에 넣어야 할지 애매한 경우가 생겼습니다.

예를 들어 어떤 서비스는 AI 도구이면서 동시에 생산성 도구이기도 했고, 어떤 커뮤니티는 특정 분야 정보 사이트 역할까지 하고 있었습니다.

처음에는 여러 카테고리에 같이 넣어보기도 했습니다.

하지만 그렇게 하니 사용자가 비슷한 사이트를 계속 보게 되고, 페이지마다 내용도 점점 겹치기 시작했습니다.

그래서 어느 순간부터는 “이 사이트가 어떤 종류인가?”보다 “사람들이 이 사이트를 어떤 목적으로 찾을까?”를 먼저 보기 시작했습니다.

그렇게 기준을 바꾸고 나니 정리가 조금 쉬워졌습니다.

AI 페이지에서는 유용한 AI 사이트, 구인구직에서는 구인구직 사이트, 커뮤니티에서는 온라인 커뮤니티처럼 사용 목적을 기준으로 페이지를 나누게 됐습니다.

키워드를 많이 넣는다고 검색 구조가 좋아지지는 않았습니다

초반에는 한 페이지에 관련 키워드를 많이 넣는 것이 좋을 거라고 생각했습니다.

예를 들어 AI 페이지라면 AI 사이트, AI 도구, AI 플랫폼, 무료 AI 등 여러 표현을 최대한 많이 넣었습니다.

그런데 페이지가 늘어나면서 비슷한 키워드가 여러 페이지에 반복되기 시작했습니다.

어떤 페이지를 어떤 키워드로 가져가야 할지 저부터 헷갈렸습니다.

그래서 지금은 한 페이지가 담당할 핵심 주제를 먼저 정하고, 나머지 표현은 그 주제를 설명하는 수준으로만 넣고 있습니다.

이 방식으로 바꾸니 콘텐츠 작성할 때도 훨씬 편해졌습니다.

첫 화면에 너무 많은 걸 보여줬다가 다시 줄였습니다

초기에는 방문자가 선택할 수 있는 게 많으면 좋을 거라고 생각해서 첫 화면에 카테고리와 링크를 많이 보여주려고 했습니다.

그런데 실제로 보면 정보가 많은 만큼 어디부터 눌러야 할지 애매해졌습니다.

특히 모바일에서는 더 복잡하게 느껴졌습니다.

그래서 지금은 먼저 카테고리를 고르게 하고, 그다음 관련 사이트를 보여주는 방식으로 정리하고 있습니다.

현재 제가 가장 중요하게 보는 흐름은 단순합니다.

카테고리 선택 → 관련 사이트 확인 → 여러 선택지 비교 → 사이트 이동

사용자가 처음 들어왔을 때 “여기서 뭘 해야 하지?”라는 생각이 들지 않게 만드는 게 목표입니다.

내부 링크도 많이 넣었다가 다시 정리했습니다

SEO 때문에 내부 링크를 늘려야 한다는 생각으로 초반에는 관련 페이지를 최대한 많이 연결하려고 했습니다.

그런데 링크가 많아지니 오히려 본문 흐름이 끊겼습니다.

사용자 입장에서는 지금 보고 있는 내용과 크게 상관없는 페이지까지 계속 추천받는 느낌이었습니다.

그래서 지금은 실제로 다음 행동으로 이어질 가능성이 높은 페이지 위주로 연결하고 있습니다.

예를 들어 AI 사이트를 보는 사람이 커뮤니티나 다른 온라인 도구도 같이 볼 가능성이 있다면 연결하지만, 단순히 내부 링크 수를 늘리기 위한 링크는 줄이는 식입니다.

사람들이 다시 들어오는 이유도 따로 필요했습니다

운영하면서 또 하나 알게 된 건, 디렉터리 사이트는 한 번 필요한 링크를 찾으면 다시 들어올 이유가 약하다는 점이었습니다.

이 문제를 해결하려고 최신주소안내라는 역할을 같이 넣기 시작했습니다.

예전에 사용했던 사이트를 다시 찾거나, 기존 주소로 접속이 안 될 때 다시 확인할 수 있게 하는 방식입니다.

이 기능은 신규 사이트를 발견하는 것과는 조금 다른 사용 목적이지만, 실제 재방문 이유를 만드는 데는 더 직접적이라고 느꼈습니다.

지금은 이 네 가지를 계속 보고 있습니다

레이더를 운영하면서 지금 가장 많이 확인하는 건 다음입니다.

사용자가 원하는 카테고리를 바로 찾는지
페이지마다 주제가 겹치지 않는지
관련 사이트를 비교하기 쉬운지
다시 방문할 이유가 있는지

현재 구조는 radarjuso.com에서 확인할 수 있습니다.

처음에는 단순한 링크 디렉터리라고 생각했는데, 직접 운영해보니 카테고리 하나를 나누는 기준부터 내부 링크를 어디까지 연결할지까지 계속 수정하게 되는 프로젝트였습니다.

비슷한 형태의 사이트를 만들어본 분들이라면, 콘텐츠가 늘어나기 시작했을 때 카테고리 구조와 검색 기능 중 어느 쪽을 먼저 손보셨는지 궁금합니다.

카테고리형 웹사이트를 만들면서 배운 SEO와 탐색 구조 설계

austin — Tue, 06 Oct 2026 03:01:22 +0000

카테고리형 웹사이트를 만들면서 배운 SEO와 탐색 구조 설계

웹사이트에 콘텐츠가 많아질수록 단순히 페이지를 늘리는 것보다 어떻게 분류하고, 어떤 검색 의도를 각 페이지에 맡길 것인가가 더 중요해지는 것 같습니다.

제가 운영하고 있는 레이더(Radar)도 이런 고민에서 시작한 프로젝트입니다.

레이더는 여러 웹사이트를 분야별로 정리해서 사용자가 필요한 사이트를 보다 쉽게 탐색할 수 있도록 만든 주소안내·주소모음 서비스입니다.

현재는 radarjuso.com에서 운영하고 있습니다.

처음에는 단순한 디렉터리라고 생각했습니다

웹 디렉터리의 기본 구조는 단순합니다.

사이트를 모으고, 카테고리를 만들고, 사용자가 원하는 링크를 선택하게 하면 됩니다.

하지만 실제로 콘텐츠가 늘어나기 시작하면 문제가 생깁니다.

카테고리가 너무 넓으면 서로 다른 검색 의도가 한 페이지에 섞이고, 너무 세분화하면 사용자가 원하는 정보를 찾기 위해 여러 단계를 이동해야 합니다.

결국 중요한 건 링크의 개수가 아니라 정보 구조와 탐색 비용이었습니다.

카테고리는 검색 의도를 기준으로 나누기

현재 Radar에서는 카테고리 이름 자체보다 사용자가 왜 해당 페이지를 찾는지를 더 중요하게 보고 있습니다.

예를 들어:

AI → 유용한 AI 사이트
커뮤니티 → 온라인 커뮤니티
구인구직 → 구인구직 사이트
해외직구 → 해외직구 사이트

처럼 각 페이지가 담당하는 검색 의도를 최대한 명확하게 분리하는 방식입니다.

SEO 측면에서도 한 페이지가 너무 많은 키워드를 동시에 노리는 것보다, 하나의 명확한 주제를 가지고 관련 검색어를 자연스럽게 확장하는 구조가 관리하기 훨씬 편했습니다.

검색 유입만큼 중요한 건 탐색 UX

SEO로 사용자를 데려오는 것과, 사이트 안에서 원하는 정보를 찾게 만드는 것은 완전히 다른 문제였습니다.

사용자가 검색 결과를 통해 들어왔는데 어디를 클릭해야 할지 바로 이해하지 못한다면 페이지 수가 많아도 큰 의미가 없습니다.

그래서 Radar에서는 기본적으로 다음 흐름을 중요하게 보고 있습니다.

카테고리 선택 → 관련 사이트 탐색 → 여러 선택지 비교 → 필요한 사이트 확인

사이트 이름을 정확히 알고 있는 사용자는 검색엔진에서 바로 찾으면 됩니다.

하지만 “어떤 AI 사이트가 있지?”, “사용할 만한 커뮤니티가 뭐가 있지?”처럼 선택지를 먼저 보고 싶은 사용자에게는 카테고리형 탐색 구조가 더 잘 맞을 수 있습니다.

내부 링크도 단순 연결보다 맥락이 중요했습니다

카테고리가 많아지면 내부 링크도 자연스럽게 증가합니다.

이때 모든 페이지를 무조건 서로 연결하는 것보다, 검색 의도와 사용 목적이 가까운 페이지를 자연스럽게 이어주는 편이 사용자 경험 측면에서도 더 낫다고 보고 있습니다.

예를 들어 AI 관련 사이트를 보고 있는 사용자가 다음으로 관심을 가질 만한 커뮤니티나 생산성 관련 리소스를 보여주는 식입니다.

결국 내부 링크도 SEO를 위한 구조이면서 동시에 사용자의 다음 행동을 설계하는 UX 요소라고 생각합니다.

지금 가장 중요하게 보는 네 가지

현재 Radar를 운영하면서 가장 중요하게 보고 있는 부분은 다음 네 가지입니다.

Search Intent — 페이지마다 명확한 검색 목적을 부여하기
Information Architecture — 콘텐츠가 늘어나도 구조가 복잡해지지 않게 만들기
Discoverability — 사용자가 몰랐던 사이트도 자연스럽게 발견하게 만들기
Return Visits — 한 번 방문하고 끝나는 서비스가 되지 않게 하기

실제 구조는 radarjuso.com에서 확인할 수 있습니다.

웹 디렉터리처럼 단순해 보이는 서비스도 규모가 커질수록 결국 SEO, taxonomy, internal linking, UX가 서로 연결되는 문제라는 걸 계속 느끼고 있습니다.

비슷한 카테고리형 서비스를 만든다면 여러분은 검색 기능, 카테고리 구조, 추천 시스템, 내부 링크 중 어떤 요소를 가장 먼저 고도화할 것 같나요?

웹사이트를 찾는 과정 자체를 제품으로 만들었습니다 — Radar 개발 이야기

austin — Wed, 30 Sep 2026 03:38:57 +0000

웹사이트를 찾는 과정 자체를 제품으로 만들었습니다 — Radar 개발 이야기

웹서비스를 만들다 보면 거창한 문제보다 반복되는 작은 불편에서 아이디어가 시작될 때가 있습니다.

제가 Radar를 만들게 된 이유도 비슷했습니다.

인터넷에는 정말 많은 웹사이트가 있지만, 막상 필요한 사이트를 찾으려고 하면 다시 검색부터 시작하게 됩니다. 예전에 사용했던 사이트 이름이 기억나지 않기도 하고, 같은 분야의 여러 서비스를 비교하려면 검색 결과를 계속 오가야 하는 경우도 많습니다.

그래서 이런 생각을 했습니다.

“검색 결과를 계속 돌아다니지 않고, 필요한 분야의 사이트를 한곳에서 탐색할 수 있다면 어떨까?”

그 생각에서 시작한 프로젝트가 Radar — radarjuso.com입니다.

Radar가 해결하려는 문제

Radar는 단순히 URL을 나열하는 링크 페이지를 목표로 하지 않았습니다.

제가 만들고 싶었던 것은 사용자가 사이트 이름을 정확히 몰라도 먼저 목적을 선택하고 → 관련 사이트를 탐색하고 → 여러 선택지를 비교할 수 있는 구조였습니다.

현재 Radar에서는 서로 성격이 다른 웹사이트들을 카테고리별로 구분해서 살펴볼 수 있습니다.

예를 들면:

유용한 AI 사이트
온라인 커뮤니티
구인구직 사이트
해외직구 사이트
금융·재테크 관련 서비스
영화·드라마·웹툰 등 다양한 웹 콘텐츠 카테고리

이런 식으로 사용자의 검색 목적을 먼저 나눈 뒤 그 안에서 관련 사이트를 확인할 수 있도록 구성하고 있습니다.

프로젝트는 radarjuso.com에서 직접 확인할 수 있습니다.

링크가 많다고 좋은 디렉터리는 아니었습니다

처음 이런 형태의 서비스를 생각했을 때 가장 쉬운 방법은 가능한 한 많은 링크를 한 화면에 보여주는 것이었습니다.

하지만 실제로 만들어보면 문제가 생깁니다.

링크가 많아질수록 사용자는 오히려 어디를 봐야 할지 모르게 됩니다.

결국 중요한 것은 링크의 수가 아니라 정보 구조였습니다.

그래서 Radar에서는 다음 흐름을 중요하게 보고 있습니다.

카테고리 선택 → 관련 사이트 탐색 → 선택지 비교 → 원하는 사이트 이동

사용자가 처음부터 정확한 사이트명을 알고 있어야 하는 구조가 아니라, “AI 도구가 필요하다”, “커뮤니티를 찾고 있다”, “구인구직 사이트를 보고 싶다” 같은 목적에서 출발할 수 있도록 만드는 것입니다.

검색 의도도 카테고리마다 다르게 봤습니다

개발하면서 흥미로웠던 부분 중 하나는 카테고리마다 사용자가 원하는 것이 완전히 다르다는 점이었습니다.

AI 카테고리에 들어오는 사람은 새로운 도구를 발견하고 싶을 수 있고, 구인구직 페이지를 찾는 사람은 실제 채용 사이트를 빠르게 비교하고 싶을 수 있습니다.

따라서 모든 페이지를 동일한 템플릿과 동일한 설명으로 만들기보다 각각의 카테고리가 담당하는 검색 의도(Search Intent)를 분리하는 것이 중요하다고 봤습니다.

예를 들면:

AI
→ 유용한 AI 사이트 / AI 툴 모음 / AI 사이트 추천

커뮤니티
→ 온라인 커뮤니티 / 커뮤니티 사이트 추천

구인구직
→ 구인구직 사이트 / 취업 사이트

처럼 실제 사용자가 찾는 목적을 기준으로 페이지의 역할을 구분하는 방식입니다.

“다시 찾는 문제”도 해결하고 싶었습니다

또 하나 자주 발생하는 문제가 있습니다.

“전에 사용했던 그 사이트 주소가 뭐였지?”

인터넷 서비스를 오래 이용하다 보면 북마크를 하지 않은 사이트를 다시 찾는 일이 생각보다 많습니다.

일부 웹사이트는 주소가 변경되기도 하기 때문에 Radar에서는 단순한 사이트 발견뿐 아니라 주소안내와 최신주소안내라는 역할도 같이 가져가고 있습니다.

그래서 제가 보는 Radar의 핵심 역할은 다음 네 단계입니다.

분류 → 탐색 → 비교 → 주소 확인

검색엔진을 대체하는 것이 아니라, 검색을 시작하기 전에 사용할 수 있는 웹사이트 탐색 레이어에 조금 더 가깝습니다.

앞으로 더 개선하고 싶은 부분

현재도 계속 고민하고 있는 부분이 있습니다.

카테고리가 많아져도 복잡하지 않은 탐색 구조
사용자가 새로운 사이트를 자연스럽게 발견하는 방식
각 카테고리의 검색 의도를 더 명확하게 만드는 방법
단순 방문이 아니라 다시 찾아올 이유를 만드는 방법
많은 링크를 보여주면서도 정보 밀도를 과하게 높이지 않는 UX

디렉터리형 프로젝트는 겉으로 보면 단순해 보이지만, 실제로 만들어보니 정보 구조와 탐색 UX를 계속 개선해야 하는 제품이라는 생각이 들었습니다.

현재 제가 만들고 있는 결과물은 여기에서 확인할 수 있습니다.

Radar — https://radarjuso.com

개발자 입장에서 이런 종류의 디렉터리를 만든다면 여러분은 검색(Search), 카테고리(Category), 개인화(Personalization), 추천(Recommendation) 중 어떤 기능을 가장 먼저 강화할 것 같나요?

DEV Community: austin

주소모음 서비스를 만들면서 사이트 탐색 UX를 단순화한 방법

사이트를 먼저 보여주는 대신 카테고리를 먼저 보여줬습니다

카테고리마다 역할을 나눴습니다

검색과 탐색을 같은 기능으로 보지 않았습니다

내부 링크도 사용자 흐름에 맞췄습니다

주소모음 서비스도 결국 정보 구조 문제였습니다

카테고리 페이지끼리 검색 의도가 겹칠 때 바꾼 것들

문제는 페이지 수가 아니라 역할이었습니다

페이지마다 검색 의도를 분리했습니다

내부 링크도 같이 정리했습니다

최신주소는 별도 의도로 봤습니다

지금 적용하고 있는 방식

카테고리형 사이트의 색인과 크롤링 구조를 다시 설계한 이유

페이지를 만들었다고 자동으로 색인되는 건 아니었습니다

먼저 카테고리 구조부터 다시 확인했습니다

모든 페이지에 같은 키워드를 넣지 않았습니다

실제로 레이더에 적용한 변경사항

1. 메인 페이지와 카테고리 페이지의 역할을 분리했습니다

2. 카테고리별 핵심 키워드를 따로 정했습니다

3. 내부 링크를 무조건 많이 넣는 방식을 줄였습니다

4. 사이트맵에 실제 정식 URL만 유지했습니다

5. 카테고리 진입 방식을 더 단순하게 만들었습니다

6. 최신주소안내를 별도의 검색 의도로 봤습니다

내부 링크도 크롤링 경로를 기준으로 정리했습니다

사이트맵도 단순 제출에서 끝내지 않았습니다

최신주소안내도 검색 의도를 따로 봤습니다

색인 문제를 보면서 가장 많이 바뀐 생각

처음에는 카테고리가 많아지는 게 좋은 일이라고 생각했습니다.

서로 다른 페이지인데 비슷한 키워드를 쓰고 있었습니다

그래서 페이지마다 한 가지 역할을 먼저 정했습니다

비슷한 페이지는 합치기도 했습니다

내부 링크 방식도 바꿨습니다

Radar에서는 이렇게 정리하고 있습니다

지금 새 페이지를 만들기 전에 확인하는 것

카테고리형 웹사이트를 만들면서 직접 겪은 SEO와 탐색 구조 문제

카테고리형 웹사이트를 만들면서 직접 겪은 SEO와 탐색 구조 문제

사이트가 늘어나자 카테고리가 애매해지기 시작했습니다

키워드를 많이 넣는다고 검색 구조가 좋아지지는 않았습니다

첫 화면에 너무 많은 걸 보여줬다가 다시 줄였습니다

내부 링크도 많이 넣었다가 다시 정리했습니다

사람들이 다시 들어오는 이유도 따로 필요했습니다

지금은 이 네 가지를 계속 보고 있습니다

카테고리형 웹사이트를 만들면서 배운 SEO와 탐색 구조 설계

카테고리형 웹사이트를 만들면서 배운 SEO와 탐색 구조 설계

처음에는 단순한 디렉터리라고 생각했습니다

카테고리는 검색 의도를 기준으로 나누기

검색 유입만큼 중요한 건 탐색 UX

내부 링크도 단순 연결보다 맥락이 중요했습니다

최신주소안내라는 재방문 이유

지금 가장 중요하게 보는 네 가지

웹사이트를 찾는 과정 자체를 제품으로 만들었습니다 — Radar 개발 이야기

웹사이트를 찾는 과정 자체를 제품으로 만들었습니다 — Radar 개발 이야기

Radar가 해결하려는 문제

링크가 많다고 좋은 디렉터리는 아니었습니다

검색 의도도 카테고리마다 다르게 봤습니다

“다시 찾는 문제”도 해결하고 싶었습니다

앞으로 더 개선하고 싶은 부분