파일 메모리
세션이 끝나도 남는 기억을 파일로 둔다.
문제
대화를 닫으면 다 사라진다.
같은 실수를 지적해도 다음 세션에서 또 한다. 이 프로젝트가 왜 이렇게 생겼는지, 뭘 시도했다가 접었는지를 매번 다시 설명해야 한다. 어제 "그 방법은 이미 해봤고 안 됐다"고 말한 걸 오늘 또 제안한다.
이건 능력 문제가 아니라 저장 문제다. 기억할 곳이 없으면 기억할 수 없다.
하는 일
기억을 파일로 쓴다. 한 파일에 하나씩, 지금 128개가 쌓여 있다. 인덱스 한 장이 매 세션 자동으로 올라오고, 필요한 것만 그때 펼쳐 읽는다.
무엇을 기억하나
네 가지로 나눠 둔다.
- 사람: 배경, 선호, 일하는 방식
- 피드백: 받은 지적과 그 이유. 이게 제일 값이 크다
- 프로젝트: 결정과 그 근거. 코드나 커밋에 안 남는 것
- 참조: 외부 자원 위치
여기서 중요한 건 안 적는 것이다. 코드를 보면 아는 것은 안 적는다. 파일 구조, 함수 이름, 지난 버그 수정 내역 같은 것들. 그건 저장소가 이미 기억하고 있고, 메모리에 옮겨 적는 순간 두 개의 사본이 생겨 언젠가 어긋난다.
메모리에 적을 값이 있는 건 "왜"다. 무엇을 했는지는 커밋 로그에 있지만, 왜 그렇게 정했는지와 무엇을 시도했다가 접었는지는 어디에도 없다.
제일 값이 큰 건 피드백이다
기능 결정보다 지적이 더 값지다. 지적은 반복되기 때문이다.
같은 실수를 두 번 하면 세 번째도 한다. 그런데 그게 파일에 적혀 있으면 세 번째부터는 안 한다. 그래서 지적을 받으면 그 자리에서 적는다. 무엇을 지적받았는지만이 아니라 왜 그게 문제인지까지 같이. 이유가 없으면 다음 세션에서 규칙만 보고 상황이 다르다고 판단해 또 어긴다.
메모리는 쌓기만 하면 안 된다. 낡은 기억은 없는 것보다 나쁘다.
실제로 겪었다. "이 도구가 색 기반 배경 제거 엔진을 쓴다"고 적어뒀는데, 코드를 열어보니 그 엔진은 다른 프로젝트 것이었고 이 도구는 진작에 다른 방식으로 갈아탄 뒤였다. 그 메모리를 믿고 말했으면 그대로 틀린 소리를 했을 것이다.
그래서 메모리가 파일이나 동작을 지목하면, 말하기 전에 그게 지금도 그런지 확인한다. 메모리는 그때 사실이었던 것이지 지금 사실이 아니다.
규칙과 어떻게 다른가
규칙 자동 주입과 헷갈리기 쉬운데 성격이 반대다.
규칙은 내가 정해서 박는 것이고 잘 안 바뀐다. 기억은 겪으면서 쌓이는 것이고 계속 는다. 규칙은 짧아야 힘이 있고, 기억은 많아도 인덱스로 견딘다.
둘을 섞으면 양쪽이 망가진다. 기억을 규칙 파일에 밀어 넣으면 금지 목록이 부풀어 아무것도 안 지켜지고, 규칙을 기억에 맡기면 매번 다르게 나온다.
정직한 한계
기억이 있다고 판단이 좋아지는 건 아니다. 같은 사실을 놓고도 엉뚱하게 쓸 수 있다.
그리고 적히지 않은 건 여전히 사라진다. 지적을 받고도 그 자리에서 안 적으면 그냥 없던 일이 된다. 결국 기억을 남길지 정하는 건 그 순간의 판단이고, 그건 자동화가 안 된다.