우리에게 정말 고품질소프트웨어가 필요한가?

마이크로소프트웨어 2012년 12월호 원고...

삐딱한 아키텍트의 생각

우리에게 정말 고품질소프트웨어가 필요한가?

소프트웨어 개발에 있어 영원한 화두는 ‘품질’이다. 현업에서 항상 고민하는 ‘적당한 품질의 소프트웨어’라는 것은 어느 정도의 품질을 뜻하는가? 과연 사용자의 요구사항에 어느 정도 맞춘 품질을 고려하는 것이 최선의 선택일까? 비용과 시간을 저울질해 적절한 수준의 품질비용이 어느 정도인가 하는 것은 꽤 오래된 화두이며 꾸준한 논의와 고민이 진행돼왔던 영역이라고 할 수 있다. 실상 사용자는 자신의 요구사항과 품질의 연관 관계에 대해서 인지하자 못하는 경우도 많다. 이번 글에서는 이러한 소프트웨어의 품질과 관련한 몇 가지 사례와 그 방향성에 대해 원칙적인 부분을 인식하고 함께 고민해보도록 하겠다.

------------------------<필자 사진/ 전달 동일>-------------------------

신현묵 supims@gmail.com, 트위터 @zetlos | ㈜헬스허브의 HIE사업부 담당이사와 (주)DRSoft의 고문이사로 활동하고 있다. 과거 우리들병원그룹과 명지병원에서는 정보시스템 구축과 운용 업무를 총괄하는 등 온라인게임 개발부터 대형 SI까지 넓은 경험의 폭을 지녔다. 소프트웨어 아키텍트 생활을 오랫동안 해오고 있으며 지식경제부 산하 KEA 디지털병원수출기획단의 디지털병원 지원사업 기술위원장을 3년간 역임했다. 현재는 정보통신산업진흥원의 소프트웨어아키텍트실무포럼의 의료분과장으로 활동 중이다.

---------------------------------------------------------------------

소프트웨어를 100%의 고품질로 만들어낼 수 있다면 얼마나 행복할까? 엄청난 테스트량과 세밀한 요구 분석과 설계 그리고 뛰어난 개발자들의 손을 거쳐 품질 높은 소프트웨어를 만들어 낸다면 좋겠으나, 현실적으로는 거의 불가능하다. 이러한 집중되고 과투자 된 방법으로 소프트웨어를 만들어내는 분야라는 것이 과연 실제로 존재할 것에서부터 의문이 생긴다. 의문을 풀기에 앞서 소프트웨어 품질을 높이기 위한 최종적인 결론부터 먼저 이야기해보겠다.

인간이 코딩하면 버그가 생긴다 그렇다면?

어떤 소프트웨어를 만드는데 있어서 가장 오류가 적게 만드는 이상적인 방법은 바로 ‘인간’의 개입이 최소화하는 것이라고 생각한다.

‘개발자는 오류를 만들어낸다’

최후의 프로그래머가 만들어낸 최후의 컴파일러가 인간의 마지막 코딩이 되는 시기가 올수 있을지는 모르겠으나, 대표적으로 ‘Formal Language(형식언어)’라고 부르는 영역이 있다. 소프트웨어언어나 정규언어, 유한 오토마타 등의 세계는 형식언어를 어떻게 정의하느냐에 따라 오류와 품질이 결정된다고 생각되기도 한다. 현재 우리의 소프트웨어 프로그래밍도 이러한 형식언어의 세계의 지배하에 있다고 보는 것이 맞다.

우선 대부분의 프로그래머들은 ‘현실’을 시스템에 ‘시뮬레이션’하는 것을 평생의 업으로 살아가는 것이라고 정의하자. 그럼 형식언어는 ‘구조, 범위 등이 명확히 규정된 언어, 자연 언어의 문법구조를 수학적 측면에서 형식화한 것으로 자연언어보다 훨씬 간단한 구조의 인공 언어’라고 설명된다. 위의 말자체가 어렵지만, 저렇게 명확하게 설명한다. 이러한 내용을 간단하게 설명하면 다음과 같이 쉽게 설명할 수 있겠다. 개발자들이 문제를 인식하고 소프트웨어를 개발하면서 만나는 구조적인 부분인 패턴, 중복, 라이브러리, 컴포넌트, 서비스 이 모든 것들을 단순화한 함수로 설명하려 노력하는 것이 소프트웨어 개발활동, 형식언어로 만들어가는 활동이라 할 수 있겠다.

조금 비약하면 어떤 도메인이나 특정 목적에 맞는 시스템을 디자인하고 그 시스템을 구현하고 설명하는 ‘형식언어’를 만드는 것이 프로그래머의 일이라고 생각한다. 그래서 프로그래머들은 처음에는 범용적인 프로그래밍언어를 사용해 해당 도메인을 시뮬레이션하다가 해당 도메인에 맞는 구조를 발견하고 이를 구조화해 이에 대응되는 기능과 환경들을 서술한다. 궁극적으로는 해당 도메인을 형식언어 수준으로 설명 가능한 세계를 창조하고 그것을 표현하는 것이 프로그래머가 해당 도메인을 구현하는 가장 궁극적인 방법이라고 생각한다. 어떻게 보면 그것이 가장 ‘고품질의 소프트웨어’를 얻을 수 있는 방법이라고 정의할 수 있지 않을까? 가장 궁극적인 시뮬레이션은 그 세계를 표현하는 언어를 만들어내는 것이라고 생각한다.

가장 고품질이 요구되는 소프트웨어 개발 분야

실제 이런 식의 소프트웨어 개발이 이루어지는 분야가 있다. 생각보다 가까이서 이러한 분야를 접할수 있는데, 대표적인 것이 원자력, 군용기, 항공기, 선박 등의 분야가 이에 속한다.

최근에 국내에서 진행된 사업 중의 하나인 PKX(고속정) 개발사업을 예로 들어보자. 당시 신문기사를 살펴보면 PKX-B의 24대 생산에 2조 1,300억 원의 사업비가 책정됐다가 실제 사업 시행 시 18대 생산으로 조정되고 총 사업비 역시 1조 8,900억 원으로 조정됐음을 알 수 있다.

이를 소프트웨어 개발자의 입장에서 생각해보자. 실제 이 PKX 사업에 소프트웨어 개발비용이 얼마나 들어갔을까? 주변을 수소문해 얻은 자료에 의하면 PKX 사업에 투자된 총 예산 1조 8,900억 원 중에 1차적 소프트웨어 개발 비용에 680억 원 정도가 투여됐다고 한다. 단순계산만으로도 예산의 60%를 넘는 금액이 소프트웨어 개발비용에 투자된 셈이다. 물론 2차 이후는 기밀로 정의돼 더 세부적인 내용은 알지 못하지만 이렇듯 예산만 봐도 소프트웨어 개발이 PKX 사업에서 큰 비중을 차지하고 있음을 알 수 있다.

현대의 고도화된 산업제품들의 소프트웨어 투자비용은 상상을 초월하고 있다. 믿을 만한 자료를 참조하면 국내에서 생산된 T-50 고등훈련기 가격의 30%는 소프트웨어 가격이고 미국의 F-22 프로젝트의 경우에도 제작비용의 55%가 소프트웨어 개발비용이다. 이지스함의 경우에도 50%가 소프트웨어 제작비용을 차지한다. 이처럼 고도의 제작기술과 비용이 투하되는 시점에서의 소프트웨어의 품질은 이를 초월하는 품질검증비용이 투자돼야 한다(그래서 항공기 소프트웨어는 각각 블록1, 2, 3 버전이 따로 만들어진다. 항공기 시뮬레이션의 피드백된 결과물을 계속 해당 소프트웨어에 반영해 실제 비행의 정보들을 가지고 계속 수정해 향상시키는 것이다).

일반적인 비행기 항공엔진 제어 소프트웨어로 약 80만~110만 라인의 제품이 만들어진다. 이때 가장 중요한 것은 무엇일까? 모든 소프트웨어의 개발 시 기본적인 내용은 동일하다. 그것은 ‘이 소프트웨어가 제대로 동작하는가?’를 증명하는 것이다. 풀어서 설명하면 다음의 2가지로 간략하게 설명할 수 있겠다.

1. 요구사항을 어떻게 표현하는가?

2. 분기/조건 등의 소프트웨어 수행조건이 제대로 구현됐는가?

중요한 것은 이것을 어떻게 객관적으로 증명하고 보여주는가다. 또한 항공기같이 작은 오류가 큰 사고로 연결될 수 있는 경우나 미사일처럼 수십억 원을 호가하는 제품은 그 품질을 증명하는 방법 또한 매우 엄격하고 신중하다.

대표적인 예로 항공안전인증의 do178B를 들 수 있겠다. 이 인증방법을 짧게 설명하면 항공기에 사용된 소프트웨어의 안정성을 어떻게 검증하고 또 어떻게 인증할 것인가에 대한 자세한 기준들이다. 이 인증 기준으로 항공기에 사용될 소프트웨어들의 안정성이 증명되고 인정받게 된다. 그렇기에 엄청나게 높은 가격을 형성하고 있다.

또한 엔지니어링 공학의 근간이라고 할 수 있는 IEC-61508은 이러한 ‘기능 안전’과 관련된 국제적인 규격을 정의한다. 대부분의 안전과 관련된 기준들은 이를 기준으로 정의될 정도로 이 IEC-61508은 기능 안전 시스템에 대한 요구사항 명세, 설계, 개발, 설치, 운영, 유지보수의 표준이다. 각 제품들은 이를 통해 ‘Functional Safety'에 대한 국제적인 규격을 갖췄음을 증명한다. 이를 좀더 세분화하면 다음과 같다.

• IEC 62278, 62279, 62280, EN 50129 : 철도(Railway)

• IEC 62061 : 기계류(Machinery)

• IEC 61511 : 공장 계측 제어 설비(SIS) 프로세스

• ISO 26262 : 자동차(Automotive)

이러한, IEC 61508의 기본적인 목적은 ‘실질적인 상황에서 신뢰성 있게 구동되는 시스템이 달성해야할 요구사항을 만드는 것’이다. 2010년 Edition 2가 업데이트됐고, 현재 법적인 강제 사항은 아니지만 유럽, 미국 등의 선진국에서는 2000년대 초부터 안전필수(safety-critcal) 시스템인 원전, 항공, 의료, 철도, 장치산업 등에서 활용되는 컴퓨팅 자동제어 시스템의 안전을 위해 IEC-61508을 근간으로 기능안전성(functional safety) 검증을 요구하고 있다.

유럽 등지에 관련 제품을 수출하는 한국기업의 경우에도 수입처가 IEC61508과 관련된 인증을 요구하는 경우가 늘고 있어, 이를 기준으로 제품을 만드는 것이 점차 중요해지고 있다. 그런데 아이러니하게도 국내 자동차 기업들은 이 기준에 준하는 제품을 만들기 위해 노력하기 보다는 인증의 또 다른 항목인 ‘일정 수치 이상의 물량을 생산하고 사고율을 통해 얻는 실증적인 자료가 만족될 시 안전인증을 통과한 것으로 본다‘는 항목을 충족시켜 인증을 받고 있다. 이 사실을 알았을 때의 충격은 지금도 잊히질 않는다.

소프트웨어 아키텍처의 귀중한 실패경험 사례

어느 국가의 고속정 개발사업 사례를 통해 간단하게 설명할 수 있다. 해당 시스템은 대략 150여개의 고속정 서브시스템들을 통합 운영할 수 있는 지휘통제시스템을 개발하고 구현하는 프로젝트에서 발생한 사례로, 각각의 서브시스템들이 데이터통신을 통해 실시간으로 운용되는 시스템을 디자인하는 프로젝트였다. 서로 간의 단위 테스트에는 아무런 문제가 없었는데 실제 지휘통제시스템 전체를 가동하고 150여개의 서브시스템을 모두 통합해 운용하는 테스트를 실시했더니 첫 가동 시 모든 시스템이 레디 상태가 되는데 무려 이틀이나 걸렸다.

이것을 대표적인 아키텍처 디자인 실수 사례로 꼽을 수 있겠다. 일종의 단위테스트는 통과했지만 통합테스트가 실패한 케이스로, 이런 구조적인 상황을 예측하지 못한 것은 소프트웨어 아키텍처의 중대한 품질속성 위반이라고 할 수 있다. 각각의 서브시스템들 간의 운용에는 문제가 없었지만 모든 채널을 식별하는데 2일이 걸렸다는 말은 실제 사용해야 하는 상황에서 해당 고속정이 전원을 올린 뒤 2일이 지나야 움직일 수 있다는 말이기 때문이다.

논리적으로 동작 가능한 소프트웨어를 만드는 것과 실제 사용이 가능한 소프트웨어를 만들어 서비스하는 것은 전혀 다른 이야기다. 그래서 소프트웨어 아키텍처에게 있어 가장 중요한 품질속성을 어떻게 도출하고 이를 어떻게 관리하느냐가 이 문제의 핵심을 차지한다. 대부분의 고품질 소프트웨어를 만드는 프로세스에는 아예 이 부분이 비용과 패키지, 프로세스의 모든 부분에 반영돼 있다. 결론적으로 비용투자 없는 고품질이란 존재하지 않는다고 봐도 무방하다.

고품질 소프트웨어를 위한 조건

항공기와 고속정 개발 등에서는 이미 소프트웨어의 개발비용은 절대적인 위치를 굳히고 있고 해당 소프트웨어를 고품질로 제작하기 위한 수많은 기준과 조건　또한 수많은 논의를 통해 국제표준과 기준들이 만들어져있는 상태다. 그렇다면 기업에서 사용하는 IT리소스에 대해서는 뭘 기준으로 고품질 소프트웨어임을 판단하거나 효율적이라고 볼 수 있을까?

정보통신부고시로 제시된 ‘소프트웨어품질보증기준’은 너무도 광범위하고 교과서적인 이야기인데다 그만큼 모호하다. 물론 이 기준을 충족하는 조직이나 기준을 만들고 처리하는 것 또한 현실적으로 매우 어려운 게 사실이다. 그렇다면 현실에 맞춘 최선은 어떤 것일까?

공개 소프트웨어포털이 2012년 9월 제시한 소프트웨어품질검증분야의 공개 소프트웨어목록을 살펴보면 테스트 관리 4종, 형상관리 7종, BTS 9종, 테스트 도구 10종, 정적분석도구 13종에 대해 언급하고 있다. 그 외에도 2008년 11월 6일에 공표된 ‘소프트웨어 품질인증의 세부기준 및 절차’를 통해서도 꽤 많은 소프트웨어 품질인증의 세부적인 절차와 기준들을 제시하고 있다.

결론부터 이야기하면 여기서 언급한 ‘기준’과 ‘가이드라인’을 충실하게 따른다면 소프트웨어의 ‘품질’을 보장할 수 있는가? 문제는 이런 기준과 가이드라인으로 소프트웨어를 개발하기에는 현재 책정된 예산이나 국내 소프트웨어 개발 산업의 구조와는 맞지 않는다는 것이다. ISO, IEEE, IEC, CMMI 등의 기준과 절차, 가이드라인이 중요한 것이 아니라, 그 기준과 품질을 수행할 수 있는 개념과 마인드를 가지고 있는지가 중요하다. 문화가 바뀌지 않는다면 도구는 아무 소용이 없다.

소프트웨어 품질은 너무 어렵다

소프트웨어분야에서 특정시점을 잡고 ‘달성됐다’고 말할 수 있다는 것은 거의 불가능에 가까운 일일지도 모른다. 소프트웨어 품질은 지속적으로 관리돼야 하는 활동(on going activity)이기 때문에 테스트와 개발활동이 언제나 평행선을 그리면서 움직여 특정시점을 잡기도 어렵다. 소프트웨어 테스트 계획은 요구사항 단계에서부터 시작하고 개발 생명주기 동안 논스톱으로 계속 수행되며 소프트웨어의 품질을 향상시키는 것이기 때문이다.

일반적으로 ‘소프트웨어 개발을 준비한다’하면 테스트부터 준비하라고 말한다. 국내는 ‘on going activity’를 바이블 삼아 활동에 들어가는 비용과 리소스, 시간을 최소화 혹은 무시하는 것이 관행처럼 굳어져있다. 그런 식으로 우리는 프로젝트를 구성할 때 최악의 상황은 전혀 고려하지 않는다. 언제 어떻게 닥쳐 올지 모르는 최악의 상황에 대한 대비가 너무 소홀하다고 할까?

‘당신은 정말 고품질의 소프트웨어를 원하는가?’

그런데 여기서 한 가지 의문이 생긴다. 이렇게 큰돈을 들여 힘들게 고품질의 소프트웨어를 원하는 이유가 뭘까? 이 질문에 답하기 위해 ‘지금 만들고 있는 소프트웨어는 어느 정도 품질의 소프트웨어를 구축해야 고품질이라고 인정받는가?’부터 출발해보자. 대부분의 소프트웨어 개발 방법론이나 품질과 관련된 콘텐츠들을 살펴보면 그 정도에 대해 개발자의 관념과 경험에 의존해 그 상황을 결정한다고 명확하게 설명돼 있다.

소프트웨어 개발방법론에 있어서 실버블렛(어떤 문제 해결을 위한 묘책, 특효약)은 존재하지 않는다. 다만 소프트웨어 개발에도 유행이 존재할 뿐이다. 사람이 바뀌지 않으면 도구와 방법론은 언제나 무용지물이라는 걸 잊어선 안 된다. 애자입 도입 초창기 경험 없는 사람들이 ‘큰 고려 없이 문서 작성도 필요하지 않은 것이 애자일’이라고 까지 말하는 게 국내 소프트웨어 개발 분야의 실상이다 보니 애자일을 프로세스의 일부라고 주장하는 사람까지도 등장할 정도로 왜곡돼 버렸다. 실제 산업현장에서의 이러한 화두는 끝도 없이 이어진다. 필요로 하는 방법론에 대해 제대로 인지하지도 못하고 있는 것이 우리의 현실이다.

귤은 왜 탱자가 됐는가

옛 말씀에 귤이 강을 건너면 탱자가 된다 했다. 강남에서 잘 열리던 귤나무를 강북으로 옮기니 원래 귤이 자라던 좋은 토양이 아닌 거친 땅의 영향을 받아 귤이 탱자같이 됐다는 말이다. 아무리 좋은 문화나 생각일지라도 배경, 환경이 바뀌면 다른 식으로 해석되는 것은 당연할 런지도 모른다. 애자일은 ‘조기 참여(Early Involvement)’를 달성하기 위한 현실적인 접근방법을 다룬 철학이라는 것을 항상 염두에 두자. 반복적 개발 모델이나 점진적 프로세스는 애자일이 지향하고 있는 조기 참여를 이루기 위한 도구일 뿐 그 자체가 애자일인 것은 아니다. 물론 스크럼, 스프린트 등은 프로세스이며, 이런 프로세스는 개선이 가능하지만 애자일 같은 철학은 개선되는 것이 아니다. 철학은 개념적인 틀일뿐이다.

애자일을 프로세스라고 착각하고 있다면 다시 한 번 애자일 선언문을 읽어보고 그들이 2000년에 모여서 무슨 고민과 생각을 했는지 살펴보자. 서로 소통하고 호흡하지 않는 자리에서 애자일이라는 단어를 떠올린다는 것 자체가 우스운 일이다.

천재 한명이 소프트웨어품질을 높일 수는 없다

국내에서 故스티브잡스와 같이 개발을 한다 생각해보자. 일단 故잡스옹이 한국어도 잘한다고 하자. 그래도 우리가 아는 그의 활약대로 일하기는 힘들다. 그의 인생은 실패와 재기가 반복되다 나중에서야 상승곡선에 이르는 삶인데 국내에서라면 어림도 없는 이야기다. 이미 예전에 ‘투자가치가 없음’, ‘실패’ 낙인이 찍혀버린다.

그런데도 아이러니하게 국내는 뛰어난 천재와 성공한 사람을 정말 좋아하며, 스티브잡스 같은 사람이 우리나라 사람이었으면 한다. 물론 우리나라에도 그런 개발자들이 있기는 하다. 하지만 그나마 이런 개발자들도 부지불식간에 우리의 기억에서 사라진다. 대한민국 사회는 한 번의 실패도 용서(?)하질 않는다. 소프트웨어 개발은 실패를 축적한 경험이 가장 중요한데 우연히 좋은 소프트웨어를 만들어, 혹은 우연히 좋은 소프트웨어가 돼 스타가 되는 것만을 생각한다. 무슨 소프트웨어 개발을 유전 파듯 우연에 기대야 하는 현실이 참으로 개탄스럽다.

게다가 국내는 소프트웨어 개발이나 테스트의 설계품질이나 코드 품질을 프로그래머의 역량에 전가한다. 실제 품질이나 비용에 관한 문제는 고려하지 않고 말이다. 이에 대한 객관적인 증명이나 타당성에 대한 검증은 오로지 단위 서비스나 컴포넌트 단위로만 진행시킨다. 그러니 고품질이 유지될 수 없다. 그러다보니 소프트웨어 공학에서 추구하는 ‘포괄적인 개념을 경험하고 습득한 소프트웨어 품질 전문가’는 육성되지 못하고 해본 사람 정도만 존재하게 된다.

그래서 오늘날 ‘가짜 공학자’들이 판치는지도 모르겠다. 실제 업계에서 일하다 보면 이런 가짜 공학자들을 많이 만나게 된다. 일반적으로 공학자들이 해결해야하고 중재해야할 문제의 방기를 넘어 누구의, 무엇이 잘못인지도 모르고 그저 티격태격하고 있는 것 같다. 이런 상황인지라 아키텍쳐를 ‘화백’이라고 비하하기에 이르렀다. 실제 구현할 수 없는 이론적인 그림을 그린다는 게 아니라 그냥 그림만 그리는 화백이라는 것. 업계에서는 이런 짓(?)을 ‘화백질’이라고 한다.

그렇다면 이런 상황에 빠진 아키텍칭을 어떻게 해야 견인하고 품질을 유지할 수 있을까. 결국 소프트웨어 개발 방법론에 있어 가장 중요한 것은 서로간의 신뢰라고 본다. 아무리 멋진 말로 포장한다고 하더라도 결국 신뢰를 만들지 못하면 아무 것도 이루지 못한다. 또 하나의 포인트는 소프트웨어 개발에 있어 ‘할 것은 해야’ 한다는 태도를 가지는 것이다. 시간도, 인력도 한정돼 있어 추가는 힘들다. 어차피 품질에 대한 정의도 제대로 세워져있지 않다면 담당자로써 어떻게 해야 할까? 당장 때려치우고 나와야할까? 하지만 실제 우리의 입장은 그렇지 못하다. 그렇다면 어쨌든 할 수 있는 일을 해야겠지 않겠는가.

즉 ‘모듈-컴포넌트 테스트’를 시작하자는 것이다. 구슬이 서 말이라도 꿰어야 보배라고 어쨌든 뭐라도 해야 목걸이가, 제품이 된다. 행동하지 않는 것은 아무런 소용이 없다. 행동하지 않는 소프트웨어 개발자는 푸념만 늘어놓는 투덜이 게으름뱅이일 뿐이다.