쓰기도 전에 일 시키는 메모앱들
'노션이랑 뭐가 달라요'에 계속 제대로 답을 못 해서 메모앱들을 한 번 깔아놓고 봤는데, 다들 쓰기 시작하기 전에 뭔가를 시키고 있었어요. 그걸 안 시키려고 뭘 포기했는지 적어둘게요.
메모앱을 만들고 있다고 하면 거의 항상 이걸 물어봐요.
"그거 노션이랑 뭐가 달라요?"
그동안은 "AI가 알아서 정리해줘요"라고 답했는데 답하면서도 좀 찔렸어요. 요즘 그거 안 하는 앱이 없거든요. Mem도 하고 Tana도 하고 Notion AI도 해요. 그래서 이번엔 제대로 답해보려고 다른 메모앱들을 깔아놓고 리뷰랑 문서를 뒤졌는데, 자동 정리는 역시 차별점이 아니었고 대신 다른 게 걸렸어요. 앱마다 쓰기 시작하기까지 저한테 시키는 일이 완전히 달랐어요.
"저장에 품이 들거나, 셋업에 품이 들거나"
세 앱을 60일씩 써보고 쓴 비교 글에서 이 문장을 봤어요.
Notion은 저장에 품이 너무 들고, Obsidian은 셋업에 품이 너무 들고, Apple Notes는 되찾는 걸 사용자에게 떠넘긴다.
(출처)
읽자마자 아 이거구나 싶었어요. 셋 다 좋은 앱인데 저한테 일을 시키는 타이밍이 서로 다를 뿐이에요.
Obsidian은 첫날에 몰아서 시켜요. 폴더 규칙이든 링크 규칙이든 플러그인이든 제 시스템을 먼저 세워야 쓸 만해지는데, 대신 그렇게 세운 게 온전히 제 것이고 파일도 제 디스크에 남으니까 이걸 시킨다고 표현하는 게 맞나 싶기도 해요.
Notion은 담을 때마다 조금씩 시켜요. 어느 DB에 넣을지, 어떤 속성을 채울지. 빠른 메모 위젯이 있어도 "이거 어디 넣지"를 매번 묻는 건 똑같아요.
Tana는 앞에서 크게 한 번 시켜요. supertag를 붙이면 필드가 딸려오면서 노트가 데이터베이스 레코드가 되는 구조인데, 그 태그 체계를 제 일에 맞게 세우는 데 시간과 반복이 든다는 게 공통된 후기고 어떤 가이드는 손에 붙는 데 2주쯤 잡으라고 적어놨어요. (2주면 저는 아마 못 버텨요.)
Mem은 아무것도 안 시켜요. 폴더도 태그도 만들지 말라고 하니까요. 근데 리뷰들이 공통으로 짚는 한계가 구조적인 도구를 쓰던 사람은 수동 제어가 부족하다고 느낀다는 거였는데, 생각해보면 시킬 게 없는 이유가 애초에 제 구조가 없어서예요.
Apple Notes도 안 시켜요. 대신 정리도 안 해줘요.
표로 그려보니 이렇게 됐어요.
| 첫날 해야 하는 일 | 담는 곳 | 설정 화면 | 정리 | |
|---|---|---|---|---|
| Obsidian | 시스템·플러그인 설계 | vault·폴더 자유 | 매우 많음 | 나 |
| Notion | DB·속성 설계 | DB 여러 개 | 많음 | 나 |
| Tana | supertag 체계 설계 | 노드·데일리 노트 | 많음 | AI 제안 → 내 승인 |
| Mem | 없음 | 하나 | 적음 | AI |
| Apple Notes | 없음 | 폴더 | 적음 | 안 함 |
| camemot | 없음 | Inbox 하나 | 세 칸 | AI 또는 끌어다 놓기 |
우리는 맨 아랫줄을 골랐어요. 첫날에 아무것도 안 세우고 바로 담기 시작하는데 트리는 계속 제 것으로 남는 자리인데, 말이야 쉽지 이걸 지키려면 코드에서 계속 뭔가를 안 만들어야 해요.
로그인하면 이미 다 돼 있어요
첫 로그인이 끝나면 서버가 워크스페이스를 하나 만들어줘요. 그 트리가 이게 전부예요.
// 첫 로그인이 만들어주는 트리 전부
const DEFAULT_TREE = [
{ key: "todo", name: { ko: "할 일", en: "To do" } },
{ key: "ideas", name: { ko: "아이디어", en: "Ideas" } },
{ key: "archive", name: { ko: "보관", en: "Archive" } },
];
const DEFAULT_FALLBACK_KEY = "archive"; // 애매한 메모가 떨어질 자리
세 칸이에요. 중요한 건 마지막 줄인데, 분류가 애매한 메모가 갈 자리를 우리가 미리 정해두는 거라서 결과적으로 트리의 "빈 상태"를 0개가 아니라 1개로 정의하게 됐어요. 노드가 아예 없는 워크스페이스는 만들어지지 않아요. 이게 없으면 첫 화면이 "먼저 분류 체계를 만드세요"가 되는데, 없애려던 게 딱 그거였어요.
템플릿도 같은 규칙으로 묶었어요. 직군별로 6종을 주는데 1단 6칸을 안 넘기고, 나누는 축도 업무 분야가 아니라 메모의 종류(할 일·아이디어·알게 된 것)로 잡았어요. 분야로 쪼개면 담는 순간에 "이건 업무인가 개인인가"를 판단해야 하는데, 그 판단 없애자고 만든 앱이라 그렇게 하면 앞뒤가 안 맞아요.
첫 로그인 투어도 네 곳만 보여주고 끝나요. 입력창, Inbox, 정리 버튼, 트리. 스펙에 "아무것도 시키지 않는다"라고 한 줄 박아뒀는데, 담아봐라 정리해봐라 없이 그냥 읽고 넘기면 끝나게 하려고 그랬어요. 체크리스트 같은 것도 안 만들었고요. (이건 나중에 온보딩 완주율 같은 걸 재보자는 얘기가 나오면 흔들릴 것 같긴 해요...)
담는 곳은 하나예요
데일리 노트도 없고 프로젝트별 노트도 없고 DB도 없어요. 입력창에 적고 Enter. 그게 전부예요.
담기 함수도 지금 이만큼이에요.
// 담기가 하는 일 전부 — 여기서 모델을 부르지 않는다
async capture(workspaceId: string, userId: string, dto: CreateMemoDto) {
await this.assertWorkspace(workspaceId, userId);
return this.prisma.memo.create({
data: { workspaceId, content: dto.content, status: "inbox" },
});
}
임베딩도 자동 태깅도 요약도 없어요. 스펙의 첫 번째 불변식이라 아예 코드 경계로 막아놨는데, 모델 호출은 AiService 한 곳만 하고 분류기는 담기 쪽을 아예 모르게 해뒀어요. 이러니까 딸려오는 게 하나 있는데, AI가 죽어도 담기는 돼요. 모델 키가 없어도 API가 장애여도 이번 달 AI 한도를 다 써도 입력창은 그대로 동작하고, 한도 초과는 정리 버튼만 막아요.
담는 곳을 하나만 둔 이유는 단순한데, 담는 곳이 둘이면 담을 때 고르게 되고 그 순간 "잠깐, 이건 어디에?"가 돌아오기 때문이에요. 같은 이유로 메모는 한 번에 한 곳에만 살아요. (스키마는 그래도 다대다로 짜놨어요. 나중에 다중 태그를 열더라도 마이그레이션은 없게 하려고요.)
설정 화면이 세 칸이에요
설정에 있는 건 계정, 일반(테마랑 언어), MCP 연결. 이게 다예요.
없는 게 더 많아요. 플러그인, 단축키 설정, 뷰·필터 설정, 동기화 설정. AI 모델도 프롬프트도 confidence 임계값도 안 묻고 전부 env로 우리가 정해요.
임계값을 설정으로 열어줄까 잠깐 생각해보긴 했는데, 열어놓으면 사용자가 "0.7이 맞나 0.8이 맞나"를 알 방법이 없어서 그만뒀어요. 모르는 걸 물어보는 설정은 선택지가 아니라 불안인 것 같아요. (물론 이건 제 생각이고, 열어달라는 사람이 나오면 또 모를 일이에요.)
MCP 연결도 같은 식으로 짰어요. 첫 로그인 때 서버가 연결 키를 미리 끊어놔서 설정에 들어가면 붙여넣을 스니펫이 이미 완성돼 있고, 키 발급하고 이름 짓고 복사하는 단계를 사용자한테 안 넘겨요.
단순한 건 가만두면 안 단순해져요
기능이 늘면 설정이 늘고 설정이 늘면 첫날이 무거워지니까, 몇 개는 아예 못 자라게 박아놨어요.
AI는 새 노드를 못 만들어요. 제 트리에 이미 있는 것 중에서 고르기만 하는데, 부탁이 아니라 structured output의 enum으로 막아놔서 유효한 노드 밖을 고를 방법이 구조적으로 없어요. 자동 태깅에 자유를 주면 "회사"랑 "직장"이랑 "업무"가 따로 생기면서 목록이 번식하는 게 제일 무서웠거든요.
노드는 50개, 깊이는 4단계까지. 이 숫자는 취향이 아니라 역산한 값인데, 트리의 노드 목록이 그대로 위의 enum이 되고 enum 값이 250개를 넘어가면 글자 수 제한이 하나 더 붙길래 거기서 한참 아래로 잡았어요.
애매해도 안 물어봐요. confidence가 임계값 아래면 되묻는 대신 기본 자리로 보내는데, 승인 큐는 일부러 안 만들었어요. "이 메모 여기 넣을까요?"가 쌓이면 그건 분류 숙제를 나중의 저한테 다시 넘기는 거라서요. 틀리면 끌어다 옮기면 되고 고치는 비용이 매번 승인하는 비용보다 싸다는 데 걸었는데, 이건 아직 가설이에요.
정리하는 입구는 셋인데 결과는 같아요. 끌어다 놓기, AI 버튼, MCP로 붙은 에이전트가 다 같은 함수 하나를 지나요. 입구마다 결과가 다르면 "이건 AI한테 맡겨도 되나"를 또 판단하게 되니까요.
MCP 툴은 넷뿐이고 AI 정리 툴이 없어요. 부르는 쪽이 이미 모델이라 넣을 이유가 없었고, 삭제나 트리 편집이나 키 관리도 안 넣었어요.
그래서 못 하는 것들
자기 약점 안 쓰면 광고랑 다를 게 없으니까 같이 적어요. 위에 쓴 결정들은 전부 뭔가를 못 하게 만들어요.
- 검색이 없어요. 지금은 트리에서 노드를 열어 꺼내요. 위에 인용한 "저장과 찾기 사이의 간극"을 우리도 절반만 메운 셈이에요.
- 커스터마이즈가 없어요. 설정이 세 칸이라는 건 취향에 맞출 방법도 없다는 뜻이라 Obsidian 잘 쓰는 사람한테는 답답할 거예요.
- 큰 트리를 못 쌓아요. 50개에 4단계는 지식 베이스를 키우는 용도가 아니에요.
- 뷰도 필터도 정렬도 없어요. Inbox는 시간순 하나예요.
- 팀 공유가 없어요. 개인용이에요.
- 제 디스크에 파일로 안 남아요. 로컬 소유권이 중요하면 Obsidian이 맞아요.
아직 모르는 것들
- 다른 앱 얘기는 문서랑 리뷰 보고 쓴 거예요. 전부 직접 오래 써보고 쓴 게 아니고, 특히 Tana 자료 중엔 Tana가 직접 쓴 비교 글도 있어서 자기한테 유리하게 적혀 있다고 보고 읽어야 해요.
- 단순해서 좋다는 말이 오래 쓴다는 뜻인지 모르겠어요. 첫인상에서는 칭찬받기 쉬운데 두 달 뒤에도 같은 말인지는 아직 못 봤어요.
- 3칸이 맞는 숫자인지도 모르겠어요. 할 일·아이디어·보관으로 둔 건 그냥 감이었고, 다섯 칸이 나을 수도 있고요.
- 기본 자리로 떨어지는 비율을 안 재봤어요. 이게 높으면 "안 물어본다"는 결정부터 다시 봐야 해요.
지금은 로그인하면 세 칸짜리 트리랑 Inbox 하나가 있고 설정에서 고를 건 테마랑 언어뿐인데, 이게 맞는 방향인지는 솔직히 아직 잘 모르겠어요. 담는 순간에 머리 안 쓰게 하자고 시작한 건데 그러다 보니 못 하는 게 계속 늘어나서, 언젠가 "이건 좀 심한데" 소리가 나오면 그때 하나씩 열어야 할 것 같아요. 아마 검색부터 붙이게 될 것 같고요.