소프트웨어 검증은 종종 성가시고 거추장스러운 영역으로 여겨진다. 비용이소요되는 반면 당장의 수익으로 이어지지 않고, 큰 책임이 따르지만 어떻게든 내 책임만은 아니기를 바라는게 관련자들의 솔직한 심정이다. 완벽하게 해내더라도 성과가 바로 눈에 보이지 않는데, 잘못되면 큰 사고가 발생되다 보니, 모두가 갖은 핑계로 책임을 회피하려는심정이다.
문제는 모두가 책임을 회피하려는 이 분야가, 갈수록 더 중요한 역할을맡는다는 점이다. 어느새 우리 산업의 구조는 완전히 바뀌어, CPS가모든 산업을 통제하는 수준까지 확산되었다. 소프트웨어가 기껏해야 책상 위 컴퓨터 속에나 존재하던 시절에는오류가 나더라도 컴퓨터를 재부팅 하면 그만이었다. 하지만 소프트웨어가 보안, 교통, 의료, 건설, 항공, 원자력 등 산업 전반의 각종 민감한 일들을 처리하는 상황에서는, 사소한 오류가 인간의 생명을 물리적으로 위협할 수 있다.
[소프트웨어세이프티는 하드웨어 점검과 출발점 자체가 다르다]
게다가 소프트웨어 특유의 자율성이 해결을 더 어렵게 만든다. 자동화가하드웨어만으로 구성되어 있던 때에는 정해진 기능 부품들의 내구성과 노화가 주 고장 원인이었다. 하지만, 소프트웨어는 상황에 따라 제 스스로 동작한다. 제품을 물리적으로교체하지 않아도 코드 변경만으로 전체 시스템을 진화하게 만들 수 있다는 점이 소프트웨어의 탁월함이자 매력인데, 그것은동시에, 소프트웨어에 설계 시에는 전혀 예측하지 못했던 (오)작동 자유도가 높다는 의미이기도 한다. 그래서 소프트웨어 세이프티는정해진 기능검증뿐만 아니라, 발생 가능한 모든 극한의 시나리오까지 미리 예측해서 도출하고 대비해야 한다.
[눈이멀었을지도 모르는 내비게이션에 우리 가족의 안전을 맡기다]
그럼에도 아직까지 소프트웨어 검증은 대부분 테스팅 경험자들의 ‘감’에 의존하고 있다. 설계된 기능에서 논리적으로 발생 가능한 경우의수가 너무 많고 유추도 어렵기 때문에, 실제로 테스팅 설계는 기술이 아닌 경험자의 노하우를 빙자한 직관에의존한다. 성공하면 전문가가 용한 것이고 실패하면 ‘테스팅이란게 원래 그러니까, 100% 완벽하게는 불가능하니까’ 로치부한다. 이쯤 되면 공학이 아니라 점술의 영역 같다. 소프트웨어가나날이 산업의 중요한 일들을 처리할수록, 우리의 일상과 안전은 점점 더 운에 맡겨지는 셈이다. 어제는 괜찮았고, 어쩌면 오늘도 별 일 없이 넘어갈지 모른다. 마치 진작부터 구조적 결함으로 인한 위험이 여러 차례 지적되었던, 사고전의 성수대교나 삼풍백화점을 지나쳤던 사람들처럼 말이다.
안타깝게도 과거에는 쉽게 적용할 수 있는 실용적 공학 기술이 없다 보니, CPS 산업 현장에서 소프트웨어 검증은 ‘꼭 해야하지만, 가능하면 나는, 지금은, 여기서는 안 했으면 좋겠다는’ 일에 속해 있다. 그것은 세이프티가 중요하지 않아서가 아니라, 너무나 중요하다 보니그 막중한 책임이 부담으로 작용하기 때문이다. 그렇다면 더욱 더 기술 중심의 전문 인력들이, 더 좋은 대우로 업무에 투입되어 기업과 사회 전체의 부담을 줄여줘야 한다.
[지금까지의테스트 커버리지로는 안심할 수 없다]
공학은 2차 방정식과 같다. 형이상학적문제로 고민하는 것이 아니라, 바로 와 같은 근의 공식에 대입하여 결과를 보장해야 한다. 본질적인 고민은 극소수의 천재들에게 맡기고, 우리는 천재들이 발견한지식체계를 이용해서 해법을 도출하면 된다. 하물며 많은 사람의 생명이 걸린 안전 검증이라면 더욱 더기술적이고, 객관적이며, 공학적인 접근이 이루어져야 한다.
비슷한 의도로 사용중인 Code Coverage 나 RBT Coverage 등의 경우, ‘구현된것에 대한 검증 수준‘ 이지, ‘필요함에도 구현되지 않은 세이프티 메카니즘’을 측정하는 능력은 없다. 그렇기 때문에, 개인적으로는 Code Coverage를 ‘구현된 코드만의 Coverage(필요함에도구현되지 않은 것은 책임지지 않음)’ 로 이름을 바꾸는 것이 더 나을 것 같다. RBT 또한 ‘요구사항이라는 것을 구현해본 적은 있음(모든 예외 처리를 했다고는 기대하지 마시오)’라는 말로 바꾸면 좋겠다. 이 두 커버리지를 ‘품질 커버리지’ 혹은 ‘안전성’이라고부르는 것은 누군가의 사업적 이익은 될지 몰라도 안전 검증에 대한 잘못된 인식을 가져온다는 점에서, 해롭다.
자동차 브레이크를 소프트웨어로 구현했다고 가정한다면, 위 두 커버리지는 ‘밟았더니 정지했던 적이 있더라‘ 정도의 결과를 내놓는다. 그런데 우리가 굳이 자동차 브레이크를 검사하는 이유는 빗길, 커브길, 타이어 공기압, 마찰력, 차량속도, 가속도, 타이어 크기, 무게 등을 조합한 모든 상황에서 ‘어떠한 경우에도 정지할 수 있는지‘를 확인하고 싶어서이지 ‘어차피 완벽한 테스트는 불가능하다.’며찜찜한 기분으로 검증되지 않은 자동차에 내 생명을 맡기기 위해서가 아니다.
안정성 관점에서 검증이 필요한 모든 경우의 수를 대략적으로 계산하면, 26만가지정도가 도출되는데, 당연히 그것들 모두를 사람이 수동으로 도출하거나 수행할 수는 없다. 그렇기 때문에 시나리오를 자동/반자동으로 도출하는 기술과, 중요한(위험한) 곳만 테스트 하는 ‘전략’이 투입되어야, 점술이 아닌 공학 영역에서의 소프트웨어 세이프티가 검증이 가능해진다. 이를테면, 소프트웨어 공학기술 전문기업인 씽크포비엘 (대표 박지환) 에서 연구 개발한 CETA (Cause-Effect Test Auto Analyzer) 기술을 통해 이러한 부분을 검증할 수 있다..
[새로운 기술의 도입이 필요하다]
CETA는 테스트의거장 마이어스(Glenford J. Myers)가 1974년에창안한 방법을 기반으로 국내 산업 현장에 실용적으로 적용할 수 있도록 연구 개발된 독자기술이다. 해당기술을 통해 1단계에서는 명세서를 기반으로 논리 관계 분석 기법을 적용하여 식별하고[1], 2단계에서는 명세서의 논리 관계를 DNF (Disjunctive Normal Form) 라는 논리식으로 표현한다[2]. 예를 들면 명세서 상에는 논리적으로는 없으나, 사람은 있다고 잘못해석하는 경우 (A+C è AB+C), 논리 관계의 위치를 틀리게 해석하는 경우 (AB+C è A+BC), 누락한 경우 (AB+C è A+C), 논리의 관계성을 잘못 해석한 경우 (AB è A+B) 등 오작동을 일으킬 수 있는 총 9가지의 실수 유형을 제안한다. 마지막으로, 3단계에서는 SW의모듈 특성을 10가지 관점으로 분류해서, 테스트의 충분성을측정 및 평가한다.[3]
기존에는 ‘어떠한 경우가 발생할 지’를 고민하는데 시간을 소비했고, 막대한 열정으로도 만족할 만한 결과를 얻지 못했다면, 이 기술은아무런 고민 없이도 발생 가능한 모든 경우를 도출한다는 것과, 이렇게 줄어든 시간을 ‘어디를 더 테스트하는 것이 좋을까’의 전략 시간으로 전환할 수 있다는 것이 보다 의미 있는 점이다. 이 모든 기술은공식으로 정형화되어, 테스트 시나리오 도출 및 전략적 검증 영역 제안 등, 대다수 단계가 자동화 되어 있다. 물론 이 정도 수준으로도 완벽하다거나소프트웨어 세이프티에 만능이라 할 수 없지만, 적어도 일부 전문가들의 감에 의지하는 것보다는 객관적신뢰를 월등한 수준으로 보장한다는 것이 중요하다. 남은 것은 이제 기술을 산업에 빠르게 확산시킬 전문인력의 수급이다.
[기술이있어도, 제대로 활용할 사람이 없다]
아쉽게도 CETA와같은 유용한 신기술도, 인력 공급의 한계로 현장에서 필요한 수요만큼 적시에 산업에 확산되지 못하고 있다. 이를테면 면적을 구하는 공식이 없어 눈대중으로 찍던 시절을 지나, 이제는정확하게 계산할 적분 공식과 시간을 단축시킬 적분 계산기까지 발전이 되었음에도, 기술을 사용할 인력부족으로 현장에서는 여전히 비효율적이며 위험한 방식을 유지하는 상황이다. 소프트웨어 세이프티의 인력수급 문제는 민, 관, 학이 바로 지금, 고민하고 해법을 내놓아야 할 과제이다. 그래야 안전 기반 기술이토대가 될 미래의 산업 환경을 더 유리하게 맞이할 수 있다.
안전 산업에서는 지금보다 더 전문적이면서 소통 가능한 인력들이, 객관적으로보장받을 방법론과 기술을 가지고 업무를 전담할 수 있어야 한다. 기업도 정부도, 안전성에 대한 면밀한 검토 없이 눈앞의 수익과 당시 성과를 좇아 쌓아 올린 성취는 그 성장에 한계가 있을 뿐아니라, 언제고 허망하게 무너질 수 있음을 주지해야 한다. 오작동이심각한 문제로 발생한 후에 책임 소재를 찾으려면 이미 늦다. 확실한 전문가들이 객관적 기술로 처음부터책임을 갖고 문제를 예측 가능하게 만든 이후에야 다양한 소프트웨어 산업에 우리의 생활과 안전을 믿고 맡길 수 있다.
[1] 한국정보통신기술협회(TTA) 표준 소프트웨어 기능 안전성 검증을 위한 명세 기반 테스트 설계 방법 TTAK.KO-11.0251
[2] IEEE InSTA 2017 in Tokyo (Suggestion of Practical Quantification Measuring Method of Test Design Which Can Represent the Current Status
[3] 한국정보통신기술협회(TTA) 표준 소프트웨어 기능 안전성 검증을 위한 테스트 커버리지 측정 방법 TTAK.KO-11.0250
