TECH 으로 돌아가기
TECH HACKER NEWS 2026.10.29 10:04 8분 읽기 39 READS

같은 화이트보드, 다른 철학: Obsidian Canvas와 Heptabase를 데이터 구조로 비교하기

같은 화이트보드, 다른 철학: Obsidian Canvas와 Heptabase를 데이터 구조로 비교하기
SOURCE IMAGE · HACKER NEWS
같은 화이트보드, 다른 철학: Obsidian Canvas와 Heptabase를 데이터 구조로 비교하기

생각을 정리할 때 노트를 한 줄로 쭉 쓰는 대신, 화이트보드에 카드를 펼쳐놓고 화살표로 잇는 방식을 좋아하는 분들이 많아요. 이런 ‘비주얼 노트’ 도구 중에서 개발자들이 특히 많이 쓰는 게 Obsidian Canvas와 Heptabase예요.

겉으로 보면 둘 다 끝없는 캔버스 위에 카드를 올리고 선으로 잇는, 거의 똑같은 도구 같아요. 그런데 최근 두 도구를 아키텍처 관점에서, 그러니까 “데이터를 어떤 구조로 저장하느냐”를 기준으로 비교한 글이 나왔어요. 이 차이를 알면 어떤 도구가 내 작업 방식에 맞는지 훨씬 분명해지고, 덤으로 데이터 모델링 공부도 꽤 돼요.

Obsidian Canvas: 파일이 먼저, 캔버스는 그 위의 레이어

Obsidian의 기본 철학은 모든 건 내 컴퓨터에 있는 평범한 파일이라는 거예요. 볼트(vault)라는 폴더 안에 마크다운 파일이 쌓이고, 앱은 그 파일들을 보여주는 창일 뿐이에요.

Canvas도 이 철학을 그대로 따라요. 캔버스 하나는 .canvas 확장자를 가진 JSON 파일 하나이고, 이 포맷은 JSON Canvas라는 오픈 스펙으로 공개돼 있어요. 구조도 아주 단순해서 nodes(카드)와 edges(연결선) 배열 두 개가 전부예요.

{
"nodes": [
{"id": "a1", "type": "text", "text": "아이디어 메모", "x": 0, "y": 0, "width": 250, "height": 60},
{"id": "b2", "type": "file", "file": "notes/CRDT.md", "x": 400, "y": 0, "width": 400, "height": 300}
],
"edges": [
{"id": "e1", "fromNode": "a1", "toNode": "b2", "label": "참고"}
]
}

눈여겨볼 건 카드 종류예요. text 카드는 내용이 캔버스 JSON 안에 직접 들어가 있어요. 반면 file 카드는 볼트에 있는 마크다운 파일을 경로로 가리키기만 해요. 그래서 같은 노트를 여러 캔버스에 올리려면 파일 카드를 써야 하고, 텍스트 카드로 적은 메모는 그 캔버스 밖에선 따로 존재하지 않아요. 캔버스에서 그은 화살표도 .canvas 파일 안에만 기록되기 때문에 노트 본문의 [[위키링크]]와는 별개 정보예요.

Heptabase: 카드가 먼저, 화이트보드는 카드 배치도

Heptabase는 출발점부터 달라요. 여기서는 카드 자체가 1급 객체(혼자서도 존재하는 기본 단위)예요. 모든 카드는 카드 라이브러리에 따로 저장되고, 화이트보드는 “어떤 카드를 어디에 놓았는지”라는 배치 정보만 가져요.

그래서 같은 카드를 화이트보드 다섯 개에 올려도 실체는 하나뿐이고, 어디서 고치든 모든 곳에 반영돼요. 화이트보드 안에 하위 화이트보드를 넣는 것도 자연스럽고요. 대신 데이터는 Heptabase 자체 저장소에 들어가서 클라우드로 동기화돼요. 그래서 Obsidian처럼 아무 텍스트 에디터로 바로 열어볼 수는 없고, 필요하면 마크다운으로 내보내야 해요.

DB 설계로 비유하면 쉬워요

개발자 입장에서 보면 이 차이는 임베딩(embedding) vs 참조(reference) 문제와 딱 맞아떨어져요.

어느 쪽이 정답이라기보다는 이식성(portability)과 일관성(consistency) 사이의 트레이드오프예요.

업계 흐름 속에서

이 분야엔 다른 선택지도 많아요. Excalidraw와 tldraw는 손그림 느낌의 화이트보드가 강점이고, AFFiNE은 문서와 화이트보드를 하나의 블록 구조로 합치는 쪽을 택했어요. 크게 보면 “내 데이터는 내 기기에 평범한 파일로”를 외치는 로컬 퍼스트(local-first) 진영과, 클라우드에서 풍부한 관계를 다루는 진영이 경쟁하고 있는데요. Obsidian과 Heptabase가 각 진영을 대표하는 셈이에요.

한국 개발자에게 주는 팁

Obsidian을 쓰신다면 오래 남길 메모는 처음부터 파일 카드로 만드는 습관을 들이세요. 이미 만든 텍스트 카드도 우클릭 메뉴에서 파일로 바꿀 수 있어요. 그리고 JSON Canvas는 스펙이 단순해서 스크립트로 만들어내기 좋아요. 예를 들어 우리 서비스의 마이크로서비스 의존성이나 DB 테이블 관계를 파싱해서 .canvas 파일로 뽑으면, 아키텍처 다이어그램을 자동으로 만들 수 있어요.

반대로 리서치나 공부처럼 같은 개념을 여러 맥락에서 다시 엮을 일이 많다면 Heptabase의 카드 중심 모델이 더 편할 수 있어요.

마무리

겉모습은 같은 화이트보드여도, 그 도구로 할 수 있는 일과 없는 일은 데이터 구조가 정해요.

여러분은 노트 도구를 고를 때 데이터 이식성과 사용 편의성 중 어느 쪽을 더 중요하게 보시나요? 화이트보드 도구로 개발 업무를 정리해본 경험이 있다면 공유해주세요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://www.fluxlinks.com/blog/obsidian-canvas-vs-heptabase
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...