주간 보고서는 여러 파일로 만들어지고 있었어요. 원천 기록을 정리한 문서, 해석을 붙인 문서, 공개 검토 문서, 요약 메일까지 있었어요. 그런데 파일이 네 개라는 사실만으로 각 독자에게 필요한 질문이 나뉘지는 않았어요. 같은 변경 목록을 모양만 바꿔 읽는 데 머물 수 있었어요.
매일 남기는 기록에서도 비슷한 간극이 있었어요. 사람에게는 정상적인 문서인데 다음 작업은 그 문서를 정해진 형식으로 읽지 못했어요. 파일이 존재한다는 것과 읽을 수 있다는 것은 달랐고, 읽을 수 있다는 것과 의사결정에 쓸 수 있다는 것도 달랐어요.
독자가 무엇을 결정해야 하는지부터 나눴어요
일일 기록에서는 내용을 다시 쓰는 것보다 읽는 형식의 충돌을 먼저 바로잡았어요. 사람이 볼 때 문제없던 첫 부분이 자동 처리의 기준과 어긋나 있었어요. 기존 내용을 보존하면서 형식을 맞추고 다음 생성에서도 같은 기준을 따르도록 정리했어요. 다만 최종 저장 뒤 언제나 강제 확인하는 단계까지 완성된 것은 아니었어요.
주간 보고서는 목적을 다시 정했어요. 첫 문서는 무엇이 실제로 있었는지 찾는 근거 장부, 다음 문서는 그 변화가 업무에 어떤 영향을 주는지 읽는 내부 판단 보고서로 나눴어요. 공개 검토 문서는 고객에게 말해도 되는 변화가 있는지 판단하는 곳으로 두고, 요약 메일은 내부에서 빠르게 현황을 읽는 역할을 맡겼어요.
이 구분을 하고 나니 들어갈 내용도 달라졌어요. 내부 판단에는 서비스의 변화와 위험, 다음 행동이 필요했어요. 공개 검토에는 실제 배포와 제품 상태의 근거가 필요했어요. 구현 기록이 있다는 이유만으로 고객이 이미 사용할 수 있는 기능이라고 쓰지 않도록 했어요.
원천 기록에서 같은 변경을 다시 찾을 수 있는 연결은 유지했어요. 해석이 풍부해졌다고 근거와 멀어지면 다음 사람이 내용을 검토하기 어려워요. 기존 발행본은 남기고 같은 원천으로 검토본을 다시 만들었어요. 새 기준이 이전 보고서의 흔적을 지우지 않게 했어요.
같은 원천으로 검토본을 다시 만들면 바뀐 판단의 근거를 비교할 수 있어요. 원천을 새로 모으면서 내용까지 바꾸면 보고서 구조가 좋아진 것인지 입력이 달라진 것인지 구분하기 어려워요. 이번에는 독자를 나눈 결과가 같은 사실에서 어떻게 달라지는지 보려 했어요.
내용이 없는 공개 검토 결과도 의미가 있었어요. 구현한 작업이 많더라도 실제 배포를 확인하지 못하면 고객에게 알릴 변화는 없을 수 있어요. 내부 판단과 외부 약속의 기준을 나눠야 보고서가 작성된 일을 사용자 성과로 바꾸지 않아요.
또한 승인 상태를 보고서 안에 남기는 것과 승인한 행동을 실제로 실행하는 것은 달랐어요. 검토가 끝났다고 메일을 보낸 것으로 읽거나 고객에게 공개한 것으로 읽지 않도록 범위를 명시했어요. 보고서의 완료 문장도 그 문서를 읽는 다음 행동과 맞아야 했어요.
버전과 승인도 어떤 대상인지 분명해야 했어요
보고서의 버전 표시에도 두 의미가 섞일 수 있었어요. 보고서 형식이 바뀌었다는 버전과 고객 제품이 바뀌었다는 버전은 다른 정보예요. 제품의 실제 버전이 없는데 보고서 숫자를 제품 상태처럼 보여 주면 독자가 없는 릴리스를 읽게 돼요.
그래서 보고 패키지의 기준과 실제 서비스 버전을 분리했어요. 같은 주의 보고서를 다시 만든다고 새로운 제품 성과가 되는 것도 아니었어요. 검토와 재생성의 이력은 기록하되 사용자가 받을 변화와 혼동하지 않도록 했어요.
검토 승인의 범위도 따로 두었어요. 보고서가 내부 검토를 통과했다고 메일 발송이나 고객 공개까지 허용된 것은 아니었어요. 실제 배포 근거가 없던 주의 공개 검토에서는 발행할 후보가 없다는 판단을 남겼어요. 빈 결과를 실패처럼 숨기지 않았어요.
확인에서는 형식과 보고서 내용, 좁은 화면의 요약 레이아웃을 살폈어요. 실제 메일 클라이언트에서 수신한 결과는 이번 범위에 없었고, 실제 배포가 있는 주의 공개 후보를 끝까지 검증하는 일도 남아 있었어요.
이 작업은 보고서 수를 늘린 사례가 아니었어요. 같은 기록을 읽는 사람이 서로 다른 결정을 할 수 있도록 질문을 나누는 일이었어요. 매일의 기록은 무슨 일이 있었는지 남기고, 주간 판단은 그 사실로 무엇을 할지 이어 줘야 했어요.
