**빠른 결론**
R&D design freeze는 "이제 아무것도 바꾸지 않는다"가 아니라 "이 기준선 이후의 변경은 요청, 영향 분석, 승인, 재검증, 릴리스 노트 증거 없이는 인계물에 섞지 않는다"는 통제선입니다. 프로토타입 인계 전에는 동결 대상, 허용 예외, 변경 요청서 양식, 요구사항/시험 영향, 비용과 일정 영향, 승인권자, 동결 후 결함 분류, 릴리스 노트 증거가 같은 기준선 번호로 연결되어야 합니다[S1][S3][S4]. 이 글은 QMS 전체 절차나 마일스톤 gate review가 아니라, 한 번 동결된 설계 패키지를 인계 가능한 상태로 지키는 문서 판단에만 집중합니다.
프로토타입 인계 직전의 설계 동결은 회의에서 가장 쉽게 오해됩니다. 연구팀은 "주요 기능은 끝났다"고 말하고, 제작팀은 "도면이 더 바뀌면 발주를 못 한다"고 말하며, 시험 담당자는 "아직 실패 케이스가 남았다"고 말합니다. 이때 design freeze를 단순 완료 선언으로 쓰면 다음 단계에서 문제가 생깁니다. 어떤 요구사항을 기준으로 만들었는지, 어떤 시험을 다시 해야 하는지, 누가 변경을 승인했는지, 릴리스 노트에는 무엇을 남겨야 하는지 흐려지기 때문입니다.
이 글의 범위는 좁습니다. R&D 품질관리 QMS 전체 체크리스트, 마일스톤 gate review, 사용자 테스트, 리스크 레지스터, 추적성 매트릭스, 제조 스케일업은 다루지 않습니다. 해당 주제들은 각각 다른 판단 단위를 갖습니다. 여기서는 프로토타입을 넘기기 전 "동결된 설계 기준선"과 "동결 후 변경 통제"를 어떻게 기록해야 하는지만 봅니다. 그래서 문서는 길고 거창할 필요가 없습니다. 대신 한 줄을 바꿀 때마다 어떤 기준선, 요구사항, 시험, 비용, 일정, 승인, 릴리스 노트가 같이 움직이는지 보여야 합니다.
R&D design freeze는 회의 통과가 아니라 기준선 잠금입니다
좋은 design freeze 문장은 짧지만 경계가 분명합니다. "2026-07-03 DF-01 기준으로 PRD v1.4, 시스템 요구사항 SRS v0.9, 인터페이스 사양 IF-02, 회로/기구 도면 패키지 DPK-07, 검증계획 VTP-03을 prototype handoff baseline으로 동결한다"처럼 씁니다. 이 문장에는 무엇을 잠갔는지, 어떤 버전을 잠갔는지, 어디까지가 인계 대상인지가 들어 있습니다. 반대로 "설계 완료" 또는 "프로토타입 준비 완료"만 쓰면 변경 통제의 출발점이 없습니다.
NASA 시스템공학 핸드북의 구성관리 설명은 기준선 이후 변경을 제안, 정당화, 평가, 승인, 반영, 검증하는 흐름으로 봅니다[S1]. ISO 10007도 구성관리를 제품과 서비스의 개념 단계부터 폐기까지 적용 가능한 관리 지침으로 설명합니다[S3]. 이 관점을 R&D 팀에 맞추면 design freeze는 창의성을 막는 잠금장치가 아니라, 창의적인 변경을 프로토타입 인계물에 섞기 전에 비용을 보이게 하는 장치입니다.
동결 대상은 산출물의 전부가 아니라 인계 판단에 영향을 주는 구성 항목입니다. 보통 요구사항 기준선, 설계 출력, 인터페이스, 시험 기준, 알려진 이슈, 사용 제한, 릴리스 노트 초안이 들어갑니다. 연구 노트, 아이디어 백로그, 장기 개선 후보까지 모두 동결하면 개발 속도가 떨어집니다. 반대로 도면과 코드만 동결하고 시험 기준과 예외 조건을 빼면 인계 후 결함 책임이 흐려집니다. 핵심은 "이 버전으로 제작하거나 시험해도 되는가"라는 질문에 답하는 항목만 잠그는 것입니다.
프로토타입 인계 전 design freeze criteria는 8개 칸으로 충분합니다
동결 기준은 체크박스가 아니라 인계 가능성을 판단하는 문장이어야 합니다. 각 기준은 `pass`, `conditional`, `hold` 중 하나로만 둡니다. `pass`는 그대로 인계해도 되는 상태입니다. `conditional`은 인계는 가능하지만 릴리스 노트와 변경 트리거가 붙어야 하는 상태입니다. `hold`는 프로토타입 인계를 멈추거나 인계 범위를 줄여야 하는 상태입니다.
**design freeze criteria 최소 표**
<table>
<thead>
<tr><th>기준</th><th>동결 전에 확인할 질문</th><th>보류 신호</th></tr>
</thead>
<tbody>
<tr><td>요구사항 기준선</td><td>프로토타입 범위 요구사항과 제외 요구사항이 버전으로 고정되었는가</td><td>요구사항 문장이 아직 구두 합의에 머무름</td></tr>
<tr><td>설계 출력</td><td>도면, 모델, 코드, 부품, 알고리즘 버전이 같은 기준선 번호를 쓰는가</td><td>파일은 있으나 어느 버전이 인계본인지 모름</td></tr>
<tr><td>인터페이스</td><td>기구, 전기, 소프트웨어, 데이터 인터페이스의 변경 금지 범위가 정해졌는가</td><td>한 팀의 수정이 다른 팀 시험 조건을 바꿈</td></tr>
<tr><td>시험 기준</td><td>동결본을 검증할 시험 ID와 합격 기준이 연결되었는가</td><td>시험 결과는 있으나 동결 버전과 연결되지 않음</td></tr>
<tr><td>open issue exception</td><td>남겨도 되는 이슈와 막아야 할 이슈가 분리되었는가</td><td>중요 결함을 "나중에 처리"로만 적음</td></tr>
<tr><td>비용/일정 영향</td><td>동결 후 변경 시 재작업, 재시험, 발주 지연 영향이 보이는가</td><td>변경 비용을 감으로만 판단함</td></tr>
<tr><td>승인권자</td><td>기술, 제품, 시험, 구매 또는 제작 승인 범위가 나뉘었는가</td><td>참석자 동의를 승인으로 착각함</td></tr>
<tr><td>릴리스 노트</td><td>인계받는 사람이 제한사항과 변경 이력을 읽을 수 있는가</td><td>릴리스 노트가 기능 홍보 문구만 담음</td></tr>
</tbody>
</table>
NASA Appendix G의 기술 검토 기준은 기술 성숙도, 기술 계획의 적절성, 비용과 일정 및 위험의 신뢰성, 다음 단계 준비성을 함께 보도록 설명합니다[S2]. 이 글의 체크리스트는 그 원리를 프로토타입 인계 직전으로 좁힌 것입니다. 동결 기준을 모두 초록색으로 만드는 것이 목적이 아닙니다. 어느 항목이 조건부이고, 어느 항목이 인계를 막는지 회의 후에도 같은 표로 다시 읽히게 하는 것이 목적입니다.
open issue exception은 "미해결"이 아니라 "인계 허용 조건"입니다
프로토타입 동결 전에 모든 이슈가 닫히는 경우는 드뭅니다. 그렇다고 모든 미해결 이슈를 예외로 허용하면 freeze는 의미가 없습니다. open issue exception은 남아 있는 문제를 숨기는 칸이 아니라, 인계해도 되는 문제와 인계하면 안 되는 문제를 가르는 칸입니다. 예외가 되려면 세 가지가 필요합니다. 첫째, 사용 또는 시험 제한이 명확해야 합니다. 둘째, 해당 이슈가 어떤 요구사항과 시험에 영향을 주는지 보여야 합니다. 셋째, 동결 후 변경 요청으로 승격되는 조건이 있어야 합니다.
예를 들어 외장 색상 편차가 프로토타입 사용자 평가 범위 밖이고 기구 간섭, 안전, 성능, 고객 약속에 영향을 주지 않는다면 `exception-watch`로 남길 수 있습니다. 반대로 센서 고정 구조가 진동 시험 결과를 바꾸거나, 데이터 수집 알고리즘 변경이 기존 성능 시험을 무효로 만든다면 예외가 아니라 `freeze blocker`입니다. 단순히 "심각하지 않음"이라고 쓰지 말고 "REQ-12 외관 평가 제외, TEST-08 영향 없음, handoff note HN-04에 사용 제한 표기"처럼 쓰는 편이 안전합니다.
SEBoK의 요구사항 관리 설명은 요구사항 기준선이 비용, 일정, 기술 영향 분석의 기준이 된다고 설명합니다[S5]. 그러므로 open issue exception은 리스크 레지스터의 긴 항목이 아니라, 기준선 옆에 붙는 조건문이어야 합니다. "이 조건에서는 인계 가능하지만, 이 조건을 넘으면 변경 요청서를 열어야 한다"는 문장이 없으면 예외가 아닙니다.
change request form은 아이디어 접수표가 아니라 동결 기준선 변경 허가서입니다
동결 후 변경 요청서는 단순 개선 아이디어와 달라야 합니다. 동결 전에는 아이디어가 백로그에 들어갈 수 있습니다. 동결 후에는 같은 아이디어라도 기준선을 흔드는 순간 변경 요청서가 됩니다. NASA 구성관리 설명은 변경을 제안, 정당화, 평가, 승인, 반영, 검증하는 절차로 다룹니다[S1]. NIST SP 800-53의 구성 변경 통제도 변경 유형 문서화, 제안 변경 검토와 승인/거절, 변경 결정 기록, 승인된 변경 구현, 기록 보존, 활동 검토를 요구하는 흐름을 제시합니다[S6][S7].
**change request form 최소 필드**
- **change_id:** CR-DF-001처럼 동결 기준선과 연결되는 번호
- **origin:** 시험 실패, 고객 요청, 제작 제약, 공급 부품 변경, 내부 설계 개선 중 무엇인지
- **baseline_affected:** 요구사항, 도면, 코드, 인터페이스, 시험, 릴리스 노트 중 바뀌는 항목
- **reason:** 좋아 보이는 개선이 아니라 변경하지 않으면 생기는 손실 또는 제한
- **requirement_test_impact:** 영향받는 요구사항 ID와 재시험 ID
- **cost_schedule_impact:** 재작업 시간, 재시험 시간, 발주 지연, 폐기 비용, 인계일 영향
- **approval_authority:** 기술 승인, 제품 승인, 시험 승인, 비용 승인 중 필요한 권한
- **release_note_update:** 인계 노트에 남길 변경 설명, 제한사항, 검증 상태
좋은 변경 요청서는 "왜 바꾸고 싶은가"보다 "이 변경이 기준선의 어느 줄을 바꾸는가"를 먼저 보여줍니다. 예를 들어 "하우징 두께를 1.2mm에서 1.5mm로 변경"은 아직 부족합니다. "DPK-07 기구 도면 3번, REQ-MECH-04 낙하 내구성, TEST-MECH-02 낙하 시험, BOM-CASE-02 원가, 3D 프린팅 리드타임 2일 증가, prototype handoff date 영향 없음, 기구 리드와 PM 승인 필요" 정도가 되어야 변경 통제가 됩니다.
affected requirement/test mapping은 전체 추적성 매트릭스를 다시 만드는 일이 아닙니다
동결 후 변경이 생기면 많은 팀이 전체 traceability matrix를 다시 열려고 합니다. 그 작업은 필요할 수 있지만 이 글의 목적은 다릅니다. 여기서는 변경 한 건이 어떤 요구사항과 시험을 흔드는지 좁게 표시합니다. 전체 요구사항-시험 매트릭스는 별도 문서의 일입니다. design freeze change control에서는 `delta map`이면 충분합니다.
delta map의 기본 줄은 `변경 항목 -> 요구사항 -> 시험/검증 -> 릴리스 노트 -> 승인`입니다. 예를 들어 `CR-DF-004 -> IF-POWER-02 커넥터 핀 배열 -> REQ-INT-03 전원 인터페이스 -> TEST-INT-05 재시험 -> RN-DF-02 제한사항 갱신 -> 전기 리드 승인`처럼 씁니다. 이 줄 하나가 있으면 회의에서 "이건 작은 변경"이라는 말을 줄일 수 있습니다. 작은 변경인지 아닌지는 사람의 느낌이 아니라 요구사항과 시험 영향으로 결정됩니다.
SEBoK 구성관리 설명은 구성 변경 관리가 변경과 비준수의 분석, 정당화, 평가, 조정, 처분을 포함한다고 설명합니다[S4]. 요구사항 관리 자료도 요구사항과 시스템 산출물 사이의 추적성을 유지해야 한다고 설명합니다[S5]. 이 두 관점을 합치면 delta map은 전체 매트릭스의 축소판이 아니라, 변경 승인에 필요한 최소 영향 분석입니다. 모든 항목을 복사하지 말고, 바뀌는 항목과 다시 봐야 하는 시험만 남깁니다.
cost and schedule impact는 승인권자를 바꾸는 신호입니다
동결 후 변경이 기술적으로 맞아도 승인권자가 바뀔 수 있습니다. 코드 한 줄 변경이라도 외주 시험을 다시 열면 비용 승인자가 필요합니다. 부품 하나 변경이라도 납기와 폐기 비용이 생기면 구매 또는 PM 승인 범위가 됩니다. 인터페이스 변경이 고객 데모 시나리오를 바꾸면 제품 책임자 승인도 필요합니다. 비용과 일정 영향은 단순 참고값이 아니라 승인 경로를 결정하는 신호입니다.
비용 영향은 정확한 회계 보고서가 아니어도 됩니다. 최소한 재설계 시간, 재제작 수량, 폐기될 부품 또는 시편, 재시험 범위, 외주 또는 장비 예약 변경, 인계일 영향은 분리해야 합니다. 일정 영향도 "조금 늦어짐"이라고 쓰지 않습니다. "재프린트 1일, 조립 0.5일, 진동 재시험 1일, 릴리스 노트 갱신 0.5일, handoff date 2일 지연 또는 범위 축소 필요"처럼 씁니다.
승인권자는 참석자가 아니라 권한입니다. 기술 리드는 설계 타당성을 승인할 수 있지만 비용 초과를 승인하지 못할 수 있습니다. PM은 일정 영향과 범위를 승인할 수 있지만 시험 기준 완화를 승인하지 못할 수 있습니다. 시험 리드는 재시험 충분성을 승인할 수 있지만 고객 약속 변경을 승인하지 못합니다. design freeze 기록에는 "누가 참석했는가"보다 "누가 어떤 영향 범위를 승인했는가"가 남아야 합니다.
post-freeze defect triage는 결함을 고치는 순서보다 기준선 처리 방식을 먼저 정합니다
동결 후 결함은 모두 같은 방식으로 처리하지 않습니다. 어떤 결함은 동결을 깨야 하고, 어떤 결함은 릴리스 노트 제한사항으로 남겨도 됩니다. 어떤 결함은 다음 프로토타입 빌드로 넘겨야 하고, 어떤 결함은 인계 자체를 멈춰야 합니다. post-freeze defect triage의 첫 질문은 "어떻게 고칠까"가 아니라 "이 결함이 동결 기준선을 바꾸는가"입니다.
**동결 후 결함 분류표**
<table>
<thead>
<tr><th>분류</th><th>판단 기준</th><th>처리 방식</th></tr>
</thead>
<tbody>
<tr><td>freeze breaker</td><td>요구사항, 인터페이스, 안전, 핵심 시험 기준을 바꿈</td><td>변경 요청서, 영향 분석, 재승인, 재릴리스 필요</td></tr>
<tr><td>handoff blocker</td><td>기준선은 바꾸지 않지만 현재 인계 목적을 달성하지 못함</td><td>인계 보류 또는 범위 축소 결정 필요</td></tr>
<tr><td>release note exception</td><td>제한사항을 명확히 쓰면 인계 목적을 해치지 않음</td><td>릴리스 노트와 사용 제한에 기록</td></tr>
<tr><td>next build backlog</td><td>현재 프로토타입 인계 판단에는 영향이 작음</td><td>다음 빌드 후보로 이동, 동결본에는 미반영</td></tr>
<tr><td>not reproducible</td><td>재현 조건이 불명확해 기준선 변경 판단이 불가능함</td><td>재현 조건 수집 전 변경 금지</td></tr>
</tbody>
</table>
이 분류가 없으면 결함 회의가 우선순위 싸움이 됩니다. 개발자는 고치고 싶고, PM은 넘기고 싶고, 시험 담당자는 다시 확인하고 싶습니다. 하지만 분류가 있으면 대화가 바뀝니다. "이 결함은 REQ-THERM-02와 TEST-THERM-04에 영향을 주므로 freeze breaker입니다" 또는 "이 결함은 외관 평가 제외 범위이고 demo script에 제한사항을 남기면 release note exception입니다"처럼 판단합니다. 결함을 빨리 고치는 팀보다, 기준선을 어떻게 다루는지 먼저 정하는 팀이 인계 후 혼선을 덜 겪습니다.
release note evidence는 홍보 문구가 아니라 인계받는 사람이 다시 판단할 근거입니다
프로토타입 릴리스 노트는 "기능 A 추가, 성능 개선"으로 끝나면 부족합니다. 인계받는 사람은 무엇을 믿고 시험하거나 사용해도 되는지 알아야 합니다. 따라서 release note evidence에는 동결 기준선, 포함 범위, 제외 범위, 알려진 제한사항, 허용 예외, 변경 이력, 재시험 상태, 승인자, 다음 빌드 후보가 들어가야 합니다. NASA 구성관리 자료가 강조하는 구성 상태 회계도 현재 및 과거 구성 문서, 제안 변경 상태, 편차와 waiver, 불일치와 조치 처분 상태를 기록하는 방향입니다[S1].
릴리스 노트에는 최소 다섯 줄이 필요합니다. 첫째, `baseline`: 이 프로토타입이 어떤 동결 기준선에서 나온 것인지. 둘째, `verified_for`: 어떤 목적과 시험 범위에서 검증되었는지. 셋째, `not_verified_for`: 무엇을 아직 주장하면 안 되는지. 넷째, `known_exceptions`: 인계는 가능하지만 제한이 필요한 이슈. 다섯째, `post_freeze_changes`: 동결 후 반영된 변경과 재시험 상태입니다. 이 다섯 줄이 있으면 인계받는 팀은 "이 프로토타입을 어디까지 믿어도 되는가"를 빠르게 판단할 수 있습니다.
릴리스 노트 증거는 최종보고서 증거 패키지와 다릅니다. 최종보고서는 과제 전체 성과와 제출 증거를 정리합니다. 여기서의 릴리스 노트는 동결된 프로토타입 한 버전의 사용 조건을 설명합니다. 따라서 과장된 성과 문구를 넣지 않는 편이 좋습니다. "성능 검증 완료"보다 "TEST-PERF-03 조건에서 20회 중 19회 합격, CR-DF-002 이후 재시험 완료, 온도 45도 이상 조건은 미검증"처럼 쓰는 문장이 더 유용합니다.
30분 design freeze change control 점검 순서
첫 5분에는 동결 기준선 번호를 정합니다. 기준선 번호가 없으면 회의가 시작되지 않은 것입니다. 요구사항, 설계 출력, 인터페이스, 시험 계획, open issue log, 릴리스 노트 초안이 같은 기준선 번호를 쓰는지 확인합니다. 5~10분에는 동결 기준 8개 칸을 `pass`, `conditional`, `hold`로 분류합니다. 이때 모든 칸을 통과시키려 하지 말고, 조건부와 보류 항목을 눈에 보이게 남깁니다.
10~15분에는 open issue exception을 봅니다. 남겨도 되는 이슈인지, 인계를 막는 이슈인지, 릴리스 노트 제한사항으로 충분한지 분류합니다. 15~20분에는 동결 후 예상 변경 후보를 change request form에 대입합니다. 양식에 요구사항/시험 영향과 비용/일정 영향이 채워지지 않으면 아직 변경 요청이 아니라 아이디어입니다. 20~25분에는 승인권자를 나눕니다. 기술 승인, 제품 승인, 시험 승인, 비용 승인, 제작 승인 중 무엇이 필요한지 적습니다. 25~30분에는 release note evidence 다섯 줄을 읽습니다. 인계받는 사람이 그 노트만 보고 사용 가능 범위와 금지 범위를 구분할 수 있으면 동결 기록이 제 역할을 합니다.
이 순서는 팀을 느리게 만들기 위한 절차가 아닙니다. 설계가 동결된 뒤에도 좋은 변경은 들어와야 합니다. 다만 좋은 변경도 기준선, 요구사항, 시험, 비용, 일정, 승인, 릴리스 노트가 함께 움직여야 합니다. 그 연결이 보이면 프로토타입 인계 후 "누가 바꿨나", "왜 다시 시험해야 하나", "왜 일정이 밀렸나"라는 질문이 줄어듭니다.
이 글에서 일부러 다루지 않는 R&D 문서
전체 품질시스템 변경 절차와 부적합 처리는 [R&D 품질관리 QMS 증거 체크리스트](/guide/rnd-quality-management-qms-checklist)에서 보는 편이 맞습니다. 중간 단계 go/no-go와 예산 투입 판단은 [R&D 마일스톤 gate review 체크리스트](/guide/rnd-milestone-gate-review-checklist)가 더 직접적입니다. 요구사항과 시험 전체를 줄 단위로 연결하는 작업은 [R&D evidence traceability matrix checklist](/guide/rnd-evidence-traceability-matrix-checklist)의 범위입니다. 사용자 관찰과 사용성 근거는 [R&D user testing usability evidence checklist](/guide/rnd-user-testing-usability-evidence-checklist)로 분리하는 편이 안전합니다. 제조 반복성, BOM 안정성, 공정능력은 [R&D 제조 스케일업 체크리스트](/guide/rnd-manufacturing-scaleup-checklist)가 다룹니다.
design freeze change control의 목적은 그 모든 문서를 대체하는 것이 아닙니다. 한 프로토타입 버전을 넘기기 전에 "이 기준선은 무엇이고, 이후 변경은 어떤 허가 없이는 섞이지 않는가"를 분명히 하는 것입니다. 기준선이 선명하면 변경도 빨라집니다. 무엇을 바꾸는지, 왜 바꾸는지, 무엇을 다시 시험해야 하는지, 누가 승인해야 하는지, 릴리스 노트에 무엇을 남겨야 하는지 한 줄로 보이기 때문입니다. 그 정도의 통제만 있어도 프로토타입 인계는 회의 기억이 아니라 재검토 가능한 엔지니어링 기록이 됩니다.
R&D design freeze change control checklist 참고 출처
- [S1] [NASA Systems Engineering Handbook, 6.5 Configuration Management](https://www.nasa.gov/reference/6-5-configuration-management/)
- [S2] [NASA NPR 7123.1D, Appendix G. Life-Cycle and Technical Review Entrance and Success Criteria](https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7123_001D_&page_name=AppendixG)
- [S3] [ISO 10007:2017 Quality management - Guidelines for configuration management](https://www.iso.org/standard/70400.html)
- [S4] [SEBoK, Configuration Management](https://sebokwiki.org/wiki/Configuration_Management)
- [S5] [SEBoK, Requirements Management](https://sebokwiki.org/wiki/Requirements_Management)
- [S6] [NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)
- [S7] [CSF Tools, NIST SP 800-53 Rev. 5.2.0 CM-3 Configuration Change Control](https://csf.tools/reference/nist-sp-800-53/r5/cm/cm-3/)
- [S8] [SEBoK, Configuration Baselines](https://sebokwiki.org/wiki/Configuration_Baselines)