당신이 이 글을 보고 있는 웹사이트의 첫 번째 버전인 solmee.xyz 1.0.0의 기획과 개발 과정을 다루는 문서이다. 이 프로젝트의 목표는 기록을 생성하고, 기록한 것을 나중에 편집하고 접근할때 낭비되는 시간을 줄이는 것이다. 목표를 달성했는지는 작성 시점에 알 수 없지만 1년 후에도 이걸 사용하고 있다면 달성했다고 볼 수 있을 것이다.
이 웹사이트를 만들게 된 배경
번아웃으로 기말고사 공부를 세상 끝까지 미루던 24년 6월, 나는 공부를 하는 대신 내가 왜 공부를 하지 않는지에 대해 생각하는 것을 택했다. 내용물이 아닌 내용물이 정리되는 구조에 한눈을 팔게 하는 비효율적인 기록 시스템이 문제라고 생각했다.
당시 했던 생각들이다.
- 줄글의 존재 이유는 문법요소에 있고 줄글의 단점은 하이퍼텍스트가 보완한다
- 시간의 흐름에 저항하려면 시간의 좌표계를 제거하면 된다
- prescribe된 계층적 구조로 노트를 정리할 때 불편한 점
- 사소한 원인으로 인한 삽질이라도 가감없이 기록해 놓는 것이 좋다
- 서로 다른 두 개 이상의 도메인에서 지식 줍기의 힘든 점과 장점
시간 순서가 아닌 노트 간의 연결을 통해 구조가 귀납적으로 형성되는 도구인 Obsidian을 써 보게 되었다. 노트들은 여기저기 발산되어 있는데 막상 결과물을 내놓으려 하면 밑바닥부터 쌓아올려야 함에 좌절하고 있었던 나에게, 글쓰기는 선형적이지 않으며 지금까지 해놓은 생각을 엮는 것일 뿐이라는 Zettelkasten의 가르침이 와 닿았다.
Obsidian에 대한 글들을 읽다 보니 Digital Garden이라는 개념도 자주 보게 되었다. 비정형적이지만 꾸준히 관리되고 있는 상태의 정원처럼 내 컨텐츠들을 공개적인 웹 공간에 심어 놓고 가꾸어 나간다는 아이디어였다. 완벽하게 완성된 출판물이 아니더라도 내가 가진 것을 불특정 다수와 공유하는 것은 지금껏 인터넷에서 정보를 얻으며 항상 꿈꾸던 것이었다.
그래서 Obsidian 플러그인을 사용해서 만들었었는데, 남이 만든 골격을 사용하는 것이라서 만족스럽지 않았다. 그리고 내비게이션 툴로 그래프 뷰와 사이드바가 공존했는데 사이드바의 존재가 앞서 말한 ‘컨텐츠 자체보다 구조에 한눈팔게 한다’는 문제를 전혀 해결하지 않았다. IndieWeb Principle을 알게 되었고 거기서 주장하는 것들, 예를 들어 ‘네 데이터를 소유해라’, ‘너에게 필요한 것을 만들어라’, ‘네가 만든 것을 사용해라’, ‘특정 기기, UI, 언어, API, 백엔드, 데이터베이스, 플랫폼에 귀속되지 않도록 모듈화해라’ 에 감명받았다. 그래서 플러그인을 사용하지 않고 직접 다시 만들기로 했다.
기획 과정의 생각들
지금까지 만들어본 웹사이트는 모두 장기적인 목적을 가지고 만든 것이 아니었고, 이전 프로젝트들보다 장기 프로젝트가 될 것이었다. 그래서 혼자 만드는 것보다 계속 피드백을 받아야겠다고 생각해서 학교에서 졸업 예정인 학생들을 위해 자유 주제로 프로젝트를 하는 수업을 수강신청해서 과제로 했다. 1-2주에 한 번씩 교수님들께 발표하고 피드백을 받는 것은 기획과 UX 측면에서 내 생각에만 틀어박히지 않게 하는 데 큰 도움이 되었다.
예를 들어서 나는 사이드바가 모든 문제의 원흉이라고 생각해서 무작정 없애 버리고 Obsidian을 통해 알게 된 새로운 내비게이션 도구인 네트워크 그래프만 아주 크게 넣으려고 했다. 그건 Zettelkasten의 Bi-Directional Link 개념을 시각화한 것이었다. 하지만 내가 간과했던 사실은 Zettelkasten은 마지막 단계인 ‘출판’이 아닌 ‘초안 쓰기’를 위한 방법론이었다는 것이다. 그에 비해 웹은 ‘출판’에 가까웠다. 심지어 웹은 종이 출판물보다 효율성이 더 중시된다. 종이책은 기록을 목적으로 탄생했지만 웹은 탄생할 때부터 공유를 목적으로 했기 때문이다. 게다가 사람들은 종이책보다 웹에서 더 쉽게 이탈한다. 사람들이 그래픽을 보고 3초 감탄한 뒤 이탈하는 웹사이트를 만드는 것은 내 목적이 아니었다.
그래서 새로운 내비게이션과 정리 방식을 실험하면서 동시에 사용자 경험도 해치지 않기 위해 이런저런 시안을 생각해 보며 몇 주를 보냈다. 최종은 매우 단순해졌다. 홈에서는 네트워크 그래프를 숨겨놓고, 글로벌 그래프를 띄울 수 있는 아이콘을 잘 보이는 곳에 놓는다. 노트 안에 들어가면 작은 창으로 지역 그래프를 띄워 놓고, 그래프가 익숙하지 않은 사람들을 위해 숨길 수 있는 버튼을 마련해 놓는다. 내비게이션 바에는 각 노트 타입에 해당하는 노트가 시간 순으로 정렬되어 있는 페이지를 링크한다.
내비게이션 바
글로벌 그래프
로컬 그래프
웹사이트에 들어갈 컨텐츠는 내가 평소에 생성하는 노트의 종류 중 Digital Garden, 즉 공유된 지식 저장소라는 공간의 성격에 부합하는 것을 걸러서 세 가지로 정했다.
- 일반 메모
- 작업 과정 기록
- 포트폴리오
이런 것들은 이 웹사이트에 들어가지 않는다.
- 프로젝트 기획안 → UpNote와 Notion을 사용한다.
- 계속 수정되는 프로젝트 대시보드 → UpNote와 기본 메모장 어플을 사용한다.
- 개인적인 일기 → UpNote에 임시로 쓰고, Journal Shrine에 영구 보관한다.
네트워크 그래프 디자인하기
네트워크 그래프는 노트 안의 내부링크들을 시각화한다. 그래프의 Node 즉 점이 노트를, Link 즉 선이 링크를 나타낸다. 여기서 노드의 디자인을 어떻게할지 고민을 많이 했다. 각 노트의 태그에 따라 형태와 색이 자동으로 생성되는 심볼 시스템을 만들려고도 했었는데, 피드백을 거치며 지나친 정보를 줄여 나갔다.
- 색이 많아지면 의미가 줄어든다
- 인지할 수 있는 색의 개수에 한계가 있다
- 형태보다 색의 구분이 빠르게 인지된다
내가 만들려는 그래프의 정확한 정의를 해 보았다. 먼저 링크의 방향이 없고, 링크의 중요도에 구분이 없는 Undirected and unweighted 이다. 그리고 각 글의 컨텐츠보다 전체 맥락이 중요한, 예를 들어 학자들이 서로에게 편지를 보낸 것에 대한 그래프를 그릴 때 편지의 내용이나 학자의 출생지 같은 게 아닌 어느 학자가 어느 학자에게 편지를 보냈는지가 중요한 메타데이터 네트워크이다. 그래서 자세한 노드나 링크의 정보는 나타낼 필요가 없다. 그 자체로 정보를 전달하기 위한 그래프가 아닌, 클릭해서 내용을 보기 위한 내비게이션 도구일 뿐이니까.
노드의 색과 크기에는 구분을 주기로 했다. 시각적으로 중심이 어디인지 분별되게 하기 위해 링크가 많이 연결된 노드의 크기를 크게 하고, 노드의 색은 노트의 타입에 따라 3가지 색을 부여했다.
컬러 팔레트 (라이트 모드)
인터랙션에는 줌, 패닝, 드래그, 호버가 있다. 호버를 하면 해당 노드와 거기에 depth 1로 연결된 링크, 노드에만 색을 넣고 나머지는 opacity를 낮춘다.
이어서 디자인
노트 타입의 라벨링: 어떤 Digital Garden은 노트의 성숙된 정도에 따라 Seedlings - Saplings - Trees라는 비유적인 단어를 붙이기도 했다. 나의 분류도 어떻게 보면 연속성을 갖긴 한다. 일반 메모들이 프로젝트의 씨앗이 되고, 프로젝트를 진행하면 그 결과로 포트폴리오가 나오기 때문이다. 하지만 그런 연속성보다는 각 타입들끼리의 연관성이 더 강하기 때문에 Journal, Logbooks, Works라는 좀더 평범하고 직관적으로 이해되는 이름을 붙였다.
노트 타입별 레이아웃: Journal은 그냥 노트, Logbook은 한 프로젝트 하위 노트들을 만들고 거기에 순서를 달아서 밑에 이전/다음 글로 가는 버튼을 둔다, Work는 레이아웃을 이미지가 강조되게 한다 이런 것들.
Logbooks의 SequenceNav 컴포넌트
내부링크: 내부링크에 호버하면 팝업창으로 해당 노트의 컨텐츠가 뜬다. 스크롤 가능하다. 그리고 동시에 네트워크 그래프의 해당 노드에도 호버한 것과 같은 효과가 적용된다.
외부링크: ’↗’ 문자가 뒤에 붙는다. 팝업창이 뜨는 대신 url이 툴팁으로 보여진다. 클릭하면 새 탭으로 열린다.
반응형 디자인: 네트워크 그래프 숨김/보임, 테마 버튼과 네비게이션바의 위치 변화, 타이포그래피 변화, 모바일 뷰일 때 ‘맨 위로 스크롤’ 버튼 추가
검색: 내비게이션 바에서 Search 클릭 시 모달로 열림.
네트워크 그래프에서도, 그리고 웹사이트 전체구조에서도 뭔가 실험적이지만 실용적이지 않은 것들을 계속 넣으려고 하다가 피드백 후 재고하고, 덜어내고, 정말 필요한 것만 남기는 것을 반복했다. 반 년동안 잘 쓴 걸 보면 필요한 것만 잘 남긴 것 같다. 그리고 내 개발 능력치를 벗어나지 않아 최종 발표일까지 넉넉하게 웹사이트 개발을 완성할 수 있었다.
개발
기획과 디자인을 하는 동안 마크다운 파일 배포 방법에 대해 조사했다. 그리고 어떤 SSG 프레임워크를 사용할지 결정했다. 도메인을 구매하고 적용했다. 전체 16주 중 10주차쯤부터 개발을 시작했다. 개발을 하면서도 계속해서 디자인을 디벨롭했다.
Astro를 SSG 프레임워크로, Obsidian을 텍스트 에디터로 사용한다. Obsidian은 Vault로 정한 로컬 디렉토리에 마크다운 파일들을 저장한다. 내 노트 타입은 Journal, Logbook, Work 총 세 개. 이 타입에 따라 프론트매터들도 다르다. 예를 들어 Journal의 프론트매터는 이렇게 생겼다.
---
aliases:
- 새로운 블로그 개발 계획하기
layout: ../../layouts/JournalsLayout.astro
type: journals
date: 2025-06-09
tags:
- web
---
Astro 내부의 이미지와 마크다운 폴더를 Obsidian Vault의 이미지와 마크다운 폴더에 각각 Symlink를 걸어서 싱크를 시켰다. 그래서 Obsidian에서 글을 쓰고 이미지를 링크하면 웹사이트에서도 똑같이 글이 들어가고 이미지가 링크된다.
- assets
- ...
- markdown
- markdown
- ...
이때 글과 이미지 사이의 상대경로가 Obsidian이랑 웹사이트에서 같게 하기 위해서 Obsidian Vault의 파일 구조를 임의로 이렇게 만들어야 했다.

그래서 이렇게 상대경로를 적어야 한다.
Obsidian의 내부링크 신택스는 이렇다. [[
파일명 #
내부 소제목 |
별명 ]]
. [[solmee-1-0-1|solmee.xyz 1.0.1: 빌드 메모리 초과 에러 고침]]
이것을 링크로 <a href="/markdown/solmee-1-0-1">solmee.xyz 1.0.1: 빌드 메모리 초과 에러 고침</a>
변환하기 위해 remark-wiki-link라는 라이브러리를 사용했다.
마크다운의 ’- >‘를 리가처 ’→‘로 바꾸기 위해 unist-util-visit을 사용했다. gray-matter를 사용해 마크다운 파일을 파싱해서 1. frontmatter에서 aliases를 뽑아 그래프의 노드 데이터를 만들고 2. content에서 내부링크를 뽑아 그래프의 링크 데이터를 만들었다.
검색은 fuse로도 만들어보고 Pagefind 로도 만들었는데 Pagefind가 더 기능이 많아서 그것만 남겼다. 컴포넌트는 .astro로도 만들고 React integrate해서 .jsx로도 만들었다.
Table of content는 이 블로그 글을 참고해서 만들었다. 뉴스레터를 위해 수집한 이메일 저장과 과제전 기간 동안의 방명록 저장은 Firebase Realtime Database를 이용했다. 배포는 Vercel에서 했다.
네트워크 그래프는 force-graph 라이브러리를 사용했다. 가장 어려웠던 거는 그래프를 위한 모달을 띄우는 것과 글로벌그래프, 로컬그래프의 상태가 서로 영향을 주고받는거를 방지하는 것이었다. 자세히는 기억 안나지만 어떻게든 해결했다. 노드에 색깔넣고, 인터랙션 넣고, 필터링 넣고, 지역그래프의 주인공 노드에 아웃라인을 그려 표시하고, 주인공 노드를 센터로 이동시키는 등 약간의 커스터마이징을 했다.
반응형 타이포그래피는 utopia의 css변수를 이용했다. 브레이크포인트 없이 부드럽게 요소들의 크기를 조절할 수 있도록 하는 도구였다. CSS의 미디어쿼리도 이용했다. 웹사이트 내의 큼직한 덩어리들은 CSS Grid를 이용해 배치했다.
애널리틱스는 goatcounter를 이용했다.
개발과정에는 이런 글들을 썼다.
그래서 결과적으로 현재 내가 이 웹사이트에 글을 쓰는 방법은 이렇다: 글에 넣을 이미지를 정리하고 파일명을 다시 짓는다, assets 폴더에 집어넣는다, 옵시디언을 켜서 새글을 만들고 프론트매터 템플릿을 삽입한다, 프론트매터를 쓰고 글을 쓰고 이미지를 링크하고 웹사이트 내 다른 글을 링크한다, npm run dev로 미리보기를 한다, npm run build로 빌드가 되는지 확인하고 Commit한다, 그러면 자동으로 배포된다.
아쉬움
리액트 상태관리 어떻게하는지 잘 몰라서 최대한 모든것을 CSS로 하려고 했고, CSS를 이상하게 썼는데 예를 들어 ‘링크에 호버하면 팝업창 뜨는거 안뜨는 경우를 모조리 나열하기’ 같은 어이없는 짓들을 많이 했다.
가끔 프론트매터에 값을 잘못넣어서 에러가 뜨는데 이런 에러 처리가 부족하다.
현재 그래프에서 노드끼리 쌍방 링크된 경우 링크가 중복 처리돼서 노드 크기가 두 배로 커지는데 이거 수정해야 한다.
Logbooks에 순서를 직접 매겨줘야 하는게 너무 노동이다. 더 쉽게 또는 자동으로 순서가 매겨져야 한다. 그리고 프로젝트 안에 어떤 노트들이 있는지 프로젝트 클릭 전에도 볼 수 있었으면 좋겠다. 그리고 Journal과 Logbooks 사이의 구분이 필요한 것인지 생각해 봐야겠다.
컴포넌트와 함수들 리팩터링 해야 하고 상태관리 더 잘해야 한다.
필터링과 정렬 등 메타데이트를 활용한 노트 탐색 기능을 확장하고 싶다. 그리고 전역그래프의 태그 필터링 화면에 태그가 너무 많이 펼쳐져있는거 고쳐야 한다.
배경음악 기능 넣고싶고 이미지 carusel 컴포넌트 넣고싶다. 타이포그래피 고쳐야한다. Table of Content 고쳐야 한다.
더 재밌는거 넣고싶다.