為何把一個網頁目錄拆成兩個網站：快速瀏覽與內容説明需要不同的 UI

웹 디렉터리를 처음 만들 때는 한 사이트 안에 모든 기능을 넣는 것이 가장 단순하다고 생각했습니다.

카테고리를 만들고, 사이트를 등록하고, 사용자가 원하는 링크를 찾게 하면 끝이라고 생각했습니다.

하지만 운영하면서 조금 다른 문제가 보이기 시작했습니다.

사용자는 모두 같은 목적으로 방문하지 않았습니다.

어떤 사용자는 주소를 빨리 찾고 싶어 했고, 어떤 사용자는 어떤 사이트들이 있는지 비교하고 싶어 했습니다.

그리고 또 다른 사용자는 특정 카테고리가 무엇인지, 어떤 사이트를 선택해야 하는지 설명부터 필요로 했습니다.

결국 하나의 인터페이스에 너무 많은 역할을 넣기보다 역할을 분리하는 방향으로 구조를 바꾸게 됐습니다.

현재 제가 운영하고 있는 두 프로젝트가 그 결과입니다.

문제는 데이터가 아니라 사용자 의도였다

처음에는 이런 구조가 자연스러워 보였습니다.

Home
├── AI
├── Community
├── Shopping
├── Jobs
├── Finance
└── Other Categories

카테고리를 선택하면 사이트 목록이 나오고, 사용자가 원하는 사이트를 클릭합니다.

웹 디렉터리로서는 충분히 정상적인 구조입니다.

그런데 실제 사용 흐름을 생각해보면 두 가지 의도가 섞여 있었습니다.

Intent A
"I already know roughly what I need."

→ category
→ site
→ visit

반면 다른 사용자는 다음과 같습니다.

Intent B
"I know the topic, but I don't know which site I need."

→ understand category
→ discover options
→ compare
→ choose

두 흐름은 비슷해 보이지만 필요한 인터페이스가 다릅니다.

빠른 탐색과 설명형 콘텐츠의 충돌

주소를 빨리 찾는 사용자에게 긴 설명은 방해가 됩니다.

반대로 새로운 사이트를 탐색하는 사용자에게 링크 목록만 보여주면 맥락이 부족합니다.

예를 들어 빠른 탐색 페이지에서는 이런 구조가 적합합니다.

AI
├── Site A
├── Site B
├── Site C
└── Site D

하지만 설명형 페이지는 다음과 같은 구조가 더 자연스럽습니다.

What is this category?
↓
What kinds of sites are included?
↓
Available options
↓
How are they different?
↓
Related categories

하나의 페이지에서 두 가지를 모두 만족시키려고 하면 결국 UI가 복잡해지기 시작합니다.

버튼은 늘어나고 설명은 길어지고, 사용자가 실제로 원하는 링크는 아래로 밀립니다.

그래서 저는 역할 자체를 분리하기로 했습니다.

radarjuso.com: 빠른 탐색 중심

첫 번째 프로젝트는 radarjuso.com 입니다.

이쪽에서는 사용자가 원하는 분야를 먼저 선택하고 관련 사이트를 빠르게 확인하는 흐름을 중요하게 보고 있습니다.

개념적으로는 다음과 같습니다.

Category
↓
Relevant Sites
↓
Destination

정보 밀도를 높이고 이동 단계를 줄이는 것이 핵심입니다.

사용자가 이미 원하는 분야를 알고 있다면 설명보다 선택지가 먼저 보여야 하기 때문입니다.

radarlinksite.com: 설명과 탐색을 연결

두 번째 프로젝트는 radarlinksite.com 입니다.

이 사이트에서는 링크 목록 자체보다 카테고리와 사이트를 이해하는 과정에 조금 더 공간을 사용하고 있습니다.

현재 이 프로젝트는 Next.js 기반의 정적 사이트 구조로 운영하고 있습니다.

개념적인 페이지 구조는 다음과 같습니다.

/
├── sites/
│   ├── category-a/
│   ├── category-b/
│   └── category-c/
├── blog/
├── about/
└── privacy/

여기에서는 단순히 목적지 URL을 보여주는 것뿐 아니라 사용자가 관련 카테고리를 탐색할 수 있도록 구조를 확장할 수 있습니다.

즉 역할을 단순하게 나누면 다음과 같습니다.

radarjuso.com
→ Find

radarlinksite.com
→ Discover + Understand

두 사이트가 완전히 다른 서비스를 제공한다기보다 같은 문제를 서로 다른 사용자 흐름에서 해결하도록 분리한 것에 가깝습니다.

처음부터 두 사이트가 필요했던 것은 아니다

여기서 중요한 점은 프로젝트를 시작하자마자 여러 사이트로 분리하는 것이 좋은 설계라는 뜻은 아닙니다.

오히려 대부분의 경우 하나의 사이트로 시작하는 것이 훨씬 낫습니다.

서비스가 작을 때 두 개의 사이트를 운영하면 다음과 같은 비용이 생깁니다.

Deployment × 2
Analytics × 2
SEO monitoring × 2
Content maintenance × 2
Broken link checks × 2

네, 구조를 분리하면 관리해야 할 것도 친절하게 두 배 가까이 늘어납니다.

소프트웨어는 늘 문제를 해결한 대가로 새로운 문제를 하나 무료로 제공합니다.

그래서 분리 기준은 기술적인 이유보다 사용자 흐름이 정말 다른가가 되어야 한다고 생각합니다.

같은 내용을 복사하지 않는 것이 중요했다

사이트를 둘로 나눈 다음 가장 피하고 싶었던 것은 동일한 페이지를 두 도메인에 복사하는 것이었습니다.

예를 들어 이런 구조는 좋지 않습니다.

Site A:
/ai

Site B:
/ai

Same title
Same description
Same links
Same content

이렇게 만들면 사용자의 입장에서도 두 사이트를 운영할 이유가 없습니다.

대신 동일한 주제를 다루더라도 페이지의 역할을 다르게 정의했습니다.

Directory page
→ 선택과 이동

Editorial / discovery page
→ 설명과 탐색

콘텐츠 자체보다 페이지가 수행하는 작업을 먼저 정의하는 방식입니다.

페이지 역할을 먼저 정의하면 구현도 단순해진다

이후 새로운 페이지를 만들 때는 먼저 질문합니다.

What should the user accomplish here?

그리고 페이지 역할을 몇 가지로 제한합니다.

const pageRoles = {
  directory: "find a destination quickly",
  category: "explore related websites",
  editorial: "understand a topic",
  navigation: "move between categories"
};

실제 코드에서 꼭 이런 객체를 사용할 필요는 없습니다.

중요한 것은 각 페이지마다 하나의 주된 역할을 정하는 것입니다.

그렇게 하면 다음 결정도 쉬워집니다.

얼마나 많은 설명을 넣을 것인가?
링크를 어디에 배치할 것인가?
관련 카테고리를 보여줄 것인가?
검색 기능이 필요한가?
다음 행동은 무엇이어야 하는가?

두 사이트를 운영하면서 얻은 가장 큰 교훈

처음에는 웹 디렉터리를 데이터 문제라고 생각했습니다.

Collect URLs
↓
Categorize them
↓
Display them

지금은 조금 다르게 생각합니다.

User intent
↓
Page role
↓
Information architecture
↓
Content
↓
Links

링크 자체는 마지막에 가깝습니다.

그 전에 사용자가 왜 이 페이지에 왔는지를 정의해야 합니다.

현재 이 구조를 실제로 테스트하고 있는 두 사이트가 다음 프로젝트입니다.

두 사이트를 운영하면서 계속 확인하고 있는 질문은 간단합니다.

사용자가 원하는 것은 더 많은 링크일까, 아니면 더 빠른 결정일까?

점점 후자에 가깝다고 생각하고 있습니다.

이 글은 실제 웹 디렉터리 프로젝트 운영 경험을 기반으로 작성했으며, AI는 초안 구성과 문장 정리에 보조적으로 사용했습니다. 게시 전 기술 내용과 프로젝트 관련 사실을 직접 검토했습니다.