여러 개의 작은 인터넷 서비스를 한 페이지에서 컬러 타일 형태로 노출해, 브랜드 게이트웨이 + 발견 채널 역할을 동시에 수행하는 멀티서비스 허브.

포지셔닝

oos 는 작은 인터넷 서비스들을 한 화면에 모아 보여주는 브랜드 게이트웨이 + 발견 채널 입니다. 사용자는 도착해서 한 번의 클릭으로 원하는 서비스로 진입하고, 운영자는 여러 서비스를 같은 정체성 아래 묶어 노출합니다.

시장과 문제 정의

작은 서비스를 여러 개 운영하는 1인 운영자는 두 가지 마찰을 동시에 겪습니다.

각 서비스를 개별 도메인에 띄워두면 사용자가 다른 서비스의 존재를 모름
랜딩 페이지를 하나하나 정성스럽게 만들기엔 시간이 부족함 — 그러나 서비스에 도착한 사용자에게 즉시 가치 전달을 못하면 이탈

oos 는 이 사이를 메우는 가벼운 hub. 각 서비스의 정체성(컬러·로고·한 줄 설명) 만 타일로 보여주고, 클릭으로 즉시 해당 서비스로 이동하게 합니다. 별도의 회원가입·로그인·온보딩이 없는 zero-friction 진입.

핵심 타깃과 페르소나

여러 작은 서비스를 운영하는 1인 / 소규모 팀 — 각 서비스의 디스커버리를 묶어 처리하고 싶은 운영자
브랜드 게이트웨이가 필요한 프로덕트 오너 — “우리 팀이 어떤 도구들을 만들고 있는지” 를 한 페이지로 보여주고 싶은 케이스
새로운 작은 도구를 둘러보고 싶은 사용자 — 큰 플랫폼 검색 결과가 아니라 큐레이션된 작은 인터넷 서비스 모음을 보고 싶은 그룹

가치 제안과 차별점

컬러 타일 기반 발견 — 각 서비스의 브랜드 컬러 / 워드마크 / 한 줄 설명만으로 즉시 식별. 텍스트 카탈로그가 아닌 시각적 카탈로그
자동 톤 매칭 — 타일 배경 컬러의 명도에 따라 텍스트 톤(밝음/어두움) 이 자동 결정 — 서비스가 추가될 때 별도 디자인 작업 없이 가독성 보장
반응형 그리드 자동 구성 — 서비스 개수에 맞춰 desktop / tablet / mobile 컬럼이 자동 결정. 1개일 때와 9개일 때 모두 의도된 비례 유지
zero-friction 진입 — 회원가입·로그인·검색 없음. 타일 = 링크. 추가 인터랙션 비용 0

핵심 사용자 흐름

도착: www.oos.kr 진입 — 헤드라인 + 컬러 타일 그리드만 보임
스캔: 컬러 / 워드마크 / 한 줄 설명으로 관심 서비스 식별
이동: 타일 클릭 → 해당 서비스 도메인으로 이동
이탈 후 재방문: bookmark / 검색 으로 재진입해 다른 서비스를 둘러보는 행동 패턴 형성 의도

비즈니스 모델 가설

oos 자체는 직접 수익화 대상이 아니라 여러 서비스의 디스커버리 채널 로 작동. 수익은 각 하위 서비스에서 발생.

하위 서비스 진입 전환률 향상 — 한 사용자가 여러 서비스를 인지하면 평균 사용 서비스 수가 늘어남 (cross-discovery)
브랜드 일관성 — 운영자가 만드는 모든 작은 도구를 같은 정체성 아래 묶어 외부 인지도 누적
선택적 광고/스폰서 슬롯 (가설) — 서드파티 작은 도구를 큐레이션해 노출하는 형태로 확장 가능

시스템 아키텍처 (기획 결정을 시스템으로)

기획 결정 두 가지가 시스템 단순성을 결정.

1. “허브는 백엔드가 필요 없어야 한다” → 100% 정적 사이트. 서비스 목록은 빌드 타임에 TypeScript 데이터로 박혀 들어가고, S3 + CloudFront 만으로 서빙. 가용성 / 비용 모두 최소.

2. “디자인 일관성은 시스템이 강제해야 한다” → 타일 텍스트 톤 자동 결정 (luminance threshold), 서비스 수에 맞춘 그리드 자동 구성. 새 서비스를 추가할 때 데이터 한 줄만 늘리면 끝 — 별도 디자인 검토 없이 일관성 유지.

flowchart LR
    Data["apps.ts
(서비스 데이터)"] --> Build["Astro build
(static)"]
    Build --> S3["S3
web/"]
    S3 --> CF["CloudFront"]
    CF --> User["사용자 브라우저"]
    User --> Service1["weple.oos.kr"]
    User --> Service2["…"]

기술 결정과 트레이드오프

Frontend: Astro 5 (static output) + TypeScript. SPA 도 React 도 필요 없음 — 타일 그리드 한 페이지가 전체 인터페이스라 SSG 가 가장 정직한 선택
Backend: 없음. 모든 데이터는 빌드 타임 정적
호스팅: 워크스페이스 표준 S3 (oos.kr/web/) + CloudFront. trailingSlash always
운영 신호: GA4 (페이지뷰 / 타일 클릭) + Channel Talk (피드백 채널)
포기한 것: 동적 서비스 목록 (CMS·DB), 검색 / 필터 (서비스 수가 적을 땐 한 화면 스캔이 더 빠름), 사용자 계정 (허브에 계정이 있을 이유 없음)

운영 자동화

타일 톤 자동 결정 — 배경 컬러 hex → 상대 명도(WCAG luminance) 계산 → 임계값 기준으로 white / dark text 자동 선택
그리드 자동 구성 — 서비스 개수에 따라 desktop / tablet / mobile 컬럼 / 종횡비 자동 결정
OG 자동 — 빌드 시 헤드라인 + 브랜드를 합성한 og-image 자동 생성
JSON-LD 자동 — 서비스 목록을 빌드 타임에 ItemList(WebApplication) 구조화 데이터로 자동 출력

현재 상태와 운영 신호

상태: 운영 중. weple 1개 서비스로 시작, 추후 확장
시작: 2026-04
인프라: AWS S3 (oos.kr/web/) + CloudFront, GA4 (G-0N2TV2NS1G), Channel Talk
검증 신호: 타일 클릭률, 단일 세션 내 다중 서비스 접속률 (cross-discovery 신호)

회고와 다음 가설

잘 작동한 것: “타일 = 링크” 라는 zero-friction 결정. 사용자가 망설일 인터랙션이 없음
다시 한다면: 첫 출시에서 OG / Channel Talk / GA / sitemap 을 동시에 박지 않은 것은 검색 인덱싱 지연으로 이어졌음. SEO 인프라는 출시 1일차에 모두 박혀 있어야 함 (이번 회차에 보강)
다음 가설: (1) 서비스가 5개 이상이 되면 카테고리 그룹핑, (2) 각 서비스의 라이브 상태 / 최신 업데이트 노출, (3) 외부 큐레이션 슬롯, (4) 다국어 (en) 분기

비슷한 결의 작업 의뢰

oos 를 단독으로 기획·구현·운영하면서 만들어낸 핵심 역량은 다른 도메인에도 적용 가능합니다.

멀티서비스 브랜드 허브 / 디렉터리 페이지 — 여러 제품을 운영하는 팀의 게이트웨이 페이지 설계
zero-friction 디스커버리 UX — 회원가입·검색 없이 한 화면 스캔으로 의사결정이 끝나는 인터페이스
데이터 한 줄로 디자인 일관성을 강제하는 시스템 — 컬러 / 그리드 / 타이포 톤이 데이터 변경만으로 자동 보장되는 구조
정적 사이트 기반 SEO 인프라 자동화 — sitemap / robots / JSON-LD / OG / GA / 헬프채널을 빌드 타임에 박는 패턴
저비용 정적 호스팅 (S3 + CloudFront) 다중 사이트 운영 — 작은 서비스를 빠르게 띄우고 같은 인프라 패턴으로 운영하는 작업

기획부터 시스템 구축, 운영 자동화까지 한 사람이 끝까지 들고 가는 형태의 작업을 선호합니다. 의뢰는 /work-with-me 또는 /contact 로 연락주세요.