product

요즘은 저장할 정보보다 저장해야 할 정보가 더 빨리 늘어납니다. 좋은 글을 읽다가 “이건 나중에 다시 봐야지” 싶으면 일단 어디엔가 넣어두게 되는데, 문제는 그다음입니다.

저장하는 순간에는 분명 중요해 보였는데, 막상 필요해졌을 때는 다시 찾기가 어렵습니다. 검색은 되는데 제목이 기억나지 않고, 제목은 기억나는데 어디에 저장했는지 모르고, 저장 위치는 기억나는데 왜 저장했는지는 더 모르겠습니다.

저도 꽤 오래 이런 방식으로 헤맸습니다.

  • 에버노트
  • 애플 기본 메모
  • 노션
  • 옵시디언
  • 구글 Keep

도구는 계속 바뀌었지만 문제는 비슷했습니다.

  1. 저장 자체가 생각보다 번거롭다
  2. 저장 규칙을 지키는 일이 금방 귀찮아진다
  3. 나중에 검색은 되더라도 저장 당시의 맥락은 남지 않는다
  4. 결국 “가장 빨리 넣을 수 있는 곳”으로만 흘러간다

한동안은 카카오톡 나에게 보내기가 사실상 기본 저장소였습니다. 당장 빠르다는 점에서는 꽤 괜찮았습니다. 그런데 링크가 쌓이기 시작하니, 이번에는 저장은 쉬운데 꺼내오는 게 다시 어려워졌습니다.

결국 제가 원했던 건 “정리 잘하는 사람만 유지할 수 있는 시스템”이 아니었습니다. 귀찮은 날에도 계속 쓰게 되는 시스템이 필요했습니다.

저장 방식을 바꾸지 않고, 저장 규칙을 바꾸다

여러 도구를 바꾸다 보니 어느 순간 이런 생각이 들었습니다.

문제는 앱이 아니라, 저장할 때마다 판단이 필요하다는 점 아닐까?

어디에 넣을지, 어떤 제목으로 저장할지, 태그를 붙일지 말지, 지금 바로 메모를 남길지 나중에 정리할지. 이 작은 판단들이 쌓이면 저장 자체가 느려집니다.

그래서 저는 저장 방식을 더 똑똑하게 만드는 대신, 저장 규칙을 더 단순하게 만들기로 했습니다.

핵심 규칙은 하나입니다.

URL만 단독으로 보내면, 나중에 읽기용으로 자동 저장한다.

이 규칙을 OpenClaw로 묶어서 개인 워크플로우로 만들었습니다.

OpenClaw로 URL을 Keep에 저장하는 흐름

[메신저나 입력창에 URL 하나를 보내면, OpenClaw가 이를 받아 Obsidian의 Keep 노트에 저장하는 흐름을 3단계로 단순화한 다이어그램]

지금 동작하는 방식

제가 실제로 쓰는 흐름은 단순합니다.

  1. 좋은 글이나 참고할 링크를 발견한다
  2. 아무 설명 없이 URL만 보낸다
  3. OpenClaw가 그 링크를 “나중에 읽기” 항목으로 저장한다
  4. 나중에 필요할 때 대화형으로 다시 찾는다

예를 들면 이런 식입니다.

  • “그때 조쉬가 쓴 팀문화 글 링크 뭐였지?”
  • “어제 저장한 Threads 링크 찾아줘”
  • “지난주에 저장한 생산성 관련 글 다시 보여줘”

즉, 저장은 극단적으로 단순하게 하고, 검색은 문서 검색이 아니라 질문으로 처리하는 방식입니다.

파일명을 기억할 필요도 없고, 어느 폴더에 넣었는지 떠올릴 필요도 없습니다. 기억나는 단서 하나만 있으면 됩니다.

URL 입력부터 대화형 조회까지의 흐름

[`URL 입력 -> OpenClaw 저장 -> 나중에 대화형 조회` 흐름을 한눈에 보여주는 워크플로우 다이어그램]

실제로 쓰는 규칙

  • URL만 단독으로 보내면 자동 저장
  • 개발이나 디버깅 문맥처럼 의도가 애매하면 저장 전 한 번 확인
  • 저장 위치는 Obsidian 안의 Keep 노트로 통일
  • 나중에 키워드, 도메인, 날짜 기준으로 다시 조회 가능

중요한 건 기능이 많다는 점이 아니라, 저장할 때 고민할 요소가 거의 없다는 점입니다.

“이걸 어디에 저장하지?”가 사라지면 정보 관리의 절반은 이미 해결됩니다.

실제로 쓰는 저장 규칙 요약

[지금 워크플로우를 구성하는 저장 규칙 네 가지를 카드 형태로 정리한 요약 이미지]

이 방식이 계속 쓰일 수 있는 이유

1. 저장 부담이 거의 없다

좋은 시스템은 저장을 결심한 순간 거의 끝나야 합니다. 링크 하나 던지는 데 1초 이상 걸리기 시작하면, 사람은 다시 가장 쉬운 우회로로 갑니다.

이 방식은 저장 시점의 결정을 거의 없애버립니다. 분류와 정리는 나중 문제로 미루고, 일단 잃어버리지 않는 데 집중합니다.

이전 방식과 지금 방식의 저장 비용 비교

[저장하기까지 거쳐야 하는 단계 차이를 before/after로 비교한 이미지]

2. 검색의 미래는 “찾기”가 아니라 “묻기”

대부분의 저장 도구는 검색창에 정확한 단어를 넣는 방식에 익숙합니다. 그런데 실제 기억은 그렇게 남지 않습니다.

저는 보통 이렇게 기억합니다.

  • 그 글이 무슨 주제였는지
  • 어디서 봤는지
  • 언제쯤 저장했는지
  • 왜 저장했는지

대화형 조회는 이런 흐릿한 기억과 잘 맞습니다. 그래서 체감상 문서 검색보다 훨씬 덜 피곤합니다.

문서 검색과 대화형 조회의 차이

[정확한 키워드 검색과 대화형 조회의 차이를 대비한 비교 이미지]

3. 시스템이 내 습관을 억지로 바꾸지 않게 하기

새로운 도구를 도입하면 보통 “이제부터는 정리 습관을 잘 들여야지” 같은 다짐이 붙습니다. 그런데 그런 다짐은 오래가지 않습니다.

반대로 이 방식은 제 원래 습관을 크게 바꾸지 않습니다. 링크를 던지는 행동은 원래 하던 행동이고, 그 뒤 처리만 자동화합니다.

저는 이런 종류의 워크플로우가 실제로 오래간다고 봅니다.

앞으로의 확장 가능성

이 방식의 장점은 기본 규칙은 단순하지만, 나중 확장은 꽤 유연하다는 점입니다.

예를 들면 이런 것들을 붙일 수 있습니다.

  • 자동 태깅
  • 중복 링크 정리
  • 주간 저장 링크 요약
  • 특정 주제 링크 묶음 생성
  • 저장한 링크를 바탕으로 블로그 초안 만들기

다만 지금 단계에서 중요한 건 확장성이 아니라, 기본 흐름이 계속 살아남는가입니다. 아무리 멋진 기능이 많아도 저장 자체가 다시 귀찮아지면 결국 무너집니다.

마무리

지식 관리는 도구 싸움처럼 보이지만, 실제로는 저장 부담을 얼마나 줄이느냐의 문제에 더 가깝다고 생각합니다.

좋은 시스템은 정리를 열심히 하는 사람만 유지할 수 있는 시스템이 아니라, 귀찮은 날에도 계속 쓰게 되는 시스템이어야 합니다.

저에게는 그게 “URL만 보내면 저장되고, 나중에 대화로 다시 꺼내오는 방식”이었습니다.

아직 완성형이라고 보지는 않습니다. 하지만 최소한, 저장한 링크를 다시 못 찾는 문제에서는 꽤 멀어졌습니다. 그리고 지금 단계에서는 그 정도면 충분히 쓸 만한 개선입니다.

댓글남기기