파일로 정보 정리하기

snail
2023 년 3 월 12 일

텍스트 파일로 정보와 생각을 정리하는 방법에 대한 고민을 공유합니다. 쓸데없고 불필요한 고민일 수 있으나 적어도 흥미있는 주제이길 바라면서..;;

↪ 정보를 어떻게 정리할지는 늘 고민이 되는 문제입니다. 가끔은 저장했던 정보를 까먹고 새롭게 “발견”하는 일도 흔합니다. 저장과 더불어 저장된 정보의 우연한 발견에 대한 문제도 함께 고민해야 된다고 생각합니다. – hcho

굳이 텍스트 파일인 것은 가장 간결하고 투명하고 가공 하기 쉬운 형태라고 생각하기 때문입니다. 글 편집 도구, 표현 도구가 변덕때문에 달라지더라도 원천 데이터는 오래도록 유지가 되었으면 하는 마음입니다. 윦잌휘의 영향을 받았을지도.. 그러니까 이 글은 정보와 생각을 파일에 어떻게 나누어 담을 것인지에 대한 고민입니다. 물론 잘 나누고 분류 하려는 것은 추후에 빠르고 정확하게 찾고 최대한 중복은 줄이며, 또 그것은 정보들을 잘 연결하고 섞이게 하려는 의도 이고요.

↪ 텍스트 파일에 대해서는 완전히 동의합니다. 에디터만 있거나 심지어 단순히 cat으로도 내용을 확인할 수 있으니 다른 파일 포맷이 따라 올 수 없는 정보의 투명성입니다.

사실 파일 포맷보다는 문법에 대한 “변덕”이 큰 문제이지요. 지금까지 잘 쓰던 문법을 다시 한번 살펴 보면 “왜 이렇게 했었지?” 의문이 들면서 바꾸고 싶어집니다. 그러면 이전의 파일들을 다 열어서 문법을 바꾸거나 추가 문법을 정의해야 합니다. 점점 지저분해 지지요. – hcho

이 일련의 과정을 단순하고 간결하게 풀어내고 싶습니다. 간결성을 생각하면 빠르고 정확, 중복 같은 문제들이 해결이 안되거나 기능이 미약해 질 수 있겠으나 지속성을 생각했을 때 간결, 단순함에 더 우선순위를 두고 싶네요.

↪ 동의합니다. 정보 저장의 편의성이 보장되지 않으면 정보 자체를 저장하는 일이 줄어들겠지요. – hcho

작성한 텍트스 파일은 최종적으로 인터넷 공간에 배포됩니다. 실제 운용의 측면에서 보자면. 먼저 글 편집도구(obsidian or vimwiki)로 텍스트 파일을 작성합니다. 파일을 git을 통하여 배포하면 1차 개인 웹싸이트의 형태로 배포됩니다(현재 모노로그.미) 또한 어떠한 분류표시에 의해 널리 알려진 여러 상용블로그 시스템에 나누어 배포됩니다. 이 설명은 이 글의 주제와는 관련이 없으나 분류 고민에 일부 영향이 있을 수 있어서 언급했습니다.

↪ 저도 vimwiki를 씁니다. 순전히 개인적인 정보를 관리하는데 쓰고 있습니다. 파일은 Nextcloud로 싱크합니다. – hcho

↪ 글 편집도구를 emacs(org mode)를 포함해서 가볍게 써보았습니다. 모바일에서 불가능하다는 단점은 그리 크지 않지만. 파싱작업을 하다보니 문법을 해당 편집기에 따라가야하는 부분이 석연치 않더군요. 내가 쓸만한 문법만 구현하는 것도 조금 찝찝하고요. 위에 말씀하신 문법에 대한 변덕과도 비슷한 부분이 있는 것 같습니다. – snail

여러 고민이 있는데 가장 신경쓰이는 부분은 아래 두 가지 입니다.

1. 글에 대한 메타정보를 어디에 넣을 것인가.
2. 파일을 관리할때 폴더를 이용할 것인가.

먼저 메타정보에 대한 부분부터 살펴 보겠습니다. 생각하고 있는 메타정보는 분류(category, tag)와 제목(sumarry), 생성시각(timestamp)입니다. 생성시각은 이미 파일시스템에 남는 정보이지만 추후에 원천파일이 이리저리 옮겨지고 세월을 타다가보면 손실될 수 있지도 않을까 하는 우려때문입니다. 이 부분은 관리를 잘 할 수 있다면 필요 없을 수도 있습니다. 메타정보를 파일이름에 넣는 방법이라면 202303120123:tag1:tag2:subject_or_summary.txt 와 같은 형식이면 될것 같아요. 내용 안에 링크 삽입시 link name 이렇게 됩니다. 좀 너저분해지죠. 메타정보를 제목에 넣지않고 내용에 org mode 형식으로 넣는 방법도 있겠습니다. 내용으로 입력하게 되면 파일명과 링크가 조금 간결해지고 내용은 메타정보로 약간 지저분해 집니다. 두 방법의 장단점이 크지않은것 같아서 더 고민이 되는 부분입니다.

↪ 메타정보를 파일명에 포함하면 그 확장성이 제한된다고 생각합니다. 윦윜휘는 별도의 메타정보 파일을 생성하는데 사실 메타정보라기 보다는 git을 대신해서 버전을 트래킹하는 역할이 더 큽니다. 메타정보를 최종 출력에 포함되지 않는 문법을 이용해서 글과 함께 같은 파일에 저장하는 것이 제일 깔끔하다고 생각합니다. 마크다운 플레인 텍스트 파일 기반의 CMS들이 쓰는 방법입니다. 예를 들면 Grav, Pico CMS – hcho

↪ 완전히 납득했습니다! – snail

다음은 폴더에 대한 부분입니다. 하나의 폴더에 모든 파일을 저장하는 방법과 어떤 규칙에 의해 폴더를 나누는 방법이 있을 것 같아요. 파일이 얼마나 많아질지 예상되지 않지만 하나의 폴더에 파일이 많아지며 성능에 문제가 생기지 않을까 하는 막연한 염려가 있어요. 이것은 1차 배포 전에 텍스트 편집 도구에서의 문제이고 어떤 도구를 쓰냐에 따라 달라질 수도 있겠습니다. 파일은 여러 폴더로 구분하게 된다면 어떤 기준으로 구분해야 할지의 문제가 있는데 yyyymm 같이 기간 으로 나누거나 category나 tag 로 나누는 방법이 떠오릅니다. 후자의 경우 category, tag를 하나로 고정을 시켜야 하는 한계가 있지 않을까 싶습니다.

↪ 이 부분이 늘 고민입니다. 카테고리는 보통 폴더와 일대일 매핑이 되어서 반 영구적인 느낌이 듭니다. 물론 파일을 다른 폴더로 옮기면 그만이지만 복수의 카테고리에 해당하는 글도 분명히 존재하거든요. 그래서 윦윜휘(최대한 복잡한 철자로 ㅋㅋ)는 플랫하게 모든 파일을 한 폴더에 넣어 버리고 이 고민에서 해방되었습니다. 대신 태그를 남발하게 되었지요. – hcho

↪ 저도 플랫하게 하고 고민을 더는 것으로ㅎ 태그를 붙여가며 글을 써 보았는데 제목만큼이나 고민이 되는 부분인 것 같습니다. 고민없이 끄적이는 것이 가장 첫번째 목표이기 때문에 극단적으로 태그없이 사용해볼까 합니다; 통안에 던져넣는 느낌으로.. 로컬 편집이라면 검색에 대한 부담도 별로 없고요.(ag, rg 같은 유틸 사용) – snail

혹자는 구체적이지 않고 충분히 넓은 범위의 카테고리로 운용해야 글을 어디로 분류할지 고민이 없을 것이라고 합니다. 저도 늘 그렇게 생각하고 있었지만. 비슷한 것을 담으려고 비교하는 것이 문제이니 각각을 유일한 분류로 만드는 것도 방법이지 않을까 하는. 해보고 싶은 시도 중 하나는, 중복을 허용하고 각 분류는 주제와 타입의 속성을 합하여 이름짓고 그 이름의 의도를 확인하는 방법입니다. 기존 knot 분류와 레벨이 비슷하지만 기존에는 주제, 타입, 의도에 대한 생각이 빠져있었죠.

돌이켜보면 위키 초기 시절에는 이런 고민이 없었던것 같은데.. 그리고 지금껏 다른 분들도 특별히 문제가 없이 쓰시는것을 보면 문제는 분명히 저에게 있는 것 같습니다. 분류와 이름짓는 문제는 애초에 개인적인 문제라서 방법도 없고 나름의 관습으로 키워나가야 하는 건지도 모르겠어요. 비대칭과 불규칙적인 것인 기억이 더 잘 되는 것처럼요. 그리고 방법론이나 이론을 분석하기 보다는 아웃풋을 많이 내다보면 잡혀나가는 것이 아닐까 하는. – snail

↪ 내가 쓴 생각이지만 동의; 플랫한 구조 + 불규칙한 제목 + 분류와 태그없는 페이지 링크. wiki 에서 느꼈던 공간감도 결국 계획된 블럭이 보다는 그때그때 필요로 생긴 골목길에서 잘 드러나는. – snail

동의합니다. 플랫한 구조 + 불규칙한 제목 + 분류와 태그없이 글을 쓰게 되면 글이 저장되는 구조나 그 형식보다는 내용에 더 집중할 수 있게 되어서 좋을 것 같습니다. 정보의 정리 차원에서 보자면 나중에 검색을 통해서 찾거나 조사를 자동 제거해서 단어를 뽑아 낸 다음 자동으로 태그를 생성할 수도 있을 것 같습니다. 다만 이렇게 하면 너무 많은 태그가 생성될 수도 있겠지요. 그렇다면 페이지의 제목과 섹션 타이틀에서만 태그를 뽑아 내는 방법도 생각해 볼 수 있을 것 같습니다. – hcho

↪ 자동으로 뽑아내면 임의로 설정하지 않는다는 점에서 좋아보이네요. 일단 쓰면서 고민해봐야겠습니다. 고민 미루기; 링크만 쓰니까 오래전 위킥스 시절로 돌아가는 느낌입니다. ㅋ – snail