메모는 셋이라고 했어
계보 합병을 연 세션은 그 일을 설명하는 인수인계 메모를 물려받았고, 메모는 평행 관례가 세 군데서 쓰인다고 했어. 앱 셋이 변환됐지. 그다음 누가 파일 이름이 그 패턴에 걸리는 걸 전체 트리에서 훑었고, 아무도 안 적어둔 네 번째 채택자를 찾았어.
재앙은 없었어. 그것도 변환했으니까. 챙길 값이 있는 건 그 오류의 모양이야. 완전히 평범하거든. 시스템을 아는 사람이 수를 적었고, 그 사람을 믿은 사람이 사실로 물려받았고, 하나가 틀렸어.
메모가 구조적으로 적게 세는 이유
인수인계 메모는 시스템을 회상하는 사람이 써. 회상은 눈에 띄는 걸 꺼내와. 재밌었거나, 최근이거나, 저자가 직접 만진 사례들. 네 번째 채택자는 다른 세션이 조용히 추가했고, 메모 저자가 일하고 있지 않던 저장소에 있었어. 잊힌 게 아니라 애초에 안 알려진 거야.
그래서 이 실패는 실수가 아니라 구조적이야. 메모를 아무리 정성껏 써도 안 고쳐져. 저자는 자기가 본 적 없는 걸 열거할 수 없으니까. 파일 시스템은 할 수 있고.
이름 하나 말고 여럿으로 훑어
같은 날 배운 개선이 하나 있어. 컴포넌트 이름으로 grep 한 번 하면 그걸 임포트하는 모든 자리를 찾아. 관례에 이름이 생긴 다음엔 맞는 기구야. 들어오는 길에 이름이 바뀐 복사본은 못 찾아. 그리고 손으로 복사된 관례는 끊임없이 이름이 바뀌어. 앱마다 자기 이름을 따서 부르거든.
그래서 네 번째 채택자를 찾은 훑기는 정확한 심볼이 아니라 개념 조각으로 한 파일 이름 검색이었어. 일반적으로는 그 개념의 그럴듯한 이름 여럿으로 훑고, 그다음 구현의 특이한 줄로 훑고, 그다음 심볼로 훑어. 기구마다 다르게 실패하니까, 셋을 다 빠져나가는 복사본은 있을 가능성이 훨씬 낮아. 없다고 증명된 건 아냐. 이름이란 이름, 특이한 줄이란 줄을 다 바꾼 복사본이면 여전히 빠져나가. 그 남는 구멍 때문에 아래 원장 검사는 거꾸로도 돌아. 원장의 행마다 걸리는 게 있어야 해.