문서, 파일과 가져오기
모든 파일을 강제로 Markdown으로 바꾸는 것이 Glif의 목표는 아니다. 이 장은 기존 Markdown은 그대로 열고, HWP·DOCX·PDF·XLSX·PPTX와 웹 source는 먼저 미리본 뒤 필요한 것만 Markdown 또는 문서셋으로 승격하는 입력 게이트를 설명한다.
가져오기 전에 결정할 것
| 원하는 결과 | 권장 동작 | 원본 영향 |
|---|---|---|
| 원래 파일을 그대로 보관 | source preview | 원본 유지, 읽기 중심 |
| 다른 문서에서 이동 가능한 참조 | link 삽입 | 대상 파일 유지 |
| 현재 문맥에 원문 일부 표시 | embed 삽입 | 대상 파일 유지 |
| 편집 가능한 독립 Markdown | text copy 또는 Bring To Glif | 새 Markdown 파생물 생성 |
| 웹페이지의 핵심 내용 보존 | web clip | URL·provenance와 note 분리 |
이 장의 학습 경로
- 혼합 source가 Shelf에 어떻게 표시되는지 확인한다.
- 지원 문서를 preview pane에서 읽고 변환 전 상태를 확인한다.
- 문서를 작성 영역에 drop하고 link, embed, text-copy intent의 차이를 비교한다.
- Bring To Glif로 편집 가능한 Markdown을 만들고 원본과 파생 파일의 경로를 기록한다.
- 실패 또는 일부 변환 결과에서 원본을 보존한 채 다시 시도한다.
상세 장
공용 예제에 추가할 입력
이 장의 실증 fixture는 같은 내용의 source-note.docx, source-report.pdf, source-data.xlsx와 변환 결과 imported-note.md를 함께 둔다. 캡처에서는 원본 preview, 선택한 intent, 생성된 Markdown과 provenance를 한 revision으로 묶는다.
안전 기준
- preview 성공을 완전한 변환 성공으로 간주하지 않는다.
- 지원하지 않는 요소를 조용히 버리지 않고 diagnostic과 다음 행동을 보여 준다.
- text copy는 새 파일이므로 원본과 자동 양방향 동기화된다고 표현하지 않는다.
- URL, 로컬 경로와 생성 결과의 provenance를 구분한다.
현재 형식별 개요는 소스 가져오기와 웹 클리핑에서 먼저 확인할 수 있다. 다음 장에서는 가져온 Markdown을 구조적으로 편집한다.
실제 입력 게이트 캡처
원본을 바로 변환하지 않고 preview → intent 선택 → 결과 확인 순서를 따른다.
| 단계 | 확인할 것 | 원본에 남는 것 |
|---|---|---|
| Preview | 파일명·형식·읽기 가능 여부 | 원본 파일 그대로 |
| Intent 선택 | link, embed, text copy, Bring To Glif 중 하나 | 선택한 action 기록 |
| Materialize | 새 Markdown, link 또는 embed 결과 | 원본과 파생물의 경로 |
| 검토 | 누락 요소·provenance·diagnostic | 실패 원인과 재시도 경로 |
입력 결과가 보였다는 것과 모든 서식이 보존됐다는 것은 다르다. 원본 preview와 생성된 Markdown을 나란히 읽고, 변환하지 못한 요소가 경고·누락·fallback 중 어느 상태인지 기록한다.
이 장의 완료 기준
- 원본 파일을 먼저 preview했다.
- 원본 보존, 참조, 복사, 승격 중 intent를 선택했다.
- 생성 파일의 경로와 provenance를 기록했다.
- 지원하지 않는 요소가 조용히 버려지지 않았는지 확인했다.
- 생성 결과를 다시 원본으로 착각하지 않았다.