11. 구현 순서와 검증 — 무엇부터, 무엇으로 확인하나

⚠️ SR에 없는 내용이다. §2가 "시험 절차는 별도의 시험 명세서에서 정의한다"고 미뤄 둔 부분과, 프로젝트 진행 계획을 요구사항에서 역산한 초안이다. 09편(구조)·10편(인터페이스)이 "무엇을 만드나"였다면, 이 편은 **"어떤 순서로 만들고 무엇으로 통과를 판정하나"**다.

---

0. 이 프로젝트가 서 있는 틀 — V모델

개발 프로세스로 **V모델**을 쓴다. 자동차 임베디드에서 사실상 표준이고, ISO 26262 도 이 구조를 전제한다.

점선이 V모델의 전부다

왼팔을 내려가며 요구사항을 쪼개고, 오른팔을 올라가며 합쳐서 검증한다. 각 층이 자기 짝이 되는 시험 단계를 갖는다는 게 핵심이다.

시험 명세는 구현 전에 쓴다

이게 V모델을 쓰는 실질적 이유다. SR 을 쓸 때 인수 시험 항목을 같이 정하고, 설계를 할 때 단위 시험을 같이 정한다. 구현을 다 하고 나서 "이제 뭘 시험하지"를 고민하지 않는다.

그래서 §9 가 요구사항을 검증 가능성 기준으로 쪼개라고 하는 것이다 — 요구사항 하나가 시험 항목 하나가 되도록 쓰여 있어야 이 대응이 성립한다.

✗  "끼임을 감지하면 정지하고 보호 위치까지 열어야 한다"
     → 정지는 됐는데 보호 동작이 안 되면 이 시험은 통과인가 실패인가

✓  두 문장으로 분리
     → 시험 항목 둘. 결함 위치가 정확히 특정된다

이 프로젝트가 V 의 어디에 있나

SR       ✅  이 문서 (v1.0). 왼팔 맨 위는 확보됐다
SysRS    🔶  12편이 초안. 노드 할당·중재 규칙까지는 잡았으나 팀 합의 전이고,
             정책 TBD 4건은 여기서 못 닫는다
설계     🔶  09편(구조) · 10편(인터페이스)이 초안. 팀 합의 전이라 확정 아님
구현     ⬜  M2 부터
시험     🔶  §3 의 추적 매트릭스가 뼈대. 시험 명세서로 옮겨야 한다

비어 있는 SysRS 가 이 프로젝트의 가장 큰 공백이다. 09·10편이 그 자리를 임시로 채우고 있지만, 정식 문서가 아니라 요구사항에서 역산한 초안이다. 그리고 TBD 32건 중 상당수가 사실 SysRS 에서 결정될 항목이다 — 통신 방식, 노드 간 프로토콜, 중재 규칙.

흔한 오해 — V모델 = 폭포수?

아니다. 왼팔을 다 끝내고 오른팔로 넘어가야 하는 게 아니다. 기능 단위로 V 를 여러 번 돌 수 있고(반복 V), 실제로 이 프로젝트도 그렇게 간다 — M1 벤치 실험에서 얻은 수치가 SR 의 TBD 를 닫으면서 왼팔로 되돌아간다.

V모델이 강제하는 건 순서가 아니라 대응 관계다. "이 요구사항은 어느 시험으로 확인하나"에 항상 답이 있어야 한다는 것.

그래서 §9 의 마지막 원칙이 중요해진다

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

왼팔이 바뀌면 오른팔도 바뀐다. 변경 영향 분석이 V모델에서 필수인 이유이고, §6 의 tbd_status.md 에 "재시험 필요" 열을 둔 것이 그 실행이다.

---

1. 순서를 정하는 원칙

1-1. 세 가지 제약이 순서를 결정한다

③이 가장 자주 무시된다. 쉬운 것부터 하면 진도가 빨리 나가는 것처럼 보이지만, 어려운 것을 나중에 만나면 그때 설계를 뒤집어야 한다. 이 프로젝트에서 미지수가 가장 큰 것은:

전부 "만들어 봐야 아는 것"이다. 그래서 벤치 실험이 기능 구현보다 먼저 온다.

1-2. TBD 차단 그래프 — 무엇을 먼저 닫아야 하나

08편 §3-3에서 만든 의존 그래프를 결정 순서로 다시 그리면:

0주차 4건은 회의 한 번으로 닫힌다. 그런데 이게 안 닫히면 아무도 통신 코드를 못 짠다. 가장 값싸고 가장 파급이 큰 결정이므로 제일 먼저 해야 한다.

정책 TBD 4건(WP)을 별도 트랙으로 뺀 게 중요하다. 08편 §3-2에서 지적했듯, 이건 시험 대기 목록에 넣으면 영원히 안 닫힌다.

---

2. 마일스톤

M0 — 계약 확정 (0주차)

코드를 짜기 전에 이걸 끝내야 한다. common/을 먼저 만드는 이유는, 각 노드 담당자가 자기 방식으로 유효성 판정을 짜기 시작하면 나중에 통일이 불가능하기 때문이다.

M0 통과 기준: 6개 노드 담당자가 같은 signals.h를 include 해서 빈 프로젝트가 빌드된다.

M1 — 벤치 실험 (1~2주차)

기능 구현이 아니라 미지수를 숫자로 바꾸는 단계다.

TBD-009 실험이 이 단계의 핵심이다. 02편 §4-2에서 봤듯 전류 절대값만으로는 안 되고 학습 기준선이 필요한데, 기준선을 만들려면 먼저 정상 프로파일을 측정해야 한다. 이게 없으면 Anti-pinch를 아예 못 짠다.

실험 절차 (TBD-009)
1. 정상 닫힘 20회 — 위치 구간별 전류·속도 로깅 → 기준선 프로파일
2. 온도 조건 변경(냉장고/히터) 후 반복 → 기준선의 온도 의존성
3. 인위적 끼임 (스펀지·목재·손가락 모형) × 위치 5구간 × 10회
4. 정상 스톨(완전 닫힘) 20회 → 끼임과 구분되는 특징 확인
5. 기준선 대비 초과 전류 · 속도 저하율의 분포 → 임계값 후보
6. 감지 → 브레이크 완료까지의 실측 지연 → 반응 시간

M1 통과 기준: 위 5개 TBD의 값이 근거 데이터와 함께 문서에 기록된다. "대충 이 정도"가 아니라 측정 그래프가 있어야 한다.

M2 — 노드별 단독 동작 (3~5주차)

각 노드가 통신 없이 자기 기능을 한다. 이 단계에서 통합을 시도하면 디버깅이 지옥이 된다.

Power Window의 "통신선 뽑고 시험"이 특히 중요하다. §6.2.5의 "통신 오류가 발생하더라도 로컬 Anti-pinch 보호 기능을 유지"를 M2 단계에서 이미 검증하게 된다. 나중에 통합한 뒤 확인하려 하면 로컬 폐루프가 이미 깨져 있을 수 있다.

M2 통과 기준: 각 노드가 CAN 케이블 없이 자기 기능을 수행한다. 09편 §6-2의 safety.c include 검사도 여기서 한다.

M3 — 2노드 통합 (6~7주차)

한 번에 다 붙이지 않는다. 쌍으로 붙인다.

① Central ↔ Sensing      : 센서 값이 올라오고 age 판정이 동작
② Central ↔ Power Window : 명령이 내려가고 Anti-pinch 이벤트가 올라옴 → 경고음
③ Central ↔ Function     : 도어락·Fan·Ambient 제어
④ Central ↔ ESP32        : 상태 표시 + 요청 생성
⑤ Sensing ↔ RPi          : 비전 결과 중계

②를 먼저 하는 이유: 01편 §5의 전체 시퀀스(끼임 → CAN → 경고음)가 이 시스템에서 가장 타이밍이 빡빡한 경로다. 여기서 지연이 크게 나오면 설계를 고쳐야 하는데, 늦게 발견할수록 비싸다.

M3 통과 기준: 각 쌍에서 heartbeat·E2E·age가 정상 동작하고, 한쪽 노드를 껐을 때 다른 쪽이 §6.5.3대로 stale/오류를 표시한다.

M4 — 전체 통합 (8~9주차)

M4 통과 기준: TBD-020/021/022/038/017이 실측값으로 확정된다.

M5 — 요구사항 검증 (10주차~)

§6 전 요구사항을 시험 항목으로 돌린다. 3절의 매트릭스가 그 목록이다.

---

3. 요구사항 → 모듈 → 시험 항목 추적

08편 §2-4에서 본 문제 — SR에 요구사항 ID가 없어 추적성이 약하다 — 를 보완하는 표다. 절-순번 참조를 쓴다.

3-1. 표기 규칙

§6.2.4-2  =  §6.2.4 절의 2번째 요구사항 문장

문장 순서가 바뀌면 참조가 깨지므로, SR 개정 시 이 표를 함께 갱신해야 한다(§9 변경 영향 분석).

3-2. 안전 요구사항 — 반드시 검증해야 하는 것들

§6.2.5-1의 "CAN 케이블 분리 후 끼임"이 가장 중요한 단일 시험이다. 이 하나가 통과하면 로컬 폐루프 설계가 실제로 성립함이 증명된다. M2 단계에서 이미 하고, M4에서 다시 한다.

3-3. 유효성·오류 처리

오류 주입(fault injection)이 이 그룹 시험의 전부다. 정상 동작만 시험하면 SR의 절반을 검증 안 한 것이다 — 00편 §4에서 봤듯 이 문서는 "~하지 않아야 한다"가 대단히 많다.

/* 시험용 오류 주입 훅 — 개발 빌드에서만 컴파일 */
#ifdef VCS_FAULT_INJECTION
typedef enum {
    FI_NONE, FI_SENSOR_STUCK, FI_SENSOR_RANGE, FI_TASK_HANG,
    FI_CAN_SILENT, FI_CAN_CORRUPT, FI_ACTUATOR_NORESP,
} fi_mode_t;

extern fi_mode_t g_fi[FUNC_COUNT];
#define FI_ACTIVE(f, m)  (g_fi[(f)] == (m))
#else
#define FI_ACTIVE(f, m)  (0)
#endif

#ifdef로 감싸 양산 빌드에서 아예 링크되지 않게 한다. 03편 §4-3의 개인정보 코드와 같은 방식이다.

3-4. 우선순위·중재

이 그룹은 "동시 발생"을 만들어야 하므로 시험 지그가 필요하다. 손으로 타이밍을 맞출 수 없다. CAN으로 이벤트를 주입하는 스크립트를 만드는 게 현실적이다.

# tools/inject.py — 우선순위 시험용 이벤트 주입
import can, time
bus = can.interface.Bus(channel="can0", bustype="socketcan")

def send(arb_id, data): bus.send(can.Message(arbitration_id=arb_id, data=data))

# §6.1.2 시나리오: 미디어 → 피드백 → 장애물 → 안티핀치
send(0x130, [0x01])          # 미디어 재생 시작
time.sleep(1.0)
send(0x140, [0x01])          # 조작 피드백음
time.sleep(0.5)
send(0x210, prox_frame(400)) # 장애물 40 cm — 주의 거리
time.sleep(0.5)
send(0x010, [0x01])          # pinch_event  ← 최우선, 즉시 선점되어야

3-5. 요청 생애주기·표시

마지막 항목이 만들기 까다롭다. 자동 환기가 열려 있는 상태에서 Anti-pinch를 사용 불가로 만들어야 한다. 오류 주입 훅(FI_SENSOR_STUCK을 전류 센서에)으로 유도하는 게 현실적이다.

---

4. 시험 환경

4-1. 필요한 지그

4-2. 로깅

시험 결과를 재현 가능하게 남기려면 로깅이 시험 지그의 일부다.

/* svc/log.h — 순환 버퍼 + CAN 또는 UART 덤프 */
typedef struct __attribute__((packed)) {
    uint32_t t_ms;
    uint8_t  src;        /* 모듈 ID */
    uint8_t  evt;        /* 이벤트 코드 */
    int16_t  a, b;       /* 값 2개 */
} log_rec_t;             /* 10 byte */

#define LOG(src, evt, a, b)  log_push((src), (evt), (a), (b))

Anti-pinch 시험에서는 1 ms 주기 전류·속도·위치를 전부 남겨야 한다. 그래야 임계값을 사후에 다시 계산할 수 있다. 판정 결과만 남기면 임계값을 바꿀 때마다 시험을 다시 해야 한다.

---

5. 통합 시 자주 나오는 문제

미리 알고 있으면 디버깅 시간이 크게 준다.

아래 3개는 코드 리뷰에서 잡아야 하는 구조적 위반이고, 나머지는 통합 시험에서 드러난다.

---

6. 진행 상황 추적 — docs/tbd_status.md

TBD 32건을 이런 형태로 관리하면 §9의 변경 영향 분석이 실제로 돌아간다.

| ID | 상태 | 확정값 | 확정일 | 근거 | 영향받는 절 | 재시험 필요 |
|----|------|--------|--------|------|-------------|-------------|
| TBD-002 | 확정 | Classic CAN 500 kbps | 2026-09-05 | 부하 2.8 % 계산 | §전체 통신 | — |
| TBD-001 | 확정 | CAN (TBD-002 Classic 확정에 따름) | 2026-09-05 | 프로토콜 통일 | §6.5 | — |
| TBD-009 | 진행 | — | — | 벤치 실험 M1 | §6.2.2, §6.2.4 | §6.2 전체 |
| TBD-034 | 대기 | — | — | 정책 회의 필요 | §6.3.5, §6.4.3 | Ambient 우선순위 |

"재시험 필요" 열이 §9 마지막 원칙의 실행이다. 값이 바뀌면 어떤 시험을 다시 해야 하는지가 표에 적혀 있어야, 나중에 "이거 다시 봐야 하나?"로 시간을 쓰지 않는다.

---

7. 한 줄 요약

---

설계 판단 체크포인트

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

1. M1(벤치 실험)에 2주를 쓰는 게 아깝지 않은가? TBD-009 없이 Anti-pinch를 짜면 임계값을 상수로 박고 나중에 전부 다시 튜닝해야 한다. 그리고 감지 방식(전류만 / 전류+속도 / 로드셀)에 따라 safety.c 구조와 필요한 센서가 바뀐다 — 구현을 먼저 하면 그 구조를 버리게 된다. 실험은 재작업 보험이다.

2. M2에서 노드별 단독 동작을 강제하면 통합이 늦어지지 않나? 늦어 보이지만 총 시간은 준다. 6개 노드를 한꺼번에 붙이면 문제가 났을 때 원인 후보가 6개다. 단독 동작이 검증된 노드끼리 붙이면 원인이 "둘 사이"로 좁혀진다. 그리고 Power Window의 단독 동작 시험은 그 자체가 §6.2.5 검증이라 버리는 시간이 아니다.

3. 오류 주입 훅을 넣으면 양산 코드가 더러워지지 않나? #ifdef VCS_FAULT_INJECTION으로 감싸면 양산 빌드에는 한 줄도 안 들어간다. 대안은 물리적으로 센서를 뽑는 것인데, "송신 태스크만 hang" 같은 고장은 물리적으로 만들 수 없다. §6.6·§6.4.4의 격리 요구사항을 검증하려면 주입이 필요하다.

4. 정책 TBD 4건(010·019·034·036)의 결정 주체는 누구인가? 이게 정해져 있지 않으면 회의를 열어도 결론이 안 난다. 특히 TBD-010(닫힘 정책)은 안전과 법규가 걸려 있어 한 사람이 책임지고 결정 기록을 남겨야 한다. 08편 §3-2에서 지적한 "기술 TBD와 섞으면 안 닫힌다"의 실질적 해법은 결정 주체와 기한을 붙이는 것이다.

5. 시험 항목을 SR 문장 단위로 만들면 항목 수가 200개를 넘는다. 전부 해야 하나? §9의 "하나의 요구사항 = 하나의 검증 가능한 동작"을 따르면 원칙적으로 그렇다. 현실적으로는 3-2절의 안전 요구사항 13개를 필수로 두고, 나머지는 시나리오 시험으로 묶어 커버리지를 확보하는 게 합리적이다. 다만 어느 요구사항이 어느 시나리오로 커버되는지는 표에 남겨야 한다 — 안 그러면 빠진 게 있어도 모른다.

6. log_rec_t를 10바이트로 잡았는데 1 ms 로깅이면 초당 10 KB다. 어디에 남기나? S32K144 내부 RAM(수십 KB)으로는 수 초밖에 못 담는다. Anti-pinch 시험은 한 번이 수 초이므로 RAM 순환 버퍼 + 시험 종료 후 UART 덤프로 충분하다. 장시간 로깅이 필요하면 외부 플래시나 CAN 실시간 스트림이 필요한데, 후자는 버스 부하를 크게 올리므로 시험 전용 모드로만 켜야 한다.