유신의 "내일의 소프트웨어"

소프트웨어는 피시(PC) 밖에 더 많다. 스마트폰에서, 연구실 시뮬레이션에서, 위험관리 시스템에서…, 소프트웨어가 사회를 움직인다. 그러나 정작 우리는 소프트웨어에 관해 얼마나 많은 이야기를 알고 있을까?

“오류 존재를 보여도 오류 없음을 보일 순 없다”

[5] 소프트웨어 테스팅과 ‘부족한 근사값’


00swtesting.jpg » 자기가 작성한 프로그램이 제대로 작동하는지 확인해 보는 가장 자연스러운 방법은 몇 가지 입력값을 이용해 프로그램을 실행해 본 뒤 제대로 결과가 나오는지 확인해보는 것이다. 이런 자연스런 테스팅 이면에는 사실 복잡한 문제들이 자리잡고 있다. 사진/ Wikimedia Commons


깐, 자신이 프로그래머라고 상상해 봅시다. 방금 회사의 다음 프로젝트 중 일부로 사용할 중요한 프로그램 하나를 작성했습니다. 상사에게 이 프로그램을 넘기기 전에 자신이 작성한 프로그램이 ‘제대로 작동하는지’ 확인해보고 싶습니다. 어떤 방법을 이용해서 작동 여부를 확인하시겠습니까? 언뜻 보기에 사소하고 간단해 보이는 이 질문 뒤에는 녹록하지 않은 양의 소프트웨어 공학 연구가 버티고 있습니다.



간단한 테스트 뒤편의 복잡한 문제들

00line.jpg

아마 많은 독자 분들이(특히 프로그램 개발 경험이 있는 분이라면 더욱 더) 프로그램이 제대로 작동하는지 확인하기 위해서는 “테스트”를 거쳐야 한다고 답하셨을 거라고 믿습니다. 그런 믿음의 근거는 자신이 만든 도구를 경험적으로 시험해 본다는 행위가 ‘호모 파베르(Homo Faber)’한테는 본능에 가까운 반응이기 때문입니다. 강력 접착제로 부러진 물건을 붙일 때 입김을 호호 분 다음에, 잠시 시간이 흐른 뒤에 살짝 힘을 주어 부러진 부분이 제대로 붙었나 시험하는 것보다 더 자연스러운 일이 있을까요? 마찬가지로 자기가 작성한 프로그램이 제대로 작동하는지 확인해 보는 가장 자연스러운 방법은 몇 가지 입력값을 이용해 프로그램을 실행해 본 뒤 제대로 결과가 나오는지 확인해보는 것입니다. 일견 당연한 이야기 같습니다. 그런데 이 자연스런 행위를 둘러싸고 온갖 복잡한 연구가 행해지는 이유는 무엇일까요? 이를 알아 보기 위해서, 우선 강력 접착제의 예를 들어 용어를 몇 가지 설명해보겠습니다.


‘테스트 대상(test subject)’은 작동 여부를 확인하고자 하는 바로 그 객체입니다. 프로그래머의 예에서는 방금 작성한 프로그램 코드일 것이고, 접착제의 예에서는 방금 강력 접착제로 붙인 부러진 그릇일 것입니다. ‘테스트 입력값(test input)’은, 입력이라는 단어를 컴퓨터 프로그램과 조금 별개로 생각해보면, 대상이 제대로 작동하는지 보기 위해 사용하는 시험값입니다. 강력 접착제의 예에서는 잘 붙었나 확인해 보기 위해 손으로 가하는 힘이 바로 테스트 입력값입니다.


마지막으로 ‘테스트 오라클(test oracle)’은 대상에 입력값을 가했을 때 나온 결과가 올바른지 아닌지 말해 줄 수 있는 무언가입니다. 깨진 그릇이 잘 붙었나 시험해보기 위해서는 복잡한 오라클이 필요하지 않습니다. 손으로 적당히 힘을 줬을 때 다시 떨어지지 않으면 테스트 합격입니다. 오라클은 무조건 합격을 보장하는 ‘정답’과는 다른 개념입니다. 예를 들어 접착한 위로 자동차를 몰고 지나간다면 그릇은 당연히 산산조각이 날 테지만, 자동차의 무게는 적절한 입력값이 아니므로 오라클은 여전히 결과가 올바르다고 할 것입니다.


소프트웨어를 테스트 하기 위해서는 테스트 입력값과 테스트 오라클이 필요합니다. 직관적으로 볼 때 테스트 입력값은 소프트웨어가 처리해야 할 업무에서 발생할 수 있는 모든 경우의 수를 고려해야 할 것이고, 오라클은 이 모든 경우의 수에 대해 소프트웨어의 용도와 프로그래머의 제작 의도를 고려해 올바른 답을 줄 수 있어야 합니다. 여기에서 문제는 고려해야 할 입력값의 개수는 너무 많은 반면에 프로그램의 의도가 무엇인지는 늘 불분명하다는 것입니다. 우선 입력값의 개수가 왜 그렇게 많은지부터 알아봅시다.



우주의 별보다 많은 테스트 입력값

00line.jpg

우선 입력값의 경우의 수를 살펴봅시다. 소프트웨어 테스팅에 관련된 연구 문헌에 종종 등장하는 프로그램 중에 ‘삼각형 프로그램(triangle)’이 있습니다. 이 프로그램의 제작 의도는 세 개의 정수를 입력값으로 받은 뒤, 이를 세 변의 길이로 삼는 삼각형이 존재하는지, 그리고 존재한다면 어떤 종류인지(정삼각형, 이등변삼각형 등)를 답하는 것입니다. 사실 연구 문헌에 등장하기가 조금 멋적을 만큼 간단한 프로그램으로, 삼각형의 종류에 대한 개념이 있고 프로그래밍을 한두 달 정도 배운 사람이라면 누구나 작성할 수 있는 간단한 프로그램입니다.


00swtesting2.jpg » 세 개의 정수값을 입력받아 이를 변의 길이로 하는 삼각형의 종류를 출력하는 삼각형 프로그램은 초보자도 작성할 수 있는 스무줄 남짓의 간단한 프로그램이다. 하지만 삼각형 프로그램을 포괄적으로 테스트 하려면 무려 약 8의 28승가지 입력값을 모두 실행해야 한다. 이는 우주에 존재하는 모든 별의 갯수에 대한 추정치인 10의 24승보다 19배 이상 큰 숫자이다. 그림/ 유신 포괄적 테스팅(exhaustive testing)이란 말 그대로 프로그램이 받아들이는 테스트 입력의 모든 경우를 테스트해서, 프로그램이 가능한 모든 입력값에 대해 올바르다는 것을 확인하는 방법입니다. 그러면, 이 삼각형 프로그램을 가능한 모든 경우에 대해 테스트한다는 것은 어떤 의미일까요? 컴퓨터가 다룰 수 있는 범위 안에서 가능한 정수 세 개의 조합을 모두 실행해본다는 뜻입니다. 여러분이 사용하는 일반적인 32비트 컴퓨터가 다루는 정수의 범위는 -231부터 231-1까지, 총 42억 9496만 7295개입니다. 이 범위를 따르는 변수가 3개이므로 삼각형 프로그램의 입력으로 가능한 조합의 수는 거의 828에 가깝습니다! 이게 얼마나 큰 숫자인지 가늠하려면 현대 천문학이 관측 가능한 우주의 별 개수(추정치)가 1024개인 것을 생각해보면 됩니다.


론 삼각형 프로그램을 테스트하기 위해 실제로 8의 28승개 입력값이 필요하다고 믿는 사람은 없습니다. 하지만 삼각형 프로그램은 일반적인 프로그램의 가능한 입력값의 가짓수가 얼마나 큰지를 보여주는 좋은 예입니다. 프로그램의 입력값이 단순한 숫자보다 더 복잡한 구조를 가지면 문제는 더 심각해집니다. 워드프로세서를 테스트하기 위해 A4 용지 한 장에 들어갈 수 있는 모든 문자열을 고려한다면, 가능한 입력값의 종류는 몇 가지일까요? 분량 제한을 뒀음에도 불구하고 검사해야 하는 문자열 조합의 개수는 어마어마합니다. 조금 억지 같지만 엠피3 플레이어를 테스트하기 위해 가능한 모든 음악을 이용할 수 있을까요? 심지어 프로그램에 따라서는 입력값 뿐 아니라 다양한 실행 환경을 모두 고려해서 테스트해야 하는 경우도 있습니다.


경험적인(하지만 거부할 수 없는, 거의 절대적인) 법칙에 따르면, 의미 있는 혹은 쓸모 있는 프로그램이라면 포괄적 테스팅을 하기엔 입력값의 가짓수가 너무 많습니다. 테스팅은 언제나 무한한 입력값들에서 극소수를 샘플링 해서 실행하는 행위이고, 테스팅을 통해 내리는 결론은 어떤 샘플링을 했느냐에 의해 제한됩니다. 다시 말해, 포괄적 테스팅을 하지 않는 한, 테스팅으로 확인할 수 있는 것은 실제 프로그램이 보일 수 있는 행동의 “부족한 근사값(under-approximation)”일 뿐입니다. 유명한 컴퓨터 과학자 다익스트라(E. Dijkstra)가 소프트웨어 테스팅에 대해 남긴 말은 부족한 근사값이라는 개념의 핵심을 관통합니다:


“테스팅은 프로그램 오류가 존재하는 것을 보일 순 있지만, 오류가 없음을 보일 수는 없다”


다시 말하면, 프로그램이 지금까지 실행해 본 테스트 입력값에 대해 모두 맞는 답을 내놓았더라도, 단지 운이 좋게 문제 없는 입력값만을 샘플링했을 가능성이 언제나 존재한다는 것입니다. 하지만 특정 입력값에 대해 프로그램이 잘못된 작동을 하는 것이 실제로 관찰되면 프로그램에 오류가 있다는 것은 부정할 수 없는 사실일 것입니다. 소프트웨어 테스팅 연구의 궁극적인 목적중 하나는 이 부족한 근사값을 최대한 정확하게 만드는 것입니다.



사용자가 오류를 더 잘 찾는 이유

00line.jpg

이상하게 들릴지 모르지만 부족한 근사값 문제에 가장 취약한 사람은 바로 프로그램을 개발한 개발자 본인입니다. 하나의 독립된 프로그램은 작성자가 의도한 바를 이루기 위한 독립적인 논리법칙의 집합이고, 이 법칙과 가장 친숙한 사람이 개발자입니다. 개발자가 프로그램을 작성하는 것은 끊임없이 “안되는 것을 되게 하는” 과정이고, 따라서 개발자가 샘플링하는 테스트 입력값은 정상적인 기능 범주에 포함되는, 쉽게 말해서 “되는” 입력값이기 쉽습니다. 프로그램이 사용자의 손에 넘어갔을 때, 개발자가 전혀 생각해보지 못한 “안 되는” 사용 형태에 노출되어 오류가 발견되는 것은 흔히 있는 일입니다.


프트웨어 테스팅 연구의 상당 부분이 포괄적 테스팅을 대신해서 입력값을 체계적으로 샘플링하는 방법에 바쳐집니다. 개발자의 주관 대신 프로그램의 구조와 제작 의도를 반영해서 최대한 포괄적 테스팅에 가까운 효과를 얻고자 하는 것입니다. 하지만 제 아무리 기발한 테스팅 기술을 이용하더라도 애초에 샘플링해야 하는 입력값의 공간이 너무 큰 데에는 장사가(?) 없습니다. 더군다나 프로그램에 직접적으로 입력되는 값 말고 프로그램이 실행되는 하드웨어까지 고려해야 하는 테스트의 경우에는 문제가 더욱 심각합니다.


일례로 애플의 맥 운영체제가 마이크로소프트의 윈도우즈 운영체제보다 평균적으로 조금이라도 더 안정적일 수 있었던 이유 중 하나는, 애플은 자사의 운영체제를 스스로 제작하는 맥 컴퓨터에서만 테스트하면 되지만 마이크로소프트는 윈도우즈 호환 피시(PC) 모두에 대해 테스트를 해야 한다는 점입니다. 사실상 생산되는 모든 윈도우즈 호환 PC에 대해 운영체제를 테스트할 방법이 없으므로 (가능한 피시 부폼의 조합은 역시 무한대에 가까울 것입니다) 특정 피시에서 마이크로소프트가 예견하지 못한 문제가 발생할 가능성이 상대적으로 높은 것입니다.


주변을 돌아보면 우리가 사용하는 소프트웨어의 구조와 복잡도가 테스팅 연구보다 발이 빠르지 않나 하는 생각이 듭니다. 인터넷과 스마트폰 시대의 개발자는 자기 프로그램이 가지는 무한한 입력값은 물론 다른 사용자 및 네트워크와의 상호작용, 전력 사용량, 기기의 발열 등 기존에 생각지 못했던 다양한 요소를 고려해야 하기 때문입니다. 수많은 소프트웨어 공학 연구실에서 연구자들이 머리를 싸매고 있는 이유입니다. 다음 편에서는 테스트 오라클에 대해 알아보겠습니다.

  • 구글
  • 카카오
  • 싸이월드 공감
  • 인쇄
  • 메일
유신 카이스트 교수, 전산학
소프트웨어 테스팅 연구로 박사학위를 받은 소프트웨어공학 연구자다. 진화 알고리즘과 인공지능 기술, 정보이론 등을 소프트웨어 공학 문제에 접목하는 데에 관심이 많다. 전 영국 런던 유니버시티칼리지 조교수, 현 카이스트 전산학부 조교수
이메일 : shin.yoo@kaist.ac.kr       트위터 : @ntrolls      
블로그 : londonforgeeks.tumblr.com

최신글




최근기사 목록

  • 검증불가능 프로그램, 어떻게 검증할 것인가?검증불가능 프로그램, 어떻게 검증할 것인가?

    내일의 소프트웨어유신 | 2013. 06. 28

    [6] ‘고차변형 테스팅’ 방법3차원으로 초신성의 핵을 시각화하는 컴퓨터 시뮬레이션. 이제는 천체물리학은 물론 과학 여러 분야의 연구 상당 부분이 컴퓨터 내부에서 벌어진다. 그런데 이 시뮬레이션 프로그램에는 과연 오류가 없을까? 초신성의 ...

  • 강한 인공지능, 약한 인공지능강한 인공지능, 약한 인공지능

    내일의 소프트웨어유신 | 2012. 08. 14

    (4) 인공지능이란 대체 뭔가? 얼마 전 개봉한 영화 <프로메테우스(Prometheus)>에서 외계 생명체만큼이나 사람들의 관심을 끈 것은 인공지능 로봇 데이빗이었습니다. 뛰어난 계산 능력과 무한에 가까운 기억력을 지녔지만 감정을 느끼지 못하기 때...

  • [연재] 해도 해도 끝이 없는 계산[연재] 해도 해도 끝이 없는 계산

    내일의 소프트웨어유신 | 2012. 06. 19

    (3) 소프트웨어가 도무지 해결하지 못하는 세 가지: 두 번째, P=NP? 조금 있으면 여름 휴가철이 다가옵니다. 그런데 산으로 혹은 바다로 떠나는 사람이라면 누구나 여행 전 날 자기도 모르는 사이에 매우 복잡한 수학 문제를 풀고 있다고 하면 ...

  • [연재] 완벽한 백신SW 불가능한 이유, 튜링은 알고 있다[연재] 완벽한 백신SW 불가능한 이유, 튜링은 알고 있다

    내일의 소프트웨어유신 | 2012. 05. 22

    (2) 소프트웨어가 도무지 해결하지 못하는 세 가지: 첫 번째 '종료 문제' 지난해 과학계를 뜨겁게 달군 과학 뉴스 중 하나는 바로 중성미자 입자의 속력이 빛보다 더 빠르다는 어느 관측실험 결과였습니다. 이에 많은 사람들이 놀라움과 의구심을 나...

  • [새연재] PC 파란화면에 무오류 수학의 이상은 흩어지고[새연재] PC 파란화면에 무오류 수학의 이상은 흩어지고

    내일의 소프트웨어유신 | 2012. 04. 17

    (1) 연재를 시작하며 소프트웨어공학(Software Engineering)이라는 이름을 들으면 무엇이 연상되나요? 아마 대부분의 사람들이 “정보기술(IT) 강국” 혹은 “정보화시대” 등을 떠올리리라 생각합니다. 혹 주변에 IT업계에 종사하는 지인이 있는 경우...