R&D 마일스톤 게이트 리뷰 체크리스트: go/no-go 결정 기준과 design review package를 감사 기록으로 남기는 법

빠른 결론

R&D 마일스톤 게이트 리뷰는 “회의를 했는가”를 확인하는 자리가 아니라 다음 단계 예산과 인력을 풀어도 되는지 결정하는 통제점입니다. 통과 기준은 발표 슬라이드의 완성도가 아니라 산출물의 존재, 증거 성숙도, 미해결 이슈의 처리계획, 예산 소진 대비 실제 deliverables, 이해관계자 signoff, gate 이후 변경 요청의 통제 가능성으로 잡아야 합니다[S1][S2][S5]. 결정문에는 go, conditional go, no-go, hold 중 하나와 조건, 책임자, 마감일, 감사 추적용 근거 링크가 남아야 합니다[S2][S3].

마일스톤 게이트가 흐려지는 순간은 대개 비슷합니다. 개발팀은 “계획한 기능은 거의 만들었다”고 말하고, 제품팀은 “고객 데모는 가능하다”고 말하며, 재무 담당자는 “예산은 이미 많이 썼다”고 말합니다. 그러나 게이트 리뷰가 확인해야 하는 질문은 셋 중 어느 쪽도 아닙니다. 정확한 질문은 “현재 증거로 다음 단계의 비용과 위험을 승인할 수 있는가”입니다. Stage-Gate 모델은 게이트를 다음 단계 진입 전의 go/kill 및 자원 배분 의사결정점으로 봅니다[S1]. NASA의 시스템 엔지니어링 리뷰도 생애주기 단계마다 기술·프로그램 상태와 건강도를 점검하고, 다음 단계 진행 여부를 판단할 수 있도록 리뷰 패키지와 결과 기록을 남기도록 설명합니다[S2].

이 글은 정부 R&D 평가 지표, 리스크 레지스터, QMS, 최종보고서, TRL 검증, 예산 일정표, 사업화 로드맵을 대신하지 않습니다. 그 주제들은 각각 다른 질문을 다룹니다. 여기서는 제품·R&D 팀이 내부 마일스톤 회의에서 다음 단계로 갈지, 조건부로 갈지, 멈출지를 결정하기 위해 어떤 패키지를 보고 어떤 문장으로 기록해야 하는지만 다룹니다. 그래서 “평가 점수 높이는 법”보다 “회의에서 나중에 다시 읽어도 방어되는 결정문을 남기는 법”에 가깝습니다.

R&D 마일스톤 게이트 리뷰의 첫 질문은 산출물보다 결정 유형입니다

게이트 리뷰 안건을 만들 때 가장 먼저 정해야 할 것은 보고 순서가 아니라 가능한 결정 유형입니다. 제품·R&D 팀에는 최소 네 가지가 필요합니다. 첫째, go는 다음 단계로 진행하되 이미 식별된 잔여 이슈를 통상 관리 범위에서 처리한다는 뜻입니다. 둘째, conditional go는 일정 범위의 예산과 인력은 열어 주지만 특정 조건이 닫히기 전에는 외부 파일럿, 장비 발주, 대량 시험, 고객 공개 같은 큰 실행을 막는 결정입니다. 셋째, no-go는 현재 경로의 중단 또는 대안 재검토입니다. 넷째, hold는 기술 판단이 아니라 증거 부족 때문에 결정을 유예하는 상태입니다.

이 네 가지를 구분하지 않으면 회의록은 “논의 후 진행”이라는 말로 끝나고, 나중에 왜 진행했는지 설명하지 못합니다. NASA 생애주기 리뷰 안내는 주요 의사결정점에서 기술 성숙도, 자원 충분성, 내부 이슈와 리스크, 이해관계자 기대 변화 등을 함께 본다고 설명합니다[S2]. 이 관점을 일반 제품·R&D 팀에 적용하면, 게이트는 기능 완성 보고회가 아니라 “다음 단계의 비용과 위험을 누가 어떤 근거로 받아들였는가”를 남기는 회의입니다.

따라서 안건 첫 페이지에는 결정 유형, 요청하는 다음 단계, 승인 범위, 승인하지 않는 범위를 분리해 적습니다. 예를 들어 “P2 프로토타입 외부 파트너 데모 진행”은 너무 넓습니다. 더 나은 문장은 “내부 검증 빌드 v0.7 기준으로 파트너 2곳의 기술 데모를 허용하되, 유료 파일럿 계약·규제 적합성 문구·양산 부품 발주는 허용하지 않는다”입니다. 이 정도로 써야 게이트 통과가 사업화 로드맵 승인이나 TRL 단계 상승으로 오해되지 않습니다.

게이트 결정 유형 표

<table>

<thead>

</thead>

<tbody>

<tr><td>conditional go</td><td>진행 가치는 있으나 특정 증거·승인·수정 조건이 남음</td><td>조건, 책임자, 조건 미충족 시 중지 기준</td></tr>

<tr><td>hold</td><td>방향은 유효하지만 증거 성숙도가 낮아 결정 불가</td><td>부족한 증거, 보완 마감일, 재게이트 일정</td></tr>

<tr><td>no-go</td><td>목표 불일치, 치명 결함, 예산 대비 산출물 부족, 이해관계자 미승인</td><td>중단 범위, 보존할 산출물, 대안 검토 책임</td></tr>

</tbody>

</table>

design review package는 슬라이드보다 추적 가능한 원본 묶음이어야 합니다

게이트 리뷰 패키지는 예쁜 발표자료가 아닙니다. 발표자료는 요약이고, 결정 근거는 원본 산출물입니다. NASA는 리뷰에서 기술팀이 전체 프로그램·프로젝트 리뷰 패키지에 들어갈 기술 입력물을 제공한다고 설명하며, 리뷰 일정·자료·결과를 관리 기록으로 유지하도록 요구합니다[S2]. ISO 21502도 프로젝트 관리 지침이 조직과 프로젝트 유형에 넓게 적용될 수 있고, 생애주기 모델과 전달 방식이 달라도 사용할 수 있다고 설명합니다[S5]. 즉 게이트 패키지는 특정 산업의 거창한 산출물이 아니라 어떤 팀에서도 “같은 결정을 다시 추적할 수 있는 묶음”이어야 합니다.

패키지의 기본 구성은 여섯 묶음이면 충분합니다. 첫째, 결정 요청서입니다. 다음 단계에서 무엇을 하려는지, 어떤 자원을 요청하는지, 어떤 범위는 승인하지 않는지 적습니다. 둘째, design review package입니다. 요구사항 변경표, 설계 기준, 인터페이스 결정, 아키텍처 다이어그램, 실험·검증 결과, 사용자 또는 내부 사용 시나리오, 결정되지 않은 설계 선택지를 묶습니다. 셋째, 증거 성숙도 표입니다. 각 주장에 원본 파일, 시험 조건, 재현 가능성, 검토자, 날짜가 붙어야 합니다. 넷째, 미해결 이슈 로그입니다. 이슈가 있다는 사실보다 그 이슈가 gate 결정을 막는지, 조건부 진행으로 넘길 수 있는지가 중요합니다. 다섯째, budget burn vs deliverables 표입니다. 쓴 돈과 만든 산출물을 한 줄에 놓아 다음 단계 예산을 열어도 되는지 봅니다. 여섯째, stakeholder signoff와 변경 통제 기록입니다.

패키지에서 가장 위험한 문서는 “최신본”이라는 이름의 파일입니다. 최신본은 감사 추적에 약합니다. 대신 파일명과 회의록에는 기준 버전이 들어가야 합니다. 예를 들어 architecture_v0.8_gate2_2026-07-03, test-summary_build-142_gate2, issue-log_gate2_open-closed처럼 남깁니다. 이렇게 해 두면 gate 이후 설계 변경이 들어와도 어떤 문서가 당시 판단의 기준이었는지 분리할 수 있습니다.

evidence maturity는 완성률이 아니라 결정에 쓸 수 있는 근거 수준입니다

R&D 조직은 “80% 완성”이라는 표현을 자주 쓰지만, 게이트 리뷰에서는 위험한 말입니다. 80%가 기능 개수인지, 시험 통과율인지, 설계 검토 완료율인지, 예산 집행률인지 알 수 없기 때문입니다. evidence maturity는 완성률 대신 “이 주장을 의사결정에 써도 되는가”를 묻는 기준입니다. NASA Appendix G는 리뷰의 entrance와 success criteria가 기술 성숙도, 기술 계획의 적절성, 예산·일정·리스크의 신뢰성, 다음 단계 준비도에 초점을 둬야 한다고 설명합니다[S3]. 이 관점에서 증거 성숙도는 발표자의 확신이 아니라 검토자가 다시 열어볼 수 있는 근거의 품질입니다.

실무에서는 네 단계로 나누면 충분합니다. M0 주장은 근거 없이 팀 의견만 있는 상태입니다. M1 관찰은 데모, 내부 시험, 고객 코멘트, 계산표처럼 흔적은 있지만 조건과 원본이 약한 상태입니다. M2 추적 가능 증거는 시험 조건, 입력 데이터, 버전, 책임자, 날짜가 붙어 같은 결론을 다시 검토할 수 있는 상태입니다. M3 게이트 결정 가능 증거는 M2에 더해 반례, 잔여 이슈, 예외 조건, 다음 단계 영향이 함께 기록된 상태입니다.

evidence maturity ladder

M0 주장: “가능할 것 같다”, “문제없어 보인다”처럼 회의 발언만 있음

M1 관찰: 데모·시험·리뷰 흔적은 있으나 조건, 버전, 원본 링크가 약함

M2 추적 가능 증거: 원본 파일, 날짜, 버전, 검토자, 시험 조건, 결과가 연결됨

M3 결정 가능 증거: 잔여 이슈, 예외, 다음 단계 영향, 조건부 승인 문구까지 붙음

게이트 통과는 모든 항목이 M3이어야 한다는 뜻이 아닙니다. 핵심은 결정에 영향을 주는 주장만큼은 M2 이상이어야 한다는 것입니다. 예를 들어 “외부 데모가 가능하다”는 주장은 빌드 버전, 시연 시나리오, 실패 시 복구 절차, 데이터 사용 범위가 있어야 합니다. 반면 “UI 문구를 더 다듬는다”는 잔여 작업은 다음 단계 비용과 위험을 크게 바꾸지 않는다면 M1로 남겨도 됩니다. 이 구분이 없으면 회의가 모든 TODO를 같은 무게로 다루다가 진짜 gate blocker를 놓칩니다.

미해결 이슈 로그는 리스크 레지스터가 아니라 게이트 차단 여부 표입니다

미해결 이슈 로그는 리스크 레지스터와 다릅니다. 리스크 레지스터는 발생 가능성과 영향, 대응 전략을 장기적으로 관리합니다. 게이트 이슈 로그는 훨씬 좁습니다. 이 gate에서 다음 단계 진행을 막는가, 조건부 진행으로 넘길 수 있는가, 그냥 일반 작업으로 처리해도 되는가를 분류합니다. NASA 리뷰 완료 기준은 Review Item Discrepancies와 Requests for Action의 처리 합의, 리뷰 보드 보고서와 회의록 배포, 이슈·조치 계획 합의, 미해결 lien의 폐쇄 또는 적절한 폐쇄 계획을 요구합니다[S2]. 일반 R&D 팀도 같은 원리를 가볍게 적용할 수 있습니다.

이슈 로그의 최소 필드는 issue_id, description, evidence_link, gate_impact, decision_status, owner, due_date, closure_evidence입니다. 여기서 핵심은 gate_impact입니다. blocker는 해결 전에는 다음 단계로 갈 수 없는 항목입니다. condition은 조건부 진행의 문구로 들어갈 항목입니다. watch는 다음 단계에서 추적하지만 현재 결정은 막지 않는 항목입니다. out_of_scope는 이번 gate에서 다루지 않는 항목입니다. out_of_scope를 허용해야 회의가 QMS, 최종보고서, 사업화 로드맵까지 끝없이 확장되는 것을 막을 수 있습니다.

미해결 이슈 로그 예시

<table>

<thead>

</thead>

<tbody>

<tr><td>blocker</td><td>핵심 성능 시험 원본이 없고 결과 재현도 불가</td><td>no-go 또는 hold</td></tr>

<tr><td>condition</td><td>외부 데모 가능하나 보안 문구와 데이터 샘플 교체 필요</td><td>conditional go 조건으로 기록</td></tr>

<tr><td>watch</td><td>비핵심 UI 수정, 다음 스프린트 처리 가능</td><td>go 후 action item으로 추적</td></tr>

<tr><td>out_of_scope</td><td>최종보고서 양식, 전체 QMS 절차, 사업화 지원사업 선택</td><td>인접 문서로 이동</td></tr>

</tbody>

</table>

좋은 로그는 많은 이슈를 담는 표가 아니라 gate 결정을 가볍게 만드는 표입니다. 검토자가 “이슈가 남았는데 왜 통과했나”라고 물었을 때 “blocker는 없고, condition 두 개는 책임자와 마감일이 있으며, watch 항목은 다음 단계 계획에 반영했다”고 답할 수 있어야 합니다. 반대로 blocker가 있는데도 “논의 완료”라고 적으면 gate 리뷰는 방어력을 잃습니다.

budget burn vs deliverables는 예산 타임라인이 아니라 다음 단계 자원 승인 근거입니다

예산 소진률은 게이트 리뷰에서 강한 압박을 만듭니다. 이미 많이 썼으니 계속 가야 한다는 sunk cost 논리가 생기기 때문입니다. 하지만 게이트의 질문은 “얼마를 썼는가”가 아니라 “쓴 예산이 다음 단계 판단에 필요한 산출물로 바뀌었는가”입니다. DOE의 프로젝트 관리 자료는 critical decision milestones, performance baseline, earned value management, change control 같은 주제를 프로젝트 리뷰와 의사결정에 연결합니다[S6]. 이를 제품·R&D 팀에 맞게 줄이면 budget burn은 단독 지표가 아니라 deliverables와 나란히 놓을 때만 의미가 있습니다.

표에는 계획 예산, 실제 사용액, 계획 산출물, 실제 산출물, 미완료 산출물, 다음 단계 영향, 추가 예산 요청 사유를 한 줄에 둡니다. 예를 들어 “설계 검증 예산 2천만 원 중 1천6백만 원 사용”만 있으면 판단할 수 없습니다. “3개 시험 중 2개 완료, 1개는 장비 교정 실패로 hold, 외부 데모 승인에는 영향 없으나 양산 부품 발주는 금지”라고 써야 gate 결정과 연결됩니다. 이 글은 예산 배정 일정 자체를 다루지 않습니다. 일정 중심의 R&D 예산 계획은 2026 R&D 예산 타임라인에서 따로 보는 것이 맞습니다.

예산 대비 산출물 표는 no-go 판단에도 필요합니다. 비용을 많이 썼다는 이유로 진행하는 것이 아니라, 비용을 더 쓰기 전에 중단하는 근거를 주기 때문입니다. 특히 반복 실험, 외주 설계, 장비 제작, 데이터 구매가 붙은 프로젝트에서는 gate 이후 지출 단위가 커집니다. 따라서 이번 gate에서 승인하는 다음 단계 예산 한도, 승인하지 않는 지출, 변경 요청이 필요한 비용 임계값을 함께 적어야 합니다. “다음 단계 진행”이라는 말보다 “최대 3천만 원까지 내부 검증과 제한된 파트너 데모에 사용, 외부 인증·양산 금형·유료 고객 계약은 별도 gate 필요”라는 문장이 안전합니다.

stakeholder signoff는 참석자 명단이 아니라 기대 변화의 승인입니다

게이트 리뷰의 signoff는 회의 참석 체크가 아닙니다. 제품, 연구, 품질, 보안, 재무, 영업, 파트너 담당자가 각자 무엇을 승인했고 무엇을 승인하지 않았는지 남기는 행위입니다. NASA 생애주기 리뷰는 이해관계자 기대 변화도 주요 의사결정점에서 검토할 요소로 봅니다[S2]. Stage-Gate 모델도 gate에서 비즈니스 가치, 준비도, 사업 우선순위 정렬을 평가한다고 설명합니다[S1]. 그래서 stakeholder signoff는 “모두 동의”라는 문장이 아니라 기대와 조건의 충돌을 줄이는 장치입니다.

승인 표에는 역할, 승인 범위, 보류 조건, 반대 의견, 후속 조치를 분리합니다. 연구책임자는 기술 증거의 해석에 signoff할 수 있지만 고객 계약 문구까지 승인하는 것은 아닐 수 있습니다. 제품책임자는 고객 시나리오를 승인할 수 있지만 안전·보안 예외를 승인하지 못할 수 있습니다. 재무 담당자는 다음 단계 예산 한도를 승인할 수 있지만 제품 공개 범위를 승인하지 않습니다. 이 경계를 적지 않으면 나중에 “그 회의에서 승인된 줄 알았다”는 말이 나옵니다.

반대 의견은 삭제하지 않는 편이 좋습니다. NASA 리뷰 완료 조건에도 검토 보드와 프로젝트 간 의견 차이가 해결되었거나 해결 계획이 있어야 한다는 취지가 들어 있습니다[S2]. 작은 팀에서는 이를 “dissent 또는 reservation” 칸으로 처리하면 됩니다. 예를 들어 보안 담당자가 “외부 데모는 가능하지만 실제 고객 데이터 사용은 반대”라고 적었다면, 결정문은 conditional go가 되어야 합니다. 이렇게 남긴 반대 의견은 팀을 느리게 만드는 문서가 아니라 gate 이후 변경 요청의 기준선이 됩니다.

gate 이후 change request는 새 아이디어가 아니라 기준선 변경입니다

게이트를 통과한 뒤에는 반드시 변경 요청이 생깁니다. 고객이 새로운 요구를 말하고, 시험 결과가 바뀌고, 공급사가 부품을 바꾸고, 예산 담당자가 비용을 줄이라고 합니다. 문제는 변경 자체가 아니라 변경이 gate 결정 기준선을 조용히 바꾸는 것입니다. NASA 시스템 엔지니어링 핸드북의 계획 문맥은 milestone decision gates, major technical reviews, entry and success criteria, baseline work products를 계획 안에서 연결해 다루는 관점을 보여 줍니다[S4]. DOE 자료도 change control management를 별도 프로젝트 관리 지침으로 다룹니다[S6].

따라서 gate 이후 change request에는 최소 네 가지 질문이 붙어야 합니다. 첫째, 이 변경이 gate에서 승인한 범위 안인가. 둘째, design review package의 어떤 기준선 문서를 바꾸는가. 셋째, budget burn vs deliverables 표에서 어느 비용 또는 산출물 라인을 바꾸는가. 넷째, stakeholder signoff를 다시 받아야 하는가. 이 네 질문 중 두 개 이상이 “예”라면 단순 작업 변경이 아니라 mini-gate 또는 재승인이 필요합니다.

gate 이후 바로 재승인이 필요한 변경 신호

외부 공개 범위, 고객 데이터 사용, 보안 조건, 규제 문구가 바뀌는 경우

핵심 시험 조건이나 성공 기준을 완화해야만 통과 가능한 경우

승인된 예산 한도 또는 외주·장비 발주 범위를 넘는 경우

stakeholder signoff 당시 보류된 조건을 우회하는 경우

미해결 이슈 로그의 condition 항목을 닫지 않고 다음 단계 실행을 넓히는 경우

변경 요청을 모두 막을 필요는 없습니다. 오히려 R&D에서는 좋은 변경이 많습니다. 다만 변경 요청서에는 change_id, origin, baseline_affected, decision_needed, cost_schedule_impact, evidence_required, approver, audit_note가 있어야 합니다. 이렇게 남기면 다음 게이트에서 “왜 처음 결정과 달라졌는가”를 설명할 수 있습니다. 이 글은 전체 QMS 변경관리 절차를 다루지 않습니다. 품질 시스템 수준의 증거와 절차는 R&D 품질관리 QMS 증거 체크리스트에서 별도로 확인하는 편이 맞습니다.

감사 대응용 gate decision record는 10분 뒤가 아니라 1년 뒤 읽히게 써야 합니다

좋은 gate decision record는 회의 직후의 기억을 보완하는 문서가 아니라, 1년 뒤 감사·인수인계·분쟁·재검토 상황에서 읽히는 문서입니다. EU Funding & Tenders Portal은 프로젝트 진행 중 milestones와 deliverables 상태, critical risks 대응 등을 지속 보고 대상으로 설명하고, milestones를 진척을 확인하는 control point로 구분합니다[S7]. NASA도 기술 상태 리뷰가 나중에 참조할 수 있는 결정의 역사적 기록을 제공한다고 설명합니다[S2]. 두 자료를 함께 보면 gate decision record는 “누가 무엇을 기억하는가”보다 “어떤 통제점에서 어떤 산출물과 근거로 무엇을 승인했는가”에 초점을 둬야 합니다.

결정문은 길 필요가 없습니다. 대신 빠지면 안 되는 필드가 있습니다. gate_name, baseline_version, decision, approved_scope, not_approved_scope, conditions, open_issues, budget_limit, stakeholder_signoff, change_control_trigger, next_review, source_links입니다. 특히 not_approved_scope가 중요합니다. 많은 문제가 승인 범위를 적어서가 아니라 승인하지 않은 범위를 적지 않아서 생깁니다. “파트너 데모 승인”만 쓰면 유료 파일럿, 보도자료, 고객 데이터 사용, 인증 주장까지 같이 승인된 것처럼 읽힐 수 있습니다.

결정문에는 근거 링크를 직접 붙입니다. 발표자료 링크 하나로 끝내지 말고 design review package 원본, 시험 요약, 이슈 로그, 예산 대비 산출물 표, signoff 표, 변경 요청 기준을 각각 연결합니다. 원본이 사내 저장소에 있다면 경로와 접근권한을 남깁니다. 외부 감사나 정부 과제 최종보고서 제출을 위한 증빙 패키지는 별도 범위입니다. 그런 경우에는 정부 R&D 최종보고서 증빙 패키지 체크리스트를 이어 읽는 것이 맞습니다.

R&D 마일스톤 게이트 리뷰 체크리스트 30분 실행 순서

회의 시간이 짧다면 다음 순서로 확인합니다. 0~5분에는 결정 유형을 먼저 잠급니다. 이번 회의가 go, conditional go, hold, no-go 중 무엇을 결정해야 하는지와 승인하지 않을 범위를 적습니다. 5~10분에는 design review package의 원본 링크와 기준 버전을 확인합니다. 슬라이드가 아니라 요구사항, 설계, 시험, 이슈, 예산, signoff 원본이 있는지 봅니다. 10~15분에는 evidence maturity를 훑습니다. 다음 단계 결정에 영향을 주는 주장이 M2 이상인지, M0/M1 주장이 gate 판단에 쓰이고 있지는 않은지 표시합니다.

15~20분에는 미해결 이슈 로그를 blocker, condition, watch, out_of_scope로 나눕니다. 이때 리스크 레지스터 전체를 다시 쓰려고 하면 안 됩니다. 장기 리스크 대응은 R&D 리스크 레지스터와 contingency 체크리스트로 넘기고, 이 회의에서는 gate 차단 여부만 봅니다. 20~25분에는 budget burn vs deliverables를 확인합니다. 이미 사용한 예산이 어떤 산출물로 바뀌었는지, 다음 단계 예산 한도와 금지 지출이 무엇인지 적습니다. 25~30분에는 stakeholder signoff, gate 이후 change request 기준, 다음 리뷰일을 결정문에 넣습니다.

이 순서를 따르면 게이트 리뷰는 느린 승인 절차가 아니라 빠른 정리 장치가 됩니다. 팀은 모든 불확실성을 없애지 않아도 됩니다. 대신 어떤 불확실성은 받아들이고, 어떤 불확실성은 조건으로 묶고, 어떤 불확실성은 다음 단계 진행을 막는지 구분해야 합니다. 그 구분이 문서에 남아 있으면 다음 회의는 기억 싸움이 아니라 기준선 비교가 됩니다.

이 글에서 다루지 않는 인접 주제

게이트 리뷰는 여러 R&D 문서와 맞닿아 있지만 같은 문서는 아닙니다. 정부 과제 평가 문항을 제안서 증거로 바꾸는 작업은 정부 R&D 평가 지표 체크리스트가 더 맞습니다. 기술 성숙도 자체를 검증하는 작업은 R&D 프로토타입 TRL 검증 체크리스트가 맞습니다. 품질 시스템과 변경관리의 조직 절차는 QMS 문서 범위입니다. 사업화 경로와 후속 지원사업을 고르는 일은 R&D 사업화 로드맵 체크리스트의 질문입니다.

이번 글의 범위는 더 좁습니다. 제품·R&D 팀이 특정 마일스톤에서 다음 단계 자원을 열지 말지 결정하고, 그 결정을 나중에 다시 읽을 수 있게 남기는 것입니다. 좋은 gate decision record는 팀을 방어적으로 만들기보다 빠르게 만듭니다. 결정 기준, 증거 수준, 이슈 처리, 예산 대비 산출물, signoff, 변경 요청 기준이 한곳에 있으면 다음 단계의 실행 속도가 올라가고, 나중에 결정이 흔들릴 때도 “그때 왜 그렇게 했는지”를 설명할 수 있습니다.