1. 자료 종류별 요령

자료의 종류마다 조심할 것이 다릅니다. 같은 프롬프트를 쓰면 회의록에서는 결정이 사라지고 PDF에서는 표가 뭉개집니다. 이 절은 종류별로 붙일 한두 줄을 정리한 자리입니다.

1.1 PDF 문서

보고서, 요금제 페이지 인쇄본, 백서가 여기 들어갑니다.

가장 자주 무너지는 것이 표입니다. PDF의 표는 글자 위치로만 이뤄져 있어서, 그냥 읽으면 열이 뒤섞이거나 셀이 밀립니다.

raw/2026-08-14-competitor-a-pricing.pdf 를 인제스트해줘.

이 문서에는 요금표가 있어. 표는 마크다운 표로 그대로 옮기고,
옮긴 뒤에 원본과 숫자가 맞는지 한 번 더 대조해줘.
표에서 빈 칸은 임의로 채우지 말고 빈 칸으로 둬.

쪽수를 출처에 넣는 것도 도움이 됩니다. 100쪽짜리 보고서라면 파일 이름만으로는 확인하기 어렵습니다.

출처를 표기할 때 파일 이름 뒤에 쪽수도 적어줘.
예: (raw/2026-08-14-report.pdf, 12쪽)

1.2 회의록

회의록에서 가장 잘 사라지는 것이 결정입니다. AI가 회의록을 요약하면 논의된 주제들이 나열되고, 그중 무엇이 결정됐고 무엇이 보류됐는지는 뭉개집니다.

raw/2026-08-17-weekly-meeting.md 를 인제스트해줘.

회의록이니까 아래를 나눠서 처리해줘.
- 결정된 것: decisions/ 아래 별도 문서로. 무엇을, 왜, 누가 정했는지.
- 논의만 하고 결론 없는 것: topics/ 문서에 '검토 중'으로 표시해서.
- 할 일: 위키에 넣지 마. 이건 위키 범위 밖이야.

발언자 이름은 결정 문서에만 남기고 나머지에는 빼줘.

마지막 줄이 필요한 이유가 있습니다. 회의록을 그대로 넣으면 "김OO이 이렇게 말했다"는 문장이 위키 곳곳에 남습니다. 나중에 그 사람이 팀을 떠나거나 생각이 바뀌면 문서가 어색해집니다. 결정한 사람은 남기되 발언은 남기지 않는 편이 오래갑니다.

1.3 웹 기사와 뉴스레터

웹에서 온 자료는 두 가지를 조심합니다.

본문과 광고가 섞입니다. 저장한 페이지에는 관련 기사 목록, 구독 안내, 댓글이 함께 들어옵니다. AI가 이걸 본문으로 착각하면 엉뚱한 링크가 위키에 생깁니다. 다음 절의 Web Clipper가 이 문제를 대부분 해결합니다.

주장과 사실이 섞입니다. 기사에는 기자의 해석이 사실처럼 적혀 있습니다.

raw/2026-08-18-industry-news.md 를 인제스트해줘.

기사니까 사실과 기자의 해석을 갈라서 정리해줘.
- 수치와 발표 내용처럼 확인 가능한 것: 사실로.
- 기자의 전망과 평가: [기사 주장] 표시를 붙여서.
- 우리 판단: [추론] 표시를 붙여서.

[기사 주장]이라는 표시를 하나 더 두는 것이 요령입니다. 나중에 그 기사의 전망이 빗나갔을 때, 위키에서 그 문장만 골라낼 수 있습니다.

1.4 이미지와 캡처

화면 캡처, 그래프 사진, 손으로 그린 도식이 여기 해당합니다.

AI는 이미지를 읽을 수 있지만 그 결과를 위키에 남길 때 문제가 생깁니다. 이미지에서 읽은 내용은 원본에서 다시 확인하기 어렵습니다. 그래서 이미지 인제스트는 한 단계를 더 둡니다.

raw/assets/2026-08-19-competitor-dashboard.png 를 읽어줘.

먼저 이미지에서 읽어낸 내용을 그대로 나열해줘.
숫자는 정확히 읽었는지 자신 없으면 그렇다고 말해줘.
확인하고 나서 인제스트할게.

읽어낸 내용을 사람이 눈으로 대조한 뒤에 넣습니다. 특히 그래프의 축 값이나 작은 글씨는 잘못 읽히는 일이 있습니다.

문서에 남길 때는 이미지 링크를 같이 걸어 둡니다.

정리한 내용에 원본 이미지 링크를 걸어줘.
![[2026-08-19-competitor-dashboard.png]] 형식으로.

이렇게 하면 Obsidian에서 그 문서를 열었을 때 이미지가 본문에 바로 보입니다. 숫자가 의심스러울 때 파일을 찾아 헤맬 필요가 없습니다.

1.5 고객 문의와 후기

문의 내용이나 사용자 후기는 한 건씩 넣으면 위키가 잡동사니가 됩니다. 개별 문의는 위키에 남길 가치가 없고, 여러 건에서 반복되는 패턴이 남을 가치가 있습니다.

raw/2026-08-20-customer-inquiries.csv 를 인제스트해줘.

개별 문의는 문서로 만들지 마.
반복해서 나오는 불만이나 요청을 유형별로 묶어서
concepts/ 아래 한 문서로 정리해줘.
유형마다 몇 건인지 숫자를 적고, 대표 사례 한두 개만 인용해줘.

이름, 이메일, 전화번호는 절대 위키에 옮기지 마.

마지막 줄은 반드시 넣습니다. 고객 정보가 위키에 한번 들어가면 나중에 빼기가 아주 번거롭습니다. 11장에서 이 문제를 더 다룹니다.

1.6 종류별 요령을 규칙에 넣기

같은 종류의 자료를 세 번 넣었다면 그 요령을 규칙 문서에 옮깁니다.

## 자료 종류별 처리

- PDF: 표는 마크다운 표로 옮기고 숫자를 원본과 대조합니다.
  출처에 쪽수를 적습니다.
- 회의록: 결정은 decisions/, 논의는 topics/, 할 일은 넣지 않습니다.
  발언자 이름은 결정 문서에만 남깁니다.
- 웹 기사: 사실 / [기사 주장] / [추론]으로 갈라 적습니다.
- 이미지: 읽어낸 내용을 먼저 보여주고 확인받은 뒤 반영합니다.
- 문의·후기: 개별 건이 아니라 반복 패턴만 남기고, 개인정보는 옮기지 않습니다.

이걸 규칙에 넣어 두면 다음부터는 "인제스트해줘" 한마디로 이 처리가 다 됩니다. 프롬프트를 매번 길게 쓰는 대신 규칙 문서를 키우는 것이 이 방식의 요령입니다.

다음 절에서 자료 여러 건을 한꺼번에 넣는 법을 다룹니다.