작업 일지를 짧게 줄인다고 사용 안내가 되지는 않는다. 일지의 순서는 작성자가 무엇을 먼저 알았는지에 달려 있다. 안내의 순서는 독자가 무엇을 먼저 알아야 다음 행동을 할 수 있는지에 달려 있다. AI에게 긴 작업 기록을 정리시킬 때 이 차이를 편집 기준에서 빼면, 문장은 줄어도 안내 순서는 그대로 남는다. 중복 문장을 지우고 제목을 붙여도, 독자는 작성자가 겪은 시행착오를 같은 차례로 따라갈 수 있다.
가령 작은 개발 도구를 설치한 기록을 생각해 보자. 파일을 내려받고, 실행에 실패하고, 필요한 실행 환경을 뒤늦게 설치한 다음 다시 실행했다. 이 기록을 그대로 압축하면 다운로드, 실패, 환경 설치, 재실행 순서가 남는다. 기록으로는 맞지만 처음 설치하는 독자를 위한 순서로는 곤란하다. 필요한 환경을 미리 확인할 수 있었다면 독자에게 첫 실패까지 재현시킬 이유가 없다. 여기서 든 설치 과정은 설명을 위한 가정이다.
이 안내의 앞부분에는 도구를 쓸 수 있는 조건과 그 조건을 확인하는 방법이 와야 한다. 그다음에 다운로드와 실행을 놓는다. 작성자가 실행 환경을 마지막에 알아냈다는 사정은 독자의 준비 순서를 결정하지 않는다. 순서를 바꾸는 일은 꾸미기가 아니다. 뒤에서 밝혀진 선행 조건을 앞으로 옮기는 편집이다.
그렇다고 실패한 시도를 전부 지우면 오류를 조사할 근거도 사라진다. 이미 설치를 마쳤는데 같은 오류를 보는 독자는 무엇을 시도했고 왜 그 방법을 버렸는지 궁금할 수 있다. 처음 설치하는 순서를 본문에 두고, 우회 방법과 실패 기록은 문제 해결 부분에서 찾아볼 수 있게 남기는 편이 낫다. 모든 독자를 작성자의 첫날로 되돌려 보내는 대신, 지금 하려는 일에 따라 읽을 곳을 고르게 하는 것이다.
시간 순서가 꼭 필요한 글도 있다. 장애가 발생한 뒤 설정 변경과 오류가 어떤 차례로 이어졌는지 조사하는 문서라면, 순서를 섞는 순간 원인 후보를 잘못 좁힐 수 있다. 시간 순서로 썼다는 이유만으로 나쁜 문서는 아니다. 설치를 마치려는 독자와 장애의 경위를 추적하는 독자에게 같은 순서를 강요하는 것이 문제다.
AI가 정리한 안내를 검토할 때는 문장이 얼마나 짧아졌는지보다, 독자가 첫 행동에 들어가기 전에 필요한 조건을 알 수 있는지부터 볼 만하다. 이 검토만으로 실제 설치 성공률이나 소요 시간이 좋아졌다고 말할 수는 없다. 다만 본문 뒤에서야 등장하는 선행 조건이 있는지는 확인할 수 있다. 작업 일지는 작성자가 어제 배운 순서를 보존한다. 사용 안내는 독자가 다음에 해야 할 일을 찾게 해야 한다.