새 커뮤니티 사이트를 만들 때 가장 흔한 실수 중 하나는, 메인 사이트가 모든 역할을 다 해야 한다고 가정하는 것이다. 소개 페이지도 있어야 하고, 공지도 올려야 하고, 문서도 있어야 하고, 프로젝트 상태도 보여줘야 하고, 나중에는 토론과 댓글까지 들어와야 한다는 식이다. 겉으로는 풍성해 보이지만, 실제로는 각각 다른 읽기 방식과 운영 리듬이 뒤엉키면서 모든 화면이 애매해지기 쉽다.
CTRL은 그 반대로 가려 한다. 메인 사이트는 거대한 포털이 아니라 프런트 도어여야 한다. 즉 무엇이 여기서 읽혀야 하고, 무엇은 다른 표면으로 넘어가야 하는지를 분명하게 보여주는 입구여야 한다.
메인에서 직접 책임져야 하는 것
메인 사이트가 직접 책임져야 하는 것은 편집된 공개 글과 방향 제시다. Journal이 이 안에 있는 이유도 그래서다. 공지, 회고, 에디토리얼, 발표 요약은 메인에서 바로 읽히는 편이 맞다. 방문자는 처음 들어와서 커뮤니티의 분위기와 문제의식, 현재 흐름을 빠르게 파악할 수 있어야 한다.
이 역할을 잘하려면 메인 사이트는 아래 질문에 즉시 답해야 한다.
- CTRL은 무엇을 하는 곳인가
- 최근에 어떤 글이 발행됐는가
- 기술 문서는 어디에서 읽는가
- 실제 프로젝트와 저장소는 어디에서 보는가
- 참여하려면 어디로 가야 하는가
즉 메인은 설명과 발행, 라우팅을 맡고, 그 바깥에 있는 시스템의 역할을 대신하려 해서는 안 된다.
메인에서 직접 다루면 오히려 흐려지는 것
반대로 문서형 탐색과 저장소 상태, 토론은 메인에서 억지로 떠안지 않는 편이 더 명확하다.
Docs는 오래 읽히는 문서를 위한 공간이다. 섹션 구조, 관련 문서, 마지막 수정일, 단계별 설명, 반복 참조 같은 경험이 중요하다. 이런 문서는 타임라인 중심의 저널 UX 안에 섞는 순간 성격이 흐려진다.
Projects도 마찬가지다. 프로젝트의 실제 진행은 GitHub에서 일어나는데, 메인 사이트가 그 상태를 길게 복제하기 시작하면 정보가 늦게 갱신되거나 책임 경계가 모호해진다. 메인의 역할은 프로젝트를 설명하는 긴 본문을 품는 것이 아니라, 어떤 저장소가 있고 어떤 문서와 연결되는지를 또렷하게 보여주는 것이다.
토론 역시 전용 표면이 더 낫다. 질문과 답변, 패치 소식, 커뮤니티 반응은 스레드와 피드백이 중심이어야 하므로 메인 저널 문법과는 잘 맞지 않는다.
왜 이 구조가 더 “공식 사이트”처럼 보이는가
겉보기에는 기능을 많이 넣을수록 공식 사이트처럼 보일 것 같지만, 실제로는 역할이 분명할수록 더 단단하게 보인다. 방문자는 메인에서 아래 세 가지를 빠르게 확인할 수 있을 때 사이트를 신뢰한다.
- 무엇이 여기서 발행되는가
- 무엇이 다른 시스템으로 연결되는가
- 각 시스템이 왜 따로 존재하는가
이 구분이 명확하면 메인은 비어 보이지 않는다. 오히려 “여기는 발행과 방향 제시를 맡는 곳”이라는 인상이 강해진다. CTRL이 메인페이지에서 최신 Journal을 강하게 보여주고, Docs와 Projects를 별도 진입점으로 세우려는 이유도 이 때문이다.
Home이 해야 할 일
이 관점에서 Home은 단순 랜딩이 아니라, CTRL의 현재 흐름을 압축해서 보여주는 화면이어야 한다.
- 가장 최근에 발행된 저널 글
- 오래 남길 문서로 향하는 명확한 입구
- 진행 중인 프로젝트와 GitHub 연결
- 참여 CTA
Forum이 아직 없더라도 Home이 살아 있어야 한다는 기획 원칙도 같은 맥락이다. Home은 기능 수로 버티는 화면이 아니라, Journal + Docs + Projects 세 축만으로도 커뮤니티의 현재를 설명할 수 있어야 한다.
프런트 도어라는 말의 실제 의미
프런트 도어라는 표현은 디자인 비유가 아니라 운영 비유에 가깝다. 들어오는 사람은 여기서 전체 구조를 이해하고, 가장 읽기 쉬운 형태의 글을 먼저 만나고, 이후 자기 목적에 맞는 표면으로 이동한다. 메인 사이트는 이 이동이 자연스럽게 일어나도록 편집된 입구가 된다.
따라서 메인이 강해지려면 오히려 더 많은 것을 쌓는 대신, 무엇을 여기서 멈추고 무엇을 바깥으로 보내는지를 더 엄격하게 정해야 한다. CTRL의 메인 사이트는 바로 그 원칙 위에서 만들어질 예정이다.