Samsung Notes 일기 158개를 비공개 위키로 바꾸고, 관련 일기 299쌍을 연결했습니다

📝 한줄 요약

Samsung Notes에서 내보낸 개인 일기 158개를 원본 그대로 보존하면서 날짜별 Markdown 페이지로 바꾸고, 공개 LLM Wiki와 분리된 비공개 저장소에 배치했습니다. 내용 유사도 분석으로 서로 관련된 일기 299쌍을 상호 [[wikilink]]로 연결한 뒤, 깨진 링크·고립 문서·비상호 링크·색인 누락을 모두 다시 검사했습니다.

공개 범위
이 글은 개인 일기의 본문·제목·원본 파일명·개인 경로를 싣지 않습니다. 라이브러리에 발행하는 대상은 개인 기록 자체가 아니라, 원본 보존·비공개 분리·의미 기반 연결·검증 절차를 정리한 public-safe 파생 사례글입니다.

🎯 이런 분들께 도움돼요

• Samsung Notes나 메모 앱에 개인 기록이 쌓였지만 나중에 다시 찾기 어려운 분

• 메모를 Markdown·Obsidian으로 옮기고 싶지만 원문이 바뀔까 걱정되는 분

• 개인 기록을 공개 지식베이스나 업무용 검색 인덱스와 섞고 싶지 않은 분

• 날짜순 목록을 넘어 서로 관련된 기록을 [[wikilink]]로 탐색하고 싶은 분

• AI에게 정리를 맡기더라도 원본·출처·검증 결과를 직접 확인하고 싶은 분

이 사례의 핵심은 일기를 더 많이 요약한 것이 아닙니다. 개인 기록을 안전하게 분리한 뒤, 다시 읽을 수 있는 관계망으로 바꾼 것입니다.

😫 문제 상황 (Before)

Samsung Notes는 기록을 시작하기에는 편리하지만, 기록이 많아지면 다음 문제가 생깁니다.

• 메모가 날짜와 내보내기 시각이 섞인 파일명으로 흩어집니다.

• 한 날짜에 여러 기록이 있으면 어떤 파일을 먼저 열어야 할지 불분명합니다.

• 날짜별로 찾을 수는 있어도, 내용상 이어지는 기록을 발견하기 어렵습니다.

• 원문을 정리하는 과정에서 표현이나 문맥이 바뀌면 기록의 증거성이 약해집니다.

• 개인 일기를 공개 LLM Wiki에 넣으면 검색·배포·공유 범위가 넓어질 수 있습니다.

• “Markdown으로 변환했다”는 사실만으로는 원본이 보존되었는지 알 수 없습니다.

실제 요청은 다음과 같이 시작되었습니다.

삼성노트에 내가 작성한 일기들이 있는데 그거 md로 가져올 수 있을까?

그리고 저장 경계와 연결 방식도 분명히 정해졌습니다.

개인 일기들인만큼 따로 저장하면 좋겠고, 내용상 관련있는 문서들끼리 [[ ]]로 연결하면 좋겠어

따라서 목표를 단순한 파일 변환으로 잡지 않았습니다.

Samsung Notes export
        ↓
원본 보존 + 작성일 판독
        ↓
비공개 Markdown 위키
        ↓
내용 기반 관련 일기 연결
        ↓
링크·색인·frontmatter·압축본 검증

🛠️ 사용한 도구와 자료

여기서 TF-IDF는 문서에 자주 나오지만 다른 문서에는 드문 단어에 더 큰 가중치를 주는 방식입니다. 단순히 같은 단어가 많이 나온다는 이유만으로 연결하지 않고, 여러 기록을 구별하는 단어와 인접 표현을 사용하려는 목적이었습니다.

🔧 작업 과정

에피소드 1. “Markdown으로 옮기기”보다 먼저 저장 경계를 정했습니다

상황 → 판단 → 실제 시도 → 관찰된 결과 → 다음 결정의 순서로 진행했습니다.

처음에는 내보낸 텍스트를 Markdown으로 바꾸면 되는 것처럼 보였습니다. 그러나 대상이 개인 일기라는 점에서 가장 먼저 확인해야 할 것은 변환 성공 여부가 아니라 어디에 저장되고 어디까지 검색되는가였습니다.

그래서 공개 멀티도메인 LLM Wiki에 편입하지 않고 개인 일기 전용 비공개 저장소를 별도로 두었습니다. 원본 ZIP과 TXT는 보존 영역에 남기고, 편집 가능한 Markdown과 색인·보고서는 별도 계층에 두었습니다.

변환 규칙도 고정했습니다.

• 파일명의 첫 번째 날짜를 기록 작성일로 사용했습니다.

• 두 번째 날짜와 시각은 Samsung Notes 내보내기 시각으로 취급했습니다.

• 같은 작성일의 기록이 여러 개이면 -02 같은 결정적 접미사를 사용했습니다.

• UTF-8 BOM은 파생 Markdown에서만 제거하고, 줄바꿈만 정규화했습니다.

• 일기 본문은 요약하거나 문장 교정하지 않았습니다.

• 각 페이지에 원본 파일명·원본 SHA-256·private: true를 기록했습니다.

그 결과 작성일과 내보내기 시각을 혼동하지 않으면서, 같은 날짜의 별도 기록도 합쳐지지 않았습니다. 원본을 고치는 대신 파생 페이지를 만들고, 파생 페이지가 어느 원본에서 왔는지 남기는 구조가 첫 번째 안전장치가 되었습니다.

에피소드 2. 날짜순 목록을 내용 관계망으로 확장했습니다

변환만 끝내면 158개의 Markdown 파일이 생기지만, 그것은 여전히 파일 묶음에 가깝습니다. 사용자가 원한 것은 서로 관련 있는 문서를 [[ ]]로 연결해 다시 읽을 수 있는 구조였습니다.

자동 연결은 다음 방식으로 제한했습니다.

1. 본문에서 단어와 인접 단어쌍을 추출했습니다.

2. 모든 문서에 반복되는 챌린지 문구와 일반 불용어를 제외했습니다.

3. 한 문서에만 등장하거나 거의 모든 문서에 등장하는 단어의 영향력을 낮췄습니다.

4. TF-IDF와 코사인 유사도로 관련 후보를 계산했습니다.

5. 채택한 관계는 양쪽 문서에 모두 기록했습니다.

6. 페이지마다 관련 일기가 지나치게 몰리지 않도록 연결 수에 상한을 두었습니다.

7. 계산 점수와 공통 핵심어는 별도 분석 보고서에 남겼습니다.

이 과정에서 299개의 무방향 관계 쌍, 총 598개의 방향성 [[wikilink]]가 만들어졌습니다. 페이지별 연결 수는 2개에서 6개 사이였습니다.

다만 자동 점수를 그대로 믿지는 않았습니다. 가장 낮은 점수의 관계 한 쌍은 공통 단어가 너무 일반적이어서 제거했고, 두 문서의 원문을 직접 읽어 실제 주제가 맞는 별도의 관계로 교체했습니다. 이 수정은 “AI가 틀렸다”는 결론보다 더 중요한 것을 보여줍니다.

자동 분석은 후보를 찾는 장치이고, 의미가 있는 관계인지 결정하는 일은 원문 검토와 provenance가 맡아야 합니다.

에피소드 3. “파일이 생겼다”에서 “검증을 통과했다”로 완료 조건을 바꿨습니다

개인 기록을 다루는 작업에서는 변환 파일 수만 세는 것으로 충분하지 않습니다. 원본이 그대로인지, 링크가 실제로 열리는지, 검색 경계가 지켜지는지 확인해야 합니다.

최종 검증에서는 다음 항목을 확인했습니다.

• 원본 TXT: 158개

• Markdown 일기 페이지: 158개

• 상호 링크 쌍: 299쌍

• 전체 [[wikilink]]: 598개

• 깨진 링크: 0건

• 고립된 일기: 0건

• 비상호 링크: 0건

• 페이지당 2개 미만 링크: 0건

• 색인 누락: 0건

• frontmatter 오류: 0건

• 최종 lint: PASS

• 결과 압축본 무결성: PASS

또한 구축 과정 자체를 별도 devlog.md로 정리하고, 개인 위키의 index.md와 log.md에 운영 문서와 변경 이력을 등록했습니다. 즉, 결과 파일만 남긴 것이 아니라 다음 내보내기 때 반복할 수 있는 작업 계약도 남겼습니다.

✅ 결과 (After)

여기서 158개·299쌍·598개와 lint 결과는 이번 로컬 작업에서 확인한 값입니다. 다른 Samsung Notes 내보내기나 다른 개인 기록에 그대로 적용된다고 보장하는 수치는 아닙니다.

반대로 다음 항목은 측정하지 않았습니다.

• 변환으로 절약된 실제 시간

• 관련 일기를 찾는 검색 성공률의 변화

• 독자가 다시 기록을 찾는 데 걸린 시간

• 디스크 공간 절감량

• 외부 웹·커뮤니티 게시 효과

따라서 “생산성이 몇 퍼센트 올랐다”거나 “검색 정확도가 개선됐다”고 주장하지 않습니다. 이번 결과는 보존·분리·연결·검증 구조가 실제로 통과했다는 범위에서만 말할 수 있습니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 민감도 판단을 변환보다 먼저 하기
   개인 기록이라면 공개 위키에 넣은 뒤 숨기는 방식보다, 처음부터 비공개 저장 경계를 정하는 편이 안전합니다.

2. 원본과 파생물을 분리하기
   원본 TXT는 손대지 않고 Markdown에서만 frontmatter와 링크를 관리하면, 나중에 변환 규칙을 바꿔도 원본과 비교할 수 있습니다.

3. 파일명 날짜와 이벤트 날짜를 구분하기
   내보내기 시각을 작성 시각으로 잘못 읽으면 일기 순서와 같은 날짜 충돌이 모두 틀어질 수 있습니다.

4. AI에게 관계를 확정시키지 말고 후보를 만들게 하기
   유사도 점수는 탐색 속도를 높이는 데 유용하지만, 공통 단어가 일반적일 때는 의미 없는 링크를 만들 수 있습니다.

5. 완료 선언 대신 검증 카드를 요구하기
   파일 수, 깨진 링크, orphan, 상호성, 색인 누락, frontmatter, 원본 무결성을 각각 확인해야 “정리했다”는 말이 검증 가능한 결과가 됩니다.

이렇게 하면 안 됩니다

• 개인 일기 원문을 공개 프롬프트나 공용 검색 인덱스에 그대로 넣지 않습니다.

• 원본 ZIP이나 TXT를 “정리”한다는 이유로 직접 고치지 않습니다.

• 내보내기 날짜를 기록 날짜로 추정하지 않습니다.

• 공통 단어 몇 개만 겹친다고 의미 관계를 확정하지 않습니다.

• 링크가 부족하다는 이유로 근거 없는 관계를 억지로 만들지 않습니다.

• 실제로 측정하지 않은 시간 절약·정확도 향상을 결과처럼 쓰지 않습니다.

🌍 다른 업무에 적용한다면?

이 구조는 일기뿐 아니라 다음과 같은 개인 기록에도 적용할 수 있습니다.

독서 기록과 강의 메모

원본 PDF·전사·메모를 별도 보존하고, 편집 가능한 요약 페이지에 source_sha256을 붙입니다. 같은 개념을 다룬 여러 메모를 내용 기반 후보로 연결하되, 직접 인용이나 해석이 들어간 관계는 사람이 검토합니다.

여행 준비 기록

예약 메일·지도 링크·방문 메모·사진을 공개 여행 가이드와 분리된 개인 작업대에 보존하고, 도시·날짜·장소 관계를 연결합니다. 외부 공유본을 만들 때는 개인 예약번호와 원문 메시지를 제외한 파생본만 발행합니다.

회의·프로젝트 회고

회의록 원본은 비공개로 두고, 결정·쟁점·후속 작업만 공개 가능한 회고 페이지로 컴파일할 수 있습니다. 이때 “회의 원문”과 “사람이 읽는 사례글”을 동일한 문서로 취급하지 않는 것이 중요합니다.

어떤 업무든 공통 원칙은 같습니다.

원본 보존 → 민감도 분리 → 파생 페이지 생성 → 설명 가능한 관계 연결 → 독립 검증

🚀 앞으로의 계획

완료된 작업

• Samsung Notes export ZIP과 TXT 원본 보존

• 개인 기록 전용 비공개 Markdown 위키 구축

• 작성일 기반 파일명과 같은 날짜 충돌 처리

• 158개 페이지의 provenance frontmatter 기록

• 내용 기반 상호 wikilink 299쌍 생성

• 저신뢰 자동 관계 수동 교정

• index.md, log.md, devlog.md와 분석·lint 보고서 정리

• 최종 lint 및 압축본 무결성 검증

• 개인 원문을 제외한 public-safe 사례글 작성과 Library 발행

제안하는 다음 단계

• 새 Samsung Notes export가 들어올 때 기존 원본 SHA-256과 비교하는 증분 ingest

• 같은 내용의 재내보내기와 새로운 기록을 구분하는 중복 탐지

• 자동 연결 후보에 “자동·수동 검토·보류” 상태를 부여하는 관계 검토 화면

• 개인 위키의 public/private/secret 검색 범위를 다시 확인하는 정기 privacy audit

• 날짜·주제·연속 기록을 함께 보여주는 Obsidian topic map

이 단계들은 아직 이번 작업의 완료 결과로 포함하지 않았습니다. 새 자동화가 실제로 실행되었다고 오해하지 않도록, 현재 발행본에서는 후속 제안으로만 구분합니다.

📋 재사용 가능한 프롬프트

1. 개인 기록을 비공개 Markdown 위키로 옮길 때

이 자료는 개인 기록입니다.

1) 공개 위키·공용 검색 인덱스·외부 배포 경로와 분리된 저장 구조를 먼저 제안하세요.
2) 원본 ZIP/TXT는 바이트를 수정하지 말고 보존하세요.
3) 파일명에 작성일과 내보내기 시각이 함께 있다면 둘을 구분하세요.
4) 같은 날짜 기록은 결정적 접미사로 분리하세요.
5) Markdown 파생 페이지에는 원본 파일명, 원본 SHA-256, private 표지를 기록하세요.
6) 원문 본문은 요약·교정하지 말고 그대로 옮기세요.
7) 마지막에 원본 수·파생 페이지 수·해시·깨진 링크·고립 문서·색인 누락을 검증하세요.
8) 개인 원문이 public-safe 결과물에 노출되지 않았는지 다시 검사하세요.

2. 내용상 관련된 개인 문서를 연결할 때

문서 간 관련 링크 후보를 만들되, 자동 링크를 사실로 확정하지 마세요.

- 반복 문구와 일반 불용어를 제거하세요.
- 단어와 인접 단어쌍 기반 TF-IDF 유사도를 계산하세요.
- 링크는 양쪽 문서에 모두 기록하세요.
- 문서별 연결 수를 제한하세요.
- 가장 낮은 점수의 관계와 짧은 문서를 직접 검토하세요.
- 공통 단어만 겹치는 관계는 제거하거나 수동 검토 상태로 남기세요.
- 점수·공통 핵심어·수동 교정 사유를 별도 분석 보고서에 보존하세요.
- 최종적으로 깨진 링크·고립 문서·비상호 링크·색인 누락을 0건인지 확인하세요.

3. 작업 로그를 사례게시글로 바꿀 때

이 작업 로그를 비개발자도 읽을 수 있는 사례게시글로 재구성하세요.

- 개인 기록의 실제 본문·절대경로·원본 파일명·비밀값은 포함하지 마세요.
- Before → 판단이 필요한 작업 과정 → 의미 있는 실패 또는 경계 → 수리 → 검증 → After 순서로 쓰세요.
- 원본 수, 파생 페이지 수, 링크 수, PASS/FAIL 결과는 실제 확인된 값만 쓰세요.
- 측정하지 않은 시간 절약이나 정확도 향상은 주장하지 마세요.
- 완료된 작업과 제안 단계는 분리하세요.
- 외부 웹·커뮤니티 발행 여부는 Library 발행과 별도로 표시하세요.

🔎 근거와 공개 범위

이 사례글은 다음의 비공개 작업 원장과 검증 결과를 바탕으로 작성했습니다.

• Samsung Notes export 및 개인 일기 위키 구축 기록

• 원본·Markdown 수량과 provenance 필드 검증 결과

• TF-IDF 관계 분석 및 수동 교정 기록

• 링크·색인·frontmatter lint 결과

근거 자료에는 개인 일기 원문이 포함되어 있으므로 공개 라이브러리에는 복사하지 않았습니다. 라이브러리에 발행된 것은 작업 구조와 집계된 검증값을 재구성한 파생 글입니다.