본문 바로가기
inpilot.dev

개인 기술 허브를 랜딩→블로그→SNS 3층으로 설계한 이유

2025-08-10 · 1 min read

문제: 자산은 있는데 유통이 없었다

치트시트 PDF, 플러그인, 자료는 쌓여 있었다. 그런데 스타는 0, 방문자도 0. 품질 문제가 아니라 유통 문제였다. 좋은 글을 한 편 더 쓰는 게 아니라, 글이 사람에게 닿는 구조를 먼저 만들어야 했다.

3층 깔때기

역할지표
랜딩(위키)나를 3초에 설명 — 정적 뼈대체류·자료 클릭
블로그생존 신호 — "이 사람 살아 움직인다"구독·재방문
SNS 확산알고리즘 유입 — Threads 주력유입·팔로우

핵심은 각 층의 job이 하나씩이라는 것. 랜딩은 전환, 블로그는 신뢰, SNS는 유입. 한 페이지가 세 가지를 다 하려 들면 아무것도 못 한다.

랜딩 3구역

  • 위키 목차(본체): 정적 뼈대 — 내가 뭘 아는 사람인지
  • 최신 흐름(생존신호): 워크플로우 재현기 + 실험로그 — 구독 유도
  • 자료실: 치트시트 등 리드마그넷 — 팔로우/스타의 대가로 발송

채널: Threads 하나에 인게이지먼트 몰기

발행은 복제 가능하지만 관심과 시간은 복제 불가다. 그래서 댓글 인게이지먼트는 Threads 한 곳에만 집중하고, X는 동일 포맷 동시발행, LinkedIn은 재발행만.

타깃 재보정

랜딩 MVP의 유일한 고객 = 알고리즘 타고 지나가다 온 개발자. "나도 하고 싶다 → 자료받기/팔로우"의 3초 전환에 최적화했다. 채용담당자는 커진 다음의 고객 — 폴리싱은 후순위.

다음

  • [내가 채울 것: 첫 4주 Threads 댓글 작전의 실제 유입 수치]
  • [내가 채울 것: 자료실 리드마그넷 다운로드 → 팔로우 전환율]

구조부터 세우면 글은 그 위에 얹히면 된다. 반대로 하면 좋은 글이 허공에 흩어진다.

새 글이 올라오면 받아보기

스팸 없이, 새 글이 올라올 때만 보내드려요.

댓글

댓글은 giscus 설정 후 표시됩니다. (docs/SETUP-features.md 참고)