1. 기록의 함정: 보관인가, 활용인가?
우리는 습관적으로 노션(Notion)에 기록을 쌓는다. 하지만 시간이 흐를수록 노션은 '데이터의 무덤'이 되기 일쑤다. 기록은 늘어나는데, 그 안에서 인사이트를 뽑아내려면 다시 사람이 일일이 읽거나, 귀찮은 익스포트 과정을 거쳐 LLM에 던져줘야 한다.
최근 비개발자들로 구성된 'SELFISH AAA' 팀의 사례를 접하며 뒤통수를 맞은 기분이 들었다. 그들은 노션을 버리고 옵시디언(Obsidian)과 GitHub으로 갈아탔다. 단순한 툴 교체가 아니라, 기록을 '데이터베이스'화하여 흐르게 만든 것이 핵심이다.
2. 왜 하필 옵시디언인가? (개발자적 관점)
개발자에게 옵시디언은 단순한 노트 앱이 아니다. 로컬 마크다운(.md) 기반의 파일 시스템이다. 이 점이 왜 강력한가?
- 데이터 접근성: 데이터가 SaaS의 클라우드가 아닌 내 로컬 디스크에 있다. 즉, 내 쉘(Shell) 환경에서 파일에 직접 접근할 수 있다.
- LLM과의 궁합: Claude Code 같은 터미널 기반 AI 도구들이 내 노트를 즉시 스캔할 수 있다. 별도의 API 연동이나 복잡한 파이싱이 필요 없다.
- 버전 관리: Git을 통해 기록의 히스토리를 추적하고, 특정 시점의 데이터로 롤백하거나 브랜치를 딸 수 있다.
3. 기록이 콘텐츠가 되는 자동화 파이프라인
이 팀이 구축한 구조는 우리 개발자들에게 익숙한 CI/CD 파이프라인과 닮아 있다.
- Write: 옵시디언에서 마크다운으로 과제(데이터) 작성.
- Push: Git 저장소에 커밋 및 푸시.
- Process (LLM): Claude Code가 로컬/원격 저장소의 파일을 읽어 분석.
- Deploy: 분석된 데이터를 바탕으로 링크드인 게시글 초안 생성 및 팀 웹사이트 업데이트.
사람은 '기록'만 했을 뿐인데, 시스템(AI)이 그 기록을 재료로 '브랜딩'과 '분석'이라는 결과물을 자동으로 빌드해낸다.
마치며: 도구가 아니라 '흐름'을 설계하라
비개발자들이 Claude Code를 써서 본인들의 OS를 만드는 시대다. 8년 동안 코드를 짠 나에게 '기록'은 어떤 의미였는가? 단순히 저장하는 데 급급했다면, 이제는 AI가 읽기 좋은 구조로 데이터를 배치하고 자동화할 때다.
도구를 바꾸는 것은 어렵지 않다. 중요한 건 내 기록이 '고여있는 호수'인지, 결과물을 만들어내는 '흐르는 강물'인지 점검하는 것이다
LIST
'Software > Maker(Spring & Python & node)' 카테고리의 다른 글
| 하네스 엔지니어링(Harness Engineering): AI 에이전트 시대의 진짜 경쟁력 (0) | 2026.04.09 |
|---|---|
| 남의 기록 시스템을 보며, 나도 내 삶을 기록할 구조를 고민하게 되었다 (0) | 2026.04.07 |
| 캐싱에서 놓치기 쉬운 동시성 문제 5가지 — 장애는 항상 캐시에서 시작된다 (0) | 2026.04.07 |
| Java LTS vs Kotlin 롤링 릴리스: 오라클과 젯브레인의 언어 지원 정책, 뭐가 다른가 (0) | 2026.04.06 |
| Reverse Proxy vs API Gateway vs Load Balancer 비교 분석 (0) | 2026.04.06 |
