메모도 배운다

지난번에 기록이 템플릿을 가르치는 루프를 만들었습니다. 할 일을 한 번 해 보면 으레 무언가 달라지고 — 재료 하나를 더 챙기고, 단계 하나를 빼고 — 그 차이를 원할 때 템플릿에 되돌리는 구조였죠.

이번엔 같은 루프를 메모로 넓혔습니다. 그런데 막상 옮겨 보니, 메모가 할 일보다 단순한 덕분에 이 루프가 더 깔끔하게 들어맞았습니다.

메모는 더 단순하다

Fecit에서 메모도 할 일과 평행 구조입니다 — 템플릿이 있고, 거기서 발화한 기록이 있죠. 하지만 메모가 가진 건 본질적으로 본문(content) 하나입니다. 준비물도, 단계도, 예상 시간도 없습니다.

그리고 결정적으로, 메모엔 ‘완료’가 없습니다. 할 일은 시작하고 끝내는 생애주기를 갖지만, 메모는 그냥 적는 것 — 포착(capture)이지 성취가 아닙니다.

처음엔 이게 걸림돌처럼 보였습니다. 할 일에서 우리는 “완료된 기록 = 확정된 진술”을 드리프트 비교의 신호로 삼았으니까요. 메모엔 그 신호가 아예 없습니다.

그래서 on-demand가 더 자연스러웠다

그런데 되먹임을 자동이 아니라 사용자가 부르도록 바꾼 결정이 여기서 빛을 발했습니다.

할 일에서는 한때 완료 시점에 자동으로 제안을 만들었다가, 보지도 않는 제안이 쌓이는 garbage 때문에 수동으로 돌렸습니다. 메모엔 애초에 자동 트리거로 삼을 ‘완료’가 없습니다. 그러니 수동이 유일하게 자연스러운 길이었죠. 제거할 자동 동작조차 없었습니다.

메모의 본문을 고친 뒤, 그 메모의 메뉴에서 **‘개선 제안 생성’**을 누르면 — 그제야 Fecit이 그 메모를 원본 템플릿과 비교해 달라진 본문을 제안으로 만들어 템플릿 옆에 붙입니다. 할 일에서 다듬어 둔 모델이, 더 단순한 메모에 그대로 들어맞았습니다.

어려운 코드는 한 줄도 다시 쓰지 않았다

가장 마음에 드는 부분은 엔지니어링 쪽입니다.

메모의 본문과 할 일의 작전(description)은 같은 직렬화 포맷을 씁니다. 같은 리치 텍스트 에디터로 편집하고, 같은 줄 구조(불릿·체크·헤딩)를 갖죠. 그 말은 — 우리가 공들여 디버깅한 라인 단위 diff·patch 알고리즘을, 필드 이름만 바꿔 그대로 쓸 수 있다는 뜻이었습니다.

그래서 그 알고리즘을 순수 함수로 뽑아내 할 일과 메모가 공유하게 했습니다. 메모 쪽에 새로 쓴 건 “어느 컬렉션에 저장하고, 어느 화면에 띄울지” 같은 얇은 배선뿐입니다. 버그가 살 만한 어려운 로직은 한 곳에만 있고, 양쪽이 그걸 가리킵니다.

원칙은 단순합니다: 버그-prone한 코어는 공유하고, entity별로 다른 건 얇게. 덕분에 이미 잘 돌던 할 일 코드는 거의 건드리지 않았고, 메모는 검증된 알고리즘 위에서 출발했습니다.

빠른 메모도, 쌓이면 청사진이 된다

메모는 흔히 “대충 빠르게 적는 것”으로 여겨집니다. 하지만 같은 형식의 메모를 반복해 쓰다 보면 — 회의록, 독서 노트, 일지 — 거기에도 당신만의 더 나은 틀이 자랍니다.

이제 그 틀을 되먹일 수 있습니다. 한 번의 메모에서 얻은 더 나은 문장이 그 메모 안에서 죽지 않고, 다음번엔 조금 더 다듬어진 템플릿에서 시작하게 합니다.

성취뿐 아니라 포착도 — 살아갈수록 청사진이 당신을 닮아 갑니다.