08. 요구사항 관리 — TBD를 언제 무엇으로 닫나

출처: SR §7(가정사항 및 프로젝트 제약), §8(TBD 및 Open Issue), §9(요구사항 작성 및 관리 원칙) 이 편은 개별 기능이 아니라 SR이라는 문서 자체를 다룬다. 앞의 7편이 "무엇을 요구하는가"였다면, 여기는 "이 문서를 어떻게 관리하고 미정 항목을 어떻게 닫는가"다. 구현 순서와 시험 계획은 11편으로 이어진다.

---

1. SR이란 무엇인가 — 문서의 위치

이 문서의 정식 명칭은 Stakeholder Requirements Specification (SR), 이해관계자 요구사항 명세서다. §1 문서 정보에 그렇게 적혀 있다.

시스템 개발 문서 체계에서 SR의 위치:

§2가 이 경계를 명확히 한다.

"함수, GPIO 핀, 네트워크 프레임의 상세 Byte/Bit 배치, 회로도, 내부 소프트웨어 구조, 오디오 구현 상세 및 시험 절차는 별도의 소프트웨어 설계서, 네트워크 인터페이스 명세서, 하드웨어 설계서 및 시험 명세서에서 정의한다."

SR에 없는 것을 나열함으로써 SR이 무엇인지를 정의했다. 좋은 문서 구조다.

1-1. "사용자 관점에서 관찰 가능한"

§9의 마지막 원칙이 이 문서 전체의 작성 기준이다.

"사용자 관점에서 관찰 가능한 기능과 안전 의도는 SR에서 정의하고, Controller 간 내부 명령 전달, 상태 교환, 세부 중재 및 실행 메커니즘은 SysRS 또는 설계 문서에서 정의한다."

"관찰 가능(observable)"이 판정 기준이다.

그런데 예외처럼 보이는 문장이 하나 있다.

§6.2.5 "시스템은 윈도우 제어 관련 통신 오류가 발생하더라도 로컬 윈도우 제어기에서 수행하는 Anti-pinch 보호 기능을 유지해야 한다."

"로컬 윈도우 제어기"는 내부 구조를 언급한다. 왜 예외가 허용됐나?

이건 아키텍처 제약이 안전 요구사항이기 때문이다. "통신이 끊겨도 Anti-pinch가 동작한다"는 관찰 가능한 결과인데, 그 결과를 보장하는 유일한 방법이 "로컬에서 수행"이므로, 구조가 곧 요구사항이 된다. 이런 걸 **아키텍처 제약 요구사항(architectural constraint)**이라 부르고, SR에 들어가는 것이 정당하다.

---

2. §9 — 요구사항 작성 원칙 8개

§9는 여덟 문장으로 되어 있다. 하나씩 뜯어본다.

2-1. "하나의 요구사항에는 하나의 주요 동작 또는 검증 가능한 목적만 작성한다"

검증 단위 = 요구사항 단위라는 선언이다.

한 문장에 두 결과가 들어가면 시험 판정이 애매해진다.

✗ "시스템은 끼임 위험을 감지한 경우 닫힘을 정지하고 보호 위치까지 열어야 한다."
   → 정지는 됐는데 보호 동작이 안 되면? "부분 통과"라는 판정은 없다.

✓ "시스템은 끼임 위험을 감지한 경우 진행 중인 윈도우 닫힘 동작을 즉시 정지해야 한다."
✓ "시스템은 끼임 위험으로 닫힘 동작을 정지한 경우 정의된 보호 위치까지 열림 방향의 보호 동작을 수행해야 한다."
   → 두 개의 독립된 시험 항목. 결함 위치가 정확히 특정된다.

2-2. "둘 이상의 독립 검증 가능한 요소는 별도 요구사항으로 분리한다"

앞 원칙의 실행 지침이다. 이 문서에서 분리가 가장 두드러진 곳은 우선순위 사슬이다.

§6.2.1은 우선순위를 이렇게 쓴다.

전용 스위치 > HMI, 원격, 자동환기
HMI > 원격, 자동환기
원격 > 자동환기

한 문장 "전용 스위치 > HMI > 원격 > 자동환기"로 쓸 수 있는데 세 문장으로 나눴다. 그래야 "스위치 vs 원격"을 검증하는 근거 요구사항이 명확히 존재한다.

§6.4.3의 Ambient Lighting 우선순위도 같은 방식이다 — Emergency, Fault, Warning, Access, Goodbye가 각각 "자기보다 낮은 모든 것"을 열거한다. 중복이 아니라 검증 가능성을 위한 의도적 반복이다.

2-3. "책임 주체와 수행 동작이 명확한 '해야 한다' 형식으로 작성한다"

주어의 세 가지 형태(00편 §6 참고):

세 번째 형식이 미묘하다. "사용자는 목표 온도를 설정할 수 있어야 한다"는 시스템 동작이 아니라 사용자 능력이다. 이걸 "시스템은 목표 온도 설정 기능을 제공해야 한다"로 바꿔 쓸 수도 있는데, 굳이 사용자를 주어로 둔 이유는 누구의 관점에서 쓴 문서인지를 명확히 하기 위해서다. SR은 이해관계자(사용자) 요구사항 명세다.

2-4. "기능별 사용자 요구사항에는 별도의 요구사항 ID를 부여하지 않고 기능 및 하위 기능 제목으로 구분하여 관리한다"

이 문서에는 요구사항 ID가 없다. REQ-001 같은 번호가 안 붙어 있고, "§6.2.4 Anti-pinch 안전 보호"라는 제목 아래 여섯 문장이 나열될 뿐이다.

이게 좋은 선택인가? 장단이 명확하다.

프로토타입 단계에서는 합리적이다. 하지만 §9의 마지막 원칙 — "요구사항 변경 시 관련 기능 요구사항, 기능별 상태, HMI 표시 및 시험 항목의 영향을 함께 검토한다" — 을 실제로 수행하려면 결국 추적성이 필요하다.

실무 절충안: SR에는 ID를 안 붙이되, 시험 명세서에서 "§6.2.4-3" 같은 절-순번 참조를 쓴다. 위치가 바뀌면 참조가 깨지지만, 절 단위로는 안정적이다.

2-5. "미확정 통신 방식, 센서 임계값, 법규 적용 범위 및 성능 수치는 TBD로 관리한다"

§8 전체가 이 원칙의 실행이다. 3절에서 다룬다.

2-6. "부품 모델, 센서 구현 방식, 회로 구성, 구동 전압·전류, 핀맵 및 배선과 같은 하드웨어 상세 설계 항목은 SR에서 고정하지 않고 하드웨어 설계서에서 정의한다"

§7.2가 같은 말을 한 번 더 한다. 왜 두 번 쓰나?

§7.2는 "이번 프로젝트에서는 이렇게 한다"는 프로젝트 제약이고, §9는 "SR이라는 문서는 원래 이런 것"이라는 작성 원칙이다. 성격이 다르다.

2-7. "사용자 관점 관찰 가능 vs 내부 메커니즘"

2-1절에서 다뤘다.

2-8. "요구사항 변경 시 관련 기능 요구사항, 기능별 상태, HMI 표시 및 시험 항목의 영향을 함께 검토한다"

**변경 영향 분석(change impact analysis)**이다. 네 가지를 함께 보라고 한다.

실제 예로 확인해 보자. TBD-034(엔진룸 동물 진입의 Ambient 우선순위 등급)를 "Emergency"로 확정한다고 하자.

한 TBD를 닫는 것이 네 영역에 파급된다. 이걸 안 하면 SR과 시험 명세서가 어긋난다.

---

3. §8 — TBD 관리

3-1. 전체 목록

§8의 표를 그대로 옮기고, 이 노트 시리즈에서 어느 편이 다루는지 표시했다.

총 32건이다. 번호는 038까지 가지만 023~026, 028, 035, 037이 비어 있다. 번호의 빈칸은 통합·삭제된 항목의 흔적이고, 이걸 그대로 두는 게 옳다 — 번호를 재사용하면 과거 회의록·이슈 트래커의 참조가 깨진다.

3-2. TBD를 성격별로 분류하면

"정책·우선순위" 4건이 특별하다. 이건 시험을 아무리 해도 답이 안 나온다. 사람이 결정해야 한다.

• TBD-010: 자동 환기 닫힘 정책 — 법규와 데모 안전 조건의 균형
• TBD-019: Ambient 표시 패턴 — 디자인·UX 결정
• TBD-034: 동물 진입의 등급 — 위험을 어떻게 볼 것인가
• TBD-036: CV 트리거 — 배터리와 안전의 교환비

기술 TBD와 정책 TBD를 섞어 관리하면 정책 TBD가 영원히 안 닫힌다. "시험하면 나오겠지" 하고 미루기 때문이다. 실무에서는 정책 항목을 별도 회의 안건으로 올려야 한다.

3-3. TBD 의존 그래프 — 문서에 안 적힌 것

§8의 표는 각 TBD를 독립적으로 보여주지만, 실제로는 얽혀 있다. 앞선 편들에서 발견한 의존을 모으면:

이 그래프에서 읽어야 할 것:

1. TBD-022가 가장 많은 것에 의존한다 — heartbeat 주기와 재전송 주기가 정해져야 max age를 정할 수 있다. 그리고 TBD-022가 정해져야 §6.2.2, §6.3.4, §6.4.4, §6.5.3의 "신뢰할 수 없는 경우"가 실제로 판정 가능해진다. 이 문서에서 가장 널리 퍼진 미정 항목이다.

2. TBD-008 → TBD-009는 물리적 의존이다. 위치를 어떻게 아느냐가 정해져야 끼임을 어떻게 감지할지 정할 수 있다(02편 §4-2 참고). 순서를 뒤집으면 재작업이 생긴다.

3. TBD-002가 TBD-001을 제약한다 — 하드웨어 제약이므로 되돌릴 수 없다. 07편 §6-1에서 다뤘다.

§8의 표에는 이 의존이 안 적혀 있다. "참조 절"은 있지만 "선행 TBD"는 없다. 실무에서는 이 그래프를 별도로 만들어 결정 순서를 잡아야 한다.

3-4. TBD를 문서에 남기는 것의 가치

✗ 임의 값으로 채우기:
   "Anti-pinch 임계값은 2.5 A로 한다"  (근거 없이 정함)
   → 시험 통과 → 기록 남음
   → 나중에 실제 값이 1.8 A로 밝혀짐
   → 어떤 시험을 다시 해야 하는지 추적 불가

✓ TBD로 남기기:
   TBD-009 → 시험 명세서가 "TBD-009 확정 후 수행"으로 표시됨
   → 값 확정 시 §9의 변경 영향 분석 절차가 작동
   → 재검증 범위가 명확

TBD는 "모른다"의 고백이 아니라 "언제 어떻게 알게 될지"의 계획이다. §8의 "초기 제안" 열이 그 계획이다 — "벤치 시험 후", "통합 시험 후", "하드웨어 설계 단계에서".

---

4. §7 — 가정사항과 제약을 읽는 법

4-1. 가정사항(§7.1)과 제약사항(§7.2)의 차이

§7.1의 항목들을 보면 전부 검증 환경에 대한 가정이다.

• 본 시스템은 실제 양산 차량이 아닌 실내 저전압 프로토타입 환경에서 검증한다.
• Central Controller 와 VSS 기능은 하나의 S32K344-WB 보드에서 함께 수행하며 두 기능 사이에 별도 차량 네트워크 통신을 사용하지 않는다.
• Sensing/Vision Subsystem 은 S32K144 Sensing Controller 와 Raspberry Pi 3 B Vision Module 을 기준 구성으로 하며, Vision Module 은 실내 카메라와 엔진룸 카메라를 사용한다.
• 원격 사용자 기능과 BLE Digital Key 는 프로토타입의 로컬 네트워크/BLE 환경에서 검증한다.
• 파워윈도우의 법규 적용 범위와 안전 수치는 적용 국가/차종 및 프로젝트 시험 조건을 확정한 후 최종 검증 기준으로 사용한다.
• 엔진룸 CV 는 저전압 프로토타입 환경에서 별도 소형 카메라 모듈로 구현하며, 실제 엔진룸 환경(고온·진동·방수)은 검증 범위에서 제외한다.

"이 가정이 깨지면 무엇이 무효가 되는가"를 각각 생각해 봐야 한다.

4-2. §7.2 제약사항이 실질적으로 요구사항인 경우

§7.2의 대부분은 구성 확정이지만, 두 항목은 사실상 안전 요구사항이다.

"Function Controller 는 Door Lock Actuator, 공조 출력 장치 및 Ambient Lighting 을 직접 제어한다. Window Motor 는 Power Window Controller 만 직접 제어한다."

"만"이 붙어 있다. 이건 구성이 아니라 금지 규정이다. 02편에서 봤듯, 모터 구동 권한을 한 노드로 못 박아야 Anti-pinch가 우회당할 경로가 없어진다.

"Power Window 는 단일 윈도우의 열림·닫힘·정지, 위치 확인 및 Anti-pinch 보호 기능을 검증할 수 있는 저전압 모사 장치로 구성한다."

이건 범위 한정이다. 4-도어 동기 제어, 도어별 우선순위, 운전석 마스터 스위치 같은 실차 기능은 요구사항에 없다.

4-3. "제외한다"의 정확한 의미

§7.2 "실차 수준의 기계 하중, 고전압·고전류 부하, 양산 인증 및 완전한 AUTOSAR 양산 적용은 1차 프로젝트 범위에서 제외한다."

**"1차 프로젝트 범위에서"**라는 한정이 붙어 있다. 영원히 안 한다는 게 아니라, 이번엔 안 한다는 뜻이다.

AUTOSAR를 제외한 것의 실질적 의미:

프로토타입에서는 직접 구현이 옳은 선택이다. AUTOSAR 툴체인 학습에 프로젝트 기간을 다 쓸 수 없다. 다만 나중에 양산으로 갈 때 아키텍처를 크게 바꿔야 한다는 걸 알고 있어야 한다.

---

5. 이 SR을 리뷰한다면 — 발견한 이슈들

앞의 7편을 쓰면서 발견한, 설계 문의(clarification request)로 올릴 만한 항목들을 모았다. SR 리뷰의 실제 산출물이 이런 목록이다.

5-1. 용어 정의와 본문의 불일치

5-2. 같은 절 안의 상태 모델 충돌

5-3. 용어의 이중 의미

5-4. 미정의 조건 하의 동작

5-5. 우선순위 충돌 가능성

5-6. TBD 간 의존이 표에 없음

3-3절의 그래프. 특히 TBD-002 → TBD-001(하드웨어 제약), TBD-020·021 → TBD-022(수치 의존), TBD-008 → TBD-009(방식 의존)는 결정 순서를 잘못 잡으면 재작업이 발생한다.

---

6. 좋은 요구사항 문장의 체크리스트

이 SR에서 반복적으로 나타나는 좋은 패턴을 일반화하면:

6-1. 특히 잘 쓰인 것 — 생성/해제 쌍

이 문서는 상태를 만드는 요구사항 옆에 반드시 지우는 요구사항을 둔다.

§6.3.3  후진 기어 AND 기준 거리 이내  → 근접 위험 상태 생성
        기준 거리 이탈 OR 후진 기어 이탈 → 근접 위험 상태 해제

§6.3.5  대상 동물 진입 유효 확인 → 진입 상태 생성
        미감지가 정의된 시간 이상 유지 → 진입 상태 해제

§6.1.1  위험 상태 감지 → 경고음 출력
        위험 해제 또는 최대 경고 시간 초과 → 경고음 중단

"상태를 만드는 코드는 누구나 쓰고, 지우는 코드를 빼먹는다." 요구사항 레벨에서 쌍을 강제하면 이 버그가 구조적으로 예방된다.

6-2. 특히 잘 쓰인 것 — 비대칭 설계

여러 곳에서 진입은 민감하게, 해제/복구는 보수적으로가 일관되게 나타난다.

위험 쪽으로 기울인 설계(fail-safe bias)가 문서 전체에서 일관된다. 이건 우연이 아니라 작성자가 안전 원칙을 이해하고 썼다는 증거다.

---

7. 한 줄 요약

---

설계 판단 체크포인트

구현에 들어가기 전에 팀이 답을 갖고 있어야 하는 것들이다. 답이 안 나오면 그 자리가 곧 설계 문의 또는 TBD 후보다.

1. 요구사항 ID를 부여하지 않은 선택의 대가는 무엇이고, 어떻게 보완할 수 있나? 추적성이 약해진다. §9의 마지막 원칙(변경 영향 분석)을 수행하려면 "이 요구사항에 연결된 시험 항목이 무엇인가"를 알아야 하는데, ID가 없으면 절 제목과 순번으로 참조해야 하고 문장 순서가 바뀌면 깨진다. 보완책은 시험 명세서에서 "§6.2.4-3" 같은 절-순번 참조를 쓰되, 절 단위 안정성에 의존하는 것이다. 규모가 커지면 결국 ID를 도입해야 한다.

2. "시스템은 …해야 한다"와 "사용자는 …할 수 있어야 한다"를 구분해 쓰는 이유는? 전자는 시스템 동작(system behavior), 후자는 사용자에게 보장되는 능력(user capability)이다. 후자는 시스템이 어떤 수단으로 그 능력을 제공하든 상관없다는 뜻이므로, 구현 자유도가 더 크다. 그리고 SR이 이해관계자 관점 문서임을 문법으로 드러낸다.

3. §6.2.5의 "로컬 윈도우 제어기에서 수행하는"은 내부 구조 언급인데 왜 SR에 허용되나? "통신이 끊겨도 Anti-pinch가 유지된다"는 관찰 가능한 안전 요구인데, 이를 보장하는 유일한 방법이 로컬 실행이다. 구조가 곧 요구사항인 경우를 아키텍처 제약 요구사항이라 하고, SR에 포함하는 것이 정당하다. 다만 이런 예외는 안전상 필요할 때만 써야 하고, 남용하면 SR이 설계서가 된다.

4. TBD-022(데이터 max age)를 가장 먼저 확정하려 하면 무슨 문제가 생기나? TBD-020(heartbeat 주기)과 TBD-021(상태 재전송 주기)이 정해지지 않으면 max age를 정할 근거가 없다. max age는 재전송 주기의 배수로 잡아야 하는데, 주기를 모르면 임의 값이 된다. 결정 순서를 지켜야 한다 — 이게 3-3절 의존 그래프의 실용적 가치다.

5. 정책 성격의 TBD(010, 019, 034, 036)를 기술 TBD와 같은 방식으로 관리하면 왜 안 닫히나? 기술 TBD는 "시험하면 답이 나온다"는 경로가 있지만, 정책 TBD는 시험 결과가 답을 주지 않는다. 예컨대 TBD-034(동물 진입이 Warning인가 Emergency인가)는 데이터로 결정되지 않고 "우리 팀이 이 위험을 어떻게 볼 것인가"의 문제다. 시험 대기 목록에 넣어 두면 영원히 대기한다. 별도 의사결정 안건으로 올려야 한다.

6. §6.1.2와 §6.1.3의 "중단 vs 복구" 충돌을 발견했다. 리뷰어로서 무엇을 제안하겠나? 두 문장이 다른 상태 모델을 가정하므로 하나로 통일해야 한다. §6.1.2가 "즉시 중단"이라고 명시했으므로, §6.1.3의 "복구"를 음량 복구로 한정하는 게 정합적이다. 구체적으로는 §6.1.2를 "일반 음향 출력을 즉시 중단하거나 식별 불가 수준으로 감쇄해야 한다"로 완화하거나, §6.1.3을 "안티핀치 위험 중 감쇄된 일반 음향의 음량을 서서히 정상 수준으로 복구해야 한다"로 명확히 하는 두 방향이 있다. 어느 쪽이든 SR 작성자가 의도를 확인해 줘야 하고, 리뷰어가 임의로 정할 일이 아니다.