왜 장비 소프트웨어는 V자 모델의 오른쪽 절반을 실행할 수 없는가

V자 모델을 모르는 장비 엔지니어는 아마 없을 겁니다. 왼쪽을 따라 내려가며 요구에서 상세 설계와 구현으로 가고, 오른쪽을 따라 올라오며 단위 테스트, 통합 테스트, 시스템 검증으로 돌아옵니다. 교과서에도 나오고 사내 품질 매뉴얼에도 실려 있습니다.

그런데도 자동화 장비 개발 현장에서 이 그림대로 움직이는 곳은 거의 없습니다. 왼쪽은 대체로 쓰여 있습니다. 오른쪽은 아래 두 단이 비어 있습니다.

현장이 게을러서가 아닙니다.

왼쪽은 경험으로 쓸 수 있다

V자의 왼쪽 내리막 —— 요구 정의, 위험성 평가, 안전 요구 사양, 시스템 설계, 상세 설계, 구현 —— 은 사실 어떻게든 해낼 수 있습니다.

과거 장비의 자료가 있고, 비슷한 기구를 짜 본 경험이 있고, 지난번에 어디서 막혔는지 기억하는 사람이 있습니다. 완벽하지는 않더라도 레거시 자료와 숙련자의 경험으로 왼쪽은 채워집니다.

문제는 오른쪽입니다.

오른쪽 아래 두 단은 물리적으로 존재하지 않는다

V자의 오른쪽은 아래에서부터 단위 테스트 → 통합 테스트 → 시스템 검증 → 인수 검증 순으로 올라갑니다. 소프트웨어 산업이라면 이 맨 아래 —— 단위 테스트 —— 의 밀도가 가장 높습니다. 함수 하나, 클래스 하나를 떼어내서 입력을 주고 출력을 확인합니다.

자동화 장비에서 같은 일을 해 보십시오.

Z축 승강 로직만 떼어내서 시험하고 싶습니다. 그런데 Z축은 모터 드라이버에 물려 있고, 원점 센서에 물려 있고, 상위 제어기에 물려 있고, 옆 축과의 간섭 조건에 묶여 있습니다. 이것들은 하나의 하드웨어로 조립되고 나서야 비로소 움직입니다. 분해해서 단위로 시험할 구조가 애초에 존재하지 않습니다.

장비 소프트웨어에 단위 테스트가 없는 것은 쓰지 않았기 때문이 아닙니다. 쓸 대상이 물리적으로 존재하지 않기 때문입니다.

그 결과 검증은 통합 테스트 → 시스템 검증 → 현장 시운전에만 의존하게 됩니다. V자의 오른쪽은 아래 두 단이 빠진 채로 운용됩니다.

그리고 장비 업계는 이 빠진 상태로 수십 년을 해 왔습니다. 방법은 단순합니다 —— 장비가 돌아가면 됐다.

”돌아가면 됐다”의 대가는 언제 치르는가

이 경험적 검증은 실제로 잘 굴러왔습니다. 적어도 잘 굴러가는 것처럼 보였습니다. 그래서 지금까지 이어져 왔습니다.

대가는 돌아가지 않았을 때 나타납니다. 그것도 가장 비싼 자리에서.

소프트웨어 공학에는 수정 비용이 발견이 늦어질수록 뛴다는 오래된 경험칙이 있습니다. 설계 단계에서 고치는 비용을 1이라 하면 통합 테스트에서 10, 현장이나 양산에서 100에서 1000. 장비 개발에서는 여기에 현장 재작업, 납기 지연, 안전 인증 재제출이 얹힙니다.

그러나 정말로 발목을 잡는 것은 금액 자체가 아닙니다. 원인을 갈라낼 수 없다는 점입니다.

단위 테스트와 모듈 검증이 있으면 오류가 어디 있는지 어느 정도 좁힐 수 있습니다. 그것이 없으면 현장에서 문제가 났을 때 이렇게 시작하게 됩니다 ——

“이건 설계 문제인가, 구현 문제인가”

이 판단부터 시작해야 한다는 상황 자체가 장비 소프트웨어 검증 비용의 정체입니다. 디버깅에 몇 명이 몇 주를 썼는지 떠올려 보십시오. 그 대부분은 고치는 시간이 아니라 어디가 잘못됐는지 밝혀내는 시간이었을 겁니다.

업계는 현실적인 타협을 해 왔다

물론 손을 놓고 있었던 것은 아닙니다.

• 설계 리뷰를 두껍게 한다
• 설계 변경을 최소한으로 억제한다
• 검증된 모듈만 사용한다
• 통합 테스트를 강화한다

모두 옳습니다. 그리고 모두 오류를 줄일 수는 있어도 없앨 수는 없습니다. 리뷰는 사람이 읽는 한 놓치고, “검증된 모듈만 쓴다”는 새로운 것을 하지 않는다는 뜻이기도 합니다.

한 단계 더 들어가려 하면 이렇게 됩니다.

정적 분석을 도입한다. 레거시 코드에 돌리는 순간 경고가 수천 건 나옵니다. 어느 것이 진짜 문제인지 모르는 채로 우선 분류부터 시작해야 합니다. 도입 첫날이 가장 무거운 구조입니다.

단위 테스트를 도입한다. 그러려면 테스트할 수 있는 단위로 분해되는 구현을 먼저 준비해야 합니다. 즉 구현과 제작 비용을 전부 앞에서 치르게 됩니다.

둘 다 “하는 편이 낫다는 건 안다”에서 멈추는 데에는 이유가 있습니다.

빠져 있는 것은 테스트가 아니라 “설계를 확인할 수단”

여기서 질문을 다시 세울 필요가 있습니다.

V자 오른쪽 아래 두 단이 채워지지 않는 것은 구현된 것을 시험할 수단이 장비에 없기 때문이었습니다. 그렇다면 구현된 것을 시험하기를 그만두면 됩니다 —— 설계 자체를 확인한다는 수가 남아 있습니다.

말장난이 아닙니다. 실제로 V자 왼쪽에서 우리가 쓰고 있는 것을 보십시오. 상세 설계에는 장비가 어떤 상태를 가지고, 어떤 순서로 움직이고, 어떤 조건에서 인터록이 걸리는지가 적혀 있습니다. 그 정보만으로 확인할 수 있는 질문이 여럿 있습니다.

• 이 설계에서 두 축이 동시에 위험 영역에 들어가는 절차가 존재하는가
• 비상 정지에서의 복귀 시퀀스에, 어떤 센서 상태에서도 빠져나올 수 없는 조합은 없는가
• 이 인터록 조건은 상정하고 있는 위험 시나리오를 정말로 전부 막고 있는가

모두 실물 장비가 없어도 답할 수 있는 질문입니다. 그리고 실물 장비가 나온 뒤에 답하기에는 너무 비싼 질문이기도 합니다.

다음에 읽을 글

“설계 자체를 확인한다”는 것은 장비 업계에 익숙하지 않은 발상일지도 모릅니다. 그러나 완전히 새로운 이야기는 아닙니다. 세계는 이미 “모델로 설계한다”는 방향으로 움직이고 있고, 거기에 한 단이 모자랄 뿐입니다.

그 한 단이 무엇인지는 “모델로 설계한다”의 다음에 오는 것에서 다룹니다.

설계를 확인하는 것과 테스트하는 것이 구체적으로 어떻게 다른지는 테스트와 형식기법은 무엇이 다른가에서 다룹니다.