개념
범위를 먼저 줄인다
이 레슨의 원래 주제는 "전장관리·무기체계의 실시간·안전 시험 환경" 이었다. 그 범위를 의도적으로 줄였다. 특정 무기체계의 시험 절차, 시험장 운용 방식, 체계별 안전 통제 절차는 사업·기관마다 다르고 공개 확인이 어렵다. 공개되지 않은 절차를 추정해 적는 것은 이 모듈의 원칙에 어긋난다.
그래서 이 레슨은 어느 실시간·안전 소프트웨어에나 공통으로 성립하는 부분 만 다룬다 — 시험 환경이 증거의 전제가 되는 구조 다. 이 부분은 규격이 공개된 항공 쪽과 일반 임베디드 검증에서 확인할 수 있고, 어떤 사업에 들어가더라도 그대로 쓰인다.
그리고 무기체계의 구체적 취약점·공격 기법은 다루지 않는다. 이 모듈의 주제는 규격이 요구하는 검증과 증빙이다.
환경이 증거의 전제라는 말의 뜻
일반 소프트웨어 QA 에서 시험 환경은 편의 다. 어디서 돌려도 결과가 같다면 빠른 환경을 쓴다. 규격 환경에서는 다르다. "어디서 실행했는가" 가 결과의 의미를 바꾼다.
"시험 1,240건 전부 통과" 라는 문장은 그 자체로 아무것도 증명하지 않는다. 증명하는 문장은 이런 모양이다 — "형상 번호 R1.4.2 의 실행 코드를, 대상 하드웨어 동등 구성에서, 계측 없이, 명시된 컴파일 옵션으로 빌드해, 1,240건을 실행해 전부 통과했다." 전제가 빠지면 결과는 재현할 수 없고, 재현할 수 없는 결과는 증거가 되지 못한다.
그래서 이 분야 QA 가 환경에 들이는 시간은 낭비가 아니다. 환경을 문서화하는 일이 시험 작업의 절반 이다.
호스트에서 통과한 것이 대상에서 깨지는 이유
개발 PC(호스트) 에서 돌리는 시험은 빠르고 편하다. 그리고 많은 활동을 그렇게 한다. 문제는 호스트와 대상 하드웨어가 같은 코드를 다르게 실행한다 는 점이다. 차이는 여섯 축에서 나온다.
| 축 | 차이가 만드는 결함 |
|---|---|
| 컴파일러·최적화 | 분기 합치기·순서 변경·미정의 동작 해석 차이 |
| 자료형 크기·정렬 | int 폭, 구조체 패딩, 정렬 제약 위반 |
| 바이트 순서 | 통신·저장 데이터 해석이 반대로 |
| 부동소수 처리 | 연산 순서·중간 정밀도·라운딩 차이로 값이 미세하게 다름 |
| 자원 한계 | 스택 깊이, 힙 없음, 메모리 보호 유무 |
| 타이밍 | 클럭, 캐시, 인터럽트, 실제 주기 |
마지막 두 축이 특히 중요하다. 호스트에는 메모리가 넘치고 스택이 깊지만 대상에는 없다. 호스트에서 멀쩡한 재귀가 대상에서 스택을 넘긴다. 그리고 호스트는 실시간 환경이 아니다 — 주기를 맞춘다는 요구는 호스트에서 검증 자체가 불가능 하다.
그래서 활동을 환경에 배분하는 원칙이 생긴다.
- 호스트에서 할 수 있는 것 — 요구 기반 시험의 논리 확인, 초기 커버리지 측정, 빠른 회귀. 다만 결과를 최종 증거로 쓰기 전에 대상에서 다시 확인 한다
- 대상(또는 동등 구성) 에서만 할 수 있는 것 — 타이밍, 자원 사용, 하드웨어 인터페이스, 인터럽트 상호작용, 최종 실행 코드의 동작
- 둘 다 하는 것 — 안전 관련 핵심 요구. 호스트에서 설계하고 대상에서 확정한다
xIL 계층(MIL·SIL·PIL·HIL) 의 구분과 각 계층이 무엇을 대체하는지는 모듈 46 레슨 5 가 다룬다. 이 레슨은 그 위에서 "그래서 어느 결과를 증거로 쓸 수 있는가" 만 본다.
계측이 대상을 바꾼다 — 관측의 역설
커버리지를 재려면 계측이 필요하고, 타이밍을 재려면 측정 코드나 외부 장비가 필요하다. 그런데 계측은 코드를 바꾼다. 코드가 커지고 느려지고, 때로는 메모리 배치가 달라진다.
여기서 모순이 생긴다.
- 계측하고 실행한 결과 — 커버리지는 얻지만, 실행된 코드가 배포 코드가 아니다
- 계측 없이 실행한 결과 — 배포 코드지만, 커버리지를 모른다
실무에서 쓰이는 처리 방식은 둘 다 하고 차이를 설명하는 것 이다.
- 계측 빌드로 커버리지를 측정한다
- 비계측 빌드로 기능·타이밍 시험을 실행한다
- 두 실행이 같은 소스 형상 임을 형상 식별로 보인다
- 계측이 결과에 영향을 주지 않았음을 보이는 근거를 적는다 — 동일 케이스의 판정 결과 비교, 타이밍 여유의 비교
- 계측 빌드에서만 통과하거나 비계측에서만 통과하는 케이스가 있으면 그 자체가 결함 신호 로 다룬다
5번이 핵심이다. 계측 유무로 결과가 갈리는 코드는 타이밍이나 메모리 배치에 의존하는 코드 이고, 그런 의존은 안전이 걸린 소프트웨어에서 결함이다. 즉 이 비교는 번거로운 절차가 아니라 결함을 찾는 수단 이다.
관측 수단의 영향은 하드웨어 쪽에서도 나타난다. 오실로스코프·로직 분석기로 신호를 보는 일과 그 전기적 영향은 모듈 46 레슨 4 가 다룬다.
실시간 요구를 다루는 환경의 조건
"주기 안에 끝난다" 는 요구를 시험하려면 환경이 세 가지를 만족해야 한다.
1) 측정이 대상을 방해하지 않아야 한다. 소프트웨어 타이머로 자기 자신을 재면 측정 오버헤드가 결과에 들어간다. 외부 관측(출력 핀 토글 + 계측기, 추적 포트) 이 더 신뢰할 수 있다. 어떤 방법을 썼고 오차가 얼마인지가 증거에 들어간다.
2) 최악 조건을 만들 수 있어야 한다. 평균 실행 시간은 거의 의미가 없다. 필요한 것은 가장 오래 걸리는 경로 이고, 그 경로를 만드는 입력과 상태를 설계해야 한다. 캐시가 비어 있는 상태, 인터럽트가 몰리는 상태, 분기가 가장 긴 경로로 가는 입력을 의도적으로 만든다. 최악 실행 시간(WCET) 분석의 기법과 도구는 모듈 46 의 RTOS·실시간 영역에서 다룬다 — 이 레슨은 그 결과를 증거로 남기는 조건 만 본다.
3) 반복 가능해야 한다. 같은 입력으로 같은 결과가 나와야 한다. 실시간 소프트웨어에서 이것이 어려운 이유는 비결정성 이다 — 인터럽트가 언제 들어오는지, 스케줄러가 어떤 순서로 깨우는지가 실행마다 다를 수 있다. 결과가 매번 다르면 "통과" 가 무슨 뜻인지 모호해진다.
비결정성을 다루는 현실적 방법은 셋이다.
- 고정한다 — 인터럽트 소스를 통제하고, 시작 상태를 매번 같게 만든다
- 반복한다 — 한 번 통과를 증거로 쓰지 않고, 횟수를 정해 반복하고 분포를 남긴다
- 여유를 요구한다 — 측정값이 한계에 닿지 않고 여유(margin) 를 갖도록 기준을 세운다. 한계의 몇 %를 여유로 요구할지는 사업·규격이 정하므로 원문 확인 이다
환경 적격성 — 환경 자체를 문서로 만든다
규격 환경에서 시험 환경은 적격성(qualification) 을 설명해야 하는 대상 이다. "이 환경에서 얻은 결과를 왜 믿을 수 있는가" 에 답하는 문서가 필요하다. 적격성 요구의 정확한 범위와 수준별 차이는 규격 원문과 사업의 인증 계획에서 확인한다(원문 확인). 공통으로 요구되는 성격은 이렇다.
| 항목 | 적어야 하는 것 |
|---|---|
| 구성 식별 | 하드웨어 품명·개정, 보드·케이블·전원, 계측기 모델·교정 상태 |
| 소프트웨어 식별 | OS·RTOS 버전, 컴파일러·링커·옵션, 라이브러리, 시험 도구 버전 |
| 대상 동등성 | 실제 장비와 다른 점과, 그 차이가 결과에 미치는 영향 평가 |
| 자극·부하 생성 | 입력을 어떻게 만드는가, 그 수단의 정확도 |
| 관측 수단 | 무엇으로 재는가, 오차와 영향 |
| 설정 보존 | 설정이 재현되는가(파일로 관리되는가, 손으로 맞추는가) |
| 변경 통제 | 환경이 바뀌면 무엇을 다시 하는가 |
"대상 동등성" 칸이 이 표의 핵심 이다. 실제 장비 그대로 시험할 수 있는 경우는 드물다. 거의 항상 일부가 다른 구성 에서 시험하고, 그 차이를 설명해야 한다. 차이를 숨기면 증거가 무너지고, 차이를 적고 영향을 평가하면 증거가 성립한다.
그리고 손으로 맞추는 설정은 증거의 약점 이다. 다음 사람이 같은 환경을 재현할 수 없으면 그 결과는 1회성이다. 환경 설정을 파일로 관리하고 버전을 붙이는 것이 이 분야에서 자동화보다 먼저 오는 기본기다.
환경이 바뀌면 결과가 무효가 된다
사업 중에 환경은 반드시 바뀐다. 보드 개정이 올라가고, 컴파일러 패치가 적용되고, 계측기가 교체되고, RTOS 버전이 올라간다. 그때마다 어느 결과가 무효가 되는가 를 판정해야 한다.
판정 기준을 미리 정해 두는 것이 QA 의 일이다.
- 전면 재실행 — 컴파일러·최적화 옵션 변경, RTOS 버전 변경, 대상 프로세서 변경
- 부분 재실행 — 특정 주변장치 관련 변경 → 그 인터페이스 관련 케이스
- 재실행 불필요(근거 기록) — 결과에 영향을 주지 않음을 설명할 수 있는 변경 (예: 계측기 교정 갱신, 시험 데이터 생성 스크립트의 로그 문구 수정)
이 기준이 없으면 두 극단으로 간다. 전부 다시 돌리느라 일정이 터지거나, 아무것도 다시 돌리지 않아 증거가 실제 형상과 어긋난다. 기준을 문서로 만들어 합의해 두면 변경이 일어날 때마다 논쟁하지 않는다.
안전 전제 — 이 레슨에서 하지 않는 일
시험 환경이 실제 장비·전원·구동부와 연결되는 순간, 그것은 소프트웨어 작업이 아니다. 분명히 해 둔다.
- 실제 장비·구동부·전원 계통의 조작을 QA 가 임의로 하지 않는다. 승인, 자격, 안전 조치가 전제다. 이 레슨의 실습 과제는 전부 설계·문서 과제 다
- 구동부가 움직이는 시험은 참관·기록 쪽이 QA 의 자리 다. 조작은 해당 담당이 한다
- 안전 장치를 우회한 구성으로 시험하지 않는다. 시험 편의를 위해 인터락을 해제하는 구성은 그 자체로 중대한 절차 위반이다
- 실제 운용 환경에서 임의 시험을 하지 않는다. 시험은 정해진 환경과 일정에서 한다
장애 주입의 일반 기법과 안전 원칙은 모듈 46 레슨 6, 설비 안전 영역의 QA 경계는 모듈 62 레슨 6 이 다룬다. 두 레슨의 원칙이 여기서도 그대로 적용된다.
실무에서 왜 필요한가
이 분야에서 심사·검토에서 가장 자주 되돌아오는 지적이 환경 이다. 시험을 성실하게 했고 결과도 좋은데, "이 결과가 대상 하드웨어에서 얻어진 것입니까", "계측 빌드와 배포 빌드가 같은 형상입니까", "환경 구성이 어디에 적혀 있습니까" 에 답하지 못해 되돌아온다.
그리고 되돌아오는 시점이 사업 후반 이다. 그때는 환경이 이미 바뀌어 있어 같은 조건을 재현할 수 없고, 다시 실행하려면 장비 시간을 새로 받아야 한다. 장비 시간은 이 분야에서 가장 희소한 자원이다.
반대로 환경 문서를 처음부터 관리하면 두 가지를 얻는다. 첫째, 질문에 문서로 답하게 된다. 둘째, 변경이 일어날 때 영향 범위를 즉시 말할 수 있다. 이 두 가지가 가능한 QA 는 사업에서 위치가 다르다.
실무적으로 더 큰 소득이 하나 더 있다. 계측 유무 비교와 반복 실행이 결함을 찾아낸다. 타이밍에 의존하는 코드, 초기화 순서에 의존하는 코드, 간헐적으로 깨지는 코드는 이 절차에서 드러난다. 환경 관리를 형식으로 보면 그 소득을 놓친다.
채용 관점에서는 이 레슨의 내용이 경력의 구분선 이 된다. "시험을 돌렸습니다" 와 "대상 동등 구성에서 비계측 빌드로 100회 반복해 여유를 확인했고 환경 구성서를 첨부했습니다" 의 차이는 면접에서 즉시 드러난다.