徐東秀
86년 중앙대 컴퓨터공학과 졸업
89년 중앙대 컴퓨터공학과 석사
90년 연국 맨체스터 이공대학(UMIST) 전자계산학과 석사
94S년 영국 맨체스터 이공대학(UMIST) 전자계산학과 공학박사 소프트웨어공학 전공
현재 시스템공학연구소(SERI) 소프트웨어공학연구부 선임연구원
정보화 과정에서 우리는 알게 모르게 생활의 많은 부분을 컴퓨터에 의존하거나 많은 영향을 받게 된다. 마이크로 프로세서 제어 분사엔진이 장착된 자가용, 교통신호 제어기, 카드 키 출입문, 전자메일, 일정관리기, 워드프로세서 등 수없이 많다. 워드프로세서나 카드 키 입력기, 일정관리기처럼 시스템의 비정상 종료(Failure)로 인해 사람에게 미치는 피해가 미미할 수 있지만 교통신호 제어기, 항법장치 소프트웨어(SW) 등은 인명이나 재산에 직접적인 피해를 줄 수 있어 이들 시스템들의 오동작은 중대한 사고와 직결된다. 이러한 SW들을 통칭해 고안전성(Safety-critical) 소프트웨어라 부른다. 또 어느 정도 신뢰성을 확보해야 하는 전자메일, 엔진제어시스템 등은 특정 시간내에 반드시 정해진 임무를 수행해야 하는 SW로 고기능성(Mission-critical) 소프트웨어라 한다.
우리가 만든 SW는 과연 얼마나 신뢰할 수 있는가. 이는 SW를 개발하는 사람들을 끊임없이 괴롭혀왔던 문제 중 하나다. SW의 신뢰성과 안전성에 대해 체계적인 접근 방법으로 시스템신뢰도 측정, 위험성 분석, 테스팅, 검증, 품질보증 등 많은 기법들이 개발됐다. 이처럼 많은 기법들이 있는데도 불구하고 인수된 SW의 10% 정도만 수정없이 사용됐다는 미국 국방부(DoD)의 보고가 있다. 이 문제에 대한 근본적인 이해를 위해 기존 SW개발을 보는 시각에 대해 한번쯤 짚고 넘어가야 한다.
많은 사람들은 SW개발에서 코딩 혹은 프로그래밍 작업이 제일 어렵고 중요하다고 믿고 있다. 여기에는 일반인, 심지어 SW개발자들도 범하기 쉬운 오류가 도사리고 있다. 즉 프로그램을 생성시키는 것은 코딩이지만 그 이전 혹은 이후에도 역시 그에 못지않은 중요한 작업이 있으며 이 작업은 오히려 코딩보다 더 어렵고 중요하다는 점이다. 실제로 SW개발을 위해 투입되는 인력 및 시간 분포는 프로그래밍 단계보다 이전 단계의 활동에 많이 편중되어 있다.
SW는 하드웨어와 달리 그 형체가 보이지 않아 유연하다는 통념을 가지고 있고 이것을 생산하는 과정 역시 프로그래머의 머리속에 존재하는 소프트한 생각을 프로그래밍 언어라는 매체를 통해 컴퓨터에 표현한 것이라 이해하기 쉽다. 그러나 현실적으로 SW 자체는 「소프트」할 수 있어도 이를 개발하는 과정은 전혀 「소프트」하지 않다는 점이다. 미국 카네기 멜론 대학의 대니얼 잭슨 교수는 『소프트웨어를 개발하는 전 단계를 공정에 비유한다면 실제 제품을 생산하는 생산공정, 다시말해 프로그래밍도 중요하지만 어떤 제품을 만들 것인가 하는 계획과정, 즉 사용자 요구분석 역시 이에 못지않게 중요하고 심지어 이 과정이 프로그래밍 활동보다 더욱 어렵다』고 주장한다.
잘못된 명세(Specification) 혹은 스펙을 가지고 시작하는 작업은 이후 개발 과정이 아무리 정교하다할 지라도 쓸모없는 제품을 만들어내게 된다. SW 컨설턴트인 크레인들러 박사는 개발이 끝난 SW를 인도한 후 1년동안 보고된 에러 리포트를 분석한 결과 3분의 2이상의 에러가 시스템개발 초기인 요구분석 단계에서 발생된 것이라고 지적했다. 또한 시스템 요구 정의 과정에서 발견된 에러를 고치기 위한 노력을 1이라 가정하면 개발 단계에서는 1.5∼6배의 노력이 들고 유지보수 단계에서는 60∼1백배 정도의 노력이 소요되는 것으로 알려졌다. 이는 시스템 개발에서 코딩보다 사용자 요구 사항을 명확히 찾아내는 것이 얼마나 중요한가를 단적으로 말해주는 것이다.
사용자의 요구사항을 찾아내기 위해 흔히 쓰이는 방법은 인터뷰를 통해 얻은 내용을 자연어, 혹은 일정 양식의 명세서를 이용하거나 그림을 통해 표현하는 방식이다. 이러한 일들을 통해 정리된 문서를 사용자 요구명세서라 한다. 사용자 요구 명세서의 용도는 크게 세가지로 구분할 수 있다.
첫째, 사용자와 개발자 사이의 의사소통을 위한 계약이다. 만일 최종 인도된 제품이 사용자 요구명세의 내용과 다를 경우 문제가 발생한다. 둘째, 개발자 사이의 의사전달을 하는 수단으로 쓰인다. 실제 프로그래머들은 사용자와 직접 접촉하는 일은 드물며 이들은 시스템 분석가가 전달해 준 사용자 요구 명세를 통해 무엇을 해야 하는지 이해한다. 더구나 시스템의 일부가 용역을 통해 개발되는 상황이면 이들 명세서의 역할은 더욱 중요해 진다. 셋째, 개발된 제품에 대해 테스트를 할 경우 테스트의 기준이 되는 정보를 전달해 준다는 점이다.
이같은 활동에서 공통점은 명세가 여러 사람들 사이의 의사전달수단으로 쓰인다는 점이다. 만일 명세에 표현된 정보 자체가 명확하지 않고 애매모호하다면 사람에 따라 해석이 달라질 가능성이 있다. 따라서 정보를 전달하는 과정, 즉 사용자에서 시스템 분석가로, 또 설계자에서 프로그래머로 전달되는 사이 원래 의도했던 바와 많이 변질될 수 있다. 이를 완화시키는 방법으로 구조적 분석기법, 객체지향 설계기법, 엔터티 릴레이션 모형 등 많은 기법이 제안되어왔다. 이들 방법은 도형으로 시스템을 표현하며 일치된 이해를 얻기 위해 각종 설계지침, 지원도구들을 수반한다. 하지만 이들 중 어떤 것도 SW의 검증 혹은 증명이 요구될 경우 특별한 해법을 제공해 주지 못한다.
대안으로 나온 것이 현재 해외에서 각광 받고있는 정형방법(Formal Methods)이다. 정형방법이란 정형명세(Formal Specification)라는 수학적 표기법을 사용해 SW 혹은 하드웨어가 포함되는 시스템의 특성 및 기능을 서술하며 증명 가능한 사항에 대해 증명하는 기법으로 정의할 수 있다. 따라서 이 방법은 명세에 대한 수학적 완전성(Completeness), 정확성(Correctness), 일관성(Consistency)을 증명할 수 있어야 한다. 정형방법의 우수성은 신뢰성, 안전성을 증명해야 하는 응용에 대해 기존 어떤 방법보다 명확한 답을 줄 수 있다는 점이다.
정형명세가 갖는 구조적인 특징은 먼저 시스템이 만족해야 할 특성들을 서술할 수 있는 명세 언어를 제공한다는 점이다. 현재 세계적으로 많이 쓰이고 있는 정형명세 언어로는 옥스퍼드 대학이 개발한 Z, CSP(Communicating Sequence Process)방법, 영국 맨체스터 대학의 VDM(Vienna Development Method), CCITT표준인 SDL(Specification and Description Language), LOTOS(Language of Temporal Ordering Specification)등 수 십종에 달한다. 정형명세가 기존의 컴퓨터 프로그램과 근본적으로 틀린 점은 서술 방식에 있다. 정형명세는 어떤 시스템이 반드시 만족시켜야 할 조건들을 집합이론, 대수논리 혹은 술어논리에 바탕을 둔 수학적 기호들로 표기해 서술한다. 이는 애매모호성이 제거되고 시스템의 핵심을 이해하는데 도움을 주며 잘 조직된 정리와 공리체계로 제시되는 명제에 관한 증명이 가능하는 장점이 있다.
정형방법을 사용하는 개발절차를 보면 사용자로부터 인터뷰를 통해 획득된 요구정보는 그림 혹은 자연어에 의해 표현되나 이것을 정형언어에 의해 표현되도록 바꾸는 과정의 필요하다. 이 과정에서 누락된 부분, 중복 혹은 모순되는 정보의 확인이 가능하며 사용자에게는 명세를 즉석에서 실행시켜 확인받는 시뮬레이션 기법이 쓰이기도 한다. 그 다음 정형명세는 설계 정보가 담긴 설계 명세로 정제(Refine)되며 이 과정 역시 요구명세의 특성이 설계명세에 정확히 보존되었나 하는 것을 확인받게 된다. 다음으로 검증된 설계명세를 만족시키는 구현을 하게 되며 이때 특정 프로그래밍 언어가 선택되어 코딩된다. 만일 코딩이 수작업으로 진행되었다면 이 코드 역시 설계명세의 충실한 구현물인지가 증명돼야 한다. 현재는 자동화 지원도구의 도움을 받아 상당한 부분의 코드가 정형 설계명세로부터 자동 생성되고 있다.
정형방법은 명세작성, 증명이라는 반복작업을 필요로 하며 따라서 많은 비용과 노력을 필요로 한다. 이것은 일반 개발자가 정형방법을 고려할 때 걸림돌로 작용하고 있다. 이를 해결하는 방법으로 최근 맨체스터 대학의 클리프 존스 교수와 MIT의 재닛 윙 교수가 경량화된 정형방법(Lightweight Formal Methods)이란 주제로 연구하고 있어 그 결과가 주목된다.
정형방법의 성공적 활용은 적절한 지원도구의 사용과 전문가 양성에 있다. 명세의 증명 및 코드생성은 지원도구 없이는 상당히 어려운 작업으로 알려져 있다. 현재 40여종 이상의 정형방법 지원 도구가 개발되어 있다. 대표적으로 상업화에 성공한 도구로는 영국 B코어사의 B툴킷, 포멀시스템사의 FDR, 덴마크 IFAD사의 VDM SL툴박스, CRI사의 RAISE툴 등이다. 외국의 경우 10년 전부터 대학에 정형방법을 교과목으로 채택해 강의하고 있고 영국 옥스퍼드, 케임브리지 대학, 덴마크 IFAD 등에서는 실무자 교육코스로 실시하고 있다.
정형방법을 사용한 사례는 95년 미국 NASA가 우주왕복선 변경관리에 사용한 것을 비롯 현재까지 30여개에 달한다. 특히 캐나다의 AECB(Atomic Energy Control Board)는 원자로 제어관련 시스템의 입찰에 참여하는 기관들에게 정형방법을 사용할 것을 권고하고 있고 영국 국방성은 89년부터 고안전도 SW의 정형방법 적용을 Interim Defence Standard 00-55로 의무화하고 있다.
정형기법관련 과제로 유럽의 경우 3천만달러 규모의 ARISE, 1천6백만 달러 규모의 SPECS과제 등이 수행됐으며 특히 미국의 NASA, 포드 항공사에서는 실무적용의 효과를 보고 있고 국방성과 상무성에서도 역시 많은 관심을 가지고 있다. 국내의 경우 미흡하기는 하지만 한국전자통신연구소, 한국원자력연구소, 시스템공학연구소 등에서 부분적으로 적용 중이며 한국과학기술원, 포항공대, 경기대 등 일부 대학에서도 서서히 연구되고 있다. 응용 측면에서의 정형방법 활용은 다양하나 특별히 통신, 교통, 원자력, 공장자동화, 우주항공 등의 영역에 효과적으로 적용될 수 있다. 고신뢰도, 안전성을 요하는 SW의 대부분을 수입에 의존하는 국내 SW산업의 현실에 비추어볼 때 정형방법 활용을 위한 이론적 토대 구축 및 전문가 양성에 학계, 연구계, 그리고 특히 산업계에서는 많은 관심을 기울여야 할 것이다.