3년 동안 회의록과 실험 기록을 하나의 긴 시간순 더미에 쌓았다. 성실했고, 쓸모없었다. 정작 내가 하게 되는 질문들 — 이거 해봤나? 왜 그만뒀지? 지난번엔 뭐가 문제였지? — 은 매번 20분씩 스크롤한 끝에 엉성하게 답할 수밖에 없었다.
반사적으로 도구를 탓하게 된다. 도구 문제가 아니다.
두 개의 기록, 두 개의 규칙
해법은 규칙이 정반대인 두 기록을 따로 두고, 그 사이를 넘나드는 것을 의무로 만드는 것이다.
log는 사건의 기록이다. 날짜가 붙고, 한 번 쓰면 고치지 않는다. 4,000 step에서 발산했다고 적혀 있으면, 나중에 이유를 알게 되어도 그 문장은 그대로 남는다. 고쳐 쓰는 순간 증거가 사라진다.
노트는 이해의 기록이다. 날짜가 없고, 계속 고쳐 쓴다. 노트는 내가 지금 무엇을 믿는지를 말하고, 믿음이 바뀌면 그 즉시 수정된다.
모든 걸 바꿔놓은 필드 하나
앱을 갈아타는 것보다 이 frontmatter 필드 하나가 더 많은 일을 했다.
result: refuted # supported | refuted | inconclusive | pending실패한 실험은 보통 가장 먼저 사라진다. 정리하기 지루하고, 논문에 들어가지도 않고, 마땅히 넣을 자리도 없다. 그래서 이미 해봤는데 안 된다는 지식은 누군가 기억하는 동안에만 존재한다.
enum 하나면 그게 질문 가능한 형태가 된다.
| 질의 | 답 |
|---|---|
result=refuted&project=x | 여기서 내가 이미 아니라고 확인한 것들 |
status=running&updated<14d | 시작해놓고 조용히 놓아버린 것들 |
hypothesis!=∅ & result=pending | 열어놓고 닫지 않은 질문들 |
세 번째는 보고 있기 불편하다. 그래서 쓸모가 있다.
시스템은 곧 의례다
구조는 관리하지 않으면 무너지고, 관리는 실제로 할 수 있을 만큼 작을 때만 일어난다. 내 경우는 금요일
20분이다. 그 주에 끝난 것들의 result를 채우고, 관찰 한두 개를 노트로 승격시키고, 다음에 할 일을
적는다.
이 사이트의 나머지 전부 — 대시보드, 링크 제안, 그래프 — 는 그 20분을 쉽게 만들려고 있다. 어느 것도 그 20분을 대신하지 못한다.