글감 추천을 검토하며 여러 사람의 메모와 제목이 같은 메모를 섞어 보았습니다. 후보를 고르기 전 원문을 전부 읽지 않도록 한 규칙이, 후보를 구별할 요약까지 막는 경우가 있었습니다. 문제 해결 사례에서는 또 다른 빈틈이 드러났습니다. 검토용 사례에서 조치 뒤 관찰을 빼면 해결을 확인할 근거가 사라졌습니다. 1.5.1에서는 글감을 고를 만큼 읽게 했고, 1.5.3에서는 사례로 저장할 때 해결을 확인한 증거를 요구했습니다.

1.5.1 목록과 추천 분리

coco-blog는 로컬 TIL에서 대상이 되는 노트를 모두 찾아 번호, 제목, 짧은 요약을 보여 줍니다. 제목이 같아도 파일이 다르면 별도 항목으로 두고, 읽을 수 없거나 기여 관계가 확인되지 않은 항목은 그 상태를 표시합니다. 작성자가 고르기 전에는 메타데이터와 필요한 일부만 읽고, 선택이 끝난 뒤 해당 노트의 전문을 읽습니다. 이미 고른 노트가 있다면 그 선택에서 이어갑니다. COCO 1.5.1 변경 기록

추천에서는 작성자가 직접 구현하거나 조사하거나 검증한 경험을 우선 봅니다. 같은 사건의 진단 메모와 수정 메모를 묶을 때도 두 기록을 같은 사람의 작업으로 간주하면 회고의 주체가 틀어질 수 있습니다. 메모의 저장 위치만으로 기여자를 추정하지 않고, 확인된 기여와 함께 볼 근거를 글감 번호에 연결합니다.

지침을 검토할 때 여러 기여자의 노트 네 개가 섞인 경우, 중복 제목과 읽기 실패가 있는 큰 목록, 팀원 노트를 이미 선택한 경우를 각각 적용해 봤습니다. 그 과정에서 진입점의 읽기 제한이 목록 요약에 필요한 발췌와 충돌하는 점을 찾아 고쳤습니다. 세 사례는 준비된 입력으로 지침을 확인한 결과입니다. 1.5.1 글감 추천 검증

1.5.3 재검증한 문제 해결 기록

개념 노트가 “이 기술이 어떻게 동작하는가”를 기억하는 데 쓰인다면, 문제 해결 사례는 “같은 증상이 보일 때 무엇을 보고 다음 확인을 결정할 것인가”에 답합니다. coco-til에 세션당 대표 사례 하나를 TIL/cases/에 저장하는 경로를 추가했습니다. 사례에는 증상과 성공 기준, 진단에 사용한 관찰, 재발 시 확인 순서, 실제 수정과 재검증을 남깁니다. 재현용 예시와 실제 실행, 읽기 전용 확인과 상태를 바꾸는 조치도 구분합니다. COCO 1.5.3 변경 기록

검토용 사례에서는 Jenkins 잡이 첫 단계까지 10분을 기다렸습니다. 큐와 실행기 상태를 확인한 뒤 예약 실행기를 복구했고, 다음 빌드의 대기는 20초로 기록됐습니다. 미리 정한 성공 기준인 1분 미만은 충족했습니다. 두 빌드의 부하를 맞추지 않았으므로 기록할 수 있는 것은 복구 뒤의 관찰입니다. 그 재검증을 사례에서 빼면 복구 조치만 남고, 사례 저장 조건을 충족하지 않습니다. 같은 관찰을 제목만 바꿔 다시 가져와도 기존 사례를 유지하고, 새 근거가 생기면 기존 사례에 반영합니다. 파일과 인덱스 구조는 자동 검사로 확인했고, 사례 선정과 중복 판단은 지침 검토로 확인했습니다. 1.5.3 사례 검증

나중에 이 사례를 글감으로 고르면, 초안의 출발점이 조치 한 줄에서 판단을 뒷받침하는 기록으로 바뀝니다. 개인 노트에는 다음에 다시 확인할 근거를 남기고, 공개 초안에는 작성자가 설명할 수 있는 선택과 독자가 재사용할 수 있는 절차를 옮깁니다. 얼쑤 블로그에서 Jenkins 빌드 시간을 다룰 때도 실행기 대기와 최적화 계산을 따로 적어, 어떤 수치가 어떤 판단을 뒷받침하는지 드러냈습니다. 얼쑤의 Jenkins 빌드 분석 글