“근거를 더 넣어 주세요”와 “한 쪽 안으로 줄여 주세요”라는 의견이 동시에 왔다고 해 볼게요. 둘 중 나중에 온 의견을 따르는 것만으로는 문서가 좋아지지 않아요. 두 사람이 요구하는 것이 정보의 양인지, 읽는 위치인지, 판단에 필요한 근거인지 먼저 나누면 함께 충족할 방법이 보이기도 해요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
이번 예제는 CSV 자동화의 다음 검증 범위를 정하는 가상 내부 메모예요. 실제 회사 의견이나 승인 기록은 아니에요. 완성물은 최신 메모 (ZIP: memo-v2.md), 의견 처리 기록 (ZIP: decision-log.csv), 사례 부록 (ZIP: appendix.csv)이에요. 여섯 의견 가운데 네 개는 반영 또는 사실 정정으로 처리하고, 두 개는 담당과 기한을 붙여 보류해요.
문서 목적과 바꿀 수 없는 조건을 먼저 써요
가상의 요청자는 “현재 자동화를 전면 도입할지, 제한된 예비 검증을 계속할지 결정할 자료”를 원해요. 조건은 본문 한 쪽, 기준을 충족한 건수의 분자·분모와 오류 종류 표시, 상세 근거 부록 허용이에요. 표현과 배치는 편집 담당이 정할 수 있지만 참여 범위·예산·일정 변경은 가상 팀장이 결정한다고 정했어요.
이 조건을 적지 않으면 분량을 줄이라는 의견에 근거가 사라지고, 근거를 늘리라는 의견에 결정 질문이 묻힐 수 있어요. 조건은 의견을 거절하기 위한 방패가 아니라 같은 문서를 평가할 기준이에요. NASA의 의사결정 분석 안내 6.8.1.2도 기준과 의사결정 주체를 명확히 하고 대안을 평가하도록 설명해요. 여기서는 그 원칙을 작은 공동 편집 문서에 맞게 적용했어요.
의견 문장에서 요청과 이유를 분리해요
C01은 여덟 건의 상세 로그를 본문에 넣으라는 요구, C02는 결론만 남기고 근거표를 빼라는 요구예요. 겉으로는 충돌하지만 C01의 목적이 근거 확인이고 C02의 목적이 빠른 판단이라면 모두 만족시킬 수 있어요. 예제에서는 본문에 ‘8건 중 5건 충족, 실패 3건’과 오류 종류를 남기고, 전체 로그는 부록 A로 옮겼어요.
이 결정은 두 의견을 모두 ‘반영’으로 뭉뚱그리지 않고 ‘일부 반영’으로 기록해요. C01이 지정한 본문 위치는 받아들이지 않았고, C02가 요구한 근거 삭제도 받아들이지 않았기 때문이에요. 대신 요구의 목적을 어떻게 충족했는지를 이유 칸에 적었어요. 원래 의견은 보존하므로 검토자가 다른 뜻이었다고 정정해도 판단을 다시 할 수 있어요.
사실 문제는 취향 투표로 해결하지 않아요
C03은 “오류 없는 자동화”라고 쓰자는 의견이에요. 합성 입력은 T01~T08의 여덟 건이며, T03과 T06은 중복 키, T08은 빈 날짜 때문에 실패한 것으로 정했어요. 즉 기준 충족은 5건이고 실패는 3건이에요. 이것은 예제 안의 입력 사실이므로 세 사람이 표현을 좋아한다고 바뀌지 않아요.
최신 메모 M01은 “전면 도입은 보류하고 실패 유형을 수정한 뒤 기존 범위의 예비 검증을 진행하도록 권고한다”로 고쳤어요. ‘오류 없는’만 ‘안정적인’으로 바꾸면 근거보다 강한 판단이 남기 때문에 권고 자체도 조정했어요. 다만 이 문장은 편집자가 제안한 권고이며 승인된 결정은 아니에요.
C05는 고객명을 식별자로 바꾸라는 의견이에요. 이 자료는 처음부터 합성 사례지만 결정에 이름이 필요하지 않으므로 부록에서 T01~T08로 통일했어요. 같은 경우 실제 업무에서는 이름을 숨겨도 사유·날짜·세부 값의 조합으로 식별되는지 고려해야 해요. 이번 예제에는 실제 고객 데이터가 들어 있지 않아요.
범위 변경은 문서 편집과 따로 상태를 관리해요
C04는 참여 범위를 8명에서 30명으로 넓히라는 의견이에요. 표현 수정과 달리 자원과 일정이 달라지므로 편집 담당이 확정하지 않아요. 처리 기록에는 보류, 담당은 가상 팀장, 기한은 2026년 10월 15일, 필요한 입력은 확대 예산·일정안으로 남겼어요. 승인 근거가 없는 상태에서 최신본에 ‘30명 진행 확정’을 넣지 않았어요.
C06은 내일 나올 도구 판본의 결과를 포함하라는 요청이에요. 아직 결과가 없으므로 이전 판본의 성과를 새 판본의 것으로 옮길 수 없어요. M03에 현재 판본 v0.1과 입력 형식만 검토했다는 범위를 쓰고, M04에 분석 담당의 재확인 날짜를 남겼어요. ‘나중에 확인’ 대신 언제 무엇을 가져오면 문장을 바꿀지 정한 셈이에요.
보류가 있다고 문서 전체를 빈 상태로 둘 필요는 없어요. 현재 근거로 말할 수 있는 권고와, 권고를 확정하기 위해 필요한 결정을 나누면 독자가 다음 행동을 알 수 있어요. 단, 보류된 결정에 의존하는 실행은 문서가 완성되었다는 이유로 시작하지 않아요.
부록을 못 보내게 되면 같은 타협안을 유지하지 않아요
C01·C02를 함께 처리한 이유는 ‘본문 한 쪽’과 ‘상세 근거 부록 허용’이 동시에 유효하기 때문이에요. 보안이나 제출 형식 때문에 부록을 보낼 수 없게 되면 링크만 남긴 요약은 근거를 확인하려는 C01의 목적을 충족하지 못해요. 이때는 기존의 ‘일부 반영’ 상태를 다시 열고 제약을 바꿔 대조해요.
| 대안 | 기본 조건에서의 판단 | 부록을 금지하면 |
|---|---|---|
| 본문에 5/8·오류 3건, 8건 로그는 부록 | 필수 수치와 상세 추적을 함께 유지 | 상세 근거를 전달할 수 없어 재검토 |
| 결론만 남기고 근거를 모두 삭제 | 분자·분모와 실패 종류가 없어 제외 | 분량은 짧아도 여전히 제외 |
| 8건 로그를 본문 2쪽에 수록 | 1쪽 제한을 넘어서 제외 | 결정권자가 2쪽을 허용해야 가능 |
조건 입력 (ZIP: decision-conditions.json)에 선언한 세 대안을 대조하면 ‘1쪽 유지·부록 금지’에서는 충족안이 없어요. 그래서 이번 결과물은 임의의 축약본이 아니라 ‘2쪽 본문 허용 또는 접근 가능한 상세 근거 전달 경로 중 하나를 결정해 달라’는 재협의 항목이에요. 8행을 아주 작게 줄여 한 쪽에 넣는 방법도 생각할 수 있지만, 실제 제출 형식에서 가독성과 쪽수를 확인하기 전에는 해결됐다고 세지 않아요. 이 예제의 쪽수는 대안의 가정이며 PDF를 출력해 측정한 결과는 아니에요.
이 절차는 필수 기준을 못 맞춘 대안을 제외하고, 가정이 바뀌면 평가도 다시 하는 NASA 6.8.1.2.1·6.8.1.2.4의 원칙을 문서 편집에 적용한 예예요. NASA가 본문 한 쪽이나 특정 승인 양식을 요구한다는 뜻은 아니에요.
‘승인’이라는 단어 대신 적용 범위가 일치하는지 봐요
C04의 보류를 풀려면 누가 언제 결정했는지와 함께 대상 인원, 도구 판본, 예산안, 일정안이 연결돼야 해요. ‘30명으로 해 봅시다’라는 문장만 있고 예산·일정 검토가 남았다면 결정 기록을 요청한 상태를 유지해요. C06도 출시 예정일이 지났다는 이유로 완료되지 않아요. 판본 ID, 검증 입력, 성공·실패 결과와 실행 기록이 있어야 M03의 적용 범위를 고칠 수 있어요.
가정한 결정 기록이 ‘v0.1·30명·예산안 B1·일정안 S1’까지 승인했다고 해도, 실패 3건이 수정됐다는 증거는 별개예요. 범위 결정을 문서에 반영할 수 있는 것과 확대 검증에 착수할 준비가 된 것을 나눠요. 여기서 도구를 v0.2로 바꾸면 기존 범위 기록은 과거 증거로 보존하되, 새 판본 검증과 승인 범위 확인을 다시 열어요. 기존 승인이 모든 미래 판본에 적용된다고 추정하지 않아요.
실행 코드 (ZIP: verify-decisions.py)는 실제 부록의 8건을 읽어 충족 5·실패 3·중복 키 2·빈 날짜 1을 다시 세고, 의견 6개와 보류 2개의 담당·기한·해제조건을 확인해요. 이어 승인 없음, 범위만 맞는 가정, 판본 변경, 예산·일정 미확인의 네 조건을 대조해요. 범위가 맞는 가정 1개도 기술 준비 증거가 없으므로 실행 준비로 판정하지 않았어요. 검증 JSON (ZIP: decision-verification.json)은 합성 조건에 규칙을 적용한 실제 로컬 결과이며 조직의 승인이나 CSV 도구의 작동을 확인한 기록은 아니에요.
최신본과 처리 기록을 한 번 왕복해요
마지막에는 댓글 수가 줄었는지보다 연결이 맞는지 봐요. 각 의견 ID에서 새 문서 위치를 열고, 그 위치의 문장이 기록한 이유와 맞는지 확인해요. 반대로 최신본에서 중요한 변경을 골라 어느 의견이나 입력 사실 때문에 바뀌었는지도 찾아요. 이 왕복이 안 되면 ‘완료’ 표시가 실제 변경을 대신하고 있을 수 있어요.
제공 CSV에는 ID, 의견, 처리, 이유, 변경 위치, 담당, 기한, 상태와 보류를 풀 조건·다시 열 조건을 채웠어요. 원고 폴더에서 python3 assets/verify-decisions.py로 첨부 기록과 조건 검사를 다시 실행할 수 있어요. 승인되지 않은 두 사안은 명확히 남겨 두었어요. 문서를 다른 형식으로 옮길 때도 이 연결을 유지하면 돼요. 줄 번호가 자주 바뀌면 안정된 절 이름을 먼저 쓰고, 최종 PDF에서 필요한 페이지를 보태세요.
2026년 10월 13일 공개 의사결정 지침을 확인하고 가상 입력으로 문서와 기록을 작성했어요. 실제 팀 합의나 승인·실행은 없어요. 학술 심사처럼 외부 검토자에게 변경을 설명해야 하는 경우에는 리뷰어 답변서처럼 직접 답변과 수정 문장을 붙이면 돼요.
작성·확인: Codex가 공개 원문 또는 공식 문서를 확인하고 예제와 초안을 작성했어요. 사람을 대상으로 한 사용성 검증은 수행하지 않았어요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.