사이트를 설계할 때 Projects를 가장 쉽게 오해하기 쉬운 방식은, 또 하나의 콘텐츠 섹션처럼 생각하는 것이다. 프로젝트 카드가 있으니 상세 페이지도 길게 만들고, 설명도 사이트 안에 다 넣고, 저장소 상태도 여기서 보여주자는 식이다. 하지만 CTRL은 Projects를 그런 본문 시스템으로 보지 않는다.
CTRL에서 Projects는 GitHub 작업을 읽기 좋게 연결해 보여주는 디렉터리에 더 가깝다.
왜 사이트 안에서 모든 설명을 다 하지 않는가
프로젝트의 실제 작업 공간은 GitHub다. 저장소, 이슈, PR, README, 변경 이력, 협업의 흔적이 모두 그곳에 있다. 그런데 메인 사이트가 이 상태를 별도로 길게 복제하기 시작하면 몇 가지 문제가 바로 생긴다.
- 정보가 늦게 갱신된다.
- 어느 쪽이 최신인지 헷갈린다.
- 메인 사이트가 작업 상태를 흉내 내는 중복 표면이 된다.
- 운영자가 불필요한 수동 정리를 계속 떠안게 된다.
이 문제를 피하려면 Projects의 역할을 처음부터 줄이는 것이 아니라, 정확하게 정의해야 한다. 즉 메인 사이트는 프로젝트 작업을 대신하는 곳이 아니라, 어떤 저장소가 있고 왜 중요한지를 보여주는 입구가 되어야 한다.
그럼 Projects는 무엇을 보여줘야 하는가
CTRL이 생각하는 Projects 화면에는 아래 정도면 충분하다.
- 저장소 이름과 간단한 설명
- GitHub 링크
- 현재 상태를 짧게 설명하는 라벨
- 관련 Docs 링크
- 필요 시 순서와 노출 여부를 조정하는 운영용 메타
이 정도면 방문자는 프로젝트의 존재를 이해하고, 자세한 설명이 필요하면 Docs로, 실제 작업 흐름이 궁금하면 GitHub로 이동할 수 있다. 메인은 흐름을 연결해주고, 각 표면은 자기 역할을 유지한다.
긴 설명은 어디에 남기는가
Projects를 짧게 가져가면 설명이 사라지는 것이 아니라 위치가 분명해진다. 장기적으로 읽혀야 할 배경 설명, 구조 정리, 사용 방법, 비교 노트는 Docs로 가는 편이 맞다. 반대로 진행 상태와 협업 흔적은 GitHub가 맡아야 한다.
이렇게 보면 Projects는 빈약한 섹션이 아니라, 오히려 책임이 명확한 섹션이 된다. 저장소 목록을 보기 좋게 정리하고, 어디로 넘어가야 하는지 분명하게 안내하는 역할이다.
왜 이 구조가 운영에도 유리한가
CTRL은 처음부터 Journal, Docs, Projects의 운영 방식을 다르게 보려고 한다. Journal은 빠르게 발행되는 글 시스템이고, Docs는 장기 문서 시스템이다. Projects는 이 둘과 달리 콘텐츠를 많이 쌓는 곳이 아니라 연결과 상태 표시를 담당한다.
이 경계를 분명히 하면 운영 부담도 줄어든다. 글은 저널에, 설명은 문서에, 실제 협업 상태는 GitHub에 남기면 되기 때문이다. 모든 층을 메인 사이트가 혼자 책임지려 하지 않아도 된다.
프로젝트를 보여주는 가장 좋은 방법
결국 프로젝트를 잘 보여준다는 것은, 사이트 안에서 더 많은 문장을 쓰는 것이 아니다. 오히려 아래가 더 중요하다.
- 이 저장소가 왜 여기 있는지 짧고 분명하게 설명할 것
- 관련 문서로 자연스럽게 연결할 것
- 실제 작업이 일어나는 곳으로 곧바로 보낼 것
Projects를 GitHub-linked directory로 본다는 것은 기능을 포기하는 것이 아니라, 각 시스템의 강점을 살리는 선택에 가깝다. CTRL이 이 구조를 택한 이유도 바로 여기에 있다.