개발 중 요구사항이 바뀌면 변경 내용만 전달하지 말고 바꾼 이유, 영향을 받는 업무, 보류한 사항을 함께 남겨야 합니다. 요청 메시지를 보관하는 것만으로는 현재 합의가 무엇인지 찾기 어렵습니다. 결정 기록을 짧게 남기면 다음 회의와 검수에서 같은 질문을 반복하는 일을 줄일 수 있습니다.
기록은 긴 회의록일 필요가 없습니다. 어떤 조건을 바꾸기로 했는지와 그 선택의 근거, 실제 반영 여부를 한 곳에서 확인할 수 있으면 됩니다. 특히 AI 기능이 포함된 업무에서는 답변 방식의 변경과 회사 업무 규칙의 변경을 구분해야 합니다.
결정 기록이 필요한 이유는 구현한 내용과 회의에서 기대한 내용의 차이를 나중에도 판정해야 하기 때문입니다. 이유와 보류 조건이 빠지면 같은 요청을 두고 결함 수정인지 추가 개발인지부터 다시 논의하게 됩니다. 변경 전후와 확인 방법을 남기면 검수 기준, 영향받는 업무, 아직 끝나지 않은 일을 함께 추적할 수 있습니다.
요청, 결정, 반영 상태를 나눕니다
“보고서에 거래처별 합계를 넣어 주세요”라는 말이 나왔다고 바로 개발 범위가 확정되는 것은 아닙니다. 누가 그 합계를 쓰는지, 기준일과 취소 거래 처리는 무엇인지 확인해야 합니다. 검토 중인 요청을 확정 요구사항과 같은 목록에 표시하면 서로 다른 기대가 생깁니다.
상태는 요청됨, 검토 중, 결정됨, 반영 확인처럼 나누어 사용할 수 있습니다. 보류와 취소도 따로 표시합니다. 이름은 회사에 맞춰 정하되 “결정됨”이 곧 “운영에 반영됨”을 뜻하지 않게 합니다. 결정일과 적용일이 다르면 두 날짜를 함께 적습니다.
AI가 회의 내용을 요약했더라도 결정 권한이 있는 사람이 내용을 확인해야 합니다. “검토하겠다”는 발언이 “적용한다”로 바뀌지 않았는지, 조건부 합의의 조건이 빠지지 않았는지 봅니다. 확정하지 못한 부분을 빈칸으로 남기는 편이 잘못된 합의를 만드는 것보다 낫습니다.
그대로 사용하는 결정 기록 양식
| 항목 | 적을 내용 |
|---|---|
| 기록 번호와 주제 | 나중에 찾을 식별자와 업무 이름 |
| 현재 상태 | 요청·검토·결정·보류·반영 확인 등 |
| 변경 전과 후 | 달라지는 조건을 나란히 설명 |
| 변경 이유 | 새로 확인한 사실 또는 업무상 필요 |
| 검토한 선택지 | 채택한 방식과 다른 방식의 보류 이유 |
| 영향 범위 | 화면·데이터·권한·알림·일정 등 |
| 결정 역할과 날짜 | 합의한 역할, 결정일, 적용 예정일 |
| 남은 질문 | 미정 사항과 답할 담당 역할 |
| 확인 방법과 결과 | 검수 입력, 기대 결과, 실제 확인 상태 |
양식에 모든 내용을 길게 쓸 필요는 없습니다. 관련 요구사항과 화면 설명이 이미 있다면 경로를 연결합니다. 다만 “회의대로 수정”이나 “기존과 동일”처럼 당시 참석자만 아는 말로 남기지 않습니다. 새로 들어온 담당자도 무엇이 달라졌는지 읽을 수 있어야 합니다.
설명용 예시: 월말 집계에 취소 거래를 반영하기
가상의 유통 회사에서 월말 매출표에 취소 거래를 어떻게 반영할지 바뀌었다고 가정해 보겠습니다. 변경 전에는 주문 금액을 단순 합산했고, 변경 후에는 기준일까지 취소가 확정된 주문을 집계에서 제외하기로 했습니다. 이유는 회계 담당자가 보고서와 실제 처리 내역을 대조할 수 있도록 하기 위해서입니다.
기록에는 제외 조건뿐 아니라 기준일, 부분 취소 처리, 과거 보고서 재계산 여부를 함께 남깁니다. 부분 취소가 미정이라면 자동으로 전액 제외하도록 추측해 구현하지 않습니다. 그 항목은 보류하고 어떤 역할이 규칙을 정할지 적습니다.
영향 범위에는 보고서 합계, 내려받는 파일, 화면의 취소 상태 표시, 기존 데이터 처리 여부를 넣을 수 있습니다. 일정과 비용에 영향이 있다면 실제 검토 결과를 별도로 합의합니다. 작아 보이는 문구 변경을 보고 모든 영향이 없다고 단정하지 않습니다.
결정이 실제 반영으로 이어지는 과정
검수할 예시도 결정할 때 남깁니다
취소 거래 예시라면 정상 주문, 전액 취소, 부분 취소, 기준일 이후 취소를 각각 준비합니다. 모든 경우의 기대 결과가 정해지지 않았다면 어느 범위까지 확인할 수 있는지 표시합니다. 검수 때 처음 규칙을 해석하면 결정 기록이 있어도 합의가 다시 흔들립니다.
구현 결과가 기대와 다르면 결함인지 새로운 요구인지 구분합니다. 이미 정한 조건을 구현하지 못한 경우와 합의 후 추가 조건이 생긴 경우는 처리 방식이 다릅니다. 원래 기록을 지워 새 결정만 남기기보다 변경 이유를 이어 적어 현재 규칙에 이른 과정을 보존합니다.
운영에 적용한 뒤에는 실제 사용 화면과 결과 파일에서 바뀐 조건을 확인하고 그 위치를 기록합니다. 개발 환경에서 확인한 상태라면 그대로 표시합니다. 회의에서 합의한 사실, 코드에 반영한 사실, 운영에서 확인한 사실을 각각 남겨야 후속 담당자가 남은 일을 알 수 있습니다.
기존 요구사항을 만드는 방법은 ERP 요구사항 체크리스트에서 볼 수 있습니다. 결정이 운영 데이터 수정까지 이어지는 경우에는 일괄 데이터 변경의 확인 기준도 함께 참고하세요.
회의가 끝날 때 확인할 항목
- 검토 중인 의견과 확정한 결정을 구분했습니까?
- 변경 전후의 차이를 조건과 결과로 설명했습니까?
- 관련 화면뿐 아니라 데이터와 권한의 영향도 살폈습니까?
- 미정 항목마다 답할 역할이 적혀 있습니까?
- 결정일, 적용일, 실제 반영 확인을 구분했습니까?
시온랩의 S-Docs는 운영 과정의 예외와 의사결정을 문서로 남겨 인계하는 구성을 안내합니다. 개발 중에도 같은 방식으로 짧은 결정 기록을 쌓아 두면 현재 규칙과 보류 질문을 다음 담당자에게 설명하기 쉬워집니다. 다음 변경 요청부터 이 양식의 변경 전후와 이유 항목을 먼저 채워 보세요.
