개발 중에는 긴 설명보다 짧은 후속 질문을 자주 하게 돼요. 앞에서 다룬 내용을 이어 묻는 것이어서 매번 프로젝트 이름을 반복하지는 않죠. 그런데 7월 작업 기록을 분류할 때 이런 질문 일부가 넓은 기본 분류로 흘러갔어요. 대화에서는 이어진 일인데 기록에서는 연결이 약해진 거예요.
나중에 프로젝트의 진행을 살피려면 그 짧은 질문도 중요해요. 왜 수정을 했는지, 다음 단계로 넘어가기 전에 무엇을 확인했는지 들어 있을 수 있으니까요. 문장 하나만 보면 의미가 얇아 보여도 앞선 대화와 함께 읽으면 작업의 판단 지점이 될 수 있었어요.
키워드를 더 넣기보다, 대화의 자리를 보기
잘못 묶인 기록을 보고 프로젝트 이름을 더 많이 찾도록 하는 방식만으로는 부족했어요. 후속 질문에는 그런 이름이 없을 수 있어요. 반대로 이름이 들어 있어도 여러 프로젝트를 비교하는 문장이면 하나로 확정하기 어려워요. 단어만 늘리면 다른 혼선이 생길 수 있었어요.
기록이 나온 작업 맥락과 앞선 대화를 대조했어요. 같은 작업에서 이어진 질문인지, 실제로 다른 주제로 넘어간 것인지 확인해야 했어요. 질문을 짧게 했다는 이유로 맥락까지 없어졌다고 처리하지 않으려는 수정이었어요.
원천 대화를 다시 보며 분류된 단위와 대응시켰어요. 이때 분류를 바꾸는 일과 원자료를 잃지 않는 일을 함께 확인했어요. 결과의 개수가 달라졌다고 곧바로 누락을 의미하지는 않아요. 같은 작업의 연속된 내용을 묶으면서 숫자가 줄 수 있었어요.
더 강한 근거와, 여전히 약한 근거
재평가에서는 원천 대화가 빠지지 않았는지 확인하고 분류 근거와 관련 검사를 보강했어요. 이어지는 작업 단위를 정리한 결과도 남아 있어요. 문장을 다른 칸으로 옮기는 조치보다 왜 그 프로젝트의 기록인지 설명할 수 있게 하려는 과정이었어요.
그렇다고 모든 기록이 확실해진 것은 아니었어요. 일반적인 기술 질문은 특정 제품의 결정이라고 볼 근거가 없을 수 있어요. 여러 프로젝트를 동시에 언급한 내용도 한 곳으로 강제 배정하면 오히려 이후 읽는 사람이 잘못된 맥락을 받아들일 수 있었어요.
원천 답변의 확인이 얇은 기록도 남았어요. 분류가 맞는지와 작업이 실제로 끝났는지는 다른 문제예요. 프로젝트 이름을 정확히 붙였다고 그 안의 모든 완료 주장이 검증되는 것은 아니었어요. 분류의 약함과 결과 근거의 약함을 함께 정상으로 바꾸지 않았어요.
이 변경이 지향한 경험은 나중에 프로젝트를 읽을 때 사용자가 흩어진 대화를 다시 이어 붙이는 부담을 덜어 주는 것이었어요. 실제로 얼마나 시간이 줄었는지 측정한 기록은 없어요. 확인한 것은 재대조와 근거 보강, 그리고 확정할 수 없는 내용은 약한 상태로 유지한 부분이에요.
같은 날짜의 원자료에는 회사 보고서 발행 문제도 들어 있어요. 그 수정과 이번 기록 분류를 하나의 원인으로 설명하지 않았어요. 한 번의 작업 대화에 여러 문제가 담길 수 있으므로 글에서는 사용자의 맥락을 복원한 판단에 초점을 맞췄어요.
대화의 편의와 기록의 정확성이 서로 반대되는 목표일 필요는 없었어요. 사용자는 자연스럽게 이어 말하고, 기록하는 쪽은 그 이어짐을 살펴야 해요. 문장마다 이름을 다시 붙이게 하는 방식은 분류를 쉽게 할 수 있어도 실제 대화의 부담을 늘릴 수 있어요.
반대로 앞선 맥락을 무조건 유지하면 주제가 바뀐 순간을 놓칠 수 있어요. 이어지는 질문인지 새 질문인지 확인할 근거가 필요했어요. 이번 수정은 짧은 문장을 자동으로 같은 곳에 넣는 규칙보다 실제 작업의 연결을 대조하는 쪽에 가까웠어요.
분류가 개선된 결과도 원천과 함께 남아야 해요. 나중에 판단을 다시 볼 수 있어야 잘못 묶인 단위를 고칠 수 있죠. 원자료를 보존한 채 기록의 묶음을 바꾼 과정은 결과의 숫자보다 그 연결을 확인하는 일에 의미가 있었어요.
사용자가 편하게 대화하려면 매번 제목과 프로젝트 이름을 다시 붙일 필요가 없어야 해요. 그 편의는 뒤에서 기록을 읽는 과정이 앞선 맥락을 잇는 일을 맡을 때 가능해져요. 이번에는 짧은 질문을 정보가 없는 문장으로 보기보다 어느 대화의 다음 문장인지 살피는 쪽으로 기준을 바꿨어요.
